A database administrator can’t restore a database if there’s no backup copy, so it’s only logical that DBAs tend to think of backups before recovery. But, to me, that line of reasoning has always been faulty.

Database backups done with tools such as Oracle Recovery Manager, or RMAN, really serve only one purpose: to restore data that was lost due to some failure, and which is otherwise unrecoverable.

Too often, database administrators (DBAs) don’t understand that recovery drives backups, not the other way around. To avoid possible breakdowns in the database recovery management process, DBAs must have a good handle on their recovery requirements prior to implementing a backup strategy and the software to support it.

Oracle Recovery Manager is a solid backup and recovery tool, and I can certainly understand why many Oracle DBAs feel it is the best or preferred technology option. Before RMAN existed, a DBA needed to know the ins and outs of what is now called a user-managed backup. Back then, I had a book sitting on my shelf that provided lots of diferent recovery scenarios.

RMAN automates so much of this for us. It knows what was last backed up and can figure out what to back up next. It also knows which database pieces are missing and can handle restores automatically. RMAN certainly is a great tool to have at our disposal.

Like anything, though, RMAN is not without its faults. It isn’t the perfect tool for every situation. For example, RMAN can’t restore a 20 TB database in under 10 minutes, but hardware-based disk snapshots can. Likewise, RMAN can’t restore a database that runs on one operating system to any other operating system that is Oracle-certified, but Oracle Data Pump can.

The best course of action is to document the recovery requirements first. Skip backups for now — focus initially on recovery and spelling out the relevant scenarios, along with the expected recovery time for each in a service-level agreement (SLA).

The amount of acceptable data loss should be part of the SLA, as well. For example, an SLA may state that a DBA must be able to achieve zero data loss and have a database up and running again within 10 minutes of a complete data center failure. Or it may say that losing up to one day’s worth of data and being down for an entire day is acceptable. Also, document any extra business processes that rely on backups, such as data transmittal or database duplication and cloning.

Once the recovery requirements are nailed down, implement a backup strategy that covers all of them. Sometimes, a single tool like RMAN can handle the backup and recovery needs outlined in an SLA. Other times, DBAs may have to employ more than one method, such as implementing RMAN and Data Pump together.


Backups are a necessary, if tedious, component of storing data. We back up data regularly — daily or even multiple times per day — knowing we can restore it when the inevitable happens. But how often do we restore? When it comes to data backup and restoration, what is the ratio of backup volume to restore volume?

Because data loss is a common concern, it’s likely that organizations transfer hundreds of times more data to backup than they end up restoring. Surely there must be some way to get more business value from this efort. Alternatively, is there a way to reduce the efort to achieve the current business value?

The more frequently you back up, the more granular your restore; however, you also transfer more data and require more space for these additional backups.

Most modern data backup applications do not create full backups every time; they make one full data copy and follow that with incremental backups to minimize the data transferred. The efciency of moving from full copies to incremental has enabled more frequent backups, possibly without regard for the value of these backups. If we understand the business value of the application, we may be able to reduce the frequency of the backups based on the business risk of data loss.

It is also worth identifying which storage characteristics are beneficial for data backup and restoration. Backups are generally sequential and write-intensive. Restores are sequential and read-intensive.
Backup storage is usually optimised for storing a lot of data and for sequential access. Production primary storage is usually smaller and more optimised for random access. If we use backup storage for periodic scanning and sequential access tasks, then we can offload it from the primary storage. The result is better performance of the primary storage.

Over the last few years, a new generation of data backup and restoration products has appeared that uses solid-state, as well as hard disk drives. This hybrid backup storage offers excellent performance for random access to the data in solid-state.

[X id=761

To read full download the whitepaper:
Mastering the art of Database Backup and Recovery