Defining a robust backup strategy for your database requires careful consideration of your business requirements, including factors such as the requirements for database availability and the maximum time the database can be down for backups. The Backup Database SmartGuide, described in "Step 5. Backing Up a Database for the First Time", helps you with the decision-making. This section describes the considerations and issues in more detail, in order to provide you with a better understanding of this important area.
To begin, you must decide on the types of failure that you are protecting against. The purpose of running a backup is to be able to use it to perform a recovery. Therefore, you must test your processes and procedures to ensure that your backups will be useful in the event of a failure. Backups that cannot be used to restore data are pointless.
The following are general guidelines for planning a recovery strategy:
Beyond transaction failures and system crashes, both of which DB2 will recover from, you should consider application errors. This refers to the general case of data being damaged in some manner. Clearly there is no way to prevent an authorized user from altering data inappropriately. The best strategy for dealing with this type of problem is to ensure that you have archive logs to roll forward the database to the point just prior to the corruption of the data. Be sure to factor into your schedule the maximum time the database can be down for backups, and whether these are online or off-line.
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, it is suggested that you 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. See the Administration Guide for information on disk arrays. 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.