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.
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 different recovery scenarios.
One scenario covered the loss of a data file, another covered the loss of an entire database and so on. The DBA had to identify which scenario applied to the recovery effort at hand and implement the appropriate steps.
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.
Not an RMAN for all seasons
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.
Maybe those requirements aren't applicable to your environment. If RMAN satisfies all of your recovery requirements, go ahead and use it by itself. But you won't know if RMAN does satisfy your needs until you have a full understanding of the scenarios under which you may need to recover data.
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.
Cover all your database recovery bases
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.
The DBA is the data guardian in an organization, and the most important role of the DBA isn't doing backups. Rather, it's being able to restore data. If a company loses data and can't get it back, the DBA who's responsible for the affected database may need to look for a new job.
Companies are counting on DBAs for data protection. To provide that, it's vital for DBAs to know exactly how they need to recover data. Only then should they think about backups.
Which other backup vendors support RMAN integration?
How to use RMAN for cold backups
Read an Oracle RMAN case study