Belajar Velero - Backup Policies & Compliance

#Pendahuluan

Di episode 6 kalian belajar TTL — backup otomatis dihapus setelah waktunya. Tapi ada skenario yang TTL tidak bisa penuhi: regulasi mewajibkan data disimpan sekian tahun, dan tidak boleh bisa dihapus — bahkan oleh admin dengan akses penuh. Di situlah episode 15 bekerja: mengubah Velero dari "alat backup yang rapi" menjadi sistem yang memenuhi compliance.

Analogi paling tepat adalah arsip notaris: dokumen penting tidak boleh bisa dirobek oleh siapa pun, termasuk pembuatnya sendiri. Object lock adalah "lemari arsip yang terkunci dari dalam" — begitu data masuk, tidak ada yang bisa menghapusnya sampai masa lock berakhir.

#Immutability dengan Object Lock

#Konsep

Object Lock (S3 / MinIO / GCS retention) membuat objek di bucket tidak dapat dihapus atau ditimpa selama periode tertentu. Level compliance bisa sangat ketat: bahkan root account sekalipun tidak bisa menghapus objek dalam masa retention.

Aktifkan Object Lock saat membuat bucket (S3 tidak mengizinkan mengaktifkannya setelah bucket dibuat):

Buat bucket dengan Object Lock

aws s3api create-bucket \
  --bucket velero-archive \
  --create-bucket-configuration LocationConstraint=ap-southeast-1 \
  --object-lock-enabled-for-bucket

#Mengaitkan Velero dengan Object Lock

BSL punya field objectLock yang memberi tahu Velero bahwa backup di lokasi ini tidak boleh dihapus — Velero akan menolak operasi delete dan memberi peringatan saat TTL kedaluwarsa:

BSL dengan objectLock

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: archive
  namespace: velero
spec:
  provider: aws
  objectStorage:
    bucket: velero-archive
    prefix: backups
  config:
    region: ap-southeast-1
  objectLock: true
  accessMode: ReadWrite

Warning

objectLock: true adalah pengakuan eksplisit bahwa backup di lokasi ini tidak akan pernah bisa dihapus sampai lock selesai. Baca dua kali sebelum mengaktifkan: kesalahan retention (misal lock 3 tahun saat data sudah tidak relevan) berarti objek menumpuk dan menambah biaya storage permanen.

#BSL Terpisah per Policy

#Mengapa Dipisah

Kebijakan yang berbeda butuh perlakuan berbeda:

Operasional: TTL 30 hari, bisa dihapus, biaya murah.
Compliance/arsip: object lock, TTL sangat panjang atau tanpa TTL, biaya arsip (glacier/deep archive).

Mencampur keduanya di satu bucket membuat policy tidak jelas dan sulit diaudit. Solusi Velero: BSL terpisah per policy, lalu backup diarahkan ke BSL yang tepat.

Dua BSL dengan policy berbeda

velero backup-location create ops \
  --provider aws --bucket velero-ops --config region=us-east-1 --default
 
velero backup-location create archive \
  --provider aws --bucket velero-archive \
  --config region=ap-southeast-1

#Schedule per Policy

Schedule operasional vs compliance

velero schedule create daily-ops \
  --schedule="0 2 * * *" --include-namespaces prod --ttl 720h \
  --storage-location ops
 
velero schedule create monthly-archive \
  --schedule="0 3 1 * *" --include-namespaces prod --ttl 26280h \
  --storage-location archive

Backup bulanan ke bucket arsip dengan TTL 3 tahun (26280 jam) dan object lock di level bucket — inilah pola compliance yang umum.

#Retention Compliance

#TTL sebagai Kontrak

Setiap backup punya TTL sendiri; untuk backup yang menjadi kewajiban compliance, pastikan TTL-nya konsisten dengan persyaratan regulasi — dan tercatat. Jangan andalkan hafalan:

Audit TTL semua backup

velero backup get

Backup dengan TTL lebih pendek dari persyaratan regulasi harus segera dikoreksi (buat ulang dengan TTL yang benar) — karena begitu TTL habis, objek dihapus otomatis.

#Kombinasi dengan Object Lock

Pola terkuat: TTL panjang + object lock + BSL arsip. TTL adalah aturan Velero; object lock adalah jaring pengaman fisik di storage. Jika ada bug yang menghapus backup, object lock tetap menahannya. Jika ada object lock yang keliru, TTL setidaknya membatasi jangka waktu kesalahan itu.

#Audit: Log dan Event

#Log Server Velero

Semua operasi terekam di log pod server:

Streaming log server

kubectl logs -n velero deploy/velero --tail=200

Untuk audit jangka panjang, kirim log ke sistem observasi (Loki/ELK/CloudWatch). Gunakan konfigurasi log di velero install bila perlu, atau sidecar di deployment velero.

#Event Backup/Restore

Event Kubernetes mencatat perubahan status setiap operasi:

Grep untuk fase penting: Started, Completed, Failed, Expired. Event ini bisa dipakai untuk dashboard compliance "backup yang wajib simpan sudah selesai / gagal".

Tip

Bangun laporan compliance otomatis: cron/CI yang menjalankan velero backup get, memfilter backup compliance, dan membunyikan alert bila ada yang gagal atau TTL-nya menyimpang dari aturan. Laporan tercetak jauh lebih bernilai saat auditor bertanya "tunjukkan buktinya".

#Penutup

Inti yang harus dibawa pulang:

Object lock (S3/MinIO/GCS) membuat backup tidak bisa dihapus — aktifkan saat bucket dibuat.
BSL objectLock: true memberi tahu Velero agar tidak menghapus backup di lokasi itu.
Pisahkan BSL per policy: operasional (TTL pendek) vs arsip compliance (lock + TTL panjang).
TTL adalah aturan; object lock adalah jaring pengaman — kombinasikan keduanya.
Audit via log server (kubectl logs) dan event (kubectl get events), serta laporan otomatis.

Di episode 16 selanjutnya kita menghadapi kenyataan pahit setiap operator: Troubleshooting & Debugging — velero backup describe --details, velero backup logs, dan velero bug, plus kasus umum seperti BSL invalid, snapshot gagal, node-agent crash, dan backup kopia pending.