{"id":348,"date":"2026-08-11T17:10:58","date_gmt":"2026-08-11T17:10:58","guid":{"rendered":"https:\/\/www.goteams.de\/blog\/?p=348"},"modified":"2026-08-11T17:11:01","modified_gmt":"2026-08-11T17:11:01","slug":"aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden","status":"publish","type":"post","link":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/","title":{"rendered":"AWS RDS Point-in-Time Recovery (PITR): Der vollst\u00e4ndige Entwickler-Leitfaden"},"content":{"rendered":"\n

Ein entwicklerfreundlicher Leitfaden zu dem AWS-RDS-Feature, der dich eines Tages retten wird<\/strong><\/p>\n\n\n\n

Kurzfassung:<\/strong> AWS RDS Point-in-Time Recovery erm\u00f6glicht es, eine Datenbank auf jede beliebige Sekunde in der Vergangenheit wiederherzustellen – durch Replay des Write-Ahead-Logs auf Basis t\u00e4glicher Snapshots. Der Standard-Aufbewahrungszeitraum f\u00fcr Backups betr\u00e4gt nur 1 Tag – deshalb sofort auf mindestens 7 Tage erh\u00f6hen. Es gibt eine 5-Minuten-L\u00fccke bei der Wiederherstellbarkeit. Dieser Leitfaden erkl\u00e4rt, wie PITR funktioniert, wie man es unter Druck einsetzt, und welche der drei Wiederherstellungsstrategien je nach Schadensausma\u00df die richtige ist.<\/p>\n\n\n\n

Es ist ein vollkommen normaler Dienstag. Der Kaffee ist hei\u00df, das Stand-up war kurz, PRs werden gemergt. Das Leben ist gut.<\/p>\n\n\n\n

Und dann vibriert das Slack-Handy.<\/p>\n\n\n\n

\ud83d\udea8 [KRITISCH] Produktionsfehlerrate: 847 % \u00fcber Baseline<\/strong><\/p>\n\n\n\n

Jemand im Team hat eine Query auf der Produktionsdatenbank ohne WHERE-Klausel auf einer Tabelle mit 80.000 Zeilen ausgef\u00fchrt.<\/p>\n\n\n\n

Der Slack-Thread erreicht in drei Minuten vierzig Nachrichten. Das Monitoring-Dashboard sieht aus wie ein Weihnachtsbaum. Die H\u00e4lfte des Engineering-Teams tippt wie verr\u00fcckt. Die andere H\u00e4lfte ist sehr, sehr still.<\/p>\n\n\n\n

Und irgendwo im Hinterkopf wird eine einzige Frage immer lauter:<\/p>\n\n\n\n

Haben wir Backups?<\/em><\/p>\n\n\n\n

Wer Point-in-Time Recovery richtig eingerichtet hat, kann jetzt “Alles gut” sagen – w\u00e4hrend alle anderen noch herausfinden, wie schlimm es ist.<\/p>\n\n\n\n

Wer das nicht hat, sollte sich den Abend freihalten.<\/p>\n\n\n\n

Das ist der vollst\u00e4ndige Leitfaden zu AWS RDS PITR: was es ist, wie es unter der Haube funktioniert, die t\u00fcckische 5-Minuten-Falle, die jeden beim ersten Mal erwischt, und wie man es einsetzt, wenn es darauf ankommt.<\/p>\n\n\n\n

Was ist AWS RDS Point-in-Time Recovery?<\/h2>\n\n\n\n

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

Man kann es sich wie einen DVR f\u00fcr die Datenbank vorstellen. Traditionelle Backups sind wie einmal t\u00e4glich 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\u00e4hlt das gew\u00fcnschte Frame aus.<\/p>\n\n\n\n

PITR ist ein natives AWS-RDS-Feature. Kein Drittanbieter-Tool, nichts, das selbst gebaut werden muss, und nichts, wof\u00fcr \u00fcber 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.<\/p>\n\n\n\n

Wie AWS RDS PITR funktioniert: Das Write-Ahead-Log erkl\u00e4rt<\/h2>\n\n\n\n

Um zu verstehen, warum PITR so pr\u00e4zise ist, muss man wissen, was unter der Haube passiert.<\/p>\n\n\n\n

Jede \u00c4nderung an der Datenbank wird zuerst in das Write-Ahead-Log (WAL)<\/strong> geschrieben. Bevor PostgreSQL eine Datendatei aktualisiert, schreibt es einen Eintrag: “Transaktion 1042 hat Zeile X um 14:38:47 in Tabelle orders eingef\u00fcgt.” Das WAL ist ein sequenzielles, nur anh\u00e4ngbares Journal von buchst\u00e4blich allem, was jemals mit den Daten passiert ist.<\/p>\n\n\n\n

Auf RDS nutzt AWS das in drei Schritten:<\/p>\n\n\n\n

    \n
  1. Vollst\u00e4ndiger t\u00e4glicher Snapshot.<\/strong> RDS macht einmal t\u00e4glich w\u00e4hrend eines konfigurierten Backup-Fensters einen automatisierten Snapshot der gesamten Datenbank.<\/li>\n\n\n\n
  2. Kontinuierliche WAL-Erfassung.<\/strong> Transaktionslogs werden im Hintergrund zu AWS S3 \u00fcbertragen und erfassen jede \u00c4nderung zwischen den t\u00e4glichen Snapshots.<\/li>\n\n\n\n
  3. WAL-Replay beim Wiederherstellen.<\/strong> Bei einer PITR-Wiederherstellung nimmt AWS den n\u00e4chstgelegenen vollst\u00e4ndigen Snapshot als Basis und spielt das WAL vorw\u00e4rts bis zur gew\u00fcnschten Sekunde ab.<\/li>\n<\/ol>\n\n\n\n

    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\u00e4hlen. 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.<\/p>\n\n\n\n

    3:00 Uhr        11:00 Uhr       14:47 Uhr       JETZT<\/p>\n\n\n\n

       |                |               |             |<\/p>\n\n\n\n

    [Snapshot] —[WAL replay]—–[Oops!]———–[Du]<\/p>\n\n\n\n

                                        ^<\/p>\n\n\n\n

                         Wiederherstellen HIER: 14:46:59 Uhr<\/p>\n\n\n\n

                         Gerettet: alles vor dem Desaster<\/p>\n\n\n\n

                         Fehlend: ~1 Min. Arbeit zum Abgleich<\/p>\n\n\n\n

    Die L\u00fccke zwischen dem Schadensereignis und dem letzten Backup schrumpft von potenziell Stunden auf ein bis zwei Minuten.<\/p>\n\n\n\n

    Wo man die RDS-Point-in-Time-Wiederherstellung in der AWS-Konsole findet<\/h2>\n\n\n\n

    PITR ist nicht in einem obskuren Einstellungsbereich versteckt. Es befindet sich direkt in der RDS-Konsole, einen Klick entfernt.<\/p>\n\n\n\n

    Zu RDS navigieren, die Datenbank ausw\u00e4hlen und oben rechts auf Aktionen<\/strong> klicken. Dort steht “Zu einem bestimmten Zeitpunkt wiederherstellen”<\/strong> – das ist die Schaltfl\u00e4che, die eines Abends den Abend retten wird.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Ein Klick darauf f\u00fchrt zum Wiederherstellungsbildschirm, auf dem zwischen der Wiederherstellung bis zum letzten verf\u00fcgbaren Zeitpunkt und der Eingabe eines benutzerdefinierten Zeitstempels gew\u00e4hlt werden kann. Die Letzte wiederherstellbare Zeit<\/strong> wird sofort angezeigt – was uns zum n\u00e4chsten Abschnitt bringt.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
    \n\n\n\n

    Die 5-Minuten-L\u00fccke bei AWS RDS PITR: Bedeutung und Relevanz<\/h2>\n\n\n\n

    Hier ist die Falle. Die Sache, die Entwickler w\u00e4hrend eines ohnehin stressigen Vorfalls verdutzt auf den Bildschirm starren l\u00e4sst.<\/p>\n\n\n\n

    RDS l\u00e4dt Transaktionslogs alle 5 Minuten zu S3 hoch, nicht kontinuierlich.<\/strong><\/p>\n\n\n\n

    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\u00e4tselraten. Wenn das Schadensereignis aber buchst\u00e4blich wenige Minuten vor dem \u00d6ffnen der Konsole stattfand, warten die neuesten WAL-Eintr\u00e4ge noch auf dem RDS-Server auf ihren n\u00e4chsten Upload-Zyklus. Sie sind noch nicht in S3 und nicht erreichbar.<\/p>\n\n\n\n

    Bei Aurora ist die L\u00fccke 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\u00fcfen, bevor der Wiederherstellungszeitstempel eingegeben wird.<\/strong><\/p>\n\n\n\n

    # Per CLI pr\u00fcfen\naws rds describe-db-instances \\\n  --db-instance-identifier datenbankname \\\n  --query 'DBInstances[0].LatestRestorableTime'<\/code><\/pre>\n\n\n\n
    Bei den meisten Vorf\u00e4llen spielt das keine Rolle – man stellt auf vor einer Stunde wieder her, nicht auf vor f\u00fcnf Minuten. Aber die L\u00fccke sollte bekannt sein.<\/p>\n\n\n\n
    AWS RDS PITR richtig einrichten (bevor das Feuer ausbricht)<\/h2>\n\n\n\n
    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\u00e4ter bereuen.<\/p>\n\n\n\n
    1. Backup-Aufbewahrungszeitraum: Die schlechteste AWS-Standardeinstellung \u00e4ndern<\/h3>\n\n\n\n
    Standardm\u00e4\u00dfig h\u00e4lt RDS automatisierte Backups 1 Tag<\/strong> vor. Einen. Einzigen. Tag.<\/p>\n\n\n\n
    Was das in der Praxis bedeutet: Wenn ein Problem auftritt und es 36 Stunden lang unbemerkt bleibt – stille Datenbesch\u00e4digung, eine fehlerhafte Migration, die erst beim Monatsabschluss auff\u00e4llt, oder ein langes Wochenende – ist man bereits au\u00dferhalb des Wiederherstellungsfensters. PITR kann dann nicht mehr helfen. Die Logs sind weg.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    F\u00fcr die meisten Produktionsdatenbanken empfiehlt sich ein Minimum von 7 Tagen<\/strong>. F\u00fcr alles, was echte Kundendaten ber\u00fchrt oder Compliance-Anforderungen hat (DSGVO, SOC 2, etc.), auf 30 oder sogar 35 Tage erh\u00f6hen – das ist das von AWS erlaubte Maximum.<\/p>\n\n\n\n
    aws rds modify-db-instance \\\n  --db-instance-identifier datenbankname \\\n  --backup-retention-period 7 \\\n  --apply-immediately<\/code><\/pre>\n\n\n\n
    Der Speicherkostenunterschied zwischen 1 und 7 Tagen Aufbewahrung betr\u00e4gt typischerweise ein paar Euro pro Monat. Das ist keine Budgetentscheidung. Es ist eine “Wie viel sind die Produktionsdaten wert?”-Entscheidung.<\/p>\n\n\n\n
    2. Backup-Fenster<\/h3>\n\n\n\n
    Ein Fenster w\u00e4hlen, das sich nicht mit dem Spitzenverkehr \u00fcberschneidet. Der t\u00e4gliche Snapshot verursacht bei manchen Instanztypen eine kurze I\/O-Belastung. Irgendwo zwischen 1:00 und 4:00 Uhr in der prim\u00e4ren Zeitzone ist f\u00fcr die meisten Teams sicher.<\/p>\n\n\n\n
    3. Einen Test-Restore durchf\u00fchren (Ernst gemeint)<\/h3>\n\n\n\n
    Das ist der Punkt, den Teams immer \u00fcberspringen und immer bereuen.<\/p>\n\n\n\n
    PITR sitzt im Hintergrund und vermittelt ein beruhigendes Gef\u00fchl. Entwickler richten es ein, f\u00fchlen sich gut dabei und versuchen es nie wirklich, bis ein echter Vorfall eintritt. Dann entdecken sie an einem Mittwochnachmittag, w\u00e4hrend die halbe Firma Slack beobachtet, etwas Unerwartetes \u00fcber den Prozess, das sie nicht wussten.<\/p>\n\n\n\n
    Einen Test-Restore auf eine tempor\u00e4re Instanz einmal pro Quartal durchf\u00fchren. Das dauert 20 Minuten und lehrt mehr \u00fcber die tats\u00e4chlichen Wiederherstellungsf\u00e4higkeiten als jegliches Dokumentationslesen.<\/p>\n\n\n\n
    Wie man eine AWS-RDS-Point-in-Time-Wiederherstellung durchf\u00fchrt: Schritt f\u00fcr Schritt<\/h2>\n\n\n\n
    Wenn der Vorfall eintritt, gilt als oberstes Gebot: Nicht hetzen.<\/strong> Der Wiederherstellungsprozess erstellt eine neue RDS-Instanz. Er ber\u00fchrt die vorhandene Produktionsdatenbank nicht. Das Starten einer Wiederherstellung kann die Lage nicht verschlechtern.<\/p>\n\n\n\n
    Schritt 1: Den genauen Zeitstempel ermitteln<\/h3>\n\n\n\n
    Vor dem \u00d6ffnen der Konsole den genauen Zeitpunkt feststellen, zu dem die Daten zuletzt sauber waren. Das ist der wichtigste Schritt und es lohnt sich, daf\u00fcr zehn Minuten zu investieren.<\/p>\n\n\n\n
    Pr\u00fcfen:<\/p>\n\n\n\n
      \n
    • CloudWatch, New Relic oder Datadog f\u00fcr den genauen Moment, in dem die Metriken anstiegen<\/li>\n\n\n\n
    • Anwendungs-Fehlerlogs f\u00fcr die ersten Fehler, die auf fehlende oder falsche Daten hinweisen<\/li>\n\n\n\n
    • Alert-Zeitstempel in Slack oder PagerDuty<\/li>\n\n\n\n
    • Performance Insights: Ein pl\u00f6tzlicher Sprung bei FreeStorageSpace ist ein pr\u00e4ziser, objektiver Zeitstempel daf\u00fcr, wann Daten entfernt wurden<\/li>\n<\/ul>\n\n\n\n
      Schritt 2: Wiederherstellung auf eine neue Instanz starten<\/h3>\n\n\n\n
      Zu RDS \u2192 Aktionen \u2192 Zu einem bestimmten Zeitpunkt wiederherstellen<\/strong> navigieren. “Benutzerdefiniertes Datum und Uhrzeit” ausw\u00e4hlen, 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.<\/p>\n\n\n\n
      aws rds restore-db-instance-to-point-in-time \\\n  --source-db-instance-identifier produktions-db \\\n  --target-db-instance-identifier prod-pitr-recovery-20260623 \\\n  --restore-time \"2026-06-23T11:08:59Z\" \\\n  --db-instance-class db.t3.medium \\\n  --no-multi-az<\/code><\/pre>\n\n\n\n
      Das Flag –no-multi-az macht die Recovery-Instanz g\u00fcnstiger, da sie tempor\u00e4r ist. Einen eindeutigen Namen mit Datum vergeben, damit niemand sie versehentlich als echte Produktionsinstanz behandelt.<\/p>\n\n\n\n
      Schritt 3: Warten (15\u201340 Minuten), dann validieren<\/h3>\n\n\n\n
      W\u00e4hrend die Wiederherstellung l\u00e4uft, wird die Ursache untersucht. Wenn sie abgeschlossen ist, zur neuen Instanz verbinden und pr\u00fcfen, ob die Daten korrekt aussehen, bevor irgendetwas anderes getan wird.<\/strong><\/p>\n\n\n\n
      Drei Wiederherstellungsstrategien je nach Schadensausma\u00df<\/h2>\n\n\n\n
      Eine saubere Kopie der Datenbank liegt vor. Was nun? Die Antwort h\u00e4ngt vom Ausma\u00df des Schadens ab.<\/p>\n\n\n\n
      Nur wenige Tabellen betroffen: Der chirurgische Ansatz<\/h3>\n\n\n\n
      Das ist der beste Fall. Statt die gesamte Produktionsdatenbank zu tauschen (was Ausfallzeit bedeutet und alle legitimen Schreibvorg\u00e4nge im gleichen Zeitfenster verliert), nur die besch\u00e4digten Tabellen aus der wiederhergestellten Instanz extrahieren und in die Live-Produktion importieren.<\/p>\n\n\n\n
      # Nur die betroffenen Tabellen aus der PITR-Instanz exportieren\npg_dump \\\n  -h pitr-recovery-instanz.rds.amazonaws.com \\\n  -U benutzer \\\n  -d datenbank \\\n  -t orders \\\n  -t order_items \\\n  --data-only \\\n  -f recovered_tables.sql\n\n# In Live-Produktion innerhalb einer Transaktion importieren\npsql \\\n  -h produktions-instanz.rds.amazonaws.com \\\n  -U benutzer \\\n  -d datenbank \\\n  -c \"BEGIN; TRUNCATE TABLE orders, order_items;\"\n\npsql \\\n  -h produktions-instanz.rds.amazonaws.com \\\n  -U benutzer \\\n  -d datenbank \\\n  -f recovered_tables.sql\n\n# Zeilenzahlen pr\u00fcfen, dann COMMIT - oder ROLLBACK wenn etwas nicht stimmt<\/code><\/pre>\n\n\n\n
      Dieser Ansatz h\u00e4lt die Produktion durchgehend am Laufen. Nur die besch\u00e4digten Tabellen werden wiederhergestellt. Alles andere bleibt unber\u00fchrt.<\/p>\n\n\n\n
      Weitreichender Schaden \u00fcber viele Tabellen: Der vollst\u00e4ndige DNS-Tausch<\/h3>\n\n\n\n
      Wenn der Schaden weitreichend ist und nicht zuverl\u00e4ssig festgestellt werden kann, welche Tabellen sauber sind, ist der Tausch der gesamten Datenbank sicherer als das chirurgische Patchen eines Systems, dem man nicht vollst\u00e4ndig vertraut.<\/p>\n\n\n\n
      Der am wenigsten st\u00f6rende Weg ist ein DNS-CNAME-Tausch<\/strong>. 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.<\/p>\n\n\n\n
      Nach dem Tausch die Anwendungslogs und Event-Streams nutzen, um legitime Schreibvorg\u00e4nge zwischen dem Wiederherstellungspunkt und dem Tausch zu identifizieren und manuell nachzuspielen.<\/p>\n\n\n\n
      Eine fehlerhafte Migration hat das Schema ver\u00e4ndert: Der Referenzansatz<\/h3>\n\n\n\n
      Wenn eine Migration Spalten ver\u00e4ndert oder gel\u00f6scht hat, anstatt nur Zeilen zu l\u00f6schen, kann man nicht einfach Daten zur\u00fcckimportieren – die Schemas stimmen nicht \u00fcberein.<\/p>\n\n\n\n
      In diesem Fall wird die PITR-Instanz zur Referenzumgebung<\/strong>, nicht zur Datenquelle. Sie nutzen, um zu verstehen, wie das Schema vor der Migration aussah. Danach korrigierende SQL schreiben, um die strukturellen \u00c4nderungen r\u00fcckg\u00e4ngig zu machen, in die Produktion einzuspielen und dann die Daten zu \u00fcbertragen, sobald die Struktur wieder \u00fcbereinstimmt.<\/p>\n\n\n\n
      Die Fehler, die eine Wiederherstellung ruinieren<\/h2>\n\n\n\n
        \n
      • Aufbewahrungszeitraum noch auf 1 Tag.<\/strong> Der h\u00e4ufigste und kostspieligste Fehler. Vor dem Schlie\u00dfen dieses Tabs \u00e4ndern.<\/li>\n\n\n\n
      • Nie einen Test-Restore durchgef\u00fchrt.<\/strong> Das erste Mal PITR unter echtem Druck zu nutzen ist der denkbar schlechteste Zeitpunkt, um Unerwartetes zu entdecken.<\/li>\n\n\n\n
      • Die letzte wiederherstellbare Zeit nicht zuerst gepr\u00fcft.<\/strong> Die Konsole zeigt das deutlich an. Die 5-Minuten-L\u00fccke ist bei sehr aktuellen Vorf\u00e4llen relevant.<\/li>\n\n\n\n
      • Den Abgleichsschritt \u00fcberspringen.<\/strong> Die Wiederherstellung auf vor dem Vorfall stellt nicht automatisch legitime Arbeit wieder her, die im gleichen Zeitfenster stattfand.<\/li>\n\n\n\n
      • Eine wiederhergestellte Instanz in Produktion bef\u00f6rdern, ohne sie zuerst zu validieren.<\/strong> Zehn Minuten nehmen. Niemals blind.<\/li>\n<\/ul>\n\n\n\n
        H\u00e4ufig gestellte Fragen zu AWS RDS PITR<\/h2>\n\n\n\n
        Was ist AWS RDS Point-in-Time Recovery (PITR)?<\/strong> 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\u00f6glicht. Es funktioniert durch die Kombination automatisierter t\u00e4glicher Snapshots mit kontinuierlicher Write-Ahead-Log-Erfassung (WAL) in S3. Bei einer Wiederherstellung spielt AWS das WAL vom n\u00e4chsten Snapshot bis zum gew\u00fcnschten Zeitstempel vor.<\/p>\n\n\n\n
        Wie weit zur\u00fcck kann mit AWS RDS PITR wiederhergestellt werden?<\/strong> Innerhalb des konfigurierten Backup-Aufbewahrungszeitraums – zwischen 1 und 35 Tagen. Der Standard betr\u00e4gt 1 Tag, was f\u00fcr jede Produktionsdatenbank auf mindestens 7 Tage erh\u00f6ht werden sollte. Das Maximum sind 35 Tage.<\/p>\n\n\n\n
        Was ist die 5-Minuten-L\u00fccke bei AWS RDS PITR?<\/strong> RDS l\u00e4dt 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 \u00d6ffnen der Konsole stattfindet, befinden sich diese neuesten WAL-Eintr\u00e4ge m\u00f6glicherweise noch nicht in S3. Bei Aurora ist die L\u00fccke typischerweise kleiner.<\/p>\n\n\n\n
        Beeinflusst ein PITR-Restore die vorhandene Produktionsdatenbank?<\/strong> Nein. PITR erstellt immer eine brandneue RDS-Instanz. Die vorhandene Produktionsdatenbank wird nicht ber\u00fchrt, \u00fcberschrieben oder ver\u00e4ndert. Eine Wiederherstellung kann die Lage nicht verschlechtern.<\/p>\n\n\n\n
        Wie lange dauert eine AWS-RDS-Point-in-Time-Wiederherstellung?<\/strong> Typischerweise 15 bis 40 Minuten, abh\u00e4ngig von der Datenbankgr\u00f6\u00dfe und wie weit das WAL abgespielt werden muss. Gr\u00f6\u00dfere Datenbanken mit l\u00e4ngeren Zeitspannen zwischen Snapshot und Wiederherstellungspunkt dauern l\u00e4nger.<\/p>\n\n\n\n
        Auf wie viele Tage sollte der RDS-Backup-Aufbewahrungszeitraum gesetzt werden?<\/strong> Mindestens 7 Tage f\u00fcr jede Produktionsdatenbank. F\u00fcr Datenbanken mit Kundendaten oder Compliance-Anforderungen (DSGVO, SOC 2, etc.) auf 30 oder 35 Tage setzen. Der Standard von 1 Tag ist f\u00fcr nahezu jeden echten Produktionseinsatz unzureichend.<\/p>\n\n\n\n
        Kostet AWS PITR extra?<\/strong> PITR selbst kostet nichts extra \u00fcber die Speicherkosten f\u00fcr die automatisierten Snapshots und Transaktionslog-Backups in S3 hinaus. Die Erh\u00f6hung des Aufbewahrungszeitraums von 1 auf 7 Tage f\u00fcgt typischerweise ein paar Euro pro Monat pro Datenbank hinzu.<\/p>\n\n\n\n
        Schnellreferenz<\/h2>\n\n\n\n
        Lesezeichen setzen. Wird bei Bedarf gesucht, wenn die H\u00e4nde leicht zittern.<\/p>\n\n\n\n
        # 1. Aktuellen Aufbewahrungszeitraum pr\u00fcfen (sollte 7+ sein)\naws rds describe-db-instances \\\n  --db-instance-identifier DATENBANK \\\n  --query 'DBInstances[0].BackupRetentionPeriod'\n\n# 2. Aufbewahrungszeitraum auf 7 Tage setzen\naws rds modify-db-instance \\\n  --db-instance-identifier DATENBANK \\\n  --backup-retention-period 7 \\\n  --apply-immediately\n\n# 3. Letzte wiederherstellbare Zeit pr\u00fcfen\naws rds describe-db-instances \\\n  --db-instance-identifier DATENBANK \\\n  --query 'DBInstances[0].LatestRestorableTime'\n\n# 4. Wiederherstellung auf einen bestimmten Zeitstempel starten\naws rds restore-db-instance-to-point-in-time \\\n  --source-db-instance-identifier DATENBANK \\\n  --target-db-instance-identifier DATENBANK-pitr-recovery \\\n  --restore-time \"2026-06-23T11:08:59Z\" \\\n  --no-multi-az\n\n# 5. Oder auf den letzten verf\u00fcgbaren sicheren Zeitpunkt wiederherstellen\naws rds restore-db-instance-to-point-in-time \\\n  --source-db-instance-identifier DATENBANK \\\n  --target-db-instance-identifier DATENBANK-pitr-recovery \\\n  --use-latest-restorable-time \\\n  --no-multi-az\n\n# 6. Betroffene Tabellen aus der Recovery-Instanz exportieren\npg_dump \\\n  -h PITR_INSTANZ_ENDPUNKT \\\n  -U benutzer \\\n  -d datenbank \\\n  -t betroffene_tabelle \\\n  --data-only \\\n  -f recovered_tables.sql\n\n# 7. Wiederhergestellte Daten in Produktion importieren\npsql \\\n  -h PRODUKTIONS_ENDPUNKT \\\n  -U benutzer \\\n  -d datenbank \\\n  -f recovered_tables.sql<\/code><\/pre>\n\n\n\n
        Die eigentliche Lektion<\/h2>\n\n\n\n
        PITR kostet fast nichts, es richtig einzurichten. Ein l\u00e4ngerer Aufbewahrungszeitraum f\u00fcgt ein paar Euro pro Monat hinzu. Ein Test-Restore dauert zwanzig Minuten. Den Ablauf aufzuschreiben weitere zehn.<\/p>\n\n\n\n
        Es nicht zu haben, wenn man es braucht, kostet Daten und Vertrauen.<\/p>\n\n\n\n
        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.<\/p>\n\n\n\n
        PITR ist der Feuerl\u00f6scher an der B\u00fcrowand. Er wird an einem normalen Tag angebracht, damit man beim Brand nicht herumsteht und \u00fcberlegt, wo man einen findet.<\/p>\n\n\n\n
        Automatisierte Backups auf jeder Produktionsdatenbank aktivieren. Aufbewahrungszeitraum auf mindestens 7 Tage setzen. Einen Test-Restore durchf\u00fchren. Den Ablauf kennen.<\/p>\n\n\n\n
        Und wenn diese Slack-Benachrichtigung an einem Dienstagnachmittag kommt, ist man die Person, die bereits die Wiederherstellung gestartet hat, w\u00e4hrend alle anderen noch die Fehlermeldung lesen.<\/p>\n\n\n\n
        Wer diesen Leitfaden n\u00fctzlich fand: Teilen mit der Person, die zuletzt die RDS-Backup-Einstellungen angefasst hat. Sie muss ihn auch lesen.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
        Ein entwicklerfreundlicher Leitfaden zu dem AWS-RDS-Feature, der dich eines Tages retten wird Kurzfassung: AWS RDS Point-in-Time Recovery erm\u00f6glicht es, eine Datenbank auf jede beliebige Sekunde in der Vergangenheit wiederherzustellen – durch Replay des Write-Ahead-Logs auf Basis t\u00e4glicher Snapshots. Der Standard-Aufbewahrungszeitraum f\u00fcr Backups betr\u00e4gt nur 1 Tag – deshalb sofort auf mindestens 7 Tage erh\u00f6hen. Es […]<\/p>\n","protected":false},"author":14,"featured_media":343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[22],"tags":[136,129,132,140,130],"class_list":["post-348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering-de","tag-aws-datenbankwiederherstellung","tag-aws-rds-datenbank-wiederherstellen","tag-rds-backup-aufbewahrungszeitraum","tag-rds-pitr-de","tag-wal-replay-datenbankwiederherstellung"],"yoast_head":"\nAWS RDS Point-in-Time Recovery: Der Entwickler-Leitfaden<\/title>\n<meta name=\"description\" content=\"AWS RDS PITR stellt Datenbanken sekundengenau vor dem Desaster wieder her. Wie es funktioniert, die 5-Minuten-Falle und was im Ernstfall zu tun ist.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"AWS RDS Point-in-Time Recovery: Der Entwickler-Leitfaden\" \/>\n<meta property=\"og:description\" content=\"AWS RDS PITR stellt Datenbanken sekundengenau vor dem Desaster wieder her. Wie es funktioniert, die 5-Minuten-Falle und was im Ernstfall zu tun ist.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/\" \/>\n<meta property=\"og:site_name\" content=\"The GoTeams Way\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-11T17:10:58+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-08-11T17:11:01+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/08\/Blogpost-T09-scaled.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"2560\" \/>\n\t<meta property=\"og:image:height\" content=\"1216\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Ashutosh\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Ashutosh\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/\"},\"author\":{\"name\":\"Ashutosh\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#\\\/schema\\\/person\\\/be2177739605974a03ed98d640cc56e1\"},\"headline\":\"AWS RDS Point-in-Time Recovery (PITR): Der vollst\u00e4ndige Entwickler-Leitfaden\",\"datePublished\":\"2026-08-11T17:10:58+00:00\",\"dateModified\":\"2026-08-11T17:11:01+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/\"},\"wordCount\":2542,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/Blogpost-T09-scaled.jpg\",\"keywords\":[\"AWS Datenbankwiederherstellung\",\"AWS RDS Datenbank wiederherstellen\",\"RDS Backup Aufbewahrungszeitraum\",\"RDS PITR\",\"WAL Replay Datenbankwiederherstellung\"],\"articleSection\":[\"Ingenieurwesen\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/\",\"url\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/\",\"name\":\"AWS RDS Point-in-Time Recovery: Der Entwickler-Leitfaden\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/Blogpost-T09-scaled.jpg\",\"datePublished\":\"2026-08-11T17:10:58+00:00\",\"dateModified\":\"2026-08-11T17:11:01+00:00\",\"description\":\"AWS RDS PITR stellt Datenbanken sekundengenau vor dem Desaster wieder her. Wie es funktioniert, die 5-Minuten-Falle und was im Ernstfall zu tun ist.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/Blogpost-T09-scaled.jpg\",\"contentUrl\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/Blogpost-T09-scaled.jpg\",\"width\":2560,\"height\":1216,\"caption\":\"AWS RDS Point-in-Time Recovery\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/de\\\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"AWS RDS Point-in-Time Recovery (PITR): Der vollst\u00e4ndige Entwickler-Leitfaden\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/\",\"name\":\"The GoTeams Way\",\"description\":\"By Entrepreneurs, for Entrepreneurs.\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#organization\",\"name\":\"GoTeams\",\"url\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/Frame.png\",\"contentUrl\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/Frame.png\",\"width\":488,\"height\":80,\"caption\":\"GoTeams\"},\"image\":{\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.linkedin.com\\\/company\\\/go-teams\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/#\\\/schema\\\/person\\\/be2177739605974a03ed98d640cc56e1\",\"name\":\"Ashutosh\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/e7346ff7f947945493b0fbe556649f15bd21842d29a4c848f3b171398a0b4d21?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/e7346ff7f947945493b0fbe556649f15bd21842d29a4c848f3b171398a0b4d21?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/e7346ff7f947945493b0fbe556649f15bd21842d29a4c848f3b171398a0b4d21?s=96&d=mm&r=g\",\"caption\":\"Ashutosh\"},\"sameAs\":[\"https:\\\/\\\/www.goteams.de\"],\"url\":\"https:\\\/\\\/www.goteams.de\\\/blog\\\/author\\\/ashutosh\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"AWS RDS Point-in-Time Recovery: Der Entwickler-Leitfaden","description":"AWS RDS PITR stellt Datenbanken sekundengenau vor dem Desaster wieder her. Wie es funktioniert, die 5-Minuten-Falle und was im Ernstfall zu tun ist.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/","og_locale":"en_US","og_type":"article","og_title":"AWS RDS Point-in-Time Recovery: Der Entwickler-Leitfaden","og_description":"AWS RDS PITR stellt Datenbanken sekundengenau vor dem Desaster wieder her. Wie es funktioniert, die 5-Minuten-Falle und was im Ernstfall zu tun ist.","og_url":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/","og_site_name":"The GoTeams Way","article_published_time":"2026-08-11T17:10:58+00:00","article_modified_time":"2026-08-11T17:11:01+00:00","og_image":[{"width":2560,"height":1216,"url":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/08\/Blogpost-T09-scaled.jpg","type":"image\/jpeg"}],"author":"Ashutosh","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Ashutosh","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#article","isPartOf":{"@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/"},"author":{"name":"Ashutosh","@id":"https:\/\/www.goteams.de\/blog\/#\/schema\/person\/be2177739605974a03ed98d640cc56e1"},"headline":"AWS RDS Point-in-Time Recovery (PITR): Der vollst\u00e4ndige Entwickler-Leitfaden","datePublished":"2026-08-11T17:10:58+00:00","dateModified":"2026-08-11T17:11:01+00:00","mainEntityOfPage":{"@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/"},"wordCount":2542,"commentCount":0,"publisher":{"@id":"https:\/\/www.goteams.de\/blog\/#organization"},"image":{"@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#primaryimage"},"thumbnailUrl":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/08\/Blogpost-T09-scaled.jpg","keywords":["AWS Datenbankwiederherstellung","AWS RDS Datenbank wiederherstellen","RDS Backup Aufbewahrungszeitraum","RDS PITR","WAL Replay Datenbankwiederherstellung"],"articleSection":["Ingenieurwesen"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/","url":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/","name":"AWS RDS Point-in-Time Recovery: Der Entwickler-Leitfaden","isPartOf":{"@id":"https:\/\/www.goteams.de\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#primaryimage"},"image":{"@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#primaryimage"},"thumbnailUrl":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/08\/Blogpost-T09-scaled.jpg","datePublished":"2026-08-11T17:10:58+00:00","dateModified":"2026-08-11T17:11:01+00:00","description":"AWS RDS PITR stellt Datenbanken sekundengenau vor dem Desaster wieder her. Wie es funktioniert, die 5-Minuten-Falle und was im Ernstfall zu tun ist.","breadcrumb":{"@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#primaryimage","url":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/08\/Blogpost-T09-scaled.jpg","contentUrl":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/08\/Blogpost-T09-scaled.jpg","width":2560,"height":1216,"caption":"AWS RDS Point-in-Time Recovery"},{"@type":"BreadcrumbList","@id":"https:\/\/www.goteams.de\/blog\/de\/aws-rds-point-in-time-recovery-pitr-der-vollstaendige-entwickler-leitfaden\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.goteams.de\/blog\/"},{"@type":"ListItem","position":2,"name":"AWS RDS Point-in-Time Recovery (PITR): Der vollst\u00e4ndige Entwickler-Leitfaden"}]},{"@type":"WebSite","@id":"https:\/\/www.goteams.de\/blog\/#website","url":"https:\/\/www.goteams.de\/blog\/","name":"The GoTeams Way","description":"By Entrepreneurs, for Entrepreneurs.","publisher":{"@id":"https:\/\/www.goteams.de\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.goteams.de\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.goteams.de\/blog\/#organization","name":"GoTeams","url":"https:\/\/www.goteams.de\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.goteams.de\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/05\/Frame.png","contentUrl":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/05\/Frame.png","width":488,"height":80,"caption":"GoTeams"},"image":{"@id":"https:\/\/www.goteams.de\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.linkedin.com\/company\/go-teams"]},{"@type":"Person","@id":"https:\/\/www.goteams.de\/blog\/#\/schema\/person\/be2177739605974a03ed98d640cc56e1","name":"Ashutosh","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/e7346ff7f947945493b0fbe556649f15bd21842d29a4c848f3b171398a0b4d21?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/e7346ff7f947945493b0fbe556649f15bd21842d29a4c848f3b171398a0b4d21?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/e7346ff7f947945493b0fbe556649f15bd21842d29a4c848f3b171398a0b4d21?s=96&d=mm&r=g","caption":"Ashutosh"},"sameAs":["https:\/\/www.goteams.de"],"url":"https:\/\/www.goteams.de\/blog\/author\/ashutosh\/"}]}},"jetpack_featured_media_url":"https:\/\/www.goteams.de\/blog\/wp-content\/uploads\/2026\/08\/Blogpost-T09-scaled.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/posts\/348","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/users\/14"}],"replies":[{"embeddable":true,"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/comments?post=348"}],"version-history":[{"count":1,"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/posts\/348\/revisions"}],"predecessor-version":[{"id":352,"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/posts\/348\/revisions\/352"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/media\/343"}],"wp:attachment":[{"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/media?parent=348"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/categories?post=348"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.goteams.de\/blog\/wp-json\/wp\/v2\/tags?post=348"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}