Optionen zur Wiederherstellung aus Speicher-Snapshots
Besonderheiten von auf Speicher-Snapshots basierenden Wiederherstellungspunkten
Wenn Sie wie beschrieben Speicher-Snapshots erstellt haben, werden diese automatisch gescannt, Sie können jedoch auch von der Konsole aus einen Scan auslösen. Die darin enthaltenen VMs werden im Baum “Backups” der Veeam-Konsole angezeigt. Neben den regulären Backups finden Sie die VMs mit all ihren Wiederherstellungspunkten im Hive “Snapshots”. Jeder Wiederherstellungspunkt entspricht einem bestimmten Snapshot innerhalb von DataCore.
Das hier gezeigte Beispiel wurde mit einem Snapshot-Only-Job namens “Snapshot-Only-Demo” erstellt, der nur eine einzige VM namens “Zeus” enthält, die mit der Anwendungsintegration gesichert werden soll.
Sobald der Scan des Speicher-Snapshots erfolgreich abgeschlossen ist, werden alle VMs innerhalb des Snapshots der LUN angezeigt. Selbst wenn der Snapshot durch einen Snapshot-Only-Job mit nur einigen Ihrer VMs erstellt wurde, finden Sie alle VMs auf der/den gesnappten LUN(s) als deren Inhalt. Daher könnten die anderen drei VMs in unserem Beispiel als “Beifang” betrachtet werden. Wir könnten jedoch auch aus ihnen Daten wiederherstellen.
Beachten Sie, dass ein Fehler in der aktuellen Version des DataCore-Plugins die anwendungskonsistenten VMs mit einem falschen Erstellungsdatum anzeigt. Die absturzkonsistenten VMs werden mit dem korrekten Erstellungsdatum des Snapshots angezeigt. Dieser Fehler wird voraussichtlich in der nächsten Version des Plugins behoben werden.
Die Snapshots unterhalb werden auch im Menü “Storage Infrastructure” angezeigt. Auch mit den darin enthaltenen VMs. Der Jobname wird in der Spalte ” protected by” angezeigt. Wenn der Snapshot-Only-Job mit Anwendungsintegration ausgeführt wurde, können Sie die VMs hier nach ihrem Zustand unterscheiden. Dieser kann entweder “Application consistent” oder “Crash-consistent” sein.
Optionen für Wiederherstellungen von Snapshots
Wie bei regulären Veeam-Backups werden uns verschiedene Arten von Wiederherstellungen angeboten. Bei Storage-Snapshots haben wir bei Veeam Backup und Replikation folgende Möglichkeiten:
- Instant-Recovery einer vollständigen VM
- Guest file recovery
- Application item recovery
Im Vergleich zu den regulären Veeam-Wiederherstellungen, mit denen Sie sicher vertraut sind, verwenden alle diese Optionen bei einer Wiederherstellung einen komplett anderen Pfad für Ihre Daten.
Die Daten können nicht direkt aus einem Repository geholt werden, da hier keine involviert sind. Bevor also eine der oben genannten Methoden genutzt werden kann, muss der Snapshot irgendwie gemountet werden. Dies geschieht über einen ESX-Host. Sie müssen den Host definieren, auf den der Speicher-Snapshot gemountet werden soll. Veeam erledigt dies vollautomatisch, indem der Snapshot auf den Host gemountet wird. Es muss jedoch ein Host sein, der Zugriff auf den DataCore-Speicher hat, mit dem wir es zu tun haben.
Instant-Recovery
Wenn wir eine VM vollständig wiederherstellen müssen, um die Verfügbarkeit zu gewährleisten und in Sekundenschnelle booten zu können, entscheiden wir uns für “Instant VM Recovery” und wählen einfach die VM und den Wiederherstellungspunkt aus. Beachten Sie nochmals den Bug, der diesen Wiederherstellungspunkt fälschlicherweise auf das Jahr 1970 setzt. Dies geschieht für jede anwendungskonsistente VM innerhalb eines Snapshots. Vgl. vorheriges Kapitel.
Jetzt haben wir, wie bei jedem “Instant VM Recovery”, die Möglichkeit, auf “…den ursprünglichen Speicherort” wiederherzustellen und dabei dieselbe ID (genauer gesagt MoRef) zu verwenden. Auf diese Weise können wir erreichen, dass die VM von Veeam in den bestehenden Backup-Jobs wieder erkannt wird. Veeam muss jedoch zuerst die ursprüngliche VM löschen, da die ID eindeutig sein muss.
Die Option “…an einen neuen Standort…” erzeugt eine VM parallel zu einer neuen MoRef/ID, so dass beide koexistieren können.
In unserem Beispiel, in dem wir einen produktiven Domänencontroller wiederherstellen werden, werde ich die zweite Option wählen. Einfach, um die produktive VM nicht zu verändern.
Auf dem nächsten Bildschirm wählen wir einen Namen für die unabhängige VM und den Host, auf dem sie veröffentlicht werden soll.
Schließlich müssen wir entscheiden, ob wir die VM sofort starten und ob wir sie an das Netzwerk anschließen wollen. Ich werde keine Verbindung mit dem Netzwerk herstellen, da die produktive VM noch aktiv ist.
Sobald wir auf “Fertigstellen” geklickt haben, geschieht Folgendes:
Der Snapshot wird innerhalb von DataCore zunächst in ein unabhängiges Volumen geklont (VeeamClone PT). Für dieses Volume wird dann erneut ein Snapshot erstellt.
Dieser neu erstellte Helfer-Snapshot wird schließlich an den ausgewählten ESX-Host gemountet.
Nun ist Veeam bereit, eine Resignatur der LUN im ESX einzuleiten und die wiederherzustellende VM mit dem gewählten Namen zu registrieren.
Am Ende wird Veeam auf eine Speichermigration warten, wie es bei jedem “Instant VM Recovery” der Fall wäre.
Beachten Sie, dass die zusätzliche temporäre LUN innerhalb des VMWARE-Clients als “Snap-…” Datenspeicher exakt derselben Größe wie die produktive LUN sichtbar ist.
Die VM löst in vCenter einen Alarm aus, da sie parallel zum ursprünglichen Workload dieselbe MAC-Adresse wie bei jedem Recovery trägt. Das können wir getrost ignorieren. Wir sollten sie sowieso nie zur gleichen Zeit live in dasselbe Netzwerk bringen.
Sobald die Wiederherstellung abgeschlossen ist, sollten wir nicht vergessen, den “Instant VM recovery”-Job zu stoppen, damit der Klon gelöscht und aufgeräumt werden kann.
Guest file recovery
Die Wiederherstellung von Gastdateien ist ebenfalls ein häufiges Szenario, das von einem DataCore-Speicher-Snapshot aus durchgeführt werden kann. Als Beispiel werden wir diesen dieses Mal über das Menü “Storage Infrastructure” aktivieren. Wir werden also keinen Rücksicherungspunkt auswählen müssen, da durch einen bestimmten Snapshot bereits ein solcher definiert ist.
Der Rest des Prozesses funktioniert ganz ähnlich wie die ” Instant VM recovery” auf der Speicherebene. Wir brauchen dazu einen Helfer-Host, um den Snapshot des Klons zu mounten, der ebenfalls generiert wird.
Nach dem Mount, dem Re-signieren und der Registrierung der VM sind wir wieder im gewohnten Ablauf. Die Dateiwiederherstellungskonsole öffnet sich, um für die eigentliche Wiederherstellung verwendet zu werden.
Vergessen Sie nicht, diese Konsole nach Beendigung zu schließen, damit auf der DataCore-Seite wieder aufgeräumt werden kann.
Application item recovery
TDie letzte Recoveryoption, die wir bei Snapshots haben, ist die Wiederherstellung von Anwendungselementen. Hier stehen alle Veeam-Explorer zur Verfügung, um Objekte aus den verschiedenen Workloads wiederherzustellen.
Auf dem nächsten Bildschirm müssen wir erneut den Wiederherstellungspunkt wählen, da wir den Prozess diesmal wieder vom “Backups”-Baum aus eingeleitet haben. Beachten Sie wieder den Fehler mit 1970.
Als nächstes müssen wir den Helfer-Host für den Mount auswählen.
Wenn alle Clones, Snapshots und Mounts vorhanden sind, öffnet sich schließlich ein Veeam-Explorer, um eine Wiederherstellung des gewählten Objekttyps zu ermöglichen. Active-Directory-Objekte in unserem Beispiel.
Schließen Sie den Veeam Explorer wieder, um DataCore und den ausführenden Host zu bereinigen.
DataCore licDataCore-Lizenzbegrenzung
Wie bereits erläutert, klonen alle drei Prozesse den wiederherzustellenden Snapshot vom ursprünglichen Snapshot in ein unabhängiges Volume innerhalb von DataCore. Dieses Volume wird erneut gesnappt, und dieser Snapshot wird an den unterstützenden Host gemountet. Hier könnte ein kleines Problem mit einer bestimmten Lizenzkombination von DataCore auftreten, die Sie möglicherweise installiert haben (Legacy VL und SB).
Bei der VL-Lizenz behebt eine so genannte Blindaktivierung das Problem. Sie beseitigt lediglich die Erweiterungsgrenze. Nicht so bei der SB-Lizenz.
Hintergrund: Da der Snapshot durch erneutes Mounten auf denselben DataCore-Server geklont wird, erhöht sich die verwaltete Kapazität Ihres Clusters um die Größe dieses Clones. Diese Kapazität wird absichtlich nicht auf Ihre verwendete Lizenz angerechnet. Also kein Problem hier. Aber bei einigen Lizenz-Editionen von DataCore ist auch eine maximale Erweiterungsgrenze voreingestellt. Wenn unser Cluster bereits nahe an dieser maximalen Ausbaustufe arbeitet, kann es vorkommen, dass der zusätzliche Re-Mount diese Grenze überschreitet und deshalb fehlschlägt.
Hintergrund: Da der Snapshot durch erneutes Mounten auf denselben DataCore-Server geklont wird, erhöht sich die verwaltete Kapazität Ihres Clusters um die Größe dieses Clones. Diese Kapazität wird absichtlich nicht auf Ihre verwendete Lizenz angerechnet. Also kein Problem hier. Aber bei einigen Lizenz-Editionen von DataCore ist auch eine maximale Erweiterungsgrenze voreingestellt. Wenn unser Cluster bereits nahe an dieser maximalen Ausbaustufe arbeitet, kann es vorkommen, dass der zusätzliche Re-Mount diese Grenze überschreitet und deshalb fehlschlägt.
Dies würde die betreffende Wiederherstellung verhindern. Wir können dieses Problem vermeiden, wenn uns genügend Spielraum zur Verfügung steht, damit wir das größtmögliche Produktionsvolumen in unserem Cluster ein zweites mal bereitstellen können, ohne die Grenze zu sprengen.