Introduction
When disaster strikes, ensuring your data’s availability is critical. Azure Storage provides robust disaster recovery options to keep our applications running smoothly, even during unexpected outages. This guide explores the different types of failover available in Azure Storage and when to use them.
Failover Basics
Failover refers to the process of switching to a backup system when the primary system fails. In Azure Storage, failover options ensure data accessibility during unplanned outages or planned disaster recovery tests. Azure supports three types of failover:
- Customer-Managed Planned Failover
- Customer-Managed Unplanned Failover
- Microsoft-Managed Failover
Failover Types
1. Customer-Managed Planned Failover
- Use Case: Ideal for testing disaster recovery plans or proactively preparing for events like hurricanes.
- Data Loss: No data loss expected since both primary and secondary regions are operational during the failover.
- How It Works: The primary and secondary regions swap roles. After the failover, the original primary becomes secondary.
- Key Points:
- Requires the storage account to be available in both regions.
- Retains geo-redundancy.
2. Customer-Managed Unplanned Failover
- Use Case: Triggered when the primary region is unavailable due to an outage, and we need immediate access to our data.
- Data Loss: Some data loss is possible due to asynchronous replication between regions.
- How It Works: The secondary region becomes the new primary. The original primary’s data is lost.
- Key Points:
- Storage account converts to Locally Redundant Storage (LRS) after failover.
- Geo-redundancy must be manually reconfigured.
3. Microsoft-Managed Failover
- Use Case: Reserved for catastrophic disasters affecting an entire Azure region.
- Data Loss: Data loss is possible, similar to unplanned failover.
- How It Works: Microsoft initiates the failover, making the secondary region the new primary.
- Key Points:
- No action required by the customer.
- Only used in extreme cases.
Comparison of Failover Types
| Feature | Planned Failover | Unplanned Failover | Microsoft-Managed Failover |
|---|---|---|---|
| Trigger | Customer Initiated | Customer Initiated | Microsoft Initiated |
| Use Case | Testing or proactive | Outage recovery | Extreme disasters |
| Data Loss | None | Possible | Possible |
| Geo-Redundancy Post-Failover | Retained | Lost (converted to LRS) | Retained |
Key Considerations
- Last Sync Time: Before initiating unplanned failover, check the “Last Sync Time” to estimate potential data loss.
- Geo-Redundancy: Post-failover, you must manually re-enable geo-redundancy if using unplanned failover.
- Testing Failover: Use planned failover regularly to test disaster recovery plans without risking data loss.
- Design for High Availability: Build applications with redundancy and failover in mind to minimize downtime and data loss.
When to Use Which Failover
- Planned Failover: Testing recovery strategies or preparing for a forecasted disaster.
- Unplanned Failover: Responding to unexpected outages in the primary region.
- Microsoft-Managed Failover: Rely on this only during severe regional disasters.
Conclusion
Failover is a cornerstone of disaster recovery planning. By understanding the options and their implications, we can ensure our Azure applications remain resilient, even during unforeseen disruptions. We need to regularly test and update our disaster recovery plans to align with our organization’s needs.