Inhalt (5 Abschnitte)
Die richtige Frage lautet nicht „Haben Sie Backups?“: Darauf antworten alle mit Ja. Sie lautet: „Wann haben Sie zuletzt etwas wiederhergestellt, und was hindert einen Angreifer, der Ihre Server kontrolliert, daran, Ihre Backups zusammen mit dem Rest zu zerstören?“ Auf diese beiden Fragen antwortet die große Mehrheit der KMU schlecht. Hier finden Sie die 3-2-1-Regel, das, was 2026 hinzukommen muss, und die Architektur, die wir betreiben.
Die 3-2-1-Regel, und warum sie nicht mehr reicht #
Die Regel ist einfach und im Prinzip kein bisschen gealtert: 3 Kopien Ihrer Daten (die Produktion eingeschlossen), auf 2 verschiedenen Medien oder Systemen, davon 1 außer Haus. Sie schützt vor Hardwareausfällen, menschlichen Fehlern und Bränden. Aber sie wurde formuliert, bevor Ransomware zu einer Industrie wurde, und Ransomware hat etwas Grundlegendes verändert: Ihre Backups sind heute das erste Ziel, nicht die letzte Verteidigungslinie.
Ein fähiger Ransomware-Betreiber verschlüsselt Ihre Server nicht an dem Tag, an dem er eindringt. Er erkundet, sammelt Zugangsdaten, findet die Backups und zerstört oder verschlüsselt sie zuerst. Kennt Ihr Produktionsserver das Passwort des Backup-NAS, sind Ihre drei Kopien in Wahrheit nur eine. Daher die beiden modernen Ergänzungen, manchmal als „3-2-1-1-0“ zusammengefasst: 1 unveränderliche oder Offline-Kopie und 0 Fehler bei der Wiederherstellung, also tatsächlich getestete Wiederherstellungen.
Unveränderlichkeit: eine Kopie, die niemand verändern kann, nicht einmal Sie selbst #
Ein unveränderliches Backup ist eine Kopie, die sich während ihrer Aufbewahrungsfrist mit keinen kompromittierten Zugangsdaten verändern lässt. Konkret baut man das mit zwei Architekturprinzipien:
- Der Backup-Server vertraut den Maschinen nicht, die er sichert. Jede Maschine legt ihre Backups mit reinem Schreibrecht ab (append-only): sie kann hinzufügen, aber nie löschen oder ändern. Ein Angreifer, der die Produktion kontrolliert, kann die Historie also nicht zerstören: Löschungen und Aufbewahrung werden auf der Seite des Backup-Servers gesteuert, mit anderen Zugangsdaten.
- *Die externe Kopie entsteht im Pull-Modus, nicht im Push-Modus. Der entfernte Standort holt* die Backups selbst ab, mit eigenen Lesezugriffen. Die Produktionskette besitzt keinerlei Zugangsdaten zur externen Kopie: sie weiß nicht einmal, dass es sie gibt. Wer die Produktion kompromittiert, hat keinen Weg zur letzten Verteidigungslinie.
Der Test ist einfach: Kann man von einem kompromittierten Produktionsserver aus, mit all seinen Geheimnissen, die Backups zerstören? Lautet die Antwort nicht nachweisbar „nein“, haben Sie keine Backups: Sie haben vorläufige Kopien.
Unsere Architektur in Produktion #
So setzen sich diese Prinzipien auf der Infrastruktur um, die wir für unsere Kunden betreiben, mit Proxmox Backup Server, dessen Deduplizierung und Aufbewahrung wir bereits ausführlich beschrieben haben:
- Tägliche Backups jeder Maschine auf einen eigenen Backup-Server außerhalb des Produktionsclusters, im Append-only-Modus: Die Produktion schreibt, sie löscht nichts.
- Ein abgeschotteter Bereich pro Kunde (Namespaces): Jeder Mandant hat seine eigenen Zugänge, niemand sieht die Daten der anderen, und der Schadensradius kompromittierter Zugangsdaten bleibt begrenzt.
- Gemessene Deduplizierung von 7,4× auf unserer Serverflotte: Wochen an Historie aufzubewahren, kostet nur einen Bruchteil des Rohvolumens, sodass lange Aufbewahrung keine finanzielle Abwägung mehr ist.
- Externer Spiegel im Pull-Modus an einem geografisch getrennten Standort, mit eigenen, rein lesenden Zugangsdaten und unabhängiger Aufbewahrung.
- Clientseitige Verschlüsselung für die Backups, die wir für Dritte hosten: Wir speichern verschlüsselte Blöcke, deren Schlüssel wir nicht besitzen.
Ein ungetestetes Backup gibt es nicht #
Die „0“ in 3-2-1-1-0 wird am häufigsten vernachlässigt. Backups scheitern still: ein Job, der seit Wochen abstürzt, ein volles Volume, eine im laufenden Betrieb exportierte und inkonsistente Datenbank. Der einzige Beweis für ein Backup ist eine echte Wiederherstellung: komplette Maschine auf einem leeren Host wiederaufgebaut, Datenbank eingespielt, Anwendung gestartet und geprüft. Wir tun das regelmäßig auf unserer eigenen Infrastruktur, und der erste Test bringt immer etwas zutage: Unserer hat Details im Ablauf offengelegt, die keine theoretische Dokumentation erfasst hätte.
Prüfen Sie Ihre Backups mit fünf Fragen #
- Kann man von einem kompromittierten Produktionsserver aus die Backups löschen oder verschlüsseln? (append-only, getrennte Zugangsdaten)
- Wird die externe Kopie per Push von der Produktion aus beschickt oder per Pull vom entfernten Standort aus abgeholt?
- Wann fand die letzte erfolgreiche vollständige Wiederherstellung statt, und wer hat sie festgestellt?
- Wer wird alarmiert, wenn ein Backup-Job fehlschlägt, und wurde der Alarm getestet, indem ein Job absichtlich abgebrochen wurde?
- Deckt Ihre Aufbewahrung eine spät entdeckte Ransomware ab? (Ein Angreifer kann wochenlang warten, bevor er verschlüsselt.)
Diese Architektur ist in unserem souveränen Hosting und unseren Managed Services enthalten: tägliche Backups, unveränderliche Kopie, externe Kopie und Wiederherstellungstests. Wenn Sie die fünf Fragen oben auf Ihre eigene Umgebung anwenden möchten, können wir das gemeinsam tun.
