Video Screencast Help

Anyone with Master Solaris NBU 7.5 and Clients solaris 8 with nbu60mp7?

Created: 12 Jan 2013 • Updated: 14 Feb 2013 | 4 comments
SAF's picture
This issue has been solved. See solution.

I have been facing issues with this scenario. The backups (Oracle and Standard) go through but if I would like to restore I receive the error "No entity was found".

If I do a bpimagelist I can see the images, if I create a Client Backups Report I see the backups were taken OK, if I use the BAR GUI and look for the files (after receiving the error) I can see the list of backup under backup history table.

The bplist command returns "no entity was found" also.

This solution have been working for one year and restore have been done on this clients (Solaris 8 + nbu6) but now, it's not possible. I have even try doing a new backup (which ends ok) and then trying to browse it for restore or doing a verify and I always receive the same error.

I have also seen a log in the bpdbm log saying Error bpverify (pid=9629) Verify of policy DB_XXX_Hot_Backup, schedule Default-Application-Backup (XXX_1356838188) failed, the database contains conflicting or erroneous entries.

I checked the correct spelling of the client name (I replaced it here by XXX) and is ok. Also I tested hostname resolution, comminication and basic stuff, everithing ok.

Every single command I try in these machines I have tried in another one (aleatory) and works, but in these solaris 8 they dont.

I log a ticket like a month ago and Support is still working (very slowly) on my case, but you know that patience have a threshold.

I just would like to find some light here in Connect.

Again: Master/Media Server Solaris 10 + NBU, Clients Solaris 8 + NBU 60MP7 (I know it is out of support but the customer is still working on a new solution to move them up).

Comments 4 CommentsJump to latest comment

Marianne's picture

...bpdbm log saying Error bpverify (pid=9629) Verify of policy DB_XXX_Hot_Backup, schedule Default-Application-Backup (XXX_1356838188) failed, the database contains conflicting or erroneous entries.

You need someone with lots of time and patience to examine image database files.  Has the support engineer requested copies of problematic image files?

I feel that you are actually lucky that Symantec support accepted the call. Maybe because the actual problem is with image entries on the supported master server.

Ask that your call be escalated to backline engineer.

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

badri's picture

when did you upgrade to netbackup 7.5 and are you trying to restore from an images which was backed up after the upgrade?

glenn71's picture


Was a solution found to this problem? we are planning on a NB7.1.0.4 -> upgrade with a few Sol8 clients in our environment.. would like to know if it works before upgrading.

Thanks for your time.smiley


SAF's picture

Hi everyone,

The root problem was that the clients were backed up once using lower case, then, the customer notice that the actual names were in capital letters everywhere, so they decided to change it.

bpdbm log:

17:51:22.629 [9325] <2> DbmOdbcView::executeSql: (3455.2) Executing "SELECT ClientMachineName FROM DBM_Main.DBM_Client, DBM_Main.DBM_ClientAlias WHERE DBM_Main.DBM_ClientAlias.MasterServerKey = ? AND ClientAliasName = LOWER(?) AND DBM_ClientAlias.ClientKey = DBM_Client.ClientKey FOR READ ONLY"

17:51:22.629 [9325] <2> DbmOdbcView::executeSql: Bindings = <1000002, 'XXX'>

17:51:22.631 [9325] <2> DbmOdbcView::executeSql: SQL_SUCCESS

17:51:22.631 [9325] <2> DbmOdbcView::fetchChars: (.2) Fetched : xxx

The solution has two stages, the first one was to create a simbolic link so that when NBU look for a client in lower case on the imageDB, it could reach the one in upper case.

/usr/openv/netbackup/db/images/xxx  -->  /usr/openv/netbackup/db/images/XXX

The second one was more complex and required catalog manipulation.

I would say that the problem itself was in place even before the migration, and it was a bomb waiting for the right moment.

By the way, Symantec support wasn't helpfull at all, and even the engineer argued with me because while he was trying to solve someone else's case, I was trying to solve this issue (layer 8) by myself. Great!!!

Marianne and Badri, thanks for your comments, Glenn go ahead with the migration.

Sorry I didn't post it before, but I have been involved in a lot things these days.