Belajar Velero - Sejarah, Latar Belakang & Mengapa Membutuhkannya

#Pendahuluan

Environment sudah siap di episode 0. Sekarang waktunya memahami mengapa Velero ada. Setiap teknologi besar lahir karena masalah nyata, dan Velero lahir dari masalah yang sangat spesifik: menyimpan dan memulihkan data di Kubernetes tidak semudah menyimpan file. Di episode 1 kita menelusuri sejarahnya dari Heptio, evolusinya menjadi proyek CNCF, dan alasan konkret mengapa tool ini dibutuhkan di workload Kubernetes modern.

Pertanyaan yang akan kita jawab: mengapa Kubernetes sendiri tidak punya fitur backup? Apa yang membuat backup K8s berbeda dari backup VM biasa? Dan mengapa Velero akhirnya menjadi solusi standar? Jawaban-jawaban ini penting karena menentukan kapan kalian harus memakai Velero — dan kapan tidak.

#Sejarah dan Latar Belakang

#Lahir dari Heptio

Velero dikembangkan pertama kali oleh Heptio — perusahaan yang didirikan Craig McLuckie dan Joe Beda, dua mantan engineer Google yang juga pendiri Kubernetes. Awalnya bernama Ark, kemudian di-rename menjadi Velero (dari "velero" bahasa Italia/Spanish untuk "layar kapal" — metafora yang pas untuk perjalanan dan pemulihan). Heptio diakuisisi VMware pada 2018, dan kini Velero dirawat di bawah naungan VMware/Broadcom, tetapi tetap open source.

Sejak awal, filosofi Velero jelas: backup harus portable. Bukan tool yang terkunci ke satu vendor, melainkan solusi yang bisa mem-backup cluster mana pun dan menyimpan data ke object storage mana pun.

#Menjadi Proyek CNCF

Velero diterima sebagai proyek CNCF (Cloud Native Computing Foundation) dan saat ini berstatus proyek sandbox di ekosistem CNCF. Apa artinya ini bagi kalian? Beberapa hal:

• Governance terbuka: roadmap dan arah pengembangan diputuskan bersama komunitas, bukan satu vendor.
• Ekosistem plugin: banyak penyedia (AWS, Azure, GCP, OpenStack) dan vendor pihak ketiga membangun plugin resmi.
• Jaminan jangka panjang: proyek CNCF kecil kemungkinannya hilang begitu saja dibanding tool proprietary.

#Solusi Standar BaaS untuk Kubernetes

Dari sana Velero tumbuh menjadi solusi standar backup-as-a-service (BaaS) untuk Kubernetes. Nama "Velero" sekarang sering dipakai sebagai kata generik untuk "backup K8s", mirip "Kleenex" untuk tisu. Posisi ini tidak datang dari pemasaran, melainkan dari desain arsitektur yang tepat sasaran — sesuatu yang kita bedah di episode 2.

#Mengapa Membutuhkan Velero

#Kubernetes Tidak Punya Backup Bawaan

Ini titik paling penting: etcd snapshot bukan backup workload. Menyimpan snapshot etcd (database state cluster) memang memulihkan "konfigurasi" cluster, tetapi tidak memulihkan data volume yang disimpan di luar etcd. Dan backup manual dengan kubectl get -o yaml hanya mengambil manifest — data di PVC dan state aplikasi tidak ikut.

Bayangkan kalian mem-backup isi lemari arsip (etc = daftar isi) tapi lupa membawa isi dokumennya (volume = file aktual). Restore dari dua hal itu adalah dua operasi yang sama sekali berbeda — dan keduanya dibutuhkan.

#Backup Resource API + Volume

Velero menggabungkan keduanya dalam satu alur. Satu operasi backup menghasilkan:

• Manifest resource: Deployment, Service, ConfigMap, Secret, PVC, CRD — semua sebagai YAML/JSON.
• Data volume: isi persistent volume lewat snapshot cloud (EBS/GCP PD/Azure Disk) atau file-level backup memakai restic/kopia.

Dua lapis ini membuat restore bisa selektif: mau pulihkan aplikasi lengkap, hanya manifest, atau hanya data volume tertentu.

#Restore Selektif dan Migrasi Antar Cluster

Velero tidak hanya "backup semua". Kalian bisa restore sebagian — per namespace, per resource, atau per label — dan bahkan memetakan namespace (misalnya prod → staging). Ini membuka kemampuan kedua yang paling kuat: migrasi antar cluster. Backup di cluster A, restore di cluster B, tanpa vendor lock-in — selama kedua cluster memakai BSL yang sama.

#Scheduling dan Disaster Recovery

Velero mendukung schedule (backup terjadwal dengan TTL otomatis), sehingga kalian bisa membangun disaster recovery plan dengan RPO/RTO terukur: backup off-site ke object storage, DR drill berkala, dan runbook restore yang bisa dieksekusi dalam hitungan menit.

#Posisi di Ekosistem Backup K8s

Untuk memposisikan Velero, ingatlah spektrum alat backup Kubernetes:

• Velero: general-purpose, open source, backup resource + volume, migrasi lintas cluster.
• Kasten K10 (Veeam): enterprise, UI dan policy lengkap di atas fondasi mirip Velero.
• Stash (AppsCode): backup berbasis script (restic) per workload.
• CloudNativePG/PGO: backup spesifik untuk PostgreSQL di dalam Kubernetes.
• etcd snapshot: backup state cluster, bukan workload.

Kami bandingkan detailnya di episode 22. Yang perlu kalian ingat sekarang: Velero adalah titik masuk yang tepat karena open source, matang, dan menutupi kebutuhan backup general.

#Penutup

Inti yang harus dibawa pulang:

• Velero lahir dari Heptio (awalnya bernama Ark), kini di bawah VMware/Broadcom tetapi tetap open source.
• Proyek CNCF (sandbox) dengan governance terbuka dan ekosistem plugin yang kaya.
• Kubernetes tidak punya backup bawaan: etcd snapshot bukan backup workload, dan manifest tanpa data volume tidak lengkap.
• Velero menggabungkan backup resource API + volume (cloud snapshot atau restic/kopia) dalam satu alur.
• Restore selektif, namespace mapping, migrasi antar cluster, scheduling, dan DR tanpa vendor lock-in.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Velero — bagaimana velero server berjalan sebagai deployment di cluster, peran velero CLI, serta fungsi CRD BackupStorageLocation (BSL) dan VolumeSnapshotLocation (VSL) yang menjadi tulang punggung seluruh seri ini.