stratton@hpcupt1.HP.COM (Jim Stratton) (08/30/89)
I bet there is a simple answer to this tar question, but after having RTFM,
I can't figure out a solution. In order to make my backups smaller in
size, I compress the tar image using something like this:
tar cf - [files] | compress -c >/tmp/xxx
cd /tmp; tar c xxx; rm xxx
Unfortunately, this method requires that I maintain enough free disk space to
hold the /tmp/xxx file. What I want to do is pipe the output of compress
directly into tar, avoiding the tmp file altogether. Something like:
tar cf - [files] | compress -c | tar c ...
Anyone know what flags I can use to convince tar that I want it to backup
from standard input?
As an alternative to tar, I've tried piping compress to dd but always get
an error writing to the output device.
I am running Xenix/386 2.3.1 if it matters.
Thanks for any and all help!
- Jim Stratton stratton@hpcupt1.hp.comcpcahil@virtech.UUCP (Conor P. Cahill) (08/31/89)
In article <6340004@hpcupt1.HP.COM>, stratton@hpcupt1.HP.COM (Jim Stratton) writes: > In order to make my backups smaller in > size, I compress the tar image using something like this: > tar cf - [files] | compress -c >/tmp/xxx > cd /tmp; tar c xxx; rm xxx > As an alternative to tar, I've tried piping compress to dd but always get > an error writing to the output device. The dd error is probably (and i am really guessing since you didn't display the command you used) caused by the fact that the output from compress is not in a nice blocked format that your output device (maybee a tape?) wants. Under 386/ix I routinely backup 120Meg filesystems to my 60 Meg tape backup using the following command: find . -print | cpio -oBc | compress | dd of=/dev/rmt0 obs=2048k I know this isn't tar, but substituting tar for the find|cpio should work without any problem. The obs=2048k give me a 2Meg output buffer for the tape, so it streams along when it is writing. If you do not have that much memory you might want to reduce it to 50-100 K. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
stratton@hpcupt1.HP.COM (Jim Stratton) (09/01/89)
cpcahil@virtech.UUCP (Conor P. Cahill) writes: >The dd error is probably (and i am really guessing since you didn't display >the command you used) caused by the fact that the output from compress is not >in a nice blocked format that your output device (maybee a tape?) wants. Yes, this is what I'd like to do. Problem is, whenever I try using dd to my tape I get the same error: ... | dd of=/dev/rct0 obs=10k dd write error: I/O error n+m records in x+y records out I've tried many, many different output blocking sizes from 1k up to 1024k; all result in the above. I'm using SCO's tape driver. tar directly to the tape works just fine. ??? -- - Jim Stratton stratton@hpcupt1.hp.com
bob@wyse.wyse.com (Bob McGowen Wyse Technology Training) (09/07/89)
In article <6340005@hpcupt1.HP.COM> stratton@hpcupt1.HP.COM (Jim Stratton) writes: >cpcahil@virtech.UUCP (Conor P. Cahill) writes: >>The dd error is probably (and i am really guessing since you didn't display ---deleted discussion on dd usage--- > dd write error: I/O error > n+m records in > x+y records out >I've tried many, many different output blocking sizes from 1k up to 1024k; >all result in the above. I'm using SCO's tape driver. tar directly to the >tape works just fine. ??? Still not enough info. What values are reported (n+m and x+y)? Could you be exceeding the tape size? dd will fail at end of tape while tar will (depending on version) prompt for another volume (ie tape). Bob McGowan (standard disclaimer, these are my own ...) Customer Education, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com