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 | Not specified in the current upgrade guide | Not specified in the current upgrade guide | 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
The current Disaster Recovery Upgrade Guide does not state whether upgrades are applied in-place or require redeploying a VM, and does not address OS-level upgrade handling. It covers release/platform compatibility checks, support entitlement for planned failovers, backup/snapshot steps, known upgrade-related issues, and post-upgrade validation.
The Disaster Recovery upgrade guide doesn't currently specify in-place vs. redeployment behavior or OS-upgrade handling. Until this is confirmed with the product team, refer to the general Core Agent Appliance & ECA and OS-level upgrade guides below, since Disaster Recovery runs on the same underlying appliance architecture.
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 15.5→15.6 and 15.6→16.0 guides both state that the OS is the customer's responsibility, that assisted OS upgrades are not covered under the support contract, and that the supported approach is to deploy a new OVA and restore configuration — then immediately provide a full in-place zypper dup procedure for both Eyeglass and ECA VMs. This is a direct contradiction between the stated support position and the documented steps. This page does not attempt to resolve it; confirm the intended guidance with the product/support team before treating either statement as authoritative.
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.