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
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.
