Media Management for Migrated Files

Migrated data is managed by the Backup server and is subject to all of the usual storage management features such as pools, cloning, and auto media verification. Because migrated files must be available for recall by the user, however, migrated data is exempt from the automatic data recycling policies that the Backup server applies to backup data. This means that Backup tracks the location of the migrated files in the client index and media database as long as the stub file remains on the client machine. Backups of the migrated stub files, however, are subject to the Backup server's data recycling policies. See "How HSM Handles Renamed or Deleted Files" for more information.

As long as a stub file remains on a client filesystem, the migrated files must be available for quick recall. Consequently, standalone tape drives for migration are not acceptable. Instead, use an autochanger or silo for your migration media.

Using the Migration and Migration Clone Pools

Migration volumes are the media that hold migrated data. You can either use the preconfigured Migration pool of volumes to store migrated data or create your own custom migration pool to use as the migration store. You can also automatically clone the volume to which migrated data is sent. Because migration data is written in a different format than regular backup data, migrated data can be written only to storage volumes associated with a pool of type "migration." Clones of migration volumes can be written only to storage volumes from a pool of type "migration clone." Backup provides preconfigured pools called Migration and Migration Clone for your migration data.

Client Indexes and the Bootstrap Save Set for Migration Data

Migration data is in a different format than regular Backup backup data; therefore, it must be written to a different pool of volumes. Because of these differences, the client indexes and bootstrap save set created during a premigration or migration operation are not written to the same volume as the migrated save sets. Depending on how volume pools are configured in your environment, they are most likely written to a volume from the Default pool. If you need to direct the client indexes and bootstrap to a volume pool other than Default, see "Example: Directing Client Indexes and Bootstrap to a Separate Pool " for information.

Save Set Staging and Migrated Files

You can use save set staging to move migrated files from one storage medium to another. For example, you can migrate files to a file device type and then use save set staging to move the migrated files to optical disk at a later time. Backup tracks the location of a migrated file on the new storage media and recalls the file to the location of the stub file. The change in the physical location of the migrated data is transparent to the user. See Table 8-1 for a comparison between backup, HSM, save set staging, and archive operations.

Just as you must use a volume from a pool of type "clone" for staging backup data, you must use you must use a volume from a pool of type "migration clone" when you stage migration data. For example, you can use the preconfigured Migration Clone pool when you set the staging policies for your migration data.

To manually stage a specific migration save set to the Migration Clone pool, enter the following command:

# nsrstage -s server-name -b Migration Clone -m -S save-set-ID

See "Save Set Staging " for more information on save set staging. Refer to the nsrstage man page for the syntax and options for the nsrstage program.