Managing backups and clones with the DEVICE_CLASS parameter

Edit online

Use the DEVICE_CLASS parameter in the CLIENT section of the IBM® Storage Protect Snapshot profile file to select the storage device configuration for backups. In the CLONING section of the profile file, use this parameter to select the storage device configurations for cloning.

The IBM Storage Protect Snapshot DEVICE_CLASS profile parameter can be used as a filter to determine these backup criteria:

  • Partition number
  • Day of week
  • Time of backup
  • Cloning only: Clone database name

When used in this manner, the DEVICE_CLASS parameter provides access to a specific storage device. This device is identified by the copy services type, user name, and storage server name that is defined by the corresponding DEVICE_CLASS profile section. It also provides a backup policy that is device-specific. For example, this device-specific backup policy might be defined by these factors:

  • List of target sets on DS8000®, SAN Volume Controller, or Storwize® family
  • The type of snapshot backup to be completed (for example, incremental or copy)
  • The mount location of the backup
  • Whether a snapshot backup should be offloaded to an IBM Storage Protect server.

The DEVICE_CLASS parameter is specified in the client section of IBM Storage Protect Snapshot profile file. The settings for this parameter can be overridden with a command-line option during backup operations. Use the following command-line option:

From the Oracle in an SAP environment interface
-S device class in SAP BR*Tools configuration profile (.sap) util_options parameter.
From the Oracle environment
-s device class on the acsora -f backup command.

The DEVICE_CLASS parameter cannot be specified with the restore, mount, unmount, and delete commands. You can specify the backup ID, if it is not specified the latest backup is used. IBM Storage Protect Snapshot automatically uses the DEVICE_CLASS that was used for the selected backup at backup time.

Examples of how to use DEVICE_CLASS filters

This example creates alternating backups to each mirror. Device classes MIRROR_1 and MIRROR_2 refer to two separate storage clusters. Only those backups that are created to MIRROR_2 are offloaded to the IBM Storage Protect server:
>>> CLIENT 
TSM_BACKUP LATEST USE_FOR MIRROR_2
DEVICE_CLASS MIRROR_1 MIRROR_2
[...]
<<<
This example creates backups to MIRROR_1 on Monday (1), Wednesday (3), and Friday (5). It creates backups to MIRROR_2 on Sunday (0), Tuesday (2), and Thursday (4), and Saturday (6). All backups are stored on the IBM Storage Protect server:
 >>> CLIENT
TSM_BACKUP LATEST
DEVICE_CLASS MIRROR_1 USE_AT Mon Wed Fri
DEVICE_CLASS MIRROR_2 USE_AT Sun Tue Thu Sat
[...]
<<<
This example creates disk only backups during the specified period of the day. These disk only backups are considered space-efficient. A full backup is also created at midnight that is stored on the IBM Storage Protect server. Although the DAYTIME and MIDNIGHT device classes might have the same configuration, two different device classes are used. This setting is used even if both device classes point to the same SAN Volume Controller cluster:
 >>> CLIENT
TSM_BACKUP LATEST USE_FOR MIDNIGHT
DEVICE_CLASS DAYTIME FROM 1:00 TO 23:59
DEVICE_CLASS MIDNIGHT FROM 0:00 TO 0:59
[...]
<<<
>>> DEVICE_CLASS DAYTIME
COPYSERVICES_HARDWARE_TYPE SVC
FLASHCOPY_TYPE NOCOPY
[...]
<<<
>>> DEVICE_CLASS MIDNIGHT
COPYSERVICES_HARDWARE_TYPE SVC
FLASHCOPY_TYPE INCR
SVC_COPY_RATE 80
[...]
<<<
Note: The time period that is specified cannot span midnight for a device class. If a device class time period is required to span midnight, you must specify two time periods for the device class. The first time period must end with a value 1 minute before midnight and the second time period must start at midnight. The following example shows how to specify a time period that spans midnight for a device class:
DEVICE_CLASS myClass FROM 20:00 TO 23:59
DEVICE_CLASS myClass FROM 00:00 TO 06:00

This example demonstrates how to create clone databases on different clone servers from the same production database. In this scenario, there are two clone servers, each one uses a different device class. The clone server host1 uses DEVICE_CLASS CLONE1 and host2 uses DEVICE_CLASS CLONE2. When a clone request is started with clone database B01 selected, this clone is created with DEVICE_CLASS CLONE1 and it is created on clone server host1.

>>> CLONING
DEVICE_CLASS CLONE1 USE_FOR_CLONING B01 C01
DEVICE_CLASS CLONE2 USE_FOR_CLONING B02 C02
<<< 
>>> DEVICE_CLASS CLONE1
CLONE_DATABASE YES
...
<<< 
>>> DEVICE_CLASS CLONE2
CLONE_DATABASE YES
...
<<<