How do you set up Vault for high availability and disaster recovery?

Think of Vault HA like a hospital emergency room. There is always one attending physician on duty (active node) making decisions and treating patients (handling requests). Several residents (standby nodes) are in the building, fully equipped and ready to step in if the attending is unavailable (leader election). For disaster recovery, the hospital has partnerships with hospitals in other cities (replication clusters) and keeps complete copies of all patient records (snapshots) in secure off-site storage, so even if the entire building goes down, operations can resume elsewhere.

Vault achieves high availability through leader election where only one node is active at any time and multiple standbys are ready to take over. With integrated Raft storage (the recommended approach since Vault 1.4), Vault nodes form a consensus cluster where the leader handles all writes and copies data to followers. If the leader fails, Raft automatically elects a new leader, usually within seconds. When using Consul as the storage backend, Vault uses Consul's session and locking mechanism for leader election. Standby nodes can either forward requests to the active node (the default) or send HTTP 307 redirects pointing the client to the active node's address.

Under the hood, the Raft consensus protocol needs a quorum (majority) of nodes to be healthy for the cluster to work. In a 3-node cluster, 2 must be up; in a 5-node cluster, 3 must be up. Writes only commit when the leader replicates the log entry to a quorum of followers, which ensures data durability. The unsealing process matters during recovery because each Vault node starts sealed and must be individually unsealed. Auto-unseal using cloud KMS services (AWS KMS, Azure Key Vault, GCP Cloud KMS) removes the manual bottleneck by letting the cloud provider's hardware security modules handle the unseal key. Vault Enterprise extends HA with performance replication (read replicas that serve reads locally) and disaster recovery replication (full cluster replication across regions for failover).

In production, a solid Vault deployment needs multiple layers of protection. The Raft cluster should have 3 or 5 nodes spread across availability zones within a region. Auto-unseal should be configured so node restarts and scaling events do not need manual intervention. Automated snapshots using vault operator raft snapshot save should run on a schedule (every 1-4 hours) and be stored in a separate system like S3 with versioning and cross-region replication. Monitoring should track seal status, leader elections, storage backend latency, and token expiration rates. Load balancers should use Vault's /v1/sys/health endpoint for health checks, with the right response codes configured (200 for active, 429 for standby, 472 for DR secondary). For multi-region setups, Vault Enterprise's DR replication provides near-zero RPO (Recovery Point Objective) and RTO (Recovery Time Objective) of minutes.

The most dangerous mistake is losing unseal keys and the recovery key at the same time. Without auto-unseal, losing enough unseal keys means your Vault data is permanently encrypted and unrecoverable. Teams must set up secure key distribution, such as storing each key share with a different trusted person or in separate secure storage systems. Another critical pitfall is never testing disaster recovery. Having snapshots is worthless if you have never practiced restoring them to a new cluster under pressure. A subtler Raft issue is split-brain during network partitions, where an isolated leader keeps accepting writes that will be lost when the partition heals and a new leader has already been elected. Setting appropriate Raft timeouts and monitoring for leadership changes helps catch this.