Datensicherung ist der Bereich, in dem die meisten Unternehmen glauben, vorbereitet zu sein – bis sie es ausprobieren müssen. Der entscheidende Satz: Eine Sicherung, deren Wiederherstellung nie geprüft wurde, ist eine Annahme, keine Sicherung.
Die 3-2-1-Regel – und warum sie nicht reicht
3-2-1:
3 Kopien der Daten (Original + 2 Sicherungen)
2 verschiedene Medien oder Systeme
1 Kopie ausserhalb des Standorts
Erweiterung 3-2-1-1-0:
+1 Kopie ausserhalb des Netzes (unveraenderlich/offline)
+0 Fehler bei der Wiederherstellung (GEPRUEFT!)
Warum die Erweiterung noetig ist:
Ransomware verschluesselt ALLES, was erreichbar ist.
Eine Sicherung im gleichen Netz mit denselben
Zugangsdaten ist mitbetroffen.
# Die haeufigste Ursache fuer Totalverluste ist nicht
# der Angriff, sondern die mitverschluesselte Sicherung.
Wichtig: EINE Kopie muss UNVERAENDERLICH sein
- Band (nach dem Schreiben physisch getrennt)
- Objektspeicher mit Aufbewahrungssperre (WORM)
- Sicherungslaufwerk, das nur zeitweise verbunden ist
# "Unveraenderlich" heisst: Auch der Administrator
# kann die Daten in der Aufbewahrungsfrist nicht loeschen.
# Nur das schuetzt gegen einen Angreifer mit
# Administratorrechten.Die drei Sicherungsarten
VOLLSTAENDIG (full)
Alles wird gesichert.
Vorteil: Wiederherstellung in einem Schritt
Nachteil: Gross, langsam, viel Speicher
DIFFERENTIELL (differential)
Alles seit der letzten VOLLstaendigen.
Wiederherstellung: letzte volle + letzte differenzielle
Vorteil: zwei Bausteine, einfach
Nachteil: waechst taeglich bis zur naechsten vollen
INKREMENTELL (incremental)
Alles seit der letzten Sicherung (egal welcher Art).
Wiederherstellung: volle + ALLE inkrementellen in
richtiger Reihenfolge
Vorteil: klein, schnell
Nachteil: Kette! Eine fehlerhafte Sicherung in der
Mitte macht alle spaeteren unbrauchbar (typische
Fehlerquelle bei Bandbestaenden)
Empfehlung fuer die Praxis:
Woechentlich vollstaendig + taeglich inkrementell
+ die Moeglichkeit, aus einer Kette wiederherzustellen
# Und: die Kette MESSEN, nicht hoffen.
SYNTHETISCH (synthetic full)
Moderne Werkzeuge erzeugen aus der vollen Sicherung
und den inkrementellen eine neue "volle", ohne die
Quelldaten erneut zu lesen.
Vorteil: Wiederherstellung immer nur zwei Bausteine
# Sehr praktisch, um Ketten zu vermeiden.Wiederherstellungsziele
Zwei Zahlen bestimmen die gesamte Planung:
RPO (Recovery Point Objective)
Wie viel Datenverlust ist akzeptabel?
RPO = 1 Stunde -> Sicherungen mindestens stuendlich
RPO = 24 Stunden -> taegliche Sicherung genuegt
# Die Frage lautet: "Wie viel Arbeit duerfen wir
# verlieren?" Nicht: "Wie oft kann ich sichern?"
RTO (Recovery Time Objective)
Wie lange darf die Wiederherstellung dauern?
RTO = 4 Stunden -> Uebung muss zeigen, dass es geht!
# Ein RTO ohne gemessene Uebung ist ein Wunsch.
Pruefen ob die Werkzeuge das koennen:
50 TB Daten in 4 Stunden zurueckholen = 3,5 GB/s
# Das schafft kaum eine Bandbibliothek. Wer solche
# Zahlen zusagt, muss sie messen - oder die Zusage
# anpassen.
Beispielhafte Ziele:
Datenbank (Bestellungen) RPO 5 min, RTO 1 h
Dateiablage RPO 24 h, RTO 8 h
Firmenwiki RPO 24 h, RTO 24 h
Konfiguration (Infra) oft aus Git wiederherstellbar
RPO 0, RTO 1 hDer wichtigste Teil: Prüfen
# Ohne diesen Teil ist alles Vorherige wertlos.
# 1) Regelmaessiger Wiederherstellungstest
# Mindestens vierteljaehrlich, dokumentiert:
# Datum, was wiederhergestellt wurde,
# Dauer, Ergebnis, Abweichungen
# # Ein Ticket mit diesen Angaben ist der Nachweis.
# 2) Automatisierte Pruefung jeder Sicherung
# - Wurde die Sicherung erstellt? (Zeitstempel)
# - Ist sie vollstaendig? (Ende-Status des Auftrags)
# - Groesse im erwarteten Bereich? (Ausreisser = Alarm!)
# - Anzahl Dateien im erwarteten Bereich?
# - Pruefsummen (bei Werkzeugen, die das unterstuetzen)
# # Der haeufigste Ausfall: Keine Sicherung erstellt,
# # und niemand hat es gemerkt, weil keine Ueberwachung
# # der Sicherungsauftraege existierte.
# 3) Alarm bei Fehlschlag
# Ein fehlgeschlagener Sicherungsauftrag MUSS eine
# Meldung erzeugen. Nicht in einem taeglichen Bericht,
# den niemand liest, sondern als Alarm.
# Schwelle: Eine Nacht ohne Sicherung = Alarm.
# 4) Widerherstellung ueben - das ganze Verfahren
# Nicht nur "Datei zurueckgeholt", sondern:
# - Auf anderer Hardware?
# - Von der Offline-Kopie?
# - Mit dem vollstaendigen Verfahren (auch Konfiguration,
# Zugangsdaten, DNS-Umstellung)?
# # Die eigentliche Zeitfalle ist nicht die Datenmenge,
# # sondern die Wiederherstellung der Umgebung drumherum.
# 5) Pruefen, dass die Sicherung nicht mitverschluesselt wurde
# Stichprobe: Datei aus der Sicherung oeffnen.
# # Eine Sicherung kann technisch "erfolgreich" sein
# # und trotzdem verschluesselten Inhalt enthalten.Sicherungen für Anwendungen richtig machen
# Die haeufigste Falle: Datenbankdateien im laufenden
# Betrieb kopieren. Ergebnis: eine Sicherung, die
# beim Zurueckspielen inkonsistent ist.
# FALSCH: Dateien einfach kopieren
cp -r /var/lib/postgresql/data /sicherung/ # NEIN!
# RICHTIG: Werkzeuge der Datenbank verwenden
pg_dump -Fc -f /sicherung/db.dump meine_db # PostgreSQL
mysqldump --single-transaction meine_db > dump.sql # MySQL/MariaDB
sqlite3 daten.db ".backup /sicherung/daten.db" # SQLite (auch im Betrieb!)
# Oder: Momentaufnahme und diese sichern
# LVM-Snapshot, ZFS-Snapshot, Speicher-Snapshot
lvcreate --size 5G --snapshot --name schnapp /dev/vg/daten
# Dann aus dem Schnapp sichern und ihn danach loeschen.
# # Nachteil: Die Momentaufnahme waechst mit den Aenderungen.
# # Kurz halten!
# Bei Kubernetes: PersistentVolumeClaims sichern
# (Velero oder Kasten) - nicht die Dateien des Knotens
# Anwendungsdaten und Datenbank MUESSEN zusammenpassen:
# Eine Datenbank aus 10:00 und Dateien aus 12:00
# sind inkonsistent. Beide aus demselben Zeitpunkt
# sichern (Momentaufnahme fuer beide oder Anwendung
# kurz anhalten / in Lese-Modus setzen).Prüfliste
- Gibt es drei Kopien auf zwei Medien, eine davon außer Haus?
- Ist eine Kopie unveränderlich (WORM, Band, getrenntes Laufwerk)?
- Sind RPO und RTO je Dienst definiert?
- Ist die Wiederherstellung in den letzten 3 Monaten getestet worden – mit Protokoll?
- Wird jeder Sicherungsauftrag automatisch auf Erfolg geprüft?
- Löst ein fehlgeschlagener Sicherungsauftrag einen Alarm aus?
- Ist die Größe der Sicherungen auf Ausreißer geprüft?
- Wird die Sicherung mit den Werkzeugen der Anwendung erstellt (nicht durch Dateikopie)?
- Werden Datenbank und Dateien aus demselben Zeitpunkt gesichert?
- Sind die Aufbewahrungsfristen definiert (und eingehalten)?
- Ist der Zugriff auf die Sicherungen beschränkt (nicht mit denselben Konten wie das Produktivsystem)?
- Ist die Wiederherstellung von der Offline-Kopie einmal geübt?
Häufige Fehler
- Keine Prüfung der Wiederherstellung. Der häufigste und teuerste Fehler. Der Bericht „Sicherung erfolgreich“ bezieht sich auf den Schreibvorgang, nicht auf die Brauchbarkeit.
- Sicherung im gleichen Netz mit gleichen Konten. Ransomware erreicht sie. Unveränderliche Kopie ist Pflicht.
- Fehlgeschlagene Aufträge ohne Alarm. Drei Wochen ohne Sicherung – und niemand hat es bemerkt.
- Dateikopie statt Anwendungswerkzeug. Liefert bei Datenbanken inkonsistente Sicherungen.
- Größenausreißer ignoriert. Eine plötzlich halb so große Sicherung ist ein Warnsignal (Sicherung unvollständig oder Daten verschwunden).
- Zu lange Ketten. Bei inkrementellen Sicherungen ohne synthetische Vollkopie wird die Wiederherstellung lang und fehleranfällig.
- Keine RPO/RTO definiert. Ohne Ziele weiß man nicht, ob die Sicherung ausreicht – und plant entweder zu viel oder zu wenig.
- Ungeprüfte Sicherung zurückgespielt. Rückkehr des Schadcodes, wenn die Kompromittierung vor der Sicherung begann.
- Aufbewahrung vergessen. Sicherungen werden nie gelöscht und wachsen unbegrenzt – oder die Aufbewahrung ist kürzer als die Erkennungszeit eines Angriffs.
Verwandte Grundlagen: Backup, 3-2-1-Regel konkret, Datenbank-Backup, Vorfallbehandlung.