On 11/09/2015 01:55 PM, David Brodbeck wrote:
On Sat, Nov 7, 2015 at 12:55 PM, Philip Robar <[email protected]>
wrote:
Please correct me if I'm wrong, but the thing that both Jerry's
administrator friend and David are missing is that ZFS data redundancy
isn't just a "sexy" form of reliability. It is also provides data
integrity, i.e. with redundancy ZFS will not just notice that a file is
corrupt, with redundancy it can fix the problem. With a single drive ZFS
pool you give up that integrity and there's a good chance that any data
corruption will then be passed on to your backup before ZFS flags it
resulting in the loss of that data.
Redundant is always better than non-redundant. In general, though, I don't
see a lot of people losing files due to data corruption. Most losses I've
seen are due to hardware failure, unrepairable levels of filesystem
corruption, or operator error (overwriting files, deleting the wrong
files.) I think this is probably because if the hardware is so marginal
that it's writing corrupted data, it will rapidly corrupt the filesystem
beyond repair, too. I have yet to see a data checksum error during a scrub
of an otherwise healthy pool.
Basically, I think redundancy has some data safety benefits, but I think
the best solution to your scenario is to keep more than one backup at
different points in time -- especially since zfs streams are pretty fragile
as a backup format.
Operator error is actually by far the most common way to lose data, in my
experience, and it's one where redundancy won't help you. It's also hard
to protect against unless you keep multiple backups, since you may not
realize what happened for a while.
I run a small SOHO setup and do a bit of both. I have mirrored pools
with nightly backups of important data (along with backups of Linux/Unix
desktops using dirvish) to an "archive" pool (also mirrored). The zfs
mirrors prevent data corruption and I can still recover from the archive
pool in the event of an error.
_______________________________________________
openindiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
