ADB Data Guard and DR

Disaster recovery is the part of a database design that nobody thinks about until they need it, and by then it is too late to add. On Autonomous Database, disaster recovery is delivered through Autonomous Data Guard, which maintains a standby copy of the database that can take over if the primary is lost. This is a powerful and largely managed capability, but it is not automatic in the sense of being there without a decision, and it is frequently confused with backups, which protect against a different kind of failure entirely. This guide explains how Autonomous Data Guard works, the choices it presents, and how to think about disaster recovery as distinct from backups.

What disaster recovery protects against

Disaster recovery exists to keep a database available when something large fails, the loss of an availability domain or, in the more serious case, the loss of an entire region. These are rare events, but they are exactly the events that take an unprepared workload offline for an extended and uncontrolled period, and the purpose of disaster recovery is to convert that uncontrolled outage into a controlled failover to a standby that is ready to take over. The distinction from everyday failures is important, because the platform already handles small failures transparently, and disaster recovery is about the large ones.

Because disaster recovery is about surviving the loss of a location, it requires a copy of the database in a different location, which is the standby that Autonomous Data Guard maintains. This is fundamentally different from a backup, which is a copy in time rather than in place, and conflating the two is the most common and most dangerous misunderstanding in this area. A workload protected by backups alone is not protected against losing a region, no matter how good the backups are.

How Autonomous Data Guard works

Autonomous Data Guard maintains a standby database that is kept in sync with the primary, so that if the primary becomes unavailable the standby can take over with minimal data loss and a short recovery time. The synchronisation is managed by the platform, which removes the configuration and operational burden that traditional standby databases carried, and the failover is likewise a managed operation rather than a manual rebuild. This makes a capability that used to be complex and expensive to operate available as a feature you enable.

The standby can be placed locally, within the same region but a different availability domain, or across regions in an entirely separate region, and the choice determines what the disaster recovery protects against. A local standby protects against the loss of an availability domain, which covers a significant class of failures, while a cross region standby protects against the loss of the whole region, which is the more complete but also more involved option. Choosing between them is the central disaster recovery decision on Autonomous Database.

Local versus cross region standby

The right choice depends on what the workload must survive and what the business requires, and this should be a deliberate decision driven by the consequences of an outage rather than a default. A workload whose loss for the duration of a regional event is unacceptable needs a cross region standby, while one for which domain level protection is sufficient can use a local standby at lower complexity. The decision also touches data residency, because a cross region standby places a copy of the data in another region, which may have regulatory implications worth checking. Our disaster recovery solution helps make this decision against the real business requirements.

Recovery objectives

Disaster recovery is measured by two objectives, how much data you can afford to lose, expressed as the recovery point objective, and how quickly you need to be running again, expressed as the recovery time objective. These objectives are business decisions, not technical ones, because they express how much disruption the organisation can tolerate, and the disaster recovery design exists to meet them. Autonomous Data Guard is built to provide a short recovery time and minimal data loss, but the only way to know whether it meets your specific objectives is to state those objectives explicitly and check the design against them.

Stating the objectives clearly also prevents a common failure, which is assuming a level of protection that the configuration does not actually provide. A workload that needs near zero data loss and rapid recovery needs a design built and tested for that, and a workload with more relaxed objectives can use a simpler design, but in both cases the objectives must be written down and the design verified against them. The objectives are the contract between the business and the technical design, and they should be explicit.

Failover and the discipline of testing

A standby that has never been failed over to is a standby you hope works rather than one you know works, and the discipline that disaster recovery requires above all is testing the failover. Autonomous Data Guard makes failover a managed operation, which is a large improvement over manual disaster recovery, but the managed operation still needs to be exercised so that the recovery time is measured rather than assumed, the people who would invoke it under pressure know how, and any application side dependencies on the failover are understood. A disaster recovery plan that has been tested is a capability, and one that has not is a document.

Testing also reveals the application side of failover, which is often where the real work lies, because the database failing over cleanly does not help if the applications cannot follow it to the standby. The connection configuration, the network paths and the application behaviour all need to handle the failover, and only a test exercises them together. This end to end validation is part of the day two discipline our managed services provide, turning a configured standby into a proven recovery capability.

A disaster recovery framework

Bringing it together

Disaster recovery on Autonomous Database, delivered through Autonomous Data Guard, makes a once complex capability available as a managed feature, with local and cross region standbys that protect against domain and region loss respectively. The discipline that makes it real is clarity about objectives, a deliberate choice of standby scope, a firm distinction between disaster recovery and backups, attention to data residency, and above all testing the failover end to end. The companion guide on backups and recovery covers the complementary protection, and the pillar guide to Autonomous Database on OCI sets it in context. When you want disaster recovery designed against real business objectives, built and tested properly, our disaster recovery solution and managed services cover it.