Cloud-Backup-Strategie: Der umfassende Leitfaden

Das BDSG und die DSGVO verlangen in Art. 32 „geeignete technische und organisatorische Maßnahmen", um die Verfügbarkeit personenbezogener Daten zu gewährleisten — fehlende Backups sind damit nicht nur ein operatives, sondern ein Compliance-Risiko. Eine funktionierende Cloud-Backup-Strategie folgt der 3-2-1-Regel: drei Kopien der Daten, auf zwei verschiedenen Medientypen, mit einer Kopie außerhalb des Standorts — in der Praxis bedeutet das einen Primärspeicher (Produktionssystem), ein lokales Backup (NAS oder externe Festplatte) und mindestens eine Cloud-Stufe (Backblaze B2, AWS S3 Glacier Deep Archive oder Wasabi).

Ergänzen Sie Unveränderlichkeit via Object Lock, verschlüsseln Sie clientseitig mit AES-256 vor dem Upload, automatisieren Sie nächstens via restic oder Borg, und — das ist der Schritt, den die meisten Teams überspringen — testen Sie vierteljährlich eine vollständige Wiederherstellung. Ohne einen getesteten Restore haben Sie Hoffnung, kein Backup.

Warum die 3-2-1-Regel in 2026 weiterhin gilt

3-2-1 stammt aus der analogen Fotografie, aber die Mathematik hat sich nicht geändert. Drei Kopien bieten genug Redundanz, damit jeder einzelne Ausfall (Festplattencrash, Ransomware, versehentliches rm -rf) zwei Kopien intakt lässt. Zwei Medientypen hedgen gegen systematische Ausfälle — eine fehlerhafte Firmware-Version, die ein ganzes SSD-Modell ausbrickt, oder ein Cloud-Provider-Regions-Ausfall. Außerhalb des Standorts schützt gegen das Gebäude-Ereignis: Brand, Überschwemmung, Diebstahl oder der Umzugswagen, der gegen den Server-Rack fährt.

Modernisierte Varianten existieren. 3-2-1-1-0 fügt eine unveränderliche Kopie hinzu und erfordert null Fehler bei Wiederherstellungstests. 4-3-2 (von vielen MSPs verwendet) hält vier Kopien und zwei Cloud-Anbieter. Wählen Sie eines, dokumentieren Sie es und halten Sie daran fest. Die genaue Zahl spielt weniger eine Rolle als die Disziplin.

Speicherstufen für Kosten vs. Wiederherstellungsgeschwindigkeit auswählen

Cloud-Anbieter bieten Speicherklassen zu dramatisch unterschiedlichen Preisen:

| Stufe | Kosten/GB/Monat | Erste-Byte-Latenz | Egress-Gebühr | |-------|-----------------|-------------------|---------------| | S3 Standard | $0,023 | Millisekunden | $0,09/GB | | S3 Glacier Instant | $0,004 | Millisekunden | $0,03/GB | | S3 Glacier Flexible | $0,0036 | 3–5 Minuten | $0,02/GB | | S3 Glacier Deep Archive | $0,00099 | 12 Stunden | $0,02/GB | | Backblaze B2 | $0,006 | Millisekunden | $0,01/GB | | Wasabi | $0,0069 | Millisekunden | kostenlos (bis 1x gespeichert/Monat) | | Cloudflare R2 | $0,015 | Millisekunden | kostenlos |

Für Backups trifft Glacier Deep Archive etwa $1 pro TB pro Monat, aber die 12-Stunden-Wiederherstellungslatenz macht es ungeeignet für „Ich habe die gestrige Datei versehentlich gelöscht." Ein zweistufiger Ansatz funktioniert am besten: neuere Backups in einer heißen Stufe (B2 oder R2), ältere als 30 Tage per Lifecycle-Policy zu Glacier Deep Archive.

Die 3-2-1-Regel in konkreten Begriffen

Ein Beispiel-Stack für 2 TB Arbeitsdaten:

Produktion: Laptops, Server, SaaS-Daten (primäre Kopie)
Lokal: NAS mit ZFS und Snapshots, 4 TB nutzbar, wöchentlich auf eine externe USB-Festplatte gespiegelt, die im feuerfesten Safe liegt
Cloud-heiß: Backblaze-B2-Bucket mit restic, nächtliche Inkremente, 90-Tage-Aufbewahrung bei ~$12/Monat für 2 TB
Cloud-kalt: S3 Glacier Deep Archive via Lifecycle-Policy, jährliche Snapshots, 7-Jahres-Aufbewahrung bei ~$24/Jahr für 2 TB

Gesamtmonatliche Kosten: unter $20 für vollständige 3-2-1-Abdeckung mit siebenjähriger Historie. Günstiger als ein einzelner Ersatz-Laptop.

Backups mit sicheren Tools automatisieren

Restic ist die De-facto-Wahl für verschlüsselte inkrementelle Backups in Object Storage. Es dedupliziert, komprimiert, verschlüsselt mit AES-256-CTR plus Poly1305 und unterstützt B2, S3, Azure, GCS und SFTP nativ:

restic -r b2:hexa-backups:produktion init
restic -r b2:hexa-backups:produktion backup /var/data \
  --exclude-file=/etc/restic/exclude.txt \
  --tag nightly
restic -r b2:hexa-backups:produktion forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Nächstens per systemd-Timer oder Cron ausführen, mit dem Repository-Passwort in einer nur für Root lesbaren Datei. Borg Backup ist eine ausgezeichnete Alternative, besonders wenn lokale Repository-Unterstützung benötigt wird; Kopia ist neuer und hat eine benutzerfreundlichere Oberfläche.

Backups gegen Ransomware unveränderlich machen

Ransomware, die Ihre Produktionsdaten verschlüsselt, versucht auch, Ihre Backups zu verschlüsseln. Object Lock verhindert das. AWS S3 und Backblaze B2 unterstützen „Compliance-Modus", bei dem selbst der Root-Account keine Objekte löschen kann, bis die Aufbewahrungsfrist abläuft:

aws s3api put-object-lock-configuration \
  --bucket backup-immutable \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}
  }'

30 Tage nach dem Upload kann niemand — auch kein kompromittierter Administrator — das Backup löschen. Kombinieren Sie das mit Versionierung, MFA-Delete und einer IAM-Rolle, die schreiben, aber nicht überschreiben kann, und Sie haben den dominanten Ransomware-Pfad geschlossen.

Clientseitig vor dem Upload verschlüsseln

Auch mit anbieterseitiger Verschlüsselung (SSE-KMS) hält Ihr Cloud-Anbieter die Schlüssel, was bedeutet, dass Vorladungsanfragen zur Entschlüsselung zwingen können. Für sensible Daten vor dem Verlassen Ihres Netzwerks verschlüsseln. Restic macht das automatisch; für Ad-hoc-Dateien ist age eine gute Wahl:

age -r age1xyz... -o archiv.tar.gz.age archiv.tar.gz
aws s3 cp archiv.tar.gz.age s3://backups/

Den privaten age-Schlüssel in 1Password oder einem Hardware-Sicherheitsschlüssel wie YubiKey speichern. Den Schlüssel selbst auf Papier sichern, mit einer Passphrase verschlüsselt, in einem Bankschließfach. Ein verlorener Verschlüsselungsschlüssel ist so katastrophal wie verlorene Daten.

Wiederherstellungstests sind das Backup

Jeden Quartal eine zufällige Datei oder einen Server auswählen und komplett in einer sauberen Umgebung wiederherstellen. Messen:

RTO (Recovery Time Objective): von der Entscheidung bis zur Wiederherstellung
RPO (Recovery Point Objective): wie viele Daten verloren gingen (Stunden, Tage)
Integrität: stimmen die wiederhergestellten Bytes mit dem ursprünglichen Hash überein?

Ein reales Beispiel: Ein Team, das nächstens zu S3 Glacier Deep Archive sicherte, entdeckte beim ersten Wiederherstellungstest, dass die Bereitstellung der Restore-Berechtigungen plus das 12-Stunden-Warten auf den Abruf die RTO auf 18 Stunden brachte, obwohl das Unternehmen 4 Stunden benötigte. Sie verschoben die aktive Aufbewahrung zu Glacier Flexible (3–5-Minuten-Abruf) und behielten Deep Archive nur für Compliance-Historie. Dieser Test bewahrte sie davor, die Lektion bei einem echten Vorfall zu lernen.

Das Runbook dokumentieren, während man vorgeht: Befehle, Zugangsdaten, Entschlüsselungs-Passphrases, wer einen Restore autorisieren kann. Auf einem frischen Laptop testen, damit bekannt ist, dass das Runbook ohne die lokale Umgebung funktioniert.

Gesetzliche Aufbewahrungspflichten

Viele Regelwerke legen Mindestaufbewahrungsfristen fest:

DSGVO: keine feste Zahl; so lange wie nötig für angegebene Zwecke aufbewahren
HIPAA: 6 Jahre für Audit-Logs und Richtlinien
SOX: 7 Jahre für Finanzdaten
PCI DSS 4.0: 1 Jahr für Audit-Trails, 3 Monate „sofort verfügbar"
BDSG: Orientierung an DSGVO; für besondere Kategorien besondere Vorsicht

Backups mit Aufbewahrungsmetadaten taggen und per Lifecycle-Policies durchsetzen, damit Daten weder länger als nötig aufbewahrt (ein DSGVO-Problem) noch kürzer als erforderlich (ein SOX-Problem) aufbewahrt werden.

Überwachung und Alarmierung

Backups, die still scheitern, sind schlimmer als kein Backup. Jeder restic- oder Borg-Job sollte Metriken ausgeben: Dauer, übertragene Bytes, geänderte Dateien, Erfolg/Fehler. An Prometheus, Datadog oder ein einfaches Cron-Log senden, das von einem Dead-Man's-Snitch-artigen Tool überwacht wird, das alarmiert, wenn das erwartete Heartbeat nicht ankommt.

Alarmieren bei: Job-Fehler, übersprungener Job, Repository-Korruption (restic check), ungewöhnliche Größenänderung und fehlgeschlagenem Wiederherstellungstest.

HexaTransfer ist kein Backup-Tool — es ist für einmalige verschlüsselte Übertragungen gedacht — aber dieselben Ende-zu-Ende-Verschlüsselungsprinzipien gelten, wenn Sie ein Backup-Archiv an einen Kollegen senden. Testen Sie es unter https://hexatransfer.com — kostenlos, kein Konto, bis 10 GB.

Von der Strategie zur Disziplin

Eine Cloud-Backup-Strategie steht oder fällt mit Disziplin mehr als mit der Architektur. Nächtliche Ausführungen, vierteljährliche Wiederherstellungstests, jährliche Runbook-Überprüfungen, unveränderliche Aufbewahrung und clientseitige Verschlüsselung sind nicht glamourös, aber sie sind der Unterschied zwischen „wir hatten ein Backup" und „wir hatten eine Wiederherstellung." Aufschreiben, was man tut; automatisieren, was möglich ist; testen, was sich nicht automatisieren lässt; und die monatlichen Gesamtkosten niedrig genug halten, damit niemand im Finanzbereich Sie je bittet, sie zu reduzieren. Günstig plus langweilig schlägt teuer plus clever jedes Mal.