Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

NBU fails to delete disk pool

Created: 20 Jan 2011 • Updated: 31 Jan 2011 | 1 comment
This issue has been solved. See solution.

I executed a command on NBU ( V 6.5 + Linux platform )

nbdevquery -listdp -stype XXX

And it gave the output

V6.5 DefaultDP_1 1 268435456.00 268435456.00 1 98 80  XXX

Now after some time I tried to delete the diskpool 'DefaultDP_1'

nbdevconfig -deletedp -stype XXX -dp DefaultDP_1 -M YYY

which gave the output

'DSM was unable to find the following disk pool: DefaultDP_1(XXX)@YYY\n',
 'failed to delete disk pool, invalid command parameter\n'], returnCode: 20'

I am surprised to see such output that how DSM could not found diskpool that it has reported a few minutes ago.

How can I analyse such cases by seeing NBU logs ?

Is this a normal scenerio which can happen from time to time ?

I have encountered such type of problems that NBU does not able to find policy etc. which are already craeetd on it. Now , is this a kind of database error ?

Discussion Filed Under:

Comments 1 CommentJump to latest comment

Murray Butler's picture

Hello,

 

the easiest log analyses will come form the admin logs in teh legacy logging directory.  Simply up the verbosity to VERBOSE=5 in bp.conf, and create the directory "/usr/openv/netbackup/logs/admin" (on unix variants, windows is very similar).  Restart the nbrmms service and try the command again.  The admin log may have some insight into the command failure.

This isn't a normal scenario, typically, we run into issues deleting disk pools that still have images on them (we condisder that data loss and won't commit the action without the disk pool being "clean"). 

this one isn't reading as a data base error, it appears to be returning Status Code 20, a command parameter is not correct.  This can be differing issues, if you are on Windows, our commands are STILL case sensitive, this is sometimes a problem on Windows, as many times, Windows commands are not case sensitive.  This command should work as presented above.  I'm not sure what parameter it would have been complaining about, but it may have more info in the log files, once you generate those.

 

Thanks,

 

Murray

SOLUTION