Options for restoring migrated files

Use the Restore as migrated file (restoremigstate) and Restore resident if not accessible (restorecheckstubaccess) backup-archive client options to manage how the backup-archive client restores migrated files from Tivoli® Storage Manager storage.

For files that are backed up with the backup-archive client, there is a backup copy of a resident file for every corresponding stub file. With the backup-archive client, you can restore the stub file or the resident file.

There are times when the Tivoli Storage Manager HSM pool does not contain a copy of the migrated file, as shown in the following scenario:

1. A resident file is migrated to the Tivoli Storage Manager HSM pool. A stub file remains on the volume.
2. The stub file is backed up. There is a backup copy of the stub file and a backup copy of the resident file in the Tivoli Storage Manager backup pool.
3. The stub file is deleted from the volume.
4. During reconciliation, the migration copy in the Tivoli Storage Manager HSM pool is deleted.

In this case, restoring the stub file can lead to problems because the HSM for Windows client cannot recall the migration copy of the file. If there is no migration copy in Tivoli Storage Manager HSM pool, it would be better to restore the resident file rather than restore the stub. The backup-archive client can check whether a migration copy exists before restoring a stub file. If a migration copy does not exist, the backup-archive client can automatically restore the resident file instead of the stub file.

The Restore resident if not accessible (restorecheckstubaccess) and Restore as migrated file (restoremigstate) options configure how migrated files are restored by the backup-archive client. The options yield the restore results that are described in Table 1

In addition to the preceding options settings, the following conditions must also be true to restore a stub:

• The file was migrated at the time of the last backup
• The HSM for Windows client is installed
• The stub backup copy is an active version backup.
• The original file system and the target file system are of the same type (NTFS or ReFS)
• The stub is restored to the same path, and the file space name matches the volume name

There are some advantages to restoring a stub without checking that a migration copy exists in the HSM pool:

• Less temporary space is needed during restore
• There is less network traffic during a restore
• The restore is faster

There is a disadvantage to restoring a stub without checking that a migration copy exists in the HSM pool. There might be no migration copy in the HSM pool. If you restore a stub for which there is no migration copy, you create a stub file orphan. However, you can use reconciliation to report the stubs that are orphans. Then, you can restore the resident files from the backup pool with the option restoremigstate=no. If you run reconciliation in emulation mode, the HSM for Windows client creates a list of orphan stubs, but does not delete any files from Tivoli Storage Manager storage.

In the following examples, N:\file.txt was migrated, and a stub file remained on the volume. The stub file was backed up with the backup-archive client. Both the stub file and the resident file are available to the backup-archive client. The migrated file is restored by the backup-archive client with the restore command.

Task

Restore the resident file N:\file.txt.

Command: dsmc rest N:\file.txt –restoremigstate=no

Task

Restore a stub file N:\file.txt, regardless of whether a migration copy exists in Tivoli Storage Manager HSM pool.

Command: dsmc rest N:\file.txt –restoremigstate=yes –restorecheckstubaccess=no

Task

Restore a stub file N:\file.txt, if a migration copy exists in Tivoli Storage Manager HSM pool. If a migration copy does not exist in Tivoli Storage Manager HSM pool, restore the resident file.

Command: dsmc rest N:\file.txt

Because the default option values are –restoremigstate=yes and –restorecheckstubaccess=yes, it is not necessary to specify the options.