Update 2017/01/09: After some discussions with colleagues… you need to know, that for Data Protector clients “systemd” is used and only on Cell Manager the legacy mode with “xinetd” is leveraged. Even with the legacy mode there is no need to change to “systemd”, as “xinetd” is supported on RHEL too.

There are Data Protector customers interested to use systemd on RHEL 7, instead of xinetd. A colleague (Michael S.) sent a short how to with the required steps.

• Modify file /etc/xinetd.d/omni and change the parameter disable: disable = yes. Optional: Move the file to another location or delete it.
• Create the file data-protector.socket in folder /etc/systemd/system and add the following entries:
  

  [Unit]
  Description=Data Protector Socket
  
  [Socket]
  ListenStream=5555
  Accept=yes
  BindIPv6Only=both
  
  [Install]
  WantedBy=sockets.target
  

• Create the file data-protector@.service in folder /etc/systemd/system and add the following entries:
  

  [Unit]
  Description=Data Protector Server
  
  [Service]
  ExecStart=/opt/omni/lbin/inet -log /var/opt/omni/log/inet.log
  User=root
  StandardInput=socket

• Restart daemon xinetd to deactivate port 5555: systemctl restart xinetd
• Enable the socket data-protector.socket using the command: systemctl enable data-protector.socket
• Start the socket data-protector.socket using the command: systemctl start data-protector.socket
• Verify port 5555 using the command: netstat –an | grep 5555 or ss –ln | grep 5555 or ss –l | grep omni
• If possible try to restart the server to verify the changes made are psersistent.
• As usual, you could leverage telnet for the verification:
  

  [root@rheldp908 ~]# telnet rheldp907 5555
  Trying 192.128.253.132...
  Connected to rheldp907.
  Escape character is '^]'.
  HP Data Protector A.09.00: INET, internal build 110, built on Thu Aug 11 12:37:31 2016
  Connection closed by foreign host.
  

I already wrote several articles on how to migrate the internal database to a new hardware, new Data Protector version, or new operating system (see link).

With the introduction of PostgreSQL as internal database for Data Protector and compared to previous versions (DP 6 and DP 7), some more steps are required to migrate a cell manager to new hardware or operating system. However, if you follow the steps below it will not be a complicated procedure. In the document the migration from DP 9.0x to DP 9.0x on new hardware (or virtual machine) is described. It is assumed that the server name, IP address, installation path, passwords, … stay the same and as it was the case on source server. Hence, some less steps required when compared with a previous article about migration (see link). This document could also be used to migrate from Windows 2008 R2 to Windows 2012 or Windows 2012 R2 (using new hardware). The migration to Windows 2016 is not possible so far, as the Cell Manager (and DA, and MA) are not yet supported. Probably it becomes supported with the patches for DP 9.08 (build 113) in January, but this is not promised and not guaranteed. As the steps used for the migration are mainly DP commands executed, it could be used for migration of a Linux Cell Manager too.

For the runbook below, a migration from Data Protector 9.08 to Data Protector 9.08 on Windows 2012 R2 was done (using a virtual machine), the patches used for the installation on source and target was configured as “C:\Program Files\OmniBack” and “C:\Programdata\OmniBack”. The documentation will not include any information regarding preparation of the target server (IP configuration, domain join, …). In case the migration does not succeed, we keep the source server in order to fail back. However, the network will be deactivated, access could be gained using iLO (assuming it is an HPE Proliant server) or using a console session (in case source server is virtual machine).

Comment: the runbook is one of several ways to run a migration. There will be a even faster way, and I will publish this migration method in a different article.

To run a smooth and successful migration some prerequisites and requirements needs to be met. And as always, no guarantee can be given when the documentation is used.

Requirements and prerequisites:

• The command omnidbcheck -extended must not display any error. Output of 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!
  

• No DCBF 1.0 files (Detail Catalog Binary Files from a migration before to DP 8.XX or 9.0X) are found on the system; the internal database has already been migrated. The command "<OMNIBIN>\perl" omnimigrate.pl -report_old_catalog can be used for validation. In case old “binary files” are found, migrate them first using the command "<OMNIBIN>\perl" omnimigrate.pl -start_catalog_migration. For any additional information, you might refer to link.
• Document the DCBF directories using the command omnidbutil -list_dcdirs. In case the directories are located on several mount points, or in case additional directories were configured, you need to either consolidate on target (move files into the standard folders and run “remap_dcdir”) or create additional folders before you import the IDB (“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!
  

• The configured users and passwords to start the data protector services will be kept identical on the target server. In case different users and password are required, you might use the document – link.
• The runbook can be used for migrating from DP 9.0X to 9.0X only (this does not include a possible upcoming version 9.1.x).
• The server name and the IP address are not changed for the target server (the same information as on source will be used). In case you need to make changes, additional steps like changing Cell Manager name for the clients, change the cell server name, etc.), and this is not part of the documentation.
• The server name and domain suffix needs to follow the usual recommendations.
• On the source server there is no version of a recovered internale database (several db80* directories).
• All used names and directories are to be seen as an example.
• After the migration is done, it is recommended to immediately run a backup of the internal database.
• The documentation does not apply to MoM manager, however, can be used to migrate single Cell Manager in an MoM environment.
• On the source server there is no StoreOnce Software Deduplication used. The migration of jukeboxes or file libraries are not part of the documentation, however, can be simply copied when the same directories and mount points are used on the target server.
• During the migration all important files are copied or exported into the directory “C:\migration”.

Migration tasks on the soruce server:

• Stop the Data Protector schedules using the command omnitrig -stop (or rename the folder “schedules”, “barschedules”, …).
• Backup the internal database using the existing backup specification.
• 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”.
• Export the internal database using the command omnidbutil –writedb <pathname> (C:\migration\writedb). You get prompted to make a copy of the directories DCBF, MSG, and META (depending on configuration more folders are displayed), copy the folders to the migration directory.
  

  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"
  

  If you have used “VSS Transportable Snapshot” during backups, Zero Downtime Backup using SMIS, Exchange, …, it might be necessary to copy additional “db80” directories (reportdb, smisdb, sqldb, sysdb, vssdb, and xpdp).

• Stop the Data Protector services using the command omnisv -stop and modify the Data Protector services to start manual (not automatic when server is restarted).
• Backup (=Copy to c:\migration) the file obrindex.dat in directory “C:\ProgramData\OmniBack\server\db80\logfiles\rlog”.
• If you have changed PostgreSQL configuration files in the past, copy ph_hba.conf, pg_ident.conf and postgresql.conf from “C:\ProgramData\OmniBack\server\db80\pg” in addition.
• Document the configured users (impersonation) using the command omniinetpasswd -list.
• Document the local security policy “Impersonate a client after authentication” and “Replace a process level token”.
• Backup the file omnirc from “C:\ProgramData\OmniBack”.
• Backup pre- and post-exec scripts from “C:\Program Files\OmniBack\bin”.
• Backup the files media.log and Ob2EventLog.txt, and the directory auditing (if used) from “C:\ProgramData\OmniBack\log\server”.
• Backup Site Specific Patches/Hotfixes from “C:\ProgramData\OmniBack\depot\server” if you plan to use the files on the new server.
• Backup the Data Protector configuration – directory “C:\ProgramData\OmniBack\Config\Server”.
• Backup any additional files and folders not part of the Data Protector installation.
• Copy all saved files and folders onto the new server.
• Document server name and IP settings.
• Deactivate the old server (in the example the network is disabled).

Tasks on the target server:

• Configure the new server in the same way as it was done for the old server (server name, IP address, domain, user and groups).
• Install HPE Data Protector 9.00 using path “C:\Program Files\Omniback” and “C:\Programdata\Omniback”.
• Installation of patch bundle and/or patches; use the same version as installed on the source server.
• Import the internal database using the command omnidbutil –readdb <pathname> (C:\migration\writedb).
• Stop the Data Protector services using the command omnisv -stop.
• The folders DCBF, MSG, and META are copied back from “c:\migration” to the original location; the path used in the example “C:\Programdata\OmniBack\server\db80”. Depending on the configuration (see above) you need to copy additional folders, like reportdb, smisdb, sqldb, sysdb, vssdb, and xpdp into “db80” folder.
• Recover (=Copy from Migration folder to target folder) the file obrindex.dat to “C:\ProgramData\OmniBack\server\db80\logfiles\rlog”.
• On demand recover PostgreSQL configuration files ph_hba.conf, pg_ident.conf, and postgresql.conf to “C:\ProgramData\OmniBack\server\db80\pg”.
• Recover the file omnirc to “C:\ProgramData\OmniBack”.
• Recover any pre- and post-exec scripts to “C:\Program Files\OmniBack\bin”.
• Recover the files media.log and Ob2EventLog.txt, and if used, the folder auditing to “C:\ProgramData\OmniBack\log\server”.
• On demand recover Site Specific Patches/Hotfixes to “C:\ProgramData\OmniBack\depot\server”.
• Recover the Data Protector configuration to “C:\ProgramData\OmniBack\Config\Server”.
• Start the Data Protector services using the command omnisv -start.
• Copy the “Key Stores Files” (see above) to “C:\ProgramData\OmniBack\Config\Server\import\keys” and execute the command omnikeytool -import CSFVFile to import the keys.
• Configure impersonation (see documentation on source server and link).
• Configure the local security policy (see documentation on source server).
• Modify the configuration files global and omnirc, if required (Changes to the global file requires a restart of the Data Protector services).
• Verify the integrity of the internal database using the command omnidbcheck -extended. No errors must be displayed.
• Verify the environment by starting backups and restores after the migration.
• After the migration the old server is no longer required and can be deactivated. However, it is recommended to keep it at least for seven days with deactivated network and stopped Data Protector services.