Point in Time Recovery (PITR): Datenbank auf die Minute zurückholen
Point in Time Recovery statt Stand von gestern Nacht
Laut der Bitkom-Studie Wirtschaftsschutz 2025 hatten 34 Prozent der befragten Unternehmen innerhalb eines Jahres Schaden durch Ransomware, 2022 waren es 12 Prozent. Ob danach der Stand der letzten Nacht zurückkommt oder jener der letzten Minute, entscheidet ein Verfahren, das eine Datenbank wie eine Uhr zurückdreht.
Point in Time Recovery (PITR) ist ein Verfahren, das eine Datenbank auf einen frei gewählten Zeitpunkt in der Vergangenheit zurücksetzt, meist auf die Sekunde genau. Grundlage sind eine vollständige Basissicherung und das fortlaufend gesicherte Transaktionsprotokoll, in dem die Datenbank jede Änderung der Reihe nach mitschreibt. Bei der Wiederherstellung wird die Basissicherung eingespielt und das Protokoll bis zum gewählten Zeitpunkt nachgespielt.
Was die Datenbank dafür mitschreiben muss
Bei PostgreSQL heißt das Transaktionsprotokoll Write Ahead Log und dient zugleich der Reparatur nach einem Absturz, bei MySQL übernimmt das Binary Log diese Rolle. Für eine Zeitpunktwiederherstellung reicht das laufende Protokoll aber nicht. Es muss fortlaufend und ohne Lücke in ein Archiv kopiert werden, denn das Nachspielen endet an der ersten fehlenden Datei. Die nächtliche Datenbanksicherung bleibt dabei die Basis, das Archiv füllt die Stunden zwischen zwei Läufen.
Ohne archiviertes Binary Log ist eine Point in Time Recovery unter MySQL nicht möglich, und für die Point in Time Recovery mit PostgreSQL gilt dasselbe für das Write Ahead Log. Manches steht allerdings in keinem Protokoll. Außerhalb der Wiederherstellung bleiben typischerweise:
- Konfigurationsdateien des Datenbankservers
- hochgeladene Dokumente und Bilder im Dateisystem
- Zugangsdaten und Zertifikate der Anwendung
- Datenstände angebundener Systeme wie Shop oder Buchhaltung
Wie weit PITR zurückreicht
Wie weit das Verfahren zurückreicht, hängt allein daran, wie lange Basissicherung und Protokollarchiv aufbewahrt werden, und ist damit eine Frage der Datensicherung, nicht der Datenbanktechnik. AWS nennt für kontinuierliche Backups höchstens 35 Tage, Azure SQL ebenfalls. Im eigenen Betrieb ist das Fenster frei wählbar, jeder zusätzliche Tag belegt aber Speicher.
Welches Fenster gilt und welche Wiederherstellungszeit zugesagt ist, steht bei einem externen Betrieb im Service Level Agreement. Fehlt die Angabe dort, wird sie erst im Ernstfall verhandelt. Ältere Stände kommen dann nur noch aus einer Vollsicherung, also ohne Minutengenauigkeit. Ob das Archiv einen Angriff übersteht, der die Server selbst verschlüsselt, klärt der Abschnitt PITR nach einem Ransomware-Angriff.
Was bei der Wiederherstellung zu entscheiden ist
Nach einem Fehler fallen drei Entscheidungen an. Zuerst der Zielzeitpunkt, also die letzte Minute vor dem Fehler, den meist der Zeitstempel der letzten korrekten Buchung verrät. Dann der Weg, ob die ganze Datenbank ersetzt wird oder nur einzelne Daten zurückkommen. Und schließlich die Frage, wie lange der Betrieb ohne die Anwendung auskommt, bis die Wiederherstellung zu einem bestimmten Zeitpunkt abgeschlossen ist.
Ganze Datenbank ersetzen oder Daten herausholen?
Das Zurücksetzen der ganzen Datenbank ist der einfachste Weg und der teuerste, denn es löscht jede korrekte Bestellung seit dem Zielzeitpunkt. Azure SQL legt bei einer Point in Time Recovery deshalb immer eine neue Datenbank neben der alten an. Aus dieser Kopie holt ein Skript nur die beschädigten Daten zurück in den laufenden Bestand. Gelöschte Datensätze aus der Datenbank wiederherstellen, ohne die Arbeit danach zu verlieren, gelingt nur auf diesem Weg. Der parallele Aufbau braucht Speicher und Rechenleistung für eine zweite Datenbank, meist nur für Stunden.
Was mit den Buchungen nach dem Fehler geschieht
Wird trotzdem ersetzt, weil der Fehler zu tief sitzt, fehlen alle Vorgänge ab dem Zielzeitpunkt. Sie werden aus anderen Quellen nachgetragen, etwa aus Bestellmails oder dem Zahlungsdienst. Heikel sind angebundene Systeme. Eine Finanzbuchhaltung, die über eine Schnittstelle Daten erhalten hat, springt nicht mit zurück und kennt danach Rechnungsnummern, die es in der Datenbank nicht mehr gibt.
Wie lange dauert eine Point in Time Recovery?
Die Dauer setzt sich aus dem Einspielen der Basissicherung und dem Nachspielen jeder Änderung seit ihrem Ende zusammen. Microsoft nennt für große oder sehr aktive Datenbanken in Azure SQL mehrere Stunden. Bestimmt wird die Wiederherstellungszeit vor allem durch diese Größen:
- Größe der Basissicherung
- Abstand zwischen Basissicherung und Zielzeitpunkt
- Menge der Änderungen in diesem Abstand
- Rechenleistung und Speichertempo des Zielservers
- Netzwerk, wenn das Archiv entfernt liegt
Häufigere Basissicherungen verkürzen das Nachspielen deutlich, weil weniger Protokoll anfällt, belegen aber mehr Speicher. Der vereinbarte Höchstwert heißt Recovery Time Objective (RTO). Er sagt, wie lange der Betrieb höchstens ohne die Anwendung auskommen muss, und gibt damit den Takt der Basissicherungen vor.
Wo Point in Time Recovery an Grenzen stößt
Das Verfahren setzt voraus, dass Basissicherung und Protokollarchiv vollständig und unbeschädigt vorliegen. Ein Angriff, der ganze Server verschlüsselt, zielt auf diese Voraussetzung. Verwaltete Cloud-Datenbanken schränken sie auf ihre Weise ein, über feste Fenster und Regeln zum Speicherort. Beide Fälle entscheiden, ob ein vereinbarter Minutenwert im Ernstfall hält.
PITR nach einem Ransomware-Angriff
Wer die Datenbank nach dem Ransomware-Angriff wiederherstellen will, kommt mit einer Point in Time Recovery nur weiter, wenn Basissicherung und Protokollarchiv den Angriff überstanden haben. Liegen beide auf einem Speicher, den der Datenbankserver mit denselben Zugangsdaten beschreibt, verschlüsselt der Angriff sie womöglich mit. Hinzu kommt der Zeitpunkt, denn Schadsoftware kann schon aktiv sein, bevor sie Daten verschlüsselt. Das Aufbewahrungsfenster muss länger sein als die Zeit bis zur Entdeckung, sonst ist der saubere Zeitpunkt aus dem Archiv bereits gelöscht.
Das Protokollarchiv getrennt aufbewahren
Der BSI IT-Grundschutz sieht im Baustein CON.3 vor, Datensicherungen räumlich getrennt von den gesicherten Systemen aufzubewahren und vor unbefugtem Zugriff zu schützen. Für das Protokollarchiv heißt das, es liegt auf einem eigenen Speicher mit eigenen Zugangsdaten, auf dem geschriebene Dateien möglichst unveränderlich sind. Bricht die Übertragung einer einzigen Protokolldatei ab, endet jede spätere Wiederherstellung an dieser Stelle, oft unbemerkt. Das Backup Monitoring prüft deshalb auch den Archivlauf, nicht nur die nächtliche Sicherung.
Reicht die Wiederherstellung einer Cloud-Datenbank?
Von den Unternehmen mit 50 bis 249 Beschäftigten nutzten 2025 laut Statistischem Bundesamt 65 Prozent kostenpflichtige Cloud-Dienste. Verwaltete Datenbanken bringen die Funktion meist mit, bei AWS RDS bis etwa fünf Minuten vor dem aktuellen Stand. Microsoft nennt sie auf Deutsch Point-in-Time-Wiederherstellung, auf Englisch heißt sie bei Azure SQL Point in Time Restore. Die Point in Time Recovery bei AWS RDS hat wie die bei Azure feste Grenzen:
❗ höchstens 35 Tage zurück
❗ Wiederherstellung immer als neue Datenbank
❗ bei Azure SQL nur auf demselben Server
❗ ein gelöschter Server nimmt seine PITR-Sicherungen mit
❗ bei AWS keine PITR-Kopien in andere Regionen
Die täglichen AWS-Snapshots reichen weiter zurück, doch ein Snapshot Backup hält nur einen Moment fest. Gegen den Verlust des Kontos oder einer Region schützt erst eine Kopie außerhalb des Anbieters, und nicht alle Backup-Lösungen nehmen dabei das Protokoll der Datenbank mit. Continuous Data Protection auf Speicherebene ersetzt das Protokollarchiv nicht, weil sie meist nichts von den Transaktionen der Datenbank weiß.
Recovery Point Objective für die Datenbank festlegen
Das Recovery Point Objective (RPO) beschreibt, wie viel Arbeit bei einem Fehler höchstens verloren gehen darf, gemessen als Zeitspanne. Mit nächtlichen Sicherungen liegt der Wert bei bis zu 24 Stunden, eine Point in Time Recovery aus einem lückenlosen Protokollarchiv senkt ihn auf wenige Minuten. Ob er erreicht wird, zeigt erst ein Test.
Für eine Warenwirtschaft mit laufenden Bestellungen ist ein Recovery Point Objective von 24 Stunden selten tragbar, für ein Archiv mit wenigen Änderungen im Monat oft schon. Laut einer forsa-Umfrage im Auftrag des GDV hat allerdings fast jedes zweite kleine und mittlere Unternehmen (48 Prozent) gar keinen Notfallplan, in dem ein solcher Wert stehen könnte.
Einen Zeitpunkt zurückspielen, nicht nur das Backup
Ein Restore Test der letzten Vollsicherung beweist nur, dass die Basis funktioniert. Eine Point in Time Recovery wird an einem Zeitpunkt zwischen zwei Basissicherungen geprüft, weil erst dort das Protokollarchiv beteiligt ist. Der BSI-Baustein CON.3 verlangt, regelmäßig zu testen, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können. In das Testprotokoll gehören deshalb:
- gewählter Zielzeitpunkt und tatsächlich erreichter Stand
- ältester noch erreichbarer Zeitpunkt
- Dauer bis zur lauffähigen Anwendung
- Zahl der nachgespielten Protokolldateien
- Lücken oder Fehler im Archiv
Die gemessene Dauer wird mit dem Recovery Time Objective verglichen, der erreichte Stand mit dem Recovery Point Objective. Liegt einer der Werte daneben, stimmt entweder der Takt der Basissicherungen nicht oder die Zusage.
Was das Protokollarchiv kostet
Die Kosten wachsen mit der Änderungsrate, nicht mit der Größe der Datenbank, denn eine Warenwirtschaft mit vielen Buchungen erzeugt täglich mehr Protokoll als ein großes, kaum verändertes Archiv. Bei der Point in Time Recovery mit PostgreSQL verwalten Werkzeuge wie pgBackRest Basissicherungen und das PostgreSQL WAL gemeinsam. Ein längeres Aufbewahrungsfenster kostet vor allem Speicher, kaum Rechenleistung.
Liegt der Betrieb bei einem Dienstleister, gehören Aufbewahrungsfenster, Recovery Point Objective und Testturnus in den Vertrag über Softwarebetrieb und Wartung. Eine mündliche Zusage hilft im Ernstfall nicht. Ebenso wenig hilft ein Wert, der nie getestet wurde. Beim Relaunch eines Datenbanksystems für ein Bildungsinstitut sichern automatisierte Backups und ein Monitoring den laufenden Betrieb auf MySQL.
