This page describes how to back up and recover Data Control Tower (DCT) in OpenShift 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. This page refers to the two DCT servers as source and target.

Choose your backup approach

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

Approach

Best for

What it captures

Portability

OpenShift-native volume snapshots (OADP / CSI / 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 OpenShift or Kubernetes 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 OADP (OpenShift API for Data Protection) 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. OpenShift-native volume snapshot approaches (OADP, CSI drivers, 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, OpenShift-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

  1. The source DCT server is up and running.

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

  3. Both source and target run DCT version 2025.2.0.0 or later.

  4. The target does not run an earlier DCT version than the version that created the backup.

  5. For a backup created before the PostgreSQL 18 upgrade, the target runs DCT 2026.5.0. The target database image must contain the migration script, and the automated database migration step must be enabled.

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

  7. Sufficient access to perform oc commands on both the source and target clusters.

  8. All required DCT services have a running, reachable container. Resolve unavailable services and restart loops before starting a restore. The AI control and AI execution services are optional.

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.

% 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 tar, zip, and unzip utilities.

Make sure DCT on OpenShift 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 oc 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

Before changing the target installation, the tool verifies that the required services are reachable and that the backup is compatible with the target. The tool does not modify the installation if a compatibility or preflight check fails.

A same-version restore typically completes within a few minutes. A restore from a PostgreSQL 14 backup to DCT 2026.5.0 runs an automatic database conversion that can take approximately 15 to 90 minutes. The tool might not display progress during the conversion.

Restore a backup created before the PostgreSQL 18 upgrade

DCT 2026.5.0 is the bridge release for backups created before the PostgreSQL 18 upgrade. To prepare such a backup for use with a later DCT release:

  1. Deploy or upgrade the target installation to DCT 2026.5.0.

  2. Confirm that all required DCT services are running and reachable.

  3. Restore the backup by using the preceding restore command.

  4. Allow the automatic database conversion and ordered service restart to finish. This process can take approximately 15 to 90 minutes without displaying progress.

  5. Verify that the restored DCT installation is operational.

  6. Create a new backup from DCT 2026.5.0. Use this backup when restoring to a later DCT release.

Recover from a failed restore

Read the failure message before running the restore again. The message describes the state of the installation and provides the appropriate recovery action:

  • If the database was not replaced, correct the reported problem and run the restore again. The original database remains intact.

  • If the database was replaced, do not run the restore again. Follow the recovery instructions in the message, including any steps to restart services or clear maintenance mode.

AI provider credentials

New backups include the AI control service encryption key, so stored AI provider credentials survive a restore. The backup and restore tool skips the AI control and AI execution services when they are not deployed.

Backups created before AI encryption key support do not contain this key. Re-enter the AI provider credentials after restoring one of these backups.

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.

OpenShift-native volume snapshots

In addition to the script-based backup described above, OpenShift-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, which is fully supported in OpenShift, 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 OpenShift-compatible backup tool that supports VolumeSnapshots can be used, including:

  • OpenShift API for Data Protection (OADP): Red Hat's supported backup solution, built on Velero. OADP documentation

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

  • Cloud provider tools such as AWS Backup for ROSA, Azure Backup for ARO, or equivalent managed OpenShift backup services

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

Last updated
Oct 8, 2026