Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!psuvax1!rutgers!att!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: comp.unix.i386 Subject: Re: backups on 386/ix - some pronblems using GNUtar; any hints? Keywords: backups, 386ix, GNUtar, tape streamer Message-ID: <1989Dec5.232732.16194@chinet.chi.il.us> Date: 5 Dec 89 23:27:32 GMT References: <481@hades.OZ> Reply-To: les@chinet.chi.il.us (Leslie Mikesell) Organization: Chinet - Chicago Public Access UNIX Lines: 34 In article <481@hades.OZ> greyham@hades.OZ (Greyham Stoney) writes: >1) When the tape is completely full, GNUtar reports "error opening >directory ...." for every directory not yet covered. At least, this seems >to be what's happening. If the tape drive is 120Mb, and the filesystem is >115Mb, how come the tape fills up at all anyway when doing a full dump???. Keep in mind that the minimum header block for a tar file is 512 bytes even for zero length files or linked files that take no actual disk space. Try tarring /usr/lib/terminfo to see the problem. There is also a possibility that you have sparse files that have their "holes" filled when you copy them. >2) When doing a compressed TAR, gnutar's return code incorrectly indicates >that the tar went OK even if the tape is write protected. Our dump script >relies on this return code to know whether or not to update the automatic >tape-contents register we've got. That probably could be fixed, although I'd rather see per-file compression so you have some hope of recovery if you have a media error during a restore. Anyone working on this (or cpio format output)? >Has anyone got any hints, or even just general ideas on the best strategy >I should adopt here?. I don't want to hack GNUtar (much); You might want to try cpio to see how much space the tar headers are actually wasting. You could still use GNUtar for the incrementals, since it has a mode where it can delete any files which were not present when the incremental was taken that is handy if the filesystem is nearly full or you want to restore that state. Les Mikesell les@chinet.chi.il.us