Subject: Re: backup: dump | gzip | cdrecord ?
To: None <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 08/25/2005 11:39:11
On Thu, 25 Aug 2005, Geert Hendrickx wrote:
> On Sat, Aug 06, 2005 at 03:23:37PM +0200, Geert Hendrickx wrote:
> > One solution would be to embed gzip into dump(8) (and gunzip into
> > restore(8)), so dump can start a new volume when the *compressed* data
> > has reached a predefined size. Or, more generally, we could define an
> > extra command line option for dump so that it accepts a command
> > (sequence) through which it pipes all the data before writing it to
> > tape/file. Then the user can pipe it through anything he wants, be it
> > gzip, gnupg, ... Same for restore, of course.
Of course, stream compression assumes zero corruption on the tape, which
becomes more probable as the tape dump gets larger. Once a corrupted block
is hit, the rest of the dump is unusable (or at least, a pretty huge chunk;
things like bzip2recover can reset the decompression every once in a while
in the data stream).
> It would be very nice if NetBSD's dump would support compressed output too.
...if the compression were on a per-file basis, not a whole-dump basis, so
that the risk of middle-of-dump corruption is minimized.
-- Todd Vierling <email@example.com> <firstname.lastname@example.org> <email@example.com>