SLP Error code 190

[cgoliver]

How do I determine which jobs to cancel? I'm assuming this error message is coming from expired images that cannot dupe.

[Sebastian_Baszc]

You can find the backupid in the duplication job (activity monitor).

Copy this, open cmd, navigate to InstallPath\Veritas\NetBackup\bin\admincmd

run:

nbstlutil cancel -backupid

Hope it helps.

[cgoliver]

The most recent job doesn't have a backup id. Just a PID and job ID.

[Yasuhisa_Ishika]

I'm not sure what goes on in your environment, but I guess some inconsistency exist in SLP backup information. I had similar(but not exactly same with yours) issue ago that some of backup images was left unduplicated. To fix this, I manipulated EMM DB by SQL script with assistance of Symantec Support team. I recommend you to call symantec and open case. If you want to identify what's wrong by your self, for the first, run "nbstl list -U" and compare entries of duplicated and unduplicated images.

[cgoliver]

nbstl list -U is not a valid command. -U is not an option.

That command requires the name of the SLP as part of the argument and my most current 190 errors have no data about the SLP.

[Andy_Welburn]

nor do I use SLP so cannot comment on the veracity of any of the previous posts per se, but a quick browse of the man pages led me to the following.

Could this be the command that should've been referenced?

/usr/openv/netbackup/bin/nbstlutil list [-l] [-U] [-backupid value]  [-client  name]  [-mediaid value] [-mediaserver name] [-storageserver name] [-state value]

where:

list      Shows the contents of an image  list  (EMM  database). The  tables can be listed that hold the information about images that lifecycles  process. This option is primarily a debugging tool, but support may use the information to troubleshoot problems.

[Mark_Solutions]

nbstlutil stlilist -image_incomplete -l

This will list the state of all incomplete SLP images from all SLPs so should help you pin down the ones having problems

[mph999]

The commands to use are :

nbstlutil list

nbstlutil stlilist

nbstlutil list -U

nbstlutil stlilist -U

The images are not expired that is the idea of SLP, leave at infinity until they dup.

If you cancel them (nbstlutil cancel -backupid <backupid)  ) they may expire, if, the end retention time has passed (once dropped from SLP, they revert to the intended retention).

If you log a call with Symantec. give the above output, + dump the emm database 

/usr/openv/db/bin/nbdb_unload <dir>

... where <dir> is the directory you give (just make one up) and them send in the contents of the <dir> also (lots of xxx.dat files + a couple of others ...) then there should be enough info to work out what is going on.  Also incldue the nbsu output please (nbsu -c -t)

Martin 

[cgoliver]

I'm burning so many candles on so many ends that we haven't gotten back to this problem.

But looking at

nbstlutil stlilist -image_incomplete -l

We see many incomplete images, but now the issue is that we can no longer manually dup images and at an impasse.

[Mark_Solutions]

Hi

Do use use GRT for Exchange (or maybe AD / SharePoint)?

Do the outstanding images relate to any of those?

It could be that you have an issue with the setup of that and producing the Granular Cataloging to tape.

You could turn this off in the Master Servers Host properties - General tab to see if the duplications go through.

Otherwise we need to see a listing of your SLPs and know what backup types are failing their duplicaitons.

Another thing that may help is to look in the admin log on the Master as it quite often writes details to there in relation to duplications.

Failing all of this run the All Log Entries report for an hour during which duplications fail and post it on  here

Thanks