Ein Backup ist erst dann etwas wert, wenn du daraus unter realistischen Bedingungen wiederherstellen kannst. Genau daran scheitern viele Organisationen nicht wegen fehlender Speicherkapazität, sondern wegen unklarer Prioritäten, ungetesteter Abläufe und Abhängigkeiten, die erst im Incident sichtbar werden. Eine Backup Strategie ist deshalb kein Infrastrukturdetail. Sie ist eine überprüfbare Vereinbarung darüber, welche Geschäftsprozesse nach welchem Schaden wie schnell und mit welchem Datenstand wieder laufen müssen.
Für CIOs und CISOs ist das eine Frage der Resilienz und Steuerbarkeit. Für Architekten und Betriebsteams geht es um Datenkonsistenz, Identitäten, Automatisierung, Netzsegmente und belastbare Runbooks. Beide Perspektiven gehören zusammen. Wer nur über Backup-Tools entscheidet, übersieht den eigentlichen Gegenstand: die Wiederherstellungsfähigkeit der Organisation.
Die Backup Strategie beginnt bei Recovery-Zielen
Die Reihenfolge ist entscheidend: Erst definierst du die Wiederherstellungsziele, dann leitest du Technik und Betriebsmodell ab. Recovery Time Objective (RTO) beschreibt, wie lange ein Service maximal ausfallen darf. Recovery Point Objective (RPO) legt fest, wie viel Datenverlust zwischen letztem konsistenten Wiederherstellungspunkt und Störung akzeptabel ist. Beide Werte sind keine technischen Wunschgrößen. Sie müssen aus geschäftlichen Folgen, regulatorischen Anforderungen, vertraglichen Verpflichtungen und operativen Abhängigkeiten entstehen.
Ein ERP-System mit wenigen Stunden Datenverlust kann unter Umständen weiterbetrieben werden, ein Zahlungs- oder Produktionsprozess möglicherweise nicht. Bei einem Verzeichnisdienst oder einer zentralen Identity-Plattform ist die Lage nochmals anders: Fällt sie aus oder wird sie kompromittiert, kann der Zugriff auf zahlreiche weitere Dienste blockiert sein. Eine einheitliche Vorgabe wie „alles innerhalb von vier Stunden“ klingt entschlossen, führt aber meist zu unnötigen Kosten an einer Stelle und unvertretbaren Risiken an anderer.
Sinnvoll ist eine Klassifizierung nach Geschäftsservice statt nach Server oder Datenbank. Ein Service umfasst Anwendungen, Daten, Schnittstellen, Identitäten, Konfigurationen, Berechtigungen und gegebenenfalls externe Abhängigkeiten. Erst diese Sicht macht sichtbar, was tatsächlich wiederhergestellt werden muss. Die Datenbank allein zurückzuspielen genügt nicht, wenn Zertifikate, Secrets, Netzwerkregeln oder die Infrastrukturdefinition fehlen.
RTO und RPO sind nur die halbe Wahrheit
Ergänze RTO und RPO um eine Aussage zur Wiederanlauffähigkeit. Welcher minimale Funktionsumfang muss zuerst verfügbar sein? Welche Fachbereiche dürfen mit einem eingeschränkten Prozess arbeiten? Und welche Vorbedingungen braucht das Recovery-Team, etwa privilegierte Konten, saubere Administrationsarbeitsplätze oder einen alternativen Kommunikationskanal?
Diese Fragen wirken operativ, entscheiden aber über die Qualität der Strategie. Ein nominell gutes RTO hilft wenig, wenn die verantwortlichen Personen im Krisenfall nicht auf Dokumentation, Schlüsselmaterial oder die Management-Oberfläche zugreifen können.
3-2-1 bleibt nützlich, reicht aber nicht aus
Die bekannte 3-2-1-Regel ist als Denkmodell weiterhin sinnvoll: mehrere Kopien, unterschiedliche Medientypen oder Speicherklassen, eine Kopie außerhalb des Primärstandorts. Sie verhindert jedoch nicht automatisch die häufigsten Ursachen für gescheiterte Wiederherstellungen: kompromittierte Administrationskonten, replizierte Verschlüsselung, unerkannte Datenkorruption oder falsch konfigurierte Aufbewahrungsfristen.
Deshalb sollte die Backup Strategie zusätzliche Eigenschaften definieren. Backups brauchen Unveränderbarkeit für einen festgelegten Zeitraum, getrennte administrative Berechtigungen und möglichst eine Sicherheitsdomäne, die nicht vollständig vom Produktivbetrieb abhängt. Je nach Schutzbedarf kann auch eine logisch oder physisch getrennte Kopie erforderlich sein. Entscheidend ist nicht das Etikett „air-gapped“, sondern die konkrete Frage: Kann ein Angreifer mit den Berechtigungen, die er realistischerweise erlangen könnte, die letzte brauchbare Sicherung löschen oder manipulieren?
Unveränderbare Speicherung ist dabei kein Freifahrtschein. Wenn die Sicherung bereits verschlüsselte oder korrumpierte Daten enthält, konserviert sie den Schaden lediglich. Du brauchst daher ausreichend lange Aufbewahrungszeiträume und klar identifizierbare Wiederherstellungspunkte. Besonders bei schleichender Datenmanipulation kann der letzte erfolgreiche Backup-Job weit hinter dem letzten vertrauenswürdigen Datenstand liegen.
Auch Replikation ist nicht gleich Backup. Sie reduziert Ausfallzeiten bei Infrastrukturfehlern und Standortstörungen, repliziert aber häufig auch Löschungen, fehlerhafte Daten oder Angriffe. Replikation und Backup erfüllen unterschiedliche Zwecke und sollten in Architektur- und Risikodiskussionen nicht gegeneinander ausgespielt werden.
Was du tatsächlich sichern musst
Die größte Lücke entsteht oft außerhalb klassischer Datenbanken und Filesysteme. Moderne Unternehmens-IT verteilt Zustand über SaaS-Dienste, Cloud-Plattformen, Container-Orchestrierung, CI/CD-Pipelines und Identity-Systeme. Ein Recovery-Konzept muss deshalb Daten, Konfiguration und Kontrollebenen unterscheiden und gemeinsam betrachten.
Für cloudnative Anwendungen gehören etwa Infrastrukturdefinitionen, Container-Images, Artefakt-Repositories, Deployment-Manifeste, Secrets-Management, Schlüssel, Zertifikate und Observability-Konfigurationen in die Betrachtung. Infrastructure as Code erleichtert die Reproduzierbarkeit, ersetzt aber keine Sicherung. Ein Repository kann unvollständig sein, ein Secret absichtlich nicht versioniert oder ein externer Dienst nicht mehr verfügbar sein.
Bei SaaS gilt derselbe Grundsatz: Die Verantwortung für Verfügbarkeit des Dienstes und die Verantwortung für die Wiederherstellung eigener Inhalte, Mandantenkonfigurationen oder Berechtigungen sind nicht automatisch deckungsgleich. Prüfe konkret, welche Export-, Restore- und Aufbewahrungsfunktionen existieren, welche Objekte sie erfassen und ob sie die fachlich benötigte Granularität bieten. Pauschale Annahmen über ein Shared-Responsibility-Modell sind riskant.
Besondere Priorität verdienen Identitäten. Backups von Verzeichnisdiensten, IAM-Konfigurationen, privilegierten Rollen und Break-Glass-Konten müssen mit einem Verfahren verbunden sein, das auch nach einer Kompromittierung funktioniert. Dazu gehört eine dokumentierte Reihenfolge: Welche Identitätsbasis wird zuerst wiederhergestellt, wie werden vertrauenswürdige Administrationszugänge bereitgestellt und wann dürfen abhängige Systeme wieder verbunden werden?
Der Wiederherstellungstest ist der Beweis
Ein erfolgreicher Backup-Job beweist nur, dass Daten geschrieben wurden. Er beweist weder Konsistenz noch Vollständigkeit noch die Einhaltung deines RTO. Die entscheidende Kennzahl lautet daher nicht Backup-Erfolgsquote, sondern erfolgreich getestete Wiederherstellung innerhalb eines definierten Szenarios.
Teste nicht nur einzelne Dateien. Übe die Wiederherstellung eines priorisierten Geschäftsservices in einer isolierten Umgebung. Prüfe dabei Datenintegrität, Abhängigkeiten, Funktionalität, Zeitbedarf und die Qualität der Arbeitsanweisungen. Ein Test sollte außerdem beantworten, ob der gewünschte Wiederherstellungspunkt tatsächlich frei von der simulierten Störung ist.
Die Testtiefe darf nach Kritikalität variieren. Für weniger kritische Systeme kann ein technischer Restore-Test genügen. Für geschäftskritische Services brauchst du regelmäßig eine Ende-zu-Ende-Übung mit Fachseite, Betrieb, Security und gegebenenfalls Dienstleistern. Gerade bei Ransomware-Szenarien lohnt sich ein bewusst eingeschränktes Szenario: Produktivumgebung als nicht vertrauenswürdig annehmen, Administration aus einer sauberen Umgebung durchführen und nur geprüfte Komponenten schrittweise zurückführen.
Tests liefern fast immer unbequeme Erkenntnisse. Fehlende Netzwerkfreigaben, unklare Eigentümerschaft, veraltete Dokumentation oder zu geringe Kapazitäten im Recovery-Ziel sind keine Testfehler. Sie sind Risiken, die der Test rechtzeitig sichtbar gemacht hat. Behandle sie wie technische Schulden mit Priorität, Verantwortlichen und Termin.
Betrieb, Governance und Kosten gehören zusammen
Eine gute Strategie macht Verantwortlichkeiten explizit. Die fachliche Seite definiert die Schutzbedarfe und akzeptierten Einschränkungen. IT-Architektur übersetzt sie in Zielbilder und Abhängigkeiten. Betriebsteams verantworten Ausführung, Monitoring und Runbooks. Security prüft insbesondere Trennung von Rollen, Zugriffsschutz und Angriffsszenarien. Ohne dieses Zusammenspiel bleibt Backup entweder ein Ticket im Infrastrukturteam oder ein abstrakter Punkt im Risikoregister.
Auch Kosten müssen transparent werden. Sehr kurze RPOs, lange Aufbewahrung, mehrere Regionen und isolierte Recovery-Umgebungen sind nicht kostenlos. Die richtige Entscheidung ist nicht immer die technisch maximal mögliche Absicherung. Sie liegt dort, wo Schutzbedarf, Schadenspotenzial und Betriebsaufwand nachvollziehbar gegeneinander abgewogen wurden. Diese Abwägung sollte dokumentiert, regelmäßig überprüft und bei wesentlichen Architekturänderungen aktualisiert werden.
Achte außerdem auf Monitoring, das nicht nur fehlgeschlagene Sicherungen meldet. Relevante Signale sind ungewöhnliche Löschvorgänge, Änderungen an Aufbewahrungsregeln, fehlende Unveränderbarkeit, stark veränderte Datenvolumina und administrative Aktionen außerhalb erwarteter Wartungsfenster. Backup-Plattformen sind ein attraktives Ziel. Sie verdienen daher ein eigenes Sicherheitsdesign, nicht lediglich die gleichen Zugriffsregeln wie Produktivsysteme.
Die wirksamste Backup Strategie ist am Ende keine Spezifikation im Wiki. Sie zeigt sich darin, dass dein Team für die wichtigsten Services einen sauberen, getesteten und nachvollziehbaren Weg zurück kennt – auch dann, wenn Teile der eigenen IT gerade nicht mehr vertrauenswürdig sind.
