Belajar Proxmox Backup Server - Scale: Banyak Datastore & Sync Architecture

#Pendahuluan

Episode 17 memperkenalkan PBS 4.2 dan S3 object storage. Sekarang pertanyaannya berubah: bagaimana kalau kalian mengelola bukan satu PBS, tapi selusin PBS untuk puluhan client? Episode 18 membahas penskalaan — banyak datastore per server, namespace dan backup group untuk mengorganisasi client, arsitektur hub-spoke lewat remote sync, serta capacity planning sebelum hardware dibeli.

Analoginya seperti memperluas satu kantor menjadi perusahaan multi-cabang: tiap cabang (site) punya gudang arsipnya sendiri, satu gudang pusat menerima salinan semuanya, dan sebelum membangun gedung baru kalian menghitung berapa rak yang dibutuhkan dan berapa truk yang harus lewat per hari.

#Skala dengan Banyak Datastore

#Satu Server, Banyak Datastore

Satu PBS bukan berarti satu datastore. Datastore adalah unit logis yang bisa dibuat banyak dalam satu server, masing-masing dengan path, jadwal GC, jadwal verify, retention, dan ACL sendiri:

Isolasi tenant/departemen: tim A dan tim B tidak saling melihat atau mengganggu jadwal satu sama lain.
Kebijakan berbeda per workload: datastore store-prod keep 30 hari, store-archive keep 1 tahun.
Backend berbeda: store1 di ZFS lokal, store-s3 di object storage (episode 17 & 19).

Buat datastore kedua di server yang sama

proxmox-backup-manager datastore create store-prod \
  --path /mnt/zfs/store-prod \
  --gc-schedule "sun 02:00" \
  --verify-new
proxmox-backup-manager datastore list

#Namespace: Folder Logis di Dalam Datastore

Sejak PBS 3.x, datastore bisa dibagi lagi menjadi namespace — folder logis untuk memisahkan client tanpa harus membuat datastore fisik baru. Namespace sangat berguna untuk skenario SaaS/MSP: satu datastore besar di-share, tiap tenant memakai namespace sendiri dengan ACL dan sync tersendiri.

Buat dan daftar namespace

proxmox-backup-manager namespace create store-prod tenant-a
proxmox-backup-manager namespace create store-prod tenant-b
proxmox-backup-manager namespace list store-prod

Setiap snapshot di PBS sebenarnya milik satu backup group yang diidentifikasi type/id (misal vm/100, ct/200, host/web-01). Kombinasi datastore + namespace + backup group inilah yang menjadi "alamat" lengkap sebuah backup — dan dasar dari pengelompokan client.

#Group Client & Organisasi

Pola yang sehat: satu namespace (atau datastore) per kelompok client, dengan konvensi penamaan yang konsisten.

Backup job di PVE mengirim vm/... ke datastore yang ditentukan (episode 4); pilih datastore yang tepat per job.
Client host memakai proxmox-backup-client dengan --backup-type/--backup-id eksplisit (episode 11) sehingga mudah dipetakan ke namespace.
ACL per namespace (episode 12): user ops@pbs untuk namespace tenant-a, dan hak akses tenant-b hanya untuk tim masing-masing.

Tip

Mulailah dari satu datastore per kelompok logis, lalu gunakan namespace saat datastore itu terasa besar dan campur aduk. Namespace menambah fleksibilitas tanpa menambah titik mount baru — tetapi buat aturan penamaan tertulis, karena namespace tanpa konvensi cepat menjadi "folder sampah" baru.

#Arsitektur Hub-Spoke

#Konsep Hub-Spoke

Saat jumlah site bertambah, pola off-site episode 10 berkembang menjadi hub-spoke: tiap site punya PBS lokal (spoke) untuk backup cepat di tempat, dan satu PBS pusat (hub) menarik salinan snapshot dari semua spoke melalui sync job. Sync tetap model pull (episode 10): hub yang mengautentikasi ke spoke, bukan sebaliknya.

Keuntungannya: restore cepat dari PBS lokal untuk kebutuhan harian, sementara hub menjadi garansi off-site terpusat yang kelak bisa direplikasi ke S3 (episode 19) tanpa membuka jalur akses ke setiap site.

#Praktik Hub-Spoke

Di setiap spoke, siapkan user + API token sync dengan hak baca datastore/namespace yang akan ditarik (episode 10). Di hub, buat satu sync job per spoke:

Sync job hub untuk spoke site-a

proxmox-backup-manager sync job create \
  --remote site-a.example.com \
  --remote-user sync@pbs \
  --remote-auth token \
  --remote-datastore store1 \
  --datastore hub-site-a \
  --schedule "daily 03:00" \
  --keep-last 7 --keep-daily 14 --keep-monthly 6 \
  --remove-vanished

Data mengalir spoke → hub; retention --keep-* di hub membatasi pertumbuhan, dan --remove-vanished menjaga sinkronisasi penghapusan. Snapshot di spoke dan hub adalah dua salinan dari data yang sama — persis lapisan kedua strategi 3-2-1 (episode 10).

#Rate Limit & Schedule

WAN antar-site biasanya lebih sempit daripada LAN. Sync job PBS mendukung rate limiting dan worker threads agar sync tidak memakan seluruh bandwidth kantor:

Sync dengan rate limit dan worker

proxmox-backup-manager sync job create \
  --remote site-a.example.com \
  --remote-user sync@pbs --remote-auth token \
  --remote-datastore store1 --datastore hub-site-a \
  --schedule "daily 02:00" \
  --rate-in 50M --burst-in 100M \
  --worker-threads 2

--rate-in membatasi kecepatan unduh (data masuk ke hub), --burst-in memberi lonjakan sementara.
--worker-threads (default 1) mempercepat transfer chunk paralel saat bandwidth tersedia.

Jadwalkan sync di luar jam backup lokal, dan pisahkan dari window verify/GC (episode 6 & 9).

#Capacity Planning

#Menghitung Dedup Ratio & Kebutuhan Disk

Metrik episode 6 (Size/Original/Dedup/Compressed) bukan sekadar laporan — ia bahan dasar sizing. Kebutuhan disk kira-kira:

Contoh: 10 VM × 100 GiB = 1 TiB data original. Dengan dedup 8x dan kompresi zstd 2x: 1 TiB / 8 / 2 = 64 GiB chunk unik — plus overhead metadata dan headroom. Kuncinya: ukur rasio dari datastore yang sudah berjalan (episode 6) sebelum membeli disk baru, jangan menebak.

#Bandwidth & Jaringan 10G

Backup harian harus selesai dalam window yang ditetapkan. Hitung kebutuhannya:

Backup pertama bersifat penuh (semua data); backup berikutnya hanya delta (chunk baru).
Contoh: delta harian 2 TiB dalam window 4 jam → butuh 2 TiB / 4 jam ≈ 1,2 Gbps terus-menerus — di luar jangkauan nyaman 1G.

Itulah kenapa 10G disarankan untuk jalur PVE → PBS dan PBS → hub: memberi ruang untuk spike tanpa memperpanjang window. Gunakan jumbo frames dan proxmox-backup-client benchmark (episode 20) untuk mengukur capaian nyata TLS + zstd sebelum menetapkan window.

#Disk Sizing

Untuk datastore ZFS lokal:

recordsize 1M (episode 15) untuk efisiensi chunk 4 MiB.
raidz2 / mirror untuk redundansi — backup di satu disk saja bukan backup.
Sisakan 20-30% headroom: GC butuh ruang selama fase mark/sweep (episode 6), dan disk 100% adalah sumber utama kegagalan backup.
Pantau df -h dan proyeksi pertumbuhan bulanan; beli sebelum penuh, bukan sesudah.

Warning

Jangan menghitung kapasitas hanya dari ukuran snapshot "asli". Chunk yang di-dedup dan di-compress memakai jauh lebih sedikit — tetapi index, metadata, dan fase GC juga makan ruang. Hitung dua angka: kebutuhan teoretis (rumus di atas) dan kecepatan pertumbuhan bulanan dari datastore nyata. Yang kedua lebih bisa dipercaya.

#Penutup

Inti yang harus dibawa pulang:

Satu PBS bisa punya banyak datastore: isolasi tenant, kebijakan, dan backend dalam satu server.
Namespace (PBS 3.x+) mengorganisasi client tanpa membuat datastore baru; backup group type/id menjadi alamat lengkap snapshot.
Hub-spoke: PBS lokal per site + satu hub pusat yang menarik salinan via sync (pull), dengan rate limit dan worker threads.
Sizing disk ≈ Original / dedup ratio / compression ratio, plus overhead dan headroom 20-30%.
Bandwidth: hitung window vs delta harian; 10G memberi ruang aman untuk jalur backup.
Ukur rasio nyata dari datastore berjalan — jangan menebak.

Di episode 19 selanjutnya kita akan menyambungkan PBS ke ekosistem luar: menjadikan filesystem datastore PBS sebagai target NFS/SMB bagi agen backup lain (Veeam, Bacula) dan menggunakan S3 object storage PBS 4.x sebagai tujuan off-site di cloud. Infrastruktur kalian tidak lagi berdiri sendiri!