Belajar Proxmox Backup Server - Integrasi Ekosistem: Veeam, Bacula & Cloud

#Pendahuluan

Arsitektur hub-spoke episode 18 menangani PBS-to-PBS. Tapi ekosistem backup lebih luas dari itu: kalian mungkin masih punya server fisik non-Proxmox, atau suite backup komersial, yang butuh tujuan penyimpanan di tempat yang sama. Episode 19 menjembatani PBS ke ekosistem lain: PBS sebagai target NFS/SMB untuk Veeam dan Bacula, plus S3 object storage PBS 4.x untuk off-site di cloud.

Analoginya seperti gudang arsip pusat yang melayani banyak kurir: PBS tetap mengelola rak-raknya sendiri dengan format chunk-nya, tapi menyediakan pintu masuk standar (NFS/SMB) agar kurir lain — Veeam, Bacula — bisa menitipkan kotak arsipnya sendiri di gudang yang sama.

#PBS Sebagai Target Backup Agent Lain

#Konsep: Pintu NFS/SMB di Sisi Datastore

PBS menyimpan backup VM/CT dalam format chunk-nya sendiri — data itu tidak bisa dibaca Veeam/Bacula secara langsung. Yang bisa di-share adalah filesystem tempat datastore berada. Pola yang benar:

1. Export direktori tersendiri (bukan direktori chunk datastore PBS) via NFS/SMB.
2. Veeam/Bacula menggunakannya sebagai repository file biasa.
3. PBS dan agen lain berbagi kapasitas disk yang sama, tanpa saling memahami format.

Praktik ini memusatkan storage di satu tempat: PBS menangani VM/CT Proxmox secara native, Veeam/Bacula menangani workload lain, keduanya menulis di mesin yang sama.

#Export NFS di Atas ZFS

Jika datastore PBS berada di pool ZFS, ekspor paling mudah lewat sharenfs:

zfs set sharenfs="on" zpool-pbs/shared
zfs list -r zpool-pbs -o name,mountpoint,sharenfs

Cek akses dari client (misal gateway server Veeam) dengan mount biasa:

mkdir -p /mnt/pbs-shared
mount -t nfs 10.0.1.5:/zpool-pbs/shared /mnt/pbs-shared

Untuk SMB, install Samba di PBS dan ekspor direktori yang sama. Catatan performa dari episode 15: path NFS/SMB punya latency lebih tinggi daripada disk lokal — ukur throughput dulu sebelum menetapkan share sebagai target repository.

#Veeam: Repository NFS/SMB

Veeam Backup & Replication mendukung NFS share dan CIFS/SMB share sebagai backup repository. Di sisi Veeam:

• NFS share memerlukan gateway server (Windows atau Linux) dengan package NFS client — gateway inilah "jembatan" antara Veeam dan share.
• Repository berbasis Linux di Veeam mendukung hardened repository (immutable) — kombinasi yang kuat dengan konsep anti-ransomware episode 14.
• Untuk lingkungan Proxmox, Veeam juga menyediakan Veeam Plug-in for Proxmox VE — integrasi resmi yang menjadikan PVE sebagai workload yang didukung.

Keuntungan memakai PBS sebagai tuan rumah share: satu mesin, satu pemeliharaan, satu sumber daya — PBS dan Veeam hidup berdampingan tanpa server tambahan.

#Bacula: File Storage di Atas NFS

Bacula (suite enterprise berbasis arsitektur director/storage) menulis backup ke File storage:

1. Bacula Storage Daemon (SD) mengarahkan direktori storage ke mount NFS tadi.
2. Blok Storage { Device = PBS-Shared } di konfigurasi Bacula menunjuk ke path tersebut.
3. Volume Bacula tersimpan di share, sementara PBS mengelola VM/CT-nya sendiri.

Pola yang sama berlaku untuk Bacula Community maupun Enterprise (tipe File/autochanger). Konfigurasi Bacula tidak berubah — hanya lokasi file-nya yang kini berada di mesin PBS.

#Cloud: S3 Object Storage Off-site

#Datastore S3 di PBS 4.x

Episode 17 memperkenalkan fitur headline PBS 4.2: datastore di atas S3-compatible object storage. Ini mengubah cara off-site: alih-alih PBS kedua yang harus dirawat (episode 10), tujuan cloud bisa berupa bucket object storage.

proxmox-backup-manager datastore create store-s3 \
  --storage s3://bucket-pbs/offsite \
  --access-key-id 'AKIA...' \
  --secret-key '...'

Chunk, dedup, dan snapshot bekerja identik dengan datastore lokal — PBS hanya menulis ke "kertas" yang berbeda. Jadwal verify dan GC tetap berlaku.

#Arsitektur: Lokal → S3

Pola yang paling masuk akal: backup lokal cepat, S3 sebagai lapisan off-site:

Lokal cepat + cloud off-site

[PVE cluster] ──backup──> [PBS lokal: ZFS]
                              │  sync harian
                              ▼
                       [Datastore S3: cloud]

Kombinasi ini menghindari dua masalah sekaligus: latency S3 (tidak cocok untuk backup harian langsung) dan beban merawat PBS kedua. Sync ke S3 menciptakan salinan off-site otomatis — lapisan "1" dari strategi 3-2-1 (episode 10).

#Object Lock & Enkripsi

Dua lapisan keamanan yang bisa digabung:

• S3 Object Lock (mode compliance/governance): object di bucket tidak bisa dihapus/timpa selama periode yang ditentukan — bentuk immutable anti-ransomware untuk cloud (episode 14).
• Enkripsi client-side (episode 7): jika backup asli dienkripsi, ciphertext yang disinkronkan ke S3 tetap tidak terbaca oleh siapa pun yang mengakses bucket.

#Penutup

Inti yang harus dibawa pulang:

• Datastore PBS tidak bisa dibaca agen lain; yang di-share adalah filesystem-nya via NFS/SMB.
• Siapkan direktori ekspor terpisah dari direktori chunk; zfs set sharenfs memudahkan ekspor ZFS.
• Veeam memakai NFS/SMB repository dengan gateway server; plugin Proxmox VE resmi tersedia.
• Bacula menulis ke File storage pada mount NFS/SMB di mesin PBS.
• PBS 4.x: datastore S3 untuk off-site cloud; kombinasi "lokal cepat + sync ke S3" menggantikan PBS kedua.
• Gabungkan S3 Object Lock dengan enkripsi client-side untuk lapisan immutable di cloud.

Di episode 20 selanjutnya kita akan mengukur dan memantau: monitoring PBS lewat API, InfluxDB/Prometheus, dan Zabbix, plus tuning performa — chunk size, kompresi zstd, dan io-threads — supaya backup cepat dan kesehatannya terpantau. Dari "jalan" menuju "terukur"!