Belajar Rsync - Sejarah, Latar Belakang & Mengapa Membutuhkannya
Menelusuri perjalanan rsync dari proyek yang ditulis Andrew Tridgell (pencipta Samba) dan Paul Mackerras pada 1996 hingga menjadi standar de facto backup & mirroring, serta memahami delta-transfer algorithm yang membuatnya hemat bandwidth dan mengapa versi 3.4.x kini penting dari sisi keamanan.
#Pendahuluan
Setelah di episode 0 kita menyiapkan environment — memastikan rsync ≥3.4.4 terinstall dan lab dua direktori siap — pada episode ini kita menarik napas sejenak dari hands-on dan memahami mengapa rsync ada. Sejarah sebuah tool mungkin terasa tidak penting, padahal justru di sanalah letak alasan mengapa desainnya seperti sekarang.
Mengapa harus memahami sejarah rsync? Karena rsync tidak lahir dari ruang rapat perusahaan, melainkan dari kebutuhan nyata para engineer yang frustrasi dengan sinkronisasi file yang boros. Memahami asal-usulnya akan menjelaskan keputusan-keputusan desainnya — mengapa rsync hanya mengirim bagian yang berubah, mengapa ia bisa di-resume dengan aman, dan mengapa ia menjadi fondasi sistem backup modern.
#Lahir dari Tangan Andrew Tridgell & Paul Mackerras
Rsync ditulis oleh Andrew Tridgell — nama yang sama di balik Samba, server file-berbagi untuk jaringan Windows — bersama Paul Mackerras. Rilis pertama terjadi pada tahun 1996, dan nama rsync adalah kependekan dari "remote sync".
| Fakta | Detail |
|---|---|
| Penulis | Andrew Tridgell (Samba) & Paul Mackerras |
| Rilis pertama | 1996 |
| Asal nama | "remote sync" |
| Bahasa | C |
| Pengelolaan | Samba project (lists.samba.org) |
Tridgell membawa kecerdasan yang sama dari Samba: memahami protokol secara mendalam dan membangun implementasi yang efisien. Rsync lahir dari rasa frustrasi dengan alat yang ada saat itu — rcp dan scp — yang menyalin seluruh file setiap kali, tidak peduli seberapa kecil perubahannya.
#Menggantikan rcp/scp
Sebelum rsync, cara standar menyalin file antar mesin adalah rcp dan scp. Masalahnya, keduanya selalu mengirim file utuh. Bayangkan file database 10 GB yang berubah 1 MB: scp tetap mengirim 10 GB penuh. Di era koneksi dial-up dan leased line yang mahal, ini pemborosan yang menyakitkan.
Rsync mengubah permainan: ia membandingkan sumber dan tujuan, lalu hanya mengirim bagian yang berbeda. Inilah yang membuatnya langsung populer dan, dalam tiga dekade, menjadi standar de facto untuk backup, mirroring, dan migrasi server di dunia Linux/Unix.
Note
scp masih ada sampai sekarang, tetapi untuk sinkronisasi berulang rsync selalu menang: scp tidak punya delta-transfer, tidak bisa melewatkan file yang sudah sama, dan tidak mendukung filter. Di episode 22 kita bandingkan keduanya secara lengkap.
#Delta-Transfer Algorithm
Jantung rsync adalah delta-transfer algorithm. Prosesnya kira-kira begini:
- Rsync di sisi penerima memecah file tujuan menjadi blok-blok berukuran tetap (biasanya 700 byte sampai 64 KB tergantung ukuran file).
- Untuk setiap blok, ia menghitung checksum lemah (rolling checksum) yang murah secara komputasi, lalu checksum kuat (hash) untuk konfirmasi.
- Sender menggunakan daftar checksum ini untuk mencari blok yang sudah ada di penerima — hanya blok yang tidak cocok yang dikirim.
Dampaknya: untuk file yang berubah sebagian, rsync mentransfer data berkali lipat lebih kecil dibanding ukuran file. Semakin besar file dan semakin sedikit perubahannya, semakin besar penghematannya. Kita bedah detail arsitektur algoritmanya di episode 2.
#Mengapa Rsync: Keunggulan Inti
Empat alasan rsync menjadi pilihan utama selama hampir tiga dekade:
| Keunggulan | Arti Praktis |
|---|---|
| Bandwidth minimal | Delta-transfer hanya mengirim bagian yang berubah |
| Resume aman | Transfer terputus bisa dilanjutkan tanpa mulai dari nol (--partial, episode 7) |
| Fleksibilitas flag | Lebih dari 100 opsi: filter, throttle, checksum, hardlink, ACL, dan banyak lagi |
| Mode lokal & remote | Satu binary untuk menyalin di mesin yang sama atau lintas SSH/daemon |
Kombinasinya jarang ditemukan di tool lain: rsync se-efisien algoritma modern, tetapi tetap seramah tool Unix klasik — mudah dipakai dari script, cron, dan pipeline CI.
#Keamanan: 3.4.x dan CVE
Rsync 3.4.x (2025-2026) adalah babak penting dalam sejarahnya: bukan karena fitur baru, melainkan karena pengerasan keamanan besar-besaran. Rsync 3.4.0 (Januari 2025) menutup 33 kerentanan, termasuk 2 RCE (CVE-2024-12084 dan CVE-2024-12085), heap buffer overflow, dan perbaikan perilaku --safe-links. Versi 3.4.3 dan 3.4.4 menyusul dengan tambalan tambahan (misalnya CVE-2026-29518 dan CVE-2026-4361).
Ini mengubah rekomendasi praktik: selalu pakai rsync ≥3.4.4. Versi 3.2.x yang lama — yang masih banyak terpasang di distro LTS lama — kini dianggap berisiko. Detail lengkap CVE dan mitigasinya kita bahas di episode 13.
#Timeline Singkat
| Tahun | Tonggak |
|---|---|
| 1996 | Rilis pertama rsync oleh Tridgell & Mackerras |
| 2000-an | Menjadi standar de facto backup & mirroring Unix |
| 2018 | Rsync 3.1.3 — versi paling banyak terpasang di distro LTS |
| 2025-01 | Rsync 3.4.0 — security release besar (33 CVE, 2 RCE) |
| 2025-2026 | 3.4.1, 3.4.2, 3.4.3, 3.4.4 — tambalan berkelanjutan |
| 2026-06-08 | Rilis 3.4.4 — versi yang dipakai di series ini |
#Penutup
Pada episode 1 ini, kalian telah menelusuri perjalanan rsync dari proyek 1996 karya Andrew Tridgell & Paul Mackerras hingga menjadi tool sinkronisasi paling tepercaya di dunia Unix.
Inti yang harus dibawa pulang:
- Rsync ditulis Tridgell & Mackerras, rilis pertama 1996; nama dari "remote sync".
- Ia menggantikan
rcp/scpkarena delta-transfer algorithm hanya mengirim bagian yang berubah. - Keunggulan inti: hemat bandwidth, resume aman, fleksibilitas flag, mode lokal & remote.
- Rsync 3.4.x adalah tonggak keamanan: 33 CVE ditutup termasuk 2 RCE; selalu pakai ≥3.4.4.
Di episode 2 selanjutnya, kita akan membedah konsep dasar dan arsitektur utama rsync — mode lokal vs remote (SSH dan daemon rsyncd di port 873), komponen-komponen utamanya, serta cara kerja rolling checksum dan hash di balik layar. Sampai jumpa di episode 2!