Firstly, why is Database Disaster Recovery so Important? 

Databases are the backbone of an organization's critical data and information. They store vital records, customer details, financial transactions, and other essential business data. Any loss or damage to this data can have severe consequences, leading to operational disruptions, financial losses, and reputational damage.

This is why it is crucial to have robust DR measures in place to safeguard sensitive information. It provides peace of mind to businesses and their stakeholders. It instils confidence that even in the face of unforeseen events, critical data can be quickly recovered, maintaining business continuity and minimizing disruptions.

Given the higher RPO/RTO and data consistency requirements of databases, database-specific Disaster Recovery that guarantees database consistency and delivers near-zero data loss should be used. 

What Features do you Need for Database-Specific Disaster Recovery? 

• Ability to use a standby environment for read-only data access.

• Control over when transaction logs are applied to the standby environment, as a means of providing protection against data corruption or events such as ransomware.

• Continual application of transaction logs to the standby database provides near real-time indication of database consistency on the standby environment.  This provides a guarantee that the database can be recovered whenever it is needed.

• Ability to perform rolling upgrades of the environment, while minimizing (or eliminating) downtime.

• Ability to enable DR testing, to validate failover process and business continuity testing.

What are my Options for Database Disaster Recovery on Azure Site Recovery? 

Availability Groups combined with Azure Site Recovery 

For companies that utilize Always On Availability Groups (AOAGs) with SQL Server Enterprise Edition, ASR  provides integration to support replication and failover. ASR will provide the surrounding capabilities for managing the broader DR process, along with managing the necessary Availability Group (AG) aspects in failover. Site Recovery will fail over the SQL Server machines as part of the ASR plan. For the SQL Server database, you add the Failover AG script as a pre-action of the first group of the recovery plan. 

Learn about the ASR integration with SQL Server, including various approaches available and expected RTO/RPO timeframes in this Microsoft article.  

Data Consistency = Good 

• ASR leverages SQL Server Availability Groups to ensure data integrity and consistency between the primary and secondary systems. 

RPO/RTO Performance = Good 

• RPO and RTO timeframes are good, given that the database replication and failover are leveraging Availability Group capabilities.

• RPO: Minimal data loss, due to the secondary replica having asynchronous replication.

• RTO: Time taken to make a secondary replica of the primary.

DR Testing = Limited

• SQL Server AOAGs do not natively support DR Testing. ASR provides a step-by-step manual guide to perform a test failover. However, this is a manual process and not as automated as those components that have native DR testing.

ASR combined with AGs provides a nicely integrated DR solution, for those installations that are running SQL Server Enterprise Edition and wish to deploy AGs.  Data consistency and low RPO/RTO timeframes are a byproduct of leveraging SQL Server AGs. Given that there is no native DR testing capability with AGs, system administrators will be required to perform this process manually.

On the other hand, for customers on Standard Edition with many databases, the Basic AGs limitation of only one database per AG makes management cumbersome. So what other options exist? 

Dbvisit Standby MultiPlatform Combined With Azure Site Recovery 

A smarter way to manage DR on ASR is with Dbvisit's Standby MultiPlatform (StandbyMP) DR solution. StandbyMP leverages native database capabilities of the underlying database platform, to ensure data consistency on the standby environment. Database logs are transferred to the secondary system and automatically applied to the standby database.

Data Consistency = Good 

• Dbvisit Standby leverages native database capabilities of the underlying database platform, to ensure data consistency on the standby environment. Database logs are transferred to the secondary system and automatically applied to the standby database.

RPO/RTO Performance = Good 

• RPO and RTO timeframes are good, as the database replication and failover are leveraging underlying components of the database platforms.

• RTO: 5 minutes.

• RPO: < 5 minutes. Minimal data loss due to the asynchronous nature of the data replication.

DR Testing = Good 

• Dbvisit StandbyMP provides zero data loss planned switchovers for standalone environment tests and patching. You can also plug in your own scripts to verify database and environment states. 

Oracle Databases on Azure 

For Oracle on Azure, there are a number of solutions and options available to provide robust database DR capabilities, such as Oracle Data Guard and Dbvisit StandbyMP. Microsoft has reference architecture documents for database deployments. For companies wanting to deploy Oracle within Azure, the following Microsoft article is well worth the read.

Azure provides many options for a warm standby environment when using Oracle Enterprise Edition; Data Guard, Goldengate, etc.  However, for Standard Edition customers Microsoft recommends using products such as Dbvisit StandbyMP, which delivers similar functionality to Data Guard for Standard Edition.

Our Recommendation: ASR + Database DR Solution

While ASR is a great option for companies leveraging Azure, we do not recommend it be implemented for database environments due to the associated risks:

• Caveats in the recovery process: when it comes to ensuring data consistency, databases live-or-die based on data consistency. A database that cannot be guaranteed recovery is an extremely risky bet to make.

• Performance impact during the Snapshot process: particularly during the application consistent snapshot could have negative impacts on production environments.

• Poorer RPO/RTO performance: when compared to specialized database DR.

• I/O throughput limits for high transaction workloads: particularly OLTP database systems.

For companies running business critical databases, an ideal approach would be to leverage ASR for non-database workloads (e.g. application servers, active directory, etc) and implement a database-specific DR solution like Dbvisit StandbyMP or AGs to ensure that the database environments are fully protected.

In summary, StandbyMP provides native database DR capabilities for companies that are running SQL Server Standard and Enterprise Edition, Oracle Standard Edition or PostgreSQL. In addition to managing the database replication and failover, Dbvisit provides zero-data-loss planned switchovers for patching, testing and migrations.

What's Next?

• Check out the StandbyMP and AGs comparison table

• Test Drive StandbyMP in a cloud environment - it only takes two minutes to get started!

If you have any questions or would like to discuss how Dbvisit StandbyMP could fit within your organizational needs, contact us, and one of our technical specialists will reach out to you.