evik wrote:
Reading this list for a while made it clear that zfs send is not a
backup solution, it can be used for cloning the filesystem to a backup
array if you are consuming the stream with zfs receive so you get
notified immediately about errors. Even one bitflip will render the
stream unusable and you will loose all data, not just part of your
backup cause zfs receive will restore the whole filesystem or nothing
at all depending on the correctness of the stream.
You can use par2 or something similar to try to protect the stream
against bit flips but that would require a lot of free storage space
to recover from errors.
e
The all or nothing aspect does make me nervous, but there are things
which can be done about it. The first step, I think, is to calculate a
checksum of the data stream(s).
-k chkfile.
Calculates MD5 checksums for each tape and for the
stream as a whole. These are written to chkfile, or if
specified as -, then to stdout.
Run the dump stream back through digest -a md5 and verify that it is intact.
Certainly, using an error correcting code could help us out, but at
additional expense, both computational and storage.
Personally, for disaster recovery purposes, I think that verifying the
data after writing to tape is good enough. What I am looking to guard
against is the unlikely event that I have a hardware (or software)
failure, or serious human error. This is okay with the zfs send stream,
unless, of course, we get a data corruption on the tape. I think the
correlation between hardware failure today and tape corruption since
yesterday / last week when I last backed up must be pretty small.
In the event that I reach for the tape and find it corrupted, I go back
a week to the previous full dump stream.
Clearly the strength of the backup solution needs to match the value of
the data, and especially the cost of not having the data. For our large
database applications we mirror to a remote location, and use tape
backup. But still, I find the ability to restore the zfs filesystem
with all its snapshots very useful, which is why I choose to work with
zfs send.
Tristram
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
