abbbi / virtnbdbackup

Backup utility for Libvirt / qemu / kvm supporting incremental and differential backups + instant recovery (agentless).
http://libvirtbackup.grinser.de/
GNU General Public License v3.0
330 stars 46 forks source link

Why it supposed to back up the VM only in running state? #83

Closed starkovv closed 1 year ago

starkovv commented 1 year ago

Hi,

The README is quite complicated for me. Could anyone answer a few most prominent questions I have?

1) What's the role of NBD server in QEMU project and what the role does it serve in virtnbdbackup?

2) Why it is said in README that VM can be backed up for using in modern incremental mode only if it's in running state, and it can't be backed up in poweroff state?

What does virtnbdbackup do under the hood when it is backing up VM in running state? Are we talking here only about disk backups and no RAM & CPU state preserving?

What's the point to backup VM in running state that when we will restore it it may be in insonsistent state from the point of view of the operating system that is running within the VM?

As I see it in it's documentation (https://github.com/qemu/qemu/blob/master/docs/interop/bitmaps.rst), the QEMU project suggests to power off the VM and then in one transaction start VM and immediately pause the VM and in that state start the VM backup of one or more disks of VM in transactional manner to guarantee disks data consistency at the moment of backup and the right "state" of the data on the disk from the guest OS point of view as it's the same state when the backup was being recorded and when it's being restored later on (the guest VM was in "just powered on and not yet even booted" state when we backed up and it will be in the same "just powered on and not yet even booted" state when we restored it).

abbbi commented 1 year ago
  1. What's the role of NBD server in QEMU project and what the role does it serve in virtnbdbackup?

qemu has an NBD backend, which allows you to expose virtual disks via the NBD protocol. Qemu can also use disks attached via NBD, it is used in various ways to give other components access to the disk data.

For the specific purpose of the backup operation, the NBD server also knows about the created bitmaps, thus, it allows other applications to access the bitmap information over NBD, what happens is:

1) virtnbdbackup uses the libvirt API to start a backup job. Depending on the backup mode, a new bitmap is created which stores information about further changes to the disks 2) After virtnbdbackup has told that it wants to create a backup, QEMU spins up an NBD Server which exposes the disk data. 3) virtnbdbackup connects to this NBD Server and gets informations about the data that needs to be backed up, during incremental or differencial backup, it also gets the informations about the blocks which have changed since the last backup and saves only changed blocks. 4) After virtnbdbackup has finished saving all data, the backup operation is stopped and the NBD Server quits operation.

  1. Why it is said in README that VM can be backed up for using in modern incremental mode only if it's in running state, and it can't be backed up in poweroff state?

If you want to create forward incremental backups, which you can use for future backus, the qemu process needs to create an bitmap within the qcow image, this obviously only works if the qemu process is running. If the virtual machine is powered off, virtnbdbackup starts an NBD server manually, which accesses the disks read only, it then saves only the changed blocks since the last bitmap has been created.

Both the libvirt API and the qcow image need to know about the bitmaps. On libvirt side, it is called a "checkpoint". Checkpoints can only be created if the virtual machine is in online mode.

What does virtnbdbackup do under the hood when it is backing up VM in running state? Are we talking here only about disk backups and no RAM & CPU state preserving?

virtnbdbackup only saves disk data, it does not care about memory state or cpu state. It is not an "snapshot" type backup.

What's the point to backup VM in running state that when we will restore it it may be in insonsistent state from the point of view of the operating system that is running within the VM?

if the virtual machine has an qemu agen installed, virtnbdbackup will tell the virtual machine to freeze the filesystems for the moment the bitmap is created, thus you need to be sure the qemu agent within the virtual machine does all things required to get your FS and other applications such as databases into a consistent state.

As I see it in it's documentation (https://github.com/qemu/qemu/blob/master/docs/interop/bitmaps.rst), the QEMU project suggests to power off the VM and then in one transaction start VM and immediately pause the VM and in that state start the VM backup of one or more disks of VM in transactional manner to guarantee disks data consistency at the moment of backup and the right "state" of the data on the disk from the guest OS point of view as it's the same state when the backup was being recorded and when it's being restored later on (the guest VM was in "just powered on and not yet even booted" state when we backed up and it will be in the same "just powered on and not yet even booted" state when we restored it).

Well, if you want to be 100% sure the VM is in consistent state, then poweroff your VM and create manual backups, but if you have server systems hosted on libvirt, thats obviously not an option to power off your virtual machines for daily backups. virtnbdbackup does more or less what all other hypervisor backup solutions do nowadays to allow online full/incremental or differencial backups.