Aug 19

Tape drive performance with MTWEOFI on Linux

Physical tape drives are a precious resource in today’s fast growing data centers. If you’re running backups or copies to physical tape drives performance is key. I did some research on this topic based on a customer request. They reported that backups on Windows clients where much faster compared to Linux clients when writing directly to tape (via locally Media Agent).

When checking the device configuration in Data Protector I’ve noticed that drive where using the default segment size for LTO drives (2000). After changing the segment size from 2000 to 20000 (my own default) the performance issue was gone!

The default value 2000 is for LTO1 drives and there is a close relationship between cartridge capacity and the size/number of segments that are created during a write operation. If you’re using modern drives such as LTO5, LTO6 or even LTO7 you can store multiple times the data that fits on a LTO1 cartridge (6000 GB vs. 100 GB native).

While the performance issue was resolved it was still not clear why a Windows client does not show the same reduced performance with a segment size of 2000.

It turned out that st driver in the Linux Kernel usually needs to flush its buffer when a file mark is written. It was obvious that there is a relation so I started looking into MTWEOFI. MTWEOFI allows the st driver to preserve the content of its buffer, enabling the next file operation to start immediately.

Starting with Data Protector A.09.05 the MTWEOFI functionality can be abled in the omnirc of the Linux Media Agent host. It is mandatory that the used Linux Kernel understands MTWEOFI. This is the case for RHEL 6.5 and later as well as for SLES11 and later (have not checked SLES10).

# Enable MTWEOFI support on Linux Media Agent / Performance
OB2FORCESCSI=WFM
OB2IMMEDFM=1

Performance tests

The following performance numbers have been collected during my tests to demonstrate the relationship of segment size and write throughput on Linux using Data Protector A.09.07. I’ve been using a single 16 GB file that was backed up directly to a LTO4 drive. The drive was configured with a 256k block size (default) and 32 agent buffers.

  1. Without MTWEOFI the drive would stop after every 2GB of data written resulting in a poor overall performance.
  2. A larger segment size (20000 over 2000) will cause the drive to stop less frequently resulting in a better performance.
  3. With MTWEOFI support the drive would not stop at all, even if a file mark needs to be written.

108,84 MB/s – default omnirc, segment size 2000 (default)
183,91 MB/s – default omnirc, segment size 20000
188,24 MB/s – modified omnirc, segment size 2000 (default)
190,48 MB/s – modified omnirc, segment size 20000

Test environment: Internal HP LTO4 SAS drive (Firmware U64D) attached to HP Smart Array P410 (Firmware 6.64) in HP ProLiant ML350 G6 running CentOS release 6.8, 2.6.32-642.1.1.el6.x86_64.

The Data Protector online help gives additional details on segment size:

Read the rest of this entry »

Feb 28

Resolve Cell Manager installation failures on RHEL7

Starting with Data Protector A.09.05 Red Hat Enterprise Linux 7.0 and 7.1 is now a supported Cell Manager platform. But running the regular installation procedure on a fresh RHEL 7.1 system does not work, even with all requirements met.

[root@linux ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)
[root@linux ~]# uname -a
Linux jetlnx01.godyo.int 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

The installation script omnisetup.sh -CM -IS will fail during certificate generation phase.

Installing OB2-CS packet
Preparing… ################################# [100%]
Updating / installing…
1:OB2-CS-A.09.00-1 ################################# [100%]
NOTE: No Data Protector A.09.00 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.09.00… Done!

ERROR: Cell Manager certificates generation failed. (Return code = 3)
For more detail please refer to /var/opt/omni/server/log/DPIDBsetup_3627.log
warning: %post(OB2-CS-A.09.00-1.x86_64) scriptlet failed, exit status 3

When looking at the logs I found the root cause in /opt/omni/sbin/omnigencert.pl. The function ParseIpData() is not able to get any IP addresses from the /sbin/ifconfig output on the system. The command is part of net-tools-2.0-0.17.20131004git.el7.x86_64 required for installation. The ifconfig output is different compared to previous RHEL versions causing parsing failures.

I’ve developed a patch that resolves the parsing errors. You can download the patch and the modified omnigencert.pl here. Just copy the modified omnigencert.pl from the tarball to /opt/omni/sbin after OB2-CS-A.09.00-1.x86_64 is installed and before the certificate creation starts. The installation will go through smoothly.

Update: The Hewlett Packard Enterprise support provides a fix for this issue with SSPLNX900_005.

Sep 05

VMware Power On from 3PAR ZDB

This post will guide you through the basic configuration, backup and restore (Power On/Live Migrate) for VEAgent backups (VMware) hosted on 3PAR storage systems. This functionality has been introduced with Data Protector A.09.04 (b104). While this guide is considered as a good starting point you should also check the ZDBAdmin.pdf and ZDBIntegration.pdf for complete documentation, list of limitations and troubleshooting procedures.

Storage integration in Data Protector

There are a few steps that must be done once to make the ZDB work. The first step should be the installation of the required storage provider (HP P6000 / HP 3PAR SMI-S Agent) on your backup host. Of course the Virtual Environment Integration is required to perform VMware backups. This guide assumes that you’re familiar with the required procedures (installation, vCenter import).

Make sure that the CIM provider on your 3PAR system is started.

 

BLACKHAWK cli% showcim
-Service- -State- –SLP– SLPPort -HTTP– HTTPPort -HTTPS- HTTPSPort PGVer CIMVer
Disabled Active Enabled 427 Enabled 5988 Enabled 5989 2.9.1 3.2.1
BLACKHAWK cli% startcim
CIM server will start in about 90 seconds

BLACKHAWK cli% showcim
-Service- -State- –SLP– SLPPort -HTTP– HTTPPort -HTTPS- HTTPSPort PGVer CIMVer
Enabled Active Enabled 427 Enabled 5988 Enabled 5989 2.9.1 3.2.1
BLACKHAWK cli%

 

Once the provider is up and running you should be able to register the storage system with Data Protector. You should check the connection before proceeding.

 

C:\>omnidbzdb –diskarray 3PAR –ompasswd –add blackhawk.syncer.de –ssl –user 3paradm –passwd password
HP 3PAR provider authentication data updated for user 3paradm at host blackhawk.syncer.de.

C:\>omnidbzdb –diskarray 3PAR –ompasswd –list
User Host Port Ssl
—————-+——————–+—–+—–
3paradm blackhawk.syncer.de 5989 Yes

C:\>omnidbzdb –diskarray 3PAR –ompasswd –check
Starting configuration check on host wildfire.syncer.de.
[Normal] From: SMISA@wildfire.syncer.de “SMISA” Time: 05.09.2015 09:13:51
Checking the HP 3PAR provider using this connection data:
Host: blackhawk.syncer.de
User: 3paradm
Namespace: root/tpd
Port: 5989
SSL mode: TRUE

[Normal] From: SMISA@wildfire.syncer.de “SMISA” Time: 05.09.2015 09:13:51
This HP 3PAR provider has access to the following unit:
Name: BLACKHAWK
WWN: 2FF70002AC012345
Description: HP_3PAR 7200c, ID: 12345, Serial number: 1612345, InForm OS version: 3.2.1 (MU3)

Configuration check finished.

Read the rest of this entry »

Jul 02

Clean up after Data Protector IDB restore (Windows)

This is a follow-up on my post Clean up after Data Protector IDB restore which was intended for Linux/UNIX Cell Managers. It will guide you through the very same procedure to clean up after a successful IDB restore on a Windows Cell Manager. The same rules and warnings apply.

Please note: Data Protector program files and program data are installed to O:\OmniBack in this example. The default installation is C:\Program Files\OmniBack and C:\ProgramData\OmniBack.

  • Stop the services and check restored directory structure

O:\>omnisv stop
HP Data Protector services successfully stopped.

O:\>dir O:\OmniBack\server
Volume in drive O is OmniBack
Volume Serial Number is 261B-48D4

Directory of O:\OmniBack\server

07/02/2015 10:36 AM <DIR> .
07/02/2015 10:36 AM <DIR> ..
06/15/2015 04:46 PM <DIR> AppServer
07/02/2015 10:40 AM <DIR> db80
07/02/2015 10:37 AM <DIR> db80_restore
0 File(s) 0 bytes
5 Dir(s) 86,840,508,416 bytes free

O:\>dir O:\OmniBack\server\db80
Volume in drive O is OmniBack
Volume Serial Number is 261B-48D4

Directory of O:\OmniBack\server\db80

07/02/2015 10:40 AM <DIR> .
07/02/2015 10:40 AM <DIR> ..
06/15/2015 04:47 PM <DIR> dcbf
07/01/2015 08:46 PM <DIR> idb
07/01/2015 08:46 PM <DIR> jce
06/15/2015 09:38 PM <DIR> keystore
06/15/2015 04:46 PM <DIR> logfiles
06/15/2015 04:46 PM <DIR> meta
07/02/2015 10:36 AM <DIR> meta_2015_07_02-4_1435826212
07/02/2015 10:40 AM 13,276 mmd.ctx
06/15/2015 05:08 PM 16 mmd.id
06/15/2015 08:18 PM <DIR> msg
07/02/2015 10:36 AM <DIR> msg_2015_07_02-4_1435826212
07/02/2015 10:39 AM <DIR> pg
06/15/2015 04:46 PM <DIR> reportdb
06/15/2015 04:46 PM <DIR> smisdb
06/15/2015 04:46 PM <DIR> sqldb
06/15/2015 04:46 PM <DIR> sysdb
06/15/2015 04:46 PM <DIR> vssdb
06/15/2015 04:46 PM <DIR> xpdb
2 File(s) 13,292 bytes
18 Dir(s) 86,840,508,416 bytes free

O:\>dir O:\OmniBack\server\db80_restore
Volume in drive O is OmniBack
Volume Serial Number is 261B-48D4

Directory of O:\OmniBack\server\db80_restore

07/02/2015 10:37 AM <DIR> .
07/02/2015 10:37 AM <DIR> ..
07/02/2015 10:37 AM <DIR> idb
07/02/2015 10:37 AM <DIR> jce
07/02/2015 10:43 AM <DIR> pg
0 File(s) 0 bytes
5 Dir(s) 86,840,508,416 bytes free

  • Move the restored database in the target directory and adjust directory junctions. Please note: The name of the directory junctions might vary on your Cell Manager.

O:\>rmdir /S /Q O:\OmniBack\server\db80\idb

O:\>rmdir /S /Q O:\OmniBack\server\db80\jce

O:\>rmdir /S /Q O:\OmniBack\server\db80\pg

O:\>move /Y O:\OmniBack\server\db80_restore\idb O:\OmniBack\server\db80
1 dir(s) moved.

O:\>move /Y O:\OmniBack\server\db80_restore\jce O:\OmniBack\server\db80
1 dir(s) moved.

O:\>move /Y O:\OmniBack\server\db80_restore\pg O:\OmniBack\server\db80
1 dir(s) moved.

O:\>dir O:\OmniBack\server\db80\pg\pg_tblspc
Volume in drive O is OmniBack
Volume Serial Number is 261B-48D4

Directory of O:\OmniBack\server\db80\pg\pg_tblspc

07/02/2015 10:37 AM <DIR> .
07/02/2015 10:37 AM <DIR> ..
07/02/2015 10:37 AM <JUNCTION> 16387 [O:\OmniBack\server\db80_restore\idb]
07/02/2015 10:37 AM <JUNCTION> 16445 [O:\OmniBack\server\db80_restore\jce]
0 File(s) 0 bytes
4 Dir(s) 87,235,559,424 bytes free

O:\>rmdir /Q O:\OmniBack\server\db80\pg\pg_tblspc\16387

O:\>rmdir /Q O:\OmniBack\server\db80\pg\pg_tblspc\16445

O:\>mklink /J O:\OmniBack\server\db80\pg\pg_tblspc\16387 O:\OmniBack\server\db80\idb
Junction created for O:\OmniBack\server\db80\pg\pg_tblspc\16387 <<===>> O:\OmniBack\server\db80\idb

O:\>mklink /J O:\OmniBack\server\db80\pg\pg_tblspc\16445 O:\OmniBack\server\db80\jce
Junction created for O:\OmniBack\server\db80\pg\pg_tblspc\16445 <<===>> O:\OmniBack\server\db80\jce

  • Update configuration files accordingly. For example replace all occurrences of db80_restore with db80.

O:\>notepad O:\OmniBack\server\db80\pg\postgresql.conf

O:\>notepad O:\OmniBack\server\db80\pg\postmaster.opts

O:\>notepad O:\OmniBack\Config\Server\idb\idb.config

  • Adjust the ImagePath registry value for the hpdp-idb service in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\hpdp-idb to reflect the previous changes

  • Additional clean up, depending on your configuration

O:\>rmdir /Q /S O:\OmniBack\server\db80_restore

O:\>rmdir /Q /S O:\OmniBack\server\db80\meta_2015_07_02-4_1435826212

O:\>rmdir /Q /S O:\OmniBack\server\db80\msg_2015_07_02-4_1435826212

O:\>rmdir /Q /S O:\OmniBack\log\server\auditing_2015_07_02-4_1435826212

  • Start the services and do basic verification

O:\>omnisv start -idb_only
The HP Data Protector IDB services successfully started.

O:\>omnisv status
ProcName Status [PID]
===============================
crs : Down
mmd : Down
kms : Down
hpdp-idb : Active [10688]
hpdp-idb-cp : Active [23584]
hpdp-as : Down
omniinet : Down
Sending of traps disabled.
===============================
Status: At least one of the Data Protector processes/services is not running.

O:\>omnisv start
HP Data Protector services successfully started.

O:\>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!

O:\>omnib -idb_list IDB_BACKUP
[Normal] From: BSM@windows.syncer.de “IDB_BACKUP” Time: 7/2/2015 11:15:17 AM
Backup session 2015/07/02-5 started.

[Normal] From: BSM@windows.syncer.de “IDB_BACKUP” Time: 7/2/2015 11:15:17 AM
OB2BAR application on “windows.syncer.de” successfully started.

[Normal] From: OB2BAR_POSTGRES_BAR@windows.syncer.de “DPIDB” Time: 7/2/2015 11:15:18 AM
Checking the Internal Database consistency

[Normal] From: OB2BAR_POSTGRES_BAR@windows.syncer.de “DPIDB” Time: 7/2/2015 11:15:19 AM
Check of the Internal Database consistency succeeded

[Normal] From: OB2BAR_POSTGRES_BAR@windows.syncer.de “DPIDB” Time: 7/2/2015 11:15:19 AM
Putting the Internal database into the backup mode finished

[…]

Jun 11

List non-migrated DCBFs

If you need to deal with non-migrated DCBFs after an upgrade to Data Protector 8 or later, you might find this SQL query useful. It will display all non-migrated DCBFs (dcbf_version = -1) with references in the IDB. Don’t remove the old catalog using perl omnimigrate.pl -remove_old_catalog before all v1 DCBFs have been successfully migrated to v2. The migration is done using perl omnimigrate.pl -start_catalog_migration.

 

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 and dcbf_version != ‘2’
ORDER BY medium_name ASC, dcbf_directory ASC;

Save the query as dcbf_version.sql and run omnidbutil -run_script dcbf_version.sql -detail.

May 28

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.

May 10

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
HP Data Protector 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
HP Data Protector 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
DONE!

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

[…]

[Normal] From: BSM@linux.syncer.de “LINUX_IDB” Time: 05/10/2014 12:44:16 PM
OB2BAR application on “linux.syncer.de” successfully started.

[Normal] From: OB2BAR_POSTGRES_BAR@linux.syncer.de “DPIDB” Time: 05/10/2014 12:44:16 PM
Checking the Internal Database consistency

[Normal] From: OB2BAR_POSTGRES_BAR@linux.syncer.de “DPIDB” Time: 05/10/2014 12:44:17 PM
Check of the Internal Database consistency succeeded

[Normal] From: OB2BAR_POSTGRES_BAR@linux.syncer.de “DPIDB” Time: 05/10/2014 12:44:17 PM
Putting the Internal database into the backup mode finished

May 09

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 IDBSetup.sh which usually runs during installation time to initialize the IDB and Application server

[root@linux ~]# /opt/omni/sbin/IDBsetup.sh
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
DONE!

May 07

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:

root = HKEY_LOCAL_MACHINE

keyName = SOFTWARE\Hewlett-Packard\OpenView\OmniBackII\Common\Parameters

valueName = OB2_ALIGNNMENTEXCEPTION

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 8.0.3.1345 (sp63727.exe) running Windows 8.1 installed on a HP ProBook 6570b.

Apr 25

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 http://support.openview.hp.com/selfsolve/document/KM00481540, 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

DONE!

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
           dcbf_directory
————————————
 O:\OmniBack\db40\dcbf
 O:/OmniBack/server/db80/dcbf/dcbf4
 O:/OmniBack/server/db80/dcbf/dcbf3
 O:/OmniBack/server/db80/dcbf/dcbf2
 O:/OmniBack/server/db80/dcbf/dcbf1
 O:/OmniBack/server/db80/dcbf/dcbf0
(6 rows)
 
UPDATE 6
UPDATE 6
           dcbf_directory
————————————
 O:/OmniBack/db40/dcbf
 O:/OmniBack/server/db80/dcbf/dcbf4
 O:/OmniBack/server/db80/dcbf/dcbf3
 O:/OmniBack/server/db80/dcbf/dcbf2
 O:/OmniBack/server/db80/dcbf/dcbf1
 O:/OmniBack/server/db80/dcbf/dcbf0
(6 rows)
DONE!
C:\>omnidbutil -remove_dcdir O:/OmniBack/db40/dcbf
DONE!

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

DONE!

Older posts «