VHD Check Error

acebmxer

I have forced a full backup and then did another delta backup and still delta backups are falling back to full backups.

MajorP93

@acebmxer According to your screenshots it looks like you are using CBT for your backups.
I had the same issue (backup fell back to a full) back when I was using CBT.
After disabling CBT for all backup jobs, virtual disks and therefore using classic snapshot approach all is working fine. No more fallbacks to full backups.

Pilow

@MajorP93 did see that too
but when in a THICK lvmoiscsi environment, hard to let full snaps ... CBT is quite a savior, but you get these quircks (backup fell back to full) from time to time.. seems random.

only time when you get it 100% is when you have a DR job and then next delta of VM WILL BE a full...

acebmxer

@majorp93,

I am in the process moving a vm to new SR to see if that would make a difference. I cant recall 100% but i am sure i had cbt enabled before. I just double checked works backup and cbt is enable there with no issue.

Once migration is complete i will try again with out CBT.

MajorP93

@Pilow Yeah, true.
Also during my CBT-enabled-backups tests live migrations did trigger the fallback to a full from time to time aswell (VM residing on a different host during backup run compared to last backup run).
But I did those tests ~6 months ago so maybe some fixes have been applied in that regard.

You are right, in a thick provision SR / block based scenario taking a snapshot would result in the same size of base VHD being allocated again for the purpose of snapshotting... not really practical.

I really hope that CBT receives some more love as we plan to move our storage to a vSAN cluster and intend to use iSCSI instead of NFS by that time so using CBT would also be our best bet then...
CBT also reduces the load on the SR (as in I/O) as it removes the need to constantly coalesce disks during backup job re-creation / deletion of snapshots.

@acebmxer Interesting during my tests CBT was not really stable as in backups falling back to full quite often. I recall reading somewhere in the documentation that CBT has some quirks so it seems to be a known issue.

acebmxer

After shuffuling a vm around on differen SR I started another backup job and all vms failed back to full with CBT disabled in backup job.

When the following schedule back task started all vms did a delta backup.....

acebmxer

Now delta backups are working again. I tried re-enabling CBT so far so good. Still did a delta backup snapshot was removed no errors.

Maybe someone with more knowledge could explain why its working now.

2026-03-12T00_32_16.994Z - backup NG.txt

Pilow

@acebmxer when changing SR, full pass is expected (it is documented) even with CBT enabled.
the bitmap file of the CBT needs to be reconstructed on the destination SR, so you get a full pass, and next passes will get delta as expected

acebmxer

@Pilow

While that could be true only 1 vm was shuffled to another SR. But all VMs now being backup with CBT enabled.

Well... i just check again at backups and after the last scheduled backup at 1am all vms fell back to full backup again.

poddingue

Pilow's right that moving a VM to another SR forces one full pass while the CBT bitmap is rebuilt; that part is expected.
But your screenshot actually shows the likely culprit for the all-VMs-fall-back-to-full pattern: you have Purge snapshot data when using CBT enabled, and XO's incremental backup docs flag exactly that combination as a known issue where you can occasionally get unexpected fulls: https://docs.xen-orchestra.com/xo5/incremental_backups#known-issues.
It might be worth running a few jobs with that toggle off to see if the deltas hold. It is a known rough edge on the CBT side, so following the central CBT feedback thread and maybe a nudge to @Team-XO-Backend wouldn't hurt.