Fixed by opening the following ports inbound on the media server AWS security group:
1556 - Netbackup
7394 - Netbackup NBFSD
111 - Netbackup GRT
I realised that the NFS client was stopped on the media server. After starting that, the log looks better but i'm still getting the same errors.
Actually when I follow the comands in this document: https://www.veritas.com/content/support/en_US/article.100000686
I can never mount the drive, it gets stuck at this point indefinitely.
C:\Program Files\Veritas\NetBackup\bin>nbfs mount -server mymediaserver -cred BBCB97CF22B6C74CFA2738BC3C4F69E8CF7F31ECC069D672239D977B2FB3E2B288872549C0EC2F0FD83B540AA109000E373FCF7E1549FE8366D43A91BA4412BB * BASEDIR= MNTPATH=/NBUFS_A_EA9CC093F145072D_001 MOUNTPOINT=
Which looks like this on the media server:
16:45:36.605 [3637197] <2> debuglog: <2> common_init: nbfsd: starting... @(#) NetBackup_8.2 mymediaserver (2019062501, 1604382336 201103.164536) 16:45:36.605 [3637197] <2> debuglog: <2> common_init: nbfsd: unix - Linux, mymediaserver, 4.18.0-193.14.3.el8_2.x86_64, #1 SMP Mon Jul 20 15:02:29 UTC 2020, x86_64 16:45:36.605 [3637197] <2> logparams: nbfsd -d -v 5 -j 5 -B client02_123456789 16:45:36.605 [3637197] <2> debuglog: <2> ivfs_parse_use_options: bid client02_123456789, type , options 16:45:36.605 [3637197] <2> debuglog: <2> ivfs_parse_use_options: generic use type 16:45:36.605 [3637197] <2> debuglog: <2> ivfs_parse_use_options: returning useinfo 0x3000f90 - 16:45:36.605 [3637197] <2> debuglog: <2> read_shared_memory: Failed to get shared memory segment 16:45:37.606 [3637197] <2> debuglog: <2> cred_load_keyfile: read nbfsd_key file 16:45:57.125 [3636296] <8> vnet_get_user_credential_path: [vnet_vxss.c:1620] status 35 0x23 16:45:57.125 [3636296] <8> vnet_check_user_certificate: [vnet_vxss_helper.c:4122] vnet_get_user_credential_path failed 35 0x23 16:45:57.125 [3636296] <2> ConnectionCache::connectAndCache: Acquiring new connection for host forge, query type 81 16:45:57.125 [3636296] <2> logconnections: BPDBM CONNECT FROM 10.66.4.50.43739 TO 10.66.4.50.13721 fd = 10 16:45:57.130 [3636296] <2> closeConnection: Caching connection for query type 81 for reuse 16:45:57.130 [3636296] <2> debuglog: <16> imgrec::refresh: failed to get image record for client02_123456789 (227) 16:45:57.130 [3636296] <2> debuglog: <16> imgrec::refresh: THROWING 22 failed to get image record
Is this a DAG? If so, do you have the DAG name mapped to your Exchange server names in the Distributed Application Restore Mapping? This is a host configuration setting for the master server.
The most recent error you're getting from your nbfsd mount attempt says that the master server is not providing the client about the backup image. Look in the bprd log to find out why. Bprd is the request daemon on the master server. I think the request is bpclimagelist. I am running a GRT backup to confirm it.
In the bprd log look for "process_request: imagelist". Copy the lines for that pid off into a separate editor window. Look for a line like the following:
>is_redirected_restore_allowed: Component host <vm562dag> is validated for application host <rsvlmvc01vm562>
Where the component host is my DAG and the application host is the Exchange server where bpbkar32 ran. The function "is_redirected_restore_allowed" is the DARM lookup.
Check the exit status:
>process_request: EXIT STATUS 0
You may need to temporarily set logging level to 3 on the master server to find these log entries. I have mine set to 5.
Hi Lowell,
In response to your other post, yes I have the DAG mapped as a host mapping.
I can't see those lines in my bprd log, and i've turned the bprd logging up to 5 also.
The only obvious errors I can see when trying manually test a GRT backup are:
10:29:31.700 [3947558] <2> debuglog: <16> imgrec::refresh: failed to get image record for client01_123456789 (227) 10:29:31.700 [3947558] <2> debuglog: <16> imgrec::refresh: THROWING 22 failed to get image record 10:29:31.700 [3947558] <2> debuglog: <2> ivfs_cred_activate: caught from image refresh - 22 failed to get image record
