Data backup, recovery, and migration for Kubernetes

The instructions below outline how to back up, recover, and migrate Data Control Tower (DCT) in Kubernetes environments. These steps support lift-and-shift or blue-green deployment strategies, as well as one-off migration scenarios. The two DCT installations are referred to as source (initial environment) and target (destination environment).

Prerequisites

  1. The source DCT server must be operational.

  2. The target DCT installation must be deployed in a separate Kubernetes cluster and running the same DCT version as the source at the time of backup.

    1. Note: A separate cluster is required to avoid conflicts in networking, service discovery, and persistent volume claims that may arise when running two DCT instances within the same cluster. This isolation helps ensure clean separation of environments during migration and recovery operations.

  3. Both source and target must run DCT version 2025.2.0.0 or later—backup and restore via the scripted solution is only supported beginning with version 2025.2.0.0.

  4. Backup files must be shareable between the source and target environments.

  5. You must have sufficient access to run kubectl (or oc) commands in both clusters.

Backup steps

  1. Download the dct-support-tools tarball from the Delphix download site.

  2. Extract the tarball and navigate into the backup-restore directory. Key files include:

    1. backup_restore.sh

    2. appliance_backup_restore.sh

  3. A README with version-specific details.

  4. Transfer the backup_restore.sh script to a host that has kubectl access to the DCT pods. Required tools include:

    1. bash

    2. zip / unzip

  5. Make sure the source DCT Kubernetes cluster is active and run:

Copy 
python
Copy code
/bin/bash backup_restore.sh -n <namespace> > dct-backup.zip 

Replace <namespace> as needed (defaults to dct-services). Output is typically silent on success. The backup size usually ranges from 1 GB to 10 GB and takes a few minutes to complete. This backup file contains all the necessary information to restore your DCT install in the new environment, except for the environment configuration information.

Restore steps

Before restoring, transfer the backup file (dct-backup.zip) to a host with access to the target Kubernetes cluster. If your source and target environments are within the same cluster (but using different namespaces), make sure the script is executed from a context that targets the correct namespace.

Once the file is in the correct environment, run the restore command:

Copy 
/bin/bash backup_restore.sh -n <namespace> -r dct-backup.zip

Replace <namespace> with the target DCT namespace (defaults to dct-services if not specified).

The restoration process typically completes within a few minutes.

In a migration scenario from a Kubernetes DCT deployment to a DCT appliance VM deployment, use these restore steps.

Additional environment configuration

The DCT Helm chart values.yaml file includes configuration settings such as certificates, hostname, and resource limits. They are critical to ensure your installation is secure and performant. These values are not managed by the restore process and must be managed manually. You may update this file either before or after the migration.

It’s recommended that you configure these values as expected before beginning the migration process to minimize downtime.

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.