RAID Parity Applications For Cheap Media?

yamgirl asks: "I've been reading up on RAID strategies for protecting against hard disk failure, particularly those RAID levels that involve recording parity on one disk to duplicate data on multiple other drives, and I've been thinking that this would also be wonderfully useful in making backups to CDROM, or even floppies. Many's the time when I've had a bagful of floppies with me, trying to install something, and found that one floppy out of the batch had crapped out, rendering the rest useless until I went home and got a new copy. If I could make a RAID-style parity disk whenever I needed to make multiple-volume disk sets, I'd only have to carry around three extra disks (one blank to write a new copy on to in case of emergency, and one disk to keep the recovery software on - but the latter two I'd just need one each of for any number of separate sets of parity disks and multi-volume sets of media.) as very effective insurance against crappy disks. Much cheaper in time and effort and disks than making entire extra copies of multi-volume sets, or for that matter of needing to go off site to track down a new copy. ANYHOW, my question is, has anyone ever seen or written any software to do this, to generate parity disks and to recover lost data with them? (And is it free? =)"

3ware ATA Raid Controller?

[SEWilco]

You could check if the 3ware.com [3ware.com] disk controller will work with removable media. It does RAID on multiple IDE drives, with separate IDE channels to each drive. It was in the Linux area at COMDEX.

It's been done with CDs

[penguinboy]

Someone already did this with CD-Rs. They set up a stripe set on a bunch of CD-Rs to speed up access by putting all the CDs into a CD-ROM tower and accessing all of them at once by mounting all the CDs as a RAID volume. I wish I could find, the link, but I lost it. Try Google-ing for "CD RAID Linux"

Re:It's been done with CDs

[penguinboy]

Found the link on Google: http://www.crosswinds.net/~technos/cd rom.html [crosswinds.net]. Although the how-to deals with RAID-0 , you could probably do RAID-5 if you were feeling ambitious enough...

why ?

[Zurk]

RAID is for hard disks with large amounts of changing data. its not just one parity disk..RAID systems use around 30-40% of the disks striped with parity information plus a log disk (extra) in RAID-5. youre better off with just one entire mirror of your data on a different set of disks.
read a bit more about RAID - its slightly different to what youre thinking.

Re:why ?

[Zurk]

umm..no. most software packages (e.g. the veritas, sun and HP volume managers that i use) ALL recommend a dedicated log disk. this is because in an array if an operation fails the only think that would help recover it (besides the NVRAM battery which protects the battery backed NVRAM cache on a hardware raid device) is the log disk. so..it may not be strictly required by the definition but you would be extremely *stupid* to not have it.

Maybe possible on linux, but floppy isnt feasible.

[csoh]

I've seen some possibilities on the old slashdot article [slashdot.org]. Someone posted the idea of making cd-raid0 backup and this smart person even posted the HOWTO on his page [crosswinds.net]. Maybe you can modify this method to do cd/floppy-raid5, but I personally think making floppy-raid5(or floppy-whatever redundant method by any software) is not worth doing in your case because you need same software to regenerate the dead disk(s) on the remote site. And, by the way, how are you going to carry your regeneration software with you? Same floppy disk that are subject to crap out?

I think it's better to make the image file(s) of the floppy disk(s) and backup the entire sets and imaging program to more reliable and useful media like CD-R(though it's not that reliable, too) or your notebook(it's cumbersome though) before going out so that you'd only have to carry one additional CD (or heavy notebook) and one additional blank floppy to reduce the chance of disaster. Anyway, if you have large piles of the floppy backups already, you should backup these unstable magnetic timebombs(with random timer setup) to other media as soon as possible!

It would make more sense to use a new disk format.

[Tau Zero]

Back in the days when people actually backed up on floppies, there was a company which had a pretty convincing demo of their software's recovery capabilities: they took a backup floppy, made a hole in it with a hole punch, and read all the data back regardless.

This isn't rocket science, and it wouldn't be all that difficult to do the same thing today. All you'd really need to do is to create a disk format that allows you to scatter file data across the floppy and reserve some fraction of the disk for parity or Hamming code sectors, which you use to reconstruct any sectors you lose. You'd have to be sophisticated about where you arrange your data (if you lose too much of the redundancy for any one part, your data is still toast) but this would allow you to manage things on a single floppy. Now that I think about it, it shouldn't be too hard to make a parity file which occupies certain tracks (say, the inner 8 tracks) and use the sectors on those tracks as parity for the other 72. With a little sophisticated software, you could recover any single lost sector or track.
--

Re:why ?

[flawed]

Aren't you mixing RAID and logging/journaling file systems?

Err... floppies?

[Wakko Warner]

Why not use a relatively recent technology -- burn two copies of whatever data you need to CD or CD-RW. The chances of both CDs becoming corrupted is much less than that of a single one doing so, and certainly much, much less than that of a floppy.

The only thing floppies should be used for nowadays is propping up wobbly tables.

- A.P.
--

"One World, one Web, one Program" - Microsoft promotional ad

Re:It would make more sense to use a new disk form

[Detritus]

I think I had a copy of that program. It was an MS-DOS backup program that wrote a parity sector on every track. This allowed it to recover from disk errors as long as no more than one sector was bad on any given track.

Simple parity?

[DaveHowe]

Hmm. Theoretically, if you broke up the disk array into a spanning archive (as arj will) then it should be semi-trivial to generate a final parity disk.
If you have nfiles each one-floppy big (arj1 to arjn) you can then generate a final parity file by simply xoring all the nfiles together, to give a file equal in size to the largest file that makes it up. should any single floppy in the set fail, then exactly the same utility will allow you to xor all the remaining files, plus the parity file, and gain back the original (missing) file.
obviously this will only protect you from ONE missing disk however, but it is better than nothing :+)

I imagine you could do the same thing on a disk-image basis, but it would require much more specialized access to the low level floppy calls to get "raw" reads of the disk sectors for the operation, whereas a simple file XOR can be knocked together in MS Quickbasic in five minutes, and as a under-one-k executable in ten :+) - if you don't want the bother of writing one yourself, a simple websearch on One Time Pad implimentations will turn up several dozen - with source.....
--

Not that hard..

[technos]

As several people have pointed out, RAID-(X) is trivial to do with CD-R/RW, and is easily usable on floppies. I use it all the time. Several other people have linked to my shoddy HOWTO [crosswinds.net] on CD-RAID, and that will get you going if you really want a RAID. Keep in mind that it is totally unusable unless you have a system with (n) CD/floppy drives or enough spare HD space to hold (n-1) cd images.

I wouldn't do it with floppies. Disk images on a bootable CD-R/RW work quite well. If a disk craps out, boot to the CD and make a new disk image. Writing a bootable CD with a small Linux or *BSD install and all of the images is easy. Of course, that means you have to carry (n + 1) + backup CD, but that shouldn't be terrible.

Re:It would make more sense to use a new disk form

[technos]

Custom FS, and reduced volume may be tolerable. What about storing the parity information outside of the normal disk area? Say we're working with 1440k floppies. You can actually fit 1600k on the disk. Use the first 1440k for a MSDOS/MINIX/etc filesystem, and the remaining 160k for parity.

You'd need at least nine disks in the set, and you'd have to carry (n>9)+1 disks (the extra disk being the rebuild utility) but they would seem to any unknowing PC to be ordinary install media. No custom filesystem, and probably easy to implement.