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

[starkovv]

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]

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. From this point on, qemu tracks all changed blocks for the
   attached disks of the virtual machine. You imagine a bitmap like a "snapshot", just that is much more intelligent.
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.

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?

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. So you CAN backup offline virtual machines, its just that an virtual
machine which is powered off does not change its disk data, as such it makes no sense to create a new bitmap/checkpoint.

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. The readme states:

Note:

If the virtual domain is not in running state (powered off) virtnbdbackup supports copy and inc/diff backup modes. Incremental and differential backups will then save the changed blocks since last created checkpoint. As no new checkpoints can be defined for offline domains, the Backup mode full is changed to mode copy.

is the wording problematic here? If so it can be changed.

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, qcow image and vm configuration, it does not care about memory state or cpu state. It is not an "snapshot" type backup. It allows you to restore the complete virtual machine from the backup, in case of disaster or disk failure.

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.

Its the same as if you want to create consistent snapshots while the virtual machine is running, ..

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).

The transactions which are stated within the documentation are all handled by the libvirt API, the documentation which
you link, goes into much more detail about what needs to happen on the QMP protocol side of the qemu process. Libvirt
handles this for virtnbdbackup.

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.

[abbbi]

I have moved this over to a discussion, because its not an issue per-se.