Belajar Proxmox Backup Server - Retention & Prune Policy
Episode ini mengatur siklus hidup snapshot: kebijakan prune dengan keep-last, keep-daily, keep-weekly, dan keep-monthly per backup group, serta bagaimana sync job mempertahankan retention di sisi remote. Kalian belajar menyelaraskan retention dengan target RPO/RTO dan memverifikasi hasil prune agar datastore tetap sehat.
#Pendahuluan
Enkripsi di episode 7 menjaga data tetap rahasia, tapi berapa lama snapshot bertahan belum dijawab. Simpan selamanya dan storage membengkak; hapus terlalu cepat dan recovery point kalian menipis. Episode 8 membahas retention & prune policy — bahasa kebijakan yang menentukan snapshot mana yang hidup dan mana yang pensiun.
Bayangkan seperti lemari arsip dengan aturan kadaluarsa: dokumen hari ini, kemarin, dan seminggu terakhir tetap disimpan lengkap; yang lebih tua cukup satu per minggu, lebih tua lagi satu per bulan. Lemari tetap tertata tanpa membuang yang masih dibutuhkan — itulah prune policy yang baik.
#Prune: Retention per Backup Group
#Keep-last, Keep-daily, Keep-weekly, Keep-monthly
PBS menawarkan aturan retention yang diterapkan per backup group. Aturan-aturannya:
- Keep-last N: simpan N snapshot terakhir, apa pun waktunya.
- Keep-hourly N: simpan maksimal N snapshot per jam terakhir.
- Keep-daily N: maksimal N snapshot per hari.
- Keep-weekly N: maksimal N snapshot per minggu.
- Keep-monthly N: maksimal N snapshot per bulan.
- Keep-yearly N: maksimal N snapshot per tahun.
Prune mempertahankan snapshot yang memenuhi kriteria, sisanya dihapus. Contoh kebijakan khas:
keep-last: 7 → 7 snapshot terakhir
keep-daily: 14 → 14 snapshot harian
keep-weekly: 8 → 8 snapshot mingguan
keep-monthly: 6 → 6 snapshot bulanan#Menjalankan Prune
Di PVE, retention diset di job backup lewat opsi Prune Backups (format keep-last=7,keep-daily=14,...). Dari CLI proxmox-backup-client:
proxmox-backup-client prune \
--repository backup@pbs@10.0.1.10:store1 \
--keep-last 7 --keep-daily 14 --keep-weekly 8 --keep-monthly 6Di sisi server, prune juga bisa dijadwalkan sebagai prune job (Datastore → Prune Jobs) sehingga berjalan otomatis setelah backup. Prune adalah operasi metadata — cepat, karena tidak menyentuh chunk. Ingat aturan episode 6: prune dulu, GC kemudian.
Note
Prune hanya menghapus snapshot dari daftar, bukan chunk-nya langsung. Ruang disk baru benar-benar bebas setelah GC. Jika prune tampak tidak menghemat disk, itu normal — GC belum jalan.
#Retention di Sync Job
Kapan pun snapshot disinkronkan ke PBS remote (episode 10), retention harus diatur ulang di sisi remote. Sync job punya parameter keep sendiri dan opsi --remove-vanished yang menghapus snapshot remote yang sudah tidak ada di sumber. Ini mencegah datastore remote membengkak karena menyalin semua history tanpa batas:
proxmox-backup-manager sync job update <id> \
--keep-last 7 --keep-daily 14 --remove-vanishedKombinasi ini membuat remote mirror tetap ringkas: ia menyimpan subset retention yang sama dengan sumber, tanpa menumpuk duplikat.
#Menyusun Policy Sesuai RPO/RTO
#Hubungan Retention dengan RPO/RTO
Retention harus menjawab dua pertanyaan bisnis:
- RPO (Recovery Point Objective): seberapa jauh ke belakang kalian sanggup kehilangan data. Semakin sering backup, semakin kecil kehilangan data; retention menentukan berapa jauh ke belakang itu tersedia.
- RTO (Recovery Time Objective): seberapa cepat restore harus selesai. Retention yang terlalu besar memperlambat GC dan memakan storage, tapi tidak mengubah RTO restore (restore hanya butuh satu snapshot).
Contoh penyusunan untuk workload menengah:
| Tingkat | Backup | Retention | Rasional |
|---|---|---|---|
| Kritis | 6x/hari | keep-last 10, keep-daily 14 | RPO 4 jam, recovery fleksibel |
| Standar | 1x/hari | keep-daily 14, keep-weekly 8 | RPO 24 jam, restore mingguan |
| Arsip | 1x/hari | keep-weekly 4, keep-monthly 12 | minimal storage, tahan audit |
#Verifikasi Setelah Prune
Setelah prune berjalan, verifikasi bahwa hasilnya sesuai keinginan:
proxmox-backup-client snapshot list \
--repository backup@pbs@10.0.1.10:store1Periksa jumlah dan rentang timestamp per backup group. Jika snapshot yang masih dibutuhkan ikut terhapus, periksa konfigurasi keep — kemungkinan besar aturan keep diisi terlalu kecil atau terjadi konflik antar aturan.
Warning
Hati-hati dengan kombinasi keep yang tidak disengaja: misalnya keep-last 2 bersama keep-daily 14 di tengah penjadwalan harian. Setiap aturan dihitung terpisah dan snapshot yang lolos salah satu aturan akan dipertahankan. Uji di lab dan verifikasi setelah prune sebelum memakainya di production.
#Penutup
Inti yang harus dibawa pulang:
- Retention dinyatakan sebagai keep-last/hourly/daily/weekly/monthly/yearly per backup group.
- Prune menghapus snapshot sesuai kebijakan; opsi di PVE (
prune-backups) dan CLI (proxmox-backup-client prune). - Prune tidak membebaskan disk sampai GC berjalan — urutan prune lalu GC tetap wajib.
- Sync job perlu retention sendiri (
--keep-*) dan--remove-vanishedagar remote tidak membengkak. - Susun retention dari kebutuhan RPO/RTO, bukan tebakan.
- Verifikasi hasil prune dengan
proxmox-backup-client snapshot list.
Di episode 9 selanjutnya kita akan memastikan data tidak diam-diam rusak: verify & integrity check — menjadwalkan verify yang membaca dan memvalidasi checksum chunk, memakai --verify-new untuk snapshot baru, serta melakukan audit lewat task log dan pemeriksaan integritas datastore. Backup yang rusak tanpa terdeteksi adalah bencana yang tertunda!