On Aug 24, 2009, at 5:22 PM, Daniel Carosone wrote:
You can validate a stream stored as a file at any
time using the "zfs receive -n" option.
Interesting. Maybe it's just a documentation issue, but the man
page doesn't make it clear that this command verifies much more than
the names in the stream, and suggests that the rest of the data
could just be skipped over.
If you think about it, the stream may be concatenated, so the end is
when the stream ends. You have to read the stream to find the end.
If indeed this command does thoroughly process and validate the
stream, without actually writing anything to disk, that would be
very useful and should be advertised clearly.
In my testing, yes, this is what happens. I am not sure if it is
designed
to be used as such. Someone from the zfs-team should be able to
answer that question.
Personally, I prefer to use -n and -u,
but -u is a relatively new option.
I don't get how they combine, from the descriptions. It seems to me
that with -n there's no filesystem being created for -u to then not
mount. Again, maybe this is the result of misleading descriptions.
Without -u, you need a receiving filesystem, even if you don't actually
receive anything.
Therefore, the procedures we've used for decades
still works:
1. make backup
2. verify backup
3. breathe easier
That's what I want, of course. The best/only way I have found is to
store the backup recv'd in a pool. This gives me:
* validation of correct transfer, which I don't get any other way
that I've found so far.
* version upgrade compatibility guarantees. The zfs on-disk format
is the only one for which this is presently true, and which
preserves properties, metadata, etc. I actually like this: one
well-tested historical compatibility path is possibly better than
maintaining multiple formats each with compatibility quirks.
Since it is open source, worst case is that you have to dig up an
antique to receive to and then transfer again.
* redundancy, compression, and other zfs goodness for backup media
This is a different topic, but yes, I agree.
* the ability to manage backup cycles and space to the size of the
destination, thus detecting problems before the time-consuming part
when writing out media.
Can't do this with a stream (pipe). This is a feature for an enterprise
backup system and, repeat after me, zfs send/receive is not a substitute
for an enterprise backup solution.
* the ability to browse and explore content, or restore individual
files if needed, though this is of less immediate concern (that's
what snapshots are for, at least in the common case)
send streams are dataset objects, not files. If you want file-level
backups
and restorations, then use an enterprise backup solution.
FWIW, amanda is open source and what I consider an enterprise backup
solution.
-- richard
However, I do get the attraction of storing backups as files. I
just use a different file format:
I have taken to making backup pools out of files the size of
whatever removable media I plan on storing the backup on. When the
backup pool is ready, I can export it, and gpg the files as they're
written out as an archive copy of the backup pool. Then I reimport
the pool and keep sending backups to it. This is for home, and
this scheme lets me separate the "making a second copy" from the
"making an offsite archive" parts of the cycle, to suit my available
time.
*Then* I breathe easier. :-)
I got burnt (thankfully only in testing) by a previous attempt to
use mirrors and resilvering with such files. They're ~useless once
detached. The downside is the need to completely re-write the
offsite copies (no smart resilver, but irrelevant for dvd or tapes),
and the need to read all files back in before restoring. I only
plan on needing that for a full post-disaster rebuild, so no biggie
there.
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
