Upgrade Paths and In-Place Behavior by Product
Introduction
Superna products differ in how software and operating system upgrades are performed. This page consolidates, per product, whether an upgrade is applied in-place or requires redeploying a new virtual machine, how operating system (OS) upgrades are handled, and what supported upgrade path information currently exists in the documentation.
Overview
| Product | Software Upgrade | OS-Level Upgrade | Details |
|---|---|---|---|
| Data Security | In-place — Carrier-Grade (no downtime, requires ECA 2.5.8.2 or later) or Standard (brief downtime) | Not in-place — requires migrating to a new ECA cluster | Data Security |
| Disaster Recovery (Dell Cyberstorage) | In-place — Eyeglass services are disrupted for less than 10 minutes | In-place — does not require a new appliance | Disaster Recovery |
| Disaster Recovery (Multiplatform Cyberstorage — VAST, Qumulo, Pure FlashBlade) | Shares the Core Agent Appliance & ECA in-place upgrade file | Shares the OS-level upgrade guides below | Disaster Recovery |
| AirGap | In-place — upgrade file applied to the existing VM | Not in-place — requires VM re-deployment | AirGap |
| Data Orchestration | In-place — offline upgrade procedure | Not addressed in the current upgrade guide | Data Orchestration |
| Core Agent Appliance & ECA (shared component) | In-place upgrade file available | Not in-place — separate re-deployment guide | Core Agent Appliance and ECA |
Each product's upgrade guide is the authoritative source for that product's exact steps. This page summarizes what those guides say and points out where OS-level behavior is not yet clearly documented.
Data Security
Data Security supports two in-place upgrade methods:
- Carrier-Grade Upgrade: applied with
.run --rolling-upgrade, with no downtime. Requires ECA version 2.5.8.2 or later. - Standard Upgrade: a 9-step procedure that takes the cluster down and back up via
ecactl, resulting in brief downtime.
Both methods upgrade the software on the existing ECA cluster without redeploying VMs.
OS-level upgrades are handled differently: the documented approach is Migrating to a New ECA Cluster, meaning an OS upgrade for Data Security is not applied in-place — a new ECA cluster is deployed and the existing configuration is migrated to it.
Data Security also has a separate Threat Hunting ML VM, upgraded through a Helm-based mechanism with its own YAML-file-to-component mapping.
See Data Security Upgrades for full steps.
Disaster Recovery
Disaster Recovery upgrades are applied in-place. An in-place upgrade disrupts Eyeglass services for less than 10 minutes, and you should take a VM-level snapshot before you upgrade. An in-place OS upgrade upgrades the operating system and does not require a new appliance; see OS-Level Upgrades.
The Disaster Recovery Upgrade Guide also covers release/platform compatibility checks, support entitlement for planned failovers, backup/snapshot steps, known upgrade-related issues, and post-upgrade validation.
AirGap
AirGap documents two explicit upgrade paths for the Vault Agent VM:
- In-Place Upgrade: applies a
.runupgrade file to the existing VM without redeploying it. The upgrade file must match the OS version currently installed on the VM — this upgrade method does not change the underlying OS. - VM Re-deployment Upgrade: deploys a new VM and migrates the existing configuration to it.
Because AirGap Vault Agents are network-isolated by design, upgrades also involve a network-access decision: temporarily opening in-band access to the vault, or connecting physically (the recommended approach).
See AirGap Upgrades for full steps.
Data Orchestration
Data Orchestration documents an Offline Upgrade Procedure: an in-place, .run-based upgrade that takes the cluster down and back up via ecactl. The guide does not use the term "in-place" explicitly and does not address OS-level upgrade handling.
Version-specific notes called out in the guide:
- Version 1.1.16 and later support a configuration-backup capability during upgrade.
- Version 1.1.9 has a known-issue caveat noted in the guide.
See Data Orchestration Upgrade Guide for full steps.
Core Agent Appliance and ECA
The Core Agent Appliance and Extended Cluster Appliance (ECA) — the shared appliance architecture used across products — have two dedicated guides in this section:
As with AirGap, the in-place upgrade file must match the OS version currently installed — confirming that the in-place path is software-only and does not change the OS.
OS-Level Upgrades
Separate from product/appliance software upgrades, this section also documents OS-level upgrade paths:
The openSUSE-to-SLES migration is a separate, optional path: it applies to appliances running Dell Cyberstorage 2.10.0 or later, or Multiplatform Cyberstorage 4.0.0 or later, and requires a licensed SLES entitlement.
For OS and hypervisor compatibility, see the Platform Support page, which lists supported operating systems separately for Install (openSUSE Leap 16 only) and Upgrade via .run (openSUSE Leap 15.5, 15.6, and 16).
Supported Upgrade Paths
There is currently no consolidated matrix in the documentation showing which specific product versions can upgrade directly to the latest release. The closest information that does exist today is scattered across individual guides:
- Data Security's Carrier-Grade upgrade requires ECA 2.5.8.2 or later.
- Data Orchestration notes a configuration-backup capability starting at 1.1.16, and a known issue specific to 1.1.9.
- The openSUSE-to-SLES guide applies to Dell Cyberstorage 2.10.0+ or Multiplatform Cyberstorage 4.0.0+.
- The Platform Support page documents supported OS versions for install versus upgrade, but not product-version-to-product-version upgrade paths.
Building a true "which version can I upgrade from" matrix would require version-by-version confirmation from each product team and is not something this page fabricates.