Der Löschversuch, der scheitern muss

20. Oktober 2026

TL;DR

1. Immutability prüft man nicht in den Einstellungen, sondern mit einem Löschversuch. Rechtsklick auf die Kopie im Cloud Repository, „Delete from disk“.
2. Das richtige Ergebnis ist eine Warnung: „Unable to delete 1 immutable backup file“. Die Kopie bleibt liegen.
3. Die Sperre schützt vor dem Löschen, nicht vor der Zeit. Was nach Ablauf der Aufbewahrung weg ist, ist weg.

„Ist die Kopie bei euch wirklich unveränderbar?“ Die Frage hören wir von Partnern regelmäßig. Unsere Antwort ist inzwischen immer dieselbe: Probier es aus. Lösch sie.

Das klingt nach einem schlechten Rat und ist der beste, den wir haben. Eine Sperrfrist, die im Dialog auf 14 Tagen steht, ist eine Behauptung. Ob sie hält, zeigt sich erst, wenn jemand mit Admin-Rechten versucht, die Sicherung loszuwerden. Im Ernstfall ist das ein Angreifer. Vorher sollte man selbst das gewesen sein.

Der Test

In der Konsole von Veeam Backup & Replication:

1. Backups → Cloud öffnen, die Sicherung auf dem Cloud Repository auswählen.
2. Rechtsklick → Delete from disk.
3. Bestätigen und den Löschauftrag beobachten.

Der Auftrag endet nicht grün und nicht rot, sondern gelb:

Unable to delete 1 immutable backup file
Backup files can be deleted after …

Dahinter steht das Datum, ab dem die Datei gelöscht werden darf. Genau das soll passieren. Auch wer die Konsole voll in der Hand hat, kommt vor Ablauf der Frist nicht an die Kopie.

Was am Test irritiert

Die Bruchstelle liegt nicht in der Technik, sondern im Lesen. Eine Warnung wirkt wie ein Problem, das jemand lösen sollte. Wir hatten Rückfragen, ob man „das noch wegbekommt“. Nein, und das ist der Sinn.

Umgekehrt ist ein grüner Löschauftrag auf einer Kopie, die gesperrt sein sollte, ein Alarmzeichen. Dann ist die Sperre nicht dort, wo man sie vermutet. Bei Objektspeicher etwa hängt sie am einzelnen Ziel und nicht an einer zentralen Stelle. Wie leicht sie dort fehlt, steht in Wenn die Sperre länger hält als die Aufbewahrung .

Was die Sperre nicht kann

Immutability ist kein Archiv. Sie verhindert, dass eine Datei vor Ablauf der Frist gelöscht oder verändert wird. Sie sorgt nicht dafür, dass eine Datei länger da ist, als die Aufbewahrung im Job es vorsieht. Wer 14 Tage vorhält, findet nach 20 Tagen nichts mehr, auch wenn die Sperre aktiv war.

Daraus folgen bei uns zwei Einstellungen:

• Aufbewahrung mindestens so lang wie die Sperre. Auf unserer gemeinsamen Infrastruktur sind das 14 Tage plus ein wöchentliches Synthetic Full. Ist die Aufbewahrung kürzer, will Veeam löschen, darf nicht, und die Kette wächst still weiter.
• Synthetic statt Active Full. Ein Active Full schiebt die ganze Maschine erneut durch die Leitung. Ein Synthetic Full baut die Vollsicherung aus dem zusammen, was schon im Ziel liegt.

Seit Version 13 wird die Aufbewahrung nur noch in Tagen angegeben. Wer dabei „Remove deleted items data after“ nicht setzt, schleppt die Sicherungen gelöschter VMs ohne Ende mit.

Warum jetzt auf 13.1?

Im Cloud Repository legt der Provider die Frist fest, die Konsole des Kunden kommt an sie nicht heran. Wer dagegen selbst ein Hardened Repository betreibt, hat die Frist in der eigenen Konsole. Dort zeigt der Löschtest nur, dass die gesperrten Dateien bleiben. Er zeigt nicht, ob ein gekapertes Admin-Konto die Sperre für alles Künftige herunterdrehen könnte. Genau da setzt Veeam Backup & Replication 13.1 an. Die Sperre selbst ist dabei nicht neu.

• Vier Augen für die Frist. Ist die Vier-Augen-Freigabe aktiv, braucht das Verkürzen oder Abschalten der Immutability auf einem Hardened Repository die Zustimmung eines zweiten berechtigten Benutzers.
• MFA für Rechteänderungen. Wer Benutzer und Rollen ändern will, muss das bei eingeschalteter MFA eigens bestätigen.
• Gesperrte Konfigurationssicherung. Auch die Konfiguration des Backup-Servers lässt sich jetzt unveränderbar auf ein Hardened Repository legen.

Warum also jetzt? Weil der Löschtest mit 13.1 auch im eigenen Haus nicht mehr die halbe Wahrheit ist. Die Kopie hält, und die Regeln, nach denen sie hält, lassen sich nicht mehr mit einem einzigen Konto ändern. Vorausgesetzt, man schaltet beides ein.