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.
Comments on this page:
|
|