File restores failure from Azure VM Backup 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.