Error when trying to restore SQL database

Question

I am trying to restore an SQL backup from an Azure vault but am getting an error after about an hour of it stating "In Progress". We have successfully restored files from the vault on a regular basis over the last year or so in exactly the same way, and the scheduled backups of the SQL databases continue to work OK (which suggests the Azure service health is OK, connectivity is OK etc)

The error we get is as follows: -

Error details

Error Code : UserErrorCannotConnectToAzureStorageService

Error message : Operation failed because Azure Backup workload extension could not connect to Azure Storage service.

Additional details : Error : UserErrorCannotConnectToAzureStorageService - Workload extension is unable to communicate with Azure storage accounts.

One thing that has changed since the last successful restore is that we have changed our public IP address - although I'm not sure if this is relevant, as I would have thought the whole restore process is 'internal' to Azure.

Any idea as to what might be causing the issue?

Answer 1

Hi Michael,

Thank you for reaching out and for providing the detailed error message here at Q&A portal.

The error you're seeing: Error Code: UserErrorCannotConnectToAzureStorageService 

Message: Workload extension is unable to communicate with Azure storage accounts.

typically indicates that the Azure Backup workload extension is unable to establish outbound connectivity to the Azure Storage service a critical step during the restore operation.

Based on your description, the recent change to your public IP address is likely relevant.

Even though the restore operation appears internal to Azure, it involves the VM (running the workload extension) communicating with the storage account, and this communication relies on outbound internet connectivity, especially if the storage account has firewall rules enabled.

Please try the following:

Check the Networking settings of the Azure Storage Account:

Go to the storage account used by Azure Backup.

Open “Networking” > “Firewalls and virtual networks”.

If access is limited to “Selected networks,” please ensure your new public IP address is whitelisted, or allow access from the appropriate virtual network/subnet.

Review NSG and firewall rules applied to the VM or its subnet:

Confirm that outbound access on port 443 (HTTPS) is allowed to *.blob.core.windows.net.

Enable “Allow trusted Microsoft services to access this storage account”:

This setting can be found in the storage account’s networking tab.

It enables services like Azure Backup to access the storage account securely, even if firewalls are enabled.

Retry the restore operation once network access has been verified.

Useful documentation:

Configure storage account network access

Azure Backup for SQL Server documentation

 

Best regards,

Alex

P.s. If my answer help to you, please Accept my answer

Answer 2

Thanks for the response.

When you say "Go to the storage account used by Azure Backup" - how do you identify that? We have 2 storage accounts but I can't see anything in the Vault details that identifies which Storage Account it uses. However, I'm pretty sure of which SA it is, although I've checked both, and they are both as follows.

Our new IP address is listed as 'trusted' and "Allow Azure services on the trusted services list to access this storage account" is ticked.

I can also see that the firewall on the VM NSG allows port 443 inbound to "Any" source, and Outbound on Any port to "Internet" which I assume covers *.blob.core.windows.net

So I'm not seeing anything that looks wrong. And to confirm, all of the backups are still working fine, it's only the restore that's failing.

Update : After checking the above (but changing nothing), whilst writing this response I tried a restore again, and after sitting there "In progress" for about 40 minutes, it worked. Strangely it reported that the job had taken 3 minutes - so I can only assume that communication was restored 37 mins into that job.

Its a bit frustrating not knowing what has caused the issue, but at least it's working now. Thanks