Perbaiki Error Checksum Mismatch pada Sinkronisasi Cloud di RcloneView

6 April 2026 · 6 menit membaca

Senior Engineer

Checksum mismatch saat sinkronisasi cloud biasanya berarti sumber dan tujuan menggunakan algoritma hash yang berbeda, bukan berarti data Anda rusak. Berikut cara mendiagnosis dan mengatasinya.

Saat rclone melakukan sinkronisasi file antar provider cloud, ia membandingkan checksum untuk memverifikasi bahwa data yang ditransfer sesuai dengan aslinya. Jika provider sumber dan tujuan menggunakan algoritma hash yang berbeda — atau jika salah satu provider tidak mengembalikan checksum sama sekali — rclone dapat melaporkan mismatch atau mentransfer ulang file secara tidak perlu. Panduan ini menjelaskan apa yang sebenarnya terjadi dan cara memperbaikinya di RcloneView.

Kelola & Sinkronkan Semua Cloud di Satu Tempat

RcloneView adalah GUI lintas platform untuk rclone. Bandingkan folder, transfer atau sinkronkan file, dan otomatiskan alur kerja multi-cloud dengan antarmuka visual yang bersih.

Pekerjaan sekali klik: Salin · Sinkronkan · Bandingkan
Penjadwal & riwayat untuk otomatisasi yang andal
Bekerja dengan Google Drive, OneDrive, Dropbox, S3, WebDAV, SFTP, dan lainnya

WindowsmacOSLinux

Mulai Gratis →

Fitur inti gratis. Otomatisasi Plus tersedia.

Apa Arti Checksum Mismatch

Checksum (atau hash) adalah string dengan panjang tetap yang dihitung dari isi sebuah file. Jika dua file menghasilkan checksum yang sama, keduanya identik. Rclone menggunakan checksum untuk:

Memverifikasi upload — memastikan file di tujuan sesuai dengan sumber setelah transfer.
Mendeteksi perubahan — selama sinkronisasi, melewati file yang checksum dan ukurannya tidak berubah.
Menjamin integritas — menandai adanya kerusakan jika hash sebuah file tidak sesuai dengan yang diharapkan.

Mismatch berarti hash yang dihitung pada satu sisi tidak sesuai dengan sisi lainnya. Ini bisa menandakan kerusakan data yang sebenarnya, tetapi lebih sering mencerminkan ketidakcocokan algoritma hash antar provider.

Perbedaan Hash Spesifik Tiap Provider

Provider cloud yang berbeda mendukung algoritma hash yang berbeda pula:

Provider	Hash yang Didukung
Local disk	MD5, SHA-1, SHA-256 (tergantung OS)
Google Drive	MD5
OneDrive	SHA-1, QuickXorHash
Dropbox	Dropbox content hash (custom)
Amazon S3	MD5 (ETag, tapi tidak untuk multipart upload)
Backblaze B2	SHA-1
Azure Blob	MD5
SFTP	MD5, SHA-1 (jika didukung server)
Wasabi	MD5 (ETag)
Cloudflare R2	MD5 (ETag)

Saat melakukan sinkronisasi antar provider yang memiliki hash yang sama (misalnya, Google Drive MD5 ke Azure Blob MD5), checksum bekerja dengan mulus. Jika tidak ada hash yang sama (misalnya, Google Drive MD5 vs OneDrive QuickXorHash), rclone tidak dapat membandingkan checksum secara langsung.

Bagaimana Rclone Menangani Hash yang Tidak Cocok

Rclone cukup pintar dalam membandingkan hash:

Ditemukan hash yang sama — rclone menggunakan algoritma bersama tersebut untuk membandingkan file. Tidak ada masalah.
Tidak ada hash yang sama — rclone beralih ke perbandingan ukuran file dan waktu modifikasi. File dengan ukuran dan waktu yang sama dianggap identik.
Flag --checksum diaktifkan — rclone hanya menggunakan checksum (tanpa perbandingan waktu). Jika tidak ada hash yang sama, rclone akan mentransfer ulang setiap file karena tidak dapat memastikan kecocokannya.

Skenario ketiga ini adalah penyebab paling umum dari perilaku yang tidak diharapkan: mengaktifkan --checksum antar provider yang tidak kompatibel memaksa terjadinya transfer ulang yang tidak perlu.

Compare folders in RcloneView to identify mismatched files

Skenario Error Umum

Skenario 1: S3 Multipart Upload ETag Mismatch

Saat Anda mengunggah file besar ke S3 menggunakan multipart upload, ETag yang dihasilkan bukanlah hash MD5 sederhana — melainkan hash gabungan dari bagian-bagiannya. MD5 lokal dari file menurut rclone tidak akan cocok dengan ETag S3, sehingga memicu mismatch pada sinkronisasi berikutnya.

Solusi: Ini adalah perilaku yang wajar. Rclone menanganinya dengan menyimpan hash yang diharapkan dalam metadata jika memungkinkan. Jika Anda melihat transfer ulang pada file besar, Anda dapat dengan aman menggunakan --ignore-checksum untuk job sinkronisasi tersebut.

Skenario 2: Sinkronisasi Google Drive ke OneDrive

Google Drive menggunakan MD5 sedangkan OneDrive menggunakan QuickXorHash. Tidak ada algoritma hash yang tumpang tindih.

Solusi: Rclone secara otomatis beralih ke ukuran + waktu modifikasi. Jangan gunakan --checksum untuk kombinasi ini, atau setiap file akan ditransfer ulang.

Skenario 3: Remote Terenkripsi (Crypt)

Saat menggunakan rclone crypt, file terenkripsi memiliki hash yang berbeda dari sumber plaintext-nya. Rclone menangani hal ini secara internal, tetapi jika Anda membandingkan hash remote crypt dengan hash provider aslinya, keduanya tidak akan pernah cocok.

Solusi: Selalu bandingkan file melalui lapisan remote crypt, bukan dengan melihat langsung ke penyimpanan terenkripsi yang mendasarinya.

Mengonfigurasi Perilaku Checksum di RcloneView

Menggunakan Flag --checksum

Flag --checksum memerintahkan rclone untuk hanya menggunakan checksum (bukan waktu modifikasi) dalam menentukan apakah file perlu ditransfer. Aktifkan flag ini saat:

Sumber dan tujuan sama-sama mendukung algoritma hash yang sama.
Anda menginginkan jaminan integritas yang paling kuat.
Anda melakukan sinkronisasi antara local disk dan provider yang mendukung MD5.

Jangan gunakan flag ini saat:

Sumber dan tujuan tidak memiliki hash yang sama — ini akan memaksa transfer ulang semua file.
Anda melakukan sinkronisasi file besar ke S3 (ETag multipart tidak akan cocok).

Menggunakan Flag --ignore-checksum

Flag --ignore-checksum melewati seluruh proses verifikasi checksum. Gunakan flag ini saat:

Anda telah memastikan data sudah benar tetapi checksum tidak akan pernah cocok (misalnya, ETag multipart S3).
Anda menginginkan sinkronisasi yang lebih cepat dengan melewati perhitungan hash pada dataset yang sangat besar.
Sebuah provider mengembalikan hash yang tidak konsisten atau salah (jarang terjadi tetapi mungkin).

Jangan gunakan flag ini sebagai pengaturan default — checksum ada untuk mendeteksi kerusakan yang sebenarnya.

Configure sync job flags in RcloneView before execution

Memverifikasi Integritas Data

Jika Anda menduga terjadi kerusakan data yang sebenarnya, bukan sekadar ketidakcocokan algoritma hash:

Jalankan rclone check — ini membandingkan file sumber dan tujuan lalu melaporkan setiap perbedaan. Di RcloneView, Anda dapat menggunakan tampilan perbandingan folder.
Unduh dan bandingkan secara lokal — unduh file dari sumber dan tujuan, lalu hitung checksum lokal dengan md5sum atau sha256sum.
Periksa log transfer — tinjau riwayat job RcloneView untuk mencari error selama transfer awal.

Monitor transfer progress and verify checksums in RcloneView

Referensi Cepat: Matriks Kompatibilitas Hash

Arah Sinkronisasi	Hash yang Sama	Aman Menggunakan Flag Checksum?
Local ke Google Drive	MD5	Ya
Local ke OneDrive	SHA-1	Ya
Local ke S3 (file kecil)	MD5	Ya
Local ke S3 (multipart)	Tidak ada (ETag berbeda)	Tidak
Google Drive ke OneDrive	Tidak ada	Tidak
Google Drive ke S3	MD5	Ya (file kecil)
S3 ke Backblaze B2	Tidak ada (MD5 vs SHA-1)	Tidak
S3 ke Azure Blob	MD5	Ya (file kecil)

Memulai

Unduh RcloneView dari rcloneview.com.
Periksa dukungan hash provider Anda menggunakan tabel di atas.
Hindari --checksum antar provider yang tidak kompatibel untuk mencegah transfer ulang yang tidak perlu.
Gunakan perbandingan folder di RcloneView untuk memverifikasi hasil sinkronisasi secara visual.

Sebagian besar error checksum mismatch bukanlah kerusakan data — melainkan ketidakcocokan algoritma hash antar provider. Memahami hash apa yang didukung oleh setiap provider adalah kunci untuk menyelesaikan masalah ini dengan cepat.

Panduan Terkait: