Online recovery of VM is Failing

Question

Online recovery of VM is Failing

kartik Sarsawat 0

We are currently attempting to restore the virtual machine (TESTVM) from an Azure Online Recovery Point using Microsoft Azure Backup Server (MABS). During this process, we evaluated all three available recovery methods and encountered the following specific issues:

Recover to Original Instance:

Result: Failed.

Observed Issue: The restore job fails with an internal communication error (ID 130001 / ID 3111), indicating an outbound HTTPS (Port 443) connectivity or endpoint resolution issue between the MABS/MARS agent and Azure Storage endpoints.

Recover as Virtual Machine to Any Host (Alternate Location):

Result: Partially succeeded, requiring configuration alignment.

Observed Issue: The recovery completed and the VM was instantiated on the target host; however, the virtual disk remained bound to a temporary staging volume GUID (\\?\Volume...) rather than a permanent Cluster Shared Volume (CSV). As a result, the VM could not be registered for High Availability (HA) or projected into the Azure Local portal via Azure Arc.

Copy to a Network Folder / Recovery from Staging:

Result: Failed.

Observed Issue: Terminated due to insufficient disk space (Error ID: 100072). The current MABS staging volume on the C: drive ran out of capacity during the cloud data stream unpacking phase.

Bharath Y P 10,530 Reputation points Microsoft External Staff Moderator

2026-08-29T17:39:37.6966667+00:00
Hello kartik Sarsawat,

Thank you for sharing the recovery test results. Based on the observed behavior, please find our recommendations below for each recovery method:

1. Recover to Original Instance

The restore operation is failing with Error ID 130001 / 3111, which typically indicates a communication issue between the MABS/MARS agent and the required Azure endpoints.

Recommended actions:

Verify outbound HTTPS (TCP 443) connectivity from the MABS server to Azure Backup and Azure Storage endpoints.

Confirm DNS resolution is functioning correctly for Azure Backup-related endpoints.

Review any proxy, firewall, or network security configurations that may be blocking outbound traffic.

Validate that the MARS agent is healthy and able to communicate successfully with Azure services.

Once connectivity is confirmed, retry the restore operation.

2. Recover as Virtual Machine to Any Host (Alternate Location)

The recovery completed successfully; however, the restored VM disks are currently located on a temporary staging volume, which prevents High Availability configuration and Azure Arc projection.

Recommended actions:

Move the restored virtual disks from the temporary volume location to a permanent Cluster Shared Volume (CSV).

Update the VM configuration to reference the new CSV disk location.

Verify that the virtual machine starts successfully from the CSV storage.

Configure the VM as a clustered role and enable High Availability.

After the VM is highly available, perform Azure Arc synchronization so that it can be projected into the Azure Local portal.

3. Copy to a Network Folder / Recovery from Staging

The recovery failed with Error ID 100072 due to insufficient disk space on the MABS staging volume.

Recommended actions:

Increase the available free space on the MABS staging drive.

Consider relocating the MABS scratch/staging area to a larger volume if available.

Ensure sufficient temporary space is available for downloading and extracting the recovery data.

Verify that the destination network share has adequate free capacity and required permissions.

Retry the recovery after increasing the available staging storage.

Recommended Recovery Path

Based on the results, the "Recover as Virtual Machine to Any Host" option appears to be the most viable approach, as the VM restoration itself completed successfully. The remaining work is primarily related to post-recovery storage placement and HA configuration, which may provide the fastest path to bringing the workload back online.

Please let us know if you would like assistance with any of the above validation or configuration steps, and we will be happy to help.
kartik Sarsawat 0 Reputation points

2026-08-30T05:39:06.66+00:00

Thanks Bharati, it would be great if you can provide the required steps for each scenario like to configure staging and scratch location, port checking details

1 answer

Your answer

kartik Sarsawat 0 Reputation points

2026-08-30T05:39:06.66+00:00

Thanks Bharati, it would be great if you can provide the required steps for each scenario like to configure staging and scratch location, port checking details

Answer 1

Would try to bring in something that was not added already in the other answer.

Bharath YP has summed up it very well, I think i can add some perspective.

Based on the test results, each recovery option appears to be failing at a different stage of the recovery workflow, which helps narrow down the underlying dependency involved.

Recover to Original Instance

The restore operation fails with Error ID 130001/3111, which generally indicates that the recovery process cannot complete communication with Azure services during the restore workflow.

Rather than focusing only on the restore job itself, it may be useful to validate whether the MABS server can successfully reach the Azure Backup service endpoints outside of the recovery operation. If endpoint access, name resolution, or outbound HTTPS communication is interrupted, cloud recovery jobs may fail before the VM data is fully restored.

Key areas to review include:

Outbound HTTPS (TCP 443) connectivity.
DNS resolution of Azure Backup and Azure Storage endpoints.
Proxy and firewall configuration.
MARS agent health and registration status.

Recover as Virtual Machine to Any Host

This recovery path appears to have successfully recovered the VM payload itself, which is a useful diagnostic outcome because it confirms that:

The recovery point is valid.
Recovery data can be downloaded from Azure Backup.
MABS is capable of completing the restore process.

The remaining issue is not the recovery operation itself, but the placement of the recovered disks. Since the disks are attached through a temporary staging volume path rather than a Cluster Shared Volume (CSV), the VM does not meet the storage requirements typically expected for High Availability workloads and Azure Local integration.

A practical next step would be to migrate the restored virtual disks to permanent clustered storage and then validate HA registration and Azure Arc visibility from that location.

Copy to Network Folder

Error 100072 indicates that the recovery process exhausted available local staging capacity before completion.

An important point is that cloud recovery operations often require temporary local space even when the final destination is a network share. As a result, sufficient free space is required both for staging and for the target recovery location.

Consider validating:

Available free space on the MABS staging volume.
Scratch/staging location configuration.
Available capacity and permissions on the destination share

Overall Assessment

The most significant finding is that the alternate-host recovery completed successfully, which suggests that the Azure recovery point itself is healthy and usable.

Based on the observed behaviour:

The Original Instance recovery appears to be blocked by a communication or endpoint-access dependency.
The Network Folder recovery appears to be blocked by a local capacity constraint.
The Alternate Host recovery successfully restored the workload, leaving only post-recovery storage placement and HA configuration activities to complete.

This makes the alternate-host recovery path the strongest indicator that the backup data is intact and recoverable, while the remaining issues are environmental rather than recovery-point related.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.