Azure Backup - Frequently asked questions

Yes. You can create up to 500 Recovery Services vaults, per supported region of Azure Backup, per subscription. If you need additional vaults, create an additional subscription.

You can register up to 1000 Azure Virtual machines per vault. If you're using the Microsoft Azure Backup Agent, you can register up to 50 MARS agents per vault. And you can register 50 MABS servers/DPM servers to a vault.

Protection of up to 2000 datasources/items across all workloads (such as IaaS VM, SQL, AFS) is the recommended limit per vault. For example, if you have already protected 500 VMs and 400 Azure Files shares in the vault, we would recommend protecting up to 1100 SQL databases in it.

You can only have up to 200 policies per vault. However, adding new backup policies or editing current policies through Azure Resource Manager (ARM) templates or Azure Automation clients such as PowerShell, CLI is limited to 50 over a span of 24 hours.

Server data that you want to recover together should use the same passphrase when you set up backup. If you want to isolate recovery to a specific server or servers, use a passphrase for that server or servers only. For example, human resources servers could use one encryption passphrase, accounting servers another, and storage servers a third.

Yes. To move a Recovery Services vault, refer this article

No. Backup data stored in a vault can't be moved to a different vault.

The storage replication type by default is set to geo-redundant storage (GRS). Once you configure the backup, the option to modify is in disabled state and can't be changed.

If you've already configured the backup and must move from GRS to LRS, then see How to change from GRS to LRS after configuring backup.

• ILR is supported for Azure VMs backed up by Azure VM backup. For more information, see article
• ILR isn't supported for online recovery points of on-premises VMs backed up by Azure Backup Server (MABS) or System Center DPM.

To move backup data out of Recovery Services Vault, you need to restore the necessary data. If your vault contains backup of on-premises data, use the corresponding agent (MARS, MABS, or DPM) to restore to on-premises.

We don't support exporting data directly from the Recovery Services vault to on-premises storage for backup of cloud workload (Azure VMs, SQL, and SAP HANA in Azure VMs). However, you can restore these to the corresponding cloud resources in Azure Storage Accounts, and then move the data to on-premises. You can also export this data to on-premises via Data Box or Import/Export.

If a GRS vault without CRR capability enabled, the data in the secondary region can't be accessed until Azure declares a disaster in the primary region. In such a scenario, the restore happens from the secondary region. When CRR is enabled, even if the primary region is up and running, you can trigger a restore in the secondary region.

Yes. To move a subscription (that contains a vault) to a different Microsoft Entra ID, see Transfer subscription to a different directory.

Yes. Ensure that you do the following:

Recovery Services vault and Backup vault are both supported in Azure Backup, and target the backup and restore of different datasources. You need to create the appropriate vault based on the datasource type that you want to protect.

The following table lists the various datasources that each vault supports:

No. Currently, Azure Backup supports only copying restore points from one vault to another. You can move snapshots to a different region using the VM restore point APIs, but this isn't supported for Vault-tier recovery points.

• For the agent running on Azure VMs, read this FAQ.
• For the agent used to back up Azure file folders, read this FAQ.

Yes.

• You can back up Windows Server or Windows machines up to three times a day by MARS backup. You can set the scheduling policy to daily or weekly schedules.
• You can back up DPM up to twice a day. You can set the scheduling policy to daily, weekly, monthly, and yearly.
• You can back up Azure VMs once a day by Standard backup policy.

Azure Backup supports these operating systems for backing up files and folders, and apps protected by Azure Backup Server and DPM.

Azure Backup doesn't support 32-bit operating systems.

For Azure VM Linux backups, Azure Backup supports the list of distributions endorsed by Azure, except Core OS Linux and 32-bit operating system. Other bring-your-own Linux distributions might work as long as the VM agent is available on the VM, and support for Python exists.

Learn more about the latest workloads supported by DPM and MABS Server.

Sizes limits are as follows:

The following table explains how each data source size is determined.

There's no limit on the total amount of data you can back up using a Recovery Services vault. The individual data sources (other than Azure VMs), can be a maximum of 54,400 GB in size. For more information about limits, see the vault limits section in the support matrix.

Data backed up from Azure Backup Agent, DPM, and Azure Backup Server is compressed and encrypted before being transferred. With compression and encryption is applied, the data in the vault is 30-40% smaller.

No, you can't view the expiration time for the scheduled backups. However, you can view the expiration time for the on-demand backups through backup jobs.

No, Azure Backup doesn't support deleting or purging individual items from stored backups.

No. All data that was transferred into the vault before the backup job was canceled remains in the vault.

• Azure Backup uses a checkpoint mechanism to occasionally add checkpoints to the backup data during the backup.
• Because there are checkpoints in the backup data, the next backup process can validate the integrity of the files.
• The next backup job will be incremental to the data previously backed up. Incremental backups only transfer new or changed data, which equates to better utilization of bandwidth.

If you cancel a backup job for an Azure VM, any transferred data is ignored. The next backup job transfers incremental data from the last successful backup job.

No, backup items in a vault can't be deleted if the corresponding Resource Group has a delete lock.

Yes, they both have daily, weekly, monthly, and yearly retention policies.

Yes, you've customize policies. For example, you can configure weekly and daily retention requirements, but not yearly and monthly.

No. Retention policies can only be applied on backup points. For example, this image shows a retention policy for backups taken at 12am and 6pm.

No. The time to recover the oldest or the newest point is the same. Each recovery point behaves like a full point.

Typical long-term retention point products store backup data as full points.

• The full points are storage inefficient but are easier and faster to restore.
• Incremental copies are storage efficient but require you to restore a chain of data, which impacts your recovery time

Azure Backup storage architecture gives you the best of both worlds by optimally storing data for fast restores and incurring low storage costs. This ensures that your ingress and egress bandwidth is used efficiently. The amount of data storage, and the time needed to recover the data, is kept to a minimum. Learn more about incremental backups.

You can create up to 9999 recovery points per protected instance. A protected instance is a computer, server (physical or virtual), or workload that backs up to Azure.

• Learn more about backup and retention.

There's no limit on the number of recoveries from Azure Backup.

No. Recovery is free and you aren't charged for the egress traffic.

When a new policy is applied, schedule and retention of the new policy is followed.

• If retention is extended, existing recovery points are marked to keep them according to new policy.
• If retention is reduced, they're marked for pruning in the next cleanup job and subsequently deleted.

When backups are stopped and the data is retained, existing policy rules for data pruning will cease and data will be retained indefinitely until initiated by the administrator for deletion.

Yes. Data is encrypted on the on-premises machine using AES256. The data is sent over a secure HTTPS link. The data transmitted in cloud is protected by HTTPS link only between storage and recovery service. iSCSI protocol secures the data transmitted between recovery service and user machine. Secure tunneling is used to protect the iSCSI channel.

Yes. The data in Azure is encrypted-at-rest.

• For on-premises backup, encryption-at-rest is provided using the passphrase you provide when backing up to Azure.
• For Azure VMs, data is encrypted-at-rest using Storage Service Encryption (SSE).

Microsoft doesn't decrypt the backup data at any point.

The encryption key used by the Microsoft Azure Recovery Services (MARS) Agent is derived from a passphrase that should be at least 16 characters long. For Azure VMs, there's no limit to the length of keys used by Azure KeyVault.

The key used to encrypt the backup data is present only on your site. Microsoft doesn't maintain a copy in Azure and doesn't have any access to the key. If you misplace the key, Microsoft can't recover the backup data.

Next steps

Read the other FAQs:

• Common questions about Azure VM backups.
• Common questions about the Azure Backup agent