Vault Raft Snapshotで実現するバックアップとリストア運用

Vaultの統合ストレージ（Raft）は、クラスタの一貫した状態をスナップショットとして取得できます。ダウンタイム最小で取得でき、障害時の復旧や移行に有効です。

この記事では、実務で使えるコマンドと順序に絞って解説し、Ops系資格対策ポイントも併記します。

Raft Snapshotの基礎と安全性

Vaultの統合ストレージはRaftで複数ノードにレプリケーションされます。スナップショットはリーダーの適用済み状態を元に作成されるため、整合性が取れたバックアップです。コマンドはどのノードに対しても実行できますが、内部でリーダーへフォワードされます。

スナップショットにはVaultのストレージ状態全体（シークレット、ポリシー、認証バックエンド設定、名前空間、レプリケーションのメタなど）が含まれます。サーバ設定ファイル（vault.hcl）やTLS証明書・鍵などは含まれません。スナップショット自体は機密扱いとし、アクセス制御・暗号化・整合性検証を行って保管してください。

復元時は元のUnsealキー（シャード）が必要です。スナップショットを入手してもUnsealキーがなければデータを開封できません。バージョン互換性は厳密ではなく、作成元と同一か新しめの互換バージョンへの復元が安全です。

• 取得はオンラインで可能（通常、ダウンタイム不要）
• 任意ノードへ実行してもリーダーが処理（フォワーディング有効時）
• スナップショットはストレージ状態のみ。設定ファイルや証明書は別管理
• 復元には元のUnsealキーが必要
• バージョン互換性は限定的。同一メジャー内を基本とする

基本確認コマンド（リーダー確認とピア状況）

export VAULT_ADDR=https://vault.example.com:8200
export VAULT_TOKEN=s.xxxxx  # sudo権限のあるトークン

# リーダー確認
vault status | egrep 'HA Mode|HA Cluster|Active Node Address'

# Raftピアの確認
vault operator raft list-peers

バックアップ手順（スナップショット取得）

平常時バックアップは次の順で実施します。1) ピアとヘルス確認、2) スナップショットを安全な一時領域へ保存、3) ハッシュ計算、4) リテンションポリシーに従いローテーション、5) 監査ログに記録。

スナップショット作成はリーダー上で整合性点を切り出します。大規模環境ではI/O時間がかかるため、取得先ボリュームの空き容量とスループットを事前確認してください。

• 事前チェック: vault status と raft list-peers が安定していること
• 取得先の空き容量を確保（圧縮前サイズ≒使用データ量の目安）
• ハッシュとメタ情報（作成時刻・作成ノード・Vaultバージョン）を併せて保管
• 運用時間帯はレイテンシを監視（監視閾値を一時的に緩和する場合あり）

スナップショット取得と検証の例

# 取得
SNAP_DIR=/var/backups/vault
SNAP_FILE=${SNAP_DIR}/vault-raft-$(date +%Y%m%d-%H%M%S).snap
mkdir -p "$SNAP_DIR"

vault operator raft snapshot save "$SNAP_FILE"

# 整合性検証（ハッシュ）
sha256sum "$SNAP_FILE" | tee -a ${SNAP_DIR}/SHA256SUMS

# メタ情報を記録
{
  echo "created_at=$(date -Is)"
  vault version | xargs echo "vault_version="
  vault operator raft list-peers -format=json | jq -r '.data.leader_address' | xargs echo "leader="
} | tee -a ${SNAP_FILE}.meta

# ローテーション（例：30世代保持）
ls -1t ${SNAP_DIR}/vault-raft-*.snap | tail -n +31 | xargs -r rm -f

スナップショットの保管・暗号化・リテンション

スナップショットは少なくともオフサイト/他AZへ複製し、改ざん検出のためハッシュとメタを同送します。クラウドストレージではバージョニングやWORM（オブジェクトロック）を活用すると復旧耐性が高まります。

転送・保管時の暗号化は二重化が望ましいです。SSE-KMSやGPGでの暗号化を併用し、復号鍵の保管者を最小化します。監査ログにバックアップの成否とハッシュを残すことで、監査対応も容易になります。

• S3やGCS等の冗長ストレージへ即時アップロード
• サーバ側暗号化（SSE-KMS）またはクライアント暗号化（GPG）
• WORM/バージョニング/ライフサイクルで世代管理
• 復元ドリルは四半期ごとに実施し、復旧時間の実測を記録

S3への転送（SSE-KMS）とGPG暗号化の例

# S3へアップロード（KMS鍵で暗号化）
AWS_BUCKET=s3://org-backup-vault
aws s3 cp "$SNAP_FILE" "$AWS_BUCKET" \
  --sse aws:kms --sse-kms-key-id arn:aws:kms:us-east-1:123456789012:key/xxxx
aws s3 cp "${SNAP_FILE}.meta" "$AWS_BUCKET"
aws s3 cp "${SNAP_DIR}/SHA256SUMS" "$AWS_BUCKET"

# GPGでクライアント暗号化してから送る例
gpg --encrypt --recipient [email protected] "$SNAP_FILE"
aws s3 cp "${SNAP_FILE}.gpg" "$AWS_BUCKET"

リストア手順（単一ノード復旧とクラスタ全体の再構築）

単一ノードの再作成やクラスタ全体の復旧は、まず1台にスナップショットを適用して起動・Unsealし、その後に他ノードをjoinさせるのが基本です。既存データが残る状態への上書きは失敗するため、対象ノードのRaftデータディレクトリは空にします。

リストアは作成元と同一か互換性のあるVaultバージョンで実施してください。復元後、TTLの経過した動的シークレットやリースは有効期限に基づいて整理されます。サーバ設定（vault.hcl）やTLS証明書はスナップショットに含まれないため、別途同一内容を用意します。

• 全体復旧は1台へ適用→Unseal→他ノードjoinの順序
• 対象ノードのdata_dirを空に（既存Raftログがあるとエラー）
• vault operator raft snapshot restore は -force 指定で上書き承諾
• 復旧後に raft list-peers と機能確認（認証/シークレット読み出し）

フルクラスタ復旧の例（systemd想定）

# 1) すべてのVaultを停止
sudo systemctl stop vault

# 2) 復旧に使うノードAのみデータ削除
sudo rm -rf /opt/vault/data/*

# 3) ノードAを起動
sudo systemctl start vault
export VAULT_ADDR=https://node-a.example.com:8200
export VAULT_TOKEN=s.xxxxx

# 4) スナップショットを適用（A上で）
vault operator raft snapshot restore -force /var/backups/vault/vault-raft-20240401-000000.snap

# 5) Unseal（元のUnsealキーを使用）
vault operator unseal
vault operator unseal
vault operator unseal

# 6) 動作確認
vault status
vault operator raft list-peers

# 7) 残りノードB/Cを初期化・起動後、各ノードでjoin
# ノードB側で実行（BのVAULT_ADDRをエクスポートしてから）
vault operator raft join https://node-a.example.com:8200
vault operator unseal

# ノードC側も同様
vault operator raft join https://node-a.example.com:8200
vault operator unseal

代替手段との比較とアーキテクチャの把握

Vaultのバックアップは、Raftスナップショット、ファイルシステムレベルのコピー、（Consulストレージ使用時の）Consulスナップショットなどが考えられます。Raft統合ストレージを使う場合は原則としてRaftスナップショットが最も安全です。

運用設計では、スナップショットの保管先・暗号化・リテンション、設定ファイルと証明書の別管理、復旧ドリルの頻度を決めておくと、実際の障害時に迷いがありません。

• Raft使用時はRaftスナップショットを第一選択
• 設定ファイル・TLS素材は別バックアップが必須
• 移行時はバージョン互換性を必ず検証（ステージングでリハーサル）

Raftスナップショットの取得と復元フロー（概念図）

比較用：Consulバックエンド時の例（参考）

# VaultがConsulストレージを使っている場合の参考（Raft統合ストレージでは使用不可）
# Consulのスナップショット
consul snapshot save consul-$(date +%Y%m%d).snap
# 復元
consul snapshot restore consul-20240401.snap

試験対策チェックリストとトラブルシュート

Ops試験では、取得コマンド・復元の順序・Unsealキーの必要性・設定がスナップショットに含まれない点・バージョン互換の扱いが頻出です。復旧時の順序（1台へ適用→Unseal→join）を言い切れるようにしてください。

典型的なエラーは、データディレクトリ未クリアでの復元（既存ログがあり失敗）、ネットワーク分断でのリーダーフォワーディング失敗、バージョン互換エラーなどです。事前にステージングでの復元手順を自動化しておくと、本番時の迷いを最小化できます。

• コマンド暗記: vault operator raft snapshot save / restore（restoreは -force）
• 設定/TLSは別バックアップ。スナップショットには含まれない
• 復元後はUnsealが必須。Unsealキー管理がボトルネックになりやすい
• joinは新規ノード側で実行し、リーダーのアドレスを指定
• バージョンは作成元と同等以上で復元（後方非互換に注意）

トラブル時の確認コマンド

# リーダーへのフォワーディングが機能しているか
vault status

# ピアと投票状況の把握
vault operator raft list-peers -format=json | jq .

# スナップショットサイズとハッシュ再計算
ls -lh /var/backups/vault/*.snap
sha256sum /var/backups/vault/*.snap

# Autopilotの状態（安定性評価の参考）
vault operator raft autopilot state

問題で確認

よくある質問