Re: backup archive format saved to disk
On Tue, Dec 05, 2006 at 07:55:40PM -0600, Mike McCarty wrote:
> Douglas Tutty wrote:
> >On Tue, Dec 05, 2006 at 06:57:38PM -0600, Ron Johnson wrote:
> > >
> >
> >The question is, if a block is sucessfully written now, if the drive is
> >not used for 5 years then a read is attempted, is the drive able to
> >retreive that data using ECC (as a tape drive could)?
>
> I thought the question was "How can I be sure I can get my data back?"
> So far, some people have suggested few techniques to accomplish that,
> but all I've seen is complaints in response.
I'm not complaining Mike. Also, note who's saying what; there's a few
voices in this conversation.
Please don't take my questions the wrong way.
I am very gratefull for the wisdom. I'm just trying to tease apart
where failures can occur and what can mitigate them.
>
> I guess I don't know what the question is.
>
> >Since I don't __know__ that it can, I'm assuming that it can't. I'm
> >playing my own devils advocate and trying to find out how to plan to be
> >able to read successfully off a drive with bad blocks after years of
> >sitting on a shelf.
>
> IF this is what your goal is, then, as I pointed out, you can implement
> your own FEC.
>
Yes I could. The origional question was to see if one existed already.
> >I'm focusing on the one-drive issue because this is one drive sitting in
> >a bank vault. This is __archive__ (just like tape). I have backup
> >procedures as a separate issue. One of the places that backup data goes
> >to is the bank vault archive.
>
> If the issue is a drive, then you need more than one drive. If the
> drive itself fails, then you are SOL.
>
So drive failures are atomic? I.e. if in 5 years I go to read a drive
and it has errors, everything is toast? I'm wanting a data-stream
format (call it a file system, an archive format, whatever) that can
withstand those errors.
> >In the absence of an all-in-one archive format, I'll use tar (which can
> >detect errors just not fix them) to take care of names, owners,
> >permissions, etc. Then that tar needs to be made ECC and compressed.
> >If I want to throw in a monkey, I'll consider encryption.
> >
> >Yes tape drives do that. Its probably why they cost so much. Hard
> >drives are much cheaper and are supposed to be able to hang on to their
> >data (Seagate gives a 5 year warranty). But having seagate give me a
> >new drive when I can't get my data off after 4 years is cold comfort.
>
> Hard disc drives use FEC (usually a BCH 11 bit redundant code).
> If you want to be able to read more reliably than the FEC already
> present, you'll have to add your own.
>
> >The other problem with tapes is their fragility. Drop a DLT and I'm
> >told that its toast. Put that tape in the drive and I'm told it can
>
> The most common cause of that is edge damage.
>
> >damage the drive. A laptop drive in a ruggedized enclosure is much more
> >robust and has a wider environmental range.
> >
> >Perhaps what I'm looking for doesn't exist. If it doesn't, I'll start
> >work on it.
>
> Hmm. You going to become an expert at designing ECC? I suggest you take
> a course in abstract algebra first.
>
Can (or at least I used to be able to) do the algebra, but that's not
the issue. There are programs like par2 that do the ECC stuff but put
it in separate files. If I went that route, I just have to pack it all
together.
> >As far as computer history prior to 1991, I could never get the hang of
> >C. I'll stick with fortran77.
>
> Which progamming language one uses is less important than the algorithm
> implemented.
>
True.
Thanks.
Doug.
Reply to: