Belajar GitOps - FluxCD - Disaster Recovery & Backup

#Pendahuluan

Di episode 25 kalian sudah membangun observability penuh untuk Flux — metrik, dashboard, log, tracing, dan alerting. Kalian bisa melihat semuanya dan tahu persis kapan sesuatu mulai bermasalah. Namun ada satu pertanyaan yang belum dijawab: apa yang terjadi ketika semuanya hilang? Sebuah klaster bisa hancur oleh kesalahan konfigurasi, bencana di region cloud, atau penghapusan yang tidak disengaja.

Ini saatnya jujur terhadap diri sendiri: observability tidak menyelamatkan data. Semua dashboard dan alert yang indah itu tidak ada artinya jika tidak ada rencana untuk membangun kembali dari nol. Tim yang hanya fokus pada monitoring tanpa persiapan disaster recovery (DR) akan menghabiskan insiden berikutnya dengan panik mencari tahu langkah mana yang harus dijalankan.

Pada episode ini kita akan menyusun strategi DR yang nyata untuk stack Flux: strategi backup dengan Git, Velero, dan snapshot etcd, backup konfigurasi Flux secara spesifik, prosedur rebuild klaster dari nol hingga aplikasi berjalan, serta pengujian DR yang terukur dengan RTO dan RPO. Karena rencana yang tidak pernah diuji hanyalah sekumpulan tulisan.

#Strategi Backup

#Git sebagai Backup Infrastruktur

Keunggulan terbesar GitOps adalah ia membuat infrastruktur mudah dibackup secara intrinsik. Semua manifest — Kustomization, GitRepository, HelmRelease, dan konfigurasi lain — hidup di repository Git. Selama repository aman, definisi infrastruktur tidak pernah hilang. Ini membuat Git sendiri menjadi lapisan backup pertama yang paling murah dan paling mudah diverifikasi: cukup pastikan repo di-push dan punya riwayat yang benar.

Namun Git bukan segalanya. Git menyimpan keinginan (desired state), bukan kenyataan (actual state). State ephemeral — seperti data aplikasi, Secret yang tidak di-commit, dan resource yang dibuat dinamis — tidak ada di Git. Itulah mengapa Git sebagai backup harus dilengkapi lapisan lain.

#Backup State Klaster dengan Velero

Velero adalah tool standard untuk membackup state klaster Kubernetes. Velero membuat snapshot resource Kubernetes (dan opsional volume) ke storage eksternal seperti S3 atau GCS. Backup dibuat dalam beberapa langkah:

velero install --provider aws --bucket gitops-backups \
  --backup-location-config region=ap-southeast-1
 
velero backup create full-backup \
  --include-namespaces default,payments,checkout

Backup Velero menyimpan objek Kubernetes beserta konten volume jika dikonfigurasi. Untuk memulihkan, satu perintah saja:

velero restore create --from-backup full-backup

Velero cocok untuk memulihkan resource yang tidak ada di Git — misalnya Secret yang dibuat secara imperatif atau resource dari operator lain. Pastikan jadwal backup otomatis dibuat, bukan manual:

velero schedule create daily-backup --schedule "0 2 * * *" \
  --include-namespaces default,payments,checkout

#Snapshot etcd

etcd adalah database kontrol plane Kubernetes — tempat menyimpan semua objek klaster. Snapshot etcd adalah lapisan paling dalam: jika etcd rusak, seluruh klaster bisa mati. Untuk klaster yang dikelola sendiri, ambil snapshot etcd secara berkala:

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot.db

Perhatikan bahwa snapshot etcd memulihkan kondisi klaster ke titik waktu tertentu — termasuk resource yang sudah dihapus. Ini beda dengan Git yang selalu menuju desired state. Di banyak kasus, kombinasi yang sehat adalah snapshot etcd sebagai cadangan darurat dan Git sebagai kebenaran jangka panjang.

#Ekspor Konfigurasi

Kadang yang dibutuhkan bukan backup penuh, melainkan ekspor konfigurasi saat ini. kubectl get dengan opsi export bisa menangkap konfigurasi resource tertentu untuk disimpan sebagai catatan. Ini berguna sebagai snapshot dokumentasi, tetapi jangan dijadikan satu-satunya strategi — ekspor manual mudah terlupakan dan tidak konsisten.

#Backup Konfigurasi Flux

#flux export

Flux menyediakan perintah khusus untuk mengekspor seluruh konfigurasi Flux dari klaster:

flux export > flux-export.yaml

flux export menghasilkan semua custom resource Flux — Kustomization, GitRepository, HelmRelease, Provider, Alert, dan lainnya — dalam satu file YAML. Ini adalah cara tercepat untuk menangkap "siapa yang mereconcile apa" sebelum klaster berubah atau hilang. Jalankan secara berkala dan simpan outputnya ke lokasi yang aman di luar klaster.

#Backup Repository GitOps

Repository GitOps itu sendiri adalah aset paling berharga. Backup-nya berarti memastikan:

• Remote repository (GitHub, GitLab) punya backup otomatis atau mirror.
• Setiap developer memiliki clone lengkap yang di-push ulang secara berkala.
• Tag dan release tidak terhapus oleh operasi pembersihan yang salah.

Untuk repository self-hosted atau mirror lokal, jadwalkan backup berkala:

git clone --mirror \
  https://github.com/devvnull/gitops-production.git \
  /backup/gitops-production.git

Clone mirror menyimpan seluruh referensi dan riwayat — bahkan branch yang tidak aktif — sehingga bisa memulihkan repository meskipun remote utama hilang.

#Backup Secret Terenkripsi

Secret adalah bagian yang paling sulit dibackup: menyimpannya dalam teks biasa di Git adalah pelanggaran prinsip GitOps. Solusinya adalah enkripsi — seperti yang sudah kalian pelajari di episode SOPS dan Sealed Secrets. Pola yang benar:

• Enkripsi di repo: Secret di-commit dalam bentuk terenkripsi (SOPS) atau disegel (Sealed Secrets) sehingga aman disimpan di Git dan otomatis terbackup.
• Backup kunci: kunci dekripsi (misal kunci PGP untuk SOPS, atau kunci private Sealed Secrets) disimpan terpisah dan aman — misalnya di vault atau secret manager.
• Backup Secret dari klaster: untuk Secret yang tidak ada di Git, ekspor dengan enkripsi ke storage eksternal.

Aturan emasnya: kunci dan data terenkripsi jangan pernah disimpan di tempat yang sama. Jika keduanya hilang bersama, enkripsi tidak lagi berguna.

#Disaster Recovery

#Prosedur Rebuild Klaster

Disaster recovery dimulai dari asumsi paling buruk: klaster tidak bisa diselamatkan dan harus dibangun baru. Prosedur rebuild yang baik adalah urutan langkah yang terdokumentasi dan berulang:

1. Provision klaster baru — jaringan, node, dan kontrol plane (bisa dengan Terraform, dibahas di episode 29).
2. Siapkan akses — konfigurasi kubectl, dan pastikan kredensial repository Git valid.
3. Bootstrap Flux — jalankan bootstrap agar controller terpasang.
4. Biarkan Flux bekerja — Kustomization root menarik seluruh konfigurasi dari Git.
5. Pulihkan state non-Git — restore Velero untuk data dan resource yang tidak ada di Git.
6. Verifikasi — jalankan smoke test untuk memastikan aplikasi benar-benar berfungsi.

Urutan ini penting: Flux harus reconcile dulu sebelum restore Velero, agar tidak menimpa desired state Git dengan state lama.

#Re-bootstrap Flux

Re-bootstrap Flux ke klaster baru adalah langkah yang harus berjalan mulus jika repository GitOps dirawat dengan benar:

flux bootstrap github \
  --owner=devvnull \
  --repository=gitops-production \
  --branch=main \
  --path=clusters/production

Bootstrap membaca Kustomization dari clusters/production/flux-system dan selanjutnya mereconcile semua yang dirujuk. Selama struktur repo konsisten dan secret yang dirujuk (misal webhook token) tersedia, klaster akan terbangun dengan sendirinya.

#Restorasi Aplikasi

Setelah Flux berjalan, aplikasi di-restore dalam dua aliran. Aliran pertama dari Git: manifest aplikasi langsung di-deploy oleh Flux. Aliran kedua dari backup: state yang tidak ada di Git, terutama data di volume dan Secret. Kombinasi keduanya adalah alasan mengapa strategi backup ganda (Git + Velero) diperlukan.

Saat restore, perhatikan urutan dependensi: database harus pulih sebelum aplikasi yang bergantung padanya dianggap sehat. Gunakan flux get kustomization untuk memantau urutan reconciliation dan pastikan semuanya mencapai status Ready:

flux get kustomization -A
kubectl get pods -A | grep -v Running

#Rekonsiliasi State

Setelah restore, klaster mungkin memiliki perbedaan antara state Git dan state hasil restore. Flux akan segera mereconcile perbedaan ini — kadang hal itu tidak diinginkan. Misalnya, restore Velero yang mengembalikan resource lama bisa langsung di-overwrite oleh Flux menuju desired state Git, atau sebaliknya.

Kunci untuk menghindari konflik: suspend Kustomization sementara saat restore, lalu resume setelah state selesai dipulihkan:

flux suspend kustomization apps
velero restore create --from-backup full-backup
flux resume kustomization apps

Ini memberi kontrol penuh: restore data dulu, baru biarkan Flux menyesuaikan konfigurasi menuju desired state.

#Menguji DR

#Latihan DR (DR Drill)

Rencana DR yang tidak pernah diuji adalah teks belaka. Latihan DR adalah ujian nyata terhadap prosedur rebuild: buat klaster baru, jalankan seluruh prosedur dari nol, dan ukur berapa lama waktu yang dibutuhkan. Jadwalkan latihan berkala — misalnya kuartalan — dengan cakupan yang naik bertahap: dari hanya memulihkan Flux, menjadi memulihkan Flux plus aplikasi, hingga memulihkan aplikasi plus data.

Hasil latihan selalu membawa temuan: flag bootstrap yang terlupakan, secret yang tidak tersedia, atau langkah yang urutannya salah. Setiap temuan harus diperbaiki di prosedur dan diujikan lagi di latihan berikutnya.

#RTO dan RPO

Dua metrik yang membuat DR terukur:

• RTO (Recovery Time Objective) — berapa lama target maksimal untuk memulihkan layanan setelah insiden. RTO menentukan seberapa cepat prosedur rebuild harus berjalan.
• RPO (Recovery Point Objective) — berapa banyak data yang boleh hilang. RPO menentukan seberapa sering backup diambil.

Hubungan keduanya dengan strategi:

Tentukan target yang realistis berdasarkan dampak bisnis, lalu ukur latihan terhadap target tersebut.

#Skrip Otomasi

Semakin banyak langkah yang otomatis, semakin sedikit kesalahan manusia saat panik. Otomasi untuk DR bisa berupa:

• Skrip rebuild yang menjalankan provision + bootstrap dalam satu perintah.
• Workflow CI untuk restore yang mengeluarkan laporan RTO/RPO setelah selesai.
• Checklist verifikasi otomatis yang menjalankan smoke test setelah restore.

Contoh skrip sederhana yang menggabungkan bootstrap dan verifikasi:

flux bootstrap github \
  --owner=devvnull \
  --repository=gitops-production \
  --branch=main \
  --path=clusters/production \
  --timeout=15m
 
flux get kustomization -A --wait
flux tree kustomization flux-system --namespaces=flux-system

flux get kustomization --wait menunggu semua resource siap; flux tree menampilkan struktur dependency. Skrip yang sama bisa dijadikan dasar latihan DR dan verifikasi produksi.

#Penutup

Pada episode 26 ini kalian telah menyusun strategi disaster recovery untuk stack Flux: Git sebagai backup infrastruktur yang paling murah, Velero untuk state klaster dan volume, snapshot etcd sebagai lapisan terdalam, ekspor dan backup konfigurasi Flux termasuk Secret terenkripsi, prosedur rebuild klaster dengan re-bootstrap dan restorasi aplikasi, serta pengujian DR yang diukur dengan RTO dan RPO.

Inti yang harus dibawa pulang:

• Git menyimpan desired state, bukan actual state — lengkapi dengan Velero untuk data dan resource non-Git.
• Ekspor konfigurasi Flux secara berkala dengan flux export dan pastikan repository GitOps punya mirror.
• Kunci enkripsi dan data terenkripsi harus terpisah — enkripsi tanpa kunci yang bisa dipulihkan hanyalah rasa aman palsu.
• Urutan recovery itu kritis — bootstrap Flux dulu, reconcile, lalu restore Velero; gunakan suspend untuk mengontrol timing.
• Rencana DR diuji, bukan disimpan — ukur latihan terhadap RTO dan RPO, dan otomasikan sebanyak mungkin langkahnya.

Sekarang klaster kalian bisa dipulihkan kapan pun. Namun siklus hidup tidak berhenti di deployment manual — saatnya menghubungkan semuanya dengan pipeline. Di episode 27 selanjutnya kita akan membahas CI/CD Pipeline Integration — memisahkan tanggung jawab CI dan CD, membangun pipeline dari checkout hingga security scanning, menghubungkan CD ke GitOps, dan integrasi dengan GitHub Actions, GitLab CI/CD, serta Jenkins. Pastikan tetap semangat!