Belajar Proxmox Backup Server - Deduplication & Garbage Collection

#Pendahuluan

Restore sudah teruji di episode 5 — sekarang kita bicara biaya. Backup yang tidak di-manage akan terus membesar sampai disk penuh. PBS menyelesaikan dua masalah sekaligus: deduplication membuat data tidak disimpan berulang, dan garbage collection membersihkan sisa chunk yang tidak lagi dibutuhkan. Episode 6 adalah jantung efisiensi PBS.

Bayangkan dedup seperti hotel dengan dapur pusat: semua tamu (VM) memesan telur yang sama, tapi hotel hanya menyimpan satu porsi telur di dapur (chunk unik), lalu mencatat siapa saja yang memakainya. Saat seorang tamu pulang, telur yang hanya dipakai tamu itu tetap di dapur sampai petugas (GC) memastikan tidak ada yang butuh lagi.

#Deduplication: Menghindari Data Ganda

#Chunking Content-Defined dan Dedup Lintas Backup

Seperti dibahas di episode 2, PBS memecah data menjadi chunk berbasis content-defined chunking (CDC). Konsekuensi langsungnya: satu chunk unik hanya disimpan sekali, di seluruh datastore. Artinya:

• Lintas backup: snapshot hari ini dan kemarin berbagi chunk data yang tidak berubah — backup berikutnya hanya mengirim delta.
• Lintas VM: sepuluh VM Debian yang identik menyimpan chunk OS hanya sekali.
• Lintas host: backup file dari host yang menjalankan software sama ikut di-dedup.

Dedup terjadi otomatis, transparan, dan dihitung real-time oleh PBS. Tidak ada konfigurasi khusus — kalian cukup menikmati efisiensinya.

#Membaca Metrik Dedup di Datastore

Web UI PBS menampilkan statistik penting per datastore: Size (kapasitas fisik yang terpakai), Original (ukuran data sebenarnya sebelum dedup/compress), Dedup (ukuran chunk unik setelah dedup, sebelum compress), dan Compressed (ukuran nyata setelah compression). Dari sini muncul dua rasio:

• Dedup ratio = Original / Dedup — seberapa banyak penyimpanan ganda yang dihindari.
• Compression ratio = Dedup / Compressed — efisiensi zstd.

proxmox-backup-manager datastore list --output-format json

#Garbage Collection

#Mengapa GC Diperlukan

Ketika retention (episode 8) menghapus snapshot, PBS tidak langsung menghapus chunk-nya — karena chunk yang sama mungkin dipakai snapshot lain. Menghapus tanpa memeriksa akan merusak snapshot yang masih hidup. Garbage collection menjawab ini: ia menghitung referensi setiap chunk, lalu menghapus yang tidak lagi direferensikan oleh snapshot mana pun.

Alurnya dua tahap:

1. Prune: hapus snapshot berdasarkan kebijakan retention (keep-last, keep-daily, dll).
2. Garbage collection: setelah prune, cari dan hapus chunk yang yatim (orphaned).

Urutan ini wajib: GC tanpa prune tidak ada gunanya (semua chunk masih direferensikan), dan prune tanpa GC membuat disk membengkak (chunk snapshot lama tetap disimpan).

#Menjalankan GC

proxmox-backup-manager datastore garbage-collection store1

Saat berjalan, PBS memasuki fase mark (menandai semua chunk yang direferensikan — bisa berlangsung lama untuk datastore besar) lalu fase sweep (menghapus yang tidak ditandai). Log akhir menampilkan jumlah chunk yang dibebaskan:

Contoh output GC

TASK OK — GC finished.
Marked 12345 chunks, removed 678 chunks, freed 2.1 GiB

#Menjadwalkan GC

Jangan jalankan GC manual terus-menerus — jadwalkan. Idealnya di waktu sepi dan setelah prune job selesai. Di episode 3 kita sudah membuat GC mingguan (sun 02:00). Buat job eksplisit via CLI:

proxmox-backup-manager gc job create \
  --datastore store1 --schedule "sun 02:00"

proxmox-backup-manager gc job list

#Praktik: Prune + GC Bersama

Urutan yang sehat untuk production:

1. Backup harian berjalan sesuai schedule.
2. Prune job membersihkan snapshot lama (misal setiap hari 03:00).
3. GC job berjalan setelahnya (misal mingguan Minggu 02:00) untuk membebaskan ruang.

Hasilnya: datastore tumbuh sesuai retention, bukan tanpa batas. Check disk health berkala dengan df -h dan pantau metrik datastore di web UI.

#Penutup

Inti yang harus dibawa pulang:

• Chunking content-defined menghasilkan dedup lintas backup, VM, bahkan host.
• Dedup otomatis; metrik Size/Original/Dedup/Compressed dibaca di web UI datastore.
• Dedup ratio = Original/Dedup; compression ratio = Dedup/Compressed.
• Prune menghapus snapshot sesuai retention; GC menghapus chunk yang tidak lagi direferensikan.
• Urutan wajib: prune dulu, GC setelahnya.
• Jadwalkan GC di jam sepi (proxmox-backup-manager gc job create) dan jangan bentrokkan dengan backup/sync.

Di episode 7 selanjutnya kita akan mengamankan data: enkripsi client-side — generate key base64 di sisi client, mengatur encryption-key pada task backup, memverifikasi bahwa server tidak bisa membaca data, dan praktik manajemen key yang benar karena tanpa key, restore mustahil dilakukan!