Backups nach der 3-2-1-Regel: Sicherungen, die im Ernstfall tragen

Die 3-2-1-Regel besagt: drei Kopien Ihrer Daten, auf zwei verschiedenen Speichermedien, davon eine an einem anderen Ort. Fast jedes Unternehmen macht Backups. Deutlich weniger Unternehmen wissen, ob sie sich im Ernstfall auch zurückspielen lassen – und wie lange das dauert. Spätestens seit Ransomware gezielt nach Sicherungen sucht, um sie vor der Verschlüsselung der Produktivsysteme zu zerstören, reicht ein nächtlicher Kopierjob auf ein Netzlaufwerk nicht mehr aus.

Dieser Leitfaden erklärt die 3-2-1-Regel, ihre moderne Erweiterung, die Rolle unveränderlicher Kopien und drei bewährte Open-Source-Werkzeuge.

Was besagt die 3-2-1-Regel?

Die Faustregel ist alt, aber nach wie vor die beste Grundlage:

• 3 Kopien Ihrer Daten: das Original plus zwei Sicherungen.
• 2 verschiedene Speichermedien oder -systeme, damit ein einzelner Defekt – etwa ein fehlerhafter Controller oder eine Firmware-Panne – nicht alle Kopien trifft.
• 1 Kopie an einem anderen Ort, damit Brand, Wasserschaden oder Diebstahl am Hauptstandort nicht alles vernichten.

Der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik (BSI) verlangt im Baustein CON.3 „Datensicherungskonzept“ im Kern dasselbe: Speichermedien für die Datensicherung müssen räumlich getrennt von den gesicherten Systemen aufbewahrt werden, möglichst in einem anderen Brandabschnitt (Anforderung CON.3.A12).

Die Erweiterung: Was bedeutet 3-2-1-1-0?

In der Branche hat sich eine erweiterte Fassung etabliert, die auf die heutige Bedrohungslage antwortet:

• +1 Kopie offline oder unveränderlich (immutable): Mindestens eine Sicherung darf für einen Angreifer – auch mit Administratorrechten im Produktivnetz – nicht löschbar oder überschreibbar sein.
• 0 Fehler bei der Wiederherstellungsprüfung: Sicherungen werden regelmäßig verifiziert und testweise zurückgespielt.

Auch hier deckt sich die Logik mit dem BSI-Baustein: CON.3.A14 fordert, dass Datensicherungen nicht absichtlich oder unbeabsichtigt überschrieben werden können und dass Sicherungssysteme nur für autorisierte Vorgänge schreibend auf die Sicherungsmedien zugreifen. CON.3.A15 verlangt, regelmäßig zu testen, ob gesicherte Daten „einwandfrei und in angemessener Zeit“ zurückgespielt werden können. Der Baustein beschreibt Ransomware ausdrücklich als Gefährdung, auch für dauerhaft erreichbare Sicherungen.

Warum „unveränderlich“ der entscheidende Punkt ist

Ein Angreifer, der Ihr Netz übernommen hat, nutzt dieselben Zugangsdaten und Werkzeuge wie Ihre Administratoren. Ist der Backup-Server per Windows-Freigabe eingebunden oder mit demselben Domänenkonto verwaltet, ist er Teil der Angriffsfläche. Drei Ansätze schaffen Abhilfe:

Offline-Medien

Bänder oder Wechselfestplatten, die nach der Sicherung physisch getrennt werden, sind die klassische und nach wie vor wirksamste Lösung. Nachteil: Sie erfordern manuelle Disziplin und eine sichere Lagerung.

Append-only-Repositories

Der Sicherungsserver erlaubt dem Client nur, neue Daten hinzuzufügen – nicht, bestehende zu löschen oder zu verändern. Ein kompromittierter Client kann die Historie dann nicht zerstören. Aufräumen (Pruning) erfolgt ausschließlich von einer vertrauenswürdigen Stelle aus.

Object Lock

S3-kompatible Objektspeicher bieten häufig eine Objektsperre (Object Lock): Daten sind für einen festgelegten Zeitraum gegen Löschen geschützt, im strengen Modus auch gegen den Kontoinhaber. Prüfen Sie beim Anbieter, welche Modi unterstützt werden und wer die Sperre aufheben kann.

Für alle drei gilt: Getrennte Zugangsdaten, getrennte Administration, idealerweise eine andere Authentifizierungsquelle als Ihr Active Directory. Ein Backup-System, auf das man sich mit dem Domänen-Admin-Konto anmelden kann, ist kein sicheres Backup-System.

Drei Werkzeuge im Überblick

Proxmox Backup Server

Der Proxmox Backup Server (PBS) ist das Gegenstück zu Proxmox VE, sichert aber auch beliebige Linux-Hosts über einen eigenen Client. Er arbeitet inkrementell und dedupliziert blockweise; Verschlüsselung erfolgt auf Wunsch schon auf dem Client. Verifikationsjobs prüfen gesicherte Daten in regelmäßigen Abständen auf Integrität. Über Sync-Jobs lassen sich Datenbestände auf einen zweiten PBS an einem anderen Standort spiegeln, zudem unterstützt PBS Band-Sicherungen. Seit Version 4.2 (April 2026) werden S3-kompatible Objektspeicher offiziell als Speicher-Backend unterstützt.

Ein bewährtes Muster: PBS am Hauptstandort, ein zweiter PBS an einem anderen Ort, der die Daten per Pull-Sync selbst abholt. So hat der Hauptstandort keine Schreibrechte auf die Zweitkopie. Wer gerade von VMware wechselt, findet die Einordnung in unserem Leitfaden Proxmox statt VMware.

restic

restic ist ein in Go geschriebenes Kommandozeilenwerkzeug, das Sicherungen grundsätzlich verschlüsselt und dedupliziert. Es unterstützt lokale Verzeichnisse, SFTP, S3-kompatible Speicher und weitere Ziele. Der zugehörige rest-server bietet einen Append-only-Modus, der neue Sicherungen erlaubt, aber das Löschen und Verändern bestehender verhindert. Wichtig: Das Aufräumen alter Snapshots (forget/prune) sollte dann nicht automatisch vom gesicherten Host aus laufen.

BorgBackup

Borg ist auf Linux-Servern verbreitet und für seine effiziente Deduplizierung bekannt. Ein Repository lässt sich in den Append-only-Modus versetzen, etwa serverseitig per borg serve --append-only für einen bestimmten SSH-Schlüssel. Die Dokumentation weist auf einen wichtigen Haken hin: prune und delete vom Client markieren Daten nur als gelöscht; ein späterer normaler Schreibvorgang, etwa ein Aufräumjob vom Admin-Rechner, entfernt sie endgültig. Automatisierte Prune-Jobs können den Schutz also aushebeln. Prüfen Sie vor solchen Vorgängen das Repository, zum Beispiel mit borg check --verify-data.

Restore-Tests: der Teil, der meistens fehlt

Eine Sicherung, die nie zurückgespielt wurde, ist eine Hypothese. Planen Sie Wiederherstellungstests fest ein:

1. Monatlich: Einzelne Dateien und eine ausgewählte VM zurückspielen, Funktion prüfen.
2. Quartalsweise: Eine komplette Anwendung inklusive Datenbank in einer isolierten Umgebung wiederherstellen.
3. Jährlich: Ein Szenario „Standort verloren“ durchspielen – nur mit der externen Kopie und der Dokumentation.

Messen Sie dabei die Zeit. Zwei Kennzahlen gehören in jedes Sicherungskonzept:

• RPO (Recovery Point Objective): Wie viel Datenverlust ist tolerierbar? Daraus folgt die Sicherungsfrequenz.
• RTO (Recovery Time Objective): Wie lange darf die Wiederherstellung dauern? Daraus folgen Bandbreite, Hardware und Reihenfolge.

Beispiel: Angenommen, Ihre Warenwirtschaft darf höchstens vier Stunden Daten verlieren und muss nach einem Tag wieder laufen. Dann genügt eine nächtliche Sicherung nicht; Sie brauchen zusätzlich häufigere Datenbank-Sicherungen – und einen Test, der belegt, dass ein Restore der gesamten Datenmenge innerhalb eines Tages tatsächlich gelingt.

Was in das Sicherungskonzept gehört

Der BSI-Baustein CON.3 nennt als Basis-Anforderungen unter anderem die Erhebung der Einflussfaktoren, festgelegte Verfahrensweisen, Datensicherungspläne und regelmäßige Sicherungen. In der Praxis sollte Ihr Konzept mindestens beantworten:

• Welche Daten und Systeme werden gesichert – und welche bewusst nicht?
• Wie oft, wie lange aufbewahrt, wohin?
• Wer ist verantwortlich, wer wird bei Fehlern alarmiert?
• Wo liegen Schlüssel für verschlüsselte Sicherungen? (Ohne Schlüssel ist das beste Backup wertlos – bewahren Sie ihn getrennt und ebenfalls offline auf.)
• Wie läuft eine Wiederherstellung ab, Schritt für Schritt, auch wenn der übliche Administrator nicht erreichbar ist?

Für Unternehmen, die unter die NIS-2-Regulierung fallen, ist ein funktionierendes Backup-Management zudem Teil der gesetzlich geforderten Risikomanagementmaßnahmen. Details dazu in unserer Analyse der NIS-2-Pflichten für die Geschäftsleitung.

Nächste Schritte

• Bestandsaufnahme: Welche Daten, wo, mit welcher Sicherung?
• RPO und RTO je System mit den Fachbereichen festlegen
• Mindestens eine Kopie außer Haus, eine offline oder unveränderlich
• Backup-Systeme vom Produktiv-Verzeichnisdienst trennen, eigene Zugangsdaten, MFA
• Verifikation automatisieren, Alarmierung bei Fehlern einrichten
• Verschlüsselungsschlüssel getrennt und offline hinterlegen
• Restore-Tests fest im Kalender verankern und protokollieren
• Wiederherstellungsanleitung schreiben – für jemanden, der das System nicht kennt