Thread: Use tar to online backup has an error
Hi,
when I use tar to online backup ,It has an error:
when I use tar to online backup ,It has an error:
/bin/tar: Removing leading `/' from member names
/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.
[~]$ ls -al /data/test/PG_9.0_201008051/20001/24500001 ls: /data/test/PG_9.0_201008051/20001/24500001 : No such file or directory what should I do to resolve this error. I'm using pg9.0. Thanks
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
Attachment
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
Hi
I got it. Thanks for your kindly support!!!
Thank you very much.
2015-09-24 22:18 GMT+08:00 David Steele <david@pgmasters.net>:
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