• Hardware failure. While RAID disk configurations can protect you against drive failures, these are of no use in the event of a system failure (caused by a power spike, etc.).
  
  
• User and software problems. While hardware failures are rare, human error is not. More than once, a DBA, power user or developer has mistakenly run a piece of code in production that corrupted data beyond the ability to programmatically recover. Viruses can remove or corrupt files, or a software upgrade can introduce a mission critical bug that requires you to revert back to the original version.
  
  
• Natural disasters such as flood or fire. Most hardware vendors have guaranteed response times to get your server and network running within a certain period of time, but nobody can recover your data if it wasn't backed up properly.
  
  

Planning and testing backup procedures are key to full media recovery. Oracle provides three different ways to backup your database:

• The first and easiest method of backing up an Oracle database is a cold backup. In order to perform a cold backup the database must be shut down, making it unavailable to your users for a short period of time while the files are copied.
  
  
• The second backup method is to perform a database export. The export utility that Oracle provides allows you to export the entire database, a specific schema or individual database tables. Exports can be done while the database is up and running.
  
  
• The third method is a hot backup, which also allows the database to remain up throughout the backup process. Be aware that in order to perform a hot backup the database must be running in archive log mode. This is normally specified upon database creation but can be changed after database creation. By placing the database in archive log mode, Oracle is able to maintain a history of each and every change to the database by writing log files. All log files should be backed up as well as database files in order to perform complete recovery.
  

Many shops use more than one of the above options. Because you can pick and choose which items to recover from an export, exports are useful to have if the problem affects only one table or application (such as when someone accidentally drops a single database table).

Once a backup method is determined and implemented, it can be scheduled to run without any human intervention, but the backup process should be reviewed daily via log files generated from the backup. This can be done manually, or you can instruct the program initiating the backup to email or page someone in the event of a failure. If you are backing up your files to disk, make sure to copy those files to tape in the event of a hardware failure. Ideally, the tapes would be stored at a separate site from the server, in the event of a fire or similar disaster. A reasonable practice is to make a nightly backup, and once a week send the tape off-site.

The final piece of the backup and recovery process is testing. It doesn't take much to imagine the feeling of learning, in the middle of a recovery, that the backup process was not writing all of the backup files to tape.