If you have a second datacentre, and use PPRC (or equivalent) for remote replication of data, then you still need to take image copies. That's obvious to Storage Manager, but it is surprising how many non-storage people think that replication does away with the need for backups. Apart from the obvious need to recover from individual database corruption, there is also a requirement to handle a rolling disaster. This happens when disks when disks do not all fail at once, so some updates fail, while others succeed. If this causes databases to become corrupt, then full recovery may be needed. PPRC and SDRF mirroring both support consistency groups, which safeguards against rolling disasters. See the article Remote Data Mirroring for details on PPRC and also GDPS, the product which helps prevent rolling disasters.
Image copies are invoked using the DB2 COPY command. COPY can create up to five image copies: two sequential image copies for the local site, two sequential image copies for the recovery site, and one FlashCopy image copy. There are two kinds of image copies, FULL and INCREMENTAL. You can make full image copies of a variety of different DB2 objects, including table spaces, table space partitions, data sets of non partitioned table spaces, index spaces, and index space partitions. A typical DB2 copy statement to backup a single tablespace is simply:
COPY TABLESPACE database.tablespace
The COPY statement will write the backup to a single output dataset, no matter how many objects are copied in that run.
An incremental image copy is a copy of the pages that have been changed since the last full or incremental image copy. A typical COPY statement to backup a single tablespace looks like:
COPY TABLESPACE database.tablespace FULL NO SHRLEVEL CHANGE
FlashCopy is an IBM product used by DSxxxx storage subsystems. All other mainframe storage disk providers have a Flashcopy equivalent that supports the Flashcopy command set. The product is described in detail in the FlashCopy section, but in brief it creates an 'instant copy' of a disk or dataset.
DB2 v10 can control the creation of image copies using the dataset level Flashcopy facility. Image copies are allocated by DFDSS as VSAM datasets and are always catalogued. A dataset is created for each partition or object that is backed up and some utilities can also create sequential image copies using an existing Flashcopy image as input. For FlashCopy image copies, if the object consists of multiple data sets and all are copied in one run, there is a FlashCopy image copy data set for each data set. FlashCopy image copies are registered in SYSIBM.SYSCOPY as any other image copy. Because FlashCopy image copy does not support incremental copies, do not consider FlashCopy image copy as a replacement for incremental image copies.
If you run the image copy with options SHRLEVEL CHANGE and FLASHCOPY CONSISTENT, then once the FlashCopy image copy is created the utility checks the logs for changes to the copied data that were uncommitted at the time that the image copy was created. Any uncommitted data that is identified in the logs is backed out of the image copy before the utility terminates.
For this reason, a FLASHCOPY CONSISTENT image copy uses more system resources and takes longer than a simple FLASHCOPY YES image copy.
Dataset level Flashcopies don't always work as expected so it is worth knowing the restrictions before your DBA comes round asking questions. The types of things that can cause problems are
No Flashcopy V2 disks available
The source dataset must not be a target in an existing Flashcopy relationship
The target dataset must not be a source in an existing Flashcopy relationship
The source dataset can exist in multiple Flashcopy relationships, but no more than 12
Target dataset attributes like CISIZE, CASIZE, physical record size and physical blocksize must match the source dataset, except that the CASIZE can be different if the source dataset is less than one cylinder
Both source and target dataset must be fully contained on the same physical control unit
Both datasets must be SMS managed
If any of these parameters are not met, then the image copy will run, but it will not use Flashcopy and so will take longer than maybe was expected.
DB2 used to support two copy pools for backups, one for the database and one for logs. DB2 12 system level backups support multiple copy pools in which you can keep extra system level backups on disk during upgrades.
The Backing up DB2 on AIX with TSM page in the Spectrum Protect or TSM section describes how to backup DB2 LUW databases using IBM's Spectrum Protect, formerly called TSM.
IBM's General Parallel File System (GPFS) is a high-performance clustered file system that runs on AIX, Linux and Windows Server clusters. One of its many features is the ability to take snapshots of file systems and interface those snapshots to TSM for backups. DB2 Purescale uses Tivoli Storage FlashCopy Manager to create a second DB2 pureScale instance in an independent GPFS Backup Cluster, then use this backup cluster to send a snapshot of a DB2 pureScale database to TSM. The Production Cluster hosts the original file system and the production applications, which run apart from the backups and are not affected by them.
To successfully back up and restore a DB2 database in a DB2 pureScale environment, the data and log files must be in separate independent file sets within the same GPFS file system, OR, the data and log files must be in separate GPFS file systems.
The production and backup clusters must have the same number of members, bur you can create logical members on the same host, which reduces the number of hosts that are required for the backup cluster. TSM mounts the GPFS file systems that contain the snapshot backup on the backup cluster. Databases are security protected to prevent misuse, so permissions must be granted to allow the FlashCopy Manager to mount file systems on the backup cluster. The necessary commands are:
On the production cluster run the 'mmauth add' command to authorize the backup cluster to mount all the file systems that the production database is allocated on, then run the 'mmauth grant' command to grant permission to the backup cluster to mount the file systems of the database that are enabled for snapshot-based data protection.
On the backup cluster run the 'mmremotecluster add' command to add the production cluster to the backup cluster.