Paperkey 1.3

[Mark H. Wood]

On Mon, Jan 07, 2013 at 05:54:15PM +0100, Peter Lebbing wrote:
> On 07/01/13 16:39, Mark H. Wood wrote:
> > I'd suggest assuming some periodic read-only use, since we *should* be
> > testing our backups regularly to discover decay *before* it makes
> > something irretrievable.
> 
> I would assume the decay to make it irretrievable the moment you discover
> it. Hoping the bit flips in a non-vital piece of (meta)data seems like a
> risky backup strategy.

[Hmmm, we are diverging a bit from Paperkey.]

This is why backup formats typically have internal redundancy.
(Printing the data as characters on paper adds a *lot* of redundancy.)
Depending on the medium, you might include error-correcting codes that
can recover from single-bit errors.  If you catch it at that stage,
you can copy it out and discard the failing medium.

Some codes will also detect errors that can't be corrected, so that
you know *now* to throw this medium away and make a new copy of your
other backup.  (You *do* have another backup?)  If you wait, they may
both turn out to be corrupt.

Every backup medium decays.  Long-term backups should be:

o  armored against bit-level decay;
o  tested regularly to detect degradation in progress;
o  replicated (and the replicas housed separately);
o  periodically refreshed or copied to new media.

I realize that most of us don't do any of that which didn't come with
the software, but we should. :-/

Of course, if an active device (like a flash stick) just stops working
and starts smoking, nothing can be recovered from it.  That's one of
the reasons you keep two of them.

-- 
Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
There's an app for that:  your browser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20130108/0b4b90d6/attachment.pgp>