Kann Ihre Business-App einen Fehler beheben, ohne spätere Arbeit zu verlieren?

Eine Business-App kann möglicherweise einen früheren Datenbankstand wiederherstellen, ohne damit einen einzelnen Fehler im laufenden System sicher rückgängig machen zu können. Klären Sie, welches Verfahren tatsächlich eingerichtet ist, welchen Umfang es zurücksetzt und wie inzwischen korrekt erledigte Arbeit erhalten bleibt. „Wir haben Backups“ beantwortet diese Fragen nicht.

Das wird wichtig, wenn ein fehlerhafter Import oder eine Löschung erst auffällt, nachdem das Team weitergearbeitet hat. Einen früheren Stand getrennt untersuchen, ausgewählte Daten nach einem geprüften Verfahren reparieren und die produktive Datenbank vollständig ersetzen sind unterschiedliche Eingriffe. Sie brauchen unterschiedliche Freigaben.

Welchen Stand stellt das Verfahren wieder her?

Die PostgreSQL-Dokumentation zur kontinuierlichen Archivierung beschreibt eine Basissicherung zusammen mit archivierten Write-Ahead-Log-Dateien. Beim Wiederherstellen werden aufgezeichnete Änderungen erneut abgespielt. Das lässt sich an einem früheren Zeitpunkt stoppen, sodass ein konsistenter Datenbankstand dieses Zeitpunkts entsteht. Die dokumentierte Technik beweist weder, dass Ihr Hosting-Tarif sie enthält, noch dass sie für Ihre App eingerichtet wurde.

Entscheidend ist der Umfang: Das beschriebene Verfahren stellt einen vollständigen Datenbank-Cluster wieder her, nicht einen ausgewählten Kunden oder Auftrag. „Cluster“ bezeichnet hier die PostgreSQL-Datenbanksammlung und nicht mehrere Bürocomputer. Diesen Stand im Produktivsystem zurückzusetzen ist deshalb etwas anderes als „Rückgängig“ auf einer einzelnen Bildschirmseite.

Auch das Wort „Backup“ bezeichnet nicht automatisch diese Fähigkeit. PostgreSQL erklärt ausdrücklich, dass logische Sicherungen mit pg_dump oder pg_dumpall nicht als dateisystembasierte Basissicherung für dieses Archivierungsverfahren dienen können. Lassen Sie sich das tatsächlich verwendete Verfahren nennen, statt es aus einer Dateiendung oder einem grünen Sicherungssymbol abzuleiten.

Ein späterer richtiger Auftrag verändert die Lage

Ein erfundenes Beispiel: Morgens überschreibt ein falscher Import Kundendaten. Bevor das auffällt, erfasst das Team einen berechtigten neuen Auftrag und versendet dazu eine Nachricht. Eine vollständige Rückkehr zum Datenbankstand vor dem Import würde die Datenbank auch vor diesen Auftrag zurücksetzen. Die Nachricht wäre dadurch nicht zurückgeholt.

Legen Sie fest, was mit Aktivitäten zwischen dem gewählten Wiederherstellungszeitpunkt und der Fehlerbearbeitung geschieht. Dazu gehören neue Datensätze, Änderungen, hochgeladene Dateien und Vorgänge bei angebundenen Diensten. Ein in sich konsistenter alter Datenbankstand belegt nicht, dass der heutige Geschäftsablauf dazu passt.

Fragen Sie zunächst, ob ein früherer Stand zur Untersuchung in einer isolierten Umgebung aufgebaut werden kann, während der aktuelle Stand erhalten bleibt. Das ist eine vorgeschlagene Vorgehensweise, keine automatisch zugesagte Funktion des Datenbankverfahrens. Sollen anschließend einzelne Daten repariert werden, müssen ihre Beziehungen und zwischenzeitliche Änderungen vor dem Zurückschreiben geprüft werden. Eine alte Kundenzeile über die aktuelle zu kopieren ist noch kein vollständiger Reparaturplan.

Wie weit reicht die Wiederherstellung wirklich zurück?

Das PostgreSQL-Verfahren benötigt eine lückenlose Folge archivierter Logdateien, die mindestens bis zum Beginn der Basissicherung zurückreicht. Eine aktuell wirkende Basissicherung allein belegt nicht, dass diese Kette vorhanden ist.

Verlangen Sie eine verständliche Angabe zum frühesten und spätesten tatsächlich verfügbaren Wiederherstellungspunkt, zur Prüfung dieser Verfügbarkeit und zur Zuständigkeit bei Archivierungsfehlern. Unterscheiden Sie den Zeitpunkt des Fehlers von seiner Entdeckung. Liegt der benötigte Verlauf bereits außerhalb des verfügbaren Fensters, wäre die Zusage „zu jedem beliebigen Zeitpunkt“ irreführend.

Schreiben Sie keine beeindruckende pauschale Minutenzahl ins Briefing. Bestimmen Sie mit dem Betrieb, welcher Datenverlust und welche Unterbrechung akzeptabel wären. Lassen Sie danach vorführen, ob die gewählte Lösung diese Anforderung erfüllt. Ein Planungsziel und das Ergebnis einer Übung sind unterschiedliche Angaben.

Die Testkopie darf nicht zum zweiten Produktivsystem werden

Als Schutzmaßnahme sollte die Übungsumgebung nicht öffentlich sein und keine echten E-Mails, Zahlungen oder Automatisierungsaktionen auslösen können. Verwenden Sie für die Abnahme erfundene Daten mit einer früheren Fehländerung und späterer korrekter Arbeit. Alte wieder auftauchende Aufgaben dürfen nicht versehentlich Kunden kontaktieren.

Vereinbaren Sie, wer einen produktiven Wechsel freigibt, wie laufende Schreibvorgänge nötigenfalls pausieren, welcher aktuelle Stand zuvor gesichert wird und wie die wiederhergestellte App geprüft wird. Außerhalb der Datenbank gespeicherte Dateien brauchen eine eigene Entscheidung zur Wiederherstellung und zum passenden Stand. Ein PostgreSQL-Restore stellt nicht automatisch Uploads, Hosting-Einstellungen oder Transaktionen fremder Dienste wieder her.

Welchen Nachweis sollten Sie verlangen?

Fordern Sie ein datiertes Übungsprotokoll mit dem gewählten Zeitpunkt, der Zielumgebung, dem tatsächlich wiederhergestellten Umfang und dem Ergebnis für spätere Testvorgänge. Fehlende Archive, nicht verfügbare Zeitpunkte oder gescheiterte Wiederherstellungen müssen erklärt werden. Ein Screenshot einer erfolgreichen Sicherung ersetzt das nicht.

Prüfen Sie einen ausgewählten früheren Stand und die betroffenen Testdaten. Lassen Sie den vereinbarten Umgang mit späterer korrekter Arbeit und externen Aktionen zeigen. Halten Sie fest, was nur besprochen und was wirklich erprobt wurde. Bringen Sie diesen Ablauf in ein Gespräch über Ihre Web-App mit. Die brauchbare Zusage ist ein begrenztes, vorgeführtes Wiederherstellungsverfahren, kein unbegrenzter Rückgängig-Knopf.