Azure Backup provides a centralized interface for managing backups for a wide range of enterprise services, including:

  • Azure Managed disks 
  • Azure File Shares
  • SQL Server Databases
  • SAP HANA databases
  • SharePoint, Exchange, Hyper-V workloads
  • VMWare and bare metal machines 

Azure Backup ensures application consistency through its Volume Shadow Copy Service (VSS) and pre/post processing scripts. Storage options include Locally Redundant Storage (LRS), Geo-Redundant storage (GRS), Zone Redundant Storage (ZRS), and Read-Access Geo-Redundant Storage (RA-GRS).  

Azure Backup Pricing

There are three main components that drive the cost of Azure Backup pricing: 

  1. Fixed service cost: This cost is incurred regardless of the amount of data or bandwidth consumed. 
  2. Storage: This cost is based on how much data you store and depends on backup sizes, retention periods, the frequency of your backup schedule, and storage types.
  3. Average daily data churn: This cost is based on how often your data changes.

 The Azure Pricing Calculator allows you to configure the various cost elements to determine your approximate Azure Backup costs. However, as multiple variables contribute to the total cost, using the Azure Backup pricing estimator offers greater accuracy. This Excel-based worksheet tool also provides accurate Azure Backup cost estimates for the various workloads protected by this service. 

Calculating Azure Backup Costs

Because so many elements are factored into the total cost of backing up a particular workload, calculating your Azure Backup costs requires specifying the key details for each service. Use the following sections to get an idea of how to accomplish this. 

Azure Virtual Machines (VMs) or On-Premise Servers

Key Details:

  • The “used size” (vs. provisioned size) of disks that require backing up
  • The total number of servers multiplied by their amount of “used disk space” 
  • The expected amount of data churn (high, moderate, or low)
  • Backup policy retention time lengths (daily, weekly, monthly, yearly)
  • Backup storage redundancy (Locally Redundant Storage (LRS), Geo-Redundant Storage (GRS), or Read-Access Geo-Redundant Storage (RA-GRS))

The table below provides an indicative cost for various Azure VM or on-premise server backup scenarios. 

ServiceProtected InstancesBackup Policy Retention Backup Storage Data CharacteristicsAverage Monthly Backup DataMonthly Data CostFixed CostTotal Cost
Azure VM1 x 40 GB30 Days 5 Weeks 12 Months5 Years Moderate ChurnGRS136 GB$6.10$5.00$11.10
Azure VM1 x 500 GB30 Days 5 Weeks 12 Months5 Years  High ChurnGRS2,502 GB$112.10$10.00$122.10
Azure VM1 x 1000 GB30 Days 5 Weeks 12 Months5 Years  Low ChurnLRS2,601 GB$58.28$20.00$78.28
On-Prem Server1 x 40 GB30 Days 5 Weeks 12 Months5 Years  Moderate ChurnLRS136 GB$3.05$5.00$8.05
On-Prem Server1 x 500 GB30 Days 5 Weeks 12 Months5 Years High ChurnGRS2,502 GB$112.10$10.00$122.10
On-Prem Server1 x 2000 GB30 Days 5 Weeks 12 Months5 Years High ChurnGRS10,0008 GB$448.40$40.00$488.40
Hybrid Cloud Solutions Demo

See the best multi-cloud management solution on the market, and when you book & attend your CloudBolt demo we’ll send you a $75 Amazon Gift Card.

Book demo

SQL Server on Azure VMs

Key Details

  • The data size of the SQL servers that require backing up
  • Number of SQL servers with that size
  • Expected compression
  • Expected log size as a percentage of the SQL server size
  • The expected amount of data churn (high, moderate, or low)
  • Backup type; daily differentials with weekly, monthly, yearly full backups, or daily, weekly, monthly, yearly full backups
  • Backup policy retention time lengths (daily, weekly, monthly, yearly)
  • Backup storage redundancy (Locally Redundant Storage (LRS) or Geo-Redundant Storage (GRS))

The table below provides an indicative cost for various SQL in Azure VM backup scenarios.

ServiceProtected InstancesBackup Policy Retention Backup Storage Data CharacteristicsAverage Monthly Backup DataMonthly Data CostFixed CostTotal Cost
SQL Server on Azure VM1 x 40 GB30 Days 5 Weeks 12 Months5 Years 15 Day Log RotationHigh ChurnGRS222 GB$9.95$25.00$34.95
SQL Server on Azure VM1 x 500 GB30 Days 5 Weeks 12 Months5 Years 15 Day Log RotationModerate ChurnGRS2,404 GB$107.70$25.00$132.70
SQL Server on Azure VM1 x 1000 GB30 Days 5 Weeks 12 Months5 Years 15  Day Log Rotation High ChurnGRS5,555 GB$248.86$50.00$298.86
SQL Server on Azure VM1 x 2000 GB30 Days 5 Weeks 12 Months5 Years 7 Day Log RotationHigh ChurnGRS9,510 GB$426.05$426.05$526.05

SAP HANA in Azure VMs

  • The sum of the full backup size of each of the databases, as reported by SAP HANA
  • Number of SAP HANA servers with that size
  • Expected log size as a percentage of the SAP HANA database size
  • The expected amount of data churn (high, moderate, or low)
  • Backup type; daily differentials with weekly, monthly, yearly full backups, or daily, weekly, monthly, yearly full backups
  • Backup policy retention time lengths (daily, weekly, monthly, yearly)
  • Backup storage redundancy (Locally Redundant Storage (LRS) or Geo-Redundant Storage (GRS))
  • The option to check your estimates for a different region or discounted rates

The table below provides an indicative cost for various SAP HANA in Azure VM backup scenarios.

ServiceProtected InstancesBackup Policy Retention Backup Storage Data CharacteristicsAverage Monthly Backup DataMonthly Data CostFixed CostTotal Cost
SAP HANA on Azure VM1 x 40 GB30 Days 5 Weeks 12 Months5 Years 7 Day Log RotationModerate ChurnLRS512 GB$11.47$80.00$91.47
SAP HANA on Azure VM1 x 500 GB30 Days 5 Weeks 12 Months5 Years 7 Day Log RotationModerate ChurnGRS6,400 GB$286.76$80.00$366.76
SAP HANA on Azure VM1 x 1000 GB30 Days 5 Weeks 12 Months5 Years 15  Day Log Rotation High ChurnGRS15,016 GB$672.75$160.00$832.75
SAP HANA on Azure VM1 x 2000 GB30 Days 5 Weeks 12 Months5 Years 15 Day Log RotationHigh ChurnGRS30,033 GB$1,345.89$320.00$1,665.49

Azure files shares

Key Details: 

  • Size (in GB) of the file shares
  • The number of storage accounts hosting the file shares with the quoted size
  • The expected amount of data churn (high, moderate, or low)
  • Type of storage account (standard or premium) 
  • Backup policy retention time lengths (daily, weekly, monthly, yearly)
  • Backup storage redundancy (Locally Redundant Storage (LRS), Geo-Redundant Storage (GRS), or Zone Redundant Storage (ZRS))
  • Performance tier (Transaction Optimized, Premium, Hot, Cool)
  • The option to check your estimates for a different region or discounted rates

The table below provides an indicative cost for various Azure file share scenarios.

ServiceProtected InstancesBackup Policy Retention Backup Storage Data CharacteristicsAverage Monthly Backup DataMonthly Data CostFixed CostTotal Cost
Azure Files1 x 40 GB30 Days 5 Weeks 12 Months10 Years Low ChurnLRSTransaction Optimized Tier64 GB$3.84$3.00$6.84
Azure Files1 x 500 GB30 Days 5 Weeks 12 Months10 YearsHigh ChurnGRSHot Tier2,002 GB$126.54$5.00$131.54
Azure Files1 x 1000 GB30 Days 5 Weeks 12 Months10 Years  High ChurnGRSTransaction Optimized Tier4,004 GB$400.45$5.00$405.45
Azure Files1 x 2000 GB30 Days 5 Weeks 12 Months5 Years 15 Day Log RotationModerateChurnGRSCool Tier4,805 GB$240.75$5.00$245.75
A comprehensive approach to hybrid cloud management
Platform
Multi Cloud Integrations
Cost Management
Security & Compliance
Provisioning Automation
Automated Discovery
Infrastructure Testing
Collaborative Exchange
CloudHealth
Morpheus
CloudBolt

Azure Backup Architecture

Azure Backup leverages four different technologies: Azure virtual machine extensions, Microsoft Azure Backup Server (MABS),  System Center Data Protection Manager (DPM), and Microsoft Azure Recovery Services (MARS).  

  • VM Extensions:  Uses small applications in post-deployment to backup VMs.
  • MABS: Deployable using an on-premise server or an Azure virtual machine. As you run it on a server you manage, it uses the Infrastructure as a Service (IaaS) cloud computing service model. 
  • DPM: The same as MABS except for licensing; if you have System Center in your on-premise environment, then DPM falls under that model. 
  • MARS: Deployable using a lightweight agent on selected workloads; does not need any infrastructure to operate and uses the Platform as a Service (PaaS) cloud computing service model. 

Azure’s setup wizard specifies which architecture should be used based on the type of workload you want to back up. The following screenshots walk through the setup wizard. 

In the second example, when we choose Azure as the workload’s location and select a virtual machine, it uses the Azure VM extension to protect the workload.

The solution selected by Azure depends on a combination of workload and location. The table below details the limits and benefits of each Azure Backup solution.

Azure Backup SolutionFeaturesLimitations
Azure VM ExtensionsFull VM backup for Windows or Linux with no additional agent neededApplication-aware snapshots using Volume Shadow Copy Services (VSS) on Windows and pre- and post-processing scripts on LinuxPlatform as a Service; no additional backup infrastructure needed One scheduled backup per day, however, you can also execute three on-demand backups per day No monthly or yearly backup supportLimited granularity as you can only restore at the disk levelNo on-premise backup support
Azure MARS AgentSupports backup for on-premise and Azure virtual machinesPlatform as a Service; no additional backup infrastructure needed No application awareness; backups are limited to files, folders, and volumesNo Linux supportLimited to 3 scheduled backups per day
Azure MABSSupports Windows and LinuxApplication-aware with agents for SQL, Exchange, etc.Granular backups and restoresVMware and Hyper-V supportNo additional licensing costSQL backups every 15 minutes; other workloads are backed up hourlyCan only backup Azure VMs if MABS is deployed in AzureInfrastructure as a Service requiring additional monitoring and maintenance
System Center DPMSupports Windows and LinuxApplication-aware with agents for SQL, Exchange, etc.Granular backups and restoresVMware and Hyper-V supportLicensing costInfrastructure as a Service requiring additional monitoring and maintenance

Azure Backup Cost Optimization 

You can optimize your Azure Backup costs in the following ways. 

1. Optimize Backup Policies

Microsoft Azure Backup offers three backup policies: full backups, differential backups, and incremental backups. Each policy type has its advantages and disadvantages regarding cost, recovery point objectives, and recovery time objectives. The key to optimizing Azure Backups is to apply the appropriate policies to the relevant workloads. Configuring a blanket policy for every server, database, or file storage location is inefficient.  

Recovery Point and Recovery Time Objectives

Recovery points and the recovery time form the core components of any backup strategy.  

  • Recovery Point Objective (RPO): Relates to the point in time the backup takes place. For example, if you run backups once daily, your RPO is 24 hours. In this instance, should you need to restore your data, the maximum amount of information you may lose is 24 hours. 
  • Recovery Time Objective (RTO): Represents the amount of time it would take to restore the data from backup. For example, if you keep data on a local disk, your recovery time will be far shorter than restoring data from a data center in another part of the world.  

Your backup policy’s RPO and RTO determine the type of backup you need for each workload. It also dictates your backup schedule. If your backup strategy requires a very high RPO, you need to ensure your backups run more frequently. Regarding the RTO, full backups offer the fastest recovery times as you only need to recover one backup.

Differential backups offer the second-fastest RTO as you need to perform two restore operations: the last full backup and the latest differential. Incrementals are potentially the slowest backup type to recover. As you need to restore the last full backup and every incremental since that point, you may need to perform several operations to recover data.  

Optimizing Recovery Point and Recovery Time Objectives

If your workloads do not need a very high RPO, setting your backups to run less frequently will lower your Azure Backup storage costs. The same approach can also save you money when it comes to your RTO. For example, running a full backup every day stores more data than a full backup once a week and an incremental every other day. Reviewing the Optimize tab in your Azure Backup reports is a quick and efficient way to determine which workloads have daily full backups configured. You can click on the backup policy from this screen and amend it for workloads that need a lower RPO. 

2. Reviewing Backups for Deleted Resources

The Azure Backup service stores backups until an administrator deletes them. Although the retention policies determine the number of successful backups it retains, the data remains perpetually if a workload no longer exists. There may be instances where an organization may need to keep this information. For example, some regulatory frameworks obligate companies to store records for several years. However, in many instances, administrators neglect to delete the backups when they decommission a particular service.  

Regularly reviewing your Azure Backup reports can help you determine if you have any backups taking up storage that you no longer need. You can also configure these reports to provide details on inactive resources. This report configuration also helps you identify any protected resources that have not reported a successful backup for an extended time. You can find this information by navigating to the Optimize tab and selecting the Inactive Resources tile.  

3. Reduce Retention Periods

The retention periods you specify when configuring your Azure Backup policies affect the cost you need to pay for the service. In some instances, you may meet your compliance requirements and RTO and RPO objectives by reducing the duration of your retention periods.  

For example, web servers may need backing up but do not need long retention periods; databases may need longer retention periods with backups that run more frequently.  You can set retention periods when configuring your Azure backups.

4. Backup selectively

In many cases, you only need to protect some of the data in a particular workload. For example, a virtual machine may have a second drive to store non-production data, or a database server may contain a combination of test and production information. In these instances, configuring a full backup of the entire virtual machine or database is inefficient and costly, especially if you are backing up a large quantity of data. 

The Azure Backup service gives you the option to include or exclude particular objects from your backup policy. For example, if you need to backup an Azure VM, you can select to include or exclude certain disks. It also has an OS disk-only option ideal for servers that host vital services but no data, such as web servers.   

A comprehensive approach to hybrid cloud management

Only solution with automated discovery, testing, provisioning, security, and cost management

A `single pane`for infrastructure spanning on-premise, private cloud, and multiple public clouds

A comprehensive framework that extends your existing tool investments and fills the gaps

Azure Backup Limitations

Although Azure Backup offers many features that make it an enterprise-grade data protection solution, the service does have some limitations. Before deploying Azure Backup, administrators must ensure these limitations do not contravene any compliance obligations or business requirements.  

The list below details some of the service’s limitations. 

  • Maximum backup frequency: The maximum backup frequency for SQL Server is every 15 minutes, and other workloads are once per hour using MABS/DPM. The MARS agent only allows a maximum of three backups per day. If you are backing up using the VM extension, then that backup frequency drops even further to once a day.  
  • Disks: Azure Backup does not support Ultra SSD, temporary, and NVME/ephemeral disks.  
  • Static IP addresses: VMs configured with a static IP address lose the association should you restore the VM.   
  • Linux Support: The MARS agent does not support Linux. If you need to protect an Azure Linux VM, you will need to use the Azure VM extension. MABS/DPM Linux support is limited to on-prem Hyper-V and VMware platforms.
You Deserve Better Than Broadcom

Speak with a VMWare expert about your migration options today and discover how CloudBolt can transform your cloud journey.

Demand Better

Explore the chapters:

Related Blogs

 
thumbnail
The New FinOps Paradigm: Maximizing Cloud ROI

Featuring guest presenter Tracy Woo, Principal Analyst at Forrester Research In a world where 98% of enterprises are embracing FinOps,…

 
thumbnail
FinOps Evolved: Key Insights from Day One of FinOps X Europe 2024

The FinOps Foundation’s flagship conference has kicked off in Europe, and it’s set to be a remarkable event. Attendees familiar…

 
thumbnail
FinOps for AI: Navigating the Wild West of Generative AI Costs

Buckle up, folks! The rapid evolution of cloud services and the rise of generative AI are reshaping how organizations approach…

 
thumbnail
Is Your FinOps Practice Ready for AI? Here’s How to Find Out

As a FinOps leader, you’re likely seeing the mad dash toward AI across industries—from automating workflows to cutting operational costs,…