Backup & Restore
Backup & Restore
Backup & Restore ist die Disziplin der Datensicherung und des Wiederanlaufs: unabhängige Kopien anlegen, sicher aufbewahren, Wiederherstellbarkeit nachweisen.
- 3-2-1 bzw. 3-2-1-1-0
- RPO und RTO als Planungsgrößen
- Immutability und Air-Gap gegen Ransomware
- Voll, inkrementell, differenziell
- Restore-Test als Pflicht
Backup & Restore ist die Disziplin, Daten so zu sichern, dass sie nach einem Verlust zuverlässig wiederhergestellt werden können. Der zweite Teil ist der wichtigere: Ein Backup, das nie auf Wiederherstellbarkeit getestet wurde, ist kein Backup, sondern eine Hoffnung. Seit Ransomware gezielt die Sicherungen angreift, hat sich der Fokus von „läuft das Backup?“ zu „ist die Sicherung unabhängig, unveränderbar und wiederherstellbar?“ verschoben.
Dieser Artikel klärt die Abgrenzung zu Snapshot, Replikation und Archivierung, erklärt RPO und RTO, die Backup-Arten, die 3-2-1- und 3-2-1-1-0-Regel, Immutability und Air-Gap, Konsistenz (crash- vs. application-consistent), Deduplizierung und GFS-Retention, den Restore-Test sowie die regulatorische Einordnung (BSI-Grundschutz, NIS2). Konkrete Werkzeuge wie Proxmox Backup Server, Veeam, Bareos oder Restic behandeln eigene Artikel.
1. Was ein Backup ist und was nicht
Ein Backup ist eine eigenständige, vom Quellsystem getrennte Kopie. Davon abzugrenzen sind verwandte Verfahren mit anderem Zweck:
- Snapshot schneller Wiederherstellungspunkt auf derselben Plattform; teilt deren Fehlerdomäne. Bei Storage-Ausfall oder Ransomware oft mitbetroffen, also kein Ersatz.
- Replikation spiegelt Daten auf ein zweites System für Hochverfügbarkeit; repliziert aber auch Fehler und Verschlüsselung sofort mit.
- Archivierung langfristige, revisionssichere Aufbewahrung aus Compliance-Gründen; dient nicht der schnellen Recovery.
- Hochverfügbarkeit redundante Komponenten gegen Ausfall einzelner Teile; schützt nicht vor logischem Datenverlust.
Snapshot ist kein Backup
Der häufigste konzeptionelle Fehler: Ein VM- oder Storage-Snapshot liegt auf derselben Plattform wie die Quelldaten. Fällt das Storage-System aus oder verschlüsselt Ransomware es, sind die Snapshots in der Regel mit verloren. Snapshots ergänzen Backups (schnelles Rollback), ersetzen sie aber nicht.
2. RPO und RTO
Zwei Kennzahlen steuern jedes Backup-Design. Das RPO (Recovery Point Objective) ist der maximal tolerierbare Datenverlust, gemessen rückwärts vom Ausfall: Wie viel Arbeit darf verloren gehen? Es bestimmt die Sicherungshäufigkeit. Das RTO (Recovery Time Objective) ist die maximal tolerierbare Ausfalldauer, gemessen vorwärts: Wie lange darf der Wiederanlauf dauern? Es bestimmt Restore-Technik und Infrastruktur. Beide werden pro System differenziert festgelegt, denn eine Produktivdatenbank hat andere Anforderungen als ein Archiv-Share.
3. Backup-Arten
Die Verfahren unterscheiden sich in Speicherbedarf, Sicherungsdauer und Restore-Aufwand:
- Vollbackup komplette Kopie; höchster Platzbedarf, aber Restore in einem Schritt.
- Inkrementell nur Änderungen seit dem letzten Backup; sparsam, aber Restore braucht die ganze Kette.
- Differenziell alle Änderungen seit dem letzten Voll; Restore aus Voll plus einem Differenzial.
- Synthetisches Vollbackup der Backup-Server fügt Inkremente serverseitig zu einem Voll zusammen, ohne die Quelle erneut zu lesen.
- Forever-Incremental nach einem einmaligen Voll dauerhaft nur Inkremente; die Software fügt sie serverseitig regelmäßig zu einem synthetischen Vollstand zusammen, ohne die Quelle erneut zu lesen.
4. 3-2-1 und 3-2-1-1-0
Die bewährte 3-2-1-Regel verlangt drei Kopien der Daten auf zwei verschiedenen Medientypen, davon eine an einem anderen Ort. Gegen Ransomware wurde sie zu 3-2-1-1-0 erweitert: zusätzlich eine Kopie offline, air-gapped oder immutable, und null Fehler nach automatisierter Wiederherstellungs-Verifikation. Das ist ein Industrie-Richtwert, keine Norm, aber inhaltlich tragfähig.
Immutability/WORM verhindert, dass Backups nachträglich überschrieben oder gelöscht werden, selbst durch kompromittierte Admin-Konten. Technisch umgesetzt etwa über S3 Object Lock (Governance- oder Compliance-Modus) oder unveränderbare Repositories. Ein Air-Gap trennt das Backup-Ziel physisch (Band, getrennter Datenträger) oder logisch (eigene Anmeldung, strikte Segmentierung, eigene Schlüssel).
Ransomware-Akteure greifen heute zuerst die Backups an, oft Wochen vor der eigentlichen Verschlüsselung. Eine Sicherung, die mit denselben Admin-Credentials löschbar ist wie die Produktion, ist im Ernstfall keine Versicherung, sondern Teil des Schadens. Unabhängigkeit und Unveränderbarkeit sind kein Luxus, sondern der Kern.
5. Konsistenz, Deduplizierung und Verschlüsselung
Ein Backup ist crash-consistent, wenn es dem Zustand nach einem Stromausfall entspricht; für Dateiserver meist ausreichend. Datenbanken (SQL, Exchange, Oracle) brauchen application-consistent Backups: Anwendungen werden vor dem Snapshot kurz in einen konsistenten Zustand gebracht (unter Windows über VSS, unter Linux per Agent oder DB-API). Deduplizierung und Komprimierung senken den Speicherbedarf erheblich, indem identische Datenblöcke nur einmal gespeichert werden. Die Verschlüsselung gehört in Transit und at rest aktiviert, und der Schlüssel muss getrennt vom gesicherten System aufbewahrt werden, sonst ist er im Ransomware-Fall mit verloren.
6. Retention, Restore-Test und Regulatorik
Die Aufbewahrung folgt oft dem GFS-Schema (Grandfather-Father-Son): tägliche, wöchentliche und monatliche Sicherungen mit gestaffelter Aufbewahrung. Zentral bleibt der Restore-Test: Wiederherstellung in eine isolierte Umgebung, Funktionsprüfung, Zeitmessung gegen das RTO. Regulatorisch fordert der BSI-Grundschutz (Baustein CON.3) ein Datensicherungskonzept mit getrennter Aufbewahrung und regelmäßigen Wiederherstellungstests. Für regulierte Einrichtungen nennt NIS2 (über das BSIG) Backup-Management und Notfall-Wiederherstellung ausdrücklich als Maßnahme, im Rahmen der Verhältnismäßigkeit. Steuerliche Aufbewahrungspflichten (GoBD) sind eine eigene, ergänzende Anforderung und mit reiner Datensicherung nicht gleichzusetzen.
7. Typische Fehler
| Gut gemeint | Besser |
|---|---|
| Backup läuft, niemand testet den Restore | Restore regelmäßig in isolierter Umgebung üben |
| Sicherung im selben Netz, mit denselben Admin-Rechten löschbar | mindestens eine immutable oder offline Kopie |
| Snapshot auf demselben Storage gilt als Backup | unabhängige Kopie auf anderem Medium und Ort |
| Ein Zeitplan für alle Systeme | RPO/RTO pro System differenzieren |
| Verschlüsselungsschlüssel nur auf dem gesicherten System | Schlüssel getrennt und sicher verwahren |
Häufige Fragen zu Backup & Restore
Nein. Snapshots liegen auf derselben Plattform wie die Originaldaten und teilen deren Schicksal bei Storage-Ausfall oder Ransomware. Sie sind ein schnelles Rollback-Werkzeug, ersetzen aber keine unabhängige, idealerweise unveränderbare Kopie an einem anderen Ort.
Null Fehler nach einer automatisierten Wiederherstellungs-Verifikation. Es genügt nicht, dass ein Backup geschrieben wurde; es muss nachweislich wiederherstellbar sein. Erst der erfolgreiche, getestete Restore macht aus einer Sicherung eine belastbare Absicherung.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Backup & Restore im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.