Restore a backup of data

The Mission Control package includes Medusa, a tool for restoring Apache Cassandra® and DataStax Enterprise (DSE) data in Kubernetes.

Topics covered:

Restore a backup
Monitor restore activity status
Synchronize MedusaBackup objects with a Medusa storage backend
Purge backups

For a restore to be possible, a MedusaBackup object must exist.

Restore a backup

Access Mission Control’s UI.
In the Home Clusters dialog, click the target cluster namespace.
Click the Backups tab.
In the Backup Activity section, click the overflow menu icon (3 dots) on the row of your target datacenter.
Select Restore Backup.
Review the warning in the confirmation dialog, and then click Restore Backup.

To view notifications from the restore activity, see Monitor restore activity status.

Access Mission Control’s CLI.
To restore an existing backup for a Apache Cassandra® or a DataStax Enterprise (DSE) datacenter, create the MedusaRestoreJob Custom Resource (CR) for your release in the same namespace where the MissionControlCluster or cassandraDatacenter resource resides. This example uses cassandraDatacenter:demo-dc1:
```
apiVersion: medusa.missioncontrol.datastax.com/v1beta1
kind: MedusaRestoreJob
metadata:
  name: restore-backup1
  namespace: project-4vcx
spec:
  cassandraDatacenter: demo-dc1
  backup: medusa-backup1
```
The spec.backup `value should match the `MedusaBackup metadata.name value. As soon as Mission Control detects the MedusaRestoreJob object creation, it orchestrates the shutdown of all Cassandra or DSE pods, and the medusa-restore container performs the data restore upon pod restart. The restore runs concurrently and restores all nodes at the same time.

Monitor restore activity status

Access Mission Control’s UI.
In the main navigation, click Activities.
See Status notifications regarding the progress of the restore activity.

A status of SUCCESS indicates the restore completed without issue. The Start and End columns list the timestamps of the restore activity.

Access Mission Control’s CLI.

Check if the finishTime is set in the MedusaRestoreJob object status.

kubectl get cassandrarestore/restore-backup1 -o yaml

Sample results

apiVersion: medusa.missioncontrol.datastax.com/v1beta1
kind: MedusaRestoreJob
metadata:
  name: restore-backup1
spec:
  backup: medusa-backup1
  cassandraDatacenter: demo-dc1
status:
  datacenterStopped: "2022-01-06T16:45:09Z"
  finishTime: "2022-01-06T16:48:23Z"
  restoreKey: ec5b35c1-f2fe-4465-a74f-e29aa1d467ff
  restorePrepared: true
  startTime: "2022-01-06T16:44:53Z"

Synchronize MedusaBackup objects with a Medusa storage backend

To restore a backup taken on a different Cassandra or DSE cluster, you must execute a synchronization task to create the corresponding MedusaBackup object locally.

Choose a backup Custom Resource Definition (CRD) that matches your release.
Create a MedusaTask object in the Kubernetes cluster and namespace where the referenced MissionControlCluster or cassandraDatacenter is deployed.

Define a sync operation in the MedusaTask object:

apiVersion: medusa.missioncontrol.datastax.com/v1beta1
kind: MedusaTask
metadata:
  name: sync-backups-1
  namespace: project-4vcx
spec:
  cassandraDatacenter: demo-dc1
  operation: sync

Reconciliation is triggered by the MedusaTask object creation, executing the following operations:

List the backups in the remote storage system.
Create backups that are missing locally.
Delete locally any backups that are missing in the remote storage system.

As reconciliation completes, the MedusaTask object status is updated with the finish time and the name of the pod that was used to communicate with the storage backend:

...
status:
  finishTime: '2022-07-26T08:15:55Z'
  finished:
    - podName: demo-dc2-default-sts-0
  startTime: '2022-07-26T08:15:54Z'
...

Purge backups

The Medusa resource type has two storageProperties settings to control the retention of backups:

maxBackupAge
maxBackupCount

These settings are used by the medusa purge operation to determine which backups to delete. See the backup CRDs and their properties for your release.

Mission Control schedules the purge operation on all Cassandra or DSE nodes in the datacenter and applies Medusa’s purge rules on the data per node. Upon purge completion, the MedusaTask object status is updated with the finishTime and the purge statistics of each node:

status:
  finishTime: '2022-07-26T08:42:33Z'
  finished:
    - nbBackupsPurged: 3
      nbObjectsPurged: 814
      podName: demo-dc2-default-sts-1
      totalObjectsWithinGcGrace: 542
      totalPurgedSize: 10770961
    - nbBackupsPurged: 3
      nbObjectsPurged: 852
      podName: demo-dc2-default-sts-2
      totalObjectsWithinGcGrace: 520
      totalPurgedSize: 10787447
    - nbBackupsPurged: 3
      nbObjectsPurged: 808
      podName: demo-dc2-default-sts-0
      totalObjectsWithinGcGrace: 444
      totalPurgedSize: 10903221
  startTime: '2022-07-26T08:37:48Z'

The purge task generates a sync task to delete the purged backups from the Kubernetes storage.

References

See the release-specific list of restore Custom Resource Definitions (CRD) files and properties for:

MedusaRestoreJob
MedusaTask

Find additional documentation and sources at Medusa GitHub.