Belajar Kubernetes Block Storage RWO - Disaster Recovery & Restore Flow
Menyusun strategi disaster recovery untuk Longhorn: merestorasi backup ke cluster baru, memakai Longhorn volume DR untuk replikasi asinkron lintas-cluster, menjadwalkan test restore rutin, dan menetapkan target RPO/RTO yang realistis.
#Pendahuluan
Backup sudah berjalan otomatis di episode 15. Episode 16 menjawab pertanyaan paling menegangkan: apa yang terjadi kalau semua cluster hilang? Inilah disaster recovery — bukan sekadar "punya backup", melainkan bisa membuktikan bahwa backup bisa dikembalikan.
Mengapa penting? Backup yang tidak pernah diuji = backup yang kemungkinan besar rusak. RTO/RPO hanya angka sampai kalian membuktikan restore bekerja. Di episode ini kalian mempraktikkan restore ke cluster baru dan merancang DR policy.
#Restore Backup ke Cluster Baru
#Prosedur Dasar
- Deploy Longhorn baru di cluster baru (episode 4).
- Set BackupTarget yang sama (NFS/S3) di cluster baru.
- Buka UI → Backup → pilih backup file → Restore.
- PVC baru dibuat; mount ke workload dan verifikasi.
Atau via manifest dengan StorageClass fromBackup:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-from-backup
provisioner: driver.longhorn.io
parameters:
fromBackup: "s3://my-bucket@us-east-1/backups?backup=backup-xyz"#Verifikasi Restore
Setelah PVC Bound, mount ke StatefulSet (kembalikan data-postgres-0) lalu jalankan:
kubectl exec -it postgres-0 -- psql -U postgres -d laravel -c "\dt"Cek struktur tabel & data — ini bukti restore berhasil. Jangan hanya lihat status PVC Bound.
#Cross-Cluster DR
#Longhorn DR Volume (Async Replication)
Longhorn menyediakan volume DR: replikasi asinkron ke cluster sekunder. Backup tetap dikelola cluster utama, cluster DR menunggu dengan volume aktif standby:
- Longhorn DR volume melakukan polling backup dari target dan meng-update volume DR.
- Saat cluster utama gagal, tingkatkan volume DR menjadi writable di cluster cadangan.
- PostgreSQL di sisi DR di-start setelah failover.
Ini memberikan RPO mendekati backup terakhir (menit-jam, tergantung siklus) dan RTO dalam menit — jauh lebih besar dari restore manual.
#CloudCasa / Velero (Opsional)
Alat seperti Velero atau CloudCasa mengelola backup + DR secara terkelola (resource + volume). Longhorn menyediakan integrasi CSI snapshot yang dipakai Velero. Kita bedah lebih lanjut di episode 23.
#Perbandingan Pendekatan
| Pendekatan | RPO | RTO | Kompleksitas |
|---|---|---|---|
| Restore manual dari backup | sesuai siklus backup (jam) | jam | Rendah |
| Longhorn volume DR | menit (siklus poll) | menit | Sedang |
| Velero/CloudCasa full DR | menit | menit | Tinggi |
#Test Restore Routine
#Jangan Hanya Mem-Backup
Backup yang tidak pernah di-restore adalah ilusi keamanan. Jadwalkan test restore — lewat worry list, uji pemicu:
Setiap 3 bulan:
1. Restore backup terbaru ke cluster staging-lab.
2. Jalankan PostgreSQL, verifikasi `\dt`, hitung row.
3. Simulasikan login Laravel: API response normal.
4. Catat durasi restore → update RTO nyata.Catatan: latihan ini sekaligus "membakar" proses — jika restore gagal, kalian tahu sebelumnya, bukan saat bencana.
#Automasi Test Restore
Gunakan pipeline (GitHub Actions, schedule cron) yang menjalankan:
kubectl apply -f restore-sc.yaml
kubectl apply -f postgres-restore-sts.yaml
kubectl wait --for=condition=ready pod -l app=postgres-restore --timeout=300s
kubectl exec deploy/postgres-restore -- psql -c "SELECT 1;" && echo "restore-ok"Kalau berhasil, kirim notifikasi; jika gagal, alert. Ini menjadikan DR sebuah mekanisme yang terus diuji, bukan dokumentasi yang menganggur.
#RPO & RTO
#Menetapkan Target
| Metrik | Definisi | Contoh Target |
|---|---|---|
| RPO (Recovery Point Objective) | Seberapa jauh waktu kembali — seberapa banyak data yang rela hilang | 4 jam (backup 4×/hari) |
| RTO (Recovery Time Objective) | Seberapa cepat layanan kembali | 4 jam (restore + migrasi) |
Target ini menentukan frekuensi backup dan arsitektur DR:
- RPO 1 jam → recurring backup tiap jam + volume DR.
- RTO 30 menit → perlu kluster standby + failover otomatis.
- RPO 24 jam → cukup backup harian.
Important
RPO/RTO adalah keputusan bisnis, bukan teknis murni. Diskusikan dengan stakeholder berapa menit/jam toleransi downtime data. Setelah itu baru kalkulasi frekuensi backup dan investasi DR — jangan kebalik.
#Penutup
Inti yang harus dibawa pulang:
- Restore = deploy Longhorn baru → set BackupTarget → restore backup → verifikasi.
- Longhorn volume DR memberi replikasi asinkron lintas-cluster untuk failover cepat.
- Test restore rutin (mis. kuartal) wajib — backup yang tak diuji = ilusi.
- Tetapkan RPO/RTO sebagai keputusan bisnis, lalu susun frekuensi backup & arsitektur DR-nya.
Di episode 17 selanjutnya kita akan membahas monitoring & observability Longhorn — metrik Prometheus bawaan, dashboard Grafana resmi, alerting untuk volume degraded & backup gagal, health UI, dan sentralisasi log manager. Sampai jumpa di episode 17!