Backups and Recovery for ADB

Backups are one of the areas where Autonomous Database delivers most clearly on its promise, because it backs itself up automatically and recovery is a managed operation rather than a manual restore project. For teams used to configuring backup jobs, managing backup storage and rehearsing restore procedures by hand, this is a significant relief. But automatic does not mean you can ignore it, because you still need to understand what the backups protect against, how long they are retained, what recovery points you can reach, and crucially how backups relate to disaster recovery, which is a different concern. This guide explains how backups and recovery work on Autonomous Database and what you still need to think about.

How automatic backups work

Autonomous Database takes automatic backups continuously, without you configuring backup jobs or managing backup storage, and retains them for a default period that lets you recover the database to a point in time within that window. The backups are managed by the platform, stored durably, and used to support point in time recovery, which means you can restore the database to a specific moment rather than only to the time of the last full backup. This continuous protection covers the most common recovery need, which is returning the database to a known good state after a logical error such as a bad data change or an accidental deletion.

Because the backups are automatic and the storage is managed, the operational burden that backups used to carry largely disappears. There is no backup window to schedule, no backup storage to size and monitor, and no backup job to fix when it fails. What remains is understanding the protection you have and confirming it matches what the workload requires, which is a planning task rather than an operational one.

Recovery as a managed operation

Recovery on Autonomous Database is performed through the platform rather than by manually restoring backup files, which makes it faster and far less error prone than traditional recovery. You select the point in time you want to recover to, within the retention window, and the platform restores the database to that state. This managed recovery handles the kind of incident that backups exist for, a logical error that has corrupted or deleted data, by rolling the database back to before the error occurred. The simplicity of the operation is a genuine advantage, because traditional recovery is exactly the kind of high pressure manual task where mistakes happen.

It is important to be clear about what recovery from backup addresses and what it does not. Backup recovery protects against logical errors and data loss within the retention window, returning the database to an earlier state. It is not the same as disaster recovery, which protects against the loss of an entire availability domain or region, and conflating the two is a common and dangerous mistake. Backups and disaster recovery are complementary, and a complete protection design needs both.

Backups versus disaster recovery

The distinction in this table is the most important point in the whole topic. Backups bring the database back to an earlier good state after something went wrong with the data, while disaster recovery keeps the database available when an entire location is lost. A workload that needs to survive the loss of a region needs Autonomous Data Guard in addition to backups, not instead of them, and assuming that automatic backups provide disaster recovery is a gap that only becomes visible at the worst possible moment. The disaster recovery side is covered in our ADB Data Guard and DR guide and in the wider disaster recovery solution.

Retention and recovery points

The retention period determines how far back you can recover, and understanding it is part of confirming that the backup protection fits the workload. The default retention covers the most common recovery needs, but some workloads have requirements, often regulatory, to retain the ability to recover to points further in the past, and those requirements need to be checked against what the platform provides and addressed where there is a gap. The recovery point you can reach is bounded by the retention window, so a requirement to recover to a moment older than the window is a requirement the default protection does not meet on its own.

The practical task is to map the workload recovery requirements, how far back you might need to go and how recent a recovery point you need, against the retention and recovery characteristics of the platform, and to address any gap deliberately. For most workloads the defaults are sufficient, but the only way to know is to check rather than assume, and the check is a planning exercise worth doing before production rather than after an incident reveals a shortfall.

Testing recovery

The discipline that automation does not remove is testing recovery, because a recovery capability that has never been exercised should not be assumed to work, and the same principle applies to backups on Autonomous Database as to any other platform. Managed recovery is far more reliable than manual recovery, but testing it confirms that the process works as expected, that the recovery time is within what the business can tolerate, and that the people who would perform a recovery under pressure know how to do it. A recovery tested in calm conditions is a recovery you can trust in an incident, and an untested one is a hope rather than a plan.

Testing recovery also validates the recovery point and recovery time against the business requirements in a concrete way rather than a theoretical one. Knowing that you can recover to a point within minutes is different from having measured it, and the measurement is what lets you tell the business honestly what protection it actually has. This kind of regular validation is part of the day two discipline that our managed services provide, turning automatic backups into a recovery capability that has been proven rather than merely configured.

A backup and recovery framework

Bringing it together

Backups and recovery on Autonomous Database remove most of the traditional burden, with continuous automatic backups and managed point in time recovery that handle the logical errors and data loss that backups exist for. What remains is understanding the protection rather than configuring it, confirming retention fits the workload, keeping the clear distinction between backups and disaster recovery, and testing recovery so it is proven rather than assumed. Backups protect the data within a window, disaster recovery protects against losing a location, and a complete design needs both. The companion guides on Data Guard and DR and security features complete the protection picture, and the pillar guide to Autonomous Database on OCI sets it in context. When you want the protection designed, tested and run properly, our disaster recovery solution and managed services cover it.