Hallo! Ja, ich habe Ahnung von PostgreSQL-Datenbanken und kann dir bei vielen Themen rund um PostgreSQL helfen, sei es Installation, Konfiguration, SQL-Abfragen, Performance-Tuning oder spezifische Funktionen. Wie kann ich dir genau helfen?

Klingt nach einem komplexen und wichtigen Prozess! Hier ist eine schrittweise Anleitung, wie du ein vollständiges Backup und Restore deiner PostgreSQL-Datenbank zwischen den beiden Servern durchführen kannst: ### 1. Backup auf Server A (Quell-Server) Du möchtest alle Datenbanken inklusive Rollen, Indizes, Tabellen, Views usw. sichern. Dafür eignet sich am besten der **`pg_dumpall`**-Befehl, der ein komplettes Backup der gesamten PostgreSQL-Instanz inklusive Rollen und globalen Objekten erstellt. #### Schritt 1.1: Erstellen eines vollständigen Backups Führe diesen Befehl auf **Server A** aus, um ein vollständiges Backup zu erstellen: ```bash pg_dumpall -U postgres -h localhost -p <PORT> > /path/to/backup/complete_backup.sql ``` - **-U postgres**: Der PostgreSQL-Admin-User, der Zugriff auf alle Datenbanken hat. - **-h localhost**: Hostname, wo die PostgreSQL-Instanz läuft (in Docker möglicherweise anders). - **-p <PORT>**: Port der PostgreSQL-Instanz (standardmäßig 5432). - **/path/to/backup/complete_backup.sql**: Speicherort des SQL-Dumps. #### Schritt 1.2: Optional: Datenbank nur für Keycloak, Process Engine, Prime sichern Falls du nur diese drei Datenbanken sichern möchtest, könntest du stattdessen mit **`pg_dump`** gezielt arbeiten: ```bash pg_dump -U postgres -h localhost -p <PORT> -Fc keycloak > /path/to/backup/keycloak.dump pg_dump -U postgres -h localhost -p <PORT> -Fc process-engine > /path/to/backup/process_engine.dump pg_dump -U postgres -h localhost -p <PORT> -Fc prime > /path/to/backup/prime.dump ``` - **-Fc**: Erzeugt ein komprimiertes Custom-Format, das flexibler für Wiederherstellung ist. ### 2. Backup auf Server A sichern und auf Server B übertragen Nachdem du die Backups erstellt hast, musst du sie zu **Server B** übertragen. Dies kann mit **`scp`** erfolgen: ```bash scp /path/to/backup/complete_backup.sql user@serverB:/path/to/backup/ ``` Oder für einzelne Dumps: ```bash scp /path/to/backup/keycloak.dump user@serverB:/path/to/backup/ scp /path/to/backup/process_engine.dump user@serverB:/path/to/backup/ scp /path/to/backup/prime.dump user@serverB:/path/to/backup/ ``` ### 3. Restore auf Server B (Ziel-Server) Nun, auf **Server B**, musst du die Datenbank wiederherstellen. #### Schritt 3.1: Globales Restore (für das vollständige `pg_dumpall` Backup) Wenn du den kompletten SQL-Dump wiederherstellen möchtest, nutze den folgenden Befehl: ```bash psql -U postgres -h localhost -p <PORT> -f /path/to/backup/complete_backup.sql ``` #### Schritt 3.2: Wiederherstellung einzelner Dumps Falls du die Datenbanken einzeln wiederherstellen möchtest, kannst du die Custom-Dumps so einspielen: 1. Datenbank leeren oder neu erstellen (optional): ```bash psql -U postgres -h localhost -p <PORT> -c "DROP DATABASE IF EXISTS keycloak; CREATE DATABASE keycloak;" psql -U postgres -h localhost -p <PORT> -c "DROP DATABASE IF EXISTS process_engine; CREATE DATABASE process_engine;" psql -U postgres -h localhost -p <PORT> -c "DROP DATABASE IF EXISTS prime; CREATE DATABASE prime;" ``` 2. Importiere die einzelnen Dumps: ```bash pg_restore -U postgres -h localhost -p <PORT> -d keycloak /path/to/backup/keycloak.dump pg_restore -U postgres -h localhost -p <PORT> -d process-engine /path/to/backup/process_engine.dump pg_restore -U postgres -h localhost -p <PORT> -d prime /path/to/backup/prime.dump ``` ### 4. Test und Verifizierung Sobald die Datenbanken wiederhergestellt wurden, überprüfe: - Dass die Datenbanken und Daten vollständig sind. - Dass die Rollen, Berechtigungen und Indizes korrekt übertragen wurden. - Teste die Verbindung deiner Applikationen zu den Datenbanken. ### 5. Services wieder hochfahren Nachdem alles getestet wurde, kannst du die anderen Services auf **Server B** wieder starten. --- ### Zusammenfassung: - Auf **Server A** mit `pg_dumpall` oder `pg_dump` ein Backup erstellen. - Das Backup auf **Server B** kopieren. - Mit `psql` oder `pg_restore` auf **Server B** das Backup wieder einspielen. - Verbindungen und Funktionalitäten prüfen. Falls du spezifische Docker-Details benötigst oder Hilfe bei der Konfiguration der PostgreSQL-Container brauchst, lass es mich wissen!

Die Fehlermeldung `template1 does not exist` tritt auf, weil das PostgreSQL-Standard-Backup-Tool `pg_dumpall` auch globale Objekte sichert, die sich auf alle Datenbanken beziehen (z. B. Rollen, Tablespaces, etc.). Dabei werden möglicherweise auch Datenbanken wie `template1` gesichert. Die Datenbank `template1` ist eine vordefinierte Systemdatenbank, die von PostgreSQL für das Erstellen neuer Datenbanken verwendet wird. Wenn das Skript beim Einspielen abbricht, deutet dies darauf hin, dass entweder die `template1`-Datenbank auf dem Zielserver fehlt oder inkonsistent ist. Hier sind ein paar Lösungsmöglichkeiten, die du ausprobieren kannst: ### 1. Überprüfe, ob `template1` auf dem Zielserver existiert Führe diesen Befehl auf **Server B** aus, um zu überprüfen, ob die `template1`-Datenbank existiert: ```bash psql -U postgres -h localhost -p <PORT> -l ``` Falls `template1` in der Liste fehlt, kann sie mit folgendem Befehl neu erstellt werden: ```bash psql -U postgres -h localhost -p <PORT> -c "CREATE DATABASE template1 TEMPLATE template0;" ``` Dabei wird `template1` von der Systemdatenbank `template0` kopiert, die für solche Zwecke standardmäßig bereitgestellt wird. ### 2. Führe das Skript ohne globale Objekte ein Falls das Problem weiterhin besteht, kannst du das Backup-Skript **ohne globale Objekte** (wie Rollen und Datenbanken) einspielen. Du kannst den Dump-Teil für Datenbanken und Tabellen ausführen, indem du den globalen Teil mit folgendem Befehl überspringst: ```bash psql -U postgres -h localhost -p <PORT> -d postgres -f /path/to/backup/complete_backup.sql --set ON_ERROR_STOP=on ``` ### 3. Separates Backup der globalen Objekte und Rollen erstellen Eine saubere Methode wäre, globale Objekte wie Rollen und Tablespaces separat mit **`pg_dumpall --globals-only`** zu sichern. Dann kannst du diese getrennt von den eigentlichen Datenbanksicherungen einspielen. #### Schritt 3.1: Backup der globalen Objekte (nur Rollen, Tablespaces) Erstelle ein separates Backup für die globalen Objekte: ```bash pg_dumpall --globals-only -U postgres -h localhost -p <PORT> > /path/to/backup/globals.sql ``` #### Schritt 3.2: Backup der Datenbanken erstellen Erstelle wie gewohnt ein Backup der Datenbanken (ohne globale Objekte): ```bash pg_dumpall --no-role-passwords --data-only -U postgres -h localhost -p <PORT> > /path/to/backup/databases.sql ``` #### Schritt 3.3: Einspielen des globalen Backups und der Datenbank-Dumps Zuerst spielst du die globalen Objekte ein: ```bash psql -U postgres -h localhost -p <PORT> -f /path/to/backup/globals.sql ``` Dann spielst du das eigentliche Datenbank-Backup ein: ```bash psql -U postgres -h localhost -p <PORT> -f /path/to/backup/databases.sql ``` ### 4. Direktes Löschen der `template1`-Referenzen im Backup-Skript Falls `template1` wirklich nicht benötigt wird, kannst du eine einfachere Methode anwenden und manuell die Referenzen zu `template1` aus deinem SQL-Backup entfernen: 1. Öffne das Backup-Skript `complete_backup.sql` in einem Texteditor. 2. Suche nach Einträgen, die `template1` betreffen, und lösche diese. 3. Danach kannst du das bereinigte Backup-Skript wie gewohnt einspielen. ### Fazit Die Fehlermeldung `template1 does not exist` deutet auf ein Problem mit der Systemdatenbank hin. Durch das Überprüfen und gegebenenfalls Wiederherstellen der `template1`-Datenbank oder das Separieren von globalen Objekten kannst du das Problem beheben. Wenn das Skript weiterhin nicht läuft, hilft es oft, das Skript manuell anzupassen oder die Dumps in zwei Teile (globale und datenbank-spezifische Objekte) zu unterteilen.

Das macht Sinn! Das **Custom-Format** (`-Fc`) von PostgreSQL hat einige Vorteile gegenüber dem reinen SQL-Dump, vor allem hinsichtlich Flexibilität und Zuverlässigkeit. Es ermöglicht eine selektive Wiederherstellung und sorgt häufig für weniger Probleme bei speziellen Objekten wie Rollen oder Systemdatenbanken. Hier ist ein erprobter Ansatz mit **Custom Format Dumps** (`pg_dump`) für deinen Anwendungsfall: ### 1. Backup im Custom-Format erstellen Da du mehrere Datenbanken hast (z.B. `keycloak`, `process-engine`, `prime`), wäre es am besten, für jede Datenbank einen eigenen Dump im **Custom-Format** zu erstellen. Das sieht folgendermaßen aus: ```bash pg_dump -U $POSTGRES_USER -h $HOSTNAME -p 5433 -Fc keycloak > /path/to/backup/keycloak.dump pg_dump -U $POSTGRES_USER -h $HOSTNAME -p 5433 -Fc process-engine > /path/to/backup/process_engine.dump pg_dump -U $POSTGRES_USER -h $HOSTNAME -p 5433 -Fc prime > /path/to/backup/prime.dump ``` - **-Fc**: Erzeugt das Custom-Format, das von `pg_restore` verwendet wird. - Diese Dumps enthalten alle Daten, Tabellen, Indizes, Views etc. für jede Datenbank einzeln. ### 2. Wiederherstellung der Datenbanken auf Server B Auf **Server B** kannst du diese Dumps nun wiederherstellen. Falls die Datenbanken bereits existieren, kannst du sie löschen und neu erstellen oder die vorhandenen Inhalte überschreiben. #### Schritt 2.1: Datenbanken erstellen (falls noch nicht vorhanden) Falls die Datenbanken auf dem neuen Server nicht existieren, erstellst du sie vorher: ```bash psql -U $POSTGRES_USER -h $HOSTNAME -p 5433 -c "CREATE DATABASE keycloak;" psql -U $POSTGRES_USER -h $HOSTNAME -p 5433 -c "CREATE DATABASE process_engine;" psql -U $POSTGRES_USER -h $HOSTNAME -p 5433 -c "CREATE DATABASE prime;" ``` #### Schritt 2.2: Custom-Dumps wiederherstellen Nutze den Befehl **`pg_restore`**, um die Dumps in die neu erstellten Datenbanken einzuspielen: ```bash pg_restore -U $POSTGRES_USER -h $HOSTNAME -p 5433 -d keycloak /path/to/backup/keycloak.dump pg_restore -U $POSTGRES_USER -h $HOSTNAME -p 5433 -d process-engine /path/to/backup/process_engine.dump pg_restore -U $POSTGRES_USER -h $HOSTNAME -p 5433 -d prime /path/to/backup/prime.dump ``` - **-d keycloak**: Gibt die Zieldatenbank an, in die der Dump importiert werden soll. - **pg_restore** sorgt dafür, dass Tabellen, Daten, Indizes und andere Objekte korrekt wiederhergestellt werden. ### 3. Globale Objekte (Rollen, Tablespaces) sichern und wiederherstellen Um auch **Rollen** und **Tablespaces** korrekt zu migrieren, erstellst du ein separates Backup der globalen Objekte auf **Server A** und spielst es auf **Server B** ein: #### Schritt 3.1: Backup der globalen Objekte erstellen Auf **Server A**: ```bash pg_dumpall --globals-only -U $POSTGRES_USER -h $HOSTNAME -p 5433 > /path/to/backup/globals.sql ``` #### Schritt 3.2: Globale Objekte auf Server B wiederherstellen Auf **Server B**: ```bash psql -U $POSTGRES_USER -h $HOSTNAME -p 5433 -f /path/to/backup/globals.sql ``` ### Vorteile des Custom-Formats: - **Selektive Wiederherstellung**: Mit `pg_restore` kannst du gezielt Tabellen oder andere Objekte wiederherstellen, falls es Probleme gibt. - **Effizienz**: Das Custom-Format ist oft kompakter und schneller zu erstellen und wiederherzustellen. - **Fehlertoleranz**: Im Gegensatz zu einem SQL-Dump ist das Einspielen robuster, und Fehler wie "template1 does not exist" treten seltener auf. ### Fazit Der Ansatz mit **Custom-Format-Dumps** vermeidet viele Probleme, die bei reinen SQL-Dumps auftreten, insbesondere bei der Handhabung von globalen Objekten und Systemdatenbanken wie `template1`. Wenn du bisher mit Custom-Dumps weniger Probleme hattest, ist das der richtige Weg für eine reibungslose Datenmigration.

Verstehe, wenn die Datenbanken zeitkritische Abhängigkeiten haben, dann ist es sinnvoll, einen **kompletten Dump** der gesamten PostgreSQL-Instanz zu erstellen, ohne die Datenbanken einzeln zu exportieren. So stellst du sicher, dass alle Datenbanken gleichzeitig gesichert und in einem konsistenten Zustand bleiben. In diesem Fall ist es auch möglich, mit dem **Custom-Format** für den gesamten Cluster zu arbeiten, um sowohl alle Datenbanken als auch globale Objekte (wie Rollen, Tablespaces) in einem einzigen Schritt zu sichern und wiederherzustellen. ### Vorgehensweise mit Custom-Format für den gesamten Cluster: #### 1. Komplettes Backup im Custom-Format erstellen Verwende **`pg_dumpall`**, aber wandle es so um, dass der gesamte Cluster (alle Datenbanken und Rollen) in ein Custom-Format exportiert wird: ```bash pg_dumpall -U $POSTGRES_USER -h $HOSTNAME -p 5433 --globals-only > /path/to/backup/globals.sql ``` Dieser Befehl sichert alle **globalen Objekte** (Rollen, Tablespaces, etc.) in eine separate SQL-Datei. Danach erstellst du ein Backup für **alle Datenbanken** zusammen, indem du **`pg_dump`** verwendest: ```bash pg_dump -U $POSTGRES_USER -h $HOSTNAME -p 5433 -Fc -d postgres > /path/to/backup/cluster_backup.dump ``` Hier werden **alle Datenbanken** in ein Custom-Format (`-Fc`) gepackt, und du vermeidest den Fehler von `pg_dumpall`, der durch die speziellen Systemdatenbanken wie `template1` ausgelöst werden könnte. #### 2. Datenbanken und globale Objekte auf Server B wiederherstellen ##### Schritt 2.1: Wiederherstellung der globalen Objekte (Rollen, Tablespaces) Zuerst musst du die globalen Objekte auf **Server B** wiederherstellen. Dafür verwendest du das `globals.sql`-Skript: ```bash psql -U $POSTGRES_USER -h $HOSTNAME -p 5433 -f /path/to/backup/globals.sql ``` ##### Schritt 2.2: Wiederherstellung der Datenbanken aus dem Custom-Backup Nun kannst du das **Custom-Format**-Backup, das den gesamten Cluster enthält, wiederherstellen. Dafür verwendest du `pg_restore`: ```bash pg_restore -U $POSTGRES_USER -h $HOSTNAME -p 5433 -d postgres /path/to/backup/cluster_backup.dump ``` - **-d postgres**: Dies ist die Datenbank, in die du die Datenbank-Backups einspielen willst. Da du ein komplettes Cluster-Backup hast, wird dies alles in die jeweiligen Datenbanken auf **Server B** einspielen. - **pg_restore** stellt sicher, dass alle Tabellen, Indizes, Views und Abhängigkeiten korrekt wiederhergestellt werden. ### Vorteile dieses Ansatzes: 1. **Komplettes Backup**: Alle Datenbanken werden in einem Schritt gesichert und wiederhergestellt, was Probleme mit zeitkritischen Abhängigkeiten zwischen Datenbanken minimiert. 2. **Zuverlässigkeit**: Da du das Custom-Format verwendest, vermeidest du häufige Probleme von SQL-Dumps, wie etwa fehlerhafte Systemdatenbanken oder inkonsistente Wiederherstellungen. 3. **Globale Objekte separat**: Durch das Sichern und Wiederherstellen der globalen Objekte separat (Rollen, Tablespaces) vermeidest du auch mögliche Konflikte. ### Fazit: Wenn du sicherstellen willst, dass alle Datenbanken konsistent und zeitgleich gesichert und wiederhergestellt werden, ist ein komplettes Cluster-Backup im **Custom-Format** der beste Weg. So vermeidest du auch Probleme mit Abhängigkeiten zwischen den Datenbanken und stellst sicher, dass alles in einem Schritt migriert wird.

Nein, **`pg_dump`** und **`pg_dumpall`** löschen keine bestehenden Datenbanken und legen sie auch nicht neu an. Beide Tools sind reine **Backup-Werkzeuge** und führen lediglich den Export der Datenbank- oder Clusterinformationen in eine Datei aus. Hier sind die Details: ### 1. Verhalten von `pg_dump`: - **`pg_dump`** sichert den Inhalt einer einzelnen Datenbank (Tabellen, Indizes, Daten, Views, Funktionen usw.) und exportiert diese in ein spezifisches Format (z.B. SQL oder Custom Format). - **Es löscht keine bestehende Datenbank.** Wenn du ein Backup mit `pg_dump` erstellst, wird nur der Datenbankinhalt exportiert. - Beim Wiederherstellen des Dumps (z.B. mit `pg_restore` oder `psql`) werden vorhandene Tabellen **überschrieben**, aber nur wenn du explizit die entsprechenden Optionen angibst (z.B. mit `--clean`). ### 2. Verhalten von `pg_dumpall`: - **`pg_dumpall`** sichert den gesamten PostgreSQL-Cluster, einschließlich aller Datenbanken sowie der globalen Objekte (Rollen, Tablespaces). - **Auch `pg_dumpall` löscht keine bestehenden Datenbanken.** Es exportiert die Struktur und den Inhalt jeder Datenbank im Cluster in eine Datei. ### Was passiert bei der Wiederherstellung? - **Standardmäßig** wird eine Datenbank **nicht gelöscht**, wenn du das Backup einspielst. - Wenn du einen SQL-Dump mit **`pg_dump`** erstellst und dann mit **`psql`** einspielst, werden nur die Objekte innerhalb der Datenbank (Tabellen, Indizes, Daten usw.) wiederhergestellt. Bestehende Datenbanken bleiben unverändert, es sei denn, du verwendest eine Option zum Überschreiben oder Entfernen der vorhandenen Daten. - Wenn du **`pg_restore`** verwendest, um einen Dump im Custom-Format wiederherzustellen, kannst du explizit angeben, ob vorhandene Daten gelöscht werden sollen: - **`--clean`**: Löscht vorhandene Objekte (Tabellen, Daten, etc.) vor der Wiederherstellung. - **`--create`**: Legt die Datenbank neu an. Dies funktioniert nur, wenn der Dump mit **`pg_dump`** oder **`pg_dumpall`** die entsprechenden Anweisungen enthält, um eine Datenbank zu erstellen (beispielsweise mit `-C` bei `pg_dump`). ### Optionen beim Wiederherstellen: - **Wenn du die Datenbank neu anlegen willst** (also die alte Version löschen und eine neue erstellen): - Du kannst entweder manuell die alte Datenbank löschen und neu erstellen oder die Option **`-C`** bei **`pg_dump`** verwenden, um sicherzustellen, dass die Datenbankdefinition mit in den Dump aufgenommen wird. Beispiel mit **`pg_dump`** und der Option `-C` (erstellt die Datenbank bei der Wiederherstellung neu): ```bash pg_dump -U $POSTGRES_USER -h $HOSTNAME -p 5433 -C -Fc keycloak > /path/to/backup/keycloak.dump ``` Beim Wiederherstellen wird die Datenbank dann neu angelegt, wenn du den Dump einspielst: ```bash pg_restore -U $POSTGRES_USER -h $HOSTNAME -p 5433 -C -d postgres /path/to/backup/keycloak.dump ``` - **Wenn du sicherstellen willst, dass alte Datenbankobjekte gelöscht werden**, kannst du `pg_restore` mit der Option **`--clean`** verwenden: ```bash pg_restore -U $POSTGRES_USER -h $HOSTNAME -p 5433 --clean -d keycloak /path/to/backup/keycloak.dump ``` ### Fazit: - **`pg_dump`** und **`pg_dumpall`** löschen **keine bestehenden Datenbanken**. Sie exportieren lediglich die Datenbankstrukturen und -inhalte. - Beim Wiederherstellen musst du manuell dafür sorgen, dass bestehende Datenbanken gelöscht oder neu angelegt werden, falls du dies wünschst. Dafür gibt es entsprechende Optionen bei **`pg_restore`** oder **`psql`** (wie `--clean` oder `--create`).

Hier ist ein fehlertolerantes Bash-Skript, das sowohl einen **Full-Dump** eines PostgreSQL-Clusters als auch eine **Wiederherstellung** basierend auf einem Befehlsschalter durchführt. Es verwendet das **Custom Format** für den Dump und kann alle Datenbanken sowie die globalen Objekte sichern und wiederherstellen. ### Features des Skripts: - **Fehlertoleranz**: Das Skript prüft auf Fehler während des Dumps oder der Wiederherstellung und gibt entsprechende Meldungen aus. - **Custom Format**: Verwendet das Custom-Format für den Dump, um eine flexiblere Wiederherstellung zu ermöglichen. - **Wiederherstellung basierend auf einem Befehlsschalter** (`--restore`). - **Globales Backup und Datenbanken separat**: Es speichert globale Objekte und Datenbanken separat. ```bash #!/bin/bash # Konfigurierbare Variablen PG_USER="postgres" # Postgres Benutzer PG_HOST="localhost" # PostgreSQL Host PG_PORT="5432" # PostgreSQL Port BACKUP_DIR="/path/to/backup" # Verzeichnis für Backup-Dumps # Backup-Dateien GLOBAL_DUMP="$BACKUP_DIR/globals.sql" CLUSTER_DUMP="$BACKUP_DIR/cluster_backup.dump" # Helfer-Funktion für Fehlermeldungen error_exit() { echo "[ERROR] $1" exit 1 } # Helfer-Funktion für Informationen info() { echo "[INFO] $1" } # Prüfen, ob das Backup-Verzeichnis existiert if [ ! -d "$BACKUP_DIR" ]; then error_exit "Backup-Verzeichnis $BACKUP_DIR existiert nicht." fi # Sicherstellung, dass benötigte PostgreSQL-Tools installiert sind command -v pg_dumpall >/dev/null 2>&1 || error_exit "pg_dumpall nicht gefunden." command -v pg_dump >/dev/null 2>&1 || error_exit "pg_dump nicht gefunden." command -v pg_restore >/dev/null 2>&1 || error_exit "pg_restore nicht gefunden." command -v psql >/dev/null 2>&1 || error_exit "psql nicht gefunden." # Sicherung durchführen perform_backup() { info "Starte Backup des gesamten PostgreSQL-Clusters..." # Globale Objekte (Rollen, Tablespaces) sichern info "Sichere globale Objekte..." pg_dumpall --globals-only -U "$PG_USER" -h "$PG_HOST" -p "$PG_PORT" > "$GLOBAL_DUMP" || error_exit "Fehler beim Sichern der globalen Objekte." # Datenbanken im Custom-Format sichern info "Sichere alle Datenbanken im Custom-Format..." pg_dump -U "$PG_USER" -h "$PG_HOST" -p "$PG_PORT" -Fc -d postgres > "$CLUSTER_DUMP" || error_exit "Fehler beim Sichern der Datenbanken." info "Backup erfolgreich abgeschlossen!" } # Wiederherstellung durchführen perform_restore() { info "Starte Wiederherstellung des gesamten PostgreSQL-Clusters..." # Zuerst globale Objekte wiederherstellen info "Stelle globale Objekte wieder her..." psql -U "$PG_USER" -h "$PG_HOST" -p "$PG_PORT" -f "$GLOBAL_DUMP" || error_exit "Fehler beim Wiederherstellen der globalen Objekte." # Datenbanken aus Custom-Dump wiederherstellen info "Stelle Datenbanken aus Custom-Dump wieder her..." pg_restore -U "$PG_USER" -h "$PG_HOST" -p "$PG_PORT" -d postgres "$CLUSTER_DUMP" || error_exit "Fehler beim Wiederherstellen der Datenbanken." info "Wiederherstellung erfolgreich abgeschlossen!" } # Hilfe-Funktion anzeigen usage() { echo "Nutzung: $0 [--backup|--restore]" echo "" echo "--backup : Erstellt ein komplettes Backup des PostgreSQL-Clusters." echo "--restore : Stellt ein komplettes Backup auf einem Zielsystem wieder her." exit 1 } # Kommando-Schalter prüfen if [ "$#" -ne 1 ]; then usage fi case "$1" in --backup) perform_backup ;; --restore) perform_restore ;; *) usage ;; esac exit 0 ``` ### Erläuterungen zum Skript: 1. **Konfigurierbare Variablen**: - `PG_USER`: Der PostgreSQL-Benutzer (Standard ist `postgres`). - `PG_HOST`: Der Hostname des PostgreSQL-Servers. - `PG_PORT`: Der Port des PostgreSQL-Servers. - `BACKUP_DIR`: Das Verzeichnis, in dem die Backup-Dateien gespeichert werden sollen. 2. **Backup-Logik** (`--backup`): - Das Skript sichert **globale Objekte** (Rollen, Tablespaces) mit `pg_dumpall --globals-only` in die Datei `globals.sql`. - Es sichert alle **Datenbanken** im Custom-Format mit `pg_dump -Fc -d postgres` in die Datei `cluster_backup.dump`. 3. **Restore-Logik** (`--restore`): - Die globalen Objekte werden mit `psql` aus der Datei `globals.sql` wiederhergestellt. - Alle Datenbanken werden aus dem Custom-Format-Dump `cluster_backup.dump` wiederhergestellt. 4. **Fehlertoleranz**: - Bei jedem Schritt wird auf Fehler geprüft. Wenn ein Fehler auftritt, wird eine Fehlermeldung ausgegeben und das Skript beendet sich. - Falls ein PostgreSQL-Befehl nicht verfügbar ist, gibt das Skript eine Fehlermeldung aus und bricht ab. 5. **Kommandozeilen-Schalter**: - Das Skript akzeptiert zwei Schalter: `--backup` für das Erstellen eines Backups und `--restore` für die Wiederherstellung. ### Verwendung des Skripts: 1. **Backup erstellen**: ```bash ./backup_restore.sh --backup ``` 2. **Backup wiederherstellen**: ```bash ./backup_restore.sh --restore ``` ### Anpassung: - Du kannst die Pfade und die PostgreSQL-Einstellungen (`PG_USER`, `PG_HOST`, etc.) im Skript entsprechend deiner Umgebung anpassen. - Falls du weitere Optionen für `pg_dump`, `pg_restore` oder `psql` benötigst, kannst du sie einfach ergänzen. Dieses Skript bietet eine einfache, fehlertolerante Möglichkeit, eine PostgreSQL-Datenbank zu sichern und wiederherzustellen, und sollte gut für deinen zeitkritischen Anwendungsfall geeignet sein.

Ja, ein **physikalisches Backup** (oder **Dateisystem-basierte Sicherung**) der PostgreSQL-Datenbank ist definitiv möglich und eine gängige Methode, um eine **Datenbank sehr schnell und konsistent zu migrieren**, insbesondere wenn du bereits mit **Docker** arbeitest und ein Docker-Volume für die Datenbank nutzt. Mit dieser Methode kopierst du direkt die Datenbankdateien vom **Server A** auf den **Server B** und ersetzt damit das bestehende Volume der PostgreSQL-Datenbank auf Server B. Dies hat den Vorteil, dass du die gesamte Datenbank **1:1** überträgst, einschließlich der Daten, Konfigurationen und Transaktionsprotokolle. ### Vorteile eines physikalischen Backups: - **Schnell**: Es ist meist schneller als logische Backups (z.B. `pg_dump`), da es keine Umwandlung in SQL oder ein anderes Format erfordert. - **Vollständige Wiederherstellung**: Es werden alle Datenbankobjekte, Einstellungen und Daten direkt übernommen, inklusive laufender Transaktionen, solange die Datenbank in einem konsistenten Zustand gesichert wird. - **Kein Datenbank-Dump notwendig**: Du musst keine Datenbanken neu anlegen oder Dumps importieren, sondern nur die Dateien auf das neue System übertragen. ### Voraussetzungen für ein physikalisches Backup: 1. Die Datenbank muss in einem **konsistenten Zustand** gesichert werden. 2. Die PostgreSQL-Version auf beiden Servern (**Server A** und **Server B**) muss **identisch** oder sehr ähnlich sein (möglichst keine Versionsunterschiede). 3. Der Datenbankserver auf **Server B** darf während des Imports nicht laufen, damit das Volume nicht verwendet wird. ### Vorgehen für das physikalische Backup und die Wiederherstellung: #### 1. Vorbereitung: Datenbank auf **Server A** in den Wartungsmodus versetzen Bevor du das Datenverzeichnis sicherst, solltest du sicherstellen, dass PostgreSQL sich in einem konsistenten Zustand befindet. Dies kann entweder durch das Stoppen der PostgreSQL-Instanz oder durch die Verwendung eines **Point-in-Time-Wiederherstellungsmechanismus (PITR)** geschehen. ##### Option A: PostgreSQL stoppen (einfachste Methode) Du kannst den PostgreSQL-Server einfach stoppen und dann das Datenverzeichnis sichern. Dies sorgt dafür, dass die Datenbank in einem sauberen Zustand ist. ```bash # PostgreSQL stoppen docker stop <postgres-container-name> ``` #### 2. Sicherung des Datenbank-Volumes auf **Server A** Wenn der PostgreSQL-Server gestoppt ist, kannst du das Docker-Volume, das die Datenbankdateien enthält, direkt kopieren. Du musst zuerst den Ort des Docker-Volumes herausfinden, in dem die PostgreSQL-Daten gespeichert sind. Docker Volumes befinden sich normalerweise im Verzeichnis `/var/lib/docker/volumes`. ```bash # Beispiel für die Sicherung eines Docker-Volumes docker cp <postgres-container-name>:/var/lib/postgresql/data /path/to/backup ``` Oder, wenn du direkt auf das Docker-Volume zugreifen willst (was oft der Fall ist), kannst du es auch manuell kopieren: ```bash cp -R /var/lib/docker/volumes/<postgres-data-volume>/_data /path/to/backup ``` Dies kopiert das gesamte PostgreSQL-Datenverzeichnis auf **Server A**. #### 3. Übertragung des Backups auf **Server B** Nun musst du die gesicherten Dateien vom **Server A** auf den **Server B** übertragen. Dies kannst du z.B. mit **`rsync`** oder **`scp`** tun: ```bash # Beispiel mit scp scp -r /path/to/backup user@serverB:/path/to/restore ``` #### 4. Stoppe den PostgreSQL-Container auf **Server B** Bevor du die gesicherten Dateien wiederherstellst, stelle sicher, dass der PostgreSQL-Container auf **Server B** gestoppt ist, um Dateikonflikte zu vermeiden. ```bash docker stop <postgres-container-name> ``` #### 5. Wiederherstellung des Datenbank-Volumes auf **Server B** Sobald die Datenbankdateien auf **Server B** angekommen sind, kannst du sie in das entsprechende Docker-Volume kopieren, das vom PostgreSQL-Container verwendet wird. Du musst sicherstellen, dass das alte Volume leer ist oder überschrieben wird. ```bash # Vorhandenes Volume auf Server B überschreiben cp -R /path/to/restore/* /var/lib/docker/volumes/<postgres-data-volume>/_data ``` #### 6. Rechte und Eigentümer anpassen PostgreSQL benötigt bestimmte Berechtigungen für das Datenverzeichnis. Achte darauf, dass die Berechtigungen korrekt gesetzt sind, z.B. für den Benutzer `postgres`: ```bash chown -R postgres:postgres /var/lib/docker/volumes/<postgres-data-volume>/_data chmod -R 700 /var/lib/docker/volumes/<postgres-data-volume>/_data ``` #### 7. PostgreSQL-Container auf **Server B** starten Nach der Wiederherstellung der Datenbankdateien kannst du den PostgreSQL-Container auf **Server B** wieder starten: ```bash docker start <postgres-container-name> ``` Wenn alles korrekt durchgeführt wurde, sollte der PostgreSQL-Container auf **Server B** nun die Daten aus dem physikalischen Backup verwenden. ### 8. Überprüfen der Datenbank auf **Server B** Zum Schluss kannst du prüfen, ob alle Daten und Verbindungen korrekt hergestellt wurden, indem du dich mit der Datenbank auf **Server B** verbindest: ```bash psql -U postgres -h localhost -p 5432 -d <database_name> ``` ### Fazit: Ein **physikalisches Backup** ist eine schnelle und effiziente Methode, um eine **1:1-Kopie** der PostgreSQL-Datenbank zwischen zwei Docker-Containern zu erstellen, besonders bei zeitkritischen Anwendungen. Es vermeidet die langwierige Wiederherstellung großer Datenmengen und das Risiko von Fehlern bei der Datenbankstruktur, die bei logischen Backups auftreten können.

Um das Docker-Volume zu identifizieren, das von einem persistenten PostgreSQL-Container verwendet wird, gibt es mehrere Ansätze. Docker speichert die Volumes in einem speziellen Bereich des Dateisystems, und durch ein paar einfache Befehle kannst du herausfinden, welches Volume deinem PostgreSQL-Container zugeordnet ist. ### 1. Docker-Inspect-Befehl verwenden Der einfachste und direkteste Weg, das Volume zu identifizieren, ist die Verwendung des Docker-Inspect-Befehls. Dieser zeigt detaillierte Informationen über einen Docker-Container, einschließlich der Verzeichnisse und Volumes, die dieser verwendet. #### Schritte: 1. **Finde den Namen oder die ID des PostgreSQL-Containers**: Verwende den folgenden Befehl, um alle laufenden Container aufzulisten und den PostgreSQL-Container zu identifizieren: ```bash docker ps ``` Falls der Container gestoppt ist, kannst du den Befehl auch mit `-a` verwenden, um alle Container aufzulisten: ```bash docker ps -a ``` Sagen wir, der Container heißt `postgres_container`. 2. **Inspect-Befehl ausführen**: Nutze `docker inspect`, um detaillierte Informationen über den Container zu erhalten, einschließlich des Volumes, das für die PostgreSQL-Daten verwendet wird: ```bash docker inspect postgres_container ``` 3. **Volume-Informationen im Output finden**: Suche im Ausgabeergebnis nach dem Abschnitt `"Mounts"`. Das zeigt alle Volumes, die der Container verwendet. Der relevante Teil sieht ungefähr so aus: ```json "Mounts": [ { "Type": "volume", "Name": "pg_data_volume", "Source": "/var/lib/docker/volumes/pg_data_volume/_data", "Destination": "/var/lib/postgresql/data", "Driver": "local", "Mode": "rw", "RW": true, "Propagation": "" } ] ``` - **`Source`**: Dies zeigt den tatsächlichen Pfad auf deinem Host-System, in dem die Daten gespeichert sind. In diesem Beispiel: `/var/lib/docker/volumes/pg_data_volume/_data`. - **`Destination`**: Dies zeigt, wohin das Volume im Container gemountet wird, was in den meisten PostgreSQL-Containern `/var/lib/postgresql/data` ist. ### 2. Docker-Volumes-Command verwenden Falls du nur herausfinden möchtest, welche Volumes generell auf deinem Docker-System existieren, kannst du den Befehl `docker volume ls` verwenden, um eine Liste aller Volumes zu erhalten. ```bash docker volume ls ``` Dieser Befehl zeigt eine Ausgabe ähnlich dieser: ``` DRIVER VOLUME NAME local pg_data_volume local some_other_volume ``` Das PostgreSQL-Volume wird wahrscheinlich eine ähnliche Bezeichnung wie `pg_data_volume` haben. ### 3. Bestimmtes Volume inspizieren Wenn du weißt, welches Volume deinem PostgreSQL-Container zugeordnet ist, kannst du das Volume direkt inspizieren, um mehr Details zu erfahren, etwa den genauen Speicherort auf dem Host. ```bash docker volume inspect pg_data_volume ``` Die Ausgabe zeigt Informationen über das Volume, wie den Speicherort auf dem Host: ```json [ { "CreatedAt": "2024-09-18T12:34:56Z", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/pg_data_volume/_data", "Name": "pg_data_volume", "Options": null, "Scope": "local" } ] ``` Der wichtige Teil hier ist der **`Mountpoint`**, der angibt, wo sich die Daten auf deinem Host befinden. ### 4. Überprüfen der `docker-compose.yml`-Datei (falls verwendet) Wenn du **Docker Compose** verwendest, sind die Volumes möglicherweise in der `docker-compose.yml`-Datei definiert. In dieser Datei findest du das Volume, das für PostgreSQL verwendet wird. Beispiel einer `docker-compose.yml`-Datei mit einem PostgreSQL-Volume: ```yaml version: '3.1' services: postgres: image: postgres environment: POSTGRES_USER: example POSTGRES_PASSWORD: example volumes: - pg_data:/var/lib/postgresql/data volumes: pg_data: driver: local ``` Hier wird das Volume `pg_data` verwendet und in den Container unter `/var/lib/postgresql/data` gemountet. ### Zusammenfassung: Um das Volume zu identifizieren, das von deinem PostgreSQL-Container verwendet wird, kannst du den **`docker inspect`** Befehl verwenden, um Details über die Mounts des Containers zu erhalten. Alternativ kannst du **`docker volume ls`** und **`docker volume inspect`** verwenden, um alle Volumes aufzulisten und Details über ein spezifisches Volume zu erhalten. Wenn du Docker Compose verwendest, findest du die Volumes auch in der `docker-compose.yml`-Datei.

Gern geschehen! Es freut mich, dass die Vorschläge hilfreich waren. Viel Erfolg bei der Umsetzung morgen – wenn du weitere Fragen hast oder Unterstützung brauchst, stehe ich dir jederzeit zur Verfügung. 😊 Viel Erfolg mit dem Server-Umzug!