Point-in-Time-Recovery vs. Snapshots: Was Sie verlieren

Jemand führt um 16:15 Uhr ein DELETE ohne WHERE-Klausel aus. Ihr aktuellstes Backup stammt von 03:00 Uhr. Alles, was zwischen diesen beiden Zeitpunkten passiert ist, ist verloren – und kein Restore kann es zurückbringen.

Diese Lücke hat einen Namen: Recovery Point Objective oder RPO. Bei der Entscheidung zwischen Point-in-Time-Recovery und Snapshots geht es ausschließlich darum, wie groß diese Lücke sein darf.

Die beiden Modelle

Snapshots erfassen den Zustand Ihrer Daten zu einem bestimmten Zeitpunkt. Sie werden nach einem Zeitplan erstellt, normalerweise jede Nacht. Wenn Sie einen Snapshot wiederherstellen, landen Sie genau bei dem Stand, der zum Erstellungszeitpunkt vorlag – alles danach ist verloren.

Point-in-Time-Recovery kombiniert ein Base Backup mit einem kontinuierlichen Stream des Write-Ahead-Logs der Datenbank. Da jede Änderung der Reihe nach aufgezeichnet wird, können Sie den Zustand auf jeden vom aufbewahrten Log abgedeckten Zeitpunkt zurücksetzen – einschließlich 16:14 Uhr, also eine Minute vor dem DELETE.

Der Unterschied ist nicht graduell. Es ist der Unterschied zwischen „Wir haben einen Tag verloren“ und „Wir haben eine Minute verloren“.

Die entscheidende Zahl

Stellen Sie sich ehrlich eine Frage: Was passiert, wenn Sie alles verlieren, was in den letzten zwölf Stunden geschrieben wurde?

Bei einem persönlichen Projekt, einer Dokumentationsseite oder einem internen Tool, dessen Daten sich reproduzieren lassen: nicht viel. Nächtliche Snapshots sind dann tatsächlich die richtige Antwort, und kontinuierliches Archiving wäre unnötige Verschwendung.

Bei allem, worin Kunden Daten schreiben, lautet die Antwort normalerweise sinngemäß: „Wir müssten den Leuten eine E-Mail schreiben und es erklären.“ Bestellungen, die nicht mehr existieren. Uploads, die verschwunden sind. Nachrichten, die versendet wurden und nun nicht mehr vorhanden sind. Allein die Supportkosten übersteigen typischerweise innerhalb eines Jahres den Unterschied bei den Infrastrukturkosten.

Der Fehler besteht nicht darin, Snapshots zu wählen. Der Fehler besteht darin, Snapshots standardmäßig zu wählen, ohne jemals zu fragen, was eine Lücke von zwölf Stunden kosten würde.

Wofür Snapshots wirklich gut sind

Snapshots sind kein minderwertiges Produkt. Sie decken Ausfälle ab, bei denen PITR nicht hilft:

• Vollständiger Verlust des Datenträgers. Ein Snapshot auf separatem Storage stellt alles wieder her – einschließlich Dateien, die nicht der Datenbank gehören.
• Schnelles, grobes Rollback. Eine fehlerhafte Migration in einer Staging-Umgebung lässt sich mit einem Snapshot schneller zurücksetzen als durch das Replay eines Logs.
• Kosten. Eine Kopie pro Tag zu speichern ist günstiger, als jeden Schreibvorgang zu speichern.
• Einfachheit. Weniger bewegliche Teile sind eine echte operative Eigenschaft – besonders für ein kleines Team.

Die Falle besteht darin, Snapshots für eine Datenbank, in die kontinuierlich geschrieben wird, als ausreichend zu betrachten.

Was PITR kostet

PITR ist nicht kostenlos, und die Kosten sollten klar benannt werden:

• Storage. Sie speichern das Base Backup plus jeden Schreibvorgang innerhalb des Aufbewahrungszeitraums.
• Komplexität. Das Archiving muss kontinuierlich funktionieren. Ein Archiver, der eine Woche lang unbemerkt ausfällt, bedeutet, dass Ihr wiederherstellbares Zeitfenster eine Woche zurückliegt – deshalb ist die Überwachung des Archivs genauso wichtig wie seine Konfiguration.
• Restore-Zeit. Das Replay eines Logs dauert länger als die Wiederherstellung eines Snapshots. Ihr RPO wird besser, Ihr RTO aber normalerweise schlechter.

Dieser letzte Zielkonflikt wird häufig übersehen. PITR bedeutet, dass Sie weniger Daten verlieren – nicht, dass Sie schneller wieder online sind.

Die mehrschichtige Antwort, die die meisten Teams tatsächlich brauchen

In der Praxis ist das keine Entscheidung zwischen zwei Optionen. Produktionsdatenbanken benötigen normalerweise drei Schichten, weil sie auf drei unterschiedliche Arten ausfallen:

Snapshots, täglich, mit einer Aufbewahrung von ein bis zwei Wochen. Eine günstige Absicherung gegen den Verlust der Maschine. Sie decken außerdem die Nicht-Datenbankdateien ab, die auf demselben Volume liegen.

Logische Dumps, täglich, außerhalb des Hosts aufbewahrt. Ein pg_dump ist portabel und von Haus aus konsistent. Es lässt sich auf einer anderen Major-Version, bei einem anderen Provider oder auf einem Laptop wiederherstellen – genau das brauchen Sie, wenn das Problem bei der Plattform und nicht bei den Daten liegt.

Kontinuierliches Archiving, sobald Kundendaten betroffen sind. Die Schicht, die aus „Wir haben den heutigen Tag verloren“ ein „Wir haben eine Minute verloren“ macht.

Jede Schicht deckt ab, was die anderen nicht leisten. Ein Snapshot hilft Ihnen nicht beim Wechsel des Providers. Ein logischer Dump hilft Ihnen nicht bei der Wiederherstellung einer Datei, die nicht in der Datenbank lag. Keine der beiden Optionen hilft Ihnen dabei, ein vier Stunden zurückliegendes DELETE rückgängig zu machen.

Wo Dockup ins Spiel kommt

Dockup bietet Ihnen die beiden Schichten, die die häufigsten Ausfälle abdecken. Es lohnt sich, genau zu benennen, um welche es sich handelt.

Volume-Snapshots, bei Bedarf oder nach einem Zeitplan mit einer festgelegten Aufbewahrungsanzahl:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Logische Datenbank-Backups, direkt in Object Storage gestreamt und während der Übertragung verschlüsselt:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Für die Wiederherstellung sind zwei Eigenschaften der zweiten Option wichtig. Das Backup wird niemals auf dem Datenbank-Host abgelegt – es wird direkt in den Storage gestreamt, während pg_dump es erzeugt. Dadurch teilt es nicht das Schicksal des Datenträgers, von dem es stammt. Außerdem wird ein Dump, der mit einem Fehlercode ungleich null beendet wird oder null Bytes erzeugt, gelöscht und als fehlgeschlagen aufgezeichnet, statt in der Liste wie ein gültiges Backup auszusehen.

Kontinuierliches Archiving übernimmt Dockup heute nicht für Sie. Wenn Ihr RPO tatsächlich im Minutenbereich liegen muss, sollten Sie das wissen, bevor Sie sich entscheiden. Es ist durchaus sinnvoll, dies selbst gegen eine verwaltete Datenbank zu betreiben und die Plattform für alles andere zu verwenden.

Die Übung, die Sie diese Woche machen sollten

Notieren Sie sich für Ihre Produktionsdatenbank zwei Zahlen:

1. RPO – wie viele Daten Sie verlieren können. Gemessen in Zeit.
2. RTO – wie lange Sie offline sein können. Ebenfalls gemessen in Zeit.

Prüfen Sie anschließend, was Ihr aktuelles Setup tatsächlich liefert, indem Sie etwas wiederherstellen. Wenn sich die notierten Zahlen von den Werten unterscheiden, die Ihr Setup liefert, haben Sie eine Entscheidung gefunden, die Sie treffen können, solange noch nichts brennt – und das ist der einzig gute Zeitpunkt dafür.

Häufig gestellte Fragen

Was ist der Unterschied zwischen RPO und RTO? RPO bezeichnet die Menge an Daten, die Sie verlieren – die Lücke zwischen dem letzten wiederherstellbaren Zeitpunkt und dem Ausfall. RTO bezeichnet die Dauer der Wiederherstellung. Snapshots bieten ein großes RPO und ein kurzes RTO; PITR kehrt dieses Verhältnis um.

Kann ich mit einem nächtlichen Snapshot vor einer Stunde gelöschte Zeilen wiederherstellen? Nein. Ein Snapshot stellt den Zustand zu dem Zeitpunkt wieder her, an dem er erstellt wurde. Alles, was danach geschrieben wurde, ist in der Datei nicht enthalten. Die Wiederherstellung eines beliebigen Zeitpunkts erfordert kontinuierliches Archiving.

Ist ein Volume-Snapshot dasselbe wie ein Datenbank-Backup? Nein. Ein Snapshot erfasst den Datenträger einschließlich des Zustands, in dem sich die Datenbank möglicherweise gerade mitten in einem Schreibvorgang befand. Ein logischer Dump ist intern konsistent und auf andere Versionen und Provider portierbar. Die meisten Produktionsumgebungen benötigen beides.

Wie lange sollte ich Backups aufbewahren? Lange genug, um ein Problem zu bemerken. Beschädigungen oder eine fehlerhafte Migration werden häufig erst Tage später entdeckt. Eine Aufbewahrung von nur einem Tag bedeutet daher oft, dass die einzigen vorhandenen Backups den Schaden bereits enthalten.