HP Data Protector: Can’t delete old DCBF directories

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.
This applies to upgrades from Data Protector 6.x and 7.x to 8.x and 9.x.

It seems that today is my debugging day… Yesterday I performed a Data Protector update from 7.03 to 8.13. During this update, the Data Protector IDB is migrated to another database format. Last night the backups went smoothly, but today I noticed that two old Detail Catalog Binary File (DCBF) directories were still referenced in the HP Data Protector IDB.

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
 |        |        |        |        |
===========================================================================
 2        16384    10000    2048     C:/ProgramData/OmniBack/db40/dcbf
 0        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf0
 1        16384    10000    100      D:/OmniBack/db40/dcbf
 1        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf1
 4        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf4
 3        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf3
 2        204800   100000   2048     C:/ProgramData/OmniBack/server/db80/dcbf/dcbf2

DONE!

The two directories with the “db40” inside the path are old DCBF directories. Because the directories contained actively used DCBF files, I relocated the files and did a “omnidbutil -remap_dcdir”:

C:\Users\Administrator>omnidbutil -remap_dcdir
DONE!

A quick check after the relocation showed no errors.

C:\Users\Administrator>omnidbcheck -bf

 Medium ID:                      Actual Size       Header Size   Check
========================================================================
6d50d6a3:54777b65:09d0:6604           809828            809828      OK
6d50d6a3:5479522c:09d0:6b4f           163080            163080      OK
<SNIP>
01401eac:547d2251:0bbc:01ec          6008832           6008832      OK
01401eac:547d21e9:0bbc:01e9           311296            311296      OK
01401eac:547d22d4:0bbc:01ef          2600960           2600960      OK
01401eac:547d2411:0bbc:01f2          2883584           2883584      OK
01401eac:547d24e2:0bbc:01f5          1929216           1929216      OK
01401eac:547d25bc:0bbc:01f8          2146304           2146304      OK
01401eac:547d266e:0bbc:01fb          7098368           7098368      OK
01401eac:547d2790:0bbc:01fe          2015232           2015232      OK


Check has finished : 0 errors reported
DONE!

Looking good. Time to remove the old DCBF directories:

C:\Users\Administrator>omnidbutil -remove_dcdir D:/OmniBack/db40/dcbf
**********************  DEFAULT ERROR REPORT  *******************************
[Critical] From: OMNIDBUTIL@sauron.swb.local.de ""  Time: 02.12.2014 10:07:07

*****************************************************************************

Did I mentioned that today was my debugging day? To make a long story short: HP switched the path separator character for the Data Protector IDB. They are using now a / instead a \ on both platforms (Windows & UNIX). During the update, this change is not performed correctly. Sebastian Koehler wrote a small SQL script that fixes this problem. Check his blog post (he had the same problem as me).

This is the script (you can also find it on Sebastian Koehlers blog):

–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;

This is the output of the script when I run it.

C:\Users\Administrator>omnidbutil -run_script D:\TMP\dcbf_dir_fix.sql -detail
                 dcbf_directory
------------------------------------------------
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf1
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf4
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf0
 C:\ProgramData\OmniBack\db40\dcbf
 D:\OmniBack\db40\dcbf
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf3
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf2
(7 rows)

UPDATE 7
UPDATE 7
                 dcbf_directory
------------------------------------------------
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf1
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf4
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf0
 C:/ProgramData/OmniBack/db40/dcbf
 D:/OmniBack/db40/dcbf
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf3
 C:/ProgramData/OmniBack/server/db80/dcbf/dcbf2
(7 rows)


DONE!

You can clearly see that the wrong path separator is used for the old DB40 directories (the upper part of the output). Compare it to the output of omnidbutil -list_dcdirs! The lower part shows that the correct path separator was set. After the run of the script I was able to delete the old DCBF directories.

C:\Users\Administrator>omnidbutil -remove_dcdir D:/OmniBack/db40/dcbf
DONE!

C:\Users\Administrator>omnidbutil -remove_dcdir C:/ProgramData/OmniBack/db40/dcbf
DONE!

Thanks to Sebastian, who described this bug.

5/5 - (2 votes)
Patrick Terlisten
Follow me

Leave a Reply

Your email address will not be published. Required fields are marked *