On Tue, 2007-05-08 at 10:25 -0500, Jim Nasby wrote: > On May 7, 2007, at 1:58 PM, Jeff Davis wrote: > > Second, it seems that it can cause a bad backup to occur if you > > pass the > > "z" option to tar. Instead, piping the output of tar through the > > compression program seems to avoid that problem (i.e. "tar cf - ... | > > gzip > ..."). I am using FreeBSD's tar, other implementations may be > > different. > > What *exactly* are you seeing there? If anything -z should be safer > than piping through gzip, since you could easily accidentally pipe > stderr through gzip as well, which *would* corrupt the backup. > tar: Truncated write; file may have grown while being archived. tar: Truncated write; file may have grown while being archived. tar: GZip compression failed is the output from my cron script (which is emailed to me). This happened several times in a row. When I tried to extract one of those backups, I got errors like (some names have been changed): $ tar zxf mybackup.tar.gz data/base/16418/32309.1: Premature end of gzip compressed data: Input/output error tar: Premature end of gzip compressed data: Input/output error and $ gzip -dc mybackup.tar.gz > /dev/null gzip: ../mybackup.tar.gz: unexpected end of file gzip: ../mybackup.tar.gz: uncompress failed This may be specific to FreeBSD's tar. I remember testing in the past on Linux and never had these problems. When I changed to do it as a pipe instead of using the "z" flag, it worked fine. I still get the stderr properly (which is also emailed to me via cron) but only contains the "truncated write" warnings. > > Are my observations correct, and if so, should they be documented as a > > potential "gotcha" when making base backups? > > I believe the bit about tar complaining about changed files is > already in there, no? I was talking about using the "z" flag with tar causing potential bad backups as described above, not just the warnings. If that's true, there are probably other people with untrustworthy backups. Regards, Jeff Davis
