AWS RDS Point-in-Time Recovery (PITR): Der vollständige Entwickler-Leitfaden

Aug. 11, 2026

—

Ein entwicklerfreundlicher Leitfaden zu dem AWS-RDS-Feature, der dich eines Tages retten wird

Kurzfassung: AWS RDS Point-in-Time Recovery ermöglicht es, eine Datenbank auf jede beliebige Sekunde in der Vergangenheit wiederherzustellen – durch Replay des Write-Ahead-Logs auf Basis täglicher Snapshots. Der Standard-Aufbewahrungszeitraum für Backups beträgt nur 1 Tag – deshalb sofort auf mindestens 7 Tage erhöhen. Es gibt eine 5-Minuten-Lücke bei der Wiederherstellbarkeit. Dieser Leitfaden erklärt, wie PITR funktioniert, wie man es unter Druck einsetzt, und welche der drei Wiederherstellungsstrategien je nach Schadensausmaß die richtige ist.

Es ist ein vollkommen normaler Dienstag. Der Kaffee ist heiß, das Stand-up war kurz, PRs werden gemergt. Das Leben ist gut.

Und dann vibriert das Slack-Handy.

🚨 [KRITISCH] Produktionsfehlerrate: 847 % über Baseline

Jemand im Team hat eine Query auf der Produktionsdatenbank ohne WHERE-Klausel auf einer Tabelle mit 80.000 Zeilen ausgeführt.

Der Slack-Thread erreicht in drei Minuten vierzig Nachrichten. Das Monitoring-Dashboard sieht aus wie ein Weihnachtsbaum. Die Hälfte des Engineering-Teams tippt wie verrückt. Die andere Hälfte ist sehr, sehr still.

Und irgendwo im Hinterkopf wird eine einzige Frage immer lauter:

Haben wir Backups?

Wer Point-in-Time Recovery richtig eingerichtet hat, kann jetzt „Alles gut“ sagen – während alle anderen noch herausfinden, wie schlimm es ist.

Wer das nicht hat, sollte sich den Abend freihalten.

Das ist der vollständige Leitfaden zu AWS RDS PITR: was es ist, wie es unter der Haube funktioniert, die tückische 5-Minuten-Falle, die jeden beim ersten Mal erwischt, und wie man es einsetzt, wenn es darauf ankommt.

Was ist AWS RDS Point-in-Time Recovery?

AWS RDS Point-in-Time Recovery (PITR) ermöglicht es, eine RDS-Datenbank auf jeden beliebigen Moment in der Vergangenheit, sekundengenau, wiederherzustellen – nicht nur den Snapshot vom Vorabend, sondern den exakten Moment eine Sekunde bevor eine destruktive Query die Tabelle traf.

Man kann es sich wie einen DVR für die Datenbank vorstellen. Traditionelle Backups sind wie einmal täglich ein Foto der Wohnung zu machen: Wenn um 23:58 Uhr etwas kaputt geht, hat man das Mitternachtsfoto – und das war’s. Alles dazwischen ist weg. PITR ist eine Daueraufnahme. Jeder Moment ist vorhanden. Man wählt das gewünschte Frame aus.

PITR ist ein natives AWS-RDS-Feature. Kein Drittanbieter-Tool, nichts, das selbst gebaut werden muss, und nichts, wofür über die Speicherkosten hinaus extra gezahlt wird. Es kommt mit RDS. Es muss nur korrekt eingerichtet werden – was, wie wir noch sehen werden, die meisten Teams nicht tun.

Wie AWS RDS PITR funktioniert: Das Write-Ahead-Log erklärt

Um zu verstehen, warum PITR so präzise ist, muss man wissen, was unter der Haube passiert.

Jede Änderung an der Datenbank wird zuerst in das Write-Ahead-Log (WAL) geschrieben. Bevor PostgreSQL eine Datendatei aktualisiert, schreibt es einen Eintrag: „Transaktion 1042 hat Zeile X um 14:38:47 in Tabelle orders eingefügt.“ Das WAL ist ein sequenzielles, nur anhängbares Journal von buchstäblich allem, was jemals mit den Daten passiert ist.

Auf RDS nutzt AWS das in drei Schritten:

Vollständiger täglicher Snapshot. RDS macht einmal täglich während eines konfigurierten Backup-Fensters einen automatisierten Snapshot der gesamten Datenbank.
Kontinuierliche WAL-Erfassung. Transaktionslogs werden im Hintergrund zu AWS S3 übertragen und erfassen jede Änderung zwischen den täglichen Snapshots.
WAL-Replay beim Wiederherstellen. Bei einer PITR-Wiederherstellung nimmt AWS den nächstgelegenen vollständigen Snapshot als Basis und spielt das WAL vorwärts bis zur gewünschten Sekunde ab.

Wenn der letzte Snapshot um 3:00 Uhr morgens war und um 14:47 Uhr etwas schiefging, muss man nicht zwischen gestern Nacht und jetzt wählen. PITR startet vom 3-Uhr-Snapshot und spielt elf Stunden und siebenundvierzig Minuten protokollierter Operationen darauf ab. Die Daten landen genau dort, wo man es angegeben hat.

3:00 Uhr 11:00 Uhr 14:47 Uhr JETZT

| | | |

[Snapshot] —[WAL replay]—–[Oops!]———–[Du]

Wiederherstellen HIER: 14:46:59 Uhr

Gerettet: alles vor dem Desaster

Fehlend: ~1 Min. Arbeit zum Abgleich

Die Lücke zwischen dem Schadensereignis und dem letzten Backup schrumpft von potenziell Stunden auf ein bis zwei Minuten.

Wo man die RDS-Point-in-Time-Wiederherstellung in der AWS-Konsole findet

PITR ist nicht in einem obskuren Einstellungsbereich versteckt. Es befindet sich direkt in der RDS-Konsole, einen Klick entfernt.

Zu RDS navigieren, die Datenbank auswählen und oben rechts auf Aktionen klicken. Dort steht „Zu einem bestimmten Zeitpunkt wiederherstellen“ – das ist die Schaltfläche, die eines Abends den Abend retten wird.

Ein Klick darauf führt zum Wiederherstellungsbildschirm, auf dem zwischen der Wiederherstellung bis zum letzten verfügbaren Zeitpunkt und der Eingabe eines benutzerdefinierten Zeitstempels gewählt werden kann. Die Letzte wiederherstellbare Zeit wird sofort angezeigt – was uns zum nächsten Abschnitt bringt.

Die 5-Minuten-Lücke bei AWS RDS PITR: Bedeutung und Relevanz

Hier ist die Falle. Die Sache, die Entwickler während eines ohnehin stressigen Vorfalls verdutzt auf den Bildschirm starren lässt.

RDS lädt Transaktionslogs alle 5 Minuten zu S3 hoch, nicht kontinuierlich.

Das bedeutet, dass die letzte wiederherstellbare Zeit immer etwa 5 Minuten hinter dem aktuellen Moment liegt. AWS zeigt genau an, bis zu welchem Zeitpunkt wiederhergestellt werden kann – kein Rätselraten. Wenn das Schadensereignis aber buchstäblich wenige Minuten vor dem Öffnen der Konsole stattfand, warten die neuesten WAL-Einträge noch auf dem RDS-Server auf ihren nächsten Upload-Zyklus. Sie sind noch nicht in S3 und nicht erreichbar.

Bei Aurora ist die Lücke typischerweise kleiner. Bei Standard-RDS-PostgreSQL ist das 5-Minuten-Fenster real, offiziell und direkt auf dem Wiederherstellungsbildschirm sichtbar. Die praktische Regel: Immer zuerst die Letzte wiederherstellbare Zeit prüfen, bevor der Wiederherstellungszeitstempel eingegeben wird.

# Per CLI prüfen
aws rds describe-db-instances \
  --db-instance-identifier datenbankname \
  --query 'DBInstances[0].LatestRestorableTime'

Bei den meisten Vorfällen spielt das keine Rolle – man stellt auf vor einer Stunde wieder her, nicht auf vor fünf Minuten. Aber die Lücke sollte bekannt sein.

AWS RDS PITR richtig einrichten (bevor das Feuer ausbricht)

PITR aktiviert sich automatisch, wenn automatisierte Backups aktiviert sind. Aber es gibt ein paar Einstellungen, die die meisten Teams bei den Standardwerten belassen und später bereuen.

1. Backup-Aufbewahrungszeitraum: Die schlechteste AWS-Standardeinstellung ändern

Standardmäßig hält RDS automatisierte Backups 1 Tag vor. Einen. Einzigen. Tag.

Was das in der Praxis bedeutet: Wenn ein Problem auftritt und es 36 Stunden lang unbemerkt bleibt – stille Datenbeschädigung, eine fehlerhafte Migration, die erst beim Monatsabschluss auffällt, oder ein langes Wochenende – ist man bereits außerhalb des Wiederherstellungsfensters. PITR kann dann nicht mehr helfen. Die Logs sind weg.

Für die meisten Produktionsdatenbanken empfiehlt sich ein Minimum von 7 Tagen. Für alles, was echte Kundendaten berührt oder Compliance-Anforderungen hat (DSGVO, SOC 2, etc.), auf 30 oder sogar 35 Tage erhöhen – das ist das von AWS erlaubte Maximum.

aws rds modify-db-instance \
  --db-instance-identifier datenbankname \
  --backup-retention-period 7 \
  --apply-immediately

Der Speicherkostenunterschied zwischen 1 und 7 Tagen Aufbewahrung beträgt typischerweise ein paar Euro pro Monat. Das ist keine Budgetentscheidung. Es ist eine „Wie viel sind die Produktionsdaten wert?“-Entscheidung.

2. Backup-Fenster

Ein Fenster wählen, das sich nicht mit dem Spitzenverkehr überschneidet. Der tägliche Snapshot verursacht bei manchen Instanztypen eine kurze I/O-Belastung. Irgendwo zwischen 1:00 und 4:00 Uhr in der primären Zeitzone ist für die meisten Teams sicher.

3. Einen Test-Restore durchführen (Ernst gemeint)

Das ist der Punkt, den Teams immer überspringen und immer bereuen.

PITR sitzt im Hintergrund und vermittelt ein beruhigendes Gefühl. Entwickler richten es ein, fühlen sich gut dabei und versuchen es nie wirklich, bis ein echter Vorfall eintritt. Dann entdecken sie an einem Mittwochnachmittag, während die halbe Firma Slack beobachtet, etwas Unerwartetes über den Prozess, das sie nicht wussten.

Einen Test-Restore auf eine temporäre Instanz einmal pro Quartal durchführen. Das dauert 20 Minuten und lehrt mehr über die tatsächlichen Wiederherstellungsfähigkeiten als jegliches Dokumentationslesen.

Wie man eine AWS-RDS-Point-in-Time-Wiederherstellung durchführt: Schritt für Schritt

Wenn der Vorfall eintritt, gilt als oberstes Gebot: Nicht hetzen. Der Wiederherstellungsprozess erstellt eine neue RDS-Instanz. Er berührt die vorhandene Produktionsdatenbank nicht. Das Starten einer Wiederherstellung kann die Lage nicht verschlechtern.

Schritt 1: Den genauen Zeitstempel ermitteln

Vor dem Öffnen der Konsole den genauen Zeitpunkt feststellen, zu dem die Daten zuletzt sauber waren. Das ist der wichtigste Schritt und es lohnt sich, dafür zehn Minuten zu investieren.

Prüfen:

CloudWatch, New Relic oder Datadog für den genauen Moment, in dem die Metriken anstiegen
Anwendungs-Fehlerlogs für die ersten Fehler, die auf fehlende oder falsche Daten hinweisen
Alert-Zeitstempel in Slack oder PagerDuty
Performance Insights: Ein plötzlicher Sprung bei FreeStorageSpace ist ein präziser, objektiver Zeitstempel dafür, wann Daten entfernt wurden

Schritt 2: Wiederherstellung auf eine neue Instanz starten

Zu RDS → Aktionen → Zu einem bestimmten Zeitpunkt wiederherstellen navigieren. „Benutzerdefiniertes Datum und Uhrzeit“ auswählen, einen Zeitstempel etwa ein bis zwei Minuten vor dem Vorfall eingeben und der neuen Instanz einen klaren Namen geben, z.B. prod-db-pitr-recovery-20260623.

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier produktions-db \
  --target-db-instance-identifier prod-pitr-recovery-20260623 \
  --restore-time "2026-06-23T11:08:59Z" \
  --db-instance-class db.t3.medium \
  --no-multi-az

Das Flag –no-multi-az macht die Recovery-Instanz günstiger, da sie temporär ist. Einen eindeutigen Namen mit Datum vergeben, damit niemand sie versehentlich als echte Produktionsinstanz behandelt.

Schritt 3: Warten (15–40 Minuten), dann validieren

Während die Wiederherstellung läuft, wird die Ursache untersucht. Wenn sie abgeschlossen ist, zur neuen Instanz verbinden und prüfen, ob die Daten korrekt aussehen, bevor irgendetwas anderes getan wird.

Drei Wiederherstellungsstrategien je nach Schadensausmaß

Eine saubere Kopie der Datenbank liegt vor. Was nun? Die Antwort hängt vom Ausmaß des Schadens ab.

Nur wenige Tabellen betroffen: Der chirurgische Ansatz

Das ist der beste Fall. Statt die gesamte Produktionsdatenbank zu tauschen (was Ausfallzeit bedeutet und alle legitimen Schreibvorgänge im gleichen Zeitfenster verliert), nur die beschädigten Tabellen aus der wiederhergestellten Instanz extrahieren und in die Live-Produktion importieren.

# Nur die betroffenen Tabellen aus der PITR-Instanz exportieren
pg_dump \
  -h pitr-recovery-instanz.rds.amazonaws.com \
  -U benutzer \
  -d datenbank \
  -t orders \
  -t order_items \
  --data-only \
  -f recovered_tables.sql

# In Live-Produktion innerhalb einer Transaktion importieren
psql \
  -h produktions-instanz.rds.amazonaws.com \
  -U benutzer \
  -d datenbank \
  -c "BEGIN; TRUNCATE TABLE orders, order_items;"

psql \
  -h produktions-instanz.rds.amazonaws.com \
  -U benutzer \
  -d datenbank \
  -f recovered_tables.sql

# Zeilenzahlen prüfen, dann COMMIT - oder ROLLBACK wenn etwas nicht stimmt

Dieser Ansatz hält die Produktion durchgehend am Laufen. Nur die beschädigten Tabellen werden wiederhergestellt. Alles andere bleibt unberührt.

Weitreichender Schaden über viele Tabellen: Der vollständige DNS-Tausch

Wenn der Schaden weitreichend ist und nicht zuverlässig festgestellt werden kann, welche Tabellen sauber sind, ist der Tausch der gesamten Datenbank sicherer als das chirurgische Patchen eines Systems, dem man nicht vollständig vertraut.

Der am wenigsten störende Weg ist ein DNS-CNAME-Tausch. Die meisten Teams zeigen ihre Anwendung auf einen CNAME-Eintrag anstatt direkt auf den RDS-Endpunkt. Den CNAME auf die wiederhergestellte Instanz aktualisieren – und die Anwendung spricht bereits mit sauberen Daten, ohne ein einziges Code-Deployment.

Nach dem Tausch die Anwendungslogs und Event-Streams nutzen, um legitime Schreibvorgänge zwischen dem Wiederherstellungspunkt und dem Tausch zu identifizieren und manuell nachzuspielen.

Eine fehlerhafte Migration hat das Schema verändert: Der Referenzansatz

Wenn eine Migration Spalten verändert oder gelöscht hat, anstatt nur Zeilen zu löschen, kann man nicht einfach Daten zurückimportieren – die Schemas stimmen nicht überein.

In diesem Fall wird die PITR-Instanz zur Referenzumgebung, nicht zur Datenquelle. Sie nutzen, um zu verstehen, wie das Schema vor der Migration aussah. Danach korrigierende SQL schreiben, um die strukturellen Änderungen rückgängig zu machen, in die Produktion einzuspielen und dann die Daten zu übertragen, sobald die Struktur wieder übereinstimmt.

Die Fehler, die eine Wiederherstellung ruinieren

Aufbewahrungszeitraum noch auf 1 Tag. Der häufigste und kostspieligste Fehler. Vor dem Schließen dieses Tabs ändern.
Nie einen Test-Restore durchgeführt. Das erste Mal PITR unter echtem Druck zu nutzen ist der denkbar schlechteste Zeitpunkt, um Unerwartetes zu entdecken.
Die letzte wiederherstellbare Zeit nicht zuerst geprüft. Die Konsole zeigt das deutlich an. Die 5-Minuten-Lücke ist bei sehr aktuellen Vorfällen relevant.
Den Abgleichsschritt überspringen. Die Wiederherstellung auf vor dem Vorfall stellt nicht automatisch legitime Arbeit wieder her, die im gleichen Zeitfenster stattfand.
Eine wiederhergestellte Instanz in Produktion befördern, ohne sie zuerst zu validieren. Zehn Minuten nehmen. Niemals blind.

Häufig gestellte Fragen zu AWS RDS PITR

Was ist AWS RDS Point-in-Time Recovery (PITR)? AWS RDS Point-in-Time Recovery ist ein natives RDS-Feature, das die Wiederherstellung einer Datenbank auf jede beliebige Sekunde in der Vergangenheit innerhalb des konfigurierten Aufbewahrungszeitraums ermöglicht. Es funktioniert durch die Kombination automatisierter täglicher Snapshots mit kontinuierlicher Write-Ahead-Log-Erfassung (WAL) in S3. Bei einer Wiederherstellung spielt AWS das WAL vom nächsten Snapshot bis zum gewünschten Zeitstempel vor.

Wie weit zurück kann mit AWS RDS PITR wiederhergestellt werden? Innerhalb des konfigurierten Backup-Aufbewahrungszeitraums – zwischen 1 und 35 Tagen. Der Standard beträgt 1 Tag, was für jede Produktionsdatenbank auf mindestens 7 Tage erhöht werden sollte. Das Maximum sind 35 Tage.

Was ist die 5-Minuten-Lücke bei AWS RDS PITR? RDS lädt Transaktionslogs (WAL) alle 5 Minuten zu S3 hoch, nicht kontinuierlich. Das bedeutet, dass die in der Konsole angezeigte Letzte wiederherstellbare Zeit immer etwa 5 Minuten hinter dem aktuellen Moment liegt. Wenn ein destruktives Ereignis weniger als 5 Minuten vor dem Öffnen der Konsole stattfindet, befinden sich diese neuesten WAL-Einträge möglicherweise noch nicht in S3. Bei Aurora ist die Lücke typischerweise kleiner.

Beeinflusst ein PITR-Restore die vorhandene Produktionsdatenbank? Nein. PITR erstellt immer eine brandneue RDS-Instanz. Die vorhandene Produktionsdatenbank wird nicht berührt, überschrieben oder verändert. Eine Wiederherstellung kann die Lage nicht verschlechtern.

Wie lange dauert eine AWS-RDS-Point-in-Time-Wiederherstellung? Typischerweise 15 bis 40 Minuten, abhängig von der Datenbankgröße und wie weit das WAL abgespielt werden muss. Größere Datenbanken mit längeren Zeitspannen zwischen Snapshot und Wiederherstellungspunkt dauern länger.

Auf wie viele Tage sollte der RDS-Backup-Aufbewahrungszeitraum gesetzt werden? Mindestens 7 Tage für jede Produktionsdatenbank. Für Datenbanken mit Kundendaten oder Compliance-Anforderungen (DSGVO, SOC 2, etc.) auf 30 oder 35 Tage setzen. Der Standard von 1 Tag ist für nahezu jeden echten Produktionseinsatz unzureichend.

Kostet AWS PITR extra? PITR selbst kostet nichts extra über die Speicherkosten für die automatisierten Snapshots und Transaktionslog-Backups in S3 hinaus. Die Erhöhung des Aufbewahrungszeitraums von 1 auf 7 Tage fügt typischerweise ein paar Euro pro Monat pro Datenbank hinzu.

Schnellreferenz

Lesezeichen setzen. Wird bei Bedarf gesucht, wenn die Hände leicht zittern.

# 1. Aktuellen Aufbewahrungszeitraum prüfen (sollte 7+ sein)
aws rds describe-db-instances \
  --db-instance-identifier DATENBANK \
  --query 'DBInstances[0].BackupRetentionPeriod'

# 2. Aufbewahrungszeitraum auf 7 Tage setzen
aws rds modify-db-instance \
  --db-instance-identifier DATENBANK \
  --backup-retention-period 7 \
  --apply-immediately

# 3. Letzte wiederherstellbare Zeit prüfen
aws rds describe-db-instances \
  --db-instance-identifier DATENBANK \
  --query 'DBInstances[0].LatestRestorableTime'

# 4. Wiederherstellung auf einen bestimmten Zeitstempel starten
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier DATENBANK \
  --target-db-instance-identifier DATENBANK-pitr-recovery \
  --restore-time "2026-06-23T11:08:59Z" \
  --no-multi-az

# 5. Oder auf den letzten verfügbaren sicheren Zeitpunkt wiederherstellen
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier DATENBANK \
  --target-db-instance-identifier DATENBANK-pitr-recovery \
  --use-latest-restorable-time \
  --no-multi-az

# 6. Betroffene Tabellen aus der Recovery-Instanz exportieren
pg_dump \
  -h PITR_INSTANZ_ENDPUNKT \
  -U benutzer \
  -d datenbank \
  -t betroffene_tabelle \
  --data-only \
  -f recovered_tables.sql

# 7. Wiederhergestellte Daten in Produktion importieren
psql \
  -h PRODUKTIONS_ENDPUNKT \
  -U benutzer \
  -d datenbank \
  -f recovered_tables.sql

Die eigentliche Lektion

PITR kostet fast nichts, es richtig einzurichten. Ein längerer Aufbewahrungszeitraum fügt ein paar Euro pro Monat hinzu. Ein Test-Restore dauert zwanzig Minuten. Den Ablauf aufzuschreiben weitere zehn.

Es nicht zu haben, wenn man es braucht, kostet Daten und Vertrauen.

Die Entwickler, die bei einem Datenbankvorfall ruhig bleiben, sind nicht immer die Erfahrensten im Raum. Es sind die, die an einem beliebigen Dienstag vor sechs Monaten still paranoid waren – die dachten „Was, wenn das schiefgeht?“ und zwanzig Minuten aufgewendet haben, um etwas dagegen zu tun.

PITR ist der Feuerlöscher an der Bürowand. Er wird an einem normalen Tag angebracht, damit man beim Brand nicht herumsteht und überlegt, wo man einen findet.

Automatisierte Backups auf jeder Produktionsdatenbank aktivieren. Aufbewahrungszeitraum auf mindestens 7 Tage setzen. Einen Test-Restore durchführen. Den Ablauf kennen.

Und wenn diese Slack-Benachrichtigung an einem Dienstagnachmittag kommt, ist man die Person, die bereits die Wiederherstellung gestartet hat, während alle anderen noch die Fehlermeldung lesen.

Wer diesen Leitfaden nützlich fand: Teilen mit der Person, die zuletzt die RDS-Backup-Einstellungen angefasst hat. Sie muss ihn auch lesen.