Belajar Restic - Performance Tuning & Large Data

#Pendahuluan

Sejauh ini kalian berlatih dengan dataset kecil. Episode 18 berbicara soal skala: saat data mencapai TB-level, atau 50 host membackup ke satu server, aturan mainnya berubah. Backup bukan lagi soal "jalan atau tidak", tapi soal "berapa lama dan berapa murah".

Kuncinya bukan mengotak-atik asal-asalan, tapi memahami di mana bottleneck berada: CPU, disk, atau jaringan — lalu menyesuaikan parameter yang tepat.

#Mengukur Dulu: Benchmark Dedup Rate

Sebelum tuning, ukur baseline. Dedup rate adalah angka paling informatif:

Ukur performa dedup per backup

restic stats --mode raw-data
restic stats --mode restore-size

Perbandingan keduanya (episode 6) menentukan strategi: data dengan dedup tinggi (container, log, code) mendapat manfaat besar dari chunking; data unik (foto/video) lebih butuh bandwidth daripada CPU.

Ukur juga waktu backup per volume data:

Ukur throughput backup

restic backup /data --json | jq '.total_duration, .data_added_packed'

Jadikan angka ini baseline; setiap tuning diukur terhadapnya, bukan perasaan.

#--read-concurrency: Paralelisme Baca

Restore dan check --read-data membuka banyak blob sekaligus. --read-concurrency mengontrol jumlah pembacaan paralel:

Restore dengan concurrency tinggi

restic restore latest --target /tmp/r --read-concurrency 32

Disk lokal (SSD): naikkan ke 16–32 — disk bisa melayani banyak I/O paralel.
HDD: lebih sedikit (4–8) — banyak koneksi justru membuat head thrashing.
Jaringan/object storage: sesuaikan dengan koneksi backend; opsi s3.connections (episode 16) saling berkaitan.

#Network Buffer & Latency

Untuk backend remote (S3, rest-server), latency lebih menentukan daripada bandwidth. Setiap request memakai satu koneksi; dengan buffer kecil, throughput terbatas oleh round-trip. Tuning yang umum untuk S3:

Tuning koneksi S3

restic -o s3.connections=10 \
  -o s3.part-size=64 \
  -o s3.upload-concurrency=8 \
  backup /data

s3.connections: jumlah koneksi paralel.
s3.part-size (MiB): ukuran part multipart — part lebih besar = lebih sedikit request.
s3.upload-concurrency: upload paralel per file.

Cek dokumentasi backend kalian — tiap backend punya opsi -o sendiri yang bisa dieksplorasi dengan restic help.

#Caching: --cache-dir

Restic menyimpan index dan cache blob lokal untuk menghindari download ulang:

Tentukan cache dir

restic --cache-dir /var/cache/restic backup /data

Index cache mempercepat pembukaan repository — penting saat repo besar.
Cache di lokasi dengan I/O cepat (SSD); jangan di disk yang sama dengan data mentah bila bisa.
Ukuran cache tumbuh; kelola dengan pembersihan berkala.

Tip

Untuk dataset raksasa, pisahkan index dari data: letakkan cache di SSD, data chunk di HDD. Backup harian memakai cache index (kecil, cepat), sementara blob besar mengalir ke HDD murah.

#Dataset TB-Level

Praktik untuk data > 1 TB:

Pecah backup per direktori top-level — snapshot terpisah, check/prune per bagian, resume lebih mudah.
Jadwalkan per bagian — bukan satu backup raksasa tengah malam, tapi beberapa backup dengan jadwal dan tag berbeda.
--read-data-subset (episode 11) untuk verifikasi bertahap.
Gunakan restic ls/find sebelum restore untuk menghindari restore selektif yang salah path.
Awasi waktu prune — untuk repo TB-level, jadwalkan prune mingguan di jam sepi, bukan setelah tiap backup.

#Banyak Host ke Satu Server

Saat banyak host membackup ke satu rest-server/S3, aturan manajemen:

Stagger jadwal: jangan biarkan 50 host backup bersamaan — acak menit ($((RANDOM % 60))) di cron.
Batas bandwidth per host: --limit-upload (episode 7) supaya host kecil tidak kelaparan.
Repo per host: satu repository per host (episode 15) agar prune satu host tidak mengunci host lain.
Monitoring per host (episode 20): tahu host mana yang gagal tanpa menunggu keluhan.

Jadwal acak di cron

M=$((RANDOM % 60))
echo "$M 2 * * * root /usr/local/bin/backup-restic.sh" > /etc/cron.d/restic-backup

#Penutup

Ukur baseline dulu: dedup rate + throughput — tuning tanpa pengukuran adalah tebak-tebakan.
--read-concurrency: sesuaikan dengan jenis disk (SSD tinggi, HDD rendah).
Tuning S3: s3.connections, s3.part-size, s3.upload-concurrency.
--cache-dir di SSD memisahkan index cepat dari data besar.
Dataset TB: pecah backup, --read-data-subset, jadwal prune terpisah.
Banyak host: stagger jadwal, limit bandwidth, repo per host, monitoring.

Di episode 19 selanjutnya kita menjelajahi ekosistem: rest-server, SDK & wrapper — rest-server sebagai produk backup server, wrapper seperti resticprofile dan restic-compose, dashboard Grafana, metrics Prometheus, serta integrasi backup pipeline di CI/CD.