Byckup/Restore schlägt fehl

Hallo Zusammen.

Ich komme eigentlich aus der ORACLE-Welt und bin gerade dabei mich in PostgreSQL einzuarbeiten, da wir momentan die Portierung unseres Systems von Oracle auf PG durchführen.

Ich habe unsere Oracle-Datenbank vor einem halben Jahr etwa mittles ora2pg auf PostgreSQL 9.4 portiert und sie läuft da auch auf einem lokalen Server auf meinem Rechner ganz ordentlich.
Nun wollte ich diese Datenbank auf einen neuen Rechner schieben. Auf diesem habe ich Postgresql 10 installiert. Danach habe die die 9.4 Datenbank mit pgAdminIII gesichert. Leider kann ich diese nicht auf PG10 mit pgAdmin 4 wiederherstellen. Es kommen unzähliche Fehlermeldungen. Ich habe alle möglichen Kombinationen aus Backup- und Restore-Einstelungen ausprobiert, ohne Erfolg.
Es kommen hunderte unterschiedlicher Fehlermeldungen wie zum beispiel sowas:

pg_restore: f�hre SEQUENCE SET seq_hd_timeseries aus
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 6853; 0 0 SEQUENCE SET seq_hd_timeseries hdmaster
pg_restore: [Archivierer (DB)] could not execute query: FEHLER:  Relation „public.seq_hd_timeseries“ existiert nicht
ZEILE 1: SELECT pg_catalog.setval('public.seq_hd_timeseries', 106, fa...
                                  ^
    Die Anweisung war: SELECT pg_catalog.setval('public.seq_hd_timeseries', 106, false);



pg_restore: f�hre SEQUENCE SET seq_hd_unit aus
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 6854; 0 0 SEQUENCE SET seq_hd_unit hdmaster
pg_restore: [Archivierer (DB)] could not execute query: FEHLER:  Relation „public.seq_hd_unit“ existiert nicht
ZEILE 1: SELECT pg_catalog.setval('public.seq_hd_unit', 60, false);
                                  ^
    Die Anweisung war: SELECT pg_catalog.setval('public.seq_hd_unit', 60, false);

Meine Vermutung war nun, dass man ebentuell ein PG94. Backup nicht einfach so in eine PG10 Datenbank importieren kann.
Daher Habe ich auf meinem PG9.4 eine zweite Datenbank angelegt und versucht das Backup da hinein zu importieren. Auch dies schlug mit den selben Fehlermeldungen fehl!!
Nun bin ich mit meinem Latein irgendwie am Ende. Es muss doch zumindest möglich sein auf ein und dem selben PG eine Datenbank mittels pgAdmin zu sichern und wieder einzuspielen. Ich befürchte, dass ich das Backup-Restore-System von PG noch nicht verstanden habe und das deutlich komplizierter ist als bei ORACLE.

Ich würde es auf der Konsole mit pg_dumpall > rechner_alt.dump und auf dem neuen Rechner mit psql < rechner_alt.dump versuchen: https://www.postgresql.org/docs/9.6/static/app-pg-dumpall.html.
Evtl. ist der Befehl pg_basebackup auch dein Freund: https://www.postgresql.org/docs/9.6/static/app-pgbasebackup.html

Schau dir auch: https://www.postgresql.org/docs/9.6/static/pgupgrade.html an.

Auf was für einem Betriebssystem läuft dein Postgres?

Grüße

Micha

Also, pg_basebackup geht nicht, das geht nur innerhalb der gleichen Major-Version. Du solltest idealerweise mit dem og_dump / pg_dumpall der 10er - Version einen Dump erstellen und mit psql bzw. pg_restore (in Abhängigkeit in welchen Format der Dump erstellt wurde) diesen wieder einspielen.

Alternativ kannst Du in 9.4 auch pg_logical installieren und damit eine logische Replikation von 9.4 auf 10 aufbauen. Damit könntest Du mit nahezu zero downtime hinkommen.

Vergiss Tools wie PGAdmin für solche Aufgaben, Du willst nicht von einer Klick-Oberfläche Dein Backup & Restore - Konzept abhängig haben.

Also ein 9.4 Backup egal welches Tool auf 9.4 sollte ja nicht so ein Problem sein. Ich kenne einige der hier genannten Tools nicht aber ich könnte mir vorstellen, dass das Problem woanders liegt.
ora2pg:
Wenn Du eine Oracle DB migriert hast, dann hast Du sicher einen Haufen Extensions und ggf. verschiedene Schemata in der 9.4 drin. Vielleicht hast Du irgendwelche Scripte laufen lassen, deren Auswirkungen (DB Schema) Dir gar nicht wirklich klar sind.
Postgres kennt ja keine Packages wie Orcle und das wird, wenn ich mich richtig erinnere über Schemata “nachempfunden”.
Ich würde einfach mal versuchen, zu Fuß die bloßen Schemata und Extensions per Copy / Paste neu zu erstellen (also logisch) in 10 und schauen, ob das alles rüberkommt. Dabei auch auf Rechte und Owner achten, also den Kram, den PGAdmin anzeigt komplett laufen lassen.
Wenn Du bei der Migration “sehr schlimm” gebastelt hast, sind evtl. sogar zirkuläre Abhängigkeiten irgendwo drin und das Anlegen von Objekten schlägt eben fehl, weil Abhängigkeiten in der Reihenfolge des Backup nicht erfüllt werden.
100te Fehler klingen vielleicht schrecklich, aber es reichen eine handvoll Basisobjekte oder auch nur eines, die (noch) nicht da sind oder Erstellungsfehler hatten, damit alle abhängigen Objekte Fehler werfen. Also tatsächlich die Fehler mal ansehen und schauen, wo es los geht. Ersten Fehler im Log raussuchen und dann dort nach dem ursächlichen, fehlenden Objekt suchen, nicht nach dem, dessen Erstellung scheitert (Ein Objekt, das gemäß Backupreihenfolge noch nicht angelegt wurde, aber von einem gerade zu erstellenden benötigt wird, erzeugt ja selbst offensichtlich keinen Fehler).

Ach und noch zur Klarheit, ich würde wegen des Versionswechsels auf jeden Fall mit SQL arbeiten, auf logischer Ebene.