3-2-1-Backup-Regel für Server: So setzen KMU sie um und machen Sicherungen widerstandsfähig gegen Ransomware

Die 3-2-1-Backup-Regel besagt: Halten Sie drei Kopien Ihrer Daten vor, auf zwei unterschiedlichen Speichersystemen, davon eine an einem anderen Standort. Für Server in KMU heißt das konkret: das Produktivsystem, eine Sicherung auf einem getrennten Backup-System und eine weitere Kopie außer Haus, die ein Angreifer mit den Zugangsdaten des Produktivservers weder ändern noch löschen kann. Genau dieser letzte Punkt entscheidet heute darüber, ob die Regel im Ernstfall trägt.

Dieser Beitrag zeigt, was als Kopie zählt und was nicht, wie Sie die Regel Schritt für Schritt auf Ihre Server übertragen und an welchen Stellen gut gemeinte Backup-Konzepte in der Praxis scheitern.

Was die 3-2-1-Backup-Regel genau bedeutet

Die drei Zahlen stehen für drei unabhängige Anforderungen. Jede schützt gegen eine andere Art von Schaden.

• 3 Kopien: Die Originaldaten plus zwei Sicherungen. Fällt eine Sicherung aus oder ist beschädigt, bleibt eine zweite.
• 2 Speichersysteme: Die Kopien liegen nicht auf demselben Speicher, derselben Hardware oder derselben Plattform. Das schützt gegen Defekte, Firmware-Fehler und Fehlkonfigurationen, die ein ganzes System betreffen.
• 1 Kopie extern: Mindestens eine Kopie liegt räumlich und organisatorisch getrennt. Das schützt gegen Brand, Wasserschaden, Diebstahl und den Totalausfall eines Standorts.

Ursprünglich dachte man bei den zwei Medien an Festplatte und Band. Heute ist die sinnvollere Lesart: zwei Systeme, die nicht gemeinsam ausfallen können und nicht gemeinsam verwaltet werden.

Warum 3-2-1 allein heute nicht mehr reicht

Die klassische Regel wurde für Hardwaredefekte und Katastrophen entworfen. Ransomware verhält sich anders: Angreifer suchen gezielt nach Backup-Systemen und löschen oder verschlüsseln sie, bevor sie die Produktivdaten angreifen. Liegen alle drei Kopien im Zugriff derselben Zugangsdaten, nützt die beste Verteilung nichts.

Deshalb hat sich die Erweiterung zu 3-2-1-1-0 etabliert:

• 1 Kopie ist unveränderlich oder offline, also für einen festgelegten Zeitraum nicht lösch- oder überschreibbar.
• 0 Fehler bei der Prüfung: Sicherungen werden regelmäßig verifiziert und testweise zurückgespielt.

Entscheidend ist nicht, wie viele Kopien existieren, sondern wie viele davon ein Angreifer mit den Rechten Ihres Produktivservers nicht erreichen kann. Wenn Sie nur eine Frage zu Ihrem Backup-Konzept stellen, dann diese.

Was als Kopie zählt und was nicht

In vielen Bestandsaufnahmen zeigt sich, dass vermeintliche Kopien keine sind. Die folgenden Mechanismen sind nützlich, ersetzen aber keine Sicherung im Sinne der Regel:

• RAID und redundanter Speicher: Schützt gegen den Ausfall einzelner Datenträger. Ein gelöschtes oder verschlüsseltes Verzeichnis ist auf allen Spiegeln gleichzeitig weg.
• Snapshots auf demselben Speicher: Schnell und praktisch für Rücksprünge nach einem fehlgeschlagenen Update. Sie liegen aber auf demselben System und verschwinden mit ihm. Wer Administratorrechte auf dem Hypervisor hat, kann sie löschen.
• Replikation: Eine Datenbankreplik oder ein gespiegelter Server übernimmt jeden Fehler in Sekunden, auch ein versehentliches DROP TABLE.
• Synchronisation: Werkzeuge, die Ordner abgleichen, synchronisieren auch Löschungen und verschlüsselte Dateien.

Als Kopie zählt eine Sicherung erst, wenn sie versioniert ist, also ältere Stände vorhält, und unabhängig vom Quellsystem ausfallen oder kompromittiert werden kann. Ein Snapshot, der zusätzlich auf ein anderes System übertragen wird, kann diese Bedingung erfüllen.

Die 3-2-1-Backup-Regel für Server umsetzen

Die folgenden Schritte funktionieren unabhängig davon, ob Sie virtuelle Maschinen, einzelne Linux-Server oder gehostete Anwendungen sichern.

1. Daten inventarisieren. Listen Sie je Server auf, was gesichert werden muss: Konfiguration unter /etc, Anwendungsdaten, Uploads, Datenbanken, Zertifikate und Secrets. Notieren Sie, was sich aus Code oder Automatisierung neu erzeugen lässt und was nicht.
2. Datenbanken konsistent sichern. Dateien einer laufenden Datenbank zu kopieren ergibt oft unbrauchbare Sicherungen. Erzeugen Sie vorher einen Dump oder nutzen Sie die Sicherungswerkzeuge der Datenbank.
3. Erste Kopie auf ein getrenntes Backup-System. Das Backup-System läuft auf eigener Hardware oder eigener Plattform, mit eigenen Zugangsdaten und ohne Anmeldung vom Produktivserver aus.
4. Zweite Kopie an einen anderen Standort. Ein zweites Rechenzentrum, ein anderer Anbieter oder ein externer Backup-Dienst. Wichtig ist, dass dort eine andere Verwaltung und andere Zugangsdaten greifen.
5. Unveränderlichkeit einrichten. Mindestens eine Kopie wird im Append-only-Modus geschrieben oder mit einer Aufbewahrungssperre versehen, sodass sie innerhalb der Frist nicht gelöscht werden kann.
6. Aufbewahrung festlegen. Ein gängiges Schema: tägliche Stände für zwei Wochen, wöchentliche für zwei Monate, monatliche für ein Jahr. Passen Sie die Fristen an Ihre rechtlichen Pflichten und daran an, wie spät Sie einen Schaden typischerweise bemerken.
7. Prüfen und zurückspielen. Automatische Integritätsprüfungen und regelmäßige Rücksicherungen auf ein Testsystem. Wie Sie Wiederherstellungsziele und Tests planen, beschreibt unser Beitrag Backup ist nicht Restore: RPO, RTO und Wiederherstellungstests.
8. Überwachen und dokumentieren. Ein fehlgeschlagener Backup-Job muss einen Alarm auslösen, kein stilles Logfile. Dokumentieren Sie, wer im Notfall wie an welche Kopie kommt, auch wenn die übliche Infrastruktur nicht verfügbar ist.

Beispiel: Append-only-Sicherung mit restic

Das quelloffene Werkzeug restic kann zusammen mit dem rest-server so betrieben werden, dass der Produktivserver neue Sicherungen schreiben, aber keine alten löschen darf:

# Auf dem Backup-System: rest-server im Append-only-Modus
rest-server --path /srv/restic --append-only --private-repos

# Auf dem Produktivserver: Repository anlegen und sichern
restic -r rest:https://server01@backup.example.de:8000/server01 init
restic -r rest:https://server01@backup.example.de:8000/server01 \
  backup /etc /var/www /srv/dumps --exclude-caches

# Regelmäßig einen Teil der Daten tatsächlich lesen und prüfen
restic -r rest:https://server01@backup.example.de:8000/server01 \
  check --read-data-subset=5%

Das Aufräumen alter Stände mit restic forget --prune erfolgt dann ausschließlich auf dem Backup-System selbst, mit Zugangsdaten, die auf dem Produktivserver nicht hinterlegt sind.

Pull statt Push: wo die meisten Konzepte scheitern

Der häufigste Konstruktionsfehler ist kein technischer, sondern einer der Rechtevergabe. Wenn der Produktivserver seine Sicherungen per Push auf das Backup-Ziel schiebt und dafür Zugangsdaten mit Löschrechten gespeichert hat, kann jeder, der den Server übernimmt, auch die Sicherungen vernichten.

Zwei Muster lösen das Problem:

• Pull-Prinzip: Das Backup-System holt die Daten aktiv ab. Der Produktivserver kennt das Backup-System nicht und hat keine Zugangsdaten dafür. Proxmox Backup Server etwa kann Datastores per Sync-Job von einem entfernten System ziehen, sodass die externe Kopie vom Primärsystem aus nicht erreichbar ist.
• Push mit eingeschränkten Rechten: Der Produktivserver darf schreiben, aber nicht löschen oder überschreiben, wie im restic-Beispiel oben.

Achten Sie auch darauf, wo die Zugangsdaten für das Backup-System liegen. Ein Passwortmanager, der vom kompromittierten Administratorkonto aus erreichbar ist, hebelt die Trennung wieder aus. Netzseitig gehört das Backup-System in ein eigenes Segment, das nur die notwendigen Verbindungen zulässt.

Ein Szenario aus dem Mittelstand

Ein typisches KMU betreibt einen Webserver mit Shop, einen Server für interne Anwendungen und eine Dateiablage. Die Ausgangslage sieht oft so aus: nächtliche Snapshots auf dem Hypervisor, dazu ein Skript, das Dateien auf ein NAS im Büro kopiert. Das NAS ist per Netzlaufwerk eingebunden.

Gemessen an der Regel fehlen hier zwei Dinge. Die Snapshots liegen auf demselben System wie die Server, und das NAS ist für jeden erreichbar, der einen Büro-PC übernimmt. Eine externe Kopie gibt es nicht.

Eine tragfähige Umstellung sieht so aus: Die Snapshots bleiben für schnelle Rücksprünge. Zusätzlich sichert ein getrenntes Backup-System im Rechenzentrum alle drei Server versioniert, ohne dass die Server Löschrechte haben. Ein zweites Backup-System an einem anderen Standort zieht die Daten per Sync-Job ab. Das Büro-NAS wird nicht mehr als Netzlaufwerk eingebunden. Damit erfüllt das Setup 3-2-1, und durch die fehlenden Löschrechte auch die zusätzliche unveränderliche Kopie.

Prüfliste für Ihr Backup-Konzept

• Gibt es für jeden Server mindestens zwei Sicherungen außerhalb des Produktivsystems?
• Liegen diese Sicherungen auf unterschiedlichen Systemen mit getrennter Verwaltung?
• Befindet sich mindestens eine Kopie an einem anderen Standort?
• Kann der Produktivserver seine eigenen Sicherungen löschen? Wenn ja, ist das zu ändern.
• Ist mindestens eine Kopie unveränderlich oder offline?
• Werden Datenbanken konsistent gesichert und nicht nur als laufende Dateien kopiert?
• Reicht die Aufbewahrungsdauer, um auch Schäden zu beheben, die erst nach Wochen auffallen?
• Löst ein fehlgeschlagener Job einen Alarm aus, der von einer Person bearbeitet wird?
• Wurde in den letzten Monaten eine vollständige Rücksicherung auf ein Testsystem durchgeführt?
• Ist dokumentiert, wie Sie an die Sicherungen kommen, wenn Ihre übliche Infrastruktur ausgefallen ist?

Selbst betreiben oder als Dienst nutzen

Die Regel lässt sich vollständig in Eigenregie umsetzen. Der Aufwand liegt weniger in der Einrichtung als im Dauerbetrieb: Jobs überwachen, Aufbewahrung pflegen, Software aktualisieren, Rücksicherungen testen und die Trennung der Zugangsdaten auch bei Personalwechseln aufrechterhalten.

Wer diesen Teil abgeben möchte, kann einzelne Bausteine extern beziehen. NETARO bietet zum Beispiel unter der Marke StorageLayer fertige Proxmox-Backup-Server als externes Sicherungsziel an, die sich als zusätzliche Kopie an einem eigenen Standort nutzen lassen. Bei Managed Hosting mit geprüfter Rücksicherung übernimmt NETARO Backups, Überwachung und Updates für die betriebenen Server in Frankfurt. Ebenso möglich ist eine Kombination mit einem anderen Anbieter oder einem eigenen zweiten Standort. Wichtig ist allein, dass die Kopien tatsächlich unabhängig voneinander sind.

FAQ

Zählt das Original bei der 3-2-1-Backup-Regel als eine der drei Kopien?

Ja. Die drei Kopien umfassen die Produktivdaten und zwei Sicherungen. Da das Original aber bei einem Angriff oder Defekt als Erstes betroffen ist, sollten Sie in der Planung von zwei unabhängigen Sicherungen ausgehen.

Reicht ein Cloud-Backup als externe Kopie?

Ein Cloud-Speicher kann die externe Kopie sein, wenn er versioniert arbeitet, eine Löschsperre bietet und mit eigenen Zugangsdaten verwaltet wird. Ein synchronisierter Cloud-Ordner erfüllt die Anforderung nicht, weil er Löschungen und verschlüsselte Dateien übernimmt. Bei personenbezogenen Daten brauchen Sie zudem einen Auftragsverarbeitungsvertrag mit dem Anbieter.

Sind Snapshots ein Ersatz für Backups?

Nein. Snapshots liegen auf demselben Speichersystem wie die Originaldaten und fallen mit ihm aus. Sie eignen sich für schnelle Rücksprünge nach Updates. Zu einer Sicherung im Sinne der Regel werden sie erst, wenn sie auf ein getrenntes System übertragen werden.

Wie oft sollte man Backups testen?

Automatische Integritätsprüfungen sollten nach jedem oder zumindest regelmäßig nach mehreren Sicherungsläufen erfolgen. Vollständige Rücksicherungen auf ein Testsystem sind mindestens nach jeder größeren Änderung an System oder Backup-Konfiguration sinnvoll und darüber hinaus in festen Abständen, etwa quartalsweise.