Can't fix error 2106 Disk Storage Server is down

[zmlat]

Hello,

Tried calling Veritas support on this matter but alas 7.6 is EOSL...

We are backing up to Data Domains using SLPs. In an effort to access the Data Domains, an admin tried to login using the boost account and locked it. I have since re-enabled the account which I thought was the cause of the 2106 errors, but I am still getting them.

nbdevquery -liststs -stype DataDomain -U   shows the storage servers are down

I've tried to change the state using nbdevconfig -changestate, but they still show "down" status. I've also deleted/recreated the boost account on the DDs, and did a tpconfig -update , but I can't get the storage server to come up.

Not sure which logs I need to look at to resolve this issue.

Thanks

[Thiago_Ribeiro]

Hi,

Take a look this TN

https://www.veritas.com/support/en_US/article.000087761

And let us know if it can help you.

Regards,

Thiago Ribeiro

[Nicolai]

The disk pools being down could indicate there is no connectivity to Data Domain or the BOOST password still causes problems. Please note, I don't think a Data Domain does password locking. So it may be somthing else

On the Data Domain web console go to :

Data Mangement - DD BOOST - Active connection.

Connections from media server should be listed here. From the media server side, you can also run command:

bpstsinfo -serverinfo -storage_server {storage server name } -stype DataDomain
Server Info:
Server Name: {what ever its called in your netbackup installation}
Supported Stream Formats:
[
]
Server Flags: (STS_SRV_IMAGELIST | STS_SRV_CRED | STS_SRV_EVSYNC | STS_SRV_IMAGE_COPY)
Maximum Connections: 540
Current Connections: 0
Supported Interfaces:
[
]
Supported Credentials:
[
]

Storage Server name(s) can be found running this command:

# nbdevquery -listdp

[zmlat]

Thanks for the replies. I had actually scoured VOX for any technotes, and while I found some useful information, nothing remediated the issue. Out of desparation, I just created a new boost account on the DD, and re-credentialed all the media servers (I had done that with the prior account), and I finally got the dedupe to work. 

One followup question I do have after reading:  https://www.veritas.com/support/en_US/article.000018028

How can I figure out which media server is actually being used on an opt-dupe job? I am now getting 2107 errors (those indicate credential issues), but the media server referenced in the failing job (which had credentials on both source and destination) may not necessarily be the media server actually used for the write operation on the destination DD STU.