„Haben Sie ein Backup?“ Diese Frage beantwortet fast jeder Betrieb mit Ja. Die Fragebögen, die gerade über die NIS2-Lieferkette kommen, fragen aber anders: Wo liegen die Kopien? Kann ein Angreifer sie löschen? Wann wurde zuletzt zurückgespielt? Spätestens da wird es bei vielen still.
Eine gute Richtschnur, um diese Fragen sauber beantworten zu können, ist die 3-2-1-1-0-Regel. In diesem Beitrag gehe ich sie Punkt für Punkt durch: was jede Zahl bedeutet, wie das in einem Betrieb mit fünf oder fünfzehn Arbeitsplätzen aussieht und was du davon ohne großen Aufwand umsetzen kannst.
Was NIS2 zum Backup sagt, und was nicht
Das NIS2-Umsetzungsgesetz verlangt von betroffenen Einrichtungen unter anderem Maßnahmen zur Aufrechterhaltung des Betriebs, „wie Backup-Management und Wiederherstellung nach einem Notfall“ (§ 30 BSIG). Wie genau das aussehen muss, steht dort nicht. Das Gesetz ist bewusst technikneutral und spricht vom „Stand der Technik“.
Die 3-2-1-1-0-Regel steht also in keinem Gesetz. Sie ist aber das, was man heute unter Stand der Technik bei der Datensicherung versteht, und genau daran messen dich Auftraggeber und Versicherer. Wenn du sie erfüllst, kannst du jede Backup-Frage in einem Fragebogen mit einem Satz beantworten.
Ob du selbst unter NIS2 fällst oder nur über deine Kunden davon betroffen bist, habe ich in NIS2 betrifft dich vielleicht, ohne dass du betroffen bist aufgeschrieben. Für das Backup spielt es keine Rolle: Die Anforderungen sind dieselben.
Warum das alte 3-2-1 nicht mehr reicht
Die klassische Regel lautete 3-2-1: drei Kopien, zwei Medien, eine außer Haus. Sie stammt aus einer Zeit, in der Festplatten kaputtgingen und Büros abbrannten. Gegen beides hilft sie nach wie vor.
Gegen den heute häufigsten Grund für einen Totalverlust hilft sie nicht: Ransomware. Wer sich in ein Netzwerk eingeschlichen hat, sucht zuerst das Backup. Das NAS ist im Netz, die Zugangsdaten liegen oft auf demselben Server, die Cloud-Sicherung läuft mit einem Konto, das auch löschen darf. Erst wenn alle Sicherungen verschlüsselt oder gelöscht sind, schlagen die Angreifer zu. Dann helfen drei Kopien nichts, wenn alle drei erreichbar waren.
Darum die zwei zusätzlichen Ziffern: 1 Kopie, die niemand ändern kann, und 0 Fehler, also der Nachweis, dass sich die Sicherung auch zurückspielen lässt.
Die Regel im Einzelnen
3 Kopien
Das Original plus zwei Sicherungen. Wichtig ist, was als Kopie zählt:
- Kein Backup ist ein RAID im Server oder NAS. Das schützt vor einer defekten Platte, aber nicht vor gelöschten oder verschlüsselten Dateien. Die werden auf alle Platten gleichzeitig geschrieben.
- Kein Backup ist ein synchronisierter Ordner (OneDrive, Dropbox, Nextcloud). Wird die Datei lokal verschlüsselt, wird die verschlüsselte Fassung brav in die Cloud übertragen.
- Ein Backup ist eine Kopie, die zu einem festen Zeitpunkt gezogen wurde und von dort aus nicht mehr automatisch mit dem Original mitläuft. Am besten mit mehreren Ständen: gestern, letzte Woche, letzter Monat.
2 verschiedene Medien
Die beiden Sicherungen sollen nicht auf derselben Art Speicher liegen, damit ein Fehler nicht beide trifft. Typische Paare im kleinen Betrieb:
- NAS im Büro und Cloud-Speicher
- NAS und wechselnde USB-Festplatten
- Server-Snapshots und Cloud-Speicher
Zwei Ordner auf demselben NAS sind ein Medium, auch wenn sie unterschiedlich heißen.
1 Kopie in einem anderen Brandabschnitt
Eine Sicherung muss einen Brand, einen Wasserschaden oder einen Einbruch im Büro überstehen. Ein „anderer Brandabschnitt“ ist baulich vom Serverraum getrennt, so dass ein Feuer nicht beides erreicht. Im kleinen Betrieb heißt das praktisch: außer Haus. Entweder in einem Rechenzentrum (Cloud-Speicher in Deutschland oder der EU) oder als Festplatte, die regelmäßig mit nach Hause genommen wird.
Das NAS im Keller unter dem Büro ist kein anderer Brandabschnitt. Ein Tresor im selben Raum auch nicht, die meisten Dokumententresore schützen Papier, aber keine Festplatte vor der Hitze.
1 unveränderliche Kopie
Das ist der Punkt, der heute den Unterschied macht. Eine Kopie muss so gespeichert sein, dass niemand sie ändern oder löschen kann, auch nicht mit den Admin-Zugangsdaten. Denn genau die hat ein Angreifer, wenn er so weit gekommen ist.
Dafür gibt es zwei Wege:
- Offline (Air Gap): Eine USB-Festplatte, die nach der Sicherung abgesteckt und mitgenommen wird. Was nicht angeschlossen ist, kann nicht verschlüsselt werden. Einfach und günstig, braucht aber Disziplin: Zwei Platten im Wechsel, eine ist immer außer Haus.
- Unveränderlich (Immutable): Der Speicher selbst verweigert das Löschen, für eine festgelegte Zeit. Bei Cloud-Speicher heißt das meist Object Lock, bei NAS-Systemen unveränderliche Snapshots (z. B. Synology ab DSM 7.2). Die Backup-Software muss das unterstützen.
Wichtig dabei: Die Sperre muss beim Speicher liegen, nicht bei der Software. Eine Einstellung „Backups nicht löschen“ im Backup-Programm hilft nichts, wenn der Angreifer das Programm einfach umkonfiguriert.
0 Fehler
Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Die Null steht für zwei Dinge:
- Jede Sicherung wird automatisch geprüft. Ist sie durchgelaufen? Sind die Daten lesbar? Und vor allem: Fällt es auf, wenn sie nicht läuft? Das häufigste Backup-Problem ist kein Defekt, sondern eine Sicherung, die seit Wochen stillschweigend ausfällt.
- Die Wiederherstellung wird regelmäßig getestet. Einmal im Jahr eine echte Probe: einen Ordner, ein Postfach, im Idealfall einen ganzen Server zurückspielen, auf einem Testgerät. Dauer und Ergebnis aufschreiben. Diese Notiz ist das, was im Fragebogen gefragt wird.
So sieht das im kleinen Betrieb aus
Für ein Büro mit einem Server oder NAS und zehn Arbeitsplätzen ist das eine Aufstellung, die ich oft so oder ähnlich einrichte:
| Kopie | Wo | Medium | Außer Haus | Unveränderlich |
|---|---|---|---|---|
| Original | Server / NAS im Büro | Festplatten | nein | nein |
| Sicherung 1 | zweites NAS oder USB-Platte, stündlich bis täglich | Festplatte | nein | Snapshots, wenn möglich |
| Sicherung 2 | Cloud-Speicher in Deutschland, täglich | Rechenzentrum | ja | ja, Object Lock 30 Tage |
Die erste Sicherung ist für den Alltag: Eine Mitarbeiterin hat eine Datei überschrieben, die ist in fünf Minuten wieder da. Die zweite ist für den Ernstfall: Brand, Einbruch, Ransomware. Sie ist langsamer zurückzuholen, aber sie ist da.
Wer keinen Cloud-Speicher will, ersetzt die zweite Sicherung durch zwei USB-Platten im Wochenwechsel, von denen eine immer zu Hause liegt. Das erfüllt die Regel genauso, solange der Wechsel wirklich passiert.
Und Microsoft 365? Der Papierkorb und die Aufbewahrung bei Microsoft sind kein Backup im Sinne der Regel. Gelöschte Postfächer und Dateien sind nach einer Frist endgültig weg, und ein kompromittiertes Admin-Konto kann sie auch vorher löschen. Postfächer, OneDrive und SharePoint gehören deshalb in eine eigene Sicherung außerhalb von Microsoft.
Wie ich es auf meinen eigenen Servern mache
Für die Technikinteressierten: Meine eigenen Dienste laufen auf einem Docker-Host, gesichert mit restic. Das Prinzip lässt sich auf jeden Linux-Server übertragen.
Tägliche Sicherung mit festen Ständen. Ein systemd-Timer startet nachts das Backup und räumt danach alte Stände auf: sieben tägliche, vier wöchentliche, sechs monatliche.
restic backup --host "$(hostname)" --tag daily /srv/daten /var/backups/sqlite
restic forget --host "$(hostname)" --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneDatenbanken werden vorher konsistent kopiert, statt die laufenden Dateien zu
sichern. Bei SQLite geht das im laufenden Betrieb mit sqlite3 app.db ".backup '/var/backups/sqlite/app.db.bak'", bei PostgreSQL mit pg_dump.
Automatische Prüfung. Einmal pro Woche liest restic einen Teil der gesicherten Daten zurück und prüft, ob sie unversehrt sind:
restic check --read-data-subset=5%Alarm, wenn das Backup ausbleibt. Nach jedem erfolgreichen Lauf schreibt das Skript den Zeitpunkt in eine kleine Datei, die Grafana Alloy an Prometheus weitergibt. Eine Regel meldet sich, wenn das letzte Backup älter als 26 Stunden ist:
- alert: BackupMissing
expr: time() - backup_last_success_timestamp_seconds > 26 * 3600
labels:
severity: critical
annotations:
summary: 'Seit {{ $value | humanizeDuration }} kein erfolgreiches Backup von {{ $labels.host }}'Damit fällt eine ausgefallene Sicherung am nächsten Morgen auf, nicht erst, wenn jemand eine Datei zurückhaben will. Wie das Monitoring dahinter aufgebaut ist, steht in Wer war auf meinem Server?.
Unveränderlich auch mit restic. restic selbst sperrt nichts. Der Weg ist,
den Speicher so einzurichten, dass der Server nur hinzufügen, aber nicht
löschen darf. Mit dem restic-eigenen rest-server im Modus --append-only nimmt der Speicher neue Sicherungen an, verweigert aber jedes Löschen. Das
Aufräumen alter Stände läuft dann getrennt, von einem anderen Rechner mit
eigenen Zugangsdaten. Alternativ bieten viele Speicheranbieter Snapshots des
gesamten Speichers an, die nur über deren Verwaltungsoberfläche gelöscht werden
können, nicht über den Zugang, mit dem gesichert wird.
Wiederherstellung üben. Zurückspielen in ein leeres Verzeichnis, Dateien vergleichen, Zeit notieren:
restic restore latest --host "$(hostname)" --target /tmp/restore-testWas du diese Woche tun kannst
Du musst nicht alles auf einmal umbauen. Drei Schritte bringen am meisten:
- Aufschreiben, was es gibt. Welche Daten, wo gesichert, wie oft, wie lange aufbewahrt. Oft stellt sich dabei heraus, dass es nur eine Kopie gibt, und die hängt am selben Netz wie das Original.
- Eine Kopie aus der Reichweite bringen. Entweder eine USB-Platte, die abends abgesteckt wird, oder ein Cloud-Ziel mit Object Lock. Das ist der größte Gewinn gegen Ransomware.
- Einmal zurückspielen. Einen Ordner, ein Postfach. Datum, Dauer und Ergebnis notieren. Damit hast du die Antwort, nach der jeder Fragebogen fragt.
Wenn du dabei Unterstützung willst: Ich prüfe die vorhandene Sicherung, schlage eine Aufstellung vor, die zu Größe und Budget deines Betriebs passt, richte sie ein und mache den ersten Wiederherstellungstest mit dir zusammen, inklusive der Notiz für den nächsten Fragebogen. Mehr dazu unter IT-Service für Geschäftskunden, oder schreib mir einfach.