Belajar Proxmox Backup Server - Monitoring & Performance

#Pendahuluan

Episode 19 menghubungkan PBS ke ekosistem luar. Sekarang ada pertanyaan yang sering dilupakan: bagaimana kalian tahu backup sedang sehat sebelum terlambat? Backup yang "tampaknya sukses" bisa saja gagal diam-diam — datastore penuh, verify menunda, atau sync tidak pernah jalan. Episode 20 menjawabnya dengan monitoring & performance: memantau PBS dari luar (API, InfluxDB, Prometheus, Zabbix) lalu mengukur dan menyetel performa (chunk size, kompresi, paralelisme).

Analoginya seperti panel kontrol di ruang arsip: kalian tidak menunggu rak roboh, melainkan memasang sensor beban, jam kerja petugas, dan alarm — lalu rutin mengukur berapa cepat arsip dipindah agar jadwal penutupan gudang tidak molor.

#Monitoring PBS

#Metrik yang Wajib Dipantau

Datastore usage: persentase terpakai dan estimasi hari tersisa — alarm pertama saat disk menipis.
Dedup factor (deduplication-factor): rasio yang menjadi dasar capacity planning (episode 18); jika turun drastis, sesuatu berubah di workload.
Status job: backup, verify, prune, GC, dan sync — mana yang sukses, error, atau molor.
Umur backup terakhir (snapshot age): backup yang tidak pernah masuk berarti RPO kalian sudah dilanggar diam-diam.

#Sumber Data: Web UI, Task Log, dan API

Web UI (port 8007) menampilkan dashboard dan task log per datastore — bagus untuk inspeksi manual. Untuk otomasi, PBS membuka JSON API di port yang sama. Buat API token dengan hak read-only dan gunakan di curl:

Ambil status datastore via API

curl -sk \
  -H "Authorization: PBSAPIToken=monitor@pbs!metrics:TOKEN" \
  https://pbs.local:8007/api2/json/admin/datastore/store1/status

Responsnya berisi used, total, avail, dan deduplication-factor — semua bahan yang dibutuhkan alerting. Task log bisa didapat dari /api2/json/nodes/localhost/tasks. Di sisi PVE, cek status storage backup dengan pvesm:

Cek status storage PBS dari PVE

pvesm status
pvesm list pbs-backup

#InfluxDB: Ekspor Native PBS

PBS punya dukungan native metric server: Konfigurasi → Metric Server → tambah InfluxDB (HTTP atau UDP). Tanpa instalasi tambahan, PBS mengirim data RRD yang sama dengan grafik GUI-nya — misalnya seri blockstat per datastore/object (host, VM) — ke InfluxDB, yang lalu divisualisasikan di Grafana. Ini jalur termudah untuk dashboard time-series.

#Prometheus & Zabbix

PBS tidak menyediakan endpoint /metrics bawaan. Untuk Prometheus, dua pola umum:

Community exporter (mis. pbs-exporter) yang menerjemahkan JSON API menjadi metrik Prometheus.
Textfile collector: skrip kecil menjalankan curl ke API lalu menulis file .prom yang dibaca node_exporter.

Untuk Zabbix, gunakan HTTP agent yang menarik endpoint JSON API di atas dengan token PBS, lalu buat template (metrik + trigger disk penuh dan job gagal). Apapun pilihannya, semuanya bermuara pada API yang sama — jadi pola "token read-only + endpoint /status" ini sekali dipahami bisa dipakai ulang.

Tip

Minimal yang harus ada sejak hari pertama: alert datastore hampir penuh dan alert job gagal. Dua itu saja sudah menyelamatkan lebih banyak data daripada dashboard cantik tanpa trigger. Dashboard menyusul kemudian.

#Logs

Task log tersimpan di /var/log/proxmox-backup/tasks/ dan bisa dibaca lewat GUI (Administration → Tasks) atau journalctl:

Cek log sistem PBS

journalctl -u proxmox-backup -u proxmox-backup-proxy -f
ls -lt /var/log/proxmox-backup/tasks/ | head

Durasi simpan task log diatur lewat --task-log-max-days pada node config (episode 16 memakai ini saat troubleshooting).

#Performance: Benchmark Dulu

Sebelum men-tune, ukur dulu. PBS menyediakan benchmark bawaan yang mengukur tiap tahap pipa backup — TLS, SHA256, kompresi, dekompresi, AES256/GCM, dan verify:

Benchmark throughput PBS

proxmox-backup-client benchmark --repository 10.0.1.5:store1

Hasilnya berupa angka MB/s per tahap. Cara membacanya:

TLS speed rendah → bottleneck jaringan (cek NIC, jumbo frames, rate limit).
SHA256 / AES256-GCM rendah → CPU; verifikasi AES-NI aktif (episode 7).
Jalankan sekali dengan --keyfile dan sekali tanpa, untuk mengukur overhead enkripsi di hardware kalian.

#Tuning: Chunk Size, Kompresi & Paralelisme

#Chunk Size

PBS memecah data menjadi chunk berukuran tetap. Ukuran diatur lewat --chunk-size (dalam KiB, 64-4096, default 4096 = 4 MiB, harus pangkat dua):

Chunk besar → kompresi dan dedup ratio lebih baik, index lebih ringkas, tapi butuh RAM lebih untuk chunk index dan granularitas dedup lebih kasar.
Chunk kecil → dedup lebih halus, tapi overhead metadata lebih besar.

Ubah hanya untuk backup baru; chunk lama mempertahankan ukurannya saat dibuat. Untuk workload campuran, 4 MiB default sudah terbukti seimbang — tuning ini biasanya untuk kasus khusus (mis. banyak file kecil).

#Kompresi zstd

PBS memakai zstd sebagai default — rasio terbaik dengan kecepatan terbaik. Di PVE, kompresi diatur per storage backup (compression): none, lzo, zlib, atau zstd. Untuk datastore ZFS, perhatikan tumpang-tindih kompresi (episode 15): kalau ZFS sudah compression=on dan data sudah dikompresi PBS, kompresi ZFS hampir tidak menambah apa-apa — matikan salah satu untuk menghemat CPU.

#Paralelisme (io-threads)

Paralelisme verify dikontrol lewat tuning datastore — pengganti knob "io-threads" di PBS modern:

Tuning paralelisme verify

proxmox-backup-manager datastore update store1 \
  --tuning default-verification-readers=4,default-verification-workers=4

default-verification-readers dan default-verification-workers membagi kerja verifikasi (episode 9) ke beberapa thread — naikkan jika disk mampu dan verify jadi bottleneck, turunkan jika memicu contention dengan backup. Sync job juga punya --worker-threads (episode 18) untuk paralel transfer chunk.

Warning

Jangan menaikkan semua knob sekaligus. Naikkan satu, ukur ulang dengan proxmox-backup-client benchmark dan durasi task log, lalu bandingkan. Paralelisme berlebihan pada disk lambat justru memperpanjang backup karena queue contention — terutama pada HDD atau Ceph.

#Fondasi yang Menguatkan

Tuning di atas hanya menambah di atas fondasi episode 15 & 18: recordsize 1M di ZFS untuk chunk 4 MiB, 10G networking dengan jumbo frames untuk jalur PVE → PBS, dan window backup yang dipisah dari window verify/GC. Benchmark ulang setelah setiap perubahan hardware — bukan sekali lalu dilupakan.

#Penutup

Inti yang harus dibawa pulang:

Pantau datastore usage, dedup factor, status job, dan umur backup terakhir.
API JSON port 8007 adalah satu-satunya pintu yang dibutuhkan semua alat monitoring; buat token read-only.
InfluxDB: dukungan native PBS (Configuration → Metric Server); Prometheus/Zabbix memakai community exporter atau HTTP agent.
proxmox-backup-client benchmark mengukur tiap tahap — jaringan vs CPU vs storage.
--chunk-size (default 4 MiB) hanya memengaruhi backup baru; zstd default; paralelisme via --tuning datastore.
Tune satu variabel, ukur, baru pindah ke variabel berikutnya.

Di episode 21 selanjutnya kita akan melihat ke depan: roadmap PBS — arah S3 object storage, peningkatan dedup/performa, dan integrasi cloud — plus peta komunitas: forum, wiki, mailing list, dan dokumentasi resmi. Dari "terukur" menuju "siap ikut berkembang"!