Belajar Proxmox Backup Server - Backup Storage: ZFS, ext4 & SMB/NFS

#Pendahuluan

Keamanan di episode 14 membuat repository tahan banting — sekarang kita bicara tempat datanya berpijak: storage. Semua chunk, dedup, dan snapshot PBS hidup di atas filesystem, dan pilihan filesystem menentukan ketahanan, performa, dan fitur yang bisa dipakai. Episode 15 membahas ZFS, ext4 + LVM, dan NFS/SMB sebagai wadah datastore.

Bayangkan PBS seperti rumah sakit: datastore adalah ruang penyimpanan sampel. ZFS adalah ruangan ber-AC dengan sistem pencatatan dan cadangan otomatis; ext4+LVM adalah ruangan simpel yang dirawat manual; dan NFS adalah ruangan di gedung seberang — tetap berfungsi, tapi tiap kali ambil sampel harus menyeberang jalan (latency jaringan).

#ZFS: Pilihan Utama

#Compression, Snapshot, dan Checksum

ZFS adalah rekomendasi utama Proxmox untuk datastore karena tiga kemampuan yang persis melengkapi PBS:

Compression: ZFS bisa dikompresi (lz4/zstd) sebagai lapisan kedua setelah kompresi PBS. Hati-hati dengan double compression — jika PBS sudah mengompres (default zstd), hasil chunk yang disimpan sudah padat dan ZFS tidak dapat mengompres lebih jauh. Banyak admin memilih kompresi di PBS saja.
Snapshot: fondasi immutability di episode 14 — snapshot ZFS read-only untuk proteksi anti-ransomware.
Checksum: ZFS memvalidasi integritas blok saat dibaca (end-to-end checksum), lapisan kedua di bawah checksum chunk PBS untuk menangkap bit rot lebih awal.

#Best Practice: recordsize 1M

Satu pengaturan yang wajib untuk datastore PBS adalah recordsize 1M (1 MiB). Default ZFS untuk dataset data adalah 128K — tapi chunk PBS berukuran hingga 4 MiB dan ditulis berurutan. Ukuran record yang lebih besar berarti:

I/O berurutan besar lebih efisien (lebih sedikit blok metadata).
Matching dengan ukuran chunk besar → lebih sedikit fragmentasi.

Buat dataset datastore dengan recordsize 1M

zfs create -o recordsize=1M -o compression=lz4 rpool/data

Atur juga xattr=sa dan atime=off untuk performa metadata dan pembacaan yang lebih baik. Dataset ZFS terpisah untuk datastore memudahkan snapshot dan pemantauan ruang.

Important

Ubah recordsize sebelum datastore terisi, dan pertimbangkan kompresi ZFS vs kompresi PBS: aktifkan salah satunya saja untuk menghindari CPU terbuang pada data yang sudah padat. Lz4 ZFS sangat ringan, tapi chunk PBS yang terkompresi tidak akan menyusut lagi.

#Alternatif: ext4 + LVM

#Kapan Memilih

Tidak semua environment punya ZFS — entah karena preferensi tim atau hardware yang sudah berjalan. ext4 di atas LVM adalah alternatif yang stabil:

LVM memisahkan logical volume dari fisik disk, memudahkan ekspansi dan snapshot LV (jika dibutuhkan).
ext4 adalah filesystem battle-tested dengan alat pemulihan yang matang (e2fsck).

Yang hilang dibanding ZFS: checksum end-to-end (bertumpu pada checksum PBS), dan snapshot immutable berbasis ZFS. Untuk proteksi anti-ransomware di skenario ini, andalkan off-site sync dan firewall.

LV dan filesystem untuk datastore

lvcreate -L 1T -n pbs-data vg1
mkfs.ext4 /dev/vg1/pbs-data
mount /dev/vg1/pbs-data /var/lib/proxmox-backup/datastore/store1

#Catatan ext4

Gunakan mount option noatime untuk mengurangi tulis metadata.
Pantau df dan inode (df -i) — chunk PBS banyak jumlahnya; inode bisa menjadi batasan di filesystem kecil.
Tidak ada snapshot filesystem asli (selain LVM snapshot yang kurang praktis); andalkan retention + sync.

#NFS/SMB: Storage Jaringan

#Performance Cost

Datastore di NFS atau SMB itu legal dan didukung — misalnya untuk memanfaatkan NAS/array yang sudah ada. Namun ada biaya nyata:

Latency: setiap tulis chunk melewati jaringan; dedup yang berat membaca metadata bisa terasa lambat.
Bandwidth: network storage berbagi link dengan traffic lain; backup yang meledak bisa memenuhi NIC.
Dependency: PBS tidak akan berfungsi jika mount putus — pastikan mount persisten dan ada monitoring.

Untuk production yang serius, network storage 10G dan jaring terpisah (episode 13) adalah syarat minimum yang wajar. Untuk keperluan lab atau environment kecil, NFS di link 1G cukup.

Mount NFS untuk datastore

mount -t nfs 10.0.20.5:/backup /mnt/pbs-nfs

#Menghitung Kapasitas

Kapasitas storage dihitung dari data aktual setelah dedup dan kompresi, bukan ukuran raw backup:

Formula estimasi kapasitas

Kapasitas ≈ (Total Data × RPO window snapshot)
            ÷ Dedup Ratio ÷ Compression Ratio

Contoh: 4 TB data VM, dedup ratio 5x, kompresi 2x, retention 30 hari penuh:

Tambahkan margin 20-30% untuk metadata, GC watermark, dan snapshot ZFS. Cara paling akurat: ukur metrik Original vs Dedup vs Compressed di datastore kalian (episode 6) setelah beberapa hari berjalan, lalu proyeksikan.

Tip

Proyeksikan kapasitas dari rasio nyata datastore kalian, bukan tebakan: setelah seminggu backup, ambil angka Dedup dan Compressed dari web UI PBS lalu kalikan dengan proyeksi pertumbuhan data. Itu jauh lebih akurat daripada formula teoritis.

#Penutup

Inti yang harus dibawa pulang:

ZFS adalah pilihan utama: compression, snapshot, dan checksum bawaan.
recordsize=1M adalah best practice wajib untuk datastore PBS di ZFS.
Aktifkan kompresi ZFS atau PBS, bukan dua-duanya.
ext4 + LVM stabil untuk environment tanpa ZFS; pantau inode dan andalkan sync untuk redundansi.
NFS/SMB bisa dipakai dengan cost latency dan bandwidth; network storage butuh 10G dan jaringan terpisah untuk production.
Hitung kapasitas dari dedup/compression ratio nyata ditambah margin 20-30%.

Di episode 16 selanjutnya kita akan menghadapi saat-saat sulit: troubleshooting & recovery — membaca task log detail, memakai perintah proxmox-backup-manager, menangani kasus umum seperti disk penuh, race GC, dan fingerprint mismatch, serta memulihkan datastore ke server baru lewat sync/import dengan test recovery menyeluruh. Siap siaga bukan berarti tidak pernah ada masalah!