Wie es der Zufall mal wieder so wollte, fragten in diesem Jahr zwei Kunden unabhängig voneinander, nach einem Prove Of Concept (POC) für den Einsatz des NMDA-OApp Moduls. In einem Fall für einen Einsatz mit PostgreSQL Datenbanken im zweiten Fall für MySQL Datenbanken.

Beide POCs konnten erfolgreich beendet werden, aber bevor wir uns mit den Details befassen ein paar kurze Infos zu dem NMDA-OApp Modul.

Mit der NetWorker Version 18.1 (2018) wurde in dem NetWorker „Modul for Database Applications (NMDA)“ die sogenannte OApp Erweiterung eingeführt. Diese ermöglicht es, mit Hilfe eines DataDomain Storage-Systems und dem zugehörigen BoostFS Modul, Datensicherungen und Wiederherstellungen der Datenbanken PostgreSQL, MySQL, MariaDB und MongoDB schnell, elegant und vor allem sicher auf ein externes Backup-Storage-System zu speichern.

Bei dieser für NetWorker neuen Art der Sicherung werden die vom Datenbankprodukt bekannten Sicherungs- und Wiederherstellungs-programme verwendet, aber die Daten sind nach der Sicherung nicht mehr auf der lokalen Platte des Datenbank-Systems sondern auf der DataDomain und auf einem NetWorker-Medium.

Vorteile:

• Alle Sicherungen (Voll und Log-Sicherungen) werden mit den bekannten NetWorker-Eigenschaften verknüpft. Im einzelnen sind das:
  • Retention Zeiten
  • Cloning auf eine 2‘te Data-Domain
  • Integration der Sicherung in die Medien-Datenbank und damit Such-Möglichkeiten über die Sicherungsattribute

• Auch eine Wiederherstellung auf einen definierten Zeitpunkt (Recover-Until-Time) werden durch die OApp Erweiterung ermöglicht.

Nachteile:

• Die Installation und Konfiguration des benötigten BoostFS Moduls und der benötigten Skripte ist ein wenig knifflig.

• Für eine Wiederherstellung müssen Anpassungen in Wiederherstellungs-Skripten vorgenommen werden.

Hier ein kurzer Abriss der benötigten Installations- und Konfigurations-Schritte beim Einsatz des Moduls mit PostgreSQL Datenbanken:

1. Installation der benötigten NetWorker und DataDomain Pakete
2. BoostFS Konfiguration
   • Lockbox konfigurieren
   • BoostFS für PostgreSQL konfigurieren
3. NetWorker NMDA Config Files anlegen
4. NetWorker Ressourcen anlegen
5. Postgres Config File anpassen

> mminfo -ot -v -c sles12sp5-1
pgres.005 sles12sp5 02/17/22 55 MB cr full   PostgreSQL_nsr_full
pglog.005 sles12sp5 02/17/22 16 MB cr txnlog PostgreSQL_nsr_txnlog_1040
pglog.005 sles12sp5 02/17/22 16 MB cr txnlog PostgreSQL_nsr_txnlog_1041
pglog.005 sles12sp5 02/17/22  2 KB cr txnlog PostgreSQL_nsr_txnlog_1041.0028.backup

Nötige Schritte für einen Point in Time Recover:

• Sicherungszeit (savetime) und SaveSet-Name des gewünschten Backup in der Config-Datei eintragen
• Relocation-Destination vorbereiten
• DB-Stoppen
• PostgreSQL Data Verzeichnis entfernen
• NetWorker NMDA Recover Kommando starten
• Wiederhergestellte Daten in das PostgreSQL-Data Verzeichnis umziehen
• Definitionsparameter in der postgresql.conf editieren
  1. restore_command
  2. recovery_target_time
• Postgres Signal Datei anlegen
• DB Starten
• Postgres Log File kontrollieren
• Postgres Signal Datei entfernen
• PostgreSQL Config File editieren
• PosgreSQL Dienst neu starten

Log-Ausgabe eines erfolgreichen Point in Time Recovers

> less data/log/postgresql-2022-02-17_104617.log

starting
point-in-time recovery to 2022-02-17 10:30:00+01

The recovery completed successfully.

restored log file "1046" from archive

redo starts at 0/46000028

consistent recovery state reached at 0/46000138

database system is ready to accept read only connections

The recovery completed successfully.

restored log file "1047" from archive time 2022-02-17
10:30:24.525416+01 

recovery stopping before commit of transaction 13283,

pausing at the end of recovery

HINT: Execute pg_wal_replay_resume() to promote.

FAZIT:

Die oben gezeigten Konfigurations-Schritte haben nicht den Anspruch vollständig und ausreichend zu sein, sie sollen Ihnen nur die Komplexität des Themas vermitteln, ihnen aber auch zeigen, dass das Ergebnis den Aufwand lohnt.

Sollten Sie weitergehende Fragen zu dem Einsatz des NMDA-OApp Moduls haben oder selbst einen POC in Ihrem Hause wünschen, so scheuen Sie sich nicht, den Autor zu kontaktieren.

Visualisierung und Management von NetWorker Log- und Raw-Dateien sowie Systemparametern

1. Einleitung

Wer für die Sicherung einer größeren Firma verantwortlich ist, möchte frühzeitig mitbekommen, wenn
das Backup-System in eine Schieflage gerät. Um das zu erreichen, reicht es nicht, nur die Meldun-
gen der Sicherungen zu kontrollieren, sondern der Administrator sollte auch die Protokolle der Back-
up-Software und des Betriebssystems betrachten. Zusätzlich sollten die Betriebssystem-Parameter,
wie Hauptspeicherverbrauch, Netzwerkauslastung und Ähnliches im Auge behalten werden.


Ein NetWorker Administrator ist heutzutage aber schon rein zeitlich nicht in der Lage, alle System-
protokolle und die NetWorker-Protokolle täglich durchzuarbeiten. Die Überwachung läuft folglich
auf eine Symptom-Bekämpfung hinaus. Wenn ein akutes Problem auftaucht, z.B. eine Sicherung wird
wiederhollt abgebrochen, dann wird eine Analyse gestartet. Oft wäre das Problem aber bereits im
Vorfeld zu erkennen gewesen. Man hätte die Backup Probleme vermeiden können, wenn die betref-
fenden Meldungen früh genug erkannt worden wären.


Ein Beispiel:
Ein Kunde berichtete mir in einer meiner Workshops, dass die NDMP Sicherungen in seiner Firma seit
längerem ein Zeitfenster-Problem haben. Früher wäre alles ohne Probleme gelaufen, aber seit einiger
Zeit würden die NDMP Sicherungen zu lange brauchen.


An diesem Problem wurde schon seit Wochen herumgedoktert, auch mit externen Support. Aber leider
hatten alle Beteiligten immer nur im Umfeld des Storage-Systems und des NDMP-Workflows nach
Fehlern gesucht. Das eigentliche Problem wurde aber nicht entdeckt. Dabei war das Problem in der
NetWorker Protokoll-Datei (daemon.raw) durchaus ersichtlich, wenn man danach gesucht hätte. Die
Ursache des beschriebenen Problems in diesem Beispiel war nicht der NetWorker-Server oder eine
Konfiguration im NetWorker. Die Ursache des Problems war dem Austausch von Netzwerk-Kompo-
nenten und damit veränderten Netzwerk-Routen geschuldet. Durch diese Änderung in der Peripherie
konnten einige NetWorker-Client Maschinen die DataDomain Systeme nicht mehr direkt erreichen.
Es fand folglich kein Client-Direct-Backup mehr statt, sondern die Maschinen sendeten ihre Daten
zum NetWorker-Server und dieser übergab die Daten dann an die DataDomain. Durch dieses, um
mindestens 90% höhere Datenaufkommen, waren die Netzwerk- und System-Komponenten am Net-
Worker-Server so stark belastet, dass beim Start der NDMP Sicherungen keine Kapazitäten mehr frei
waren. Wie gesagt, die Meldungen, dass die Client-Sicherungen keinen direkten Weg mehr für ihr
Backup hatten, waren in den Logs ersichtlich. Es hat nur keiner bemerkt.


Das Auffinden entprechender Meldungen in der NetWorker daemon.raw wird dadurch erschwert,
dass alle NetWorker Daemonen ihre Standard-Error-Ausgabe in diese Datei schreiben. Wenn es dann
noch ein paar Maschinen gibt deren Client-Zertifikat fehlerhaft im NetWorker eingetragen ist, sieht
man schnell den Wald vor lauter Bäumen nicht mehr. Einige Tausend Meldungen pro Tag sind keine
Seltenheit. Hier die Spreu vom Weizen zu trennen war folglich das Ziel des vorliegenden Tools.

2. Das Ergebnis

   Eine WWW-Oberfläche in der:

   • alle wichtigen NetWorker Umgebungsparameter auf einen Blick ersichtlich sind.
   
   • es möglich ist die daemon.raw Meldungen zu filtern, zu bearbeiten und bei definierten Meldungen
     automatische Aktionen einzuleiten.
   
   • es möglich ist, Meldungen nach dem Status (NEW, ACCEPTED, ...), dem Verursacher (nsrexecd,
     nsrd, ...), nach Meldungs-Texten und ausgewählten Zeiträumen, zu filten und nach allen gezeigten
     Spalten, zu sortieren.
   
   • es möglich ist den zeitlichen Verlauf von System-Ressourcen der NetWorker-Server Maschine graphisch zu betrachten
   • es möglich ist Datensicherungslangläufer (Long Running Jobs  anzeigen zu lassen.
   • es möglich ist den Speicher- und Swap-Verbrauch der NetWorker-Server Maschine des letzten Monats visualisiert zu betrachten

3. Weitere Module

   • Überwachung der RetentionLock Definitionen in den NetWorker Workflow-Actions
   • Visualisierung der NetWorker Rap.log Datei
   • Kontrolle der installierten NetWorker Client- und Modul-Versionen
   • Berechnung der DataDomain DeDup-Werte pro Client und SaveSet. Gruppierung der Clients zu Abrechnungzwecken.

4. Die Zukunft

   Weitere Überwachungsparameter sind in Planung oder bereits in Arbeit.
   zum Beispiel:
   
   • Erkennen von Backup Anomalien
   • Überwachung der Bootstrap Sicherungen
   • Kontrolle der RetentionLock Funktionalität bei Datenbank Sicherungen
   • Visualisierung der NetWorker Client- und Modul-Logdateien
   • ...

Sollten sie weitere Fragen oder Interesse an einer Live-Demo des Tools haben so wenden Sie sich am besten per Mail an den Autor.

In diesem von Corona bestimmten Jahr, fanden leider kaum NetWorker-Workshops statt. Doch hierdurch ergab sich auch die Zeit und die Möglichkeit, sich mit anderen Themen rund um die Datensicherung mit NetWorker zu beschäftigen.

Im August und November diesen Jahres, durfte ich bei zwei großen NetWorker-Kunden (mit jeweils mehr als 10 NetWorker-Servern) einen NetWorker Health-Check durchführen. Beide Firmen waren der Meinung, an sich läuft ihre Datensicherung weitestgehend fehlerfrei und problemlos. Meine jeweils viertägige Analyse an ausgewählten NetWorker-Servern ergab jedoch in beiden Fällen eine längere Liste an erkannten Problemen und Verbesserungsmöglichkeiten.

Der Schlüssel zu diesen Erkenntnissen waren

• eine Analyse der NetWorker Ressourcen

• eine konsequente Filterung der NetWorker Daemon.raw Dateien

• eine Analyse der Sicherungszeiten (Sicherungsdauer einzelner SaveSets)

Die Daemon.raw Datei

Diese von allen NetWorker Dämonen beschriebene Datei wird meist viel zu selten oder auch gar nicht für tägliche Analysen herangezogen. Bei akuten Fehlern schaut der Administrator zwar zwangsweise in sie hinein, aber einfach mal so?

Dabei sind hier durchaus interessante und auch wichtige Meldungen enthalten, die auf nicht erkannte Probleme hin deuten oder aufzeigen können, wo noch Konfigurations-Verbesserungen möglich und nötig sind.

Die Probleme bei der Analyse dieser Log-Datei sind:

1. ihre schiere Größe (wie gesagt alle NetWorker Dämonen schrieben hier gleichzeitig hinein)

2. das Verhältnis zwischen unwichtigen Meldungen und relevanten Meldungen

3. das Format

Die Kunst beim Auswerten der Datei bestand folglich darin, die Spreu vom Weizen zu trennen. Soll heißen, die unwichtigen oder bereits bearbeiteten Meldungen aus der zu untersuchenden Datei heraus zu filtern, um im Anschluss die übrigen Meldungen zu sichten und zu bewerten.

Die Sicherungszeiten

Wenn eine Sicherung länger als das eingestellte Workflow-Intervall dauert, bekommt das der Backup-Administrator in den meisten Fällen gar nicht mit. Dies liegt darin begründet, dass NetWorker seit der NetWorker Version 9, in diesen Fällen keine Benachrichtigung (Notification) mehr versendet. Um diese Probleme folglich zu ermitteln, muss man die NetWorker-Medien-DB befragen. Mit einem entsprechendes Skript kann man dann die Intervall-Zeiten des jeweiligen Workflows mit den tatsächlichen Sicherungszeiten der zugehörigen Sicherungen vergleichen. Aber auch eine Sicherung die zwar im Intervall fertig wird, aber mehr als z.B. 16 Stunden dauert, kann für eventuelle Wiederherstellungen zum Problem führen! Für diese erkannten Sicherungsprobleme galt es im Anschluss die jeweilige Ursache und eine mögliche Lösung zu finden.

Die Lösungen konten hierbei leider aus keinem Kochrezept entnommen werden, sondern sie bedurften teils längeren Analysen und Tests. Vor allem, weil es einmal um Filesystem- dann um Datenbank- aber auch um NDMP Sicherungen ging.

Die Methoden und Erkenntnisse dieser beiden Health-Checks sind unter anderem in unser neues NetWorker Log-Analyse und Monitoring Tool eingeflossen. Dieses aus einem WWW-Server und einer Datenbank, sowie 3 Analyse-Daemonen bestehenden Produkt, filtert nicht nur die Meldungen der jeweiligen Daemon.raw Datei vor, sondern es bietet interaktiv die Möglichkeit diese Filter selbst zu erweitern. Zusätzlich werden Sicherungslangläufer und weitere Probleme der NetWorker-Maschine analysiert und dargestellt. Mehr zu diesem Tool erfahren sie hier in Kürze.

Sollten auch Sie einen NetWorker Health-Check wünschen, so wenden Sie sich einfach per E-Mail an den Autor.

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!