Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!jarthur!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!rutgers!netnews.upenn.edu!dccs.upenn.edu!litwack
From: litwack@dccs.upenn.edu (Mark Litwack)
Newsgroups: comp.unix.ultrix
Subject: Re: Multivolume dumps via dump | compress | dd
Keywords: dump dd compress multivolume tk50
Message-ID: <21904@netnews.upenn.edu>
Date: 19 Mar 90 23:35:55 GMT
References: <9908@cbmvax.commodore.com> <25276@ut-emx.UUCP>
Sender: news@netnews.upenn.edu
Reply-To: litwack@dccs.upenn.edu (Mark Litwack)
Organization: University of Pennsylvania
Lines: 28

In article <25276@ut-emx.UUCP> jeff@nic.the.net writes:
: I'm trying to save some space and time by compressing my dumps before writing
: them to tk50 on my DS3100 running UWS 2.1.  I use
:
:       dump 0ucf - /usr | compress | dd of=/dev/rmt0h obs=60k
:
: to write a dump, which seems to work fine. dd prompts me to replace
: cartridges
: when appropriate, and dump seems happy.
:
: A restore of the form
:
:       dd if=/dev/rmt0h ibs=60k | uncompress | restore if -
:
: works, until the end of the first tape is reached.


It seems to me that using compress for doing backups is not a good idea.
If you get a bad spot on your tape and cannot read it, the rest of your tape
will be unreadable since uncompress cannot continue uncompressing with
missing blocks in the middle of the file.

Restore by itself will at least attempt to re-sync itself if it encounters
bad areas on the tape.

Dump really needs to do a compress for each file it saves.

-mark