Proxmox Backup using 'Stop' is not working properly

[greavette]

Hello,

I've created a new cluster (4 nodes) and upgraded to the latest version 4.3-1/e7cdc165. I have purchased the Proxmox basic subscription for our office.

I've been doing some testing on my weekly backups whereby the backup should stop the VM, take the backup then start it back up again. What I've noticed though is Proxmox instead restarts the VM instead of full stop. The backup continues without errors even though the backup was essentially taken while the VM was running.

To be clear, I'm using the Stop option in the backup and not the Snapshot option (where the VM is supposed to be running during the backup).

Has anyone else noticed this with the new version of Proxmox?

Thank you.

 

[dietmar]

I've been doing some testing on my weekly backups whereby the backup should stop the VM, take the backup then start it back up again. What I've noticed though is Proxmox instead restarts the VM instead of full stop.

This is a feature. It stops the VM, Makes a snapshot and starts again... To minimize stop time.

 

[greavette]

Thank you for the reply @dietmar . Excellent feature! So the VM temporarily stops...the snapshot is then taken very quickly and when Proxmox has successfully taken the snapshot it starts up the VM again to be used...then the rest of the backup time is the snapshot then saved to the backup location?

Is there a way for me to calculate how long a snapshot, while the VM is off, will take? The reason I ask is because I've watched a Windows 7 VM in the console and I've watched the backup task as it logged it's steps and the VM was off for just seconds before starting backup again? Is the VM being down for just a 1 to 2 seconds enough time for Proxmox to take that snapshot?

I've always wanted to use snapshots but needed to ensure my database VM's were in full stop first so I've shyed away from snapshot backups on those VM's. But I'd like to make sure that the stop backup is safe and will work for me still.

Thank you.

 

[dietmar]

Thank you for the reply @dietmar . Excellent feature! So the VM temporarily stops...the snapshot is then taken very quickly and when Proxmox has successfully taken the snapshot it starts up the VM again to be used...then the rest of the backup time is the snapshot then saved to the backup location?

Basically yes. But we do not take a storage snapshot - instead we use the qemu live backup feature, which has the same effect as taking
a storage snapshot.

Is there a way for me to calculate how long a snapshot, while the VM is off, will take? The reason I ask is because I've watched a Windows 7 VM in the console and I've watched the backup task as it logged it's steps and the VM was off for just seconds before starting backup again? Is the VM being down for just a 1 to 2 seconds enough time for Proxmox to take that snapshot?

Snapshot will not cause any delay (= 0 seconds)

 

[greavette]

Hello @dietmar , thank you for this information. I'm used to when I ran 'Stop' backups weekly on version 3.4 whereby the VM would be stopped and the backup taken. During that time I was assured (maybe in my own mind) that the backup was good and I could trust it. This new way of Stop backup, although much more useful to me in that downtime is reduced, is hard to trust if within essentially zero seconds after the VM has been successfully shutdown a 'qemu live backup' has occurred on my entire VM and now the VM can be started again. How can the live backup feature be so quick on my 160 GB VM to get a copy of it in via a snapshot in 0 seconds!

I guess I'll need to test this a bit before I'm comfortable but I really don't want to trust something only to find out it didn't work as I needed it too when disaster strikes.

 

[dietmar]

How can the live backup feature be so quick on my 160 GB VM to get a copy of it in via a snapshot in 0 seconds!

Please read

https://git.proxmox.com/?p=pve-qemu...5250ca9f681e5377bd1821479259e81d4e78d;hb=HEAD

if you want to know details.

 

[greavette]

Thank you @dietmar for this added information.