[This is preliminary documentation and subject to change.]
RSM media belongs to the following two groups:
Libraries are physical media storage locations. RSM media always belong to a library.
There are three types of libraries in an RSM system: online, stand-alone drives, and offline.
Media can be moved from an offline library to an online library or stand-alone drive only when the administrator physically inserts the media into a library unit or stand-alone drive.
In addition to media, libraries contain devices that are also managed by RSM. Drives and robotic changers are devices. RSM maintains information about devices in the database.
All RSM media also belong to a media pool. Media pools are logical collections of media that have the same media management policies. Media pools are used by applications to control access to media within an RSM system. A single media pool can contain media from more than one library. Each medium can belong to only one media pool.
The purpose of media pools is to provide a mechanism by which policies and properties can be defined for logical groupings of media. In the past, media policies and properties were typically defined for all the media in a library.
With RSM media pools, media in a single library can be shared among multiple applications. Therefore:
RSM supports two classes of media pools:
You can logically group media pools by creating hierarchies of media pools. However, a media pool cannot contain both media and other media pools.
Administrators can move media among pools through the RSM MMC snap-in, or you can use the RSM API to do this in your application.
The different types of media pools are described next.
Scratch media pools contain media that are not allocated by an application and do not contain useful data. RSM creates one scratch media pool for each media type in an RSM system.
Scratch media pools are media buffers for application media pools. An application can draw media from a scratch media pool when it is necessary for the application to allocate media. An application can deallocate media to send the media to a scratch pool. Only media that are not allocated by an application can be moved between media pools.
An application media pool can be configured so that it never automatically draws media from or returns media to scratch pools. When a media pool uses this configuration, the administrator must explicitly move media in or out of that pool.
Foreign media pools contain blank media and media that have unrecognized on-media identifiers (OMIDs).
Foreign media pools also contain media that are new to an RSM system. Administrators should immediately move new media from the foreign media pool to a scratch media pool so that RSM can assign and record OMIDs to the media for tracking.
Media in foreign media pools can be inserted, ejected, mounted, dismounted, and moved to a scratch media pool. Foreign media are automatically deleted from the RSM database when they are ejected from an online library or stand-alone drive.
RSM puts media in an import media pool when RSM recognizes the on-media identifier, but the piece of media is not cataloged in the current RSM database. For example, media in an import media pool can be from one office location that is introduced into an RSM system at another office location. RSM recognizes the OMIDs, but does not have information about the media in the current RSM database.
Media in import media pools can be moved into a scratch pool or application pool for reuse. Such media must be explicitly moved using the RSM API or the RSM MMC snap-in.
Application media pools are used by applications to determine which media can be accessed by which applications and to set the policies for that media. Media in an application media pool are owned by an application or group of applications.
Application media pools can be created by an application using the RSM API or by the administrator in the RSM MMC snap-in.
An application can use more than one media pool. For example, a backup application might use one media pool for full backup media and one for incremental backup media, each containing a different media type. More than one application can also share one media pool.
This section describes an example system and how the media pools might be configured. The example system contains one optical library and one tape library, and the administrator wants to use a backup application and a document management application on the system.
The following table shows the intersections among the libraries and applications in this system. The backup application uses tape media to store full and incremental backups, and optical disk for catalog storage. The document management application uses tape media to store engineering archive documents, and optical disk media to store accounting and engineering documents.
| Backup Application | Document Management Application | |
|---|---|---|
| Tape Media | Full backup Incremental backup |
Engineering archive documents |
| Optical Disk Media | Catalog storage | Accounting documents Engineering documents |
The following image depicts a model media pool configuration for this system. This configuration uses nesting to create a useful media pool configuration. Notice that each media pool contains other media pools or media; no media pool contains both.
In this media pool configuration, each media pool contains one type of media and serves a single purpose.