Azure backup policy is the configuration layer that decides what gets backed up, when, and for how long. This guide covers setup, Standard vs Enhanced, retention tiering, and where Eon's CBPM automates the same decisions at scale.
What is an Azure backup policy?
An Azure backup policy is a configuration rule set inside a Recovery Services vault or Backup vault. It defines when Azure backs up your resources and how long it retains each recovery point.
The policy applies to virtual machines, Azure Files, Azure Blobs, and managed databases. It combines a backup schedule with a tiered retention rule that can stretch from daily to yearly.
Azure Backup uses these policies to enforce protection consistently across your environment. One vault can hold many policies, and one policy can protect many resources.
Three components define every policy: the data source type, the backup schedule, and the retention range. Get those right, and Azure handles the rest of the lifecycle automatically.
Standard vs Enhanced policy: Which to use
Azure Backup supports two VM policy subtypes, and the differences matter for both cost and compatibility.
The Standard policy runs daily backups and keeps instant-restore snapshots for 2 days by default, configurable up to 5. It works fine for legacy VMs and stable workloads with relaxed recovery time objectives.
The Enhanced policy adds three big upgrades: sub-daily backups as frequent as every 4 hours, support for newer Azure hardware, and instant restore retention up to 30 days. Enhanced is the right default for production cloud-first workloads.
Two caveats matter. Enhanced policy incurs higher snapshot costs because more recovery points are stored. Once a VM is moved to Enhanced, Azure does not allow a downgrade to Standard.
How to create an Azure backup policy in 7 steps
The portal workflow follows the same pattern whether you back up VMs, files, or storage accounts. We use Azure Virtual Machines as the example here.
Step 1: Create a Recovery Services vault
Open the Azure portal and create a Recovery Services vault in the same region and subscription as the resources you plan to protect. The vault is the container that stores all backup data and policies.
Pick the storage redundancy carefully at this point. Geo-redundant storage (GRS) is the default, locally redundant storage (LRS) is cheaper for non-production, and zone-redundant storage (ZRS) suits production with data residency rules.
Once you configure backup against the vault, this redundancy setting locks in.
Pro tip: Name the vault something that signals scope, like rsv-prod-eastus-vms or rsv-finance-payroll. Naming saves hours during compliance audits and incident response.
Step 2: Choose the datasource type
Inside the vault, head to Resiliency, then Protection policies, and select Create Policy. Choose the datasource type that matches what you want to protect.
The options include Azure Virtual Machine, Azure Files, Azure Blobs, SQL in Azure VMs, and managed database services. Each data source type unlocks a different set of schedule and retention options.
Step 3: Pick policy subtype (Standard or Enhanced)
For VM workloads, select the Enhanced subtype unless you specifically need Standard for a legacy workload or budget constraint. Enhanced unlocks sub-daily backups as frequent as every 4 hours, multi-disk crash-consistent snapshots, and support for the latest Azure VM offerings.
Step 4: Configure the backup schedule
Pick the frequency: Hourly, Daily, or Weekly for Enhanced policies, or Daily and Weekly for Standard. For Hourly, choose an interval of 4, 6, 8, 12, or 24 hours.
Time zone matters. Azure does not auto-adjust for daylight saving time, so when the clocks move, you adjust the policy manually, or your backup windows drift by an hour twice a year.
Pro tip: Stagger schedules across policies. If you protect 500 VMs across five policies, set each policy to a different start time so the snapshot load spreads across the day.
Step 5: Set retention rules
Retention is the most consequential decision because it controls cost long after the policy is created. Azure Backup supports four retention tiers in a single policy: daily, weekly, monthly, and yearly.
A common pattern: keep daily recovery points for 30 days, weekly for 12 weeks, monthly for 60 months, and yearly for 10 years. That structure satisfies most compliance frameworks (SOC 2, GDPR, HIPAA, ISO 27001) and aligns with backup frequency and retention guidance in NIST SP 800-34.
Move long-term retention points to the Archive tier when possible. Storage costs drop sharply, with the trade-off that restores require rehydration and can take many hours depending on the priority you select.
Reserve Archive for yearly retention. Keep anything an incident response team might need urgently in the Standard tier.
Step 6: Enable immutability and security settings
Turn on vault immutability before you ever apply the policy to a production resource. Immutability uses write-once, read-many (WORM) semantics, so no one (including administrators) can delete recovery points before they expire.
Pair immutability with multi-user authorization (MUA) and resource guards for high-value vaults. These controls protect against malicious or accidental deletion during a ransomware event.
Step 7: Apply the policy to resources
With the policy created, go to Configure Protection in the vault, select the VMs (or files or blobs) you want to protect, and assign the policy. Azure deploys the policy to the vault and installs the backup extension on each VM agent.
The first backup runs at the next scheduled time, or you can trigger one immediately from Resiliency > Protected items > Backup Now. The initial backup is full; subsequent backups are incremental.
Built-in Azure Policy options for backup
Azure Policy (the governance service) integrates with Azure Backup to automate policy assignment at scale. Four enforcement definitions and one audit-only definition cover the most common enrollment patterns. Any enforcement variant can be scoped to a single resource group at assignment time.
- Configure backup on tagged VMs to a new Recovery Services vault. Backs up VMs carrying a specific tag to a freshly created vault with a default policy. Useful for decentralized teams managing their own backup configurations.
- Configure backup on tagged VMs to an existing vault. Backs up all tagged VMs into a single existing vault in the same location. The common pattern for a central backup team.
- Configure backup on untagged VMs to a new Recovery Services vault. Backs up every VM that does not carry a given exclusion tag to a new vault with a default policy.
- Configure backup on untagged VMs to an existing vault. Catches every VM in scope without an exclusion tag and backs it up to an existing vault. The strongest enforcement pattern for compliance-driven environments.
- Audit: Azure Backup should be enabled for Virtual Machines. Flags VMs without a configured backup but applies no changes. Use this first to assess coverage gaps before rolling out enforcement.
The audit-only policy is the right starting point for most teams. Roll it out in audit mode for a few weeks and fix the gaps it surfaces. Then move to one of the enforcement variants once the tag schema or resource group structure is solid.
Best practices for Azure backup policies at scale
These patterns separate teams running backup smoothly from teams firefighting policy drift every week:
- Split large VM fleets across multiple policies: Microsoft caps each backup policy at 100 VMs. A 500-VM fleet, for example, needs at least five policies, which we recommend running on staggered schedules.
- Use tags as your enrollment system of record: Build a tag schema that classifies workloads by criticality (prod, staging, dev), data sensitivity (PII, financial, public), and compliance scope (GDPR, HIPAA, SOX). Use Azure Policy to enforce backup assignment based on those tags.
- Pair daily backups with archive-tier retention for yearly backups: Use daily and weekly in Standard, push monthly and yearly to Archive, and review the retention range every two quarters to catch over-retention.
- Test restores quarterly, at a minimum: Pick a recovery point from each major policy every quarter, run a real restore to a test environment, and time the recovery. Recovery time objectives that exist only on paper fall apart in real incidents.
- Track policy drift across subscriptions: Track policy state in version control or a configuration management database so drift becomes visible before audit time.
How Eon automates Azure backup posture beyond what Azure Policy can do
Azure Policy automates enrollment. What it doesn't solve is everything that comes after: keeping classification current as environments grow, maintaining consistent posture across subscriptions, and making backup data useful outside of a recovery event.
Eon's Cloud Backup Posture Management (CBPM) handles the discovery and classification layer automatically; no tag schemas to maintain, no per-subscription rule upkeep.
The same posture model runs across AWS, Azure, and Google Cloud from a single console, with incremental-forever storage and global deduplication reducing backup spend by 30–50% compared to native tools.
SoFi cut recovery time from a full day to minutes after rolling out Eon, with CJ Keefe (Director, Corporate Infrastructure, DevOps & SRE) reporting over 100% ROI in the first year.
On Azure specifically, Eon goes a step further: every backup is automatically written as Apache Iceberg tables in Azure Blob Storage.
With native support for Microsoft Fabric and OneLake, that data becomes queryable directly from Power BI, SQL, Spark, and AI workloads. No restores, no ETL, no separate analytics copy. Backup stops being a passive insurance copy and becomes an active layer your data team can use for audits, investigations, and AI training.
Explore how Eon compares to Azure Backup on cost, recovery model, and posture coverage.
Choosing your Azure backup approach
Azure backup policy is the right starting point for most teams. Configure Enhanced policies for cloud-first workloads, structure retention around your compliance requirements, and use Azure Policy to automate enrollment.
That model starts to strain at fleet scale, across subscriptions, and across clouds — which is where CBPM and granular recovery take over.
Book a demo to see how Eon handles Azure backup policy across your environment.
Frequently asked questions
What is the difference between Azure Backup and Azure Site Recovery?
The main difference between Azure Backup and Azure Site Recovery is purpose. Azure Backup protects data with scheduled recovery points and retention rules, while Azure Site Recovery replicates entire workloads for failover during an outage.
How much does an Azure backup policy cost?
An Azure backup policy itself is free, but the backup data it generates is billed monthly. Costs depend on the number of protected instances, the size of front-end data, snapshot tier usage, and retention range.
Can I have multiple backup policies in the same vault?
Yes, a single Recovery Services vault can hold multiple backup policies. Microsoft caps each policy at 100 VMs, so split large fleets across several policies with staggered schedules.
What is the longest retention period for Azure Backup?
Azure Backup supports retention up to 99 years for yearly recovery points. Most compliance frameworks (SOC 2, GDPR, HIPAA) require retention of 7 to 10 years, so retention longer than that usually reflects internal preservation rules set by company policy.
Does Eon work with Microsoft Fabric and OneLake?
Yes, Eon writes Azure backups as Apache Iceberg tables in Azure Blob Storage. These appear in Microsoft Fabric through OneLake Shortcuts and can be queried as virtualized Delta tables. Power BI, SQL, Spark, and AI workloads access the backup data directly without restores or ETL pipelines.
.png)