Belajar GitOps dengan ArgoCD - Disaster Recovery & Backup

#Pendahuluan

Di episode 20 sebelumnya kita membangun service mesh yang dikelola penuh dari Git — dan di sana tersembunyi kekuatan GitOps yang paling kurang dihargai: semua yang mengatur perilaku sistem sudah tersimpan di Git. Jika cluster lenyap malam ini, apa yang tersisa? Hampir semuanya. Pada episode ini kita membahas disaster recovery & backup — bukan sekadar prosedur, melainkan cara berpikir: seberapa cepat kalian bangkit (RTO) dan seberapa banyak data yang rela hilang (RPO).

Mengapa ini penting? Disaster recovery adalah satu-satunya fitur yang tidak bisa diuji saat benar-benar dibutuhkan. Banyak tim punya rencana DR yang "tinggal menjalankan skrip", dan baru sadar skripnya rusak ketika cluster hilang dan skrip itu tidak pernah dijalankan sejak enam bulan lalu. GitOps memberi keuntungan struktural: karena konfigurasi hidup di Git, pemulihan adalah masalah menyusun ulang, bukan membangun ulang. Tugas kita adalah memastikan bagian yang bukan konfigurasi — secret, state ArgoCD, dan data — ikut terlindungi.

#Git sebagai Backup Pertama

Sebelum membangun infrastruktur backup, ingatlah bahwa Git itu sendiri adalah backup konfigurasi terbaik yang pernah ada. Setiap Application, Project, manifest aplikasi, dan konfigurasi mesh sudah tersimpan sebagai commit dengan riwayat penuh. Untuk aplikasi stateless, DR bahkan bisa sesederhana:

1. Buat cluster baru.
2. Instal ArgoCD.
3. Registrasi repo dan cluster (dari episode 9).
4. Buat Application dengan source yang sama — ArgoCD menyinkronkan semuanya.

Inilah mengapa prinsip GitOps "konfigurasi deklaratif di Git" bukan sekadar kebersihan — ia adalah kebijakan DR. Jika kalian menemukan konfigurasi yang tidak ada di Git (misalnya aplikasi yang dibuat manual lewat UI tanpa commit), itu adalah risiko DR yang wajib diperbaiki segera.

#Ekspor Konfigurasi ArgoCD

Meski Git menyimpan Application, ada bagian ArgoCD yang bukan manifest: credentials (repo SSH key, token cluster), RBAC, dan pengaturan argocd-cm. Untuk pemulihan penuh, ekspor semua itu:

Ekspor konfigurasi ArgoCD

argocd app list -o name > backup-apps.txt
argocd proj list -o name > backup-projects.txt
argocd repo list -o name | awk '{print $1}' > backup-repos.txt

Namun ekspor manual rapuh dan mudah lupa. Pendekatan yang lebih kokoh adalah mengelola ArgoCD itu sendiri secara GitOps (pola self-managed dari episode 6): argocd-cm, argocd-rbac-cm, repo secrets, dan cluster secrets disimpan sebagai manifest terenkripsi (dari episode 12) di repo argocd-config. Dengan begitu, pemulihan ArgoCD = kubectl apply -f bootstrap + satu ApplicationSet.

#Skrip Backup dan Penjadwalan Otomatis

Untuk state yang belum sepenuhnya di-Git, buat skrip backup terjadwal. Skrip ini mengekspor resource ArgoCD dan resource cluster ke YAML, lalu menyimpannya ke bucket atau repo:

#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/backup/$(date +%Y%m%d-%H%M)"
mkdir -p "$BACKUP_DIR"
kubectl get applications,appprojects -n argocd -o yaml > "$BACKUP_DIR/argocd-config.yaml"
kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=repo \
  -o yaml > "$BACKUP_DIR/repos.yaml"
kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster \
  -o yaml > "$BACKUP_DIR/clusters.yaml"

Jadwalkan dengan CronJob di cluster yang berbeda dari yang di-backup (backup tidak boleh ikut hilang bersama cluster):

CronJob backup harian

apiVersion: batch/v1
kind: CronJob
metadata:
  name: argocd-backup
  namespace: argocd
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: backup
              image: bitnami/kubectl:latest
              command: ["/backup/backup.sh"]
              volumeMounts:
                - name: script
                  mountPath: /backup

#Prosedur Disaster Recovery

Ketika cluster benar-benar hilang, ikuti urutan berikut — dari yang paling tidak bergantung pada yang hilang:

1. Registrasi repo di tempat baru. Pastikan akses ke Git tetap ada; jika token/SSH key dicabut bersamaan dengan cluster, minta yang baru.
2. Instal ArgoCD. Pakai Helm atau manifest terbaru (episode 4).
3. Restore konfigurasi. Terapkan argocd-config.yaml, repos.yaml, dan clusters.yaml dari backup terakhir.
4. Restore aplikasi. Terapkan file Application/ApplicationSet; ArgoCD menarik manifest dari Git dan menyinkronkan.
5. Rekonsiliasi state. Jalankan argocd app sync -l app.kubernetes.io/part-of=myapp lalu verifikasi health semua aplikasi:

Sinkronkan semua aplikasi setelah restore

argocd app list
argocd app sync -l app.kubernetes.io/instance=prod
argocd app wait --health

Seluruh langkah ini bekerja karena Git adalah sumber kebenaran. Cluster baru tidak tahu sejarah — ia hanya menarik keadaan yang diinginkan dan mewujudkannya. Aplikasi stateless pulih secepat ArgoCD selesai menyinkronkan; aplikasi stateful membutuhkan restore data (Velero, snapshot database) yang berada di luar lingkup ArgoCD.

#Multi-Cluster DR

Untuk SLO yang lebih ketat, cluster tunggal tidak cukup. Dua pola utama:

Dalam pola GitOps, keduanya diwujudkan dengan satu repo, dua ApplicationSet — masing-masing menargetkan cluster berbeda (generator cluster dari episode 11). Failover active-passive berarti memindahkan trafik DNS ke cluster sekunder yang sudah menyinkronkan konfigurasi yang sama; karena Git identik, perilaku kedua cluster identik.

#Menguji DR: RTO dan RPO

Rencana DR tanpa pengujian adalah fiksi. Dua metrik yang wajib diukur:

• RPO (Recovery Point Objective) — seberapa baru data saat dipulihkan. Ditentukan frekuensi backup: backup harian berarti RPO maksimal 24 jam.
• RTO (Recovery Time Objective) — seberapa cepat sistem kembali. Diukur dengan DR drill: matikan cluster staging, nyalakan yang baru, dan catat waktunya.

Praktik baik: jadwalkan drill DR setidaknya setiap kuartal, otomatiskan dengan skenario "chaos" (episode 26), dan dokumentasikan hasilnya. Dokumentasi harus menjawab: siapa yang memutuskan failover, perintah apa yang dijalankan, ke mana trafik dipindahkan, dan bagaimana verifikasi selesai. Setiap drill yang memperpanjang RTO adalah umpan balik untuk menyederhanakan prosedur.

#Penutup

Episode ini menjadikan DR bagian dari desain GitOps: Git sebagai backup konfigurasi pertama, ekspor konfigurasi ArgoCD, skrip backup dan CronJob otomatis, backup secret terenkripsi, prosedur pemulihan dari cluster kosong, pola multi-cluster active-passive dan active-active, serta pengukuran RTO/RPO lewat DR drill yang teratur.

Poin yang harus kalian bawa:

• Konfigurasi di Git adalah backup DR yang paling berharga; yang tersisa adalah credential, secret, dan state.
• Kelola ArgoCD secara GitOps agar pemulihan ArgoCD sama mudahnya dengan aplikasi.
• Backup dijadwalkan dan disimpan di tempat yang tidak ikut hilang bersama cluster.
• Secret mentah tidak boleh masuk Git; gunakan enkripsi di repositori.
• DR yang tidak pernah diuji adalah DR yang tidak ada — lakukan drill teratur dan ukur RTO.

Cluster yang bisa pulih dari nol membuat kalian tidur nyenyak. Namun bagaimana kalian tahu cluster sehat, dan bagaimana kalian melihat tanda-tanda masalah sebelum menjadi bencana? Di episode 22 selanjutnya kita membahas monitoring & observability — metrik ArgoCD di Prometheus, dasbor Grafana, alerting, dan agregasi log. Sampai jumpa di episode 22!