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

Upgrade Guide for Disaster Recovery for Dell

Introduction​

This page covers what to confirm and review before upgrading Superna Disaster Recovery (DR) Edition — release and platform compatibility, support entitlement considerations for planned failovers, and general upgrade precautions. For the initial deployment process, which shares underlying appliance mechanics with an upgrade, see the Installation Guide.

Coordinated upgrades

If your upgrade needs to be sequenced with other components (for example, ECA/Core Agent components) within a single maintenance window, confirm the correct sequencing with Superna Support before you begin — particularly when the target release introduces new required service-account privileges or changes to PowerScale OneFS support boundaries.

Before You Upgrade​

Confirm Release and Platform Compatibility​

Before upgrading, confirm the target Superna release supports the PowerScale OneFS (or ECS/VAST/Qumulo) release running on your clusters. See the Platform Support page for the first Superna release to support each PowerScale/ECS version.

Support Entitlement for Planned Failovers​

Superna's support policy ties your support entitlement for a planned failover event to how current your release is (this does not apply to unplanned/real DR failovers):

  • Superna adds enhancements in every release specifically to prevent or document conditions that could block a failover. Running an outdated release can affect your support entitlement for a planned event.
  • If you are not on the latest GA release when you open a planned-failover case, you are assumed to have read and accepted the risks documented in that release's Release Notes page before proceeding.

See Failover Process and Customer Role for the complete case-classification and planning-process policy.

Review the Failover Planning Checklist​

The Failover Planning checklist lists "upgrade Eyeglass to the latest version" as one of the pre-failover-day planning tasks, alongside reviewing best practices and release notes, before a planned failover. If you are upgrading specifically to prepare for a planned failover, complete the upgrade with enough lead time to also complete DR readiness validation and rehearsal testing afterward.

Take a Backup / Snapshot Before You Begin​

tip

Eyeglass provides appliance backup and restore capability (for example, igls app pull-config for migrating configuration to a new appliance). As a general precaution, take a VM-level snapshot of the appliance and confirm a recent Eyeglass backup exists before starting any upgrade.

New Validations After Upgrade​

Expect to see warnings after an upgrade. This is expected and is a key feature of the release: it detects failover conditions that must be addressed before you are ready to fail over. If you get alarms, the issues can be fixed.

  1. SyncIQ domain mark for fast failback - Checks both clusters to verify that a SyncIQ domain mark exists and raises a warning if it is not found. A warning is also raised if the sudo update was not applied.
  2. SPN delegation for Access Zone and IP pool failover - Checks that AD delegation was completed to the cluster AD objects and to the opposite cluster (cross test). If any test fails, the warning states exactly which delegation permission is missing.
  3. DNS dual delegation - Ensures automatic DNS resolution is in place before a failover. The validation inspects your DNS configuration to determine whether the delegation is correct and whether A records resolve to subnet service IPs in the correct subnet. If you use Infoblox, this validation must be disabled. It only supports standards-based name server delegations and not DNS forwarding.

In-Place Upgrade​

An in-place upgrade disrupts Eyeglass services for less than 10 minutes. Take a VM-level snapshot before you upgrade so you can roll back to the previous version of the appliance.

To check the OS version of the appliance, SSH as the admin user and run:

cat /etc/os-release
note

OpenSUSE OS versions 42.3 and 15.1 no longer receive security updates. Staying on this OS is the customer's choice, and the OS is not covered by the support contract. To move to the latest OS, use the new appliance method described in Upgrade to a New Appliance.

To complete an offline upgrade:

  1. Log in to the support site (https://support.superna.net) with a registered support account.

  2. Scroll down the page to locate the software download validation form.

  3. Get the appliance ID from the About window of the Eyeglass desktop.

  4. Enter the appliance ID and click Download to retrieve the offline installer.

    note

    The download checks for an active support contract and only downloads software if support contract validation is successful.

  5. Use a tool such as WinSCP to copy the offline package onto the appliance with the admin user and password.

  6. SSH to the Eyeglass appliance and elevate to root (you are prompted for the admin password again):

    sudo su -

  7. Make the offline package executable:

    chmod 755 <filename>

  8. Run the installer:

    ./<filename>

  9. If you have not previously set it, you may be prompted for the Phone Home Agreement. Enter y or n to continue. Phone Home allows remote monitoring and faster support, including remote log collection.

  10. When the update completes, log in to the Eyeglass web page and refresh any open Eyeglass window to ensure you have the latest changes.

  11. Open the About Eyeglass window and verify that the version matches the version you downloaded.

  12. Continue with Post-Upgrade Steps.

Upgrade to a New Appliance​

Use this option to move to the latest Eyeglass release and the latest OpenSUSE 15.x OS, which includes automatic security patch updates. Appliance versions prior to the latest use OpenSUSE versions that no longer have security patches available (13.1, 13.2, 42.1, 42.3, 15.1).

  1. Download the new OVF and deploy a new Eyeglass VM using the Installation Guide.
  2. The new appliance IP address can be different from the old appliance IP address.
  3. After the new appliance is deployed and you can log in to the web UI and SSH, continue with the steps below.
warning

If you use an older appliance backup file, some settings are not retained, depending on the backup file release version. All existing Eyeglass databases are removed on the new appliance and no backup is made; they are rediscovered on startup. Do not use this method if you need to retain Cluster Storage Monitor or Ransomware Defender historical events, or RPO report data. Contact Superna Support if this applies to your scenario.

Settings Migrated by Backup/Restore​

Eyeglass Configuration ItemRestored (source appliance version > 1.8.0)
Local credentials for clustersYes
License keysYes
Adjusting license keys to latest formatYes
Job schedulesYes
Job initial state setting (enabled, disabled)No
Custom settings made with the igls adv commandYes
Notification Center settings (edit the notification settings after the restore)Yes
Failover log history (if available)Yes
Custom RBAC roles (if available)Yes
API tokens (if available)Yes (as of 1.9.0)
Ransomware Defender Security Guard logs (if available)Yes
Cluster configuration reports (if available)Yes
Current job state (enabled, disabled, DFS mode) (if available)Yes
Alarm historyNo
Old backup archivesNo
Cluster Storage Monitor data (if available)No
RPO generated reportsNo
RPO report dataNo
Failover scriptsYes
Ransomware Defender settings and history (history, ignored list, statistics, settings, Security Guard configuration)No (the Security Guard schedule is restored, but no other settings; re-add them manually with the user service account and password)

Information to Record Before Upgrading​

  1. Take a screenshot of the Eyeglass Jobs window to use as a reference to verify the job state and type (for example, auto type or DFS type).
  2. If IP pool mode is configured, take a screenshot of the IP pool failover policy to pool mappings.
  3. If you use Ransomware Defender, take a screenshot of each of the following:
    • Learned Thresholds
    • Ignored List
    • Threshold window (all settings)
    • File Filters
    • Monitor Only Settings
  4. If you use Easy Auditor, take a screenshot of the Active Auditor triggers configured.

Automated Appliance Configuration Import​

Use igls app pull-config from the new appliance to automate the migration.

Requirements:

  • The new appliance must be running release 2.5.7.1 or later. Check the About icon for the version. Do not use this command on an earlier version; use the manual restore procedure below instead.
  • SSH access from the new appliance to the old appliance.
  • The new appliance is deployed on a new IP address.
  • For 2.5.7.1, ECA must be updated to point at the new Eyeglass IP address. From 2.5.8, the ECA configuration, Eyeglass IP address, and API token are updated automatically and pushed to all ECA nodes.
note
  • This option does not migrate custom threat file settings on ECA. This is not a common modification and does not apply to most deployments.
  • The command can take 10 minutes to run.

On the new appliance, log in as admin and run the import command:

igls app pull-config --ip=<ip> --user=<user>
  • --ip is the address of the old Eyeglass appliance.
  • --user is admin. You are prompted for the password.

The command automates these steps:

  1. Creates a backup on the old appliance.
  2. Copies the backup to the new appliance.
  3. Applies the backup to the new appliance.
  4. Updates the ECA configuration to use the new Eyeglass IP address. After the command completes, restart the ECA cluster to update the firewall configuration: log in to ECA node 1 and run ecactl cluster down, followed by ecactl cluster up.
  5. Shuts down the OS on the source appliance.

When the steps complete, continue with Post-Upgrade Steps.

Manual Backup and Restore​

  1. Take an Eyeglass Restore backup from the old Eyeglass appliance. The Restore Backup option is required rather than the support backup: the Restore backup includes SSL private keys and the support backup does not (applies to releases later than 2.5.3).

  2. Download the Restore backup locally, then copy the zip file with scp or WinSCP to the /tmp folder on the newly deployed Eyeglass appliance.

  3. Power off the old Eyeglass appliance. Multiple Eyeglass appliances managing the same clusters is not supported.

  4. SSH to the new Eyeglass appliance as admin and elevate to root with sudo su -.

  5. Run the restore command, replacing the file name with the name of the Eyeglass archive file and always including the full path:

    igls app restore /tmp/<eyeglass_backup.xxxx.zip> --anyrelease

  6. When prompted to continue, enter y. For example:

    igls app restore /tmp/eyeglass_backup_17-07-05_20-42-08.zip --anyrelease
    Do you want to revert to the archive at /tmp/eyeglass_backup_17-07-05_20-42-08.zip? [y/N]: y

  7. When the restore completes, continue with Post-Upgrade Steps.

Post-Upgrade Steps​

These steps apply to all upgrade paths.

Validate Service Account Permissions, Jobs, Pool Mappings, Licenses, and Inventory​

  1. Mandatory: Confirm that the minimum service account permissions and sudo entries for your release are all in place, as described in the Installation Guide. Missing permissions generate errors.
  2. Log in to the new Eyeglass appliance and open the Jobs window. Verify that all jobs are set to the correct mode and appear in either the config sync or DFS section, using the screenshot taken before the upgrade. If a job is in the wrong mode, set the mode with the bulk actions menu.
  3. If IP pool failover mode is configured, use the screenshot taken before the upgrade to verify the SyncIQ pool mappings on the DR Dashboard mapping screen.
  4. Open License Manager and verify that licenses are visible.
  5. Open Inventory and verify that clusters are displayed.
  6. Open Notification Center and verify that the alarm severity filter is correctly set and that email recipients are set with the correct email type.

Validate License Assignment for Ransomware Defender, Easy Auditor, and Performance Auditor​

warning

This step is mandatory to ensure licenses are assigned to the correct cluster. Auto-assigned license mode for clusters is no longer supported.

  1. Log in to Eyeglass and open License Manager.
  2. Click the Licensed Devices tab.
  3. First, set each cluster that should not be licensed to Unlicensed using the drop-down menu.
  4. Then set each remaining cluster to User Licensed for the product or products that should be assigned to it. For example, set production writable clusters to User Licensed for Ransomware Defender or Easy Auditor.
  5. Click Submit to save.

Validate Ransomware Defender and Easy Auditor Settings​

Verify that the settings you recorded before the upgrade are preserved:

  • If you use Ransomware Defender: Learned Thresholds, Ignored List, Threshold window (all settings), File Filters, and Monitor Only Settings.
  • If you use Easy Auditor: Active Auditor triggers configured.

If you are upgrading a very old environment (pre-2.6.1) directly to 2.15.0 in a single step, contact Superna Support before you begin to confirm there are no version-specific conditions affecting your upgrade path.

The following general requirements and considerations apply when upgrading:

  • Disk usage requirement: An Eyeglass upgrade requires appliance disk usage to be below 80% before it will proceed. Free up space (for example, remove old backup files — see Appliance Check) before starting the upgrade if you are close to this threshold.
  • Script Editor is disabled by default: As a security hardening measure, the Script Editor (used for pre/post-failover scripts) ships disabled by default. If your environment relies on custom pre/post-failover scripts and they stop running after an upgrade, this is the most likely cause — contact Superna Support for the current re-enablement procedure.
  • New or changed service-account privileges: Some releases require additional eyeglass service-account privileges on PowerScale OneFS after upgrade. Review the Installation Guide service-account section and compare against the Release Notes for the release you are upgrading to.
Upgrading PowerScale OneFS itself

The steps above cover upgrading the Eyeglass appliance. If you are instead upgrading the PowerScale OneFS release on clusters managed by Eyeglass, see the OneFS Upgrade Procedure for the major/minor release upgrade paths, mixed-mode behavior, and post-upgrade validation steps for Ransomware Defender, Easy Auditor, and Performance Auditor.

note

Consult the Release Notes page for the complete, current-release list of fixes and known limitations before and after upgrading.

Post-Upgrade Validation​

As a baseline, and consistent with the general system checks described in the Installation Guide, confirm the following after any upgrade:

  • Confirm the appliance reports the expected version after upgrade.
  • Confirm all managed clusters still show healthy inventory and job status in the Eyeglass UI.
  • If the upgrade changed required service-account privileges or the supported-platform boundary, re-check DR Dashboard / Failover Readiness results for new errors or warnings before relying on the environment for a planned failover.

See Also​