pg_restore bricht mit Fehlermeldung ab

Hallo zusammen,

Meine Produktivdatenbank läuft auf dem System:
PostgreSQL 8.4.4-2.3
Linux version 2.6.34-12-desktop
openSuSE 11.3 (x86_64)
Die Datenbank hat folgende Einstellungen
ENCODING = ‘UTF8’
LC_CTYPE = ‘de_DE.UTF-8’

Ein Dump habe ich folgendermaßen erstellt:

pg_dump -i -h localhost -p 5432 -U postgres -s -F c -b -v -f $dumpFile $DB

Wollte das auf meinem Entwicklungssystem einspielen
PostgreSQL 8.4.5-1
Windows XP Prof SP3
ENCODING = ‘UTF8’
LC_CTYPE = ‘German_Germany.1252’

pg_restore.exe -i -h localhost -p 5432 -U postgres -d %DB% -c -v %DUMP_FILE%

Beim Einlesen der Daten bricht der Prozess nach der 150sten Tabelle ab:
[Custom-Archivierer] konnte Block-ID 4322 nicht im Archiv finden – möglicherweise wegen Wiederherstellung außer der Reihe, was wegen fehlender Datenoffsets im Archiv nicht möglich ist

Das Schema allein lässt sich problemlos anlegen.

Was könnte ich tun um die Daten einzulesen?

Gruß
Uli

P.S. Habe direkt vorher die Version 8.3 deinstalliert und 8.4 installiert
Das Datenverzeichnis hatte ich weggelöscht

Du könntest mit “–list” ein Inhaltsverzeichnis des Dumps erstellen und probieren, die Daten für jede Tabelle einzeln auszukommentieren (such nach “DATA”). Mit “–use-list” kannst du dann das geänderte Inhaltsverzeichnis zum Wiederherstellen nutzen.

Es sieht so aus, als ob dein Archiv kaputt ist. Da wirst du wohl Daten verlieren.

Für die Zukunft: Backups ohne einen Test sind wertlos.

“–use-list” habe ich zwischenzeitlich probiert. Ab der 151sten Tabelle kommt immer dieser Fehler, vorher nicht.

Versuche mich mit dem nächsten Dump. Werde auch ein Dump im Textformat erstellen und mit psql einen restore versuchen.

Backups ohne einen Test sind wertlos.

Wie wahr.
Die Aktion ist für mich jetzt der Test.

Danke, ich melde mich nach dem nächsten Versuch.

Dann ist dein Backup kaputt - und du kannst wohl alle Daten ab dieser Tabelle vergessen.

Ich habe ein anderes Backup von letzter Nacht probiert. Genau der gleiche Fehler ab genau der gleichen Tabelle! :confused:
Die Datenbank läuft problemlos, an den Daten kann ich nichts ungewöhnliches erkennen.

Es ist nicht das erste mal, dass ich mit pg_dump / pg_restore die Daten wiederherstelle, aber das erste mal dass ich die Sicherung aus einem Linux System zum wiederherstellen auf einem Windows System benutze. Vielleicht Probleme mit der Zeichenkodierung?

Mein Versuch plain text mit psql einzulesen ist an der großen Datei (12GB) gescheitert, die ich nicht auf eine externe Festplatte kopieren konnte.
Habe jetzt handliche Dateien mit:

pg_dump -i -h localhost -p 5432 -U postgres -F p -b -v $DB | split -b 1000m - $DUMP_FILE

erzeugt.

Wie kann ich die in Windows einlesen?

Kannst du ein “SELECT *” von der betroffenen Tabelle ohne Fehler durchführen?

Ja, der select geht problemlos.
Ich überlege, ob das ein Fehler auf der Zielplatte sein könnte.
Habe aber noch keinen chkdsk gemacht.
Am Montag versuche ich einen restore auf einem anderen Rechner
Zuerst Windows, dann Linux.
Melde mich wieder

Kannst Du ausschließen, daß auf dem Transport zwischen den Systemen was schief ging? Das kann z.B. schon durch FTP passieren. Ist es vielleicht ein Dateigrößenproblem?
Du könntest mittels Prüfsummen das mal prüfen…

Andreas

Das Kopieren lief über eine externe Festplatte.
Die Prüfsummen stimmen! Ich war fast enttäuscht.

Ich habe jetzt nur die fraglichen Tabellen gesichert

pg_dump -i -h localhost -p 5432 -U  postgres -F c -t tbl150 -t tbl151 -b -v -f $DUMP_FILE $DB

Schau an, das konnte ich einlesen.
Das Archiv scheint also wirklich kaputt zu sein.

Wie oben gesagt teste ich noch auf anderen Rechnern (Windows/Linux) mit Sicherungen von anderen Tagen. (Kann bis Mittwoch dauern)

Gruß
Uli

P.S. chkdsk hatte keine Fehler gemeldet

Das einlesen der Backupdatei auf einem Linux Rechner ist erwartungsgemäß auch gescheitert.
Ich habe jetzt von diesem Linux Rechner
(Suse Linux, gleiche Version wie Server mit Produktivdatenbank; PostgreSql Version 8.4.4) eine Sicherung ausgeführt:

pg_dump -i -h 192.168.2.99 -p 5432 -U postgres -F c -b -f $dumpFile $DB

Einzigster Unterschied in der Befehlszeile ist das “-v”
Das Einlesen von diesem dumpFile hat problemlos geklappt.

Könnten Umgebungsvariablen eine Rolle spielen?

Uli

An sich spielen die keine (große) Rolle, zumindest keine, die das Backup zerstören sollte.

Kannst du von der Linuxmaschine aus das pg_dump nutzen und damit das Backup von der Windowsmaschine ziehen?

Ja klar, auf die Idee hätte ich mal selber kommen können.

Ist leider erst am Montag möglich.

Bis dahin.

Hier eine Zusammenfassung “was bisher geschah”

Im folgenden habe ich die Rechner so benannt:
Linux Produktivserver mit IP …99 -> LProd 99
Linux Testmaschine mit IP …104 -> LTest 104

LProd 99 macht pg_dump von localhost
Kopieren das Backups auf LTest 104
Restore des Backups auf LTest 104 schlägt fehl (wie oben beschrieben)

LTest 104 macht pg_dump von LProd 99
Restore des Backups auf LTest 104 funktioniert

Und hier der vorgeschlagene Dump:
LProd 99 macht pg_dump von LTest 104
Kopieren das Backups auf LTest 104
Restore des Backups auf LTest 104 funktioniert

Bitte wie? Das hätte meines Erachtens eher schief gehen sollen.

Ob es eine gute Idee wäre ein funktionierendes Backup auf den Produktivserver zurückzuspielen?
Das sieht aus als hätte die Daten einen Knacks, obwohl die Datenverarbeitung reibungslos läuft.

Uli

Das hört sich alles reichlich komisch an grübel
Ich glaube nicht, dass man da ohne einen Blick auf die Datenbanken irgendeine Aussage treffen sollte.

ich denke ich habs.
Es gibt immer mehr Randbedingungen als darstellbar sind.

Meine Sicherung wird (nein wurde) von einem in Java selbst geschriebenen Timer ausgeführt. Das hat in der Windowswelt prima funktioniert, scheint in Linux aber schief zu gehen. Immer Nachts um 5 Uhr wurde mit

Process process = Runtime.getRuntime().exec("./script/dbDump.bash");

die Sicherung ausgeführt.

Als ich vorhin ein Drop auf eine View machen wollte hab ich gesehen dass über 1000 AccessShareLocks auf IDLE stehen. Das Beenden der Java Applikation hat sie alle freigegeben.
Warum durch die Locks die Sicherung unbrauchbar wird weiss ich nicht, ist wohl aber so.

Ein manuelles Aufrufen von dbDump.bash führt zu einer korrekten Sicherung.

Jetzt ists mir wieder wohler.
Falls jemand noch was zu dem exec Aufruf weiss wärs schön (bin leider neu in Linux),
ansonsten vielen Dank für die Antworten.
Hat mir viel weitergeholfen.

Uli

um einen Job periodisch durchführen zu lassen, empfiehlt sich auf UN*X-Rechnern der cron Befehl. Infos dazu findest du auf deinem Linux-Rechner in einer Shell mittels ‘man cron’. Alternativ hilft Google natürlich ich auch.

Mein Tipp: Vergiss den Timer in Java, nutze cron.

Danke,
den cron werde ich mir mal vornehmen.

Uli

Ja, richtig. Unter Windows nennt sich das Task-Managner, den man normalerweise für solche Aufgaben nutzt. Zudem hat PgAdmin auch eine solche Funktion und nennt sich pgAgent. Downloaden muß man diese Tool nicht separat, nur wird wird diese Tool bei der Installation von PgAdmin nicht automatisch mit installiert. Leider kennen dieses Tool nicht viele, weil sie es einfach vermeiden, sich einmal die Doku anzuschauen.


mfg

fristo

wie groß sind denn die dumps? :slight_smile:
wie sind die busbreiten der OS?

PostgreSQL 8.4.5-1
Windows XP Prof SP3
ENCODING = ‘UTF8’
LC_CTYPE = ‘German_Germany.1252’

nun kann es durchaus sein (wo ich mir net sicher bin), dass pg_dump large file support inne hat … aber vielleicht hat irgendein tool beim kopieren zwischendurch die haelfte unterschlagen