Data backup, recovery, and migration for Kubernetes

The following directions will guide you through a Data Control Tower (DCT) backup, recovery, and migration for Kubernetes. They can be used for a lift and shift or a blue-green deployment (described in the Example deployment scenarios below), but are also standardized and thus, can be applied in one-off scenarios.

This page refers to the two DCT servers as source and target.

Prerequisites

  1. The source DCT server is up and running.

  2. The target DCT server is installed in a separate Kubernetes cluster.

    1. It is the same version as the source DCT server when the backup is taken.

  3. Ability to share backup files from source to target environments.

  4. Sufficient access to perform various commands on both the source and target clusters.

Backup steps

Download dct-support-tools from the downloads site. Once the file is downloaded, untar the file and open the backup-restore directory to find the backup_restore.sh and appliance_backup_restore.sh scripts.

Copy 
% tar -xzvf dct-support-tools-02132025.tar.gz
% ./
% ./backup-restore/
% ./backup-restore/README
% ./backup-restore/backup_restore.sh
% ./backup-restore/appliance_backup_restore.sh
% ./support-bundle/
% ./support-bundle/collect_bundle.sh
% ./support-bundle/README
% ./VERSION
% cd backup-restore

Transfer the backup_restore.sh script to the machine where you have permissions to execute oc commands against the DCT pods. You must install the bash shell to run the script, as well as the zip/unzip utilities.

Make sure DCT on Kubernetes is running and execute the backup_restore.sh script. The script may need to run with sudo if root permissions are needed to run the kubectl commands. Use the -n flag, pass the namespace (if not using the default dct-services), and redirect the script output to the desired backup location. The size of the backup depends on the size of the DCT data to be backed up but is typically in the 1GB to 10GB range. The script may take several minutes to execute and does not print anything to the console in case of success.

% /bin/bash backup_restore.sh -n dct-services > dct-backup1.zip

Restore steps

Execute the backup_restore.sh script with the -r flag specifying the path to the backup file:

% /bin/bash backup_restore.sh -n dct-services -r dct-backup1.zip

The operations takes several minutes.

Additional environment configuration

The HELM chart’s values.yaml contains information specific to your environment, such as certificates, hostname, or resource limits. You can update this information before or after the migration process. The standard installation and configuration process can be followed to update these values.

Example deployment scenarios

An example of a lift and shift deployment could be:

  1. Backup the running source server pre-upgrade.

  2. Upgrade the source server to the desired version and confirm functionality.

  3. Backup the source server post-upgrade.

  4. Install a new target server as the same source server’s post-upgrade version.

  5. Restore the source post-upgrade backup to the target server.

  6. Restart the target services and confirm functionality.

  7. Shutdown the source server or maintain it for further testing.

An example of a blue-green deployment could be:

  1. Backup the running source server.

  2. Install a new target server with the same source server’s version.

  3. Restore the source backup to the target server.

  4. Restart the target services and confirm functionality.

  5. Upgrade the target server to the newer version and confirm functionality.

  6. Redirect traffic to the target server.

  7. Shutdown the source server or maintain it for a future blue-green deployment.