Changed-block tracking (CBT) Incremental Backup for oVirt | Red Hat Virtualization (RHV)

Changed-block tracking (CBT) is a commonly used mechanism to optimize the snapshot-based incremental backup process. While in VMware environments it has been available for years, it wasn't commonly available in other solutions, especially with its roots in open-source, only until recent months.

With version 4.4, oVirt introduced CBT incremental backup, APIs as a technical preview. Storware has quickly implemented a new backup strategy in vProtect, which allows administrators to test how it works in real-life. In this short blog, I'm going to briefly describe this new backup approach.

Let's start with the core advantage of CBT - no snapshots are needed to be left on the hypervisor to perform future incremental backups. Behind the scenes, oVirt, or more accurately KVM with QEMU is going to keep track of what has changed using dirty-block maps. Snapshots can occupy a significant amount of space and affect performance - no wonder why CBT was a long-awaited feature.

Although CBT needs to be enabled per-disk basis, it is done automatically by vProtect, so the administrator doesn't have to click in the details of each VM.

Whenever vProtect performs a backup, it needs to record checkpoint ID (an ID that is later used to perform the next backup to refer to changes that happened since this particular point in time). Using this ID we can query oVirt APIs to return a list of changed blocks - which also includes information about zeroed blocks.

In the new strategy you also need to use Disk Image Transfer APIs, like it was in the past, however, there is a significant difference - this time you don't export data via the manager, but you can receive a link to the Image I/O service that runs on hypervisor and export data directly from this service. 

Now, this approach helps to scale significantly better, as the manager is no longer a bottleneck. Note, however, that contrary to the SSH transfer method (which also transfers data from the hypervisor, optionally with netcat), actual protocol/communication-related aspects have a lower impact on the overall performance - multiple HTTP requests for parts of the blocks are generally costly compared to pure netcat transfer. On the other hand - you don't have to read unnecessary blocks, which may significantly shorten the time of the data export phase. 

Once you export data, you finalize transfer in Disk Image Transfer APIs and record checkpoint ID for the next backup.

Restore process is almost exactly opposite. vProtect recreates VM with metadata, exactly like before, then creates new disks and imports using Disk Image Transfer APIs. Again, the actual data transfer doesn't happen via the manager, like in original APIs, but you are pointed to the specific host, which receives blocks. The last step is to complete disk image transfer with SDK.

One drawback of currently available APIs is backup of VMs that are down - this is not supported yet, so the regular Disk Image Transfer method is used (this means backup via manager).

Currently, the CBT strategy is still a technical preview, and some improvements may be needed, but it is a promising new approach that can help you to achieve a high performing agent-less backups in oVirt-based environments. I encourage you to try out a new approach and see how it performs in your environment. 

If you hungry for more details, please find one of my last webinars, where I described CBT usage in Storware vProtect.