Belajar Restic - Deduplication, Storage & Compression

#Pendahuluan

Episode 5 menutup siklus dasar backup→restore. Namun ada satu hal yang membuat restic benar-benar berbeda dari rsync atau tar: ia menyimpan delta, bukan salinan. Ini adalah alasan mengapa kalian bisa membackup server setiap hari bertahun-tahun tanpa disk meledak.

Episode ini membedah mesin efisiensi restic: deduplication berbasis chunk, bagaimana kompresi ikut berperan, dan bagaimana membaca angka nyatanya.

#Content-Defined Chunking: Jantung Dedup

Kita sudah mengenal konsepnya di episode 2. Sekarang mari lihat mengapa metode ini penting secara praktis.

Restic memecah file menjadi potongan-potongan (chunk) di posisi yang ditentukan isi data (rolling hash), bukan tiap N byte. Contoh file log yang terus bertambah:

Bayangkan sebuah file log

[2026-08-13 08:00] request OK
[2026-08-13 08:01] request OK
[2026-08-13 08:02] request FAIL

Dengan fixed-size chunking, semua chunk bergeser setiap ada baris baru — semua chunk "baru". Dengan content-defined chunking, hanya potongan yang benar-benar berubah yang disimpan ulang; sisanya dikenali identik dan tidak disimpan lagi. Inilah yang membuat backup harian server dengan log besar tetap ringan.

#Kasus yang Menguntungkan Dedup

• File yang sama di banyak direktori (template, node_modules, build cache).
• Virtual disk (VM image) yang jarang berubah.
• File log yang bertambah — mayoritas isinya sama dengan backup kemarin.
• Restrukturisasi direktori (memindahkan file ke folder baru).

#Membaca Angka Dedup dengan stats

Restic menyediakan dua sudut pandang ukuran:

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

• restore-size: total ukuran file jika seluruh snapshot di-restore — data "asli" kalian.
• raw-data: ukuran blob fisik yang benar-benar tersimpan di repository — setelah dedup dan sebelum kompresi.

Rasio keduanya adalah kekuatan dedup kalian. Contoh: restore-size 500 GiB dengan raw-data 12 GiB berarti dedup bekerja sangat baik (server container dengan banyak image identik), sedangkan rasio mendekati 1:1 menandakan data yang unik semua — wajar untuk foto/video.

#Kompresi: zstd Sejak 0.14

Selain dedup, restic mengompresi chunk sebelum dienkripsi. Sejak restic 0.14, kompresi menggunakan zstd dan diaktifkan secara default melalui mode auto.

#Mode --compression

restic backup --compression auto /data   # default: hemat, kompres bila menguntungkan
restic backup --compression max /data    # rasio tertinggi, CPU lebih banyak
restic backup --compression off /data    # tanpa kompresi, data alokatif

• auto (default): chunk yang jelas tidak bisa dikompres (file terenkripsi, media) dilewati — ini menghemat CPU pada data yang sudah tercompress seperti JPG/MP4.
• max: memaksakan rasio terbaik; cocok untuk teks, JSON, log — tapi makan CPU.
• off: data alokatif seperti VM image bisa disimpan tanpa dikompres agar restore lebih cepat.

#Dedup + Kompresi: Gambaran Utuh

Alur tiap chunk baru: chunking → dedup check (sudah ada? lewati) → kompresi zstd → enkripsi AES-256 → simpan sebagai blob. Gabungan ketiganya adalah alasan restic diklaim "backups done right": setiap byte yang tidak perlu disimpan adalah bandwidth dan uang yang terhemat.

#Menghitung Penghematan Nyata

Untuk mengukur dampaknya di repo kalian:

restic stats --mode raw-data
du -sh /backup/restic

Bandingkan angka raw-data dengan total restore-size semua snapshot. Perbedaan itulah jumlah data yang berhasil dihindari berkat dedup — angka yang bagus untuk dilaporkan ke tim.

#Penutup

• Content-defined chunking membuat batas chunk mengikuti isi data → dedup delta.
• File log, image container, dan file duplikat adalah kasus keuntungan dedup terbesar.
• restic stats --mode restore-size = ukuran asli; --mode raw-data = ukuran fisik.
• Kompresi zstd default (--compression auto) hemat storage tanpa boros CPU.
• Dedup menghindari duplikasi; kompresi mengecilkan data unik — keduanya berlapis.
• --compression adalah parameter repository: pilih sekali, konsisten.

Di episode 7 selanjutnya kita memetakan backend: local, SFTP, S3 & REST server — perbedaan tiap target storage, URL repository masing-masing, konfigurasi credential (AWS key), serta pembatasan bandwidth dengan --limit-upload/--limit-download. Waktunya backup kalian keluar dari satu mesin.