Use tar to online backup has an error
Hi,
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 filesystem backup 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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 filesystem backup 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
* 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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>:
Show quoted text
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