Wie wahrscheinlich alle festgestellt haben, waren wir gestern down. Leider war dies aus verschiedenen Gründen länger, als es eigentlich hätte dauern sollen. In diesem Artikel möchte ich kurz auf das geschehene eingehen.
Der Ausfall
Er kam unterwartet, plötzlich und unbegründet. Gestern Nacht, als ich – wie so oft – mal wieder nicht schlafen konnte, arbeitete ich an einem Projekt das auch auf diesem Server liegt. Das Terminal wurde zäh und reagierte kaum noch auf Eingaben. Im Browser hingegen war alles da, nur nicht in der gewohnten Geschwindigkeit.
Das war in der Vergangenheit hin und wieder mal der Fall, hier half ein Neustart der VM. Bis zur Eingabe des LUKS Kennworts sah auch noch alles gut aus. Der Bootprozess an sich hat sich nicht mehr gefangen. Waiting for Service XXX lachte mich mehrfach an – auch nach 10 Minuten kein gestartetes System.
Die Recovery
“Es ist ja nachts, das merkt keiner. Leg das Teil halt mal in den Restore” war mein erster Gedanke, gegen 3 meldete sich dann mal die Müdigkeit. Veeam Recovery Media in den Server gelegt, Zugangsdaten zu einer Hetzner StorageBox eingegeben und auf Full Restore gedrückt. Das dauert erstmal eine Weile, husch ins Bettchen. 💤
Am Morgen, noch vor meiner ersten Tasse Kaffee, folgte ein Blick in mein Terminal. Er sagt fertig, okay ISO aushängen und Neustart. Kein Boot, der Server landet direkt in der EFI Shell. Mein erster Gedanke war “Partitionierung nicht im Standard, LUKS und UEFI Boot… Veeam hat damit vielleicht ein Problem”. An und für sich nicht tragisch: GRML ISO booten, LUKS einhängen, Logical Volumes bzw. die VG einhängen, GRUB drumherumbauen und los gehts. So der Plan.
Ein Blick in lsblk eröffnete mir dann den Totalschaden:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 3T 0 disk
└─sda1 254:0 0 3T cryptWas soll das denn? Alles ins LUKS geschrieben. Mir völlig unverständlich, der Recovery Assistant hatte das Partitionslayout korrekt angezeigt.
Der letzte Ausweg: Veeam Extract Utility
Nach diesem Rückschlag war die Motivation wirklich am Boden! Ein Kaffee später dann die Idee: “Du hast den baugleichen Server nochmal im Bestand, der darf nochmal Veeam versuchen. Parallel dazu installierst du einfach einen per Hand und verpflanzt die Daten”. Auf dem Verpflanzten lest ihr gerade diesen Artikel, Veeam hat es erneut nicht geschafft. Getreu einer bekannten Filmreihe hieß es dann “Helft mir Obi-Wan Kenobi, ihr seid meine letzte Hoffnung” – das Veeam Extract Utility to the Rescue!
Veeam ist der König der Datensicherung, noch nie habe ich etwas besseres gesehen. Dieses Bild vom Produkt hat sich seit gestern Nacht verändert. Sie bieten ein Extract Utility an, um ihre propreitären .vbk Files zu öffnen. Hier hätte es ein leichtes sein sollen, die Files herauszukopieren. Jedoch mit meinem inkrementellen Backup von 1 Uhr konnte er nichts anfangen: Could not find Full Backup File for XXX. Hmpf doof, ich habe die Daten hier alle liegen, komme aber nicht ran. Selbstverständlich lag das Full Backup File direkt daneben. Das kann es doch nun wirklich nicht sein – Wut machte sich breit. Eine kurze Google Suche später kam heraus, die dicke Backup&Replication Konsole (mit der zugehörigen Serverkomponente) kann vbk’s aus einem Ordner importieren. Von diversen Fällen im Beruf wusste ich, das die Konsole ein Guest File Restore bietet, genau das was ich brauche. Wenn es der Extractor nicht schafft, dann vielleicht die dicke Konsole!
Server drei kam ins Spiel, Windows Server mit Veeam darauf installiert, FIles importiert, File Restore angeworfen und … meh:
Das Ding braucht einen Linux Server um seine eigenen propreitären Daten zu öffnen, dessen Konsole aber nur Windows-fähig ist?! Naja missbrauchen wir Server 4 – an Servern soll es hier nicht mangeln! Ist nur etwas hirnrissig die Daten einmal durchs Internet schieben zu müssen.
Erfolg! Daten!!! Die Freude war größer als an Weihnachten. Die Neuinstallation von Server 2 war bereits abgeschlossen, ab ans betanken: Pakete installieren, SCP der Konfigurationsdateien, Neustart der Dienste, Datenverzeichnisse /var/www/ kopieren, Datenbanken importieren, Zertifikate ausstellen und go.
Dumm, dümmer, Veeam
Veeam hat aktiviertes Application Aware Processing sowie Datenbanksicherung aktiviert. In der Firma funktioniert das mit MSSQL auch echt super, doch hier…. Seht selbst:
Mal abgesehen von der Tatsache, dass er nur PostgreSQL Datenbanken findet obwohl auch mysql aktiviert ist, bricht das auch noch mit einem Fehler ab. Für die Recovery nur zeitverzögernd – Datenverzeichnisse sind ja vorhanden und müssen manuell verpflanzt werden (klingt einfacher als es ist). Unnötige Arbeit die man sich hätte sparen können, wenn das Produkt richtig funktionieren würde.
Hetzner “Online” GmbH 🤬
Wohl eher Hetzner Offline, die größte Bremse bei der gesamten Aktion. Irgendjemand dort hielt es für klug die Übertragungsrate einer StorageBox auf 11,3 MB/s zu limitieren. Für etwas über einem halben Terrabyte Datensicherung nicht geeignet. Hierbei war es auch egal ob der Webserver selbst (gleiches RZ) mit 2,5 GBit/s oder eine AWS EC2 mit 10 GBit/s aus Frankfurt versucht zu saugen. Wer entscheidet sowas? Mir absolut unbegreiflich. Klar teilen sich mehrere Kunden einen Storage-Host, dieses Limit ist dennoch nicht mehr zeitgemäß und sollte überdacht werden.
Diese StorageBoxen werden einem auch angedreht, wenn man einen Server dort anmietet. Somit muss das Produkt ja eigentlich auch dafür ausgelegt sein Full Backups zurückzuspielen! Dort scheint es aber nicht nur mit den Produkten Probleme zu geben, wenn man hier oder hier mal reinschaut – diese Seiten sprechen eigentlich für sich.
Danke für diese Erfahrung, Kündigung geht heute Abend raus, die beiden Dell PowerEdge dann im Laufe der nächsten Monate. Der S3 Speicher von Wasabi ist schnell und günstig – das wird die Zwischenlösung werden.
Wird Zeit das IP-Projects endlich mit einem StorageBox-Produkt um die Ecke kommt, das dürfte dann auch vernünftig konfiguriert sein so wie ich deren Arbeit und Produkte bisher kennengelernt habe.
Fazit
Lässt sich am besten als Bullet-List zusammenfassen:
- Veeam Extractor ist doof.
- Veeam wird ersetzt!
- Hetzner StorageBoxen sind unerträglich langsam und für Desaster Recovery absolut unbrauchbar!
- Restores künftig nur mit Neuinstallation und Datenübernahme (Borg und Deployment-Script)
Exakt 24h nach dem Ausfall waren wir wieder online. Über den Berg sind aber noch nicht alle Dienste – es muss noch einiges im Hintergrund passieren. Kurze Aussetzer werden heute noch vorkommen, sorry dafür!
Somit geht mein digitaler Mittelfinger diese Woche an Veeam und Hetzner für ihre gut funktionierenden Produkte die ihresgleichen suchen!
Update vom 18.03.2023 14:30 Uhr
Der Senior Director Technical Sales Germany von Veeam hat uns kontaktiert um eine Lösung für dieses Problem zu finden. Für uns ist es zwar zu spät, das Produkt kann man trotzdem verbessern. Mal sehen was daraus wird. Wir halten euch auf dem laufenden!
Update vom 20.03.2023 13:30 Uhr
Auch Hetzner Online hat uns kontaktiert, um den Fall zu überprüfen. Hierzu wird es ein Follow-Up geben.