Backup overview

Create a backup of your DB2® database and related stored data to prevent data loss in the event of a database service outage. There are several tools that you can use to complete the backup process.

db2 backup db sample

In IBM® Data Studio Version 3.1 or later, you can use the task assistant for backing up databases. Task assistants can guide you through the process of setting options, reviewing the automatically generated commands to perform the task, and running these commands. For more details, see Administering databases with task assistants.

The recovery history file is updated automatically with summary information whenever you invoke a database backup operation. This file is created in the same directory as the database configuration file.

If you want to delete old backup images that are no longer required, you can remove the files if the backups are stored as files. If you subsequently run a LIST HISTORY command with the BACKUP option, information about the deleted backup images will also be returned. You must use the PRUNE command to remove those entries from the recovery history file.

If your recovery objects were saved using Tivoli Storage Manager (TSM), you can use the db2adutl utility to query, extract, verify, and delete the recovery objects. On Linux and UNIX, this utility is located in the sqllib/adsm directory, and on Windows operating systems, it is located in sqllib\bin. For snapshots, use the db2acsutil utility located in sqllib/bin.

DB_alias.Type.Inst_name.DBPARTnnn.timestamp.Seq_num

STAFF.0.DB201.DBPART000.19950922120112.001

Database alias

A 1- to 8-character database alias name that was specified when the backup utility was invoked.

Type

Type of backup operation, where: 0 represents a full database-level backup, 3 represents a table space-level backup, and 4 represents a backup image generated by the LOAD COPY TO command.

Instance name

A 1- to 8-character name of the current instance that is taken from the DB2INSTANCE environment variable.

Database partition number

In single partition database environments, this is always DBPART000. In partitioned database environments, it is DBPARTxxx, where xxx is the number assigned to the database partition in the db2nodes.cfg file.

Time stamp

A 14-character representation of the date and time at which the backup operation was performed. The time stamp is in the form yyyymmddhhnnss, where:

• yyyy represents the year (1995 to 9999)
• mm represents the month (01 to 12)
• dd represents the day of the month (01 to 31)
• hh represents the hour (00 to 23)
• nn represents the minutes (00 to 59)
• ss represents the seconds (00 to 59)

Sequence number

A 3-digit number used as a file extension.

When a backup image is written to tape:

• File names are not created, but the information described previously is stored in the backup header for verification purposes.
• A tape device must be available through the standard operating system interface. In a large partitioned database environment, however, it might not be practical to have a tape device dedicated to each database partition server. You can connect the tape devices to one or more TSM servers, so that access to these tape devices is provided to each database partition server.
• In a partitioned database environment, you can also use products that provide virtual tape device functions, such as REELlibrarian 4.2 or CLIO/S. You can use these products to access the tape device connected to other nodes (database partition servers) through a pseudo tape device. Access to the remote tape device is provided transparently, and the pseudo tape device can be accessed through the standard operating system interface.

You cannot back up a database that is not in a normal or backup-pending state. A table space that is in a normal or backup-pending state can be backed up. If the table space is not in a normal or backup-pending state, a backup may or may not be permitted.

Concurrent backup operations on the same table space are not permitted. Once a backup operation has been initiated on a table space, any subsequent attempts will fail (SQL2048N).

If a database or a table space is in a partially restored state because a system crash occurred during the restore operation, you must successfully restore the database or the table space before you can back it up.

A backup operation will fail if a list of the table spaces to be backed up contains the name of a temporary table space.

The backup utility provides concurrency control for multiple processes that are making backup copies of different databases. This concurrency control keeps the backup target devices open until all the backup operations have ended. If an error occurs during a backup operation, and an open container cannot be closed, other backup operations targeting the same drive might receive access errors. To correct such access errors, you must terminate the backup operation that caused the error and disconnect from the target device. If you are using the backup utility for concurrent backup operations to tape, ensure that the processes do not target the same tape.