Backing up data

Use the BACKUP DATABASE command to take a copy of the database data and store it on a different medium. This backup data can then be used in the case of a failure or damage to the original data. You can back up an entire database, database partition, or only selected table spaces.

Before you begin

You do not need to be connected to the database that is to be backed up: the backup database utility automatically establishes a connection to the specified database, and this connection is terminated at the completion of the backup operation. If you are connected to a database that is to be backed up, you will be disconnected when the BACKUP DATABASE command is issued and the backup operation will proceed.

The database can be local or remote. The backup image remains on the database server, unless you are using a storage management product such as Tivoli® Storage Manager (TSM) or Db2® Advanced Copy Services (ACS).

If you are performing an offline backup and if you have activated the database by using the ACTIVATE DATABASE command, you must deactivate the database before you run the offline backup. If there are active connections to the database, in order to deactivate the database successfully, a user with SYSADM authority must connect to the database, and issue the following commands:

CONNECT TO database-alias
QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS;
UNQUIESCE DATABASE;
TERMINATE;
DEACTIVATE DATABASE database-alias

In a partitioned database environment, you can use the BACKUP DATABASE command to back up database partitions individually, use the ON DBPARTITIONNUM command parameter to back up several of the database partitions at once, or use the ALL DBPARTITIONNUMS parameter to back up all of the database partitions simultaneously. You can use the LIST DBPARTITIONNUMS command to identify the database partitions that have user tables on them that you might want to back up.

Unless you are using a single system view (SSV) backup, if you are performing an offline backup in a partitioned database environment, you should back up the catalog partition separately from all other database partitions. For example, you can back up the catalog partition first, then back up the other database partitions. This action is necessary because the backup operation might require an exclusive database connection on the catalog partition, during which the other database partitions cannot connect. If you are performing an online backup, all database partitions (including the catalog partition) can be backed up simultaneously or in any order.

On a distributed request system, backup operations apply to the distributed request database and the metadata stored in the database catalog (wrappers, servers, nicknames, and so on). Data source objects (tables and views) are not backed up, unless they are stored in the distributed request database

If a database was created with a previous release of the database manager, and the database has not been upgraded, you must upgrade the database before you can back it up.


Restrictions

The following restrictions apply to the backup utility:

  • A table space backup operation and a table space restore operation cannot be run at the same time, even if different table spaces are involved.
  • If you want to be able to do rollforward recovery in a partitioned database environment, you must regularly back up the database on the list of nodes. You must also have at least one backup image of the rest of the nodes in the system (even those nodes that do not contain user data for that database). Two situations require the backed-up image of a database partition at a database partition server that does not contain user data for the database:
    • You added a database partition server to the database system after taking the last backup, and you need to do forward recovery on this database partition server.
    • Point-in-time recovery is used, which requires that all database partitions in the system are in rollforward pending state.
  • Online backup operations for DMS table spaces are incompatible with the following operations:
    • load
    • reorganization (online and offline)
    • drop table space
    • table truncation
    • index creation
    • not logged initially (used with the CREATE TABLE and ALTER TABLE statements)
  • If you attempt to perform an offline backup of a database that is currently active, you will receive an error. Before you run an offline backup, you can make sure that the database is not active by issuing the DEACTIVATE DATABASE command.

Procedure

To invoke the backup utility:

  • Issue the BACKUP DATABASE command in the command line processor (CLP).
  • Run the ADMIN_CMD procedure with the BACKUP DATABASE parameter.
  • Use the db2Backup application programming interface (API).
  • Open the task assistant in IBM® Data Studio for the BACKUP DATABASE command.

Example

Following is an example of the BACKUP DATABASE command issued through the CLP:
db2 backup database sample to c:\DB2Backups

What to do next

If you performed an offline backup, after the backup completes, you must reactivate the database:
ACTIVATE DATABASE sample