Was ist Point-in-Time Recovery (PITR)?

Point-in-Time Recovery ist ein Restore-Verfahren, das ein Änderungsprotokoll über ein Basis-Backup wiedergibt und die Datenbank auf jede Sekunde zurückführt. Das Szenario, für das es existiert, ist nicht der Hardwareausfall – dafür ist die Replikation da –, sondern das menschliche: eine Migration, die um 14:32 Zeilen beschädigt hat, ein Skript, das den falschen Tenant gelöscht hat. PITR antwortet mit dem Einzigen, was hilft: der Datenbank genau so, wie sie um 14:31:59 war.

Das Wichtigste in Kürze

Der Mechanismus in einer einzigen Arbeitssitzung

-- Das Änderungsprotokoll ist das Rohmaterial: jeder bestätigte Schreibvorgang, der Reihe nach.
-- Vor riskanten Arbeiten können Sie eine benannte Marke darin ablegen:
SELECT pg_create_restore_point('before_pricing_migration');

-- Wiederherstellung = Basis-Backup + Wiedergabe, angehalten, wo Sie es sagen:
--   das um 02:00 erstellte Basis-Backup wiederherstellen
--   das Protokoll vorwärts wiedergeben…
--   …und kurz vor dem Schaden anhalten:
--     recovery_target_time = '2026-08-05 14:31:59+00'
--     (oder recovery_target_name = 'before_pricing_migration')

-- Alles vor dem Ziel Bestätigte existiert; nichts danach.

Hier leistet das Write-Ahead-Log doppelte Arbeit: Dieselbe geordnete Aufzeichnung, die Transaktionen ihre Dauerhaftigkeit gibt, wird, fortlaufend archiviert, zur Zeitmaschine. Dokumentdatenbanken spielen dasselbe Stück mit dem Oplog – den Operationsstrom aufzeichnen, auf einen Snapshot wiedergeben, auf Ansage anhalten (PostgreSQL nennt es Continuous Archiving; MongoDB dokumentiert dieselbe Architektur über Dateisystem-Snapshots).

Nach jeder Wiederherstellung findet der Prüfschritt der Übung auf Anwendungsebene statt – bestätigen Sie, dass die Zeitachse dort gelandet ist, wo sie sollte:

// JavaScript / Node.js — Back4app JS SDK
// Restore drill: verify the restored data lines up with the incident timeline
const incident = new Date('2026-08-05T14:32:00Z'); // when the bad deploy hit

const latest = new Parse.Query('Order');
latest.lessThan('createdAt', incident);
latest.descending('createdAt');
const lastGood = await latest.first();   // newest order before the incident

const after = new Parse.Query('Order');
after.greaterThanOrEqualTo('createdAt', incident);
const leaked = await after.count();      // must be 0 on a clean PITR restore

console.log(`last good write: ${lastGood?.get('createdAt')}`);
console.log(`rows past the recovery target: ${leaked}`);

// Flutter / Dart — Back4app Flutter SDK
// Restore drill: verify the restored data lines up with the incident timeline
final incident = DateTime.parse('2026-08-05T14:32:00Z'); // the bad deploy

final latest = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereLessThan('createdAt', incident)
  ..orderByDescending('createdAt')
  ..setLimit(1);
final lastGood = await latest.query();   // newest order before the incident

final after = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereGreaterThanOrEqualsTo('createdAt', incident);
final leaked = await after.count();      // must be 0 on a clean PITR restore

print('last good write: '
    '${(lastGood.results?.first as ParseObject?)?.createdAt}');
print('rows past the recovery target: ${leaked.count}');

// iOS / Swift — Back4app Swift SDK
// Restore drill: verify the restored data lines up with the incident timeline
let incident = ISO8601DateFormatter()
  .date(from: "2026-08-05T14:32:00Z")!   // when the bad deploy hit

let latest = Order.query("createdAt" < incident)
  .order([.descending("createdAt")])
  .limit(1)
latest.first { result in                 // newest order before the incident
  if case .success(let lastGood) = result {
    print("last good write: \(String(describing: lastGood.createdAt))")
  }
}

let after = Order.query("createdAt" >= incident)
after.count { result in                  // must be 0 on a clean PITR restore
  if case .success(let leaked) = result {
    print("rows past the recovery target: \(leaked)")
  }
}

// Android / Kotlin — Back4app Android SDK
// Restore drill: verify the restored data lines up with the incident timeline
val incident = Date(1754404320000L)      // 2026-08-05T14:32:00Z, the bad deploy

val latest = ParseQuery.getQuery<ParseObject>("Order")
latest.whereLessThan("createdAt", incident)
latest.orderByDescending("createdAt")
latest.limit = 1
latest.findInBackground { lastGood, _ -> // newest order before the incident
    println("last good write: ${lastGood?.firstOrNull()?.createdAt}")
}

val after = ParseQuery.getQuery<ParseObject>("Order")
after.whereGreaterThanOrEqualTo("createdAt", incident)
after.countInBackground { leaked, e ->   // must be 0 on a clean PITR restore
    if (e == null) println("rows past the recovery target: $leaked")
}

Wie eine Wiederherstellung 14:31:59 erreicht

Zwei Eigenschaften folgen aus dem Mechanismus. Erstens: Der RPO wird von der Aufzeichnungsfrequenz bestimmt. Alle paar Sekunden versandte Protokolle bedeuten Sekunden maximalen Verlusts, ganz gleich, wann der letzte Snapshot lief. Zweitens: Der RTO wird von der Wiedergabedistanz bestimmt. Eine Wiederherstellung auf 23:00 aus einer Basis von 02:00 bedeutet, 21 Stunden an Schreibvorgängen wiederzugeben – deshalb erstellen PITR-Systeme weiterhin häufige Snapshots, nicht für die Granularität, sondern um die Anlaufstrecke zu verkürzen.

Snapshots vs. PITR

Welche Wiederherstellungsgarantie brauchen Sie wirklich?

Typische Anwendungsfälle

• Das fehlerhafte Deployment. Eine Migration oder ein Hotfix beschädigt am Nachmittag Daten – Wiederherstellung auf die Sekunde vor der Auslieferung.
• Versehentliche Löschungen. Der falsche Tenant, die falsche Collection, die falsche WHERE-Klausel – Wiederherstellung auf den Moment unmittelbar vor der Anweisung, oft in eine Wegwerfdatenbank, um nur das Verlorene herauszuziehen.
• Ransomware und kompromittierte Konten. Zurückspulen auf die Zeit vor dem Eingriff in die Daten – wobei Verschlüsselung im Ruhezustand die Archivkopien selbst schützt.
• Aufbewahrung aus Compliance-Gründen. Regulierte Produkte müssen Wiederherstellbarkeit nachweisen – dokumentierte Zeitfenster, getestete Restores, prüfbare Übungen.
• Probe vor dem Launch. Die Restore-Übung als Freigabekriterium: Teams, die einmal auf einen Zeitstempel wiederhergestellt haben, tun es in der entscheidenden Nacht gelassen.

Sollten Sie sich auf die Standard-Backups verlassen? Eine Entscheidungsmatrix

Was die Plattform auch mitbringt, drei Entscheidungen bleiben Ihre: der RPO, den Ihr Produkt übersteht, der RTO, den Ihre Nutzer hinnehmen, und der Übungsrhythmus, der beide Zahlen ehrlich hält – die Disziplin, die die Notfallplanungsleitlinie des NIST so formalisiert: Ziele definieren, dann gegen sie testen.

Grenzen und Trade-offs

• Replikation ist keine Wiederherstellung. Replikate replizieren den Fehler binnen Sekunden; nur Backups reichen davor zurück. Andere Werkzeuge, andere Fehlerklassen.
• Das Zeitfenster ist endlich. PITR erreicht jede Sekunde – innerhalb der Aufbewahrungsfrist. Schaden, der nach dem Schließen des Fensters entdeckt wird, ist dauerhaft; bemessen Sie die Frist nach der Entdeckungszeit, nicht allein nach dem Speicherpreis.
• Wiedergabe braucht Zeit. Protokolllastige Restores können lange laufen; Ihr echter RTO wird in Übungen gemessen und nicht von Dashboards zitiert.
• Wiederherstellungen landen als Ganzes. Klassisches PITR baut die Datenbank zu einem Zeitstempel wieder auf; die verlorenen Zeilen einer einzelnen Tabelle herauszuholen bedeutet, in eine Wegwerfinstanz wiederherzustellen und sie herüberzukopieren – planen Sie diesen Ablauf ein.
• Ein ungetestetes Backup ist ein Gerücht. Stillschweigend fehlgeschlagene Exporte, abgelaufene Zugangsdaten, fehlende Runbooks – jedes davon bleibt unsichtbar, bis eine Übung oder ein Ernstfall es findet. Übungen sind günstiger.

PITR und Backups mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Backups der verwalteten Datenbank laufen ohne Einrichtung nach Zeitplan, und die Wiederherstellung ist ein Handgriff im Dashboard statt einer Nacht voller Protokollarchäologie – die Snapshot-und-Mechanik-Hälfte dieses Artikels, von der Plattform übernommen. Die Hälfte, die bei Ihnen bleibt, ist das Entscheiden: Ihre RPO- und RTO-Ziele, Ihr Bedarf an Aufbewahrung und die vierteljährliche Übung, in der die Code-Tabs oben belegen, dass die wiederhergestellte Zeitachse genau die ist, die Sie angefordert haben.