Die Migration der internen Datenbank auf eine neue Hardware oder ein neues Microsoft Windows Betriebssystem war in der Vergangenheit und vor Data Protector 8.XX keine große Schwierigkeit. Mit Einführung von PostgreSQL als neue interne Datenbank sind aber mehrere Schritte notwendig, um eine erfolgreiche Migration durchführen zu können. Nachfolgend eine Anleitung, die eine Migration auf neue Hardware, oder zum Beispiel den Umzug von Windows 2008 R2 auf Windows 2012 R2 ermöglichen. 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 und es wird empfohlen die Migration mit einem HP Partner durchzuführen. Für den aufwendigen Artikel freue ich mich über Spenden.
Voraussetzungen und Bedingungen:
- Der Befehl
omnidbcheck -extendedliefert keine Fehler. Für Data Protector 8.10 ist unter Umständen der Hotfix QCCR2A50694 notwendig. Erfolgreicher omnidbcheck:
C:\>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!
- Die alten „Detail Catalog Binary Files“ (pre DP 8.XX) der internen Datenbank wurde vollständig migriert. Der Befehl (Beispiel)
"C:\Program Files\Omniback\bin\perl.exe" omnimigrate.pl -report_old_catalogliefert folgendes Ergebnis:
Old Detail Catalog Binary Files size: DCBF ( 0 files): 0 MB Old filename data files: 0 MB Total: 0 MB
Falls noch alte „Binary Files“ angezeigt werden, so sind diese zunächst zu migrieren. Hierfür kann der Befehl (Beispiel)
"C:\Program Files\Omniback\bin\perl.exe" omnimigrate.pl -start_catalog_migrationgenutzt werden. Falls für „DCBF“ 0 Dateien angezeigt werden, aber immer noch „Old filename data files“ vorhanden sind, so kann das auf Veränderungen an den alten DCBF Verzeichnissen vor oder nach der Migration hindeuten. In diesem speziellen Fall können die DCBF Dateien aus den alten db40 Verzeichnissen in die db80 Verzeichnisse verschoben werden. Ein anschließendesomnidbutil -remap_dcdirundomnidbutil -fixmposmüssen durchgeführt werden. - Der alte Katalog und die alten „Binary Files“ wurden nach der Migration gelöscht (Achtung: siehe Hinweis db40). Falls dieser Schritt noch nicht durchgeführt wurde oder Unsicherheit darüber besteht, so kann der Befehl (Beispiel)
"C:\Program Files\Omniback\bin\perl.exe" omnimigrate.pl -remove_old_catalogzum Löschen verwendet werden. Bei einem erfolgreichen Löschen wird auch die Dateiglobalangepasst und die Unterstützung für den alten Katalog entfernt (SupportOldDCBF=1). - Es dürfen keine DCBF Verzeichnisse aus einer früheren (pre DP 8.XX) Data Protector Version existieren. Der Check kann über die GUI – Internal Database durchgeführt werden. Alternativ kann ein Export der IDB mit dem Befehl
omnidbutil –writedb <Pathname>durchgeführt werden. Nach dem Export und dem Hinweis zu den zu kopierenden Verzeichnissen, darf kein db40 Pfad enthalten sein. Übrigens ist seit Version 8.XX ein Export der IDB auch auf eine verbundene Netzwerkfreigabe möglich. Kontrolle Export auf db40 Verzeichnisse:
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:/Program Files/OmniBack/server/db80/msg" "C:/Program Files/OmniBack/server/db80/meta" "C:/Program Files/OmniBack/server/db80/dcbf/dcbf3" "C:/Program Files/OmniBack/server/db80/dcbf/dcbf0" "C:/Program Files/OmniBack/server/db80/dcbf/dcbf2" "C:/Program Files/OmniBack/server/db80/dcbf/dcbf1" "C:/Program Files/OmniBack/server/db80/dcbf/dcbf4"Hinweis: im Beispiel wurde noch nicht die Trennung nach „Program Files“ und „Programdata“ durchgeführt, siehe hierzu auch Folgepunkte.
- Hinweis db40: Sollten noch DCBF Dateien im db40 Pfad existieren, so kann das verschiedene Ursachen haben. Eine Migration ist unbedingt vor dem Entfernen des alten Katalogs notwendig. Zur Prüfung ob noch „Binary Files“ migriert werden müssen, speichert man
select medium_name, dcbf_directory, dcbf_version from dp_dcbf_info i, dp_dcbf_directory d where i.dcbf_directory_seq_id = d.dp_numkey order by dcbf_version;in die Dateidcbf_version.sqlund führt den Befehlomnidbutil –run_script dcbf_version.sql –detailaus. Die Ausgabe beinhaltet die Medium ID, das Verzeichnis und die DCBF Version. Medien mit-1stammen noch von einer pre DP 8.XX Version und können einzeln mit dem Befehlomnimm -upgrade_dcbf <mediumID>migriert werden. Falls für die Anzeige der DCBF Verzeichnisse im DB40 Pfad (sofern noch vorhanden) ein Back-Slash statt Forward-Slash angezeigt wird, so ist die Datenbank zu exportieren (omnidbutil –writedb <Pathname>), die Dateidpidb.datzu bearbeiten, und die betroffenen Verzeichnisse (siehe Ausgabe vorheriger Punkt) zu ändern (Back-Slash in Forward-Slash). Nun kann über den Befehlomnidbutil –readdb <Pathname>die IDB importiert werden. Über den Befehlomnidbutil -remove_dcdir <PathName>können nun die alten DCBF Verzeichnisse entfernt werden. Der relevante Teil der Dateidpidb.datsollte so aussehen (Beispiel und ohne Trennung „Program Files“ und „Programdata“):
20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1004 C:/Program Files/OmniBack/server/db80/dcbf/dcbf3 214748364800 3 2147483648 100000 44 6964137984 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1001 C:/Program Files/OmniBack/server/db80/dcbf/dcbf0 214748364800 0 2147483648 100000 48 9023758336 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1003 C:/Program Files/OmniBack/server/db80/dcbf/dcbf2 214748364800 2 2147483648 100000 39 6941310976 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1002 C:/Program Files/OmniBack/server/db80/dcbf/dcbf1 214748364800 1 2147483648 100000 40 6340190208 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1005 C:/Program Files/OmniBack/server/db80/dcbf/dcbf4 214748364800 4 2147483648 100000 63 7780794368
- Die Trennung von „Program Files“ und „Programdata“ sollte bereits in der Vergangenheit vollzogen wurden sein. Ist dies nicht der Fall und die Trennung der Verzeichnisse soll während der Migration auf der Ziel-Hardware/Ziel-Plattform durchgeführt werden, so sind besondere Schritte in der Migration notwendig. In dieser Anleitung wurde die Trennung noch nicht vollzogen; die zusätzlichen Schritte sind entsprechend dokumentiert.
- Die verwendeten Benutzernamen und Passwörter (Windows) zum Starten der Data Protector Dienste werden auf der Ziel-Hardware/Ziel-Plattform identisch weiterverwendet. Sollte jedoch für die neue Hardware/Plattform andere Benutzernamen und Passwörter verwendet werden, so kann die Anleitung „Data Protector 8.0 Windows – change user account for DP services“ (Link: https://www.data-protector.org/wordpress/2013/11/data-protector-8-0-windows-change-user-account-dp-services/) genutzt werden.
- Die Anleitung ist nicht für ein Upgrade von pre DP 8.XX Versionen gültig.
- Das Upgrade auf die aktuellste Data Protector 8.XX Version sollte bereits auf dem Quell-System erfolgen, dies erleichtert die anschliessende Migration. Dies sollte jedoch nur dann auf dem Quell-System durchgeführt werden, wenn die Trennung von „Program Files“ und „Programdata“ bereits erfolgt ist. Grund für diese Vorgehensweise ist ein Bug in der Installationsroutine beim Upgrade von DP 8.0X auf 8.10. Im konkreten Fall wird auf dem neuen Server/Betriebssystem die bestehende Version neu installiert und anschließend das Uprade auf dem Ziel-System durchgeführt.
- Der Servername und die IP Adresse ändern sich für den Cell Server auf dem Ziel-System nicht. Sollte dies notwendig sein, so sind weitere Schritte wie das Exportieren der Clients vor der Migration, das Importieren der Clients nach der Migration, das Ändern des Cell Server Namens, usw. durchzuführen (nicht Bestandteil dieser Anleitung).
- Der Servername darf nicht mit einer führenden Zahl, sondern muss mit einem Buchstaben beginnen. Grund hierfür ist eine Limitierung im enthaltenen Anwendungsserver (JBOSS/Tomcat).
- Die interne Datenbank wurde bisher nicht komplett wiederhergestellt und es existieren nicht mehrere DB80 Verzeichnisse (Restore Versionen).
- Alle verwendeten Namen sind beispielhaft anzusehen.
- Nach erfolgter Migration ist eine sofortige Sicherung des Servers und der internen Datenbank durchzuführen. Ein Restore der IDB auf einen Stand vor der Migration ist unter Umständen und insbesondere beim Verändern der Zielverzeichnisse nicht möglich, bzw. nur beim manuellen Bearbeiten der exportierten Datenbank realisierbar.
- Die Anleitung gilt nicht für MoM Umgebungen.
Durchführung der Migration:
- Sicherung der internen Datenbank für einen schnellen Import im Falle eines Fehlers. Hierfür wird eine Jukebox mit mehreren Slots und einem Laufwerk angelegt. Die Bänder werden formatiert und anschliessend eine Sicherung der IDB durchgeführt. Nach der Sicherung wurden die Jukebox Dateien (im Beispiel: e:\IDBSicherung\01..05) in einen Migrationsordner außerhalb des Servers kopiert. Falls lokal nicht genügend Plattenplatz für das Betreiben einer Jukebox vorhanden ist (Jukebox Dateien müssen auf lokalen Platten liegen), so kann alternativ eine Filelibrary mit Speicherung auf einer Netzwerkfreigabe verwendet werden. Die Jukeboxdefinition und die Laufwerksdefinition werden zur Sicherheit in Textdateien gespeichert. Jukeboxdefinition:
E:\Program Files\OmniBack\bin>omnidownload -library IDBSicherung NAME "IDBSicherung" DESCRIPTION "" HOST servername.domain POLICY Jukebox TYPE File REPOSITORY "E:\IDBSicherung\01" "E:\IDBSicherung\02" "E:\IDBSicherung\03" "E:\IDBSicherung\04" "E:\IDBSicherung\05" MGMTCONSOLEURL ""Laufwerksdefinition:
E:\Program Files\OmniBack\bin>omnidownload -device IDBSicherung_Drive01 NAME "IDBSicherung_Drive01" DESCRIPTION "" HOST servername.domain POLICY Jukebox TYPE File POOL "IDBSicherung" LIBRARY "IDBSicherung" CONCURRENCY 10 ENCRCAPABLE BUFFERS 16 BLKSIZE 64 RESTOREDEVICEPOOL NO COPYDEVICEPOOL NO
Im Fehlerfall kann die Ausgabe zur Erstellung der Jukebox verwendet werden (siehe Hilfe zu Befehl
omniupload). - Stoppen des Data Protector Schedulers mit dem Befehl
omnitrig -stop - Export der internen Datenbank mit dem Befehl
omnidbutil –writedb <pathname>(im Beispiel Z:\ExportIDB). Nach Aufforderung werden die Verzeichnisse DCBF, MSG und META in den Migrationsordner ausserhalb des Servers (z.B. Z:\Migration) kopiert. - Stoppen der Data Protector Dienste mit dem Befehl
omnisv -stop - Kopieren der Data Protector Verzeichnisse ausserhalb des Servers (z.B. Z:\Migration). Hierbei kann auf das Kopieren der DCBF, MSG und META Verzeichnisse verzichtet werden, da dies bereits im vorherigen Schritt erfolgt ist. Hinweis: Beim Kopieren werden symbolische Links in der IDB Verzeichnisstruktur komplett kopiert, so dass auf dem Zielsystem entsprechen mehr Plattenplatz zur Verfügung gestellt werden muss. Mit dem Kopieren sind alle Data Protector relevanten Verzeichnisse gesichert, dies gilt nicht für eventuell weitere installierte Dienste auf dem Server.
- Neuinstallation der neuen Hardware oder des neuen Betriebssystems. Für die Installation des neuen Systems sind der gleiche Servername, IP Adresse, Domain, Benutzer und Gruppen zu verwenden. Bei notwendigen Änderungen müssen die anzupassenden Konfigurationsdateien (siehe unten) einzeln geprüft werden.
- Neu-Installation des HP Data Protector 8.XX nach „D:\Program Files\Omniback“ und „D:\Programdata\Omniback“. Es ist die gleiche Version, inklusive Patches, Hotfixes, usw. wie auf dem Quell-System zu installieren.
- Impersonation konfigurieren:
C:\Users\administrator>omniinetpasswd -inst_srv_user domain\administrator User 'domain\administrator' is configured to be used by Installation Server.
- Stoppen der Data Protector Dienste mit dem Befehl
omnisv -stop - Bei Bedarf Anpassung der lokalen Sicherheitsrichtlinie. Dies ist notwendig, wenn für den „Data Protector INET“ Dienst ein personalisierter Account statt NT Authority\SYSTEM verwendet werden soll. Der verwendete Benutzer muss in der lokalen Sicherheitsrichtline bei den Policies „Impersonate a client after authentication“ = „Annehmen der Clientidentität nach Authentifizierung“ und „Replace a process level token“ = „Ersetzen eines Tokens auf Prozessebene“ hinzugefügt werden.
- Die DCBF, MSG und META Verzeichnisse werden an ihre neue Stelle kopiert. Der Pfad im Beispiel ist
D:\Programdata\OmniBack\server\db80. - Ändern der DCBF Verzeichnisse in der Datei
dpidb.dat(siehe Export der internen Datenbank). Dieser Schritt ist nur notwendig, wenn die Zielverzeichnisse während der Migration geändert wurden. Ändern der DCBF Verzeichnisse von:
COPY dp_catalog_dcbf_directory (db_uuid, seq_id, dcbf_directory, maxsize, fill_sequence, min_freespace, max_dcbf_files, cur_num_of_files, cur_occupied_space) FROM stdin; 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1002 E:/Program Files/OmniBack/server/db80/dcbf/dcbf1 214748364800 1 2147483648 100000 47 6341406720 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1004 E:/Program Files/OmniBack/server/db80/dcbf/dcbf3 214748364800 3 2147483648 100000 44 6964137984 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1001 E:/Program Files/OmniBack/server/db80/dcbf/dcbf0 214748364800 0 2147483648 100000 48 9023758336 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1003 E:/Program Files/OmniBack/server/db80/dcbf/dcbf2 214748364800 2 2147483648 100000 39 6941310976 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1005 E:/Program Files/OmniBack/server/db80/dcbf/dcbf4 214748364800 4 2147483648 100000 63 7780794368
Ändern der DCBF Verzeichnisse auf:
COPY dp_catalog_dcbf_directory (db_uuid, seq_id, dcbf_directory, maxsize, fill_sequence, min_freespace, max_dcbf_files, cur_num_of_files, cur_occupied_space) FROM stdin; 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1002 D:/ProgramData/OmniBack/server/db80/dcbf/dcbf1 214748364800 1 2147483648 100000 47 6341406720 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1004 D:/ProgramData/OmniBack/server/db80/dcbf/dcbf3 214748364800 3 2147483648 100000 44 6964137984 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1001 D:/ProgramData/OmniBack/server/db80/dcbf/dcbf0 214748364800 0 2147483648 100000 48 9023758336 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1003 D:/ProgramData/OmniBack/server/db80/dcbf/dcbf2 214748364800 2 2147483648 100000 39 6941310976 20cf4d3f-d425-4f01-8823-9b9e9dcfa72c 1005 D:/ProgramData/OmniBack/server/db80/dcbf/dcbf4 214748364800 4 2147483648 100000 63 7780794368
- Selektives Wiederherstellen (Kopieren) der Dateien in
D:\Programdata\OmniBack\log\server. Relevant sind Dateien wiemedia.log,Ob2Event.*und der Ordnerauditing. - Anpassen, bzw. Wiederherstellen der Konfigurationsdateien
global(Beispiel:D:\ProgramData\Omniback\Config\Server\Options) undomnirc(Beispiel:D:\ProgramData\Omniback). - Anpassen, bzw. Wiederherstellen der Dateien
cell_info,lic.datundinstallation_servers. Hinweis: Nach dem Upgrade auf DP 8.1X sind bisherige Lizenzen ungültig und müssen über http://webware.hp.com neu generiert werden. Dies setzt einen gültigen Wartungsvertrag voraus. - Wiederherstellen (Kopieren) der Ordner:
BarLists, Barschedules, consolidationlists, copylists, Datalists, dlgroups, dr, Integ, rptgroups, rptschedules, Schedules, users. Für die Dateien im Ordnerusersempfiehlt es sich selektiv Einträge aus der altenuserlistzu übernehmen. - Anpassen der Dateien
hpdp-idb-cp.cfgundidb.configim Verzeichnis (Beispiel)D:\ProgramData\Omniback\Config\Server\idb. In beiden Dateien müssen die Pfade angepasst werden.
Beispiel hpdp-idb-cp.cfg:[databases] hpdpidb = host=127.0.0.1 port=7112 dbname=hpdpidb [pgbouncer] service_name=hpdp-idb-cp listen_addr = * listen_port = 7113 unix_socket_dir = /tmp auth_type = md5 admin_users = hpdp stats_users = hpdp pool_mode = transaction server_reset_query = ignore_startup_parameters = application_name,extra_float_digits server_check_query = select 1 server_check_delay = 10 max_client_conn = 1200 default_pool_size = 50 query_wait_timeout = 10 log_connections = 0 log_disconnections = 0 log_pooler_errors = 1 logfile = D:\ProgramData\OmniBack\log\hpdp-idb-cp.log pidfile = D:\ProgramData\OmniBack\log\hpdp-idb-cp.pid auth_file = D:\ProgramData\OmniBack\config\server\idb\ulist
Beispiel idb.config:
PGHOSTNAME='localhost'; PGIDBNAME='hpdpidb'; PGUSER='hpdpidb_app'; PGPASSWORD='bWhhbnTvZ3Xxbao2Zw=='; PGSUPERUSER='hpdp'; PGSUPERPASSWORD='anpabZl3bnh6dGY3eQ=='; PGMAXOPEN_CONN_NUMBER='5'; PGDATA_PG='D:\ProgramData\OmniBack\server\db80\pg'; PGDATA_IDB='D:\ProgramData\OmniBack\server\db80\idb'; PGDATA_JCE='D:\ProgramData\OmniBack\server\db80\jce'; PGOSUSER='domain\administrator'; PGPORT='7112'; PGCPPORT='7113'; PGWALPATH='D:\ProgramData\OmniBack\server\db80\pg\pg_xlog_archive'; IDB_SEC_FLAG='11';
- Bei Bedarf und je nach Konfiguration müssen weitere Ordner wiederhergestellt werden. Beispielsweise wird bei einer Exchange Sicherung der Ordner (Beispiel)
D:\ProgramData\Omniback\server\db80\vssdb\metadata60zusätzlich benötigt. - Starten der Data Protector Dienste mit dem Befehl
omnisv -start. - Stoppen des Data Protector Schedulers mit dem Befehl
omnitrig -stop. - Import der Datenbank mit dem Befehl
omnidbutil -readdb <pathname>(im Beispiel Z:\ExportIDB). - Stoppen der Data Protector Dienste mit dem Befehl
omnisv -stop. - Starten der Data Protector Dienste mit dem Befehl
omnisv -start. - Ü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 die verwendete Jukebox (IDBSicherung) und die verwendeten Verzeichnisse entfernt werden. Die anderen für die Migration verwendeten Verzeichnisse sollten zur Sicherheit für mindestens 7 Tage aufbewahrt werden.
- Nun kann bei Bedarf und falls nicht bereits auf dem Quell-System durchgeführt, das Upgrade auf die aktuelle Data Protector Version durchgeführt werden.