Re: backup archive format saved to disk
On Thu, Dec 07, 2006 at 04:36:02PM -0600, Ron Johnson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/07/06 16:27, Mike McCarty wrote:
> > Ron Johnson wrote:
> >>
> >> RAID is *not* for archives!!!
> >
> > RAID was not designed for archives. I can see no reason why
> > it wouldn't work for that. RAID 1, for example, is simply
> > making two (or more) copies of the data. Are you saying that
> > making more than one copy of a backup is not a reasonable
> > approach?
> >
> [snip]
> > The main advantages would be that one would essentially
> > have burst error correction of the size of the disc
> > (this being, with the FEC on the disc, if any, an
> > interleaved code in effect), which is enormous, indeed,
> > and economy in storage over using multiple copies, as
> > illustrated above.
>
> I'd only trust "RAID archiving" if the controller and a rescue CD
> were also stored in the "archive location" along with the hard drives.
In the case I'm talking about for raid is in the case of my current
raid1 of my system. Vanialla Etch LVM on MD. The "controler" is the
linux kernel. Each of my existing disks can boot on its own (since grub
can't read two MBRs at once, but my bios can boot either drive since I
installed grub into the MBR of both). That takes care of /boot on md0.
md1 is vg0 with lvm on top. Its all taken care of nicely by the kernel
and the initramfs.
For backing up this 80 GB pair of drives, I would use an 80 GB laptop
drive partitioned exactly the same. Add each partition into its
corresponding raid1 array and get it to sync. Install grub onto its
MBR. Remove it from the array and you have a perfect copy. If disaster
strikes, buy a new computer with new drives, hook up the laptop drive
and boot. Partition the new drives and add them to the (degraded)
array. Then remove the laptop drive fromt the array. You're back where
you started (except for hardware changes). (Thanks to Len Sorensen on
the amd64 list for this idea).
This is neat and elegant but doesn't address the issue of the backup
drive's failure if such failure is non-atomic. Actually, it means
forcing drive failure to be atomic since there is no FEC underlying the
md arrays except the drive's ECC. I wonder how long it would take my
Athlon 3800+ to calculate an SHA-sum of the raw partition? Write the
sum on the outside of the drive. The can boot it up in ro
(init=/bin/sh) and calculate it again. If its the same there should be
no files missing or corrupted.
As far as rescue CD we run into the problem of the longevity of CD-ROM
media. Yes I would have Etch netinst CD (on a 2" disk) but I would also
have a USB stick set up with hd-media and the full CD1.iso (so I have
the installation manual, readmes, etc). I don't know how long a USB
stick lasts in storage; they haven't been around for 10 years (yes I
know that EEROM has been around for a while). Hard drives have been
around for a while.
Doug.
Reply to: