A few years ago I had the privilege to attend Azure Site Recovery Boot Camp training at Microsoft’s Silicon Valley in Mountain View, CA. The experience was amazing, and I enjoyed it. In fact, we received a first-hand preview of the (yet to be released) ASR VMware replication/protection through the newly acquired InMage technology.
The training was led by Vishal Mehrotra, and one thing that he mentioned has stuck with me every since.
Simply: Backup is NOT Disaster Recovery.
Although that is a simple statement and may seem obvious, it is powerful.
Business Continuity & Disaster Recovery (BCDR)
When most organization think about BCDR, they usually only think about Backup. But that’s only one piece of the puzzle. The other piece is Disaster Recovery.
Here’s a quick definition of each component:
Disaster Recovery
When your sites, servers or applications have a catastrophic failure and you are required to run them in Azure or a secondary datacenter.
Backup
When your data is corrupted or lost and you need to restore your data or infrastructure to the original location or a new location.
Azure Backup vs. Azure Site Recovery
Both services are related, in that they both backup and restore data. But they have different purposes. Azure Backup is used to protect and restore data at a more granular level. So, if some files become corrupted, you can use Azure Backup to restore them. But, if you wanted to replicate the configuration and data of a system to another datacenter, then you would use Azure Site Recovery.
Azure Backup protects data on-premises and in the cloud. Azure Site Recovery coordinates replication, failover, and failback. Both services are important because your disaster recovery solution needs to keep your data safe and recoverable (Backup) and keep your workloads available (Site Recovery) when outages occur.
| Concept | Details | Backup | Disaster Recovery (DR) |
|---|---|---|---|
| Recovery point objective (RPO) | The amount of acceptable data loss if a recovery needs to be done. | Backup solutions have wide variability in their acceptable RPO. Virtual machine backups usually have an RPO of one day, while database backups have RPOs as low as 15 minutes. | Disaster recovery solutions have low RPOs. The DR copy can be behind by a few seconds or a few minutes. |
| Recovery time objective (RTO) | The amount of time that it takes to complete a recovery or restore. | Because of the larger RPO, the amount of data that a backup solution needs to process is typically much higher, which leads to longer RTOs. For example, it can take days to restore data from tapes, depending on the time it takes to transport the tape from an off-site location. | Disaster recovery solutions have smaller RTOs because they are more in sync with the source. Fewer changes need to be processed. |
| Retention | How long data needs to be stored | For scenarios that require operational recovery (data corruption, inadvertent file deletion, OS failure), backup data is typically retained for 30 days or less. From a compliance standpoint, data might need to be stored for months or even years. Backup data is ideally suited for archiving in such cases. | Disaster recovery needs only operational recovery data, which typically takes a few hours or up to a day. Because of the fine-grained data capture used in DR solutions, using DR data for long-term retention is not recommended. |
Azure Recovery Services
In the Azure Portal, Site Recovery and Backup were separate services. In the modern Azure Portal, these 2 services are contained within the Recovery Services Vault service.
Azure Site Recovery (ASR)
Azure Site Recovery (ASR) supports multiple scenarios, including Disaster Recovery, Migration, and Dev/Test.
- Automated VM level Replication and Failover
- Continuous log based replication (Not snapshots!)
- RPO of seconds and RTO of minutes
- 30 seconds, 5 mins, 15 minutes
- Planned and unplanned failover
- Orchestrated Recovery Plans for Disaster Recovery
- Failback support
- No impact DR Drills with Test Failover
- Migrate to Azure from anywhere
- Azure to Azure DR (NEW)
- Create on-demand test copies in Azure
ASR Use Cases
- Disaster Recovery
- Single click Application recovery
- Compliance Assurance without impacting Production
- Disaster Avoidance – Hurricane warning
- Failover during real disasters – Fire, Earthquake, etc.
- Migration
- No impact on production during replication – Just minutes of downtime during cutover
- Test before migration using Test failover
- Free Migration
- Dev/Test environment
- Using Test Failover get an identical copy of your production environment
- Use this for testing different scenarios like Patch Tuesday, New release testing
- Deploy new patches/bits to production with confidence.
Azure Backup (AB)
Azure Backup (AB) supports backups across your heterogeneous environment, including VMware virtual machines.
- Azure Backup is part of OMS add-on as well as sold standalone
- First party SaaS service running in public Azure
- Backs up Windows Server, SCDPM, IaaS VM to Azure
- Supports file/folder, VMs (Linux & Windows), SQL Server, Exchange Server, SharePoint Server
- Flexible long term retention policy
- Granular recovery
AB Use Cases
- Accidental deletion
- In the case that someone accidentally deletes business critical data, or that data become corrupted
- Patch Testing
- Take a backup (and restore) if patch testing fails or causes application issues
- Alternative location recovery
- Create a copy of your workload in an alternative location, whether for disaster recovery purposes or testing
- Security
- Secure your data from the growing threat of ransomware attacks
A Note About Encryption
Both Azure Backup and Azure Site Recovery include encryption.
With Azure Backup, the data is encrypted using AES256 and is transmitted over HTTPS. The data is also encrypted at rest, and you store and keep the encryption passphrase locally, it is never sent or stored in Azure.
With Azure Site Recovery, the data being transmitted is never inspected or intercepted. Only the metadata is used for orchestrating replication and failover. Both encryption-in-transit and encryption-at-rest (in Azure) are supported.
Site Recovery is ISO 27001:2013, 27018, HIPAA, DPA certified and is SOC and FedRAMP compliant.
In Conclusion
So in conclusion, both backup and site recovery is needed to ensure you are fully covered and have a complete BCDR solution. If you forego one piece, then you only have half the puzzle, and could be in a compromising situation.
By leveraging Azure Backup (AB) for long-term data retention (including protection against ransomware), and Azure Site Recovery (ASR) for quick failover with low RPO/RTO and on-demand copies for testing; your BCDR strategy is complete, and you will be ready for anything.