Immutable Backup: Wovor es wirklich schützt, wie es funktioniert und wie lange man sperren sollte
- Ein unveränderliches Backup kann für einen festgelegten Zeitraum von niemandem geändert, gelöscht oder verschlüsselt werden, auch nicht vom Backup-Administrator; es ist eine logische Kontrolle, kein Air Gap
- Auf einem Veeam Hardened Repository ist die Sperre das Linux-Attribut „immutable“, gesetzt von einem Dienst mit Root-Rechten, 7 bis 9.999 Tage, gezählt ab dem letzten Wiederherstellungspunkt der Kette und auf die ganze Kette neu angewandt
- Auf Objektspeicher schreibt Veeam S3 Object Lock immer im Compliance-Modus, 1 bis 999 Tage, plus eine Block Generation von 10 oder 30 Tagen; nicht einmal der Root-Nutzer des Cloud-Kontos kann vor Ablauf löschen
- Es schützt nicht gegen einen Angreifer, der die Sperrfrist aussitzt, gegen an der Quelle verschlüsselte und treu gesicherte Daten, ein kompromittiertes Cloud-Konto im Governance-Modus, physischen Zugang zur Maschine oder eine Wiederherstellung in ein noch infiziertes Netz
- Bemessen Sie die Sperrfrist an der Verweildauer: Mandiants globaler Median lag für Einbrüche 2025 bei 14 Tagen; sieben Tage sind die technische Untergrenze, dreißig Tage oder die volle Job-Aufbewahrung sind der vertretbare Standard
Was unveränderlich bedeutet, und was nicht
Veeams Definition ist die der Branche: ein Backup, das für einen festgelegten Zeitraum nicht geändert, gelöscht oder verschlüsselt werden kann. Das wichtige Wort ist: von niemandem. Eine sauber gebaute unveränderliche Kopie übersteht ein gestohlenes Passwort des Backup-Administrators, einen kompromittierten Backup-Server und einen Ransomware-Betreiber, der das Repository gefunden hat, weil der Löschbefehl dort verweigert wird, wo die Daten liegen, nicht dort, woher die Anfrage kommt.
Es ist kein Air Gap. Die NIST-Definition eines Air Gap verlangt keine physische Verbindung und keine automatisierte logische Verbindung; ein Bucket mit Object Lock und ein Hardened Repository sind online, erreichbar und schreiben jede Nacht. Anbieter, die ihre Online-Tresore als „logisch air-gapped“ beschreiben, benutzen Marketingsprache. Der Unterschied zählt, wenn eine Aufsichtsbehörde oder ein Auditor fragt, was „offline“ in Ihrer Backup-Richtlinie bedeutet, und er zählt in den Ausfallszenarien am Ende dieses Artikels. Immutability ist die „1“ in Veeams 3-2-1-1-0-Regel: drei Kopien, zwei Medien, eine außer Haus, eine offline oder unveränderlich, null Fehler nach der Prüfung.
Wie ein Hardened Repository die Sperre durchsetzt
Ein Veeam Hardened Repository (ein gehärtetes Repository) ist ein Linux-Server mit lokalem Blockspeicher. Zwei Dienste laufen darauf: der Transportdienst, der die Daten bewegt und als Nicht-Root-Nutzer läuft, und der Immutability-Dienst, der als dessen Kindprozess mit Root-Rechten läuft, die Dateien alle zwanzig Minuten prüft und das Attribut „immutable“ setzt oder entfernt. Das Dateisystem muss unveränderliche Dateien und erweiterte Attribute unterstützen, weshalb XFS die empfohlene Wahl ist, und jede Backup-Datei bekommt eine Lock-Datei und ein Attribut mit ihrem Ablaufdatum. Der Server wird mit Einmal-Zugangsdaten hinzugefügt, die nirgendwo in der Backup-Infrastruktur gespeichert werden; danach verliert das Konto sudo, und SSH wird deaktiviert, sodass ein kompromittierter Backup-Server nichts hat, womit er sich anmelden könnte. In Version 13 ist der empfohlene Aufbau die Veeam Infrastructure Appliance mit der Rolle Hardened Repository: nur Zertifikatsauthentifizierung, gar kein SSH, Multi-Faktor-Authentifizierung, die sich nicht abschalten lässt, kein Domain-Join.
| REGEL | WAS DAS IN DER PRAXIS HEISST |
|---|---|
| Sperrfrist | 7 bis 9.999 Tage; der Assistent lehnt alles Kürzere ab |
| Wo die Uhr startet | am letzten Wiederherstellungspunkt der aktiven Kette, und die Frist wird bei jedem erfolgreichen Lauf auf jede Datei dieser Kette neu angewandt |
| Rechenbeispiel | Vollsicherung am 12. Januar, letztes Inkrement am 14. Januar, Frist zehn Tage: alles in der Kette ist bis zum 24. Januar gesperrt |
| Backup-Methode | nur Forward Incremental mit periodischen Vollsicherungen; Reverse Incremental und Forever Forward Incremental müssten gesperrte Dateien umschreiben |
| GFS-Punkte | eine jährliche Vollsicherung ist für die längere von Repository-Frist und eigener Lebensdauer gesperrt; ihre Inkremente nur für die Repository-Frist |
| Verkürzen der Einstellung | wirkt nur auf künftige Wiederherstellungspunkte; bereits gesperrte Dateien behalten ihr Ablaufdatum |
| Metadaten | die .VBM-Datei wird nie gesperrt, weil sie bei jedem Lauf neu geschrieben wird; geht sie verloren, importieren Sie aus den .VBK-Dateien |
| Fehlgeschlagene Sitzungen | das Flag wird erst nach einer abgeschlossenen Sitzung gesetzt; ein fehlgeschlagener Lauf, gefolgt von einer neuen Vollsicherung, lässt die fehlgeschlagenen Dateien ungesperrt |
| Log-Backups | Log-Dateien von SQL, Oracle und PostgreSQL werden nicht mit der Kette verlängert; die Frist muss die ganze Kette abdecken, sonst scheitert eine Log-Wiederherstellung |
| Angriffe auf die Uhr | eine Verstellung der Uhr um mehr als 24 Stunden oder eine mehr als 24 Stunden ausgeschaltete Maschine blockiert jede Aufbewahrung, bis ein Administrator sie zurücksetzt |
Dokumentation zu Veeam Backup & Replication 13.1, September 2026; die Mechanik ist in 12.3 dieselbe.
Daraus folgen zwei Konstruktionsregeln. Der Immutability-Zeitraum muss mindestens so lang sein wie die Kette, sonst werden die ältesten Dateien entsperrt, bevor die Kette schließt; und Immutability hat Vorrang vor der Aufbewahrung, Dateien mit abgelaufener Aufbewahrung bleiben also auf der Platte, bis die Sperre abläuft, und das ist Kapazität, die Sie einplanen müssen.
Wie Object Lock sie durchsetzt
Auf Amazon S3 und S3-kompatiblem Speicher ist die Sperre eine Eigenschaft der Objektversion. Object Lock setzt Versionierung voraus, wird auf dem Bucket aktiviert und lässt sich danach nicht mehr deaktivieren. Jede Version trägt ein Retain-until-Datum in einem von zwei Modi. Compliance-Modus heißt, dass niemand, auch nicht der Root-Nutzer des Kontos, sie löschen oder verkürzen kann; AWS erklärt, der einzige Ausweg vor Ablauf sei das Löschen des Kontos. Governance-Modus kann von einem Principal mit der Bypass-Berechtigung umgangen werden, der einen expliziten Header sendet, und das ist genau die Berechtigung, die ein kompromittierter Cloud-Administrator nutzen würde. Veeam schreibt deshalb jedes Objekt im Compliance-Modus mit einem Zeitraum von 1 bis 999 Tagen und verwaltet die Aufbewahrung selbst; der Bucket muss Object Lock und Versionierung eingeschaltet, die Standardaufbewahrung ausgeschaltet und keine Lifecycle-Regeln haben, und diese Einstellungen dürfen nach dem Hinzufügen des Buckets nie mehr geändert werden.
Veeam sperrt Datenblöcke statt Dateien und fügt eine Block Generation hinzu, damit Inkremente, die innerhalb einer Generation geschrieben werden, das Ablaufdatum der Vollsicherung teilen, ohne einen API-Aufruf je Block: 30 Tage auf Amazon S3, IBM, Google und 11:11, 10 Tage auf allem anderen, einschließlich S3-kompatibler Appliances vor Ort und Azure. Die tatsächliche Zeit auf dem Speicher ist deshalb die Job-Aufbewahrung oder die minimale Immutability plus die Block Generation: Veeams eigenes Beispiel sind 13 Tage Aufbewahrung, 7 Tage minimale Immutability und eine Generation von 10 Tagen, gelöscht nach 23 Tagen. Seit dem ersten Patch für 13.0 sperrt der Standardmodus für die gesamte Aufbewahrungsdauer statt für das Minimum. Azure funktioniert genauso, mit Immutability auf Versionsebene und Blob-Versionierung, nur auf neuen Containern, und nur eine gesperrte Richtlinie ist Compliance-tauglich; eine ungesperrte lässt sich entfernen.
Wogegen es nicht schützt
Die Liste ist länger als die Verkaufspräsentation.
| BEDROHUNG | WARUM IMMUTABILITY ALLEIN VERSAGT |
|---|---|
| Ein Angreifer, der wartet | Sperren laufen ab; mit einer Frist von sieben Tagen und einer mittleren Verweildauer von zwei Wochen sind die Kopien, die Sie brauchen, möglicherweise wieder veränderbar, wenn Sie es bemerken |
| An der Quelle verschlüsselte Daten | das Repository bewahrt treu, was es bekommen hat; Inline-Scanning ist standardmäßig aus und sieht schlafende Malware nicht |
| Kompromittiertes Cloud-Konto | Umgehung im Governance-Modus, eine ungesperrte Azure-Richtlinie oder schlicht eine unbezahlte Rechnung und ein geschlossenes Konto |
| Falsch konfigurierte Buckets | Standardaufbewahrung an, Lifecycle-Regeln, umgeschaltete Versionierung, ein wiederverwendeter Container: alles von Veeam als Ursache für Datenverlust dokumentiert |
| Physischer, Konsolen- oder Out-of-Band-Zugang | wer einen Live-USB-Stick oder einen ungesicherten BMC hat, kann die Maschine neu formatieren; Immutability ist eine logische Kontrolle |
| Ein einziges Repository | ein Platten-, RAID- oder Firmware-Ausfall oder ein Brand wird von einem Flag nicht abgedeckt; die EU-Durchführungsvorschriften zu NIS2 verlangen Kopien in einem anderen Netz in ausreichender Entfernung |
| Eine Frist kürzer als die Kette | Log-Backups werden nicht verlängert, fehlgeschlagene Läufe bleiben ungesperrt, und die .VBM wird nie gesperrt |
| Wiederherstellung ins kompromittierte Netz | die Kopien sind sauber; die Umgebung nicht; DORA verlangt die Wiederherstellung auf physisch und logisch getrennten Systemen |
| Replikate, die für die unveränderliche Kopie gehalten werden | ein Replikat ist eine lebende, veränderbare VM-Kopie, die Verschlüsselung mitrepliziert und von einem kompromittierten Hypervisor-Administrator gelöscht werden kann |
Sophos hat 2024 gemessen, was auf dem Spiel steht: 94 Prozent der von Ransomware getroffenen Organisationen gaben an, die Angreifer hätten es auf die Backups abgesehen, und 57 Prozent dieser Versuche waren erfolgreich. Mandiants Bericht von 2026 stellt fest, dass Ransomware-Betreiber gezielt Backup-Infrastruktur, Identitätsdienste und die Management-Ebenen der Virtualisierung angegriffen haben. Die unveränderliche Kopie ist die Antwort auf den ersten Teil dieses Befunds; der Rest des Cyber-Resilienz-Designs beantwortet die übrigen.
Wie lange sperren: das Argument der Verweildauer
Die Frist muss die Zeit überdauern, die ein Eindringling im Netz verbringt, bevor es jemand bemerkt, plus die Zeit für Entscheidung und Wiederherstellung. Mandiants globale mediane Verweildauer lag bei 11 Tagen für Einbrüche 2024 und bei 14 Tagen für 2025, mit einem langen Ausläufer: 122 Tage bei Spionagefällen und rund 400 bei einer Kampagne. Ransomware-Gruppen verkürzen sie selbst, fünf Tage, wenn der Angreifer die Verschlüsselung bekannt gibt, aber die Daten wurden oft lange vorher bereitgestellt und abgezogen. Auf der Wiederherstellungsseite fand die Sophos-Umfrage 2026 nur 55 Prozent der Opfer innerhalb einer Woche wieder arbeitsfähig und 83 Prozent innerhalb eines Monats.
| EINSTELLUNG | URTEIL |
|---|---|
| 7 Tage | die technische Untergrenze auf einem Hardened Repository, keine Empfehlung; kürzer als die mediane Verweildauer |
| 14 Tage | entspricht dem Median 2025; die Hälfte aller Einbrüche dauert länger |
| 30 Tage | deckt die meisten Erkennungs- und Entscheidungszyklen ab; unser Standard für das primäre Hardened Repository |
| Gesamte Job-Aufbewahrung | der Standard von Version 13 auf Objektspeicher; die richtige Antwort, wo das Speicherbudget es erlaubt |
| Monatliche und jährliche GFS-Punkte | automatisch für ihre gesamte Lebensdauer gesperrt; der Langzeitschutz braucht keine zusätzliche Einstellung |
Die letzten drei Zeilen sind Einschätzung; die Mechanik und die Zahlen zur Verweildauer sind belegt.
Auf Objektspeicher ist jeder zusätzliche Tag bezahlter Speicher, plus die Block Generation, weshalb Veeam selbst davor warnt, länger als die Job-Aufbewahrung zu sperren. Auf einem Hardened Repository sind die Kosten Platten, und Platten sind günstig verglichen mit einer Woche, in der das Unternehmen stillsteht.
Beweisen, dass die Kopie funktioniert
Die Null in 3-2-1-1-0 ist die Prüfung. SureBackup startet Maschinen aus dem Backup in einem isolierten Labor, führt Heartbeat-, Ping- und Anwendungstests aus und kann den Inhalt mit Antivirus und YARA-Regeln scannen; ein leichterer Modus prüft und scannt ohne Labor. Secure Restore scannt einen Wiederherstellungspunkt, bevor er die Produktion berührt, und bricht ab oder stellt mit Einschränkungen wieder her, wenn er Malware findet. Keines von beiden ersetzt eine geübte Wiederherstellungsreihenfolge, die unser Leitfaden zu RPO und RTO behandelt, und keines hilft, wenn das Wiederherstellungsziel dasselbe Netz ist, in dem der Angreifer noch sitzt. Veeams Umfrage 2025 fand nur 44 Prozent der Playbooks mit Verfahren zur Backup-Prüfung; diese Zahl ist der Grund, warum es diesen Abschnitt gibt.
Die regulatorischen Anker
NIS2 führt Backup-Management und Disaster Recovery in Artikel 21 unter den Mindestmaßnahmen auf; die Durchführungsverordnung der Kommission vom Oktober 2024 buchstabiert es aus: Sicherungskopien an Orten, die nicht im selben Netz liegen, Aufbewahrungsfristen nach geschäftlichen und regulatorischen Anforderungen, regelmäßige Integritätsprüfungen und regelmäßige Wiederherstellungstests. Artikel 12 von DORA verlangt dokumentierte Backup-Richtlinien mit Umfang und Mindesthäufigkeit, regelmäßige Tests und die Wiederherstellung auf Systemen, die physisch und logisch von der Quelle getrennt sind. Artikel 32 der DSGVO verlangt die Fähigkeit, die Verfügbarkeit personenbezogener Daten rasch wiederherzustellen, und die regelmäßige Überprüfung der Maßnahmen. Keiner von ihnen sagt „unveränderlich“; alle sind leichter zu beantworten mit einer unveränderlichen Kopie, die planmäßig wiederhergestellt wurde, und genau darum ist unser Disaster-Recovery-Service gebaut.
Was wir bauen
Eurokommerz plant und betreibt Backup-Umgebungen auf Veeam in der ganzen EU mit unserem Engineering-Partner Vixen.UNO: ein Hardened Repository auf lokaler Platte als primäre unveränderliche Kopie, eine Object-Lock-Kopie außer Haus im Compliance-Modus, GFS-Punkte für ihre Lebensdauer gesperrt, SureBackup nach Zeitplan und eine schriftlich festgelegte Frist, die zum Wiederherstellungsplan des Unternehmens passt statt zum Minimum des Assistenten. Schicken Sie uns die aktuelle Job-Liste und die Aufbewahrung, und wir liefern die Lücken.
FAQ
Ist ein unveränderliches Backup dasselbe wie ein Backup mit Air Gap?
Wie lang sollte die Sperrfrist sein?
Kann der Backup-Administrator ein unveränderliches Backup löschen?
Warum ist die tatsächliche Aufbewahrung auf Objektspeicher länger als konfiguriert?
Schützt Immutability gegen Ransomware, die die Dateien vor dem Backup verschlüsselt hat?
Verlangen NIS2 oder DORA unveränderliche Backups?
Schicken Sie uns die Liste der Backup-Jobs, die Aufbewahrung und wo die Kopien liegen. Wir liefern die Immutability-Lücken, die Frist, die wir setzen würden, und den Plan für den Wiederherstellungstest. Wir antworten innerhalb eines Werktages.
Mit einem Experten sprechenWir antworten innerhalb eines Werktages