Vault Backup and Restore: A Practical Guide Centered on Raft Snapshots

When you run Vault on Integrated Storage (Raft), the first-choice backup mechanism is the official Raft Snapshot feature. It captures a consistent point-in-time snapshot online and offers a clear, well-documented recovery procedure.

This article tackles the points operators most often get wrong — permissions, stop conditions, recovery order, and version compatibility — and is structured so you can quickly check the items frequently tested on Ops-track certifications. The behavior described aligns with the stable specs documented by HashiCorp.

Raft Snapshot Fundamentals and Backup Options

Integrated Storage (Raft) is the storage layer built directly into Vault, with cluster nodes coordinating through Raft consensus. Raft Snapshot is the official way to dump that storage in a consistent form. Capture happens online (the leader provides the consistent view); restore is done during planned downtime.

A snapshot contains the storage-layer data, but not the Unseal keys themselves. Snapshots therefore do not replace key management (Shamir key shares or the KMS configuration backing Auto-Unseal). Recovery still requires the same Unseal mechanism you use normally.

It helps to compare Raft Snapshot against the other common approaches — Consul Snapshot (when using the Consul backend) and VM/filesystem-level backups — so you can make better operational decisions.

• Capture can run on any node — the request is proxied to the leader
• Data is persisted while still encrypted — Vault's seal key is required to use it
• For safety, recovery requires stopping the target cluster and reforming it from a single node

Operating Snapshot Capture: Permissions, Commands, and Scheduling

Snapshots can be captured online. When you run the CLI against any node, the leader internally produces a consistent snapshot. The capture token needs sudo permission (the ability to execute operator functions).

The output is a single, easy-to-handle file. Build rotation, off-site transfer, and integrity verification (hashing) into your runbook. Size scales with data volume and can be reduced via compression.

• Permissions: a token with sudo capability (a root token also works)
• Frequency: every 15 minutes to once a day depending on sensitivity and RPO. At minimum, capture before configuration changes and mass key rotations
• Destination: stage locally, then ship to WORM/S3 or similar. Storage-layer encryption is preserved, but double encryption is recommended

Example of capture, verification, and rotation

# 1) Take it (run from any node; the API proxies to the leader)
export VAULT_ADDR="https://vault.example.com:8200"
export VAULT_TOKEN="s.xxxxxx"   # needs sudo capability

# Save it with the date in the name
vault operator raft snapshot save /var/backups/vault/vault-$(date +%Y%m%d-%H%M%S).snap

# 2) A hash for the integrity check
sha256sum /var/backups/vault/vault-*.snap >> /var/backups/vault/SHA256SUMS

# 3) Compress and ship it offsite (gzip + s3 cp, for example)
ls -1 /var/backups/vault/vault-*.snap | tail -n 1 | xargs -I {} gzip {}
aws s3 cp /var/backups/vault/ s3://vault-bak/ --recursive --exclude "*" --include "*.gz"

# 4) Rotate (delete anything older than 14 days)
find /var/backups/vault -type f -name "*.snap.gz" -mtime +14 -delete

# (optional) Example cron entry: on the hour
# 0 * * * * /usr/local/bin/vault-snapshot.sh >> /var/log/vault-snapshot.log 2>&1

Consistency and Performance Impact, Storage and Encryption Handling

Snapshots are consistent from the Raft leader's perspective, so they never contain half-applied in-flight writes. Capture happens online and only causes a brief CPU/IO bump on top of normal traffic. The safe operational pattern is to avoid peak hours.

The file itself contains data after Vault's storage encryption, so on its own it cannot be decrypted. Recovery requires the same Unseal mechanism — Shamir key shares or KMS permissions for Auto-Unseal. Keep snapshots and key material in separate locations and audit the whereabouts and validity of KMS permissions and key shares regularly.

• Size management: every snapshot is a full backup. Apply compression and generation retention as needed
• Capture impact: briefly consumes leader CPU/IO. Run outside of peak windows
• Verification: rehearse restores in an isolated environment regularly and measure your actual RTO/RPO

Safe Restore Procedure (Single Cluster)

Recovery is a planned-downtime operation. Apply the snapshot to a single node first to form a new leader, then have the remaining nodes join. The target node's Raft data directory must be empty, and Vault must be running but sealed (do not unseal it) so the API can respond. The other nodes stay stopped.

For compatibility, use the same version where possible — at minimum the same major/minor with an equal or newer patch. When the internal format differs between versions, backward compatibility is not guaranteed, so check the official release notes and storage compatibility documentation ahead of time.

• Preconditions: all existing nodes stopped; the target node's Raft data directory emptied
• Vault on the target node is started but sealed (do not unseal)
• The restore command needs a sudo-capable token and the -force flag
• After restore, unseal the target node, then start the others and have them raft join

Raft Snapshot restore flow

Typical restore procedure (example)

# 0) Stop every node (example)
systemctl stop vault   # on every node

# 1) Pick the node to recover into and empty its Raft data directory
rm -rf /opt/vault/data/raft/*

# 2) Start Vault on that node only (it stays sealed)
systemctl start vault
export VAULT_ADDR="https://vault-node-a.example.com:8200"
export VAULT_TOKEN="s.restore-token-with-sudo"

# 3) Apply the snapshot (-force is required)
vault operator raft snapshot restore -force /safe/path/backup.snap

# 4) Unseal (Shamir or auto-unseal)
vault operator unseal   # enter as many keys as the threshold requires

# 5) Start the other nodes one by one and join them to the leader (run on each node)
export VAULT_ADDR="https://vault-node-b.example.com:8200"
vault operator raft join https://vault-node-a.example.com:8200

export VAULT_ADDR="https://vault-node-c.example.com:8200"
vault operator raft join https://vault-node-a.example.com:8200

# 6) Health check
export VAULT_ADDR="https://vault-node-a.example.com:8200"
vault status
vault operator raft list-peers

DR Design and the Role of Snapshots

Snapshots are the cornerstone of offline point-in-time recovery in a DR plan. If you need tighter RPO/RTO, look at online replication features such as Vault Enterprise's DR replication. Offline snapshots are still valuable alongside replication — they cover point-in-time recovery from logical deletes and human error.

Network-isolated storage (off-site / WORM), regular restore drills, and independent custody of key material (Shamir / Auto-Unseal) are the keys to making it actually work.

• RPO: determined by snapshot cadence. Consider 15-60 minute intervals for critical workloads
• RTO: shorten it by automating the restore procedure (IaC / scripts)
• Use replication together with snapshots: online redundancy plus snapshots covers logical failures too

Ops Exam Essentials and Pitfall Checklist

Keep in mind that Raft Snapshot is online-capture / offline-apply by design, and never confuse the restore preconditions: sealed state, empty data directory, and reformation from a single node. Two more frequently tested points: Unseal keys are not in the snapshot, and you need a sudo-capable token.

• Capture can run on any node, but consistency is leader-based
• restore requires -force and sudo permission; target node must be sealed with an empty Raft data directory
• Manage Unseal keys separately — snapshots do not replace key management
• Recovery sequence: start one node → Unseal → have other nodes raft join
• Be careful with version compatibility (same major/minor as a baseline)

Check Your Understanding

Frequently Asked Questions