Ü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
undOb2EventLog.txt
, sowie den Ordnerauditing
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
undOb2EventLog.txt
, sowie des Ordnersauditing
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
undomnirc
(Ä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.
Hi.
After completed IDB migration accordingly to your guide,to new server ,and execute
Omnisv start,
I saw that all services in active state (!).
But can’t connect to IDB (got error message in GUI) and found in
E:\OmniBack\log\ hpdp-idb-cp
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
2016-12-11 12:26:11.049 3832 WARNING server login failed: FATAL password authentication failed for user „hpdpidb_app“
2016-12-11 12:26:11.049 3832 WARNING C-0000000000E99270: hpdpidb/hpdpidb_app@::1:49554 Pooler Error: password authentication failed for user „hpdpidb_app“
2016-12-11 12:26:11.518 3832 WARNING C-0000000000E99270: hpdpidb/hpdpidb_app@::1:49568 Pooler Error: pgbouncer cannot connect to server
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
But after change:
E:\OmniBack\server\db80\pg\ pg_hba
From
///////////////////////////////////////////////////////////////////////////
# TYPE DATABASE USER ADDRESS METHOD
#host postgres hpdp 127.0.0.1/32 sspi map=hpdpidb
#host postgres hpdp ::1/128 sspi map=hpdpidb
#host all all 127.0.0.1/32 md5
#host all all ::1/128 md5
//////////////////////////////////////////////////////////////////////////
To:
////////////////////////////////////////////////////////////////////////
host postgres hpdp 127.0.0.1/32 trust
host postgres hpdp ::1/128 trust
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
//////////////////////////////////////////////////////////////////////////////////////
And omnisv stop/start,
DP started to work properly, including omnidbcheck -extended .
Somethig wrong with migration hpdpidb_app user in postgres SQL.
Now DP working with local „trust“ authentication.
Do you have solution for that issue?
Hi Alex,
thanks for the information. I’ll need to investigate…
I experienced a similar problem during the first attempt. When I did not copied the pg configuration files, the migration was successful.
Best regards
Daniel
Hi Alex,
I ran into the same problem. Followed all the relevant steps in this post, everything was lollypop and rainbows until I attempted to run omnidbcheck -extended. It was not possible to connect to the idb. Same errors logged and same behaviour when modifying pg_hba file.
In my case, the source of my pain was that, sometime in the past, someone had changed the password for hpdpidb_app user and forgot to document it anywhere.
So, prior to migrate the IDB on the Source Server, change the password for hpdpidb_app user into something easy to remember (for the migration process only). Then follow the rest of the instructions, and before importing the IDB on the Target Server, set the same password for user hpdpidb_app on the Target Server as well.
So the sequence on the Source Server should be:
– Export Key Store using the command ‚omnikeytool -export CSFVFile -all‘ and copy the file from “C:\ProgramData\OmniBack\Config\Server\export\keys” to “C:\migration”.
– Change password for user hpdpidb_app using the command: ‚omnidbutil -set_passwd hpdpidb_app -pass 1234‘
– Export the internal database using the command ‚omnidbutil –writedb ‚
And the sequence on the Target Server should be:
– Installation of patch bundle and/or patches; use the same version as installed on the source server.
– Change password for user hpdpidb_app using the command: ‚omnidbutil -set_passwd hpdpidb_app -pass 1234‘
– Import the internal database using the command omnidbutil –readdb (C:\migration\writedb).
Then database connection should work fine, just like omnidbcheck -extended.
Hope that helps. And as for danielbraun, thanks a lot for the post: you saved me a lot of trouble and grieve with this nice and neat step-by-step guide!
Cheers.
Hello!
There is a procedure inside the „Installation Guide for HPE Data Protector“ (Version 9.xx ) that
is titled „Migrating a Windows Cell Manager Internal Database to a Different Server“ .
I have tested it several times ( DP 9.08 , from „Windows Server 2008 x64 SP2 German“ to „Windows Server 2008 R2 engl.“ or „WS 2008 SP2 x64 German“ to „Windows Server 2012 R2 German“ and many more).
I had only the last IDB full backup on a LTO tape!
None of my testing worked, many, many errors.
I opened a case with HPE Support, they were sure it must work with the mentioned procedure.
Weeks later another HPE supporter gave me his own IDB migration procedure : it worked fine in the first attempt!!
Your procedure, the „Installation Guide“ and the personal one of HPE supporter are totally different!
Because HPE Data Protector is an Enterprise product there must be a well tested and supported procedure by HPE.
Dirk,
I am having the same issue when trying to restore the IDB from an LTO tape. Can you possibly share the IDB migration procedure that worked for you? Performing a migration from one server to another is very helpful, but in the event that the Cell Manager should crash and you need to restore and recover from tape, this is the situation that I have.
Lee,
I have only now read your reply to my comment. What I got from HPE support is the following and a PDF document with instructions and pictures. I dont know how to insert or send a PDF to this forum.
For the migration, if the hostname and IP address of old and new cell server are the same, then actually, it is the same procedure with maunally IDB restore to original CM.
I would suggestion this action plan:
You should remove current DP installation on new server completely (make sure no omniback folder are present), reinstall DP again, configure device to new server as usual to import IDB backup then follow the steps described in the attached document.
How can I send you this document?
Please share that document.
Thanks
RIP Daniel Braun