Fallstricke beim vProxy FLR

Andreas Balthasar Unkategorisiert

Wie in meinem vorherigen Beitrag “NetWorker vProxy File-Level-Recovery” bereits geschrieben, möchte ich hier einmal eingehender auf Probleme, bzw. Fallstricke eingehen, denen man möglicherweise begegnet.
Beim Aufsetzen des Restores kommt man unweigerlich zu dem Punkt, an dem NetWorker um Zugangsdaten für das Zielsystem bittet.
Diese werden benötigt, damit NetWorker sich auf dem Zielsystem einloggen und dort Dateien restoren kann.
Hier gibt es jedoch einige Fallstricke, bzw. Besonderheiten:

1) NetWorker benötigt für den Restore-Vorgang auf dem Zielsystem einen FLR-Agenten. Ist dieser nicht vorhanden oder veraltet (z.B. noch von einer alten vProxy-Version), kopiert er diesen auf das Zielsystem und installiert, bzw. aktualisiert diesen.
Für die Installation ist ein Benutzer mit Administrator-Berechtigungen (bei Windows), bzw. der root-Benutzer (bei Linux) nötig. Da es Unternehmen gibt, die Restores ausschließlich über personalisierte Benutzer erfolgen lassen wollen, ist der root-Account natürlich nicht so toll. Leider gibt es keine Möglichkeit, die Installation mittels sudo zu erledigen. D.h. es bleibt bei Linux tatsächlich nur der root-Account.

Alternativ kann man sich jedoch auch den FLR-Agenten vom vProxy manuell runterladen (z.B. mit WinSCP oder via scp). Die Dateien liegen in /opt/emc/sw-repo/vflragent, bzw. dort in den Unterverzeichnissen “linux” und “windows”. Die entsprechene Datei kann man dann auf das Zielsystem kopieren und dort installieren. Oder, falls man das Aufsetzen von neuen Servern automatisiert hat, könnte man den Agenten natürlich auch sofort beim Aufsetzen mitinstallieren. Z.B. via SCCM oder Satellite Server, ö.ä. Darüber lassen sich auch Updates durchführen.
2) Wenn der FLR Agent bereits installiert ist, wird für den Restore theoretisch kein Account mehr mit administrativen Rechten benötigt. Ich schreibe hier allerdings mit Absicht ‘theoretisch’. Wenn man sich z.B. mit seinem persönlichen Account auf einem Linux-System anmeldet, bedeutet das eben noch lange nicht, dass man auch Zugriff auf das Verzeichnis hat, in welches man restoren soll. D.h. den Restore müsste man demnach immer im Kontext des Endbenutzers durchführen. Den Endbenutzer bekommt man z.B. bei einem Fileserver aber wohl kaum dazu, seine Zugangsdaten in eine ihm bislang unbekannte Eingabemaske einzutippen. Geschweige, dass man den Endbenutzer überhaupt kontaktiert bekommet, da hier häufig z.B. noch ein User Help Desk o.Ä. dazwischen ist. Durch die sehr komplizierte Rechtestrektur bei Windows wird dies sogar noch problematischer.
Bei einem Linux darf der root alles. Punkt. Er darf jede Datei auf dem System kopieren, verschieben oder löschen. Bei Windows sieht die ganze Sache jedoch anders aus. Nur weil man der Administrator ist, heißt das noch lange nicht, dass man auch alles darf. Wenn man mit seinem Account nämlich keine Berechtigungen auf ein Verzeichnis oder eine Datei hat, kann man die auch nicht verändern oder kopieren – obwohl man einen Administrator-Account hat. Und auf die Home-Verzeichnisse von Benutzern hat man diese Berechtigungen häufig nunmal nicht. Beim traditionellen Restore über den normalen NetWorker Agenten umgeht NetWorker dies, indem der Agent mit den Berechtigungen des SYSTEM-Accounts läuft. Der darf wirklich alles, aber als SYSTEM kann man sich nunmal nicht einloggen.
3) Jeder kennt sicher das Pop-Up von Windows, in der man gefragt wird, ob man diese Operation mit erhöhten Rechten ausführen möchte. Als Anwender kann man hier auf ‘Ja’ klicken und schon geht es weiter. NetWorker kann dies leider nicht, wodurch man ggf. schon in Probleme läuft, wenn man die zu restorenden Dateien auswählen möchte – oder spätestens dann, wenn man die Dateien in das Original-Verzeichnis zurückschreiben möchte.

Wenn man den FLR Agenten installiert bekommt (sprich der Mount ist abgeschlossen und man kommt an dem Punkt, wo man sich Dateien aussuchen darf), hat man jedoch noch andere Möglichkeiten. Denn die Platten hängen jetzt an der Ziel-VM und – wie in meinem vorherigen Beitrag unter dem Punkt 12) beschrieben – kann man jetzt auch z.B. mit dem Windows-Explorer darauf zugreifen. Dadurch hat man jetzt deutlich mehr Möglichkeiten. Hierzu schreibe ich ebenfalls noch einen gesonderten Beitrag, der zeigt, welche Tricks man noch nutzen kann.

Schaut man in die Kompatibilitätsmatrix des FLR Agenten fällt auf, dass z.B. Windows 2003 dort nicht aufgeführt wird. Und wer es trotzdem einmal bei einem Windows 2003 probiert, wird feststellen, dass sich der Agent dort nicht installieren lässt. Ja, Windows 2003 wird schon lange nicht mehr unterstützt, aber die Realität sieht halt so aus, dass viele Unternehmen trotzdem noch Windows 2003 einsetzen.
Also kein FLR bei Windows 2003?
Doch! Auch dazu werde ich noch in einem Beitrag eingehen. Vorweg: Hierfür kann man einen ganz normalen Instant Access Restore durchführen und mountet dann die gewünschte Platte im vCenter mit “Add existing hard disk” an die Ziel-VM. Und schon hat die Ziel-VM eine neue Platte, auf die man mit Betriebssystem-Mitteln (z.B. Windows-Explorer) zugreifen kann.