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 -extended
liefert 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_catalog
liefert 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_migration
genutzt 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_dcdir
undomnidbutil -fixmpos
mü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_catalog
zum Löschen verwendet werden. Bei einem erfolgreichen Löschen wird auch die Dateiglobal
angepasst 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.sql
und führt den Befehlomnidbutil –run_script dcbf_version.sql –detail
aus. Die Ausgabe beinhaltet die Medium ID, das Verzeichnis und die DCBF Version. Medien mit-1
stammen 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.dat
zu 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.dat
sollte 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.dat
undinstallation_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 Ordnerusers
empfiehlt es sich selektiv Einträge aus der altenuserlist
zu übernehmen. - Anpassen der Dateien
hpdp-idb-cp.cfg
undidb.config
im 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\metadata60
zusä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.
Hi Daniel,
I have a doubt at the first steps:
When i run the „omnimigrate.pl -start_catalog_migration“ and the script show that was concluded but the „omnimigrate.pl -report_old_catalog“ show that there are many OLD DCBF and FILENAMES, can i run the „omnimigrate.pl -remove_old_catalog“ ?
I don’t understand why the start_catalog_migration was done but the report show that there are many files….
And after run the „omnimigrate.pl -remove_old_catalog“ how can i remove the old DCBF directories ? I try to remove with CLI and GUI but it doesn’t work.
Diogo
Hi Diogo,
thanks for your reply.
In case you cannot remove the old DCBF directories (I guess you tried it using
omnidbutil -remove_dcdir <PathName>
), you may refer to the part of the guide where I wrote about the backs-lashes and forward-slashes. This is in the most cases the reason why the dcbf directory cannot be removed.In case you migrated the catalog, but the command
omnimigrate.pl -report_old_catalog
still shows files, you have to look for the possible reasons. First, you can use the SQL command posted to find out which media has not been migrated so far and try the procedure for that. The other point might be that during the migration from DP 6,7 to DP 8, a backup was started on exisiting media and therfor the catalog information was written to the old DCBF Directory; so you have the old and new information in the old directories. And, of course, when this happens the DCBF file is purged only when all Information on the media becomes obsolete. In this case I recommend to find out which media is involved and try copy the media to a new one and expire the old one. This should expire the old dcbf file. I had the same situation in my very early DP 6,7 to DP 8 migrations. After I figured it out, I decided to move all „old“ media to a different pool, so that it does not become appended after the migration. I started the catalog migration and was done. The good thing about your doubt is, you just need to wait… once all old media are expired, the DCBF should be removed automatically. If not, export the expired media and reformat it, this will create the DCBF file in the new directories.Hope this explanation helps.
Thanks an best regards
Daniel
Hi Daniel,
Very informative piece….just a couple of suggestions:
– When you mention the files for the devices (first step – IDB Backup), one can use the -file option for the command omnidownload itself to save the configurations in text files.
– You mention „restore or modify“ some files, and it also lists lic.dat file, It is too dangerous to play with it….I’d stick to copy/restore of the file.
Regards,
Nikhil
PS: Similarly inexperienced user(s) might be locked out if they play with UserList…I’d write a word of caution or use GUI in case of ambiguity….:)
Hi Nikhil,
thanks for sharing your thoughts. Yes, you are right, using -file option allows you to directly save the device specification into a file.
With „restore/modifying“ I mean to copy back the files / folders saved previously and of course, the user doing the migration should know what he is doing before copying back any files.
Best regards
Daniel
Thank you so much for this article! This saved me a lot of time when I needed to migrate the box on which Data Protector was installed. Much appreciated!
This page was very useful, thank you. We recently performed the following:
1. Upgrade from DP 8.0 to DP 8.12 on Windows Server 2012
2. Migrate the Cell Manager a new Physical Server on Windows Server 2012 R2
We used this guide to assist us in removing any traces of the old db40\dcbf files. We were unable to remove the old dcbf from the GUI, it would error. Turned out when you do the writedb and check out the exported dat file the slashes in the folder paths for the db40 folders were the wrong way. We fixed that then reimported and were able to remove the folders. The upgrade itself and migration was a piece of cake, almost too easy since data protector is originally a Unix application, everything is right there in that omniback folder. What we did was this:
Upgrade to DP 8.12
1. Stop all DP Services on the Cell Manager
2. Use robocopy to copy the d:\program files\omniback folder to another temporary drive
3. Ran the DP 8.10 upgrade (this failed the first time, but worked when I ran the upgrade as the service account that runs the windows services)
4. The IDB service would not start, however I saw this in my test lab so knew I had to replace the lic.dat in \config\server\cell with the 8.1 licence file I got from webware.hp.com
5. Started the IDB Service
6. Ran the DP 8.12 upgrade
7. We use HP StoreOnce appliances and found that any backup via a Media Agent that was still 8.0 would fail, so we had to upgrade all Media Agents to 8.12 immediately (even though the installation guide has a recommendation to upgrade clients within two weeks, not immediately … thanks HP)
8. Upgraded the remaining clients after a couple of days of successful backups
Migrate Cell Manager to New Server and OS (Windows 2012 to Windows 2012 R2)
1. Built a new server ready to go (different name and IP temporarily)
2. Stop all DP Services on the Cell Manager
3. Use robocopy to copy the d:\program files\omniback folder to another temporary drive
4. Attach temp drive with the omniback folder backup to the new server
5. Shutdown the older server and disconnect from network (so there is no chance of a conflict if someone powers it on)
6. Rename new server to the same name and IP as the old cell manager
7. Install DP 8.10 fresh, making sure to use the exact same install path as the old cell manager
8. Apply DP 8.10 lic.dat
9. Install DP 8.12 Update
10. Stop all DP Services on Cell Manager
11. Copy the omniback folder backup from the old cell manager directly over the top of the new installation folder (overwrite anything and everything)
12. Start DP Services on Cell Manager
13. Voila! Cell Manager is moved.
I assume you’d have issues moving between architectures (x86 to x64) using this method. I moved to x64 a few years ago and since then have used this exact method to move from Windows 2008 to 2008 R2, to 2012 and now to 2012 R2.
Hi Chris,
nice to see you again and that the post was a inspiration for your own migration.
Best regards
Daniel
Hi All,
I am trying to migrate internal database (IDB) from Data Protector Version 7 to Version 9. I don’t find any related information from website or any other resources. If you have any information about steps than please share.
Thanks,
Sagar
Hi All,
I am trying to migrate internal database (IDB) from Data Protector Version 7 to Version 9. I don’t find any related information from website or any other resources. If you have any information about steps than please share and update all.
Thanks,
Sagar