Fix Azure Backup Issues, Setup, Errors & Configuration

The vault is the foundation of everything in Azure Backup. If it's misconfigured, no amount of agent reinstalls or policy tweaks will fix your Azure Backup issues. So start here.

In the Azure portal, search for Recovery Services vaults and open yours. In the left navigation, go to Properties. Under Backup Configuration, verify:

• Storage replication type, Microsoft recommends GRS (Geo-redundant storage) as the default because it replicates your backup data to a secondary region hundreds of miles away. LRS is cheaper but only protects against local hardware failures. ZRS (Zone-redundant storage) is the right choice if you need data residency within a single region with no downtime tolerance. You cannot change this after backups exist in the vault.
• Cross Region Restore, this must be explicitly enabled. It's off by default. If you need to restore into a secondary region after a regional outage, flip this toggle to Enabled. Note: enabling this means your backup data costs will increase because the data is now accessible in the paired region.
• Soft Delete, should be enabled. Soft delete retains backup data for 14 days after deletion, protecting against accidental removal or ransomware attacks on your backup configuration.

Next, check that the vault is in the same region as the resources you're trying to back up. Azure Backup for VMs and managed disks requires the vault and the source resource to be in the same region. If they're in different regions, re-protection won't work.

Finally, confirm RBAC assignments. Go to your vault → Access control (IAM) → Role assignments. The service principal or managed identity doing the backup work needs at minimum the Backup Contributor role on the vault and Virtual Machine Contributor (or equivalent) on the VMs being protected. Missing role assignments are a very common silent failure, the portal won't scream about it, but jobs will fail with UserErrorAccessDenied.

When this step is done correctly, you'll see all vault properties showing expected values and no role assignment gaps in IAM. Then move to agent-level checks.

If you're backing up on-premises Windows machines, Windows Server, or individual files and folders from Azure VMs, you're using the Microsoft Azure Recovery Services (MARS) agent. Azure Backup MARS agent issues are among the most common complaints I see, particularly around registration failures and connectivity timeouts.

First, check the agent version. Open the MARS agent console on the affected machine: search for Microsoft Azure Backup in your Start menu. Go to Actions → About Microsoft Azure Backup. Note the version number and compare it against the current release. Outdated MARS agents will silently fail to connect. Download the latest agent from the Azure portal: go to your Recovery Services vault → + Backup → select On-premises → Files and folders → download the agent installer.

After updating, re-register the machine if it shows as Unregistered in your vault. You'll need the vault credentials file, download it from Recovery Services vault → Properties → Backup Credentials. The credentials file expires after 10 days, so generate a fresh one if the machine was never successfully registered.

Connectivity is the next thing to check. The MARS agent needs outbound HTTPS access on port 443 to these endpoints:

# Required outbound endpoints for MARS agent
*.backup.windowsazure.com
*.blob.core.windows.net
*.queue.core.windows.net
*.store.core.windows.net
dc.services.visualstudio.com

Run this command on the machine to test connectivity to the Azure Backup service URL for your region:

Test-NetConnection -ComputerName "pod01-manag1.backup.windowsazure.com" -Port 443

If TcpTestSucceeded returns False, your firewall or proxy is blocking the agent. Work with your network team to whitelist the required FQDN patterns. If your org uses a proxy server, configure the MARS agent to use it: in the agent console, go to Change Properties → Proxy Configuration and enter your proxy details.

Success looks like this: agent status shows as Registered in the vault's Backup Infrastructure → Protected Servers view, and a manual backup job completes without errors.

For Azure VM backup, there's no agent to install manually, Azure Backup works through a VM extension that gets installed automatically when you first protect a VM. But this extension fails more often than you'd expect. When it does, you'll see error codes like ExtensionSnapshotFailedNoNetwork, ExtensionOperationFailed, or GuestAgentSnapshotTaskStatusError in your backup job details.

The extension involved is called VMSnapshot (Windows) or VMSnapshotLinux (Linux). Check its status by going to your VM in the Azure portal → Extensions + applications. Look for the snapshot extension and check its provisioning state. If it shows Failed or Updating (stuck), delete it, Azure Backup will reinstall it fresh on the next backup job.

To delete and force reinstall via PowerShell:

# Remove the failed extension
Remove-AzVMExtension `
  -ResourceGroupName "YourResourceGroup" `
  -VMName "YourVMName" `
  -Name "VMSnapshot" `
  -Force

# Trigger a backup job to reinstall the extension
$vault = Get-AzRecoveryServicesVault -Name "YourVaultName" -ResourceGroupName "YourRG"
Set-AzRecoveryServicesVaultContext -Vault $vault

$container = Get-AzRecoveryServicesBackupContainer -ContainerType "AzureVM" -FriendlyName "YourVMName"
$item = Get-AzRecoveryServicesBackupItem -Container $container -WorkloadType AzureVM
Backup-AzRecoveryServicesBackupItem -Item $item

The other critical dependency is the Azure VM Guest Agent. The snapshot extension requires the Guest Agent to be running and healthy. On Windows VMs, check this in Services (services.msc), the service is called Windows Azure Guest Agent and should be running. On Linux, check with sudo systemctl status walinuxagent. If the Guest Agent is stopped or crashed, the backup extension can't function regardless of how the vault is configured.

Once the extension reinstalls and the Guest Agent is healthy, trigger another on-demand backup. You should see the job move through status: Transferring data to vault → Completed. That confirms the extension chain is working again.

One of the sneakiest Azure Backup problems I've encountered is when everything looks configured but backups are just not running on schedule. The culprit is almost always a broken or missing backup policy association. The vault has a policy. The VM exists. But they were never actually linked, or the link got broken during a resource move or subscription change.

In the Azure portal, go to your Recovery Services vault → Backup Items → select Azure Virtual Machine. You'll see a list of protected VMs. For each one, check the Last Backup Status column. If it says Warning or shows a date older than your policy frequency, click the item name → Backup Policy. Confirm the correct policy is assigned.

To reassign a backup policy via PowerShell (which also fixes stale associations):

$vault = Get-AzRecoveryServicesVault -Name "YourVaultName" -ResourceGroupName "YourRG"
Set-AzRecoveryServicesVaultContext -Vault $vault

# Get the policy you want to assign
$policy = Get-AzRecoveryServicesBackupProtectionPolicy -Name "DefaultPolicy"

# Get the VM item
$container = Get-AzRecoveryServicesBackupContainer -ContainerType "AzureVM" -FriendlyName "YourVMName"
$item = Get-AzRecoveryServicesBackupItem -Container $container -WorkloadType AzureVM

# Re-enable protection with the policy
Enable-AzRecoveryServicesBackupProtection -Policy $policy -Item $item

On the retention settings side: Azure Backup lets you retain data short-term and long-term through the policy. Short-term retention stores data in the vault's standard tier. For long-term retention beyond what standard tier supports, Azure Backup supports moving recovery points to the Archive tier, this is significantly cheaper for data you need to keep for compliance but rarely access. If your backup policy retention looks correct but old recovery points are disappearing, check whether Archive tier tiering rules are configured under your policy's Advanced Settings.

Also confirm that for databases like SQL Server in Azure VMs or SAP HANA, you have a separate backup policy for the log backup frequency in addition to the full/differential schedule. Missing log backups means you can't do point-in-time restores even if your full backups are healthy.

Getting backup jobs to run is half the battle. Actually getting data back when you need it is the other half, and restore failures are their own category of pain. The most common Azure Backup restore failure scenarios are: restoring to the wrong region, restoring a VM to a VNet that no longer exists, and permission gaps that only surface at restore time because nobody tested restore since the initial setup.

For Azure VM restore failures, go to your vault → Backup Items → select the VM → Restore VM. Before choosing a recovery point, check the date range, you'll only see recovery points that fall within your policy's retention window. If the recovery point you need is in the Archive tier, you'll need to rehydrate it first (which takes up to 15 minutes) before you can restore from it.

If restore is failing with UserErrorVnetNotFound or similar network errors:

# List available recovery points for a VM
$vault = Get-AzRecoveryServicesVault -Name "YourVaultName" -ResourceGroupName "YourRG"
Set-AzRecoveryServicesVaultContext -Vault $vault

$container = Get-AzRecoveryServicesBackupContainer -ContainerType "AzureVM" -FriendlyName "YourVMName"
$item = Get-AzRecoveryServicesBackupItem -Container $container -WorkloadType AzureVM

$startDate = (Get-Date).AddDays(-30)
$endDate = Get-Date

Get-AzRecoveryServicesBackupRecoveryPoint `
  -Item $item `
  -StartDate $startDate.ToUniversalTime() `
  -EndDate $endDate.ToUniversalTime()

When the target VNet no longer exists (common after infrastructure changes), choose the Create new virtual machine restore option instead of Replace existing VM, and specify a valid VNet and subnet. You can always move the restored VM to the correct VNet afterward.

For cross-region restore, restoring into a secondary region after a disaster, this only works if you enabled it on the vault beforehand (see Step 1). If it was enabled, go to your vault → Backup Items → switch the region dropdown to your secondary region → select the VM → Restore. The recovery points available in the secondary region are typically 12-24 hours behind the primary region, which is expected behavior per the official Azure Backup support matrix for cross-region restore.

You'll know the restore completed successfully when the new VM appears in the target resource group with status Running and all disks are attached. For file-level restores using the MARS agent, success means the recovered files appear in the target directory you specified during the recovery wizard.