Frequently asked questions-Back up Azure VMs

When you create a VM, you can enable backup for VMs running supported operating systems.

Initial backup is always a full backup and its duration will depend on the size of the data and when the backup is processed.

To improve backup performance see, backup best practices; Backup considerations and Backup Performance

Although the total backup time for incremental backups is less than 24 hours that might not be the case for the first backup.

No. Backup costs are separate from a VM's costs. Learn more about Azure Backup pricing.

If you're a VM contributor, you can enable backup on the VM. If you're using a custom role, you need the following permissions to enable backup on the VM:

• Microsoft.RecoveryServices/Vaults/write
• Microsoft.RecoveryServices/Vaults/read
• Microsoft.RecoveryServices/locations/*
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/*/read
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/read
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/write
• Microsoft.RecoveryServices/Vaults/backupFabrics/backupProtectionIntent/write
• Microsoft.RecoveryServices/Vaults/backupPolicies/read
• Microsoft.RecoveryServices/Vaults/backupPolicies/write

If your Recovery Services vault and VM have different resource groups, make sure you have write permissions in the resource group for the Recovery Services vault.

No. Specify the retention range for an on-demand backup job. By default, it's retained for 30 days when triggered from the portal.

Provide permissions for Azure Backup to access the Key Vault. Specify the permissions in PowerShell as described in the Enable backup section in the Azure Backup PowerShell documentation.

Yes, backups work seamlessly. There's no need to reconfigure anything.

The wizard only lists VMs in the same region as the vault, and that aren't already being backed up.

Yes. Backups run when a machine is shut down. The recovery point is marked as crash consistent.

Yes. You can cancel the backup job in a Taking snapshot state. You can't cancel a job if data transfer from the snapshot is in progress.

If you lock the resource group created by the Azure Backup Service, backups will start to fail. Remove the lock, and clear the restore point collection from that resource group to make the future backups successful. Follow these steps to remove the restore point collection.

Azure Backup creates a separate resource group in the format AzureBackupRG_<geo>_<number> to store ResourcePointCollections objects. Since this resource group is service owned, locking it will cause backups to fail. Locks can be only applied to customer-created resource groups.

Yes, Azure Backup supports standard SSD managed disks.

Snapshots can be taken on only data disks that are WA enabled and not OS disks. So, only data disks that are WA enabled can be protected.

Azure Backup can back up the WA-enabled data disk. However, the backup won't provide database consistency.

Azure Backup provides a streaming backup solution for SAP HANA databases with an RPO of 15 minutes. It's Backint certified by SAP to provide a native backup support leveraging SAP HANA’s native APIs. Learn more about backing up SAP HANA databases in Azure VMs.

The scheduled backup will be triggered within 2 hours of the scheduled backup time. For example, If 100 VMs have their backup start time scheduled at 2:00 AM, then by 4:00 AM at the latest all the 100 VMs will have their backup job in progress. If scheduled backups have been paused because of an outage and resumed or retried, then the backup can start outside of this scheduled two-hour window.

Azure Virtual Machine backup policy supports a minimum retention range from seven days up to 9999 days. By default, backup of VMs are kept for 7 days in snapshot and 180 days in vault. Any modification to an existing VM backup policy with less than seven days will require an update to meet the minimum retention range of seven days.

If you change the case (to upper or lower) of your VM or VM resource group, the case of the backup item name won't change; this is expected Azure Backup behavior. The case change won't appear in the backup item, but is updated at the backend.

Azure Backup now supports selective disk backup and restore using the Azure Virtual Machine backup solution. For more information, see Selective disk backup and restore for Azure VMs.

If tenant changes occur, you're required to disable and re-enable managed identities to make backups work again.

Azure Backup doesn't support backing up NFS files that are mounted from storage, or from any other NFS server, to Linux or Windows machines. It only backs up disks which are locally attached to the VM.

All the VM configurations required to perform the restore operations are stored in the VM backup. That includes the encryption copies of the VM encrypted keys, which are accessible to you on restore. The encryption copies can only be decrypted using the key vault. Temporary disks and memory state aren't captured in the snapshot.

Azure Backup can back up and restore tags, except NICs and IPs. Azure Backup honors the subscription limitations of Azure Resource Group and restores up to 50 tags.

For detailed information, see Subscription limits.

No, you can’t trigger on-demand backups by disabling scheduled backup.

Every Azure VM in a cluster is considered as an individual Azure VM. So, all backup operations are applicable as per individual Azure VMs.

Creating a VM Snapshot takes few minutes, and there will be a very minimal interference on application performance at this stage. But, data transfer to a vault takes a couple of hours; so we recommend scheduling backups during off business hours. Learn more about best practices for backup and restore.

Yes, a new disk added to a VM will be backed up automatically during the next backup, unless selective disk backup is configured on the VM. A newly added disks to the VM will have a Full snapshot (Initial Replica) taken on the first backup, the existing disks will continue the Incremental logic chain.

Restoring files and folders from encrypted VM backup is currently not supported, you must recover the entire VM to restore files and folders. See, steps to restore an encrypted Azure Virtual machine. However you can recover files from backups before they were encrypted.

Yes, you can do this when Transfer data to vault phase is in progress.

Azure Backup backs up encryption keys and secrets of the backup data. Generally, the keys are not restored in the Key vault, but Azure Backup allows restoring the keys during the loss of keys.

No, you can't retain one single restore point. When you delete the previous restore points, the chain gets deleted. Therefore, you can't selectively retain or delete a recovery point.

The maximum retentions of the backup points are:

• Retention of daily backup points: 9999 days
• Retention of weekly backup points: 5163 weeks
• Retention of monthly backup points: 1188 months
• Retention of yearly backup points: 99 years

Think of a VM restore as a quick create option for an Azure VM. This option changes disk names, containers used by the disks, public IP addresses, and network interface names. The change maintains unique resources when a VM is created. The VM isn't added to an availability set.

You can use the restore disk option if you want to:

• Customize the VM that gets created. For example, change the size.
• Add configuration settings that weren't there at the time of backup.
• Control the naming convention for resources that are created.
• Add the VM to an availability set.
• Add any other setting that must be configured using PowerShell or a template.

Yes, you can use backups taken before disks were migrated from unmanaged to managed.

The restore process remains the same. If the recovery point is of a point-in-time when VM had unmanaged disks, you can restore disks as unmanaged. If the VM had managed disks, then you can restore disks as managed disks. Then you can create a VM from those disks.

Learn more about doing this in PowerShell.

In the event of a managed VM restore, even if the VM creation fails, the disks will still be restored.

Yes. Even if you delete the VM, you can go to the corresponding backup item in the vault and restore from a recovery point.

For Managed Disk Azure VMs, restoring to the availability sets is enabled by providing an option in the template while restoring as managed disks. This template has the input parameter called Availability sets.

Instant Restore capability helps with faster backups and instant restores from the snapshots.

After you change the key vault settings for the encrypted VM, backups will continue to work with the new set of details. However, after the restore from a recovery point before the change, you'll have to restore the secrets in a key vault before you can create the VM from it. For more information, see this article.

Operations like secret/key roll-over don't require this step and the same key vault can be used after restore.

Yes, you can access the VM once restored due to a VM having a broken relationship with the domain controller. For more information, see this article.

Yes, you can cancel the restore job till the data transfer phase. Once it enters VM creation phase, you can't cancel the restore job.

The total restore time depends on the input/output operations per second (IOPS) speed and the throughput of the storage account. The total restore time can be affected if the target storage account is loaded with other application read and write operations. To improve the speed of restore operation, select a storage account that isn't loaded with other application data. Learn about the best practices for Azure VM backup and restore.

Azure Backup uses "attach" disks from recovery points and doesn't look at your image references or galleries. So in the policy you can check "storageProfile.osDisk.createOption as Attach", and the script condition will be:

if (storageProfile.osDisk.createOption == "Attach") then { exclude <Policy> }

To restore a VM in powered down state, you can create a VM or restore disks, but you can't replace an existing VM. Learn more about the available restore options.

Azure VM must be in the powered-off state while you restore. Otherwise, the restore operation would fail in the pre-check stage, with the error code UserErrorVmNotShutDown.

Also, before you swap VM disks, you must power off the VM.

Yes, the default maximum limit to trigger restore is 20 attempts per VM in 24 hours, and 24 hours window gets reset at UTC 00:00.

In the case of an unmanaged VM, the VM disk type is Premium SSD or HDD and depends on the SA in which VHDs exist. If you provide normal SA during restore, the VM disk would be HDD, and if you provide Premium SA, all disks would be Premium SSDs.

Yes, you can delete these files once the restoration process is complete. By default, Azure Backup retains these files for future use.

The encrypted keys are not expected to be present in the target region as part of Cross Regions Restore (CRR). Therefore, you need to restore the encrypted keys and secrets using the restored file. When the restore is complete, you can create Azure encrypted VM using restored disks.

Microsoft Windows allows a VM name that has maximum of 15 characters. Also, you can't specify a DNS host name that differs from the NETBIOS host name. However, you can create host headers for a website hosted on an Azure VM with the name as per recommendation.

Learn more about the VM naming convention limitations for Azure VMs.

Yes, Cross Subscription Restore now allows you to restore Azure VMs from a recovery point in one subscription to another under tenant as per Azure role-based access control (Azure RBAC) rules. Cross Subscription Restore is unsupported from snapshots and secondary region restores.

No, it's unsupported for Encrypted Azure VMs.

No, Cross Subscription Restore is unsupported from snapshot restore.

No, Cross Subscription Restore does not support restore from secondary regions.

Yes, it's supported for Cross subscription Restore.

Yes, Cross Zonal Restore now allows you to restore Azure zone pinned VMs to a different available zone using a recovery point in a vault with Zonal-redundant storage (ZRS) enabled as per Azure role-based access control (Azure RBAC) rules. It's also supported from vaults with Cross Region Restore (CRR).

Yes, Cross Zonal Restore now allows you to restore Azure non-zone pinned VMs to any available zones using a recovery point in a vault with Zonal-redundant storage (ZRS) enabled as per Azure role-based access control (Azure RBAC) rules.

No, it's unsupported for Encrypted Azure VMs.

No, Cross Zonal Restore is unsupported from snapshot restore.

Yes, Azure Backup support restore of Azure zone pinned VMs to secondary regions.

Yes, it's supported for Cross Zonal Restore.

After you unmount disks from the Azure portal, run the Python script with clean parameter (python scriptName.py clean) to clear the session and remove the mount paths of the recovery point from the machine.

The VM is backed up using the schedule and retention settings in the modified policy.

• If retention is extended, existing recovery points are marked and kept in accordance with the new policy.
• If retention is reduced, recovery points are marked for pruning in the next cleanup job, and subsequently deleted.

However, recovery points are specific to retention range frequency. For example, adding or modifying a yearly retention policy does not affect the retention of preexisting monthly recovery points.

1. Temporarily stop the backup and retain backup data.

2. To move virtual machines configured with Azure Backup, do the following steps:

   1. Find the location of your virtual machine.
   2. Find a resource group with the following naming pattern: AzureBackupRG_<location of your VM>_1. For example, AzureBackupRG_chinanorth2_1
   3. In the Azure portal, check Show hidden types.
   4. Find the resource with type Microsoft.Compute/restorePointCollections that has the naming pattern AzureBackup_<name of your VM that you're trying to move>_###########.
   5. Delete this resource. This operation deletes only the instant recovery points, not the backed-up data in the vault.
   6. After the delete operation is complete, you can move your virtual machine.

3. Move the VM to the target resource group.

4. Resume the backup.

You can restore the VM from available restore points that were created before the move operation.

Once a VM is moved to a different resource group, it's a new VM as far as Azure Backup is concerned.

After moving the VM to a new resource group, you can reprotect the VM either in the same vault or a different vault. Since this is a new VM for Azure Backup, you'll be billed for it separately.

The old VM's restore points will be available for restore if needed. If you don't need this backup data, you can stop protecting your old VM with delete data.

Yes, there's a limit of 100 VMs that can be associated to the same backup policy. We recommend that for more than 100 VMs, create multiple backup policies with same schedule or different schedule.

There is a daily limit of 1000 for overall configure/modify protections in a vault.

Currently, you can view retention settings at a backup item (VM) level based on the backup policy that's assigned to the VM.

One way to view the retention settings for your backups, is to navigate to the backup item dashboard for your VM, in the Azure portal. Selecting the link to its backup policy helps you view the retention duration of all the daily, weekly, monthly and yearly retention points associated with the VM.

You can also use Backup Explorer to view the retention settings for all your VMs within a single pane of glass. Go to the Backup Explorer from any Recovery Services vault, go to the Backup Items tab and select the Advanced View to see detailed retention information for each VM.

Azure VM Backup uses HTTPS communication for encryption in transit. The data transfer uses Azure fabric (and not public endpoints), which do not need Internet access for VM backup.

This API provision a script for invoking an iSCSI connection for file recovery from Azure Backup.

• You can disable this option using custom role-definitions by excluding API action.
• You can also disable this option across an organization using the deny assignment feature.

The policy takes effect immediately after the modifications of the parameters, such as retention, schedule, and so on. This is applicable for all new backups taken from the modified policy. However, the pruning of the recovery points (if applicable) according to the new policy takes 24 hours.

This feature is currently not supported. You can post any feature ask in the Azure Backup community portal.

Retention of stopped backups cannot be modified since they do not have any policy attached to it. However, you can resume protection and assign a policy.

Stopped backups are retained until manually deleted.

You need to check the subscription permissions in the secondary region. Write to us at AskAzureBackupTeam@microsoft.com for subscription enrollment.

Because Azure resources handle this traffic, it can't be determined by an external user.

RPO: The minimum RPO is 1 day or 24 hours when you're using Standard policy. If you use Enhanced policy, the minimum RPO is 4 hours.

This error appears when you try to start a VM after creating an Azure VM from a non-Marketplace image or swap the OS disk of a VM with a non-Marketplace image, and then the VM deployment fails. To resolve this issue, remove the plan information from the VM.

Azure Backup backs up the secrets and KEK data of the key version during backup, and restores the same. However, booting ADE VMs with older version keys are also possible.

Backup data fully replicated to the secondary region before the failure of the primary region will remain intact. This remains the case even after the primary region has recovered from the failure. In other words, the virtual machine can be recovered in the secondary region with the data it had before the failure as per the replication schedule. Note that the RPO for the secondary region is 36 hours i.e., data takes approximately 36 hours to be fully replicated from primary to the secondary region.

Expiry Time of recovery points are updated when Garbage Collector (GC) runs, which is every 24 hours. Once you update the backup policy, it can take up to 24 hours to show the updates in the Expiry Time, if there're no delays in GC jobs.

The expiry time for the latest recovery point doesn't appear because it has infinite retention until a newer one gets created. The expiry time of other recovery points will be available in the Azure Portal after 24 hours of creation, depending on when the garbage collection runs (that will be within 24 hours).

No, the restore operation (to the original or an alternate location) doesn't affect scheduled backups.

• Restore to Original Location: Azure Backup replaces the existing VM’s disks with the ones from the restore point. This process includes taking a snapshot of the current VM before the restore ensuring that the backup schedule remains.
• Restore to Alternate Location: Azure Backup creates a new VM using the restore point. This new VM won't have the same backup schedule as the original VM; you need to configure the Backup policy manually. Learn about Azure VM restore.

In these restore scenarios, the original backup policy and schedule for the original VM remain unaffected. However, if you want the restored VM (in the alternate location) to have a backup schedule, you need to set up the Backup policy.

In case of an Original Location Restore (OLR) or an Alternate Location Restore (ALR) for Azure VMs, Azure Backup performs the backup configuration as:

Storage Spaces Direct is not supported since it has data spread across two different virtual machines.

Storage spaces in a single VM not supported for application consistent VM backup. For application consistent VM backup, VSS freezes the I/O and ensures that disk snapshots are consistent. Storage Spaces can still perform writes in the background, breaking the application consistent guarantee. This can result in a small probability that the backup taken is not application consistent. Today, backup and recovery of VM with storage spaces is not blocked in the product.

Removing a disk, will simply not run any snapshot or data transfer for the removed disk. Number of disks included in the restore point will differ depending on the VM state at the time of the backup.

Resizing a disk will continue with incremental backups unless the underlying storage account of the disk changes, which results in a full backup.

For Initial Replica, a full backup will be re-initiated in case of failure. However, for Incremental the snapshot from the last successful backup will be compared to the latest snapshot to copy the changed data into the vault.