[OpenIndiana-discuss] Broken zpool
Philip Robar
philip.robar at gmail.com
Sat Nov 7 20:55:15 UTC 2015
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
More information about the openindiana-discuss
mailing list