Autor Archiv: danielbraun

Über die Migration der internen Datenbank auf neue Hardware, neue Version oder neues Betriebssystem habe ich in der Vergangenheit schon oft berichtet (siehe Link).

Mit der PostgreSQL Datenbank als interne Datenbank sind gegenüber früheren Migrationen (DP 6 und DP 7) ein paar mehr Schritte notwendig, diese sind jedoch recht einfach umzusetzen. In der Anleitung wird die Migration von DP 9.0x nach DP 9.0x auf neue Hardware (oder virtuelle Maschine) unter Beibehaltung des Server Namen, IP Adresse, Installationspfade, Passwörter, usw. beschrieben. Somit fallen ein paar Schritte verglichen zu einer früheren Anleitung (siehe Link) weg. Diese Anleitung kann prinzipielle auch für die Migration von Windows 2008 R2 auf Windows 2012 und Windows 2012 R2 genutzt werden. Eine Migration auf Windows 2016 ist zum derzeitigen Stand noch nicht möglich, da der Cell Manager (wie auch DA, MA, …) wahrscheinlich erst mit den Patches für DP 9.08 (build 113) im Janaur (Hinweis: keine Garantie) unterstützt wird. Die Schritte können auch für eine Migration eines Linux Cell Servers angewendet werden, da die Befehle aus Data Protector Sicht identisch sind.

Für die nachfolgenden Schritte wurde eine Migration von Data Protector 9.08 nach Data Protector 9.08 unter Windows 2012 R2 durchgeführt (virtuelle Maschine), die Installationspfade waren an der Quelle und am Ziel auf „C:\Program Files\OmniBack“ und „C:\Programdata\OmniBack“ gesetzt. In der Anleitung wird darauf verzichtet detailliert zu beschreiben welche Schritte notwendig sind um den Ziel-Server vorzubereiten (IP Konfiguration, Domain Join, …). Bei der Migration bleibt der Quell-Server für einen eventuellen Failback erhalten, es wird lediglich das Netzwerk deaktiviert; der Zugriff kann dann über iLO (HPE Proliant Server) oder Konsolensitzung (virtuelle Maschine) durchgeführt werden.

Hinweis: die Anleitung ist eine von mehreren Möglichkeiten eine Migration durchzuführen. Einen noch schnelleren Weg stelle ich in einem weiteren Artikel vor.

Damit der Umzug erfolgreich durchgeführt werden kann, sind einige Voraussetzungen zu erfüllen; des Weiteren ist die Migration an einige Bedingungen geknüpft. Für die Anleitung kann keine Garantie übernommen werden.

Voraussetzungen und Bedingungen:

• Der Befehl omnidbcheck -extended liefert keine Fehler. Erfolgreicher omnidbcheck:
  

  PS C:\Users\Administrator> omnidbcheck -extended
  Check Level             Mode                    Status
  ===========================================================
  Database connection     -connection             OK
  Schema consistency      -schema_consistency     OK
  Datafiles consistency   -verify_db_files        OK
  Database consistency    -database_consistency   OK
  Media consistency       -media_consistency      OK
  SIBF(readability)       -sibf                   OK
  DCBF(presence and size) -bf                     OK
  OMNIDC(consistency)     -dc                     OK
  DONE!
  

• Es gibt keine DCBF 1.0 Dateien (Detail Catalog Binary Files aus einer Migration vor DP 8.XX oder DP 9.0X); die internen Datenbank wurde vollständig migriert. Der Befehl "<OMNIBIN>\perl" omnimigrate.pl -report_old_catalog kann zur Überprüfung genutzt werden. Falls noch alte „Binary Files“ vorhanden sind, so sind diese mit dem Befehl "<OMNIBIN>\perl" omnimigrate.pl -start_catalog_migration zu migrieren. Für weitere Informationen zur DCBF Migration und DCBF Verzeichnissen – siehe Link.
• Dokumentieren der DCBF Verzeichnisse mit dem Befehl omnidbutil -list_dcdirs. Sollten die Verzeichnisse auf unterschiedlichen Mount Points liegen oder zusätzliche Verzeichnisse vorhanden sein, so müssen diese entweder auf dem Ziel-Server konsolidiert werden (Verschieben der Dateien in die Standardverzeichnisse mit anschliessendem „remap_dcdir“) oder vor dem Import der IDB angelegt werden („add_dcdir“).
  

  PS C:\Users\Administrator> omnidbutil -list_dcdirs
  Configured DC directories:
  
   Allocation Sequence
   |        Maximum Usage in MB
   |        |        Maximum Number of Files in Directory
   |        |        |        Minimum Free Space [MB]
   |        |        |        |        Directory
   |        |        |        |        |
  ===========================================================================
   0        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf0
   1        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf1
   2        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf2
   3        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf3
   4        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf4
  
  DONE!
  

• Die verwendeten Benutzernamen und Passwörter (Windows) zum Starten der Data Protector Dienste werden auf dem Ziel-Server/Ziel-Plattform identisch weiterverwendet. Sollte jedoch für den neuen Server andere Benutzernamen und Passwörter verwendet werden, so kann die Anleitung (siehe Link) verwendet werden.
• Die Anleitung ist ausschliesslich für eine Migration von DP 9.0X nach 9.0X gültig (dies schließt nicht ein mögliches Release von 9.1.X ein).
• Der Servername und die IP Adresse werden für den Ziel-Server nicht geändert. Sollte dies notwendig sein, so sind weitere Schritte notwendig (Änderung des Cell Manager für den Client, Änderung des Cell Server Namens, usw.); diese sind nicht Bestandteil dieser Anleitung.
• Der Servername und der Domänensuffix müssen den gültigen Empfehlungen folgen.
• Auf dem Quell-Server ist keine wiederhergestellte Version der internen Datenbank vorhanden (mehrere db80* Verzeichnisse).
• Alle verwendeten Namen sind beispielhaft anzusehen.
• Nach erfolgter Migration ist eine sofortige Sicherung des Servers und der internen Datenbank durchzuführen.
• Die Anleitung gilt nicht für MoM Manager, kann aber für Cell Manager in einer MoM Umgebung eingesetzt werden.
• Auf dem Quell-Server wird nicht StoreOnce Software Deduplication genutzt. Der Umzug einer Jukebox oder File Library sind nicht Bestandteil der Dokumentation, können aber unter Beibehaltung der Verzeichnisse auf dem Ziel-Server einfach kopiert werden.
• Für die Migration werden alle benötigten Dateien in das Verzeichnis „C:\migration“ kopiert und/oder exportiert.

Durchführung der Migration auf dem Quell-Server:

• Stoppen des Data Protector Schedulers mit dem Befehl omnitrig -stop (alternativ die Verzeichnisse „schedules“, „barschedules“, … umbenennen).
• Sicherung der internen Datenbank mit der vorhandenen Backupspezifikation.
• Export des Key Stores mit dem Befehl omnikeytool -export CSFVFile -all und kopieren des Exports von „C:\ProgramData\OmniBack\Config\Server\export\keys“ nach „C:\migration“.
• Export der internen Datenbank mit dem Befehl omnidbutil –writedb <pathname> (C:\migration\writedb). Nach Aufforderung werden die Verzeichnisse DCBF, MSG und META (bei Bedarf weitere Verzeichnisse) in den Migrationsordner kopiert.
  

  PS C:\Users\Administrator> omnidbutil -writedb C:\Migration\writedb
  
  Please make a copy of the following Internal Database directories and
  then press Enter to bring the Internal Database back to a fully operational state:
  
  
          "C:\ProgramData\OmniBack\server\db80\msg\"
          "C:\ProgramData\OmniBack\server\db80\meta\"
          "C:/ProgramData/OmniBack/server/db80/dcbf/dcbf4"
          "C:/ProgramData/OmniBack/server/db80/dcbf/dcbf0"
          "C:/ProgramData/OmniBack/server/db80/dcbf/dcbf3"
          "C:/ProgramData/OmniBack/server/db80/dcbf/dcbf1"
          "C:/ProgramData/OmniBack/server/db80/dcbf/dcbf2"
  

  Bei Verwendung von „VSS Transportable Snapshot“ für Sicherungen, Zero Downtime Backup über SMIS, Exchange, …, kann es notwendig sein weitere Verzeichnisse im db80 Verzeichnis zu kopieren (reportdb, smisdb, sqldb, sysdb, vssdb, und xpdp).

• Stoppen der Data Protector Dienste mit dem Befehl omnisv -stop und die Data Protector Dienste auf manuell setzen.
• Sicherung (=Kopieren nach c:\migration) der vorhandenen obrindex.dat aus dem Verzeichnis „C:\ProgramData\OmniBack\server\db80\logfiles\rlog“.
• Sollten in der Vergangenheit Änderungen an der PostgreSQL Konfiguration vorgenommen worden sein, so sind die Dateien ph_hba.conf, pg_ident.conf und postgresql.conf aus dem Verzeichnis „C:\ProgramData\OmniBack\server\db80\pg“ zu sichern.
• Dokumentation der konfigurierten Benutzer (Impersonation) mit dem befehl omniinetpasswd -list.
• Dokumentation der lokalen Sicherheitsrichtline für „Annehmen der Clientidentität nach Authentifizierung“ (Impersonate a client after authentication) und „Ersetzen eines Tokens auf Prozessebene“ (Replace a process level token).
• Sicherung der Datei omnirc aus dem Verzeichnis „C:\ProgramData\OmniBack“.
• Sicherung von pre- und post-exec Skripten aus dem Verzeichnis „C:\Program Files\OmniBack\bin“.
• Sicherung der Dateien media.log und Ob2EventLog.txt, sowie den Ordner auditing aus dem Verzeichnis „C:\ProgramData\OmniBack\log\server“.
• Sicherung der Site Specific Patches/Hotfixes aus dem Verzeichnis „C:\ProgramData\OmniBack\depot\server“, falls diese auf dem Ziel-Server zur späteren Verteilung benötigt werden.
• Sicherung der Data Protector Konfiguration – Verzeichnis „C:\ProgramData\OmniBack\Config\Server“.
• Sicherung weiterer notwendiger Dateien die nicht Bestandteil der Data Protector Installation sind.
• Alle gesicherten Dateien und Verzeichnisse auf den neuen Server kopieren.
• Server Name und IP Einstellungen notieren.
• Alten Server deaktivieren (in dem Beispiel Netzwerk deaktivieren).

Aktivitäten auf dem Ziel-Server:

• Konfiguration des neuen Servers analog dem alten Server (Servername, IP Adresse, Domain, Benutzer und Gruppen).
• Neu-Installation des HPE Data Protector 9.00 nach „C:\Program Files\Omniback“ und „C:\Programdata\Omniback“.
• Installation der Patches wie auf dem Quell-System.
• Import der internen Datenbank mit dem Befehl omnidbutil –readdb <pathname> (C:\migration\writedb).
• Stoppen der Data Protector Dienste mit dem Befehl omnisv -stop.
• Die DCBF, MSG und META Verzeichnisse werden von „c:\migration“ an die ursprüngliche Stelle kopiert. Der Pfad im Beispiel ist „C:\Programdata\OmniBack\server\db80“. Je nach Konfiguration (siehe oben) werden weitere Verzeichnisse, wie reportdb, smisdb, sqldb, sysdb, vssdb, und xpdp in das „db80“ Verzeichnis zurückkopiert.
• Wiederherstellung (=Kopieren vom Migrationsverzeichnis) der obrindex.dat nach „C:\ProgramData\OmniBack\server\db80\logfiles\rlog“.
• Bei Bedarf Wiederherstellung PostgreSQL Konfigurationsdateien ph_hba.conf, pg_ident.conf, postgresql.conf in das Verzeichnis „C:\ProgramData\OmniBack\server\db80\pg“.
• Wiederherstellung der Datei omnirc in das Verzeichnis „C:\ProgramData\OmniBack“.
• Wiederherstellung von pre- und post-exec Skripten in das Verzeichnis „C:\Program Files\OmniBack\bin“.
• Wiederherstellung der Dateien media.log und Ob2EventLog.txt, sowie des Ordners auditing in das Verzeichnis „C:\ProgramData\OmniBack\log\server“.
• Bei Bedarf Wiederherstellung der Site Specific Patches/Hotfixes in das Verzeichnis „C:\ProgramData\OmniBack\depot\server“.
• Wiederherstellung der Data Protector Konfiguration – Verzeichnis „C:\ProgramData\OmniBack\Config\Server“.
• Starten der Data Protector Dienste mit dem Befehl omnisv -start.
• Kopieren des „Key Stores Files“ (siehe oben) nach „C:\ProgramData\OmniBack\Config\Server\import\keys“ und durchführen des Imports mit dem Befehl omnikeytool -import CSFVFile.
• Impersonation konfigurieren (siehe Dokumentation auf Quell-Server und Link).
• Konfiguration der lokalen Sicherheitsrichtline (siehe Dokumentation auf Quell-Server).
• Anpassen der Konfigurationsdateien global und omnirc (Änderungen an der global benötigen einen Restart der Data Protector Dienste).
• Überprüfung der internen Datenbank mit dem Befehl omnidbcheck -extended. Es dürfen keine Fehler protokolliert werden.
• Überprüfung der Umgebung durch Starten von Sicherungen und Wiederherstellen von Daten vor und nach der Migration.
• Nach erfolgreicher Migration kann der alte Server deaktiviert werden; es wird empfohlen den alten Server für mindestens 7 Tage mit deaktiviertem Netzwerk „aufzubewahren“, bevor er einem anderen Verwendungszweck zugeführt wird.