Monatsarchiv: Juli 2016

Update 05.07.2016: Bei der Installationsquelle wurde darauf hingewiesen eine gepatchte Installationsquelle zu nutzen. Diese Methode darf nicht für Upgrades von Data Protector Versionen 8.13 und neueren Versionen angewandt werden, da in diesem Fall die interne Datenbank nicht reparierbare Schäden erleiden wird. Für Versionen kleiner 8.13 wird die Methode auch nicht empfohlen, da dieser Weg nicht komplett durch die Entwicklung getestet wurde. In diesem Falle ist also erst Data Protector 9.0 und dann separat das aktuelle Patchbundle zu installieren. Einzige Ausnahme für „streamed“ Installation scheinen Neuinstallationen zu sein (beispielsweise bei der Installation von Windows 2012 R2 Cluster Cell Server), da es hier keine Abhängigkeit zur Aktualisierung der internen Datenbank gibt.

Data Protector 7.0 wurde am 16.04.2012 eingeführt und mittlerweile durch zwei weitere Major Releases erweitert. Am 30.06.2016 ist es nun soweit, der Support für Data Protector 7.0x endet. Damit ist es Zeit für alle Unentschlossenen auf die aktuelle Version – Data Protector 9.06 – zu wechseln. Ein großer Schritt, da mit dem Upgrade der Wechsel der internen Datenbank verbunden ist. Viele Kunden haben diesen Schritt bisher gescheut, waren doch auch Unsicherheiten mit dem Upgrade verbunden. Hewlett Packard Enterprise hatte in der Vergangenheit bereits Advisories (siehe http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04350769 und http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=c04937621) veröffentlicht und aufgeführt wie das Upgrade auf die neue interne Datenbank durchgeführt werden kann. Der Wechsel auf die neue Version bietet jedoch auch Chancen die Backup- und Recovery-Strategie (zum Beispiel Sicherung auf HPE StoreOnce) zu überdenken, da in der aktuellen Version sehr viele neue Funktionen verglichen zu Data Protector 7.0x enthalten sind. Einige ausgewählte Funktionen:

• 3PAR Remote Copy Support
• Automatisiertes Pausieren und Fortführen von Backup Jobs
• VMware Backup mittels 3PAR Snapshot Management
• Cached VMware Single Item Recovery – direkt aus HPE 3PAR Snapshots oder dem Data Protector Smart Cache
• VMware Power On und Live Migrate von HPE 3PAR Snapshots oder dem Data Protector Smart Cache
• StoreOnce Catalyst over Fiber Channel und Federated Catalyst Support
• Automated Replication Synchronization – ermöglicht die Synchronisation von Metadaten replizierter Objekte (StoreOnce) zwischen Cell Managern

Im Netz existieren weitere Anleitungen, jedoch keine Schritt-für-Schritt Anleitung. Daher beschäftigt sich dieser Artikel mit dem Upgrade von Data Protector 7.0x auf Data Protector 9.06 und stellt alle notwendigen Schritte als RUNBOOK zur Verfügung.

Einige Hinweise bevor es losgehen kann:

• Diese Schritt-für-Schritt Anleitung gilt für Cell Manager Installationen unter Windows 2008 und Windows 2012. Es wird davon ausgegangen, dass die Pfade C:\Program Files\OmniBack und C:\ProgramData\OmniBack verwendet werden. Diese Anleitung kann aber auch prinzipiell für Linux oder abweichende Installationspfade verwendet werden.
• Bei der Migration (separater und anschließender Prozess) werden die DCBF Dateien in ein neues Format konvertiert. Das neue DCBF Format ist ca. 1,5-mal bis 2-mal größer als das alte Format, es ist daher genügend freier Plattenplatz notwendig.
• Alle vorhandenen Data Protector Lizenzen sollten im Vorfeld über das neue Lizenzportal https://myenterpriselicense.hpe.com neu generiert werden, die alten OVKEY3 Lizenzen lassen sich in den aktuellen Data Protector Versionen nicht mehr verwenden. Es können natürlich nur Lizenzen migriert werden, für die ein Wartungsvertrag besteht.
• Sollte das Upgrade trotz dieser detaillierten Anleitung fehlschlagen, so besteht jederzeit die Möglichkeit auf die alte Data Protector 7.0x Version zurückzugehen. Dafür werden aber die DP 7.0 Installationsquellen und das zuletzt installierte Patch-Bundle benötigt.
• Es wird empfohlen alle verwendeten und anhängbaren Medien in einen separaten Pool zu verschieben, so dass eine Vermischung von zu migrierenden und neuen Medien vermieden wird.
• Die Catalog Migration der DCBF Dateien ist ein nachgelagerter Prozess und kann entweder direkt nach dem Upgrade oder nach ein paar Wochen erfolgen. Während der Catalog Migration sollten möglichst keine Aktivitäten auf dem Cell Server stattfinden.
• Es wird empfohlen das Upgrade in einer virtuellen Maschine vorab zu testen, hierfür kann einfach eine exportierte Data Protector 7 Datenbank in die Testumgebung importiert werden.
• Mit Data Protector 9.0x wird die Namensauflösung Priorität 1 zur Vermeidung von Problemen während oder nach der Migration. Es ist daher sicherzustellen, dass der Cell Manager immer „aufgelöst“ (FQDN, short und reverse) werden kann.
• Mit dem Upgrade auf die aktuelle Version werden möglicherweise nicht mehr ältere Clients wie Windows 2003 unterstützt. Handelt es sich bei einem solchen Client um eine virtuelle Maschine, so kann diese zukünftig mit der VMware oder Hyper-V Integration gesichert werden.
• Die nachfolgende Anleitung stellt nur einen möglichen Weg für die Migration dar, es gibt mehrere Wege. Somit wird keine Garantie übernommen, da ein erfolgreiches Upgrade auch von der vorhandenen Umgebung abhängt. Mit diesem Runbook wurden jedoch bereits sehr viele erfolgreiche Migrationen durchgeführt und somit sollte die Anleitung auch für eure Umgebung geeignet sein.

Vorbereitung:

• Überprüfung der Konsistenz der internen Datenbank. Es dürfen keine Fehler angezeigt werden. Bei Fehlern sind diese erst zu beheben bevor mit dem Upgrade auf DP 9.0x fortgefahren werden kann
  • omnidbcheck -extended
• Bereinigung der internen Datenbank
  • Data Protector GUI schliessen
  • omnidbutil -clear
  • omnidb -strip
  • omnidbutil -purge -sessions 90 (oder entsprechend höherer, geringerer Wert)
  • omnidbutil -purge -dcbf -force
  • omnitrig -stop
  • omnistat (es darf keine Sicherung laufen)
  • omnidbutil -purge -filenames -force
  • Data Protector GUI öffnen
    • Monitor –> Current Sessions
    • Purge Session auswählen
    • Fortschritt und Ende des Purges Prozesses beobachten
• Während des Purges der Filenames können keine Sicherungen ausgeführt werden, scheduled Jobs werden in die Warteschlange eingeordnet und erst dann ausgeführt wenn der Purge abgeschlossen ist. In größeren Umgebungen kann es notwendig sein den Purge Vorgang abzubrechen und zu einem späteren Zeitpunkt fortzusetzen. Hierbei kann das Kommando omnidbutil -purge_stop verwendet werden. Alternativ kann der Purge auch selektiv für einzelne Clients ausgeführt werden.
• Anlegen von Sicherungsverzeichnissen:
  • mkdir C:\migration\mmdb
  • mkdir C:\migration\cdb
  • mkdir C:\migration\other
  • mkdir C:\migration\programfiles\omniback
  • mkdir C:\migration\programdata\omniback
• Defragmentierung der internen Datenbank über den Export und Import
  • Es dürfen keine Sicherungen laufen, Prüfung mit dem Befehl omnistat
  • omnidbutil -writedb -mmdb C:\migration\mmdb -cdb C:\migration\cdb
  • Am Ende des Exports wird aufgefordert bestimmte Verzeichnisse zu kopieren, bevor die Datenbank weder aktiviert wird. Dies sind in der Regel die DCBF und MSG Verzeichnisse, es können jedoch auch andere Verzeichnisse notwendig sein. Zur Sicherheit werden daher folgende Verzeichnisse kopiert:
    • robocopy "C:\ProgramData\OmniBack\db40\dcbf" C:\migration\other\dcbf *.* /e /r:1 /w:1
    • Das Kopieren kann für weitere DCBF Verzeichnisse notwendig sein. In diesem Fall ist der Kopiervorgang entsprechend fortzuführen.
    • robocopy "C:\ProgramData\OmniBack\db40\msg" C:\migration\other\msg *.* /e /r:1 /w:1
    • robocopy "C:\ProgramData\OmniBack\db40\meta" C:\migration\other\meta *.* /e /r:1 /w:1
    • robocopy "C:\ProgramData\OmniBack\db40\vssdb" C:\migration\other\vssdb *.* /e /r:1 /w:1
  • Jetzt kann die exportierte Datenbank wieder importiert werden. Hierzu wird der folgende Befehl verwendet.
    • omnidbutil -readdb -mmdb C:\migration\mmdb -cdb C:\migration\cdb
  • Wird vor dem Import der Datenbank auch ein omnidbinit -force ausgeführt, müssen die DCBF, MSG und META Verzeichnisse wieder an die alte Stelle kopiert werden, da die originalen Verzeichnisse beim Initialisieren der Datenbank gelöscht werden. Hierfür müssen jedoch die Data Protector Dienste gestoppt sein. Bei Bedarf müssen auch zusätzliche DCBF Verzeichnisse für die interne Datenbank angelegt werden.
• Zur Sicherheit wird nochmals ein omnidbcheck -extended ausgeführt, es dürfen keine Fehler angezeigt werden.
• Bei Bedarf können jetzt noch temporäre Dateien in den Verzeichnissen C:\ProgramData\OmniBack\tmp und C:\ProgramData\OmniBack\log entfernt werden. Aber Achtung: nicht jede Log Data kann gelöscht werden. Dateien wie das media.log müssen aufbewahrt werden, da die unter Umständen bei der Wiederherstellung von Daten benötigt werden kann. Das media.log enthält Informationen wann und in welcher Reihenfolge ein Medium bei einer Sicherung genutzt wurde.
• Sicherung der gesamten Data Protector Installation:
  • omnisv -stop
  • robocopy "C:\Program Files\OmniBack" C:\migration\programfiles\omniback *.* /e /r:1 /w:1 /purge
  • robocopy C:\ProgramData\OmniBack C:\migration\programdata\omniback *.* /e /r:1 /w:1 /purge
  • omnisv -start

Installationsquellen:

• Für die Installation sollte unbedingt eine gepatchte Installationsquelle genutzt werden. Hierfür werden auf einen temporären Windows Server, auf dem noch kein Data Protector Installation vorhanden ist folgende Schritte ausgeführt:
  • Aufrufen der Data Protector 9.0 Installation als Administrator (run as admin) und die Installation vom Installation Server durchführen. Es werden keine weiteren Komponenten außer dem Installation Server installiert.
  • Nach Abschluss der Installation das aktuelle Patch-Bundle und bei Bedarf weitere Patches installieren. Siehe auch https://www.data-protector.org/wordpress/2016/04/hpe-data-protector-patch-bundle-9-06-features/ und https://www.data-protector.org/wordpress/2013/06/basics-installation-order-patches/
• Die nun so aktualisierte Installation kann als Installationsquelle für das Upgrade des Cell Managers verwendet werden. Hierzu werden alle Ordner des Depots auf den Data Protector 7.0x Cell Managers (zum Beispiel nach C:\migration\install) kopiert. Anschließend kann der temporäre Installation Server wieder deinstalliert werden.

Upgrade:

• Das Upgrade erfolgt mit den gepatchten Installationsquellen und setup.exe wird als Administrator (run as admin) ausgeführt.
• Es wird empfohlen alle vorgeschlagenen Standards bei der Installation zu belassen und damit das Upgrade durchzuführen.
• Während des Upgrades werden Teile der alten Datenbank exportiert und für den Import in die neue Datenbank vorbereitet. Dieser Vorgang kann je nach Größe der Umgebung Zeit in Anspruch nehmen; der Vorgang sollte nicht unterbrochen werden.



• Im Anschluss wird die Installation von Data Protector 9.0x normal fortgeführt.
• Nach dem Upgrade sollten unbedingt die Konfigurationsdateien global und omnirc überprüft und angepasst werden.
• Zusätzlich sollte die Sicherungsspezifikation des Cell Servers überprüft werden. Mit dem Upgrade wurde die bisherige Spezifikation geteilt in eine IDB- und eine Filesystemspezifikation.

Nach dem Upgrade:

• Nach dem Upgrade sollten die DCBF Verzeichnisse auf das neue Format migriert werden. Prinzipiell gibt es hier zwei Möglichkeiten: die sofortige Migration aller DCBF Dateien oder eine Migration der DCBF Dateien für Langzeitsicherungen.
• Beim zweiten Weg wird auf das Auslaufen der Schutzfrist für die alten Medien und damit DCBF gewartet, in diesem Falle wäre keine Migration dieser Medien notwendig und nach ca. vier bis sechs Wochen werden nur noch die Medien mit einer längeren Schutzfrist migriert.
• Vorgehensweise für beide Wege:
  • Administrative Command Line öffnen und in das Verzeichnis C:\Program Files\OmniBack\bin wechseln
  • Folgenden Befehl ausführen: perl omnimigrate.pl -start_catalog_migration
  • Die DCBF Migration ist sehr langwierig, läuft jedoch im Hintergrund und muss nicht aktiv beobachtet werden.
  • Nach Ende der DCBF Migration ist zu prüfen ob alle Medien migriert wurden. Hierfür wird der Befehl perl omnimigrate.pl -report_old_catalog verwendet. Als Ergebnis wird hierbei "DCBF ( 0 files)" erwartet. Sollten noch Dateien angezeigt werden, so dürfen die nachfolgenden Schritte nicht ausgeführt werden.
  • Falls während der DCBF Migration bereits neue Sicherungen gelaufen sind, so kann es passieren, dass in den DB40\DCBF* Verzeichnissen DCBF 2.0 Dateien angelegt wurden.
  • Die im DB40\DCBF* gefundenen Dateien sind nach C:\ProgramData\OmniBack\server\db80\dcbf\dcbf1-4 zu verschieben. Hierbei können die Dateien verteilt werden, es ist prinzipiell nicht notwendig eine bestimmte Ordnung einzuhalten.
  • Mit dem Befehl omnidbutil -remap_dcdir erfolgt eine Anpassung der internen Datenbank nach dem Verschieben der DCBF Dateien.
  • Die alten DCBF Pfade sind zu entfernen, hierbei werden die folgenden Befehle genutzt:
    • omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\db40\dcbf"
    • omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\db40\dcbf1"
    • omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\db40\dcbf2"
    • omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\db40\dcbf3"
    • omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\db40\dcbf4"
  • Je nach Größe der Umgebung können weniger oder mehr DCBF Verzeichnisse vorhanden sein und müssen entsprechend entfernt werden.
  • Mit dem Befehl perl omnimigrate.pl -remove_old_catalog wird nur der alte Catalog entfernt
  • In der Datei C:\ProgramData\OmniBack\Config\Server\options\global sollte nun die Variable SupportOldDCBF=0 stehen (Default ist 1 nach der Migration), sie kann jedoch auch ganz entfernt werden.
  • Nun kann der DB40 Pfad gelöscht werden – C:\ProgramData\OmniBack\db40

Rollback:

• Sollte das Upgrade fehlschlagen, so kann jeder Zeit und sofern noch keine Migration der DCBF Dateien begonnen wurde der Cell Server auf den Stand von Data Protector 7.0x zurückgeführt werden.
• Die fehlgeschlagene Data Protector 9.0x Installation ist zu deinstallieren und Data Protector 7.0x zu installieren.
• Mit dem Befehl omnidbutil -readdb -mmdb C:\migration\mmdb -cdb C:\migration\cdb kann die alte Datenbank wieder importiert werden.
• Zusätzliche Verzeichnisse, wie DCBF, MSG und META, müssen wieder in den db40 Pfad zurückkopiert werden.
• Die Konfiguration vom Data Protector aus dem vorher gesicherten Verzeichnis C:\migration\omniback\programdata\config\server wird nach C:\ProgramData\OmniBack\Config\Server kopiert, damit ist der Ausgangszustand wiederhergestellt.
• Sollte ein Rollback nicht gewünscht sein, so können auch aus den oben beschriebenen Advisories die Schritte zur Fehleranalyse ausgeführt werden.