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:
- Fixed service cost: This cost is incurred regardless of the amount of data or bandwidth consumed.
- 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.
- 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.
Service | Protected Instances | Backup Policy Retention | Backup Storage Data Characteristics | Average Monthly Backup Data | Monthly Data Cost | Fixed Cost | Total Cost |
---|---|---|---|---|---|---|---|
Azure VM | 1 x 40 GB | 30 Days 5 Weeks 12 Months5 Years | Moderate ChurnGRS | 136 GB | $6.10 | $5.00 | $11.10 |
Azure VM | 1 x 500 GB | 30 Days 5 Weeks 12 Months5 Years | High ChurnGRS | 2,502 GB | $112.10 | $10.00 | $122.10 |
Azure VM | 1 x 1000 GB | 30 Days 5 Weeks 12 Months5 Years | Low ChurnLRS | 2,601 GB | $58.28 | $20.00 | $78.28 |
On-Prem Server | 1 x 40 GB | 30 Days 5 Weeks 12 Months5 Years | Moderate ChurnLRS | 136 GB | $3.05 | $5.00 | $8.05 |
On-Prem Server | 1 x 500 GB | 30 Days 5 Weeks 12 Months5 Years | High ChurnGRS | 2,502 GB | $112.10 | $10.00 | $122.10 |
On-Prem Server | 1 x 2000 GB | 30 Days 5 Weeks 12 Months5 Years | High ChurnGRS | 10,0008 GB | $448.40 | $40.00 | $488.40 |
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.
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.
Service | Protected Instances | Backup Policy Retention | Backup Storage Data Characteristics | Average Monthly Backup Data | Monthly Data Cost | Fixed Cost | Total Cost |
---|---|---|---|---|---|---|---|
SQL Server on Azure VM | 1 x 40 GB | 30 Days 5 Weeks 12 Months5 Years 15 Day Log Rotation | High ChurnGRS | 222 GB | $9.95 | $25.00 | $34.95 |
SQL Server on Azure VM | 1 x 500 GB | 30 Days 5 Weeks 12 Months5 Years 15 Day Log Rotation | Moderate ChurnGRS | 2,404 GB | $107.70 | $25.00 | $132.70 |
SQL Server on Azure VM | 1 x 1000 GB | 30 Days 5 Weeks 12 Months5 Years 15 Day Log Rotation | High ChurnGRS | 5,555 GB | $248.86 | $50.00 | $298.86 |
SQL Server on Azure VM | 1 x 2000 GB | 30 Days 5 Weeks 12 Months5 Years 7 Day Log Rotation | High ChurnGRS | 9,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.
Service | Protected Instances | Backup Policy Retention | Backup Storage Data Characteristics | Average Monthly Backup Data | Monthly Data Cost | Fixed Cost | Total Cost |
---|---|---|---|---|---|---|---|
SAP HANA on Azure VM | 1 x 40 GB | 30 Days 5 Weeks 12 Months5 Years 7 Day Log Rotation | Moderate ChurnLRS | 512 GB | $11.47 | $80.00 | $91.47 |
SAP HANA on Azure VM | 1 x 500 GB | 30 Days 5 Weeks 12 Months5 Years 7 Day Log Rotation | Moderate ChurnGRS | 6,400 GB | $286.76 | $80.00 | $366.76 |
SAP HANA on Azure VM | 1 x 1000 GB | 30 Days 5 Weeks 12 Months5 Years 15 Day Log Rotation | High ChurnGRS | 15,016 GB | $672.75 | $160.00 | $832.75 |
SAP HANA on Azure VM | 1 x 2000 GB | 30 Days 5 Weeks 12 Months5 Years 15 Day Log Rotation | High ChurnGRS | 30,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.
Service | Protected Instances | Backup Policy Retention | Backup Storage Data Characteristics | Average Monthly Backup Data | Monthly Data Cost | Fixed Cost | Total Cost |
---|---|---|---|---|---|---|---|
Azure Files | 1 x 40 GB | 30 Days 5 Weeks 12 Months10 Years | Low ChurnLRSTransaction Optimized Tier | 64 GB | $3.84 | $3.00 | $6.84 |
Azure Files | 1 x 500 GB | 30 Days 5 Weeks 12 Months10 Years | High ChurnGRSHot Tier | 2,002 GB | $126.54 | $5.00 | $131.54 |
Azure Files | 1 x 1000 GB | 30 Days 5 Weeks 12 Months10 Years | High ChurnGRSTransaction Optimized Tier | 4,004 GB | $400.45 | $5.00 | $405.45 |
Azure Files | 1 x 2000 GB | 30 Days 5 Weeks 12 Months5 Years 15 Day Log Rotation | ModerateChurnGRSCool Tier | 4,805 GB | $240.75 | $5.00 | $245.75 |
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 Solution | Features | Limitations |
---|---|---|
Azure VM Extensions | Full 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 Agent | Supports 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 MABS | Supports 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 hourly | Can only backup Azure VMs if MABS is deployed in AzureInfrastructure as a Service requiring additional monitoring and maintenance |
System Center DPM | Supports Windows and LinuxApplication-aware with agents for SQL, Exchange, etc.Granular backups and restoresVMware and Hyper-V support | Licensing 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.
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.
Related Blogs
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,…
Ready to Run Webinar: Achieving Automation Maturity in FinOps
Automation has become essential to keeping up with today’s fast-paced cloud environment. Manual FinOps processes create bottlenecks, delay decisions, and…