NetWorker vProxy File-Level-Recovery

Andreas Balthasar NetWorker, VMware

In diesem Beitrag möchte ich eingehender auf den File-Level-Recovery (FLR) Prozess mittels des vProxies eingehen. Als Vorbereitung dafür sollte man sich meinen Beitrag “Was genau macht ein NetWorker Instant Access Restore?” durchlesen.
Das FLR-Feature, mit welchem man ausgewählte Dateien oder Verzeichnisse restoren kann, gehört wohl zu den am häufigsten genutzten Restore-Methoden. In den meisten Fällen stellt man ja nicht ganze Server, sondern eben einzelne Dateien oder Verzeichnisse wieder her. Z.B. wenn jemand versehentlich eine Datei gelöscht hat.

In meinem vorherigen Beitrag zum Instant Access habe ich ja bereits einen großen Teil der Vorgänge beschrieben.
Die dort beschriebenen Schritte 1-9 gelten auch für den FLR, da FLR auf Instant Access basiert.
Es kommen jedoch noch einige Zwischenschritte dazu und in weiteren Beiträgen werde ich noch auf die besonderen Fallen beim FLR eingehen.

1) NetWorker sucht sich für den Restore ein passendes DDBoost Device und entnimmt die dort hinterlegten Device access Information. Diese beinhalten neben dem Namen (oder der IP) der Data Domain auch den Pfad auf dem Filesystem der Data Domain.
2) NetWorker versucht einen geeigneten vProxy zu ermitteln oder, falls man einen ausgewählt hat, wird dieser genommen. Die automatische Ermittlung funktioniert leider häufig nicht, wenn man in einem vCenter verschiedene Cluster hat, die voneinander unabhängig sind. In diesem Fall sollte man direkt einen geeigneten vProxy auswählen, um sich Zeitverluste zu ersparen.
3) Nun geht es ans vCenter. NetWorker ermittelt dort den Namen und alle IP-Adressen des ESX-Hosts, auf dem der Ziel-VM läuft.
4) Die Informationen aus 1) und weitere Informationen (z.B. Saveset ID des gewünschten Backups, Mtree Name auf der DD, usw.) werden an den vProxy übermittelt.
5) NetWorker versucht, sich mit den Zugangsdaten, die man vor dem Start des Restores eingegeben hat, am Ziel-System einzuloggen.
5a) Kann NetWorker sich nicht einloggen (z.B. falsches Passwort), ist an dieser Stelle Ende.
5b) Wenn NetWorker sich einloggen kann, prüft er noch, ob der FLR-Agent installiert ist.
6a) Ist der FLR-Agent installiert und aktuell genug, gehts weiter.
6b) Ist der FLR-Agent nicht installiert, wird er vom vProxy (der Agent liegt nämlich dort) mittels VMware Tools auf den Zielserver kopiert und dort versucht, diesen zu installieren, bzw. zu aktualisieren. Achtung: Dafür wird bei Linux der root-User, bzw. bei Windows ein Benutzer mit Administrator-Berechtigungen benötigt. Hat der verwendete User diese nicht, kann NetWorker den Agenten nicht installieren/aktualisieren und bricht hier ab.
7) Der vProxy kontaktiert die Data Domain unter der in 1) ermittelten IP/Name und teilt dieser mit, dass sie einen VMware Datastore mit einer Kopie dieses Savesets erstellen soll.
8) Die Data Domain führt diese Kopie in einen separaten Bereich durch, nämlich nach: /data/col1/<mtree (meist Backup Server Name)>/Recover-<vProxy-Name>-<ID>
9) Der vProxy kontaktiert die Data Domain und teilt dieser mit, dass sie einen NFS-Export für das Verzeichnis aus 8) mit dem Namen des Verzeichnisses aus 8) an den ESX-Host aus 3) erstellen soll. Die Liste der erlaubten NFS-Clients für diesen Export beinhaltet alle IPv4 & IPv6 Adressen des ESX-Hosts, sodass dieser eine Host auf welchem Weg auch immer an den Share kommt, aber niemand sonst. In der Data Domain GUI (oder auf der CLI) sieht man diesen Export auch bei Protocols -> NFS
10) Nun wird dem vCenter mitgeteilt, dass es einen neuen Datastore anlegen soll. Als Quelle dient der NFS-Share auf der Data Domain und gemountet werden soll er an dem ESX-Host aus 3)
11) In den ‘Benutzerdefinierten Attributen’ der Ziel-VM wird nun gesetzt, dass eine vProxy Aktion bei dieser VM aktiv ist. Achtung: Dies verhindert, dass NetWorker für diese VM Backups oder andere FLR durchführen kann! D.h. man sollte den FLR idealerweise nicht während oder kurz vor einem Backup durchführen. Gleichzeitig verhindert ein laufendes Backup (oder ein anderes FLR dieser VM) auch, dass ein FLR durchgeführt werden kann!
12) Nun werden die Platten an die Ziel-VM gemountet (mittels VMware HotAdd). Das Betriebssystem in der VM erkennt, dass es jetzt neue Platten gibt und kann damit arbeiten. Quasi so als würde man einen USB-Stick anschließen. Die neuen Platten sieht man bei Windows dann auch im Disk Management und kann diesen z.B. auch Laufwerksbuchstaben zuweisen.
Die Platten bekommen auch direkt einen Mountpunkt zugewiesen. Bei Windows z.B. “C:\Program Files (x86)\EMC\vProxy FLR Agent\flr\mountpoints\xxx” <- das xxx ist eine längere Zahlen- & Buchstabenkombination. D.h. mittels des Explorers kann man auch direkt darauf zugreifen. Bei Linux ist dies genauso. Auch dort sind neue Platten sichtbar und ihnen wird ein Mountpunkt zugewiesen.
13) Nachdem dies abgeschlossen ist, kann man in der NMC auf “Next” klicken und kann nun die Dateien und Verzeichnisse auswählen, die man restoren möchte.
14) Als nächstes wird man dann noch nach dem Ziel-Verzeichnis gefragt. Hier kann man ein vorhandenes Verzeichnis auswählen oder ein neues erstellen.
15) Jetzt geschieht der eigentliche Restore. Über die VMware Tools wird eine Liste der zu restorenden Objekte auf das Zielsystem kopiert. Der FLR-Agent bekommt den Pfad zu der Liste und das Ziel-Verzeichnis mitgeteilt. Wenn man sich einmal die Software-Anforderungen des FLR-Agenten angesehen hat, wird man nun auch erkennen, warum dort bei Linux rsync und bei Windows robocopy aufgeführt wird. Der FLR-Agent macht nämlich nichts anderes, als die Dateiliste und das Zielverzeichnis an rsync/robocopy weiterzugeben und diese führen dann den eigentlichen Kopiervorgang aus.
16) Sobald der Restore durch ist (oder wenn man den Restore-Prozess zwischen den Schritten 7-12 abbricht) räumt NetWorker auf. D.h. das Attribut der VM wird gelöscht, sodass wieder andere vProxy Aktionen möglich sind. Die Platten werden wieder von der VM unmounted (USB-Stick rausziehen), der Datastore wird ebenfalls unmounted und der NFS-Export auf der Data Domain gelöscht.