Re: Are you waiting?

On Thu, 4 Oct 2007 13:12:56 -0400, Phil <Phil.Yff@xxxxxxxxxxx> wrote:

On Wed, 03 Oct 2007 21:41:10 GMT, Abraham Evangelista wrote:

RAID or Redundant Array of Independent Drives

I should mention that I differentiate between mirroring (RAID level
1,) and the other traditional RAID levels involving all that nasty
error recovery, parity generation, multiple unit "striping" and what
not. :-)

I should also state that a mirror is still not a backup, even if its
offsite. :-) (tee-hee-hee)

<Snip!>

Pet peeve of mine. So....

I hope you don't take this the wrong way.

No offence taken at all. (And to be fair I was more than a bit
brusque in my original post.)

A pet peeve, by definition, is a
personal annoyance and not a universal fallacy.

Maybe it really is a pet peeve. Laymen still think of RAID as a
backup. It's not, and I just can't help but jump whenever it's even
implied that it is.

(Note to trolls: If you wanna get Abe's hackles up, data recovery is
the topic of choice.) :-)

It looks like you are
confusing some specific implementations of the RAID concept with the
concept itself. RAID is a concept based on a 1978 patent. Google United
States Patent 4,092,732 (include the commas) in order to get the full text
in pdf format.

The title of the patent is, "System for recovering data stored in failed
memory unit". The main concept is articulated in the following sentence,
"The check sum segments and the associated system record segments are
stored on different units so that if one unit containing a system record
segment becomes unavailable, the unavailable segment is reconstructed
during transfer of the other available segments and the check sum segment
to the CPU."

The key concept is that you have an automated process for reconstructing
data on a different unit should one unit fail. The most narrow
interpretation of this concept is for the different units to be colocated.

In fact, the two memory units can be different logical units of the same
physical disk or drive.

Yup. And while that protects you from the failure of a logical unit,
it sure doesn't protect you from the failure of the physical unit. And
when that physical unit goes, so does your data. IT's the eggs/basket
argument all over again. :-)

That'd be like doing backups and NOT sending them off-site. You could
do it, but it's definitely not good practice.

However, the different memory units need not be
colocated. This concept which was originally formulated in the mainframe
environment is used extensively by large computer operations in
continuation of operation strategies to survive catastrophes.

I may be betraying my ignorance here, but I've never seen a RAID setup
that spanned multiple sites. Mirroring yes, but not RAID.

To extend the concept a bit, I've seen whole site duplication. I
wouldn't call that RAID. (I would however consider it to be a pretty
good disaster recovery plan!)

<RANT!>

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! NO! NO! NO!

RAID is not backup.
RAID is not backup.
RAID IS NOT BACKUP.

Agreed. Backup is backup and can be accomplished in many ways. RAID is a
system for recovering data stored in failed memory units. Depending on how
you implement the RAID concept, though, the data in a good memory unit used
to reconstruct the data in the failed memory unit can be considered as a
backup of the data in the failed memory unit.

I'd consider that stretching the concept of backup. IMO backups
protect from both data corruption, and unit failure. The price paid
is in downtime. As always, the question is, which is more important
to the client? Time? Or the Data?

I admit though that you're probably right in SpaceGirl's case. Working
past a failed disk is far more likely than her having the studio burn
down. That said, if the studio goes, RAID as commonly implemented
won't help in the slightest. (Although to be fair she's got downtime
anyway since she'll have to replace the equipment in additon to
restoring the data.)

You will, of course, recall that I made the point that the end state was
continuity of operations and not backup for the sake of backup.

Fair 'nuff. Nothing beats being able to keep working. But being able
to keep working in the case of single disk failure is not the same
thing as being able to resume work later in the event of site
destruction. :-) More to the point, your original response (which to
be fair, I really should have quoted!) was to address the issue of
automated archival.

IMHO RAID doesn't do archival. Period. I do like the suggestion of a
content management system though! That should do the archival nicely.

RAID protects you from a certain number of disk failures.

You should note that I did say that I was presenting the issue
oversimplistically. I did distinguish, though, between recovering data
where a local disk failed and recovering data when the site was destroyed.

And here's where I get to the meat of things. RAID protects data from
the failure of one (or possibly several) data units.

A proper scheme of offsite backups protects the data from the failure
of ALL UNITS. In a proper full/incremental scheme, it also provides
at the very least some rudimentary version control and limited
archival. These are all things that RAID in its most commonly
implemented forms simply doesn't provide.

I'm tempted to say that RAID saves you downtime, but backup saves your
data, but really that's again oversimplifying the situation.

The RAID concept includes using a geographically remote memory unit to
reconstruct data even if the data to be reconstructed was destroyed during
the destruction of an entire site.

I shudder to think of how that would aside from mirroring. Of course
duplicating the entire site is best! (And of course the msot costly.)
:-)

RAID will not protect you from:

- Destruction of the site. (Offsite backups for that.)
- Stolen disks/machines. (Again, offsites.)
- Damaged/corrupted data. (Incremental backups for that.)
- Deleted data. (Incrementals!)
- Poor version control. (Again, incrementals.)

RAID, in itself, is a technological concept. Thus, in and of itself, it
does not protect you from any of the above. However, the technology can be
used in a cohesive plan that protects you from a wide assortment of
potential failures.

I agree that a business needs protection from everything that you list
above. However, one must distinguish data quality assurance from
recovering from physical damage.

And maybe, just maybe that's what REALLY gets my goat. Allow me to
make a qualifying statement and rephrase my rant ever so slightly.

RAID is fault-tolerance.

Fault-tolerance is not backup.
Fault-tolerance is not backup.
FAULT-TOLERANCE IS NOT BACKUP.

People (and I'm not saying you, or spacegirl for that matter) confuse
fault-tolerance for backup. To an extent, any setup where the data is
of any value should absolutely have both. And neither one is a
substitute for the other.

I've had plenty of consumer clients who spent lavishly on exotic
fault-tolerance systems. And they've all still cry when they
experience non-fault-related (often PEBCAK induced) data corruption
and realize that I wasn't being paranoid when I told them to keep
doing their backups. :-(

An organization uses business processes
to ensure the correctness of data including configuration and version
control.

Absolutely 100% in agreement.

Data recovery operations recover only the data as it was created. If
business operations do not have quality control checks to provide for the
veracity of data, no continuity of operations plan will be able to make
chicken soup from the proverbial chicken excrement. In other words, your
data strategy has several pillars. One pillar ensures that you are
creating and storing the right data. Another pillar ensures you can take a
licking and keep on ticking. Other pillars deal with security,
distribution of data, and other critical issues associated with the data.

And here is where I sheepisly admit that Phil more eloquently states
exactly what I was thinking just upstream. :-)

RAID and Mirroring provide faster recovery from disk hardware failure.
No more, no less, and most definitely no substitute for a real backup!

</RANT>

I think the reason you are ranting is because you are confusing specific
hardware implementations of the RAID concept (RAID disks, RAID cards, or
other devices with a RAID controller) with the RAID concept itself.

Bad terminology. Strike the "real" qualifier. What I'm really trying
to do, (and hadn't stated clearly enough) is to differentiate between
fault-tolerance and backup. To non-IT folks, it's nitpicking, but
AFAIC the understanding the difference between them is absolutely
crucial in formulating a disaster recovery plan for your data.

Over
the last 30 years, the RAID concept, based on the 1978 patent, has been
used in very sophisticated restoration strategies. I don't know what you
mean by a 'real backup'. I, myself, feel that large corporations and
governments should be able to withstand the destruction of a site as the
result of a calamity and be able to continue operations at another site.
The RAID concept can be used as implementing technology in a comprehensive
continuity of operations plan to effectively do just that.

I completely agree and I'd even go so far as to say that RAID in one
of it's many forms is an essential part of implementing continuity of
operations. But as you stated in the original post, (and I'm inclined
to agree) it's not a magical panacea for data recovery.

There's that, and then there's the fact I die a little inside every
time someone I know loses data on a mirror or stripe set, and doesn't
have a backup lying around even thought I tried my damnedst to get
them to make one. :-(
--
Abraham Evangelista
.

Relevant Pages

  • Re: RAID vs. non-RAID?
    ... > RAID 0 splits the system on two physical hard drives. ... > RAID 1 backs up the first hard drive to the second one. ... Mirroring is *not* suitable for using as backup. ...
    (microsoft.public.windowsxp.newusers)
  • Re: Best backup
    ... Mirroring, in this case RAID 1, is for backup in case of hard drive failure. ...
    (microsoft.public.windowsxp.general)
  • Re: RAID Setup with Offline Spare
    ... I hear what you are saying that RAID is not a backup system. ... There are many ways to lose data - hard disk failure is only one situation. ... RAID can't do point-in-time snapshots or backups. ...
    (comp.os.linux.misc)
  • Re: RAIDING different size drives
    ... failure regardless of what what happens when part of it fails. ... Having no experience with windows software raid, I did not know if there were any complications involved. ... But I am now happy to hear that recovery from failure in this situation is straightforward, and therefore this sort of raid setup does offer useful protection. ... That's why testing your restore procedure is so vital - many people believe they have good backup procedures, but have problems when they have to do a restore. ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: Wiederherstellung RAID-Backup
    ... fertige dann endlich ein komplettes Backup an und bewahre es gut ... Anwendungszweck besser, wenn man nicht nur auf Prestige "Raid5" setzt, ... Experimente mit Softwareerweiterungen auf dem Raid wenn das Backup ... Dazu muestest Du die Firmware des Raid gut genug kennen. ...
    (de.comp.hardware.laufwerke.festplatten)