Belajar Rsync - Performance Tuning untuk Dataset Besar

#Pendahuluan

Di episode-episode sebelumnya, rsync dipakai untuk backup harian yang cepat selesai. Episode 18 membahas situasi yang berbeda: dataset besar — puluhan GB sampai TB — di mana setiap persen kecepatan berarti berjam-jam lebih cepat selesai dan bandwidth yang terpakai lebih wajar.

Mengapa ini penting? Karena rsync yang lambat bukan sekadar "menunggu lama" — ia menahan lock, memakai bandwidth, dan memblokir workload lain. Tuning yang benar mengubah transfer 40 jam menjadi 6 jam. Kita bedah tiga area: strategi transfer, paralelisme, dan benchmark.

#--whole-file vs Delta

Rsync memilih antara dua strategi transfer:

• Delta-transfer (default) — memecah file menjadi blok, membandingkan, mengirim hanya bagian yang berubah. Tujuannya meminimalkan data yang dikirim.
• --whole-file — mengirim file utuh, tidak dipecah. Tujuannya meminimalkan CPU dan penundaan.

rsync -avh --whole-file /media/ /backup/media/

#Paralelisme: Multiple rsync per Shard

Rsync adalah single-threaded per proses: satu proses memakai satu koneksi dan satu pipeline. Untuk dataset TB, ini bottleneck — NIC dan disk bisa jauh lebih cepat dari satu stream rsync.

Solusinya: memecah dataset menjadi shard dan menjalankan beberapa rsync secara paralel:

for d in a b c d; do
  rsync -avh --bwlimit=2048 /data/$d/ root@backup:/backup/$d/ &
done
wait

Pola yang umum: satu rsync per direktori tingkat atas, atau per rentang file (misal memecah daftar file menjadi N bagian dengan split). Jumlah paralel yang wajar: 2-4 untuk memulai — jangan 20, karena disk tujuan bisa kewalahan dan malah lambat. Kombinasikan dengan --bwlimit agar total bandwidth tetap terkendali.

#Benchmark NIC dan Disk

Jangan menebak bottleneck — ukur. Dua alat wajib:

iperf3 -c backup-host                    # throughput TCP maksimum
dd if=/dev/zero of=/tmp/test bs=1M count=4096 conv=fdatasync 2>&1 | tail -1
hdparm -t /dev/sdb                       # read speed disk (HDD/SSD)

Angka dari iperf3 dan dd/hdparm memberi tahu batas fisik. Lalu bandingkan dengan throughput rsync aktual:

rsync -avh --stats /large/ backup-host:/backup/

Jika rsync jauh di bawah batas fisik, tuning masih berpeluang: coba --whole-file, paralelisme, atau buffer soket (episode 12). Jika sudah mendekati batas, masalahnya bukan rsync — sudah optimal.

#Kasus: MongoDB/Postgres Data Dir

Data directory database (misal /var/lib/postgresql atau /var/lib/mongodb) tidak boleh di-rsync langsung selagi database berjalan — file bisa berubah di tengah pembacaan dan hasilnya korup. Dua pola yang benar:

1. Consistent snapshot — gunakan mekanisme snapshot filesystem (LVM lvcreate --snapshot, btrfs/zfs snapshot), lalu rsync dari snapshot.
2. Dump + transfer — pg_dump/mongodump, lalu rsync file dump (pola di episode 11).

Untuk replica seeding (membangun secondary di MongoDB/Postgres), pendekatan yang umum dipakai:

rsync -avh --bwlimit=2048 --whole-file \
  /snap/lvm/data/ postgres@replica:/var/lib/postgresql/16/main/

Rsync di sini hanya memindahkan file yang sudah konsisten (dari snapshot), dengan throttle agar tidak menggangu produksi.

#Kasus: Media Library

Library media (video, image) adalah kasus klasik dataset besar dengan file yang hampir tidak pernah berubah setelah ditulis. Konsekuensinya:

• Backup pertama mahal, backup berikutnya murah — delta-transfer bekerja maksimal.
• Kompresi -z tidak membantu (file video/image sudah terkompresi) — matikan.
• Tambah file baru lebih sering daripada mengubah yang lama — pastikan filter *.tmp dll. tetap ada (episode 6).

rsync -avh --no-compress --bwlimit=2048 /media/ backup:/media/

--no-compress mematikan -z secara eksplisit — menghemat CPU yang tidak membawa manfaat apa pun untuk file media.

#Kasus: Dataset TB-Level

Untuk dataset puluhan TB, strategi lengkapnya:

1. Break dataset menjadi shard logis (per cluster file atau rentang).
2. Paralelkan 2-4 rsync, masing-masing dengan --bwlimit agar total terkendali.
3. Susun jadwal bertahap: fase awal saat produksi sepi, fase final delta pendek (pola migrasi episode 11).
4. Monitor throughput per shard; hentikan yang bermasalah tanpa mengganggu yang lain.
5. Verifikasi dengan -c di spot-check (episode 16), bukan seluruh dataset — untuk TB-level, checksum penuh terlalu mahal.

Satu prinsip yang harus selalu diingat untuk skala ini: ukur, susun, lalu jalankan — bukan menyalakan satu rsync besar dan berdoa.

#Penutup

Pada episode 18 ini, kalian telah menguasai tuning performa dataset besar.

Inti yang harus dibawa pulang:

• --whole-file untuk jaringan sangat cepat; delta untuk jaringan lambat dan file jarang berubah.
• Paralelkan dengan multiple rsync per shard; mulai 2-4 proses, bukan puluhan.
• Benchmark dulu dengan iperf3/dd/hdparm, lalu bandingkan throughput rsync.
• Database: jangan rsync data dir live — pakai snapshot atau dump.
• Media library: matikan -z; TB-level: shard + paralel + throttle + spot-check.

Di episode 19 selanjutnya, kita perluas wawasan: alternatif & ekosistem backup — membandingkan rsync (sinkronisasi) dengan rclone (cloud object storage), restic/borg (dedup + enkripsi), dan tar/dd (image-level), plus kombinasi terbaiknya. Sampai jumpa di episode 19!