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 [email protected] There's an app for that: your browser
pgp6zjqM1VidT.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
