[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: backup archive format saved to disk

Ron Johnson wrote:

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.

I gave two examples of RAID archiving which required no
special controller, and which would need to special rescue CD
to use. You snipped those, and didn't answer my question.
I'll ask the question again, and then I'll supply you with
a simple software RAID implementation which I wrote in
less than 15 minutes.

RAID level 1 is simply multiple copies. Do you think that
making multiple copies of the backup is an unreasonable
way to protect data from loss?

One way of doing RAID 5 with three discs is to write data
to each of two discs, and write the bitwise XOR of the
data on the two discs to a third. This requires no special
controller, it simply requires a tiny program. Here's one
in completely portable C:

Separate parity disk is RAID-4, not -5.

Not according to my information.

See http://www.sohoconsult.ch/raid/raid.html

#include <stdlib.h>
#include <stdio.h>

int     main(void) {
   FILE    *Input1, *Input2, *Output;
   int     Chr1, Chr2;

   Input1 = fopen("disc1.raw","rb");
   Input2 = fopen("disc2.raw","rb");
   Output = fopen("disc3.raw","wb");
   if (!Input1 || !Input2 || !Output)
       fprintf(stderr,"unable to open files\n"), exit(EXIT_FAILURE);
   while ((Chr1 = fgetc(Input1)) != EOF && (Chr2 = fgetc(Input2)) != EOF)
       fputc(Chr1 ^ Chr2,Output);
   if (Chr1 != Chr2) {
       if (Chr1 == EOF)
           Input1 = Input2;
       while ((Chr1 = fgetc(Input1)) != EOF)
   return EXIT_SUCCESS;

Shouldn't these be raw devices instead of files on filesystems?

We're talking about images to be writen to some medium as an example
for backup. In any case, the names in the quotes can be changed
to "/dev/hda", "/dev/hdb" and "/dev/hdc" if you insist on
using direct devices.

Code compiled but not tested. The files disc1.raw and disc2.raw
are the inputs, disc3.raw gets written. This program works both
to create the image, and to recover from a fault in one of the
discs. The shorter disc image is padded with bytes with all bits
off to fit the length of the longer. For recovery this would
need some change, of course, to truncate the output as necessary.

This program has, of course, no error checking or other fancies.
It is a proof-of-concept prototype only. But it shows just how
simple a RAID system can be.

What you've done is create a parity disk.  Useful, but not RAID.

Pardon? Perhaps you are using a definition of RAID I'm not
familiar with. "Redundant Array of Inexpensive Discs"
(some have changed that to "Independent".)

I'll admit that this is not the usual way it is implemented,
but it is certainly RAID to my way of thinking, and conforms to the
definitions I've seen, and uses the same kind of redundant data.

This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Reply to: