Backup dan Pemulihan Bencana untuk Proxmox dan Kubernetes Kecil

Dalam infrastruktur kecil, satu insiden saja—disk rusak, salah konfigurasi, atau serangan ransomware—bisa menghentikan layanan kritikal: web sekolah, ERP, ataupun portal orang tua. Strategi backup + DR yang disiplin harus sederhana, otomatis, dan teruji. Fokus artikel ini adalah lingkungan kecil berbasis Proxmox VE (VM/LXC) dan Kubernetes (aplikasi kontainer), dengan prinsip 3-2-1: tiga salinan data, dua media berbeda, satu offsite.

Arsitektur & Target RPO/RTO

RPO (Recovery Point Objective) adalah titik waktu pemulihan (berapa banyak data boleh hilang), sementara RTO (Recovery Time Objective) adalah lamanya layanan boleh down. Untuk sekolah/institusi kecil, target realistis:

• RPO: 24 jam untuk sistem non-kritis; 4–8 jam untuk database transaksi (mis. keuangan siswa).
• RTO: 4–24 jam tergantung sistem; sistem publik (website) biasanya RTO lebih ketat.

Arsitektur ringkas yang disarankan:

• Onsite: Proxmox VE host(s) + penyimpanan lokal/NAS (Synology) untuk cadangan cepat.
• Offsite: S3 kompatibel (AWS/MinIO) dan/atau Google Drive via rclone server-side.
• Kubernetes: Velero (objek & PV) ke lokasi S3 yang sama agar terpusat.

Proxmox: Backup VM/LXC dengan PBS/NAS

Prioritas: snapshot-based backup (konsisten & cepat) ke PBS/NAS, dengan retensi & pruning yang wajar.

1) Menambahkan Storage Proxmox Backup Server (PBS)

Jika Anda memiliki PBS (virtual/fisik), tambahkan sebagai storage di Proxmox. Gunakan sidik jari TLS PBS dan akun khusus (mis. backup@pbs).

# Jalankan di Proxmox node (root)
# Ganti parameter sesuai lingkungan Anda
pvesm add pbs pbs1 \
  --server 10.10.150.50 \
  --datastore backups \
  --username 'backup@pbs' \
  --password '<PBS_PASSWORD>' \
  --fingerprint '<PBS_TLS_FINGERPRINT>' \
  --content backup

2) Menjadwalkan Job Backup (Semua VM/LXC atau Selektif)

Gunakan pvesh untuk membuat jadwal vzdump (bisa juga via UI). Contoh: backup harian ke PBS pada pukul 23:30, kompresi ZSTD, mode snapshot.

# Backup harian semua VM/LXC ke storage PBS
pvesh create /cluster/backup \
  --id nightly-pbs \
  --starttime 23:30 \
  --dow mon,tue,wed,thu,fri,sat,sun \
  --storage pbs1 \
  --mode snapshot \
  --compress zstd \
  --all 1

Tip: Retensi/penyapuan versi cadangan sebaiknya diatur di sisi PBS (prune), misal keep-last=7, keep-daily=14, keep-weekly=8, keep-monthly=12.

3) Alternatif NAS (NFS/SMB)

Jika belum ada PBS, gunakan NAS sebagai storage vzdump.

# Contoh NFS
pvesm add nfs nas-backup --server 10.10.150.60 --path /volume1/proxmox-backup --content backup

# Contoh SMB/CIFS (pastikan kredensial memiliki izin tulis)
pvesm add cifs nas-cifs --server 10.10.150.60 --share backup$ \
  --username '<NAS_USER>' --password '<NAS_PASS>' --content backup

4) Backup Ad-Hoc VM/LXC

# Backup satu VM ID 101 ke PBS
vzdump 101 --storage pbs1 --mode snapshot --compress zstd

# Backup satu container LXC ID 202 ke NAS
vzdump 202 --storage nas-backup --mode snapshot --compress zstd

Proxmox: Backup Konfigurasi Node/Cluster

Selain VM/LXC, simpanan konfigurasi Proxmox wajib dicadangkan, khususnya direktori /etc/pve (cluster) dan konfigurasi penting lainnya.

# Jalankan di setiap node Proxmox (root)
# Cadangkan konfigurasi kritikal (tanpa image VM)
BACKUP_DIR=/root/pve-config-backup
mkdir -p "$BACKUP_DIR"

tar --warning=no-file-changed -czf "$BACKUP_DIR/etc-pve-$(date +%F).tar.gz" /etc/pve
tar -czf "$BACKUP_DIR/etc-network-$(date +%F).tar.gz" /etc/network
cp /etc/hosts "$BACKUP_DIR/hosts-$(date +%F)"
cp /etc/resolv.conf "$BACKUP_DIR/resolv-$(date +%F).conf"

# Opsional: unggah arsip konfigurasi ke NAS/PBS/s3 (lihat bagian rclone)

Offsite: Enkripsi & Sinkronisasi ke S3/Drive

Salinan offsite menyelamatkan dari skenario bencana lokal (banjir, kebakaran, pencurian). Gunakan rclone dengan remote terenkripsi.

1) Menyiapkan Rclone (Enkripsi + S3/Drive)

# Konfigurasi interaktif
rclone config

# Buat remote S3 (mis. "s3school") dan tentukan akses-key/secret-key (placeholder)
# Buat lapisan "crypt" di atas S3 agar cadangan terenkripsi di sisi server:
# Remote: "s3school-crypt" menunjuk ke s3school:bucket-name/path

2) Skrip Sinkronisasi Offsite Berkala

# Jalankan di PBS/NAS (cron)
#!/usr/bin/env bash
set -euo pipefail

SRC="/mnt/datastore/backups"                    # ganti sesuai direktori PBS/NAS
DEST="s3school-crypt:proxmox-backups"           # remote terenkripsi
LOG="/var/log/rclone-proxmox-offsite.log"

# Eksklusi file sementara
rclone sync "$SRC" "$DEST" \
  --log-file "$LOG" --log-level INFO \
  --progress --transfers 8 --checkers 16 \
  --exclude "*.tmp" --exclude "lost+found/**"

# Opsional: kirim notifikasi sederhana
echo "[$(date)] Rclone sync selesai" | mail -s "Offsite Backup OK" admin@example.org

Catatan keamanan: simpan kredensial rclone di file rclone.conf yang izinnya dibatasi (chmod 600). Jangan menaruh kunci di skrip.

Kubernetes: Backup dengan Velero

Velero mencadangkan objek Kubernetes (deployment, service, CRD) dan PersistentVolume (melalui volume snapshot atau restic). Untuk lingkungan kecil, penyimpanan S3 kompatibel (MinIO/AWS) sangat praktis.

1) Instalasi Velero (S3/MinIO/AWS)

# Siapkan kredensial S3 di berkas: credentials-velero
[default]
aws_access_key_id=<S3_ACCESS_KEY>
aws_secret_access_key=<S3_SECRET_KEY>

# Instal via CLI (sesuaikan URL endpoint dan region)
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.2 \
  --bucket <NAMA_BUCKET> \
  --backup-location-config region=<REGION>,s3ForcePathStyle=true,s3Url=http://minio.minio.svc.cluster.local:9000 \
  --secret-file ./credentials-velero \
  --use-restic

Jika memakai MinIO eksternal, ganti s3Url ke alamat MinIO Anda. Opsi --use-restic mengaktifkan cadangan berbasis file-level untuk PV yang tidak mendukung snapshot CSI.

2) Jadwal Backup Otomatis per Namespace

# Backup harian semua namespace penting (contoh: apps-prod, apps-dev)
velero create schedule daily-k8s \
  --schedule "0 22 * * *" \
  --ttl 168h \
  --include-namespaces apps-prod,apps-dev

# Backup hanya label tertentu
velero create schedule daily-labeled \
  --schedule "30 22 * * *" \
  --selector "backup=enabled" \
  --ttl 168h

3) Backup Ad-Hoc & Restore

# Backup ad-hoc satu namespace
velero backup create onetime-prod --include-namespaces apps-prod --ttl 168h

# Lihat daftar backup
velero backup get

# Restore seluruh backup
velero restore create --from-backup onetime-prod

# Restore selektif berdasarkan label
velero restore create restore-ops --from-backup daily-k8s-2025-11-10 --selector app=erp

Kubernetes: etcd Snapshot untuk Control Plane

Selain Velero, cadangan etcd wajib untuk control plane yang dikelola sendiri (kubeadm). Simpan rahasia CA/kubeconfig bersama snapshot.

# Jalankan di control-plane (root)
export ETCDCTL_API=3
ETCDCTL_ENDPOINTS=https://127.0.0.1:2379
ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
ETCDCTL_CERT=/etc/kubernetes/pki/etcd/server.crt
ETCDCTL_KEY=/etc/kubernetes/pki/etcd/server.key

SNAP=/var/backups/etcd-snap-$(date +%F-%H%M).db
etcdctl --endpoints=$ETCDCTL_ENDPOINTS \
  --cacert=$ETCDCTL_CACERT --cert=$ETCDCTL_CERT --key=$ETCDCTL_KEY \
  snapshot save "$SNAP"

# Verifikasi
etcdctl snapshot status "$SNAP"

Restore ke node baru melibatkan etcdctl snapshot restore, lalu menyesuaikan --initial-cluster dan file kubeadm/static pod. Uji ini di lingkungan lab sebelum kejadian nyata.

Skenario Restore yang Wajib Diuji

1. Restore satu VM/LXC dari PBS ke host yang sama (uji cepat RTO).
2. Restore penuh VM ke host berbeda (simulasi host failure).
3. Restore Kubernetes sebagian (satu aplikasi/namespace) dan penuh (semua namespace penting) dari Velero.
4. Recovery control plane dari etcd snapshot ke node baru.
5. Restore database (MariaDB/Postgres) dari dump ke VM baru—uji konsistensi aplikasi.

Catat durasi aktual (RTO) dan waktu kehilangan data (RPO) setiap skenario, lalu tuning jadwal dan media backup berdasar hasil.

Matriks Perbandingan Opsi & Komponen

Checklist Operasional & Kepatuhan

• Kebijakan 3-2-1: minimal satu salinan offsite, media berbeda.
• Jadwal: VM/LXC harian, database transaksi 4–8 jam (dump logical), Velero harian.
• Retensi: harian 7–14, mingguan 4–8, bulanan 6–12 (sesuaikan kapasitas).
• Uji-restore: fire-drill bulanan (satu VM + satu aplikasi K8s) dan triwulan (skala penuh lab).
• Imutabilitas: gunakan bucket/object lock bila tersedia; minimal izin tulis dibatasi.
• Keamanan: enkripsi rclone, akses berbasis peran (PBS/NAS/S3), air-gap admin.
• Dokumentasi: SOP backup/restore, runbook DR, dan kontak darurat.

Troubleshooting Singkat

• Backup lambat ke NAS → cek MTU/jumbo frame, IOPS NAS, atau migrasi ke PBS.
• Velero gagal unggah → periksa credentials, s3Url, DNS/Firewall cluster.
• Rclone time out → tambah --transfers/--checkers wajar; stabilkan koneksi.
• Snapshot LXC gagal → pastikan filesystem & guest agent bila perlu; gunakan stop mode sebagai alternatif.

Kesimpulan

Strategi cadangan yang sukses itu terukur dan teruji. Dengan PBS/NAS untuk VM/LXC, rclone terenkripsi untuk offsite, Velero untuk beban kerja Kubernetes, serta etcd snapshot bagi control plane, Anda memiliki fondasi DR yang kokoh. Pastikan jadwal realistis, retensi selaras kapasitas, dan yang terpenting: lakukan uji-restore berkala sehingga saat bencana datang, pemulihan tinggal mengikuti runbook.

Sumber/Referensi

• Proxmox VE — Backup and Restore
• Proxmox Backup Server — Documentation
• Velero — Documentation
• etcd — Documentation
• rclone — Documentation