Why ZFS needs a zfsdump

February 6, 2008

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.

Written on 06 February 2008.
« Prewiring experimental racks
Why /usr/local is now useless (and where it came from) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Feb 6 23:01:29 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.