Backup und Recovery planen: So schützen Sie Ihre Dateien

Ein Backup- und Recovery-Plan beantwortet zwei konkrete Fragen: RPO (wie viel Datenverlust ist tolerierbar, gemessen in Zeit) und RTO (wie lange darf das System ausfallen). Definieren Sie diese Werte pro Workload und entwickeln Sie die Architektur rückwärts daraus. Eine Datenbank mit einem 5-Minuten-RPO braucht kontinuierliches WAL-Shipping; ein wöchentlicher Marketing-Bericht mit 24-Stunden-RPO kommt mit einem nächtlichen Job aus. Kombinieren Sie das mit der 3-2-1-Regel — drei Kopien, auf zwei Medientypen, eine davon extern — und testen Sie Wiederherstellungen vierteljährlich. Die meisten „wir haben Backups"-Geschichten enden schlecht, weil niemand die Wiederherstellung jemals geübt hat.

RPO und RTO: Die Ausgangszahlen

RPO (Recovery Point Objective) = maximal akzeptabler Datenverlust in Zeit. RTO (Recovery Time Objective) = maximal akzeptable Ausfallzeit.

Beispiele nach Workload:

Produktionsdatenbank für einen Onlineshop: RPO 5 Min., RTO 1 Stunde
Kundenseitige Datei-Uploads: RPO 15 Min., RTO 2 Stunden
Interner Dateiserver: RPO 24 Stunden, RTO 8 Stunden
E-Mail-Archiv: RPO 24 Stunden, RTO 48 Stunden
Marketing-Analytics: RPO 24 Stunden, RTO 72 Stunden

Engere RPO/RTO-Werte kosten mehr. Ein 5-Minuten-RPO erfordert kontinuierliche Replikation (teure Infrastruktur); ein 24-Stunden-RPO reicht ein nächtlicher Job. Nicht jeder Workload braucht einen Hot-Standby — Überengineering vermeiden.

Die 3-2-1-Regel gilt weiterhin

Drei Kopien der Daten, auf zwei verschiedenen Speichertypen, eine davon extern. Die 3-2-1-Regel stammt aus der Vor-Cloud-Ära und gilt noch immer:

Primär: Produktionsspeicher (S3, EBS, PostgreSQL-Disk)
Sekundär: Backup auf anderem Medium oder in anderer Region (weiterer S3-Bucket mit Replikation, Glacier)
Tertiär: extern, idealerweise anderer Anbieter oder Air-Gap (Backblaze B2, On-Premises-Band, physische Festplatten in einem Safe)

Der Punkt der Anbietervielfalt ist entscheidend. Ein kompromittiertes Root-AWS-Konto kann alle AWS-Backups löschen. Ein Sekundär-Backup bei Backblaze, Wasabi oder On-Premises übersteht dieses Szenario. Für Unternehmen unter 50 Mio. EUR Umsatz fügt eine Zweit-Anbieter-Kopie vielleicht 50–200 EUR/Monat hinzu und versichert gegen katastrophale mandantenweite Probleme.

Voll-, Inkrementell- und synthetisches Vollbackup

Drei Backup-Strategien:

Vollbackup: Alles jedes Mal kopieren. Einfach, schnelle Wiederherstellung (eine Datei), viel Speicher.
Inkrementelles Backup: Nur Änderungen seit dem letzten Backup kopieren. Speichereffizient, Wiederherstellung erfordert Vollbackup plus alle Inkremente.
Synthetisches Vollbackup: Serverseitiges Zusammenführen von Voll- und Inkrementbackups zu einem neuen virtuellen Vollbackup. Schnelle Wiederherstellung von jedem Punkt.

Moderne Backup-Werkzeuge (Veeam, Rubrik, restic mit Prune, BorgBackup) verwenden intern „incremental-forever" mit synthetischen Vollbackups. Das Muster: nächtliche Inkremente, wöchentliches synthetisches Vollbackup, 30 Tages- + 12 Monats- + 7 Jahres-Kopien aufbewahren (Großvater-Vater-Sohn-Rotation).

Für einen 2-TB-Dateiserver mit 5 % täglicher Änderungsrate speichert incremental-forever bei einem Jahres-Retention etwa 3–5 TB gesamt — gegenüber 700+ TB bei täglichem Vollbackup.

Verschlüsselung vor dem Transport

Backups sollten weder unverschlüsselt übertragen noch gespeichert werden. Client-seitige Verschlüsselung mit AES-256-GCM (Standard in restic, Borg, Duplicacy, Veeam u.a.) stellt sicher, dass der Backup-Host keinen Klartext sieht.

Schlüsselmanagement ist wichtiger als die Algorithmuswahl. Ein Backup, das mit einem Schlüssel verschlüsselt ist, der im selben AWS-Konto wie das Backup liegt, ist Theater — ein Angreifer mit IAM-Zugriff bekommt beides. Schlüssel speichern in:

AWS KMS mit einem Schlüssel aus einem separaten Konto (kontoübergreifende Entschlüsselung)
HashiCorp Vault in einer Out-of-Band-Umgebung
Einem Hardware-Security-Modul (YubiKey, HSM) für den Root-Schlüssel
Einem gedruckten und versiegelten Papierexemplar für wirklich kritische Schlüssel

Regelmäßig rotieren (jährlich), jeden Einsatz protokollieren und die Wiederherstellung mit einem rotierten Schlüssel testen, bevor die Rotation in der Produktion wirksam wird.

Unveränderlichkeit: Die Antwort auf Ransomware

Ransomware-Angriffe zielen 2025 häufig zuerst auf Backups ab — Produktionsdaten verschlüsseln, dann Backups löschen oder verschlüsseln, um eine Wiederherstellung zu verhindern. Unveränderliche Backups machen das zunichte.

Implementierungen:

S3 Object Lock (Compliance-Modus): Selbst Root kann während des Aufbewahrungszeitraums nicht löschen
Azure Blob Immutable Storage: Ähnlich, auf Container-Ebene durchgesetzt
Veeam Hardened Linux Repository: Append-only, nur SSH, keine Lösch-API
Physisches Band in einem Safe: Der ultimative Air-Gap

Für geschäftskritische Daten sollte mindestens eine Backup-Kopie für den Aufbewahrungszeitraum unveränderlich sein. Die zusätzlichen Kosten sind meist null — Sie hätten es ohnehin aufbewahrt. Der Wert bei einem Ransomware-Angriff ist absolut.

Tests: Der nicht-optionale Teil

Ein Backup, das Sie nie wiederhergestellt haben, ist kein Backup — es ist Hoffnung. Testplan nach Priorität:

Tier 1 (geschäftskritisch): vollständige Wiederherstellungsübung vierteljährlich, zufällige Dateiwiederherstellung monatlich
Tier 2 (geschäftlich wichtig): vollständige Wiederherstellungsübung halbjährlich, zufällige Dateiwiederherstellung vierteljährlich
Tier 3 (Standard): vollständige Wiederherstellungsübung jährlich, zufällige Dateiwiederherstellung vierteljährlich

Im Test dokumentieren:

Wie lange hat die Wiederherstellung gedauert (mit RTO vergleichen)?
Stimmten die Daten mit dem Produktionszustand überein (Prüfsummen gegen einen bekannten Zeitpunkt)?
Gab es Probleme bei der Wiederherstellung von Berechtigungen oder Konfigurationen?
Was hat nicht funktioniert und wie wurde es behoben?

Unternehmen, die Tests überspringen, entdecken korrupte Backups bei echten Vorfällen — das teuerste aller denkbaren Lernmöglichkeiten.

Datenbankbackups brauchen einen eigenen Plan

Dateien und Datenbanken werden unterschiedlich gesichert. Ein während einer Transaktion kopiertes .pgdata-Verzeichnis ist korrupt. Verwenden Sie native Werkzeuge:

PostgreSQL: pg_basebackup + WAL-Archivierung für PITR, pg_dump für logische Sicherungen
MySQL: Percona XtraBackup für physische Hot-Backups, mysqldump für logische
MongoDB: mongodump, Replica-Sets mit verzögerten Secondaries
Microsoft SQL Server: natives Backup mit BACKUP DATABASE, Log-Shipping für PITR

Für eine 500-GB-PostgreSQL-Datenbank mit 5-Minuten-RPO liefern nächtliche Basis-Backups plus kontinuierliches WAL-Archiving nach S3 eine Point-in-Time-Wiederherstellung auf jede Sekunde der letzten 30 Tage. Wiederherstellungszeit: Basis-Backup laden (30 Min.), WAL bis Zielzeitpunkt wiederholen (5–30 Min.). Enges RTO bedeutet ein warmes Replikat bereit zur Promotion.

Anwendungskonsistente Snapshots

Dateisystem-Snapshots (ZFS, Btrfs, AWS EBS, Azure Managed Disks, GCP Persistent Disk) frieren einen Zeitpunkt auf Block-Ebene ein. Für Datenbanken kombinieren Sie das mit dem Quieszieren der Anwendung:

pg_start_backup('label') (PostgreSQL) oder FLUSH TABLES WITH READ LOCK (MySQL)
Snapshot erstellen
pg_stop_backup() oder entsperren

Der Snapshot ist anwendungskonsistent — ohne Crash-Recovery wiederherstellbar. AWS Backup, Azure Backup und Google Cloud Backup automatisieren dieses Muster für gängige Datenbanken.

Backup-Archive an Dritte übertragen

Wenn Backups an externe Parteien gehen müssen — Prüfer, Regulierungsbehörden, Nachfolgetreuhänder — braucht die Übertragung selbst Sorgfalt. FTP ist veraltet; E-Mail-Anhänge stoßen an Größengrenzen; USB-Laufwerke auszuhändigen ist langsam.

Ende-zu-Ende-verschlüsselte Dateiübertragung bewältigt die ad-hoc-Verteilung von Backups sauber. HexaTransfer überträgt Dateien bis 10 GB mit clientseitiger AES-256-GCM-Verschlüsselung und einem Einmal-Link. Ideal, um einen Datenbank-Snapshot an einen Wirtschaftsprüfer zu senden, ohne ihm Zugriff auf Ihre S3-Buckets einräumen zu müssen.

Dokumentation ist Teil des Backups

Das beste Backup der Welt nützt nichts, wenn die Person, die es wiederherstellen kann, im Urlaub ist und niemand sonst weiß wie. Dokumentieren Sie:

Was gesichert wird und was nicht (explizite Ausschlüsse)
Zeitplan und Retention pro Workload
Schlüsselmanagement und Zugang
Wiederherstellungs-Runbooks mit schrittweisen Befehlen
Kontaktliste (Anbieter-Support, Bereitschaftsdienst)
Testergebnisse und Daten

Drucken Sie eine Kopie aus. Bewahren Sie eine Kopie im physischen Safe mit den Notfallschlüsseln auf. Wenn Ihr Backup-Runbook nur auf einer Confluence-Seite liegt, die von der soeben ausgefallenen Infrastruktur betrieben wird, haben Sie ein Problem. Papier funktioniert noch, wenn nichts anderes mehr tut.

RPO/RTO definieren, 3-2-1 mit Unveränderlichkeit umsetzen, clientseitig verschlüsseln, vierteljährlich testen, lückenlos dokumentieren. Backup-Erfolg ist zu 10 % Technologie und zu 90 % Disziplin.

Jetzt kostenlos testen auf hexatransfer.com — kein Konto, max. 10 GB.