vProxy FLR durchführen auch bei nicht-unterstützten Betriebssystemen

Es gibt immer noch Server mit Betriebssystemen, die von Dell EMC NetWorker nicht unterstützt werden, wie z.B. Windows 2003. Beim Backup macht der vProxy da keinen Unterschied und sichert auch diese problemlos. Beim File Level Recovery (FLR) fangen dann aber die Probleme an. Denn der FLR Agent lässt sich bei Windows 2003 nicht installieren.
Und damit kann man über den gewohnten Weg über die NMC auch keinen FLR mehr durchführen. Aber zum Glück gibt es dafür Workarounds.
Ein FLR ist vom Prinzip nichts anderes als ein Instant Access Restore, nur mit dem Unterschied, dass beim FLR keine neue VM registriert wird, sondern dass die Platten direkt an eine bestehende VM gemountet werden und dort zur Verfügung stehen. Eine Übersicht der verschiedenen Restore-Methoden gibt es hier.

In meinen vorherigen Beiträgen bin ich bereits auf die Fallstricke beim FLR eingegangen. Jetzt kommen wir auch endlich zu den Lösungsmöglichkeiten. 🙂

Der erste Workaround besteht schlicht und ergreifend darin, den FLR mit einer anderen Ziel-VM durchzuführen, auf der sich der FLR Agent installieren lässt. Im Anschluss kann man die Daten dann z.B. über eine Remote Deskop Session oder via scp auf den eigentlichen Ziel-Server kopieren. Dies hat allerdings den Nachteil, dass dieser Restore halt nicht direkt am eigentlichen Ziel ausgeführt wird und dementsprechend auch mehr Zeit kostet, als wenn man die Daten direkt auf auf der Ziel-VM restored.

Wie bereits oben erwähnt, ist der FLR vom Prinzip her ein Instant Access Restore. Die Data Domain stellt einen Datastore via NFS bereit, welcher dann von einem ESXi-Host gemountet wird. Darauf befinden sich normale VMDK-Dateien, sprich virtuelle Festplatten.
Damit stehen einem nun mehrere Möglichkeiten offen. Vom Prinzip her geht es schließlich darum, dass wir die VMDK-Datei, die unsere gewünschten Daten enthält, irgendwie an die Ziel-VM bekommen.
Wenn es sich um eine kleine Datenmenge (z.B. nur eine Datei) handelt, können wir den FLR verwenden. Als Ziel wählen wir hier eine VM mit einem unterstützen Betriebssystem (z.B. Windows 2008). Der Einfachheit halber sollte diese VM auf dem gleichen ESXi-Host laufen, auf dem sich auch unsere eigentliche Ziel-VM befindet. Für den Fall, dass eine solche VM nicht verfügbar ist, werde ich noch einen gesonderten Beitrag schreiben.
In der NMC klicken wir nach Eingabe von Benutzer & Passwort auf den Mount-Button und warten bis dieser durchgelaufen ist. Mehr ist an dieser Stelle hier nicht zu tun.

Jetzt müssen wir als erstens wissen, welche Platte(n) wir überhaupt haben wollen. Hier gibt z.B. unter Window das Disk Management Auskunft. Wichtig ist die Nummer der Disk und die Größe.
Jetzt müssen wir ins vCenter wechseln. Hier gehen wir zu unserer eigentlichen Ziel-VM, machen einen Rechtsklick auf diese und wählen “Einstellungen bearbeiten”.
Unten bei “Neues Gerät:” wählen wir “Vorhandene Festplatte” und klicken auf “Hinzufügen”. Es erscheint ein Fenster mit den möglichen Datenspeichern. Dabei sollte dann jetzt auch ein “EMC-FLR-<vproxy>-<zeitstempel>” Datenspeicher auftauchen. Diesen wählt man aus und bekommt dann den Inhalt angezeigt. Hier wählt man die gewünschte Platte (meist identifizierbar an der Größe der Platte und irgendeiner numerischen Zuordnung. z.B. de VMDK 2 ist in Windows häufig die Disk 1 – bei Windows fangen die Disks bei 0 an). Noch ein Klick auf OK und dann nochmal auf OK – und schon ist die Platte an der Ziel-VM. Über das Disk Management von Windows kann man der Platte dann einen Laufwerksbuchstaben zuweisen und über den Windows-Explorer die gewünschten Dateien kopieren.

Wichtig: Wenn man den Restore abgeschlossen hat, muss man über das vCenter die Platte wieder von der VM, an der man sie manuell gemountet hat, entfernen! Ansonsten kann NetWorker ggf. nicht verünftig aufräumen und es bleiben Mountpunkte und dergleichen liegen, oder der NFS-Export auf der Data Domain wird nicht gelöscht.
Ebenfalls wichtig: Für diese Methode über den FLR hat man nur ca. 30 Minuten Zeit. Ansonsten räumt NetWorker auf Grund von Inaktivität selbstständig auf, was zu den oben genannten Problemen führen kann.

Als letzten Schritt bricht man den Restore in der NMC ab. Danach räumt NetWorker alles wieder auf.