Wandering Thoughts archives

Why ZFS needs a zfsdump

ZFS needs a zfsdump program for the same reasons that every filesystem needs a *dump program: you need something that can fully and completely reproduce the state of the on-disk data, complete with sparse files and weird permissions and so on, and can restore small portions of the backup not just the whole thing.

(In this day of more and more people turning off atime, it's probably no longer so important to have a backup tool that is guaranteed not to change the state of files.)

Generalized backup tools like GNU tar can do partial restores, but cannot completely capture things like sparse files. zfs send and zfs receive can exactly capture sparse files and so on, but do not support partial restores.

(There are other significant drawbacks of zfs send as a backup mechanism, including the issue with snapshots and quotas if you want to do incremental backups. My strong impression is that the whole mechanism is only really intended for transferring filesystems between pools and replication.)

Unfortunately it looks like almost all of the real work of zfs send is done deep in the kernel ZFS code, so you can't reuse the user level stuff and just make it generate dump compatible output instead of the current stream format.