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

Data Domain Retention Lock

Die Data Domain verfügt über das sogenannte Retention Lock Feature, für das jedoch ggf. eine zusätzliche Lizenz erworben werden muss.
Gerade in der heutigen Zeit, in denen Ransomware-Attacken (leider) fast an der Tagesordnung sind und mittlerweile zusätzlich manchmal noch durch Insider unterstützt werden, die z.B. Backups löschen, ist dies ein wichtiges Feature, welches allerdings nur relativ wenig Beachtung erhält.

Kurz gesagt sorgt Retention Lock dafür, dass Daten, die auf die Data Domain geschrieben werden, nicht vor Ablauf einer gewissen Aufbewahrungszeit gelöscht werden können.
Wenn man nun z.B. in der Backup-Applikation NetWorker aus Versehen (oder vielleicht auch absichtlich) ein Backup löschen möchte, bekommt man eine entsprechende Fehlermeldung präsentiert, die einem sagt, dass die Aufbewahrungszeit nicht erreicht ist und man das Backup daher nicht löschen kann.
Retention Lock wird auf der Data Domain auf Mtree-Ebene aktiviert, d.h. man kann Mtrees mit Retention Lock haben und gleichzeitig auch andere Mtrees ohne. Man kann auch Mtrees mit unterschiedlichen Retention Lock Editionen (zu den Editionen später mehr) haben.
Die Applikation, die die Daten auf die Data Domain schreibt, gibt dann für jede Datei die entsprechende Aufbewahrungszeit mit.
Auf der Data Domain kann man für jeden Retention Lock Mtree eine minimale und eine maximale Aufbewahrungszeit einstellen. D.h. die Applikation erhält dann auch eine entsprechende Fehlermeldung von der Data Domain, wenn sie sich außerhalb dieser Zeiten bewegt. Durch eine Begrenzung der maximalen Aufbewahrungsdauer kann man z.B. verhindern, dass man Daten versehentlich länger als eigentlich gewünscht speichern kann. Z.B. wenn man weiß, dass man keine Daten länger als ein Jahr aufbewahren möchte, kann man dies so einstellen. Damit wird verhindert, dass man versehentlich Daten für einen längeren Zeitraum speichert. Die möglichen Aufbewahrungszeiten können jedoch auch später noch angepasst werden.

Diverse Backup- & Archivierungsprogramme unterstützen dieses Feature.
Beispielsweise kann man einen CIFS-Share von der Data Domain an die Mail-Archivierungslösung Enterprise Vault exportieren. Der CIFS-Share liegt auf der Data Domain auf einem Mtree mit Retention Lock. Enterprise Vault unterstützt Retention Lock und kann daher die Aufbewahrungszeit mitgeben.
Wie bereits oben erwähnt unterstützten auch die Dell EMC Backup-Produkte wie z.B. NetWorker Retention Lock.

Ich werde auf die Einbindung in NetWorker in einem späteren Beitrag näher eingehen.

Von Retention Lock gibt es zwei Editionen – Governance und Compliance.
Der Hauptunterschied besteht darin, dass ein Data Domain Admin die Governance Edition auch wieder deaktivieren kann. Sprich der Schutz beruht darauf, dass die Data Domain nicht kompromittiert wurde, bzw. dass der DD Admin hier nicht das schwarze Schaf ist. Aber die Governance Edition verhindert z.B. das Löschen von Backups mit Hilfe der Backup Applikation oder bei Enterprise Vault den Löschvorgang auf dem CIFS-Share.

Für die Compliance Edition muss man zwingend noch ein Benutzerkonto für einen Security Admin anlegen. Sobald man die Compliance Edition aktiviert, wird bei diversen Tätigkeiten auf der Data Domain dann auch der Security Admin benötigt, bei welchem es sich im Idealfall um eine andere Person als den normale DD Admin handel.
Alle Tätigkeiten, die in irgendeiner Weise die Integrität der Daten gefährden könnten, wie z.B. Änderung der Zeiteinstellungen, erfordern beide Admins. Zudem können danach solche Tätigkeiten nur noch auf der Kommandozeile erledigt werden.
Aber auch diese beiden zusammen können einmal geschriebene Daten auf der Data Domain nicht entfernen. Wurde die Aufbewahrungszeit einmal gesetzt, bleibt die Dateien da, bis diese Zeit abgelaufen ist.
Wichtig bei der Compliance Edition ist noch, dass man die maximale Aufbewahrungsdauer nur erhöhen, nicht verringern kann, selbst wenn es keine Daten gibt, deren Aufbewahrungszeit länger als das neue Maximum ist.

Für welche Edition man sich entscheidet, hängt von mehreren Faktoren ab.
Die Compliance Edition ist ohne Frage sicherer, birgt aber auf der anderen Seite Risiken.
Vielleicht wollte man bei einem jährlichen Backup Job einstellen, dass das Backup für 12 Monate aufbewahrt wird, hat sich dabei aber verklickt und versehentlich (und unbemerkt) 12 Jahre ausgewählt. Dann bleiben die Daten auch 12 Jahre da.

Es kommt auch hin und wieder vor, dass man z.B. ein größeres Datenwachstum als gedacht hat und die Data Domain vollzulaufen droht. Und dann ist vielleicht auch gerade kein Budget für eine Erweiterung da. Was macht man häufig in diesem Fall? Richtig, die Aufbewahrungszeit von Backups verringern und alte Backups löschen.
Ersteres kann man natürlich nach wie vor tun, doch gewinnt man damit erst in Wochen oder gar Monaten Speicherplatz, bis die alten Backups von alleine ablaufen. Ate Backups kann man bei der Compliance Edition eben nicht löschen, sodass man hier nicht kurzfristig für Platz sorgen kann. Dann steht man vor der Entscheidung, doch noch irgendwo Geld für die Erweiterung aufzutreiben oder auf Backups zu verzichten.

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

Backup von Windows 2008 R2/Windows 2012 Servern mit Visual Studio 2012 oder MS .net

Dies mag vielleicht eine ewas besondere Konstellation sein, aber meistens sind es genau diese, über die man irgendwann stolpert und die einem dann jede Menge Kopfzerbrechen bereiten.
Und eine solche Konstellation ist es, wenn man einen Server hat, auf dem Microsoft Visual Studio 2012 installiert ist.
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

Fehlgeschlagenen vProxy FLR aufräumen

Es gibt leider hin und wieder mit File Level Restores, sodass der Dell EMC NetWorker nicht in der Lage ist, korrekt aufzuräumen. Die Folgen sind vielfältig, angefangen damit, dass für die Ziel-VM keine Backups oder Restores mehr funktionieren, bis hin zu der Tatsache, dass die Data Domain den NFS Share mit den Daten weiter bereitstellen muss, auch wenn die Backups vielleicht schon abgelaufen sind.
Dann wird es Zeit, selbst Hand anzulegen und manuell aufzuräumen.
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

Fallstricke beim vProxy FLR

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