Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!aurs01!throop
From: throop@aurs01.UUCP (Wayne Throop)
Newsgroups: comp.unix.questions
Subject: Re: Backups using compress
Message-ID: <59378@aurs01.UUCP>
Date: 4 Dec 90 16:15:24 GMT
References: <27551FBF.2222@tct.uucp> <11389:Nov3010:16:4190@kramden.acf.nyu.edu> <275A875A.3AB0@tct.uucp> <26547:Dec404:51:1690@kramden.acf.nyu.edu>
Sender: news@aurs01.UUCP
Lines: 26

>> chip@tct.uucp (Chip Salzenberg)
>>>,> brnstnd@kramden.acf.nyu.edu (Dan Bernstein)

>>> If you want to correct errors, use an error-correcting code.
>> Sure, error correction is very nice.  But sometimes data are lost,
>> period, no recourse, from the *middle* of a backup.
> ``But if someone bombs your computer center and all your offsite storage
> locations then you probably won't be able to recover the backup.''

I thought it perfectly clear that Chip was talking about losing a block
from the middle of a tape from "bit rot" or "alpha particles", or
losing a reel from the middle of a multi-reel backup by misfiling,
exposure to a kitchen magnet, or whatever.  That is, he was talking
about simple, plausible ways of losing many thousands of consecutive
bits, which error correcting codes cannot reasonably deal with.

I don't know about the archiving Dan depends upon, but these types of
of errors are all too common in my experience.  Certainly such
occurences are not nearly as remote as the example Dan uses in
attempting to downplay the likelihood of such losses.

On the other hand, I'd think a little thought and a slick shell
script or two could arrange to use (say) tar and compress to write
compressed archives with "sync points" built in, so that missing
data's impact is limited.
Wayne Throop       ...!mcnc!aurgate!throop