Your first backup of a 200GB VM takes 40 minutes. The next one finishes in under two. Nothing changed in the guest, no incremental flag was flipped, and the disk is exactly as large as it was yesterday. The thing doing the work is a QEMU dirty bitmap, and once you understand when it exists and when it silently disappears, the occasional "why did tonight's backup take 40 minutes again" mystery solves itself.
Key Takeaways
- A QEMU dirty bitmap tracks which blocks of a running VM disk changed since the last backup.
- The bitmap lives in the QEMU process RAM, per disk. It is not stored on the datastore.
- Fast incremental mode reads only the dirty blocks, which is why a repeat backup finishes in minutes instead of an hour.
- A guest reboot keeps the bitmap. A full VM stop/start, host reboot, or live migration usually loses it.
- Losing the bitmap means the next backup reads the whole disk. It does not mean it re-uploads the whole disk, because deduplication still applies.
- The backup task log tells you which mode ran and how much of the disk was dirty.
What "Incremental" Actually Means Here
There are two separate costs in any VM backup, and people conflate them constantly.
The first cost is reading the disk. To back up a 200GB virtual disk, something has to read 200GB of blocks off storage, split them into chunks, and hash each chunk. That is CPU and disk I/O, and on spinning storage it is the slow part.
The second cost is sending data over the network. After chunking, the client asks Proxmox Backup Server which chunks it already has and uploads only the missing ones. Thanks to content-defined chunking and deduplication, that number is tiny on a quiet day, often a few hundred MB against a 200GB disk.
The dirty bitmap attacks the first cost. It lets QEMU skip reading blocks that provably did not change, so the backup reads 5GB instead of 200GB. Deduplication was already keeping the network transfer small. The bitmap is what keeps the read fast.
Two different meanings of the word incremental
Some backup products mean "only stores changed data" when they say incremental. Proxmox Backup Server always stores only changed data because of deduplication, bitmap or no bitmap. Here, fast incremental specifically means only reads changed data. Keep the two ideas separate and the rest of this post is easy.
How the Dirty Bitmap Works
When you back up a running VM, QEMU allocates a bitmap in its own memory. Each bit covers a fixed span of the virtual disk, the granularity, typically a few tens to a couple hundred KiB. A set bit means "this region was written since the last backup." A clear bit means "untouched."
The sequence looks like this:
Lifecycle of a dirty bitmap
First backup runs
No bitmap exists yet, so QEMU reads the entire disk. This is the slow full-read pass. At the same time, it creates a fresh bitmap and starts tracking writes.
Guest keeps running
Every write the guest issues sets the corresponding bit. The bitmap accumulates the change footprint since that first backup.
Next backup runs
QEMU consults the bitmap, reads only the regions with set bits, and hands those to the backup client. Everything else is skipped entirely.
Bitmap resets to the new baseline
After a successful backup, the tracking baseline advances to the snapshot just taken, and the cycle repeats.
The critical detail is where the bitmap lives: inside the running QEMU process, in RAM. It is never written to the PBS datastore. That single fact explains every situation where fast incremental mode stops working.
When the Bitmap Survives, and When It Vanishes
Because the bitmap is tied to the QEMU process memory, anything that ends or replaces that process throws the bitmap away.
What happens to the dirty bitmap
| Event | Guest reboot (reboot inside the VM) | Backup completes normally | VM stop then start (qm stop / qm start) | Host reboot | Live migration to another node | QEMU process crash | Previous PBS snapshot pruned away |
|---|---|---|---|---|---|---|---|
Bitmap survives? | |||||||
Next backup reads | Only dirty blocks | Only dirty blocks | Whole disk | Whole disk | Whole disk | Whole disk | Whole disk |
The one that trips people up most is the difference between a guest reboot and a VM stop/start. A reboot from inside the guest, or qm reboot, keeps the same QEMU process alive, so the bitmap is intact. A full qm stop followed by qm start builds a brand new QEMU process with no memory of yesterday, so the next backup is a full read.
A nightly host reboot quietly kills fast incremental mode
If a cron job or update routine reboots your Proxmox host every night, every VM starts each day with no bitmap, and the first backup after boot reads every disk in full. The backups still succeed and still deduplicate, but they run far longer than they should. If your backup windows are creeping, check whether something is restarting the host or the VMs.
Live migration deserves a note too. The dirty bitmap is not carried to the destination node during a live migration, so the first backup after a migration reads the whole disk. If you run a scheduled load-balancer that shuffles VMs across the cluster, expect a full-read backup on any VM that moved that day.
Reading the Task Log
You never have to guess which mode ran. The backup task log states it plainly. A fast incremental run looks like this:
The line that matters is using fast incremental mode (dirty-bitmap), 4.8 GiB dirty of 200.0 GiB total. QEMU knew only 4.8GB of the disk had changed and read only that.
When the bitmap is gone, the same VM logs something closer to:
Same VM, same disk, same amount of actually-changed data. The difference between 112 seconds and 38 minutes is entirely the read pass. Note that both runs succeed and both upload roughly the same small amount of changed chunks, which is why a full read costs you time but not much bandwidth.
Keeping Backups Fast
There is no bitmap to configure. QEMU manages it automatically for running VMs backed up in snapshot mode. What you can do is avoid the things that throw it away.
- Do not reboot hosts on a schedule unless you need to. If you must, run backups before the reboot window, not after, so the day's first backup uses the bitmap that is still alive.
- Prefer
qm rebootover stop/start when you need to cycle a guest. The process stays up and the bitmap with it. - Expect a slow backup after any live migration and after applying kernel or QEMU updates that restart the VM process. This is normal, not a fault.
- Do not prune so aggressively that the reference snapshot disappears between backups. If the snapshot the bitmap is anchored to gets removed by pruning and garbage collection, the next run falls back to a full read.
- Back up in snapshot mode. Stop mode shuts the guest down, which by definition ends the QEMU process and the bitmap. Snapshot mode is the default for running VMs for exactly this reason.
A slow backup is not a broken backup
A full-read backup after a reboot or migration is completely valid. It reads more, takes longer, and produces an identical, restorable snapshot. If you see one occasional long run in an otherwise fast schedule, correlate it with a host reboot or a VM migration before treating it as a problem.
Where This Sits in the Stack
The dirty bitmap is a QEMU feature, not a PBS feature, which is why it only applies to VMs and not to LXC containers. Containers get their change detection a different way, through the file-level backup client walking the filesystem. For VMs, the bitmap is the top layer of a pipeline: QEMU decides which blocks to read, the chunker decides where to cut those blocks, and deduplication decides which chunks actually cross the wire. If you came from vzdump-to-a-directory backups, this read-only-what-changed behaviour is one of the biggest practical differences with Proxmox Backup Server.
Wrapping Up
Fast incremental backups are not magic and not a setting. A running VM accumulates a dirty bitmap in QEMU memory, the next backup reads only the blocks that bitmap flags, and that is the whole trick. The bitmap survives reboots inside the guest and the backups themselves, but a full VM restart, a host reboot, or a live migration wipes it and forces one slow full-read pass. Learn to read the one line in the task log that tells you which mode ran, and the occasional long backup stops being a mystery.
Want fast backups without babysitting the host?
remote-backups.com runs managed Proxmox Backup Server targets in EU datacenters, so your incrementals stay small and encrypted while we handle the offsite side.
View Plans
