12.2 Disaster Recovery (DR) Vault & PADR Replication Architecture

12.2 Disaster Recovery (DR) Vault & PADR Replication Architecture

Quick Answer: The CyberArk Disaster Recovery (DR) Vault operates as an active-passive warm standby server. While the Primary Vault is operational, the DR Vault's PrivateArk Server service is strictly stopped, while its CyberArk Disaster Recovery (PADR) service runs continuously, pulling database and Safe changes unidirectionally over TCP port 1858. Parameters in PADR.ini—including CheckSyncInterval, EnableFailover, and FailoverMode—govern replication frequency and failover behavior. To prevent catastrophic split-brain conditions, manual failover (EnableFailover=No) is strongly recommended across WANs. When recovering from a disaster, administrators must execute a strict failback synchronization workflow, reversing replication to push newly rotated credentials back to the restored Primary Vault before restarting primary services.

---

DR Vault Architecture & Active-Passive Standby Principles

Privileged Access Management represents Tier 0 infrastructure; any disruption to the Digital Vault halts administrative operations and enterprise automation. CyberArk addresses business continuity through dedicated Disaster Recovery (DR) Vaults deployed in secondary datacenters or isolated cloud regions.

The Single Active Vault Rule

A foundational architectural rule tested on the PAM-DEF exam is that only one Digital Vault can be active at any given time within a replication environment:

• Primary Vault State: The PrivateArk Server service (PrivateArk Database and PrivateArk Server) is Started and listening on TCP port 1858. The local CyberArk Disaster Recovery service is Stopped.
• DR Vault State: The PrivateArk Server service is Stopped (configured with Startup type: Manual). The CyberArk Disaster Recovery service (PADR.exe) is Started (configured with Startup type: Automatic), executing continuous replication cycles.
• Risk of Non-Compliance: If the PrivateArk Server service is inadvertently started on both Vaults simultaneously, external components may write transactions to both nodes, resulting in divergent databases, desynchronized credentials, and data corruption.

---

PrivateArk Disaster Recovery (PADR) Replication Mechanics

The CyberArk Disaster Recovery service (PADR.exe) is a background replication client installed on the DR Vault host. It communicates with the Primary Vault using the native PrivateArk protocol over TCP port 1858.

Synchronized Data Components

During each replication cycle, the PADR engine synchronizes four critical layers:

1. Vault Database Engine: Replicates relational tables storing user accounts, safe permissions, platform definitions, active session tickets, and audit trails.
2. Encrypted Safe Objects: Transfers newly created or updated password objects, SSH private keys, and session recording metadata residing on the storage volume (D:\PrivateArk\Safes\).
3. Cryptographic Key Containers: Maintains synchronized server keys, ensuring the DR Vault can decrypt Safes upon promotion without requiring manual key transfers.
4. Database Transaction Logs: Incremental transaction logs are committed directly to the DR database to preserve ACID compliance.

Authentication and Authorization

PADR authenticates to the Primary Vault using a dedicated built-in service user named DR:

• The credentials for DR are encrypted in C:\Program Files (x86)\PrivateArk\PADR\Conf\user.ini using CreateCredFile, bound to the DR server's machine hardware keys.
• The Primary Vault verifies that the replication request originates from an authorized IP address explicitly listed in the BackupServers parameter in the Primary Vault's DBParm.ini.

---

PADR.ini Configuration & Operational Parameters

The PADR engine is configured via PADR.ini, located in C:\Program Files (x86)\PrivateArk\PADR\Conf\PADR.ini:

[DisasterRecovery]
ServerVaultName=PrimaryVault
ServerVaultIP=10.0.1.10
ServerVaultPort=1858
CheckSyncInterval=60
EnableFailover=No
FailoverMode=Manual
EnableMaintainDB=Yes

Detailed Parameter Definitions

• CheckSyncInterval: The time interval, in seconds, between consecutive replication cycles. Defaults to 3600 seconds, but production environments typically set this to 60 to 300 seconds for an aggressive Recovery Point Objective (RPO).
• EnableFailover: Accepts Yes or No. Determines whether the PADR service is authorized to initiate automatic failover when the Primary Vault is unreachable.
• FailoverMode: Configured as Auto or Manual. Governs criteria evaluated before promoting the DR Vault.
• EnableMaintainDB: Accepts Yes or No. When set to Yes, PADR executes database index maintenance during replication cycles.
• padr.log: Located in PADR\Logs\padr.log. Tracks replication heartbeats, synchronization durations, byte counts transferred, and error codes.

---

Split-Brain Risk & Failover Topologies

A split-brain condition occurs when network disruption isolates the Primary and DR datacenters, causing the DR Vault to conclude the Primary has failed. If automatic failover is active, the DR Vault starts its PrivateArk Server service while the Primary Vault continues running. Components in Datacenter A write to the Primary Vault, while components in Datacenter B write to the DR Vault, creating two divergent databases that cannot be automatically merged.

Because WAN links frequently experience transient disconnects, CyberArk's best practice for multi-datacenter environments is Manual Failover (EnableFailover=No):

Component Redirection via Vault.ini

When failover occurs, external components (PVWA, CPM, PSM) redirect their TCP 1858 traffic via the ServerIP parameter in each component's client-side Vault.ini file:

[Vault]
ServerVaultName=EnterpriseVault
ServerIP=10.0.1.10,10.0.2.10
ServerPort=1858
Timeout=30

Components attempt connection to the primary IP (10.0.1.10). If no response is received within the Timeout threshold, the client library automatically redirects socket connections to the secondary IP (10.0.2.10). Alternatively, organizations use automated DNS alias or network Virtual IP (VIP) switching.

---

Failback Synchronization & Recovery Workflow

Following a disaster, the DR Vault may operate as the primary production Vault, rotating credentials and recording sessions. Restoring the original Primary Vault requires a strict failback workflow:

1. Step 1 — Isolate the Restored Primary Vault: When the restored Primary Vault comes online, verify that the PrivateArk Server service remains strictly STOPPED to prevent split-brain.
2. Step 2 — Reverse Replication Direction in PADR.ini: On the original Primary Vault, edit PADR.ini. Set ServerVaultIP to the IP address of the currently active DR Vault. Configure the Primary Vault to behave temporarily as a replication client pulling data from the DR Vault.
3. Step 3 — Execute Full Synchronization: Run PADR.exe /replicate on the original Primary Vault. Monitor padr.log until message PADR0022I Replication completed successfully confirms that all database records and Safe files created during the DR period have been replicated back to the Primary Vault.
4. Step 4 — Deactivate the DR Vault: Once synchronization is confirmed, stop the PrivateArk Server service on the DR Vault host.
5. Step 5 — Start the Primary Vault: Start the PrivateArk Server service on the original Primary Vault and verify component connectivity over TCP 1858.
6. Step 6 — Restore Standard DR Standby State: On the DR Vault, revert PADR.ini to point back to the Primary Vault and start the CyberArk Disaster Recovery service to resume normal standby replication.