Achieving data consistency with AWS Elastic Disaster Recovery

When designing a disaster recovery (DR) plan, data consistency is an important factor to consider. This is especially important when protecting certain database applications, such as Microsoft SQL, Oracle, and SAP Hana. These database workloads must be restored to a consistent state to avoid database corruption. Failing to do so could result in loss of data and an increased time to recovery.

AWS Elastic Disaster Recovery (DRS) is the recommended service for disaster recovery to AWS. Operated from the AWS Management Console, AWS Elastic Disaster Recovery helps you recover all of your applications and databases that run on supported Windows and Linux operating system versions. They will then run natively within Amazon Elastic Compute Cloud (EC2) in the event of a DR event or drill.

In this post, I review what data consistency is, and show how AWS Elastic Disaster Recovery ensures data consistency during both the replication and recovery stages.

What is data consistency?

Data consistency is the ability to recover data, while maintaining its validity, usability, and integrity post recovery.

How does AWS Elastic Disaster Recovery ensure data consistency?

First, it’s important to understand how AWS Elastic Disaster Recovery replicates data into the staging area within the target AWS Region.

Replication is performed at the block level, via an agent that is installed on each source machine that you want to protect. The agent runs in memory and recognizes write operations to locally attached disks. These writes are captured and then asynchronously replicated into a staging area within the customer’s AWS account. During this ongoing replication process, AWS Elastic Disaster Recovery maintains the write order among all disks in the same source server.

AWS Elastic Disaster Recovery uses Amazon Elastic Block Store (EBS) snapshots to take point-in-time snapshots of this data held within the staging area. It then provides crash consistent point-in-time recovery options that can be used in the event of a disaster or DR drill.

It is a common misconception that applications, such as MS SQL, Oracle and SAP Hana, require application consistent recovery points to recover without corruption. The truth is that most modern applications and file systems can recover from a crash-consistent recovery point since they are ACID-compliant. This means, from a database perspective, that once recovered from a crash-consistent snapshot, any non-completed transactions are rolled back so the database comes up in a consistent state.

Some rare use cases may still require application-consistent snapshots, such as the need to capture a specific state of the data. For example, you might need a snapshot of data at exactly midnight each day. Another case is multi-node databases that require all the nodes to be in sync when the backup is taken.

Conclusion

AWS Elastic Disaster Recovery provides organizations with a way to protect database applications, such as MS SQL, Oracle, and SAP Hana. Using AWS Elastic Disaster Recovery helps you to recover those workloads from a disaster with consistent data, avoiding database corruption and helping ensure smooth recovery along with minimal downtime.

Thanks for reading this blog post. If you have any comments or questions, you can add them to the comment section.