Belajar Rsync - Migrasi Server & Directory Sync
Menerapkan rsync untuk migrasi server nyata: memindahkan home, var/www, dan database dump antar host dengan --numeric-ids dan -H (hardlink), ditambah pembahasan jujur tentang keterbatasan rsync untuk sinkronisasi dua arah dan solusinya melalui unison.
#Pendahuluan
Semua materi sejauh ini berujung pada satu momen yang pernah dialami setiap sysadmin: pindah server. Entah upgrade hardware, migrasi cloud, atau konsolidasi data center — rsync adalah alat utama untuk memindahkan data tanpa downtime panjang.
Episode 11 memadukan semuanya: cara memigrasi direktori sistem penting (home, var/www, dump database) dengan fidelitas tinggi lewat dua flag yang sering terlupakan — --numeric-ids dan -H — lalu jujur tentang apa yang rsync tidak bisa lakukan: sinkronisasi dua arah.
#Migrasi Server: Skenario
Skenario umum: memigrasi dari server lama (old.example.com) ke server baru (new.example.com), sambil meminimalkan downtime. Strategi dua fase:
- Fase awal — salin data utama saat layanan masih jalan (bisa beberapa jam, boleh lambat, gunakan throttle episode 12).
- Fase final — hentikan layanan, jalankan rsync sekali lagi (hanya mengambil delta sejak fase awal, hitungan menit), lalu cut-over DNS/traffic.
rsync -avHAX --numeric-ids -e ssh \
/home/ /var/www/ root@new.example.com:/migrate-in/Fase final yang singkat itulah alasan rsync sempurna untuk migrasi: delta-transfer membuat "copy terakhir" hanya beberapa menit, bukan jam.
#--numeric-ids: ID Numerik
Secara default, rsync memetakan owner/group berdasarkan nama. Di mesin yang berbeda, nama user bisa menunjuk ke UID berbeda — hasilnya file bermigrasi dengan pemilik yang salah.
--numeric-ids menonaktifkan pemetaan nama dan menyimpan UID/GID numerik apa adanya:
rsync -av --numeric-ids /home/ root@new.example.com:/home/Important
--numeric-ids di sisi penerima berarti file dibuat dengan UID/GID numerik dari sumber. Jika di server baru user belum dibuat dengan UID yang sama, file akan tampak dimiliki user lain. Buat dulu user dengan UID/GID yang identik di server tujuan — urutannya: buat user, baru jalankan migrasi.
#-H: Hardlink
-H (--hard-links) mempertahankan hubungan hardlink antar file — sesuatu yang tidak dilakukan -a:
rsync -avH /var/www/ root@new.example.com:/var/www/Tanpa -H, dua file yang di sumber berbagi inode yang sama akan disalin menjadi dua salinan terpisah di tujuan — duplikat yang membengkakkan storage. Dengan -H, hubungannya dipertahankan. Untuk direktori yang memakai hardlink (misalnya backup berbasis --link-dest, Git alternatif, atau media library), flag ini wajib. Harga yang dibayar: rsync harus melacak semua file untuk mencocokkan inode, sehingga sedikit lebih lambat dan butuh memori lebih.
#Contoh Migrasi Lengkap
Migrasi database dump (misal PostgreSQL) — dump dulu, baru rsync:
pg_dump -Fc mydb > /var/backups/mydb.dump
rsync -avhP --numeric-ids /var/backups/ root@new.example.com:/var/backups/Pola yang sama berlaku untuk semua data sistem:
| Data | Perintah inti |
|---|---|
/home/* | rsync -avHAX --numeric-ids |
/var/www | rsync -avHAX --numeric-ids |
| Dump database | pg_dump/mysqldump lalu rsync file dump |
/etc (config) | rsync -avHX --numeric-ids |
Untuk direktori yang berubah terus-menerus (database live), jangan rsync data dir-nya langsung selagi server berjalan — bisa tidak konsisten. Dump adalah jalur aman; alternatif konsisten untuk DB nanti kita bahas di episode 18.
#Pasca Migrasi
Setelah data pindah, verifikasi sebelum cut-over:
du -s /home/ /var/www/
ssh root@new.example.com "du -s /home/ /var/www/"Perbandingan du -s memberi sinyal cepat: ukuran yang sangat jauh berarti ada yang tertinggal (atau hardlink tidak dipertahankan). Untuk verifikasi ketat per file, jalankan rsync -n -i (episode 16) dari server baru terhadap sumber lama — jika bersih, migrasi selesai.
#Sync Dua Arah: Keterbatasan rsync
Ini batas yang harus kalian pahami: rsync satu arah. Ia selalu menyalin dari SRC ke DEST, dan perubahan di DEST tidak pernah kembali ke SRC. Jika kalian menjalankan dua rsync yang berlawanan arah secara bergantian, hasilnya: file yang berubah di kedua sisi saling menimpa — versi termutakhir menang, dan konflik diam-diam hilang.
Warning
Jangan pernah "menyinkronkan dua arah" dengan dua perintah rsync yang saling menimpa untuk data yang diubah dari dua sisi. Ini resep kehilangan data. Untuk sync dua arah, gunakan tool yang dirancang untuk itu.
#Unison: Solusi Two-Way
Unison adalah tool sinkronisasi dua arah berbasis rsync-style delta, yang melacak perubahan di kedua sisi dan menangani konflik secara eksplisit:
unison /home/data ssh://user@otherhost//home/dataJika sebuah file diubah di kedua sisi, unison tidak menebak — ia menampilkan konflik dan meminta keputusan. Unison menyimpan profil di ~/.unison/ dan bisa berjalan non-interaktif untuk kasus non-konflik. Itulah pilihan yang tepat ketika kalian benar-benar butuh two-way sync (misalnya laptop dan server yang keduanya aktif).
#Kapan Memakai yang Mana
| Kebutuhan | Tool |
|---|---|
| Satu arah: backup, mirror, migrasi | rsync |
| Satu arah ke banyak host | rsync batch (episode 7) |
| Dua arah dengan deteksi konflik | unison |
| Dua arah live real-time | lsyncd (episode 22) |
| Cloud object storage | rclone (episode 19) |
#Penutup
Pada episode 11 ini, kalian telah menguasai migrasi server dan memahami batas rsync.
Inti yang harus dibawa pulang:
- Migrasi dua fase: copy awal saat layanan jalan + copy delta singkat sebelum cut-over.
--numeric-idsmempertahankan UID/GID; buat user identik di tujuan dulu.-Hmempertahankan hubungan hardlink — wajib untuk direktori penuh hardlink.- Dump database lalu rsync dump-nya; jangan rsync data dir DB yang live.
- Rsync satu arah; untuk two-way gunakan unison (deteksi konflik), bukan dua rsync saling menimpa.
Di episode 12 selanjutnya, kita kendalikan sumber daya: bandwidth & resource control — --bwlimit=RATE, --max-size/--min-size, nice/ionice, efek kompresi -z terhadap throughput, dan tuning buffer soket. Sampai jumpa di episode 12!