PostgreSQL-Backup prüfen: Vom Dump zum nutzbaren System

Zuerst festlegen, was wieder funktionieren muss

Wählen Sie einen vorhandenen Sicherungsstand und eine konkrete Anwendung. Notieren Sie Sicherungszeitpunkt, Datenbankname, PostgreSQL-Version, Dumpformat und die verwendeten Werkzeuge. Erfassen Sie auch Anwendungsversion, Erweiterungen und Dateien außerhalb der Datenbank, beispielsweise Dokumentanhänge. Ein Datenbank-Dump enthält diese externen Dateien nicht automatisch.

Legen Sie mit der Fachabteilung fest, welche Arbeitsschritte die Abnahme belegen. Für eine beispielhafte Auftragsverwaltung könnten das Anmeldung, das Lesen eines bekannten Auftrags und das Speichern eines gekennzeichneten Testdatensatzes sein. Das ist ein Testbeispiel, keine Kundenreferenz. Messbar wird der Test, wenn das erwartete Ergebnis vorher feststeht.

Das Ziel eindeutig von der Produktion trennen

Verwenden Sie eine getrennte Testinstanz mit eigener Datenbank und eigenen Anwendungszugängen. Prüfen Sie Hostname und Ziel vor jedem Import. Unterbinden Sie automatische Kundenmails, Zahlungen, Webhooks und Hintergrundjobs mit produktiven Nebenwirkungen. Ein anderer Datenbankname allein verhindert nicht, dass eine Anwendung externe Systeme anspricht.

Ein Restore-Test verarbeitet möglicherweise echte Unternehmensdaten. Begrenzen Sie Zugriff und Aufbewahrung entsprechend und schützen Sie Sicherungsdateien sowie Zugangsdaten. Verwenden Sie nur Dumps aus einer vertrauenswürdigen Quelle: Beim Wiederherstellen werden darin enthaltene Datenbankanweisungen ausgeführt. Die PostgreSQL-Dokumentation weist ausdrücklich auf diese Vertrauensgrenze hin.

Rollen und Erweiterungen vor dem Import prüfen

pg_dump sichert eine einzelne Datenbank. Globale Objekte wie Rollen und Tablespaces gehören nicht zu diesem Umfang; pg_dumpall kann sie gesondert erfassen. Klären Sie deshalb, welche Rollen am Ziel benötigt werden und wie Eigentümer sowie Berechtigungen wiederhergestellt werden. Eine Option wie --no-owner verändert die Zuordnung und ist kein Ersatz für die Prüfung mit dem späteren Anwendungskonto.

Prüfen Sie außerdem benötigte Erweiterungen und die Kompatibilität der eingesetzten Datenbank- und Werkzeugversionen. Planen Sie die erste Probe möglichst mit einer Umgebung, die der wiederherzustellenden Installation entspricht. Einen Versionswechsel behandeln Sie als zusätzliche Änderung mit eigener Prüfung, statt ihn unbemerkt mit dem Wiederherstellungstest zu verbinden.

Das passende Werkzeug verwenden und Fehler auswerten

Ein SQL-Dump im Klartext wird mit psql eingelesen; für die Archivformate von pg_dump ist pg_restore vorgesehen. Die Dateiendung allein beschreibt das Format nicht zuverlässig. Halten Sie das tatsächlich verwendete Sicherungsverfahren fest und orientieren Sie den Import an dessen Format.

Lassen Sie Fehler nicht nur in einer langen Ausgabe verschwinden. psql kann mit ON_ERROR_STOP=on beim ersten SQL-Fehler abbrechen; pg_restore bietet --exit-on-error. Ein Abbruch rollt bereits abgeschlossene Schritte nicht automatisch zurück. Eine einzelne Transaktion ist eine gesonderte Option und muss zu Umfang und Ablauf passen. Dokumentieren Sie Rückgabestatus und Fehlermeldungen, bevor Sie die Anwendung starten.

Mit dem Anwendungskonto testen

Prüfen Sie den Datenstand anhand bekannter Datensätze. Starten Sie anschließend die passende Anwendungsversion und testen Sie die vereinbarten Abläufe mit den vorgesehenen Rechten. Ein erfolgreicher Zugriff als Datenbankadministrator sagt wenig darüber aus, ob das eingeschränkte Anwendungskonto lesen und schreiben kann. Kontrollieren Sie auch, ob zugehörige Anhänge vorhanden sind und zum Datenstand passen.

Messen Sie die gesamte Dauer: Sicherung bereitstellen, Ziel vorbereiten, Daten importieren und fachlich prüfen. Halten Sie daneben fest, wie alt der wiederhergestellte Stand ist. Benötigte Wiederanlaufzeit und möglicher Verlust neuerer Änderungen sind zwei unterschiedliche Ergebnisse. Beides muss zu den Anforderungen des Betriebs passen.

• Sicherungsstand, Formate, Versionen und verwendete Optionen dokumentieren.
• Importstatus, Fehler, Berechtigungen und externe Dateien kontrollieren.
• Anmeldung, Lesen und Schreiben mit dem Anwendungskonto abnehmen.
• Dauer, Datenstand, offene Punkte und Verantwortliche festhalten.
• Testdaten nach dem vereinbarten Verfahren entfernen und nach wesentlichen Änderungen erneut testen.

Den Test in den Betrieb übernehmen

Ein erster erfolgreicher Test liefert einen Ausgangspunkt. Wiederholen Sie ihn nach Änderungen am Sicherungsverfahren, an Erweiterungen oder an der Anwendung und in einem zum Risiko passenden Rhythmus. Für eine Server- oder Betriebsanfrage an NUXOA helfen die dokumentierten Versionen, der Datenumfang und die gemessenen Zeiten. Klären Sie ausdrücklich, wer die Datenbank sichert, Wiederherstellungstests ausführt und offene Fehler bearbeitet.