Chapter 8 Hierarchical Storage Management

Backup Hierarchical Storage Management (HSM) is an optional module for Solaris Backup clients that enables you to effectively manage your network's storage resources. HSM allows you to keep newer data available for fast access without compromising the availability of older or less frequently accessed data. The HSM module must be enabled on a Backup server, and the client computer must be configured as a migration client.

This chapter contains the following topics:

• "How HSM Works"

• "Enabling and Registering HSM"

• "Configuring a Migration Client"

• "File Migration Management"

How HSM Works

HSM automatically moves data between your local disk and another storage media based on a set of policies specified by an administrator. Migration is the process of moving files from a client filesystem to the migration store, which is a remote migration storage device; recall is the process of moving files from the remote storage device back to the original location on the client filesystem. The purpose of HSM is to manage a network's storage resources more effectively by keeping newer data available for fast access without compromising the availability of older or less frequently accessed data. Except for a relatively longer access time for migrated files, the entire migration and recall process is transparent to the user.

HSM moves files between the migration client and the migration store and is managed by the migration server. The migration client is any system on the network containing data to be migrated. The migration server is a system on the network providing migration services. The migration store is attached to the migration server and can consist of disks, tapes, or optical storage media.

This data management strategy relies on the administrator's definition of a high water mark, which defines the threshold condition that determines when automatic migration begins, and a low water mark, which defines the threshold condition that determines when automatic migration stops. Migration continues until all eligible files are migrated or until the low water mark is reached.

File Migration

File migration is a "sweeping" operation determined by the criteria you define. Backup generates lists of files that are candidates for migration according to the assigned criteria. Access time is the most frequently used parameter to determine these candidates. You can enable or disable migration services for each migration client. Certain files are always excluded from migration. These files include system files, shared libraries, and all executables and data files used by Backup.

File migration can be either automatic or manual, depending on the requirements of your system. All you have to do is define your criteria and assign the appropriate criteria to each migration client. Backup automatically migrates each client's files that meet those criteria. Backup automatically recalls a migrated file when a user or application accesses it.

When a file is migrated, the original file on the client computer is replaced with a stub file that points to the location of the migrated file on storage media. The stub file is a UNIX symbolic link and contains information about the file that serves two purposes:

• As a place holder for the migrated file, making it appear as though the file is still resident on the local disk

• As a pointer to the new location, allowing the HSM software to find the migrated file and recall it to the local disk

After a file migrates and is replaced with a stub file, the user can perform the same actions on the stub file as on any other file in the filesystem. The stub file can be moved, renamed, or have any other action applied to it that does not require read or write access.

Migration Policies

You can set the values in the Migration resource that HSM uses to determine what the client filesystem capacity should be for migration to start and stop. From the nwadmin GUI, select Migration Setup from the Clients menu. For each migration client, you determine the following:

• High water mark - specifies the percentage of disk space filled. When this value is reached, migration starts automatically.

• Low water mark - specifies the percentage of disk space filled after migration. When this value is reached, migration stops.

When the client filesystem reaches the specified high water mark, the Backup HSM application automatically migrates the files that meet the defined criteria.

In addition to the high and low water marks, you must set one or more criteria that files must meet to become candidates for migration. If you set more that one criteria, files must meet all the specified criteria to become candidates for migration. For example, you can set a policy that specifies when the client filesystem exceeds 70% full, files in the /home directory that have not been accessed in over 60 days and are at least 2 KB or larger in size are automatically migrated. You can set the following migration criteria:

• Last access time - specifies the length of time since a file was last accessed.

• Minimum file size - specifies the minimum file size to consider for migration. Files smaller than this entry do not provide enough available disk space after being replaced with a stub file to warrant migrating them.

• File owner - specifies the name of the owner of the file you want considered for migration. If you want all owners allowed, leave this text box blank. If you want all owners allowed except for owner_name, enter -owner_name in the field.

• File group - specifies the name of the group with access to the files to be migrated. If you want all groups allowed except for group_name, enter -group_name in this field.

• Preserve - specifies the files you do not want migrated. These entries must be full pathnames and may contain UNIX shell wildcard characters.

How Files Are Migrated

After you have specified migration policies for your migration client in the Migration resource, Backup migrates files in the following way:

1. When the Backup server conducts a regularly scheduled backup, it checks each client in the backup group for files that are candidates for migration. During a scheduled backup, the premigration command, nsrpmig, searches the migration client filesystem for files that meet the migration criteria.

   Premigration is a resource-intensive activity. The group containing migration clients should start its scheduled backup at a time of low system use.

2. Files that meet the migration criteria are premigrated. During premigration, the file is copied to a Backup storage location (a migration volume), but the original file remains on the client machine.

3. When the client filesystem reaches the high water mark, the nsrexecd daemon starts the migration command, nsrmig, and migration occurs automatically. The nsrmig command checks the premigrated files to ensure that they still meet the migration criteria. If the premigrated files are still candidates for migration, the nsrmig command does the following:

   • Renames the original file on the client filesystem with a temporary name.

   • Creates a stub file on the client filesystem to point to the migrated file on the migration media.

   • Deletes the original file from the client filesystem.

4. Migration continues until the low water mark is reached. If not enough files meet the migration criteria, the migration process might not meet the low water mark.

5. A migration report is emailed to the administrator.

   Backup makes entries for migrated files in the client index. These entries, however, are not visible to a user through the recovery GUI. Backup uses these entries to track the link between the migrated file and the stub file in the client filesystem as well as for recall purposes. Because a migrated file must be available for a user to recall, the index entries for migrated data are exempt from the automatic data recycling policies set for a Backup client. See "How HSM Handles Renamed or Deleted Files" for details on how Backup handles files that have been deleted from the client filesystem.

Files That Are Not Migrated

Certain files are always excluded from migration. These files include system files, shared libraries, and all executables and data files used by Backup. The following files are excluded from migration:

• All files in the /, /usr, /opt, and /var filesystems

• All files that end with .so

• All files (executables and data files) used by Backup

• Files that are larger than 2 GB

Additionally, you can choose certain files or groups of files to exclude from migration. For example, you can exclude files owned by root from automatic migration.

File Recall

When a user or application accesses a migrated file to read, write, or change attributes, Backup automatically recalls the file to the location of the stub file. After the recall starts, the file begins to open. The recall operation finishes before control return to the user program. Therefore, the user might notice a delay in reading and writing until the file is completely recalled to its original position. Other than a slower access time, however, the entire recall process is transparent to the user. Access time depends on the availability of the migration media, device speed, and network speed.

If the local hard disk has insufficient free space to recall the file, Backup issues the appropriate notifications. Backup provides preconfigured HSM notifications. See "Event Notification" for details on using notifications.

How HSM Complements Backup Operations

HSM is a complementary solution to backup, archiving, and save set staging operations. HSM allows system administrators to manage network resources more effectively, often resulting in lower cost for hardware storage. All Backup features store data on media; each one, however, has a specific purpose. Table 8-1 compares the goals of backup, HSM, save set staging, and archiving to demonstrate how these features work together to provide a complete storage management solution.

Using HSM with Network Filesystem (NFS) Clients

When Backup migrates a file, it leaves a stub file on the original client filesystem. The stub file is a UNIX symbolic link that points to the new location of the migrated file. Because the stub files that Backup creates are symbolic links, NFS (network filesystem) clients cannot premigrate or migrate files on an NFS-mounted directory.

An NFS client, however, might need to recall previously migrated files from an NFS-mounted directory. Backup allows this operation under the following configuration:

• The NFS server must be a Solaris computer running the Backup client software and have a Migration Setup configured for it.

• The NFS client must be a Solaris computer running the Backup client software and have a Migration Setup configured for it.

• Both the NFS server and the NFS client must be configured as clients to the same Backup server.

• The NFS client must have the correct user/group available and have write privileges on the NFS-mounted directory.

• The NFS server must list the NFS client as a Remote Access User in its Backup client resource.

Figure 8-1 illustrates this configuration scenario.

Figure 8-1 Configuration Scenario For NFS and Migration Clients

In this scenario, the host Oak is a Backup server with the HSM module enabled and Elm and Pine on its list of clients. The host Elm is an NFS server that has the Backup client software running on it and Migration Setup configured for it, which makes it a Backup migration client. Pine is an NFS client that receives NFS services from Elm. Pine also has the Backup client software running on it and a Migration Setup configured for it, which makes it a Backup migration client.

For Pine to recall a file that has been migrated from Elm, Pine must be listed in the Remote Access attribute in Elm's Backup client resource. The recall operation recalls the migrated file from the migration store to the location of the stub file on Elm. This operation is transparent to the user.

If an NFS client does not meet these configuration criteria, you can use the rlogin command to log on to the NFS server and recall the file by performing any read or write operation on it. The migrated file is automatically recalled to its original location.

Enabling and Registering HSM

The HSM software is an optional module that is included on the Backup server distribution media. To enable the HSM software, you must enter an enabler code into your Backup server. Refer to the Solstice Backup Installation and Release Notes for details on evaluating HSM with your existing Backup server software for 30 days.

When you purchase the HSM module, you receive an Enabler Certificate with an enabler code to enable the HSM functionality. Enabling and registering the software is a three-part process involving these steps:

1. Follow the directions listed in "Enabler Code Entry " to enter the enabler code into your Backup server.

2. Register the HSM software with SunSoft. You have 45 days to register the software with SunSoft before the software times out. After SunSoft receives your registration form, you will be sent a permanent authorization code for the HSM software.

3. Enter the authorization code into your Backup server. This code permanently enables the HSM software. See "How to Register and Authorize Your Software " for instructions to enter the authorization code on your server.

When HSM is enabled on a Backup server, all the clients of that Backup server can be configured as migration clients.

Configuring a Migration Client

After you enable HSM on a Backup server, you can configure all the clients managed by that Backup server as migration clients. To ensure that your files are migrated correctly, you should perform the following configuration tasks:

• Create a group for migration clients.

• Configure a migration pool resource for your migration data.

• Configure a migration client resource for each migration client.

Creating a Group for Migration Clients

You should create a group for your migration clients. The start time for this group determines when automatic premigration activities take place. When Backup backs up a group containing migration clients and save sets, premigration occurs for qualifying files. Premigration happens automatically and is not controlled by high and low water marks. For automatic premigration to occur, Backup requires that files be premigrated as part of a group.

Since premigration is a resource-intensive process, you should designate a start time for the group when other system demands are low. See "Backup Group Configuration " for details about how to configure Backup groups.

How to Configure a Migration Pool Resource

Migrated files are written to a migration-type pool. A migration-type pool differs from both a backup-type pool and an archive-type pool. Because each of the pool types writes data in a different format, you cannot mix backup data and migration or archive data within the same pool. When HSM is enabled on the Backup server, two additional pool resources are available: Migration and Migration Clone. Use these two pool resources and their corresponding label templates for your migration data. Depending on your needs, you can create several migration pool resources for your migration clients. From the nwadmin GUI:

1. Select Pools from the Media menu to open the Pools resource.

2. Select the Migration pool or create a new pool resource and designate its Type attribute as "Migration."

3. Select the migration group you created for your migration clients.

4. Apply your settings.

   During the migration group's scheduled backup, data that qualifies for premigration is written to this migration pool. If you have auto media management enabled or are using an autochanger, Backup mounts a labeled volume from this pool automatically.

How to Configure a Migration Client Resource

Use the Migration Client resource for individual migration clients, for each filesystem on a migration client or for a combination of the two.

You must have a Client or Client/save set combination resource configured for each client or filesystem you want to receive migration services before you can set up a Migration Client resource. See "How to Create a New Client" and "Use of Unique Client/Save Set Combinations " for more information.

1. Ensure that the computer you want to receive migration services is configured as a client of the Backup server that has HSM enabled.

2. Ensure that nsrexecd is running on the client.

3. Select Migration Setup from the Clients menu to open the Migration resource.

4. Complete the fields in the Migration resource to establish your migration policies.

   See "Migration Policies" for details about the criteria you can designate for your migration clients.

   Clients and save sets meeting these criteria are available for automatic premigration. Premigration copies the file to the storage location, leaving the original on the client's local disk. When Backup backs up a group containing migration clients, premigration occurs. This happens automatically and is not controlled by high and low water marks. For automatic premigration to occur, Backup requires that files be premigrated as part of a group. When the high water mark is reached or the client filesystem is full, migration occurs; the premigrated file is deleted from the client filesystem, leaving a stub file that contains information about the migrated file.

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.