Using Data Migration, you can move the NSS data from NSS32 to NSS64 pools or volumes. The data migration is performed by migrating all the data and corresponding metadata from the source NSS32 to target NSS64 pools or volumes. This section covers data migration from NSS32 to NSS64 pools or volumes in the same tree, same server or different server, and clustered or non-clustered pools or volumes.
The data size is growing rapidly and the storage support provided by NSS32 (8 TB) pool is not sufficient. Therefore, NSS32 pool can be replaced with NSS64 (8 EB) pool to store large amount of data.
Multiple NSS32 pools can be consolidated to a single NSS64 pool due to large storage support.
Ensure the source and target volume is in the same tree.
To handle the compressed files, see Migrating Compressed Files in the OES 23.4: Migration Tool Administration Guide.
If source or target volume is DST enabled, see Data Migration for DST Volumes in the OES 23.4: Migration Tool Administration Guide.
Ensure that the source and target volume properties are same. You can obtain the pool and volume information using Section B.12, nsssettings.
If source volume is accessible by the end user during migration, ensure that the final sync (remove files from the target that no longer exist on the source, files that are renamed, or moved to a different folder) is performed before decommissioning the source volume.
Ensure to take backup of the data, although the data on the source server is not deleted as part of migration.
To retain any deleted files on the volume, salvage those files before migration.
Ensure that you allocate sufficient space for the target volume to hold all the source data.
This section provides information on how to use the Migration tool to migrate the data from NSS32 source to NSS64 target volume. For more information about Migration tool, see Overview of the Migration GUI, Using the Migration GUI Tool, and Security Considerations for Data Migration sections in the OES 23.4: Migration Tool Administration Guide.
The migration can be done in the following ways:
Create a new NSS64 pool and volume on the server or create a new volume on the existing NSS64 pool. For more information, see Section 16.2, Creating a Pool and Section 19.3, Creating Unencrypted NSS Volumes.
Launch the Migration Tool from the target server, using either of the following methods:
Desktop: Click Computer > More Applications > System > Novell Migration Tools to launch the Migration GUI.
Server Console: Log in as the root user and at a server console, enter miggui.
NOTE:If you are using putty, ensure that X forwarding is configured.
Enter authentication credentials for the source server.
(Optional) Is Cluster Resource: If you want to migrate data in a cluster environment, you can perform either of the following:
Migrating Cluster Volumes: In the Source Server Authentication screen, specify the cluster resource IP and select the Is Cluster Resource option. On configuring file system the Volume Information tab displays all cluster volumes from the cluster resource as part of the source volume.
Migrating Non Cluster Volumes from a Cluster Node: In the Source Server Authentication screen, specify the cluster node IP and do not select the Is Cluster Resource option. On configuring file system the Volume Information tab displays all non cluster volumes present on the source server.
Enter the authentication credentials for the target server.
In the Services panel, click Add and select File System.
The Status of the file system service is Not Configured.
To configure migration parameters for the file system, select File System, then click Configure.
Tabs |
Purpose |
---|---|
Identify the volumes or folders that you want to move from the selected source server to a selected target server. By default, all of the data in the volumes or folders that you select for migration in the source server tree is migrated to the target server. |
|
Customize the files and quotas that are migrating to the target server. You can also specify the home directory location and set options to synchronize the file system. |
In the Volume Information tab, in the Source Server tree, select volumes or folders that you want to migrate, then drag and drop it in the Target Server tree. The names of the source cluster volumes can only include “_” as a special character to be listed in the Source Server tree.
IMPORTANT:A DFS junction is displayed under the source tree as a folder because this junction appears in the file structure as a directory. Under Volume Information, the DFS junction can be dragged to the target server tree, but actually, the junction and the data are not migrated to the target server and migration fails. However, if you select the source volume that contains the junction for migration and dragged to the target server tree, the junction is migrated to the target server.
In the Source Server tree, you cannot expand volumes or folders that are copied to the Target Server tree.
For explanation on different tasks that can be performed in the Volume Information tab, refer to the table below, else proceed with default settings to Step 8.
Task |
Description |
---|---|
Target Location |
After you have selected volumes and folders for migration, you might want to identify the path of the folder or volume moved to the target server. In the Source Server tree, right-click the volume or folder that is selected for migration, then click Target Location from the drop-down menu. The tree in the Target Server view expands to display the volume or folder that was copied from the source server. |
Source Location |
After you have selected volumes and folders for migration, you might want to identify the path of the folder or volume moved from the source Server. In the Target Server tree, right-click the volume or folder that is highlighted for migration, then click Source Location from the drop-down menu. The tree in the Source Server view expands to display the volume or folder that was copied to the Target Server. |
Volumes or Folders selected for migration |
The volumes or folders that are selected for migration are highlighted in blue in the Source Server tree and the Target Server tree. |
Removing Volumes or Folders from the Target Server |
In the target server tree, right-click the volume or folder that you have decided not to migrate, then select Undo. The folder no longer appears under the target server tree and is no longer a candidate for migration. |
Follow Cluster Resource |
Select this option to perform uninterrupted migration when cluster resources migrate to different cluster nodes. This option is valid only on the source server clusters. For example, when a failure occurs on one node of the cluster, the resources are relocated to another node in the cluster. The migration tool connects to the cluster instead of individual server and performs uninterrupted migration during this failure. If this option is not selected, migration stops when the resource migrates to a different node. When the resource comes up on a different node, run the migration project again, the migration tool ensures that the migration process resumes from the state where it had stopped. On migrating data to cluster volume on the target server, migration stops when the resource migrates to a different node. To continue migration you must make the resource active on the target server. |
Click the File Options tab, then click OK to accept the defaults.
or
Use the options to customize the files and quotas to migrate to the target server, then click OK to save the settings.
For explanation of the different tasks that can be performed in the File Options page, refer to the Table below.
Task |
Description |
---|---|
Duplicate File Resolution |
Determines what action to take when a file copied from the source server has the same filename as an existing file on the target server. Specify one of the following resolutions:
|
Quotas |
This option is applicable only for data migration. NOTE:If you are migrating to a different file system (NSS to NCP volumes or from NSS to Linux POSIX volumes) on the target server, user quotas and directory quotas are not valid.
|
File Filters |
Determines which files to include for migration. If no filters are set, all files are migrated. You can specify the files that you want to migrate by specifying the date range or you can exclude the files from migrating by specifying the filenames or file extensions.
|
Home Directory Options |
Specify the target server path for the users whose home directory you are migrating from the source server. For example, If the users’s home directory path on the source server is /media/nss/VOL1/users and the target path where the users will be migrated is /media/nss/VOL2/users, then specify the path in the Home Directory Options as /media/nss/VOL2/users. On successful migration, the home directory of the users is updated with the new target server path. NOTE:If you are performing migration across multiple volumes, you cannot specify multiple home directory paths. |
Sync Options |
The Sync option performs synchronization of the target server with the source server. After completion of file system migration, if the source server is updated with new information, you can use the Sync option for synchronizing the servers. The Sync option is available in the main Migration GUI window. Delete Files Not On Source: During synchronization of the servers, additional files or folders on the target servers are deleted that are not available on the source server. Delete Trustees Not On Source: This option is enabled only for same tree migration. Set this option to update trustee information on target server when trustees are deleted on the source volume on completion of migration or synchronization. Trustee information that is not on the source server is deleted from the target server. Copy Trustees Only At The Directory Level: Synchronizes trustees only at the directory level. Trustees for files are not synchronized. Do Not Copy Trustees: The user rights on the source server folders are not synced to the target server. |
Login Options |
This option indicates whether you want users to be logged in during the data migration. Disable Login On Source: If you disable user login, the users cannot log in to the network and modify the open files during the file copy. Users already logged in to the source server are not logged out, but no new logins are allowed until the migration completes. |
After you have finished configuring the parameters in each tab, click OK to save your file system migration setup and return to the main Migration window.
Click Migrate on the main migration window to begin the migration.
On successful migration, you are ready to perform synchronization for any new or modified files or trustee rights.
Launch the Migration Tool on the target server.
Open the migration project that you need to perform synchronization.
The status of the file system is "Migrated on <Date and Time of successful migration>".
Authenticate the source server and target server.
(Conditional) You can modify only few options for file system. In the Services to Migrate panel, select File System, then click Configure. In the File system GUI, File Options tab only the Duplicate File Resolution, Login Options, and Sync Options are enabled and can be modified.
In the main Migration Tool GUI, click Sync.
All the new or modified files or trustee rights on the source server are migrated to the target server.
The following log files are created during the file system migration:
filesystem.log: Stores the information about the command sequence and errors encountered during the migration.
filesystem.success.log: Stores the list of successfully migrated files.
filesystem.delete.log: While performing sync, stores the list of deleted files from the target server, which are not available on the source server.
NOTE:This log file is updated with the list of deleted files only if you select Delete Files Not On Source option in the File Options tab.
The log files are available under the migration project location. For more information on migration logs, see View Logs in the OES 23.4: Migration Tool Administration Guide.
The source data can be migrated to an existing NSS64 volume either by migrating to a directory on target volume or merge with the already existing data on the root of target volume. This can be done in the following ways:
In the Volume Information tab, in the Source Server tree, select volumes or folders that you want to migrate, then drag and drop it in the Target Server tree. The Volume Drop Options dialog-box is displayed. Select Create a new directory with the name of volume option under Volume dragged action and then click OK.
The names of the source cluster volumes can only include “_” as a special character to be listed in the Source Server tree.
IMPORTANT:A DFS junction is displayed under the source tree as a folder because this junction appears in the file structure as a directory. Under Volume Information, the DFS junction can be dragged to the target server tree, but actually, the junction and the data are not migrated to the target server and migration fails. However, if you select the source volume that contains the junction for migration and dragged to the target server tree, the junction is migrated to the target server.
In the Source Server tree, you cannot expand volumes or folders that are copied to the Target Server tree.
For explanation on different tasks that can be performed in the Volume Information tab, refer to the table below, else proceed with default settings to Step 3.
Task |
Description |
---|---|
Target Location |
After you have selected volumes and folders for migration, you might want to identify the path of the folder or volume moved to the target server. In the Source Server tree, right-click the volume or folder that is selected for migration, then click Target Location from the drop-down menu. The tree in the Target Server view expands to display the volume or folder that was copied from the source server. |
Source Location |
After you have selected volumes and folders for migration, you might want to identify the path of the folder or volume moved from the source Server. In the Target Server tree, right-click the volume or folder that is highlighted for migration, then click Source Location from the drop-down menu. The tree in the Source Server view expands to display the volume or folder that was copied to the Target Server. |
Volumes or Folders selected for migration |
The volumes or folders that are selected for migration are highlighted in blue in the Source Server tree and the Target Server tree. |
Removing Volumes or Folders from the Target Server |
In the target server tree, right-click the volume or folder that you have decided not to migrate, then select Undo. The folder no longer appears under the target server tree and is no longer a candidate for migration. |
Follow Cluster Resource |
Select this option to perform uninterrupted migration when cluster resources migrate to different cluster nodes. This option is valid only on the source server clusters. For example, when a failure occurs on one node of the cluster, the resources are relocated to another node in the cluster. The migration tool connects to the cluster instead of individual server and performs uninterrupted migration during this failure. If this option is not selected, migration stops when the resource migrates to a different node. When the resource comes up on a different node, run the migration project again, the migration tool ensures that the migration process resumes from the state where it had stopped. On migrating data to cluster volume on the target server, migration stops when the resource migrates to a different node. To continue migration you must make the resource active on the target server. |
After the data migration, the miggui tool does not restore the user quota values that are set on source volume, because the target is not a volume. You can migrate the user quota using metamig utility. For more information, see Section B.3, metamig.
IMPORTANT:Ensure to backup the target volume’s metadata using metamig utility.
The metamig utility takes the backup of source and then restores on target as follows:
If both the source and target volume has quota set for the same user (user1.wpg.idc.microfocus), the quota for user1.wpg.idc.microfocus on target volume is overwritten with the source volume.
If user quota is set for user2.smg.idc.microfocus on source volume but not on the target volume, then metamig adds the quota restriction for user2.smg.idc.microfocus on the target volume.
If user quota is set for user3.wpg.idc.microfocus on target volume but not on the source volume, then the quota value is retained for user3.wpg.idc.microfocus on the target volume.
For example, the source volume contains two users, user1.wpg.idc.microfocus and user2.smg.idc.microfocus with user quota 5 GB and 3 GB respectively. The target volume also contains two users, user1.wpg.idc.microfocus and user3.wpg.idc.microfocus with user quota 2 GB and 3 GB respectively. After migration, the target volume contains three users: user1.wpg.idc.microfocus, user2.smg.idc.microfocus, and user3.wpg.idc.microfocus with user quota 5 GB, 3 GB and 3 GB respectively.
The source volume rights are migrated to the directory with the source volume name in the target location.
On successful migration, you are ready to perform synchronization for any new or modified files or trustee rights.
Launch the Migration Tool on the target server.
Open the migration project that you need to perform synchronization.
The status of the file system is "Migrated on <Date and Time of successful migration>".
Authenticate the source server and target server.
(Conditional) You can modify only few options for file system. In the Services to Migrate panel, select File System, then click Configure. In the File system GUI, File Options tab only the Duplicate File Resolution, Login Options, and Sync Options are enabled and can be modified.
In the main Migration Tool GUI, click Sync.
All the new or modified files or trustee rights on the source server are migrated to the target server.
The following log files are created during the file system migration:
filesystem.log: Stores the information about the command sequence and errors encountered during the migration.
filesystem.success.log: Stores the list of successfully migrated files.
filesystem.delete.log: While performing sync, stores the list of deleted files from the target server, which are not available on the source server.
NOTE:This log file is updated with the list of deleted files only if you select Delete Files Not On Source option in the File Options tab.
The log files are available under the migration project location. For more information on migration logs, see View Logs in the OES 23.4: Migration Tool Administration Guide.
Before copying the source data at the root of the NSS64 target volume, ensure to meet the following:
Backup the existing target volume.
Consider a scenario, where the files and folders with the same name might exist on both the source and target volume, and the access rights (trustees or trustee rights) are different on source and the target volume. On migrating a source volume to an existing target volume, there are access rights (trustees or trustee rights) set on the target volume that can be inherited by the files or folders that are migrated from the source. Before you allow other users to access the migrated data in the new location, you need to modify the settings as required, so that the files are available only to authorized users.
As source data is going to merge with the existing data, take care of the following:
Duplicate Files: miggui provides options to handle the duplicate files.
User Quotas and Trustee Rights: The user quotas are handled as follows:
If both the source and target volume has quota set for the same user (user1.wpg.idc.microfocus), the quota for user1.wpg.idc.microfocus on target volume is overwritten with the source volume.
If user quota is set for user2.smg.idc.microfocus on source volume but not on the target volume, then the quota restriction is added for user2.smg.idc.microfocus on the target volume.
If user quota is set for user3.wpg.idc.microfocus on target volume but not on the source volume, then the quota value is retained for user3.wpg.idc.microfocus on the target volume.
For example, the source volume contains two users, user1.wpg.idc.microfocus and user2.smg.idc.microfocus with user quota 5 GB and 3 GB respectively. The target volume also contains two users, user1.wpg.idc.microfocus and user3.wpg.idc.microfocus with user quota 2 GB and 3 GB respectively. After migration, the target volume contains three users: user1.wpg.idc.microfocus, user2.smg.idc.microfocus, and user3.wpg.idc.microfocus with user quota 5 GB, 3 GB and 3 GB respectively.
Similarly, the trustee rights are also handled.
Attributes, IRF, Owner, and Directory Quota: In case of duplicates files or directories, all these metadata are overwritten with the source.
For example, the source volume contains file (test) with attributes sd, di, aa; and the target volume contains the same file (test) with attributes sd, ri, aa. After migration, the target volume is replaced with the source volume file with attributes sd, di, aa.
This section includes the following:
In the Volume Information tab, in the Source Server tree, select volumes or folders that you want to migrate, then drag and drop it in the Target Server tree. The Volume Drop Options dialog-box is displayed. Select Copy the volume contents into the directory or volume option under Volume dragged action and click OK.
The names of the source cluster volumes can only include “_” as a special character to be listed in the Source Server tree.
IMPORTANT:A DFS junction is displayed under the source tree as a folder because this junction appears in the file structure as a directory. Under Volume Information, the DFS junction can be dragged to the target server tree, but actually, the junction and the data are not migrated to the target server and migration fails. However, if you select the source volume that contains the junction for migration and dragged to the target server tree, the junction is migrated to the target server.
In the Source Server tree, you cannot expand volumes or folders that are copied to the Target Server tree.
For explanation on different tasks that can be performed in the Volume Information tab, refer to the table below, else proceed with default settings to Step 3.
Task |
Description |
---|---|
Target Location |
After you have selected volumes and folders for migration, you might want to identify the path of the folder or volume moved to the target server. In the Source Server tree, right-click the volume or folder that is selected for migration, then click Target Location from the drop-down menu. The tree in the Target Server view expands to display the volume or folder that was copied from the source server. |
Source Location |
After you have selected volumes and folders for migration, you might want to identify the path of the folder or volume moved from the source Server. In the Target Server tree, right-click the volume or folder that is highlighted for migration, then click Source Location from the drop-down menu. The tree in the Source Server view expands to display the volume or folder that was copied to the Target Server. |
Volumes or Folders selected for migration |
The volumes or folders that are selected for migration are highlighted in blue in the Source Server tree and the Target Server tree. |
Removing Volumes or Folders from the Target Server |
In the target server tree, right-click the volume or folder that you have decided not to migrate, then select Undo. The folder no longer appears under the target server tree and is no longer a candidate for migration. |
Follow Cluster Resource |
Select this option to perform uninterrupted migration when cluster resources migrate to different cluster nodes. This option is valid only on the source server clusters. For example, when a failure occurs on one node of the cluster, the resources are relocated to another node in the cluster. The migration tool connects to the cluster instead of individual server and performs uninterrupted migration during this failure. If this option is not selected, migration stops when the resource migrates to a different node. When the resource comes up on a different node, run the migration project again, the migration tool ensures that the migration process resumes from the state where it had stopped. On migrating data to cluster volume on the target server, migration stops when the resource migrates to a different node. To continue migration you must make the resource active on the target server. |
On successful migration, you are ready to perform synchronization for any new or modified files or trustee rights.
Launch the Migration Tool on the target server.
Open the migration project that you need to perform synchronization.
The status of the file system is "Migrated on <Date and Time of successful migration>".
Authenticate the source server and target server.
(Conditional) You can modify only few options for file system. In the Services to Migrate panel, select File System, then click Configure. In the File system GUI, File Options tab only the Duplicate File Resolution, Login Options, and Sync Options are enabled and can be modified.
In the main Migration Tool GUI, click Sync.
All the new or modified files or trustee rights on the source server are migrated to the target server.
The following log files are created during the file system migration:
filesystem.log: Stores the information about the command sequence and errors encountered during the migration.
filesystem.success.log: Stores the list of successfully migrated files.
filesystem.delete.log: While performing sync, stores the list of deleted files from the target server, which are not available on the source server.
NOTE:This log file is updated with the list of deleted files only if you select Delete Files Not On Source option in the File Options tab.
The log files are available under the migration project location. For more information on migration logs, see View Logs in the OES 23.4: Migration Tool Administration Guide.
This section provides information on how to use the migfiles command line utility to migrate the data from NSS32 source to NSS64 target volume. For more information about migfiles utility, see migfiles and Security Considerations for Data Migration in the OES 23.4: Migration Tool Administration Guide.
The migration can be done in the following ways:
This section includes the following:
Create a new NSS64 pool and volume on the server or create a new volume on the existing NSS64 pool. For more information, see Section 16.2, Creating a Pool and Section 19.3, Creating Unencrypted NSS Volumes.
Verify the input using --precheck option.
For example,
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj13/fs/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj13/fs/targetpaths.in" --precheck --progress --progress-interval 1 --source-ldap-port 636 --delete-file-on-restore-error
It prompts for username and password. Enter the admin, root username and password.
Migrate the data using migfiles utility.
For example,
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj13/fs0/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj13/fs0/targetpaths.in" --progress --progress-interval 1 --source-ldap-port 636 --delete-file-on-restore-error 2>&1 | tee /root/migration.log
sourcepaths.in: Contains the source volume mount path. For example, /media/nss/SVOL
targetpaths.in: Contains the target volume mount path of a new volume. For example, /media/nss/TVOL
--source-server: Specifies the source server IP address.
/root/migration.log: Specifies the log path for migration output. You can provide any name and location of your choice.
For information on other options of migfiles command utility, see migfiles in the OES 23.4: Migration Tool Administration Guide.
NOTE:It is better to use miggui utility for data migration as it provides proper logging and monitoring.
To sync the data between the source and the target volume, run the following:
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj1/fs/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj1/fs/targetpaths.in" --progress --progress-interval 1 --source-ldap-port 636 --sync "09-12-2016 05:07:37" --delete-file-on-restore-error 2>&1 | tee /root/migration.log
--sync "09-12-2016 05:07:37": Synchronizes source volume and target volume. When you perform data sync for the 1st time, "09-12-2016 05:07:37" indicates the date and time when the data migration is started. For the 2nd time sync, "09-12-2016 05:07:37" indicates the previous data sync end date and time.
You can use --delete-existing-trustees and --delete options to delete the files or trustees that does not exist on the source. For information on other options, see migfiles in the OES 23.4: Migration Tool Administration Guide.
The migfiles command output is available in the log file mentioned in Step 3 and Data Synchronization.
The source data can be migrated to existing NSS64 volume either by migrating to a directory on target volume or merge with the already existing data on the root of target volume. This can be done in the following ways:
This section includes the following:
Create a directory with the source volume name in the existing NSS64 volume.
Verify the input using --precheck option.
For example,
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj13/fs/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj13/fs/targetpaths.in" --precheck --progress --progress-interval 1 --source-ldap-port 636 --delete-file-on-restore-error
It prompts for username and password. Enter the admin, root username and password.
Migrate the data using migfiles utility.
For example,
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj13/fs0/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj13/fs0/targetpaths.in" --progress --progress-interval 1 --source-ldap-port 636 --delete-file-on-restore-error 2>&1 | tee /root/migration.log
sourcepaths.in: Contains the source volume mount path. For example, /media/nss/SVOL
targetpaths.in: Contains the target volume mount path of a new volume. For example, /media/nss/TVOL/SVOL
--source-server: Specifies the source server IP address.
/root/migration.log: Specifies the log path for migration output. You can provide any name and location of your choice.
For information on other options of migfiles command utility, see migfiles in the OES 23.4: Migration Tool Administration Guide.
NOTE:It is better to use miggui utility for data migration as it provides proper logging and monitoring.
After the data migration, the migfiles utility does not restore the user quota values that are set on source volume, because the target is not a volume. You can migrate the user quota using metamig utility. For more information, see Section B.3, metamig.
IMPORTANT:Ensure to backup the target volume’s metadata using metamig utility.
The metamig utility takes the backup of source and then restores on target as follows:
If both the source and target volume has quota set for the same user (user1.wpg.idc.microfocus), the quota for user1.wpg.idc.microfocus on target volume is overwritten with the source volume.
If user quota is set for user2.smg.idc.microfocus on source volume but not on the target volume, then metamig adds the quota restriction for user2.smg.idc.microfocus on the target volume.
If user quota is set for user3.wpg.idc.microfocus on target volume but not on the source volume, then the quota value is retained for user3.wpg.idc.microfocus on the target volume.
For example, the source volume contains two users, user1.wpg.idc.microfocus and user2.smg.idc.microfocus with user quota 5 GB and 3 GB respectively. The target volume also contains two users, user1.wpg.idc.microfocus and user3.wpg.idc.microfocus with user quota 2 GB and 3 GB respectively. After migration, the target volume contains three users: user1.wpg.idc.microfocus, user2.smg.idc.microfocus, and user3.wpg.idc.microfocus with user quota 5 GB, 3 GB and 3 GB respectively.
The source volume rights are migrated to the directory with the source volume name in the target location.
To sync the data between the source and the target volume, run the following:
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj1/fs/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj1/fs/targetpaths.in" --progress --progress-interval 1 --source-ldap-port 636 --sync "09-12-2016 05:07:37" --delete-file-on-restore-error 2>&1 | tee /root/migration.log
--sync "09-12-2016 05:07:37": Synchronizes source volume and target volume. When you perform data sync for the 1st time, "09-12-2016 05:07:37" indicates the date and time when the data migration is started. For the 2nd time sync, "09-12-2016 05:07:37" indicates the previous data sync end date and time.
You can use --delete-existing-trustees and --delete options to delete the files or trustees that does not exist on the source. For information on other options, see migfiles in the OES 23.4: Migration Tool Administration Guide.
The migfiles command output is available in the log file mentioned in Step 3 and Data Synchronization.
Before copying the source data at the root of the NSS64 target volume, ensure to meet the following:
Backup the existing target volume.
Consider a scenario, where the files and folders with the same name might exist on both the source and target volume, and the access rights (trustees or trustee rights) are different on the source and target volume. On migrating a source volume to an existing target volume, there are access rights (trustees or trustee rights) set on the target volume that can be inherited by the files or folders that are migrated from the source. Before you allow other users to access the migrated data in the new location, you need to modify the settings as required, so that the files are available only to authorized users.
As source data is going to merge with the existing data, take care of the following:
Duplicate Files: migfiles provides options to handle the duplicate files.
User Quotas and Trustee Rights: The user quotas are handled as follows:
If both the source and target volume has quota set for the same user (user1.wpg.idc.microfocus), the quota for user1.wpg.idc.microfocus on target volume is overwritten with the source volume.
If user quota is set for user2.smg.idc.microfocus on source volume but not on the target volume, then the quota restriction is added for user2.smg.idc.microfocus on the target volume.
If user quota is set for user3.wpg.idc.microfocus on target volume but not on the source volume, then the quota value is retained for user3.wpg.idc.microfocus on the target volume.
For example, the source volume contains two users, user1.wpg.idc.microfocus and user2.smg.idc.microfocus with user quota 5 GB and 3 GB respectively. The target volume also contains two users, user1.wpg.idc.microfocus and user3.wpg.idc.microfocus with user quota 2 GB and 3 GB respectively. After migration, the target volume contains three users: user1.wpg.idc.microfocus, user2.smg.idc.microfocus, and user3.wpg.idc.microfocus with user quota 5 GB, 3 GB and 3 GB respectively.
Similarly, the trustee rights are also handled.
Attributes, IRF, Owner, and Directory Quota: In case of duplicates files or directories, all these metadata are overwritten with the source.
For example, the source volume contains file (test) with attributes sd, di, aa; and the target volume contains the same file (test) with attributes sd, ri, aa. After migration, the target volume is replaced with the source volume file with attributes sd, di, aa.
This section includes the following:
Verify the input using --precheck option.
For example,
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj13/fs/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj13/fs/targetpaths.in" --precheck --progress --progress-interval 1 --source-ldap-port 636 --delete-file-on-restore-error
It prompts for username and password. Enter the admin, root username and password.
Migrate the data using migfiles utility.
For example,
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj13/fs0/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj13/fs0/targetpaths.in" --progress --progress-interval 1 --source-ldap-port 636 --delete-file-on-restore-error 2>&1 | tee /root/migration.log
sourcepaths.in: Contains the source volume mount path. For example, /media/nss/SVOL
targetpaths.in: Contains the target volume mount path of a new volume. For example, /media/nss/TVOL
--source-server: Specifies the source server IP address.
/root/migration.log: Specifies the log path for migration output. You can provide any name and location of your choice.
NOTE:In case of duplicate files, you can use --never-overwrite and --update-ifnewer options to take specific action on duplicate files during migration.
To sync the data between the source and the target volume, run the following:
/opt/novell/migration/sbin/migfiles --source-server 192.168.1.10 --verbose --source-full-path "@/var/opt/novell/migration/NewProj1/fs/sourcepaths.in" --destination-full-path "@/var/opt/novell/migration/NewProj1/fs/targetpaths.in" --progress --progress-interval 1 --source-ldap-port 636 --sync "09-12-2016 05:07:37" --delete-file-on-restore-error 2>&1 | tee /root/migration.log
--sync "09-12-2016 05:07:37": Synchronizes source volume and target volume. When you perform data sync for the 1st time, "09-12-2016 05:07:37" indicates the date and time when the data migration is started. For the 2nd time sync, "09-12-2016 05:07:37" indicates the previous data sync end date and time.
You can use --delete-existing-trustees and --delete options to delete the files or trustees that does not exist on the source. For information on other options, see migfiles in the OES 23.4: Migration Tool Administration Guide.
The migfiles command output is available in the log file mentioned in Step 2 and Data Synchronization.
Distributed File Services (DFS) for the OES Storage Services (NSS) file system provides location transparency of file data to end users. With DFS, you can create a single virtual file system for data on NSS volumes that spans multiple machines to maximize the use and performance of storage resources.
The DFS Move operation can be used to migrate the data to a new volume. For more information about DFS, see OES 23.4: Distributed File Services Administration Guide for Linux.
This section includes the following:
For information about migrating data to newly created NSS64 volume, see Using DFS to Move NSS Volumes in the OES 23.4: Distributed File Services Administration Guide for Linux.
IMPORTANT:After successful completion of DFS Move operation, the source volume can be deleted and moved to Salvage sub-system or permanently deleted. This can be managed by configuring the server’s ImmediatePurgeOfDeletedFiles and Purge Delay settings. For more information, see Moving an NSS Volume with DFS in the OES 23.4: Distributed File Services Administration Guide for Linux.
DFS does not provide any options to synchronize the data. Ensure that the files are not in use, when DFS Move job is running. For more information about job status, see Understanding the Job Status Report in the OES 23.4: Distributed File Services Administration Guide for Linux.
For information about DFS log, see Managing Move Volume or Split Volume Jobs in the OES 23.4: Distributed File Services Administration Guide for Linux.
NOTE:DFS does not support migrating data to an existing NSS volume.
Dynamic Storage Technology (DST) for Open Enterprise Server (OES) is an information life-cycle management technology. It makes your essential data readily available to the eDirectory and Active Directory users, while tiering files efficiently across a pair of independent NSS volumes, referred to as a DST shadow volume. You create policies to control how the files are distributed between the two volumes.
The two NSS volumes reside on different devices on the same server. The primary volume typically contains active or highly critical files, while the secondary volume contains files that are accessed less often. When users connect to a network share on the primary NSS volume, they see a merged view of files on both volumes. Users are not aware of where the files physically reside. Files on both volumes are equally accessible to users. DST pulls data directly to the user from the primary volume or the secondary volume, depending on where the file is located.
For more information about DST, see the following:
The data can be migrated from NSS32 to NSS64 volume in two ways: First, the DST pair can be created by using the existing NSS32 source as primary volume and new NSS64 target as secondary volume. Second, the new NSS64 target as primary volume and the existing NSS32 source as secondary volume. The DST policies can be configured to move the data from primary to secondary volume or secondary to primary volume. For more information, see Shadowing Scenarios in the OES 23.4: Dynamic Storage Technology Administration Guide.
IMPORTANT:If a file is hard link enabled, and it is moved between the primary and the secondary volume, the move actually copies the file and breaks the hard link. It creates an additional version of the file that is not linked to an other file.
The data migration from NSS32 volume to NSS64 volume using DST can be done only in the following way:
NOTE:DST does not support migrating data to an existing NSS volume.
The source data can be migrated to newly created NSS64 volume in the following ways:
This section includes the following:
Create a new NSS64 pool and volume on the server or create a new volume on an existing NSS64 pool.
Create a DST pair for the above mentioned volumes.
Non-Clustered: For information about creating an unshared DST shadow volumes, see Creating a DST Shadow Volume with NSS Volumes in the OES 23.4: Dynamic Storage Technology Administration Guide.
Clustered: For information about using shared NSS volumes to create a shared DST shadow volume in a cluster environment, see Configuring DST Shadow Volume Pairs with OES Cluster Services in the OES 23.4: Dynamic Storage Technology Administration Guide.
Create a policy to move the data from primary NSS32 volume to secondary NSS64 volume. For more information about policy settings, see Creating a Shadow Volume Policy in the OES 23.4: Dynamic Storage Technology Administration Guide.
Migrate the data using the policy created in Step 3.
Remove the shadow relationship after the data is successfully migrated.
Non-Clustered: For more information, see Removing the Shadow Relationship for a Non-Clustered DST Shadow Volume in the OES 23.4: Dynamic Storage Technology Administration Guide.
Clustered: For more information, see Removing the Shadow Relationship for a Clustered DST Volume Pair in the OES 23.4: Dynamic Storage Technology Administration Guide.
DST does not provide any options to synchronize the data. Ensure that the files are not in use, when policy is running. When DST enforce the policies or move files, the relocation request fails if any user has opened the file. Only, those files that are not in use will be moved. The policy should be run one more time to copy the files that were missed during the first attempt.
To view the log information, see the following:
This section includes the following:
Create a new NSS64 pool and volume on the server or create a new volume on an existing NSS64 pool.
Synchronize the quota settings.
When the secondary volume contains the data, the existing trustees are overwritten when the trustees database is synchronized from the new primary volume. There is no automatic way to synchronize the setting from the secondary volume to the primary volume. The ncpcon quotas command does not synchronize quotas settings from secondary to primary. To copy the trustee settings, user quota and directory quota settings, see Getting Quotas from an Old Secondary Volume to a New Primary Volume in the OES 23.4: Dynamic Storage Technology Administration Guide.
Create a DST pair for the above mentioned volumes.
Non-Clustered: For information about creating an unshared DST shadow volumes, see Creating a DST Shadow Volume with NSS Volumes in the OES 23.4: Dynamic Storage Technology Administration Guide.
Clustered: For information about using shared NSS volumes to create a shared DST shadow volume in a cluster environment, see Configuring DST Shadow Volume Pairs with OES Cluster Services in the OES 23.4: Dynamic Storage Technology Administration Guide.
Replicate the file tree structure from secondary to primary volume.
For more information, see Replicating the Secondary File Tree Structure to the Primary Volume in the OES 23.4: Dynamic Storage Technology Administration Guide.
Create a policy to move the data from secondary NSS32 volume to primary NSS64 volume. For more information about policy settings, see Creating a Shadow Volume Policy in the OES 23.4: Dynamic Storage Technology Administration Guide.
Migrate the data using the policy created in Step 5.
Remove the shadow relationship after the data is successfully migrated.
Non-Clustered: For more information, see Removing the Shadow Relationship for a Non-Clustered DST Shadow Volume in the OES 23.4: Dynamic Storage Technology Administration Guide.
Clustered: For more information, see Removing the Shadow Relationship for a Clustered DST Volume Pair in the OES 23.4: Dynamic Storage Technology Administration Guide.
DST does not provide any options to synchronize the data. Ensure that the files are not in use, when policy is running. When DST enforce the policies or move files, the relocation request fails if any user has opened the file. Only, those files that are not in use will be moved. The policy should be run one more time to copy the files that are missed during the first attempt.
To view the log information, see the following links:
Using rsync command line utility, the data can be migrated with the support of extended attributes. For more information about the rsync utility, see rsync.
The data migration using rsync utility can be done in the following ways:
This section includes the following:
Create a NSS64 pool and volume on the target server or create a new volume on an existing NSS64 pool.
For more information about creating a NSS64 pool and volume, see Section 16.2, Creating a Pool and Section 19.3, Creating Unencrypted NSS Volumes.
Enable extended attributes (XAttr) extension for NSS to allow you to read, backup, and restore extended attributes of files on NSS.
For example, to enable the return of netware.metadata information, enter the following in the NSS console:
nss /ListXattrNWmetadata
For more information, see Section A.12, Extended Attributes (XAttr) Commands.
NOTE:If the source and target volume are on the different servers, execute this step on both the servers.
IMPORTANT:Using -X option will have huge impact on overall achievable throughput. Therefore, it is better to use rsync without -X option and use metamig utility to transfer the trustees and quotas.
Run the following command on target server to migrate the data.
If both the source volume and target volume are on the same server:
rsync -v -r -h -lXHtS /media/nss/<Source_Volume>/ /media/nss/<Target_Volume>/ --stats --log-file=<logfile_path>
If the source volume and target volume are on the different servers:
rsync -v -r -h -lXHtS root@<Source_Server_IP or Cluster_Resource_IP>:/media/nss/<Source_Volume>/ /media/nss/<Target_Volume>/ --stats --log-file=<logfile_path>
For example,
If both the source volume and target volume are on the same server:
rsync -v -r -h -lXHtS /media/nss/TEST1/ /media/nss/TEST2/ --stats --log-file=/var/opt/novell/log/rsync
If the source volume and target volume are on the different servers:
rsync -v -r -h -lXHtS root@192.168.1.10:/media/nss/TEST1/ /media/nss/TEST2/ --stats --log-file=/var/opt/novell/log/rsync
NOTE:rsync utility has multiple options for file transfer. For information on other options, see rsync.
Use the same command provided in Step 3 to sync the data between the source and target volume. By default, it overwrites the data on the target volume with the source data. You can use --update or --ignore-existing options to modify this behavior.
The rsync command output is available in the log file provided in Step 3.
The source data can be migrated to existing NSS64 volume either by migrating to a directory on target volume or merge with the already existing data on the root of target volume. This can be done in the following ways:
This section includes the following:
IMPORTANT:Ensure to backup the target volume’s metadata using metamig utility.
Create a directory with the source volume name in the existing NSS64 volume.
Enable extended attributes (XAttr) extension for NSS to allow you to read, backup, and restore extended attributes of files on NSS.
For example, to enable the return of netware.metadata information, enter the following in the NSS console:
nss /ListXattrNWmetadata
For more information, see Section A.12, Extended Attributes (XAttr) Commands.
NOTE:If the source and target volume are on the different servers, execute this step on both the servers.
IMPORTANT:Using -X option will have huge impact on overall achievable throughput. Therefore, it is better to use rsync without -X option and use metamig utility to transfer the trustees and quotas.
Run the following command on target server to migrate the data.
If both the source volume and target volume are on the same server:
rsync -v -r -h -lXHtS /media/nss/<Source_Volume>/ /media/nss/<Target_Volume>/<Directory_with_Source_Volume_Name>/ --stats --log-file=<logfile_path>
If the source volume and target volume are on the different servers:
rsync -v -r -h -lXHtS root@<Source_Server_IP or Cluster_Resource_IP>:/media/nss/<Source_Volume>/ /media/nss/<Target_Volume>/<Directory_with_Source_Volume_Name>/ --stats --log-file=<logfile_path>
For example,
If both the source volume and target volume are on the same server:
rsync -v -r -h -lXHtS /media/nss/TEST1/ /media/nss/TEST2/TEST1/ --stats --log-file=/var/opt/novell/log/rsync
If the source volume and target volume are on the different servers:
rsync -v -r -h -lXHtS root@192.168.1.10:/media/nss/TEST1/ /media/nss/TEST2/TEST1/ --stats --log-file=/var/opt/novell/log/rsync
After the data migration, the user quota of source volume is merged with the target volume as follows:
If both the source and target volume has quota set for the same user (user1.wpg.idc.microfocus), the quota for user1.wpg.idc.microfocus on target volume is overwritten with the source volume.
If user quota is set for user2.smg.idc.microfocus on source volume but not on the target volume, then the quota restriction is added for user2.smg.idc.microfocus on the target volume.
If user quota is set for user3.wpg.idc.microfocus on target volume but not on the source volume, then the quota value is retained for user3.wpg.idc.microfocus on the target volume.
For example, the source volume contains two users, user1.wpg.idc.microfocus and user2.smg.idc.microfocus with user quota 5 GB and 3 GB respectively. The target volume also contains two users, user1.wpg.idc.microfocus and user3.wpg.idc.microfocus with user quota 2 GB and 3 GB respectively. After migration, the target volume contains three users: user1.wpg.idc.microfocus, user2.smg.idc.microfocus, and user3.wpg.idc.microfocus with user quota 5 GB, 3 GB and 3 GB respectively.
Use the same command provided in Step 3 to sync the data between the source and target volume. By default, it overwrites the data on the target volume with the source data. You can use --update or --ignore-existing options to modify this behavior.
The rsync command output is available in the log file provided in Step 3.
Before copying the source data at the root of the NSS64 target volume, ensure to meet the following:
Backup the existing target volume.
Consider a scenario, where the files and folders with the same name might exist on both the source and target volume, and the access rights (trustees or trustee rights) are different on source and the target volume. On migrating a source volume to an existing target volume, there are access rights (trustees or trustee rights) set on the target volume that can be inherited by the files or folders that are migrated from the source. Before you allow other users to access the migrated data in the new location, you need to modify the settings as required, so that the files are available only to authorized users.
As source data is going to merge with the existing data, take care of the following:
Duplicate Files: rsync provides options to handle the duplicate files.
User Quotas: Is handled as follows:
If both the source and target volume has quota set for the same user (user1.wpg.idc.microfocus), the quota for user1.wpg.idc.microfocus on target volume is overwritten with the source volume.
If user quota is set for user2.smg.idc.microfocus on source volume but not on the target volume, then the quota restriction is added for user2.smg.idc.microfocus on the target volume.
If user quota is set for user3.wpg.idc.microfocus on target volume but not on the source volume, then the quota value is retained for user3.wpg.idc.microfocus on the target volume.
For example, the source volume contains two users, user1.wpg.idc.microfocus and user2.smg.idc.microfocus with user quota 5 GB and 3 GB respectively. The target volume also contains two users, user1.wpg.idc.microfocus and user3.wpg.idc.microfocus with user quota 2 GB and 3 GB respectively. After migration, the target volume contains three users: user1.wpg.idc.microfocus, user2.smg.idc.microfocus, and user3.wpg.idc.microfocus with user quota 5 GB, 3 GB and 3 GB respectively.
Attributes, IRF, Owner, Directory Quota, and Trustee Rights: In case of duplicates files or directories, all these metadata are overwritten with the source.
For example, the source volume contains file (test) with attributes sd, di, aa; and the target volume contains the same file (test) with attributes sd, ri, aa. After migration, the target volume is replaced with the source volume file with attributes sd, di, aa.
This section includes the following:
Enable extended attributes (XAttr) extension for NSS to allow you to read, backup, and restore extended attributes of files on NSS.
For example, to enable the return of netware.metadata information, enter the following in the NSS console:
nss /ListXattrNWmetadata
For more information, see Section A.12, Extended Attributes (XAttr) Commands.
NOTE:If the source and target volume are on the different servers, execute this step on both the servers.
IMPORTANT:Using -X option will have huge impact on overall achievable throughput. Therefore, it is better to use rsync without -X option and use metamig utility to transfer the trustees and quotas.
Run the following command on target server to migrate the data.
If both the source volume and target volume are on the same server:
rsync -v -r -h -lXHtS /media/nss/<Source_Volume>/ /media/nss/<Target_Volume>/ --stats --log-file=<logfile_path>
If the source volume and target volume are on the different servers:
rsync -v -r -h -lXHtS root@<Source_Server_IP or Cluster_Resource_IP>:/media/nss/<Source_Volume>/ /media/nss/<Target_Volume>/ --stats --log-file=<logfile_path>
For example,
If both the source volume and target volume are on the same server:
rsync -v -r -h -lXHtS /media/nss/TEST1/ /media/nss/TEST2/ --stats --log-file=/var/opt/novell/log/rsync
If the source volume and target volume are on the different servers:
rsync -v -r -h -lXHtS root@192.168.1.10:/media/nss/TEST1/ /media/nss/TEST2/ --stats --log-file=/var/opt/novell/log/rsync
In case of duplicate files, you can use --update, --backup or --ignore-existing options. By default, it overwrites the existing file.
Use the same command provided in Step 2 to sync the data between the source and target volume. By default, it overwrites the data on the target volume with the source data. You can use --update or --ignore-existing options to modify this behavior.
The rsync command output is available in the log file provided in Step 2.