Data backup, recovery, and migration for Kubernetes

This page describes how to back up and recover Data Control Tower (DCT) in Kubernetes environments, as well as how to migrate between clusters or to a DCT appliance. The script-based backup supports lift-and-shift and 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).

Choose your backup approach

DCT on Kubernetes supports two backup approaches. Choose based on your recovery needs:

Approach

Best for

What it captures

Portability

Kubernetes-native volume snapshots (CSI / Velero / cloud provider tools)

Fast recovery within the same cluster or storage backend. Captures all persistent state in a single coordinated snapshot.

All DCT persistent volumes — PostgreSQL database, encryption keys, application state.

Tied to your storage backend and cluster. Cannot restore to a different cluster type or to an appliance.

Script-based backup (backup_restore.sh)

Migrating to a different cluster, a different namespace, or to an appliance. Maintaining portable, off-cluster backups. Blue-green or lift-and-shift deployments.

Full PostgreSQL database (all DCT application data) and encryption keys — accounts, passwords, access groups, engine registrations, dSource/VDB metadata, compliance configurations, bookmarks, operation history. Does not include Helm chart configuration (certificates, hostname, resource limits).

Portable across any DCT Kubernetes or OpenShift installation. Can also be used to restore to a DCT appliance.

Delphix recommends configuring at least one of these approaches at installation time. If your cluster already uses a backup tool like Velero or a cloud provider's managed backup service, extending that coverage to the DCT persistent volumes is the simplest path.

Support notice: Delphix supports the script-based backup solution described on this page. Kubernetes-native volume snapshot approaches (CSI drivers, Velero, cloud provider backup tools) are third-party solutions. Delphix can provide general guidance on which volumes must be protected, but cannot provide direct support for configuring or troubleshooting those tools. Refer to your platform and tool vendor documentation for assistance.

If you are using an external database, Kubernetes-native snapshots must still capture the encryption key volumes (gateway-data, masking-data, virtualization-app-data), and the external database must be backed up separately using your database provider's tooling. See External database support for details.

Script-based backup

The following prerequisites, backup steps, restore steps, and additional environment configuration all apply to the script-based backup approach (backup_restore.sh).

Prerequisites

The following prerequisites apply to the script-based backup and restore process:

  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.

    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. Script-based backup and restore is only supported from version 2025.2.0.0 onward.

  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.

  3. 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

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

    Copy 
    /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 is recommended that you configure these values as expected before beginning the migration process to minimize downtime.

Kubernetes-native volume snapshots

In addition to the script-based backup described above, Kubernetes-native volume snapshot capabilities can be used to back up DCT persistent data. This approach uses your cluster's CSI (Container Storage Interface) driver and the Kubernetes VolumeSnapshot API to capture all DCT persistent volumes as a coordinated group in a single snapshot operation.

Which volumes to capture

The following DCT persistent volumes must all be included in the snapshot. Your backup tool should capture these together in a single snapshot operation to ensure consistency:

Persistent volume

Contents

Required?

gateway-data

Encryption key for sensitive application data

Yes — without this, database backups cannot be decrypted

masking-data

Encryption key for masking service data

Yes

virtualization-app-data

Encryption key for virtualization service data

Yes

gwdatabase-data

PostgreSQL database (all DCT application metadata)

Yes, unless using an external database

If you are using an external database, the gwdatabase-data volume is not used by DCT. Instead, back up the external database using your database provider's backup tooling. The encryption key volumes (gateway-data, masking-data, virtualization-app-data) must still be captured. A database backup without the corresponding encryption key backups cannot be restored.

The encryption keys in gateway-data, masking-data, and virtualization-app-data do not change after initial creation. They do not need to be snapshotted on the same schedule as the database, but must be available at restore time.

Tooling

Any Kubernetes-native backup tool that supports VolumeSnapshots can be used, including:

  • Kubernetes VolumeSnapshot API (requires a CSI driver that supports snapshots): Kubernetes VolumeSnapshots documentation

  • Velero (backup and restore for Kubernetes resources and persistent volumes): Velero documentation

  • Cloud provider tools such as AWS Backup for EKS, Azure Backup for AKS, or GCP Backup for GKE

Refer to your CSI driver and cloud provider documentation for snapshot scheduling and retention configuration.

When to use the script-based backup instead

The script-based backup described above produces a portable backup file that can be restored to any DCT Kubernetes installation (or migrated to an appliance). Volume snapshots are tied to the storage backend and cluster. If you need cross-cluster or cross-platform portability, use the script-based approach.

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.