Immutable Backup ist inzwischen fast zu einem Sicherheitsversprechen geworden: Ist das Backup unveränderbar, kann Ransomware es nicht mehr löschen. Das stimmt – aber nur für einen Teil des Problems. Immutability schützt Sicherungen vor Manipulation und Löschung. Sie verhindert aber weder schlechte Backups noch falsche Retention, kompromittierte Quellsysteme oder einen Restore, der im Ernstfall nicht funktioniert.
In diesem Beitrag
Was bedeutet „immutable“ bei einem Backup?
Im Kern ist die Idee einfach: Ein einmal geschriebenes Backup soll für einen definierten Zeitraum nicht verändert oder gelöscht werden können.
Bei einem Veeam Hardened Repository bedeutet das beispielsweise, dass Backup-Dateien während des festgelegten Immutability-Zeitraums nicht verschoben, verändert oder gelöscht werden können. Veeam trennt dafür die eigentliche Backup-Infrastruktur bewusst von den Berechtigungen, die das Repository schützen.[1]
Bei Object Storage wird ein ähnliches Prinzip über WORM-Mechanismen umgesetzt – „Write Once, Read Many“. Amazon S3 Object Lock schützt einzelne Objektversionen für einen definierten Zeitraum oder über einen Legal Hold vor Überschreiben und Löschen.[2]
Das Entscheidende ist also nicht, dass eine Datei einfach nur „schreibgeschützt“ ist. Die Schutzfunktion muss auch dann bestehen bleiben, wenn ein Angreifer Zugriff auf Teile der Backup-Umgebung erhält.
Was Immutability tatsächlich schützt
Der große Nutzen zeigt sich bei Angriffen, bei denen nicht nur Produktionsdaten verschlüsselt werden, sondern gezielt auch die Sicherungen angegriffen werden.
Genau das ist inzwischen ein realistisches Angriffsszenario. CISA weist in seinen Ransomware-Empfehlungen ausdrücklich darauf hin, dass Angreifer versuchen, erreichbare Backups zu löschen oder zu verschlüsseln. Deshalb empfiehlt die Behörde unter anderem offline beziehungsweise isolierte, verschlüsselte und regelmäßig getestete Sicherungen.[3]
Ein korrekt umgesetztes immutable Backup kann insbesondere gegen folgende Situationen helfen:
- Ransomware versucht, Backup-Dateien zu löschen oder zu verändern.
- Ein kompromittierter Backup-Administrator löscht Wiederherstellungspunkte.
- Zugangsdaten des Backup-Servers geraten in falsche Hände.
- Eine Fehlbedienung oder Automatisierung würde Sicherungen vorzeitig entfernen.
- Ein Angreifer versucht, nach der Kompromittierung der Produktion auch die Recovery-Basis zu zerstören.
Für mich ist Immutability deshalb vor allem eines: eine zusätzliche Sicherheitsgrenze zwischen einem kompromittierten Produktionssystem und der letzten brauchbaren Kopie.
Was Immutability nicht schützt
Problematisch wird es, wenn „immutable“ mit „sicher wiederherstellbar“ gleichgesetzt wird. Das ist nicht dasselbe.
Ein unveränderbares schlechtes Backup bleibt ein schlechtes Backup.
Wenn bereits verschlüsselte, beschädigte oder fachlich falsche Daten gesichert werden, schützt Immutability genau diesen Zustand zuverlässig vor Veränderung. Das kann sinnvoll sein – macht ihn aber nicht automatisch brauchbar.
Deshalb braucht eine Backup-Strategie mehrere zeitlich getrennte Wiederherstellungspunkte. Wenn ein Angriff erst Tage später erkannt wird, muss ein sauberer Zustand von davor verfügbar sein.
Immutability erkennt keinen fehlgeschlagenen Restore.
Ein Backup kann technisch erfolgreich abgeschlossen sein und trotzdem im Ernstfall nicht das liefern, was benötigt wird. Vielleicht fehlt eine abhängige Datenbank, ein benötigtes Kennwort, ein Applikationsbestandteil oder schlicht die Dokumentation des Restore-Prozesses.
NIST betont deshalb nicht nur die Erstellung, sondern ausdrücklich auch die Pflege und das Testen von Backups. In der 2026 veröffentlichten OT Backup Quick Start Guide nennt NIST regelmäßige Backups, Tests und Recovery-Übungen als Bestandteil eines wirksamen Backup-Managements.[4]
Immutability ersetzt keine Trennung von Sicherheitsdomänen.
Wenn Backup-Server, Repository, Hypervisor, Active Directory und Administrationszugänge alle über dieselbe Identität und dieselben Vertrauensbeziehungen erreichbar sind, bleibt die Architektur unnötig angreifbar.
Ein immutable Repository reduziert dieses Risiko erheblich. Trotzdem sollte das Ziel weiterhin sein, Credentials, Rollen, Management-Zugänge und Backup-Ziele so weit wie sinnvoll voneinander zu trennen.
Immutability und Retention sind nicht dasselbe
Das ist in Projekten ein Punkt, der schnell durcheinandergerät.
Retention beantwortet die Frage: Wie lange soll ein Wiederherstellungspunkt grundsätzlich aufbewahrt werden?
Immutability beantwortet dagegen: Wie lange darf dieser Wiederherstellungspunkt nicht verändert oder gelöscht werden?
Beides muss zusammenpassen. Ein Beispiel: Wenn ein Unternehmen 30 Tage Wiederherstellungshistorie benötigt, aber nur sieben Tage Immutability konfiguriert sind, existieren danach weiterhin Restore Points – sie sind aber nicht mehr durch die gleiche Unveränderbarkeit geschützt.
Umgekehrt kann eine sehr lange Immutability zu einem Problem werden, wenn Speicher falsch dimensioniert wurde oder fehlerhafte Daten unnötig lange gebunden bleiben. Bei Object Lock gilt das besonders deutlich: In einem echten WORM-Modell ist „ich lösche das später einfach wieder“ gerade nicht der vorgesehene Betriebsweg.
Die Retention muss deshalb aus RPO, RTO, Bedrohungsszenario, Speicherbedarf und gegebenenfalls regulatorischen Anforderungen abgeleitet werden – nicht aus einem möglichst hohen Zahlenwert.
Hardened Repository und Object Storage lösen das Problem unterschiedlich
In modernen Backup-Architekturen begegnen mir vor allem zwei Varianten.
Linux Hardened Repository
Ein Hardened Repository stellt lokalen oder direkt angebundenen Speicher bereit und schützt die Backup-Dateien auf Betriebssystemebene. Veeam verwendet dafür unter anderem Single-Use Credentials beziehungsweise zertifikatsbasierte Authentisierung und setzt die Immutability direkt auf den Backup-Dateien um.[1]
Der Vorteil ist die Kombination aus hoher lokaler Restore-Performance und einer deutlich gehärteten Repository-Schicht. Entscheidend ist allerdings, dass der Linux-Host selbst nicht wie ein normaler Allzweckserver administriert wird.
Object Storage mit Object Lock
Bei S3-kompatiblem Object Storage wird die Unveränderbarkeit auf Objektebene umgesetzt. Amazon unterscheidet bei S3 Object Lock beispielsweise zwischen Governance und Compliance Mode. Im Compliance Mode kann eine geschützte Objektversion während der Retention selbst durch den Root-Benutzer des Accounts nicht gelöscht werden.[2]
Das ist besonders interessant für eine zusätzliche Kopie außerhalb der lokalen Infrastruktur. Gleichzeitig müssen Kostenmodell, Retention, Object Lock, Zugangsschutz und mögliche Provider-Abhängigkeiten von Anfang an verstanden werden.
Ich sehe die beiden Varianten deshalb nicht zwingend als Konkurrenz. In einer belastbaren Architektur können sie unterschiedliche Rollen übernehmen: schnelles lokales Recovery auf der einen Seite und eine getrennte, immutable Kopie auf der anderen.
Die Architektur um das immutable Backup herum entscheidet mit
Ein einzelner Haken „Immutability aktivieren“ macht noch keine Cyber-Resilience-Strategie.
Ich würde bei der Planung mindestens folgende Fragen stellen:
- Existieren mehrere unabhängige Backup-Kopien?
- Liegt mindestens eine Kopie in einer getrennten Sicherheits- oder Fehlerdomäne?
- Sind Backup-Administratoren und Produktionsadministratoren sinnvoll getrennt?
- Sind Repository-Zugangsdaten vor dem Backup-Server geschützt?
- Wie lange ist die Immutability im Verhältnis zur Erkennungszeit eines Angriffs?
- Gibt es ausreichend historische Restore Points?
- Wie wird der Zugriff auf Object Storage und Cloud-Accounts abgesichert?
- Wer überwacht, ob die Immutable-Einstellungen tatsächlich aktiv bleiben?
Das knüpft direkt an meinen Beitrag „Warum ein Backup noch lange keine Backup-Strategie ist“ an. Ein Backup-Job ist ein technischer Baustein. Eine Backup-Strategie beschreibt dagegen, wie Daten geschützt, getrennt, aufbewahrt und im Ernstfall wiederhergestellt werden.
Immutability ist darin ein sehr starker Baustein – aber eben nur ein Baustein.
Der Restore bleibt der entscheidende Test
Am Ende interessiert im Incident nicht, wie viele Backup-Jobs grün waren. Entscheidend ist, ob die benötigten Systeme und Daten in der erwarteten Zeit wiederhergestellt werden können.
Deshalb gehören für mich Restore-Tests unmittelbar zu einer Immutable-Backup-Strategie. Sie prüfen Dinge, die Immutability allein nicht beantworten kann:
- Ist der Wiederherstellungspunkt wirklich konsistent?
- Ist die Anwendung nach dem Restore funktionsfähig?
- Sind benötigte Zugangsdaten und Schlüssel verfügbar?
- Ist der Ablauf dokumentiert?
- Kann das Team die Wiederherstellung auch unter Zeitdruck durchführen?
- Entspricht die tatsächliche Wiederherstellungszeit dem erwarteten RTO?
CISA empfiehlt deshalb nicht nur offline und immutable Backups, sondern ausdrücklich regelmäßige Tests der Verfügbarkeit und Integrität in einem Disaster-Recovery-Szenario.[3]
Das ist für mich die wichtigste Einordnung: Immutability schützt die Sicherung. Der Restore-Test beweist ihren Wert.
Meine Einschätzung
Immutable Backups gehören für mich heute in jede ernsthafte Backup- und Ransomware-Strategie. Sie schließen eine gefährliche Lücke: den Angriff auf die Sicherung selbst.
Problematisch wird es nur, wenn daraus ein falsches Sicherheitsgefühl entsteht. Immutability ersetzt weder mehrere Kopien noch saubere Rechtekonzepte, sinnvolle Retention, Monitoring oder Restore-Tests.
Eine gute Architektur stellt deshalb nicht die Frage „Haben wir immutable Backups?“, sondern: Welche Angriffsszenarien übersteht unsere Recovery-Kette – und haben wir das tatsächlich getestet?
Quellen und Einordnung
Stand der Recherche: 12. Oktober 2026. Der Beitrag verbindet meine eigene Projekt- und Betriebsperspektive mit Herstellerdokumentation und Empfehlungen öffentlicher Cybersecurity-Stellen.