Backup and restore compatibility

Mission Control uses Medusa to perform backup and restore operations across Apache Cassandra®, DataStax Enterprise (DSE), and Hyper-Converged Database (HCD) clusters.

You can create backups on-demand or schedule them using cron expressions. Mission Control maintains multiple backups in your configured object storage. When restoring, you select which backup to restore from based on your recovery needs. You must configure backups before you can restore a backup. For more information about creating and managing backups, see Back up data and Restore a data backup.

Certain constraints apply when you restore backups across different versions, configurations, and storage formats.

Limitations

Consider the following limitations when you plan backup and restore operations:

Restoring to a newer major version requires SSTable upgrades.
When restoring a DSE backup to a Cassandra or HCD cluster, be aware that DSE-specific features might not work in the target cluster.
You might need to rebuild materialized views after you restore.
If the source cluster used custom compaction strategies, the same strategies must be available in the target cluster before restoration.
Time-series data with TTL might expire during long restore operations.

Backup types

Full backups: Capture all data at a specific point in time. Self-contained and don’t depend on previous backups. Use for cross-version migrations or maximum restore flexibility.
Differential backups: Capture only data that changed since the last full backup. More efficient for storage and transfer time. Can be restored, but require the base full backup to be restored first.

Version compatibility

You can restore a backup to the same version of Cassandra, DSE, or HCD that you were running at the time of the backup, or you can restore to a later version.

Additionally, some cross-platform restorations are supported, such as DSE 6.9 to HCD.

Same-version restores always work without additional steps. When you restore to a later version, you must upgrade SSTables after the restore completes. Mission Control doesn’t support downgrading to an earlier version.

When you restore DSE backups, consider both the underlying Cassandra compatibility and any DSE-specific features your cluster uses because some features might be unsupported in the target platform or version.

Version restore compatibility
Source version	Target version	Supported	Notes
Cassandra 3.11.x	Cassandra 3.11.x	Yes	Restore to the same version
Cassandra 3.11.x	Cassandra 4.0.x	Yes	Upgrade SSTables after you restore
Cassandra 3.11.x	Cassandra 4.1.x	Yes	Upgrade SSTables after you restore
Cassandra 4.0.x	Cassandra 4.0.x	Yes	Restore to the same version
Cassandra 4.0.x	Cassandra 4.1.x	Yes	Restore to a later minor version
Cassandra 4.0.x	HCD	Yes	Restore Cassandra 4.x backups to HCD
Cassandra 4.1.x	Cassandra 4.0.x	No	Don’t downgrade versions
Cassandra 4.1.x	HCD	Yes	Restore Cassandra 4.x backups to HCD
Cassandra 4.x.x	Cassandra 3.11.x	No	Don’t downgrade versions
DSE 6.8.x	DSE 6.8.x	Yes	Restore to the same version
DSE 6.8.x	DSE 6.9.x	Yes	Upgrade SSTables after you restore
DSE 6.8.x	HCD	Yes	Validate the schema during migration
DSE 6.9.x	DSE 6.9.x	Yes	Restore to the same version
DSE 6.9.x	HCD	Yes	Validate the schema during migration
HCD 1.x	HCD 1.x	Yes	Restore to the same version

SSTable upgrades

SSTables store your database data on disk as immutable data files. When you restore to a later version with a different SSTable format, upgrade the SSTables after the restore completes.

SSTable format changes occur between major versions. After you restore a backup to a cluster running a newer version, the restored SSTables remain in the earlier format until you explicitly upgrade them. While Cassandra can read earlier SSTable formats, upgrading ensures optimal performance and enables new features specific to the current version.

To upgrade SSTables, create a CassandraTask that runs the upgradesstables command on your datacenter:

apiVersion: control.k8ssandra.io/v1alpha1
kind: CassandraTask
metadata:
  name: upgrade-sstables
spec:
  datacenter:
    name: dc1
  jobs:
    - name: upgradesstables
      command: upgradesstables

For detailed instructions, see Upgrade SSTables.

Schema and topology changes

Backups capture schema information along with data.

Adding columns or tables after you take a backup doesn’t prevent restore. However, when you restore from an earlier backup, the restore doesn’t include any schema changes you made after you took that backup. To bring those schema changes forward, reapply them manually after the restore completes.

Dropping columns, adding columns, or changing data types requires careful planning because restoring an earlier backup reverts the schema to the restore point. Columns dropped after the backup reappear, and the restored schema does not include columns added after the restore point. Adjust replication settings after the restore to match your target cluster’s topology.

Secondary indexes restore automatically, and custom indexes require the same implementation in the target cluster as in the backup.

You might need to rebuild materialized views after restoration.

You can restore to a cluster with a different number of nodes, datacenters, or rack topology. Mission Control automatically recalculates token ranges and handles rack assignment. For multi-datacenter clusters, restore each datacenter’s backup independently and ensure schema consistency across all datacenters.

Security considerations

TDE-encrypted backups require the same encryption keys for restore. Store encryption keys securely in a separate location from backups.

Backups don’t include authentication and authorization settings. After you restore, recreate users and roles, reconfigure external authentication providers, and verify user access.

For more information, see Secure Mission Control infrastructure and Configure authentication.

Best practices

Test restore procedures in a non-production environment before restoring production data. Schedule regular backups to prevent data loss.

Before you restore, verify version compatibility, check storage space, and confirm backup integrity.

After you restore, run nodetool repair for data consistency, upgrade SSTables if needed, verify data integrity, recreate security settings, and update application connection strings.