best backup strategy for full backup's
Hi together, actually i only do full-backup's of my virtual machines. I use the for the backup the "old" strategy: - virsh snapshot-create-as $vmname overlay --disk-only --atomic --no-metadata --quiesce - copy the qcow2 image file - virsh blockcommit $vmname $device --active --wait --pivot - the guest agent in the VM got's an 2 seconds freeze/thaw intervall Now i want to switch to the new strategy with "backup-begin". - virsh backup-begin $vmname - the guest agent does not got an freez/thaw signal As the guest agent got's no signal, is the backup over "backup-begin" still consistent ? Or do i have to be consistent to send an virsh domfsfreeze $vmname before starting the backup and an virsh domfsthaw $vmname it it is finished ? If so, the time intervall between freeze/thaw would be on an huge disk much more then 2 secords. So, is the old method currently still the better way, if only doing full-backup's ? best regards, Michael
On Mon, Mar 10, 2025 at 11:09:38 -0000, Michael Niehren wrote:
Hi together,
actually i only do full-backup's of my virtual machines. I use the for the backup the "old" strategy: - virsh snapshot-create-as $vmname overlay --disk-only --atomic --no-metadata --quiesce - copy the qcow2 image file - virsh blockcommit $vmname $device --active --wait --pivot - the guest agent in the VM got's an 2 seconds freeze/thaw intervall
Now i want to switch to the new strategy with "backup-begin". - virsh backup-begin $vmname - the guest agent does not got an freez/thaw signal
As the guest agent got's no signal, is the backup over "backup-begin" still consistent ?
The backup api doesn't have integrated quiescing ...
Or do i have to be consistent to send an virsh domfsfreeze $vmname before starting the backup and an virsh domfsthaw $vmname it it is finished ?
... so if you want to use custom scripts and/or be sure that all caches are synced then you need to do this manually. The quiescing overcomplicates the recovery code paths if something fails during the operation so for now we decided not to go that way for backup.
If so, the time intervall between freeze/thaw would be on an huge disk much more then 2 secords.
How come? The start of the backup job is supposed to be instant. Did you observe any cases when 'virsh backup-begin' would take non-trivial time? In fact what 'virsh snapshot-create' does when --quiesce is requested is exactly the same as if you'd do it "manually".
Ok, just to be sure, that i understand it right: To be consistent on backup i have to do an: - virsh domfsfreeze $vmname - virsh backup-begin $vmname - virsh domfsthaw $vmname Do i have to wait for the "virsh domfsthaw $vmname" until the backup is finished or just after the "backup-begin" ?
On Mon, Mar 10, 2025 at 11:27:40 -0000, Michael Niehren wrote:
Ok, just to be sure, that i understand it right:
To be consistent on backup i have to do an: - virsh domfsfreeze $vmname - virsh backup-begin $vmname - virsh domfsthaw $vmname
Do i have to wait for the "virsh domfsthaw $vmname" until the backup is finished or just after the "backup-begin" ?
No you can issue 'domfsthaw' right when 'backup-begin' finishes. The backup image contains data from the point in time when the backup job *started* irrelevant how long it takes. qemu ensures that all blocks that would be overwritten by the guest are first copied to the backup image before overwriting them in the disk image.
One additional question ... if i have same snapshots in a vm, the "backup-begin" do only an backup of the currently running snapshot, right ?
On Mon, Mar 10, 2025 at 11:48:58 -0000, Michael Niehren wrote:
One additional question ...
if i have same snapshots in a vm, the "backup-begin" do only an backup of the currently running snapshot, right ?
The backup job always backs-up only the current guest-visible state of the disks. Technically a snapshot is a point-in-time in the past you might want to return to. The state represented by the snapshot is thus different from what you are backing up. With external snapshots the backup will be identical as if you merged in all the layers created by the snapshots.
participants (2)
-
Michael Niehren -
Peter Krempa