NetBackup™ Marketplace Deployment on Azure Cloud

Last Published:
Product(s): NetBackup & Alta Data Protection (11.0)

Troubleshooting

1. Deployment fails with the following error:

{"code":"InvalidResourceLocation","message":"The resource 'CPVnet' already exists in location 'westus2' in resource group 'CP_dev'. A resource with the same name cannot be created in location 'centralus'. Please select a new resource name."}

Explanation:

When you select an existing RG for deployment and existing VNet which is from another RG but has a same name as a VNet in this RG then, validation fails with conflicts. For example:

  • You choose to deploy in CP_dev which is an existing RG which has CP_VNet as a virtual network in West US 2

  • Then in the region parameter you choose region as Central US, so all your resources are deployed in central US and are linked to RG: CP_dev

  • In the networking section you choose an existing VNet, i.e. CP_VNet from another RG: demoRG, which is in Central US (as this the location selected in above step, so all VNets in central US region are listed).

In the above scenario the validation fails with conflicts saying it cannot create a VNet with same name as existing VNet CP_VNet in another region.

Solution:

Try to deploy in an RG which does not have a VNet with the same name as the existing VNet that you want to select.

2. Deployment fails with the following error:

{"code":"InvalidResourceLocation","message":"The resource 'PublicIp' already exists in location 'centralindia' in resource group 'CP_dev'. A resource with the same name cannot be created in location 'centralus'. Please select a new resource name."}

Explanation:

When you select an existing RG for deployment which has a public IP address as 'publicIP' (i.e. default public IP address of arm template) and you select to deploy without any public IP address then validation fails with conflicts. For example:

  • You select to deploy in CP_dev which is an existing RG which has publicIP as a public IP address in centralindia.

  • Then in the region parameter you select region as Central US, so all your resources are deployed in central US and are linked to RG: CP_dev

  • In the networking section you select 'none' for public IP, so that deployment would not have any public IP address.

In the above scenario the validation fails with conflicts saying it cannot create a public IP address with same name as existing public IP 'publicIP' in another region.

{"code":"InvalidResourceLocation","message":"The resource 'PublicIp' already exists in location 'centralindia' in resource group 'CP_dev'. A resource with the same name cannot be created in location 'centralus'. Please select a new resource name."}

Solution:

Try to deploy in an RG which does not have an IP address whose name is PublicIP.

3. Deployment fails with the following error:

{"code":"InvalidResourceLocation","message":"The resource 'CPIP' already exists in location 'centralindia' in resource group 'CP_dev'. A resource with the same name cannot be created in location 'centralus'. Please select a new resource name."}

Explanation:

When you select an existing RG for deployment and existing public IP address which is from another RG, but has a same name as a public IP address in this RG then, validation fails with conflicts. For example:

  • You select to deploy in CP_dev which is an existing RG which has CP_IP as a public IPaddress.

  • Then in the region parameter you select region as Central US, so all your resources are deployed in central US and are linked to RG: CP_dev

  • In the networking section you select an existing public IP, i.e. CP_IP from another RG: demoRG, which is in Central US (as this the location you selected in the above step, so all IPs in central US region are listed).

In the above scenario the validation fails with conflicts saying it cannot create an IP address with same name as existing IP address CP_IP in another region.

{"code":"InvalidResourceLocation","message":"The resource 'CPIP' already exists in location 'centralindia' in resource group 'CP_dev'. A resource with the same name cannot be created in location 'centralus'. Please select a new resource name."}

Solution:

Try to deploy in an RG which does not have an IP address with same name as the existing IP address that you want to select.

4. Unable to add Azure provider, when Snapshot Manager is deployed behind a Proxy

Explanation:

Snapshot Manager is unable to access azure.com, microsoftonline.com

Solution:

Set azure.com, microsoftonline.com values for noproxy during Snapshot Manager deployment.

5. Provisioning of VM extension NB-Primary timed out

Installation has timed out. Extension provisioning has taken too long to complete.

Explanation:

Installation of primary or media server failed because of some issue. To check the issue, login to the instance and switch to the root user using commaNetBackupnd 'sudo su'. You can check logs at location /root/NBSetup/userdata.log.

6. component upgrade failure

Explanation:

If you are trying to upgrade a NetBackup component till version 9, which was deployed through Azure marketplace then, you may get a following error:

Unable to configure target host.

ERROR: bpnbaz failed with status [68]. The authentication broker could not be configured. Review the NetBackup Security and Encryption Guide for more information.

Solution:

Add an entry in the /etc/hosts file for 'private_ip' 'short_hostname' mapping. This happens when the server cannot resolve a short hostname while upgrade. After adding an entry restart the upgrade.

7. Backup from Snapshot job fails with errors:

Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) SSL Connection failed with string, broker:<hostname> Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) Failed SSL handshake, broker:<hostname> Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Invalid operation for asset: <asset_id> Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Acknowledgement not received for datamover <datamover_id>

and/or

Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client <asset_id>: FTL - Cannot retrieve the exported snapshot details for the disk with UUID:<disk_asset_id> Jun 10, 2021 3:06:13 PM - Info bptm (pid=32582) waited for full buffer 1 times, delayed 220 times Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client <asset_id>: FTL - cleanup() failed, status 6

Explanation:

This can happen when the inbound access to Snapshot Manager on port 5671 and 443 port gets blocked at the OS firewall level (firewalld). Hence, from the datamover container (used for the Backup from Snapshot jobs), communication to Snapshot Manager gets blocked. This results in the datamover container not being able to start the backup.

Solution:

Modify the rules in OS firewall to allow the inbound connection from 5671 and 443 port.

8. Discovery fails after Snapshot Manager has been recovered by deleting instance in VM scale set

Explanation:

A manual entry in NetBackup primary and media's /etc/hosts folder with private IP address of Snapshot Manager for Backup from Snapshot to work is made. Since the new Snapshot Manager came up with a new private IP address, NetBackup is not able to find Snapshot Manager at the old IP address that it has in its /etc/hosts.

Solution:

Update /etc/hosts on both NetBackup Primary and Media with Snapshot Manager' s new private IP address.

9. Snapshot Manager deployment fails with error "Changing property 'osDisk.blobUri' is not allowed"

Changing property osDisk.blobUri is not allowed. (Code: PropertyChangeNotAllowed, Target: osDisk.blobUri) {"code":"PropertyChangeNotAllowed","target":"osDisk.blobUri","message":"Changing property 'osDisk.blobUri' is not allowed."}.

Solution:

There might be existing Snapshot Manager Image present in the resource group. Delete the image and try to install or upgrade again.

10. Deployment failed due to the following error - Data disk not attached to instance yet

The deployment on Azure marketplace failed either due to the data disk not attached to the instance or storage account permission issue or delay in connecting the disk to the virtual machine over the Azure network.

Solution:

  • 1. Login to virtual machine instance created for Snapshot Manager.

  • 2. Identify the below settings:

    • Resource Group <RG>

    • Managed identity name used to deploy NBSM <managed_identity_name>

    • Virtual Machine ScaleSet name <vmss_scaleset_name>

    • Instance ID <0> in the Virtual Machine ScaleSet

  • 3. Execute the command:az login --identity --username <managed_identity_name>

    Refer to the link Sign into Azure with a managed identity using the Azure CLI for more details.

    Execute the command. The status of the command should be success and the status of the last echo $ should be 0 (zero).

    az vmss get-instance-view --resource-group <RG> --name <vmss_scaleset_name> --instance-id 0 | python3 -c "import sys, json, os; disks=json.load(sys.stdin)['disks']; [print(disk['statuses'][0]['displayStatus']) for disk in disks if disk['name']==os.getenv('datadisk')]"

    echo $?

11. No assets are seen post NetBackup and Snapshot Manager deployment

Solution:

When no assets are listed under the Virtual Machines tab for Cloud Workload, but you see your region configured for Azure provider, then as part of deployment trigger a manual discovery for the attached Snapshot Manager.

12. NetBackup Snapshot Manager Virtual Machine Scaleset status is displayed as failed during Disaster Recovery

During Disaster Recovery of NetBackup Snapshot Manager Virtual Machine Scaleset instance intermittent behavior is seen when NetBackup Snapshot Manager containers take time to come up in healthy state. This causes Virtual Machine Scaleset status to display as Failed with the following error message:

VM has reported a failure when processing extension 'ExtensionForConfiguringCPscale' (publisher 'Microsoft.Azure.Extensions' and type 'CustomScript'). Error message: 'Enable failed: failed to execute command: command terminated with exit status=1 [stdout] exsnap-notification ...done Starting container: flexsnap-nginx ...done Upgrade finished at time: Thu Mar 6 05:24:34 UTC 2025 { "healthy": "false", "start_time": "Thu, 06 Mar 2025 05:24:31 UTC", "uptime": "00:00:3.690022", "status": "Snapshot Manager status is not healthy", "host": "localhost" } [ Thu Mar 6 05:24:35 AM UTC 2025 ] installcp: value of code: 1 [ Thu Mar 6 05:24:35 AM UTC 2025 ] installcp: Snapshot manager is not up yet, waiting... { "healthy": "false", "start_time": "Thu, 06 Mar 2025 05:24:31 UTC", "uptime": "00:00:14.441502", "status": "Snapshot Manager status is not healthy", "host": "localhost" }

Solution:

Log in to NetBackup NetBackup Snapshot Manager Virtual Machine Scaleset instance and run the following command to verify if the status is displayed as true for healthy field:

flexsnap_configure status

The output is displayed as follows:

{ "healthy": "true", "start_time": "Thu, 06 Mar 2025 11:57:59 UTC", "uptime": "00:16:38.399154", "status": "ok", "host": "localhost" }