DSU Duplicates failing constantly

[G3m_sys]

Hi There,

We are using a a disk based storage unit (staging area) for the backups, and we also have scheduled for both, full and incremental backups, the duplication to the tape lilbrary via "staging schedule".

The problem is the differential duplicates are constantly failing and when they do so, the DSSU police don't release the control of the drives, causing all the subsecuent backups to fail. The DSSU job can not be canceled from the admin console,  so, the "solution" is to reboot the master server and cross the fingers.

Our master server is a Solaris 10 sparc that was recently upgraded to 6.5.2.

I can also see in the logs (maybe related):

" ltid[622]: ltid can not be started while resources are assigned to the host. "

... but I have not found any information for our platform.

Have somebody an idea of what is going on??

Thanks.

[Nicolai]

Try using this command to solve the ltid message problem:

nbrbutil -resetMediaServer {mediaserver_name}

Regards

Nicolai

[G3m_sys]

Thanks..

I have not seen the ltid errors anymore. That was fixed with the suggested command.

.. however, I still have the problem with the DSSU duplicates but only for the differential backups. They constantly end with a " (50) client process aborted " error, and the policy backup job stays in an "Active" state even though there are not more child process. Is also impossible to cancel the job from the admin console.

Ideas?

[lopaka]

I'm experiencing the same problem.  What was the fix?

[Taqadus_Rehman]

following command was used to fix the ltid issue.

nbrbutil -resetMediaServer {mediaserver_name}

[lopaka]

I'm not experiencing the ltid issue.  I'm having the other issue described of having the problem with the DSSU duplicates but only for the differential backups. They constantly end with a " (50) client process aborted " error, and the policy backup job stays in an "Active" state even though there are not more child process. Is also impossible to cancel the job from the admin console.

Does the nbrbutil command fix this problme as well?

Thanks.

[quebek]

this is a quotation from Troubleshooting guide:

"duplicatetrace
duplicatetraceconsolidates the debug logs for the specified NetBackup duplicate jobs and writes them to standard output. It sorts the messages by time. duplicatetrace attempts to compensate for time zone changes and clock drift between remote servers and clients.
At a minimum, you must enable debug logging for admin on the master server and for bptmor bpdm on the media server. For best results, set the verbose logging level to 5 and enable debug logging for the following: bpdbm on the master server and bpcd on all servers and clients in addition to the processes already identified.
This command requires administrative privileges."
On UNIX based OS it should reside here:
/usr/openv/netbackup/bin/admincmd/duplicatetrace

Please launch it and review its logs.

[lopaka]

The differential backups issue I was having resolved itself after updating to 6.5.4.

[J_H_Is_gone]

6.5.2 had a bunch of issues.  They release a 6.5.2a - you should at least upgrade to that.  If you don't want to go to the version that just came out ( I wait as well) you can go to 2a to 6.5.3 as both have been out a while.

[CRZ]

I've GOT to find a way to stop you from repeating that 6.5.2A is so much different than 6.5.2.  :)  

The only difference (and I emphasize ONLY) is that 6.5.2 would incorrectly run a multistreamed incremental backup as a full ONE time after the upgrade, whereas 6.5.2A is fixed so that it does not.  For some people who don't have such a policy configured, they'd never even have a problem!  And, after a full backup is taken with either version, NetBackup will run exactly the same with either version, which means any bugs you might have experienced under 6.5.2 will still be there under 6.5.2A, sadly.  Besides, with only 6.5.2A available on our download site, I don't even think anyone's installing 6.5.2 anymore (even if they refer to it without the "A" when discussing their environment).

If an upgrade is going to help resolve your issue, PLEASE apply 6.5.4.  It takes care of so many more issues than 6.5.3 that I cringe every time I see somebody say "well, I'm going to wait" because it doesn't take a lot of scanning through the README to see that there's a LOT of fixes in 6.5.4 that you're just not going to get until after you apply it.

{ This is all mostly a tangent, but since this is a thread from 2008, we can probably let it go.  ;) }

[J_H_Is_gone]

sorry, I'll shut up.