Belajar Velero - Performance & Data Management

#Pendahuluan

Sepanjang seri ini fokus kita: apakah backup benar? Episode 20 menambah pertanyaan kedua yang sama pentingnya: seberapa cepat backup itu? Backup yang memakan waktu 10 jam saat RPO mengharuskan 1 jam bukanlah backup yang memenuhi janji. Dan restore yang lambat saat cluster terbakar adalah definisi kegagalan DR.

Anggap jalur backup sebagai pipa air: kapasitas pipa (paralelisme), tekanan (resource limit), dan titik sambungan (node-agent) semuanya menentukan debit. Episode ini mengajarkan kalian membaca dan memperbesar ketiganya.

#Paralelisme Backup

#Item Operation Parallelism

--item-operation-parallelism (di install) mengontrol berapa banyak resource yang diproses bersamaan dalam satu backup. Nilai defaultnya cukup konservatif; untuk cluster besar, naikkan:

Install dengan paralelisme lebih tinggi

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.14.0 \
  --bucket velero \
  --secret-file ./credentials-velero \
  --backup-location-config region=us-east-1 \
  --item-operation-parallelism 10

Konservatif di sini bukan alasan; ini keseimbangan: paralelisme tinggi mempercepat backup tapi membebani API server dan object storage.

#Parallel Files Upload

Untuk backup file-level kopia, dua parameter menentukan throughput saat membaca data dari volume:

--parallel-files-upload — jumlah file yang di-upload bersamaan.
--parallel-files-download — untuk restore.

Naikkan paralelisme upload file

velero backup create perf-test --include-namespaces app \
  --default-volumes-to-fs-backup --parallel-files-upload 16

Tip

Perhatian khusus Velero 1.18: Velero memakai Golang 1.25 yang menghormati CPU limit pod (Container-aware GOMAXPROCS). Jika kalian menetapkan CPU limit kecil di pod node-agent, throughput akan anjlok tak terduga. Naikkan CPU limit, atau sesuaikan parallel-files-upload dengan limit yang ada — dokumentasi 1.18 secara eksplisit menyebut trade-off ini.

#Resource Limits Pod Velero

#Server Pod

Pod velero harus diberi resource yang cukup untuk memproses backup banyak resource:

Lakukan sizing: mulai dari requests 512m CPU / 512Mi, dan limits 2 CPU / 2Gi — lalu pantau. Pod yang kehabisan memory akan restart di tengah backup (dampak: backup gagal).

#Node-Agent Scaling

DaemonSet node-agent berjalan di setiap node dengan satu pod per node. Beban file-level backup tersebar alami — tapi satu pod bisa menangani banyak volume. Titik bottleneck biasanya bukan jumlah pod, melainkan resource per pod:

Resource node-agent

resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 2
    memory: 2Gi

Skala "secara vertikal" (naikkan resource) lebih umum daripada horizontal — node-agent sudah satu per node. Pantau penggunaan per node untuk tahu mana yang perlu dinaikkan.

#Menganalisis Ukuran Backup

#Membaca Ukuran dari Object Storage

Gunakan client object storage (mc/awscli) untuk melihat ukuran per backup:

Ukuran backup di MinIO

mc du --recursive local/velero/backups/

Data besar hampir selalu berasal dari kopia/restic repositori volume. Melihat pertumbuhan ukuran membantu kalian tahu kapan harus memangkas scope atau menambah retention.

#Memantau Durasi dan Status

Kombinasikan ukuran dengan durasi backup (lihat dari velero backup describe atau metadata CRD) untuk menghitung throughput aktual: ukuran ÷ durasi. Angka ini adalah baseline untuk menetapkan ekspektasi RTO.

#Mengekspor Backup ke Format Lain

#Mengapa Ekspor

Alasan umum: audit (bukti backup ke auditor), migrasi ke sistem lain, atau arsip offline. Backup Velero di object storage bukanlah file yang bisa dibaca manusia begitu saja — namun manifestnya bisa diekstrak.

#Mengakses Manifest

Manifest setiap backup tersimpan sebagai JSON di bucket (<backup>/velero-backup.json dan folder resources/):

Unduh manifest backup

aws s3 cp s3://velero/backups/my-backup/velero-backup.json ./
aws s3 sync s3://velero/backups/my-backup/resources/ ./resources/

JSON manifest bisa dikonversi ke YAML untuk review atau diimpor ulang. Untuk replikasi lengkap backup antar bucket (misal ke bucket arsip di region lain), gunakan sinkronisasi object storage atau cross-region replication — lebih efisien daripada restore-ulang.

Note

Backup file-level (kopia) tidak bisa "dikonversi" ke format lain secara langsung — repositorinya proprietary. Yang portable adalah hasil restore-nya. Jika kalian butuh data keluar dari Velero, restore dulu ke cluster/namespace staging, baru ekspor dari sana.

#Penutup

Inti yang harus dibawa pulang:

--item-operation-parallelism mempercepat pemrosesan resource; naikkan secara bertahap dan pantau beban.
Kopia punya --parallel-files-upload/--parallel-files-download untuk throughput file-level.
Golang 1.25 di Velero 1.18 membuat CPU limit pod memengaruhi throughput — sesuaikan keduanya.
Node-agent skalanya vertikal (resource per pod), bukan horizontal.
Analisis ukuran + durasi memberi baseline throughput; ekspor manifest via object storage untuk audit.

Di episode 21 selanjutnya kita melihat ke depan dan ke komunitas: Roadmap & Community — fokus kopia default, maturity CSI, dukungan multi-versi K8s, serta kanal komunitas: GitHub velero-io/velero, Slack #velero, dan docs velero.io.