Belajar Velero - Disaster Recovery Plan

#Pendahuluan

Delapan episode praktik teknis sudah kalian kuasai: backup, restore, schedule, hooks, migrasi. Episode 12 mengangkat semuanya satu tingkat: strategi. Karena kenyataannya, perusahaan tidak bangkrut karena kehilangan data — mereka bangkrut karena tidak bisa pulih dalam waktu yang dijanjikan.

Bayangkan pemadam kebakaran yang punya selang dan pompa terbaik, tapi tidak pernah menyusun rencana evakuasi. Saat api datang, semua alat ada tapi tidak ada yang tahu urutannya. DR Plan adalah "rencana evakuasi" itu: angka yang disepakati, langkah yang terdokumentasi, dan latihan berkala.

#RPO dan RTO

#Definisi

Dua metrik yang wajib disepakati dengan pemangku kepentingan sebelum menyusun apa pun:

• RPO (Recovery Point Objective): seberapa banyak data yang boleh hilang. Jika RPO 24 jam, berarti backup harian cukup; jika RPO 1 jam, dibutuhkan backup per jam.
• RTO (Recovery Time Objective): seberapa cepat layanan harus kembali. Jika RTO 4 jam, seluruh proses restore harus selesai di bawah itu.

+----------------+-------------------------------------+
| RPO 24 jam     | schedule harian, TTL cukup panjang   |
| RPO 1 jam      | schedule per jam, TTL 48h            |
| RPO hampir 0   | snapshot cloud + dump logis berkala  |
| RTO 4 jam      | runbook otomatis, image Velero siap  |
| RTO < 1 jam    | DR cluster standby + pipeline deploy |
+----------------+-------------------------------------+

#Menerjemahkan ke Konfigurasi Velero

velero schedule create hourly \
  --schedule="0 * * * *" \
  --include-namespaces prod \
  --ttl 72h \
  --default-volumes-to-fs-backup

RPO 1 jam = schedule per jam. RTO 4 jam menuntut proses restore yang cepat: Velero terinstall di DR region, credential siap, dan runbook terbukti.

#Backup Off-site: Region Berbeda

#Prinsip 3-2-1 untuk Kubernetes

Prinsip backup klasik berlaku juga untuk cluster: 3 salinan, 2 media berbeda, 1 di lokasi lain. Untuk Kubernetes, terjemahannya:

• 3 salinan: data di PVC, backup di BSL primer, backup di BSL sekunder.
• 2 media: object storage primer (hot) + arsip (misal glacier/archive).
• 1 off-site: bucket di region berbeda (atau cloud berbeda).

#Konfigurasi BSL Kedua

velero backup-location create dr-region \
  --provider aws \
  --bucket velero-backups-dr \
  --config region=ap-southeast-1

Atau untuk lintas cloud — BSL GCS yang dibaca saat DR di GCP:

velero backup-location create gcs-dr \
  --provider gcp \
  --bucket velero-dr-backups

#Runbook Restore

Runbook adalah instruksi yang bisa dieksekusi siapa saja — termasuk orang yang baru jaga malam. Susun minimal langkah berikut:

1. Deteksi insiden dan eskalasi ke on-call.
2. Siapkan cluster DR: cluster baru di region DR, kubectl context benar.
3. Install Velero 1.18 dengan plugin yang sama:
   velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.14.0 \
     --bucket velero-backups-dr --secret-file ./credentials-velero \
     --backup-location-config region=ap-southeast-1
4. Verifikasi BSL Available dan backup tampak:
   velero backup-location get && velero backup get
5. Restore dengan mapping yang sesuai:
   velero restore create dr-restore --from-backup <latest> \
     --storage-class-mappings gp2:gp3
6. Verifikasi: velero restore logs, kubectl get pods, cek data volume.
7. Switch traffic ke cluster DR, update DNS/Ingress.
8. Catat waktu mulai-selesai untuk laporan RTO.

Simpan runbook ini di repository (misal GitOps repo) dan jadikan checklist commit-able — bukan di kepala seseorang.

#DR Drill: Latihan Berkala

#Mengapa Harus Dilatih

Backup yang tidak pernah direstore di cluster baru hanyalah tebakan. DR drill mengubah asumsi menjadi fakta: apakah credential masih berlaku? Apakah plugin image tersedia? Berapa lama restore benar-benar berlangsung? Semua hanya terjawab dengan latihan.

#Prosedur Drill

kubectl config use-context dr-cluster
velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.14.0 \
  --bucket velero-backups-dr --secret-file ./credentials-velero \
  --backup-location-config region=ap-southeast-1
velero restore create drill-restore --from-backup <latest>

Uji juga skenario terburuk: hapus cluster sumber, lalu restore ke cluster baru dari nol. Ini satu-satunya cara membuktikan bahwa backup kalian benar-benar independen dari cluster asalnya.

#Melengkapi DR dengan Monitoring

Backup yang diam-diam gagal adalah kebocoran paling berbahaya. Jadwalkan pemeriksaan otomatis:

velero backup get | grep -v Completed
kubectl logs -n velero deploy/velero --tail=50

Kita bahas monitoring lengkap di episode 20. Untuk episode 12, cukup tanamkan kebiasaan: backup yang tidak dimonitor sama dengan tidak ada backup.

#Penutup

Inti yang harus dibawa pulang:

• RPO = berapa banyak data boleh hilang; RTO = seberapa cepat harus pulih — keduanya menentukan konfigurasi schedule dan TTL.
• Terapkan 3-2-1: backup off-site ke BSL di region/cloud berbeda.
• Susun runbook restore yang bisa dieksekusi siapa pun, dan simpan di repository.
• DR drill berkala mengubah asumsi menjadi angka nyata; hapus cluster → restore ke cluster baru.
• Monitor backup — backup yang gagal diam-diam tidak menolong siapa pun.

Di episode 13 selanjutnya kita masuk fase keamanan: Keamanan Credential & RBAC — menyimpan cloud credential dengan benar (jangan di-commit!), memakai IRSA di EKS dan Workload Identity di GKE, serta membatasi akses user ke namespace velero.