Обсуждение: 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 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? > 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.