File Migration Management

This section contains information about additional administrative considerations for your migration clients and migrated files.

Backup and Recovery Considerations With HSM

After a file has been migrated, when Backup backs up the client filesystem from this point forward, it only backs up the stub file that is left on the client machine. A Backup backup of a stub file does not recall the migrated file. When you recover a filesystem that contains a stub file for migrated data, Backup only recovers the stub file to the local disk. The migrated data is not recalled.

To recall a file to the client's local disk, open the file on the client machine. Backup automatically recalls the file from the migration store. If the media containing your migrated file is not currently mounted, Backup notifies the administrator.

Recovering an Accidentally Deleted Stub

If you accidentally delete a stub file on a migration client, you can restore the stub file from backup media within 60 days of the deletion. Recovering a stub file does not initiate a recall. If a stub file has not been recovered after 60 days, Backup removes the entry for the migrated file from the client index and no longer tracks the data.

Cloning Migration Media

To ensure that you can recover all your data, you should regularly clone your migration media. Because Backup only backs up the stub file on the client computer, not the migrated data itself, the clone might contain the only extra copy of a file. You can specify cloning to occur automatically after the migration process is completed by selecting the Migration Clone pool in the group resource you created for your migration clients. Clones of migration data must be written to volumes from a pool of type "migration clone." See "Using the Migration and Migration Clone Pools" for more information.

Performing a Super-Full Backup

To provide additional backup protection for migrated files, you should regularly perform super-full backups of your migration clients. A super-full backup clones both the most recent full backup of a save set and all the migration save sets, so it contains the stub file on the client and the data in the migration store. To perform a super-full backup, become root on the Backup server, then enter the following command from the shell prompt:

# nsrclone -c client-name -N save-set-name

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.

Manually Migrating Files

You can manually premigrate and migrate files on a migration client from the command line. Use manual migration when the filesystem is full or nearly full, for example, after you receive a Migration Attention notification. First, you premigrate the files using the nsrpmig command, then you migrate the files using the nsrmig command. Migrating large files provides the most benefit because it frees the most local disk space.

A file must be premigrated before it can be migrated.

To premigrate a file manually, enter the following command:

# nsrpmig -s server-name -b pool -g group path

• The -b and -g options are not required. If you do not specify these options, the Migration resource defaults are used.

• If you do not specify a path, the current directory is used.

After you have premigrated a file, migrate it manually by entering the following command:

# nsrmig -s server-name path

If you do not specify a path, the current directory is used. Migration continues until the filesystem capacity reaches the low water mark specified in the Migration resource.

Refer to the nsrpmig and nsrmig man pages for more details about these two commands.

How HSM Handles Renamed or Deleted Files

The nsrhsmck (HSM consistency checker) command automatically checks and corrects the consistency of HSM-managed file systems every night at 2:00 a.m.

How to Complete Manual Consistency Check Using nsrhsmck

You can also check the consistency of HSM-managed filesystems manually. The nsrhsmck command checks and corrects the consistency of HSM-managed filesystems and deals with cases in which the stubs files are renamed or deleted from the client filesystem. The basic syntax of the nsrhsmck command is:

# nsrhsmck -cdfv -s server-name path

You must specify a path on the command line when you run nsrhsmck. Only files and index entries that fall under the specified path are examined for consistency.

If you rename the stub file on the client machine, Backup cannot recall the migrated file to its original location. Before you can recall the file, you must use the nsrhsmck -f command to update the client index to reflect the new name.

If you delete the stub file from the client machine, you can recover the stub file from backup media, then recall the actual file.

If you want to delete a migrated file, delete the stub file from local disk, then use the nsrhsmck -d command to mark the client index entry for the migrated file as possibly deleted. After 60 days, use the nsrhsmck -c command to remove the expired entries from the client index. Backup no longer tracks the migrated file and the file cannot be recalled.

Before an entry is deleted from the client index, Backup checks to make sure the file does not exist on disk. If a file marked as possibly deleted is detected on disk before the index entry is deleted, the index entry will be unmarked as a possible deletion.

Migration Monitoring

The Migration Control resource in the Backup administration program displays a list of clients configured for HSM services and statistics for all migration activities that occurred within the last seven days.

You can produce reports on HSM activities using command line instructions. Refer to the man pages for details on using these commands:

• Use the nsrinfo command to list files in a save set.

• Use the mminfo command or the cloning browser to determine which save sets were migrated in the previous twenty-four hours.

• Use the nsrmig -n command to produce a report of files eligible for migration without actually migrating them.

• Use the nsrpmig -n command to produce a report of files eligible for premigration without actually premigrating them.

To customize the Migration Completion notification, modify the resource configured for the notification. By default, a migration completion notice is sent by email to root any time a migration event occurs such as the high water mark being reached. See "Event Notification" for more information.