Migration to HCP Systems
The Hitachi NAS Platform supports migration of data to Hitachi Content Platform (HCP). After a file has been migrated, when a network client attempts to change the read-only attribute of a file that has been migrated to HCP, that request fails.
When Data Migrator migrates files to HCP systems, the HTTP protocol is used. Note the following:
-
The storage server only supports migration to HCP systems via HTTP without SSL security.
-
The only supported HTTP targets are HCP systems (migration to other remote servers uses the NFS protocol).
-
The storage server does not support the use of an HTTP proxy to access the remote HCP system.
Functionality exists which enables the user to specify a list of files to be migrated to HCP. This is disabled by default. To enable this functionality, contact your support provider.
If this functionality is enabled then the list of files, called a migration request file, is placed into a migration control directory (specified as part of the migration path for the file system or virtual volume). The migration control directory is periodically checked by the NAS Manager. When a migration request file is found, a migration operation is started. Upon completion, a report file is created in the migration control directory. External migration paths must be set up before the migration control file is created and put into the migration control directory.
Reclaimed space is the difference in available space between the start and completion of the migration. It is not a report of the amount of data migrated from the source file system to the target. For this information, refer to Amount Migrated.
It is likely that the file system will be in use by network clients while the migration is in progress. As a result, the reclaimed space can be substantially different than the amount migrated. The value can even be negative if files were added to the source.
Once a data migration has completed, copies of the files may be preserved on the source file system in snapshots. For the space to be fully reclaimed, all snapshots on the source file system that reference the migrated files must be deleted.
The server does include support for automatic policy-based reverse migration of files as a part of the Data Migrator feature. Aside from the policy-based reverse migration, there are two ways you can manually cause migrated files to be restored to primary storage:
-
Reverse Migration Through the server CLI. Individual files or whole directory trees can be reverse-migrated through the CLI. The files which are included in the reverse migration can be identified by pattern or by last access time. For detailed information on this process, run
man reverse-migrateat the CLI. - Reverse Migration From a Network Client. A file can be restored from a network client by performing the following sequence of operations:
-
From a Windows or Unix client, make a copy of the file (using a temporary file name) on the primary storage. This copy of the file will reside fully on primary storage.
-
Delete the original file. This will delete the link on primary storage, and the migrated data from secondary storage.
-
Rename the copied file to its original name.
-
Mounted iSCSI LUs cannot be migrated, regardless what has been defined in the data migration policy. Due to the types of applications typically hosted on iSCSI storage, Hitachi Vantara Support Center does not recommend migrating iSCSI LUs to secondary storage. However, if this is desired, it can be accomplished by performing the following:
-
Disconnect any iSCSI Initiators with connections to an LU.
-
Unmount the iSCSI LU. This can be done through the iSCSI Logical Unit Properties page.
-
Run the data migration policy to migrate the LU.
-
Re-mount the iSCSI LU.
- Reconnect the Initiator to the iSCSI Target.