🚀 go-pugleaf

In article <8905232207.AA18283@bu-it.BU.EDU> eap@BU-IT.BU.EDU (Eric A. Pearce) writes:
> 
>   I am thinking of using GNU Tar on a "production" system for backups.
>   I'd be interested in hearing war stories and problems with relying
>   on it for all your backups.  I know some of FSF machines use it.

The version I'm currently using (1.05) has a memory leak which kills it on
our VAX (a VAX750 running 4.3 Tahoe with about 30M of VM and 1.5G of files
to back up) way into a full level 0 dump.  I don't know yet if later versions
have the same problem, and I haven't had time to diagnose and fix it.  I
posted some bugfixes and enhancements to this group a bit ago -- see that
article for details...

Once I get it debugged, we will be relying on it for all our backups
on this machine -- it's features are just what I want.

					Bart Massey
					TV Systems Engineering
					M.S. 58-639
					627-5320
					bart@videovax.tv.tek.com

In article <8905232207.AA18283@bu-it.BU.EDU> eap@BU-IT.BU.EDU (Eric A. Pearce) writes:
>
>  I am thinking of using GNU Tar on a "production" system for backups.
>  I'd be interested in hearing war stories and problems with relying
>  on it for all your backups.  I know some of FSF machines use it.
>  Has someone done full restores with it?  (I imagine you would have to
>  make your own "miniroot" with GNU tar on it).

I have not used it for backups myself, but one thing to watch out for is that
tar images of things like dbm files can cause you some problems. DBM files
do not actually take up as much real disc space as they claim to when you do
an ls -l. This is do to the fact that they have empty blocks in their inode
block list which don't have real disk pages associated with them since they
never get referenced. You can see this if you look at the difference between
what ls -l and ls -s say the file sizes are.

For example:

-rw-r--r--  1 root       217088 May 25 15:12 /etc/yp/csri/passwd.byuid.pag

 152 /etc/yp/csri/passwd.byuid.pag

152 * 512 = 77824

If you copy the file these pages will get filled in. Likewise tar does not
know about these holes and fills them in. In fact even if tar did try to
recognize these big blocks of zero's it could do nothing about it. I have
thought about fixing this problem but it would require a pretty nonstandard
change to the record structure.

There are other ways to get files like this as well, so just because you
don't have dbm files does not mean you might not experience the problem.
A sparse file can be created by a buggy program or by a user:
        $ adb -w bigfile
        0t100000000?w0
        ^D
        $ ls -ls bigfile
          24 -rw-r--r--  1 glenn    100000004 Jan  3 17:59 bigfile

This file is really only about 24k in size but takes up 100M on a tar backup.

                    Glenn Mackintosh
                    Univ. of Toronto

CSNET/ARPA:	glenn@eecg.toronto.edu
UUCP:		UUNET!utai!eecg!glenn
CDNNET:		glenn@eecg.toronto.cdn
BITNET:		glenn@eecg.utoronto.bitnet (may not work from all sites)