Disaster Recovery #

Dalam operasional infrastruktur IT, satu-satunya hal yang lebih buruk daripada tidak memiliki cadangan data (backup) adalah berasumsi bahwa cadangan data kita berfungsi tanpa pernah menguji proses pemulihannya (restoration). Di era arsitektur cloud-native, kluster Kubernetes rentan terhadap berbagai skenario bencana (disasters), mulai dari kerusakan hardware fisik di pusat data cloud, serangan siber pemerasan (ransomware) yang merusak etcd, hingga kesalahan manusia (human error) yang secara tidak sengaja menghapus namespace produksi utama. Disaster Recovery (DR) bukanlah sekadar aktivitas menyalin data, melainkan perencanaan kelangsungan bisnis (Business Continuity) yang dirancang secara matang agar sistem dapat pulih dalam ambang batas toleransi waktu yang disepakati. Artikel ini membahas klasifikasi objek cadangan kluster, implementasi perkakas Velero, strategi pencadangan database yang konsisten, perbandingan arsitektur pemulihan multi-kluster, serta simulasi pengujian restorasi yang tangguh.

Apa yang Harus Dicadangkan? #

Sebuah kluster Kubernetes memiliki dua kategori keadaan (state) yang wajib dicadangkan secara terpisah karena memiliki metode pemulihan yang sangat berbeda:

+-------------------------------------------------------------------------+
|                        KATEGORI CADANGAN KLUSTER                        |
+---------------------------------------+---------------------------------+
|   1. CLUSTER STATE (METADATA)         |   2. WORKLOAD DATA (PERSISTENT) |
|   - Konfigurasi objek di etcd database    |   - Data riil di Persistent Volume  |
|   - Deployments, Services, RBAC, Secrets  |   - Database records, user uploads  |
|   - Dapat di-backup via Git (GitOps flow) |   - Tidak ada di Git (Statis)       |
|   - Solusi: Git repositori deklaratif    |   - Solusi: Volume Snapshot & Dump  |
+---------------------------------------+---------------------------------+

1. Jaminan Metadata Kluster (Cluster State) #

Semua manifest objek yang mendefinisikan kluster kita (seperti konfigurasi Deployment, Service, ConfigMap, Secret, NetworkPolicy, dan RBAC) disimpan di dalam database internal etcd Control Plane.

Jika kita menerapkan prinsip GitOps secara disiplin menggunakan perkakas seperti ArgoCD atau Flux CD, repositori Git kita secara otomatis bertindak sebagai cadangan Cluster State terbaik. Jika kluster hancur total, kita hanya perlu membangun kluster kosong baru, lalu menghubungkannya ke repositori Git kita untuk melakukan instalasi ulang seluruh objek secara otomatis.

2. Jaminan Data Aplikasi (Persistent Workload Data) #

GitOps tidak dapat mencadangkan data dinamis yang disimpan oleh aplikasi di dalam disk penyimpanan (seperti database PostgreSQL, antrian pesan RabbitMQ, atau folder berkas unggahan pengguna). Data ini disimpan secara fisik di dalam penyedia penyimpanan cloud melalui abstraksi PersistentVolume (PV).

Penyimpanan PV inilah yang wajib kita cadangkan menggunakan mekanisme Volume Snapshots dan proses ekspor database native secara berkala.

Velero: Standar Industri Backup dan Restore #

Velero adalah perkakas open-source yang dikelola oleh VMware yang dirancang khusus untuk melakukan pencadangan dan pemulihan objek metadata Kubernetes serta Persistent Volume secara native. Velero berinteraksi dengan Kubernetes API Server untuk mengambil snapshot objek, mengompresinya, lalu menyimpannya ke dalam Object Storage (seperti AWS S3, Google Cloud Storage, atau Harbor) menggunakan plugin cloud terkait.

flowchart TD
    Admin["Administrator (velero CLI)"] -->|"1. Kirim Custom Resource Backup"| K8sAPI["Kubernetes API Server"]
    K8sAPI -->|"2. Deteksi CR Baru"| VeleroPod["Velero Controller Pod"]
    
    subgraph ClusterBackup["Proses internal Velero"]
        direction TB
        VeleroPod -->|"3. Query Metadata Objek"| K8sAPI
        VeleroPod -->|"4. Minta Snapshot Disk via CSI"| CSIDriver["CSI Storage Driver"]
    end
    
    VeleroPod -->|"5. Unggah Arsip YAML (.tar.gz)"| S3["Object Storage (S3 / GCS)"]
    CSIDriver -->|"6. Buat Snapshot Blok Disk"| CloudSnapshot["Cloud Provider Disk Snapshots"]

1. Instalasi Velero Tingkat Produksi (AWS S3 Backend) #

Untuk menginstal Velero, kita harus menyediakan kredensial akses bucket penyimpanan S3 eksternal kluster.

# Memasang biner controller Velero ke dalam kluster
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket production-k8s-backups \
  --backup-location-config region=ap-southeast-1 \
  --snapshot-location-config region=ap-southeast-1 \
  --secret-file ./credentials-velero # Berkas kredensial IAM dengan izin S3 & EC2 Snapshot

2. Manajemen Perintah Backup Harian #

Setelah terpasang, kita dapat mengotomatiskan pembuatan cadangan menggunakan perintah deklaratif:

# 1. Membuat backup satu kali untuk namespace 'prod-apps'
velero backup create prod-apps-backup-20260617 \
  --include-namespaces prod-apps

# 2. Membuat jadwal backup otomatis (Schedule) setiap hari pukul 02:00 WIB dini hari
velero schedule create daily-prod-backup \
  --schedule="0 2 * * *" \
  --include-namespaces prod-apps \
  --ttl 720h0m0s # Tetapkan masa kedaluwarsa backup 30 hari (Time-To-Live)

# 3. Memeriksa status kesehatan hasil backup
velero backup get
velero backup describe prod-apps-backup-20260617

Mekanisme Restore Velero dan Pengujian Isolasi #

Membiarkan file cadangan menumpuk di S3 tanpa pernah mencoba memulihkannya adalah kesalahan besar. Kita harus membiasakan tim untuk melakukan pengujian restorasi secara berkala di lingkungan terisolasi.

# 1. Memulihkan seluruh namespace dari file backup yang ada
velero restore create \
  --from-backup prod-apps-backup-20260617 \
  --include-namespaces prod-apps

# 2. PENTING: Memulihkan ke Namespace berbeda untuk pengujian (Namespace Mapping)
# Perintah ini memetakan isi namespace 'prod-apps' dari backup ke namespace baru 'prod-restore-test'
velero restore create \
  --from-backup prod-apps-backup-20260617 \
  --namespace-mappings prod-apps:prod-restore-test

# 3. Memantau progres pemulihan objek dan volume disk
velero restore get
velero restore describe <restore-name>

Pencadangan Database Konsisten (Database-Native Dump) #

Meskipun Velero sangat andal untuk mencadangkan disk PV menggunakan snapshot cloud provider, metode snapshot tingkat blok (block-level snapshot) memiliki kelemahan kritis ketika digunakan untuk database relasional aktif.

Jika snapshot diambil tepat saat mesin database sedang melakukan operasi penulisan data besar ke disk (active transactions), data yang tersimpan di dalam snapshot berisiko berada dalam keadaan tidak konsisten (crash inconsistent state). Saat dipulihkan, database bisa mengalami kerusakan tabel atau kehilangan data transaksi yang belum selesai ditulis (dirty writes).

Solusi: CronJob Database-Native Dump #

Untuk menjamin konsistensi data database, kita harus menjalankan proses ekspor data (database dump) menggunakan utilitas resmi mesin database (seperti pg_dump untuk PostgreSQL). Proses ini membaca data langsung dari memori database secara aman dan terstruktur.

Berikut adalah manifest CronJob Kubernetes tingkat produksi untuk mencadangkan database PostgreSQL ke bucket S3 secara aman menggunakan otorisasi IRSA (IAM Roles for Service Accounts) tanpa menyimpan kunci sandi AWS di dalam manifest:

# File: k8s/production-postgres-backup-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: postgres-consistent-backup
  namespace: prod-apps
spec:
  schedule: "0 1 * * *" # Jalankan setiap hari pukul 01:00 WIB dini hari (saat sepi trafik)
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      template:
        spec:
          # Menggunakan ServiceAccount yang terikat ke IAM Role S3 (IRSA)
          serviceAccountName: db-backup-sa 
          restartPolicy: OnFailure
          containers:
          - name: pg-backup-agent
            image: postgres:15-alpine
            command:
            - /bin/sh
            - -c
            - |
              set -e # Hentikan eksekusi jika ada perintah yang gagal
              TIMESTAMP=$(date +%Y%m%d_%H%M%S)
              BACKUP_FILE="db_backup_${TIMESTAMP}.sql.gz"
              
              echo "Memulai proses pg_dump konsisten..."
              # Mengambil dump database secara online tanpa mengunci tabel (non-blocking)
              PGPASSWORD=$DB_PASSWORD pg_dump \
                -h $DB_HOST -U $DB_USER -d $DB_NAME \
                | gzip > /tmp/${BACKUP_FILE}
              
              echo "Proses dump selesai. Mengunduh AWS CLI untuk upload..."
              # Memanfaatkan biner CLI minimal untuk upload
              apk add --no-cache aws-cli
              
              echo "Mengunggah file ke AWS S3 bucket..."
              aws s3 cp /tmp/${BACKUP_FILE} s3://production-db-backups/postgres/${BACKUP_FILE}
              
              echo "Proses upload sukses: ${BACKUP_FILE}"
              
              # ROTASI otomatis: Hapus backup yang berusia lebih dari 7 hari di S3
              echo "Menjalankan rotasi file cadangan lama..."
              aws s3 ls s3://production-db-backups/postgres/ \
                | awk '{print $4}' \
                | sort -r | tail -n +8 \
                | xargs -I {} aws s3 rm s3://production-db-backups/postgres/{}              
            env:
            - name: DB_HOST
              value: "postgres-primary-service"
            - name: DB_NAME
              value: "banking_production"
            - name: DB_USER
              valueFrom:
                secretKeyRef:
                  name: postgres-credentials
                  key: username
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-credentials
                  key: password

Strategi Multi-Cluster Disaster Recovery #

Untuk sistem transaksi keuangan atau e-commerce kritis yang tidak dapat menoleransi kegagalan downtime, mengandalkan satu kluster tunggal di satu wilayah (region) cloud provider adalah kesalahan fatal. Jika wilayah tersebut mengalami bencana alam atau gangguan kabel serat optik bawah laut, seluruh sistem kita akan mati.

Kita harus menerapkan salah satu dari tiga strategi pemulihan multi-kluster berikut berdasarkan kebutuhan bisnis:

flowchart TD
    User["Lalu Lintas Pengguna (HTTP requests)"] --> GlobalDNS["Global DNS / Traffic Manager (Route53 / Cloudflare)"]
    GlobalDNS -->|"Rute Utama (Active)"| ClusterPrimary["Kluster Utama (Region A)"]
    GlobalDNS -. "Pindah Rute Saat Kegagalan (Standby)" .-> ClusterDR["Kluster Bencana (Region B - Standby)"]
    
    subgraph RegionA["Region A (Utama)"]
        ClusterPrimary --> DBPrimary["Database Utama (Primary)"]
    end
    
    subgraph RegionB["Region B (Bencana)"]
        ClusterDR --> DBStandby["Database Replikasi (Replica)"]
    end
    
    DBPrimary -. "Replikasi Data Sinkron/Asinkron" .-> DBStandby
    
    ClusterPrimary -. "Status: Tidak Sehat (API Server Timeout)" .-> GlobalDNS

1. Active-Passive (Failover Standby) #

• Mekanisme: Kluster Utama (Region A) melayani 100% lalu lintas transaksi. Kluster Bencana (Region B) berada dalam kondisi siaga (standby). Seluruh konfigurasi dideploy secara identik di kedua kluster. Data database direplikasi secara asinkron dari Region A ke Region B.
• Failover: Jika Region A down, DNS Global (seperti AWS Route53 atau Cloudflare) mendeteksi kegagalan melalui uji kesehatan (health checks) dan otomatis mengalihkan rute jaringan ke Region B.
• RTO: 5–15 menit (tergantung durasi propagasi DNS dan proses promosi database replika menjadi primary).

2. Active-Active (Multi-Region Active) #

• Mekanisme: Kedua kluster di Region A dan Region B melayani lalu lintas transaksi secara bersamaan (misal 50% / 50% via geographic routing).
• Keuntungan: RTO mendekati 0 detik karena jika satu wilayah mati, lalu lintas langsung dialihkan ke wilayah yang sehat tanpa delay.
• Tantangan: Kompleksitas sinkronisasi database multi-master (data consistency) sangat tinggi dan membutuhkan biaya sewa 2x lipat karena kedua kluster harus beroperasi penuh.

3. GitOps Cluster Recreation (Cold Standby) #

• Mekanisme: Kita tidak menyewa kluster cadangan kedua untuk menghemat biaya.
• Operasional: Ketika terjadi bencana, tim SRE memicu otomatisasi infrastruktur (seperti Terraform) untuk membuat kluster kosong baru dari nol, menginstalnya dengan ArgoCD, menarik seluruh manifest YAML dari Git, lalu merestorasi database dari S3 backup.
• RTO: 30–60 menit. Cocok untuk aplikasi internal non-kritis.

Menyelaraskan Target RTO dan RPO #

Dalam merancang anggaran biaya DR, kita harus menentukan dua metrik kunci berikut bersama pemangku kepentingan (stakeholders):

• Recovery Time Objective (RTO): Batas waktu maksimal durasi pemadaman sistem yang diizinkan sebelum bisnis mengalami kerugian finansial serius. “Berapa lama sistem boleh mati?”
• Recovery Point Objective (RPO): Batas maksimal kehilangan data transaksi yang diukur berdasarkan waktu penulisan terakhir. “Berapa banyak data transaksi yang boleh hilang?”

Berikut adalah tabel pemetaan keselarasan target bisnis terhadap arsitektur teknis yang harus dibangun:

Anti-Pattern dalam Praktik Disaster Recovery #

Hindari dua kesalahan fatal berikut saat merancang skema pemulihan bencana kluster:

1. Mengabaikan Pengujian Restorasi Berkala (Backup Blind Spot) #

Membanggakan jadwal backup harian Velero yang sukses selama berbulan-bulan tanpa pernah mencoba menjalankan proses restorasi ke kluster pengujian.

# JANGAN: Hanya berasumsi backup sukses karena statusnya 'Completed'
$ velero backup get
NAME                    STATUS      ERRORS   WARNINGS
daily-prod-backup-102   Completed   0        0

Risiko Operasional:
- Saat bencana sesungguhnya terjadi, kita mencoba menjalankan restore, namun proses gagal di tengah jalan karena adanya perubahan skema API versi Kubernetes (deprecated APIs) atau kegagalan driver CSI cloud yang tidak kompatibel dengan snapshot volume lama.
- Hasil backup menjadi tidak berguna dan pemulihan gagal dilakukan.
✓ SOLUSI: Jadwalkan latihan bencana (DR Drill) minimal sekali setiap 3 bulan untuk merestorasi data ke namespace isolasi pengujian guna memvalidasi keutuhan data.

2. Menyimpan Kunci Kredensial AWS IAM di Dalam Kluster (Ransomware Target) #

Menyimpan berkas kredensial AWS Access Key ID dan Secret Access Key berbentuk teks polos (plain-text) di dalam objek Secret Kubernetes untuk proses backup database.

# ANTI-PATTERN: Menyimpan kredensial admin AWS di Secret kluster
apiVersion: v1
kind: Secret
metadata:
  name: aws-s3-creds
data:
  aws_access_key_id: "QUtJQVhYWFhYWFhYWFhYWFg=" # JANGAN!
  aws_secret_access_key: "WFhYWFhYWFhYWFhYWFhY..."

Risiko Operasional:
- Jika peretas berhasil mengompromikan satu pod aplikasi dan naik tingkat memperoleh hak akses baca Secret di namespace.
- Peretas mendapatkan kunci AWS IAM tersebut dan menggunakannya untuk menghapus seluruh file cadangan backup di bucket S3, lalu mengenkripsi kluster aktif kita dengan ransomware. Kita kehilangan kluster sekaligus file cadangannya.
✓ SOLUSI: Gunakan otorisasi tanpa kunci berbasis token OIDC (GKE Workload Identity atau EKS IRSA) dan konfigurasikan kebijakan retensi S3 dengan fitur 'Object Lock' (WORM - Write Once, Read Many) agar file backup yang sudah diunggah tidak dapat dihapus oleh siapa pun (termasuk admin) sampai batas waktu retensi habis.

Checklist Audit Disaster Recovery #

Gunakan checklist ini untuk mengaudit tingkat kesiapan pemulihan bencana kluster produksi Anda:

STRATEGI BACKUP & REKONSILIASI DATA:
  □ File manifest YAML kluster tersimpan aman di repositori GitOps (sebagai cadangan metadata kluster).
  □ Jadwal backup otomatis Velero terkonfigurasi secara aktif dengan batas waktu TTL yang jelas.
  □ Database relasional dicadangkan menggunakan utilitas native (pg_dump/mysqldump) secara konsisten (bukan sekadar snapshot blok disk).
  □ File cadangan diunggah ke Object Storage di wilayah (region) yang berbeda dengan wilayah kluster utama.
  □ Fitur S3 Object Lock (WORM) diaktifkan untuk melindungi file cadangan dari serangan Ransomware.

PENGUJIAN RESTORASI (DR DRILLS):
  □ Latihan simulasi restorasi bencana (DR Drill) dilakukan secara rutin minimal setiap 3 bulan.
  □ File cadangan dipulihkan ke namespace pengujian terisolasi untuk memvalidasi keutuhan fungsionalitas aplikasi.
  □ Waktu proses pemulihan (RTO) diukur dan dicatat untuk memastikan kepatuhan terhadap target bisnis.
  □ Runbook pemulihan terdokumentasi dengan langkah-langkah eksplisit yang mudah dipahami oleh engineer *on-call*.

KEAMANAN KREDENSIAL BACKUP:
  □ Velero dan CronJob backup menggunakan otorisasi tanpa kunci (GKE Workload Identity / EKS IRSA).
  □ Izin akses IAM Role untuk biner backup dibatasi hanya pada bucket S3 spesifik (least privilege).
  □ Akses ke port etcd kluster dibatasi ketat menggunakan aturan firewall tingkat sistem operasi.

Ringkasan #

• GitOps adalah Backup Metadata Terbaik — Hindari backup etcd manual yang rumit; simpan seluruh konfigurasi manifest objek secara deklaratif di Git untuk rekonstruksi kluster yang cepat.
• Wajib Jalankan DR Drills — Sadari bahwa backup tanpa uji pemulihan berkala adalah sia-sia; jadwalkan pengujian restorasi ke namespace terisolasi minimal setiap 3 bulan.
• Gunakan Dump untuk Database — Jangan mengandalkan snapshot blok volume untuk database aktif; jalankan dump native secara konsisten via CronJob untuk menghindari korupsi data.
• Gunakan OIDC Tanpa Kunci — Jaga keamanan bucket S3 backup dari serangan ransomware dengan menggunakan Workload Identity atau IRSA sebagai pengganti berkas Secret key permanen.
• Aktifkan S3 Object Lock — Lindungi file backup dari risiko penghapusan paksa dengan mengaktifkan fitur Object Lock (WORM) di bucket penyimpanan cloud Anda.
• Tulis Runbook Eksplisit — Buat dokumen runbook pemulihan yang memuat instruksi langkah-demi-langkah sederhana agar mudah dieksekusi oleh tim on-call saat terjadi insiden darurat.

← Sebelumnya: Cost Optimization   Berikutnya: Multi-Tenancy →