I have finally got urbackup working on my unraid server, saving file and image backups to my zfs pool storage. It works great. I have come across some interesting findings relative to the general contextual and generally accepted vocabulary around full image backups.
When ZFS storage is enabled, what is the semantic difference between a UrBackup “full image backup” and an “incremental image backup”? Specifically, does a full image constitute a physically independent complete image, or is it a logically complete restore point that may share unchanged blocks with its predecessor through ZFS/CoW mechanisms?
Inspection of my datasets would lead me to conclude differently than what i would have expected ‘full image backup’ means.
I’ve been reading through the UrBackup server source recently, so I checked how this works with ZFS image snapshots enabled:
Full image backup: UrBackup creates a new, empty dataset (zfs create) and the client sends all used blocks. It’s physically independent and shares nothing with earlier backups (unless you have dedup enabled on the pool).
Incremental image backup: UrBackup clones the previous backup (zfs clone <previous>@ro <new>) and only writes the blocks that changed. It’s a logically complete image that you can restore or mount on its own, but physically it shares unchanged blocks with the backup it was cloned from.
So your second description fits incrementals, while fulls really are full copies.
What can make the datasets confusing to inspect: when cleanup deletes an older backup that later ones were cloned from, UrBackup runs zfs promote on the dependent clone first. That swaps the origin relationship, so after a few cleanups a dataset’s origin may not point where you’d expect. These show it clearly:
zfs list -r -o name,used,refer,origin <pool>/<path to images>
On an incremental, refer is roughly the full image size and used is only the changed blocks. A full has no origin (-), unless a promote has since made it the origin of something else.
Whether the function call was zfs_create or not, I cannot attest. But the fact remains - 46 minutes after the dataset was created, there is an origin snapshot on it, the USED and REFERENCED are significantly different, and the time for backup was 15 seconds and Transferred 422.176 MB - Average speed: 307.446 MBit/s. So I am still confused. Why would I ever use Full Image Backups?
You’re right, and my earlier answer was wrong for your setup, sorry. I looked again: with the raw copy-on-write image format (which ZFS image snapshots use), UrBackup always makes full image backups as “synthetic fulls”. It clones the last image backup (that’s the origin you see) and only writes what changed, so it’s recorded as a full but built exactly like an incremental. ESP and SYSVOL are the exception: they’re always real fulls, which is why they have no origin. The “full image backup style” setting doesn’t change this with the raw format.
So with ZFS, a scheduled full doesn’t give you an independent copy. It mostly matters for retention, where it counts as a full backup.