zfs send/receive as dump/restore alternative
vas at mpeks.tomsk.su
Mon Nov 14 14:49:18 UTC 2016
Matthew Seaman wrote:
> > What if I have not enough space to expand the whole datastream as a
> > filesystem? My replication stream package is 119G large at the moment
> > one one server, I have neither free space nor spare time to expand the
> > whole of it into an altroot.
> Yeah. You don't store the stream data as one big file, but you expand
> it out to a filesystem on receipt. That /shouldn't/ require very much
> more space than storing it as one big file.
Matthew, I'm not quite following you. Can you please rephrase?
What's the optimal format for offline backup of the whole box for disaster
recovery? Isn't that a replication stream?
> > If I have a complete replication stream package, can I "zfs recv" a
> > single dataset from it? It would be silly to expand the whole pool to
> > extract a couple of files from zroot/usr/home/johndoe/docs
> No -- I don't think this is possible. If you want to be able to restore
> individual datasets, then you need to zfs send individual datasets.
> > So if you ever get to restore several files and don't have enough
> > space to receive the whole stream, what would you do?
> > With restore or tar you can always do a partial extract.
> Yes. ZFS is neither restore nor tar, and behaves differently. If you
> want a backup that behaves like a tar archive, then you could simply use
> tar(1) for your backups...
That would mean storing two copies of data: a backup for disaster
recovery and an archive for restoring users' files and configs, which
is not feasible.
But I'll probably heed Steve's advice and use snapshots for undoing
users' mistakes, instead of archives.
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sudakov at sibptus.tomsk.ru
More information about the freebsd-questions