Video Screencast Help

NBU Catalog Image Import Running Long issue

Created: 08 May 2013 • Updated: 31 Mar 2014 | 4 comments

Hi Guys

We're doing a catalog recovery at one of our largest customers using DataDomain DDBOOST technology. We're following the right technotes and all using bprecover -wizard -copy 2, to kickoff the process. So far on I can see 3 Jobs in the NB Console 2xRestore jobs(1 a few MB and a second one of 120GB) which correlates to the catalog size.

Our big issue is a thrid job kicked off called Image Import. This job seems to read each Image from the datadomain and has been running for ages now with no loggin on NBConsole. I created the BPDM log and can see it running through the images. however by our estimations of the current rate this process will run for days.

Am I doing something wrong or is there some way we might speed up the process?

Thanks in advance for any help.


Just wanted to update, we reran this process today, It seems like this was a bug in, we are running and the catalog restore using the above method worked fine.

Operating Systems:

Comments 4 CommentsJump to latest comment

Nicolai's picture

Have you consider to log a call with Symantec Support ?

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Marianne's picture

Please have a look at the Recover<date> log under  <install-path>\VERITAS\NetBackup\Logs\user_ops\<user>\logs

All it should be doing is to recover all files/folders under <install-path>\VERITAS\NetBackup\db\images.
The above log file will confirm that.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

William Jansen van Nieuwenhuizen's picture


It seems like we're also having issues with NBDB recovery. We just cant understand why the 'Image import' Process has to run so long. Logs attached when the 'Image Import' Process kicks in.

catalog command output.txt 814 bytes
bpdm.txt 262.25 KB 2.43 MB
Marianne's picture

The command and Recover log simply shows us a successful Partial recovery (images only) that started at 16:23 and ended at 17:09.

bpdm log shows an import that started at 17:09:

17:09:46.081 [5176.2856] <2> bpdm: INITIATING (VERBOSE = 0): -create_db_info .....

If I look at the updated Recovery Without Import doc: it seems that a Partial Recovery in 7.5 does 2 things (bottom of p.3):

Starting with NetBackup 7.5 the default behavior of the partial catalog recovery option does two things:
1. Restores the image database component of the flat file database (/usr/openv/netbackup/db/images or the Windows equivalent) to its original location.
2. Restores the relational database to the designated relational database staging area.
In order to complete the partial catalog recovery the image metadata must be exported from the copy of the relational database in the staging area and imported into the live relational database. This is achieved by running the following commands:
1. cat_export –all –staging –source_master <source master server>
2. cat_import –all –replace_destination
So, it seems that the image headers are getting exported from the staging are and imported into the current relational database.
The header file import will probably take as long as the 'files' file restore process.... We see evidence of this import process in bpdm log.
Hope this helps.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links