System erstickt an Backupdaten – Warum man das Veeam Default-Repository nach der Installation entfernen sollte
Eine typische Veeam Backup & Replication Installation besteht aus verschiedenen Komponenten. Es gibt den Backupserver mit der Backup-Datenbank, es gibt Backup-Proxies, Mount-Server, Gateway-Server und Backup-Repositories. Repositories sind Datenspeicher, auf denen Backupdaten abgelegt werden. Bei der Installation erzeugt der Installer ein Default Repository auf der Systempartition. Normalerweise ist diese nicht sehr groß – vielleicht 100 GB oder weniger. Eine der ersten Aufgaben nach dem Setup ist die Einrichtung eines neuen Repositorys mit mehreren TB Speicherplatz. Man vergisst dabei leicht das Standard-Repository, welches immer noch auf die Systempartition zeigt. Unter bestimmten Umständen kann sich dies als Zeitbombe entpuppen, wie ich neulich in einer Umgebungs sehen konnte.
Was war passiert?
Ich beziehe mich hier auf eine recht simple Veeam Backup-Infrastruktur. Ein virtueller Veeam Server mit einem physischen Proxy, der zwei iSCSI-Targets als Repositorys hat. Das erste Repository als Primärspeicher, das zweite für Backup-Copy. Nichts besonderes.
Eines Tages reagierte der Proxy nicht mehr und musste neu gestartet werden. Nach dem Reboot wurde das zweite Repo mit den Backup-Copies nicht gemounted. Wir konnten es neu verbinden und starteten einige Retry-Jobs zuvor gescheiterter Backups. Alles sah normal aus.
Als alle Backup Wiederholungen beendet waren, begann der Backup-Copy-Job seine Arbeit und brach nach der Übertragung von 2 oder 3 VMs ab. Ich bemerkte, dass die Systempartition des Veeam Servers zu 100% belegt war mit 0 Bytes freiem Speicherplatz. Sch#####!
Zum Glück war der Veeam Server eine VM und man konnte leicht die Systemdisk vergrößern. Bei der Untersuchung der Systempartition bemerkte ich, dass diese erneut geflutet wurde. Wie es sich herausstellte mit Backupdateien. Gerade noch rechtzeitig gelang es, alle Veeam-Jobs zu beenden, kurz bevor die Systemdisk erneut volzulaufen drohte.
Beim Überprüfen der Backup-Jobs bemerkte ich, daß irgendwie der Backup-Copy-Job ein Fallback auf das Default-Repository gemacht haben musste. Wahrscheinlich als sein eigentliches Repository offline war.
Man braucht nicht viel Phantasie, sich vorzustellen, wie schnell ein Backup- oder Copyjob die kleine Systemdisk mit Daten erstickt.
Fazit
Ich mache mir dies nun zur Standard-Prozedur, nach jeder Veeam Installation: Sobald das erste Repository definiert wurde, lösche ich das Default-Repository. Dies zu vergessen ist eine schlummernde Zeitbombe in jeder Veeam Infrastruktur.