Considerations and Limitations

Prerequisites

Before recovering workloads, you must deploy a helper appliance template in the region where you plan to recover workloads. For more information, see Helper Appliance Template.

Storage Accounts

The storage accounts used for helper appliance template creation and for communication with helper appliance must have key authentication enabled.
Storage accounts with private endpoints are not supported.

Supported Backup Sources

Instant Recovery to Microsoft Azure supports recovering backups stored on the following Microsoft Azure object storage-based backup repositories:

Veeam Data Cloud Vault (object storage added as a backup repository)
Microsoft Azure Blob Storage (Azure Blob Storage object storage added as a backup repository)
External repository containing backups created by Veeam Backup for Microsoft Azure

Workloads and Architectures

Veeam Backup & Replication supports Instant Recovery to Microsoft Azure for the following workloads:

Microsoft Windows workloads that run Microsoft Windows Server 2016/Windows 10 and later.
Linux workloads (see the Supported Distributions & Versions section in Microsoft Docs).

Restoring of workloads running on the ARM CPU architecture is not supported.

Instant Recovery of Veeam Software Appliance with Veeam Backup & Replication is not supported.

Linux-Specific Requirements

We strongly recommend having dracut,mkinitrd or initramfs installed on Linux workloads that you plan to recover. Otherwise, they may not boot after restore.
Ensure that the iSCSI initiator is installed on the workloads that you plan to recover. For Debian, Ubuntu, and SUSE Linux distributions, the required package is open-iscsi. For RHEL-based distributions, install the iscsi-initiator-utils package.

Additionally, the Linux kernel must be configured with support for iSCSI boot.

Veeam Backup & Replication does not support recovery for Linux workloads with system mount points (/root, /boot, /etc, /usr, /var and others) that reside on ZFS pools. These systems will not boot after recovery. After recovery, you must manually import ZFS pools.
The cloud-init package is removed during the recovery process. If you require cloud-init functionality after restore, you must reinstall and reconfigure cloud-init manually. Do that only after migration is complete.
The waalinuxagent package is removed during the recovery process of some Linux distributives. If you require waalinuxagent functionality after restore, you must reinstall and reconfigure waalinuxagent manually. Do that only after migration is complete.

For optimal Instant Recovery performance, avoid keeping multiple Linux kernel versions installed on the workloads you plan to recover. During recovery, Veeam Backup & Replication rebuilds initramfs/dracut for each detected kernel. A large number of installed kernels can significantly increase the time required for the conversion and recovery operation.

Microsoft Windows-Specific Requirements

Microsoft Windows workloads configured with BIOS boot type that have Windows updates from March 2025 or newer will not boot after Instant Restore to Azure.
Microsoft Windows workloads where the boot partition and the operating system partition are located on separate drives are not supported for restore operations.
Instant Recovery to Microsoft Azure is not supported for Domain Controllers.
Instant Recovery to Microsoft Azure does not support the use of Azure Hybrid Use Benefit (AHUB).
During recovery, Veeam Backup & Replication assigns drive letters to iPXE disks. This disk may be visible within the Windows operating system. Do not modify the contents of this disk before migrating the VM to production. Otherwise, this can lead to failed restores or data loss.

Disks and VM Sizes

Veeam Backup & Replication does not support the Microsoft Azure VM sizes that support NVMe storage controllers. If you restore a VM with this configuration, the VM will fail to boot. For more information on the unsupported sizes, see Microsoft Docs.

Veeam Backup & Replication does not support restoring of 4K native disks (disks with 4096 bytes logical sector size). Contents of such disks will be unreadable after migration.

Instant Recovery to Microsoft Azure supports creating Premium SSD, Standard SSD, and Standard HDD disks. Ultra Disk and Premium SSD v2 are not supported.
Veeam Backup & Replication supports restoring disks equal or less than 4093 GB for OS disks and equal to or less than 32767 GB for other disks. During the restore process, VM OS disks can increase in size up to 2 GB because of conversion. For more information on all managed disk sizes that Azure supports, see Microsoft Docs. For more information on OS disk size that Azure supports, see Microsoft Docs. Note that supported disk sizes for Azure and Veeam Backup & Replication differ.
After performing migration or switchover, a restored VM may fail to boot and display the following error: "Creating a virtual machine from Marketplace image or a custom image sourced from a Marketplace image requires Plan information in the request." This issue occurs when the restored VM does not contain the required Plan Information (Publisher, Product, Name) in the boot disk metadata. If you encounter this error, contact Veeam Customer Support for further assistance.

Pricing

The price of a restored VM disk can become higher because of the increase in disk size during the restore process. For more information on pricing, see Managed Disks pricing and Unmanaged Disk and Page Blob pricing.

Security Type Support

Veeam Backup & Replication supports creation of Microsoft Azure VMs with the Standard security type. The Trusted launch security type is not supported.

Recovery Process Recommendations

For faster recovery, recover workloads to the same region where the backup is stored.
It is recommended to enable application-aware processing in the backup jobs settings. This helps the recovered VMs start faster.
It is recommended to use different subnets for the helper appliance (the Helper Appliance step) and the recovered workload (the Network step), otherwise some OSes may not boot.

After a VM is recovered, it is recommended to finalize the recovery as soon as possible, preferably within one or two days. This ensures optimal performance and stability, as Instant Recovery mounts the VM from the backup repository, and this is not intended for long-term production use.