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

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

> >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.



Reply to: