Copying a database to a new system
You can copy a database to a new system by backing up the database and restoring it to the new system. This is called cross-restoring the database. For example, you might want to copy a database to new hardware when upgrading or during disaster recovery.
When cross-restoring a database, the following restrictions apply:
- You must use either the db2inst1 or root user ID, because only these users are authorized to copy the necessary key certificates.
- The target system must have the same number of multiple logical nodes (MLNs) as the source system.
- You must use an offline backup.
- After you copy a database to a new system, perform an incremental backup of that database only after you have performed at least one full online backup.
To cross restore a database:
- On the source system, create an offline backup image of the database that is to be transferred
to the target system. For example, issue the following
command:
Note the timestamp and target path of the backup image, which are specified in the command output. For example:db_backup -type off -path /mnt/bludata0/scratch/The timestamp for this backup image is : 20191002134239 Backup path(s) :/mnt/bludata0/scratch/backup_off_1 - On the source system, issue to the following command to locate the
keystore:
This will return the keystore type and location, for example:db2 get dbm cfg | grep KEYSTOREKeystore type (KEYSTORE_TYPE) = PKCS12 Keystore location (KEYSTORE_LOCATION) = /mnt/blumeta0/db2/keystore/keystore.p12 - On the source system, change to the keystore directory. For
example:
cd /mnt/blumeta0/db2/keystore/ - On the source system, issue to the following SELECT statement to retrieve information about the
certificate that contains the master
key:
This will return the name of the certificate. For example:db2 "select MASTER_KEY_LABEL from TABLE(SYSPROC.ADMIN_GET_ENCRYPTION_INFO()) where OBJECT_NAME='BLUDB' and OBJECT_TYPE='DATABASE'"DB2_SYSGEN_db2inst1_BLUDB_2018-03-29-17.37.44_313B7CA0 - On the source system, change to the following
directory:
cd /mnt/blumeta0/home/db2inst1/sqllib/gskit/bin - On the source system, export the master-key certificate to a temporary location. Use the
-target_pwparameter to specify a strong password. For example, the following command exports the master-key certificate with the namekeystore.p12and the passwordStr0ngPassw0rd../gsk8capicmd_64 -cert -export -db /mnt/blumeta0db2/keystore/keystore.p12 -stashed -label DB2_SYSGEN_db2inst1_BLUDB_2018-03-29-17.37.44_313B7CA0 -target /mnt/bludata0/scratch/tmpKey.raw -target_type pkcs12 -target_pw "Str0ngPassw0rd"This generates the following 3 certificate files in the target location on the source system:tmpKey.raw tmpKey.crl tmpKey.rdb - Copy the 3 certificate files to the system on which the database is to be restored (that is, to the target system). For example, copy them to a directory with the name /temp.
- Copy the offline backup image that you created in Step 1 to the target system into the directory /mnt/bludata0/scratch/.
- On the target system, change to the following
directory:
cd /mnt/blumeta0/home/db2inst1/sqllib/gskit/bin - On the target system, import the master-key certificate. Specify the password that was specified
when the certificate was exported. For example, the following command imports the certificate using
the 3 certificate files located in the /temp
directory:
./gsk8capicmd_64 -cert -import -db /temp/tmpKey.raw -pw "Str0ngPassw0rd" -stashed -target /mnt/blumeta0/db2/keystore/keystore.p12 -target_type pkcs12 - On the target system, issue the following command to list all certificates and to verify that
the master-key certificate was successfully
imported:
./gsk8capicmd_64 -cert -list all -db /mnt/blumeta0/db2/keystore/keystore.p12 -type pkcs12 -stashed - On the target system, restore the backed-up database. For
example:
db_restore -type frc -timestamp 20191102134239 -path /mnt/bludata0/scratch/backup_off_1/ - On the target system, connect to the database. For
example:
db2 connect to bludb