Die leere Platte im Tresor
Die Regel im Haus lautete: Platte vor 19 Uhr tauschen. Ein geplanter Task formatierte das Medium um 20 Uhr, damit der Sicherungslauf danach Platz hatte. Wer pünktlich war, nahm die Platte vom Vortag mit in den Tresor. Wer nach 20 Uhr kam, nahm eine frisch formatierte mit — und steckte eine ein, auf der noch die Daten der Vorwoche lagen.
Es gab keine Meldung dafür. Es gibt keine Meldung für „Platte enthält nichts". Der Job lief in der Nacht trotzdem grün durch, auf die Platte, die zu spät kam, und am nächsten Morgen sah alles aus wie immer. Bis auf die Tage, an denen der Platz nicht reichte, weil die Altdaten noch drauf waren.
Das war der Befund einer Ist-Analyse in einer mittelständischen Hyper-V-Umgebung. Mehrere Dutzend VMs, ein Backup-Volumen im hohen zweistelligen Terabyte-Bereich, je Host ein Job und ein eigener Plattensatz — und als primäres Repository: Wechselfestplatten, von Hand getauscht.
Warum der Aufbau nicht dumm ist
Das muss vorweg, sonst argumentiert man am Kunden vorbei. Drei Argumente sprechen für Wechselplatten, und alle drei stimmen:
Eine Platte im Tresor ist offline. Keine Ransomware der Welt kommt an sie heran. Das wirkt wie Immutability, ohne dafür zu bezahlen. Die Hardware ist vorhanden und kostet nichts im Betrieb. Und es gibt einen physischen Nachweis — man kann die Kopie in die Hand nehmen und einem Auditor zeigen.
Alle drei Punkte gelten. Sie gelten aber nur für eine zusätzliche Kopie, nicht für das primäre Ziel.
Der Laufwerksbuchstabe ist die Identität
Windows merkt sich den Laufwerksbuchstaben je Volume — aber nur, solange der Buchstabe frei ist und niemand die Platte neu formatiert. Beides ist hier nicht gegeben. Mit zwei Plattensätzen für zwei Repositories und wechselnder Reihenfolge beim Einstecken bekommt die Platte des einen Satzes irgendwann den Buchstaben des anderen. Veeam schreibt daraufhin den falschen Datensatz auf das falsche Medium.
Der Job läuft grün durch. Der Fehler fällt beim Restore auf.
Der Schalter verdeckt genau den Fehlfall, für den er gedacht ist
In den Einstellungen des Repositories gibt es den Schalter „This repository is backed by rotated drives". Ist die Kette auf der eingelegten Platte vorhanden, setzt Veeam sie fort; fehlt sie, legt es ohne Fehler ein neues Vollbackup an.
Das ist die Absicht, und für rotierende Medien ist es der Normalfall. Genau deshalb gibt es keine Warnung, die den Fehlfall vom Normalfall unterscheidet: Ein falsch eingelegtes, ein leeres oder ein vertauschtes Medium sieht für Veeam aus wie ein regulärer Wechsel. Die unvollständige Kette auf der anderen Platte bleibt unvollständig, und niemand erfährt es.
Es gibt keinen Medienkatalog
Veeam kennt die Wiederherstellungspunkte, aber nicht, auf welcher Platte sie liegen. Bei Band führt es einen Medienkatalog und sagt beim Restore, welches Band man braucht. Bei rotierenden Platten nicht.
Wer einen älteren Stand sucht, steckt Platte für Platte an, liest sie ein und weiß vorher nicht, ob er den Stand überhaupt findet. Bei einer Rotation über Wochen ist das im Ernstfall keine Suche, sondern ein Ratespiel unter Zeitdruck.
Retention zählt Punkte, nicht Tage
„Drei Wochen Aufbewahrung" heißt bei Wechselplatten: ein bis wenige Wiederherstellungspunkte pro Medium, und die Punkte liegen verteilt auf drei Wochen Medien. Das ist etwas völlig anderes, sobald man einen bestimmten Zeitpunkt braucht.
Und inkrementelle Ketten brechen mit dem Medium. Fehlt ein Glied, ist ab dieser Stelle nur noch das letzte Vollbackup brauchbar. Bei täglichem Wechsel genügt ein einziger vergessener oder falscher Tausch, um die Verwertbarkeit mehrerer Tage zu beenden. Der typische Morgen danach: rote Meldungen wegen Platzmangel, alle Jobs von Hand nachgestartet, alle als Full — und die Leitung ist tagsüber blockiert.
Der Mensch steht im Datenpfad
Jeder Tausch ist eine manuelle Handlung mit Zeitfenster. In der beobachteten Umgebung wurden Platten vertauscht, zu spät getauscht und gar nicht getauscht. Mehrfach, in wenigen Monaten.
Das ist keine Frage von Sorgfalt. Eine tägliche Handarbeit über Jahre hat eine Fehlerrate, und die Architektur darf sie nicht in die Datenhaltung durchlassen. Der Satz taugt auch im Kundengespräch, weil er niemanden beschuldigt.
Dazu kommt, was wegfällt: Instant Recovery, das Starten einer VM direkt aus dem Backup, das Zurückholen einer einzelnen Datei in Minuten. All das existiert nur an dem einen Tag, an dem zufällig das passende Medium steckt.
Der Formatier-Task
Zurück zum Task um 20 Uhr. Die Logik dahinter ist nachvollziehbar: Das Medium ist voll, Veeam würde mit Platzmangel abbrechen, also macht man vorher Platz.
Erstens entsteht so das Fenster zwischen Formatierung und Entnahme, aus dem die leere Platte im Tresor kommt. Zweitens zerstört die Formatierung jede Chance auf eine Kette und erzwingt täglich ein Vollbackup. Sie erzeugt damit erst die Laufzeiten und die Netzlast, die dann als eigenes Problem erscheinen.
Ein Werkzeug, das Backup-Daten löscht und dem Backup-Programm nicht bekannt ist, ist ein zweiter Schreiber auf demselben Datenbestand.
Platz schafft man mit Aufbewahrungsregeln, mit „Remove deleted items data after" und mit einem ausreichend dimensionierten Ziel — und mit per-machine Backup Files, damit die Aufbewahrung je Maschine greift. Nie über das Dateisystem, nie über einen Task, der neben Veeam läuft und von dem Veeam nichts weiß.
Ob man den Task einfach abschalten darf, ist übrigens eine eigene Geschichte. Die Antwort war nein, und der Kunde hat es vor uns gemerkt — das wird ein eigener Beitrag.
Das Configuration Backup lag auf derselben Platte
Die stillste Fehlstelle fand sich im Dialog „Configuration Backup Settings". Aktiviert, letzter Lauf erfolgreich, Ziel: dasselbe rotierende Repository. Zeitplan: 18:25 Uhr, dienstags und freitags.
Auf einer Zeitachse neben den Regeln des Hauses:
- 18:25 Uhr — Configuration Backup schreibt auf die eingelegte Platte
- vor 19:00 Uhr — die Platte wird gezogen und geht in den Tresor
- 20:00 Uhr — der Formatier-Task löscht, was noch steckt
Wer die Platte um 18:20 Uhr zog, nahm den Stand vom Vortag mit — oder gar keinen. Wer nach 20 Uhr kam, nahm eine leere. Auf den Platten der übrigen Wochentage lag ohnehin nichts. Die Chance, auf einem entnommenen Medium ein brauchbares Configuration Backup zu finden, lag unter fünfzig Prozent, und niemand hätte sagen können, auf welchem.
Das ist die eine Datei, mit der ein neuer Backup-Server in Stunden statt Tagen steht. Warum sie nirgends sonst hinkann als in ein eigenes, dauerhaft erreichbares Repository , ist ein eigener Beitrag.
Wo der Aufbau vertretbar bleibt
Als zusätzliche Kopie behält er seinen Wert. Eine wöchentliche Vollkopie auf ein Wechselmedium, das in den Tresor geht, ist eine echte Offline-Kopie und erfüllt in einem 3-2-1-1-0-Design die Rolle der externen, unveränderbaren Kopie — mit vorhandener Hardware.
Voraussetzung ist ein permanent verfügbares Repository daneben, aus dem der Alltagsrestore kommt. Das Medium ist dann Versicherung, nicht Betriebsmittel. Ein vergessener Tausch kostet eine Kopie — nicht die Wiederherstellbarkeit.
Woran man den Aufbau in einer fremden Umgebung erkennt
Fünf Zeichen, die gemeinsam auftreten, weil sie dieselbe Ursache haben:
- Der Schalter für rotierende Medien in den Advanced-Einstellungen des Repositories.
diskpart- oder Format-Tasks im Aufgabenplaner des Backup-Servers.- Eine Aufbewahrung von einem einzigen Wiederherstellungspunkt.
- Jobs, die nach Hypervisor-Host benannt sind — weil je Host ein Plattensatz existiert.
- Ein Ansprechpartner, der erzählt, dass er morgens rote Meldungen sieht und Jobs von Hand nachstartet.
Wer eines findet, sollte gezielt nach den übrigen vier suchen, statt sie als Einzelbefunde zu behandeln.