Wenn die Sperre länger hält als die Aufbewahrung
Unveränderliche Sicherungen — im Produkt Immutability, beim Objektspeicher Object Lock — sind das stärkste Argument, das wir gegen Ransomware kennen. Was einmal geschrieben und für eine Frist gesperrt ist, kann auch ein Angreifer mit Administratorrechten nicht löschen. Deshalb ist die Einstellung so verbreitet. Und deshalb lohnt der Blick auf den Fehler, den wir in Healthchecks am häufigsten dazu sehen — er sieht nämlich nicht wie einer aus.
Der Fehler ist banal: Die Sperre steht länger als die Aufbewahrung.
Was passiert, wenn die Sperre länger steht als die Aufbewahrung
Angenommen, das Sicherungsziel hält jede Datei 14 Tage lang unveränderlich. Im Backup-Job steht eine Aufbewahrung von 7 Tagen. Beides für sich genommen ist eine vernünftige Einstellung. Zusammen ergeben sie einen Widerspruch, der jeden Tag aufs Neue ausgetragen wird.
Nach sieben Tagen will Veeam aufräumen. Der Job hat die Anweisung, alles Ältere zu entsorgen, und macht sich daran. Das Ziel verweigert die Löschung, weil die Frist noch läuft. Es folgt kein Dialog, keine rote Kachel, kein Ticket. Der Versuch scheitert, wird nicht sauber wiederholt und verschwindet.
Am nächsten Tag dasselbe. Und am übernächsten.
Was sich dabei aufbaut, ist kein Fehlerzustand, sondern schlicht Belegung. Die Ketten, die eigentlich hätten wegfallen sollen, bleiben liegen, während oben neue nachwachsen. Aus zwei aufeinander abgestimmten Zahlen ist ein Speicherfresser geworden, der niemandem meldet, dass er einer ist. Das Ende ist ein volles Sicherungsziel — und ein volles Sicherungsziel heißt: keine neuen Sicherungen mehr, für alle Kunden auf diesem Speicher.
Ein Kollege hat das einmal so beschrieben, dass es hängenbleibt: Veeam sagt sinngemäß „ich habe es versucht, ich konnte es nicht, ich habe es vergessen" — und versucht es beim nächsten Lauf wieder, mit demselben Ergebnis.
Die Regel dazu, in eine Richtung
Man kann diesen Widerspruch von beiden Seiten auflösen, und trotzdem ist nur eine Richtung richtig:
Die Aufbewahrung im Job muss zur Sperrfrist passen — nicht andersherum.
Der Grund ist keine Geschmacksfrage. Die Sperrfrist ist die Zusage, die man gegen einen Angreifer hält; sie zu verkürzen, damit der Job wieder aufräumen darf, gibt genau das auf, wofür man sie eingerichtet hat. Die Aufbewahrung im Job dagegen ist eine Betriebsgröße. Sie zu verlängern kostet Speicher, aber nichts an Sicherheit.
Wer also 14 Tage Unveränderlichkeit fährt, konfiguriert im Job mindestens 14 Tage Aufbewahrung. Nicht weniger. Nie weniger.
Die Detailfallen daneben
Der Mismatch ist der große Brocken. Im selben Themenkreis liegen drei kleinere Fallen, die in der Praxis genauso zuverlässig zubeißen.
Nicht jede Datei darf gesperrt sein. Die Backupdatei .vbk mit den eigentlichen Daten soll unveränderlich sein, das ist der ganze Sinn. Die Kettenmetadatei .vbm daneben darf es nicht, weil laufende Jobs hineinschreiben müssen. Ist sie versehentlich mit gesperrt, blockiert das den Jobbetrieb, und zwar mit einem Fehlerbild, das nach Speicherproblem aussieht und keines ist. Der Ausweg: die .vbm entfernen und das Repository neu einlesen — Veeam legt sie automatisch neu an. Wer auf dem Dateisystem von Hand nachgeholfen hat, muss danach zusätzlich die nicht mehr auffindbaren Sicherungen aus der Datenbank werfen lassen, sonst laufen Bestand und Verzeichnis auseinander.
Ein Wort der Vorsicht, weil so etwas nachts um zwei gelesen wird: vorher eine Kopie der .vbm wegsichern, und im Zweifel den Herstellersupport fragen statt zu raten. Das Verhalten hängt an der Produktversion, und dieser Text ist keine Dokumentation.
Bei Objektspeicher gilt es pro Ziel, nicht zentral. Auf einem Hardened Repository ist die Unveränderlichkeit eine Eigenschaft des Speichers. Bei S3-kompatiblen Zielen wird der Object Lock stattdessen im Job je Bucket gesetzt — was bedeutet, dass sie beim Anlegen jedes neuen Ziels erneut gesetzt werden muss. Bei einer Stichprobe über die Jobs eines Kunden war etwa die Hälfte schlicht nicht konfiguriert — eine Handvoll geprüfter Jobs, also keine Statistik, aber ein Muster, das wir seitdem gezielt abfragen. Nicht falsch eingestellt. Gar nicht eingestellt. Niemand hatte etwas übersehen; die Einstellung war einfach an einer Stelle, an der man beim zehnten Job nicht mehr hinsieht.
Und ein Fall, der wie ein Fehler aussieht und keiner ist: Manchmal wirkt die Aufbewahrung länger als konfiguriert — statt 14 Tagen liegen 20 oder 30 im Ziel. Das ist meist kein Defekt, sondern die Kettenlogik: Die alte Kette kann erst wegfallen, wenn die nächste Vollsicherung vollständig durch ist. Wie viel Platz so eine Kette wirklich belegt, haben wir vor Jahren schon einmal nachgerechnet. Wer hier „repariert", repariert etwas Funktionierendes.
Warum keiner dieser Fehler eine Meldung erzeugt
Die drei Fehlerbilder haben eine Eigenschaft gemeinsam, und die ist der Grund für diesen Beitrag: Keines davon meldet sich. Der Löschversuch scheitert leise, die nicht gesetzte Sperre fehlt leise, die gesperrte Metadatei erzeugt ein Symptom an der falschen Stelle. Alles sieht grün aus, bis der Speicher voll ist oder bis jemand das erste Mal wirklich auf die Unveränderlichkeit angewiesen wäre.
Dasselbe Muster in anderer Form — ein Job, der nichts meldet, weil er gar nicht mehr läuft — steht im Beitrag über den stillen Backup-Ausfall.
Die Prüfung dauert in beiden Fällen Minuten und findet nur statt, wenn jemand sie sich vornimmt: Sperrfrist am Ziel ablesen, Aufbewahrung im Job daneben legen, vergleichen. Wenn die zweite Zahl kleiner ist als die erste, hat man das Problem — auch dann, wenn heute noch alles läuft.