Belajar Restic - Forget & Prune (Retention Policy)

#Pendahuluan

Di episode 4 kalian mulai membuat snapshot — dan mulai episode ini, snapshot akan terus bertambah. Backup tiap hari menghasilkan 365 snapshot setahun; tanpa kebijakan, repository membengkak dan biaya storage melonjak. Retention policy adalah jawabannya: memutuskan snapshot mana yang pantas hidup dan mana yang harus pensiun.

Kuncinya bukan teknis, tapi bisnis: berapa lama kalian bisa kehilangan data (RPO) dan berapa cepat harus kembali beroperasi (RTO).

#Forget: Mengelola Riwayat Snapshot

restic forget menghapus metadata snapshot sesuai policy. Contoh paling umum — 7 harian, 4 mingguan, 6 bulanan, 1 tahunan:

Retention policy klasik

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --keep-yearly 1

Restic menyimpan snapshot terakhir dari tiap periode, sehingga total tersimpan maksimal 7 + 4 + 6 + 1 = 18 snapshot per tag/path — bukan semua 365.

#Semua Opsi keep

Opsi keep yang tersedia

restic forget \
  --keep-last 10 \
  --keep-hourly 24 \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --keep-yearly 1

Policy berlaku per kombinasi host + tag + path. Artinya snapshot yang ber-tag daily dihitung terpisah dari prod. Selalu beri tag konsisten (episode 4) agar policy bekerja sesuai niat.

#keep-within & keep-tag

Untuk kebutuhan berbasis waktu:

Simpan semua snapshot 30 hari terakhir

restic forget --keep-within 30d

--keep-within 30d menyimpan semua snapshot dalam 30 hari terakhir (atau 1y, 6m, 52w) — tanpa repot menghitung jumlah. Sementara --keep-tag melindungi snapshot tertentu dari kebijakan hapus, misalnya snapshot pra-deploy:

Lindungi snapshot ber-tag gold

restic forget --keep-tag gold --keep-daily 7

#Menentukan Policy Berdasarkan RPO/RTO

RPO (Recovery Point Objective): seberapa banyak data maksimal yang boleh hilang. RPO 1 hari berarti minimal ada snapshot tiap hari.
RTO (Recovery Time Objective): seberapa cepat layanan harus pulih. RTO pendek berarti backup lebih sering + restore yang teruji.

Contoh penerapan: aplikasi e-commerce butuh RPO 15 menit → snapshot tiap 15 menit via cron + --keep-within 24h, lalu agresif --keep-daily 7 --keep-monthly 6 untuk riwayat. Data arsip dengan RPO 24 jam cukup --keep-daily saja.

#Prune: Membersihkan Blob

Forget hanya menghapus referensi snapshot. Blob lama masih tersimpan sampai kalian jalankan prune:

Forget sekaligus prune

restic forget --keep-daily 7 --keep-monthly 6 --prune

Atau terpisah:

Prune terpisah

restic prune

restic prune memindai seluruh repo, menghitung blob yang tidak direferensikan snapshot mana pun, lalu menghapusnya. Ini operasi berat (membaca semua index) — jalankan di jam sepi, dan jangan terlalu sering; cukup sekali seminggu atau setelah forget besar.

Warning

prune mengunci repository (exclusive lock) dan bisa berlangsung lama untuk repo besar. Jangan jalankan prune bersamaan dengan backup. Jika proses terputus di tengah jalan, jalankan restic prune lagi — prosesnya idempotent dan aman diulang.

#Mengetes Policy Tanpa Menghapus

Sebelum mengeksekusi forget yang menghancurkan, lihat dulu apa yang akan dihapus:

Dry-run forget

restic forget --keep-daily 7 --keep-monthly 6 --dry-run

--dry-run menampilkan daftar snapshot yang akan dihapus tanpa menghapus apa pun. Jadikan ini kebiasaan — apalagi saat pertama kali menyusun policy.

#Penutup

restic forget menghapus metadata snapshot sesuai policy keep.
Opsi keep: --keep-last/hourly/daily/weekly/monthly/yearly.
--keep-within 30d untuk policy berbasis waktu; --keep-tag untuk melindungi snapshot penting.
Tentukan policy dari RPO/RTO, bukan dari ketersediaan disk.
--prune menghapus blob tak terpakai; lakukan berkala, hindari bentrok dengan backup.
Selalu --dry-run dulu sebelum forget pertama.

Di episode 9 selanjutnya kita menyatukan semuanya: otomasi backup dengan cron/systemd — script backup+forget+prune yang aman (set -euo pipefail, lock file, log), penjadwalan via cron dan systemd timer, serta verifikasi hasil backup di akhir tiap proses.