Ein Backup-Plan beantwortet zwei Fragen: Wie werden Ihre Systeme gesichert, und in welcher Reihenfolge kommen sie im Ernstfall zurück? Das Bundesamt für Sicherheit in der Informationstechnik (BSI) verlangt im IT-Grundschutz-Baustein CON.3 Datensicherungskonzept solche Datensicherungspläne je IT-System oder Gruppe von Systemen (Anforderung A4). Wie das übergeordnete Datensicherungskonzept gegliedert sein kann, zeigt unsere Backup-Konzept-Vorlage.
Dieser Beitrag führt in sechs Schritten zu einem solchen Plan. Der Schwerpunkt liegt auf der Wiederherstellung: Regelmäßige Sicherungen gewährleisten laut BSI nicht automatisch, dass sich Daten auch wiederherstellen lassen (CON.3, Abschnitt 2.2). Wie ein Dienstleister die Sicherung im laufenden Betrieb übernehmen kann, lesen Sie im Beitrag Backup Managed Service. Wie Sie bei einem Sicherheitsvorfall Rollen und Meldewege festlegen, beschreibt der Beitrag Incident-Response-Plan.
Schritt 1: Systeme und Abhängigkeiten erfassen
Listen Sie alle Systeme auf, die Daten oder Einstellungen speichern: Server, virtuelle Maschinen, Datenbanken, Arbeitsplätze und Cloud-Dienste. Das BSI zählt ausdrücklich auch Router, Switches und IoT-Geräte dazu, weil sie schützenswerte Informationen wie Konfigurationen speichern (CON.3, Abschnitt 1.1). Was Microsoft 365 und Azure von sich aus wiederherstellen können, beschreibt unser Beitrag Cloud-Backup mit Microsoft.
Notieren Sie zu jedem System, welche Geschäftsabläufe davon abhängen und welche anderen Systeme es zum Laufen braucht. Eine Fachanwendung braucht zum Beispiel ihre Datenbank, die Benutzeranmeldung und die Namensauflösung im Netz. Diese Abhängigkeiten bestimmen später die Reihenfolge der Wiederherstellung.
Nach CON.3.A1 stimmt der IT-Betrieb die Rahmenbedingungen mit den Fachverantwortlichen ab, darunter die zu sichernden Daten, Speicher- und Änderungsvolumen, Änderungszeitpunkte und Verfügbarkeitsanforderungen.
Schritt 2: Ziele für Datenverlust und Ausfallzeit festlegen
Das BSI unterscheidet im Glossar zum Standard 200-4 drei Werte:
- Maximal tolerierbare Ausfallzeit (MTPD, Maximum Tolerable Period of Disruption): die zeitliche Obergrenze, bis zu der ein Geschäftsprozess ausfallen darf, bevor nicht tolerierbare Auswirkungen für die Institution auftreten.
- Geforderte Wiederanlaufzeit (RTO, Recovery Time Objective): der Zeitraum vom Ausrufen des Notfalls bis zur geforderten Inbetriebnahme der Notfall-Lösung.
- Maximal zulässiger Datenverlust (RPO, Recovery Point Objective): das Alter, das verfügbare Daten höchstens haben dürfen; in der Regel als geforderter Sicherungszyklus angegeben.
Die Werte legt Ihr Betrieb fest, nicht die Technik. Wir empfehlen, die geforderte Wiederanlaufzeit so zu wählen, dass sie mit Abstand unter der tolerierbaren Ausfallzeit liegt. Leitfragen für typische Anwendungen finden Sie im Beitrag Backup Managed Service.
Schritt 3: Sicherungsart und Rhythmus wählen
Aus dem RPO ergibt sich, wie oft gesichert werden muss. Wer nur einmal nachts sichert, kann im ungünstigsten Fall die Arbeit eines Tages verlieren. Für die Art der Sicherung gibt es drei Grundformen, die Microsoft so beschreibt (Microsoft Learn: Architektur von Azure Backup):
- Vollständige Sicherung: enthält die gesamte Datenquelle.
- Differenzielle Sicherung: erfasst die Daten, die sich seit der letzten vollständigen Sicherung geändert haben.
- Inkrementelle Sicherung: speichert nur die Daten, die sich seit der vorherigen Sicherung geändert haben.
Bei Datenbanken kommen Sicherungen des Transaktionsprotokolls hinzu. Sie ermöglichen laut Microsoft eine Wiederherstellung bis zu einem bestimmten Zeitpunkt. In virtuellen Umgebungen und bei Storage-Systemen soll laut BSI geprüft werden, ob Snapshots als schnell wiederherstellbare Zwischenstände ergänzt werden können (CON.3.A2).
Prüfen Sie auch die Dauer jedes Laufs. Das BSI beschreibt als Gefährdung, dass eine Sicherung noch nicht beendet ist, wenn die nächste beginnt (CON.3, Abschnitt 2.9).
Schritt 4: Speicherorte und Aufbewahrung festlegen
- Sicherungen müssen immer auf separaten Speichermedien liegen (CON.3.A2).
- Die Speichermedien müssen räumlich getrennt von den gesicherten Systemen aufbewahrt werden, möglichst in einem anderen Brandabschnitt (CON.3.A12).
- Das BSI empfiehlt eine 3-2-1-Regel: drei aktuelle Versionen wichtiger Dateien auf zwei verschiedenen Medien und an mindestens einem weiteren Ort (BSI, Vorschläge zu BC-Strategien).
- Sicherungen müssen vor unbefugtem Zugriff geschützt sein und dürfen nicht überschrieben werden können (CON.3.A14).
Legen Sie fest, wie lange jede Generation aufbewahrt wird, zum Beispiel tägliche, wöchentliche und monatliche Stände. Eine Datensicherung ist dabei keine Archivierung: Für die Langzeitaufbewahrung elektronischer Dokumente verweist das BSI auf einen eigenen Baustein, OPS.1.2.2 Archivierung. Soll eine Kopie bei einem Online-Anbieter liegen, finden Sie Auswahlkriterien im Beitrag Cloud-Backup in Deutschland. Wie eine Sicherung über das Internet abläuft, beschreibt der Beitrag Online-Backup.
Schritt 5: Reihenfolge der Wiederherstellung festlegen
Der Datensicherungsplan muss nach CON.3.A4 beschreiben, in welcher Reihenfolge Systeme und Anwendungen wiederhergestellt werden und wie die Wiederherstellung abläuft. Die Reihenfolge ergibt sich aus den Abhängigkeiten aus Schritt 1 und den Zielen aus Schritt 2. Ein Beispiel, keine Vorgabe:
| Reihenfolge | System | Grund |
|---|---|---|
| 1 | Netzwerk, Firewall, Namensauflösung | Ohne Netz erreichen sich die übrigen Systeme nicht. |
| 2 | Anmeldedienst, zum Beispiel Active Directory | Viele Anwendungen setzen eine Anmeldung voraus. |
| 3 | Datenbankserver | Fachanwendungen greifen auf ihre Datenbanken zu. |
| 4 | Fachanwendungen wie Warenwirtschaft oder Buchhaltung | Sie tragen die zeitkritischen Abläufe. |
| 5 | Dateiablage | Je nach Betrieb kann sie auch früher nötig sein. |
| 6 | Arbeitsplätze | Je nach Ausstattung lassen sie sich neu einrichten statt zurückspielen. |
Nach einem Angriff mit Erpressungssoftware (Ransomware) kommt ein Schritt hinzu: Bevor eine Sicherung eingespielt wird, sollte laut BSI sichergestellt sein, dass sie nicht selbst schon befallen ist (BSI, Vorschläge zu BC-Strategien). Planen Sie dafür Zeit ein und legen Sie fest, wer die Wiederherstellung freigibt.
Das BSI unterscheidet zwei Dokumente: Ein Wiederanlaufplan beschreibt, wie ausgefallene Ressourcen kompensiert werden, um einen Notbetrieb zu erreichen. Ein Wiederherstellungsplan beschreibt, wie sie in den Normalbetrieb zurückversetzt werden (BSI-Glossar). Wir empfehlen, beide Schritte getrennt zu beschreiben, auch wenn sie im selben Dokument stehen.
Schritt 6: Testen, messen, nachbessern
Nach CON.3.A15 muss regelmäßig getestet werden, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können. Das BSI-Glossar liefert dafür ein Begriffspaar: Den geforderten Werten RTO und RPO stehen die tatsächlich zu erwartende Wiederanlaufzeit (RTA, Recovery Time Actual) und der tatsächlich zu erwartende Datenverlust (RPA, Recovery Point Actual) gegenüber. Ein Test zeigt, ob die tatsächlichen Werte innerhalb der geforderten liegen.
Halten Sie in jedem Testprotokoll fest:
- welches System getestet und welcher Sicherungsstand verwendet wurde,
- wie lange die Wiederherstellung gedauert hat, verglichen mit dem RTO,
- wie alt die wiederhergestellten Daten waren, verglichen mit dem RPO,
- ob die Anwendung danach fachlich funktionierte, geprüft von der Fachabteilung,
- was im Plan geändert werden muss.
Den Plan aktuell und erreichbar halten
Ein Plan veraltet mit jedem neuen System. Neue Anforderungen müssen laut CON.3.A1 zeitnah berücksichtigt werden. Außerdem muss der Plan im Ernstfall greifbar sein: Die technischen Informationen zur Wiederherstellung sollen so gesichert sein, dass sie auch verfügbar sind, wenn die Sicherungssysteme selbst ausfallen (CON.3.A6). Liegt die Information nur digital vor, kann sie laut BSI bei Großschäden wie Ransomware ebenfalls verloren gehen (CON.3, Abschnitt 2.4).
Für Unternehmen, die unter NIS2 fallen, nennt § 30 Abs. 2 Nr. 3 BSIG Backup-Management und Wiederherstellung nach einem Notfall ausdrücklich als Maßnahme (§ 30 BSIG). Mehr dazu auf unserer Seite NIS2 und Risikomanagement. Diese Hinweise ersetzen keine Rechtsberatung.
Backup-Plan mit der GSL Groß GmbH besprechen
Die GSL Groß GmbH betreut kleine und mittelständische Unternehmen in Rheinland-Pfalz und Hessen von Idar-Oberstein aus; im Raum Darmstadt arbeitet sie dafür mit einem Partnersystemhaus zusammen. Mit unseren Managed Services übernehmen wir den laufenden Betrieb Ihrer IT zum monatlichen Festpreis. Mit dem Security-Check prüfen wir den Stand Ihrer IT-Sicherheit.
Sie möchten über Ihren Backup-Plan und Ihre Ziele für Ausfallzeit und Datenverlust sprechen? Nehmen Sie Kontakt mit uns auf.