Vault バックアップ / リストア実務ガイド：Raft Snapshot を中心に

Vault を Integrated Storage（Raft）で運用する場合の第一選択は、公式が提供する Raft Snapshot 機能です。オンラインで一貫性のあるポイントインタイムを取得でき、復旧時も手順が明確です。

本稿は実務で迷いやすいポイント（権限、停止条件、復旧順序、互換性）を押さえつつ、Ops系資格対策で問われやすい要点を短時間で確認できるように構成しています。挙動は HashiCorp 公式ドキュメントの安定的な仕様に基づいています。

Raft Snapshot の前提とバックアップ選択肢

Integrated Storage（Raft）は Vault 本体に内蔵されたストレージで、クラスタ内のノード間で Raft 合意を行います。Raft Snapshot は、このストレージ内容を一貫性のある形でダンプする公式手段です。取得はオンラインで可能（リーダーからの整合取得）で、復旧は計画停止下で実施します。

スナップショットはストレージ層のデータを含みますが、Unseal キー自体は含みません。よってスナップショットは鍵管理（Shamir のキーシェアや Auto-Unseal の KMS 設定）を代替しません。復旧には従来どおりの Unseal 手段が必要です。

比較の基準として、Raft Snapshot と他の一般的な手段（Consul バックエンド時の Consul Snapshot、VM/FS レベルのバックアップ）を並べると運用判断がしやすくなります。

• 取得は任意ノードから実行可能（リーダーにプロキシされる）
• データは暗号化状態のまま保存される（Vault のシール鍵が必要）
• 復旧は安全のため対象クラスタの停止と単一ノードからの再形成が原則

スナップショットの取得運用（権限・コマンド・スケジューリング）

スナップショット取得はオンラインで行えます。CLI から任意ノードに対して実行すると、内部的にリーダーが一貫性のあるスナップショットを生成します。取得用トークンには sudo 権限（operator 機能の実行が可能）が必要です。

保存先は扱いやすい単一ファイルです。ローテーション、オフサイト転送、整合性検証（ハッシュ算出）を運用に組み込みましょう。サイズはデータ量に比例し、圧縮で小さくできます。

• 権限: sudo 権限を持つトークン（root トークンでも可）
• 頻度: 機密度・RPO に応じて 15分〜1日間隔。最低でも構成変更やマスローテーション前に取得
• 取得先: ローカル一時保存→WORM/S3 等へ転送。暗号化はストレージ層で維持されるが二重暗号化を推奨

取得・検証・ローテーションの例

# 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

一貫性と性能への影響、保存と暗号化の扱い

スナップショットは Raft リーダー視点の一貫性を持つため、途中書き込みによる中途半端な状態は含まれません。生成はオンラインで行われ、通常のトラフィックに対して短時間の CPU/IO 負荷上昇が見られる程度です。高負荷時間帯を避ける運用が無難です。

ファイル自体は Vault のストレージ暗号化後のデータを含むため、単独では平文化できません。復旧には既存の Unseal 手段（Shamir のキーシェアまたは Auto-Unseal の KMS 権限）が必須です。よってスナップショットと鍵情報は分離保管し、KMS 権限やキーシェアの所在・有効性を定期確認してください。

• サイズ管理: スナップショットはフルバックアップ。必要に応じて圧縮と世代管理
• 取得時の影響: リーダーの CPU/IO を短時間消費。ピーク外に実施
• 検証: 定期的に隔離環境でのリストア演習を実施（RTO/RPO の実測）

リストアの安全な手順（単一クラスタを対象）

復旧は計画停止のうえで、まず 1 台のノードにスナップショットを適用して新しいリーダーを形成し、その後に他ノードを join させます。対象ノードの Raft データディレクトリは空であること、Vault はシール状態（Unseal しない）で API 応答が可能な状態であることが前提です。他ノードは停止しておきます。

互換性は同一バージョン（少なくとも同一メジャー/マイナー、同一または新しめのパッチ）を推奨します。バージョン間の内部フォーマット差分がある場合、下位互換が保証されない可能性があるため、公式のリリースノートとストレージの互換性記載を事前に確認してください。

• 前提: すべての既存ノード停止、復旧対象ノードの Raft データディレクトリを空にする
• 対象ノードの Vault は起動済みだがシール状態（unseal はしない）
• restore の実行には sudo 権限トークンと -force 指定が必要
• 復旧後、対象ノードを Unseal→他ノードを起動して raft join

Raft Snapshot リストアの流れ

典型的なリストア手順（例）

# 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 設計とスナップショットの役割

スナップショットは災害復旧（DR）におけるオフライン・ポイントインタイム復旧の要です。一方で、RPO/RTO をさらに厳しくしたい場合は、Vault Enterprise の DR レプリケーションなどオンライン複製機能を検討します。オフラインのスナップショットはレプリケーションの補完としても有効です（論理削除・誤操作からの時点復旧）。

ネットワーク分離された保管（オフサイト/WORM）、復旧演習の定期実施、キー管理（Shamir/Auto-Unseal）の独立保全が実現のキーポイントです。

• RPO: スナップショット間隔で決定。重要運用は 15〜60 分間隔を検討
• RTO: 復旧手順の自動化（IaC/スクリプト化）で短縮可能
• レプリケーション併用: オンライン冗長 + スナップショットで論理障害にも対応

Ops 試験向けの要点と落とし穴チェックリスト

Raft Snapshot はオンライン取得・オフライン適用という設計を押さえ、復旧前提（シール状態・空ディレクトリ・単一ノードからの再形成）を誤らないことが重要です。Unseal キーはスナップショットに含まれない点、sudo 権限トークンが必要な点も頻出です。

• 取得は任意ノードから可能だが整合性はリーダー基準
• restore には -force と sudo 権限が必要、対象ノードはシール状態で Raft データ空
• Unseal キーは別管理。スナップショットは鍵管理の代替にならない
• 復旧は 1 台で起動→Unseal→他ノードを raft join
• バージョン互換は慎重に（同一メジャー/マイナーを基本）

問題で確認

よくある質問