Обсуждение: Use tar to online backup has an error

On 2015-09-24 03:55, maxiangqian wrote:

> when I use tar to online backup ,It has an error:
>
> /bin/tar: Removing leading `/' from member names

This is not an error, more like a warning. GNU tar doesn't not store the full path in the tar file, but a relative
path,as full paths are considered dangerous (easier to overwrite existing data by mistake). 


> /bin/tar: /data/test/PG_9.0_201008051/20001/24500001: Cannot stat: No such
> file or directory
>
> /bin/tar: Error exit delayed from previous errors
>
>
> and /data/test/PG_9.0_201008051/20001/24500001 file is not exist.
>

It looks like you are trying to make a filesystem backup while the files are still being updated. In order to make a
filesystembackup you need to either: 

  - shutdown the database
  - run "pg_start_backup" (make SURE that you run pg_stop_backup" when done)

http://www.postgresql.org/docs/9.3/static/backup-file.html
http://www.postgresql.org/docs/9.3/static/continuous-archiving.html#BACKUP-TIPS


--
http://yves.zioup.com
gpg: 4096R/32B0F416

On 9/24/15 9:29 AM, Yves Dorfsman wrote:
> On 2015-09-24 03:55, maxiangqian wrote:
>> /bin/tar: /data/test/PG_9.0_201008051/20001/24500001: Cannot stat: No such
>> file or directory
>>
>> /bin/tar: Error exit delayed from previous errors
>>
>>
>> and /data/test/PG_9.0_201008051/20001/24500001 file is not exist.
>>
>
> It looks like you are trying to make a filesystem backup while the files are still being updated. In order to make a
filesystembackup you need to either: 
>
>    - shutdown the database
>    - run "pg_start_backup" (make SURE that you run pg_stop_backup" when done)
>
> http://www.postgresql.org/docs/9.3/static/backup-file.html
> http://www.postgresql.org/docs/9.3/static/continuous-archiving.html#BACKUP-TIPS

It's actually perfectly normal for files to disappear during a backup,
even when pg_start_backup() is called first (never perform file-level
backup with calling pg_start_backup()).  The database continues to
operation normally during a backup so any dropped table (or temp table)
will result it files being removed by Postgres, not to mention changes
in clog, pg_xlog, etc.

All of this is reconciled during the replay of WAL after a restore.  You
just need to ignore any missing file errors while taking the backup and
be sure to back up all the WAL segments required to make the database
consistent. pg_basebackup will do all of this for you.

Another option is to use purpose-built backup software such as
pgBackRest or barman, both of which are open source.

--
-David
david@pgmasters.net

* David Steele (david@pgmasters.net) wrote:
> It's actually perfectly normal for files to disappear during a
> backup, even when pg_start_backup() is called first (never perform
> file-level backup with calling pg_start_backup()).  The database

*without* calling pg_start_backup, you mean. :)

> All of this is reconciled during the replay of WAL after a restore.

... which is why archive_command must be set and the WAL files must be
archived, otherwise PG can't go back and replay those changes.

> Another option is to use purpose-built backup software such as
> pgBackRest or barman, both of which are open source.

+100.  Rolling your own backup solution for PG really stinks and is
difficult to get right.  Use something which knows about all of the
above, verifies that all the necessary WAL is archived, does all of the
correct fsync's for the WAL files when they're saved, handles failure
gracefully, etc, etc.

Thanks!

Stephen

On 9/24/15 10:15 AM, Stephen Frost wrote:
> * David Steele (david@pgmasters.net) wrote:
>> It's actually perfectly normal for files to disappear during a
>> backup, even when pg_start_backup() is called first (never perform
>> file-level backup with calling pg_start_backup()).  The database
>
> *without* calling pg_start_backup, you mean. :)

Whoops!  That's definitely what I meant.

--
-David
david@pgmasters.net