Belajar Proxmox Backup Server - Troubleshooting & Recovery

#Pendahuluan

Semua episode sebelumnya membangun PBS yang sehat — tapi di dunia nyata, masalah akan datang. Backup gagal di jam 3 pagi, datastore penuh, atau koneksi PVE tiba-tiba ditolak. Episode 16 melatih kalian berpikir seperti operator: membaca gejala, menemukan akar masalah di log, dan memulihkan diri. Ketenangan saat incident adalah hasil latihan, bukan keberuntungan.

Bayangkan seperti mekanik yang membaca diagnosis mesin: gejala hanya petunjuk; task log adalah panel instrumen yang harus dibaca sebelum membongkar apa pun. Diagnosis yang benar menyelamatkan waktu, data, dan kewarasan.

#Debug: Membaca Gejala dari Log

#Task Log Detail

Setiap operasi PBS tercatat sebagai task. Mulai selalu dari sini:

Daftar task terbaru

proxmox-backup-manager task list --since '6 hours ago'

Buka log detail sebuah task

proxmox-backup-manager task log <UPID>

task log menampilkan output berurutan dari operasi — di sinilah error sebenarnya (misal "no space left on device" atau "connection refused") terlihat. Sumber diagnosis kedua adalah log service:

Log systemd proxmox-backup

journalctl -u proxmox-backup -n 100 --no-pager

#Perintah `proxmox-backup-manager` untuk Diagnosis

Kumpulan perintah cepat untuk memeriksa kesehatan:

Cek kesehatan dasar

proxmox-backup-manager versions
proxmox-backup-manager datastore list
df -h
pvesm status        # di sisi PVE

proxmox-backup-manager versions memastikan versi semua komponen selaras — inkonsistensi versi antara PVE dan PBS sering jadi sumber masalah integrasi.

#Kasus Umum dan Solusinya

#Disk Penuh

Gejala: backup gagal dengan "no space left on device", atau datastore status melewati watermark. Tangani bertahap:

Cek df -h dan status datastore (proxmox-backup-manager datastore list).
Jalankan prune untuk mengurangi snapshot (episode 8).
Jalankan GC untuk membebaskan chunk yatim (episode 6).
Jika tetap penuh, tambah kapasitas: ekstensi LV/pool ZFS, atau tambah disk.

Disk penuh adalah masalah proses, bukan acara: tiap insiden "penuh" berarti kapasitas tidak dipantau atau retention terlalu longgar. Pasang monitoring (episode 20) dan perketat retention.

#Race Garbage Collection

Gejala: GC berjalan bersamaan dengan backup, snapshot yang baru dibuat dianggap "hilang" atau GC gagal/memakan waktu sangat lama. Akar masalah: backup dan GC berebut datastore. PBS mendesain GC mempertimbangkan snapshot yang aktif, tapi menjalankan keduanya berbarengan tetap mengganggu performa dan bisa memunculkan peringatan.

Solusi: jadwalkan GC di jendela bebas backup (episode 6), periksa jadwal job yang bentrok, dan jika terpaksa, hentikan GC yang berjalan (proxmox-backup-manager task list → abort task) sebelum backup besar.

#Fingerprint Mismatch

Gejala: PVE/client menolak koneksi dengan error "fingerprint mismatch" setelah sebelumnya berhasil. Penyebab paling umum: sertifikat PBS berubah (reinstall, restore dari image lama, atau renew PKI).

Solusinya bukan "abaikan" — perbarui fingerprint:

Ambil fingerprint baru (di PBS)

proxmox-backup-manager cert info

Perbarui fingerprint di storage PVE

pvesm set pbs1 --fingerprint AA:BB:CC:DD:...

Fingerprint yang berubah tanpa alasan yang diketahui adalah tanda bahaya — periksa apakah server PBS benar-benar server yang sama (episode 13). Jangan pernah menonaktifkan verifikasi.

Warning

Jika fingerprint berubah dan kalian tidak pernah mengubah sertifikat, curigai intervensi tak sah pada server PBS. Verifikasi identitas server sebelum memperbarui fingerprint — dalam konteks backup, "cepat memperbaiki" tanpa curiga adalah celah yang dieksploitasi penyerang.

#Disaster: Memulihkan Datastore ke Server Baru

#Skenario: PBS Utama Rusak Total

PBS yang rusak (disk mati, server hilang) harus diganti. Ada dua jalur utama:

1. Sync dari PBS remote (jika off-site sudah jalan): install PBS baru di lokasi pengganti, lalu buat sync job dari remote ke datastore baru. Seluruh snapshot kembali tanpa menyentuh PVE yang rusak.

2. Import/resync dari data lama: jika disk datastore masih hidup (server rusak, disk selamat), pasang disk ke server PBS baru dan daftarkan ulang path datastore (proxmox-backup-manager datastore create store1 /path). PBS mengenali struktur chunk yang tersimpan.

#Test Recovery

Pemulihan datastore belum selesai sampai diuji:

Daftarkan PBS baru sebagai storage di PVE (episode 4).
Restore satu VM/CT ke storage lokal (episode 5).
Nyalakan hasil restore dan verifikasi layanan.
Verifikasi beberapa snapshot lama (bukan cuma terbaru) untuk memastikan history utuh.

Verifikasi snapshot hasil sync

proxmox-backup-client snapshot list \
  --repository backup@pbs@10.0.3.30:store1

Tip

Test recovery adalah latihan berjadwal, bukan acara sekali jalan. Buat agenda kuartalan: simulasikan "PBS utama hilang" dan ukur berapa lama kalian kembali beroperasi penuh. Angka itu adalah RTO sesungguhnya dari arsitektur backup kalian.

#Penutup

Inti yang harus dibawa pulang:

Diagnosis dimulai dari task log (proxmox-backup-manager task list/log) dan journalctl.
proxmox-backup-manager versions, datastore list, dan df -h adalah perangkat kesehatan dasar.
Disk penuh: prune → GC → tambah kapasitas; pantau agar tidak terulang.
Race GC: jangan jalankan GC bersamaan dengan backup; periksa jadwal yang bentrok.
Fingerprint mismatch: ambil fingerprint baru dan perbarui di PVE — tapi selidiki dulu penyebabnya.
Pemulihan datastore: sync dari remote, atau daftarkan ulang disk lama; selalu akhiri dengan test recovery.

Di episode 17 selanjutnya kita akan melihat masa kini: PBS 4.2 & fitur terbaru — basis Debian 13.4 Trixie, Proxmox kernel 7.0, ZFS 2.4, dan dukungan object storage S3, plus integrasi dengan PVE 8.x/9.x dan perjalanan rilis PBS dari 3.x hingga 4.2. Upgrade dan fitur baru menanti!