Forum Discussion
File restores failure from Azure VM Backup fail
We have several Azure VMs being backed up to a recovery vault. I am testing doing file restores from a VM just in case it is needed. I am using the procedure as outlined in the article Recover files and folders from Azure VM backup - Azure Backup | Microsoft Learn.
All of the VMs are on a VNet in Azure, including the one I am running the restore from. The recovery services vault has a private endpoint on the VNet.
When I run the generated script from an elevated command prompt, I get the general error "Exception caught while connecting to Target. Please retry after some time."
I have tried several times over the week, so I don't think it is a transient issue. In looking at Troubleshoot Azure VM file recovery - Azure Backup | Microsoft Learn under the heading "The script runs but the connection to the iSCSI target failed", I get back a response from the NSLookup with an external IP address. If I try to ping, I get no answer, which I expected since pings are usually blocked. I have made sure outbound port 3260 is not blocked.
Does anyone have any suggestions?
Eric Logsdon
Given the steps you've already taken, please find below some further troubleshooting suggestions:
Ensure that outbound access on port 3260 (iSCSI) is allowed for both the source VM and the Recovery Services vault. Although you've checked that it isn’t blocked, double-check the NSG (Network Security Group) settings attached to both the VMs and the subnet.
Verify that any firewall or security software on the VM itself (e.g., Windows Firewall or endpoint protection software) isn’t blocking port 3260.
Please ensure that the DNS settings on the VNet and the VM are configured correctly.
Ensure that Azure Private DNS is configured to resolve the private endpoint for your Recovery Services vault, allowing the VM to use the private endpoint rather than an external IP address.
Check the route tables associated with the subnet of the VM to ensure that no custom routes interfere with traffic to the Recovery Services vault or block outbound connections, If there is a route directing all traffic through a Network Virtual Appliance (NVA) or firewall, ensure that traffic to Azure services isn’t inadvertently blocked.
Sometimes, DNS resolution issues can prevent connectivity. If using Azure's default DNS server (168.63.129.16) doesn’t resolve the private endpoint correctly, try setting up an Azure-hosted DNS server or a custom DNS server in your environment to resolve the private endpoint
Go to the iSCSI initiator settings on your VM (iscsi initiator on Windows) to ensure is running, then manually add the IP or DNS name of the iSCSI target if possible.
Restart the iSCSI initiator service after making any changes on it.
Run the following in PowerShell command on the VM to check connectivity
Test-NetConnection -ComputerName <PrivateEndpointName> -Port 3260
(Replace <PrivateEndpointName> with the DNS name or IP of the private endpoint associated with the Recovery Services vault)Enable logging for the Recovery Services vault if it isn’t already enabled
The Azure VM Backup extension logs can sometimes provide insight into connectivity issues during file restores. You can retrieve logs from the VM in the /var/log/azure (Linux) or C:\WindowsAzure\Logs (Windows) directory, depending on your OS
Occasionally, the restore script may contain cached information or configuration specific to a previous network state. Try generating a fresh restore script from the Azure portal and executing it again.
As a last resort, create a test VM in the same VNet/subnet as your existing VM, and attempt to restore the backup there. This can help rule out VM-specific issues that might be causing the iSCSI connection to fail.
Given the steps you've already taken, please find below some further troubleshooting suggestions:
Ensure that outbound access on port 3260 (iSCSI) is allowed for both the source VM and the Recovery Services vault. Although you've checked that it isn’t blocked, double-check the NSG (Network Security Group) settings attached to both the VMs and the subnet.
Verify that any firewall or security software on the VM itself (e.g., Windows Firewall or endpoint protection software) isn’t blocking port 3260.
Please ensure that the DNS settings on the VNet and the VM are configured correctly.
Ensure that Azure Private DNS is configured to resolve the private endpoint for your Recovery Services vault, allowing the VM to use the private endpoint rather than an external IP address.
Check the route tables associated with the subnet of the VM to ensure that no custom routes interfere with traffic to the Recovery Services vault or block outbound connections, If there is a route directing all traffic through a Network Virtual Appliance (NVA) or firewall, ensure that traffic to Azure services isn’t inadvertently blocked.
Sometimes, DNS resolution issues can prevent connectivity. If using Azure's default DNS server (168.63.129.16) doesn’t resolve the private endpoint correctly, try setting up an Azure-hosted DNS server or a custom DNS server in your environment to resolve the private endpoint
Go to the iSCSI initiator settings on your VM (iscsi initiator on Windows) to ensure is running, then manually add the IP or DNS name of the iSCSI target if possible.
Restart the iSCSI initiator service after making any changes on it.
Run the following in PowerShell command on the VM to check connectivity
Test-NetConnection -ComputerName <PrivateEndpointName> -Port 3260
(Replace <PrivateEndpointName> with the DNS name or IP of the private endpoint associated with the Recovery Services vault)Enable logging for the Recovery Services vault if it isn’t already enabled
The Azure VM Backup extension logs can sometimes provide insight into connectivity issues during file restores. You can retrieve logs from the VM in the /var/log/azure (Linux) or C:\WindowsAzure\Logs (Windows) directory, depending on your OS
Occasionally, the restore script may contain cached information or configuration specific to a previous network state. Try generating a fresh restore script from the Azure portal and executing it again.
As a last resort, create a test VM in the same VNet/subnet as your existing VM, and attempt to restore the backup there. This can help rule out VM-specific issues that might be causing the iSCSI connection to fail.Mks_1973,
I have worked through most of your suggestions. I am looking at the DNS issue currently. I had to do something similar with DNS forwarders for our Azure Storage Account file shares.
I am also setting up the Recovery Vault logging suggested to get some more detailed information.
I appreciate your suggestions and will let you know what I come up with.
Mks_1973,
I got the issue resolved. The DNS forwarder was not set up correctly. I set it up using Create and use private endpoints for Azure Backup - Azure Backup | Microsoft Learn as a guide and was successful in a test restore.
Thank everyone for their input.
