Upgrading from 6.2 to 9.x is better, but there's a bug you need to work around

Upgrading to HP Data Protector version 9 is much faster than upgrading to version 8.x. It's amazing what some good indexes on a database can do! My most recent customer had a 50GB database and the upgrade for the cell manager was complete in under an hour.

I have found one interesting bug in the import process, though. It seems that one of the columns in the import gets mis-imported. After the upgrade, I found sessions like this (truncated output from omnidb -session -detail) :

SessionID : 2014/08/09-4
        Backup Specification: hpdp.IFOST@cellmgr.ifost.org.au
        Session type        : Copy
        Started             : Saturday, 9 August 2014, 7:06:02 PM
        Finished            : Monday, 11 August 2014, 5:13:37 PM
        Status              : Completed
        Number of warnings  : 0
        Number of errors    : 0
        User                :
        Group               :
        Host                :  

When previously, the session looked like this:

SessionID : 2014/08/09-4

        Backup Specification: Weekly Tape Copy

        Session type        : Copy

        Started             : Saturday, 9 August 2014, 7:06:02 PM

        Finished            : Monday, 11 August 2014, 5:13:37 PM

        Status              : Completed

        Number of warnings  : 0

        Number of errors    : 0

        User                : hpdp

        Group               : IFOST

        Host                : cellmgr.ifost.org.au

The user / group / host has been turned into the specification name! As far as I can tell, this is just a once-off, sessions run on the cell manager after the upgrade are named correctly.

This bug appears to be triggered in two situations:

1. For all copy jobs.
2. For backup jobs where the backup specification no longer exists. (e.g. you used to have a job called "Daily Sydney"; you ran it every day last year; then you deleted it; then you upgraded - congratulations, those jobs will now have a username instead of a backup specification name. 

So presumably somewhere in the upgrade script there is some code which calls out to omnidb -datalist "..." because this is the only thing I can think of which would exhibit exactly these kind of failure modes.

When you actually look into the database, there's a column on the dp_management_session table called "scratch_area" and a column called "owner". It seems that for the bad sessions, these end up with owner being the empty string, and scratch_area ending in two slashes.

The way to confirm this is to check with a SQL query like this:

     select owner,name,datalist,scratch_area 

       from dp_management_session where owner = '';

Just save this to a file and run omnidbutil -run_script filename.sql -detail

For me, the output looked like this:


 owner |      name       |           datalist              |   scratch_area
-------+-----------------+---------------------------------+--------------------
       | 2014/08/09 0010 | hpdp.IFOST@cellmgr.ifost.org.au | Daily job //
       | 2013/04/29 0016 | hpdp.IFOST@cellmgr.ifost.org.au | Weekly tape copy //
       | 2014/08/09 0004 | hpdp.IFOST@cellmgr.ifost.org.au | Daily job //
....

There were 111 other lines truncated. Here's what I ran (with omnidbutil -run_script) to fix it:

     update dp_management_session 
        set owner = datalist where owner = '';

     update dp_management_session 
        set datalist = trim(trailing ' // ' from scratch_area) 
        where scratch_area like '%//%';

The GUI console caches, so don't be surprised if you have to disconnect and reconnect before you see it reflected in the GUI.

Greg Baker is an independent consultant who happens to do a lot of work on HP DataProtector. He is the author of the only published books on HP Data Protector (http://x.ifost.org.au/dp-book). He works with HP and HP partner companies to solve the hardest big-data problems (especially around backup). See more at IFOST's DataProtector pages at http://www.ifost.org.au/dataprotector