Azure VM Backup Failed – UserErrorResourceContentionOnVM On Linux server

Question

Azure VM Backup Failed – UserErrorResourceContentionOnVM On Linux server

Vaishnavi Suresh 0

The Azure VM backup/restore point creation is failing for a Linux server with the error UserErrorResourceContentionOnVM.

The error indicates that restore point creation may have failed due to resource contention on the VM, such as high CPU, memory usage, disk resource usage, disk space exhaustion, or swap space utilization.

Initial investigation:

The Linux VM is currently running and available.
CPU utilization is approximately 20%, with no indication of high CPU usage.
Memory utilization metrics are not available in Azure Monitor for this VM.
Server-level login access is not available to validate memory utilization, disk free space, disk I/O, and swap space.

Could you please advise what additional checks can be performed from the Azure side, or whether the Linux/server team needs to validate memory usage, disk space, disk I/O, and swap utilization from within the server? Also, please advise if there are any specific Azure Backup or VMSnapshotLinux extension logs/checks that should be reviewed before retrying the backup.

0 comments

2 answers

Your answer

Answer 1

Hello Vaishnavi Suresh,

Thank you for your question.

The error UserErrorResourceContentionOnVM indicates that Azure Backup was unable to create the restore point due to possible resource contention on the virtual machine. This can occur because of disk space exhaustion, high CPU load, disk resource usage, memory utilization, swap space utilization, or other guest OS resource constraints.

From the Azure side, please verify the following:

Ensure the VM is in a Running state and the Azure Linux Agent (WAAgent) is healthy.
Confirm that all VM extensions are in a Provisioning Succeeded state and that there are no failed or stuck extensions.
Review Azure Monitor metrics for CPU and disk activity around the backup failure timeframe.
Check that no other backup, snapshot, extension deployment, or maintenance operations are running concurrently.

As Azure does not provide visibility into guest OS memory, swap usage, disk free space, or disk I/O without server access, we recommend engaging the Linux/server team to validate the following from within the VM:

Memory utilization
Swap space utilization
Disk free space
Disk I/O performance and contention
WAAgent health
Backup extension health

Please check for disk space exhaustion, high CPU load, disk resource usage, memory usage, and swap space utilization on the server. Once you have confirmed that there are no resource contention issues on the virtual machine, please retry the backup operation and share the outcome.

https://learn.microsoft.com/en-us/azure/backup/backup-azure-troubleshoot-vm-backup-fails-snapshot-timeout

Answer 2

From the Azure side, the supported checks are:

In Azure portal, go to Virtual Machines > Settings > Properties and confirm the VM Status is Running and Agent status is Ready. If the Linux guest agent is stopped or inconsistent, restart the guest agent.
In Azure portal, go to Virtual Machines > Settings > Extensions and verify all extensions are in provisioning succeeded state. A failed extension or a VM stuck in an updating/provisioning failed state can interfere with restore point creation.
Verify the Linux VM agent is current. Basic Azure Backup troubleshooting explicitly calls out ensuring the VM Agent (WA Agent) is the latest version.
Verify the VM has internet connectivity.
If Security-Enhanced Linux is in use, exclude /var/lib/waagent from the security policy and make sure the Backup extension is installed.
If application control software is in use, check whether it is blocking the backup extension. For Linux restore point troubleshooting, the documented path to review/exclude is /var/lib.

For Linux-side validation, the server team should check the items that Azure cannot confirm without guest access:

Memory usage
Disk free space
Disk I/O pressure
Swap utilization
Guest agent health
Backup extension health

For logs, the documented Linux restore point troubleshooting logs to collect from inside the VM are:

/var/lib/waagent/*.xml
/var/log/waagent.log
/var/log/azure/*

If more detail is needed, verbose logging for waagent can be enabled by editing /etc/waagent.conf, changing Logs.Verbose from n to y, saving the file, and restarting waagent.

If the guest agent is not running, the documented start commands are:

sudo systemctl start walinuxagent
for other Linux distributions: sudo systemctl start waagent

If the VM uses application-consistent backup scripts, also review the VmSnapshotLinux extension-related conditions:

corrupted Pluginhost file
incorrect VMSnapshotScriptPluginConfig.json
insufficient permissions on pre/post scripts
pre/post script timeouts

Those checks are relevant when backup is expected to be application-consistent.

Given the current limitation that server login access is unavailable, Azure-side validation is limited to VM state, agent status, extension provisioning state, connectivity, and any security policy/application control conditions. Validation of memory, disk space, disk I/O, and swap utilization requires the Linux/server team to inspect the guest OS directly before retrying the backup.

References: