Managing Tivoli Storage Manager storage

This part of the book provides information about tasks required to maintain Tivoli Storage Manager storage, such as preparing storage volumes, managing storage volumes in an automated library, managing media mount operations, automating operations, and registering client nodes. Tivoli Storage Manager is also known as IBM Spectrum Protect.

Overview

This part of the book provides a brief overview of tasks that Tivoli Storage Manager administrators need to do to manage Tivoli Storage Manager storage. The Tivoli Storage Manager Administrator's Guide presents the details of the tasks and the concepts that you need to understand to complete them. The Installation and Configuration Guide is another important source of information. When you installed and configured a Content Manager OnDemand server with Tivoli Storage Manager, you completed many of the tasks described here: configuring devices and defining them to Tivoli Storage Manager, defining policy management information, preparing storage volumes, registering client nodes, and increasing the size of the database and recovery log.

The following topics provide more information:

Using magnetic disk devices with Tivoli Storage Manager
Using removable media devices with Tivoli Storage Manager
Managing removable media operations
Defining drives and libraries
Defining device classes
Managing storage pools
Managing storage pool volumes
Managing policies
Managing client nodes
Automating server operations
Managing server operations
Managing the database and recovery log
Monitoring the server
Protecting and recovering your data

Using magnetic disk devices

In a Content Manager OnDemand system, the primary use of magnetic disk devices with Tivoli Storage Manager is the storage of the database and recovery log. The Tivoli Storage Manager database contains information needed for server operations and information about data that has been backed up, archived, and space-managed. The database contains pointers to the locations of all client files in the Tivoli Storage Manager storage pools. Changes to the database are recorded in the recovery log in order to maintain a consistent database image. The recovery log contains information about updates that have not yet been committed to the database. If the database is unusable, the entire Tivoli Storage Manager server is unavailable. If a database is lost and cannot be recovered, the backup, archive, and space-managed data for that server is lost. Refer to Managing the database and recovery log and Protecting and recovering data for steps that you can take to protect your database.

Using removable media devices

In a Content Manager OnDemand system, removable media devices can be used with Tivoli Storage Manager for the following purposes:

Storage of application group data, including migrated index data. Application group data is typically stored in optical libraries, but can also be stored in automated tape libraries.
Storage of Tivoli Storage Manager database backups. Database backups are typically stored on manually operated devices, such as an 8mm tape drive, but can also be stored in optical or automated tape libraries.
Storage of Db2® archived log files and backup image files. Db2 files must be stored on rewriteable optical media (not WORM) or tape.

Tivoli Storage Manager allows you to use and reuse removable media to store data. You must prepare removable media for initial use by Tivoli Storage Manager. You also control how and when media are reused. The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide shows examples of labeling removable media for initial use and checking storage volumes into a library. For detailed guidance and scenarios on configuring your removable media devices, see the Tivoli Storage Manager Administrator's Guide.

Managing removable media operations

Volumes must be mounted in response to mount requests from Tivoli Storage Manager. For manual libraries, you can monitor the mount requests by using an administrative client in mount mode or console mode. Someone you designate as the operator must respond to the mount requests by putting in tape volumes as requested. For devices in automated libraries, Tivoli Storage Manager interacts with the library to mount volumes, but sends messages when the library needs attention from an operator. Tivoli Storage Manager also tracks the inventory of media in each automated library.

For automated libraries, Tivoli Storage Manager works with the operating system and the library to accomplish volume mounts. Mount messages are not sent to an operator. However, information about problems with the library are still sent to the mount message queue. You can see these messages on administrative clients that have been started with either the mount mode or console mode parameter. However, you cannot use the Tivoli Storage Manager REPLY command to respond to these messages. You can get information about pending operator requests either by using the QUERY REQUEST command or by checking the mount message queue on an administrative client started in mount mode.

In many cases, an operator request has a time limit. If the requested action is not performed within the time limit, the operation times out and fails.

For most types of requests, such as volume mounts, the server detects when the operator performs the action. The operator does not usually need to respond to the Tivoli Storage Manager server carrying out the requested activity. However, sometimes the server cannot detect the completion of the requested action. When the server requires a reply, the message that is displayed by the server requests that the operator reply when the activity has been completed. For example, a request to mount a scratch volume requires that the operator reply when a scratch volume has been placed in the drive. Tivoli Storage Manager waits for a reply to prevent the use of the wrong volume.

For information about managing removable media operations, see the Tivoli Storage Manager Administrator's Guide.

Defining drives and libraries

To use removable media devices with Tivoli Storage Manager, you must define the libraries and drives to Tivoli Storage Manager.

The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide provides examples of defining drives and libraries. For detailed information about defining drives and libraries, see the Tivoli Storage Manager Administrator's Guide.

Defining device classes

A device class represents a set of storage devices with similar availability, performance, and storage characteristics. You must define devices classes for the types of drives available to a Tivoli Storage Manager server. You specify a device class when you define a storage pool, which is a named collection of volumes for storing data.

The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide provides examples of defining device classes. See the Tivoli Storage Manager Administrator's Guide for detailed information about device classes.

Managing storage pools

Content Manager OnDemand data is stored in groups of volumes called storage pools. The data on these primary storage pools can be backed up to copy storage pools for disaster recovery purposes. Because each storage pool is assigned to a device class, you can logically group your storage devices to meet your storage management needs.

The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide provides examples of defining primary storage pools. For more information about copy storage pools, see the Tivoli Storage Manager Administrator's Guide.

Managing storage pool volumes

You manage storage volumes by defining, updating, and deleting volumes, and by monitoring the use of server storage. Monitoring volumes can reveal inconsistencies between information in the database and client node files in storage pools. You can also move files within and across storage pools to optimize the use of server storage.

For each automated library, Tivoli Storage Manager tracks in its volume inventory for the library whether a volume has scratch or private status:

A scratch volume is a labeled volume that is empty or contains no valid data, and can be used to satisfy any request to mount a scratch volume. To support Content Manager OnDemand, you typically define scratch volumes to Tivoli Storage Manager. Tivoli Storage Manager uses scratch volumes as needed, and returns the volumes to scratch when they become empty (for example, when all data on the volume expires).
A private volume is a volume that is in use or owned by an application, and may contain valid data. Volumes that you define to Tivoli Storage Manager are private volumes. A private volume is used to satisfy only a request to mount that volume by name. When Tivoli Storage Manager uses a scratch volume, it changes the volume's status to private by defining it. Tivoli Storage Manager tracks whether defined volumes were originally scratch volumes. Volumes that were originally scratch volumes return to scratch status when they become empty.

In addition to preparing removable media for Tivoli Storage Manager, you need to maintain a supply of scratch volumes and manage the volume inventory in an automated library. Managing a library may mean that you need to remove volumes from a library, return volumes to a library, and manage a full library. Other chapters in this part of the book provide examples of preparing storage volumes and adding storage volumes to and removing storage volumes from automated libraries. For details about these tasks, see the Tivoli Storage Manager Administrator's Guide.

Managing policies

Content Manager OnDemand documents, application group index data, and Db2 files can be backed up to the server. This process ensures that the information can be retrieved when needed. Recall of documents and Db2 files is transparent and automatic when a client retrieves a document or Db2 needs to retrieve a backup image file or archived log file to restore the database. Importing migrated index data requires administrator intervention.

You define policies based on your requirements for archiving, backing up, or migrating data. You do this by defining policy objects, which identify archive, backup, and migration criteria, and by scheduling client operations.

The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide provides examples of defining policies to support archiving documents, backing up Db2 files, and migrating index data. See the Tivoli Storage Manager Administrator's Guide for more information about establishing and managing policies.

Managing client nodes

You register Content Manager OnDemand primary storage nodes as client nodes in Tivoli Storage Manager. You provide client/server authentication by requiring the use of passwords to ensure that the client and the server are authorized to communicate with each other. You can also set the length of passwords and determine when passwords expire.

You can define sets of client options for clients to use. For example, you typically define one set of client options for Content Manager OnDemand application group data and another set of client options for Db2 files.

You can control access to the server by administrators. An organization may name a single administrator or may distribute the workload among a number of administrators and grant them different levels of authority.

The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide provides examples of registering client nodes, defining client options for Content Manager OnDemand primary storage nodes, and registering administrators. See the Tivoli Storage Manager Administrator's Guide for more information about managing clients.

Automating server operations

You can define schedules for the automatic processing of most administrative commands, such as backing up primary storage pool data to a copy storage pool and backing up the database.

See the Tivoli Storage Manager Administrator's Guide for information about scheduling Tivoli Storage Manager commands and operations.

Managing server operations

You can manage server operations such as starting and stopping the server, maintaining and suspending client sessions with the server, and controlling server processes.

In a Content Manager OnDemand system, after you initially set up the Tivoli Storage Manager Server and Scheduler services to start automatically and define schedules for specific server operations (such as backing up the database and copying data from primary storage pools to copy storage pools), there is very little you need to do to manage the server operations on a day-to-day basis.

See the Tivoli Storage Manager Administrator's Guide for details about the day-to-day tasks involved in administering the server and about reports and information available to help you manage the server.

Managing the database and recovery log

The Tivoli Storage Manager database contains information about Content Manager OnDemand data in storage pools, registered client nodes, Tivoli Storage Manager policies, and Tivoli Storage Manager schedules. The server recovery log, which records changes made to the database, is used to restore the database to a consistent state and to maintain consistency across server start-up operations.

After your system is operational, you should monitor the database and recovery log to see if you should add space. You can reset the maximum utilization counters for the database and recovery log to monitor daily utilization. To set the maximum utilization percentage equal to the current utilization, you might want to reset the utilization statistics each day. The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide shows how to increase the size of the database and the recovery log. See the Tivoli Storage Manager Administrator's Guide for information about monitoring the database and recovery log.

Monitoring the server

Tivoli Storage Manager provides you with many sources of information about server and client status and activity, the state of the database, and resource usage. By monitoring this information, you can provide reliable services to users while making the best use of available resources.

You can use Tivoli Storage Manager queries and SQL queries to get information about the server. You can also set up logging of information about Tivoli Storage Manager clients and server events. See the Tivoli Storage Manager Administrator's Guide for more information about these tasks.

Protecting and recovering data

Tivoli Storage Manager provides a number of ways to protect and recover your data from media failure or from the loss of the Tivoli Storage Manager database or storage pools due to a disaster. These recovery methods are based on the following preventive measures:

Mirroring, by which the server maintains one or more copies of the database or recovery log, allowing the system to continue when one of the mirrored disks fails. IBM® recommends that you mirror at least one copy of the database and the recovery log to different physical storage volumes.
Periodic backup of the database. IBM recommends that you schedule frequent backups of the database, after every load or system configuration change, or once a day. If you do not load reports every day or your system configuration does not change very often, you may be able to schedule backups less frequently, perhaps once a week.
Periodic backup of the storage pools. To protect Content Manager OnDemand data stored in Tivoli Storage Manager, you may want to backup data in a primary storage pool to a copy storage pool. See your Tivoli Storage Manager information for assistance with configuring a copy storage pool.
Recovery of damaged files.

Disaster Recovery Manager (DRM) is an optional feature of Tivoli Storage Manager that assists an administrator with preparing a disaster recovery plan. The disaster recovery plan can be used to guide an administrator through disaster recovery as well as for audit procedures to certify the recoverability of the Tivoli Storage Manager server. DRM's disaster recovery methods are based on the following measures:

Enabling Disaster Recovery Manager
Creating a backup copy of server primary storage pools and database
Sending server backup volumes offsite
Moving reclaimed or expired volumes back onsite
Create the Tivoli Storage Manager server disaster recovery plan file
Storing client machine information
Defining and tracking client recovery media

For more information about protecting your data and for details about recovering from a disaster, see the Tivoli Storage Manager Administrator's Guide.

Mapping Tivoli Storage Manager objects to Content Manager OnDemand application group objects

You might need to reload data with files that are obtained from the Tivoli Storage Manager volume. For example, here is some typical Tivoli Storage Manager volume content:

OD6YNODE            Arch     /JCA             12     /RES/ 27120        
OD6YNODE            Arch     /JCA             12     /DOC/ 39072FAAA    
OD6YNODE            Arch     /LCA             15     /RES/ 7268         
OD6YNODE            Arch     /LCA             15     /DOC/ 31844FAA1

In some instances, you might not be able to determine the application group name, or know how to search in the application group tables. You might also miss system log records to find out the load ID to extract the object file name. The challenge here is to determine and verify the object file name from the existing data.

The Tivoli Storage Manager file space names (for example, /JCA) correspond to the Content Manager OnDemand application group three-letter identifier. With the three letter application group identifier, you can obtain the application group ID (AGID) by querying the ARSAG table.

You can use the application group ID to query the ARSSEG table for the corresponding application group table name or names. The table name is TABLE_NAME. The application group table name is something like AGIDn, where n is an integer. For example, JCA1.

The object file names are recorded in the DOC_NAME field of the application group table.

Important: If you delete an application group, the Tivoli Storage Manager filespace is also deleted, and all of the objects for that application group are removed regardless of their expiration parameters.

Exception: If you use data retention protection, the Tivoli Storage Manager filespace is not deleted, instead, Content Manager OnDemand deletes all application group objects.

Starting, halting, and restarting the server

Tivoli Storage Manager administrators can manage server operations. These operations include such tasks as starting and halting the server, adding or updating server options, defining devices and policies, managing removable media, and monitoring server information.

Starting the server

To start the server, complete the following steps:

Change to the Tivoli Storage Manager server program directory.
Start the server:
```
     dsmserv
```
When the server is started, Tivoli Storage Manager displays information about product licensing, server options, the database and recovery log, storage pools, and progress messages and any errors encountered during server initialization.

Important: You can capture Tivoli Storage Manager server console messages to a user log file with the Tivoli Storage Manager dsmulog utility. See the Tivoli Storage Manager documentation for more information.

Starting the Tivoli Storage Manager server command line interface

In this part of the book, most examples illustrate how to perform tasks by using the Tivoli Storage Manager server command line interface. To start the Tivoli Storage Manager server command line interface, type the following command:

     dsmadmc

Tivoli Storage Manager provides you with ways to monitor processes and messages:

Use the console mode from an administrative client to monitor processes and messages:
```
     dsmadmc -consolemode
```
While the system is running in console mode, you cannot enter any administrative commands from the client session. You can, however, start another administrative client session for entering commands.
Specify the OUTFILE option to write all terminal output to a file. For example:
```
     dsmadmc -consolemode -outfile=adsm.out
```
From the command line interface, query the activity log for status information and possible error messages:
```
     query actlog
```

Refer to the Tivoli Storage Manager documentation for more information about managing client sessions.

Halting the server

When you halt the server, all processes are abruptly stopped and client sessions are canceled, even if they are not completed. Any in-progress transactions are rolled back when the server is restarted. When the server is halted, administrator activity is not possible. If possible, halt the server only after current administrative and client node sessions have completed or canceled. To shut down the server without severely impacting administrative and client node activity with the server, follow the instructions in the Tivoli Storage Manager documentation.

To halt the server and shut down all server operations, enter halt at the Tivoli Storage Manager Server command line interface.

Restarting the server

To start the server after it has been halted, follow the instructions in Starting the server.

When you restart the server after it has been halted, Tivoli Storage Manager rolls back any operations that had been in process to ensure that the database remains in a consistent state.

Using scratch and private volumes

A scratch volume is a labeled volume that is empty or contains no valid data, and can be used to satisfy any request to mount a scratch volume. A private volume is a volume that is in use or owned by an application, and may contain valid data. Volumes that you define to Tivoli Storage Manager are private volumes. A private volume is used to satisfy only a request to mount that volume by name. For each storage pool, you must decide whether to use scratch volumes.

If you use scratch volumes, Tivoli Storage Manager uses volumes as needed, and returns the volumes to scratch when they become empty (for example, when all of the data on the volume expires). If you do not use scratch volumes, you must define each volume you want Tivoli Storage Manager to use. Volumes that you define to Tivoli Storage Manager are private volumes, and do not return to scratch when they become empty.

For each automated library, Tivoli Storage Manager tracks in its volume inventory for the library whether a volume has a scratch or private status. If you allow scratch volumes to be used for a storage pool, Tivoli Storage Manager chooses a scratch volume from the scratch volumes that are checked in for the library.

When Tivoli Storage Manager uses a scratch volume, Tivoli Storage Manager changes the volume's status to private by defining it. Tivoli Storage Manager tracks whether defined volumes were originally scratch volumes. Volumes that were originally scratch volumes return to scratch status when they become empty.

One of the benefits of using scratch volumes is that different storage pools that share the same automated library can dynamically acquire volumes from the library's pool of scratch volumes. The volumes need not be preallocated to the different storage pools.

Another benefit of using scratch volumes, even if only a single storage pool is associated with an automated library, is that you need not explicitly define all of the volumes for the storage pool using DEFINE VOLUME commands. Volumes are automatically added to and deleted from the storage pool by the server.

If a scratch volume is used for a Tivoli Storage Manager database backup or export operation, then Tivoli Storage Manager changes the volume's status to private. The volume returns to the scratch pool only when a Tivoli Storage Manager administrator determines that the volume's data is no longer needed, and uses the UPDATE LIBVOL command to change the status of the volume to scratch.

Labeling storage volumes

All removable media must be labeled before it can be used by Tivoli Storage Manager. When the server accesses a volume, it checks the volume name in the header to make sure that the correct volume is being used. Any tape storage volumes must be labeled before the server can use them.

For storage pools in automated libraries, use the CHECKIN LIBVOL command to check labeled volumes into a library.

Use the LABEL LIBVOL command with drives in an automated library to label and check in the volumes with one command. To use the LABEL LIBVOL command, there must be a drive that is not in use by another Tivoli Storage Manager process. This includes volumes that are mounted but idle. If necessary, use the UNMOUNT VOLUME command to unmount the idle volume to make that drive available.

Overwriting volume labels

By default, the label command does not overwrite an existing label on a volume. However, if you want to overwrite existing volume labels, you can specify the OVERWRITE=YES parameter when you use the LABEL LIBVOL command.

Important: By overwriting a volume label, you destroy all of the data that resides on the volume. Use caution when overwriting volume labels to avoid destroying important data.

Identifying volume labels

Use the LABEL LIBVOL command to specify the volume for labeling. You can use the VOLRANGE parameter of the LABEL command for a large number of volumes. For automated libraries, you are prompted to mount the volume in the entry/exit port of the library. If no entry/exit port is available, mount the volume in an empty slot within the library. For manual libraries, you are prompted to load the volume directly into the library.

Labeling volumes one at a time

The LABEL LIBVOL command assumes that you will insert volumes into the library when prompted to do so. The label process then mounts each inserted volume into a drive and writes a label to it using a name that you enter at a prompt. This is the default mode of operation when you specify a library for use with the LABEL LIBVOL command.

If the library does not have an entry/exit port, you are prompted to remove the volume from a specified slot number. If the library has an entry/exit port, the command by default returns each labeled volume to the entry/exit port of the library.

To label one volume in the odlib0 library, enter:

     label libvol odlib0 od5000 search=no

Where od5000 is the volume label.

Searching all of the storage slots in the library

The LABEL LIBVOL command searches all of the storage slots in the library for volumes and tries to label each one that it finds. You choose this mode when you specify the SEARCH parameter. After a volume is labeled, the volume is returned to its original location in the library.

For an automated SCSI library, you can simply open the library access door, place all of the new volumes in unused storage slots, close the door, and issue the LABEL LIBVOL command with the SEARCH=YES parameter.

To label all of the volumes in the odlib0 library by searching the library and specifying a range of volume labels, enter:

     label libvol odlib0 search=yes volrange=od5000

Tivoli Storage Manager labels the first volume od5000 and increments the number 5000 for the label of each additional volume you label with this command.

Adding storage volumes

You inform the server that a new volume is available in an automated library by checking in the volume with the CHECKIN LIBVOL command. When a volume is checked in, the server adds the volume to its library volume inventory. You can also use the LABEL LIBVOL command to label and check in volumes in one operation.

Because the CHECKIN LIBVOL command involves device access, it may take a long time to complete.

When you check in a volume, you must supply the name of the library and the status of the volume (private or scratch).

To check in one or just a few volumes, you can specify the name of the volume with the command, and issue the command for each volume.

To check in a larger number of volumes, you can use the search capability of the CHECKIN command or you can use the VOLRANGE parameter of the CHECKIN command.

Checking in volumes one at a time

Use this option if you want to check in only a single volume that is not currently in the library. Tivoli Storage Manager requests that the volume be placed in the entry/exit port of the library.

If the library does not have an entry/exit port, Tivoli Storage Manager requests that the volume be loaded into a slot within the library. The mount request specifies the location with an element address. Element addresses are listed on the device configuration worksheets for the libraries supported by Tivoli Storage Manager. See the Tivoli Storage Manager Administrator's Guide or the documentation provided with the library.

To check in a private volume:

     checkin libvol odlib0 od1092 status=private search=no

Where odlib0 is the name of the library and od1092 is the volume label.

To check in a scratch volume:

     checkin libvol odlib0 od2001 status=scratch search=no

Where odlib0 is the name of the library and od2001 is the volume label.

Searching the library

Use this option if you want Tivoli Storage Manager to automatically search the library for new volumes that have not already been added to the library volume inventory. Use this mode when you have a large number of volumes to check in, and you want to avoid issuing an explicit CHECKIN LIBVOL command for each volume.

With this option, you cannot specify a volume name because the server searches for new volumes in the library.

For an automated SCSI library, you can simply open the library access door, place all of the new volumes in unused storage slots, close the door, and issue the CHECKIN LIBVOL command with SEARCH=YES. For example:

     checkin libvol odlib0 search=yes status=scratch

Where odlib0 is the name of the library. Tivoli Storage Manager will label the new volumes, check them into the library, and add them to the library volume inventory.

Allowing swapping of volumes

If no empty slots are available in the library when you are checking in volumes, the check-in fails unless you allow swapping. If you allow swapping and the library is full, Tivoli Storage Manager selects a volume to eject before checking in the volume you requested.

Tivoli Storage Manager selects the volume to eject by checking first for any available scratch volume, then for the least frequently mounted volume.

Removing storage volumes

Tivoli Storage Manager tracks the scratch and private volumes available in an automated library through a library volume inventory. Tivoli Storage Manager maintains an inventory for each automated library. The library volume inventory is separate from the inventory of volumes for each storage pool. To add a volume to a library's volume inventory, you check in a volume to that library.

To make sure that the Tivoli Storage Manager library volume inventory remains accurate, you must check out volumes when you need to physically remove them from a SCSI or 3494 library device. When you check out a volume that is being used by a storage pool, the volume remains in the storage pool. If Tivoli Storage Manager requires the volume to be mounted while it is checked out, a message to mount the volume is displayed with a request to check in the volume. If the check in is not successful, Tivoli Storage Manager marks the volume as unavailable.

To check whether the Tivoli Storage Manager library volume inventory is consistent with the volumes that are physically in the library, you can audit the library. The inventory can become inaccurate if volumes are moved in and out of the library without informing the server (by using check-in and check-out commands).

Removing volumes from a library

You may need to remove a volume from a library because all of the volumes in the library are full, and you want to remove some that are not likely to be accessed in order to make room for new volumes that can be used to store more data.

To remove a volume from an automated library, use the CHECKOUT LIBVOL command. By default, the server mounts the volume being checked out and verifies the internal label. When the label is verified, the server removes the volume from the library volume inventory, and then moves it to the entry/exit port of the library. If the library does not have an entry/exit port, Tivoli Storage Manager requests that the volume be removed from a slot within the library.

If you check out a volume that is defined in a storage pool, the server may attempt to access it later to read or write data. If this happens, the server requests that the volume be checked in.

Returning volumes to a library

When you check out a volume that is defined to a storage pool, to make the volume available again, you must do the following:

Check in the volume for the library, with private status. Use the CHECKIN LIBVOL command with the STATUS=PRIVATE parameter.
Update the volume's ACCESS value. You must change the access from unavailable to read/write or read-only. Use the UPDATE VOL command with the ACCESS parameter.

Managing a full library

As Tivoli Storage Manager fills volumes in a storage pool, the number of volumes needed for the pool may exceed the physical capacity of the automated library. To make room for new volumes while keeping track of existing volumes, you can define an overflow location near the library for the storage pool. You then remove media to the overflow location as needed.

The following shows a typical sequence of steps to manage a full library:

Define or update the storage pool associated with the automated library, including the overflow location parameter. For example, you have a storage pool named odaix1 associated with an automated library. To update the storage pool to add an overflow location of room2948, enter:
```
     update stgpool odaix1 ovflocation=room2948
```
When the library becomes full, use the MOVE MEDIA command.
Tivoli Storage Manager records the location of the volumes that you move with the MOVE MEDIA command. The location of the volumes is the overflow location that you defined for the storage pool. For example, to move all full volumes in the specified storage pool out of the library, enter:
```
     move media * stgpool=odaix1
```
Check in new scratch volumes, if needed.
As requested through Tivoli Storage Manager mount messages, check in volumes that Tivoli Storage Manager needs for operations. The mount messages include the overflow location of the volumes.

To find the location of volumes in a storage pool that has an overflow location, you can use the QUERY MEDIA command. You can also use the QUERY MEDIA command to generate the commands required to check in all of the volumes into the library.

Offline storage of storage volumes

Refer to the documentation provided by the library manufacturer for instructions that describe how to handle physical storage volumes and remove them from the library.

Refer to your organization's media storage guide for instructions about documentation you may need to complete when you remove a storage volume from a library and where to store them for safekeeping.

Protecting data with the data retention protection (DRP) protocol

To avoid the accidental erasure or overwriting of critical data, Content Manager OnDemand now supports the Tivoli Storage Manager Version 5.2.2 or later APIs related to data retention. Specifically:

data retention protection (DRP): Prohibits the explicit deletion of documents until their specified retention criterion is met. Although documents can no longer be explicitly deleted, they can still expire. Attention: DRP is permanent. Once it is turned on, it cannot be turned off.
Event-based retention policy: Retention based on an external event other than the storage of data. For Content Manager OnDemand, the retention event is the call to delete the data. A load, unload, application group delete, or expiration of data triggers the retention event.

Restriction: Content Manager OnDemand does not support deletion hold, a feature that prevents stored data from being deleted until the hold is released.

If you decide to use these policies in Tivoli Storage Manager, then the following scenarios result:

Table 1. Scenarios of using creation-based object expiration policy and event-based retention object expiration policy. This table contains example scenarios for creation-based object expiration policies and event-based retention object expiration policies .
	Creation-based object expiration policy	Event-based retention object expiration policy
Data retention protection off	Content Manager OnDemand issues a delete object command through the TSM API. Objects are deleted during the next inventory expiration. If a Content Manager OnDemand application group is being deleted, a `delete filespace` command is issued instead, and the objects are immediately deleted along with the filespace.	Content Manager OnDemand issues an event trigger command through the TSM API. The status of the objects affected are changed from PENDING to STARTED, and will be expired by TSM based on their retention parameters. If the retention parameters are set to NOLIMIT, then the objects never expire. If a Content Manager OnDemand application group is being deleted, a `delete filespace` command is issued instead, and the objects are immediately deleted along with the filespace.
Data retention protection on	Content Manager OnDemand issues no commands to TSM. The objects are effectively orphaned by Content Manager OnDemand and will be expired by TSM based on their retention parameters. If the retention parameters are set to NOLIMIT, then the objects never expire.	Content Manager OnDemand issues an event trigger command through the TSM API. The event status of the objects affected are changed from PENDING to STARTED and will be expired by TSM based on their retention parameters. If the retention parameters are set to NOLIMIT, then the objects never expire. If a Content Manager OnDemand application group is being deleted, then a `delete filespace` cannot be used with DRP on so the operation is treated the same as if a delete were indicated. The status of all the affected objects is changed from PENDING to STARTED, and they will be expired by TSM based on their retention parameters. Because this leaves the filespace entries in TSM, you must manually delete these entries when the filespace is empty (even with DRP on).

Recommendations:

Set up the application groups to expire by load.
Define the Tivoli Storage Manager archive copy groups to be event-based, and retain data for 0 days.
Run the Tivoli Storage Manager inventory expiration regularly to ensure that expired data is cleaned up.

Additionally, Content Manager OnDemand supports the following devices:

IBM DR450 and DR550: Disk-based system that contains a Tivoli Storage Manager running DRP.
EMC Centera: Disk-based system, treated as a device by Tivoli Storage Manager. Tivoli Storage Manager must be running DRP.