DELL/EMC hat mit seinem neuen Datensicherungsprodukt „PowerProtect Data Manager“ (PPDM) ein unschlagbares Sicherungsprogramm für VMware Image Sicherungen im Portfolio. Dieses auf Transparent Snapshots basierende Sicherungsverfahren benötigt keine virtuellen Maschinen als Backup-Proxies mehr, sondern lagert die Sicherungsarbeit auf die physikalischen ESXi Maschinen aus. Die Sicherungen der virtuellen Maschinen werden so schneller, benötigen weniger System-Ressourcen und die sonst nötige Pflege der Proxy-Server entfällt auch noch.

Leider fehlt dem Produkt PPDM jedoch die Möglichkeit die PPDM-Sicherungen auf Bänder zu duplizieren. Genau diese Tape-Auslagerung wird aber durch die immer häufiger vorkommenden Ransomeware Attacken und/oder gesetzlichen Vorgaben von einigen Kunden gewünscht.

Im vorliegenden Projekt hat der Kunde parallel zur neuen PPDM Umgebung eine bestehende NetWorker-Backup-Umgebung mit StorageNodes und einer Tape-Library. Der Wunsch war die PPDM-Sicherungen einmal pro Monat mit Hilfe von NetWorker auf Band zu sichern und diese Sicherungen dort für 1 Jahr aufzuheben. Hierbei sollten für alle mit PPDM gesicherten virtuellen Maschinen, die erste Sicherung des jeweiligen Monats auf Band dupliziert werden.

Sowohl NetWorker, als auch PPDM sichern bei dem Kunden auf das DELL/EMC Backup-Storage-System DataDomain. Was lag also näher, als die von PPDM erzeugten DataDomain Sicherungen mit Hilfe von NetWorker-StorageNodes von dem DataDomain System zu lesen und auf Tape zu sichern.

Bei der PPDM Sicherung werden die Sicherungen der virtuellen Maschinen auf dem DataDomain-Filesystem als jeweils eigenes Verzeichnis mit allen VMware spezifischen Dateien abgelegt. Sichert man ein solches Verzeichnis, hat man demzufolge einen kompletten Stand der virtuellen Maschine, der im Recover-Fall vom Band in einen VMware-Datastore eingespielt werden kann.

Die Idee war geboren; was fehlte, war „lediglich“ noch die Umsetzung einiger Voraussetzungen und die Erstellung von Python Modulen und Skripten.

Basierend auf den REST-API Schnittstellen des PPDM-Servers und des NetWorker-Servers wurden 3 Programme erstellt, die die PPDM Sicherungen analysieren, die PPDM Sicherung auf Band befördern und eine NetWorker-Band-Sicherung für Recovery Zwecke auf einer DataDomain wiederherstellen.

• ppdm_find_backup.py

  • Python-Skript, das:

    • für alle VMware Sicherungen des PPDM-Servers in einem definierten MTREE, die zugehörigen Sicherungen eines definierbaren Tages sammelt und die gewonnenen Informationen für die zukünftigen Sicherungen in einer Python-Pickle Datei ablegt.

    • alle gefundenen virtuellen Maschinen als SaveSet Namen in definierten NetWorker Clients hinterlegt. Die Clients sind in dem Falle die NetWorker StorageNodes.

Dieses Skript läuft einmal monatlich vor den NetWorker Sicherungen und wird mit Hilfe eines definierten Cron-Jobs auf dem NetWorker-Server gestartet.

• nsr_ppdm2tape.py <vm-name>

  • Python-Skript, das als NetWorker Backup-Command für die Sicherung einer übergebenen virtuellen Maschine sorgt. Das Vorgehen ist wie folgt:

    • Eventuelles mounten des DataDomain Filesystems.

    • Auslesen der backup Information aus der oben definierten Pickle-Datei.

    • Starten einer NetWorker Band-Sicherung einer virtuellen Maschine.

    • Eventuelles unmounten des DataDomain Mtrees.

• ppdm_recover.py <vm-name>

  • Python-Skript, das eine NetWorker Sicherung auf einen definierten DataDomain Mtree wiederherstellt. Der gesicherte Stand der Maschine wird in einem eigenen Unterverzeichnis im Recover-Mtree abgelegt. Folgende Schritte werden hierbei durchgeführt:

    • Interaktive Auswahl des gewünschten Sicherungsstandes

    • Mount des DataDomain Recover-Mtrees

    • Wiederherstellung der virtuellen Maschine mit Hilfe des NetWorker „recover“ Kommandos.

    • Unmount des DD-Mtrees

Das hier beschriebene Konzept ist natürlich nur eine grobe Beschreibung der Funktionalität. Es fehlen die Konfigurationsschritte und Voraussetzungen auf der DataDomain und im NetWorker. Außerdem fehlt die Installationsbeschreibung der Python-Skripte auf den beteiligten Maschinen. Natürlich fehlt auch das weitere Vorgehen beim Verlauf eines Recover von Tape in eine laufende virtuelle Maschine. Aber all das würde über das Ziel dieses Blogs hinausgehen. Ich wollte Ihnen nur eine Idee für das in der Einleitung beschriebene Problem aufzeigen. Sollten Sie an diesem Projekt näher interessiert sein, so melden Sie sich bitte per E-Mail an den Autor.

Eine gute Datensicherung war noch nie so wichtig wie heute.

Es vergeht gefühlt kein Tag an dem nicht eine neue Malware oder Ransomware Attacke in den Nachrichten oder Zeitungen (z.B. heute 31.01.2023 ein ganzseitiger Artikel in der SZ) erscheint, in dem ein neuer Angriff thematisiert wird. Ein absoluter Schutz gegen diese Plage scheint nicht möglich. Umso wichtiger ist eine gute und sichere Datensicherung, damit man im Fall der Fälle die  verschlüsselten Daten schnell wieder herstellen kann. ABER: nach aktuellem Stand der Dinge ist das erste Angriffsziel der Hacker eben die Datensicherung. Denn wenn diese erst mal ausgeschaltet werden kann, ist der Angegriffene machtlos und muss wohl oder übel bezahlen.

Aus diesem Grunde sollte die Sicherheit der eigenen Datensicherungsumgebung eines der wichtigsten Themen in Ihrer  IT sein. Aber natürlich muss der Backup-Administrator zunächst mal wissen, wie man die Datensicherung vor unbefugtem Zugriff und vor allem vor vorzeitigem Löschen oder Verändern schützen kann.

Diese Herausforderung ist mittlerweile eines der wichtigsten Themen in meinem „NetWorker Advanced“. Hier ein kurzer Abriss der im NetWorker und der DataDomain eingebauten Schutzmechanismen.

Kommunikation zwischen Backup-Server und Backup-Client

Verwendung von generischen NetWorker Eigenschaften:

• Servers Datei
• Client Zertifikate
• Verschlüsselung der Datenkommunikation
  • Das ist auch ohne DataDomain möglich

• Einsatz des NetWorker Tunnel Moduls
  • nsr-tunnel : sichere Kommunikation vom NetWorker Server zu Clients in einer DMZ

Verwendung von Sicherheitsfeature der DataDomain Systeme

Boost Protokoll (Bandwidth Optimized Open Storage Protokoll)

Beim Boost Protokoll handelt es sich um ein properitäres Format, das von Viren nicht erkannt wird. Die folgenden Eigenschaften machen dieses Protokoll noch sicherer:

 

• Einsatz eines PEM-Zertifikats für das Boost-Protokoll
• Verschlüsselung des Datenstroms zwischen Client und der DD
  • Medium : AES128-SHA1
  • High : AES256-SHA1

 

Sicherheits-Konfigurationen im NetWorker

• Rollen basierte Definition der NetWorker Adminstratoren
  • Sichere Benutzer Definitionen
    • user,host, …, instname

• Bestmöglicher Einsatz von Tape als Sicherungsmedium
  • WORM
    • Verschlüsselung
      • per NetWorker ASM Funktion
      • Als Tape Funktion

• Einrichten von bestmöglichen Auditierungseinstellungen
  • Security-Audit Logs
  • Data-Audit-Logs

Sicherheits-Konfigurationen auf den DataDomain-Systemen

Verwendung einer DataDomain als sichere Datenablage:

• Einsatz der DataDomain RetentionLock Funktionalität (zeitlich beschränkte WORM Funktionalität)
• Es existieren zwei Modi:
  • Governance Mod:
    • auf MTREE Ebene aktivierbar
    • Schutz der gesicherten Daten auf der Protokoll Ebene
      • CIFS
      • NFS
      • Boost
    • Rentention-Zeiten können vom DD-Admin geändert werden.
      Allerdings nur auf Datei Ebene
  • Das Ergebnis
    • Die Backup-Daten sind vor Ablauf der Retention-Lock Zeit von der Backup-Applikation und dem Backup-Admin nicht mehr veränderbar
  • Compliance Mode:
    • Besonderheiten:
      • Kann nur für das ganze System gesetzt werden
      • benötigt einen Security Officer
      • …
    • Das Ergebnis:
      • keine auf der DD befindliche Datei kann mehr verändert werden
        Auch nicht vom DELL-Support

Einsatz weiterer Sicherheitsmechanismen der DataDomain Systeme

• Verschlüsselung der Daten auf der DataDomain
  • Unter Verwendung eines Key-Managers
• Duplizierung der Daten auf eine zweite DataDomain, mittels
  • ClonedControlReplication (CCR)
  • MTREE Replication

Einsatz weiterer DataDomain Features zum Erhöhen der Sicherheit

• Login Features
  • Unterstützung von LDAPS und AD mit SSL/TLS
  • Verwendung von DataDomain Benutzer Rollen
    • Boost User ohne Rechte auf der DD
    • Benutzer („user“)-Rolle zum monitoren der Systeme
  • Separieren der Admin und Security Benutzer
  • Einsatz einer zwei Faktor Autorisierung
    • beim Login wird ein zusätzliches Token verlangt
      • RSA-SecureID

Einsatz der DELL CyberSecurity Plattform

• Einrichten eines Air-Gap zum Schutz vor Insider Hacks
• Analyse der Daten im Secure Bereich
• Verwendung von CyberSense
  • Analyse der gesicherten Daten mit Mitteln der Software-Forensik
  • Sicher stellen eines Viren-freien Datenbestandes

Alle diese Konfigurationsmöglichkeiten zur Verbesserung der Datensicherheit werden in meinem NetWorker Workshop beleuchtet und wenn möglich auch praktisch vorgeführt.
Sollten ich Ihr Interesse an diesen Themen geweckt haben, würde ich mich freuen, Sie im Hause qSkills in Nürnberg begrüßen zu dürfen.
Es steht Ihnen aber auch die Möglichkeit zur Verfügung, mich für einen NetWorker und DataDomain Health Check in Ihrem Hause zu buchen.

Seit langem mal wieder ein NetWorker Blog mit der Besprechung eines neuen „tollen“ Features „MTREE Replication“.

Die letzten neuen NetWorker Versionen waren ja eher arm an neuen Funktionen, anders die Version 19.7, diese enthält gleich mehrere brauchbare Funktionserweiterungen und ein absolutes Highlight! Die „DataDomain MTREE Replication Unterstützung“. Diese Funktion ist bisher zwar nur auf Kommando-Ebene konfigurierbar, dies tut der Funktionalität aber keinen Abbruch und wurde diese kleine Hürde einmal geschafft, so erhält man eine ganz neue und mächtige Art der Disaster- und Test-Funktionalität für NetWorker-Server.

Eine kurze Beschreibung der Funktionalität:
Bisher war es nicht sinnvoll die DataDomain MTREE-Replication in Zusammenhang mit einem NetWorker-Server einzusetzen, da der Server mit der Kopie eines Volumes nicht direkt etwas anfangen kann (Duplikate für die Volume-ID und den Volume-Namen schließen sich in einem Server aus). Die neue MTREE-Replication geht daher einen ganz anderen Weg. Die mittels MTREE-Replication erzeugte Kopie wird nicht an dem Source-NetWorker-Server, sondern an einem zweiten NetWorker-Server (nennen wir ihn im folgenden mal DR-Server) integriert. Hierbei wird aber nicht nur das DD-Volume an dem DR-Server eingepflegt, sondern die neue Import-Funktion übernimmt auch alle Ressourcen und Indices von dem Source-Server. Nach dem Durchlauf eines Export, Replication und Import Zyklus hat man im DR-Server alle im SRC-Server durchgeführten Sicherungen für Tests oder für eine DR-Umgebung zur Verfügung!
Nach dem ersten Durchlauf des kompletten Zyklus enthalten die folgenden Workflow-Durchläufe nur das Delta der neu erzeugten Sicherungen, die völlig automatisiert in den DR-Server eingearbeitet werden.
 
Die ganze Funktionalität hat natürlich einige Voraussetzungen:

1. DataDomain-OS V7.7 oder höher
2. NetWorker VERSION 19.7
3. Den identischen DD-Boost-Benutzer auf beiden DD-Systemen (Name und UID)
4. Einige Ressourcen in beiden NetWorker Servern
   
   • Policy / Workflow / Replication Action
   • „NSR DD Device Replication“
5. Administrative Rechte des SRC-Servers im DR-Server
6. Gegenseitige Client-Ressource der beiden NetWorker-Server
7. Freien Speicherplatz im „/nsr“ Bereich, sowohl auf dem SRC- als auch auf dem DR-Server

Sind diese Hürden allerdings genommen, so erhält man folgende potentielle neue Möglichkeiten:

• Einen Standby-NetWorker-Server der immer nur „n“-Stunden hinter dem aktiven NetWorker hinterher läuft.

• Eine potentielle Test-Umgebung auf der man intensive NetWorker-Recover Tests durchführen kann, ohne den produktiven Server zu beeinträchtigen.

Einschränkungen:
Die Funktionalität ist nur von LINUX zu LINUX oder Windows zu Windows einsetzbar.

Leider kann ich in diesem Blog nicht auf alle nötigen Konfigurationsschritte eingehen, aber die Funktionalität ist ab sofort Bestandteil der beiden NetWorker-Workshops „NetWorker Update 19.x“ und „NetWorker Advanced“.

Die Corona Zeit hat uns weiterhin alle im Griff, so gab es für mich seit März keine Workshops im Hause qSkills (lediglich 3 virtuelle NetWorker Workshops fanden statt) und auch die vor Ort Einsätze bei Kunden beschränkten sich auf genau 2 HealthChecks.

Aber einige Dinge lassen sich auch in diesen Zeiten nicht bremsen, so zum Beispiel das Datenwachstum in den Unternehmen. Daher stand bei einem unserer Kunden ein Austausch der beiden DataDomain Systeme gegen neuere, größere Modelle an. Um genau zu sein, sollten zwei DD6400-er Modelle mit 4-TB Platten-Shelfs gegen zwei DD9800-er Modelle mit 8 TB Platten ersetzt werden.

Im Normalfall kann man bei einem Upgrade der DataDomain-Systeme einfach einen Head-Swap (Austausch der Betriebssystem-Einheit) durchführen, wodurch keine Datenmigration nötig wird und alle angeschlossenen Backup Systeme nach dem Tausch der Einheit weiter arbeiten können wie zuvor. In dem hier beschriebenen Fall, konnte dieses Verfahren aber leider nicht durchgeführt werden, weil die „alten“ Platten-Shelfs nicht an den neuen Kopf angeschlossen werden konnten. Wären auf den DataDomain-Systemen ausschließlich NetWorker Server im Einsatz gewesen, so hätte eine Lösung in einer schleichenden Übernahme der Daten mittels Cloned-Control-Replication (CCR) und einer NetWorker basierten Migration der Langzeitsicherungen bestehen können. Aber der Kunde ist Dienstleister und hat außer 3 NetWorker Servern, 3 weitere Backup-Applikationen (VEEAM, DD-Boost for EAPP und VRanger) auf Basis von DD-Boost mit Mtree-Replikationen im Einsatz. Zudem gibt es auch noch reine CIFS-Shares mit Mtree-Replikationen. Ziel des Systemaustausches war es aber dennoch: Alle Backup-Systeme sollten nach der Migration ohne Datenverlust und OHNE Konfigurationsänderungen wieder an den Start gehen können.

Es war folglich eine Migration der Daten mit einer Übernahme der Konfigurationen von den Alt-Systemen zu den Neu-Systemen nötig. Die Herausforderung bestand folglich darin:

• alle auf den beiden „alten“ DataDomain befindlichen Daten auf die beiden „neuen“ Systeme zu kopieren

• die Namen der „Alt-Systeme“ auf die „Neu-Systeme“ zu übernehmen

• die bestehenden Replikations-Beziehungen zwischen den DataDomain Systemen zu erhalten und auf die neuen Systeme zu übernehmen

• die Migration so zu gestalten, dass nach der erfolgreichen Migration alle Backup-Applikationen nahtlos mit den neuen Systemen weiter arbeiten können.

Wie geht man in einem solchen Falle vor?

Das DataDomain-Betriebssystem kennt neben den oben bereits erwähnten Replikationsarten, Mtree-Replikation und CCR die „altertümliche“ Art der Collection-Replikation. Diese Replikationsart kopiert auf Block-Ebene alle Daten einer DataDomain auf eine zweite DataDomain. Hierbei werden alle Mtrees, deren Snapshots und auch die lokalen Benutzer und sonstigen Konfigurationen mit kopiert. Auf den neuen Systemen sollten folglich nach der erfolgreichen Kopieraktion alle Daten und Konfigurationen der „alten“ Systeme zur Verfügung stehen. Der einzige größere Punkt wäre demnach die Übernahme der Netzwerk-Konfiguration und die Umbenennung der Systeme. So weit die graue Theorie, doch wie so oft liegt die Tücke im Detail. Doch dazu später mehr!

Meine erste Idee für eine erfolgreiche Umsetzung der obigen Aufgabe war natürlich ein Test der Migration mit virtuellen DataDomain-Systemen. ABER nachdem ich eine passende Test-Umgebung aufgebaut hatte, gab mir das virtuelle DataDomain-Betriebssystem zu verstehen, dass eine Collection-Replikation mit virtuellen Systemen nicht unterstützt wird.

Also war mal wieder eine Operation am offenen Herzen nötig. Frei nach dem Motto „No Risk No Fun“, setzte ich folglich die Collection-Replikation zwischen den Source-DataDomain- und den Destination-DataDomain-Systemen auf. Hierfür ist zwar eine DownTime aller beteiligten Backup-Systeme von Nöten (das Filesystem der DataDomain muss vor dem Aufsetzen der Collection-Replikation disabled werden), aber diese hält sich zeitlich in Grenzen und war auch nur ein kleines organisatorisches Problem.

Nach dem Aufsetzen der Replikation bestand die Aufgabe zunächst nur darin, zu beobachten, mit welcher Geschwindigkeit die Daten kopiert werden und ob evtl. die Datenrate eingeschränkt werden sollte, um die Netzwerke nicht zu überfordern. Doch dank 10-GB Ethernet gab es keine Last-Probleme und die 4 Systeme waren nach einigen Tagen synchron.

Der Tag des CutOver (Übernahme der kompletten Funktionalität auf das jeweils neue System) war schließlich da. Die Downtime für alle Backup-Syteme war vorsichtshalber für einen ganzen Arbeitstag eingeplant. Jetzt wurde es spannend. Wichtig für eine erfolgreiche Übernahme der Mtree-Replikationen ist es, vor der Unterbrechung der Collection-Replikation auf allen Mtrees einen Snapshot zu generieren. Auf diesem Snapshot kann die jeweilige Mtree-Replikation nach dem CutOver wieder aufgesetzt werden. Eine Beschreibung zu diesem Verfahren findet man hier (Data Domain: MTREE resync after Collection replication cutover). Folglich legten wir für jeden Mtree (16 an der Zahl) ein Snapshot an und kontrollierten das diese auch auf den Ziel-Systemen vorhanden waren. Nach der erfolgreichen Kontrolle wurde der BREAK der Collection-Replikation durchgeführt. Auch hierfür muss zunächst das Filesystem disabled werden. Nachdem die Filesysteme auf den neuen DataDomain-Systemen wieder aktiviert (enabled) wurden, hat man auf diesen Systemen ein voll funktionsfähiges Filesystem mit allen Mtrees und Benutzern der Alt-Systeme.

Also ran an die Umbenennung der Alt-Systeme in vorher vorbereitete Backup-Namen und Adressen. Anschließend konnten die Neu-Systeme die Namen und Adressen der altem Systeme bekommen. Diese Arbeiten müssen natürlich über die Management-Interfaces der DataDomain Systeme durchgeführt werden, da man sich ja sonst den Boden unter den Füßen wegzieht. Der erste Schreck war jedoch, dass man nach dem Umbenennen der Neu-Systeme diese nicht erreichen konnte. Eine kurzes Innehalten und reflektieren des Themas ergab dann schnell, das dieses Problem im ARP-Cache der Ethernet-Switches zu finden war. Diese Komponenten hatten natürlich noch die alten MAC-Adressen zu den alten IP-Adressen gespeichert und ließen die Kommunikation erst mal nicht zu. Nachdem dieses Thema erledigt war, konnte man sich an die Wiederherstellung der Replikationen begeben.

Wenn das oben erwähnte Dokument dieses Vorgehen auch etwas kurz ab handelt, war dieser Punkt eher eine Fleiß-Aufgabe. Auf den neuen Systemen ist nämlich zunächst nichts von den ‚alten‘ Mtree-Replikationsbeziehungen zu sehen. Diese müssen folglich zunächst auf beiden Systemen bekannt gemacht werden. Hiernach kann man durch die bestehenden Snapshots und die Funktion Resync die vorherige Beziehung wieder aktivieren.

Diese Schritte mussten für jede Mtree-Replikationsbeziehung separat durchgeführt werden. Wie gesagt, Fleißarbeit und volle Konzentration waren hier gefragt.

Aber dann der Schock, wo waren die für die DD-Boost Kommunikation benötigten Storage-Units?

Die Mtrees auf denen die StorageUnits zum Beispiel für den NetWorker-Backups basieren, waren da, aber die logische DD-Boost-Einheit „StorageUnit“ war von der Collection-Replikation nicht übertragen worden. Zumindest war von diesen nichts zu sehen! Ein Anlegen dieser StorageUnits auf den bereits bestehenden Mtrees verweigert das DataDomain-OS sowohl aus dem GUI als auch auf der CLI Ebene. Eine Recherche auf den Dell/EMC Support-Seiten konnte leider auch nicht weiter helfen. Ein Hilferuf in die EMC-Community ergab zunächst die Idee, den bestehenden Mtree mittels Fastcopy in eine neue StorageUnit zu kopieren, hierbei könnte man die alte zunächst umbenennen und die Kopie auf dem original Namen wieder aufsetzen. Dieses Verfahren funktioniert auch für die NetWorker-StorageUnits, ABER für die StorageUnits die mittels Mtree-Replikation ihre Daten auf das Destination-System kopieren ist es leider unbrauchbar, weil man hierdurch die zugehörige Replikationsbeziehung verliert. Gott sei Dank kam kurz vor der nötigen Entscheidung, entweder noch mal zurück auf die alten Systeme zu schwenken oder alle Mtree-Replikationen neu aufzusetzen, eine weitere Information aus der EMC-Community. Offensichtlich werden alle Informationen der StorageUnit bei der Collection-Replikation übertragen, lediglich der letzte Schritt das Sichtbar machen dieses logischen Elements scheint zu fehlen. Führt man demzufolge eine Veränderung an einer „verborgenen“ StorageUnit durch, dann wird diese plötzlich sichtbar und im Anschluss auch verwendbar.

Nachdem auch diese Hürde genommen war, konnten die Backup-Applikationen wieder starten, dachte man. Aber aus unerfindlichen Gründen gab es auf der Destination-DataDomain dann doch noch ein Problem mit den StorageUnits. Das betraf zwar nur die NetWorker Server, aber diese konnten auf die Destination nicht Clonen. Die Ursache dieses Problems lag darin, dass der NetWorker-Boost Benutzer auf dem neuen DataDomain System eine andere User-ID hatte als auf dem dem Ursprungssystem. Also Mounten der StorageUnit am NetWorker-Server, die Rechte umbiegen und auch dieses Problem war gelöst.

Am nächsten Tag gab es dann Gott sei Dank keine bösen Überraschungen! Alle Backups waren gelaufen, lediglich einige Überwachungsskripte, die per SSH Kommunikation (authorized keys) Daten direkt aus der DataDomain auslesen, konnten keine Daten liefern. Das Problem hier, die Home-Verzeichnisse der DataDomain-Benutzer werden bei der Collection-Replikation nicht mit kopiert. Der Benutzer selbst war aber da (s.o.), man konnte aber leider auch keine neuen SSH-Keys einrichten. Denn das zugehörige Kommando lieferte nur dubiose Fehlermeldungen (can not mkdir …). Auch hier Bestand die Lösung in einem Mount, in dem Falle des DataDomain-Konfigurations-Verzeichnisses (ddvar) und einem händischen Anlegen der zugehörigen Verzeichnisse und Dateien.

Bleibt noch zu erwähnen, dass das gesamte Projekt mittels Fern-Verbindung durchgeführt wurde.

FAZIT:

Die Migration „alter“ DataDomain Systeme auf „neue“ größere und schnellere Systeme konnte wie geplant mit einer überschaubaren Down-Time der Backup-Systeme ohne Datenverluste durchgeführt werden. Leider lässt sich dieses Verfahren nicht mit virtuellen Systemen testen und es gibt wie so oft kleine Stolpersteine auf dem Weg zum Erfolg. Aber für Umgebungen mit DD-Boost Konfigurationen mit zugehörigen Mtree-Replikationen erscheint es weiterhin die einzig praktikable Vorgehensweise zu sein.

Sollten Sie Fragen zum beschriebenen Projekt haben, oder Unterstützung bei einer ähnlichen Herausforderung haben, so scheuen Sie sich bitte nicht den Autor zu kontaktieren, wir finden bestimmt auch eine Lösung für Ihr Problem!