Belajar Kubernetes Distributed Storage - Backup & DR Scope (Velero + Ceph)

#Pendahuluan

GitOps telah menjaga konfigurasi (episode 23). Episode 24 membahas sisi data: backup dan DR scope — memastikan seluruh isi storage bisa dipulihkan saat terjadi bencana, dengan RPO/RTO yang jujur.

Mengapa penting? Storage yang hebat (Ceph) tetap bisa kehilangan data jika tidak ada backup di luar cluster: human error menghapus PVC, cluster tidak sengaja di-destroy, bencana korupsi pool. Velero + backup file + verifikasi = jaring pengaman terakhir.

#Menetapkan RPO/RTO

#Mulai dari Pertanyaan Bisnis

RPO (Recovery Point Objective): seberapa banyak data boleh hilang? 5 menit? 1 jam? 24 jam?
RTO (Recovery Time Objective): seberapa cepat sistem harus pulih? 15 menit? 2 jam?

#Kategori Data Kita

Data	Kategori	Strategi
PostgreSQL (DB)	Transaksional, kritis	PITR atau backup terencana + RBD snapshots
Media aplikasi (CephFS)	Penting, berubah	Velero file backup (Restic/Kopia), jadwal harian
Object (RGW)	Besar, arsip	RGW lifecycle / sync ke storage lain

#Jangan Klaim yang Tidak Diukur

RPO "0 menit" membutuhkan teknik tertentu (stretch, episode 21). RPO realistis untuk backup file: interval jadwal (mis. 6 jam). Verifikasi bukan hanya mengatur — uji restore menguji klaim.

#Velero

#Komponen

Backup konfigurasi/workload (K8s objects).
Plugin file (Restic/Kopia) backup volume data aplikasi (media di CephFS).

#Instalasi

Instal Velero dengan plugin Restic

velero install \
  --provider aws \
  --bucket velero-backups \
  --secret-file ./credentials \
  --backup-location-config region=us-east-1,s3ForcePathStyle=true,s3Url=https://rook-ceph-rgw.my-storage:8080 \
  --use-volume-snapshots=false \
  --use-restic

Catatan: file media bisa di-backup ke object store (RGW) — Velero menyimpan blobs di bucket.

#Contoh Backup

Backup namespace Laravel

velero backup create laravel-backup \
  --include-namespaces laravel \
  --include-resources pvc,deploy,configmap,secret,service,ingress

#Restore

Restore ke namespace baru

velero restore create --from-backup laravel-backup \
  --namespace-mappings laravel:laravel-restored

#Backup Database (PostgreSQL)

#Mengapa Tidak "Sleek Enough" Velero Saja

Backup blok (RBD snapshot/velero volume snapshot) untuk DB transaksional bisa membuat data tidak konsisten jika file didapat saat WAL sedang ditulis. Strategi yang benar:

PITR (Point-In-Time Recovery): pg_basebackup + WAL archive.
Atau wal-g / pgBackRest mem-backup ke object storage (RGW).
Atau label snapshot sebelum aplikasi quiesce (short but consistent pause).

#Contoh pgBackRest di Pod

plaintext

# crontab di pod postgres
pgbackrest --stanza=main backup --type=incr

Konfigurasi: repo path = RGW S3 (endpoint) — hasilnya ada di bucket, bukan hanya di disk node.

#Strategi Backup Media (CephFS)

#Velero Restic untuk CephFS RWX

Untuk file media (uploads, galeri):

yaml

---
apiVersion: velero.io/v1
kind: Backup
metadata:
  name: laravel-media
spec:
  includedNamespaces: [laravel]
  includedResources: [PersistentVolumeClaim]

environment Restic aktif di node — file dibaca & di-copy ke bucket setiap jadwal.

#Target Backup Terpisah?

Ide bagus: simpan backup file di klaster lain/RGW berbeda — jangan backup di klaster yang sama (data backup ikut hilang saat bencana).

#Verifikasi Restore

#Kalendera Test Restore

Jadwal restore test tiap 30-90 hari.
Restore ke namespace/klaster terpisah.
Validasi: data aplikasi, file media, kredensial.

#Contoh Cek

Validasi hasil restore

kubectl -n laravel-restored get pvc
kubectl -n laravel-restored exec deploy/laravel -- ls -la storage/app

Melebihi sekadar "file ada" — jalankan aplikasi & verifikasi login/upload.

Warning

Backup yang tidak pernah di-restore adalah berkas yang belum terbukti. Kegagalan tersembunyi (corrupt blob, wrong S3 endpoint, expired credentials) baru terungkap saat krisis — di saat mustahil untuk menyalahkannya. Uji restore adalah bagian SOP, bukan pilihan.

#Penutup

Inti yang harus dibawa pulang:

Definisikan RPO/RTO dengan jujur sesuai jenis data (DB vs media vs object).
Velero: backup K8s objects + file (Restic/Kopia) ke RGW S3 sebagai target.
DB transaksional: PITR/WAL archive (pgBackRest) — bukan sekadar snapshot blok.
Backup media CephFS tiap jadwal; simpan target di klaster/lokasi terpisah.
Uji restore berkala — verifikasi bukan sekadar keberadaan.

Di episode 25 selanjutnya kita akan membahas troubleshooting & common issues — PG stuck, OSD crashing, network latency, dan problem khas lain beserta langkah diagnosis. Sampai jumpa di episode 25!