Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.questions
Subject: Re: Backups using compress
Message-ID: <11170:Dec507:48:0390@kramden.acf.nyu.edu>
Date: 5 Dec 90 07:48:03 GMT
References: <275A875A.3AB0@tct.uucp> <26547:Dec404:51:1690@kramden.acf.nyu.edu> <59378@aurs01.UUCP>
Organization: IR
Lines: 20

In article <59378@aurs01.UUCP> throop@aurs01.UUCP (Wayne Throop) writes:
> 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.

Yes, it was quite clear. And there's no reason an error-correcting code
can't detect and correct shift errors to handle losing a block. Losing a
tape is rare---I don't think it's happened here, anyway. But then again,
we've never had the computer center and all backup sites bombed, either.
Maybe your experience differs.

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

Hate to tell you this, but that's a (primitive) error-correcting code.

---Dan