Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen

Das teuerste Missverständnis in der IT-Sicherheit

"Wir haben Backups" ist einer der gefährlichsten Sätze in der IT. Nicht weil er falsch wäre, sondern weil er ein Sicherheitsgefühl vermittelt, das möglicherweise auf Sand gebaut ist.

Ein Backup ist nur so viel wert wie der Restore, der daraus funktioniert. Ein Backup, das seit zwei Jahren nicht auf Wiederherstellbarkeit geprüft wurde, ist kein Sicherheitsnetz. Es ist eine Hoffnung. Und Hoffnung ist keine Strategie, schon gar nicht, wenn Ransomware den Fileserver verschlüsselt hat und die Geschäftsführung fragt, wie schnell alles wieder läuft.

Die Statistiken zeichnen ein ernüchterndes Bild. Studien zeigen regelmäßig, dass zwischen 30 und 40 Prozent aller Restore-Versuche scheitern - sei es durch beschädigte Backup-Medien, inkonsistente Daten, veraltete Backup-Software oder schlicht durch fehlende Dokumentation des Restore-Prozesses. In vielen Fällen wird der Fehler erst entdeckt, wenn das Backup dringend gebraucht wird.

Dazu kommt eine Bedrohungslage, die klassische Backup-Konzepte aushebelt. Moderne Ransomware-Varianten verschlüsseln nicht nur produktive Daten, sondern suchen gezielt nach Backup-Repositories, um diese ebenfalls zu zerstören. Wenn deine Backups auf einem Netzwerkspeicher liegen, den die Ransomware erreichen kann, hast du unter Umständen gar kein brauchbares Backup mehr.

Dieser Artikel behandelt beide Seiten: Die Backup-Strategie (was, wie oft, wohin) und die Restore-Tests (funktioniert der Restore, und passt er zu deinen Anforderungen).

Die 3-2-1-Regel: Das Fundament

Die 3-2-1-Regel ist seit Jahrzehnten der Goldstandard für Backup-Strategien. Sie ist einfach, einprägsam und deckt die häufigsten Ausfallszenarien ab.

Die drei Zahlen

3 Kopien deiner Daten: Das Original plus zwei Backup-Kopien. Wenn eine Kopie beschädigt ist, hast du noch eine zweite. Die Wahrscheinlichkeit, dass drei Kopien gleichzeitig ausfallen, ist bei unabhängiger Speicherung vernachlässigbar gering.

2 verschiedene Medientypen: Die Backups liegen auf mindestens zwei unterschiedlichen Speichermedien. Zum Beispiel: Festplatte und Band, lokaler Speicher und Cloud, NAS und USB-Festplatte. Der Grund: Wenn ein Medientyp einen systematischen Fehler hat (z. B. eine fehlerhafte Firmware-Version auf allen gleichartigen NAS-Geräten), sind nicht alle Kopien betroffen.

1 Kopie an einem externen Standort: Mindestens eine Backup-Kopie liegt physisch getrennt vom Produktivsystem. Das schützt vor lokalen Katastrophen: Brand im Serverraum, Wasserrohrbruch, Einbruch, oder eben Ransomware, die alle im Netzwerk erreichbaren Speicher verschlüsselt.

3-2-1-1: Die erweiterte Regel für die Ransomware-Ära

Die klassische 3-2-1-Regel hat eine Schwachstelle: Wenn alle Backup-Kopien online und vom Netzwerk aus erreichbar sind, kann Ransomware theoretisch alle drei erreichen. Deshalb wird die Regel heute oft um eine vierte Ziffer ergänzt:

3-2-1-1: Die zusätzliche 1 steht für eine Offline- oder Immutable-Kopie. Mindestens eine Backup-Kopie ist entweder physisch offline (z. B. ein Band oder eine USB-Festplatte, die nicht permanent angeschlossen ist) oder unveränderlich gespeichert (Immutable Backup).

Umsetzungsbeispiel für den Mittelstand

Backup-Typen verstehen

Nicht jedes Backup ist gleich. Die drei gängigen Backup-Typen unterscheiden sich in Geschwindigkeit, Speicherbedarf und Restore-Komplexität.

Full Backup (Vollsicherung)

Ein Full Backup sichert alle Daten vollständig. Jede Sicherung ist in sich abgeschlossen und kann unabhängig von anderen Backups wiederhergestellt werden.

Vorteile:

• Einfachster Restore: Du brauchst nur ein einziges Backup-Set
• Unabhängig von vorherigen Backups
• Schnellste Wiederherstellung

Nachteile:

• Größter Speicherbedarf: Jede Sicherung enthält alle Daten
• Längste Backup-Dauer
• Bei großen Datenmengen in der Nacht möglicherweise nicht durchführbar

Typischer Einsatz: Wöchentlich (z. B. am Wochenende, wenn mehr Zeit für die Sicherung ist)

Incremental Backup (Inkrementelle Sicherung)

Ein Incremental Backup sichert nur die Daten, die sich seit dem letzten Backup (egal ob Full oder Incremental) geändert haben.

Vorteile:

• Geringster Speicherbedarf pro Sicherung
• Schnellste Backup-Dauer
• Ideal für tägliche oder stündliche Sicherungen

Nachteile:

• Restore benötigt das letzte Full Backup plus alle nachfolgenden Incrementals
• Je mehr Incrementals in der Kette, desto langsamer und fehleranfälliger der Restore
• Wenn ein Incremental in der Kette beschädigt ist, sind alle nachfolgenden unbrauchbar

Typischer Einsatz: Täglich oder häufiger, zwischen den Full Backups

Differential Backup (Differenzielle Sicherung)

Ein Differential Backup sichert alle Daten, die sich seit dem letzten Full Backup geändert haben. Im Unterschied zum Incremental wächst es mit jedem Tag, weil es immer die gesamte Differenz zum letzten Full Backup enthält.

Vorteile:

• Restore benötigt nur das letzte Full Backup plus das letzte Differential
• Unabhängig von der Kette der täglichen Sicherungen
• Guter Kompromiss zwischen Backup-Geschwindigkeit und Restore-Einfachheit

Nachteile:

• Wachsender Speicherbedarf bis zum nächsten Full Backup
• Längere Backup-Dauer als Incremental (aber kürzer als Full)

Typischer Einsatz: Täglich, in Kombination mit wöchentlichem Full Backup

Vergleich auf einen Blick

Gängige Kombinationsstrategie

Die meisten mittelständischen Unternehmen setzen auf eine Kombination:

• Wöchentlich: Full Backup (z. B. Sonntagnacht)
• Täglich: Incremental oder Differential Backup (z. B. Nachts um 2:00 Uhr)
• Stündlich (bei kritischen Systemen): Transaction-Log-Backup oder Incremental Snapshot

Welche Kombination für dich passt, hängt von deinem RPO ab. Die passenden RPO-Werte definierst du in der Business Impact Analyse. Wenn das RPO für die Buchhaltung bei 1 Stunde liegt, brauchst du mindestens stündliche Sicherungen. Wenn das RPO für das interne Wiki bei 24 Stunden liegt, reicht ein tägliches Backup.

Aufbewahrungsfristen

Wie lange du Backups aufbewahrst, ist keine rein technische Frage. Gesetzliche Vorgaben, regulatorische Anforderungen und der eigene Schutzbedarf bestimmen die Retention Policy.

Gesetzliche Anforderungen (Deutschland)

Empfohlene Backup-Retention

DSGVO-Spannungsfeld

Die DSGVO verlangt, dass personenbezogene Daten gelöscht werden, wenn der Zweck der Verarbeitung entfällt. Das kann mit langen Backup-Aufbewahrungsfristen kollidieren. Wenn ein Kunde die Löschung seiner Daten verlangt und du ein 10 Jahre altes Jahresbackup hast, das seine Daten enthält, musst du das dokumentieren und im Restore-Fall die Löschung erneut durchführen. Eine vollständige Löschung aus dem Backup ist technisch in der Regel nicht praktikabel.

Die pragmatische Lösung: Dokumentiere in deinem Löschkonzept, dass Backups von der sofortigen Löschung ausgenommen sind, und stelle sicher, dass bei einem Restore die Löschanforderungen erneut angewendet werden.

Immutable Backups: Schutz gegen Ransomware

Immutable Backups (unveränderliche Sicherungen) sind die wichtigste Weiterentwicklung der Backup-Strategie in der Ransomware-Ära. Das Prinzip: Einmal geschrieben, können die Backup-Daten für einen definierten Zeitraum weder verändert noch gelöscht werden. Auch nicht von einem Administrator und auch nicht von Ransomware, die Adminrechte erlangt hat.

Warum klassische Backups gegen Ransomware versagen können

Moderne Ransomware-Gruppen wissen, dass Unternehmen aus Backups wiederherstellen können. Deshalb ist das Backup selbst zum Angriffsziel geworden. Typische Angriffsmuster:

1. Backup-Repositories löschen: Die Angreifer verschaffen sich Zugang zum Backup-Server und löschen alle Sicherungen, bevor sie die Verschlüsselung der Produktivsysteme starten.
2. Backup-Agenten deinstallieren: Die Backup-Software wird deaktiviert oder deinstalliert, sodass keine neuen Sicherungen mehr erstellt werden.
3. Backups verschlüsseln: Die Backup-Dateien selbst werden verschlüsselt, genau wie die Produktivdaten.
4. Zeitverzögert zuschlagen: Die Angreifer sind wochen- oder monatelang im Netzwerk und warten, bis sie auch die älteren Backup-Generationen kompromittiert haben.

Wie Immutable Backups funktionieren

Immutable Backups nutzen Mechanismen, die das Backup nach dem Schreiben für einen definierten Zeitraum gegen jede Änderung schützen:

Object Lock (S3-kompatible Cloud-Speicher): Amazon S3, Azure Blob Storage und kompatible On-Premises-Lösungen bieten Object Lock im WORM-Modus (Write Once, Read Many). Einmal geschriebene Objekte können bis zum Ablauf der Retention-Periode nicht gelöscht oder überschrieben werden - auch nicht durch den Account-Inhaber. Einen detaillierten Leitfaden zur Einrichtung findest du im Artikel zu Immutable Backups mit S3 Object Lock.

Hardened Linux Repository (Veeam): Veeam bietet ein sogenanntes Hardened Repository auf einem Linux-Server, bei dem die Immutability-Flags auf Dateisystemebene (xattr) gesetzt werden. Selbst mit Root-Zugriff können die Backup-Dateien nicht gelöscht werden, solange die Retention-Periode läuft.

Tape / Air-Gap: Die klassische Variante: Ein Band, das nach dem Beschreiben aus dem Laufwerk genommen und im Tresor eingeschlossen wird, ist per Definition immutable und air-gapped. Kein Netzwerkangriff der Welt kann ein Band im Tresor verschlüsseln.

Implementierungsempfehlung

Für den Mittelstand empfiehlt sich eine Kombination: Primäres Backup auf lokalem Storage für schnelle Restores, ein repliziertes Backup in die Cloud mit Object Lock für den Ransomware-Schutz, und ein wöchentliches Offline-Medium als letzte Verteidigungslinie.

Restore-Tests: Warum und wie oft

Hier kommen wir zum eigentlichen Kern dieses Artikels. Backups erstellen ist die eine Hälfte. Sicherstellen, dass sie im Ernstfall funktionieren, ist die andere - und die wird deutlich häufiger vernachlässigt.

Warum Restore-Tests unverzichtbar sind

Technische Gründe:

• Backup-Medien können physisch beschädigt sein (Bit Rot, defekte Sektoren)
• Backup-Software kann fehlerhafte Sicherungen erstellen, ohne einen Fehler zu melden
• Die Backup-Konsistenz (besonders bei Datenbanken) ist nicht selbstverständlich
• Nach einem Update der Backup-Software oder des Betriebssystems kann der Restore anders funktionieren

Organisatorische Gründe:

• Weiß das Team, wie ein Restore durchgeführt wird? Liegt eine Dokumentation vor?
• Wie lange dauert ein Restore tatsächlich? Passt das zum RTO aus der BIA?
• Sind die nötigen Zugangsdaten (Encryption Keys, Passwörter) verfügbar?
• Funktioniert der Restore auch, wenn der Hauptverantwortliche nicht da ist?

Regulatorische Gründe:

• NIS2 fordert, dass BCM-Maßnahmen (einschließlich Backup) regelmäßig getestet werden
• ISO 27001 (A.8.13) verlangt, dass Backup-Kopien regelmäßig getestet werden
• Auditoren fragen gezielt nach Testprotokollen für Restore-Tests

Empfohlene Test-Frequenz

Was und wie testen

Restore-Tests haben verschiedene Ebenen. Beginne mit den einfachen Tests und steigere die Komplexität.

Ebene 1: Einzelne Dateien und Ordner

Was wird getestet: Können einzelne Dateien aus dem Backup wiederhergestellt werden? Wie: Wähle zufällig 5-10 Dateien verschiedenen Alters aus dem Backup. Stelle sie an einem alternativen Speicherort wieder her. Prüfe, ob die Dateien vollständig und lesbar sind. Dauer: 15-30 Minuten Erfolgskriterium: Alle ausgewählten Dateien sind vollständig wiederherstellbar und inhaltlich korrekt.

Das ist der einfachste Test, und er sollte monatlich laufen. Er deckt Probleme mit dem Backup-Medium auf und stellt sicher, dass die grundlegende Backup-Funktionalität arbeitet. Was er nicht prüft: Ob ein komplettes System wiederhergestellt werden kann und wie lange das dauert.

Ebene 2: Komplette VM oder Server wiederherstellen

Was wird getestet: Kann ein kompletter Server oder eine VM aus dem Backup wiederhergestellt und gestartet werden? Wie: Wähle einen nicht-produktiven Server oder eine Test-VM. Stelle sie aus dem aktuellsten Backup in einer isolierten Umgebung wieder her. Starte die VM und prüfe, ob das Betriebssystem bootet und die Anwendungen starten. Dauer: 2-4 Stunden (je nach Datenmenge und Infrastruktur) Erfolgskriterium: Die VM startet, das Betriebssystem ist funktionsfähig, die Anwendung ist erreichbar.

Wichtig: Stelle die VM in einem isolierten Netzwerk wieder her, um Konflikte mit dem Produktivsystem zu vermeiden (doppelte IP-Adressen, AD-Konflikte, etc.).

Ebene 3: Datenbankwiederherstellung mit Konsistenzprüfung

Was wird getestet: Kann eine Datenbank konsistent wiederhergestellt werden, inklusive Transaction-Log-Replay? Wie: Stelle die Datenbank (z. B. SQL Server, PostgreSQL) aus dem Backup in einer Testumgebung wieder her. Spiele die Transaction-Logs ein. Führe eine Konsistenzprüfung durch (z. B. DBCC CHECKDB bei SQL Server). Prüfe stichprobenartig Datensätze. Dauer: 2-4 Stunden Erfolgskriterium: Datenbank ist konsistent, Transaction-Logs wurden erfolgreich eingespielt, Stichproben zeigen korrekte Daten.

Dieser Test ist besonders wichtig für ERP-Systeme und andere geschäftskritische Anwendungen, deren Datenbanken durch Transaction-Log-Backups auf den neuesten Stand gebracht werden.

Ebene 4: Full Disaster Recovery

Was wird getestet: Können alle kritischen Systeme in der richtigen Reihenfolge wiederhergestellt werden, und wie lange dauert das gesamte Recovery? Wie: Simuliere einen Totalausfall. Stelle alle kritischen Systeme gemäß Wiederanlaufplan wieder her: erst Infrastruktur (AD, DNS), dann Plattformen (Hypervisor, Storage), dann Anwendungen (ERP, Mail). Miss die Zeit für jeden Schritt. Dauer: 1-2 Tage (kann auch über ein Wochenende geplant werden) Erfolgskriterium: Alle kritischen Systeme sind innerhalb der definierten RTO wiederhergestellt und funktionsfähig.

Der Full Disaster Recovery Test ist der aussagekräftigste, aber auch aufwändigste Test. Er validiert nicht nur die Backup-Integrität, sondern auch den Wiederanlaufplan, die Abhängigkeiten zwischen Systemen und die tatsächlichen Recovery-Zeiten. Mindestens einmal jährlich solltest du diesen Test durchführen.

Ebene 5: Bare-Metal-Recovery auf abweichender Hardware

Was wird getestet: Kann ein System auf Hardware wiederhergestellt werden, die sich von der ursprünglichen unterscheidet? Wie: Stelle einen Server aus dem Backup auf einem anderen physischen Server oder in einer Cloud-Umgebung wieder her. Prüfe, ob Treiber, Netzwerkkonfiguration und Anwendungen funktionieren. Dauer: 4-8 Stunden Erfolgskriterium: Das System startet auf der alternativen Hardware und ist funktionsfähig.

Dieser Test ist relevant, weil im Ernstfall möglicherweise nicht die identische Hardware zur Verfügung steht. Einen vertieften Leitfaden dazu findest du im Artikel zu Bare-Metal-Recovery. Wenn der Server physisch zerstört ist (Brand, Wasser), musst du auf das, was gerade verfügbar ist, wiederherstellen können.

RPO-Validierung durch Restore-Tests

Ein oft übersehener Aspekt: Restore-Tests validieren nicht nur, ob das Backup funktioniert, sondern auch ob die Recovery-Zeiten zu den Anforderungen aus der BIA passen.

RTO-Validierung

Miss bei jedem Restore-Test die tatsächliche Wiederherstellungszeit und vergleiche sie mit dem RTO aus der BIA.

Beispiel:

Wenn die tatsächliche Restore-Zeit das RTO überschreitet, hast du drei Optionen:

1. Das RTO anpassen (mit Zustimmung der Geschäftsführung und Bewertung der Konsequenzen)
2. Die Recovery-Infrastruktur verbessern (schnelleres Storage, Instant VM Recovery, vorbereitete Standby-Systeme)
3. Die Datenmenge reduzieren (Archivierung, Auslagerung alter Daten)

RPO-Validierung

Prüfe bei jedem Restore-Test, auf welchen Datenstand du tatsächlich wiederherstellen kannst.

Fragen zur RPO-Validierung:

• Wann war das letzte erfolgreiche Backup? Stimmt das mit der geplanten Backup-Frequenz überein?
• Wenn Transaction-Log-Backups genutzt werden: Können sie erfolgreich eingespielt werden?
• Wie viel Daten gehen zwischen dem letzten Backup und dem Vorfall verloren?
• Passt der tatsächliche Datenverlust zum RPO aus der BIA?

Beispiel: Dein ERP hat ein RPO von 1 Stunde. Du machst stündliche Transaction-Log-Backups. Beim Restore-Test stellst du fest, dass das letzte Transaction-Log-Backup erfolgreich war und du auf den Stand von vor 45 Minuten wiederherstellen kannst. Das RPO wird eingehalten.

Wenn du aber feststellst, dass die Transaction-Log-Backups der letzten drei Tage fehlerhaft waren (weil die Festplatte voll war und niemand die Warnung bemerkt hat), hast du ein ernstes Problem: Dein tatsächliches RPO liegt bei 72 Stunden statt bei 1 Stunde.

Dokumentation der Restore-Tests

Die Dokumentation dient zwei Zwecken: Sie ist der Nachweis für Auditoren (NIS2, ISO 27001), und sie ist die Grundlage für die kontinuierliche Verbesserung deiner Backup-Strategie. In ISMS Lite kannst du Restore-Tests direkt dokumentieren, mit den RPO-Werten aus der BIA abgleichen und fällige Tests automatisch erinnern lassen.

Restore-Test-Protokoll

Für jeden Test dokumentierst du:

RESTORE-TEST-PROTOKOLL

Datum:              [TT.MM.JJJJ]
Durchgeführt von:   [Name]
Geprüft durch:      [Name]

Getestetes Asset:   [Name und Beschreibung]
Backup-Quelle:      [Welches Backup wurde verwendet? Datum/Uhrzeit des Backups]
Backup-Typ:         [Full/Incremental/Differential/Transaction Log]
Restore-Ziel:       [Wohin wurde wiederhergestellt? Produktiv/Test/isoliert?]

TEST-ERGEBNIS

Restore erfolgreich:     □ Ja    □ Nein    □ Teilweise
Dauer des Restores:      [HH:MM]
Wiederhergestellter Datenstand: [Datum/Uhrzeit]

Konsistenzprüfung:       □ Bestanden    □ Nicht bestanden
Funktionstest:           □ Bestanden    □ Nicht bestanden
Stichproben:             □ Korrekt      □ Abweichungen festgestellt

RTO eingehalten:         □ Ja (RTO: [X]h, Actual: [Y]h)    □ Nein
RPO eingehalten:         □ Ja (RPO: [X]h, Datenverlust: [Y]h)    □ Nein

BEMERKUNGEN / ABWEICHUNGEN
[Freitext: Was ist aufgefallen? Probleme? Verbesserungsvorschläge?]

MASSNAHMEN
[Falls Probleme festgestellt: Welche Maßnahmen werden eingeleitet?]

Unterschrift:        [Durchführender]
Datum:               [TT.MM.JJJJ]

Testmatrix: Jahresplan

Erstelle einen Jahresplan, der alle kritischen Assets und die geplanten Tests umfasst:

Legende: Dat = Datei-Restore, VM = VM-Restore, DB = Datenbank-Restore, DR = Disaster Recovery Test

Typische Probleme bei Restore-Tests

Problem 1: Kein isoliertes Testumfeld

Wenn du einen Server aus dem Backup in das Produktivnetzwerk wiederherstellst, riskierst du IP-Konflikte, AD-Replikationsprobleme und im schlimmsten Fall eine Beeinträchtigung des laufenden Betriebs. Restore-Tests gehören in ein isoliertes Netzwerk (separates VLAN, keine Verbindung zum Produktivnetz).

Problem 2: Encryption Keys nicht verfügbar

Verschlüsselte Backups sind nutzlos, wenn der Encryption Key verloren gegangen ist. Sichere die Keys an einem separaten Ort - idealerweise im Passwortmanager und zusätzlich in einem verschlossenen Umschlag im Tresor. Prüfe bei jedem Restore-Test, ob die Keys verfügbar und funktionsfähig sind.

Problem 3: Backup-Software-Version

Die Backup-Software wurde aktualisiert, aber der Restore-Katalog ist inkompatibel. Oder das Backup wurde mit einer älteren Version erstellt, die auf dem aktuellen Backup-Server nicht mehr installiert ist. Prüfe bei jedem Update der Backup-Software, ob ältere Backups noch wiederhergestellt werden können.

Problem 4: Unvollständige Sicherung

Das Backup meldet "erfolgreich abgeschlossen", aber einzelne Dateien wurden übersprungen (geöffnete Dateien, Berechtigungsprobleme, zu lange Pfade). Diese Warnungen gehen im täglichen Betrieb unter. Beim Restore-Test fällt auf, dass bestimmte Daten fehlen.

Lösung: Die täglichen Backup-Berichte nicht nur auf "Erfolg/Fehler" prüfen, sondern auch auf Warnungen und übersprungene Dateien. Automatisiere diese Prüfung, wenn möglich.

Problem 5: Die Backup-Dauer passt nicht zum Backup-Fenster

Das tägliche Full Backup braucht 10 Stunden, aber das Backup-Fenster (nachts, wenn die Systeme wenig Last haben) beträgt nur 6 Stunden. Das Backup wird jede Nacht abgebrochen und ist unvollständig. Im Restore-Test zeigt sich: Das letzte vollständige Backup ist drei Wochen alt.

Lösung: Backup-Strategie an das verfügbare Fenster anpassen. Incremental Backups statt Full Backups unter der Woche, Full Backup nur am Wochenende. Oder Backup-Infrastruktur beschleunigen (schnelleres Netzwerk, schnellerer Storage, Deduplizierung).

Backup-Monitoring und Alerting

Tests sind der eine Teil. Der andere ist die tägliche Überwachung, ob die Backups überhaupt durchlaufen.

Was du überwachen solltest

Wer bekommt die Alerts?

Backup-Alerts dürfen nicht in einer überfüllten Inbox untergehen. Definiere klar, wer die Alerts erhält und wer verantwortlich ist, auf Fehler zu reagieren.

Bewährt hat sich: Automatische Alerts per E-Mail und SMS an den zuständigen Administrator, täglicher Backup-Report per E-Mail an den IT-Leiter, wöchentlicher Zusammenfassungs-Report an die IT-Leitung mit Erfolgsquote und offenen Problemen.

Backup-Strategie und Regulierung

NIS2

NIS2 fordert in Artikel 21, Absatz 2c explizit "Backup-Management und Wiederherstellung nach einem Notfall" als eine der Mindestmaßnahmen. Das bedeutet:

• Backups müssen existieren und dokumentiert sein
• Die Backup-Strategie muss zum Schutzbedarf der Daten passen
• Restore-Prozesse müssen getestet werden
• Im Audit musst du Nachweise vorlegen (Backup-Konzept, Test-Protokolle)

ISO 27001

ISO 27001, Annex A, Kontrolle A.8.13 fordert: "Sicherungskopien von Informationen, Software und Systemabbildern müssen in Übereinstimmung mit einer vereinbarten Backup-Richtlinie erstellt und regelmäßig getestet werden."

Das "regelmäßig getestet" ist der entscheidende Punkt. Die Kontrolle verlangt nicht nur Backups, sondern Nachweise, dass sie funktionieren. Auditoren fragen nach Restore-Test-Protokollen und wollen sehen, dass die Tests systematisch und regelmäßig durchgeführt werden. Wer sein ISMS selbst hostet, steht dabei vor besonderen Anforderungen an die Backup-Strategie für selbst gehostete Compliance-Systeme.

Nächste Schritte

Eine solide Backup-Strategie und regelmäßige Restore-Tests sind kein Luxus, sondern Grundvoraussetzung für jedes Business Continuity Management. Die wichtigsten Punkte zusammengefasst:

1. 3-2-1-1 umsetzen - drei Kopien, zwei Medientypen, ein Offsite, ein Immutable. Prüfe, wo deine aktuelle Strategie Lücken hat.
2. Immutable Backups einführen - wenn du es noch nicht hast, ist das die wichtigste Einzelmaßnahme gegen Ransomware.
3. Restore-Test-Kalender erstellen - plane Tests für verschiedene Ebenen (Dateien, VMs, Datenbanken, Full DR) über das Jahr verteilt.
4. RPO aus der BIA abgleichen - stimmen Backup-Frequenz und tatsächlicher Datenverlust bei Restore mit dem RPO überein?
5. Monitoring einrichten - tägliche Überwachung der Backup-Jobs, Alerting bei Fehlern.
6. Dokumentieren - Backup-Konzept, Restore-Test-Protokolle und Maßnahmenplan. Das brauchst du für die interne Verbesserung und für jeden Auditor.

Weiterführende Artikel

• Wiederanlaufplan erstellen: Anleitung mit Vorlage für den Mittelstand
• Notfallhandbuch für die IT: Aufbau, Inhalt und PDF-Vorlage
• Business Impact Analyse (BIA) durchführen: Geschäftsprozesse bewerten
• IT-Asset-Management für das ISMS: Inventar, Kritikalität und Klassifizierung
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel

Wenn du die BIA noch nicht durchgeführt hast, die dir die RPO-Werte liefert, starte mit dem Artikel zur Business Impact Analyse. Und wenn du deinen gesamten Notfallprozess testen willst, hilft dir der Artikel zu Tabletop-Übungen weiter.