Ein Backup-Job kann jeden Abend erfolgreich durchlaufen und trotzdem im entscheidenden Moment wertlos sein. Denn eine Datei oder VM zu sichern ist nur ein technischer Vorgang. Eine Backup-Strategie beantwortet eine andere Frage: Wie wird das Unternehmen nach Datenverlust, Hardwareausfall oder Cyberangriff tatsächlich wieder arbeitsfähig?
In diesem Beitrag
Ein erfolgreiches Backup ist noch kein erfolgreiches Recovery.
In der Praxis wird Backup häufig über Jobs, Laufzeiten und grüne Häkchen bewertet. Das ist verständlich: Ein Job ist sichtbar, messbar und lässt sich überwachen. Für den Ernstfall sagt das aber nur begrenzt etwas aus.
Eine belastbare Backup-Strategie betrachtet nicht nur die Sicherung selbst, sondern den vollständigen Wiederherstellungsweg. Welche Systeme sind geschäftskritisch? In welcher Reihenfolge müssen sie zurückkommen? Welche Abhängigkeiten bestehen zwischen Active Directory, Datenbanken, Applikationen, Fileservern und Netzwerkdiensten? Wer entscheidet im Notfall, was zuerst wiederhergestellt wird?
Genau an dieser Stelle trennt sich für mich ein funktionierendes Backup von einer funktionierenden Strategie. Die Technik ist wichtig. Entscheidend ist aber, ob aus gesicherten Daten wieder ein arbeitsfähiger Betrieb wird.
RPO und RTO: Zwei Werte, die vor dem ersten Job feststehen sollten.
Bevor Aufbewahrung, Repository oder Cloud-Storage geplant werden, müssen zwei Anforderungen geklärt sein: RPO und RTO.
- RPO – Recovery Point Objective: Wie viel Datenverlust ist maximal akzeptabel? Eine Stunde? Ein Arbeitstag? Nur wenige Minuten?
- RTO – Recovery Time Objective: Wie lange darf ein Dienst ausfallen, bis er wieder verfügbar sein muss?
Das Bundesamt für Sicherheit in der Informationstechnik nennt genau diese beiden Größen als wesentliche Anforderungen einer Datensicherungsstrategie: Das Backup muss das geforderte RPO erfüllen und die Wiederherstellung innerhalb des definierten RTO möglich sein.[1]
Ein tägliches Backup kann also technisch sauber laufen und fachlich trotzdem falsch dimensioniert sein. Wenn ein Unternehmen höchstens 30 Minuten Daten verlieren darf, reicht eine Sicherung alle 24 Stunden nicht. Und wenn ein 15-TB-Fileserver innerhalb von vier Stunden wieder verfügbar sein soll, muss die gesamte Restore-Kette genau darauf ausgelegt sein.
3-2-1 ist eine gute Grundlage – heute aber nicht das Ende der Planung.
Die klassische 3-2-1-Regel ist weiterhin sinnvoll: drei Kopien der Daten, auf zwei unterschiedlichen Medien, davon mindestens eine Kopie außerhalb des primären Standorts. Auch das BSI empfiehlt dieses Prinzip als Grundlage einer Backup-Strategie.[1]
Das Problem: Moderne Angriffe richten sich nicht nur gegen Produktivsysteme. Angreifer suchen gezielt nach Backup-Infrastruktur und versuchen, Sicherungen zu löschen oder unbrauchbar zu machen. Das BSI weist ausdrücklich darauf hin, dass bei Schadsoftware-Infektionen Backups selbst ein Ziel werden können.[2]
Deshalb halte ich die erweiterte Betrachtung für wichtiger als das reine Zählen von Kopien. Veeam beschreibt dafür die 3-2-1-1-0-Regel: Zusätzlich zu 3-2-1 kommt eine unveränderliche oder anderweitig isolierte Kopie hinzu; die Null steht für überprüfte Wiederherstellbarkeit ohne unentdeckte Fehler.[3]
Ob dabei Veeam, eine andere Backup-Lösung oder mehrere Technologien eingesetzt werden, ist für das Grundprinzip zweitrangig. Wichtig ist, dass nicht ein einziger administrativer Fehler, kompromittierter Account oder Standortausfall alle Sicherungskopien gleichzeitig treffen kann.
Immutable Backup ist wichtig. Aber nicht magisch.
Immutability gehört für mich heute zu einer modernen Backup-Architektur. Eine unveränderliche Sicherung kann innerhalb ihres Schutzzeitraums nicht einfach überschrieben oder gelöscht werden. Das erschwert es Angreifern erheblich, auch die letzte Wiederherstellungsoption zu zerstören.
Aber genau hier entsteht manchmal eine falsche Sicherheit. Ein immutable Repository beantwortet beispielsweise nicht automatisch diese Fragen:
- Werden überhaupt alle geschäftskritischen Systeme gesichert?
- Ist die Retention ausreichend, wenn ein Fehler erst Wochen später entdeckt wird?
- Sind Zugangsdaten, Schlüssel und Konfigurationen für die Wiederherstellung vorhanden?
- Reicht die Bandbreite für einen großen Restore aus der Cloud?
- Kann eine Applikation konsistent wiederhergestellt werden?
- Ist klar, welche Systeme in welcher Reihenfolge zurückkommen müssen?
NIST empfiehlt im Zusammenhang mit Ransomware deshalb nicht nur sichere und isolierte Backups, sondern ausdrücklich eine geplante und getestete Backup- und Restore-Strategie.[4]
Immutability löst also ein sehr wichtiges Problem: den Schutz der Sicherung. Die Wiederherstellungsfähigkeit des Unternehmens muss trotzdem separat geplant werden.
Der Restore-Test ist der Moment, in dem Annahmen auf Realität treffen.
Ein Backup kann vollständig aussehen und sich trotzdem nicht so wiederherstellen lassen, wie es im Betrieb benötigt wird. Vielleicht fehlt ein Schlüssel. Vielleicht ist eine Datenbank inkonsistent. Vielleicht wurde eine Abhängigkeit übersehen. Oder der Restore dauert nicht zwei, sondern zwölf Stunden.
Deshalb gehören regelmäßige Wiederherstellungstests für mich fest zum Betrieb. Nicht nur als einmaliger Test nach der Einrichtung, sondern als wiederkehrende Prüfung.
Dabei muss nicht jedes Mal die komplette Umgebung wiederhergestellt werden. Sinnvoll ist ein abgestuftes Vorgehen: einzelne Dateien und Objekte, ausgewählte virtuelle Maschinen, applikationsbezogene Tests und in größeren Abständen ein kompletter Recovery-Ablauf für geschäftskritische Systeme.
Wichtig ist vor allem, dass das Ergebnis dokumentiert wird: Was wurde getestet? Wie lange hat es gedauert? Was hat nicht funktioniert? Welche Anpassung folgt daraus? Erst dann wird aus dem Test ein Bestandteil der Strategie.
Wie ich eine Backup-Strategie in der Praxis strukturiere.
Wenn ich eine Backup-Umgebung bewerte oder neu plane, beginne ich deshalb nicht beim Produkt. Ich gehe von den Anforderungen aus und arbeite mich zur Architektur vor.
- Daten und Systeme klassifizieren. Was ist geschäftskritisch, was wichtig und was im Notfall verzichtbar?
- RPO und RTO festlegen. Nicht pauschal für „die IT“, sondern je nach Dienst und Schutzbedarf.
- Sicherungs- und Aufbewahrungsmodell definieren. Frequenz, Retention, GFS-Archive und gesetzliche oder betriebliche Anforderungen gehören zusammen.
- Mehrere Fehlerdomänen einplanen. Produktionsumgebung, primäres Backup und zusätzliche Kopie dürfen nicht am gleichen Ausfall hängen.
- Backups selbst schützen. Immutability, Isolation, getrennte Credentials und ein gehärteter Backup-Server sind keine optionalen Extras mehr.
- Recovery-Pfade dokumentieren. Wer darf was wiederherstellen? Wo liegen Schlüssel? Welche Reihenfolge gilt?
- Restore regelmäßig testen. Technisch und organisatorisch – inklusive Zeitmessung und Nachbereitung.
Erst danach entscheide ich, welche Technologie diese Anforderungen am sinnvollsten erfüllt. Das kann lokaler Storage sein, Object Storage, Tape, ein zweiter Standort oder eine Kombination daraus. Die Architektur folgt der Anforderung – nicht umgekehrt. Wenn du dich mit der Plattformseite beschäftigst, passt dazu auch mein Beitrag „VMware nach Broadcom: Warum Proxmox eine echte Alternative ist.“
Meine Einschätzung
Der Satz „Wir haben ein Backup“ beruhigt schnell. Für mich ist er aber erst der Anfang der Diskussion.
Eine belastbare Backup-Strategie definiert, welche Daten geschützt werden müssen, welchen Verlust das Unternehmen verkraften kann, wie schnell Systeme zurückkommen müssen, wie die Sicherungen selbst gegen Angriffe geschützt werden und wie regelmäßig die Wiederherstellung getestet wird.
Das Ziel ist nicht möglichst viel Backup-Technik. Das Ziel ist ein planbarer Weg zurück in den Betrieb.
Quellen und Einordnung
Stand der Recherche: 4. Oktober 2026. Für Grundsätze zur Datensicherung und Ransomware wurden Veröffentlichungen des BSI und NIST verwendet. Die 3-2-1-1-0-Erweiterung wird von Veeam beschrieben und ist entsprechend als Herstellerkonzept gekennzeichnet.