[OpenIndiana-discuss] Broken zpool

[Jim Klimov]

7 ноября 2015 г. 21:55:15 CET, Philip Robar <philip.robar at gmail.com> пишет:
>On Fri, Nov 6, 2015 at 2:47 PM, David Brodbeck <brodbd at uw.edu> wrote:
>
>> On Wed, Oct 28, 2015 at 12:02 PM, Jerry Kemp
><sun.mail.list47 at oryx.us>
>> wrote:
>>
>> > I have a (Solaris admin) friend at another company who apparently
>has
>
>> quite a few friends/colleagues/etc who are running Solaris or some
>Solaris
>>
>
>> based distro at home for ZFS based data storage, and he shared (what
>I
>
>> feel) is a somewhat unique viewpoint for at home user who won't back
>up.
>> >
>> > From a high level view, his comment to them is to NOT run a mirror.
> His
>> > suggestion to them is to just run a straight drive, then every
>evening or
>> > downtime, bring the other disk(s) online and sync them with the
>online
>> > master, using rsync, or your favorite utility, then once the sync
>is
>> > complete, offline the newly synced data and put it away.
>>
>
>This doesn't make any sense. These friends are presumably able to
>afford
>backup storage, but by definition they, for whatever reason, "won't
>back
>up." So his solution is to tell them to do backups?
>
>
>> I actually was going to suggest the same thing.  I hate to be a
>Monday
>> morning quarterback, but I think this is a really important point
>that's
>> often overlooked.
>>
>> If you can only afford two disks, mirroring them is not the best way
>to
>> handle data security.  Even if you ignore file system corruption,
>think of
>> the simple case of accidentally deleting a file.  A mirror won't help
>you
>> because it'll be gone from both mirrors.
>
>
>I'm not buying the "can't afford it" situation. A given budget allows
>for a
>certain amount of storage given the owner's acceptable level of
>reliability
>and data integrity in the primary storage and safety in the form of
>backups. If someone decides to toss out safety by maximising storage
>and
>not having backups then that's their choice, but don't come crying to
>us
>when the data is lost. (I'm not saying we that we shouldn't try to help
>them, but I'm not going to feel sorry for them either.)
>
>For instance the original fixed income poster has the following drives:
>1 x
>500 TB, 1 x 2 TB, 2 x 3 TB and 1 x 4 TB. When he say's that he can't
>afford
>to back it up what he's really saying is that he has data that's
>important
>enough to purchase ~9-12 TB of storage for (depending on how it's
>configured) out of his fixed income, but that isn't important enough to
>back up. If that data is something like TV shows and movies then this
>makes
>sense, it's data that is easy to replace and his time to do so has a
>lower
>value (to him) than the cost of backups.
>
>But I'm will to bet that that isn't the case. (At least in the whole.)
>I
>think that the OP needs to come to terms with the fact that, given his
>budget, he can really only afford 6 TBs of nonredundant primary storage
>with backup and the accompanying risk that silent corruption will
>migrate
>to his backups before ZFS flags it in primary storage—resulting in the
>complete loss of that data. Or that he can have 3 TBs (2 x 3 TB mirror)
>of
>primary storage with data integrity and backups.
>
>What you want in that situation is to use one disk for storage and the
>> other for backup.  This also ensures they'll have different usage
>rates,
>> which will probably lower the likelihood of a common flaw causing
>both to
>> fail simultaneously.  (If you can get disks that are different brands
>> altogether, so much the better.)
>>
>> The way I usually explain it to people:
>>
>> - Mirroring is for *reliability* -- so the system can keep
>functioning
>> during a disk failure.
>> - Backups are for data recovery.
>>
>> Usually in a home situation you don't care that much about
>reliability; if
>> the server is down for an hour while you swap a disk it won't matter
>much.
>> Even at work I usually only use redundant disks in systems that are a
>> single point of failure for the network as a whole.
>>
>
>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.
>
>Phil
>_______________________________________________
>openindiana-discuss mailing list
>openindiana-discuss at openindiana.org
>http://openindiana.org/mailman/listinfo/openindiana-discuss

Actually, corruption should not 'get passed to backups before zfs detects and flags it as such'. ZFS gets to the leaf blocks just like any intermediates: it has a blkptr with dva (an offset and device where to start reading), ondisk data size and checksum of those raw bits. When it reads the bits from disk, it checksums the data to make sure it is intact.

So rsync'ing a file under which a disk-sector just died, and lacking enough redundancy to recover automatically, you'd get an i/o error and no (complete) data transfer. (Not sure if transport errors like noise intercepted by cabling can be ruled out - if zfs retries a request just in case or not).  

You don't have to wait for scrubbing to "flag" the errors, if that's what you meant.

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android