Membaca Log Task vzdump Proxmox Saat Backup VM Gagal di Tengah Jalan

Backup VM di Proxmox VE gagal, dan yang terlihat di dashboard cuma status error berwarna merah. Email notifikasi, kalau diaktifkan, sering hanya bilang job backup gagal tanpa penjelasan. Banyak admin langsung menebak storage penuh, padahal penyebabnya bisa juga lock yang tertinggal dari job sebelumnya atau guest agent yang tidak merespons saat filesystem mau di-freeze. Catatan ini soal cara membaca log task vzdump supaya tebakan itu bisa diganti dengan bukti. vzdump adalah tool bawaan Proxmox yang menjalankan backup VM (QEMU) dan container (LXC). Baik dijalankan dari tombol Backup now, dari job terjadwal, maupun dari command line, prosesnya tercatat sebagai task. Setiap task punya log lengkap. Masalahnya, log itu jarang dibuka sampai habis.

Di mana log vzdump sebenarnya disimpan

Cara paling cepat lewat GUI. Di panel Tasks bagian bawah, atau di menu node lalu Task History, cari baris bertipe Backup. Klik dua kali untuk membuka output lengkapnya. Kolom status di daftar itu hanya ringkasan. Isi aslinya ada di jendela output. Satu hal yang sering bikin bingung: job terjadwal biasanya berjalan sebagai satu task untuk banyak VM sekaligus. Jadi satu log bisa berisi belasan VM berurutan, dan statusnya error walaupun hanya satu VM yang gagal. Kamu perlu scroll dan mencari bagian VM yang bermasalah, bukan membaca baris terakhir saja. Di sisi disk, log task tersimpan di bawah /var/log/pve/tasks/. Nama filenya berupa UPID (Unique Process ID), yaitu string yang memuat nama node, PID, waktu mulai, tipe task (vzdump), ID VM, dan user yang menjalankannya. Kamu tidak perlu menghafal formatnya karena pvenode bisa menampilkan daftar dan isinya langsung dari terminal. Untuk storage tipe directory atau NFS, vzdump biasanya juga menyimpan file .log di samping file arsip backup. Kalau backup gagal di tengah jalan, arsipnya tidak lengkap, jadi log task tetap jadi sumber utama.

BASH

# daftar task backup terakhir di node ini
pvenode task list --typefilter vzdump --limit 10

# baca log lengkap satu task (salin UPID dari daftar di atas)
pvenode task log 'UPID:...'

# cek kapasitas storage yang dipakai untuk backup
pvesm status

# cek apakah VM masih menyimpan lock di konfigurasinya
qm config 101 | grep -i lock

# cek apakah guest agent merespons dan status freeze-nya
qm guest cmd 101 ping
qm guest cmd 101 fsfreeze-status

# pastikan tidak ada proses vzdump yang masih berjalan
ps aux | grep '[v]zdump'

Semua perintah di atas hanya membaca, jadi aman dijalankan di node produksi. Ganti 101 dengan ID VM kamu.

Membaca alurnya, bukan cuma baris ERROR

Menurutku, kebiasaan yang paling membantu adalah melihat baris INFO terakhir sebelum ERROR muncul. Log vzdump ditulis berurutan per fase: mulai job, cek status VM, menentukan mode backup, membuat arsip, freeze dan thaw filesystem lewat guest agent, transfer data dengan persentase progres, lalu selesai. Fase terakhir yang sukses memberi tahu di tahap mana prosesnya berhenti. Bentuk umumnya kira-kira seperti ini. Ini contoh format output dengan placeholder, bukan log insiden nyata:

TEXT

INFO: starting new backup job: vzdump 101 --mode snapshot --storage <nama-storage> --compress zstd
INFO: Starting Backup of VM 101 (qemu)
INFO: status = running
INFO: backup mode: snapshot
INFO: creating vzdump archive '<path-arsip>'
INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task '<id>'
INFO:  10% (<ukuran> of <total>) ...
INFO:  20% (<ukuran> of <total>) ...
ERROR: <pesan error dari fase yang gagal>
ERROR: Backup of VM 101 failed - <ringkasan error>
INFO: Failed at <waktu>

Baris ERROR: Backup of VM ... failed di bagian bawah biasanya hanya pengulangan ringkas. Detail yang berguna sering ada satu atau dua baris di atasnya, atau tersirat dari fase yang tidak pernah tercapai.

Tiga penyebab yang sering tertukar

Storage penuh biasanya punya ciri jelas. Backup sempat berjalan dan progresnya sudah naik beberapa persen, lalu berhenti dengan pesan seputar gagal menulis atau tidak ada ruang tersisa. Cek dengan pvesm status dan lihat kapasitas storage tujuan, bukan hanya disk lokal node. Hal yang sering terlewat adalah retention. Backup lama yang mau dibuang sesuai aturan retention biasanya baru dihapus setelah backup baru selesai, jadi storage butuh ruang untuk satu arsip baru sebelum yang lama dibersihkan. Untuk Proxmox Backup Server, penuhnya datastore punya mekanisme pembersihan sendiri dan perlu dicek di sisi server tersebut. Lock yang tertinggal kelihatan berbeda. Backup gagal hampir seketika, tanpa progres sama sekali, dan pesannya menyebut VM sedang terkunci, misalnya dengan keterangan backup. Proxmox memasang lock di konfigurasi VM selama backup berjalan supaya operasi lain tidak bentrok. Kalau job sebelumnya terhenti paksa, misalnya karena node reboot di tengah backup atau prosesnya di-kill, lock itu bisa tertinggal. Pola lain adalah dua job yang jadwalnya tumpang tindih, sehingga job kedua menemukan VM masih dikunci oleh job pertama yang sah. Peringatan sebelum membuka lock: pastikan dulu tidak ada backup yang masih berjalan untuk VM itu. Cek daftar task aktif dan proses vzdump dengan perintah di atas. Kalau yakin lock-nya memang sisa, qm unlock 101 (atau pct unlock untuk container) akan menghapusnya. Perintah ini mengubah konfigurasi VM. Membuka lock saat backup sungguhan masih jalan bisa membuat operasi lain bentrok dengan proses backup tersebut. Gagal freeze filesystem terjadi di fase guest agent. Kalau opsi QEMU Guest Agent diaktifkan di pengaturan VM, vzdump meminta agent di dalam guest untuk freeze filesystem sebentar supaya data di disk konsisten, lalu thaw lagi. Kalau service agent di dalam guest mati, belum terpasang, atau macet, log biasanya berhenti di sekitar baris fs-freeze dengan pesan timeout atau gagal menjalankan perintah agent. Cek dengan qm guest cmd 101 ping. Kalau tidak ada respons, masalahnya ada di dalam guest, bukan di storage. Setelah backup gagal di fase ini, cek juga fsfreeze-status. Proxmox berusaha melakukan thaw, tapi kalau guest terasa hang, status freeze adalah hal pertama yang perlu dipastikan. Untuk container LXC, ceritanya sedikit berbeda karena tidak ada guest agent. Mode snapshot di LXC bergantung pada storage yang mendukung snapshot. Kalau storage-nya tidak mendukung, log biasanya mencatat kegagalan mode dan vzdump mencoba mode lain. Jadi pesan semacam itu belum tentu berarti backup gagal total.

Yang gampang disalahpahami

Mode snapshot pada VM QEMU bukan snapshot storage seperti di ZFS atau LVM-thin. Ini fitur live backup milik QEMU: data disk dibaca sambil VM tetap berjalan, dan blok yang mau ditimpa guest disalin dulu ke backup. Konsekuensinya, kalau storage tujuan lambat, I/O di dalam VM bisa ikut melambat selama backup. Hal ini sering dilaporkan sebagai website lemot di jam backup, padahal backup-nya sendiri sukses. Kesalahpahaman lain adalah menganggap backup gagal berarti data VM rusak. Biasanya tidak. Yang gagal adalah proses salinnya, sementara VM tetap berjalan. Yang perlu dibereskan adalah sisa file arsip yang tidak lengkap di storage tujuan, setelah kamu memastikan file itu memang milik job yang gagal. Dari sisi support, pertanyaan pertama yang biasanya kita ajukan adalah apakah gagalnya selalu di VM yang sama atau acak. Kalau selalu VM yang sama, curigai guest agent atau lock di VM itu. Kalau acak dan cenderung di VM besar atau di akhir jadwal, curigai kapasitas atau kecepatan storage.

Latihan aman di node lab

Aku merasa pola log ini paling cepat dipahami kalau pernah sengaja dibuat gagal. Pakai node Proxmox uji, bisa nested di VPS yang mendukung virtualisasi atau mesin cadangan, lalu buat satu VM kecil. Urutan latihannya:

Buat storage tipe directory di disk atau partisi kecil, lalu jalankan vzdump manual ke storage itu sampai penuh. Perhatikan di persen berapa log berhenti dan bagaimana pesan errornya.
Pasang lock secara manual di VM uji, misalnya dengan qm set <vmid> --lock backup, lalu jalankan backup. Lihat betapa cepatnya ia gagal, kemudian buka lock dengan qm unlock.
Aktifkan opsi guest agent di VM, lalu matikan service qemu-guest-agent di dalam guest. Jalankan backup mode snapshot dan perhatikan fase fs-freeze di log.
Untuk tiap percobaan, buka log lewat GUI dan lewat pvenode task log, supaya terbiasa dengan kedua cara.

Jangan lakukan latihan ini di node produksi, terutama langkah yang mengisi storage sampai penuh, karena bisa mengganggu VM lain yang memakai storage yang sama. Intinya, status error di dashboard hanya penanda bahwa ada yang salah. Buka log task-nya, cari bagian VM yang gagal, lalu lihat fase terakhir sebelum ERROR. Gagal saat progres berjalan biasanya mengarah ke storage. Gagal seketika tanpa progres mengarah ke lock. Gagal di sekitar fs-freeze mengarah ke guest agent. Dengan tiga pola itu, kamu bisa langsung mengecek hal yang tepat.