NetWorker 18.x bietet neue Funktionen und Verbesserungen in verschiedenen Bereichen wie Virtualisierung, Backup Klonen, Vereinfachte Lizenzierung, Cloud Backup etc.
Die neueste NetWorker Version ist 18.2.0.1
Diese NetWorker Version wurde im März 2019 veröffentlicht.
Wir wurden gefragt, ob wir nicht einmal etwas zur Sicherung von MSSQL mit NetWorker schreiben können.
Da die NetWorker Dokumentation und der Compatibility Guide schon sehr aussagekräftig sind und beschreiben, wie man das Backup einrichtet, möchten wir an dieser Stelle unsere Empfehlungen und eine Übersicht der Möglichkeiten bereitstellen.
NetWorker und MSSQL sich eine ziemlich gute Kombination. Es werden alle MSSQL Konstellationen unterstützt, egal ob Single-Node, schwenkbarer Cluster oder AAG.
Über den NMC Wizard kann man mit wenigen Klicks einen kompletten Cluster ins Backup aufnehmen, da NetWorker sich mit dem Cluster unterhält und erkennt, was dieser für Ressourcen (z.B. AAGs) hat. Es ist möglich, auch nur ausgewählte Datenbanken oder Instanzen zu sichern, bzw. Datenbanken zu exkludieren. Neue Datenbanken in einer Instanz werden automatisch erkannt und gesichert, sofern man die komplette Instanz ins Backup aufgenommen hat. Hat man nur einzelne Datenbanken aufgenommen, funktioniert dieser Automatismus natürlich nicht.
All diese Dinge können natürlich auch restored werden. Bei NetWorker Versionen unter 19 gibt es dazu zwei Möglichkeiten:
1) Der NetWorker User for SQL Server. Dieser wird automatisch mitinstalliert und bietet Features wie z.B. Restores von mehreren Datenbanken auf einen anderen Server. Allerdings unterstützt das Tool keine AAGs.
2) Das SQL Server Managament Studio (SSMS) Plugin. Dieses kann optional (bzw. unsere Empfehlung: Immer mitinstallieren) bei der Installation ausgewählt werden und unterstützt auch AAGs. Allerdings kann man, wenn man Datenbanken von einem anderen Server restoren möchte, nur jeweils eine Datenbank restoren. Wenn man mehrere Datenbanken vom aktuellen Server restoren möchte, geht dies jedoch.
Mit NetWorker 19 wurde der NetWorker User for SQL abgeschafft. D.h. hier gibt es nur noch das SSMS Plugin mit den oben genannten Vor- und Nachteilen.
Mit beiden Tools kann man Ad-hoc Backups durchführen, sodass z.B. auch der DBA Backups erstellen kann, falls er gerade eines braucht.
Mit dem Nachteil beim SSMS Plugin mit dem Restore von mehreren Datenbanken muss man leider leben, es sei denn, dass Dell EMC hier noch etwas ändert. Es gibt jedoch die Möglichkeit, Restores auch auf der Kommandozeile zu starten. Hier könnte man sich z.B. Batch-Dateien erstellen, die nacheinander, oder wenn man mehrere Dateien gleichzeitig startet, auch gleichzeitig Restores durchführt.
Bei MSSQL gibt es drei, bzw. vier verschiedene Backup Level. Im Gegensatz zu anderen Datenbanken (z.B. Oracle) hat NetWorker hier auch die Hoheit über die Backup Level und erkennt aufeinander aufbauende Backups, sodass ein Full Backup, dessen Aufbewahrungszeit abgelaufen ist, auch erst gelöscht wird, wenn alle darauf aufbauenden Backups ebenfalls abgelaufen sind.
Folgende Backup Level werden unterstützt:
Full – Recht eindeutig 🙂
Level 1 (auch Differential oder Cumulative Incremental genannt) – Sichert die Änderungen zum letzten Full Backup
Incremental – Sichert die Transaction Logs und schneidet sie ab.
Logs Only – Im NetWorker auch txnlog genannt. Sichert ebenfalls die Transaction Logs und schneidet diese ab. Ob man Incremental oder Logs Only nimmt, ist egal.
Man kann die gleiche Client Ressource verwenden und sie in unterschiedliche Gruppen stecken, z.B. um in einer Gruppe Full & Diff Backups zu machen und mit einer anderen Gruppe dann die Transaction Logs zu sichern. Dies ist auch unsere Empfehlung. Je nach Bedarf kann man die Client Ressource kopieren. Z.B. wenn man unterschiedliche SLA-Anforderungen für einzelne Datenbanken hat und bestimmte Datenbanken öfters sichern möchte.
In den Application Information der Client Ressource kann man mit Parametern einige Dinge beeinflussen. Der Wizard fragt diese ebenfalls ab.
In der Dokumentation gibt es für alle Parameter auch eine Beschreibung.
Diese drei Parameter sollten unserer Meinung nach auf die folgenden Werte gesetzt werden:
NSR_SKIP_SIMPLE_DB=TRUE
Wenn sich eine Datenbank im Simple Recovery Model befindet, schreibt sie keine Transaction Logs. Steht dieser Parameter auf False, bedeutet dies, dass der NetWorker bei einem Transaction Log Backup stattdessen ein Full Backup durchführt. Das will man im Normalfall aber nicht. Der Parameter gilt ausschließlich für die Backup Level incr und logs only.
NSR_SKIP_LOGGAP_DETECTION=FALSE
Wenn aus irgendeinem eine Lücke in den Transaction Logs ist (z.B. weil diese mit einem anderen Backup Tool gesichert worden sind oder weil der DBA diese abgeschnitten hat), führt dies dazu, dass eine Datenbank nicht mehr über die Transaction Logs zu einem beliebigen Zeitpunkt restored werden kann, bzw. nur noch bis zum Anfang der Lücke. Steht dieser Parameter auf TRUE, macht NetWorker trotzdem ein Backup und ignoriert die Lücke. Unsere Empfehlung ist hier FALSE. In dem Fall beendet sich das Backup mit einem Fehler, sodass man über dieses Problem unterrichtet wird und klären kann, wo das herkommt.
NSR_SKIP_NON_BACKUPABLE_STATE_DB=TRUE
Datenbanken können sich in einem Modus befinden, in dem sie nicht gesichert werden können. Z.B. können sie offline sein oder es kann gerade ein Restore laufen. Setzt man diesen Parameter auf TRUE, versucht NetWorker nicht, die betroffenen Datenbanken zu sichern. Im Normalfall gibt es ja einen Grund dafür, dass sie sich in diesem Status befinden, daher kann NetWorker diese Datenbanken unserer Meinung nach ruhig überspringen. Möchte man doch über solche Vorkommnisse unterrichtet werden, setzt man ihn auf FALSE.
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.
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. 🙂
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.
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
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
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
Es gibt leider hin und wieder Probleme 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
Ü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
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