PBS incremental backup scans 162 GiB immediately after full 298 GiB backup finished

[prm_123]

Hello,

I am using Proxmox VE with Proxmox Backup Server storage.

I have a VM backup job using PBS in snapshot mode. One VM has around 298 GiB disk size. The backup completed successfully after scanning/processing almost the full disk.

But immediately after that backup finished, I manually started the backup again for the same VM, expecting it to be very small because only 1 minute passed. However, the new backup started again with a large dirty bitmap size:

scsi0: dirty-bitmap status: OK (162.4 GiB of 298.0 GiB dirty)
using fast incremental mode (dirty-bitmap), 162.4 GiB dirty of 298.0 GiB total

My question is:

1. Why does PBS/QEMU dirty bitmap show 162.4 GiB dirty immediately after the previous backup completed?
2. Does this 162.4 GiB mean that 162 GiB of new data was written to PBS, or only that 162 GiB of disk blocks were touched/changed?
3. Can dirty blocks accumulate while the first long backup is running, so that the next backup sees those blocks as dirty?
4. How can I verify what process inside the VM is causing this many dirty blocks?
5. Is this normal behavior for a database-heavy VM?

Inside the VM, disk usage did not increase by that much. For example, df -h only showed around 1 GB actual used-space increase over several days, but the PBS backup dirty bitmap showed much more changed data.

I want to understand whether this is expected incremental backup behavior or if there is any configuration issue.

Thank you.

 

[Johannes S]

Please post a log of the backup jobs.

 

[Impact]

I'd also like to see qm config VMID and cat /etc/pve/storage.cfg.

 

[prm_123]

Last login: grep -i -E "dirty-bitmap|incremental|reused|transferred|include disk|backup was|Finished Backup" /var/log/vzdump/qemu-103.log
2026-07-05 01:59:48 INFO: include disk 'scsi0' 'local-lvm:vm-103-disk-0' 278Gisk|backup was|Finished Backup" /var/log/vzdump/qemu-103.log
2026-07-05 01:59:53 INFO: scsi0: dirty-bitmap status: OK (164.3 GiB of 278.0 GiB dirty)
2026-07-05 01:59:53 INFO: using fast incremental mode (dirty-bitmap), 164.3 GiB dirty of 278.0 GiB total

 

[fabian]

Hello,

I am using Proxmox VE with Proxmox Backup Server storage.

I have a VM backup job using PBS in snapshot mode. One VM has around 298 GiB disk size. The backup completed successfully after scanning/processing almost the full disk.

But immediately after that backup finished, I manually started the backup again for the same VM, expecting it to be very small because only 1 minute passed. However, the new backup started again with a large dirty bitmap size:

scsi0: dirty-bitmap status: OK (162.4 GiB of 298.0 GiB dirty)
using fast incremental mode (dirty-bitmap), 162.4 GiB dirty of 298.0 GiB total

My question is:

1. Why does PBS/QEMU dirty bitmap show 162.4 GiB dirty immediately after the previous backup completed?
2. Does this 162.4 GiB mean that 162 GiB of new data was written to PBS, or only that 162 GiB of disk blocks were touched/changed?
3. Can dirty blocks accumulate while the first long backup is running, so that the next backup sees those blocks as dirty?

1: because the answer to 3 is yes, the bitmap tracks dirty writes since the start of the backup, since the backup itself is based on that point in time (it uses copy-before-write filtering, so that data being overwritten is backed-up before it is actually overwritten)
2: that depends on your actual write pattern, and is hard to say in general - if you first write the disk full of "1"s, then take a backup, then write it full of "2"s, then write if full of "1"s again - the whole disk will be "dirty", but the backup won't take any addition space since the data is (again) the same. the backup manifest on the PBS side will contain the upload stats - those will tell you how many new chunks this snapshot created at the time of the backup creation.

4. How can I verify what process inside the VM is causing this many dirty blocks?

that depends on what is running inside the guest.

5. Is this normal behavior for a database-heavy VM?

it can be - if the file system the database is on distributes temporarily written data across the full disk, it will dirty a lot of chunks. ensuring that "freed" data is properly discarded should help.

Inside the VM, disk usage did not increase by that much. For example, df -h only showed around 1 GB actual used-space increase over several days, but the PBS backup dirty bitmap showed much more changed data.

I want to understand whether this is expected incremental backup behavior or if there is any configuration issue.

hope my answers above help with understanding what's going on.

 

[Johannes S]

Last login: grep -i -E "dirty-bitmap|incremental|reused|transferred|include disk|backup was|Finished Backup" /var/log/vzdump/qemu-103.log
2026-07-05 01:59:48 INFO: include disk 'scsi0' 'local-lvm:vm-103-disk-0' 278Gisk|backup was|Finished Backup" /var/log/vzdump/qemu-103.log
2026-07-05 01:59:53 INFO: scsi0: dirty-bitmap status: OK (164.3 GiB of 278.0 GiB dirty)
2026-07-05 01:59:53 INFO: using fast incremental mode (dirty-bitmap), 164.3 GiB dirty of 278.0 GiB total

This lacks most of the log, please post the complete (!) logs of both jobs.

 

[J-Rod]

How much time passed between the start of the first backup and the start of the second?