Backup & Restore #

Backup adalah asuransi — nilainya terasa hanya ketika dibutuhkan. Di Kubernetes, backup storage punya beberapa lapisan yang perlu dipahami: backup filesystem, backup database, backup cluster state, dan snapshot volume. Strategi yang tepat bergantung pada RPO (Recovery Point Objective) dan RTO (Recovery Time Objective) yang kamu targetkan. Artikel ini membahas cara kerja setiap mekanisme dan bagaimana memilih kombinasi yang tepat.

Mengapa Backup Kubernetes Berbeda #

Backup di lingkungan tradisional:
  → VM snapshot mencakup OS, data, dan konfigurasi sekaligus
  → Restore = kembalikan VM ke kondisi sebelumnya

Backup di Kubernetes lebih terfragmentasi:
  → State cluster (Deployment, Service, ConfigMap) → tersimpan di Etcd
  → Data aplikasi (file, database) → tersimpan di PVC
  → Image container → tersimpan di registry
  → Ketiganya perlu backup dengan strategi yang berbeda

Untuk recovery yang lengkap, kamu butuh backup Etcd (untuk cluster state) dan backup data PVC (untuk data aplikasi) secara terpisah.

Volume Snapshot: Backup Level Storage #

Volume Snapshot adalah fitur Kubernetes (via CSI) yang memungkinkan kamu membuat snapshot dari PVC secara point-in-time.

Komponen yang Diperlukan #

# VolumeSnapshotClass — mendefinisikan cara snapshot dibuat
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-ebs-snapshots
driver: ebs.csi.aws.com
deletionPolicy: Retain           # Retain atau Delete
parameters:
  tagSpecification_1: "key=backup-type,value=ebs-snapshot"

Membuat Snapshot #

# Buat snapshot dari PVC
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: postgres-data-snapshot-20240115
  namespace: production
spec:
  volumeSnapshotClassName: csi-aws-ebs-snapshots
  source:
    persistentVolumeClaimName: data-postgres-0

# Buat snapshot via manifest
kubectl apply -f snapshot.yaml

# Pantau status snapshot
kubectl get volumesnapshot -n production

# Output:
# NAME                              READYTOUSE   SOURCEPVC       AGE
# postgres-data-snapshot-20240115   true         data-postgres-0  2m

Restore dari Snapshot #

# Buat PVC baru dari snapshot
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data-restored
  namespace: production
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: db-storage
  resources:
    requests:
      storage: 50Gi
  dataSource:
    name: postgres-data-snapshot-20240115
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Backup Level Aplikasi: Database Dump #

Untuk database, backup snapshot volume saja tidak selalu cukup — snapshot volume yang diambil saat database sedang menulis data bisa menghasilkan snapshot yang tidak konsisten. Backup level aplikasi memastikan konsistensi:

# CronJob untuk backup PostgreSQL
apiVersion: batch/v1
kind: CronJob
metadata:
  name: postgres-backup
  namespace: production
spec:
  schedule: "0 2 * * *"          # setiap hari jam 02:00
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      activeDeadlineSeconds: 3600
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup
            image: postgres:15
            command:
            - sh
            - -c
            - |
              BACKUP_FILE="backup-$(date +%Y%m%d-%H%M%S).sql.gz"
              pg_dump -h postgres-service \
                      -U $POSTGRES_USER \
                      -d $POSTGRES_DB \
                | gzip > /tmp/$BACKUP_FILE

              # Upload ke S3
              aws s3 cp /tmp/$BACKUP_FILE \
                s3://my-backups/postgres/$BACKUP_FILE

              echo "Backup completed: $BACKUP_FILE"              
            env:
            - name: POSTGRES_USER
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: username
            - name: POSTGRES_DB
              value: "appdb"
            - name: PGPASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password
            - name: AWS_ACCESS_KEY_ID
              valueFrom:
                secretKeyRef:
                  name: aws-backup-secret
                  key: access-key-id
            - name: AWS_SECRET_ACCESS_KEY
              valueFrom:
                secretKeyRef:
                  name: aws-backup-secret
                  key: secret-access-key

Velero: Backup Cluster Lengkap #

Velero adalah tool open-source untuk backup dan restore seluruh cluster Kubernetes — termasuk resource objects (Deployment, Service, PVC) dan data PVC.

# Install Velero dengan backup ke S3
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.7.0 \
  --bucket my-velero-backups \
  --backup-location-config region=ap-southeast-1 \
  --snapshot-location-config region=ap-southeast-1 \
  --secret-file ./credentials-velero

# Buat backup namespace production
velero backup create production-backup-20240115 \
  --include-namespaces production \
  --wait

# Lihat backup yang tersedia
velero backup get

# Output:
# NAME                          STATUS     ERRORS   WARNINGS   CREATED
# production-backup-20240115    Completed  0        0          2024-01-15 02:00:00

# Jadwalkan backup otomatis setiap hari jam 02:00
velero schedule create daily-production \
  --schedule="0 2 * * *" \
  --include-namespaces production \
  --ttl 168h0m0s              # simpan selama 7 hari

Restore dengan Velero #

# Restore namespace production dari backup
velero restore create --from-backup production-backup-20240115

# Restore dengan opsi
velero restore create production-restore-01 \
  --from-backup production-backup-20240115 \
  --include-namespaces production \
  --restore-volumes true

# Pantau status restore
velero restore get
velero restore describe production-restore-01

Backup Etcd #

Etcd menyimpan semua state cluster. Tanpa backup Etcd, kehilangan cluster berarti harus membangun ulang seluruh konfigurasi dari nol (semua Deployment, Service, RBAC, Secret, dll).

# Backup Etcd snapshot (jalankan di control plane node)
ETCDCTL_API=3 etcdctl snapshot save \
  /backup/etcd-$(date +%Y%m%d-%H%M%S).db \
  --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

# Verifikasi snapshot
ETCDCTL_API=3 etcdctl snapshot status \
  /backup/etcd-20240115-020001.db \
  --write-out=table

# Salin snapshot ke storage eksternal
aws s3 cp /backup/etcd-20240115-020001.db \
  s3://my-backups/etcd/etcd-20240115-020001.db

Untuk cluster managed (GKE, EKS, AKS), backup Etcd dikelola cloud provider dan tidak bisa diakses langsung. Fokus backup kamu pada data PVC dan resource manifests. Untuk cluster self-managed, backup Etcd adalah kewajiban absolut — jadwalkan otomatis dan simpan di tempat terpisah dari cluster.

Strategi Backup yang Direkomendasikan #

Lapisan backup yang lengkap:

Lapisan 1: Backup Etcd (untuk cluster state)
  → Otomatis, terjadwal setiap jam untuk production
  → Simpan di cloud storage terpisah dari cluster
  → Retensi: 30 hari

Lapisan 2: Volume Snapshot (untuk snapshot cepat PVC)
  → Otomatis via CronJob atau VolumeSnapshotSchedule
  → Untuk rollback cepat sebelum operasi berisiko
  → Retensi: 7 hari

Lapisan 3: Backup level aplikasi (untuk database)
  → pg_dump/mysqldump/mongodump terjadwal
  → Upload ke S3 atau cloud storage
  → Retensi: 30 hari (daily) + 12 bulan (monthly)

Lapisan 4: Velero backup lengkap (untuk disaster recovery)
  → Backup mingguan seluruh namespace production
  → Simpan di region yang berbeda
  → Retensi: 4 minggu

Ringkasan #

Backup Kubernetes terfragmentasi — Etcd (cluster state), PVC (data aplikasi), dan registry (images) perlu strategi backup yang berbeda.
Volume Snapshot untuk backup PVC cepat — berbasis CSI, point-in-time; restore dengan membuat PVC baru dari snapshot via dataSource.
Backup level aplikasi untuk konsistensi database — pg_dump/mysqldump lebih aman dari snapshot volume untuk database yang sedang aktif menulis.
Velero untuk disaster recovery lengkap — backup resource objects dan PVC sekaligus; cocok untuk pemulihan seluruh namespace atau cluster.
Backup Etcd untuk cluster self-managed — wajib dan terjadwal; managed Kubernetes menangani ini otomatis.
Uji restore secara reguler — backup yang tidak pernah diuji tidak bisa diandalkan; jadwalkan restore drill minimal sekali sebulan di environment non-production.

← Sebelumnya: StatefulSet + PVC Berikutnya: Dynamic Provisioning →