On Jul 9, 2006, at 12:42 PM, Richard Elling wrote:
Ok, so I only managed data centers for 10 years. I can count on 2
fingers
the times this was useful to me. It is becoming less useful over time
unless your recovery disk is exactly identical to the lost disk. This
may sound easy, but it isn't. In the old days, Sun put specific disk
geometry information for all FRU-compatible disks, no matter who
the supplier
was. Since we use multiple suppliers, that enabled us to support some
products which were very sensitive to the disk geometry. Needless to
say, this is difficult to manage over time (and expensive). A better
approach is to eliminate the need to worry about the geometry. ZFS is
an example of this trend. You can now forget about those things which
were painful, such as the borkeness created when you fmthard to a
different disk :-) Methinks you are working too hard :-)
Right. I am working too hard. It's been a pain but has shaved a lot
of time and uncertainty off of recovering from big problems in the
past. But up until 1.5 weeks ago ZFS in a production environ wasn't a
reality (No, as much as I like it I'm not going to use nevada in
production). Now ZFS is here in Solaris 10.
But you hooked into my point too much. My point was that keeping
backups of things that normal B&R systems don't touch (such as VTOCs;
such as ZFS volume structure and settings) is part of the "Plan for
the worst, maintain for the best" ethos that I've developed over /
my/ 10 years in data centers. This includes getting everything from
app software to the lowest, deepest, darkest configs of RAID arrays
(and now, ZFS) and whatnot back in place in as little time and with
most ease as possible. I see dicking around with 'zfs create blah;zfs
set foo=bar blah' and so on as a huge time waster when trying to
resurrect a system from the depths of brokeness, no matter how often
or not I'll find myself in that situation. It's slow and prone to error.
I do agree that (evil) quotas and other attributes are useful to
carry with the backup, but that is no panacea either and we'll need to
be able to overrule them. For example, suppose I'm consolidating two
servers onto one using backups. If I apply a new quota to an existing
file system, then I may go over quota -- resulting in even more manual
labor.
I'm talking about nothing beyond restoring a system to the state it
was prior to a catastrophic event. I'm just talking practicality
here, not idiosyncratics of sysadmin'ing or what's evil and what's not.
/dale
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
