# Multi Site Backup: Aufbau einer hochverfügbaren und manipulationssicheren Wiederherstellungskette

TL;DR / Management Summary Multi Site Backup (oder Disaster Recovery, DR) ist eine kritische Erweiterung der standardmäßigen Datensicherung, die darauf abzielt, Datenverlust bei regionalen Katastrophen oder totalem Ausfall des primären Standorts (inkl. Ransomware-Angriffen) zu verhindern. Wir implementieren hier die erweiterte 3-2-1-Strategie, indem wir Tools wie BorgBackup für effiziente Deduplizierung und Rclone/S3 für die sichere, verschlüsselte Replikation in ein geografisch getrenntes, immutables Speichersystem nutzen. Der Hauptvorteil ist die Gewährleistung niedriger RTO-Werte selbst im schlimmsten Fall.

# 1. Einführung & Architektur

Im Enterprise-Kontext genügt die Sicherung auf einem lokalen NAS oder einem einzelnen Datencenter nicht mehr. Die Bedrohung durch Ransomware, die darauf abzielt, Backup-Indizes zu löschen, sowie das Risiko von physischen Katastrophen (Brand, Überschwemmung) erfordern eine echte geografische und logische Trennung der Sicherungen.

# Warum brauchen wir das?

• Geografische Resilienz (DR): Sicherstellung der Geschäftskontinuität, wenn der primäre Standort komplett ausfällt.
• Ransomware-Abwehr: Klassische Backups werden oft verschlüsselt oder gelöscht. Nur die Nutzung von Immutable Storage (WORM – Write Once Read Many) im Offsite-Repository kann hier wirksamen Schutz bieten.
• Compliance: Regulatorische Anforderungen (z.B. Finanzwesen, Medizin) fordern oft die Speicherung von Daten in unterschiedlichen Jurisdiktionen oder in physisch getrennten Zonen.

# Vergleich mit Alternativen

# Architektur-Diagramm (Kernel- und Protokoll-Sicht)

Die gewählte Architektur nutzt BorgBackup, welches sich auf der Anwendungsebene einklinkt, um Datenblöcke zu hashen, deduplizieren und zu verschlüsseln, bevor sie über eine gesicherte Verbindung transportiert werden.

Schicht 1: Lokale Sicherung (Nearline DR)

• Quellserver -> Borg Client -> (SSH/LAN) -> Borg Repository Server (Lokal).
• Vorteil: Sehr niedrige RPO/RTO für alltägliche Wiederherstellungen.

Schicht 2: Remote Replikation (Offsite DR)

• Borg Repository Server (Lokal) -> Rclone Sync (TLS/HTTPS) -> S3 / Object Storage (DR Site).
• Anmerkung: Der Remote-Speicher muss Object Locking (Immutability) unterstützen.

graph TD
    A[Prod Server A/B/C] -->|Borg Deduplication| B(Local Borg Repository - LAN/VPN)
    B -->|Rclone (TLS, Encrypted)| C[Remote Object Storage (S3/MinIO)]
    C -->|Retention Policy| D(Immutable Bucket Lock - WORM)

    subgraph Primary Datacenter
        A
        B
    end

    subgraph Disaster Recovery Site
        C
        D
    end

# 2. Installation & Grundkonfiguration (Praxis)

Wir verwenden BorgBackup für seine exzellente Deduplizierung (reduziert Bandbreite und Speicherplatz) und Rclone für die flexible Anbindung an S3-kompatible Ziele (z.B. AWS S3, MinIO, Wasabi, Azure Blob).

# Voraussetzungen

1. Netzwerk: Dedizierte WAN-Verbindung mit QoS/Priorisierung für Backup-Traffic (idealerweise über 100 Mbps symmetrisch).
2. Krypto-Key Management: Sichere Speicherung des Borg Repository Key (z.B. in einem Vault oder hardwaregestützt).
3. S3 Object Lock: Das gewählte Remote-Speicherziel muss S3 Object Locking im Compliance Mode (nicht Governance) unterstützen.
4. Pakete: borgbackup, rclone, fuse (für Mounts), python3-pip (für Automation/Wrapper-Skripte).

# Schritt-für-Schritt Setup: Der 3-2-1 Happy Path

Wir konfigurieren Borg auf dem lokalen Repository-Server, um die Daten zu empfangen, und nutzen Rclone, um dieses Repository zum Remote-Ziel zu synchronisieren.

# 2.1 Lokales Repository Initialisieren (Server A)

Wir initialisieren das Repository mit AES-256 Verschlüsselung und einem dedizierten Key.

# 1. SSH Key Management: Erstellung eines dedizierten Backup-Benutzers ('borg_user')
# auf dem lokalen Repository Server. Deaktiviere Passwort-Login für maximale Sicherheit.

# 2. Umgebungsvariable setzen (Wichtig für automatisierte Läufe)
export BORG_REPO="/mnt/backup_storage/borg_local"

# 3. Repository initialisieren. 'repokey-blake2' ist der empfohlene, sichere Modus
# Der blake2 Hash wird für die Integritätsprüfung verwendet.
# Die Passphrase MUSS sicher gespeichert werden (z.B. HashiCorp Vault).
borg init --encryption=repokey-blake2

# Ausgabe: Bitte Passphrase eingeben...

# 4. Erster Test-Backup-Lauf vom Client (Prod Server)
# Der Client benötigt nur das SSH-Schlüsselpaar, keine direkte Passphrase.
# Wir nutzen LZ4 zur schnellen Kompression, da wir Bandbreite sparen wollen.
borg create --stats --progress --compression lz4 \
    ssh://borg_user@server_a:$BORG_REPO::'{hostname}-{now}' \
    /data/production_data

# 2.2 Remote S3 Konfiguration (Remote Site)

Wir konfigurieren Rclone, um auf das S3-Ziel zuzugreifen und dort das Object Lock (Immutability) zu aktivieren.

Achtung: Object Lock muss beim Erstellen des Buckets aktiviert werden.

# 1. Rclone Konfiguration starten
rclone config

# 2. Neuen Remote anlegen (Beispiel: AWS S3)
# Name: borg_s3_remote
# Type: 4 (Amazon S3)
# region: eu-central-1 (Wichtig: Geografisch getrennt von Prod)
# acl: private
# storage_class: DEEP_ARCHIVE oder STANDARD_IA, je nach RTO-Anforderung

# 3. S3 Bucket erstellen und Object Lock aktivieren (Konsole oder CLI)
# aws s3api create-bucket --bucket my-immutable-dr --object-lock-enabled-for-bucket

# 4. Policy im S3 Bucket definieren: Standardmäßige Retention von 90 Tagen im Compliance Mode.
# Alle Objekte, die hochgeladen werden, erhalten automatisch eine 90-Tage-Sperre.

# 2.3 Replikation und Immutability (Das Herzstück)

Wir nutzen Rclone, um das gesamte lokale Borg Repository in den Remote S3 Bucket zu replizieren.

# Vorbereitung: Wir synchronisieren den Inhalt des lokalen Borg-Repositories zum S3-Ziel.
# Wir nutzen '--copy-links' und 's3-chunk-size' für WAN-Optimierung.
# Wichtig: '--bwlimit' zur Drosselung, um die Produktionsnetzwerkleistung nicht zu beeinträchtigen.

rclone sync --bwlimit 20M \
    --transfers 8 \
    --checkers 16 \
    --s3-chunk-size 64M \
    /mnt/backup_storage/borg_local borg_s3_remote:my-immutable-dr

# Nach dem Sync wird JEDE Datei (Chunk, Metadaten) durch die S3 Bucket Policy
# automatisch mit dem Object Lock belegt (z.B. 90 Tage WORM).
# Selbst ein Angreifer mit vollen S3-Zugriffsschlüsseln (außer Root) kann diese Daten nicht löschen.

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning: WAN Optimierung

Der Flaschenhals im Multi-Site-Backup ist fast immer die WAN-Verbindung, insbesondere bei der initialen Seed-Phase oder bei hohem Data Change Rate (DCR).

• TCP BBR (Bottleneck Bandwidth and Round-trip Propagation Time): Stellen Sie sicher, dass auf dem Repository-Server, der die WAN-Übertragung durchführt, der BBR Congestion Control Algorithmus aktiviert ist. Dies ist effektiver als Cubic für Hochlatenzverbindungen.

  # Aktivieren von BBR (Linux Kernel 4.9+)
  echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
  echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
  sudo sysctl -p

• Borg Compression: Nutzen Sie lz4 für hohe Geschwindigkeit bei gutem Kompressionsverhältnis. Wenn die Bandbreite extrem limitiert ist, kann zstd,5 (Level 5) verwendet werden, aber dies erhöht die CPU-Last auf dem Client.

• Rclone Transfers: Erhöhen Sie --transfers und --checkers (siehe 2.3), um die verfügbare Bandbreite effizienter zu nutzen. Starten Sie immer mit dem Test-Flag --dry-run.

# Hardening & Security

Dies ist der kritischste Punkt für die Resilienz gegen Ransomware. Die Trennung der Credentials ist logisch unumgänglich (Air-Gapping).

1. Principle of Least Privilege (PoLP):

   • Der Borg Client darf nur auf das lokale Repository schreiben (SSH-Schlüssel nur für borg serve). Er darf keine Shell-Kommandos ausführen und kann das Repository nicht löschen.
   • Der Rclone Sync Job (auf dem lokalen Repository Server) darf nur S3 PutObject und GetObject ausführen. Er benötigt KEINE S3 DeleteBucket oder DisableObjectLock Berechtigungen.

2. Object Lock und Retention:

   • Wir nutzen den S3 Lifecycle Manager auf dem DR-Bucket, um sicherzustellen, dass das Object Lock nicht vor Ablauf der Retention (z.B. 90 Tage) aufgehoben werden kann.
   • Compliance Mode: Erlaubt es selbst dem Root-Konto nicht, das Lock zu entfernen, bis die Retention abgelaufen ist. Dies ist der Goldstandard für Ransomware-Abwehr.

3. Verschlüsselung der Verschlüsselung:

   • Borg verschlüsselt die Daten auf Block-Level bevor sie das LAN verlassen.
   • Rclone verschlüsselt die Übertragung via TLS/HTTPS, zusätzlich zur nativen S3-Verschlüsselung (SSE-S3).

# 4. Day-2 Operations: Wartung & Alltag

Nach der Implementierung muss das System täglich verwaltet und die Datenintegrität geprüft werden.

# Typische Tasks

# Automatisierung (Ansible)

Ein idempotentes Ansible Playbook stellt sicher, dass der Borg-Client, der S3-Endpoint und die Systemd-Timer zur Ausführung der Jobs korrekt konfiguriert sind.

# Ansible Playbook: borg_client_setup.yml

- name: Configure and run Multi-Site Backup Client
  hosts: prod_servers
  become: yes
  vars:
    borg_repo_ssh: "ssh://borg_user@server_a:/mnt/backup_storage/borg_local"
    backup_path: "/data/critical_app"

  tasks:
    - name: Ensure borgbackup package is installed
      ansible.builtin.package:
        name: borgbackup
        state: present

    - name: Deploy SSH key for borg_user access
      ansible.posix.authorized_key:
        user: borg_user_local
        state: present
        key: "{{ lookup('file', '~/.ssh/id_rsa_borg.pub') }}"

    - name: Create backup execution script (wrapper)
      ansible.builtin.template:
        src: files/borg_wrapper.sh.j2
        dest: /usr/local/bin/run_borg_backup.sh
        mode: '0750'
      # Das Wrapper-Script enthält den 'borg create' und 'borg prune' Befehl.

    - name: Configure systemd timer for local backup (Hourly)
      ansible.builtin.systemd:
        name: borg-backup-client.timer
        state: started
        enabled: yes
        daemon_reload: yes
        # Unit-File (Template) definiert:
        # [Timer]
        # OnCalendar=hourly
        # AccuracySec=1h

# 5. Troubleshooting & “War Stories”

Die Komplexität des Multi-Site-Setups führt oft zu Problemen an den Schnittstellen: Netzwerk, Dateisystemintegrität und Authentifizierung.

# Top 3 Fehlerbilder

# 1. Symptom A: “Repository is locked” / “unclean shutdown”

• Fehlermeldung: Failed to create/acquire lock ... repository is already locked.
• Ursache: Das Borg- oder Rclone-Skript wurde mitten in der Ausführung durch einen Timeout, Neustart oder OOM (Out Of Memory) beendet. Die Lock-Datei (.lock.exclusive) im Repository wurde nicht entfernt.
• Lösung: Wenn Sie sicher sind, dass kein anderer Prozess aktiv ist, die Lock-Datei manuell entfernen.

  # VORSICHT: NUR ausführen, wenn SIE WISSEN, dass kein Backup läuft!
  borg break-lock $BORG_REPO

# 2. Symptom B: Hohe Latenz verursacht RPO-Verletzung

• Symptom: Der tägliche Rclone-Sync zum S3-Ziel dauert 12 Stunden, obwohl das RPO-Ziel 8 Stunden beträgt.
• Analyse: Tools: iperf3 zwischen lokalem Repository und DR Site, um die Basis-Bandbreite zu prüfen. iostat auf dem lokalen Repository Server, um festzustellen, ob lokale Platte oder CPU der Flaschenhals ist (Deduplizierung ist CPU-intensiv).
• Lösung:
  1. Erhöhung der WAN-Bandbreite.
  2. Verwendung von borg create --read-special bei Daten, die sich nicht geändert haben (für VMs).
  3. Tuning der Rclone --bwlimit und transfers Parameter, oder Wechsel des Compression Algorithms.

# 3. Symptom C: Object Lock verhindert Pruning (Retention)

• Symptom: Sie führen borg prune erfolgreich auf dem lokalen Repository durch, aber der nächste Rclone-Sync zeigt, dass die Dateien im S3 Bucket nicht gelöscht werden.
• Ursache: Das Object Lock (WORM) im S3-Bucket verhindert die Löschung von Dateien, die noch unter der gesetzten Retention stehen. Rclone meldet dies möglicherweise nicht als harten Fehler, da die Quelle bereits gelöscht wurde.
• Lösung: Dies ist gewolltes Verhalten. Stellen Sie sicher, dass Ihre lokale prune Policy länger ist als das S3 Object Lock. (Beispiel: Object Lock = 90 Tage. Lokale Pruning = 6 Monate. Dann sind alle 90 Tage alten Chunks, die Borg löscht, auch auf S3 löschbar, wenn die lokale Copy gelöscht wird.)

# Recovery Szenarien

Worst Case: Primäres Datencenter komplett zerstört (Ransomware/Feuer)

1. Failover Setup: Provisionieren Sie einen neuen “Borg Repository Server” in der DR-Zone (Cloud VM).
2. Mount Remote Repo: Konfigurieren Sie Rclone und laden Sie alle Chunks vom immutablen S3 Bucket auf den neuen Borg Server herunter (oder nutzen Sie S3FS/MinIO Gateway).
3. Key Retrieval: Laden Sie den geheimen Borg Passphrase Key aus dem Notfall-Vault (Hardware Security Module oder verschlüsseltes Papier-Backup).
4. Restore: Führen Sie den Wiederherstellungsprozess direkt von diesem wiederhergestellten Remote Repository aus.

graph LR
    A[Backup Job Failed?] -->|Yes| B{Check Local Storage Lock};
    B -->|Locked| C[Run: borg break-lock];
    B -->|Not Locked| D{Check Log for Network/Auth Error};
    D -->|WAN Latency/Timeout| E[Verify iperf3, Adjust --bwlimit];
    D -->|Auth Error (Borg)| F[Verify SSH Key Deployment & Permissions];
    D -->|Auth Error (Rclone)| G[Verify S3 Credentials & IAM Policy];
    G -->|Policy too restrictive| H[Check for s3:PutObject/s3:GetObject];
    G -->|Policy too permissive| I[Revert to PoLP (Ensure No DeleteObject)];
    E -->|Still Slow| J{Is Data Change Rate Too High?};
    J -->|Yes| K[Adjust RPO/Retention Window];
    C --> L[Rerun Backup Job];
    K --> L;
    H --> L;

# 6. Monitoring & Alerting

Monitoring muss nicht nur den Erfolg des Backups, sondern auch die Wiederherstellbarkeit und die Sicherheitslage (Immutability Status) erfassen.

# Metriken (KPIs)

# Alerting-Regeln

Wir definieren kritische Regeln, die direkt auf den Pager geleitet werden.

1. BackupJobFailed: Trigger, wenn der Borg/Rclone-Wrapper mit Exit Code != 0 beendet wird.
2. RPOExceeded: Trigger, wenn der Zeitstempel des letzten erfolgreichen Backups älter ist als 4 Stunden.
3. S3LockCompromised: Extrem kritisch. Trigger, wenn ein Skript feststellt, dass die S3 Object Lock Policy auf dem DR-Bucket nicht mehr den Compliance Mode oder die Mindestretention aufweist. (Dies deutet auf eine Kompromittierung des S3-Root-Kontos hin).
4. HighDataChangeRate: Wenn der Backup-Job 3 Tage in Folge 50% mehr Daten als normal transportiert (kann auf CryptoLocker-Aktivität oder Datenbomben hinweisen).

Prometheus Exporter Config Snippet (Conceptual):

# Prometheus Job Configuration für den Backup Status
- job_name: 'multi_site_backup_status'
  static_configs:
    - targets: ['local_repo_server:9100'] # Node Exporter
  metrics_path: /metrics/backup # Custom Textfile Collector output
  relabel_configs:
    - source_labels: [__name__]
      regex: 'borg_last_run_timestamp'
      action: keep

# 7. Fazit & Empfehlung

Die Implementierung einer Multi Site Backup Strategie unter Nutzung von BorgBackup und Rclone bietet einen ausgezeichneten Kompromiss zwischen Kosteneffizienz, Flexibilität und höchster Sicherheit durch Object Immutability.

Wann würde ich es NICHT einsetzen?

• Extreme Transaktionslast: Bei Systemen, die Continuous Data Protection (CDP) im Minutenbereich benötigen (z.B. Hochfrequenzhandel). Hier sind block-level synchrone Replikationslösungen (Storage Arrays oder Mirroring) oder spezialisierte Cloud-CDP-Dienste besser geeignet.
• Ausschließlich proprietäre Ökosysteme: Wenn der gesamte Stack auf einem einzelnen Vendor (z.B. VMware/Hyper-V) basiert, kann eine voll integrierte Lösung dieses Vendors einfacher zu managen sein (trotz Lizenzkosten).

Ausblick:

Der Trend geht hin zu noch feiner granulierten RPO-Zielen und dem Einsatz von Cloud-nativen Backup-APIs. Die Architektur wird weiterhin auf dem Prinzip der logischen Trennung der Schlüssel basieren: Der Backup-Client kennt den Borg Key, aber nicht den S3 Key. Das S3-Target ist durch einen WORM-Mechanismus geschützt, der außerhalb der Kontrolle der laufenden Prozesse liegt. Wiederherstellungstests (TDR) sind nicht optional, sondern der einzige Nachweis der Wirksamkeit der Strategie.

# Anhang: Cheatsheet (Borg/Rclone)

# Referenzen

• BorgBackup Offizielle Dokumentation (Performance Tuning, Integrity Check): https://borgbackup.readthedocs.io/
• Rclone Offizielle Dokumentation (S3 Object Lock Integration): https://rclone.org/s3/
• AWS S3 Object Lock Best Practices (Compliance Mode vs. Governance Mode).
• RFC 793 (TCP Congestion Control).