Azure Backup best practices become critical when immutability locks are irreversible, vault redundancy is wrong for the workload, and the restore drill runs during an actual incident.
Azure Backup best practices that hold up at scale
1. Pick Recovery Services vault or Backup vault by workload requirements
Azure has two vault types that support different workloads and different feature sets. The decision is made during vault creation and cannot be reversed without recreating the vault and migrating protected items.
Recovery Services vault is the long-standing option. It supports Azure VMs, SQL Server on Azure VMs, SAP HANA on Azure VMs, Azure Files, the Backup agent (MARS), and the Backup server (MABS).
Backup vault is the newer architecture, with support for Azure Blob Storage, Azure Disks, Azure Database for PostgreSQL Flexible Server, Azure Kubernetes Service, Azure Database for MySQL Flexible Server, and the secondary-region restore workflow.
Most teams inherit a Recovery Services vault from a prior project and use it for every new workload that comes along. The backup vault gets skipped, which disables the newer features that are only available through it.
The Backup vault path is where Microsoft is actively investing. Operational backup for Blob, immutable Backup vaults, and the cross-region restore enhancements all land in Backup vault first.
Create both vault types during environment setup, organized by workload. Use Backup vault for new PostgreSQL, AKS, Disk, and Blob workloads going forward. Keep existing Recovery Services vault deployments for established VM and Files workloads.
2. Use Enhanced policy for all new VM backups
Enhanced policy is the modern VM backup policy in Azure, generally available since April 2022. Standard policy is still the default in some Azure portal flows, which is how legacy configurations propagate into new deployments.
The feature gap between the two is significant for production workloads:
- Multiple backups per day. Enhanced policy supports backups as often as every 4 hours, up to 6 per day. Standard policy is limited to one daily backup.
- 30-day instant restore. Enhanced policy retains snapshots in the source region for up to 30 days (default 7). Standard policy maxes out at 5 days (default 2).
- Trusted Launch VM support. Enhanced policy natively backs up Trusted Launch VMs. Standard policy does not.
- Confidential VM support. Enhanced policy supports Confidential VMs with customer-managed keys; Standard policy does not.
- Smaller incremental snapshots. Enhanced policy uses block-level incremental snapshots that consume less storage than Standard's snapshot model.
Azure now supports in-place migration of VM backups from Standard to Enhanced policy, so you can move existing protected VMs without stopping protection or re-seeding backup data. Migration also lets you move VMs to Trusted Launch and adopt Premium SSD v2 / Ultra Disks without disrupting existing recovery points.
The simplest rule: every new VM backup uses Enhanced policy. Existing Standard deployments get migrated during planned maintenance windows. The legacy default should never propagate into a new vault.
3. Test in the Enabled state for at least 2-4 weeks before locking immutability
Azure immutable backups have three states: Disabled, Enabled (reversible), and Enabled and Locked (irreversible). The lock cannot be undone, even by Microsoft Support, and it commits the vault to its current retention rules for the lifetime of every recovery point inside.
The trap is in the defaults. Azure's default yearly retention is unusually long, and the Azure portal applies it without prompting. Teams click Apply on the lock without changing the default, thereby inheriting a multi-decade obligation.
One Microsoft Q&A thread documents a team that accidentally locked a vault with the default 99-year retention. They have no path to dismantle it for the better part of a century. Storage charges continue for the full retention period, whether the workload still exists or not.
The defense is straightforward: test in the reversible Enabled state for two to four weeks before locking. Run real backup, restore, stop-protection, and policy modification workflows. Confirm that retention values match your compliance framework's exact requirements before you commit them.
SoFi encountered the recovery side of this problem differently. The team needed fast recovery from clean backups. Their inherited workflows took a full day. After rolling out Eon, recovery time dropped to minutes, and the team stopped treating retention decisions as one-way commitments.
4. Configure MUA via Resource Guard in a separate subscription or tenant
Multi-User Authorization (MUA) is Azure's approach to preventing a single compromised admin account from disabling backup protection. The architecture uses a Resource Guard resource that lives in a separate subscription or tenant from the protected vault.
The Resource Guard's admin authorizes protected operations. Vault admins alone cannot perform them. The list includes disabling soft delete, disabling immutability, modifying immutability settings to reduce retention, modifying backup policies to reduce retention, and stopping protection with delete data.
The separation matters operationally. If the Resource Guard sits in the same subscription as the vault, a compromised production admin with subscription-level permissions can authorize their own destructive operations. The protection collapses to a single trust boundary.
The recommended architecture:
- The backup vault subscription holds the protected data under restricted RBAC.
- Resource Guard subscription includes the authorization layer, with different admins, different MFA enforcement, and, ideally, a separate Microsoft Entra tenant.
- Conditional Access policies on the Resource Guard subscription enforce additional verification before approving destructive operations.
Microsoft's resiliency security model places a vault at the "Maximum (Excellent)" level when MUA is enabled alongside an irreversible immutability lock or always-on soft delete. Skipping MUA leaves the vault dependent on RBAC alone, which a single compromise can defeat.
5. Enforce backup coverage with Azure Policy built-in initiatives at the management group level
Tags break at scale. Resources get created without tags, tags get applied inconsistently across teams, and tag values drift as workloads change purpose. Azure Policy initiatives close the gap by programmatically enforcing the backup assignment program.
Azure ships built-in policy definitions specifically for backup enforcement. The most useful ones include:
- "Configure backup on virtual machines with a given tag to an existing recovery services vault." Assigns the right vault and policy when the tag matches.
- "Configure backup on virtual machines without a given tag to a new recovery services vault." Catches resources that should be protected even when tagging fails.
- "Azure Backup should be enabled for Virtual Machines." Surfaces unprotected resources in audit reports.
- "Azure Backup vaults should use customer-managed keys for encrypting backup data." Enforces CMK on vaults that handle compliance workloads.
Initiatives group these into auditable units that apply across subscriptions through management group assignment. New subscriptions automatically inherit the policy, catching the gap before it appears.
In our experience, the most effective deployment pattern is to apply the initiative at the management group level for the entire production environment. The policy then automatically evaluates every new VM created across all in-scope subscriptions. Coverage gaps surface in Azure Policy compliance reports during normal operations, well before incident response would expose them.
Custom policies have their place. They require maintenance whenever Azure releases new resource types or features, whereas built-in initiatives are updated by Microsoft as the platform evolves.
6. Set vault redundancy per workload tier, then enable CRR where it earns its cost
Recovery Services vault redundancy choices have direct cost and recovery implications, and the defaults are often wrong for both. The three options:
- LRS (Locally Redundant Storage). Three copies in a single datacenter. Cheapest option. Protects against drive and rack failures.
- ZRS (Zone Redundant Storage). Three copies across availability zones in the same region. Mid-tier cost. Protects against datacenter failure.
- GRS (Geo-Redundant Storage). LRS plus async replication to a paired region. Roughly 2x the cost of LRS. Required for Cross-Region Restore (CRR).
Cross-Region Restore is the workflow that lets you restore a backup to a different region during a primary region outage. It is the only Azure-native option for cross-region recovery, and it requires GRS redundancy on the vault.
The redundancy choice is set during vault creation. Changing redundancy after backups exist requires vault recreation in some scenarios, which is operationally expensive.
The right approach by tier:
- Critical workloads with strict RTOs during regional outages: GRS with CRR enabled.
- Important workloads that can tolerate a few hours of regional unavailability: ZRS for in-region resilience without the cross-region cost.
- Standard workloads without regional disaster requirements: LRS for cost optimization.
Most teams default the entire estate to GRS or LRS without tier-based thinking. GRS-by-default doubles the storage spend on dev workloads. LRS-by-default leaves critical workloads without cross-region recovery options.
7. Use customer-managed keys via Azure Key Vault for compliance-critical vaults
Azure Backup vaults encrypt data at rest by default using platform-managed keys (PMK). The default is operationally simple, with no key rotation to manage and no Key Vault to configure. The trade-off is in control and audit.
Customer-managed keys (CMKs) place the encryption key in Azure Key Vault, under your control. The benefits matter most in regulated environments:
- Rotation control. You set the rotation policy and frequency, including automated rotation through Key Vault policies.
- Access policy management. Key Vault access policies and RBAC determine who can use the key, including the option to revoke vault access by removing the key permission.
- Audit visibility. Key Vault diagnostic logs capture every key operation, including which managed identity decrypted which vault data.
The configuration depends on a few prerequisites that must be met before vault creation. Soft delete and purge protection must be enabled on the Key Vault. A User-Assigned Managed Identity handles authentication between the backup vault and Key Vault. The key itself needs to be RSA-2048, -3072, or -4096 bits.
CMK is the right choice for vaults that protect workloads under PCI-DSS, HIPAA, ISO 27001 audits, or any framework that requires customer-controlled encryption. For development and non-regulated workloads, PMK is fine and keeps operational overhead down.
The mistake we see most often is teams enabling CMK on the Key Vault and skipping purge protection in the same configuration pass. A compromised admin can then permanently delete the key, and the corresponding vault data becomes unrecoverable. Soft delete with purge protection is what makes CMK durable.
8. Operate the backup estate from Backup Center
The Recovery Services vault and the Backup vault each have their own UI in the Azure portal. At small scale, vault-by-vault management is workable. At multi-subscription scale, it becomes a coverage liability.
Backup Center is the cross-subscription, cross-tenant pane built for fleet operations. It surfaces:
- Job status across every vault in the tenant, filtered by status, workload, region, or vault.
- Policy assignments across all vaults, with drift detection when a policy diverges from its baseline.
- Restore initiation from one console, including cross-region restore workflows.
- Coverage reports that map protected resources to backup state.
- Configuration audit for soft delete, immutability, and MUA across vaults.
The Backup Center view is what makes coverage gaps visible. A vault-by-vault workflow surfaces problems only when someone looks at the right vault. Backup Center surfaces them across the estate, in one place, every time the page loads.
For security teams, Backup Center is the integration point with Microsoft Sentinel and Microsoft Defender for Cloud. Backup health alerts, suspicious operation alerts, and compliance findings all flow through Backup Center into the SIEM workflow.
The practical rule: daily backup operations happen in Backup Center. The vault UI handles configuration, and Backup Center handles operations.
9. Test each Azure-specific granular recovery workflow on its own cadence
Azure Backup offers different granular recovery workflows for different workloads, each with prerequisites, time-to-restore characteristics, and failure modes that must be exercised independently.
The workflows in scope:
- VM File Recovery via iSCSI mount: Mounts the recovery point as an iSCSI target on a connected machine. You navigate the file system, copy files out, then dismount. The workflow is manual and time-consuming, and the connection script expires after a window.
- Azure Files item-level restore: Browse and restore individual files or folders directly from the file share recovery point. No mount step required.
- SQL Database point-in-time restore: Creates a new database instance at the chosen restore point. Even when you need a single record, the workflow restores an entire database.
- PostgreSQL flexible server PITR: Same pattern. Restoring to any point creates a new server, so rolling back to specific data requires manual extraction from the restored instance.
- Cosmos DB continuous backup restore: Restores to the chosen timestamp into either a new account or the same account, depending on the scenario. Same-account restore is typically preferred for deleted databases or containers.
- Blob object versioning and snapshots: Object-level recovery without restoring the storage account, when versioning was enabled at the time of the loss.
A generic "restore drill" that only tests VM full restore doesn't exercise any of these workflows. Each one needs its own test cadence:
- Full-environment restores: quarterly.
- VM File Recovery via iSCSI: monthly. The connection script behavior and the file copy time both need to be familiar to whoever responds in an incident.
- Database PITR: monthly. The new-instance-per-restore model affects RTO calculations because you also need to swap connections.
- Files item-level and Blob versioning: monthly. These are usually fast, which is precisely why teams skip testing them and then fumble during the actual incident.
Document each workflow as a separate runbook. The team responding at 2 AM needs the exact iSCSI mount steps, the exact PITR command, and the exact connection-swap sequence. Generic "restore from backup" instructions stall the response.
Azure Backup with Eon: where the structural gaps close
The nine practices above hold up when applied consistently. At scale, consistency is the hardest part, and several of the gaps are structural, not fixable by tightening Azure configuration alone.
Vault-type fragmentation, irreversible lock decisions, low Resource Guard adoption, inconsistent tagging, and per-workload restore complexity are all limitations that persist even when teams follow best practices.
Eon's Cloud Backup Posture Management (CBPM) addresses them at the source: continuous resource discovery and classification, logically air-gapped immutable backups applied by default across AWS, Azure, and GCP, and granular recovery that works the same way whether the target is a file, a database row, or a full environment.
Coverage drift surfaces in real time, so teams catch immutability gaps and policy misalignment before audits do. There's no per-vault lock to manage, no Resource Guard configuration required, and no per-workload runbook divergence. Cross-cloud restore means an Azure backup can recover into AWS, or GCP objects can move into Azure, without a separate migration project.
Storage costs run 30–50% lower than native cloud backup through incremental-forever backups and global deduplication. NETGEAR cut backup storage spend 35% after switching, and recovered a 10TB SQL Server database 88% faster.
AlphaSense, the AI-powered market intelligence platform serving 88% of the S&P 100, completed its initial backup in three days and reached production in 25, protecting petabytes of AWS data. Joseph Rozenfeld, EVP of Engineering, said Eon “matched the scale of our data and gave us a recovery approach to meet reliability SLOs of our mission-critical solution."
Eon's full Microsoft Azure integration covers VMs, storage accounts, databases, and Azure Kubernetes Service with immutability applied automatically.
Book a demo to see how Eon protects Azure backups with default immutability, granular recovery, and no per-vault lock commitments.
Frequently asked questions
What is the difference between Recovery Services vault and Backup vault in Azure?
Recovery Services vault supports Azure VMs, SQL on Azure VMs, SAP HANA, Files, and the Backup agent. Backup vault supports Azure Blob Storage, Disks, PostgreSQL Flexible Server, and AKS, and receives new Azure workloads first.
Should I lock immutability on my Azure Backup vault?
Yes, after testing in the reversible Enabled state for two to four weeks. The lock is irreversible, and Microsoft Support cannot override it, so confirm retention values match compliance requirements before committing.
What is Resource Guard in Azure Backup?
Resource Guard is the Azure resource that implements Multi-User Authorization for backup operations. It sits in a separate subscription or tenant from the vault, so destructive operations require approval from a different admin.
How do I migrate from Standard to Enhanced policy in Azure?
Azure now supports in-place migration of VM backups from Standard to Enhanced policy, so you can move existing protected VMs without stopping protection or re-seeding data. Plan the switch during a maintenance window, since the first Enhanced backup runs as a full snapshot.
Does Eon support immutability across AWS, Azure, and Google Cloud?
Yes, Eon applies the same logically air-gapped, immutable backups across AWS, Azure, and Google Cloud through Cloud Backup Posture Management. Granular recovery, cross-cloud restore, and drift detection work uniformly.
