Heute präsentiere ich Ihnen erneut mit Freude hilfreiche Tipps von meinem Kollegen Jewgenij Iwanow, Teamleiter im technischen Support von Veeam. Diesmal hat Jewgenij Empfehlungen zur Arbeit mit Backups und Replikaten geteilt. Ich hoffe, sie helfen Ihnen, typische Fehler zu vermeiden, und Ihre Replikate und Backups werden niemals das "Schwächste Glied" im Wiederherstellungsprozess sein, falls dies erforderlich ist.

Also, willkommen unter dem Beitrag.

In meinem vorherigen Artikel haben wir uns damit beschäftigt, wie man die Belastung der Komponenten der Backup-Infrastruktur optimieren kann, und haben typische Konfigurationsfehler betrachtet. Kommen wir zu einem anderen wichtigen Thema – der ordnungsgemäßen Vorbereitung und Durchführung der Wiederherstellung. Auch dies werden wir anhand realer Beispiele untersuchen, mit denen das Support-Team gearbeitet hat.

Backup ohne Restaurant – Geld zum Fenster hinaus

Regelmäßig wenden sich Benutzer an uns, die in ähnlichen schwierigen Situationen geraten sind: Es muss eine Wiederherstellung aus einem Backup durchgeführt werden, aber bei dem Versuch erkennen die Leute, dass sie auf ein für sie unlösbares Problem stoßen. Und dieses Problem ist keineswegs das Fehlen eines Backups, das Verhalten von CryptoLocker oder etwas Ähnliches. Es ist "nur" die unzureichende Aufmerksamkeit bei der Überprüfung der Backups und Replikate auf die Wiederherstellungsfähigkeit. Viele konzentrieren sich oft ausschließlich auf den Prozess der Erstellung von Backups und vergessen, dass es nicht ausreicht, einfach nur ein Backup zu haben – es schützt nicht vor möglichen Problemen. Man muss verstehen, dass die Wiederherstellung ein völlig anderer Prozess ist, der seine eigenen Besonderheiten hat und unbedingt kontrolliert und getestet werden muss, bevor er in die Produktion geht. Hier sind einige aufschlussreiche Beispiele:

Der Benutzer hatte einen Ausfall einer kritischen virtuellen Maschine mit einer Größe von 20 TB. Ausfälle sind natürlich inakzeptabel, und der Admin startet den Prozess der Sofortwiederherstellung (VM instant recovery) – nach 5 Minuten ist die Maschine wieder bereit. Aber wir wissen, dass dieser Zustand der Maschine nur vorübergehend genutzt werden kann – sie muss unbedingt auf das Produktions-Datastore migriert werden. In diesem Beispiel stellte sich jedoch heraus, dass die Möglichkeiten der Infrastruktur es nicht erlaubten, 20 TB Daten in einem angemessenen Zeitrahmen zu kopieren. In den Einstellungen des Sofortwiederherstellungsprozesses wurde gewählt, die Änderungen auf der Festplatte zu speichern. C: Die Veeam Backup & Replication-Server (im Gegensatz zum vSphere-Snapshot) haben natürlich dazu geführt, dass der Speicherplatz auf der Festplatte schnell voll wurde. Zu dem Zeitpunkt, als der Benutzer den Support kontaktierte, hatte die VM Änderungen erfahren, die nicht ignoriert werden konnten. Das heißt, wir hatten die Situation, dass der Prozess der sofortigen Wiederherstellung einer kritischen Maschine nicht schnell abgeschlossen werden konnte – wie sollte man die Daten hier retten?
Ehrlich gesagt kann ich mich nach all den Jahren nicht mehr an alle Details des Endes erinnern, aber ich weiß, dass wir letztendlich nichts Geniales erfunden haben. Die Kunden auf ihrer Seite hatten dieses Problem mehr oder weniger gelöst, indem sie das Laufwerk C: aus den Reserven erweitert, die wichtigsten Dateien kopiert hatten und dann die VM herunterfuhren und so migrierten. Alles in allem geschah leider kein Wunder.
In der Infrastruktur des Benutzers war ein Domaincontroller aktiv, und alle Komponenten von Veeam Backup & Replication wurden unter Verwendung von DNS konfiguriert. Ja, genau so, Sie haben sich nicht verhört. Es gab mindestens hundert Möglichkeiten für die Entwicklung der Ereignisse, aber die Realität verlief so: Die Leute hatten eine Wartung geplant und beschlossen, auf die Replica ihres Domaincontrollers umzuschalten. Sie führten einen geplanten Umschalter durch, was in solchen Situationen allgemein empfohlen wird. In der ersten Phase ging alles gut, aber in der zweiten wurde die ursprüngliche VM kurzzeitig heruntergefahren, um die verbleibenden Daten zu migrieren. Natürlich schlug die Umschaltaufgabe sofort fehl, da DNS nicht mehr funktionierte.
Glücklicherweise gelang es uns, die Situation zu bewältigen, indem wir die Replica manuell aus vSphere aktivierten (diese Operation selbst durchzuführen wird eigentlich nicht empfohlen, wie Sie im nächsten Beispiel sehen werden). Aber wie Sie verstehen, wurde der Wartungsprozess unterbrochen und verschoben. Darüber hinaus mussten wir die Hostnamen manuell in die Datei C:WindowsSystem32driversetchosts auf dem Veeam Backup & Replication-Server eintragen, um die Richtigkeit beim Rückumschalten sicherzustellen.
Ein weiterer Kunde hatte seine gesamte Backup-Infrastruktur um Magnetbandlaufwerke aufgebaut, während auf der Festplatte lediglich kurze Dateiketten gespeichert waren. Als sie dann eine Reihe von Dateien von einem großen Dateiserver wiederherstellen mussten, stellte sich heraus, dass keine Maschine als Hilfsrepository für die Wiederherstellung von Bändern verwendet werden konnte, da auf keiner genügend freien Speicherplatz war. (Über die Wiederherstellung von Magnetbändern direkt und mit Hilfe eines Hilfsrepositories können Sie lesen hier (vorerst in englischer Sprache)).

Ich denke, dass in allen drei Beispielen die Benutzer sozusagen in einer Illusion gefangen waren – sie gingen davon aus, dass wenn das Backup erfolgreich war, es auch bei der Wiederherstellung keine Probleme geben würde. Doch das ist, wie Sie verstehen, keineswegs immer der Fall, und deshalb muss die Wiederherstellung ebenso sorgfältig vorbereitet werden wie das Backup. Zunächst sollte man das Benutzerhandbuch, in dem recht ausführliche Informationen zu verschiedenen Wiederherstellungsmethoden enthalten sind, studieren. Am Anfang jedes Absatzes werden die Anforderungen, vorbereitenden Maßnahmen und möglichen Einschränkungen aufgelistet. Informationen zur Wiederherstellung von Magnetbändern oder aus Snapshot-Backups von SAN finden Sie in den Dokumentationsabschnitten und auf unseren Artikeln bei Habré. Darüber hinaus sind die Schritte zur Vorbereitung der Wiederherstellung von Anwendungsobjekten mit den Veeam Explorers im Abschnitt „Planung und Vorbereitung“ beschrieben Handbuch für jedes der Tools. Ich empfehle Ihnen, sich diese sorgfältig anzusehen – das wird Ihnen helfen, das System im Bedarfsfall korrekt auf die Wiederherstellung vorzubereiten. Die Anleitungen zur Wiederherstellung von SQL Server-Datenbanken sind hier.

Warum sollte man nicht mit Replikaten über die vSphere-Konsole arbeiten?

Im Grunde genommen sind Veeam-Replikate ganz normale virtuelle Maschinen, mit denen es eigentlich sinnvoll wäre, im vSphere-Toolset zu arbeiten, insbesondere mit dem vSphere-Client. Allerdings empfehlen wir dies nicht, und hier ist der Grund: Der Wechsel zu einer Replikat in Veeam Backup & Replication ist ein ziemlich komplizierter Prozess, der ein strenges und schrittweises Vorgehen erfordert (damit man im Bedarfsfall einen Schritt zurückgehen kann) und korrekte abschließende Aktionen – schauen Sie sich nur das Bild an, das den Prozess illustriert:

Wenn Sie jedoch in Erwägung ziehen, das Replica im vSphere Client zu aktivieren, stehen Ihnen mit hoher Wahrscheinlichkeit eine Reihe von Problemen bevor:

Der Mechanismus zum Umschalten auf das Replica aus Veeam Backup & Replication (siehe Diagramm) wird für diese Maschine nicht mehr funktionieren.
Die Daten in der Veeam Backup-Datenbank stimmen nicht mit dem tatsächlichen Zustand der VM überein. Im schlimmsten Fall müssen Sie die Datenbank bearbeiten, um sie zu reparieren.
Es kann sogar zu einem Datenverlust kommen, wie in folgendem Beispiel: Ein Benutzer aktivierte manuell das Replica im vSphere Client und beschloss, weiter mit ihm zu arbeiten. Nach einiger Zeit bemerkte er, dass das Replica weiterhin im Veeam Backup & Replication-Konsolen angezeigt wurde und beschloss, es der Unnötigkeit halber zu entfernen. Er klickte mit der rechten Maustaste darauf und gab den Befehl «Delete from disk». Veeam Backup & Replication löschte umgehend das Replica von der Festplatte, das, nebenbei bemerkt, bereits als normale VM verwendet wurde und wichtige sowie nützliche Daten enthielt.

Es gibt sicherlich Situationen, in denen man das Replica aus dem vSphere Client aktivieren muss – in der Regel handelt es sich um Fälle, in denen der Veeam-Server heruntergefahren ist und das Replica mit Verzögerung aktiviert werden muss. Wenn mit dem Veeam-Server jedoch alles in Ordnung ist, sollten Sie mit den Replikaten genau aus seiner Konsole arbeiten.

Ebenso sollten Sie Replikate nicht entfernen, indem Sie den vSphere Client verwenden. Veeam Backup & Replication bleibt über diese Änderung im Unklaren, was zu Fehlern und veralteten Daten führen kann. Wenn das Replica nicht mehr benötigt wird, löschen Sie es über die Veeam-Konsole und nicht wie eine VM über den vSphere Client. So haben Sie immer eine aktuelle Liste der Replikate.

«O» – Achtung, Updates!

Hierbei beziehen wir uns natürlich auf Updates für Hypervisoren und verschiedene Anwendungen, die mit Veeam gesichert werden. Wenn man sie aus der Sicht von Veeam Backup & Replication betrachtet, kann man die Updates grob in zwei Kategorien unterteilen: große, bedeutende, die viele Änderungen bringen – und kleinere.

Betrachten wir zunächst die erste Kategorie.

Die wichtigsten Updates sind diejenigen, die für den Hypervisor gedacht sind. Bevor ein solches Update installiert wird, muss unbedingt sichergestellt werden, dass es von Veeam Backup & Replication unterstützt wird. Solche Updates bringen zahlreiche Änderungen in die Bibliotheken und APIs mit sich, die Veeam Backup & Replication verwendet, weshalb zur offiziellen Unterstützung der Code von Veeam Backup & Replication aktualisiert und umfangreiche Tests durchgeführt werden müssen.

Es ist auch zu beachten, dass beispielsweise VMware keinen vorzeitigen Zugang zu den neuesten Versionen von vSphere für Softwarehersteller bereitstellt, sodass die Entwickler und Tester von Veeam die neue Version gleichzeitig mit der gesamten übrigen fortschrittlichen Menschheit erhalten – daher vergeht in der Regel eine bestimmte Zeit zwischen der Veröffentlichung von VMware und der offiziell angekündigten Unterstützung. Die Anzahl und Vielfalt der erforderlichen Änderungen sind so groß, dass sie in einen einfachen Hotfix kaum zu integrieren sind – und die offizielle Unterstützung wird in der Regel zusammen mit der Veröffentlichung der Release-Version von Veeam Backup & Replication bekannt gegeben.

So kommt es schließlich zu dem unangenehmen Moment, in dem die Anzahl der Supportanfragen nach dem Erscheinung einer neuen Version von vSphere sprunghaft ansteigt, weil die Nutzer hektisch das neue Update installieren und ihre Backups natürlich sofort nicht mehr funktionieren. Wir – der Support von Veeam – müssen den Nutzern erklären, was genau sie falsch gemacht haben, sie bitten, zurückzukehren (wenn möglich) oder sich ausgeklügelte Lösungen zur Überwindung der Sackgasse auszudenken. Deshalb sollten Sie vor der Installation eines größeren Updates unbedingt überprüfen, ob dies mit der bei Ihnen laufenden Software kompatibel ist, ich bitte Sie darum!

All dies gilt auch für die Anwendungen, die Sie sichern und von denen Sie erwarten, sie mit Veeam wiederherzustellen. Die Produktreihe Veeam Explorers hat ebenfalls eine Liste unterstützter Versionen der entsprechenden Anwendungen, die mit jeder Veröffentlichung von Veeam Backup & Replication aktualisiert wird. Daher sollten Sie vor der Installation einer neuen Version Ihrer Anwendung – sei es Exchange, Oracle oder SharePoint – unbedingt den entsprechenden Abschnitt der Dokumentation zu Veeam Explorers lesen..

Zur zweiten Kategorie, das heißt zu kleineren Updates, zählen zum Beispiel neue Versionen von VMware Tools, kumulative Updates für Exchange, Sicherheitsupdates für vSphere usw. In der Regel bringen sie keine wesentlichen Modifikationen mit sich, und in den meisten Fällen hat Veeam Backup & Replication damit keine Probleme. (Deshalb gibt es für sie keine öffentlichen Ankündigungen zur offiziellen Unterstützung im Produkt.) Dennoch haben wir in der Praxis Fälle erlebt, in denen selbst solche Updates den gewohnten Ablauf der Dinge so stark verändert haben, dass sie zu Fehlern bei Veeam Backup & Replication führten. In solchen Situationen bemühen sich die Ingenieure von Veeam, nach Bestätigung des Problems schnell einen Hotfix herauszugeben.

An diejenigen, die technische Englischkenntnisse habenWenn Sie wissen möchten, woran Ingenieure arbeiten und mit welchen Herausforderungen Systemarchitekten und Support-Spezialisten konfrontiert sind, empfehle ich, sich für unsere Foren. Jede Woche erhalten die Abonnenten einen Newsletter „Word from Gostev“ von TheRealGostev. Darin berichtet Anton Gostev, Leiter der Produktmanagement-Abteilung, über kürzlich gefundene Probleme (und nicht nur aufseiten von Veeam), über Pläne für neue Versionen und Neuigkeiten aus der IT-Welt. Wenn Sie mehr Informationen benötigen, können Sie die Diskussionen im Forum durchstöbern – wenn bei einem der Kunden ein Problem mit dem Produkt nach einem Update auftritt, hat er wahrscheinlich bereits im Forum darüber geschrieben.

Wie Sie verstehen können, können Patches und Updates nicht nur zu Problemen bei Backups führen, sondern auch bei den Anwendungen, für die diese Backups durchgeführt werden. Hier helfen Ihnen virtuelle Labore – Veeam DataLabs. Sie haben sicherlich von der Funktionalität SureBackup gehört, die zur Verifizierung von Backups dient. Diese basiert gerade auf der Nutzung von DataLabs, indem eine isolierte Umgebung geschaffen wird, in der man unter anderem Updates testen kann, bevor sie in der Produktion installiert werden. Ich empfehle dringend, dies zu tun – das wird Ihnen viele Nerven ersparen. Und falls jemand noch nicht von SureBackup gehört hat, empfehle ich zu lesen Dokumentation.

Das wäre vorerst alles, danke für Ihre Aufmerksamkeit!