Clustered Cell Manager requires omnirc parameter

I just stumbled across an issue introduced with Data Protector A.08.00 and the new PostgreSQL database on clustered Cell Managers running on Linux and HP-UX. It’s related to restoration of IDB configuration files back to the shared disk.

IDB Configuration Restore

As you might know, parts of the Data Protector installation are stored on shared disk for a clustered configuration. The directory structure remains the same, but symlinks will point to the shared disk. This is true for the IDB located in /var/opt/omni/server and the configuration files stored in /etc/opt/omni/server.

[root@linux~]# ls -al /etc/opt/omni/server
lrwxrwxrwx 1 root hpdp 24 May 9 14:02 /etc/opt/omni/server -> /ob2/etc_opt_omni_server

To allow the IDB integration agent postgres_bar.exe to follow the symlinks properly, you must define OB2SGENABLED=1 as an omnirc parameter on all cluster nodes that are enabled to run the Data Protector Cell Manager cluster package with Data Protector 8 and later.

Please note, if this parameter is defined, the file /opt/omni/.omnirc is not backed up as a part of the IDB backup since it is local to each node. It should be included in the regular file system backup of your cluster nodes.

Clean up after Data Protector IDB restore

IDB restore with Data Protector 8 and later is really straight forward. It allows a much more granular recovery than in previous versions, since it’s done using a fully featured module instead of a file system hot-backup. You’re able to restore the IDB (PostgreSQL database) including log file recovery, DCBF files and configuration files individually or all together in a one-step process.

To be able to recovery, you need a valid backup first. Regular IDB backups are strongly recommended and can be created at any given time without interrupting backup operation.

On a Linux Cell Manager the Internal Database is located in /var/opt/omni/server/db80. For this example I will restore the database to /var/opt/omni/server/db80_restore since it cannot be overwritten and all commands I’ll use later will refer to this path. If you need to adjust that, change the commands accordingly or make the changes manually using a text editor of your choice.

Once the restore has been done, the Cell Manager will be up and operational. Just reconnect the GUI, since the IDB was switched during the process. Now it’s time to check if the restored version of the backup suits your needs. If everything is fine, we can start our clean up.

Please note: The clean up is disruptive to the service (we need to bring down Data Protector services) and should be scheduled in a maintenance window. It is not required for operation after a recovery, but I recommend it. It removes stale files and directories from file system and make directory structure look like before the restore. It can be done immediately or weeks after the restore. Create a tarball of /etc/opt/omni and /var/opt/omni to allow fail-back.

  • Stop the services and check restored directory structure
[root@linux ~]# omnisv stop
Cell Server services successfully stopped.

[root@linux ~]# ls -l /var/opt/omni/server
drwxr-xr-x 5 hpdp hpdp 4096 May 9 12:44 AppServer
drwxr-xr-x 19 root sys 4096 May 10 10:52 db80
drwxrwxrwx 5 root root 4096 May 10 10:49 db80_restore
drwxr-xr-x 4 root sys 4096 Mar 17 18:21 export
drwxr-xr-x 4 root sys 4096 Mar 17 18:21 import
drwxr-xr-x 4 root sys 4096 May 10 10:48 log
drwxr-xr-x 2 root sys 4096 Mar 17 18:21 sessions

[root@linux ~]# ls -l /var/opt/omni/server/db80_restore
drwx------ 3 hpdp hpdp 4096 May 10 10:49 idb
drwx------ 3 hpdp hpdp 4096 May 10 10:49 jce
drwx------ 15 hpdp hpdp 4096 May 10 10:56 pg
  • Move the restored database in the target directory and adjust symlinks. Please note: the name of the symlinks might vary on your Cell Manager.
[root@linux ~]# rm -rf /var/opt/omni/server/db80/idb
[root@linux ~]# rm -rf /var/opt/omni/server/db80/jce
[root@linux ~]# rm -rf /var/opt/omni/server/db80/pg

[root@linux ~]# mv /var/opt/omni/server/db80_restore/* /var/opt/omni/server/db80/

[root@linux ~]# ls -l /var/opt/omni/server/db80/pg/pg_tblspc
lrwxrwxrwx 1 hpdp hpdp 37 May 10 10:49 16387 -> /var/opt/omni/server/db80_restore/idb
lrwxrwxrwx 1 hpdp hpdp 37 May 10 10:49 16445 -> /var/opt/omni/server/db80_restore/jce

[root@linux ~]# ln -sf /var/opt/omni/server/db80/idb /var/opt/omni/server/db80/pg/pg_tblspc/16387
[root@linux ~]# ln -sf /var/opt/omni/server/db80/jce /var/opt/omni/server/db80/pg/pg_tblspc/16445
  • Update configuration files accordingly. Please note: more complex changes should be done using a text editor
[root@linux ~]# perl -p -i -e 's/db80_restore/db80/g' /var/opt/omni/server/db80/pg/postgresql.conf
[root@linux ~]# perl -p -i -e 's/db80_restore/db80/g' /var/opt/omni/server/db80/pg/postmaster.opts
[root@linux ~]# perl -p -i -e 's/db80_restore/db80/g' /etc/opt/omni/server/idb/idb.config
[root@linux ~]# perl -p -i -e 's/db80_restore/db80/g' /etc/init.d/hpdp-idb
  • Additional clean up, depending on your configuration
[root@linux ~]# rm -rf /var/opt/omni/server/db80_restore
[root@linux ~]# rm -rf /var/opt/omni/server/db80/msg_*
[root@linux ~]# rm -rf /var/opt/omni/server/db80/meta_*
[root@linux ~]# rm -rf /var/opt/omni/server/log/auditing_*
  • Start the services and do basic verification
[root@linux ~]# omnisv start -idb_only
The Internal database services successfully started.

[root@linux ~]# omnisv status
    ProcName      Status  [PID]
    crs         : Down
    mmd         : Down
    kms         : Down
    hpdp-idb    : Active  [31686]
    hpdp-idb-cp : Active  [31707]
    hpdp-as     : Down
    omnitrig    : Down
    Sending of traps disabled.
Status: At least one of the Cell Server processes/services is not running.

[root@linux ~]# grep PGSUPERUSER /etc/opt/omni/server/idb/idb.config
[root@linux ~]# grep PGPORT /etc/opt/omni/server/idb/idb.config

[root@linux ~]# su - hpdp
[hpdp@linux ~]$ /opt/omni/idb/bin/psql -U hpdp -h /var/opt/omni/tmp -p 7112 postgres

postgres=# SELECT spcname, spclocation FROM pg_tablespace;
  spcname   |          spclocation
 pg_default |
 pg_global  |
 hpdpidb    | /var/opt/omni/server/db80_restore/idb
 hpjce      | /var/opt/omni/server/db80_restore/jce
(4 rows)

postgres=# UPDATE pg_tablespace SET spclocation = '/var/opt/omni/server/db80/idb' where spcname='hpdpidb';
postgres=# UPDATE pg_tablespace SET spclocation = '/var/opt/omni/server/db80/jce' where spcname='hpjce';

postgres=# \q
[hpdp@linux ~]$ exit

[root@linux ~]# omnisv start
Cell Server services successfully started.

[root@linux ~]# 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

[root@linux ~]# omnib -idb_list LINUX_IDB -barmode full


[Normal] From: "LINUX_IDB" Time: 05/10/2014 12:44:16 PM
OB2BAR application on "" successfully started.

[Normal] From: "DPIDB" Time: 05/10/2014 12:44:16 PM
Checking the Internal Database consistency

[Normal] From: "DPIDB" Time: 05/10/2014 12:44:17 PM
Check of the Internal Database consistency succeeded

[Normal] From: "DPIDB" Time: 05/10/2014 12:44:17 PM
Putting the Internal database into the backup mode finished

Re-initialize Data Protector IDB (PostgreSQL)

This post will show you how to re-initialize the Internal Database of Data Protector 8 or later to start from scratch without the need for re-installation. This was quite simple on previous versions and needs to be adjusted for the new PostgreSQL database and JBoss application server. These instructions will work on Linux and HP-UX. If I find a proper way for Windows, I’ll update this post.

Starting from scratch means the content of the IDB and the certificates used for authentication will be lost. You have been warned! This is acceptable for my test systems.

First shut down the services and remove some files and directories from the filesystem

[root@linux ~]# omnisv stop
HP Data Protector services successfully stopped.
[root@linux ~]# rm -rf /etc/opt/omni/server/AppServer
[root@linux ~]# rm -rf /etc/opt/omni/server/idb
[root@linux ~]# rm -rf /var/opt/omni/server
[root@linux ~]# rm -rf /tmp/*

Now copy relevant files from newconfig directory

[root@linux ~]# cp -aR /opt/omni/newconfig/etc/opt/omni/server/AppServer /etc/opt/omni/server/
[root@linux ~]# cp -aR /opt/omni/newconfig/etc/opt/omni/server/idb /etc/opt/omni/server/
[root@linux ~]# cp -aR /opt/omni/newconfig/var/opt/omni/server /var/opt/omni/

The last step is to run the which usually runs during installation time to initialize the IDB and Application server

[root@linux ~]# /opt/omni/sbin/
NOTE: No Data Protector A.08.10 Internal Database found. Initializing...
Configuring and starting up Internal Database... Done!
Configuring and starting up Internal Database Connection Pool... Done!
Initializing Internal Database version A.08.10... Done!
Configuring and starting up Application Server... Done!
Setting Internal Database passwords... Done!
Starting up Data Protector Services... Done!
NOTE: Data Protector A.08.10 Internal Database initialized.

[root@linux ~]# omnisv status
ProcName Status [PID]
crs : Active [30520]
mmd : Active [30518]
kms : Active [30519]
hpdp-idb : Active [28234]
hpdp-idb-cp : Active [28058]
hpdp-as : Active [28665]
omnitrig : Active
Sending of traps disabled.
Status: All Data Protector processes/services up and running.

[root@linux ~]# 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

Failed to open Data Protector GUI: Internal Error

I just came across a strange Data Protector User Interface error. After a fresh installation the DP GUI reported the following error during first start.

Internal Error
Non-recoverable error: (0)
Failed to initialize the working environment.
System error: Unknown

The debug.log created in the home directory of the user had the following error in it that pointed to the source of the error, wrong permissions on the OpenView registry key.

05.05.2014 16:01:09 MANAGER.3472.3460 [“/lib/cmn/win32_registry.c $Rev: 39353 $ $Date:: 2013-10-04 14:54:49”:200] A.08.10 b200
[RegOpenKey2] RegOpenKeyEx failed to open key! Errno: 5

05.05.2014 16:01:09 MANAGER.3472.3460 [“/lib/cmn/win32_registry.c $Rev: 39353 $ $Date:: 2013-10-04 14:54:49”:125] A.08.10 b200
Function RegReadDWORD – error details:
keyName = SOFTWARE\Hewlett-Packard\OpenView\OmniBackII\Common\Parameters
retval = 5 ([5] Access is denied. )
value = 1L

Using regedit I discovered other HP software products sharing the same Hewlett-Packard registry key. It seems that HP ProtectTools Security Manager was installed first and created the key Hewlett-Packard with some strange permissions and ownership.

The result was nobody was able to open the OpenView key and all elements below.

I had to change the owner of the key Hewlett-Packard from Administrators to SYSTEM, enabled inheritance and selected replace all child object permissions. As a security measure, I reinstalled the GUI and now everything was working as expected.

This happened with HP ProtectTools Security Manager (sp63727.exe) running Windows 8.1 installed on a HP ProBook 6570b.

Delete db40\dcbf folder after migration to DP 8.x

If you migrate from a previous version to Data Protector A.08.00 or later on Windows, you might come across an issue where you’re unable to remove the old db40\dcbf directories using GUI or omnidbutil -remove_dcdir. This is most likely caused by the used path separator inside the Internal Database. Since version 8 the path separator is a simple / for UNIX and Windows platforms.

General requirements to remove a DCBF directory

  • No active DCBF file should point to this directory: Move any actively used DCBF files to a different DCBF directory and run omnidbutil -remap_dcdir
  • Don’t move any non-active DCBF files (most likely created due to an crash or similar) to a new db80 DCBF directory: Best way is to move the DCBFs to a temporary directory first, run omnidbcheck -bf and move back only DCBFs that are marked with as ERROR
  • Keep in mind that the DCBF name is related directly to the media id, just replace underscores (_) with colons (:) and strip away the last section: you can use omnimm -media_info 9ccb19ac:5350e998:555a:0298 to get details for DCBF 9ccb19ac_5350e998_555a_0298_22EA5053.dat

How to remove an empty DCBF directory with wrong path separator inside the IDB

The idea here is not to follow the instructions from, since omnidbutil -writedb is not always possible and might be dangerous. I just created a simple SQL script that will change the wrong path separator and make regular removal possible.

C:\>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     O:/OmniBack/db40/dcbf
4        204800   100000   2048     O:/OmniBack/server/db80/dcbf/dcbf4
3        204800   100000   2048     O:/OmniBack/server/db80/dcbf/dcbf3
2        204800   100000   2048     O:/OmniBack/server/db80/dcbf/dcbf2
1        204800   100000   2048     O:/OmniBack/server/db80/dcbf/dcbf1
0        204800   100000   2048     O:/OmniBack/server/db80/dcbf/dcbf0

C:\>notepad C:\temp\dcbf_dir_fix.sql
--Displays DCBF directories before modification
SELECT dcbf_directory from dp_catalog_dcbf_directory;
--Fixes wrong path separator for db40 DCBF directories on Windows CM
UPDATE dp_catalog_dcbf_directory SET dcbf_directory = replace(dcbf_directory, '\', '/');
UPDATE dp_catalog_dcbf_directory SET dcbf_directory = replace(dcbf_directory, '\\', '/');
--Displays DCBF directories after change
SELECT dcbf_directory from dp_catalog_dcbf_directory;

C:\>omnidbutil -run_script C:\temp\dcbf_dir_fix.sql -detail
(6 rows)
(6 rows)

C:\>omnidbutil -remove_dcdir O:/OmniBack/db40/dcbf

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

Data Protector Quick Fixes

There are situations in which you receive test modules or quick fixes from HP support to resolve a specific issue in your environment. Even if they provide instructions on how to apply them, I found the following general procedure working quite well for Linux clients and cell managers.

  • Upload the fix to the client system that need to be updated
decm01:/tmp/QCCR # ls -al

total 2132

drwxr-xr-x 2 root root 4096 Sep 4 19:29 .

drwxrwxrwt 6 root root 4096 Sep 4 19:28 ..

-rw-r--r-- 1 root root 2170880 Sep 4 19:23 QCCR2A39087_TM4.tar
  • Extract the archive provided by HP support to a new directory and examine documentation included
decm01:/tmp/QCCR # /bin/mkdir QCCR2A39087_TM4

decm01:/tmp/QCCR # /bin/tar xf QCCR2A39087_TM4.tar -C QCCR2A39087_TM4

decm01:/tmp/QCCR # cd QCCR2A39087_TM4

decm01:/tmp/QCCR/QCCR2A39087_TM4 # ls -al

total 2132

drwxr-xr-x 2 root root 4096 Sep 4 19:29 .

drwxr-xr-x 3 root root 4096 Sep 4 19:29 ..

-rw-r--r-- 1 27419 users 971 Aug 29 07:53 README.txt

-r-x------ 1 27419 users 2164336 Aug 29 07:45 csm

decm01:/tmp/QCCR/QCCR2A39087_TM4 # /usr/bin/less README.txt
  • Check if the new binaries are running on the system and reports a valid build number
decm01:/tmp/QCCR/QCCR2A39087_TM4 # /usr/bin/file csm

csm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked [...]

decm01:/tmp/QCCR/QCCR2A39087_TM4 # /usr/bin/ldd csm => (0x00007fff04df9000) => /opt/omni/lib/ (0x00007f666845d000) => /opt/omni/lib/ (0x00007f6668355000) => /opt/omni/lib/ (0x00007f6668242000) => /opt/omni/lib/ (0x00007f6668140000) => /opt/omni/lib/ (0x00007f6668026000) => /opt/omni/lib/ (0x00007f6667f20000) => /lib64/ (0x00007f6667c7e000) => /lib64/ (0x00007f6667a79000) => /usr/lib64/ (0x00007f666776f000) => /opt/omni/lib/arm/ (0x00007f666766e000) => /opt/omni/lib/ (0x00007f6667568000) => /lib64/ (0x00007f66671f4000) => /lib64/ (0x00007f6666fd7000)

/lib64/ (0x00007f666856b000) => /lib64/ (0x00007f6666dc0000)

decm01:/tmp/QCCR/QCCR2A39087_TM4 # ./csm

HP Data Protector A.07.00: CSM, internal build QCCR2A39087_TM4, built on [...]
  • Locate the binaries to be replaced (only csm in that case), create a backup including permissions
decm01:/tmp/QCCR/QCCR2A39087_TM4 # which csm


decm01:/tmp/QCCR/QCCR2A39087_TM4 # /bin/cp -a /opt/omni/lbin/csm{,.`/bin/date +%Y%m%d`}
  • Replace the files and check if build number is reported correctly for each one and their backup. You might need to shutdown Data Protector services using omnisv stop in advance. Adjust permissions and ownership not matching the backup.
decm01:/tmp/QCCR/QCCR2A39087_TM4 # /bin/cp csm /opt/omni/lbin/csm

decm01:/tmp/QCCR/QCCR2A39087_TM4 # /bin/ls -al /opt/omni/lbin/csm*

-r-x------ 1 root sys 2164336 Sep 4 19:31 /opt/omni/lbin/csm

-r-x------ 1 root sys 1955592 Jul 22 21:23 /opt/omni/lbin/csm.20120904

decm01:/tmp/QCCR/QCCR2A39087_TM4 # /opt/omni/lbin/csm

HP Data Protector A.07.00: CSM, internal build QCCR2A39087_TM4, built on [...]

decm01:/tmp/QCCR/QCCR2A39087_TM4 # /opt/omni/lbin/csm.20120904

HP Data Protector A.07.00: CSM, internal build 100, built on Tue Jul 24 09:51:39 2012
  • Start the services if stopped using omnisv start and check if the installed test module is working as expected. omnicheck -patches should list the non-standard binaries.

Keep in mind to track applied Quick Fixes if you’re going to install GR patches to your cell. Check the release notes of the fixes to make sure the issue has been resolved.

Data Protector Push installation for Debian clients

Integrating Debian or Debian-based Linux clients (e.g. Ubuntu) into a Data Protector cell could be a pain, if you have more than a bunch of them. Patch rollout and release upgrades will even take more time if you poke around with alien to convert the Data Protector rpm into deb format. There are some simple requirements that will allow you to leverage Data Protector Push installation method for Linux/UNIX even for Debian-based distributions:

  1. Name resolution work from client to IS and client to CM plus the other way around (DNS preferred)
  2. /etc/services must not contain any definition for 5555/tcp
  3. The packages xinetd and rpm must be installed
  4. root SSH login must be enabled on the client using public keys
  5. Use FQDN for all operations on CLI and GUI

With that information in mind, we can do the required modifications to our Debian 6.0 client and push the Data Protector Disk Agent (DA) to the system when ready.

  • Check for Debian and kernel version running (for your reference only)
root@decm01:~# /bin/cat /etc/debian_version


root@decm01:~# /bin/uname -a

Linux decm01 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
  • Check if the port 5555/tcp is not blocked by any entry other than omni (looks good on Debian squeeze)
root@decm01:~# /bin/grep 5555 /etc/services

rplay 5555/udp # RPlay audio service
  • Installation of required packages for Data Protector push installation on Debian client
root@decm01:~# /usr/bin/apt-get install xinetd rpm
  • Allow password-less access to Debian system using SSH: command is run from prepared UNIX IS
[root@deis01 ~]# /usr/bin/ssh-copy-id -i /root/.ssh/


The authenticity of host ' (' can't be established.

RSA key fingerprint is df:97:00:b2:62:33:1d:1e:fc:57:f7:94:bb:c5:f7:ba.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ',' (RSA) to the list of known hosts.'s password:

Now try logging into the machine, with "ssh ''", and check in:


to make sure we haven't added extra keys that you weren't expecting.
  •  Now try the remote installation from UNIX IS to new client (DA only in my case)

[Normal] Starting installation session on Dienstag, 14. August 2012, 20:24:54...

[Normal] Getting list of clients for installation...

[Normal] Connecting to client

[Normal] <> Checking for response from system

[Normal] <> Using secure shell protocol to connect to clients ...

[Normal] Client (Linux 2.6.32-5-amd64) OK.

[Normal] <> Starting installation/update for client system at...

[Normal] <> Installing Core Component

[Normal] <> Installation of Core Component succeeded.

[Normal] <> Installing Disk Agent

[Normal] <> Installation of Disk Agent succeeded.

[Normal] <> Update of client system completed.

[Normal] Installation session finished on Dienstag, 14. August 2012, 20:25:02.


Session completed successfully!

  • If the client is imported to cell automatically, everything is fine. Verify if the rpm files are installed and the service responds to requests locally
root@decm01:~# /usr/bin/rpm -qa



root@decm01:~# /usr/bin/telnet localhost 5555


Connected to localhost.

Escape character is '^]'.

HP Data Protector A.06.20: INET, internal build 403, built on Fri Jun 15 23:33:35 2012

Connection closed by foreign host.

Restore from NDMP device mirror

I just came across an issue at customer site where Data Protector Device Mirror was used to duplicate NDMP backups. In general this is a great way to reduce the amount of time it takes to create separate sets of media at backup time. The worse thing is, this feature is not supported in Data Protector including version 7.01.

The backup will work as expected, but if you need to restore from the tape that was created using Mirror (not the original one) the session will just fail with the following error. Keep in mind, the restore from the original/primary media is working fine.

[Normal] From: "" Time: 01.08.2012 13:56:35

Restore session 2012/08/01-50 started.

[Normal] From: "MSL8096_D2" Time: 01.08.2012 13:56:38

STARTING Media Agent "MSL8096_D4"

[Normal] From: "MSL8096_D2" Time: 01.08.2012 13:56:41


Loading medium from slot 3 to device c32t0l0

[Major] From: "" Time: 01.08.2012 13:57:27

Unknown internal error.

This looks pretty familiar, since there was the defect QCCR2A34355 that prevented NDMP restores from completing on 6.20 and 7.00.

DP 6.2 NDMP Restore with unknown error

Even with fixes/patches in place, the restore from Device Mirror (copy) will fail. This seems to be an issue with metadata not written correctly to DCBFs. omnidbcheck -sibf will show inconsistencies on all media used for device mirror.

I found a workaround for this issue that works pretty straight forward and allows you to restore the data.

  1. Identify the media(s) required for restore/restore chain using the restore dialog
  2. Load the tapes into library if not already present and perform barcode scan
  3. Check which session is stored on media(s)
  4. Remove data protection from session(s) in IDB that is used on that media to allow export (if not already expired)
  5. Export media(s) in question from IDB (right click on Slot -> Export)
  6. Import the media(s) in question back to IDB (right click on Slot -> Import) / make sure you select “Import Copy as Original” and “Log all”

Patch Data Protector standalone client

There are cases in with you need to apply GA patches to a UNIX client and you don’t have an Data Protector UNIX IS (Installation Server) available. This is worse, because the patches are designed to update an installation server only. The following procedure will help you out. Instead of applying the patches to an IS, we’ll just extract the desired target platform patch from the archive. I’ll demonstrate how this is done with DPLNX_00200.tar for DP 6.20.

  • Download the patches and extract the tarball
    tar xf DPLNX_00200.tar
  • Review the patch documentation and convert the IS RPM into CPIO archive
    less DPLNX_00200.text
    rpm2cpio DPLNX_00200.rpm > DPLNX_00200.cpio
  • Extract the CPIO archive into current directory
    cpio -dmi < DPLNX_00200.cpio
  • Copy the target platform patch out of the repository directory (the same structure can be found on any UNIX IS).
    cp /opt/omni/databases/vendor/omnicf/gpl/x86_64/linux-x86-64/A.06.20/packet.Z \
    `file /opt/omni/databases/vendor/omnicf/gpl/x86_64/linux-x86-64/A.06.20/packet.Z | awk '{ print $6 }'`.rpm
    cp /opt/omni/databases/vendor/integ/gpl/x86_64/linux-x86-64/A.06.20/packet.Z \
    `file /opt/omni/databases/vendor/integ/gpl/x86_64/linux-x86-64/A.06.20/packet.Z | awk '{ print $6 }'`.rpm

    Please note: The CORE patch is special, since it contains omnicf (CORE) and integ (Online Integration) patches. In case of Data Protector 6.11 and earlier, you need to gunzip the packet.Z before you can rename it. This has been changed with version 6.20 and later.

  • Apply the patch to the system. This does not even require the componet to be installed in advance.
    rpm -Uvh --replacefiles --replacepkgs OB2-CORE-A.06.20-1.rpm

Data Protector requirements for Linux CM / revised

Here are some required, but not well documented requirements for Data Protector Cell Manager (Cell Server) installation on the Linux platform. Update: This information has been revised for SLES11. These steps are not intended to replace the Installation and Licensing documentation shipped with the media kit. Rather they should help you to bring things up more quickly. As always, think before you type or copy & paste. Things might vary on your distribution. Please check directory structures and files before using the commands!

  • Make sure the port 5555 is not blocked by any conflicting entry / uncomment it if found
    /usr/bin/perl -p -i -e 's/personal-agent/\#personal-agent/' /etc/services
    /usr/bin/perl -p -i -e 's/rplay/\#rplay/' /etc/services
  • Make sure Korn shell (ksh) is installed / most likely missing on RHEL
    /bin/rpm -qa "ksh"
    /usr/bin/yum install ksh
  • Make sure compat-libstdc++ is installed. If not, install using distribution tools (yum in case of RHEL).
    /bin/rpm -qa | /usr/bin/awk '/compat-libstdc\+\+\-33|libstdc\+\+33/'
    /usr/bin/yum install compat-libstdc++-33
  • Make sure glibc.i686 is installed. This is required for the included 32 bit Perl to work on Linux x86_64.
    /bin/rpm -qa "glibc*" | /usr/bin/awk '/i686|32bit/'
    /usr/bin/yum install glibc.i686
  • Make Data Protector shared libraries available in LDPATH and update cache
    /bin/cat << EOF > /etc/
    # /etc/ - Added for Data Protector Software
  • Make Data Protector binaries available system wide using PATH variable
    /bin/cat << EOF > /etc/profile.d/
    # /etc/profile.d/ - Added for Data Protector Software
    export PATH
  • Extend search path for man command to include Data Protector manpages. The /etc/manpath.config on SLES is adjusted by making those actions irrelevant.
    /bin/echo -e "\n# Added for Data Protector Software\nMANPATH\t\t/opt/omni/lib/man" >> /etc/man.config

Load more