NetWorker mit Data Domain Retention Lock

In meinem vorherigen Beitrag bin ich auf die Eigenschaften von Retention Lock eingegangen.
Nun kommen wir zum praktischen Teil: Die Einbindung in NetWorker.

Ich gehe einmal davon aus, dass bereits mit NetWorker gesichert wird. Dementsprechend gibt es auf der Data Domain auch bereits einen Mtree für den NetWorker Server. Im Normalfall heißt der wie der NetWorker Server.
In meinem Fall heißt mein NetWorker Test-Server ddp-e01-vst-139.
Und der dazu passende Mtree auf der Data Domain /data/col1/ddp-e01-vst-139

Retention Lock kann man entweder über die Data Domain WebGUI aktivieren (Data Management -> Mtree -> Dort den gewünschten Mtree selektieren und nach unten scrollen. Ganz unten rechts steht DD Extended Retention Lock. Dort auf Edit und Enable) oder aber über die Kommandozeile mit dem Befehl „mtree retention lock enable mode {compliance | governance} mtree  <mtree-path>“.

Da ich die Governance Edition nutze, heißt der Befehl bei mir also:
mtree retention lock enable mode governance mtree /data/col1/ddp-e01-vst-139
Wenn man möchte, kann man nun (entweder über die GUI oder über die Kommandozeile mit „mtree retention-lock set {min-retention-period | max-retention-period} <period> mtree <mtree-path>“) noch die min & max Retention-Zeiten anpassen. Achtung: Bei Compliance lässt sich die Max-Zeit nicht verringern. D.h. hier hat man immer mindestens die Default-Zeit.
Und das war es auch schon auf der Data Domain. Abgesehen davon, dass man nun Retention Lock aktiviert hat, hat sich nichts getan. Die bereits geschriebenen Backups werden nicht verändert und auch zukünftige Backups sind von der Änderung erst einmal nicht betroffen.

Hier einmal eine Ansicht von der Kommandozeile nach erfolgter Aktivierung:

sysadmin@xxx# mtree list /data/col1/ddp-e01-vst-139
Name Pre-Comp (GiB) Status 
-------------------------- -------------- -------
/data/col1/ddp-e01-vst-139 306.3 RW/RLGE
-------------------------- -------------- -------
D : Deleted 
Q : Quota Defined
RO : Read Only
RW : Read Write
RD : Replication Destination
RLGE : Retention-Lock Governance Enabled
RLGD : Retention-Lock Governance Disabled
RLCE : Retention-Lock Compliance Enabled
sysadmin@xxx# mtree retention-lock show min-retention-period mtree /data/col1/ddp-e01-vst-139
Retention-lock min-retention-period of mtree /data/col1/ddp-e01-vst-139 is: 720 minutes.
sysadmin@xxx# mtree retention-lock show max-retention-period mtree /data/col1/ddp-e01-vst-139
Retention-lock max-retention-period of mtree /data/col1/ddp-e01-vst-139 is: 1827 days.
sysadmin@xxx#

Retention Lock Governance ist aktiv, die minimale Aufbewahrungszeit liegt bei 720 Minuten und die maximale Aufbewahrungszeit bei 1827 Tagen. Dabei handelt es sich um die Default-Werte.

Damit sich jetzt auch tatsächlich etwas ändert, müssen wir NetWorker mitteilen, dass wir Retention Lock aktiviert haben und dass er es nutzen soll.
Dafür benötigen wir als erstes ein entsprechendes DDBoost-Device. Hier kann man ein neues Device wie gewohnt über den New Device Wizard erstellen. Der Wizard fragt irgendwann, ob man Retention-Lock aktivieren möchte. Dort wählt man dann den entsprechenden Modus (Governance oder Compliance) aus und fährt ansonsten wie gewohnt fort. Wenn man Retention-Lock nur für ausgewählte Backups aktivieren möchte, sollte man dabei auch einen neuen Pool für diese Backups erstellen.
Alternativ kann man aber auch ein bestehendes Device benutzen und dort Retention Lock nachträglich aktivieren.
Ggf. muss man dafür den Diagnostic Mode in der NMC aktivieren (View -> Diagnostic Mode).
Nach einem Doppelklick auf das entsprechende Device wechselt man in den Reiter Configuration und findet rechts unten ein Kästchen für Retention-Lock.

DD Retention Lock Mode ändert man von None in den gewünschten Modus, also bei mir in Governance.
Damit wäre Schritt 2 erledigt und wir hätten nun ein passendes Device. Aber auch jetzt passiert tatsächlich noch nichts mit ggf. auf dem Device vorhandenen, bzw. zukünftigten Backups.

In Schritt 3 geht es nun damit weiter, dass wir dem NetWorker mitteilen, Retention Lock aktiv zu nutzen.
Hierfür gehen wir unter Protection zu den Policies. Hier können wir entweder einen neuen Workflow erstellen oder einen vorhandenen abändern. Retention-Lock wird in der jeweiligen Action (z.B. Backup- oder Clone-Action) aktiviert.

Bei einem Clone geschieht dies beim Punkt „Specifiy the Clone Options“.

Dort setzt man das Häkchen bei „Apply DD Retention Lock“ und wählt die gewünschte Aufbewahrungszeit aus. Diese kann von der normalen Aufbewahrungszeit abweichen, jedoch logischerweise nicht größer sein. NetWorker weist einen darauf hin, wenn man es trotzdem versucht.

Bei einer Backup-Action funktioniert es genauso, nur eben bei „Specify the Backup Options“.
In meinem Fall habe ich einen eigenen Pool für Retention Lock Backups namens RTBackup erstellt und diesen ausgewählt. Und ich hätte gerne, dass die Backups für ein Jahr aufbewahrt werden und solange auch durch Retention Lock geschützt werden sollen. Auch hier kann die Retention Lock Aufbewahrungszeit nicht höher als die generelle Aufbewahrungszeit sein.

Herzlichen Glückwunsch! Damit ist Retention Lock jetzt aktiv.

Wer dies einmal testen möchte, kann z.B. versuchen, ein solches Backup mal zu löschen. Auf der Kommandozeile z.B: mit „nsrmm -d -y -S <ssid>“
NetWorker verweigert den Befehl und weist einen darauf hin, dass das Backup geschützt ist.
Ich habe sämtliche mir bekannten Wege (einschließlich Löschen des ganzen Devices) probiert, aber keine Möglichkeit gefunden, mit NetWorker ein solches Saveset zu löschen. Alle Versuche wurden verweigert. Nun, so soll es ja schließlich auch sein. 🙂

Einrichtung Backup SharePoint 2013 mit NetWorker 18.2

Da ich kürzlich einmal wieder das ‚Vergnügen‘ hatte, Backup für eine SharePoint 2013 Farm einzurichten, habe ich dieses Mal ein paar Notizen entsprechend aufbereitet, um sie veröffentlichen zu können.
Der NetWorker Module for Microsoft Guide für SharePoint verschweigt leider die Hälfte der Einrichtung… Und auch der Einrichtungs-Wizard in der NMC könnte durchaus einen besseren Job machen.
Weiterlesen

NetWorker löscht Daten nicht von Volumes, von denen er gerade liest

Insbesondere bei großen Umgebungen, in denen auch noch viel geklont wird, kann es passieren, dass der Dell EMC NetWorker Backups zwar während seines nsrim-Laufes (wird während der Expiration-Action ausgeführt) Backups als abgelaufen markiert, diese dann aber nicht gelöscht werden. Der Grund dafür ist, dass NetWorker standardmäßig auf einem Volume (z.B. ein DDBoost-Volume) keine Daten löscht, während davon gelesen wird.
In größeren Umgebungen kann es jedoch passieren, dass von Volumes immer gelesen wird, während der nsrim läuft. Und damit werden dort auch niemals abgelaufene Backups gelöscht und somit auch der Platz nicht freigegeben.
Weiterlesen

Weitere Probleme mit vProxy FLR bei VMs

Über die letzten Wochen sind mir noch diverse weitere Probleme aufgefallen, denen man über den Weg laufen kann, wenn man es mit Windows-VMs zu tun hat.
Weiterlesen

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.
Weiterlesen

NetWorker vProxy File-Level-Recovery

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.
Weiterlesen

DD ifgroups nutzen bei NetWorker CCR nur ein Interface

Wer das Clone-Controlled-Replication (CCR) Feature vom Dell EMC NetWorker mit der Dell EMC Data Domain nutzt, wird unter Umständen feststellen, dass die Data Domains ihre Replikation nur über ein Interface untereinander durchführen, obwohl man dafür eine DDBoost ifgroup mit mehr als einem Interface konfiguriert hat.
Weiterlesen

Was genau macht ein NetWorker Instant Access Restore?

Ich möchte in diesem Beitrag (auch als Vorbereitung für einige folgende Beiträge) einmal auf den Instant Access Restore mit dem Dell EMC NetWorker eingehen. Vom Prinzip her funktionier dieser aber bei allen Backups Tools, welche auf Data Domain aufbauen, ähnlich. Also beim NetWorker gibt es hier z.B. zwischen VBA und vProxy keinen großen Unterschied und auch ein Veeam arbeitet genau so.
Weiterlesen

Shell-Skript zur Suche von Dateien in NetWorker

Die meisten Dell EMC NetWorker Admins werden wohl den ‚typischen‘ Restore kennen. Häufig handelt es sich bei der Anforderung um einen Enduser, welcher eine Datei oder ein Verzeichnis nicht mehr findet. Das gesuchte Objekt wurde letzte Woche zuletzt gesehen, glaubt man. Kann aber auch schon einen Monat her sein. Den genauen Pfad kennt man auch nicht mehr so genau und auch den exakten Dateinamen weiß man ebenfalls nicht, höchstens noch Bestandteile davon. Achja, und super-dringend ist es natürlich auch, weil in einer Stunde der Wirtschaftsprüfer kommt.
Die Suche im NetWorker hat (zumindest bei mir) kaum jemals irgendetwas gefunden. Und das DP Search (Dell EMC Data Protection Search) Tool haben auch nicht all zu viele Leute im Einsatz.
Deswegen habe ich mir vor Ewigkeiten (noch zu NW 7 Zeiten, da gabs weder die Suchfunktion in der NMC, noch DP Search) ein Shell-Skript geschrieben, welches mir immer wieder gute Dienste geleistet hat.
Weiterlesen

NetWorker Installation schlägt mit ‚Invalid digital signature‘ fehl – Windows 2008 R2

Wenn man NetWorker 9.1 oder höher auf einem Windows 2008 R2 Server (ohne Internetzugriff) installieren möchte, kann es passieren, dass die Installation relativ schnell abbricht. Der Fehler weist daraufhin, dass es Probleme mit der digitalen Signatur gibt und dass die Installationsdatei möglicherweise korrupt ist. Letzteres kann natürlich immer mal passieren, aber ist hier im Fall eher nicht der Fall.
Weiterlesen