# 3 2 1 Backup Regel Deep Dive – Aufbau von Enterprise-Level Datensicherheit

TL;DR / Management Summary Die 3-2-1 Regel (Drei Kopien, Zwei Medien, Eine Off-Site) ist der Goldstandard für Datensicherheit und Compliance. Im modernen Umfeld muss diese Regel jedoch um zwei kritische Komponenten erweitert werden: 1 (Immutability/Air-Gap) und 0 (Zero Errors nach Test-Restore). Nutzen Sie dedizierte, schreibgeschützte Credentials für Ihre Backups und automatisieren Sie wöchentliche Test-Restores, um RTO-Garantien einzuhalten. Ohne verifizierte Wiederherstellbarkeit existiert das Backup de facto nicht.

# 1. Einführung & Architektur

Die 3-2-1 Regel wurde historisch von Peter Krogh (Fotograf und Datenexperte) popularisiert und dient als fundierte Strategie, um Ausfallsicherheit gegen die drei häufigsten Bedrohungen zu gewährleisten: Lokaler Hardware-Ausfall, menschliches Versagen/lokale Katastrophen und Totalverlust des Rechenzentrums.

Wir Admins wissen jedoch: Compliance und ein rudimentäres Backup reichen nicht. Wir müssen eine Architektur entwerfen, die gegen die größte Bedrohung der letzten Jahre – Ransomware – resilient ist.

# Warum brauchen wir das?

• Problemstellung aus der Praxis (Der moderne Schock): Ein lokales Disk-Backup (Medien Typ 1) ist wertlos, wenn der Ransomware-Agent Netzwerk-Shares scannt und die Backup-Dateien verschlüsselt oder löscht. Zudem kann der Standard-Backup-Operator oft auch Backups löschen, was bei einer Kompromittierung fatal ist.
• Alternative (Der unzureichende Standard): Viele Organisationen erfüllen nur 3-1-0 (Drei Kopien, Ein Medium (nur Disk), Null Off-Site). Dies ist ein Single Point of Failure (SPOF) im Falle eines RZ-Brandes oder eines erfolgreichen Cyberangriffs auf die primäre Infrastruktur.
• Zielsetzung: Wir erweitern 3-2-1 zum 3-2-1-1-0 Standard:
  • 3 Kopien: Primär + Lokal + Remote.
  • 2 Medien: Disk/Flash (schnell) + Tape/Cloud (kosteneffizient/WORM).
  • 1 Off-Site: Geografisch getrennt.
  • 1 Air-Gapped/Immutable: Logisch oder physisch getrennt (WORM, S3 Object Lock, Tape Rotation).
  • 0 Fehler: Jede Wiederherstellung muss im Testfall erfolgreich sein (Verifizierung).

# Architektur-Diagramm (Datenfluss & Isolations-Tiering)

Der Schlüssel zur Resilience liegt in der Isolation der Speichertiers und der Credentials.

graph TD
    A[Produktionsdaten (Tier 0)] --> B{Backup Proxy / Agent};

    subgraph Tier 1: Local Backup (Fast RTO)
        B --> C[Lokale Storage (z.B. SAN, NAS)];
        C -- Synthetische Fulls, Deduplizierung --> D(Snapshots / Short-Term Retention);
    end

    subgraph Tier 2: Secondary Media / Off-Site
        D -- Throttled Replication --> E[Cloud / Tape Gateway];
        E --> F[Immutable Storage (WORM, S3 Object Lock)];
        F -- Separate Credentials (Read-Only Prod) --> G(Separate Network Zone / RZ);
    end

    H[Administrator / Operator] -- Write Access Nur auf B, D --> Tier 1;
    H -- Read-Only Access, Löschrechte gesperrt --> Tier 2;
    I[Ransomware Attack] -- Kann C Löschen --> Tier 1;
    I -- Kann F nicht Löschen/Modifizieren --> Tier 2 (Resilient);

Kernel-Sicht der Air-Gap Implementierung (S3 Object Lock): Die logische Air-Gap wird typischerweise nicht auf Kernel-Ebene implementiert, sondern über APIs und das Dateisystem-Protokoll (z.B. S3). Wichtig ist hier der Status des Objekts, der von der Storage-Plattform selbst (z.B. AWS S3 oder MinIO) durchgesetzt wird. Wenn die Compliance-Retention-Periode gesetzt ist, wird jede Lösch- oder Modifikationsanforderung vom Storage-Layer auf Block- oder Objekt-Ebene abgewiesen, unabhängig von den Benutzerberechtigungen. Dies emuliert das Write-Once-Read-Many (WORM) Prinzip physischer Medien.

# 2. Installation & Grundkonfiguration (Praxis)

Wir betrachten die Implementierung der Air-Gap-Komponente (die zweite ‘1’ in 3-2-1-1-0) am Beispiel eines verschlüsselten, dedplizierten Backups, das in einen Immutable S3-Speicher repliziert wird, exemplarisch unter Nutzung von Restic oder Borg.

# Voraussetzungen

1. RTO/RPO Definition: Klare, vertraglich vereinbarte Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO).
2. Bandbreite: Sicherstellen, dass die Bandbreite zur Off-Site-Lokation die RPO-Anforderungen erfüllt (inkrementelle Übertragungen vs. initiale Seeding).
3. Credential Isolation: Dedizierte IAM- oder Service-Accounts, die nur Schreibrechte auf das Backup-Repository haben und keine Lösch- oder Modifikationsrechte (außer über Object Lock Governance Mode).
4. Immutability Support: Die Ziel-Storage muss S3 Object Lock, Azure Blob Immutability oder ein WORM-Filesystem (z.B. ZFS mit Read-Only Snapshots) unterstützen.

# Schritt-für-Schritt Setup (Der “Happy Path”)

Wir konfigurieren ein Restic-Repository mit S3 Object Lock-Unterstützung (Compliance Mode).

# PRÄAMBEL: Wir gehen davon aus, dass der S3-Bucket bereits
# in der AWS-Konsole mit 'Object Lock Default Retention' (z.B. 30 Tage)
# im 'Compliance Mode' erstellt wurde. Wichtig: Dies ist NICHT reversibel.

# 1. Lokales Restic Repository initialisieren (für Tier 1 und 2 Staging)
# Wir nutzen eine starke Konfiguration: AES-256 Verschlüsselung und 
# Passwort wird über Umgebungsvariable oder Key Management System (KMS) bereitgestellt.
export RESTIC_PASSWORD_FILE=/etc/secrets/restic_master_key

# 2. S3 Repository (Tier 2/Off-Site) initialisieren
# Achtung: Die Region und der Bucket müssen mit der Object Lock Konfiguration übereinstimmen
# Der IAM-User, der diesen Befehl ausführt, benötigt 's3:PutObjectRetention'.
echo "Initialisiere Restic Repository auf S3..."
restic init -r s3:s3.eu-central-1.amazonaws.com/backup-immutable-bucket

# 3. Den ersten Backup-Job ausführen
# Wir setzen hier die Retention (zeitlich gesteuert) und wenden die 
# S3 Object Lock Retention (objektgesteuert) an.
echo "Starte Initial-Backup und setze Object Lock (WORM Prinzip)..."
restic backup /srv/app_data \
    --host prod_server_01 \
    --tag daily_full \
    --one-file-system \
    --retention-policy "keep-daily 7" \
    --s3-force-object-lock 

# Erklärung --s3-force-object-lock:
# Dieser kritische Parameter weist Restic an, für jedes hochgeladene Objekt 
# die Object Lock Retention zu erzwingen. Dies verhindert die vorzeitige 
# Löschung oder Manipulation der Backup-Teile durch Ransomware oder Rogue-Admins.

# 3. Deep Dive: Konfiguration für Profis

Hier adressieren wir die Herausforderungen, die bei der Skalierung und beim Härten von Backup-Umgebungen auftreten.

# Performance Tuning

Die Performance eines Backup-Systems ist ein Gleichgewicht zwischen RPO (Übertragungszeit) und RTO (Wiederherstellungszeit).

1. Deduplizierungs-Strategie (Block-Größen):

   • Tools wie Borg oder Restic nutzen Chunking. Wenn Sie viele virtuelle Maschinen sichern (die ähnliche OS-Dateien haben), sollte die Blockgröße (Chunk size) so gewählt werden, dass maximale Deduplizierung über die Backups hinweg erreicht wird.
   • Erfahrungswert: Zu kleine Chunks erhöhen den Metadaten-Overhead, zu große Chunks reduzieren die Effektivität inkrementeller Backups. Die Standardeinstellungen (4k bis 64k variabler Chunking) sind oft gut, sollten aber bei Terabyte-großen Datenbanken überprüft werden.

2. I/O Throttling für Tier 2:

   • Die Replikation zum Off-Site-Speicher (Tier 2) darf die kritischen Geschäftsprozesse (Tier 0) nicht behindern.
   • Nutzen Sie ionice und Netzwerk-Traffic-Shaper (tc, Net-Limiter im Backup-Appliance) oder QoS auf dem Switch/Router, um die Transferfenster strikt zu kontrollieren. Ich empfehle, maximale Bandbreitennutzung nur außerhalb der Geschäftszeiten (z.B. 22:00–06:00 Uhr) zuzulassen.

# Hardening & Security (Die Air-Gap-Garantie)

Ein Air Gap muss logisch oder physisch sein.

# A. Logisches Air Gap (Immutable Storage)

Dies ist die moderne, Cloud-basierte WORM-Implementierung.

• S3 Object Lock (Compliance Mode): Der aggressivste Modus. Nur der Root-Account des AWS-Kontos kann die Retention verkürzen (im Governance Mode). Im Compliance Mode kann niemand, nicht einmal AWS selbst (technisch gesehen), die Daten vor Ablauf der Frist löschen. Dies ist der empfohlene Standard für langfristige Archivierung.
• Zero Trust for Backup Credentials:
  • Keine Löschrechte: Der Service-Account, der die Backups schreibt, darf niemals das Recht haben, existierende Snapshots oder Objekte zu löschen. Er darf nur neue schreiben (s3:PutObject).
  • Getrennte Management-Ebene: Die Schlüssel zur Verwaltung der Backup-Software (Retention-Policies, Löschen alter Backups) müssen von einem dedizierten Jumpserver oder einem vollständig getrennten Identity Provider verwaltet werden.

# B. Physisches Air Gap (Tape oder Rotation)

• LTO Tape Rotation: Das Band, das physisch aus dem Laufwerk genommen und in einen Safe/Off-Site-Lager gebracht wird, ist die ultimative Air-Gap. Es ist immun gegen Cyberangriffe.
  • Best Practice: Die LTO-Laufwerke dürfen nur für die Dauer des Schreibvorgangs am Netzwerk hängen. Bei hochsensiblen Umgebungen empfehle ich einen isolierten Wartungs-VLAN, das nach dem Backup-Job deaktiviert wird.

# C. Verschlüsselung (LUKS/KMS Integration)

Alle Backup-Medien müssen mit starker End-to-End-Verschlüsselung gesichert werden.

• Regel: Die Verschlüsselungs-Keys dürfen niemals auf dem gleichen Server gespeichert sein wie die Produktionsdaten oder die Backup-Quellen.
• Empfehlung: Nutzung eines dedizierten Key Management Systems (KMS, wie HashiCorp Vault oder AWS KMS) zur Speicherung der Master-Keys der Backup-Software.

# 4. Day-2 Operations: Wartung & Alltag

Der Alltag eines Backup-Systems besteht zu 90% aus Wartung und Verifizierung und zu 10% aus Wiederherstellung.

# Typische Tasks

1. Regelmäßige Wiederherstellungstests (Die ‘0’ in 3-2-1-1-0):

   • Dies ist der wichtigste Task. Ein Backup, das nicht regelmäßig getestet wird, existiert nicht.
   • Prozess: Mindestens monatlich (besser wöchentlich) muss eine zufällige Auswahl von Backups auf einer isolierten Test-VM wiederhergestellt werden. Überprüfen Sie die Integrität der wiederhergestellten Daten (z.B. Datenbank-Konsistenz-Checks, Dateisystem-Validierung).
   • RTO-Test: Messen Sie die Zeit von der Alarmierung bis zur Wiederherstellung und Überprüfung der Applikations-Funktionalität. Dokumentieren Sie die Abweichung vom SLA.

2. Capacity Planning und Tier Management:

   • Die Deduplizierungsrate ist nicht konstant. Sie wird schlechter, wenn sich die Daten stark verändern.
   • Überwachen Sie die Metriken zu Deduplizierungsrate, Churn Rate und Free Space auf Tier 1 und Tier 2.
   • Achtung bei Synthetic Fulls: Synthetische vollständige Backups können immense I/O-Last auf den Target-Speicher legen, planen Sie hierfür dedizierte Zeitfenster ein.

3. Migration auf neue Hardware (pvmove-Analogie):

   • Wenn die Backup-Infrastruktur (Tier 1 Storage) veraltet, nutzen Sie Replikations-Features der Backup-Software (z.B. Backup-Copy-Jobs in Veeam) oder Tools wie rsync oder Cloud-Features zur Übertragung der Daten auf den neuen Speicher, bevor der alte Storage stillgelegt wird. Stellen Sie sicher, dass die neue Infrastruktur die Immutability-Anforderungen ebenfalls erfüllt.

# Automatisierung (Ansible/Terraform)

Wir automatisieren nicht das Backup (das macht die Backup-Software), sondern die Verifizierung des Backups.

# Ansible Playbook: Automatisierter Test-Restore für Tier 1 Data Integrity Check
---
- name: Backup Verification Workflow
  hosts: backup_verification_server
  vars:
    source_server: 'prod_db_01'
    target_restore_path: '/mnt/test_restore_db'
    backup_tool_path: '/usr/local/bin/restic'

  tasks:
    - name: 1. Ensure Verification Environment is Clean
      ansible.builtin.file:
        path: "{{ target_restore_path }}"
        state: absent
      # WICHTIG: Sollte nur auf dedizierten Test-Servern laufen

    - name: 2. Create Target Restore Directory
      ansible.builtin.file:
        path: "{{ target_restore_path }}"
        state: directory
        mode: '0700'

    - name: 3. Fetch latest Snapshot from Source Server (Restic Example)
      # Wir holen bewusst das ALLERNEUESTE Snapshot, um RPO-Compliance zu prüfen.
      ansible.builtin.command: >
        {{ backup_tool_path }} restore latest 
        --host {{ source_server }} 
        --target {{ target_restore_path }}
      environment:
        RESTIC_PASSWORD_FILE: /etc/secrets/restic_master_key # Key-Isolation
        RESTIC_REPOSITORY: s3:s3.eu-central-1.amazonaws.com/backup-immutable-bucket

    - name: 4. Run Data Integrity Check (SQL Example)
      # Beispiel: Führe einen SELECT COUNT(*) aus oder einen DBCC CHECKDB
      ansible.builtin.command: /usr/bin/db_integrity_check_script.sh {{ target_restore_path }}
      register: integrity_check_result

    - name: 5. Report Failure or Success
      ansible.builtin.fail:
        msg: "RESTORE VERIFICATION FAILED: Database check reported corruption or incompleteness."
      when: integrity_check_result.rc != 0

# 5. Troubleshooting & “War Stories”

In der Praxis scheitern Backups nicht an der Hardware, sondern an Konfigurationsfehlern und mangelnder Verifizierung.

# Top 3 Fehlerbilder

# 1. Symptom A: Silent Corruption (Der heimliche Killer)

• Fehlermeldung: Keine (Job meldet “Erfolg”), aber bei der Wiederherstellung fehlen Dateien oder Datenbanken sind inkonsistent.
• Ursache: Hardware-Fehler im Speichermedium (defekte Sektoren), fehlende End-to-End-Checksummen-Validierung der Backup-Software, oder Fehler bei der Synthetic-Full-Erstellung.
• Lösung: Sofortige Implementierung der Zero-Fehler-Verifizierung (Die ‘0’). Nutzen Sie restic check --read-data oder die proprietären Tools (Veeam SureBackup) für Block-Level-Integritätsprüfungen auf dem Zielspeicher. Führen Sie den automatisierten Test-Restore (Abschnitt 4) ein.

# 2. Symptom B: RPO Breach durch Off-Site Throttling

• Symptom: Der tägliche Backup-Transfer zur Cloud dauert länger als das geplante Backup-Fenster, oder die Latenz steigt dramatisch.
• Analyse: Tools (iostat, iftop, Backup-Report-Metriken). Meistens liegt es an einer Überschätzung der effektiven Upload-Geschwindigkeit, kombiniert mit zu hoher Churn Rate (zu viele Daten ändern sich täglich).
• Lösung: Feinjustierung des Throttling (siehe Abschnitt 3). Wechsel zu einer reineren inkrementellen/deltabasierten Backup-Strategie. Bei massiven Datenänderungen: Nutzung von Appliance-basierten WAN-Optimierern.

# 3. Symptom C: Kompromittierte Air-Gap (Ransomware-Versuch erfolgreich)

• Symptom: Backup-Logs zeigen “Deletion successful” auf dem Cloud-Speicher nach einer Ransomware-Infektion der Produktionsumgebung.
• Ursache: Der Backup-Service-Account hatte versehentlich s3:DeleteObject Berechtigungen, oder das S3 Object Lock war nur im Governance Mode konfiguriert und der Attacker nutzte seine Root-Rechte aus.
• Lösung: Sofortiges Sperren des kompromittierten Accounts. Auditierung aller IAM-Policies und Umstellung der Retention auf Compliance Mode. Nutzung dedizierter Accounts pro Tier.

# Recovery Szenarien

# Wiederherstellung nach Ransomware-Angriff

1. Isolation: Produktionssysteme vom Netzwerk trennen.
2. Quarantäne-Wiederherstellung: Ein Backup (idealerweise aus der Air-Gapped/Immutable-Tier) auf ein sauberes, isoliertes Test-Netzwerk wiederherstellen.
3. Clean Point Identifizierung: Identifizieren des letzten bekannten sauberen Snapshots VOR der Infektion. Da der Immutable Store nicht manipuliert werden konnte, ist dies oft der einzige sichere Punkt.
4. Desinfektion & Rehydration: Bereinigung der Systeme (Neuinstallation) und Wiederherstellung der sauberen Daten.

# Anekdote: Das nicht existierende Tape

• War Story: In einem mittleren Enterprise-RZ hatten wir die 3-2-1 Regel mit Disk, NAS und LTO-Tapes umgesetzt. Der Monitoring-Check für die Tape-Backups war seit Jahren grün (“Job started/finished”). Als wir jedoch ein historisches Tape für ein Audit wiederherstellen mussten, stellte sich heraus, dass das LTO-Laufwerk seit einem Firmware-Update vor 3 Jahren keine Daten mehr geschrieben, sondern die Jobs nur durchlaufen ließ (Exit Code 0, aber 0 Bytes geschrieben). Die tägliche manuelle Sichtprüfung wurde als “zu lästig” empfunden. Lektion: Vertraue niemals dem Exit Code allein. Verifiziere die Datengröße und führe den Restore Test durch.

graph TD
    A[Backup Job Failed (Report Green?)] --> B{Silent Corruption/Data Size Check};
    B -- Data Size 0/Mismatch --> C[Check Backup Agent Logs];
    B -- Checksum Mismatch (restic check) --> D[Media Failure/SPOF Tier 1];
    C --> E[Hardware Failure Tape/Disk];
    E --> F{Is Immutable Copy (Tier 2) Available?};
    F -- Yes --> G[Restore from Tier 2];
    F -- No! --> H[DR Failed: RPO Violation];
    G --> I[Root Cause Analysis: Why did Tier 1 fail?];

# 6. Monitoring & Alerting

Der Fokus liegt auf KPIs, die die RTO/RPO-Einhaltung messen, nicht nur die Job-Erfolgsrate.

# Metriken (Key Performance Indicators - KPIs)

# Alerting-Regeln

• PAGER-Alert (Sev 1 - Sofortige Reaktion):

  • RPO Violation: Wenn das letzte erfolgreiche Backup älter ist als 2x RPO.
  • Verified Restore Failure: Wenn ein automatisierter Test-Restore (Abschnitt 4) fehlschlägt.
  • Immutability Bypass Attempt: Alarm, wenn eine API-Anfrage versucht, ein geschütztes Objekt vor Ablauf der Retention zu löschen (Monitoring des S3/Cloud Logs).

• E-Mail-Alert (Sev 2 - Arbeitszeit):

  • VG Free Space (Tier 1): Wenn der Backup-Speicher unter 15% freien Platz fällt (Kapazitätsplanung).
  • Performance Degradation: Wenn die Transferzeit um mehr als 20% über dem Durchschnitt liegt (Hinweis auf Bandbreitenproblem oder Hardware-Ausfall).

# Tools

• Prometheus Exporter Config: Spezielle Exporter für Backup-Applikationen (z.B. Veeam Exporter, oder Skripte, die Restic/Borg-Metadaten parsen). Exportieren Sie die Dauer des Jobs, die Übertragungsmenge und den Deduplizierungsfaktor.
• Checkmk/Nagios Plugin: Einfache Checks auf die Existenz der letzten Backup-Datei in Tier 1 und Tier 2.

# 7. Fazit & Empfehlung

Die 3-2-1 Regel ist die notwendige Basis, aber nicht die Endlösung für moderne Disaster Recovery. Der Fokus muss auf der Integrität und Isolation liegen.

Wir empfehlen dringend, den Standard 3-2-1-1-0 zu implementieren. Die zusätzliche Schicht der Immutability (WORM) ist heute die effektivste Verteidigung gegen Ransomware. Die ‘0’ der Fehlerfreiheit (Test-Restore) ist die versicherungstechnische Garantie Ihrer RTOs.

Wann würde ich es nicht einsetzen? Die 3-2-1-1-0 Strategie ist primär für Backup (asynchrone, point-in-time Kopien) gedacht. Für kritischste Applikationen mit Near-Zero RPO/RTO (< 1 Minute) ist synchrone Replikation (z.B. Storage-Replikation, Datenbank-Replikation wie MSSQL AlwaysOn oder PostgreSQL Streaming Replication) erforderlich. Backups dienen hier nur als letzte Rettungsleine gegen logische Fehler (Datenbank-Korruption durch fehlerhaften Code).

Ausblick: Der Trend geht zu “Self-Healing” Backups, bei denen die Software automatisch auf die isolierte Test-VM wiederherstellt und Applikationstests durchführt, bevor der Job als 100% erfolgreich markiert wird. Infrastructure-as-Code (IaC) wird zunehmend nicht nur die Infrastruktur, sondern auch die Wiederherstellungsumgebung definieren.

# Anhang: Cheatsheet

# Referenzen

• AWS S3 Object Lock Documentation (Für Compliance Mode Details)
• Restic Documentation (Erläuterungen zu --s3-force-object-lock)
• The 3-2-1 Backup Rule by Peter Krogh
• NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide – Kapitel Recovery)