19
Absturz des Server PostgreSQL Rücksicherung
Hallo,
ich habe folgendes Problem.
Gestern habe ich auf meinem Server ein Update aufgespielt, welches den Server nun ganz ruiniert hat...
Ich habe den Server (SBS 2008 Standard) neu aufgesetzt und stehe nun vor der Herausforderung, die Datenbanken wieder einzuspielen.
Es handelt sich hierbei um die PostgreSQL Datenbanken. Mir liegt ein komplettes Image vor, wo ich den kompletten Programm-Ordner "postgreSQL" rausholen kann.
I.d.R. wird nur das Data-Verzeichnis benötigt.
Spiele ich dies aber ein, kann der Dienst nicht mehr gestartet werden. Die Ordnerberechtigungen wurden überprüft und sollten alle in Ordnung sein. Auch der Test mit "Jeder" schlägt fehl. Der Dienst startet nicht.
Habt Ihr ein Tipp für mich, wie ich meine Datenbanken wiederherstellen kann???
Ich freue mich auf eine Antwort von euch.
Viele Grüße
DerPalit
ich habe folgendes Problem.
Gestern habe ich auf meinem Server ein Update aufgespielt, welches den Server nun ganz ruiniert hat...
Ich habe den Server (SBS 2008 Standard) neu aufgesetzt und stehe nun vor der Herausforderung, die Datenbanken wieder einzuspielen.
Es handelt sich hierbei um die PostgreSQL Datenbanken. Mir liegt ein komplettes Image vor, wo ich den kompletten Programm-Ordner "postgreSQL" rausholen kann.
I.d.R. wird nur das Data-Verzeichnis benötigt.
Spiele ich dies aber ein, kann der Dienst nicht mehr gestartet werden. Die Ordnerberechtigungen wurden überprüft und sollten alle in Ordnung sein. Auch der Test mit "Jeder" schlägt fehl. Der Dienst startet nicht.
Habt Ihr ein Tipp für mich, wie ich meine Datenbanken wiederherstellen kann???
Ich freue mich auf eine Antwort von euch.
Viele Grüße
DerPalit
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 138160
Url: https://administrator.de/contentid/138160
Printed on: April 24, 2024 at 15:04 o'clock
19 Comments
Latest comment
Hallo,
was sagt der das Event Log dazu ?
CU,
Kai.
was sagt der das Event Log dazu ?
CU,
Kai.
Hallo Kai,
in den Logfiles vom PostgreSQL finde ich keine Kommentare dazu.
In dem Ereignisprotokoll von Windows steht "Timed out for waiting server startup".
Wenn ich den Dienst per Hand starte, dann dauert dies auch sehr lange bis eine Rückmeldung kommt.
Wenn ich das Data-Verzeichnis nehme, welches bei der Installation erstellt wurde, dann ist der Dienst innerhalb 2-3 Sekunden gestartet.
Viele Grüße
Patrick
in den Logfiles vom PostgreSQL finde ich keine Kommentare dazu.
In dem Ereignisprotokoll von Windows steht "Timed out for waiting server startup".
Wenn ich den Dienst per Hand starte, dann dauert dies auch sehr lange bis eine Rückmeldung kommt.
Wenn ich das Data-Verzeichnis nehme, welches bei der Installation erstellt wurde, dann ist der Dienst innerhalb 2-3 Sekunden gestartet.
Viele Grüße
Patrick
Hi !
Einen Dump der Datenbank(en) hast Du nicht zufällig? Hattest Du vielleicht vorher eine andere Version von Postgre gegenüber der nun neu installierten?
mrtux
Einen Dump der Datenbank(en) hast Du nicht zufällig? Hattest Du vielleicht vorher eine andere Version von Postgre gegenüber der nun neu installierten?
mrtux
Hallo,
nein der Dump ist leider beim Absturz verloren gegangen, dass ging alles ziemlich schnell...
Vor dem Crash war die Version 8.3 drauf, die gleiche habe ich nun auch wieder installiert. (Das selbe Setup-File)
Ich war der Hoffnung, dass durch die gleiche Version das Problem mit dem Rücksichern behoben ist. Leider Fehlanzeige...
Viele Grüße
Patrick
nein der Dump ist leider beim Absturz verloren gegangen, dass ging alles ziemlich schnell...
Vor dem Crash war die Version 8.3 drauf, die gleiche habe ich nun auch wieder installiert. (Das selbe Setup-File)
Ich war der Hoffnung, dass durch die gleiche Version das Problem mit dem Rücksichern behoben ist. Leider Fehlanzeige...
Viele Grüße
Patrick
Hallo,
die Pfade zur Datenbank sind auch gleich geblieben ? Hast Du den Debuglevel von postgresql mal hochgeschaubt um zu schauen, was nicht läuft Dies kann in der postgresql.conf gemacht werden (allerdings kenne ich die nur unter Linux ;).
CU,
Kai.
die Pfade zur Datenbank sind auch gleich geblieben ? Hast Du den Debuglevel von postgresql mal hochgeschaubt um zu schauen, was nicht läuft Dies kann in der postgresql.conf gemacht werden (allerdings kenne ich die nur unter Linux ;).
CU,
Kai.
Hallo,
auch die Pfade sind gleich geblieben. Gleiche Partition, gleicher Laufwerksbuchstabe, gleicher Programmordner, etc.
Das mit dem Debuglevel funktioniert in Windows wohl nicht. Jedenfalls hab ich den Eintrag nicht gefunden...
Habt ihr sonst noch eine Idee???
Gruß
Patrick
auch die Pfade sind gleich geblieben. Gleiche Partition, gleicher Laufwerksbuchstabe, gleicher Programmordner, etc.
Das mit dem Debuglevel funktioniert in Windows wohl nicht. Jedenfalls hab ich den Eintrag nicht gefunden...
Habt ihr sonst noch eine Idee???
Gruß
Patrick
Hallo DerPalit,
wurde das Image im laufenden Betrieb gemacht oder war der DB Cluster sauber runtergefahren? Setze den Debuglevel mal auf 5, wie kaiszy28 vorschlägt. Gehe dazu ins Postgres\bin Verzeichnis und starte dort die Datenbank auf der Konsole mit dem Parameter -d 5.
Grüße p
wurde das Image im laufenden Betrieb gemacht oder war der DB Cluster sauber runtergefahren? Setze den Debuglevel mal auf 5, wie kaiszy28 vorschlägt. Gehe dazu ins Postgres\bin Verzeichnis und starte dort die Datenbank auf der Konsole mit dem Parameter -d 5.
Grüße p
Hallo,
so wie ich es weiß, wurde das Image im laufenden Betrieb gemacht.
Kann also gut sein, dass der Datenbankserver noch lief. Ist das schlimm?
Das mit dem Debuglevel werde ich nochmal austesten und euch dann benachrichtigen.
Viele Grüße
Patrick
so wie ich es weiß, wurde das Image im laufenden Betrieb gemacht.
Kann also gut sein, dass der Datenbankserver noch lief. Ist das schlimm?
Das mit dem Debuglevel werde ich nochmal austesten und euch dann benachrichtigen.
Viele Grüße
Patrick
lösche mal in dem wiederhergestellten \data\ Verzeichnis die Datei postmaster.pid und schau, ob er dann startet.
Hallo,
hilft leider auch nicht. Trotzdem startet der Dienst nicht.
Langsam bin ich wirklich am verzeifeln...
hilft leider auch nicht. Trotzdem startet der Dienst nicht.
Langsam bin ich wirklich am verzeifeln...
hast Du nach dem Einspielen der "alten" Daten die Rechte dem postgres-User gegeben? Überprüfe, ob dies wirklich auf alle Dateien und Ordner angewand wurde. Ansonsten mal auf das Log warten.
Jup, der postgres User hat alle Rechte bei jeder Datei.
Ich habe es auch schon mit den Rechten "Jeder" versucht.
Leider alles ohne Erfolg...
Ich habe es auch schon mit den Rechten "Jeder" versucht.
Leider alles ohne Erfolg...
dann setz das Debuglevel mal auf 5 und stell die Logeinträge hier ein. Du kannst es auch in pgAdmin III machen. Datei -> postgresql.conf öffnen (liegt im \Data\ Verzeichnis). Es wird dann ein spezieller Editor geöffnet. Dort suchst Du log_min_messages. Diesen Eintrag aktivierst Du und schreibst als Wert DEBUG5 rein. Dann schreibt er alles ins Log.
So nun hab ich das mal mit dem Debug-Level ausprobiert und siehe da, es kommen Ergebnisse:
2010-03-13 20:22:45 CET LOG: database system was interrupted; last known up at 2010-03-11 18:58:18 CET
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: checkpoint record is at 0/8772E08
2010-03-13 20:22:45 CET DEBUG: redo record is at 0/8772E08; shutdown FALSE
2010-03-13 20:22:45 CET DEBUG: next transaction ID: 0/1842; next OID: 32768
2010-03-13 20:22:45 CET DEBUG: next MultiXactId: 1; next MultiXactOffset: 0
2010-03-13 20:22:45 CET LOG: database system was not properly shut down; automatic recovery in progress
2010-03-13 20:22:45 CET LOG: record with zero length at 0/8772E50
2010-03-13 20:22:45 CET LOG: redo is not required
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 80 to 17
2010-03-13 20:22:45 CET FATAL: invalid page header in block 0 of relation "1262"
2010-03-13 20:22:45 CET DEBUG: proc_exit(1)
2010-03-13 20:22:45 CET DEBUG: shmem_exit(1)
2010-03-13 20:22:45 CET DEBUG: exit(1)
2010-03-13 20:22:45 CET DEBUG: reaping dead processes
2010-03-13 20:22:45 CET LOG: startup process (PID 6588) exited with exit code 1
2010-03-13 20:22:45 CET LOG: aborting startup due to startup process failure
2010-03-13 20:22:45 CET DEBUG: proc_exit(1)
2010-03-13 20:22:45 CET DEBUG: shmem_exit(1)
2010-03-13 20:22:45 CET DEBUG: exit(1)
2010-03-13 20:22:46 CET DEBUG: logger shutting down
2010-03-13 20:22:46 CET DEBUG: proc_exit(0)
2010-03-13 20:22:46 CET DEBUG: shmem_exit(0)
2010-03-13 20:22:46 CET DEBUG: exit(0)
Ganz verstehen tue ich das allerdings nicht. Kommt ihr damit weiter???
Danke schon mal für eure Hilfe...
2010-03-13 20:22:45 CET LOG: database system was interrupted; last known up at 2010-03-11 18:58:18 CET
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: checkpoint record is at 0/8772E08
2010-03-13 20:22:45 CET DEBUG: redo record is at 0/8772E08; shutdown FALSE
2010-03-13 20:22:45 CET DEBUG: next transaction ID: 0/1842; next OID: 32768
2010-03-13 20:22:45 CET DEBUG: next MultiXactId: 1; next MultiXactOffset: 0
2010-03-13 20:22:45 CET LOG: database system was not properly shut down; automatic recovery in progress
2010-03-13 20:22:45 CET LOG: record with zero length at 0/8772E50
2010-03-13 20:22:45 CET LOG: redo is not required
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 2 to 2
2010-03-13 20:22:45 CET DEBUG: mapped win32 error code 80 to 17
2010-03-13 20:22:45 CET FATAL: invalid page header in block 0 of relation "1262"
2010-03-13 20:22:45 CET DEBUG: proc_exit(1)
2010-03-13 20:22:45 CET DEBUG: shmem_exit(1)
2010-03-13 20:22:45 CET DEBUG: exit(1)
2010-03-13 20:22:45 CET DEBUG: reaping dead processes
2010-03-13 20:22:45 CET LOG: startup process (PID 6588) exited with exit code 1
2010-03-13 20:22:45 CET LOG: aborting startup due to startup process failure
2010-03-13 20:22:45 CET DEBUG: proc_exit(1)
2010-03-13 20:22:45 CET DEBUG: shmem_exit(1)
2010-03-13 20:22:45 CET DEBUG: exit(1)
2010-03-13 20:22:46 CET DEBUG: logger shutting down
2010-03-13 20:22:46 CET DEBUG: proc_exit(0)
2010-03-13 20:22:46 CET DEBUG: shmem_exit(0)
2010-03-13 20:22:46 CET DEBUG: exit(0)
Ganz verstehen tue ich das allerdings nicht. Kommt ihr damit weiter???
Danke schon mal für eure Hilfe...
Hallo,
also nach kurzem Googeln mit dem Begriff:
postgres nvalid page header in block 0
sieht es fast so aus als wäre dem Dump was passiert, oder es ist das Filesystem darunter ein wenig aus dem
Tritt gekommen.
Bei solchen Debug sachen sind immer die Zeilen mit FATAL interessant.
Vielleicht kommst ja mitn googlen ein wenig weiter, sieht aber nach ner unschönen Sache aus .....
also nach kurzem Googeln mit dem Begriff:
postgres nvalid page header in block 0
sieht es fast so aus als wäre dem Dump was passiert, oder es ist das Filesystem darunter ein wenig aus dem
Tritt gekommen.
Bei solchen Debug sachen sind immer die Zeilen mit FATAL interessant.
Vielleicht kommst ja mitn googlen ein wenig weiter, sieht aber nach ner unschönen Sache aus .....
Hallo,
ich hab jetzt selber nochmal ein bisschen rumprobiert...
Wenn ich nur den Base-Ordner in das Data-Verzeichnis schiebe, startet der Server ohne Probleme. Jedoch kann ich nicht auf die Datenbank zugreifen.
Lege ich nun noch den Global Ordner in das Verzeichnis, kackt der Server beim Start jedes Mal ab...
Was kann denn im Global-Ordner drin sein, was den Server so blockiert???
ich hab jetzt selber nochmal ein bisschen rumprobiert...
Wenn ich nur den Base-Ordner in das Data-Verzeichnis schiebe, startet der Server ohne Probleme. Jedoch kann ich nicht auf die Datenbank zugreifen.
Lege ich nun noch den Global Ordner in das Verzeichnis, kackt der Server beim Start jedes Mal ab...
Was kann denn im Global-Ordner drin sein, was den Server so blockiert???
godlie hat Recht, es scheint eine Datei zerbröselt zu haben. Warum? Kann am Dateisystem liegen oder möglicherweise an einem inkonsistenten Zustand beim Speichern (Runterfahren oder Dump in Zukunft).
Im Global Verzeichnis dürften alle übergeordneten Infos zu DB, User etc. stehen. Daher auch kein Zugriff mit der "neuen" Version, da die Deine DB nicht kennt. Hinweis könnte Relation "1262" sein. Diese Datei gibt es. Vielleicht kannst Du ja nur die austauschen und Deine DB läuft wieder. Das ist natürlich arges Frickeln aber vielleicht rettet es ja Deine Daten. Probieren würd ichs.
Viel Glück p
Nachtrag: kopier die dazugehörigen _fsm und _vm Dateien mit
Im Global Verzeichnis dürften alle übergeordneten Infos zu DB, User etc. stehen. Daher auch kein Zugriff mit der "neuen" Version, da die Deine DB nicht kennt. Hinweis könnte Relation "1262" sein. Diese Datei gibt es. Vielleicht kannst Du ja nur die austauschen und Deine DB läuft wieder. Das ist natürlich arges Frickeln aber vielleicht rettet es ja Deine Daten. Probieren würd ichs.
Viel Glück p
Nachtrag: kopier die dazugehörigen _fsm und _vm Dateien mit
hab jetzt mal bei mir nachgesehen; OID gehört der Tabelle, die für die Datenbanken zuständig ist. Du kannst versuchen, Dein \data\ Verzeichnis wiederherzustellen. Dann ersetzt Du die defekte 1262 Tabelle durch die neue. Dort kannst Du dann manuell die Datenbanken eintragen. Dies kannst Du mit pgAdmin machen. Gehe in die postgres Datenbank. Dort gehst Du in Kataloge -> (PostgreSQL (pg_catalog). Wähle die Tabelle pg_database und schau Dir die Daten an. Trage dann Deine Datenbanken nach dem selben Muster ein. Als OID nimmst Du die Nummer des Ordners unter \data\base (bspweise 12019), Name der DB (sofern es nur eine ist und Du diesen weißt). Alle anderen Einträge sind identisch zu template1. Außer "datistemplate" setzt Du auf "false".
Wünsch Dir viel Erfolg und einen langen Atem...
Grüße p
Wünsch Dir viel Erfolg und einen langen Atem...
Grüße p
Hi !
Das habe ich schon von Anfang an vermutet, darum habe ich nach einem Dump gefragt....Mit einem Dump wäre er um die Bastelei sicherlich problemlos herumgekommen...Wir arbeiten nur noch mit Dumps (teilweise mehrmals täglich), auch wenn dieses Vorgehen vielleicht mehr Platz benötigt......Zugegeben, hilfreich ist meine Bemerkung nicht wenn das "Kind schon in den Brunnen gefallen" ist...
mrtux
Zitat von @perseues:
godlie hat Recht, es scheint eine Datei zerbröselt zu haben. Warum? Kann am Dateisystem liegen oder möglicherweise an
godlie hat Recht, es scheint eine Datei zerbröselt zu haben. Warum? Kann am Dateisystem liegen oder möglicherweise an
Das habe ich schon von Anfang an vermutet, darum habe ich nach einem Dump gefragt....Mit einem Dump wäre er um die Bastelei sicherlich problemlos herumgekommen...Wir arbeiten nur noch mit Dumps (teilweise mehrmals täglich), auch wenn dieses Vorgehen vielleicht mehr Platz benötigt......Zugegeben, hilfreich ist meine Bemerkung nicht wenn das "Kind schon in den Brunnen gefallen" ist...
mrtux
