10.1 Datensicherungskonzept
Ein Datensicherungskonzept beschreibt verbindlich, welche Daten und Systeme gesichert werden, wie häufig und wie lange Sicherungen aufbewahrt werden, wer verantwortlich ist und wie eine Wiederherstellung abläuft. Ein technisch erfolgreich gemeldeter Backupjob genügt nicht: Erst ein geprüfter Restore zeigt, ob Daten im geforderten Zeitraum tatsächlich wieder nutzbar sind.
Warum ein Sicherungskonzept notwendig ist
Datenverlust entsteht nicht nur durch defekte Laufwerke. Häufige Ursachen sind Fehlbedienung, fehlerhafte Software, beschädigte Dateisysteme, kompromittierte Zugangsdaten, Schadsoftware, Diebstahl, Brand, Wasser, Ausfall eines Standorts oder eine fehlerhafte Änderung. Ein Konzept betrachtet deshalb Technik, Organisation, Personal, Sicherheit und Notfallabläufe gemeinsam.
Eine Datensicherung erzeugt einen zeitlich getrennten Datenbestand, aus dem sich ein früherer Zustand wiederherstellen lässt. RAID, synchrone Replikation und Hochverfügbarkeit erhöhen die Verfügbarkeit, übernehmen Fehler oder Löschvorgänge aber möglicherweise sofort und sind daher allein kein Backup. Auch ein Snapshot ist nur dann ein belastbarer Sicherungsbaustein, wenn Aufbewahrung, Unabhängigkeit, Schutz und Wiederherstellung passend geplant sind.
- Backup: kontrollierte Sicherung von Daten, Konfigurationen und gegebenenfalls vollständigen Systemzuständen.
- Restore: Rücksicherung einzelner Objekte, Anwendungen, Systeme oder kompletter Umgebungen.
- Disaster Recovery: Wiederanlauf nach einem größeren Ausfall anhand priorisierter Verfahren.
- Archivierung: langfristige, regelgebundene Aufbewahrung; verfolgt andere Ziele als ein operatives Backup.
Die sieben Schritte des Datensicherungskonzepts
Geschäftsprozesse, Systeme, Daten, Abhängigkeiten, Bedrohungen, rechtliche Vorgaben sowie RPO und RTO ermitteln.
Sicherungsintervalle, Aufbewahrung, Versionen, Standorte, Verantwortlichkeiten und Prioritäten festlegen.
Voll-, inkrementelle, differenzielle, imagebasierte, anwendungskonsistente oder andere geeignete Verfahren kombinieren.
Software, Speicherziele, Netz, Konten, Verschlüsselung, Automatisierung und Alarmierung sicher einrichten.
Jobs, Kapazität, Aufbewahrung, Integrität und Unveränderbarkeit kontrollieren; Fehler verbindlich bearbeiten.
Restore-Reihenfolge, Ersatzsysteme, Schlüssel, Zugangsdaten, Zuständigkeiten und Kommunikationswege praktisch erproben.
Konfigurationen, Abläufe und Testergebnisse aktuell halten und nach Änderungen oder Vorfällen anpassen.
Anforderungsanalyse mit den W-Fragen
| Frage | Zu klärende Punkte | Beispiel |
|---|---|---|
| Was wird gesichert? | Dateien, Datenbanken, virtuelle Maschinen, Verzeichnisdienste, Konfigurationen, Zertifikate, Quellcode und Cloud-Daten | Neben Nutzdaten auch Wiederaufbauinformationen und Schlüssel berücksichtigen. |
| Warum wird gesichert? | Betriebsfortführung, Schutz vor Fehlbedienung oder Angriff, Nachweis- und Aufbewahrungspflichten | Ziele bestimmen Aufbewahrung und Schutzbedarf. |
| Wie viel? | Aktuelles Datenvolumen, Änderungsrate, Kompression, Deduplizierung und erwartetes Wachstum | Kapazitätsreserve und Ablauf alter Sicherungen planen. |
| Wann und wie oft? | Geschäftszeiten, Änderungsrate, RPO, Sicherungsfenster und Netzlast | Kritische Daten häufiger als selten veränderte Archive sichern. |
| Wohin? | Lokales Repository, Band, getrenntes Rechenzentrum, Cloud oder Kombination | Mindestens eine unabhängige Fehlerdomäne einplanen. |
| Wie lange? | Versionierung, Aufbewahrungsfristen, Löschkonzept und Speicherbedarf | Kurzfristige viele Versionen und langfristige ausgewählte Stände kombinieren. |
| Wer? | Datenverantwortliche, IT-Betrieb, Informationssicherheit, Datenschutz, Dienstleister und Vertretungen | Erstellung, Kontrolle und Restore-Freigabe klar trennen. |
| Wie wird geprüft? | Jobstatus, Integritätsprüfung, Stichproben, Teilrestore und vollständiger Wiederanlauftest | Ein regelmäßiger Test muss Daten und benötigte Zeit bewerten. |
RPO, RTO und Aufbewahrung
Das Recovery Point Objective, RPO, beschreibt den maximal akzeptierten Datenverlust gemessen als Zeitspanne. Bei einem RPO von vier Stunden muss die Sicherungs- oder Replikationsstrategie gewährleisten, dass im vorgesehenen Schadensfall höchstens die Änderungen der letzten vier Stunden fehlen.
Das Recovery Time Objective, RTO, beschreibt die maximal akzeptierte Zeit bis zur Wiederherstellung eines Dienstes. Dazu gehören nicht nur das Kopieren der Daten, sondern auch Bereitstellung von Hardware oder Cloudressourcen, Installation, Schlüsselzugriff, Abhängigkeiten, Validierung und Freigabe. RPO und RTO sind geschäftliche Anforderungen und dürfen nicht allein vom verfügbaren Backupwerkzeug bestimmt werden.
Aufbewahrungsdauer und Anzahl der Wiederherstellungspunkte müssen getrennt betrachtet werden. Viele kurzfristige Versionen helfen bei häufigen Änderungen; monatliche oder jährliche Stände können Nachweis- oder Langzeitbedarf abdecken. Personenbezogene Daten dürfen nicht ohne Zweck und Rechtsgrundlage unbegrenzt in Sicherungen verbleiben. Lösch-, Sperr- und Wiederherstellungsverfahren sind deshalb gemeinsam zu planen.
| Anforderung | Leitfrage | Auswirkung auf das Konzept |
|---|---|---|
| RPO | Wie alt darf der jüngste wiederherstellbare Stand höchstens sein? | Sicherungs- und gegebenenfalls Replikationsintervall |
| RTO | Wie lange darf der Dienst ausfallen? | Restore-Technik, Priorität, Personal, Ersatzressourcen und Bandbreite |
| Retention | Wie lange werden welche Wiederherstellungspunkte benötigt? | Kapazität, Medienrotation, Unveränderbarkeit und Löschregeln |
| Wiederanlaufreihenfolge | Welche Abhängigkeiten müssen zuerst verfügbar sein? | Runbook für Identität, Netzwerk, Storage, Datenbank und Anwendung |
3-2-1-1-0 als Planungsregel
Die 3-2-1-Regel empfiehlt drei aktuelle Datenkopien auf zwei geeigneten Speicherarten, davon mindestens eine an einem getrennten Ort. Moderne Erweiterungen ergänzen eine offline, air-gapped oder unveränderbare Kopie und das Ziel null ungeprüfter Fehler nach automatischer Kontrolle und Restore-Test.
Die Zählweise ist eine Planungsregel und kein Produktstandard. Zwei Ordner auf demselben NAS sind keine unabhängigen Kopien. Auch ein Cloudziel ist nicht automatisch getrennt, wenn dieselben kompromittierten Administratorkonten alle Sicherungen löschen können. Unabhängige Identitäten, Mehrpersonenfreigaben, unveränderbare Aufbewahrung und getrennte Fehlerdomänen verbessern den Schutz.
Daten und Systeme kategorisieren
Nicht alle Informationen benötigen dieselbe Sicherung. Eine Klassifizierung verhindert sowohl Unterversorgung kritischer Systeme als auch unnötige Kosten für unkritische oder reproduzierbare Daten. Kategorien müssen mit den jeweiligen Daten- und Prozessverantwortlichen abgestimmt werden.
| Kriterium | Mögliche Kategorien | Folge für die Sicherung |
|---|---|---|
| Geschäftlicher Wert | geschäftskritisch, wichtig, unterstützend, reproduzierbar | Priorität, RPO, RTO und Testtiefe |
| Schutzbedarf | normal, hoch, sehr hoch bezüglich Vertraulichkeit, Integrität und Verfügbarkeit | Verschlüsselung, Zugriff, Standort und Protokollierung |
| Rechtliche Bindung | Aufbewahrungspflicht, Löschpflicht, Nachweisbedarf, Vertragsvorgabe | Retention, Unveränderbarkeit und dokumentierte Löschung |
| Datenart | Datenbank, Benutzerdatei, Konfiguration, VM, Quellcode, Protokoll, Medienbestand | Anwendungskonsistenz und passendes Restore-Verfahren |
| Änderungsrate | kontinuierlich, täglich, selten, unverändert | Sicherungsintervall und Versionenzahl |
| Datenmenge und Wachstum | klein bis sehr groß, stabil bis stark wachsend | Kapazität, Bandbreite, Sicherungsfenster und Kosten |
| Reproduzierbarkeit | nicht ersetzbar, aus Quelle erneut erzeugbar, Installationsmedium verfügbar | Priorität und notwendiger Sicherungsumfang |
Speicherziele und Medien auswählen
| Ziel oder Medium | Stärken | Grenzen und Schutzmaßnahmen |
|---|---|---|
| Externes Laufwerk | Einfach, transportabel und für kleine Umgebungen günstig | Nach der Sicherung trennen, verschlüsseln, sicher lagern und Medienzustand überwachen. |
| Backup-Repository / Server | Automatisierung, zentrale Verwaltung und schnelle Restores | Vom Produktivnetz und von Standardadministratoren logisch trennen; RAID allein ist kein Backup. |
| NAS | Dateibasierter Zugriff, zentrale Kapazität und einfache Integration | Snapshots, getrennte Konten, unveränderbare Bereiche oder replizierte Kopie vorsehen. |
| Band | Hohe Kapazität, transportierbar und nach Entnahme physisch offline | Laufwerke, Medienrotation, passende Lagerung, Katalog und regelmäßige Lesetests erforderlich. |
| Cloud-Backup | Externer Standort, skalierbare Kapazität und verwaltete Funktionen möglich | Identitäten, Kosten, Datenstandort, Exit-Strategie, Bandbreite, Verschlüsselung und Anbieterabhängigkeit bewerten. |
| Optische Medien | Je nach Medium offline und für ausgewählte kleine Bestände geeignet | Begrenzte Kapazität, Alterung, Laufwerksverfügbarkeit und Schreibaufwand; heute eher Spezialfall. |
| USB-Stick | Kompakt und unkompliziert | Für alleinige regelmäßige Unternehmenssicherung meist ungeeignet: Verlust, Verschleiß und fehlende Zustandskontrolle. |
DAS, NAS und SAN unterscheiden
DAS ist nicht grundsätzlich „nicht teilbar“: Ein Host kann direkt angeschlossenen Speicher über Dateidienste an andere Systeme freigeben. Die Speicheranbindung selbst bleibt jedoch direkt. NAS und SAN beschreiben ebenfalls keine Sicherungsmethode, sondern die Art der Speicherbereitstellung.
| Architektur | Bereitstellung | Typischer Zugriff | Einordnung für Backups |
|---|---|---|---|
| DAS - Direct Attached Storage | Speicher ist direkt mit einem Host verbunden, intern oder extern. | Blockgerät für diesen Host, beispielsweise SATA, SAS, NVMe oder USB | Einfaches lokales Ziel; physische und logische Trennung sowie Medienrotation beachten. |
| NAS - Network Attached Storage | Ein Speichersystem stellt Dateifreigaben im IP-Netz bereit. | Dateiebene, beispielsweise SMB oder NFS | Zentrales Repository möglich; nicht automatisch gegen kompromittierte Konten oder Standortausfall geschützt. |
| SAN - Storage Area Network | Ein Speichernetz stellt Servern entfernte Blockgeräte beziehungsweise LUNs bereit. | Blockebene, häufig Fibre Channel oder iSCSI; weitere Varianten sind möglich | Hohe Leistung und zentrale Storagefunktionen; produktives SAN und Backupkopie müssen dennoch getrennte Risiken abdecken. |
Sicherungsmethode und Anwendungskonsistenz
Dateikopie, Imagebackup, Snapshot, Vollsicherung sowie inkrementelle und differenzielle Verfahren haben unterschiedliche Eigenschaften. Kapitel 10.2 behandelt diese Methoden ausführlich. Für das Konzept ist zunächst entscheidend, welches Wiederherstellungsziel jede Methode erfüllt und welche Abhängigkeiten bestehen.
Bei laufenden Datenbanken, Verzeichnisdiensten und virtuellen Maschinen reicht ein beliebiger Kopierzeitpunkt nicht immer aus. Crash-konsistente Sicherungen entsprechen ungefähr einem unerwarteten Stromausfall. Anwendungskonsistente Sicherungen koordinieren Schreibpuffer, Transaktionen und gegebenenfalls Protokolle. Das eingesetzte Verfahren muss von Anwendung und Hersteller unterstützt und im Restore getestet werden.
- Metadaten, Berechtigungen, Eigentümer, Zeitstempel, Links und erweiterte Attribute bei Bedarf mit sichern.
- Konfigurationsdateien, Lizenzinformationen, Zertifikate und Schlüssel samt sicherem Wiederherstellungsweg berücksichtigen.
- Abhängigkeiten wie DNS, Identitätsdienst, Datenbank, Secrets und Netzkonfiguration in die Wiederanlaufplanung aufnehmen.
- Deduplizierung und Kompression sparen Speicher, dürfen aber nicht die einzige Integritätskontrolle ersetzen.
Sicherheit der Sicherungsumgebung
Backup-Systeme besitzen weitreichende Zugriffe und enthalten häufig den vollständigen Datenbestand eines Unternehmens. Sie sind daher ein besonders wertvolles Angriffsziel. Verwaltung, Datenübertragung, gespeicherte Sicherungen und Schlüsselverwaltung müssen als eigene Sicherheitszone geplant werden.
- Separate Administrationskonten und Mehrfaktor-Authentisierung verwenden; tägliche Benutzerkonten nicht für Backupadministration einsetzen.
- Minimal notwendige Rechte vergeben und Löschung oder Verkürzung der Aufbewahrung besonders schützen.
- Sicherungen bei Übertragung und Speicherung angemessen verschlüsseln; Schlüssel getrennt sichern und Wiederherstellung testen.
- Offline- oder unveränderbare Kopie vorsehen, die kompromittierte Produktiv- oder Backupkonten nicht sofort verändern können.
- Backupverkehr, Verwaltungszugriff und Repository nach Möglichkeit segmentieren und überwachen.
- Manipulationen, fehlgeschlagene Jobs, Kapazitätsengpässe und Änderungen an Richtlinien alarmieren.
Überwachung, Validierung und Restore-Tests
- Testergebnis, Dauer, verwendeten Wiederherstellungspunkt, Abweichungen und Folgemaßnahmen dokumentieren.
- Tests isoliert durchführen, damit alte Systeme oder Daten keine Produktion, Identitäten oder Netzwerke beeinflussen.
- Nach Änderungen an Anwendung, Infrastruktur, Backupsoftware oder Schlüsseln erneut testen.
| Prüfebene | Was wird geprüft? | Warum reicht die vorherige Ebene nicht? |
|---|---|---|
| Jobstatus | Start, Ende, Laufzeit, Datenmenge und gemeldete Fehler | Ein grüner Job kann unvollständige Auswahl oder fachlich falsche Daten enthalten. |
| Integrität | Prüfsummen, Katalog, Lesbarkeit und Konsistenz des Sicherungssatzes | Lesbare Blöcke garantieren noch keine startfähige Anwendung. |
| Objekt-Restore | Einzelne Datei, Nachricht, Tabelle oder Konfiguration zurückholen | Beweist nicht den vollständigen Wiederanlauf aller Abhängigkeiten. |
| System-Restore | System oder VM in isolierter Umgebung wiederherstellen und starten | Startfähigkeit allein belegt noch keine fachlich korrekte Anwendung. |
| Notfallübung | Priorisierte Dienste, Personal, Kommunikation, RPO und RTO unter realistischen Bedingungen prüfen | Erst die Übung bewertet Technik, Ablauf und Verantwortung gemeinsam. |
Notfallwiederherstellung als Schritt-für-Schritt-Plan
Ursache, betroffene Systeme und möglichen Angriff klären; Wiederherstellung nicht in eine weiterhin kompromittierte Umgebung starten.
Notfallleitung, Technik, Fachverantwortliche, Informationssicherheit, Datenschutz und Dienstleister nach Plan einbinden.
Vertrauenswürdige Identitäten, Netz, Hardware oder Cloudressourcen sowie notwendige Schlüssel vorbereiten.
Zeitpunkt anhand des Schadensverlaufs wählen und Sicherung auf Integrität sowie Schadsoftware prüfen.
Beispielsweise Netzwerk, DNS, Identität, Storage, Datenbank und danach Anwendungen wiederherstellen.
Start, Datenkonsistenz, Berechtigungen, Schnittstellen und Geschäftsprozesse durch zuständige Personen prüfen.
Produktionsfreigabe dokumentieren, verstärkt überwachen und Erkenntnisse in Konzept und Schutzmaßnahmen übernehmen.
Was in der Dokumentation stehen muss
- Geltungsbereich, Daten- und Systeminventar einschließlich Verantwortlicher und Abhängigkeiten
- Schutzbedarf, Bedrohungen, RPO, RTO, Aufbewahrung und Wiederanlaufreihenfolge
- Sicherungsplan mit Verfahren, Zeitplan, Speicherzielen, Versionen und Kapazitätsplanung
- Architektur, Konten, Rollen, Schlüsselverwaltung, Verschlüsselung und Netzwerkpfade
- Überwachung, Alarmwege, Vertretung, Eskalation und regelmäßige Kontrollaufgaben
- Restore-Anleitungen für Einzelobjekte, Systeme und den vollständigen Notfall
- Testkalender, Protokolle, Ergebnisse, Abweichungen und verantwortliche Folgemaßnahmen
- Änderungshistorie sowie regelmäßiger und anlassbezogener Überprüfungstermin
Zusammenfassung
Ein belastbares Datensicherungskonzept beginnt bei Geschäftsanforderungen und endet nicht beim erfolgreichen Backupjob. Es verbindet Datenklassifizierung, RPO, RTO, Sicherungsmethoden, Speicherziele, Schutzmaßnahmen, Verantwortlichkeiten, Dokumentation und getestete Wiederherstellung.
Die zentrale Kontrollfrage lautet: Können die benötigten Daten und Dienste nach dem vorgesehenen Schadensfall vollständig, vertrauenswürdig und innerhalb der vereinbarten Zeit wiederhergestellt werden? Wenn dies nicht praktisch nachgewiesen wurde, ist die Sicherung noch nicht ausreichend validiert.
Quellen zur fachlichen Prüfung
- BSI IT-Grundschutz: CON.3 Datensicherungskonzept
- BSI Standard 200-4: Vorschläge zu Business-Continuity-Strategien
- CISA: StopRansomware Guide - offline, verschlüsselte und getestete Backups
- NIST SP 800-34 Rev. 1: Contingency Planning Guide
- Microsoft Learn: Schutz und Wiederherstellbarkeit unveränderbarer Backup-Vaults
PDF-Download nach Anmeldung
Zum Schutz der Unterrichtsunterlagen steht der PDF-Download ausschließlich angemeldeten Nutzern zur Verfügung.