Der Backup-Server sichert sich nicht selbst
Die Frage kommt bei fast jedem Onboarding, meist ganz am Ende: „Und wie sichere ich den Veeam-Server selbst?"
Die Antwort, die sich anbietet, ist naheliegend. Der Backup-Server ist eine VM. Man nimmt ihn in einen Job auf, fertig. Wir haben das in Umgebungen gesehen, die sonst sauber gebaut waren — und lange selbst nur aus Erfahrung dagegen argumentiert.
Was Veeam dazu sagt
Der Hersteller beantwortet die Frage in KB2645 „Protecting the Veeam Backup & Replication server" mit einem einzigen Satz:
The only supported way to protect the configuration of Veeam Backup & Replication is to use the native Configuration Backup tool.
Nicht unterstützt sind ausdrücklich: ein Backup- oder Replikationsjob auf die eigene VM, ein Veeam Agent auf dem Server, Werkzeuge von Dritten und native Datenbank-Backups der Konfigurationsdatenbank.
Die Begründung für den VM-Job steht gleich dabei. Das Erstellen und Entfernen des Snapshots kann die VM einfrieren — mit Verbindungsabbrüchen zur Konfigurationsdatenbank, zu den Backup-Komponenten und zum Speicher. Der Job, der den Backup-Server sichern soll, stört den Backup-Server beim Sichern. Und wer in genau so einem Moment ein Image zieht, hat ein Image von einem Server, der gerade seine eigene Datenbank verloren hat.
Der Backup-Server sichert sich nicht selbst. Das ist keine Erfahrung mehr, das ist Herstellerposition.
Was das Configuration Backup ist
Es sichert die Konfigurationsdatenbank des Backup-Servers: welche Jobs es gibt, welche Objekte darin liegen, Zeitpläne, Aufbewahrung, die eingebundenen Repositories, die hinterlegten Anmeldedaten — und die Metadaten der Verschlüsselung.
Der Wiederherstellungsweg laut KB ist entsprechend kurz: neue Maschine, Veeam installieren, Configuration Restore. Danach kennt der neue Server jedes Repository und jeden Wiederherstellungspunkt, als wäre nichts gewesen.
Ohne die Datei liegen die Backup-Dateien zwar noch auf ihren Medien, aber der neue Server kennt keine davon. Man kann sie importieren und daraus wiederherstellen — und baut nebenbei die gesamte Konfiguration von Hand nach, unter Zeitdruck, ohne zu wissen, was vorher eingestellt war. Mit der Datei ist der Wiederaufbau eine Sache von Stunden. Ohne sie von Tagen.
Der Standard ist an, und der Standard ist falsch
Das Configuration Backup ist ab Werk aktiviert und läuft täglich um 10 Uhr. Das klingt beruhigend. Nur schreibt es im Standard auf den Backup-Server selbst — und genau das verbietet der KB im nächsten Absatz: nicht auf C:\ des Backup-Servers, weil dann mit dem Server auch die Sicherung des Servers untergeht.
Und die Verschlüsselung ist im Standard aus. Damit fehlen in der Datei die hinterlegten Anmeldedaten — nach dem Restore steht man vor jedem Repository und jedem Host mit leerem Passwortfeld.
Wer den Dialog nie geöffnet hat, hat also ein Configuration Backup, das im einzigen Fall, für den es gedacht ist, nicht mehr da ist. Und wenn doch, fehlt das Wichtigste darin.
„Dann ins Cloud-Repository"
Der nächste Reflex. Das Cloud-Repository lässt sich im Dialog auswählen — und „Backup now" bricht ab mit Selected repository is not supported for a configuration backup. Cloud- und Scale-Out-Repositories scheiden aus. Das Configuration Backup will ein einfaches Repository.
Was bleibt, ist unspektakulär: ein kleines Repository außerhalb des Backup-Servers, das dauerhaft erreichbar ist. Eine Freigabe auf einer anderen Maschine, ein zweiter Server, ein Repository beim Partner. Die Datei ist klein. Sie braucht kein Volumen, sie braucht einen Ort, der nicht mit dem Server untergeht. Wer eine zweite Kopie will, zieht sie mit einem File Copy Job — auch das steht im KB.
Für unsere Kunden ist das ein eigenes Hardened Repository auf einem Managed Storage Server, nur für Configuration Backups, mit Immutability. Das ist Eigenwerbung, und sie ist genau die Ablage, die der KB verlangt: extern, dauerhaft erreichbar, unveränderbar.
Drei Einstellungen, die dazugehören
Verschlüsselung an. Erst damit kommen beim Restore alle Anmeldedaten mit — siehe oben.
Passwort woanders. Es gehört in einen Passwortmanager, dessen Wiederherstellung nicht selbst von diesem Backup abhängt. Die Zirkularität — das Passwort liegt nur in der Umgebung, die man damit wiederherstellen will — ist ein eigener, häufiger Fehler.
Mehr als ein Wiederherstellungspunkt. Sonst ist eine beschädigte oder mit falschem Stand überschriebene Datei die einzige.
Was das beim Onboarding heißt
Wer den Backup-Server per VM-Job „mitsichert", hat im Ernstfall nicht nur ein Backup, das den Server beim Sichern stört. Er hat ein Backup, für das der Hersteller im Supportfall keine Verantwortung übernimmt. Das ist der Unterschied zwischen „hat bei uns immer funktioniert" und „ist supportet" — und er zeigt sich erst, wenn man den Support braucht.
Die Frage „und wie sichere ich den Veeam-Server?" hat seit dem KB eine kurze Antwort: gar nicht. Man sichert seine Konfiguration, und zwar woanders.