Backup files

Backup files contain a copy of the database or table spaces that can be used to recover the database.

The following are general guidelines for planning what types of backup files you might need:

Databases that contain read-only data do not need to be protected through archive logging if full, offline backups are run following each new data load activity. For most customers, the table spaces that contain application group data is probably read only.
With continuously updated data that is deemed important to your business, you must use archive logging. If you use the audit feature of Content Manager OnDemand to update documents throughout the day, then you probably need to use archive logging.
If your database must be continuously available, you must take online backups. This requires the use of archive logs.
If in the event of a failure your database must be recovered in a short time, you will need to run more frequent backups. In this case, you need to establish how long it would take to recover from a failure (the sum of the time to restore the database from a backup plus the time needed to roll the log forward).
Note: Storing application group data in table spaces may reduce the time required to recover from a failure of a single device.
Consideration should also be given to keeping the database on disk arrays or mirrored volumes.

Probably the most common type of failure is caused by media problems. This is not limited to disk problems, but can extend to other I/O devices, including disk controllers and tape devices. As a starting point, do not back up your database to the same disk on which the production version exists: use either a separate disk or external media. The handling of your logs should be similar: consider directing these to a separate physical disk from that of the database. In addition to protecting against a disk failure affecting both, this may also result in performance improvements.

Though unlikely, it is possible that your backup media could suffer a problem just when it is needed to let you recover from a disk failure. Consider the impact of a tape going bad. If your data is absolutely critical, you should consider having duplicate tape media. Another strategy is to minimize the potential for impact caused by a bad disk. This applies to the disks that both the database and logs reside upon. Using disk arrays for your database volumes or logs (or both) is perhaps the best defense against disk media failures. If you extend redundancy to disk controllers as well, it is highly unlikely that your database will ever be unavailable or that logs will be lost due to a media failure.