i don't know. if you lean that direction, then the only thing raid
gives
you is reduced downtime.
On reflection, it seems I do lean that direction, and generally use
raid mainly to dodge downtime. Our plan 9 systems (and `other' alike)
mostly have redundant disks (when they must have them at all) -- but
they have regular offsite backup also. I wonder if I'm being wasteful.
i think of raid as reliable storage. backups are for saving one's
bacon in
the face of other disasters. you know, sysadmin mistakes,
misconfiguration,
code gone wild, building burns down,
meteorite! ;)
(and if my experience with backups is any indiciation, it's best
not to
rely on them.)
Probably another discussion, but I try to deal with this by testing
the offsite backups (rdarena output) of the plan9 fileserver against
a similar system that's designated the second-string fileserver. I
haven't had to do it in production in a while, (raid narrowed the
reasons I'd need to) so maybe I'm missing something and it would be
less successful than in the testing.
but this thinking is probablly specific to how i use raid. i
imagine the
exact answer on what raid gives you should be worked out based on
the application.
I probably veer toward mere semantics, but I'd still define your use
of raid to be uptime-protection. The list of exceptions you place
under ``backups are for...'' is the same list, essentially, that
motivates the offsite backups I mention -- the usual holes in the
raid prophylactic. I see how Plan 9 facilities (esp. dump) ameliorate
some of them: admin mistakes, for example. But it doesn't fireproof
the system.
Or, put another way, you're not asserting you have no backup beyond
that fileserver raid, are you? Because if so, I want to learn how I
can skip that step, too.
--
Josh
