Belajar Borg Backup - Performance & Large Dataset

#Pendahuluan

Semua yang kita bangun sejauh ini mengasumsikan backup selesai dalam waktu wajar. Tetapi saat dataset tumbuh ke skala TB, bahkan di antara malam ke malam, hal-hal yang dulu terasa instan mulai melambat. Episode 18 mengubah kalian dari pengguna menjadi tuner: memahami tiga tuas utama performa — chunker, kompresi, dan caching — lalu mengeksekusinya dengan benchmark yang jujur.

#Tiga Tuas Utama Performa

#1. Parameter Chunker

Chunker menentukan ukuran chunk — dan ukuran ini memengaruhi keseimbangan dedup vs overhead:

• Chunk kecil → dedup lebih halus (perubahan kecil tertangkap), tetapi metadata dan CPU lebih berat.
• Chunk besar → overhead lebih rendah, tetapi perubahan kecil pada file besar menyimpan ulang lebih banyak.

Parameter default Borg adalah buzhash,19,23,21,4095: rata-rata 2 MiB per chunk. Untuk dataset tertentu kalian bisa menurunkan ukuran untuk dedup lebih agresif:

borg create --chunker-params buzhash,19,23,21,4095 --stats \
  /backup/borg::"{hostname}-{now}" /home

Angka yang diturunkan (misal eksponen 20 → rata-rata 1 MiB) menambah granularitas dedup dengan biaya CPU. Ukur dulu — jangan mengganti parameter tanpa data.

#2. Level Kompresi

Dari episode 6: lz4 cepat, zstd,10 seimbang. Di dataset besar, pemilihan level kompresi berpengaruh besar pada durasi backup — dan di sinilah trade-off terlihat paling nyata. Untuk host yang backup-nya menabrak jam sibuk, kompresi rendah lebih masuk akal daripada level ekstrem yang membuat pipeline melambat.

#3. Caching: Files Cache

Borg menyimpan files cache lokal (di ~/.cache/borg) berisi metadata file + daftar chunk. Backup berikutnya membandingkan metadata (mtime, size, ctime, inode) dengan cache: file yang tidak berubah dilewati tanpa di-hash ulang — penghematan besar pada dataset yang sebagian besar statis.

• Jangan hapus cache tanpa alasan: menghapusnya memaksa re-hash semua file pada backup berikutnya (jauh lebih lambat).
• Kalau mencurigai cache korup (episode 15), bersihkan dan terima satu backup yang lebih lambat sebagai biayanya.
• Untuk dataset dengan jutaan file, cache yang besar itu wajar — beri ruang yang cukup di disk.

#Benchmark Dedup & Kecepatan

#Cara Mengukur yang Jujur

Jangan memakai time mentah saja — ukur komponen secara terpisah:

time borg create --compression zstd,10 --stats \
  /backup/borg::bench /var/lib/data
 
# jalankan ulang (semua data sudah ada) untuk mengukur kecepatan dedup
time borg create --compression zstd,10 --stats \
  /backup/borg::bench-2 /var/lib/data

Pembacaan penting dari dua run ini:

• Run pertama: kecepatan baca + kompresi + enkripsi + tulis chunk baru (throughput penuh).
• Run kedua: kecepatan dedup murni — jika nyaris instan, files cache bekerja.

--stats memberi angka: New files, Unchanged files, Deduplicated size. Rasio Unchanged files yang tinggi menunjukkan cache efektif.

#Menjaga Angka

Catat durasi dan ukuran tiap backup ke log; lonjakan durasi tanpa perubahan data adalah tanda disk melemah atau eksklusi yang hilang (episode 12).

#Backup TB-level

#Pertimbangan Khusus

• Chunker lebih besar untuk data besar yang jarang berubah: kurangi jumlah chunk dan metadata.
• Kompresi disesuaikan: untuk data yang tidak kompresibel (media, arsip terkompresi), lz4 menghindari CPU terbuang.
• Cache disk yang memadai: files cache untuk jutaan file butuh ruang dan IO — taruh di disk cepat bila memungkinkan.
• Bagi dataset: satu create untuk banyak direktori besar bisa dipecah per direktori agar progress terlihat dan kegagalan terisolasi.
• Buffer yang lebih besar: --buffer-size 1G untuk throughput tinggi di jaringan lambat atau disk jauh.

#Throttling: ionice dan nice

Backup harus berjalan tanpa mematikan produksi. Turunkan prioritas I/O dan CPU:

ionice -c 3 nice -n 10 \
  borg create --stats /backup/borg::"{hostname}-{now}" /home

• ionice -c 3 → I/O idle class: disk hanya dipakai saat tidak ada workload lain yang butuh.
• nice -n 10 → prioritas CPU lebih rendah dari proses normal.

Untuk cgroup (systemd):

[Service]
Nice=10
IOSchedulingClass=idle
IOWeight=1

#Pitfall Umum

• Mengganti chunker/kompresi tanpa benchmark: setiap perubahan menghapus efektivitas dedup historis secara parsial. Ukur dulu.
• Menghapus files cache: backup berikutnya menjadi jauh lebih lambat. Hapus hanya saat mencurigai korupsi cache.
• Tanpa throttling di produksi: backup yang makan semua I/O membuat aplikasi melambat di siang hari — pakai ionice/nice atau jadwalkan di luar jam.
• Mengukur satu run: kecepatan hanya bermakna setelah beberapa run (dedup + cache berperan). Ukur tren, bukan snapshot.

#Penutup

• Chunker: ukuran chunk menentukan granularitas dedup vs overhead — ubah dengan data, bukan tebakan.
• Kompresi: level menentukan durasi backup di dataset besar.
• Files cache menghindari re-hash file tak berubah — jangan dihapus tanpa alasan.
• Benchmark: run pertama = throughput penuh, run kedua = kecepatan dedup.
• Dataset TB-level: sesuaikan chunker, kompresi, cache, dan pecah dataset.
• Throttling: ionice -c 3 dan nice / IOSchedulingClass=idle melindungi produksi.

Di episode 19 kita melebarkan ekosistem: BorgWeb & Tools — GUI untuk mengelola repository, integrasi dengan borgmatic dan FUSE, koneksi ke monitoring klasik (nagios/zabbix) lewat wrapper, serta exporter metrik ke Prometheus.