What Is SpeedKit and How Does It Improve Backup Performance Without CBT Support?

Quick Answer

SpeedKit is Vinchin's snapshot-based incremental backup technology for virtual machines (VMs), offered as an alternative to Changed Block Tracking (CBT) on platforms without native CBT support. Instead of scanning the entire virtual disk to identify changed data, SpeedKit maintains a snapshot of each protected VM in the datastore and uses it to calculate disk changes more efficiently. This reduces the time required to determine what needs to be backed up, helping shorten incremental backup windows compared with ordinary incremental mode.

What Is SpeedKit?

Understanding SpeedKit in VM Incremental Backup

SpeedKit is an incremental backup mode in Vinchin Backup & Recovery, alongside CBT and Ordinary mode. It can be selected per backup job, allowing different platforms in a mixed environment to use the backup mode best suited to their capabilities.

SpeedKit is designed to accelerate the calculation of changed VM disk data on platforms whose hypervisors do not support native CBT. When SpeedKit is selected for an incremental backup job, Vinchin Backup & Recovery maintains a snapshot of each protected VM in the datastore. This retained snapshot serves as the reference for calculating disk changes, helping reduce the time required to identify data for incremental backup.

For more details, see our Incremental Backup Methods documentation and SpeedKit knowledge base article. This article focuses on SpeedKit's documented behavior and benefits rather than undocumented internal implementation details.

A Quick Primer: Full, Incremental and the Change-Detection Step

A full backup copies all the data of a VM. An incremental backup copies only the data that is new or changed since the previous backup, which usually means a shorter backup session and less backup storage. Incremental restore points form a chain that starts from a full restore point, so each incremental depends on the points before it.

Every incremental run has two parts: first detect what changed, then copy it. Copying is proportional to the amount of changed data. Detection is the part that differs between platforms and between modes, and it is the part CBT and SpeedKit are designed to speed up.

Why Is CBT Important for Incremental Backups?

Changed Block Tracking is a mechanism that records which blocks of a virtual disk have been modified since a given point in time. On VMware, CBT is a VMkernel feature that tracks storage block changes for backup software built on VMware’s storage APIs. Microsoft Hyper-V offers a comparable native mechanism called Resilient Change Tracking (RCT), and QEMU/KVM stacks can track changes with dirty bitmaps.

With a native change list available, a backup application can skip the unchanged data entirely. Without one, it has to find the changes on its own, which is where the time goes.

When Is CBT Not Available?

CBT can be missing or unusable for several reasons:

• The hypervisor has no implementation. Some platforms, or older releases of them, never offered native change tracking.

• Version thresholds. CBT support depends on the hypervisor version. For example, CBT is available in XenServer 7.3 and later, Red Hat Virtualization and oVirt 4.4.7 and later, and Oracle Linux Virtualization Manager 4.4.8 and later.

• Configuration prerequisites. For example, VMware CBT requires virtual hardware version 7 or later, while Hyper-V Resilient Change Tracking (RCT) is available starting with Windows Server 2016.

Not every platform handles missing CBT the same way. Vinchin Backup & Recovery addresses this gap with SpeedKit on supported platforms without native CBT.

Why Can Incremental Backups Be Slow Without CBT?

The Challenges of Identifying Changed Data

An incremental backup has two jobs: find the changed data, then copy it. Copying only the changes is cheap. Finding them is the expensive part when the platform offers no change tracking and no substitute mechanism.

In that situation the backup software may have to compare the current state of the disk against the previous backup. Without CBT, the backup window can increase dramatically, because all VM data must be read to detect which blocks changed. Where CBT is available, the software instead asks the hypervisor for a list of changed blocks rather than scanning the datastore.

When detection means reading the whole disk, the cost scales with disk size rather than with the amount of changed data. A large VM with only a few modified blocks can still take a long time to process.

How Slow Incremental Backups Affect IT Operations

• Longer backup windows. Jobs that should finish overnight may run into business hours.

• Higher processing overhead. Reading and comparing large disks consumes host, storage and network resources.

• Harder scheduling at scale. In environments with many large VMs, slow incrementals make it difficult to meet backup schedules and recovery point targets.

How Does SpeedKit Improve Backup Performance Without CBT Support?

Using VM Snapshots to Calculate Changed Data

The mechanism follows a problem, mechanism, result pattern:

1. Problem: the platform cannot tell the backup software which blocks changed.

2. Mechanism: SpeedKit retains a snapshot of each VM in the datastore as part of the incremental job. On KVM-based platforms, SpeedKit builds on the external snapshot technology of KVM virtualization. The retained snapshot gives the next job a fixed reference point to calculate disk changes against.

3. Result: the changed data is identified faster than in Ordinary mode, so the incremental session spends less time on calculation.

Reducing the Time Required for Incremental Data Calculation

Ordinary incremental mode takes longer to calculate the increments of VM data than both CBT and SpeedKit. SpeedKit’s faster calculation comes from the retained snapshot, which exists specifically for rapid calculation of VM data changes.

One distinction matters here. SpeedKit shortens the change-calculation step. Total backup duration also depends on storage performance, network throughput, the volume of changed data and the VM workload. This article does not claim a fixed speedup, because results depend on the environment and should be measured in it.

Improving Backup Efficiency Without Requiring Native CBT

SpeedKit does not need the hypervisor to implement CBT. That makes it useful for platforms where native tracking is missing, for example older releases of KVM-based stacks that predate dirty-bitmap based incremental backup. The libvirt documentation on incremental backup internals explains how newer QEMU and libvirt versions track writes with block dirty bitmaps, and LWN’s overview of changed-block tracking in QEMU gives useful background on why that capability arrived relatively late. The oVirt project, for instance, presented changed-block based incremental backup as a tech preview in oVirt 4.4. Platforms and versions that predate this are where an alternative has value.

Platform support varies by version and configuration, so confirm compatibility before deployment.

SpeedKit vs. CBT vs. Ordinary Incremental Backup

A Vinchin backup job uses either CBT or SpeedKit, not both at once.

Which Virtualization Platforms Support SpeedKit?

SpeedKit is not a generic add-on for every hypervisor. It is offered on a specific list of platforms, and the boundary with CBT is drawn by version. The table below reflects Vinchin's current incremental backup support at the time of writing.

Two details deserve care. First, “Listed” and “Not listed” mean what the official list shows, and no version range is stated for every platform. Second, older material drew some boundaries differently, for example by describing SpeedKit for RHV as covering 4.3 and older, and the current list should take precedence.

Support depends on the platform, its version and the backup configuration, and the list changes as products evolve. Confirm platform and version compatibility before planning a rollout.

When Should You Use SpeedKit?

When CBT Is Unavailable

SpeedKit exists for this case. If the hypervisor version has no native change tracking and the platform is on the supported list, SpeedKit is the mode designed to close the gap.

When Production Storage Has Sufficient Capacity

Because a snapshot is retained for each VM in the job, the datastore must have room for it. We recommend SpeedKit where storage is adequate. As general snapshot behavior, a retained snapshot holds data written to the VM after it was taken, so the space it needs depends on how much the VM writes. Our documentation gives no sizing figures, so size it against your own change rate.

When Ordinary Incremental Backups Take Too Long

If Ordinary mode is exceeding the backup window, SpeedKit is the first alternative to test, since Ordinary mode takes longer to calculate increments than SpeedKit.

When CBT Is Already Available

If the platform supports CBT and the environment is compatible, CBT is generally the natural choice, since it relies on the hypervisor’s native tracking and needs no retained snapshot for that purpose.

What Should You Consider Before Enabling SpeedKit?

• Compatibility. Confirm the virtualization platform and its exact version are on the supported list.

• Storage capacity. Check free datastore space for one retained snapshot per VM, and how fast your VMs change.

• Backup window and workload. Compare current incremental durations with your requirements.

• Job configuration. Review the incremental mode set on the backup job. Changing it makes the next incremental backup run as a full backup.

• Real-world validation. Test in your own production environment and measure the result.

Frequently Asked Questions About SpeedKit

Q1: Is SpeedKit faster than ordinary incremental backup?

SpeedKit calculates changes faster than Ordinary mode: instead of reading the disk to work out what changed, it compares against a retained snapshot. The actual gain depends on your storage, network and workload, so measure it in your environment.

Q2: Does SpeedKit require additional storage?

Yes. A snapshot is retained in the datastore for every VM included in the job, so capacity must be verified first.

Q3: Which virtualization platforms support SpeedKit?

Vinchin's SpeedKit supports Microsoft Hyper-V, older XenServer releases (below 7.3), Red Hat Virtualization and oVirt below 4.4.7, Oracle Linux Virtualization Manager below 4.4.8, Proxmox VE, OpenStack and Sangfor HCI. Confirm exact version support before planning a deployment, as supported versions change between product releases.

Q4: Can I switch between SpeedKit, CBT, and Ordinary mode?

Yes, the incremental mode of an existing job can be changed after stopping the job and editing its strategy. The next incremental backup then runs as a full backup, and when moving away from SpeedKit, the reserved snapshot is cleared on the next run.

Conclusion

Without native change tracking, the slow part of an incremental backup is working out what changed. SpeedKit addresses that step by retaining a VM snapshot in the datastore and using it to calculate changes faster than Ordinary mode. 

It is a good fit when CBT is unavailable, the platform and version are on the supported list, and production storage can hold the snapshots. It is not a replacement for CBT where CBT is supported. Verify platform compatibility, confirm storage capacity, and validate the result against your own backup window before rolling it out widely.