Restore Point Shows All Disks as LRS Even When Recovery Services Vault Is GRS – Need to Analyze All Restore Point Data

Hello Souvik, thanks for all the detail. This behavior is actually expected and here’s why:

1. Vault replication (LRS vs GRS) applies only to the vault’s underlying storage.
   • When you pick GRS on the Recovery Services Vault, Azure Backup replicates your vault data to a secondary region – but it does not change the storage SKU of the VM disks you backed up.
2. Restore-point metadata always shows the original disk SKU/redundancy (in your case Premium_LRS) because that’s what will be re-provisioned on restore.
   • The restore point record fields (e.g. storageAccountType in the recovery-point JSON) reflect the source disk settings, not the vault’s storage replication type.
3. Snapshot/replication flow:
   • Azure Backup takes a snapshot of each managed disk on your VM (preserving its SKU and LRS redundancy), ingests it into the vault, and then the vault service replicates that snapshot image to the paired region if you selected GRS.
   • During a restore, Azure Backup reads the snapshot metadata (Premium_LRS) and re-creates the disks using that SKU in your target region/resource group.
4. There’s no metadata inconsistency here – you’ll always see Premium_LRS in the restore point, even though the vault itself is geo-replicated.

If you need to inspect the full restore-point JSON, you can use PowerShell or REST:

• PowerShell

  # Login-AzAccount  

  $vault = Get-AzRecoveryServicesVault –Name "<yourVaultName>"

  Set-AzRecoveryServicesVaultContext –Vault $vault  

  $rp = Get-AzRecoveryServicesBackupRecoveryPoint –ItemName "<yourVMName>" –VaultId $vault.ID  

  $rp.Properties | Format-List *

• REST

GET

https://management.azure.com/Subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.RecoveryServices/vaults/{vaultName}/backupFabrics/Azure/protectionContainers/iaasvmcontainer;iaasvm;{rg};{vmName}/protectedItems/vm;{rg};{vmName}/recoveryPoints/{recoveryPointId}?api-version=2021-12-01

That JSON will show you:

• storageAccountType (e.g. Premium_LRS)
• backupManagementType (AzureIaasVM)
• sourceResourceId (original VM)
• Timestamps, incremental snapshot chain details, etc.

TL;DR

• GRS on the vault ⇒ geo-replication of vault blobs (backup data) only

• Restore-point metadata always shows source disk SKU (Premium_LRS)

• This is by design, not a metadata bug

—

Reference docs

• Troubleshoot vault transition LRS→GRS (explains vault vs disk redundancy)

https://learn.microsoft.com/azure/backup/backup-create-recovery-services-vault#modify-default-settings

• How to restore Azure VM data in portal (storage accounts section)

https://learn.microsoft.com/azure/backup/backup-azure-arm-restore-vms#storage-accounts

• Support matrix for Azure VM disaster-recovery (storage SKU support)

https://learn.microsoft.com/azure/site-recovery/azure-to-azure-support-matrix#replicated-machines-storage

Hope that clarifies things! Let me know if you need any help. Thanks.

Hi,

Azure Backup creates snapshots for your disks and the most recent snapshots are also retained so you can perform fast restore for the last days if needed. Those snapshots has the same replication type as on the disks. When these snapshots are also moved to the vault as data, that data on the vault is stored on the storage type of the vault - in your case GRS. So your data is still protected in the storage type of the vault but in case you need the fast restore you can use those snapshots. The retention of the snapshots is configured via the backup policy. With this in mind:

1. Clarified via the above explanation.
2. Confirmed.
3. Snapshots follow the same storage type as the disks.
   1. Disks -> snapshots -> backup vault.
      1. Snapshots has the same redundancy disks. They are another type of resource in Azure. When snapshots are moved to backup vault they are not moved as resource, the data from the snapshots is moved to the backup vault so that data have the redundancy of the backup vault when moved, it does not retain the redundancy of the snapshot.
         1. yes GRS applies to the backup vault storage
         2. expected behavior
4. Explanation provided.

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

1. Reason disks show as Premium_LRS while vault is GRS

Recovery Services vault redundancy (LRS/GRS) applies to how Azure Backup stores vault‑tier recovery points, not to the redundancy/SKU of the original managed disks or snapshots. VM disks themselves are Azure Managed Disks, which use their own redundancy model (for example, Premium_LRS, ZRS, etc.) independent of the vault.

In Azure VM backup:

• Recovery points exist in two tiers:
  • Snapshot tier (Instant Restore): snapshots are stored with the disk in the subscription.
  • Vault tier: copies of those snapshots are stored in the Recovery Services vault.
• The disk SKU and redundancy (for example, Premium_LRS) reflect the managed disk configuration, not the vault’s redundancy setting.

Therefore, seeing all disks as Premium_LRS in the restore point view is expected: it is showing the disk type/redundancy of the managed disks, while the vault’s GRS setting controls how the vault copies of those recovery points are replicated.

2. Whether the restore point stores original disk redundancy and ignores vault redundancy

From the documented behavior:

• Azure VM backups create recovery points based on the VM’s disks.
• For disk backup (and Instant Restore scenarios), Azure Backup uses incremental snapshots of the managed disks that are stored in the subscription on Standard HDD storage, regardless of the parent disk type.
• For VM backup to a Recovery Services vault, the vault’s redundancy (LRS/GRS) controls how the vault‑tier recovery point data is replicated and protected.

This implies:

• The original disk redundancy (Premium_LRS, etc.) is preserved as part of the disk metadata used when restoring or recreating the VM.
• The vault redundancy (GRS) applies to the backup data stored in the vault, not to the disk SKU shown in the restore point.

So the restore point is effectively:

• Preserving the disk’s SKU (Premium_LRS) as part of the VM/disk configuration.
• Using GRS only for the vault‑tier storage of the backup data.

3. Snapshot replication flow and how redundancy is preserved

Based on the documented backup/restore flow:

• For Azure Disk backup (and Instant Restore concepts used by VM backup):
  1. A Backup vault or Recovery Services vault is created with a redundancy setting (LRS/GRS).
  2. Azure Backup creates incremental snapshots of the managed disks.
     • These snapshots are stored in the subscription on Standard HDD storage, regardless of the parent disk type.
  3. For VM backup to a Recovery Services vault, snapshots are then copied to the vault tier, which is stored according to the vault’s redundancy (LRS/GRS).
  4. To restore, Azure Backup uses the selected recovery point and recreates disks/VMs with the appropriate disk SKU.

Key points:

• Disk SKU and redundancy: defined by Azure Managed Disks (for example, Premium_LRS, ZRS) and preserved in the restore configuration.
• Snapshot tier: incremental snapshots stored locally in the subscription (Standard HDD), used for Instant Restore.
• Vault tier: copies of those snapshots stored in the Recovery Services vault; the vault’s redundancy (LRS/GRS) applies here.
• The Backup vault storage redundancy setting doesn’t apply to Operational Tier snapshots for Azure Disk Backup; similarly, for VM backup, the vault redundancy applies to vault‑tier data, not to the disk SKU.

Thus:

• Disk redundancy is preserved as part of the disk/VM configuration metadata.
• GRS is a vault‑level durability setting, not a disk‑level redundancy override.

4. Whether this behavior is expected or a metadata inconsistency

From the documented concepts:

• Recovery points are copies of the original data.
• Vault redundancy (LRS/GRS) is a setting on the vault that controls how the vault stores and replicates recovery points.
• Managed disks have their own redundancy options (LRS, ZRS) separate from vault redundancy.

Given this separation of concerns, the behavior where:

• The vault is GRS, and
• The disks in the restore point are shown as Premium_LRS

is consistent with the design where:

• Vault redundancy protects the backup data in the vault.
• Disk redundancy (Premium_LRS) describes the managed disk type used when the VM is (re)created.

This aligns with expected behavior rather than indicating a metadata inconsistency.

5. Complete restore point metadata and backend logs

The provided documentation describes the following metadata and flows at a high level:

• Recovery point concept (snapshot vs. vault tier).
• Disk backup behavior using incremental snapshots.
• Storage redundancy options (LRS, ZRS, GRS, etc.) and their scope.
• Supported restore methods (create VM, restore disks, replace existing, cross‑region restore).

However, it does not expose:

• Full internal restore point metadata schema.
• Backend engineering logs or internal service traces.

Those internal details are not available in the documentation and require direct engagement with Microsoft Support for engineering‑level investigation and log review.

To obtain:

• Full restore point metadata beyond what the portal and APIs expose, or
• Backend logs and engineering analysis for a specific restore point,

open a support ticket so that the Azure Backup engineering team can:

• Pull internal diagnostics for the specific vault and restore point.
• Confirm the exact metadata stored and how it maps to disk redundancy and vault redundancy.

References:

• About Azure Virtual Machine restore
• How to restore Azure VM data in Azure portal
• Azure Backup - Frequently asked questions
• Support matrix for Azure VM backups
• Overview of Azure Disk Backup
• Azure Storage redundancy
• Changing Azure Storage redundancy configuration: FAQs
• Discover insights about your Azure Storage estate with Azure Storage Discovery using Azure Copilot