Backup-Strategie für Unternehmen: Wiederanlauf planbar machen

Kurzantwort: Was gehört in eine Backup-Strategie?

Eine Backup-Strategie legt fest, welche geschäftlichen Funktionen geschützt werden, welche Daten- und Systemstände dafür benötigt werden, wie viel Datenverlust und Unterbrechung tragbar sind, wo Sicherungen liegen, wer darauf zugreifen darf und wie der Wiederanlauf geprüft wird. Sie verbindet fachliche Prioritäten mit technischer Sicherung und klarer Betriebsverantwortung.

Das BSI behandelt Backup und Restore als zusammengehörige Teile eines Datensicherungskonzepts. Der Stand einer Kopie allein reicht damit nicht als Zielbild. Unternehmen müssen auch festlegen, wie ein geeigneter Sicherungsstand ausgewählt, auf einer verfügbaren Zielumgebung wiederhergestellt und anschließend als nutzbare Funktion abgenommen wird.

Vier Nachweise statt eines grünen Backup-Status verlangen

Im Betrieb werden vier Zustände getrennt bewertet: gesichert, geschützt, wiederherstellbar und betriebsfähig. Gesichert bedeutet, dass ein definierter Datenstand kopiert wurde. Geschützt bedeutet, dass dieser Stand nicht vom gleichen Fehler, Zugriff oder Standortausfall wie die Produktion betroffen ist. Wiederherstellbar ist er, wenn Daten und Komponenten technisch zurückgespielt werden können. Betriebsfähig ist die Umgebung erst, wenn ein vereinbarter Geschäftsablauf funktioniert.

Diese Trennung verhindert vorschnelle Aussagen. Eine täglich erzeugte Kopie kann unvollständig sein. Eine unveränderbare Kopie kann ohne Schlüssel oder Zielressourcen unbrauchbar bleiben. Ein erfolgreich gestarteter Server kann trotzdem keine Anmeldung, Dokumentenerzeugung oder Schnittstellenverarbeitung ermöglichen. Jeder Zustand braucht deshalb einen eigenen Nachweis und Verantwortlichen.

Vom Geschäftsprozess zum Wiederherstellungsobjekt arbeiten

Beginnen Sie mit einem Geschäftsprozess und nicht mit einer Liste von Servern. Für die Auftragsbearbeitung können beispielsweise Anwendung, Datenbank, Dokumentenspeicher, Identitätsdienst, Zertifikate, Schnittstellenkonfiguration, Druck- oder Versandlogik und ein fachlich freigegebener Datenstand zusammengehören. Fehlt ein Teil, ist die einzelne Datenbankkopie noch kein belastbarer Wiederanlauf.

DAG fasst diese Abhängigkeiten als Wiederherstellungsobjekt zusammen: eine klar abgegrenzte Funktion samt der Daten, Konfigurationen, Identitäten, Schlüssel, Installationsquellen, Dokumentation und externen Voraussetzungen, die für ihren Betrieb erforderlich sind. Das Objekt erhält einen fachlichen Eigentümer, einen technischen Betreiber und eine definierte Prüfmethode. Dadurch bleiben Systemgrenzen auch bei SaaS, Hosting und mehreren Dienstleistern sichtbar.

• Geschäftsfunktion und akzeptabler Ersatzbetrieb
• führende Datenquellen und konsistenter Sicherungszeitpunkt
• Anwendung, Laufzeit, Konfiguration und Automatisierungen
• Identitäten, Berechtigungen, Schlüssel und Zertifikate
• interne sowie externe Schnittstellen und Wiederanlaufreihenfolge
• Installationsquellen, Lizenzen, Runbooks und verantwortliche Kontakte

RPO und RTO als betriebliche Ziele festlegen

Das Recovery Point Objective (RPO) beschreibt, zu welchem Zeitpunkt Daten nach einem Ausfall mindestens wiederhergestellt werden müssen. Das Recovery Time Objective (RTO) beschreibt, wie lange eine Systemressource bis zur Wiederherstellung ausfallen darf, bevor die betriebliche Auswirkung untragbar wird. NIST ordnet beide Werte der Analyse des unterstützten Geschäftsprozesses zu; sie sind keine pauschalen Produktmerkmale.

Ein RPO von vier Stunden verlangt einen anderen Erfassungs- und Übertragungsrhythmus als ein täglicher Sicherungslauf. Ein RTO von zwei Stunden kann nicht erfüllt werden, wenn Zielinfrastruktur, Schlüssel oder fachliche Freigabe erst nach dem Ausfall organisiert werden. Fachbereich und Geschäftsverantwortung bestimmen die tragbaren Auswirkungen; die IT prüft Sicherungsintervall, Datenmenge, Wiederanlaufdauer und Abhängigkeiten dagegen.

RPO und RTO sind Ziele, keine Garantie. Messwerte aus realen Wiederherstellungen zeigen, ob Architektur und Ablauf sie unterstützen. Abweichungen werden als Risiko mit Maßnahme und Entscheidung dokumentiert, nicht durch optimistische Annahmen verdeckt.

Backup, Snapshot, Replikation, Archiv und Export unterscheiden

Ein Backup bewahrt einen definierten Daten- oder Systemstand für eine spätere Wiederherstellung. Ein Snapshot bildet häufig einen schnellen Zustand innerhalb derselben Plattform ab. Replikation hält eine zweite Instanz nahe am aktuellen Stand. Ein Archiv dient langfristiger, geordneter Aufbewahrung. Ein Export macht Daten aus einer Anwendung oder einem Mandanten heraus verfügbar. Je nach Architektur können diese Verfahren kombiniert werden, sie ersetzen sich aber nicht automatisch.

Das BSI grenzt eine RAID-Spiegelung ausdrücklich von einer Datensicherung ab, weil Änderungen gleichzeitig auf die gespiegelten Daten wirken. Dasselbe Grundproblem gilt für andere eng gekoppelte Kopien: Löschen, Fehlkonfiguration oder kompromittierte Administratorzugänge können sich fortsetzen. Prüfen Sie deshalb für jede Kopie, gegen welche Fehlerklasse sie schützt und welche Fehler sie mit der Produktion teilt.

Kopien in unabhängige Schutzdomänen verteilen

Eine Schutzdomäne ist ein Bereich mit eigenen Fehler-, Zugriffs- und Verwaltungsgrenzen. Zwei Speichersysteme im gleichen Mandanten mit denselben Administratorrollen bilden möglicherweise nur eine Domäne. Eine belastbare Strategie kombiniert schnelle Wiederherstellung mit mindestens einem Stand, der nicht über die normalen Produktionszugänge verändert oder gelöscht werden kann. Standort, Plattform, Identität, Schlüsselverwaltung und Netzwerkzugriff werden dabei gemeinsam betrachtet.

CISA empfiehlt mit Blick auf Ransomware offline gehaltene, verschlüsselte Sicherungen und regelmäßige Tests. Offline muss nicht für jede Umgebung dasselbe technische Medium bedeuten. Entscheidend ist, dass ein Angreifer oder Fehler aus der Produktionsdomäne den geschützten Stand nicht unmittelbar erreicht. Unveränderbare Aufbewahrung hilft nur, wenn Dauer, Löschrechte, Notfallzugriff und Schlüsselverwaltung ebenfalls belastbar konfiguriert sind.

Die verbreitete 3-2-1-Merksystematik kann als Kontrollfrage dienen, ersetzt aber keine Architekturprüfung. Drei Kopien sind keine drei Schutzdomänen, wenn sie von derselben Identität, demselben Mandanten oder derselben Fehlkonfiguration abhängen.

SaaS-Daten, Schnittstellen und Konfigurationen ausdrücklich einbeziehen

Cloud- oder SaaS-Betrieb nimmt dem Unternehmen nicht automatisch die Verantwortung für den eigenen Daten- und Wiederanlaufbedarf. Klären Sie je Anwendung, welche Versionierung der Anbieter bereitstellt, welche Daten exportierbar sind, wie Konfigurationen und Berechtigungen dokumentiert werden und ob ein Export ohne laufenden Mandanten praktisch nutzbar wäre. Vertrags- und Datenschutzfragen müssen im konkreten Fall gesondert geprüft werden.

Besonders häufig fehlen Randdaten: Integrationszuordnungen, technische Konten, Webhooks, API-Schlüssel, Vorlagen, Freigaberegeln oder Zeitpläne. Ein CRM-Export kann Kontakte und Vorgänge enthalten, aber keine lauffähige Prozesslogik. Das Wiederherstellungsobjekt benennt deshalb, welche Bestandteile gesichert, reproduzierbar aufgebaut oder durch ein Ersatzverfahren überbrückt werden.

Wiederherstellungszugänge und Schlüssel vom Alltag trennen

Sicherungen müssen verschlüsselt und zugleich im Notfall entschlüsselbar sein. Dafür werden Schlüsselinhaberschaft, Aufbewahrung, Vertretung und Wiederherstellungsweg dokumentiert. Ein Schlüssel, der nur im ausgefallenen System liegt, oder ein Notfallkonto, dessen Mehrfaktorverfahren vom gleichen Identitätsdienst abhängt, kann den Restore blockieren.

Normale Betriebsrollen sollten Sicherungen nicht unbemerkt löschen oder Schutzregeln ändern können. Administrative Änderungen an Aufbewahrung, Ziel, Schlüssel und Ausschlüssen benötigen Protokollierung und eine angemessene Kontrolle. Notfallzugänge werden begrenzt, geschützt und regelmäßig auf Nutzbarkeit geprüft; sie sind kein dauerhaft geteilter Generalschlüssel.

Aufbewahrung, Versionen und Löschung gemeinsam planen

Kurze Versionen unterstützen die Korrektur aktueller Fehler; ältere Stände können schleichende Beschädigung oder spät erkannte Manipulation abdecken. Die Staffelung richtet sich nach Änderungsrate, Erkennungszeit, Datenmenge und fachlichen Anforderungen. Eine lange Aufbewahrung ohne nachvollziehbaren Zweck erhöht dagegen Kosten und Schutzbedarf.

Lösch- und Aufbewahrungspflichten hängen von Datenart, Zweck und rechtlichem Kontext ab. Die Backup-Strategie dokumentiert deshalb, wie reguläre Löschung, Ablauf von Sicherungsständen, Sperren und gegebenenfalls gesonderte Aufbewahrung technisch umgesetzt werden. Sie ersetzt keine rechtliche Einzelfallprüfung.

Backup-Fehler vom Signal bis zur Korrektur führen

Ein Sicherungssystem meldet nicht nur Erfolg oder Fehler. Überwacht werden sollten auch fehlende Quellen, unerwartet kleine Datenmengen, ausbleibende Stände, abgelaufene Agenten, knapper Zielspeicher, Replikationsrückstand und Änderungen an Schutzregeln. Welche Signale relevant sind, hängt vom Wiederherstellungsobjekt ab.

Für jede kritische Abweichung braucht es Empfänger, Priorität, erste Prüfung, sichere Wiederholung, Eskalation und Nachweis der Korrektur. Ein fehlgeschlagener Job, der am Folgetag wieder grün ist, gilt nicht automatisch als erledigt: Es muss geklärt sein, ob das RPO verletzt wurde und welcher geschützte Stand tatsächlich verfügbar ist.

Den Wiederanlauf als Systemübergang vorbereiten

Die Strategie beschreibt nicht nur das Zurückkopieren von Daten. Sie legt fest, wer den Ausfall bewertet, welcher Sicherungsstand als unbelastet gilt, wo Zielressourcen entstehen, in welcher Reihenfolge Identität, Datenbank, Anwendung und Schnittstellen starten und welche automatischen Aktionen zunächst gesperrt bleiben. Kommunikation und fachliche Abnahme gehören in denselben Ablauf.

Der separate DAG-Leitfaden zu Restore-Tests beschreibt die praktische Prüfung dieses Weges. Für die Strategie genügt nicht der Verweis auf einen Dienstleister: Unternehmen benötigen bekannte Verantwortlichkeiten, Zugriff auf Nachweise und eine Entscheidung darüber, welche Wiederherstellungen der Anbieter selbstständig ausführen darf und welche Freigabe er benötigt.

Beispielprozess: Auftragsbearbeitung als Wiederherstellungsobjekt

Ein Anwendungsszenario: Ein Unternehmen verarbeitet Aufträge in einer Webanwendung mit Datenbank, Dokumentenspeicher, zentraler Anmeldung und nächtlicher Übergabe an das ERP. Der erste Entwurf sichert nur Datenbank und Dateien. Die Bestandsaufnahme zeigt jedoch, dass Zertifikate, Schnittstellenkonto, Vorlagen und Zuordnung der ERP-Felder für einen vollständigen Wiederanlauf ebenfalls benötigt werden.

Das Unternehmen definiert den Prozess als gemeinsames Wiederherstellungsobjekt. Datenbank und Dokumente erhalten abgestimmte Sicherungszeitpunkte; Konfigurationen, Vorlagen und Infrastrukturdefinitionen werden versioniert; Schlüssel und Notfallzugänge liegen in einer getrennten Schutzdomäne. Die nächtliche Übergabe bleibt beim Restore deaktiviert, bis Fachbereich und IT einen Testauftrag geprüft haben.

Ein schneller lokaler Stand unterstützt einzelne Wiederherstellungen. Ein getrennt verwalteter, unveränderbarer Stand schützt gegen kompromittierte Produktionszugänge. Ein zusätzlicher räumlich getrennter Stand deckt den Verlust des primären Standorts ab. Welche konkrete Technik eingesetzt wird, folgt den ermittelten Zielen und ist keine pauschale Produktempfehlung oder Verfügbarkeitszusage.

Die Backup-Strategie in neun Schritten erstellen

Bearbeiten Sie zuerst die geschäftlichen Ziele und erst danach Produkte und Speicher. So bleibt sichtbar, welche Entscheidung durch Technik unterstützt werden soll und welche Lücke offen ist.

• 1. Kritische Geschäftsprozesse, Eigentümer und tragbare Unterbrechungen erfassen.
• 2. Pro Prozess ein Wiederherstellungsobjekt mit Daten, Systemen und Abhängigkeiten bilden.
• 3. RPO, RTO, Ersatzverfahren und fachliche Erfolgskriterien festlegen.
• 4. Vorhandene Backups, Snapshots, Replikationen, Archive und Exporte nach Schutzwirkung inventarisieren.
• 5. Kopien auf unabhängige Zugriffs-, Plattform- und Standortdomänen verteilen.
• 6. Verschlüsselung, Schlüssel, Notfallkonten, Aufbewahrung und Löschung regeln.
• 7. Monitoring, Alarmwege, Korrektur und Nachweis für Sicherungsabweichungen einrichten.
• 8. Wiederanlaufreihenfolge, Zielressourcen, Freigaben und fachliche Abnahme dokumentieren.
• 9. Restore-Tests sowie Prüfungen nach Änderungen planen und Befunde in die Strategie zurückführen.

Checkliste für die nächste Strategieprüfung

Wenn mehrere Antworten nur für einzelne Server, aber nicht für den unterstützten Geschäftsprozess vorliegen, ist die Strategie noch unvollständig. Die offenen Punkte werden priorisiert, bevor bloß zusätzlicher Speicher beschafft wird.

• Sind alle geschäftskritischen Funktionen einem fachlichen und technischen Eigentümer zugeordnet?
• Enthält jedes Wiederherstellungsobjekt Daten, Konfiguration, Identität, Schlüssel und Schnittstellen?
• Sind RPO und RTO vom Fachbereich bestätigt und durch einen realistischen Ablauf unterstützt?
• Ist bekannt, welche Fehler jede Kopie mit der Produktion teilt?
• Existiert mindestens ein geschützter Stand außerhalb der normalen Produktionsverwaltung?
• Funktionieren Notfallzugänge und Schlüssel auch bei Ausfall des primären Identitätsdienstes?
• Sind Aufbewahrung, Versionierung, Löschung und Änderungen nachvollziehbar geregelt?
• Führen Backup-Warnungen zu einer verantworteten Prüfung und nicht nur zu einer E-Mail?
• Sind Zielumgebung, Wiederanlaufreihenfolge und fachliche Abnahme beschrieben?
• Wurde der Weg praktisch getestet und wurden Abweichungen nachverfolgt?