Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Data and Config Migration

Introduction​

Data and Config Migration is an Eyeglass feature for moving data — along with its associated configuration (SMB shares, NFS exports, quotas, and NFS aliases) — between Access Zones on the same cluster, or between clusters, using your existing DR license and SyncIQ. Unlike Configuration Replication, which continuously mirrors configuration to a standing DR target, this feature is used for one-time or scheduled migration projects: restructuring Access Zones, consolidating clusters, or preparing a new environment for cutover.

Migration jobs are created and monitored from the Data Migration page (sidebar).

Typical Use Cases​

  • Split an Access Zone into two, for failover granularity.
  • Move an application to its own Access Zone, for security isolation.
  • Split data and application load between clusters.
  • Move data and configuration to a new Access Zone on the DR cluster for testing.
  • Move data and configuration to a new Access Zone to achieve active-active clusters.
  • Migrate data and configuration from several remote clusters into a central cluster, either into the same Access Zone (fan-in) or into separate Access Zones.

Supported Clusters​

  • PowerScale, all models
  • PowerScaleSD

See the release notes for the current feature-support matrix and supported OneFS releases.

Prerequisites​

Quota jobs must be enabled before running a migration job that includes quotas. Quota jobs are disabled by default.

  1. Connect to the Eyeglass appliance over SSH and log in as the admin user.

  2. Enable quota jobs:

    igls adv initialstate set --quota=enabled

  3. Confirm the setting took effect:

    igls adv initialstate show

    Confirm the output includes:

    "QUOTA": "ENABLED",

Planning Migrations Between Access Zones​

Before starting a migration, review the source and destination paths and Access Zones:

  • Source path — the source Access Zone is selected manually, since some clusters allow overlapping Access Zone base paths, meaning a single source path could belong to more than one Access Zone.
  • Target path — the target Access Zone (on the same or a different cluster) is auto-detected based on which Access Zone base path matches the target path.
Important

The target Access Zone must use the same authentication provider as the source Access Zone. Eyeglass cannot translate user and group SIDs between different Active Directory providers — if the target zone authenticates against a different AD forest or provider than the source, users will not resolve correctly on the migrated data.

Example — migrating overlapping Access Zones​

This example illustrates migrating several Access Zones that have overlapping base paths into a single new, non-overlapping Access Zone (on the same or a different cluster). Each source Access Zone can have its own configuration objects (shares, exports, NFS aliases, and quotas).

  1. Open the Data Migration page and start a new migration job.

  2. Select each source Access Zone path and zone name as a migration source. You can leave Keep SyncIQ Policy enabled to allow incremental sync after the initial copy.

    note

    The initial SyncIQ policy is created in copy mode. To keep the source and target paths in sync afterward, change it to incremental sync mode and apply a schedule.

  3. Confirm the migration job completes successfully, then verify the configuration objects (shares, exports, NFS aliases, quotas) exist correctly on the target Access Zone.

note

When source Access Zones have overlapping paths, quotas that fall within the overlapping portion will be duplicated on the new Access Zone.

How to Create a Migration Job​

  1. Open the Data Migration page.

  2. Fill in the Device & Migration Path field for the source — select the source cluster (only clusters managed by Eyeglass are listed), then type the source path or use the Browse button to navigate to it:

    • All configuration data (shares, exports, NFS aliases, quotas) at or below this path is included in the migration.
    • Select the source Access Zone separately. This isn't auto-detected, because some clusters allow overlapping Access Zone base paths, meaning a single source path could belong to more than one Access Zone.
    note

    The 2.15.0 form combines the legacy Migration Path and Source Cluster fields into a single Device & Migration Path field with a Browse button (see Data Migration) — the same applies to the destination field in step 4 below. Whether device selection happens as a step inside the Browse dialog itself, or via a separate control alongside it, hasn't been independently confirmed; the steps here describe the two selections functionally rather than the exact dialog mechanics.

  3. Decide whether to block user access to the source path during migration:

    • Leave Enable Source Write Access selected (default) to leave the source path writable during migration.
    • Deselect it to lock the source path and deny all I/O for the duration of the migration, regardless of share or export permissions. The migrated data inherits the locking SyncIQ policy's ACLs on the parent folder once the migration completes — see Re-apply Default SMB Share ACL Post Migration below, which is required if you deselect this option.
    • If the source path is already protected by an existing SyncIQ policy, you must deselect Enable Source Write Access — otherwise the migration job will fail, since the path is under an active SyncIQ domain.

  4. Fill in the Device & Migration Path field for the destination — select the destination cluster (must be managed by Eyeglass with a DR license key), then type the target path or use Browse to navigate to it.

    • The target path must not already exist. If Eyeglass detects existing data or configuration at the target path, the migration will not proceed.
    • The target Access Zone is auto-detected based on the target path matching an Access Zone base path.

  5. Optionally enable Migrate Only Configuration (named Configuration Sync Only in earlier releases) if the data is already synced by an existing SyncIQ policy and you only need to create the corresponding configuration (shares, exports, quotas) at the target path. This skips SyncIQ policy creation entirely.

    • The target path must already exist for this option — Eyeglass will not create the folder structure for you.

  6. If a SyncIQ policy already exists between the source and target paths, Eyeglass detects it automatically and uses it to sync configuration data instead of creating a new migration policy — no administrator action or separate toggle is required. (There is no Auto-detect Existing SyncIQ control on the 2.15.0 migration form; this detection is built-in behavior, not a setting.)

  7. Use the Preview Configuration option to confirm which shares, exports, quotas, and aliases were discovered for migration before submitting.

  8. Click Submit to start the migration job, and monitor it from the Data Migration page. Submit stays dimmed until the required fields are complete. Use Clear to empty the form and start over — this replaces the legacy Cancel button, which no longer appears on the 2.15.0 form.

  9. When you're ready to cut over to the new cluster or Access Zone, DNS updates (for the subnet service IP) and SPN changes are manual steps, but the data itself can be failed over using the Failover Wizard's SyncIQ policy failover type.

info

The configuration data is synced once on the first job run, using SyncIQ copy mode. If Keep SyncIQ Policy is left checked, the policy remains after the initial run and can be scheduled or run manually to incrementally sync configuration changes — it will appear under the ZoneMigration section of the Jobs window. Do not uncheck this without confirming with Superna Support first.

tip

Once a configuration-only migration job has finished and is no longer needed, delete it from the Jobs window (select its checkbox, then use Bulk Actions → Delete). Configuration-only migration jobs should not be left in place indefinitely.

Re-apply Default SMB Share ACL Post Migration​

Use this procedure only if you deselected Enable Source Write Access when creating the migration job.

That option applies a restrictive ACL to the target's top-level parent folder to block all access during migration — this ACL is applied only at the top level, so any ACLs already present on child paths below the migration path are preserved as-is. The modified top-level ACL blocks access to the data even if the share or export permissions themselves allow write access or full control — write access requires the combination of the share/export permission and a permissive ACL.

To restore the default Microsoft-style ACLs on the parent folder after migration, connect to the cluster's CLI and run:

chmod +a# 0 group Administrators allow dir_gen_all,object_inherit,container_inherit <path>
chmod +a# 1 creator_owner allow dir_gen_all,object_inherit,container_inherit,inherit_only <path>
chmod +a# 2 everyone allow dir_gen_read,dir_gen_execute <path>
chmod +a# 3 group Users allow dir_gen_read,dir_gen_execute,object_inherit,container_inherit <path>
chmod +a# 4 group Users allow std_synchronize,add_file,add_subdir,container_inherit <path>
note

Replace <path> with the migrated parent folder path. The example ACE numbering above (0–4) assumes these are the first entries being added — adjust the index if the folder already has other ACEs.

Check the resulting ACL list with:

ls -lze <path>

If the restrictive migration-lockout ACEs are still present alongside the restored default ACEs, remove the extra entries by ACE index (highest index first, so indexes don't shift):

chmod -a# <index> <path>

Re-run ls -lze <path> to confirm only the intended ACEs remain, then connect to the target SmartConnect name to test that the mount and write access to the data behave as expected before returning the share to production use.

Planning Timeouts for Migration Jobs​

The following default timers apply to migration jobs and should be sufficient for most migrations. Use them as a starting point when troubleshooting a timeout on a long-running job:

StepDefault timeout
Run policy (overall job)15,000 minutes (10 days)
Wait for migration of config to complete50 seconds
Wait for locking policy to complete50 seconds
Wait for opened files to be closed300 seconds (delays job start; fails if the force flag isn't enabled)
Cleanup migration policy75 seconds (only if Keep SyncIQ Policy is unchecked)
Cleanup locking policy75 seconds (only if Enable Source Write Access is unchecked)

Known Limitations​

  • igls-dfs prefixed shares cannot be migrated directly. To migrate this data, a writable copy using non-prefixed shares must be migrated instead.

See Also​

Configuration Replication

How Eyeglass continuously mirrors shares, exports, quotas, zones, snapshots, and dedupe settings across PowerScale clusters for standing DR protection.

See More

Eyeglass Jobs

Understand how Eyeglass jobs work, including types, modes, and scheduling options relevant to migration and replication jobs.

See More