Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Data Migrator considerations

The server uses Data Migrator with the following considerations:

  • Snapshots and local migrations:If files are migrated locally (to storage attached to the same EVS), when snapshots are created on the primary file system, corresponding snapshots are automatically created on the secondary file system. This preserves snapshot protection on migrated files. Likewise, when a snapshot is deleted on the primary file system, the corresponding snapshot on the secondary file system is automatically deleted.

    When attempting to access a locally migrated file through a snapshot on primary storage, the server will look for the corresponding snapshot on secondary storage and retrieve the migrated data from that snapshot. If the secondary file system does not contain any snapshots, the file contents will be retrieved from the live file system.

  • Snapshots and remote migrations:If files are migrated to storage attached to a different server (a remote migration), when snapshots are created on the primary file system, corresponding snapshots are not created on the secondary file system.

    To preserve snapshot protection on migrated files for remote migrations, you must ensure that snapshots are taken of the storage attached to the remote server. Snapshots on the secondary file system are not managed, used, or accessed by the storage server.

    When a snapshot is accessed, and the snapshot contains a file system with a cross volume link, no special processing of the cross volume link is performed if the file in the snapshot is equivalent to the live file. If the file in the live file system has been modified since the snapshot was taken (if it differs from the file in the snapshot), attributes from the file in the snapshot are returned for getattr/lookup/readdir+ requests, but an error is returned for read requests.

  • Virtual volume:If files are migrated locally, either enhanced cross volume links or original cross volume links may be used depending on your configuration. When files are migrated to a remote server, enhanced cross volume links are always used.
    • If enhanced cross volume links are used, virtual volumes are not recreated at all on the secondary storage.
    • If original cross volume links are used, virtual volumes that are present on primary storage, will be automatically recreated on the secondary storage when the data is moved during the first scheduled run of the data migration policy.
  • Quota space tracking:Quotas are enforced only on the file system or virtual volume on which they were created. When a file is migrated through Data Migrator, however, the contents are moved from one file system to another file system or virtual volume, which may be on a remote server. Cross volume links are used to link the data from its original location to its new location. Quota tracking is different based upon the type of cross volume link being used:
    • When enhanced cross volume links are used, and files are migrated to a file system on a remote server, quotas are tracked just as if the file had remained in its original location. Quotas are tracked entirely on the local file system because file space and file count quotas are managed and calculated using local attributes. This behavior simplifies quota management but does not allow storage administrators to set up separate quotas for data based on the data's location.
    • When original cross volume links are used, and files are migrated to another file system or virtual volume on the same server/cluster, quotas on primary storage are only effective on files that have not been migrated. To track space utilization of migrated data, quotas must be manually defined on secondary storage. Quota restrictions on virtual volumes cannot be set until after the policy has been completed.
  • Backup, restore, and replication of migrated files:When backing up a migrated file, NDMP will backup the entire contents of the file by retrieving it from secondary storage. Additionally, the backed up file will be identified as having been a migrated file. In this way, if the file is restored to a file system or virtual volume that has been configured as primary storage in a data migration path, the contents of the file will automatically be restored to secondary storage, leaving a cross volume link on the primary storage. If the restore target is not part of a data migration path, the file will be restored in its entirety.

    Alternatively, the NDMP environment variable NDMP_BLUEARC_EXCLUDE_MIGRATED can be used to prevent migrated data from being backed up. This can also be useful if the effective data migration policies are configured to migrate non-critical files such as music and video files from home directories or aged data. It can also improve backup and replication time, and isolate the backup data set to include only the critical information on primary storage.

    You can back up a file system that is the target of a data migration. This is accomplished by performing backup of the primary file system, and selecting an option to back up only the files that have been migrated to the secondary file system. This functionality is controlled via the NDMP_BLUEARC_INCLUDE_ONLY_MIGRATED NDMP environmental variable, which does the opposite of the NDMP_BLUEARC_EXCLUDE_MIGRATED. See the Backup Administration Guide for more information.

    It is important to remember that Data Migrator extends the maximum available capacity of primary storage by migrating data to secondary storage. This means that the capacity of the backup solution, whether tape library or a replication target, must also support the new maximum available capacity. To maintain a reliable backup and recovery system, ensure that the capacity of the deployed backup solution is at least equal to the combined capacity of primary and secondary storage. Alternatively, use NDMP_BLUEARC_EXCLUDE_MIGRATED to isolate the backup dataset to only those files that are hosted natively on primary storage.

Replication of migrated files:If a file has been migrated from primary storage, and a replication operation attempts to copy the file, NDMP can be set to:

  • Ignore migrated files:If set to ignore, the replication operation copies only the files on the primary storage (migrated files are not copied).
  • Recreate links to migrated files:If set to recreate links, the replication operation copies only the details of the cross volume link. The cross volume link is recreated on the destination if the relevant external migration data path is in place and the migrated file is accessible.
  • Remigrate migrated files: (the default) If set to remigrate, the replication operation copies the file contents but marks the file as having been externally migrated. The destination re-migrates to secondary storage if there is an existing data migration path.

This functionality is controlled using the NDMP environment variable NDMP_BLUEARC_EXTERNAL_LINKS. See the Backup Administration Guide for more information.

  • Files with hard links:Files with hard links are migrated.
    • The first instance of a hard link matching the criteria will be migrated and stubbed. This results in all other hard links to be immediately considered as stubs so that redundant migration does not occur. The last instance of the stubbed hard link on the file system to be deleted will cause the object to be deleted on the target.
  • Migrated file access:Files that have been migrated should not be accessed directly by clients on the secondary file system. All access to migrated files should be done through the primary storage server.

 

  • Was this article helpful?