Thread: Re: [GENERAL] PITR and tar

Re: [GENERAL] PITR and tar

From
"Jim C. Nasby"
Date:
Moving to -docs...

Does anyone know what the history of the docs saying that GNU tar had
issues with files changing underneath it? According to this report it's
actually BSD tar that has the issue.

On Wed, May 09, 2007 at 10:19:05AM -0700, Jeff Davis wrote:
> On Wed, 2007-05-09 at 11:40 -0500, Jim Nasby wrote:
> > Actually, looking at the docs, the problem is with some versions of
> > GNU tar. AFAIK bsdtar is perfectly happy to archive files that have
> > changed from underneath it.
> >
>
> $ tar --version
> bsdtar 1.2.53 - libarchive 1.3.1
>
> That fails to create a file in proper gzip format when the files are
> concurrently modified.
>
> However,
>
> $ tar --version
> tar (GNU tar) 1.14
> Copyright (C) 2004 Free Software Foundation, Inc.
> This program comes with NO WARRANTY, to the extent permitted by law.
> You may redistribute it under the terms of the GNU General Public
> License;
> see the file named COPYING for details.
> Written by John Gilmore and Jay Fenlason.
>
> That _appears_ to work.
>
> Perhaps FreeBSD users should take notice of this problem. It's certainly
> not a postgresql problem, but I know there are a lot of freebsd users
> here, and using tar on fast-changing data may be rare outside of
> postgresql.
>
> Regards,
>     Jeff Davis
>

--
Jim Nasby                                      decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Re: [GENERAL] PITR and tar

From
Bruce Momjian
Date:
Jim C. Nasby wrote:
> Moving to -docs...
>
> Does anyone know what the history of the docs saying that GNU tar had
> issues with files changing underneath it? According to this report it's
> actually BSD tar that has the issue.

As I remember, Tom was the one who found that GNU tar would return a
non-zero exit status if the file changed during backup, so you couldn't
determine if the backup was successful based on the exit code.

---------------------------------------------------------------------------


>
> On Wed, May 09, 2007 at 10:19:05AM -0700, Jeff Davis wrote:
> > On Wed, 2007-05-09 at 11:40 -0500, Jim Nasby wrote:
> > > Actually, looking at the docs, the problem is with some versions of
> > > GNU tar. AFAIK bsdtar is perfectly happy to archive files that have
> > > changed from underneath it.
> > >
> >
> > $ tar --version
> > bsdtar 1.2.53 - libarchive 1.3.1
> >
> > That fails to create a file in proper gzip format when the files are
> > concurrently modified.
> >
> > However,
> >
> > $ tar --version
> > tar (GNU tar) 1.14
> > Copyright (C) 2004 Free Software Foundation, Inc.
> > This program comes with NO WARRANTY, to the extent permitted by law.
> > You may redistribute it under the terms of the GNU General Public
> > License;
> > see the file named COPYING for details.
> > Written by John Gilmore and Jay Fenlason.
> >
> > That _appears_ to work.
> >
> > Perhaps FreeBSD users should take notice of this problem. It's certainly
> > not a postgresql problem, but I know there are a lot of freebsd users
> > here, and using tar on fast-changing data may be rare outside of
> > postgresql.
> >
> > Regards,
> >     Jeff Davis
> >
>
> --
> Jim Nasby                                      decibel@decibel.org
> EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org/

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: [GENERAL] PITR and tar

From
Tom Lane
Date:
"Jim C. Nasby" <decibel@decibel.org> writes:
> Does anyone know what the history of the docs saying that GNU tar had
> issues with files changing underneath it? According to this report it's
> actually BSD tar that has the issue.

It seems to be a different issue.  The problem with GNU tar is that it
issues a warning and exits with nonzero status, which is a problem for
backup scripts because they can't easily distinguish this case from an
actual failure.  But AFAIK the output file is self-consistent anyway.
It sounds like bsd tar is just plain broken :-(

            regards, tom lane