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