== 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
../sysadmin/AtimeLimitations]], 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
ZFSSnapshotQuota]] 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.