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) 取得（任意ノードで実行、API はリーダーへプロキシ）
export VAULT_ADDR="https://vault.example.com:8200"
export VAULT_TOKEN="s.xxxxxx"   # sudo 権限付き

# 日付付きで保存
vault operator raft snapshot save /var/backups/vault/vault-$(date +%Y%m%d-%H%M%S).snap

# 2) 整合性チェック用ハッシュ
sha256sum /var/backups/vault/vault-*.snap >> /var/backups/vault/SHA256SUMS

# 3) 圧縮とオフサイト転送（例: gzip + s3 cp）
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) ローテーション（14日超の削除）
find /var/backups/vault -type f -name "*.snap.gz" -mtime +14 -delete

# （任意）cron 設定例：毎時00分
# 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) 全ノード停止（例）
systemctl stop vault   # すべてのノードで実行

# 1) 復旧対象ノードを選定し、Raft データディレクトリを空に
rm -rf /opt/vault/data/raft/*

# 2) 対象ノードのみ Vault を起動（Sealed のまま）
systemctl start vault
export VAULT_ADDR="https://vault-node-a.example.com:8200"
export VAULT_TOKEN="s.restore-token-with-sudo"

# 3) スナップショットを適用（-force 必須）
vault operator raft snapshot restore -force /safe/path/backup.snap

# 4) Unseal（Shamir または Auto-Unseal）
vault operator unseal   # 必要回数のキー入力

# 5) 他ノードを順次起動し、Leader に join（各ノードで実行）
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) ヘルス確認
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