Migrating Shares
  • 11 Minutes to read
  • PDF

Migrating Shares

  • PDF

Article summary

Migrate shares to the CTERA Edge Filer. The shares are created on the edge filer and the portal. The shares are not created at the root cloud folder level but at the subfolder level because ACL permissions cannot be managed at the root cloud folder level, only at the subfolder level.

Note

Before starting a migration, all non-essential features like local deduplication, antivirus, and CTERA Ransom Protect should be disabled.

Preparing the CTERA Portal to Migrate WORM Compliant Shares

When migrating a WORM compliant share, there must be a WORM Compliant Cloud Folder on the CTERA Portal for the files to be synced from the CTERA Edge Filer. This cloud folder must, therefore, be created before the migration is performed. Use the retention settings from the source file system when defining the WORM Compliance settings for the cloud folder. For details about creating a WORM Compliant cloud folder, see Folder (WORM) Compliance: CTERA Vault.

The cloud folder is specified in the migration job as the destination for the WORM compliant share from the source file system. You define a separate WORM compliant cloud folder for every WORM compliant share on the source file system and run the migration for each share, one share at a time.

When migrating a WORM compliant share together with non-WORM compliant shares, you have to run a migration job that migrates the WORM compliant share and a separate migration job that migrates the non-WORM complaint shares.

If you are migrating from Hitachi Content Platform Gateway (HCP Gateway), in the HCP Gateway Policy page note any include and exclude policies that you will specify when setting up the migration job.

Commands to Run Before and After the Migration

Before starting a migration of a WORM compliant share you must run the following command on the CTERA Portal: calculateRetentionFromCreationTime portals/ <portal_name>/cloudDrives/Users/<owner_name>/<cloudfolder_name> BACK_DATE_BIT
where:
portal_name – The name of the team portal where the WORM compliant cloud folder is defined.
owner_name – The name of the team portal admin user who owns the WORM compliant cloud folder.
cloudfolder_name – The name of the WORM compliant cloud folder.

After the migration of the WORM compliant share completes, you must run the following command on the CTERA Portal: calculateRetentionFromCreationTime portals/ <portal_name>/cloudDrives/Users/<owner_name>/<cloudfolder_name> NONE

Migration Procedure

To migrate shares to the CTERA Edge Filer:

  1. In the Configuration view, select Main > Dashboard in the navigation pane.
    The Dashboard page is displayed.
    image.png

  2. Click File Server Migration.
    The File Server Migration page is displayed.
    image.png

  3. Click + to create a new job.
    The Create Discovery Job wizard is displayed, showing the Task Type step.
    image.png
    The default job is a discovery job.

  4. Click the Migration job to change the job to migrate a file server.
    image.png

  5. Click Next.
    The Connect step is displayed.
    image.png

  6. Select the server type to connect to from the drop-down box. You can connect to one of the following:

    • Azure StorSimple
    • HCP Gateway
    • Hitachi Data Ingestor
    • Isilon OneFS
    • Microsoft Azure Files
    • Nasuni Edge Appliance
    • NetApp ONTAP
    • NetAPP StorageGRID 9 (SMB)
    • NetAPP StorageGRID 11 (SMB)
    • Panzura Freedom Filer
    • Windows Server

    Another option, Other, is available to attempt to migrate from a file server that is not listed.

  7. Select the protocol to use for the migration: SMB or NFS.
    Both NFS versions 3 and 4 are supported.
    The wizard window changes depending on the protocol selected.

    SMBNFS
    image.pngimage.png
  8. Enter the IP address or DNS name for the source file server.

  9. When Protocol is SMB, enter an administrator user name and password to access the server.

    Note

    The administrator used must have access to the files to migrate.

  10. For Microsoft Azure Files, the shares cannot be presented and have to be added manually. Expert Mode is automatically selected to enable specifying the shares in the next step.

  11. Click Next.
    The Select Shares step is displayed. For example:

    SMBNFS
    image.pngimage.png

    When migrating WORM compliant shares, select the relevant shares. You also check Migrate WORM.

    Note

    When Expert Mode is selected, the following window is displayed where you enter the shares to migrate.
    image.png

  12. Select the shares to migrate and click Next.
    The Select Options step is displayed.

    SMBNFS
    image.pngimage.png
  13. Optionally, provide a different name for the job and any specific notes about the job.

  14. You can specify patterns that you do not want to migrate, or that you do want to migrate, separating each pattern with a colon (:). You can include the asterisk (*) as a wildcard in the pattern. To specify the pattern, check the relevant box.

    • Exclude these path patterns from the migration (use the colon character (’:’) as a separator)
    • Include these path patterns in the migration (use the colon character (’:’) as a separator)

    image.png
    When the migration protocol is SMB:
    To include only WORM compliant folders in a share to migrate, and exclude all the other folders in the share:

    • If you are migrating from HCP Gateway, specify the shares to include and the shares to exclude that you noted in the HCP Gateway policy page. You also check Migrate WORM.

      Note

      Using the option to migrate specific folders can cause a migration to fail, depending on the size of the folders being migrated and the amount of RAM available to the edge filer.

  15. Check Validate and report checksums post-migration to include an MD5 hash checksum for every file being migrated to verify that the migration was successful when the hash is compared with the checksum of the file in the source file server.

    Note

    The checksum validation is performed after all the files are migrated. Depending on the number of files to check, the validation can take some time. You should not allow users to access the migrated files until the actual migratiion job finishes, after the validation completes, in case there is a checksum discrepancy for one or more of the migrated files that needs resolving.

  16. When the migration protocol is SMB: Check Migrate NT-ACLs to migrate the data from the file server, with the ACLs.

    Notes

    If Migrate Additional Attributes is checked, then Migrate NT-ACLs is also checked and cannot be unchecked.
    Alternate data streams (ADS), including macOS tags, cannot be migrated. POSIX ACLs are migrated when Migrate NT-ACLs is checked.
    When the migration protocol is NFS: Alternate data streams (ADS), including macOS tags, and POSIX ACLs, cannot be migrated.

  17. Check Migrate Additional Attributes to migrate supported extended attributes. The supported extended attributes are listed in the cloud drive folder created on the portal.

    Notes

    If Migrate Additional Attributes is checked, then Migrate NT-ACLs is also checked and cannot be unchecked.

    Warning

    Only check Migrate Additional Attributes when the edge filer is connected to a CTERA Portal version 8.1.x and higher.

  18. When the migration protocol is SMB: Check Migrate WORM to migrate WORM data from the file server.

    Note

    When Migrate WORM is checked, Migrate NT-ACLs is also checked and cannot be unchecked.

  19. Check Migrate last access and creation time to include in the migration the last access time and the creation time for each item being migrated.

    Note

    When Migrate WORM is checked, Migrate last access and creation time is checked by default and cannot be unchecked. These times are used to calculate the remaining retention period for each file in the share. If the retention time was changed in the source file system, this is not reflected in the destination and the migration calculated the remaining retention for all the files in the share based on the last retention defined for the source file server and used in the definition of the WORM compliant cloud folder on the CTERA Portal.

  20. You can specify when to start the migration:

    • Start now to start the migration immediately.
    • Don't start to save the job configuration for later use.
    • Schedule to schedule the date and time to start the migration.

  21. Check Limit bandwidth to throttle the bandwidth used for the migration to apply this throttling so as not to adversely impact ongoing work.

    • Check Limit during hours to throttle the time range to apply this throttling so as not to adversely impact ongoing work.
  22. Check Copy each share to a distinct Cloud Folder if you want to specify that each share is migrated to a distinct cloud folder.

    Note

    When migrating WORM compliant shares, Migrate WORM is checked, specify the name of the cloud folder that was defined as WORM compliant on the CTERA Portal as the destination.

    The cloud folder where the cloud folders are migrated is displayed under the Copy each share to a distinct Cloud Folder checkbox.

    When Copy each share to a distinct Cloud Folder is checked:

    • Jobs that were created in a previous version will continue to migrate into the cloud folder root directory.
    • New jobs will create a redundant directory with the name of the source share into the cloud folder root directory, and migrate into it instead.

    When Copy each share to a distinct Cloud Folder is not checked:

    • Depending on the source exposing the data, either the full path in the original server is recreated and no files are migrated into the cloud folder root, or the share name is used under the cloud folder root as was the case in previous versions.
  23. Click Create.
    During the migration, the progress bar in the Dashboard shows the percentage completed and what is currently being processed.
    image.png
    After migrating all the shares, the job completes and an email alert is sent with the job summary.

  24. Click image.png to edit the migration job name, notes, include and exclude paths, migration checksum, whether to migrate access and creation times, schedule and throttling.
    image.png

  25. Click image.png to display the migration report.
    image.png

  26. Optionally, click image.png to download the migration log file to a .log text file.

  27. Click the image.png icon to display the list of every time this job was run with the results of each run, including the start and end times for the job, the number of files migrated and the total size of the migration, access to the report and the ability to download the log, which provides information about the migration and any errors that occurred during the migration.

  28. Optionally, in the dashboard, you can select a job and click the image.png icon to delete it.
    After deleting a job, you can display all the jobs, including the deleted jobs, by clicking the Deleted filter in the dashboard.
    You can restore deleted jobs by selecting the deleted jobs to restore and clicking the image.png icon.

The share structure from the source is recreated on the CTERA Edge Filer, including nested shares and their permissions. If there are any recoverable errors during the copy process, retry the migration for the failed shares.

Note

Only ACLs are migrated with the files. Windows extended attributes are not migrated. In the CTERA Edge Filer, the shares are defined with Windows ACL Emulation Mode, as in the following example.
image.png

Direct all the users to the CTERA Edge Filer.
Users can now access and work on the CTERA Edge Filer.

Note

If you enabled deduplication and then run a migration, the file system is automatically re-indexed. You must not restart the edge filer while the re-indexing is being performed. If the edge filer is restarted while re-indexing is being performed, any file that was not re-indexed when the edge filer was restarted, is never evicted from the edge filer.

Completing a Migration and Performing a Delta Migration

After completing the migration, there may well be a number of new or changed files on the original file server that require migrating. Complete the migration process using the following procedure.

To complete a migration:

  1. During off-peak hours, disconnect the filer server.
  2. In the CTERA Edge Filer user interface, pin the folders that you want to remain local to the CTERA Edge Filer.
    1. In the Configuration view, select Cloud Drive > Pinned Folders in the navigation pane.
      The Pinned Folders page is displayed.
      image.png
      The Pinned Folders area is separated into a users pane and folders pane, with paging in the users pane. This makes it easier to page through the users and select the folders to pin.
    2. Select a user to display the folders owned by the user and then select the folders that you want pinned for this user, so that the folder content is always available on the CTERA Edge Filer.
      In addition, you can use the search field to jump to a specific user.
      Note

      You can select a a user to select all the folders and subfolders owned by the user. You can also select a higher level folder to select all the subfolders under it and then uncheck specific folders to unpin them. If you check a cloud folder, all the subfolders under the cloud folder are pinned, and any folders added later under the cloud folder will be pinned automatically.

    3. Click Save.
      The checked folders are pinned.
  3. In the Configuration view's Main > Dashboard page, click File Server Migration.
    The File Server Migration page is displayed, showing the discover and migration jobs previously run.
  4. Select the migration job to rerun and click the image.png icon.

The migration job reruns, migrating the deltas from the last migration.

Note

If you enabled deduplication and then re-run the migration, the file system is automatically re-indexed. You must not restart the edge filer while the re-indexing is being performed. If the edge filer is restarted while re-indexing is being performed, any file that was not re-indexed when the edge filer was restarted, is never evicted from the edge filer.


Was this article helpful?