Share via

NS01 - DC - VM Restoration using Azure MARS

nikhil satpute 2 Reputation points
2026-04-20T15:08:00.51+00:00

Hello Tech-Xperts,

I would like to share a scenario and seek your guidance on how best to achieve the requirement.

I have an on-premises Hyper-V environment consisting of a single-node cluster hosting 3–4 VMs. For business continuity, all VMs are backed up to a secondary Azure region using the Microsoft Azure Recovery Services (MARS) Agent.

I understand that MARS backup does not support restoring a VM as a ready-to-use virtual machine in Azure, unlike solutions such as Azure Backup (Azure VM Backup) or Veeam Backup & Replication.

However, I would like to check whether an indirect restoration approach is feasible. The proposed approach is as follows.

Restore to Local Hyper-V:

  • Restore VM data using the MARS agent
  • Locate the restored .vhd/.vhdx files and any associated VM configuration files
  • Import the VM into Hyper-V

Could you please advise if this approach is viable, or if there is a more effective method to restore full VMs either back to Hyper-V or into Azure?

Regards

Nikhil

Azure Backup
Azure Backup

An Azure backup service that provides built-in management at scale.

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Naveena Patlolla 9,660 Reputation points Microsoft External Staff Moderator
    2026-04-28T19:42:09.0066667+00:00

    Hi @nikhil satpute
    No VM configuration backup: MARS does not capture VM settings like CPU, memory, network, or checkpoints

    only data files.

    Better alternatives available: For full VM backup and restore, use MABS (Azure Backup Server) or Azure Site Recovery (ASR) instead of MARS.

    Please let me know if you face any challenge here, I can help you to resolve this issue further

    If the solution was helpful, please click "Upvote"

    Was this answer helpful?

    0 comments
  2. Suchitra Suregaunkar 14,010 Reputation points Microsoft External Staff Moderator
    2026-04-20T17:14:38.8266667+00:00

    Hello @nikhil satpute

    Thank you for posting your question on the Microsoft Q&A platform.

    The MARS agent is a file-and-folder-level backup solution. It does not natively support VM-level backup or restore so there is no direct way to restore a complete Hyper-V VM with its configuration, checkpoints, and networking using MARS alone.

    MARS agent supports these restore scenarios only:

    • Restore individual files and folders (Instant Restore up to ~6 MBps, suited for total size under 80 GB)
    • Restore all backed-up files in a volume (up to ~40 MBps, suited for larger data)
    • Restore Windows Server System State
    • Cross Region Restore (if enabled)

    User's image

    Reference: About restore using the MARS agent.

    The approach you've described using Windows Server Backup (WSB) to create VHD/VHDX files locally, backing those files to Azure via the MARS agent, then restoring and manually importing them into Hyper-V can technically work as a file-level workaround, but please be aware of the following limitations:

    • MARS treats VHD/VHDX files as regular files: There is no application-consistent VM snapshot integration at the MARS level. Consistency depends entirely on whether WSB completed a clean VSS-based backup before MARS picked up the files. [learn.microsoft.com]
    • VM configuration is not preserved: Only the virtual hard disk files are backed up. You would need to manually recreate the VM settings (vCPU, memory, network adapters, etc.) in Hyper-V Manager after restore.
    • Not supported for clustered Hyper-V: Since you mentioned a single-node cluster, be aware that this file-level approach is designed for standalone Hyper-V hosts only.
    • Schedule coordination is critical: The WSB backup must fully complete before the MARS scheduled backup runs, to avoid backing up an incomplete or in-progress VHD file.

    This is not an officially supported VM restore workflow , It is a manual workaround with inherent risks around consistency and completeness.

    So, please have a look into below recommended Alternatives:

    For proper VM-level protection of your on-premises Hyper-V environment, I'd recommend evaluating one of these two Microsoft-supported solutions:

    1. Microsoft Azure Backup Server (MABS): Best fit if your goal is VM-level backup and restore back to Hyper-V.

    MABS provides true host-level VM backup with the following capabilities:

    • Backs up entire VMs (including VHD/VHDX + configuration) at the host level using VSS-aware snapshots
    • Supports full VM restore to the original or an alternate Hyper-V host
    • Supports item-level recovery (ILR) extract individual files from a VM backup without restoring the entire VM
    • Supports Hyper-V clusters with CSV storage
    • Uses the MARS agent under the hood to replicate backup data to an Azure Recovery Services Vault for offsite protection.

    Reference:

    Back up Hyper-V virtual machines with MABS

    MABS protection matrix

    2. Azure Site Recovery (ASR): Best fit if your goal is to failover VMs to Azure during an on-premises outage.

    ASR continuously replicates your on-premises Hyper-V VMs to Azure and allows you to:

    • Perform a failover to Azure: Azure VMs are automatically created from the replicated data
    • Perform a failback to on-premises once your infrastructure is restored
    • Works with both standalone Hyper-V hosts and VMM-managed environments

    Reference:

    Set up disaster recovery of on-premises Hyper-V VMs to Azure

    Hyper-V to Azure disaster recovery architecture

    Hope this helps, feel free to follow up if you have any questions about setting up either MABS or ASR.

    If you found the comment helpful, please consider clicking "Upvote it".

    Thanks,

    Suchitra.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-04-20T15:08:22.83+00:00

    The described approach (restoring full VMs from MARS as .vhd/.vhdx plus config and importing them as ready-to-run VMs) isn’t supported with the MARS agent.

    MARS is a file/folder and system state backup solution, not an image-level/VM-level backup product. The supported recovery scenarios are:

    • Files and folders (same server or alternate server)
    • Volume-level data (same server or alternate server)
    • System state (same server or alternate server)

    These are explicitly documented as the recovery options for both same and alternate servers, and there is no VM-level restore or Hyper-V VM construct (VHD + VM configuration) restore path.

    From the MARS perspective, a VM running on Hyper‑V is just a Windows machine whose files and volumes can be backed up. Restores are at the file/volume/system-state level only. Any VHD/VHDX files that belong to Hyper‑V VMs are treated as regular files on a volume. While in theory one could:

    1. Use MARS to restore the volume or folder that contains the VHD/VHDX files.
    2. Manually re-create a Hyper‑V VM and attach the restored VHD/VHDX.

    this is not a documented or supported “VM restore” workflow for MARS, and there is no guarantee of application-consistent or crash-consistent VM images, nor any automation around restoring VM configuration, checkpoints, etc. It is essentially a manual file-level recovery, not a supported VM recovery feature.

    For full VM restore scenarios (either back to Hyper‑V or into Azure as a VM), a VM-aware backup solution is required, such as:

    • Azure VM backup (for Azure IaaS VMs) using the Azure Backup VM extension, which supports restoring entire VMs or disks directly from the vault.
    • A Hyper‑V–aware backup product (for on‑prem Hyper‑V) that performs image-level backups and can restore full VMs.

    MARS can still be used in parallel for file/folder/system-state protection, but it is not a replacement for VM-level backup/restore.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.