Unveränderliches Backup (Immutable Backup): wovor es schützt, wie es arbeitet und wie lange Sie sperren
Eurokommerz, Wien, seit 2006: Private AI/ML · IT Managed Services · Enterprise Training · KI-Hardware & Software
- 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 zum Server 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
Eurokommerz × Vixen.UNO: Cyber-Resilienz Experten kontaktieren →
Unveränderliches Backup: Bedeutung und Unterschied zum Air Gap
Veeam definiert ein unveränderliches Backup als eines, das für einen festgelegten Zeitraum nicht geändert, gelöscht oder verschlüsselt werden kann, und die Branche verwendet dieselbe Definition. Die Sperre gilt für jedes Konto, auch für das des Backup-Administrators. Eine sauber gebaute unveränderliche Kopie übersteht deshalb ein gestohlenes Passwort des Backup-Administrators, einen kompromittierten Backup-Server und einen Ransomware-Betreiber, der das Repository gefunden hat, weil der Speicher selbst den Löschbefehl verweigert, gleich von welchem Konto er kommt. Das technische Assessment unseres Service Cyber-Resilienz prüft Ihre Infrastruktur, Zugriffe und Backups. Schildern Sie kurz Ihre Backup-Umgebung, und unser Team hilft Ihnen weiter.
Ein unveränderliches Backup 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. Manche Anbieter nennen ihre Online-Tresore „logisch air-gapped“; nach der NIST-Definition ist ein solcher Tresor dennoch eine Online-Kopie. 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. Eine unveränderliche Kopie kann als zweite „1“ in Veeams 3-2-1-1-0-Backup-Regel dienen: drei Kopien, zwei Medien, eine außer Haus, eine offline, per Air Gap getrennt oder unveränderlich, null Fehler nach der Wiederherstellungsprü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 (Veeam empfiehlt XFS), und jede Backup-Datei bekommt eine Lock-Datei und ein Attribut mit ihrem Ablaufdatum. Einen Server, den Sie selbst bauen, fügt Veeam mit Einmal-Zugangsdaten hinzu, die nirgendwo in der Backup-Infrastruktur gespeichert werden; danach weist Veeams Benutzerhandbuch den Administrator an, dieses Konto aus der sudoers-Datei zu entfernen und SSH zu deaktivieren, 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 Veeam Hardened Repository: nur zertifikatsbasierte Authentifizierung, gar kein SSH, kein Domain-Join. Die Multi-Faktor-Authentifizierung (MFA) für die Konten veeamadmin und veeamso der Appliance wurde in 13.0 bei der Bereitstellung erzwungen; seit 13.1 lässt sich die Appliance ohne sie installieren und MFA später in der Host Management console aktivieren, prüfen Sie also, ob beide Konten MFA haben. Welches Repository Sie auch aufbauen, betreiben Sie den Backup-Server mit Veeam Backup & Replication ab Build 13.1.0.411 (auf 13.0 ab 13.0.3.63, auf 12.3 ab 12.3.2.4934); in diesen Builds behebt Veeam laut KB4902 die Schwachstelle CVE-2026-58069 (Stand Oktober 2026). Unser Leitfaden zum Veeam Hardened Repository behandelt Anforderungen, Aufbau und Kapazitätsplanung.
| 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 ein mehr als 24 Stunden ausgeschalteter Server 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. Wo Log-Backups von SQL, Oracle oder PostgreSQL laufen, muss der Immutability-Zeitraum die ganze Kette abdecken, weil deren Dateien nicht mit ihr verlängert werden; 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 anderer Cloud-Objektspeicher. 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. Andere Cloud-Objektspeicher, die Veeam unterstützt, folgen demselben Muster mit ihren eigenen Einstellungen für Versionierung und Immutability; nur eine gesperrte Aufbewahrungsrichtlinie ist Compliance-tauglich, denn eine ungesperrte lässt sich entfernen.
Wogegen es nicht schützt
Gegen die folgenden Bedrohungen schützt Immutability allein nicht.
| 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 Aufbewahrungsrichtlinie oder ein Konto, das nach einer unbezahlten Rechnung geschlossen wurde |
| Governance-Modus unter Linux | neu in Veeam 13.1 für Standard-Linux-Repositorys; nach Veeams Beschreibung bleibt das Löschen von Backups auf der Ebene des Systemadministrators möglich, ein gestohlenes Administratorkonto dieses Servers kann Backups also weiterhin entfernen |
| 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 den Server 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; halten Sie eine zweite Kopie in einem anderen Netz, weit genug entfernt, um eine Katastrophe am Hauptstandort zu überstehen |
| 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 | saubere Kopien, die in ein Netz zurückgespielt werden, das der Angreifer noch kontrolliert, können erneut kompromittiert werden; stellen Sie auf Systemen wieder her, die von den kompromittierten getrennt sind und vor der Nutzung geprüft wurden |
| 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 |
In der Sophos-Umfrage von 2024 gaben 94 Prozent der von Ransomware getroffenen Organisationen 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 richtet sich gegen die Angriffe auf die Backup-Infrastruktur; die übrigen Teile eines Designs für Cyber-Resilienz richten sich gegen die Angriffe auf Identitätsdienste und Management-Ebenen.
Unser Cyber-Resilienz-Service deckt diese Teile mit Zero-Trust-Zugriff, Netzwerksegmentierung, Multi-Faktor-Authentifizierung und Privileged Access Management ab. Beschreiben Sie im Formular unten, wie Administratoren auf die Backup-Server, das Hypervisor-Management und die Identitätsdienste zugreifen; das erste Gespräch ist kostenlos.
Wie lang die Sperrfrist sein sollte
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 Fällen mit nordkoreanischen IT-Mitarbeitern und fast 400 bei einer Kampagne. Ransomware-Akteure verkürzen sie selbst, 2024 auf fünf Tage, wenn sich der Angreifer zu erkennen gab, 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; ein vertretbarer Standard für ein primäres Hardened Repository |
| Gesamte Job-Aufbewahrung | die richtige Antwort, wo das Speicherbudget es erlaubt; auf Objektspeicher prüfen, welche Immutability-Einstellung das Repository nutzt |
| 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 kostet die längere Frist die Plattenkapazität für die zusätzlichen Tage an Wiederherstellungspunkten.
Die unveränderliche Kopie prüfen: SureBackup und Secure Restore
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. Laut Veeams Umfrage von 2025 enthielten nur 44 Prozent der Playbooks Verfahren zur Backup-Prüfung.
Was NIS2 und die Durchführungsverordnung verlangen
NIS2 führt Backup-Management und Disaster Recovery in Artikel 21 unter den Mindestmaßnahmen auf. Die Durchführungsverordnung (EU) 2024/2690 der Kommission gilt nur für die in ihrem Artikel 1 genannten Einrichtungen (DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten und Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter); jede andere Organisation im Anwendungsbereich von NIS2 ist an das nationale Gesetz gebunden, das Artikel 21 der Richtlinie (EU) 2022/2555 umsetzt, und welcher Text für Sie gilt, ist von Ihrer Rechtsabteilung zu bestätigen. Für diese Einrichtungen konkretisiert die Durchführungsverordnung der Kommission vom Oktober 2024 die Anforderungen: 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 32 der DSGVO verlangt die Fähigkeit, die Verfügbarkeit personenbezogener Daten rasch wiederherzustellen, und die regelmäßige Überprüfung der Maßnahmen. In diesen Texten haben wir das Wort „unveränderlich“ nicht gefunden. Eine unveränderliche Kopie ist ein technischer Weg, die Kopien gegen Löschen mit gestohlenen Administrator-Zugangsdaten zu schützen, und dokumentierte Wiederherstellungstests zeigen, dass sich die Kopien wiederherstellen lassen; unser Leitfaden zu den NIS2-Anforderungen an Backup und Business Continuity geht den Anhang Nummer für Nummer durch. Unser Service Cloud Disaster Recovery führt planmäßige Failover-Tests in isolierter Umgebung durch, mit einem Bericht nach jedem Test: was wieder anlief, wie schnell und was zu beheben ist.
Was wir tun
Im Rahmen unseres Service Cyber-Resilienz beginnt das Team unseres Engineering-Partners Vixen.UNO mit einem kostenpflichtigen technischen Assessment von Infrastruktur, Zugriffen und Backups, das mit einer Risikokarte und einem priorisierten Maßnahmenplan endet; sein Preis steht vor Beginn fest. Regelmäßige Wiederherstellungstests, Netzwerksegmentierung, Multi-Faktor-Authentifizierung und Privileged Access Management gehören zum Service, unter einem Vertrag mit Eurokommerz. Veeam-Backup-Software liefern wir und implementieren sie gemeinsam mit Vixen.UNO, wie unsere Software-Seite beschreibt.
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?
Verlangt NIS2 unveränderliche Backups?
Unser Engineering-Partner Vixen.UNO prüft Ihre Backups in einem technischen Assessment, und wir liefern und implementieren Veeam-Backup-Software. Beschreiben Sie Ihre Aufgabe in wenigen Sätzen, unser Team hilft Ihnen weiter: Wir antworten innerhalb eines Werktages. Das erste Gespräch ist kostenlos.
Mit einem Experten sprechenWir antworten innerhalb eines Werktages