Are there any downsides to using CBT when doing backups?

[archw]

I moved over to using CBT this past weekend. It seems much, much, faster and I didnt have a single error. In the past about 20% of my nightly incremental backups had errors like "can't compute delta OpaqueRef:blah-fba0-ced3-7653-blahblah from OpaqueRef:blah-b53d-3935-1af0-blahblah, fall back to a full"

I have this option "Purge snapshot data when using CBT" set to yes.

I have both of these options set to no as I don't really fully understand the implications (other than the info bubble
"Merge backups synchronously "
"Synchronize snapshots"

With that said, are there any downsides to using CBT when doing backups?

Thanks!

[jr-m4]

One potential downside is that CBT makes live-migrations between SRs alot more difficult.

[archw]

@jr-m4
What would you need to do if that were needed??

[MajorP93]

Last time I tested CBT enabled backups the backup job would sometimes create a full backup for a given VM instead of an incremental one.
This bug got triggered by live migrations. When a VM got live migrated it got processed as full backup by backup jobs even after "normal" live migrations (no storage live migration).

[poddingue]

If you do the storage migration from XO, you shouldn't have to do anything.
XAPI does refuse to move a disk while CBT is on, as @jr-m4 said, but reading XO's code it catches that refusal, turns CBT off on the VM's disks and retries.
The price to pay is that the next backup of that VM is a full one, and the backup job switches CBT back on.

The other trade-offs are in the docs (https://docs.xen-orchestra.com/backups-and-dr/backup-types/incremental_backups#purge-snapshot-data-cbt) : NBD has to be enabled, snapshot retention has to be 0, and since the purged snapshot only keeps metadata you can't roll back to it.