Ein Backup, das Sie nie wiederhergestellt haben, ist kein Backup

Der schlechteste Zeitpunkt, um festzustellen, dass ein Backup nicht funktioniert, ist der Moment, in dem Sie es brauchen. Und doch ist genau das der mit Abstand häufigste Ablauf: Backups werden einmal eingerichtet, im Dashboard leuchtet achtzehn Monate lang ein grüner Haken, und dann erzeugt eine Wiederherstellung eine leere Datenbank.

Das Wiederherstellen eines Datenbank-Backups zu testen ist nicht nur eine Best Practice, die – wie die meisten Best Practices – optional wäre. Ein Backup ist eine Behauptung. Solange Sie noch keines wiederhergestellt haben, ist es eine ungetestete Behauptung.

So schlagen Backups fehl – und das muss eine Überprüfung tatsächlich kontrollieren.

Die vier Arten, wie ein Backup unbemerkt nutzlos wird

1. Es ist leer, und niemand hat nachgesehen

Ein pg_dump, das途中 fehlschlägt, kann trotzdem eine Datei erzeugen. Ein Dump gegen den falschen Datenbanknamen erzeugt eine gültige, korrekte, leere Datei. Für alles, was nur auf einen Exit-Code ungleich null oder das Vorhandensein einer Datei prüft, sehen beide Fälle wie ein Erfolg aus.

Die günstigste Prüfung der Welt: Sehen Sie sich die Größe an und vergleichen Sie sie mit der von gestern. Ein Backup mit 400 Bytes, wenn das gestrige 40 MB groß war, sagt Ihnen alles. Ein Backup, das sechs Monate lang 400 Bytes groß war, hat es Ihnen die ganze Zeit gesagt.

2. Es enthält Daten, aber nicht die Dinge darum herum

pg_dump für eine einzelne Datenbank enthält keine Rollen und keine anderen Datenbanken. Stellen Sie es auf einem frischen Server wieder her, kommen die Tabellen an, während sich jedes GRANT auf eine Rolle bezieht, die nicht existiert. Ihre App verbindet sich und erhält für alles die Fehlermeldung „permission denied“.

Bei Extensions ist es genauso. Wenn Ihr Schema von pgcrypto oder uuid-ossp abhängt und diese auf dem Ziel nicht vorhanden sind, schlägt die Wiederherstellung途中 fehl und lässt einige Tabellen zurück.

3. Die Flags waren für die benötigte Wiederherstellung falsch

pg_dump erzeugt je nach Format unterschiedliche Ergebnisse, und der Fehler wird meistens erst unter Zeitdruck entdeckt:

• Plain SQL wird mit psql wiederhergestellt und ist menschenlesbar. Eine selektive Wiederherstellung ist nicht möglich, und bei großen Datenbanken ist es langsam.
• Custom-Format (-Fc) wird mit pg_restore wiederhergestellt, unterstützt Parallelisierung und selektive Wiederherstellung und ist die richtige Wahl für alles, was eine gewisse Größe hat.

Ein Backup im Plain-Format zu erstellen, weil das Tutorial es so gemacht hat, und während eines Incidents festzustellen, dass sich eine einzelne Tabelle nicht wiederherstellen lässt, ist eine ganz spezielle und vermeidbare Art, einen schlechten Tag zu haben.

4. Sie können es nicht entschlüsseln

Wenn Backups verschlüsselt sind – und das sollten sie sein –, gehört der Schlüssel zum Backup. Ein Schlüssel, der nur auf der verlorenen Maschine liegt oder nur in einer Umgebungsvariablen des ausgefallenen Service vorhanden ist, ist ein Schlüssel, den Sie im entscheidenden Moment nicht haben.

Wie eine echte Überprüfung aussieht

Der Test lautet nicht: „Existiert die Datei?“ Stellen Sie sie an einem anderen Ort wieder her und stellen Sie ihr eine Frage.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

Schritt 2 ist der entscheidende Punkt. Eine Wiederherstellung, die ohne Fehler abgeschlossen wird, sagt Ihnen noch nichts darüber, ob die Daten vorhanden sind. Zeilenanzahlen und eine Prüfung der Aktualität tun es.

Drei Dinge, die Sie unbedingt prüfen sollten:

• Die Zeilenanzahlen liegen in der richtigen Größenordnung. Nicht exakt – Daten ändern sich –, aber eine Tabelle, die 200.000 Zeilen hatte und jetzt nur noch 12 enthält, ist ein Fehler.
• Der neueste Datensatz ist aktuell. Wenn die letzte Bestellung in Ihrem „nächtlichen“ Backup aus dem März stammt, wurde Ihr Backup-Job im März beendet.
• Die App kann sich tatsächlich verbinden. Richten Sie eine Staging-Instanz auf die wiederhergestellte Datenbank und laden Sie eine Seite.

Nach einem Zeitplan, nicht nach einer Katastrophe

Ein realistischer Turnus ist monatlich und automatisiert, mit einem Ergebnis an einem Ort, an dem Sie es bemerken werden. Eine Kalendererinnerung mit dem Text „Backups testen“ ist eine Erinnerung, die Sie zurückstellen werden.

Damit es dauerhaft funktioniert, muss der Fehler laut sein: Wenn die Überprüfungsabfrage weniger Zeilen als ein bestimmter Schwellenwert zurückgibt, sollte dies jemanden genauso alarmieren wie ein Fehler in der Produktion. Ein Backup-System, das still fehlschlägt, ist nicht von einem fehlenden Backup-System zu unterscheiden – bis zu dem Moment, in dem es darauf ankommt.

Wie Dockup damit umgeht

Drei Entscheidungen, die jeweils auf einen der oben beschriebenen Fehler abzielen.

Backups werden an einem anderen Ort gespeichert. Ein Backup auf derselben Festplatte wie die Datenbank ist kein Backup – es ist eine Kopie, die zusammen mit der Festplatte ausfällt. Dockup streamt Datenbank-Backups direkt in den Object Storage, während sie erstellt werden. Dadurch hängt die Datei nie von dem Host ab, auf dem sie erzeugt wurde.

Sie sind verschlüsselt, und der Schlüssel liegt nicht auf der Maschine. Backups werden während des Streamings mit AES-256-GCM verschlüsselt. Für die Wiederherstellung ist entscheidend, dass der Schlüssel von der Plattform verwaltet wird und nicht in der Umgebung des zu sichernden Service liegt.

Ein Backup, das nichts erzeugt hat, wird nicht als Backup erfasst. Damit wird das Problem leerer Dateien direkt adressiert: Wenn der Dump mit einem Exit-Code ungleich null beendet wird oder null Bytes erzeugt, wird der Upload gelöscht und das Backup als fehlgeschlagen erfasst. So erhalten Sie keine Liste grüner Einträge, unter denen sich eine 400-Byte-Datei befindet.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Die Größen in dieser Liste sind der günstigste Health Check, den Sie haben. Beobachten Sie ihre Entwicklung.

Die unbequeme Frage

Wenn Ihre Produktionsdatenbank in den nächsten zehn Minuten zerstört würde: Wie lange würde es dauern, bis sie wieder verfügbar ist, und wie viele Daten hätten Sie verloren?

Wenn Sie nicht beide Zahlen nennen können, haben Sie keine Backup-Strategie – Sie haben Backup-Dateien. Der Unterschied liegt ausschließlich darin, ob jemand die Wiederherstellung jemals durchgeführt hat.

Häufig gestellte Fragen

Wie oft sollte ich eine Wiederherstellung testen? Monatlich ist ein sinnvoller Standard – automatisiert statt manuell. Entscheidend ist, dass ein Fehler laut gemeldet wird, nicht dass der Turnus besonders kurz ist.

Warum wurde meine Wiederherstellung abgeschlossen, aber es waren keine Daten vorhanden? Meistens wurde der Dump gegen die falsche Datenbank erstellt oder ist途中 fehlgeschlagen, während die Datei noch geschrieben wurde. Vergleichen Sie die Backup-Größen im Zeitverlauf – ein leerer Dump ist in einer Größenentwicklung offensichtlich, in einer Statusspalte aber unsichtbar.

Sollten Backups verschlüsselt werden? Ja, und der Schlüssel muss an einem Ort liegen, der den Verlust der Maschine übersteht. Ein verschlüsseltes Backup, dessen Schlüssel auf dem verlorenen Server lag, kann nicht wiederhergestellt werden.

Ist ein Snapshot dasselbe wie ein Backup? Nein. Ein Volume-Snapshot erfasst die Festplatte einschließlich des Zustands, in dem sich die Datenbank in diesem Moment befand. Ein logischer Dump ist konstruktionsbedingt konsistent. Die meisten Teams benötigen beides – für unterschiedliche Fehlerfälle.