[OpenIndiana-discuss] Broken zpool

[David Brodbeck]

On Sat, Nov 7, 2015 at 12:55 PM, Philip Robar <philip.robar at gmail.com>
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.

-- 
D. Brodbeck
System Administrator, Linguistics
University of Washington
GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875