Belajar Velero - Restore Workflow & Namespace Mapping

#Pendahuluan

Di episode 5 kita sudah restore ke namespace berbeda dan restore selektif. Episode 10 menaikkan standarnya: menyusun workflow restore yang benar-benar dipakai di produksi — dari restore penuh ke cluster baru, memetakan namespace untuk simulasi, sampai menghadapi kegagalan restore yang paling umum. Ini adalah materi yang kalian buka ulang saat incident.

Ingat analogi arsip: kalian sudah tahu cara mencetak ulang dokumen (episode 5). Sekarang kalian belajar mencetak ulang seluruh ruang arsip ke gedung yang berbeda — lengkap dengan aturan mana rak yang dipindahkan, dan apa yang harus dilakukan saat rak tidak muat di gedung baru.

#Restore Penuh ke Cluster Baru

#Workflow Umum

Ini alur yang dipakai untuk pindah environment atau simulasi disaster:

Cluster baru dengan Velero terinstall dan BSL yang sama menunjuk ke bucket backup lama.
Pastikan plugin yang sama terpasang (misal aws-plugin).
velero backup get di cluster baru — backup lama terlihat.

Lihat backup dari cluster baru

velero backup get
velero backup describe my-backup --details

Restore penuh:

Restore penuh ke cluster baru

velero restore create --from-backup my-backup
velero restore get

Verifikasi:

Verifikasi aplikasi dan data

kubectl get deploy,pvc -A
kubectl exec -n app deploy/nginx -- cat /usr/share/nginx/html/index.html

#Urutan Restore yang Perlu Diketahui

Velero memulihkan resource dalam urutan tertentu: namespace dulu, lalu volume/CSI, lalu workload, lalu Service dan Ingress. Ini bukan kebetulan — Deployment butuh PVC ada sebelum pod dibuat, dan Service butuh selector yang sudah eksis. Velero 1.18 juga menambahkan perbaikan urutan untuk Role/RoleBinding/ClusterRole agar aplikasi berbasis RBAC restore dengan benar.

#Namespace Mapping untuk Test/DR

#produksi → staging

Workflow DR/testing yang paling sering dipakai: membawa data produksi ke environment staging tanpa menyentuh produksi.

Restore produksi ke staging

velero restore create dr-test \
  --from-backup my-backup \
  --namespace-mappings app:app-staging

Semua resource dari namespace app dibuat ulang di app-staging — termasuk PVC baru dengan data yang dipulihkan. Velero otomatis membuat namespace target jika belum ada.

#Beberapa Namespace Sekaligus

Mapping banyak namespace

velero restore create multi-ns \
  --from-backup my-backup \
  --namespace-mappings prod-web:staging-web,prod-api:staging-api

Note

Namespace mapping mengubah namespace saja, bukan nama resource di dalamnya. Deployment bernama nginx tetap bernama nginx di namespace baru. Konflik hanya terjadi jika nama resource sudah ada di namespace target — saat itu restore menandai item sebagai "already exists" dan melewatkannya.

#Troubleshooting Restore Gagal

#Gejala 1: PVC Pending

Restore selesai tapi PVC menggantung di status Pending:

Diagnosis PVC pending

kubectl get pvc -n app-staging
kubectl describe pvc app-data -n app-staging

Penyebab paling umum: storage class tidak ada di cluster target (misal backup dari EKS gp2 di-restore ke cluster yang hanya punya gp3), atau node tidak punya akses ke volume. Cek storage class:

Bandingkan storage class

kubectl get storageclass

#Solusi: storage-class-mappings

Sejak Velero 1.17, kalian bisa memetakan storage class dari backup ke storage class di cluster target:

Mapping storage class saat restore

velero restore create fix-sc \
  --from-backup my-backup \
  --storage-class-mappings gp2:gp3

Backup yang mereferensi storage class gp2 kini direstore memakai gp3. Fitur ini menjawab masalah lintas-cloud dan cross-cluster yang sangat umum — kita pakai lagi di episode 11.

#Gejala 2: Konflik Resource yang Sudah Ada

Namespace target sudah punya resource bernama sama. Velero default melewati resource eksisting. Untuk menimpanya:

Timpa resource eksisting

velero restore create force-restore \
  --from-backup my-backup \
  --namespace-mappings app:app-staging \
  --existing-resource-policy update

--existing-resource-policy update memaksa Velero memperbarui resource yang sudah ada (hati-hati — ini menimpa konfigurasi yang mungkin dimodifikasi orang lain).

#Gejala 3: Secret/ConfigMap tidak direstore

Velero 1.18 menambahkan aturan urutan restore RBAC, tapi satu hal tetap mengejutkan pemula: Secret yang direstore tidak "menghidupkan" Deployment yang sudah ada karena Deployment hanya membaca Secret saat pod dibuat. Solusi paling bersih: restore dalam satu operasi, lalu hapus pod agar Deployment membuat pod baru yang membaca Secret terbaru — atau pakai mekanisme reload (misal restart annotation).

Tip

Pola debugging restore: velero restore describe <name> --details memberi daftar resource yang sukses, dilewati, dan gagal. Langsung ke velero restore logs <name> untuk pesan errornya — biasanya error jelas seperti storageclass.storage.k8s.io "gp2" not found.

#Penutup

Inti yang harus dibawa pulang:

Restore penuh ke cluster baru butuh Velero + plugin + BSL yang sama; backup muncul otomatis.
Velero restore dengan urutan yang benar: namespace → volume → workload → Service/Ingress.
--namespace-mappings prod:staging memetakan restore untuk testing/DR tanpa menyentuh prod.
PVC Pending hampir selalu soal storage class — periksa dengan kubectl get storageclass.
--storage-class-mappings gp2:gp3 (Velero 1.17+) menyelesaikan perbedaan storage class lintas cluster.

Di episode 11 selanjutnya kita pakai semua fondasi ini untuk tujuan paling menarik Velero: migrasi antar cluster — backup di cluster A, restore di cluster B dengan BSL bersama, mengelola perbedaan cloud/storage class, dan validasi di staging sebelum switch over.