Scenario: Protecting the database and storage pools

To demonstrate how you might protect the database and storage pools, suppose that your company takes steps to protect against the permanent loss of data that is stored in the database and storage pools. You can modify this procedure to meet your needs.

About this task

This scenario assumes a storage hierarchy that consists of the following storage pools:

Default random-access storage pools that are named BACKUPPOOL, ARCHIVEPOOL, and SPACEMGPOOL
A tape storage pool named TAPEPOOL

To provide extra levels of protection for client data, the scenario also specifies an offsite copy storage pool and an onsite active-data pool.

The standard procedures for the company include the following activities:

Weekly reclamation of its copy storage pool. Reclamation for the copy storage pools is turned off at other times.
Note: In a copy storage pool definition, the REUSEDELAY parameter delays volumes from being returned to scratch or being reused. Set the value high enough to ensure that the database can be restored to an earlier point in time and that database references to files in the storage pool are valid. For example, to retain database backups for seven days and, therefore, sets REUSEDELAY to 7.
Nightly back up of its primary storage pools to the copy storage pool. Every night, copy the active client backup data in the primary storage pools to the active-data pool.
A weekly full backup of the database and incremental backups on the other days.
Daily shipment of the database backup volumes and copy storage pool volumes to an offsite location.

Procedure

To protect client data, perform the following actions:

Create a copy storage pool named DISASTER-RECOVERY. Only scratch tapes are used, and the maximum number of scratch volumes is set to 100. The copy storage pool is defined by entering:
```
define stgpool disaster-recovery tapeclass pooltype=copy
maxscratch=100
```
Create an active-data pool named CLIENT-RESTORE and associates it with a sequential-access disk device class (FILE). Only scratch volumes are used, and the maximum number of scratch volumes is set to 50. The active-data pool is defined by entering:
```
define stgpool client-restore diskclass pooltype=activedata
maxscratch=50
```
Perform the first backup of the primary storage pools. The first backup of a primary storage pool is a full backup and, depending on the size of the storage pool, can take a long time.
Define schedules for the following daily operations:
1. Run incremental backups of the primary storage pools each night. Issue the following commands:
```
backup stgpool backuppool disaster-recovery maxprocess=2
copy activedata backuppool client-restore maxprocess=2
backup stgpool archivepool disaster-recovery maxprocess=2
backup stgpool spacemgpool disaster-recovery maxprocess=2
backup stgpool tapepool disaster-recovery maxprocess=2
copy activedata tapepool client-restore maxprocess=2
```
  The BACKUP STGPOOL commands use multiple, parallel processes to perform an incremental backup of each primary storage pool to the copy storage pool. The COPY ACTIVEDATA commands use multiple, parallel processes to copy the active versions of client backup data to the active-data pool. Only those files for which a copy does not exist in the copy pool or active-data pool are backed up.
  
  Consider turning migration off during the rest of the day. You can add a schedule to migrate from disk to tape. In this way, the backups are done while the files are still on disk.
2. Change the access mode to offsite for copy storage pool volumes that have read/write or read-only access, are onsite, and are at least partially filled. To change the access mode, issue the following command:
```
update volume * access=offsite location='vault site info'
wherestgpool=disaster-recovery whereaccess=readwrite,readonly
wherestatus=filling,full
```
3. Back up the database by using the BACKUP DB command. For example, issue the following command:
```
backup db type=incremental devclass=tapeclass scratch=yes
```
  Restriction: Do not run the MOVE DRMEDIA and BACKUP STGPOOL or BACKUP DB commands concurrently. Ensure that the storage pool backup processes are complete before you issue the MOVE DRMEDIA command.
Perform the following operations nightly after the scheduled operations completes:
1. Back up the volume history and device configuration files. If they change, back up the server options files and the database and recovery log setup information.
2. Move the copy storage pool volumes marked offsite, the database backup volumes, volume history files, device configuration files, server options files, and the database and recovery log setup information to the offsite location.
3. Identify offsite volumes that must be returned onsite. For example, issue the following command:
```
query volume stgpool=disaster-recovery access=offsite status=empty
```
  These volumes, which became empty through expiration, reclamation, and file space deletion, waited the delay time that is specified by the REUSEDELAY parameter. The administrator periodically returns outdated backup database volumes. These volumes are displayed with the QUERY VOLHISTORY command and can be released for reuse with the DELETE VOLHISTORY command.
Bring the volumes that are identified in step 5.c onsite and update their access to read/write.