I’ve been noticing that when I run multiple high-load VMs on my Proxmox host, snapshot operations sometimes fail or take much longer than expected. It feels like certain tasks aren’t fully committed until the system catches up, which can make managing backups and restores stressful. It reminded me of other systems I use daily where the latest state isn’t always reflected in real time, like checking my FAB bank balance online. Even though the transactions are done, the displayed balance often lags behind, and I have to double-check by visiting the branch. I’m curious if anyone has strategies for ensuring that snapshots and backups in Proxmox reflect the true, up-to-date VM state reliably under heavy load.
Issues with VM snapshot consistency under heavy I/O
- Thread starter Aleja
- Start date
Hi,
snapshots with RAM included will reflect the exact state of the VM (at the time the snapshot finishes). For backups and snapshots without RAM, the QEMU guest agent should be installed in the guest and enabled in the configuration. Then a filesystem freeze will be done before recording the disk state. However, that still doesn't mean that the application actually synced/committed its latest state to disk. For that, you either need to use stop mode backup or snapshot while the VM is shut down or use an fsfreeze hook which issues a command to the application to do so (if the application supports something like that).
snapshots with RAM included will reflect the exact state of the VM (at the time the snapshot finishes). For backups and snapshots without RAM, the QEMU guest agent should be installed in the guest and enabled in the configuration. Then a filesystem freeze will be done before recording the disk state. However, that still doesn't mean that the application actually synced/committed its latest state to disk. For that, you either need to use stop mode backup or snapshot while the VM is shut down or use an fsfreeze hook which issues a command to the application to do so (if the application supports something like that).
