Mengira Snapshot Proxmox Sama dengan Backup, Padahal Ikut Hilang Bersama Disk-nya

Banyak admin VPS merasa aman karena selalu menekan tombol Take Snapshot di Proxmox sebelum update kernel atau mengubah konfigurasi. Masalahnya, snapshot itu tidak pernah keluar dari storage tempat disk VM berada. Kalau storage itu rusak, terhapus, atau dienkripsi ransomware, snapshot ikut hilang bersama disk yang mau dilindungi. Tulisan ini memakai format post-mortem, tapi bukan rekaman satu kejadian tertentu. Isinya rangkuman pola yang sering muncul saat VM di Proxmox tidak bisa dipulihkan, supaya titik lemahnya bisa dikenali sebelum benar-benar kejadian.

Dampak awal yang biasanya terlihat

Gejalanya bisa bermacam-macam. VM tidak mau boot. Log host penuh error I/O. Pool ZFS berstatus FAULTED atau tidak bisa di-import. Thin pool LVM gagal diaktifkan. Atau file disk VM tiba-tiba berganti nama dan isinya tidak terbaca karena sudah dienkripsi. Ada juga versi yang lebih sederhana: VM tidak sengaja di-destroy, lalu baru sadar beberapa menit kemudian. Reaksi pertama pemilik server biasanya sama: tenang, kan ada snapshot. Di meja support, pertanyaan yang paling berguna saat itu justru dua. Snapshot-nya tersimpan di mana? Lalu, ada salinan VM ini di luar host tersebut? Jawaban pertanyaan kedua sering kosong, dan dari situ skala masalahnya mulai kelihatan.

Urutan investigasi yang biasanya dilalui

Langkah pertama hampir selalu membuka tab Snapshots di GUI atau menjalankan qm listsnapshot. Snapshot masih terlihat rapi lengkap dengan nama dan deskripsinya, jadi orang mengira datanya aman. Lalu rollback dicoba, dan gagal karena volume tidak ditemukan atau storage tidak aktif. Ini bagian yang sering menjebak. Daftar snapshot yang tampil di Proxmox berasal dari file konfigurasi VM di /etc/pve/qemu-server/<vmid>.conf. Setiap snapshot tercatat sebagai section terpisah di file itu. Folder /etc/pve disimpan oleh cluster filesystem Proxmox, terpisah dari storage disk VM. Jadi catatannya bisa masih ada, sementara datanya sudah tidak ada. Yang kamu lihat di GUI itu metadata, bukan bukti bahwa bloknya masih utuh. Langkah berikutnya adalah melihat langsung ke storage. Semua perintah di bawah hanya membaca, aman dijalankan di host:

BASH

# Snapshot yang tercatat di konfigurasi VM (contoh VMID 101)
qm listsnapshot 101

# Status semua storage yang dikenal Proxmox, termasuk yang tidak aktif
pvesm status

# Definisi storage: jenis, path, pool, dan content type
cat /etc/pve/storage.cfg

# LVM-thin: thin pool, volume disk, dan snapshot-nya
lvs -a

# ZFS: daftar snapshot beserta dataset induknya
zfs list -t snapshot

# qcow2: snapshot internal di dalam file disk (path contoh)
qemu-img snapshot -l -U /var/lib/vz/images/101/vm-101-disk-0.qcow2

Opsi -U di qemu-img dipakai supaya file tetap bisa dibaca walaupun sedang dipakai VM yang menyala. Hasilnya bisa tidak konsisten kalau VM sedang menulis, jadi cukup dipakai untuk melihat daftar saja. Path qcow2 tergantung definisi storage kamu, cek dulu di storage.cfg. Dari output ini biasanya langsung kelihatan polanya. Snapshot LVM-thin ada di thin pool yang sama dengan disk VM. Snapshot ZFS menempel di zvol milik disk VM. Snapshot qcow2 ada di dalam file disk itu sendiri. Kalau storage-nya tidak bisa dibaca, semua perintah di atas ikut gagal atau tidak menampilkan apa-apa.

Kenapa snapshot ikut hilang bersama disk-nya

Snapshot di Proxmox didelegasikan ke storage di bawahnya. Proxmox sendiri tidak menyalin data ke tempat lain. Cara kerjanya berbeda per jenis storage, tapi kesimpulannya sama. Di LVM-thin, snapshot adalah thin volume baru yang berbagi blok dengan volume aslinya di thin pool yang sama. Mekanismenya copy-on-write: saat snapshot dibuat, tidak ada data yang disalin. Baru ketika VM menulis ke sebuah blok, versi lama blok itu dipertahankan untuk snapshot. Artinya snapshot dan disk aktif bergantung pada data dan metadata thin pool yang sama. Kalau metadata thin pool rusak, atau disk fisik di bawah volume group itu mati, semua volume di pool tersebut ikut terdampak, termasuk snapshot. Di ZFS, Proxmox menyimpan disk VM sebagai zvol di dalam pool. Snapshot ZFS adalah penanda read-only yang mereferensikan blok lama di pool yang sama. Snapshot juga tidak bisa berdiri sendiri tanpa dataset induknya. Pool hilang berarti snapshot hilang. Saat disk VM dihapus dari Proxmox, snapshot-nya juga ikut dihapus. ZFS memang bisa mengirim snapshot ke host lain lewat zfs send, dan Proxmox punya fitur Storage Replication untuk ZFS. Tapi itu sudah replikasi ke tempat lain, bukan snapshot lokal yang tinggal diam di pool yang sama. Di qcow2, yang biasa dipakai di storage directory, NFS, atau CIFS, snapshot disimpan sebagai snapshot internal di dalam file .qcow2 itu sendiri. Satu file berisi disk aktif sekaligus semua snapshot-nya. File korup, terhapus, atau dienkripsi berarti semuanya hilang sekaligus. Kalau snapshot dibuat dengan opsi menyertakan RAM, state memorinya memang disimpan sebagai volume terpisah, tapi tetap di storage yang sama. Soal LVM biasa (thick), dukungan snapshot-nya secara tradisional terbatas dan mulai berubah di versi Proxmox yang lebih baru. Kalau kamu memakai jenis storage ini, cek dokumentasi versi yang terpasang. Untuk skenario ransomware, ada satu hal lagi. Penyerang yang mendapat akses root ke host Proxmox bisa menghapus snapshot dengan perintah biasa, sama seperti admin. Ransomware yang mengenkripsi file qcow2 otomatis mengenkripsi snapshot di dalamnya. RAID juga tidak menolong di sini. RAID melindungi dari disk fisik yang mati, tapi kerusakan logis, penghapusan, dan enkripsi akan ikut dicerminkan ke semua disk anggotanya.

Mitigasi sementara selama storage masih bisa dibaca

Kalau storage belum sepenuhnya mati, urutan langkah sangat menentukan. Ikuti urutan ini dengan hati-hati:

Jangan rollback dan jangan hapus snapshot dulu. Rollback menimpa kondisi disk saat ini, dan itu tidak bisa dibatalkan.
Kalau dugaannya ransomware, putus host dari jaringan lebih dulu. Jangan menyambungkan storage backup apa pun ke host yang mungkin masih terinfeksi.
Ambil salinan dari apa yang masih bisa dibaca. VM yang masih menyala bisa di-backup dengan vzdump ke storage lain. Untuk pool ZFS yang bermasalah, import dalam mode read-only (zpool import -o readonly=on <nama_pool>) biasanya lebih aman daripada langsung mencoba perbaikan.
Tunda perintah perbaikan yang menulis ke storage, misalnya zpool import -F atau lvconvert --repair untuk thin pool. Perintah ini bisa membuang transaksi terakhir atau mengubah metadata. Jalankan hanya setelah ada salinan, dan sebaiknya setelah membaca dokumentasinya untuk kondisi yang kamu hadapi.

Tahap ini hanya untuk menyelamatkan yang tersisa. Kalau storage sudah tidak terbaca sama sekali dan tidak ada salinan di tempat lain, snapshot tidak bisa diandalkan untuk pemulihan.

Perbaikan arsitektur dengan vzdump dan Proxmox Backup Server

Perbaikan yang sebenarnya adalah memastikan ada salinan utuh VM di tempat yang tidak ikut rusak bersama host. Di Proxmox ada dua jalur utama. Yang pertama vzdump, tool backup bawaan Proxmox. Hasilnya berupa file arsip lengkap, misalnya .vma.zst untuk VM atau .tar.zst untuk container. File ini berisi konfigurasi dan seluruh isi disk, dan bisa di-restore di host lain:

BASH

# Backup manual VM 101 ke storage bernama backup-nfs (nama storage contoh)
vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Istilah mode snapshot di sini sering bikin bingung. Untuk VM, mode ini memakai mekanisme live backup dari QEMU supaya VM tetap jalan selama backup. Ini bukan snapshot storage yang tadi dibahas. Hasil akhirnya tetap file backup penuh di storage tujuan. Untuk jadwal rutin, atur lewat menu Datacenter, lalu Backup, dan pastikan storage tujuannya punya content type backup. Yang penting, storage tujuan harus terpisah secara fisik, misalnya NAS atau server lain. Folder lain di disk yang sama tidak dihitung terpisah. Perlu diingat juga, share NFS yang ter-mount permanen di host masih bisa dijangkau oleh siapa pun yang mendapat root di host itu. Soal credential dan akses ke storage offsite, bahasannya ada di Cara Cek Backup Offsite Tidak Ikut Terhapus Saat Server Kena Ransomware. Jalur kedua adalah Proxmox Backup Server (PBS), yang dipasang di mesin terpisah. PBS menyimpan backup secara incremental dan deduplicated, jadi backup harian tidak memakan ruang sebesar backup penuh setiap kali. Ada juga verify job untuk mengecek integritas data, aturan prune untuk retensi, dan sync ke PBS lain di lokasi berbeda. Satu hal yang sering terlewat adalah hak akses: user atau token yang dipakai host Proxmox sebaiknya cukup untuk membuat backup, tanpa hak menghapus atau prune. Dengan begitu, host yang disusupi tidak bisa ikut membersihkan backup. Nama role yang tepat cek langsung di dokumentasi PBS versi kamu. Snapshot tetap berguna, asal dipakai sesuai fungsinya. Snapshot adalah titik kembali cepat sebelum perubahan berisiko, misalnya upgrade paket atau migrasi konfigurasi. Hapus setelah perubahan terbukti aman. Snapshot yang dibiarkan berminggu-minggu terus memakan ruang di thin pool atau pool ZFS, dan bisa membuat storage penuh untuk semua VM. Praktisnya, cek dulu storage.cfg dan output pvesm status, lalu tanyakan satu hal: kalau disk host ini mati malam ini, dari mana VM akan di-restore? Kalau jawabannya masih snapshot, jadwalkan vzdump atau PBS ke mesin lain. Setelah itu, coba restore satu VM ke host berbeda supaya kamu yakin backup-nya benar-benar bisa dipakai.