Backup and restore

This topic provides an overview, limitations, important considerations, and various use cases to perform the backup and restore of a DCT virtual appliance. The script-based backup solution uses the same approach as DCT on Kubernetes and OpenShift — there is no UI-based backup for the DCT appliance. To begin the process, choose whether to backup and restore using a script or using API calls.

Overview

The DCT appliance has a script-based backup and restore solution which can be used to take point-in-time backups of the DCT application metadata. This includes all data in the DCT application, such as the list of accounts along with their passwords, access groups, registered engines, hyperscale orchestrators, metadata on connected dSources, VDBs, bookmarks, compliance jobs, compliance connectors, etc.

This page will describe how to backup and restore a DCT appliance engine, for cases where you might need to:

  • Recover from a failure of underlying hardware.

  • Recover from loss or corruption of configurations due to user error.

  • Migrate the DCT appliance to a different VM, hypervisor, data center, etc.

  • Create a copy of the DCT appliance to test a new version or configuration without affecting the primary instance.

Choose your backup approach

DCT appliances support two backup approaches. Choose based on your recovery needs:

Approach

Best for

What it captures

Portability

Platform snapshots (VM-level)

Fastest recovery to the same or equivalent VM. No component coordination required.

Everything — application state, encryption keys, network and storage configuration, TLS certificates, system users.

Tied to your hypervisor or cloud platform. Cannot restore to a different platform or DCT version.

Script-based backup (appliance_backup_restore.sh or API calls — no UI)

Migrating to a different VM, hypervisor, or data center. Restoring to a newer DCT version. Maintaining portable, off-platform backups.

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 infrastructure configuration: network settings, storage config, TLS certificates, or system users.

Portable across any DCT appliance. Supports cross-version restores (backup version ≤ target version).

Delphix recommends configuring at least one of these approaches at installation time. Both approaches can be scheduled on a recurring cadence to maintain regular recovery points. If your organization already uses platform-level backup tooling (such as VMware HA, AWS Backup, or Azure Backup), extending that coverage to the DCT appliance is the simplest path.

For environments that require both platform portability and infrastructure-level recovery, use both approaches: platform snapshots for fast same-platform recovery, and the script-based backup for cross-platform portability.

Platform snapshots (VM-level backup)

In addition to the script-based backup and restore solution described on this page, DCT appliances can be backed up using platform-native VM snapshot capabilities. Because a VM snapshot captures the entire appliance — including the PostgreSQL database, application state, and encryption keys — there is no need to coordinate separate backups of individual components.

Support notice: Delphix fully supports the script-based backup and restore solution (script and API) described on this page. Platform snapshot approaches (VMware, AWS, Azure, OCI, Hyper-V) are provided by third-party hypervisor and cloud platforms. Delphix can provide general guidance on when and how to use platform snapshots for DCT, but cannot provide direct support for configuring or troubleshooting those tools. Refer to your platform vendor documentation for assistance.

Supported platforms

Platform

Snapshot method

Vendor documentation

VMware ESXi

VM snapshots or vSphere Replication

vSphere VM snapshots

AWS EC2

EBS volume snapshots or AWS Backup

EBS snapshots

Microsoft Azure

Azure VM snapshots or Azure Backup

Azure VM backup

Oracle Cloud (OCI)

Boot/block volume backups

OCI block volume backups

Hyper-V

Hyper-V checkpoints or Windows Server Backup

Hyper-V checkpoints

Planning

  • Consistency: Delphix requires the hypervisor to take crash-consistent snapshots across all DCT storage volumes. This might require shutting down the instance before taking the snapshot. Consult your hypervisor's documentation for best practices.

  • Scope: Both the script-based backup solution and VM snapshots capture the full PostgreSQL database (all DCT application data). The difference is that a VM snapshot additionally captures infrastructure configuration (network settings, storage config, TLS certificates, system users) that the script-based backup excludes. This means a VM snapshot restore returns the appliance to the exact state at the time of the snapshot, while a script-based backup restore requires reconfiguring the appliance infrastructure via the setup wizard.

  • Schedule: Configure your platform's snapshot schedule based on your recovery point objective (RPO). More frequent snapshots reduce potential data loss but consume more storage. Refer to your platform's documentation for scheduling and retention policies.

  • When to use the script-based backup instead: The script-based backup solution is portable across appliances and supports restoring to a different VM, a different hypervisor, or a newer DCT version. VM snapshots are tied to the platform and typically restore to the same (or an equivalent) VM. If you need cross-platform portability or version-upgrade restores, use the script-based solution.

Limitations

  • DCT appliance setup information such as network, storage, time, registration, system users, and TLS certificates are not included in the backup.

  • DCT backups can only be used to restore the DCT application itself and do not protect against failure or loss of data of the connected engines or hyperscale orchestrators.

Important considerations

Backup

  • The DCT backup may include sensitive data such as passwords to connect to engines, API keys to connect to hyperscale orchestrators, and personally identifiable information. While the data is encrypted in transit, make sure that you store the backup in an appropriate location. Make sure that the backup location adheres to your company policy on access control and encryption at rest. It is a best practice to perform the backup operation from a dedicated server, and not from an operator machine. For this reason, the DCT appliance does not provide a web user interface for the backup but mandates the use of API calls scripting.

  • A backup operation can be taken while the DCT application is in use but has a light impact on the performance of the application, so expect increased latency to API and UI experience during the operation.

  • The duration of the operation depends on the size of metadata to be included in the backup and the performance of the system, but usually ranges from 1 to 10 minutes. The size of the produced backup file also depends on the size of the metadata, typically ranging from 1GB to 10GB.

Restore

  • Restoring from a backup is a destructive operation. All DCT application data on the appliance onto which the restore operation is performed will be permanently deleted.

  • The DCT appliance onto which the restore operation is performed must have been setup via the setup wizard. As indicated above, the setup configuration information (system user, network, time, storage, TLS certificates, registration) is not part of the DCT backup and will not be restored.

  • It can be the same or a different DCT appliance than the appliance from which the backup was taken. If you are restoring a backup to a different DCT appliance, and the original DCT appliance is still running, at the end of the restore operation both DCT appliances will be pulling data (and controlling) the registered engines and hyperscale orchestrators.

  • The DCT appliance onto which the restore operation is performed can have a different system confirmation as long as the following requirements as satisfied:

    • The metadata disk size must be greater than the size of the metadata in the backup. Only the effectively used data matters.

    • Network setup (network interfaces, DNS resolvers) must allow DCT to connect to registered engines and hyperscale orchestrators, or DCT would not work properly post restore.

    • The DCT appliance must be greater or equal to the backup version (i.e. the version of the DCT appliance when the backup was taken). If the version of the DCT appliance is greater than the backup version, the restore process will automatically upgrade the backup data to the DCT appliance version. In other words, at the end of the restore operation the DCT appliance version will always be the same DCT appliance version before the restore operation, regardless of the backup version.

Use case scenarios

Backup and restore onto the same DCT appliance after a manual error

This use case covers a scenario where a DCT administrator created a regular task, for instance a cronjob, to take a backup of the DCT nightly and retain the most recent 10 entries. The storage requirement will be 10 times the size of the DCT backup, which is often between 1GB and 10GB. The backup process runs when DCT is running, but is scheduled at night to minimize the impact on UI and API latency of users activity.

The administrator later notices a script they use has a defect, which has now deleted the access group configuration in their DCT instance. Since reconstructing them manually is time consuming, and they have a recent backup, they choose to restore from the most recent backup.

With the DCT appliance is still running, they run the restore script and observe that DCT, including the access group configurations, are back to the exact state they were in when the backup was taken.

They notify all DCT users that any action taken on DCT since the last backup time might have been lost. In particular, DCT bookmarks created since the last backup are no longer present in DCT.

Backup and restore onto the same DCT appliance after a hardware failure

Consider this scenario to have the same backup process as the previous scenario, nightly backups of the DCT appliance. This time the DCT administrator is notified by the hypervisor administrator that the storage array used to store the DCT appliance virtual machine had a failure, and the virtual machine is in a failed state.

The hypervisor administrator offers to provision a new virtual machine with the same configuration as the original virtual machine (same hostname, IP address, etc.). The DCT administrator uses the initial setup wizard to configure the DCT appliance setup, selecting the appropriate settings for network interfaces, storage, TLS configuration. The DCT administrator disregards the bootstrap API key generated during initial setup, as they will immediately restore from the DCT backup.

As soon as initial setup has completed, the DCT administrator runs the restore script against the latest available backup, and DCT is restored to the state of that backup.

They notify all DCT users that any action taken on DCT since the last backup time might have been lost. In particular, DCT bookmarks created since the last backup are no longer present in DCT.

Testing a new DCT version

This scenario has the DCT administrator evaluating a new version of the DCT appliance to self-educate on new features, without disrupting current users. They provision a new virtual machine for that purpose, and install a more recent DCT appliance version.

The DCT administrator uses the initial setup wizard to configure the new DCT appliance. Then they take a backup of the original DCT appliance and immediately restore it onto the new DCT appliance.

At the end of the restore operation, both DCT appliances are pulling data from, and controlling all registered engines. The DCT administrator learns the new features and differences in the DCT appliance version, and tears down the new DCT appliance when the testing is complete.