Ja, die NetWorker Version 8.2 ist jetzt schon seit 31. Januar offiziell nicht mehr unter Support, aber dennoch laufen wohl noch eine ganze Menge NetWorker-Server unter dieser Version!

Gerade große NetWorker Konfigurationen, mit mehr als 1000 Clients, Umgebungen die mit externen Schedulern wie Atomic (UC4) und ähnlichem gekoppelt sind, sowie Sicherungen mit langen Aufbewahrungszeiten, bilden für die Umstellung eine sehr große Hürde. Die Probleme bei der Umstellung sind bekanntlich die nötige Anpassung der Skripte, aber auch die Problematik der automatischen Konvertierung der NetWorker 8 Gruppen in eine einzige Policy namens Backup. Sollte der NetWorker 8 aber mehr als 50 Gruppen gehabt haben, wird die NMC nach einer In-Place Migration nicht mehr bedienbar. Ein weiteres nicht zu unterschätzendes Problem bei der Migration besteht darin, dass die Logik des NetWorker 9 lässt sich nicht mit der Logik des NetWorker 8 gleich setzen. Man benötigt folglich für den Update einer großen NetWorker-Umgebung, nicht nur eine Anpassung der bestehenden Datensicherungs-Skripte sondern auch ein neues Konzept und einen Migrationsplan.

Nachdem ich in den letzten 2 Jahren einige In-Place Updates in kleineren Umgebungen und auch Migrationen von großen NetWorker-Umgebungen in eine neue NetWorker 9 Umgebung begleitet habe, kam ein großer Outsourcer auf mich zu, ob ich mit den in diesen Projekten entstandenen Skripten (siehe Blog) in der Lage sei, eine In-Place Migration von NetWorker-Servern mit mehr als 1700 Clients und hunderten von Gruppen zu automatisieren.

Im letzten Monat habe ich nun dieses Projekt abgeschlossen.

Wie funktioniert der implementierte Ansatz?

Die Migration läuft im wesentlichen in 2 Schritten ab.

1. In-Place Migration der NetWorker 8 Datenbanken.

   • zuvor kopieren der NetWorker Ressource DB (/nsr/res/nsrdb)

   • In-Place Migration der NetWorker Umgebung

   • Löschen aller Policys, Protection-Gruppen und auch Clients aus dem NetWorker 9 Server (mit Hilfe eines nsradmin Skriptes)

2. Migrieren der NetWorker 8 Client-Ressourcen in die neue NetWorker 9 Umgebung.

   • Anhand eines definierten Algorithmus werden die Client-Attribute der NetWorker-8 Clients wie Gruppe, StorageNode usw. herangezogen, um jeden Client in eine neu definierte NetWorker 9 Policy/Workflow/Protection-Group abzubilden.

   • Das Anlegen der neuen Policy/Workflow/Protection-Group Ressourcen wird hierbei mittels REST-API Aufrufen automatisiert erledigt. Die Clients werden wegen fehlender Client-Attribute in der REST-API mit Hilfe von nsradmin-Skripten erzeugt. Das Sammeln der „alten“ Ressource-Attribute, sowie das Anlegen der Clients erfolgt mit Hilfe der Schäfer & Tobies eigenen nsradmin-API.

Worin lag das größte Problem bzw. der größte Aufwand bei diesem Projekt?

Die Problematik bestand in einer möglichst genauen Definition der Abbildung der Alten Client-Gruppen-Strucktur auf eine eindeutige Policy/Workflow Struktur. Diese Logik musste in das Migrations-Skript implementiert werden und der Aufwand hierfür war durch fehlende und missverstandene Kommunikationen leider wesentlich höher als erwartet.

Ergebnis des Projektes:

1. Eine NetWorker-Server Migration lässt sich an einem beliebigen NetWorker-Server leicht in wenigen Stunden testen.

2. Die eigentliche In-Place-Migration ist in wenigen Stunden auch für sehr große Umgebungen durchführbar.

3. Die Migrationsquote der getesteten NetWorker-Server mit ca. 1500 und 1700 Clients lag bei 98% bzw. 99%. Clients die aus verschiedenen Gründen nicht in der neuen Umgebung angelegt werden können werden, mit allen Attributen in einer eigenen Datei abgelegt und können von den NetWorker-Administratoren per Hand leicht korrigiert und nach-migriert werden.

FAZIT:

Auch große NetWorker-Umgebungen können mit einem relativ geringem Zeitaufwand auf NetWorker 9/18 In-Place migriert werden! Der Aufwand der Migration wird von der eigentlichen Migrations-Phase auf eine Planung und Implementationsphase verschoben.

Die Vorteile dieses Verfahrens liegen auf der Hand:

• Durch die In-Place Migration können Langzeitsicherungen ordentlich übernommen werden.

• Die Migration kann vor dem eigentlichen Umstieg ordentlich getestet werden.

• Der eigentliche Update-Vorgang ist zeitlich überschaubar.

Sollte auch Ihr Unternehmen noch vor dem Update ihrer NetWorker Umgebung stehen, haben sie mit unseren Migrations-Skripten vielleicht eine neue bisher nicht bedachte Möglichkeit der sanften Migration der NetWorker Umgebung. Sprechen Sie uns ruhig unverbindlich an.

Wiederherstellen von Dateien als NetWorker-Operator

NetWorker bietet grundsätzlich 3 verschiedene Schnittstellen um Dateien wiederherzustellen. Die NMC, das Command-Line-Programm „recover“ und das Windows spezifische graphische NetWorker-User-Programm (winworkr). Die komfortabelste und mächtigste Schnittstelle ist natürlich das Recover-Frontend in der NMC. Dieses hat aber leider eine nicht in allen Umgebungen passende Voraussetzung, denn der Benutzer dieses Recovers muss immer ein NetWorker-Administrator sein. Dieses Problem entsteht dadurch, dass am für jeden definierten Wiederherstellungsvorgang am Ende eine NetWorker-Ressource generiert wird. Diese kann eben nur von einem NetWorker-Administrator angelegt werden.

Der Wunsch vieler Teilnehmer meiner NetWorker-Workshops war immer wieder:

„Die Wiederherstellung beliebiger Benutzerdaten sollen von einem NetWorker-Operator durchgeführt werden können“.

Dies war in den bisherigen NetWorker-Versionen nicht ohne größere Konfigurationsaufwände auf den Client-Maschinen möglich. Mit der NetWorker Version 9.2.x hat sich dies nun durch eine nicht veröffentlichte Änderung der Kommando-Übergabe, an den wiederherzustellenden Rechner, geändert. Aber erst einmal ein paar grundsätzliche Sätze zum Wiederherstellen von Dateien im NetWorker vorneweg.

Das Wiederherstellen eigener Dateien war im NetWorker schon immer für jeden Benutzer möglich. Hierfür ist lediglich das „NSR user group“ Recht „Recover Local Data“ erforderlich und das hat jeder (*@*) NetWorker-Benutzer. Das bedeutet, jeder Benutzer kann seine eigenen Daten mit dem CLI-Kommando recover oder auf Windows zusätzlich auch noch mit dem NetWorker-User Programm wiederherstellen.

Bei der Wiederherstellung werden selbstverständlich alle Windows/UNIX Benutzerrechte (ACLs) berücksichtigt. Der Benutzer muss das Leserecht für die wiederherzustellenden Dateien und das Schreibrecht für das Wiederherstellungsziel besitzen. Der normale Benutzer kann demzufolge keine Daten wiederherstellen, die er nicht auch auf der Betriebssystemebene kopieren oder überschreiben darf!

Sollen Daten von einem anderen Benutzer als dem Eigentümer wiederhergestellt werden, so boten sich bis zur NetWorker Version 9.1 lediglich zwei Möglichkeiten. Entweder ein NetWorker-Administrator verwendete das NMC-Recover Fenster, oder ein Windows-Administrator oder ein Unix/Linux „root“ Benutzer auf, stellte die Daten auf der Ziel-Maschine mit den oben genannten recover oder NetWorker-User Programmen wieder her. In beiden Fällen gibt es also eine Einschränkung. Im ersten Fall, bei der Wiederherstellung mit der NMC, kann dies nur von einem NetWorker-Administrator durchgeführt werden, im zweiten Fall muss sich ein privilegierter Benutzer direkt auf der Zielmaschine anmelden. Was fehlte war die Möglichkeit einer Gruppe von Operateuren die Wiederherstellung von Daten auf beliebigen NetWorker-Client-Maschinen zu ermöglichen. Diese Möglichkeit gibt es jetzt!

Sobald ein NetWorker Benutzer die Rechte der Benutzer-Gruppe „Operator“ besitzt und als „root“ oder „Administrator“ angemeldet ist, ist er in der Lage alle Dateien auf allen NetWorker-Client Maschinen wiederherzustellen. Hierbei können mit Hilfe des NetWorker-User Programms auch Linux-Daten auf einem Linux-System wiederhergestellt werden. Dies gilt natürlich ebenso für die Wiederherstellung von Windows-Daten von einem Linux-System mit Hilfe des CLI-Kommandos recover. Wohlgemerkt, der Operator-Benutzer darf hierbei auf einem beliebigen vorher berechtigten NetWorker-Client arbeiten.

• Wie sieht die Konfiguration aus?

Der Benutzer „root“ auf der Maschine „sles12nw10“ hat das Recht alle Dateien auf allen NetWorker-Client-Maschinen wiederherzustellen.

• Wie sieht der Start des Wiederherstellungsvorgangs mit dem „recover“-Kommando aus?

Wiederherstellung von Daten des Clients-A auf dem Client-A:

recover -c <client-A> -R <client-A> -i<RYN>

Wiederherstellung von Daten des Clients-A auf dem Client-B:

recover -c <client-A> -R <client-B> -i<RYN>

• Warum funktioniert die Wiederherstellung in den neueren NetWorker Versionen und warum hat sie in älteren Versionen nicht funktioniert?

In allen NetWorker-Versionen wird bei der Initiierung einer Wiederherstellung von einem anderen Rechner (auch Directed-Recover genannt), das eigentliche Recover-Kommando an den Ziel-Rechner gesendet und hier als aktives Kommando gestartet.

Hierbei werden in dem Wiederherstellungsprogramm (egal ob NMC, NetWorker-User oder recover-Kommando) die wiederherzustellenden Dateien ausgewählt ein Zielverzeichnis definiert und bestimmt was passieren soll, wenn die Dateien auf dem Zielsystem bereits existieren. Anschließend wird der so zusammengesetzte „recover-Aufruf“ an das Zielsystem übertragen. Hier findet dann der eigentliche „recover-Aufruf“ statt. Der Vorteil dieses Verfahrens liegt auf der Hand. Die wiederherzustellenden Daten werden so direkt vom Backup-Medium zum Zielmedium transferiert.

In älteren NetWorker-Versionen wurde das zusammengestellte Kommando vom Arbeitsrechner direkt an das Zielsystem gesendet. Hierzu hat eine „normale“ NetWorker-Client Maschine aber kein Recht (nur Maschinen die in der Datei /nsr/res/servers enthalten sind dürfen Kommandos auf dieser NetWorker-Client Maschine starten).

In den aktuellen NetWorker-Versionen wird das generierte Kommando nicht mehr direkt an die Ziel-Maschine gesendet, sondern dies geschieht über den Umweg des NetWorker-Servers. Dieser hat natürlich das nötige Start-Recht und dem Wiederherstellungsvorgang steht nichts mehr im Wege. Die Ausgaben der Wiederherstellung werden beim Recover-Lauf wieder zurück an das aufrufende Programm geliefert.

Beispiel:

Aufruf des Kommandos „recover“ auf der Maschine „sles12nw10“. Auf der Maschine sles12nw09 soll die Datei „/etc/passwd“ wiederhergestellt werden.

sles12nw10:~ # recover -c sles12nw09 -R sles12nw09 -iR

recover> add /etc/passwd

/

/etc

1 file(s) marked for recovery

recover> recover

Initiating remote recover to sles12nw09 from server sles12nw01.networker.qs.de, ...

Recovering 1 file into its original location

Requesting 1 file(s), this may take a while...

Total estimated disk space needed for recover is 4 KB.

Recover start time: Mon Dec  3 16:19:08 2018

Requesting 1 recover session(s) from server.

Successfully established the direct file retrieval session ...

./passwd: File exists, renaming to ./passwd.R

Received 1 file(s) from NSR server `sles12nw01.networker.qs.de'

Recover completion time: Mon Dec  3 16:19:10 2018

FAZIT:

Durch den neu eingeführten Kommunikationsweg, vom Arbeitsrechner des Operateurs zum NetWorker-Server und von hier an den Zielrechner, können jetzt auch frei definierbare NetWorker-Operateure die Wiederherstellung beliebiger Benutzer-Daten durchführen.

Ein lange gewünschte Recover-Eigenschaft ist somit endlich erfüllt!

Sollten Sie zu diesem Artikel oder zum NetWorker allgemein Fragen haben, so wenden sie sich an der Autor oder besuchen sie einen unserer NetWorker Workshops.

NetWorker erhält immer mehr Funktionen, die den Schutz Ihrer Daten vor dem unbefugten Zugriff schützen sollen. So wurde mit der NetWorker Version 18.1 die DataDomain Retention-Lock Funktionalität vollständig integriert. Aus diesem Anlass möchten wir hier die NetWorker-Sicherheits-Funktionalitäten kurz betrachten.

- Zugriff auf die zu sichernden Maschinen

Für alle bekannt sollte der Schutz vor dem unlauteren Backup / Recover von einem anderen NetWorker_Server sein. Hier steht seit langem die „Servers-Datei“ und das Client-Zertifikat als Sicherheitsschutz zur Verfügung.

- Administrations-Zugriff

Der NetWorker-Administrator darf alle Daten eines Clients sichern, aber auch beliebige Dateien auf die Client-Maschinen pushen. Somit hat der Administrator potentiell alle Maschinen die im NetWorker konfiguriert sind im Zugriff und er kann diese Maschinen auch kompromittieren. Entsprechend wichtig ist der sorgfältige Umgang mit der Administrator-Liste. Hier bietet NetWorker nicht nur den Check auf Benutzer-Name und Maschine, sondern es können weitere Attribute, wie z.B. auch das Client-Zertifikat als Kriterium für den Administrations-Zugriff überprüft werden.

- Verschlüsselung auf dem Transportweg

Wenn die zu sichernden Daten auf dem Sicherungsweg durch ein öffentliches Netz (WAN) gesendet werden, sollten diese natürlich nicht im Klartext vom Client zum Datenmedium gesendet werden. Hierfür bietet NetWorker die Möglichkeit zur Verschlüsselung der Daten auf dem Transportwege an. Diese Verschlüsselung gibt es zum einen bei der Sicherung auf DataDomain (im Boost-Protokoll) aber seid NetWorker 9 auch bei der Sicherung auf andere Medien.

- Verschlüsselung auf dem Datenmedium

Die gesicherten Daten müssen u.U. auch auf dem Backup-Medium vor dem Zugriff von Fremden geschützt werden. Dies kann zum Einen auf dem Backup-Medium DataDomain selbst erfolgen, kann aber auch bei der Erzeugung eines Tape-Mediums bei der Sicherung oder auch bei der Erzeugung eines synthetischen Full Backups.

- Schutz des Backup-Mediums vor Sabotage

Immer wichtiger wird auch der Schutz vor Sabotage. Damit kommt zwangsläufig die Frage auf, wie kann ich meine gesicherten Daten auf einem DataDomain System vor einem Saboteur schützen? Mit NetWorker 18.1 und dem DataDomain RetentionLock Feature können Sie sich jetzt auch von diesem Problem verabschieden. Denn durch die Verwendung der DataDomain Retention-Lock Funktion bei der Sicherung, können die Daten auch gegen unbefugtes Löschen, sowohl von Seiten der Backup-Applikation als auch von Seiten des DataDomain Administrators geschützt werden.

FAZIT:

Wie Sie sehen, ist Ihre Datensicherung mit NetWorker in sicheren Händen. Vorausgesetzt Sie kennen die richtigen Schrauben und Attribute und konfigurieren Ihre Backup-Umgebung danach. Sollten Sie bei einem der obigen Punkte Bedarf für eine Beratung sehen, so können wir Ihnen entweder unseren NetWorker Workshop Admin 3 (Advanced) empfehlen, oder Sie buchen den Autor. dieses Blog-Beitrages für eine vor Ort Beratung.

Entgegen der leider schon des öfteren gehörten Aussagen „das geht nicht“, zunächst mal die gute Nachricht es geht! Es geht zwar nicht mit der NetWorker Management Console, aber mit den NetWorker Kommandos „recover“ und „nsrndmp_recover“ geht es sehr gut. Und das sowohl mit der NetWorker Version 8.2.4.x und natürlich auch mit der aktuellen NetWorker Version 9.2.x.

Es gibt jedoch 2 kleine Stolpersteine, die sich aber leicht aus dem Weg räumen lassen ;-)

1. Beim Aufruf der „recover“-Kommandos benötigt man 2 Optionen

-c <7-Mode Client-Name>

-R <C-Mode-Cluster-Name>

Beispiel:

# recover -c na_82 -R na_93

Die erste Option erklärt sich von selbst, aber die zweite muss entgegen dem vielleicht erwarteten SVM-Namen, den Namen des C-Mode-Clusters enthalten. Oder vielleicht besser gesagt den Namen der StorageNode der zu verwendenden NDMP-Devices.

Nach dem Aufruf des Kommandos können die wiederherzustellenden Dateien wie gewohnt ausgewählt werden.

2. Relocate auf einen virtuellen Storage auf der C-Mode Maschine

Für den Relocate der wiederherzustellenden Daten benötigt man einen Pfad aus Sicht des C-Mode Cluster-Servers. D.h. ein Relocate sieht syntaktisch folgendermaßen aus:

> relocate /<SVM-Name>/<Volume-Name>[/<Pfad auf dem Volume>]

Beispiel:

recover> relocate /na_93_cifs/recover/uws

Hierbei ist der Name „na_93_cifs der Name eines virtuellen Storage-Systemes (SVM)

Berücksichtigt man diese beiden Besonderheiten beim Aufruf, bzw. bei der Verwendung des Kommandos, sollte einem Recover von „alten“ NetApp-7-Mode Daten auf eine neue C-Mode Maschine nichts mehr im Wege stehen.

Wenn sie nähere Informationen zum Thema NetWorker und/oder NDMP Backup mit NetWorker benötigen, so scheuen sie sich nicht eine Mail an den Autor zu senden. Oder besuchen sie unseren NetWorker Advanced Workshop.