DB2 backups
You can make a backup of an entire database or just certain tablespaces. Doing so creates a copy of the database or tablespace on separate media, such as tape or another server. Backups can be made while the database is active or inactive, depending on the type of recovery logs you use.
NOTE: When making a backup of a geodatabase in DB2 for z/OS, you must backup all databases in the database subsystem that comprise the geodatabase. At a minimum, this will be two databases: the one that stores the ArcSDE geodatabase repository and one that stores user-defined data.
- Online backup
Performing a backup of your DB2 database while the database instance is running is called an online backup. If you plan to make an online backup, you must use archive logs. To do this, you must enable the Roll-forward recovery option. After you have enabled the database for Roll-forward recovery, you must restart the database. You must also create at least one full offline backup (see the next section) after Roll-forward is enabled but before you perform an online backup.
Since the database is running, users can be connected to the database while the backup operation is being performed. Any changes made to the database during the backup operation are recorded in the logs.
If you are using an ArcSDE service, you do not need to shut down the ArcSDE server process (giomgr) prior to making an online backup.
For details on online backups, refer to the documentation for your DB2 release.
- Offline backup
Making a backup of a DB2 database while the database instance is shut down is an offline backup. Managing an offline backup is simpler than an online backup and less prone to error because with no users connected to the database, no changes can be made while the backup is taking place.
Before you take the database offline, you need to stop your ArcSDE service and any other service that accesses your database.
If you use circular logging (your database is nonrecoverable), an offline backup is your only option. You can use an offline or online backup if you use archive logging.
You should make regular full backups of the DB2 database. A full backup should include the DB2 database and, if you have started an ArcSDE service, the giomgr.defs, dbinit.sde, and services.sde files.
- Incremental backups
As the size of the database grows, the amount of time it takes to complete a full database backup operation increases. To reduce the number of times you have to perform a full database backup, you can create one full backup image and several incremental backups. An incremental backup only contains pages that have been updated since the previous backup image was made plus all the metadata of the initial database.
DB2 uses two types of incremental backup images: cumulative and delta.
A cumulative backup image is a copy of all database data that has changed since the most recent, successful, full backup operation. A cumulative backup image contains a series of incremental backups taken over a period of time; therefore, the previous incremental backup image is contained in it.
A delta backup image is a copy of all database data that has changed since the last successful backup of any kind—full, cumulative, or delta. A delta backup image is also known as a differential, or noncumulative, backup image.
The BACKUP DATABASE command is used to create a backup image. It only affects the database partition on which it is executed. To execute BACKUP DATABASE, you must have either sysadm, sysctr, or sysmaint authorization in the database.
When you use the BACKUP DATABASE command, you can specify to which directory the backup image is saved. This is the target location. Possible target locations include directories, devices, or other servers. If you do not specify a target location in the command, the backup image is saved in the directory from which the command is issued.
The database for which the backup operation is to be performed can be local or on a remote server. The backup image is saved on the database's server unless you are using a third-party storage management application.
When the BACKUP DATABASE command begins executing, a connection to the database is made that is specifically for the backup operation. If you are already connected to the database, that connection is dropped before the backup operation connection is created. Once the backup is completed, the backup operation connection is disconnected.
If the backup operation is successful, you receive a message to that effect that includes a timestamp for the backup image. This timestamp uniquely identifies each backup image.
To back up your ArcSDE DB2 database, you must copy the following files to an offline location:
- Data files
- giomgr.defs, dbinit.sde, and services.sde files
- Archive recovery log files
The database recovery log files are important for bringing the data files from an earlier state to a later state. Between any two points in time, if you want to use the recommended Roll-forward recovery option, the recovery logs must be found in an unbroken sequence for database recovery to succeed.
ESRI recommends that you maintain at least two copies of all archive recovery logs for as far back in time as may be reasonably necessary for database recovery. The two copies should be stored on physically distinct media-separate disk drives, for example, or a disk drive and a tape drive. You could use log mirroring to maintain separate copies of the recovery logs.
If you intend to purge the archive recovery log files from their location on disk, be sure that you have a second backup copy of each archive recovery log file before purging.
This strategy of multiple backups of the archive recovery log files helps guard against multiple media failure, which is not as rare as it might seem. Some tape drives, for example, fail to detect bit errors until you attempt to restore a file, when it may be too late.
You only need to make a single copy of each data file with each backup as long as you carefully maintain multiple copies of archive recovery logs.
You can use the Configure Automatic Maintenance wizard in the DB2 Control Center to set the type of maintenance performed, such as backups, and when to run them. Using the wizard, specify your maintenance goals and at what times maintenance can occur. DB2 uses this information to determine if and when maintenance activities are required and runs them during the next time period in which maintenance is allowed.
In addition to setting the type of maintenance and times, you can set up notification e-mail to send error or trouble messages to recipients you specify.
NOTE: You can perform manual backup operations even when your database is configured to use automatic maintenance.
You can also use the Backup wizard in the DB2 Control Center to create backups of database objects, partitions, or the entire database.
It is important that you read the backup and recovery documentation available for DB2. The documentation is as follows:
Data Recovery and High Availability Guide and Reference
DB2 LUW V 9 Information Center
DB2 z/OS Information Center
