Data Domain – Wechsel des Retention Lock Modus

Ich hatte schon einige Male die Anfrage, ob man auf der Data Domain den derzeit genutzen Retention Lock Modus ändern kann.

Diese Frage lässt sich leider nicht klar beantworten.
Hat man einmal die Complianc Edition aktiviert, sind die Systemweiten Veränderungen nicht mehr rückgängig zu machen. Sprich für diverse Tätigkeiten wird neben dem DD Administrator auch der Security Administrator benötigt.

In den bisherigen Anfragen, die ich dazu bekommen habe, sollte bisher immer von Governance nach Compliance gewechselt werden.
Da Governance keine DD-weiten Änderungen durchführt, ist das also kein Problem.

Aber der interessantere Teil sind natürlich die Mtrees.
Ein Wechsel des Modus ist hier leider nicht ohne Weiteres möglich – egal ob von Compliance nach Governance oder umgekehrt.
Wer jedoch von Governance nach Compliance wechseln möchte, kann dies über einige Umwege jedoch trotzdem noch erreichen.
Von Compliance gibt es jedoch keinen Weg zurück nach Governance.

Daher gehe ich hier auf die Möglichkeiten ein, um von Governance nach Compliance zu wechseln.

Das Problem: Hat man Governance bereits auf einem Mtree aktiv, wird man das leider nicht mehr los.
Man kann Governance deaktivieren, aber der Befehl „mtree retention lock enable mode compliance mtree <mtree>“ verweigert dann trotzdem den Dienst.

Hier kommt das Fastcopy-Feature der Data Domain ins Spiel. Damit kann man eine Kopie eines Mtrees erstellen.
Dazu legt man mittels „mtree create /data/col1/<mtreename>“ zuerst einen neuen Mtree an.
Und dann kann man mit Hilfe von „filesys fastcopy source /data/col1/<mtree-alt> dest /data/col1/<mtree-neu>“ eine Kopie des bestehenden Mtrees erstellen.
Die Kopie hat jedoch keine Informationen zu Retention Lock, sodass man hier nun auch Compliance auf den neuen Mtree anwenden kann.
Im Anschluss kann der alte Mtree gelöscht werden.

Damit haben wir natürlich nun ein weiteres Problem:
Je nachdem, von was der alte Mtree verwendet wurde, greift sie natürlich auf den alten Pfad zu.
Erfolgt der Zugriff via CIFS oder NFS, kann man den entsprechenden Export so belassen und muss nur den Pfad auf der Data Domain ändern.

Aber was, wenn man den Mtree für eine Backup-Applikation wie NetWorker nutzt?
Damit stehen wir vor dem nächsten Problem, welches sich leider nicht so leicht lösen lässt.
Hier kommt es auf die jeweilige Umgebung an.

Hat man nur wenige Devices im NetWorker (und auch z.B. nur kurze Aufbewahrungszeiten), kann man sich die Mühe mit dem Fastcopy sparen.
Man legt dann einfach einen neuen Mtree an konfiguriert im NetWorker neue Devices, die auf dem neuen Mtree liegen (Siehe dazu hier).
Die neuen Devices kommen in die gleichen Pools wie die alten, sodass man abgesehen von den Devices nicht noch groß die Umgebung verändern muss.
Die alten Devices setzt man auf Read-Only, sodass diese nicht weiter genutzt werden.
Achtung: Wenn die auf Read-Only sind, kann NetWorker darauf auch keine Daten löschen. D.h. man muss abwarten, bis alle Daten darauf expired sind und kann die alten Devices dann löschen.
Für die Zeit wird man jedoch vom NetWorker immer wieder Fehlermeldungen bekommen, dass er die abgelaufenen Backups nicht löschen konnte.

Hat man eine große Umgebung mit vielen Devices, muss man etwas tricksen.
Hierfür erstellt man mittels Fastcopy eine Kopie des alten Mtrees (s.o.). Damit hat man also sämtliche bestehenden Backups auf dem neuen Mtree.
Ab jetzt hat man zwei Möglichkeiten:
1) Man löscht den alten Mtree und startet ein DD Cleaning. Dieses Cleaning muss man leider abwarten, damit der alte Mtree wirklich weg ist. Und ja, währendessen funktionieren natürlich keinerlei Backups, weil die Devices noch alle auf den alten Mtree zeigen.
Sobald das Cleaning durch ist, nutzt man den Fastcopy wieder, um die Daten zurück zu kopieren und hat sie damit an der alten Stelle, jedoch ohne Retention Lock. Und nun kann man den gewünschten Retention Lock Modus aktivieren.
2) Man legt alle Devices neu an (auch wieder mit dieser Anleitung), sodass sie auf den neuen Mtree zeigen. Das ist natürlich eine ganze Menge Arbeit…
Hat man das erledigt, kann man die ganzen alten Devices und auch den alten Mtree löschen.

Alternativ gäbe es noch eine Mischung aus beidem. Man könnte z.B. nur einige Devices neu anlegen, um während des Cleanings Archive Log Backups durchführen zu können.

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

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

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

Data Domain – Login zur Bash

Manchmal braucht man doch ein bisschen mehr als was die Data Domain Shell zur Verfügung stellt. Z.B. einen traceroute über ein bestimmtes Interface. Die normale Data Domain Shell und die SE Shell bieten teilweise nicht die volle Funktionalität der Linux-Kommandos. Aber zumindest bei älteren DDOS-Versionen (bis DDOS 6) gibt es eine Möglichkeit, direkt an die Bash zu kommen.
Weiterlesen

Data Domain Weboberfläche neu starten – vProxy VMDKs verbleiben an Ziel-VM nach FLR

Vielleicht hat der eine oder andere das schonmal gehabt: Man geht wie gewohnt auf die Weboberfläche seiner Data Domain, doch statt dem gewohnten Login-Screen wird man von der Meldung „Service Not Available“ begrüßt. Oder man ist gerade auf der Konsole unterwegs und sieht plötzlich die Meldung „ddr_procmon: ALERT: MSG-PMON-00012: Cannot restart /ddr/bin/sm_em. Setting state to FAILED.“.

Weiterlesen

Data Domain System Management Service (SMS) funktioniert nicht mehr

Bei älteren DDOS Versionen (z.B. 5.5 – 5.7) kann es vorkommen, dass sich der SM Service aufhängt. Zum Glück hat dies im Normalfall wenig Auswirkungen auf Backups. Aber die Benutzbarkeit der Data Domain an sich ist beeinträchtigt und auch SNMP funktioniert ggf. nicht mehr. Z.B. kann auch die Web-Gui nicht mehr funktionieren oder alle Befehle auf der Kommandozeile werfen Fehlermeldungen. Weiterlesen

NetWorker Clients aus dem Software Inventory entfernen

NetWorker bringt eine Möglichkeit zur halb-automatisierten Verteilung von Software mit sich. Darüber kann man Updates der Software auf Clients ausrollen und muss sich dort nicht selber einloggen.
Damit man eine Übersicht darüber hat, welche NetWorker Version, bzw. welche Module man wo installiert hat, gibt es in der NMC den Reiter „Software Inventory“. Doch wenn man einen Client löscht (z.B. weil er dekommissioniert worden ist), verschwindet er leider nicht aus dem Software Inventory. Und die NMC bietet auch leider keine Möglichkeit, nicht mehr existierende Clients aus der Liste zu entfernen. Was also tun? Weiterlesen

Wie löscht man Backups im NetWorker? – Teil 2

Im vorherigen Beitrag bin ich darauf eingegangen, wie man Backups ohne große Umschweife löschen kann, was jedoch den Nachteil hat, dass der Dell EMC NetWorker hier keinerlei Kontrollen durchführt, ob das Backup vielleicht noch benötigt wird. Daher stelle ich in diesem Beitrag nun die zweite Methode – Manipulation der Aufbewahrungszeiten – vor. Weiterlesen

Wie löscht man Backups im NetWorker? – Teil 1

Nachdem ich in den letzten Beiträgen darauf eingegangen bin, wie man (unerwünschte) Backups findet, stellt sich nun natürlich die große Frage, wie man diese denn jetzt los wird.
Dafür gibt es mehrere Methoden, welche man auf der Kommandozeile und mit der NetWorker Management Console (NMC) nutzen kann.
Weiterlesen