Belajar DevOps Engineer - Disaster Recovery & Backup
Sistem yang hebat tidak bernilai jika tidak bisa dipulihkan setelah bencana; di episode ini kalian memahami RPO dan RTO, backup dengan Velero dan Restic, menyusun disaster recovery plan, lalu menjalankan simulasi restore cluster sebagai latihan wajib
#Pendahuluan
Selama 19 episode kalian membangun sistem yang canggih: container, Kubernetes, IaC, GitOps, observability. Tapi ada satu pertanyaan yang menentukan apakah semuanya benar-benar "produksi-ready": ketika semuanya hilang — cluster terhapus, data terenkripsi ransomware, region down — seberapa cepat dan seberapa lengkap kalian bisa kembali?
Disaster Recovery (DR) adalah jawaban atas pertanyaan itu. Ia bukan sekadar "punya backup", melainkan rencana, proses, dan bukti bahwa pemulihan benar-benar bekerja. Di episode ini kalian memahami dua metrik yang mengatur segalanya — RPO dan RTO — lalu mempraktikkan backup dengan Velero dan Restic, serta simulasi restore cluster.
#RPO dan RTO: Dua Angka yang Menentukan Segalanya
Setiap keputusan DR diukur dengan dua metrik:
| Metrik | Pertanyaan | Semakin kecil = |
|---|---|---|
| RPO (Recovery Point Objective) | Berapa banyak data yang boleh hilang? | Backup lebih sering |
| RTO (Recovery Time Objective) | Berapa cepat layanan harus kembali? | Infra failover lebih siap |
Contoh konkret: RPO 15 menit berarti kalian rela kehilangan data maksimal 15 menit terakhir → backup/incremental tiap 15 menit. RTO 1 jam berarti seluruh proses pemulihan — dari trigger hingga layanan hidup — harus selesai dalam 1 jam.
RPO 0 = data loss nol → replication sinkron, biaya tinggi
RPO 15m = backup streaming tiap 15 menit
RTO 1h = runbook pemulihan + automate semuanya
RTO 4h = proses manual masih boleh, tapi terujiImportant
RPO dan RTO adalah keputusan bisnis, bukan teknis. Kalian tidak memilih angka yang "bagus secara teknologi", melainkan yang sepadan dengan nilai data dan dampak downtime. Biaya DR harus proporsional dengan biaya kehilangan — dan angka itu harus ditulis dan disetujui pemangku kepentingan, lalu ditulis dalam rencana.
#Backup di Dunia Container: Velero dan Restic
Backup modern di dunia Kubernetes memakai dua tool utama:
- Velero — backup dan restore cluster Kubernetes: seluruh objek (Deployment, ConfigMap, Secret, bahkan state), plus volume data. Bisa dijadwalkan, terenkripsi, dan dipulihkan ke cluster baru.
- Restic / Kopia — backup file sistem dan volume pada level mesin, dengan deduplikasi dan enkripsi. Ideal untuk server tradisional dan volume besar.
Prinsip 3-2-1 yang harus kalian hafalkan: 3 salinan data, di 2 media berbeda, 1 di antaranya offsite (di luar lokasi utama).
#Menyusun Disaster Recovery Plan
DR plan yang baik bukan dokumen tebal yang tidak pernah dibaca, melainkan runbook yang bisa dijalankan manusia dalam tekanan. Struktur yang berfungsi:
- Identifikasi aset — apa yang harus dipulihkan? (state, data, config, DNS, certificate)
- Tentukan RPO/RTO — per aset, bukan satu angka untuk semua.
- Desain strategi — backup terjadwal (Velero/Restic), snapshot cloud, multi-region, atau kombinasi.
- Otomasi pemulihan — pemulihan infrastruktur harus IaC (episode 9); yang tersisa hanyalah data.
- Uji secara terjadwal — DR plan yang tidak pernah diuji adalah ilusi. Simulasi bukan opsional.
- Dokumentasikan + latih — runbook ringkas, searah, dan diuji oleh orang yang tidak membuatnya.
#Praktik: Simulasi Restore Cluster dengan Velero
Alur lengkap yang harus kalian latih: backup → hapus cluster → restore ke cluster baru → verifikasi.
Pertama, pasang Velero dengan backend di object storage (S3/GCS):
velero install \
--provider aws \
--bucket velero-backups \
--secret-file ./credentials-velero \
--backup-location-config region=ap-southeast-1Jadwalkan backup berkala dengan RPO yang kalian tetapkan:
velero schedule create daily-backup \
--schedule="0 2 * * *" \
--ttl 720h \
--include-namespaces default,team-billingLalu simulasi bencana penuh: hapus semua resource, restore dari backup, dan verifikasi:
# 1. Bencana: cluster hilang
kubectl delete ns default
velero backup create manual-backup --include-namespaces default
# 2. Pulihkan ke cluster baru
velero restore create --from-backup daily-backup-20260816
velero restore get
velero describe restore daily-backup-20260816-<id>
# 3. Verifikasi
kubectl get pods -n default
kubectl get ingress,svc,deploy -n default
curl -f https://app.example.com/healthRestore Velero menciptakan kembali seluruh objek Kubernetes; aplikasi dan datanya hidup kembali dari backup. Ukur waktu yang dibutuhkan — itulah RTO aktual kalian. Jika lebih lama dari target, kalian baru saja menemukan masalah DR sebelum bencana nyata.
#Pitfall Umum
- Backup tanpa restore test — backup yang tidak pernah diuji adalah asumsi, bukan jaminan.
- Hanya membackup data, bukan state — infrastruktur yang hidup harus pulih juga; kombinasikan Velero dengan IaC.
- RPO/RTO hanya di atas kertas — tanpa angka target, kalian tidak tahu kapan harus panik.
- Backup disimpan di cluster yang sama — cluster hangus = backup hangus. Simpan offsite.
- Satu strategi untuk semua data — data database, log, dan cache punya nilai yang berbeda; perlakukan sesuai nilainya.
#Penutup
Inti yang harus dibawa pulang:
- RPO mengukur toleransi kehilangan data; RTO mengukur target waktu pulih — keduanya keputusan bisnis.
- Velero membackup cluster dan state; Restic membackup file dan volume; prinsip 3-2-1 memandu lokasi.
- DR plan adalah runbook teruji, bukan dokumen — dan simulasi restore adalah latihan wajib.
- Ukur RTO aktual dari simulasi; jika meleset dari target, itulah penemuan paling berharga.
Di episode 21 selanjutnya kita kembali ke CI/CD Lanjutan — mempercepat pipeline dengan parallel jobs, caching, matrix builds, dan pola pipeline-as-code. Tim DevOps diukur dari kecepatan dan keandalan pipeline-nya; episode ini membekali kalian dengan teknik optimasinya.