Aufgaben Backup

Lösung

Vollsicherung: Alle Daten werden vollständig gesichert. Speicherbedarf: 100% pro Backup.

Differenzielle Sicherung: Es werden alle Änderungen seit der letzten Vollsicherung gesichert. Der Speicherbedarf wächst täglich. Beispiel: nach 6 Tagen ca. 15-20% einer Vollsicherung.

Inkrementelle Sicherung: Es werden nur die Änderungen seit der letzten beliebigen Sicherung gesichert. Sehr geringer Speicherbedarf pro Tag. Beispiel: ~2-5% einer Vollsicherung pro Tag. Restore aufwendig: Vollsicherung + alle Inkremente in Reihe nötig.

Mehr in L2.

Lösung

Die 3-2-1-Regel beschreibt das Mindest-Setup für Datensicherung:

• 3 Kopien der Daten – 1 Original (produktives System) + 2 Backup-Kopien
• 2 verschiedene Medien – z.B. HDD und Tape, oder NAS und Cloud. Schützt gegen medienspezifische Ausfälle.
• 1 Off-Site-Kopie – mindestens eine Kopie an einem anderen physischen Standort. Schützt gegen Brand, Wasser, Diebstahl.

Konkretes Beispiel für ein Kleinunternehmen: File-Server im Büro (Kopie 1) + NAS im Büro mit HDDs (Kopie 2) + tägliches Backup zu Hetzner Storage Box in anderem Rechenzentrum (Kopie 3, off-site).

Moderne Erweiterung: 3-2-1-1-0 mit +1 immutable Kopie (gegen Ransomware) und 0 Fehler im Restore-Test.

Lösung

RTO (Recovery Time Objective): maximale Zeitspanne, in der ein System nach einem Ausfall wieder verfügbar sein muss. Bestimmt die Restore-Geschwindigkeit und damit die benötigte Technologie: niedriger RTO erfordert schnelle Storage-Medien, ggf. Hot-Standby-Systeme.

RPO (Recovery Point Objective): maximaler Datenverlust, der akzeptabel ist. Bestimmt die Backup-Frequenz: RPO = 24h → tägliches Backup, RPO = 15 min → kontinuierliche Snapshots oder Replikation.

Festlegung der Werte erfolgt durch eine Business Impact Analyse (BIA):

• Ermittlung der Geschäftsprozesse und ihrer Kritikalität
• Berechnung der Kosten pro Stunde Ausfall
• Datenverlust-Toleranz pro System
• Abwägung gegen Kosten der Schutzmaßnahmen (Kosten steigen exponentiell mit sinkendem RTO/RPO)

Mehr in L6.

Lösung

a) Tägliche Vollsicherung: 7 × 100 GB = 700 GB / Woche

b) Voll + differenziell: Sonntag 100 GB (Voll), dann täglich kumulativ:

• Mo: 5 GB, Di: 10 GB, Mi: 15 GB, Do: 20 GB, Fr: 25 GB, Sa: 30 GB
• Summe Diff: 5+10+15+20+25+30 = 105 GB
• Gesamt: 100 + 105 = 205 GB / Woche

c) Voll + inkrementell: Sonntag 100 GB, dann jeden Tag 5 GB:

• Summe Inc: 6 × 5 = 30 GB
• Gesamt: 100 + 30 = 130 GB / Woche

Vergleich: Inkrementell ist am sparsamsten (~19% von a), differenziell guter Mittelweg (~29%), Vollsicherung am teuersten aber einfachstes Restore.

Lösung

GFS steht für Grandfather-Father-Son – ein klassisches Rotationsschema für Backup-Aufbewahrung mit drei Generationen unterschiedlicher Aufbewahrungsdauer:

• Son (Sohn): tägliche Sicherung, Aufbewahrung 1 Woche → 6 Medien (Mo-Sa)
• Father (Vater): wöchentliche Sicherung (Sonntag), Aufbewahrung 1 Monat → 4 Medien
• Grandfather (Großvater): monatliche Sicherung (letzter Sonntag des Monats), Aufbewahrung 1 Jahr → 12 Medien

Gesamt: 22 Medien (6 + 4 + 12).

Logik: Logarithmische Granularität – nahe Vergangenheit fein (täglich), entferntere Vergangenheit grobkörniger. Ermöglicht Restore auf jeden Tag der letzten Woche, jede Woche des letzten Monats und jeden Monat des letzten Jahres.

Erweiterung: Zusätzlich Yearly-Backups (Jahresendsicherung) für Compliance (z.B. GoBD: 10 Jahre). Mehr in L3.

Lösung

HDD (Festplatte):

• Kosten: ~20 €/TB (günstig im Anschaffung, schnell verfügbar)
• Geschwindigkeit: 100-200 MB/s, Random Access möglich
• Lebensdauer: 3-7 Jahre, mechanische Defekte
• Geeignet für: tägliche Backups, NAS-Lösungen, mittelfristige Aufbewahrung

Tape (LTO):

• Kosten: ~6 €/TB (Tape selbst), Drive teuer (2.000-5.000 €). Aktuelle Generation LTO-9 mit 18 TB nativ.
• Geschwindigkeit: ~400 MB/s sequenziell, langsamer Random Access
• Lebensdauer: 30 Jahre bei richtiger Lagerung
• Geeignet für: Langzeit-Archivierung, Compliance, air-gapped Off-Site-Backup, WORM-Modus für Unveränderlichkeit

Cloud-Storage:

• Kosten: monatliche Mietkosten, Tiers von $23/TB (Hot) bis $1/TB (Cold Archive)
• Geschwindigkeit: Internet-limitiert, Egress-Gebühren beachten
• Lebensdauer: Anbieter-abhängig, geo-redundant
• Geeignet für: Off-Site-Kopie, skalierbares Backup, Disaster Recovery

In der Praxis kombiniert: tiered Backup mit Hot/Warm/Cold-Tiers nach Alter und Zugriffsfrequenz.

Lösung

Point-in-Time-Recovery ermöglicht die Wiederherstellung einer Datenbank auf einen beliebigen Zeitpunkt in der Vergangenheit – nicht nur auf den Zeitpunkt eines vorhandenen Backups. Dadurch lassen sich extrem niedrige RPO-Werte (Sekunden) erreichen.

Prinzip: Vollsicherung + kontinuierliche Sicherung der Transaction Logs. Bei MySQL heißen diese Binary Logs (binlog), bei PostgreSQL WAL (Write-Ahead Logs), bei Oracle Redo Logs.

Beispiel-Ablauf für MySQL:

1. Sonntag 02:00 Uhr: Vollsicherung mit mysqldump --master-data=2 (notiert Binlog-Position)
2. Ab Sonntag werden alle Binary Logs zusätzlich archiviert
3. Disaster Donnerstag 14:35 Uhr: DROP DATABASE durch Bedienfehler
4. Restore: Sonntag-Dump einspielen → DB im Sonntag-Zustand
5. mysqlbinlog --stop-datetime="2026-05-15 14:34:59" binlog.* | mysql → Logs bis Sekunde vor Disaster abspielen
6. Ergebnis: DB im Zustand 14:34:59 – nur ~1 Sekunde Daten verloren

Voraussetzungen:

• Binary Logging in DB aktiviert (log-bin, binlog_format=ROW)
• Vollsicherung mit Logposition (master-data oder snapshot)
• Binary Logs müssen außerhalb des DB-Servers gesichert sein (sonst weg bei Hardware-Defekt)
• Logs müssen sich überlappen mit Vollsicherung (keine Lücke)

Mehr in L7.

Lösung

RAID 1 (Mirroring) spiegelt Daten auf zwei (oder mehr) Festplatten in Echtzeit. Es bietet Verfügbarkeit bei Hardware-Ausfall einzelner Platten – aber kein Backup im eigentlichen Sinn. Mehr zu RAID in K57.

Szenarien, die RAID 1 nicht abdeckt:

• Versehentliches Löschen: Datei wird gelöscht → auf beiden Platten weg, sofort
• Logische Fehler / Korruption: kaputte Datei wird auf beide Platten geschrieben
• Ransomware-Verschlüsselung: beide Platten werden verschlüsselt
• Software-Bugs: löschen Daten auf beiden Platten
• Brand / Wasserschaden / Diebstahl: trifft beide Platten gleichzeitig (gleicher Standort)
• Zeitliche Rückkehr: kein Zugriff auf älteren Zustand möglich
• Auditpflichten: keine Versionierung über die Zeit

Ein echtes Backup hingegen:

• Ist eine separate Kopie zu einem definierten Zeitpunkt
• Ist (idealerweise) off-site und gegen lokale Katastrophen geschützt
• Erlaubt Rückkehr zu früheren Zuständen
• Sollte nach 3-2-1-Regel umgesetzt sein
• Wird regelmäßig getestet (siehe L8)

Fazit: RAID schützt vor Hardware-Ausfall, Backup schützt vor Datenverlust. Beide ergänzen sich – aber ersetzen sich nicht.

Lösung

Anzuwendende Norm: DIN 66399 für Datenträgervernichtung. Für vertrauliche Daten wie Personalakten ist Sicherheitsstufe 3 (vertraulich) oder Stufe 4 (besonders sensibel) angemessen.

Methoden für HDDs:

• Bei Wiederverwendung: Überschreiben (Wiping) mit Tools wie DBAN, ShredOS oder Blancco. Mehrere Passes (DoD 5220.22-M: 3 Passes, BSI VSITR: 7 Passes)
• Bei Aussonderung: Schreddern durch zertifizierten Dienstleister nach DIN 66399 Materialklasse H (Festplatten)
• Alternative bei defekten Drives: Degaussen (magnetisches Löschen mit Spezialgerät)

Methoden für SSDs:

• Überschreiben ist nicht zuverlässig wegen Wear-Leveling und Reserveblöcken
• Königsweg: ATA Secure Erase (Firmware-Befehl) via hdparm oder Hersteller-Tools
• Bei Aussonderung: Schreddern nach DIN 66399 Materialklasse E (elektronische Datenträger)
• Bei verschlüsselten SSDs: Crypto Erase (Schlüssel löschen)

Erforderliche Dokumentation:

1. Inventar der ausgemusterten Geräte (Seriennummern, vorheriger User)
2. Klassifizierung der Datenkategorien
3. Gewählte Sicherheitsstufe nach DIN 66399
4. Vernichtungsprotokoll mit Datum, Verfahren, Verantwortlichem
5. Bei externem Dienstleister: Vernichtungszertifikat mit Seriennummern und Sicherheitsstufe
6. Aktualisierung des Asset-Management-Systems

DSGVO-Relevanz: Art. 32 (technisch angemessene Sicherheit) und Art. 5 Abs. 1 lit. f (Integrität, Vertraulichkeit) verlangen sichere Vernichtung. Strafen bis 4% Jahresumsatz möglich. Aufbewahrung der Vernichtungsdokumentation mindestens 3 Jahre.

Lösung

Bei RPO = 5 Minuten und RTO = 1 Stunde scheiden klassische tägliche Backups aus. Die Strategie muss kontinuierliche Verfahren mit schneller Restore-Fähigkeit kombinieren.

1. Datenbank-Sicherung (MySQL 500 GB):

• MySQL Replikation: Streaming Replication zu einem Standby-Server (semi-sync) → RPO ~0
• Binary Logs aktivieren und alle 5 Minuten auf separates Storage replizieren → PITR möglich
• Tägliche Vollsicherung mit mysqldump --master-data=2 oder Percona XtraBackup → wöchentlich Voll, täglich Inkrementell auf NAS
• Restore-Test monatlich auf isolierter Test-VM

2. File-Server (2 TB):

• Snapshots alle 5 Minuten auf NAS (z.B. ZFS oder Synology mit Snapshot Replication) → RPO 5 Min
• Stündliche Replikation auf zweites NAS in anderem Brandabschnitt
• Tägliches Backup nach S3 Glacier IR (für Off-Site) und LTO-Tape

3. 3-2-1-1-0 nach L5:

• Kopie 1: produktives System (MySQL Master, File-Server)
• Kopie 2 (anderes Medium): NAS mit HDDs im Büro – schneller Restore
• Kopie 3 (off-site): AWS S3 / Glacier in anderer Region UND zusätzliches Tape im Bankschließfach
• +1 immutable: S3 Object Lock aktiviert für Ransomware-Schutz
• 0 Fehler: monatliche Restore-Tests dokumentiert

4. RTO-Sicherstellung (1 Stunde):

• Warm Standby: DB-Replica und gespiegelter File-Server vorhanden → Aktivierung < 30 Min
• Lokale Backups auf schneller SSD-NAS → Restore-Geschwindigkeit hoch
• Klare Runbooks für Restore-Prozess, getestet im DR-Drill

5. Aufbewahrung (GFS-Schema, siehe L3):

• Daily Snapshots: 7 Tage
• Weekly Backups: 4 Wochen
• Monthly Backups: 12 Monate
• Yearly (GoBD): 10 Jahre auf Tape

6. Testing:

• Täglich: automatisierter Existence Check
• Wöchentlich: Integrity Check
• Monatlich: Restore-Test einer Anwendung auf Test-System
• Quartalsweise: vollständiger DB-Restore mit PITR auf Test-DB
• Jährlich: kompletter DR-Drill mit Failover auf Standby

7. Dokumentation und Monitoring:

• Backup-Konzept schriftlich festgehalten
• Monitoring mit Alarm bei fehlerhaftem Backup-Job
• DSGVO-Lösch-Konzept dokumentiert
• Restore-Runbooks für Notfall (auch ohne Original-Admin nutzbar)

Diese Strategie erfüllt RTO = 1h durch Warm Standby + schnelle lokale Backups und RPO = 5 Min durch kontinuierliche Replikation + Snapshots. Kosten: deutlich höher als reines Tagesbackup, aber für Tier-1-System angemessen.