Defining storage pools

There are four primary storage pools and two copy pools to set up in our recommended solution. Client data backups go to storage pool DISKDATA and are then migrated to storage pool TAPEDATA before going offsite to copy pool OFFDATA. Client directory structures, which are much smaller in size, go to storage pool DISKDIRS and are then backed up to the offsite copy pool OFFDIRS. This is achieved by setting the DIRMC option in either the client options file or client option set. See Figure 12 for our recommended storage pool setup.

In 1.2, “Redbook support material” on page 2, we show how to load a predefined macro into Tivoli Storage Manager. The macromac.stgcreate, that we provide to

Most tape library management systems on MVS or OS/390 use the dataset name to identify tapes to be taken offsite. Tivoli Storage Manager uses the format<prefix>.BFSfor both onsite and offsite dataset names in one device class. To choose another dataset name for offsite copies, create another device class for the offsite copies and choose a different prefix. Set the tape library management system to trigger on this offsite name, and offsite copies will be identified automatically.

Note for MVS Users:

tsm: TSM010> define devclass coffsite devtype=3570 format=drive library=l3570 ANR2203I Device class COFFSITE defined.

tsm: TSM010> query devclass

Device Device Storage Device Format Est/Max Mount

Class Access Pool Type Capacity Limit

Name Strategy Count (MB)

--- --- --- --- --- ---

---C3570 Sequential 0 3570 DRIVE 0.0 DRIVES

COFFSITE Sequential 0 3570 DRIVE 0.0 DRIVES

DISK Random 1

create the storage pools in our redbook environment, is shown in B.1.6, “Create storage pools” on page 291.

Figure 12. Storage pool hierarchy for our recommended setup

5.8.4.1 Primary storage pools

For our recommended solution we set up four primary storage pools: TAPEDATA, DISKDATA, DISKDIRS, and NONE. Storage pool TAPEDATA must be set up before storage pool DISKDATA. This is because DISKDATA refers to TAPEDATA as its next storage pool.

The following commands set up these storage pools:

1. A primary storage pool named TAPEDATA, with device class C3570. It has collocation and reclamation turned off, and has a delay of one day before empty tapes are reused. To define a storage pool for an automated library, use the same procedure as defining a pool for a manual library.

2. A primary storage pool named DISKDATA, with a device class of DISK. It has an upper threshold of 70% that must be reached for migration to start, and a lower threshold of 30% that is reached or surpassed before migration stops.

The pool to which data migrated goes is called TAPEDATA. The disk pool is not using disk caching.

3. A primary storage pool named DISKDIRS, with a device class of DISK. It has has migration turned off, since we want to keep the client directory structure

CLIENT_1

permanently on disk. This will allow fast reconstruction of the directory structure during a restore. The space needed to store directory information is small, so only a small-size volume will be needed in this storage pool. Note that only client operating systems where the directories have extended attributes need to store them in a storage pool, in particular NT. On UNIX clients, the directory entries are stored directly in the Tivoli Storage Manager server database. We recommend to use a special directory storage pool for purposes of control. If you do not use the DIRMC client option to specify where directories are stored, they will be sent to whichever management class specifies the longest retention period.

4. A dummy storage pool named NONE, which is just an empty definition. No data will be stored in this storage pool. There are no storage pool volumes assigned to it. See 6.2.3, “Defining management classes” on page 135 for an explanation for why we define this here.

5.8.4.2 Copy storage pools

For our recommended solution we have set up two copy storage pools: OFFDIRS and OFFDATA. These pools have a reuse delay of five days before reclaimed offsite tape volumes are moved back to the scratch pool. This is to allow for a long company shutdown, such as Easter holidays, where the offsite data must remain intact in case a disaster occurs onsite and it is required for the recovery.

You must set this value equal to the longest period of time before normal operations resume for you. Normal operations are when the database and primary pools are backed up and volumes are taken offsite.

The following commands set up these storage pools:

1. A copy storage pool named OFFDIRS, with device class COFFSITE.

Reclamation is switched off and the reuse delay is set for five days.

2. A copy storage pool named OFFDATA, with device class COFFSITE.

Reclamation is switched off and the reuse delay is set for five days. The MAXSCRATCH value is set high, purposefully, to avoid a "storage pool full"

message occurring.

tsm: TSM010> define stgpool tapedata c3570 highmig=100 maxscratch=1000 \ cont> collocate=no reclaim=100 reusedelay=1

ANR2200I Storage pool TAPEDATA defined (device class C3570).

tsm: TSM010> define stg diskdata disk nextstg=tapedata highmig=70 \ cont> lowmig=30 cache=no

ANR2200I Storage pool DISKDATA defined (device class DISK).

tsm: TSM010> define stgpool diskdirs disk highmig=100 ANR2200I Storage pool DISKDIRS defined (device class DISK).

tsm: TSM010> define stgpool none disk

ANR2200I Storage pool NONE defined (device class DISK).

tsm: TSM010> query stgpool

Storage Device Estimated Pct Pct High Low Next Pool Name Class Name Capacity Util Migr Mig Mig Storage

(MB) Pct Pct Pool

--- --- --- --- --- ---- ---

---DISKDATA DISK 0.0 0.0 0.0 70 30 TAPEDATA

DISKDIRS DISK 0.0 0.0 0.0 100 70

DISKFILE CFILE 1,200.0 0.3 1.0 100 70

NONE DISK 0.0 0.0 0.0 90 70

TAPEDATA C3570 0.0 0.0 0.0 100 70