Dump and restore problem
Hello, I had a very nice system where I mirrored everything to another
machine each night, so in case of disaster, I could easily switch over
to the mirror.
The backup script uses a line like this:
pg_dump -b -F t -h $postgresql_hostname $i > "$location_backup_dir/`date
+%B-%Y`/$date_info/postgresql_database-$i-backup"
I transfer the backup files by rsync and then run this on the mirror:
pg_restore -c -U dbuser -d dbname -F t postgresql_database-db-backup
This worked fine for months until I upgraded postgres on the main
machine from 8.0.13 to 8.0.15. From then on I started getting these
messages:
pg_restore: [tar archiver] could not open TOC file for input: No such
file or directory
The funny thing is that this started when I upgraded postgres on the
main main machine a little over a week ago, but I had already upgraded
from 8.0.13 to 8.0.15 on the mirror machine back in January (and the
error happens when I try to restore the backup on the mirror).
If anyone can help, I would be very appreciative.
--
Stuart Luppescu -=- slu .at. ccsr.uchicago.edu
University of Chicago -=- CCSR
才文と智奈美の父 -=- Kernel 2.6.24-gentoo-r8
Is knowledge knowable? If not, how do we know
that?
On Wed, Jun 18, 2008 at 11:41 PM, Stuart Luppescu <slu@ccsr.uchicago.edu> wrote:
[...]
pg_restore: [tar archiver] could not open TOC file for input: No such
file or directory
It sounds like the tar file is no longer being created.
Try manually running the commands, and verify that the dump, restore,
and rsync still work correctly at each step.
David.
On 木, 2008-06-19 at 11:57 +0200, David wrote:
pg_restore: [tar archiver] could not open TOC file for input: No
such
file or directory
It sounds like the tar file is no longer being created.
Try manually running the commands, and verify that the dump, restore,
and rsync still work correctly at each step.
It looks like it's working:
file postgresql_database-db-backup
postgresql_database-db-backup: tar archive
tar tfv postgresql_database-db-backup
-rw------- 2048/1024 62764 2008-06-20 03:00 toc.dat
-rw------- 2048/1024 4590795 2008-06-20 03:00 1765.dat
-rw------- 2048/1024 391040 2008-06-20 03:00 1771.dat
-rw------- 2048/1024 1262932 2008-06-20 03:00 1770.dat
-rw------- 2048/1024 4472 2008-06-20 03:00 1769.dat
-rw------- 2048/1024 5 2008-06-20 03:00 1796.dat
-rw------- 2048/1024 5 2008-06-20 03:00 1787.dat
-rw------- 2048/1024 5456 2008-06-20 03:00 1762.dat
-rw------- 2048/1024 435981 2008-06-20 03:00 1767.dat
-rw------- 2048/1024 54185 2008-06-20 03:00 1774.dat
-rw------- 2048/1024 109 2008-06-20 03:00 1764.dat
etc.
This only weird thing is the ownership is weird. Where did that
2048/1024 come from?
--
Stuart Luppescu -=- s-luppescu .at. uchicago.edu
University of Chicago (^_^)/ CCSR
才文と智奈美の父 -=-=- Kernel 2.6.23-gentoo-r
War is never imperative. -- McCoy, "Balance of
Terror", stardate 1709.2
Most files systems allocate in 1k(1024) block(s)
If the resource requests more.. the OS FS allocates one more 1024 block
(thus the display of 2048 allocation..)
hope this makes sense,
Martin
----- Original Message -----
From: "Stuart Luppescu" <slu@ccsr.uchicago.edu>
To: <pgsql-general@postgresql.org>
Sent: Saturday, June 21, 2008 9:11 PM
Subject: Re: [GENERAL] Dump and restore problem
On 木, 2008-06-19 at 11:57 +0200, David wrote:
pg_restore: [tar archiver] could not open TOC file for input: No
such
file or directory
It sounds like the tar file is no longer being created.
Try manually running the commands, and verify that the dump, restore,
and rsync still work correctly at each step.
It looks like it's working:
file postgresql_database-db-backup
postgresql_database-db-backup: tar archive
tar tfv postgresql_database-db-backup
-rw------- 2048/1024 62764 2008-06-20 03:00 toc.dat
-rw------- 2048/1024 4590795 2008-06-20 03:00 1765.dat
-rw------- 2048/1024 391040 2008-06-20 03:00 1771.dat
-rw------- 2048/1024 1262932 2008-06-20 03:00 1770.dat
-rw------- 2048/1024 4472 2008-06-20 03:00 1769.dat
-rw------- 2048/1024 5 2008-06-20 03:00 1796.dat
-rw------- 2048/1024 5 2008-06-20 03:00 1787.dat
-rw------- 2048/1024 5456 2008-06-20 03:00 1762.dat
-rw------- 2048/1024 435981 2008-06-20 03:00 1767.dat
-rw------- 2048/1024 54185 2008-06-20 03:00 1774.dat
-rw------- 2048/1024 109 2008-06-20 03:00 1764.dat
etc.
This only weird thing is the ownership is weird. Where did that
2048/1024 come from?
--
Stuart Luppescu -=- s-luppescu .at. uchicago.edu
University of Chicago (^_^)/ CCSR
才文と智奈美の父 -=-=- Kernel 2.6.23-gentoo-r
War is never imperative. -- McCoy, "Balance of
Terror", stardate 1709.2
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Sun, Jun 22, 2008 at 3:11 AM, Stuart Luppescu <slu@ccsr.uchicago.edu> wrote:
On 木, 2008-06-19 at 11:57 +0200, David wrote:
pg_restore: [tar archiver] could not open TOC file for input: No
such
file or directory
It sounds like the tar file is no longer being created.
Try manually running the commands, and verify that the dump, restore,
and rsync still work correctly at each step.It looks like it's working:
file postgresql_database-db-backup
postgresql_database-db-backup: tar archivetar tfv postgresql_database-db-backup
-rw------- 2048/1024 62764 2008-06-20 03:00 toc.dat
-rw------- 2048/1024 4590795 2008-06-20 03:00 1765.dat
-rw------- 2048/1024 391040 2008-06-20 03:00 1771.dat
-rw------- 2048/1024 1262932 2008-06-20 03:00 1770.dat
-rw------- 2048/1024 4472 2008-06-20 03:00 1769.dat
-rw------- 2048/1024 5 2008-06-20 03:00 1796.dat
-rw------- 2048/1024 5 2008-06-20 03:00 1787.dat
-rw------- 2048/1024 5456 2008-06-20 03:00 1762.dat
-rw------- 2048/1024 435981 2008-06-20 03:00 1767.dat
-rw------- 2048/1024 54185 2008-06-20 03:00 1774.dat
-rw------- 2048/1024 109 2008-06-20 03:00 1764.datetc.
This only weird thing is the ownership is weird. Where did that
2048/1024 come from?
I'm not sure about that. But if your manual process is working, then
your script should work fine too. Try adding more logging & error
checking/capturing to your mirroring scripts to check where the
problem is occurring. Debug lines like 'echo "TESTING ($LINENO) -
<Description>"' to trace which parts of the scripts get run when can
also help.
David.