Action required: The Continuous Data UI, API, and CLI are scheduled for end of life. Review the latest migration guidance and start planning your transition to Data Control Tower.
On new engine installations of 2026.5.0.0 and later, the Admin UI opens directly to the Performance Dashboard, and the Manage, Resources, and System menus are unavailable. Engines upgraded from an earlier version keep full Admin UI access. This restriction cannot be changed by customers; contact Delphix Support if you need it lifted temporarily.
Learn more about the Continuous Data end-of-life announcement.
An uncontrolled failover is used when the replication source engine is unavailable, for example after a power failure or a data center outage. Recovery uses a replica that already exists on the target. You cannot send a new replication update from an unavailable source.
During disaster-recovery preparation, record the source and target engine's IP address and UUID. These details are available on the Delphix server setup application.
Recover after a source-engine outage
The target must already contain a received replica of the required dSources and VDBs. Review its last successful replication update to assess the data available for recovery. Changes not received by the target are not available through that replica; see Replication limitations.
The following procedure requires full Continuous Data management UI access on the target. Engines upgraded from an earlier release retain this access. On new installations of 2026.5.0.0 and later, the System and Replication menus are unavailable. If the target has this installation restriction, contact Delphix Support to request temporary management UI access for outage recovery. Customers cannot lift the restriction themselves. If Support enables the required menus temporarily, use the procedure below.
-
On the replication target engine, open System > Replication and click the required replica under Received Replicas.
-
Click Failover. Review the test-failover and permanent-failover options described in Test-failover and failback before confirming the operation.
-
Wait for failover to complete successfully before recovering the environments and datasets.
-
The replicated environments, dSources, and VDBs move into the target engine's live namespace but remain disabled. Complete the platform-specific cleanup and configuration below before enabling them.
-
If the source becomes available again, keep its affected dSources and VDBs disabled while using the recovered objects on the target. Review source preparation and script redirection in Controlled failovers to avoid restarting the same objects on both engines.
Simulate a source outage for a recovery exercise
The following preparation is for a planned recovery exercise, not for an outage that has already occurred. For a reversible failover test without powering off the source, see Test-failover and failback.
-
While the source is available, create a replication profile for the required dSources and VDBs.
-
On the source engine, run that profile by clicking Replicate Now and confirm that replication completes successfully.
-
In the test environment, power off the source engine to simulate its loss, then follow Recover after a source-engine outage.
Recover environments and datasets
The following sections describe the procedures to handle an uncontrolled failover for each data platform:
For SQL Server failovers, remove stale iSCSI persistent targets, target portals, and sessions that still reference the source engine after the failover. For cleanup steps, see SQL server environments and data sources.
Oracle environments and data sources