Backups with qcow2 enabled

[acebmxer]

@florent

Both full and delta passed...

Full - 2026-04-17T11_32_42.906Z - backup NG.txt
Delta - 2026-04-17T13_26_54.973Z - backup NG.txt

@pilow

I just restarted tool stack on both pool master and second host. Re-edit backup job to remove the purge snapshot with cbt and re-ran a delta backup. Which still fell back to full backup.

[Pilow]

@acebmxer bottom of POOL advanced tab, is BACKUP NETWORK selected on the NBD enabled network accessible by both hosts and XOA ?

[acebmxer]

@Pilow

Was already configured...

Think this is the issue....
Network tab under pool.

Will run another delta once the current one finishes.

Edit - update

Can a warning be made if NBD is not enabled at the pool level? or make the error more clear?

I enabled the nbd at the pool level and ran another delta - 2026-04-17T14_40_39.535Z - backup NG.txt

I Then re-enable the purge snapshot in back up job and ran another delta. 2026-04-17T15_00_40.358Z - backup NG.txt

[Pilow]

@acebmxer so, NBD it was...

holy molly, you have some good network performance !
what kind of SR at source ? and remote at destination ?
what about the PIFs ?

[acebmxer]

@Pilow

Just a little old truenas running on AMD 5900x with 10 Gic nics bound, Unifi Agg switch with 10gb links to hosts.

Storage 5 8tb tohisba drives and two 1tb nvme drives 1 for cache 1 for log vdev.

Backup device is a DS1819+ with 4 12 tb seagate exo drives with 10gb link.

[Pilow]

@acebmxer NFS remotes on the DS1819+ ?

we have iSCSI SR (25Gb mellanox 6 PIFs on hosts to 25Gb MSA2062 SAN dual controller)
our remotes are iSCSI os mounted volumes on MSA SANs, presented as S3 (minio VMs)
using XO PROXIES to offload backups from XOA

we max out a 150/200Mb/s during backups

but we are on VHD VDIs, asking myself if the added backup performance you present could be due to QCOW2 format on source SR ?
will have to try VDIs on such SR to see the diff

[acebmxer]

@Pilow Yes NFS on vm storage and on backup storage.

All vms are now on qcow2 except for the windows vm what was vhd. However i just mirgrated it over to qcow2. the Nics in all systems are the intel 10gb either x520 or x540

Edit - Sorry missed your question about performance vhd vers qcow2. I would say its on equal to. I didnt run any benchmarks for comparison. (probably should have) But havent seen any major slowness other then GC issues. (See latest post)

[acebmxer]

So progress bar seems to be working now on exporting. But i am also noticing Garbage collection seems to be running quite often that i feel its slowing down the import for the health check.

[acebmxer]

Next thing I am noticing that garbage collection is not able to coalesce vdi to vms that are running. garbage will keep trying to run every 30 - 45 seconds for 30 seconds run time. VDIs to coalesce will keep increasing unless a vm is powered off and given enough time for garbage collection to actually run.

Because garbage collection is spamming so often importing a vdi for health check will take logger.

[acebmxer]

@florent

I disabled CBT on the vms and re-ran a delta backup. I noticed the following.

While watching the backup task when it shows [XO] Exporting it will not show the percentage and completion. Watching backup task a vm will show not using NBD at first but using XO and then fail. The backup log will then show vm fell back to full backup and the task will then show that it is using NBD.

Also with out CBT GC is not constantly spamming once a vm has finished exporting and started health check. It appears to actually be running and able to coalesce as they are no longer showing in the dashboard / health...

delta job with CBT enabled - 2026-04-20T00_43_48.487Z - backup NG.txt

CBT disabled delta job. two vms fell back to full - 2026-04-20T03_19_02.894Z - backup NG.txt

Next delta job with CBT disabled 1 vm fell back to full - 2026-04-20T04_19_10.531Z - backup NG.txt