Backups Done Right: Kopien reichen nicht

Der nächtliche Backup-Job ist grün. Eine Datei liegt in einem zweiten Verzeichnis, der Storage meldet genug freien Platz, und das Monitoring hat einen Heartbeat empfangen. Das beruhigt. Es beantwortet nur die falsche Frage.

Ein Unternehmen braucht im Ernstfall keine Kopie. Es braucht einen bekannten Weg von einem beschädigten Produktionssystem zurück zu einem brauchbaren Zustand. Dieser Weg muss auch dann funktionieren, wenn Zugangsdaten gestohlen wurden, ein Administrator den falschen Befehl ausgeführt hat, die letzte Sicherung bereits beschädigte Daten enthält oder der Backup-Host selbst nicht mehr startet.

Die amerikanische Cybersecurity-Behörde CISA empfiehlt im Ransomware Guide deshalb verschlüsselte, vom Produktivsystem getrennte Backups und regelmässige Tests ihrer Verfügbarkeit und Integrität. Sie nennt Delete Protection und Object Lock ausdrücklich als Schutz vor Ransomware. Das NIST beschreibt Backup und Recovery ebenfalls als zusammengehörigen Prozess. Die Kopie ist darin nur ein Zwischenschritt.

Ein Backup ist kein Bestand an Dateien. Es ist eine regelmässig bewiesene Fähigkeit zur Wiederherstellung.

Aus diesem Satz folgt eine andere Architektur. Sie beginnt beim Schaden, den man überstehen muss, und endet bei einem Restore, der denselben Weg nimmt wie im Notfall.

Zuerst festlegen, was wiederhergestellt werden muss

«Alles sichern» ist keine Backup-Strategie. Daten haben verschiedene Aufgaben, ändern sich unterschiedlich schnell und lassen sich nicht auf dieselbe Weise wiederherstellen.

Eine Produktionsdatenbank braucht einen konsistenten Dump oder ein Verfahren, das Transaktionsgrenzen versteht. Eine VM-Sicherung kann sehr gross sein, dafür aber als Ganzes zurückgespielt werden. Ein Medienarchiv wächst über Jahre und sollte alte Dateien behalten, selbst wenn sie an der Quelle versehentlich verschwinden. Build-Artefakte, Container-Images und Suchindizes lassen sich womöglich aus Git oder einer massgebenden Datenbank neu erzeugen. Sie zu sichern kann teurer sein als ihr Neuaufbau.

Vier Fragen bringen diese Unterschiede an die Oberfläche:

1. Welche Daten sind massgebend? Ohne welche Daten lässt sich das Geschäft nicht fortsetzen?
2. Wie viel Verlust ist tragbar? Das Recovery Point Objective, kurz RPO, beschreibt die maximal akzeptierte Lücke zwischen Schaden und letztem brauchbarem Stand.
3. Wie schnell muss der Zustand zurück sein? Das Recovery Time Objective, kurz RTO, setzt dem Wiederherstellungsweg ein Zeitlimit.
4. Was darf bewusst neu entstehen? Rebuildable State gehört in ein reproduzierbares Verfahren, nicht automatisch in die teuerste Schutzklasse.

Die Klassifikation verhindert zwei häufige Fehler. Der erste ist Unterversicherung: Eine Datenbank landet als beliebige Dateikopie auf einem NAS. Der zweite ist Überversicherung: Gigabytes an reproduzierbaren Caches werden über Jahre unveränderbar aufbewahrt, während niemand den Restore der eigentlichen Datenbank ausprobiert.

Das Bedrohungsmodell umfasst mehr als Ransomware

Ransomware liefert den anschaulichsten Test für eine Backup-Architektur: Ein Angreifer besitzt bereits einen Teil der eigenen Infrastruktur und versucht, Produktion und Recovery Points gemeinsam zu zerstören. Sie ist trotzdem nur ein Eintrag im Bedrohungsmodell.

Mindestens diese Situationen brauchen einen eigenen Wiederherstellungsweg:

• Bedienfehler. Eine berechtigte Person löscht das falsche Dataset, führt eine fehlerhafte Migration aus oder verkürzt die Retention.
• Defekte Daten. Die Anwendung schreibt logisch falschen State, und der Fehler bleibt länger unentdeckt als das kurzfristige Backup-Fenster.
• Credential-Diebstahl. Ein Angreifer erhält den API-Key des täglichen Jobs oder administrativen Zugriff auf ein Quellsystem.
• Storage-Ausfall. Eine Disk, ein Controller, ein Host oder ein ganzer Standort fällt weg.
• Abhängiger Ausfall. DNS, Identity Provider, Secret Store oder Backup-Konsole sind im selben Vorfall nicht verfügbar.
• Verlorenes Wissen. Die Person, die das Setup gebaut hat, ist nicht erreichbar. Der Restore muss aus Dokumentation und hinterlegten Schlüsseln möglich sein.

Diese Liste verändert die Bewertung einer Kopie. Ein Snapshot auf derselben Disk schützt gut gegen eine gelöschte Datei und gar nicht gegen den Ausfall dieser Disk. Eine immutable Cloud-Kopie übersteht lokale Ransomware, hilft ohne Encryption-Key aber niemandem. Ein zwei Jahre alter Jahresstand deckt späte Korruption ab, erfüllt jedoch kein RPO von sechs Stunden.

Jede Schutzmassnahme braucht deshalb eine klar benannte Schadensklasse. «Redundant» oder «offsite» allein sagt zu wenig.

3-2-1-1-0 ist eine Merkhilfe, kein Beweis

Die bekannte 3-2-1-Regel verlangt drei Kopien auf zwei Medientypen, davon eine ausser Haus. Moderne Varianten ergänzen eine unveränderbare oder offline gehaltene Kopie und null ungeprüfte Fehler. Das ergibt 3-2-1-1-0.

Als Checkliste ist das nützlich. Als Architektur ist es zu grob.

Drei Kopien mit demselben kompromittierten Administratorkonto bilden nur eine Fehlerdomäne. Zwei Medien im selben Rack überstehen keinen Gebäudeschaden. Eine Cloud-Kopie, die ein gestohlener API-Key sofort löschen darf, ist zwar offsite, aber nicht unabhängig. Und null Fehler in einem Repository-Check sagt noch nichts darüber, ob eine Anwendung mit den restaurierten Daten startet.

Darum sollte jede Kopie mit ihrer Failure Domain beschrieben werden:

• Wer kann sie schreiben?
• Wer kann sie löschen?
• Welche Identität kann ihre Retention verändern?
• Welcher Host, welches Netz und welcher Anbieter müssen für den Restore funktionieren?
• Welche Schlüssel werden benötigt, und liegen diese ausserhalb des Systems, das sie entschlüsseln sollen?

Erst diese Antworten zeigen, ob mehrere Kopien auch mehrere Wege durch einen Vorfall bilden.

Ransomware-Resilienz beginnt bei den Berechtigungen

Ransomware verschlüsselt heute selten nur die gemountete Freigabe. Angreifer suchen nach Backup-Konsolen, Cloud-Credentials und Administrationszugängen. Wer Produktion und Sicherung mit derselben Identität verwaltet, hat die wichtigste Grenze bereits entfernt.

Ein belastbares Setup trennt mindestens vier Fähigkeiten:

1. Lesen an der Quelle. Die Backup-Identität bekommt nur die Daten oder den vorbereiteten Dump, die sie tatsächlich braucht.
2. Neue Sicherungen schreiben. Der tägliche Job darf neue Archive und Objekte anlegen.
3. Alte Sicherungen löschen. Prune und Retention laufen mit einer separaten Identität und in einem eigenen Zeitfenster.
4. Schutzregeln verändern. Object Lock, Bucket-Retention und Schlüsselverwaltung gehören nicht in die Hand des täglichen Jobs.

Pull-Backups können dabei helfen: Der Backup-Host initiiert die Übertragung, und das Produktionssystem erhält keinen allgemeinen Schreibzugriff auf das Repository. Pull ist trotzdem kein automatischer Sicherheitsgewinn. Ein kompromittierter Backup-Host besitzt Leserechte auf vielen Quellen. Deshalb braucht jede Quelle einen eigenen Schlüssel, einen eng begrenzten Forced Command und einen Pfad, der keine freie Shell eröffnet.

Für eine externe Kopie gilt dasselbe. Object Lock ist erst dann eine belastbare Grenze, wenn der Standard für neue Objekte aktiv ist, die Aufbewahrung nicht verkürzt werden kann und der tägliche Schlüssel keine Löschrechte besitzt. Im Compliance Mode verhindert Backblaze B2 Object Lock Änderungen und Löschungen bis zum gesetzten Datum auch für privilegierte Benutzer.

Konsistenz entsteht an der Quelle

Ein Backup-Programm kann nur sichern, was es sieht. Es weiss nicht, ob drei Dateien gemeinsam eine Transaktion bilden oder ob ein Datenbankprozess noch nicht alle Seiten auf Disk geschrieben hat.

Darum gehört der erste Schritt der Sicherung zur Anwendung:

• PostgreSQL erzeugt einen logischen Dump mit der passenden Major-Version und den benötigten Rollen.
• MongoDB exportiert über ein konsistentes, authentifiziertes Verfahren.
• Anwendungen mit Dateien und Datenbank schreiben beide Teile in einen kontrollierten Spool und legen Metadaten dazu.
• Object Storage wird generationengenau inventarisiert, wenn ältere Objektversionen für die Wiederherstellung relevant sind.

Der Backup-Host holt danach ein abgeschlossenes Artefakt ab. Er erhält keine Datenbank-Passwörter, wenn ein eng begrenzter Quellbefehl den Export ausführen kann. Der Spool wird erst entfernt, wenn das Archiv bestätigt ist.

Das ist mehr Arbeit als ein rekursives rsync. Es verschiebt die Verantwortung an die einzige Stelle, die weiss, wann die Daten zusammenpassen.

Retention ist eine Löscharchitektur

Retention wird oft als Reihe von Zahlen beschrieben: sieben tägliche, vier wöchentliche, sechs monatliche und zwei jährliche Stände. Diese Grandfather-Father-Son-Staffelung, kurz GFS, verteilt Recovery Points über verschiedene Zeithorizonte.

Die schwierigere Frage lautet, wer die nicht mehr benötigten Stände entfernen darf.

Ein täglicher Backup-Job mit Löschrechten verbindet den häufigsten Prozess mit der gefährlichsten Fähigkeit. Besser ist ein eigener Prune-Job mit separatem Credential, engen Befehlen und einem Snapshot unmittelbar vor der Bereinigung. Der Snapshot schafft ein kurzes lokales Rückrollfenster. Eine externe Compliance-Retention schützt die zweite Kopie für eine feste Zeit.

Kapazitätsalarme gehören zu dieser Architektur. Append-only ohne kontrollierten Prune verschiebt einen Angriff lediglich: Statt alte Sicherungen zu löschen, kann ein kompromittierter Client das Repository füllen. Warn- und kritische Schwellen müssen deshalb genug Zeit für eine bewusste Reaktion lassen.

Sauber gesicherter Defekt bleibt defekt

Backups bewahren Zustände. Sie entscheiden nicht, ob dieser Zustand fachlich richtig ist.

Eine gelöschte Tabelle kann in jeder folgenden Sicherung korrekt fehlen. Eine Anwendung kann monatelang verschlüsselte Dateien archivieren, nachdem ein Angreifer sie verändert hat. Ein Dump kann formal vollständig sein und dennoch keine Daten enthalten, weil der Backup-User auf die falsche Datenbank zeigte. Ohne lange genug aufbewahrte Recovery Points und fachliche Prüfungen konserviert das System den Defekt mit perfekter Zuverlässigkeit.

Darum gehören drei Zeiträume zusammen:

1. Änderungsfrequenz. Sie bestimmt, wie dicht kurzfristige Recovery Points sein müssen.
2. Erkennungszeit. Sie bestimmt, wie weit die Retention zurückreichen muss. Ein Fehler, der erst beim Monatsabschluss auffällt, braucht mehr als sieben Tagesstände.
3. Wiederanlaufzeit. Sie bestimmt, wie schnell Daten, Runtime, Secrets und Routing wieder zusammengesetzt werden müssen.

GFS-Retention kann diese Zeiträume abdecken, wenn die Zahlen aus dem Geschäft kommen. Eine kopierte Standardkonfiguration liefert nur eine hübsche Staffelung.

Der Restore braucht eine Beweiskette

Ein einzelner grüner Test reicht nicht, denn jede Prüfstufe beantwortet eine andere Frage.

1. 01Konsistente QuelleDump, Spool oder unveränderliche Objektgeneration
2. 02Isoliertes RepositoryVerschlüsselt, versioniert und mit begrenztem Schreibpfad
3. 03Unveränderbare KopieSeparate Failure Domain und getrennte Löschberechtigung
4. 04Geprüfter RestoreIsoliert starten, Inhalte prüfen und Laufzeit messen

Geprüfter Restore

Die Beweiskette wird mit jeder Stufe stärker:

1. Job ausgeführt. Der Timer hat den Prozess gestartet.
2. Archiv bestätigt. Das Backup-Programm hat eine Transaktion erfolgreich abgeschlossen.
3. Repository geprüft. Metadaten und ein sinnvoller Anteil der Datenblöcke bestehen den Integritätscheck.
4. Datei extrahiert. Ein zufällig gewähltes Objekt lässt sich aus einem aktuellen Archiv lesen.
5. Anwendung isoliert restauriert. Eine passende, digest-gepinnte Laufzeit startet mit dem Dump. Tabellen, Rollen, Indizes, Objektzahlen oder andere fachliche Invarianten stimmen.
6. Offsite-Weg restauriert. Der Test lädt aus der externen Kopie und umgeht lokale Caches sowie das lokale Repository.
7. Host-Verlust geprobt. Schlüssel, Runbooks und Infrastruktur-Code reichen aus, um den Backup-Host auf anderer Hardware wieder aufzubauen.

Ein Repository-Check und ein Restore-Test ersetzen einander nicht. Der erste findet beschädigte Backup-Blöcke. Der zweite findet fehlende Rollen, inkompatible Datenbankversionen, unvollständige Spools und falsche Annahmen über die Anwendung.

Der Test muss hinter derselben Grenze beginnen, hinter der man nach dem Vorfall stehen würde.

Ein Cloud-Restore, der unbemerkt das lokale Repository liest, prüft keine externe Kopie. Ein Datenbanktest mit einem beweglichen Container-Tag prüft beim nächsten Lauf womöglich eine andere Runtime. Ein Skript, das nur den Exit-Code von pg_restore betrachtet, kann eine leere oder fachlich unbrauchbare Datenbank als Erfolg melden.

RTO wird gemessen und nicht aus der Dateigrösse geraten

Die Restore-Dauer besteht aus mehr als Transferzeit. Jemand muss den Vorfall erkennen, den richtigen Recovery Point wählen, Credentials beschaffen, Infrastruktur bereitstellen, Daten übertragen, importieren und fachlich freigeben. Danach folgen DNS, Routing oder ein kontrollierter Failover.

Ein Laborwert für den Download einer Datei bildet davon nur einen Ausschnitt ab. Ein brauchbarer Drill misst mindestens:

• Zeit vom Alarm bis zur eindeutigen Entscheidung für den Restore,
• Zeit für Bereitstellung und Datenübertragung,
• Import- oder Rehydrationsdauer,
• Dauer der technischen und fachlichen Prüfungen,
• Handgriffe, die weiterhin eine bestimmte Person oder einen bestimmten Rechner voraussetzen.

RTO ist erst belastbar, wenn der langsamste notwendige Schritt bekannt ist. Bei grossen Datenmengen kann das Netzwerk dominieren. Bei einer kleinen, komplexen Datenbank dauert die Validierung womöglich länger als der Import. Bei einem vollständigen Host-Verlust wird oft die Suche nach Schlüsseln zum kritischen Pfad.

Der Drill sollte dieselbe Uhr verwenden wie das Leistungsversprechen. Eine isolierte Datenbank in sieben Minuten zu starten ist ein guter technischer Test. Er beweist kein zweistündiges Recovery-Ziel, solange die Freigabe, Umschaltung und Kommunikation fehlen.

Monitoring muss das Ausbleiben sehen

Viele Backup-Jobs melden Erfolg aktiv. Bleibt ein Prozess vor dieser Meldung hängen, entsteht kein Fehlerereignis. Es entsteht Stille.

Push-Monitoring dreht das Modell um. Jeder Job sendet nach erfolgreichem Abschluss einen Heartbeat. Das Monitoring kennt den erwarteten Abstand und alarmiert, wenn der nächste Beleg fehlt. Dadurch werden ein nicht gestarteter Timer, ein hängender Transfer und ein abgebrochener Restore gleichermassen sichtbar.

Der Heartbeat gehört ans Ende. Ein Signal beim Start beweist nur, dass systemd eine Unit aufgerufen hat. Genau deshalb werden lange Restore-Tests oft durch einen Timeout sichtbar, obwohl ihr Timer pünktlich lief.

Zusätzlich braucht das System eigene Signale für Pool-Zustand, Scrubs, Kapazität, Root-Dateisystem und die Konsistenz der Manifeste. Ein gesundes Betriebssystem sagt nichts über ein volles Backup-Dataset. Ein gesundes Dataset sagt nichts über einen seit zwei Wochen fehlenden Datenbank-Dump.

Schlüssel und Runbooks gehören in den Restore

Verschlüsselung erzeugt eine neue Failure Domain. Ohne Passphrase oder exportierten Repository-Key ist die unveränderbare Offsite-Kopie mathematisch intakt und operativ verloren.

Recovery-Material darf deshalb nicht ausschliesslich auf dem Backup-Host, im gesicherten Secret Store oder auf dem Notebook einer einzelnen Person liegen. Mindestens eine kontrollierte Kopie gehört in einen getrennten administrativen Pfad. Ihr Zugriff muss protokolliert und regelmässig ausprobiert werden.

Dasselbe gilt für das Runbook. Es sollte keine Befehlsablage sein, sondern Entscheidungen sichtbar machen: Welcher Recovery Point ist zulässig? Welche Quelle wird im Zweifel als massgebend behandelt? Wann darf Produktion wieder schreiben? Welche Prüfung beendet den Restore? Wer kommuniziert den Datenverlust innerhalb des RPO?

Ein Host-Loss-Drill verbindet diese Teile. Er beginnt mit leerer Compute-Kapazität, provisioniert den Ersatz aus Infrastructure as Code, importiert oder lädt die gesicherten Daten, beschafft die Schlüssel aus dem getrennten Pfad und führt einen Restore aus. Erst dann ist belegt, dass die Dokumentation ausserhalb des Kopfes ihres Autors existiert.

Die Backup-Review-Checkliste

Diese zwölf Fragen reichen für einen ersten Architektur-Review. Jede Antwort sollte auf einen laufenden Mechanismus oder einen datierten Test zeigen können.

1. Sind die massgebenden Daten vollständig inventarisiert und nach RTO und RPO klassifiziert?
2. Erzeugt jede zustandsbehaftete Anwendung einen konsistenten Export?
3. Liegt mindestens eine Kopie in einer unabhängigen Failure Domain?
4. Kann ein kompromittiertes Produktionskonto bestehende Sicherungen löschen?
5. Sind tägliche Schreibrechte von Prune- und Retention-Rechten getrennt?
6. Ist die unveränderbare Aufbewahrung technisch erzwungen und regelmässig geprüft?
7. Liegen Verschlüsselungs- und Recovery-Schlüssel ausserhalb des gesicherten Systems?
8. Erzeugt die Retention brauchbare Recovery Points über mehrere Zeithorizonte?
9. Alarmiert das Monitoring bei einem ausbleibenden Lauf und nicht nur bei einem gemeldeten Fehler?
10. Wird jede wichtige Datenklasse regelmässig isoliert restauriert und fachlich geprüft?
11. Umgeht ein Restore-Test den lokalen Pfad und liest tatsächlich aus der Offsite-Kopie?
12. Wurde der Verlust des Backup-Hosts mit Runbook, Schlüsseln und gemessener Dauer geprobt?

Wer bei einer Frage nur auf eine Konfigurationsdatei zeigen kann, hat eine Absicht. Wer auf einen grünen Timer zeigt, hat einen gestarteten Prozess. Erst ein datierter Restore liefert den Beleg.

Von der Blaupause in den Betrieb

Diese Architektur schreibt kein Produkt vor. Borg, Restic, ZFS und ein Object Store sind mögliche Bausteine. Andere Werkzeuge können dieselben Eigenschaften herstellen. Entscheidend bleiben die Grenzen zwischen den Identitäten, die Semantik der Daten und der Weg zurück.

Im zweiten Teil zeigen wir, wie wir diese Blaupause auf einer dedizierten Backup-VM umgesetzt haben: drei Schutzklassen, getrennte SSH- und Cloud-Credentials, lokale und externe Retention, systemd-Timer, Heartbeats und anwendungsspezifische Restore-Tests. Dort gehört auch hin, was der erste Entwurf falsch eingeschätzt hat und welche Grenzen bewusst offenbleiben.

Teil 2: Vom Backup zum Restore: Wie squibble Wiederherstellbarkeit betreibt