Vor drei Wochen mittwochs war mein Termin mit Veeam, der mehr als nur aufschlussreich war. Ideen wurden getauscht, Beispiele aus der Praxis dagelassen und die ein oder andere Admin-Story hat es dann auch noch ins Programm geschafft. Es waren sehr produktive Stunden für alle Beteiligten! Danke abermals für die Möglichkeit, mit einem Techniker zu analysieren und ergründen.
Veeam
Veeam kann tatsächlich LUKS und LVM! Nur nicht so wie man es erwarten würde, man muss hier »anders« wiederherstellen. Dazu werde ich mal einen gesonderten Artikel verfassen, der auch meine nicht-Standard-LUKS-Einstellungen berücksichtigt. Dieser Weg war nachts um 3 leider nicht direkt ersichtlich, wir erinnern uns, der Restore Assistant hatte mein „altes“ Partitions/LVM Layout korrekt angezeigt.
Warum die Datenbanken nicht gesichert wurden, haben wir teilweise ergründet. Hier liegt der Teufel wie so oft im Detail. Es ist wohl so, dass es doch Unterschiede zwischen mysql und MariaDB gibt, obwohl diese als binärkompatibel beworben werden. So binärkompatibel sind sie dann doch nicht, genauer nachgefragt habe ich da nicht, als nicht-Entwickler würde ich es wahrscheinlich nur unzureichend wiedergeben können. MariaDB habe ich als Feature Request dagelassen.
Veeam kann Pre- und Post-Job Scripts ausführen. Die Datenbanken werden mit einem mysqldump und pg_dump zuvor exportiert und im Post-Script wieder gelöscht. Ob das nun Veeam direkt macht oder ein Script ist für meinen Einsatzzweck egal, weshalb wir auch die defekte PostgreSQL Sicherung nicht ergründet haben. Ohne die große Konsole ist die Datenbankinstanzsicherung nicht notwendig.
Marco hat auf seinem Blog einen Artikel verfasst, wie ein solches LUKS-Layout wiederherzustellen ist.
Wir haben den Restore mit meinem damaligen Backup durchgeführt, Ergebnis OK.
Hetzner
Zwischenzeitlich wurde ein Fix auf alle StorageBox-Hosts verteilt, der diese Probleme etwas abfedern soll. Das kann ich auch bestätigen:
Auch während dem Restore Test mit Veeam war die Verbindung stabil und in einer angenehmen Geschwindigkeit
Dennoch ist diese Lösung nicht endgültig, Hetzner möchte den eingesetzten FTP Server tauschen. Hier wird es die Zeit zeigen, den Grundpfeiler eines Produktes reißt man nicht einfach ein. Geduld ist angesagt, niemand möchte Breaking Changes oder Datenverlust.
Fazit
Kurzum: Ich bin zufrieden. Backups laufen wieder, Datenverlust gab es auch keinen. Es war nur ein unglaublicher Aufwand, alles manuell zusammenzubasteln. Trotz allen Tests, die hier bisher gelaufen sind, hat es dennoch gekracht. Diese Recovery verdeutlicht, wie es in der Praxis auch laufen kann und was eure Admins vereinzelt durchmachen müssen. Es liegt aber auch an diesen Admins, aus einem Häufchen Asche noch etwas Funktionierendes zu zaubern.
Als Wunsch habe ich Veeam eine Ergänzung der Dokumentation dagelassen. »Special Restore Szenarios« oder so ähnlich, einfach ein Punkt in der Dokumentation mit dem Flag „Kein Support hierfür, funktioniert aber meistens“. Wie so etwas aussehen könnte, zeigt DATEV (nicht nur da, es gibt mehrere Artikel »Erfahrungen aus der Praxis«). Sie können den mIdentity über den ESXi an die VM durchreichen, es KANN aber zu Problemen kommen – unterstützen wir nicht. Diese Art von Tipps, egal von welchem Hersteller, können in manchen Fällen wirklich sehr hilfreich sein.
Veeam “veeamt” wieder im Produktiveinsatz, seit der Agent Version 6 auch endlich auf S3 Speicher. Die StorageBoxen werden ein gutes zweites Ziel sein. Wer einmal die S3 Geschwindigkeit kosten durfte, möchte nicht mehr zurück.
PS An Veeam: Debian 12 bitte Day One Support, danke 😜