Contents
スポンサードリンク
Consul KV ストアとバックアップの重要性
Consul の KV（Key‑Value）ストアは、サービスディスカバリや設定情報を集中管理する中核コンポーネントです。データが失われると、マイクロサービス間の通信が止まったり、構成ミスによって障害が拡大したりします。また、多くの業界で「一定期間のデータ保持」や「改ざん防止」が法的に求められるため、バックアップは単なる運用上のベストプラクティスではなくコンプライアンス要件でもあります。
本セクションでは KV データが失われたときのリスク と バックアップを導入すべき根拠 を整理し、以降で説明する自動化・検証フローの必要性を示します。
データ損失リスクと法令遵守
- 設定情報の喪失
サービス名やヘルスチェック定義が消えると、ロードバランサーは誤ったエンドポイントへトラフィックを流す可能性があります。 - 復旧に要する時間の増大
手作業で KV を再構築すると数時間から数日かかり、サービスレベルアグリーメント（SLA）違反につながります。 - コンプライアンス上の問題
金融・医療・公共セクターでは、データ保持期間や改ざん防止が法令で義務付けられています。バックアップを取っていないと監査時に重大な指摘を受けるリスクがあります。
公式スナップショットコマンドとベストプラクティス（1.15.x 以降）
このセクションでは Consul の スナップショット取得・復元 に関する最新オプションを解説し、TLS 環境でも安全に KV 全体をバックアップできる手順を示します。まずは公式 CLI が提供しているフラグの正確な名前と動作を確認しましょう。
最新オプションと推奨フラグ
Consul 1.15 系で利用可能な主要フラグは次の通りです（2026 年 4 月時点）。
| フラグ | 説明 |
|---|---|
--encrypt |
サーバ側で AES‑256 暗号化されたスナップショットを生成します。外部ストレージに保存してもデータが平文になることはありません。 |
-skip-leader（長形は --skip-leader） |
リーダー選出待ちのタイムアウトを回避し、リーダーノードが一時的に不在でもスナップショット取得を試みます。実際のフラグ名は -skip-leader（単ハイフン）です。 |
--output-dir <path> |
スナップショットを複数ファイルに分割して出力でき、S3 のマルチパートアップロードと相性が良くなります。 |
注意: 以前のドキュメントで見られる
--skip-leader-checkは誤記です。実際のフラグは-skip-leader（または長形の--skip-leader）であることを公式リファレンスで必ず確認してください。
ローカル・S3・GCS への保存例と暗号化設定
前提環境変数（TLS 相互認証）
|
1 2 3 4 5 |
export CONSUL_HTTP_ADDR=https://consul.example.com:8501 # HTTPS デフォルトは 8500 (HTTP) / 8501 (HTTPS) ですが、設定次第で変更可能です export CONSUL_CACERT=/etc/consul.d/certs/ca.pem export CONSUL_CLIENT_CERT=/etc/consul.d/certs/client.pem export CONSUL_CLIENT_KEY=/etc/consul.d/certs/key.pem |
ローカルディスクへ保存（AES‑256 暗号化）
|
1 2 3 4 5 |
consul snapshot save \ --encrypt \ -skip-leader \ /var/backups/consul/snapshot-$(date +%Y%m%d%H%M).snap |
Amazon S3 へ保存（サーバ暗号化＋SSE‑KMS）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
export AWS_ACCESS_KEY_ID=... export AWS_SECRET_ACCESS_KEY=... TMP_SNAP=$(mktemp /tmp/consul.snap.XXXX) consul snapshot save --encrypt -skip-leader "$TMP_SNAP" aws s3 cp "$TMP_SNAP" "s3://my-consul-backup/$(basename $TMP_SNAP)" \ --sse aws:kms --sse-kms-key-id alias/consul-snapshot-key rm -f "$TMP_SNAP" |
Google Cloud Storage へ保存（CMEK）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
export GOOGLE_APPLICATION_CREDENTIALS=/opt/gcp/key.json TMP_SNAP=$(mktemp /tmp/consul.snap.XXXX) consul snapshot save --encrypt -skip-leader "$TMP_SNAP" # CMEK を使用する場合は gsutil の `-o` オプションでキーを指定 gsutil cp -o "GSUtil:encryption_key=$(gcloud kms keys versions get-public-key \ consul-snapshot-key --location=global --keyring=my-ring)" \ "$TMP_SNAP" gs://my-consul-backup/ rm -f "$TMP_SNAP" |
Enterprise 向け Snapshot Encryption（OSS との差別化）
- OSS (Open Source):
--encryptフラグだけで暗号化が行われ、キーは Consul プロセスの起動時に自動生成されます。 - Consul Enterprise: 「Snapshot Encryption」機能が追加され、
consul snapshot encrypt-key set <key>で外部 KMS と連携した鍵管理が可能です。Enterprise では--encryptに加えて--encryption-key-id（またはconsul snapshot encrypt-key set）を使用します。
|
1 2 3 4 |
# Enterprise の場合のみ有効な例 consul snapshot encrypt-key set --name my-key --type kms --kms-key arn:aws:kms:... consul snapshot save --encrypt -skip-leader /tmp/enc-snap.snap |
Zero Trust 環境での認証・最小権限設定
Zero Trust の前提では、バックアップジョブ自体も 最小権限の ACL と 相互 TLS 認証 で保護しなければなりません。ここではトークン発行からポリシー記述までの手順を示します。
TLS 設定の確認ポイント
TLS が正しく設定されているかは、consul config dump の出力で以下項目が true になっているかで判断できます。
verify_incoming = trueverify_outgoing = true
HTTPS 用ポートは デフォルトで 8501 が使用されますが、ports.https の設定により任意の番号へ変更可能です。そのため「8501 以降が必ず使われる」という表現は避け、「デフォルトは 8501」 と明記します。
ACL トークン取得と最小権限ポリシー
ポリシーファイル backup-policy.hcl（OSS / Enterprise 共通）
|
1 2 3 4 5 6 7 8 9 10 11 |
# KV の読み取り権限（バックアップ時にデータを取得できるようにする） key_prefix "" { policy = "read" } # スナップショット取得のための operator 権限 operator = "write" # Snapshot コマンド自体のアクセス制御（OSS は read/write が同等、Enterprise は encrypt が別枠になることがある） snapshot = "write" |
公式仕様との整合性
-operatorとsnapshotはトップレベルで記述し、ブロック形式ではありません。
-key_prefix "" { policy = "read" }が KV 全体の読み取りを表します。
ポリシー登録とトークン生成
|
1 2 3 4 5 6 7 8 9 |
# ポリシー作成 consul acl policy create -name backup-policy -rules @backup-policy.hcl # バックアップ専用トークンの発行 BACKUP_TOKEN=$(consul acl token create -policy-name backup-policy \ -description "Backup job token (KV read + snapshot write)") export CONSUL_HTTP_TOKEN=$BACKUP_TOKEN |
このトークンは スナップショット取得と KV の読み取り に限定され、他の操作（例: キー書き込みやサービス登録）は一切許可されません。
バックアップ自動化スクリプトと定期実行
自動化にあたっては 環境変数で機密情報を外部管理 し、cron や systemd タイマーで安全にジョブを走らせます。以下では Bash と PowerShell のサンプルスクリプトを提示し、各ステップの目的を解説します。
Bash スクリプト例（Linux）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
#!/usr/bin/env bash set -euo pipefail # ------------------------------------------------- # 1. 必要な環境変数を外部ファイルから読み込む # （/etc/consul/backup.env に格納し、権限は 600 に設定） # ------------------------------------------------- source /etc/consul/backup.env # CONSUL_HTTP_ADDR, *_CERT, BACKUP_DEST, ENCRYPT_KEY_ID など # ------------------------------------------------- # 2. 一時スナップショットファイルを作成 # ------------------------------------------------- TMP_SNAP=$(mktemp /tmp/consul-snap.XXXX) # ------------------------------------------------- # 3. スナップショット取得（サーバ側暗号化 + リーダー回避） # ------------------------------------------------- consul snapshot save --encrypt -skip-leader "$TMP_SNAP" # ------------------------------------------------- # 4. 保存先に応じたアップロード処理 # ------------------------------------------------- case "$BACKUP_DEST" in s3://*) aws s3 cp "$TMP_SNAP" "${BACKUP_DEST}snapshot-$(date +%Y%m%d%H%M).snap" \ --sse aws:kms --sse-kms-key-id "$ENCRYPT_KEY_ID" ;; gs://*) # GCS の CMEK を使用する場合は事前にキーを設定済みと想定 gsutil cp "$TMP_SNAP" "${BACKUP_DEST}snapshot-$(date +%Y%m%d%H%M).snap" ;; *) mv "$TMP_SNAP" "${BACKUP_DEST}/snapshot-$(date +%Y%m%d%H%M).snap" ;; esac # ------------------------------------------------- # 5. 一時ファイルの削除（セキュリティ上必須） # ------------------------------------------------- rm -f "$TMP_SNAP" |
スクリプト冒頭の導入文
このスクリプトは環境変数で認証情報と保存先を外部管理し、TLS 相互認証下で Consul の暗号化スナップショットを取得したうえで、S3・GCS・ローカルのいずれかに安全に転送します。
PowerShell スクリプト例（Windows）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
<# .SYNOPSIS Consul KV バックアップ用 PowerShell スクリプト .DESCRIPTION TLS 認証情報とバックアップ先を環境変数から取得し、暗号化スナップショットを生成して S3 / GCS / ローカルへ保存します。 #> $ConsulAddr = $Env:CONSUL_HTTP_ADDR $Token = $Env:CONSUL_HTTP_TOKEN $Dest = $Env:BACKUP_DEST # 例: s3://my-consul-backup/ $TmpFile = [IO.Path]::GetTempFileName() # スナップショット取得（暗号化＋リーダー回避） & consul snapshot save --encrypt -skip-leader $TmpFile if ($Dest.StartsWith('s3://')) { aws s3 cp $TmpFile "$Dest\snapshot-$(Get-Date -Format 'yyyyMMddHHmm').snap" ` --sse aws:kms --sse-kms-key-id $Env:ENCRYPT_KEY_ID } elseif ($Dest.StartsWith('gs://')) { gsutil cp $TmpFile "$Dest\snapshot-$(Get-Date -Format 'yyyyMMddHHmm').snap" } else { Move-Item $TmpFile "$Dest\snapshot-$(Get-Date -Format 'yyyyMMddHHmm').snap" } Remove-Item $TmpFile |
スクリプト冒頭の導入文
上記 PowerShell は Windows 環境で Consul のスナップショット取得からクラウドストレージへの転送までを一括で実行し、ジョブ失敗時に例外が即座に通知されるよう
-ErrorAction Stopがデフォルトで有効です。
cron と systemd タイマーでのスケジューリング
Linux (cron)
|
1 2 3 |
# 毎日 02:30 にバックアップを実行し、標準出力・エラーは専用ログにリダイレクト 30 2 * * * /usr/local/bin/consul_backup.sh >> /var/log/consul-backup.log 2>&1 |
systemd タイマー
service ファイル（/etc/systemd/system/consul-backup.service）
|
1 2 3 4 5 6 7 8 |
[Unit] Description=Consul KV ストア自動バックアップ [Service] Type=oneshot ExecStart=/usr/local/bin/consul_backup.sh EnvironmentFile=/etc/consul/backup.env # 600 権限で管理 |
timer ファイル（/etc/systemd/system/consul-backup.timer）
|
1 2 3 4 5 6 7 8 9 10 |
[Unit] Description=Run consul-backup.service daily at 02:30 [Timer] OnCalendar=*-*-* 02:30:00 Persistent=true [Install] WantedBy=timers.target |
|
1 2 3 |
systemctl daemon-reload systemctl enable --now consul-backup.timer |
バックアップ検証・リストアと障害復旧シナリオ
取得したスナップショットが正しく保存されていても、リストア手順を実際にテストしなければ意味がありません。ここではハッシュ検証からステージング環境でのリストアまでのフローと、システム全体障害時の復旧戦略をまとめます。
ハッシュ比較による整合性チェック
- スナップショット取得直後にハッシュを書き出す
bash
sha256sum /path/to/snapshot.snap > /path/to/snapshot.sha256 - 保存先からダウンロードし、ハッシュが一致するか検証
bash
aws s3 cp s3://my-consul-backup/... . && \
sha256sum -c snapshot.sha256
ハッシュが不一致の場合はストレージ転送中に破損した可能性があるため、再取得・再アップロードを行います。
ステージングクラスタでのリストア手順
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# 1. テスト用 Consul クラスタを起動（-dev モードでも可） consul agent -dev -ui & # 2. 暗号化スナップショットを復元 consul snapshot restore --encrypt /path/to/snapshot.snap # 3. KV の一部を取得し、期待値と比較 EXPECTED=$(cat expected-config.json) ACTUAL=$(consul kv get config/app/feature_flag -decode-base64) if [[ "$EXPECTED" != "$ACTUAL" ]]; then echo "リストア結果が期待値と異なります！" exit 1 fi echo "テストリストア成功" |
単一ノード障害時の復旧フロー
| 手順 | 内容 |
|---|---|
| 1 | 残存サーバでリーダーが選出されていることを consul operator raft list-peers で確認 |
| 2 | 新規ノードを追加し、OS のパッケージインストール後に snapshot restore を実行 |
| 3 | ノードがクラスタに参加したら consul members で状態を確認し、KV が同期されていることをチェック |
データセンター全体障害時の戦略
- マルチリージョン構成の場合は WAN フォワーディングなしでローカルスナップショットだけを使用する方がネットワーク分断リスクを低減できます。
- 復旧手順: 新規データセンターに Consul を bootstrap-expect で起動 → 最新のスナップショットを
consul snapshot restore -datacenter <dc>で適用 → リーダー選出と ACL の再確認。
Enterprise 向け Snapshot Encryption の復元手順
- 復号キーを事前にロード
bash
consul snapshot encrypt-key set --name my-key --type kms --kms-key arn:aws:kms:... - 暗号化スナップショットを復元
bash
consul snapshot restore --encrypt -skip-leader /path/to/enc-snap.snap
まとめ
- KV データはサービス稼働の根幹であり、バックアップなしでは法的リスク・運用リスクが顕在化します。
- Consul 1.15 系以降は
--encryptと正しいフラグ名-skip-leader（または--skip-leader）を組み合わせることで、TLS 環境下でも安全にスナップショット取得が可能です。 - Zero Trust の観点から、バックアップジョブ専用の最小権限 ACL と相互 TLS 認証を必ず設定し、トークンは「KV read + snapshot write」のみ許可します。
- Bash／PowerShell のサンプルと
cron/systemdタイマーによる自動化で人的ミスを排除し、環境変数ファイルで機密情報を分離管理します。 - ハッシュ検証・ステージングリストアでバックアップの有効性を定期的に確認し、単一ノード障害からデータセンター全体障害までの復旧シナリオを事前に策定しておくことが重要です。
- Enterprise ユーザーは Snapshot Encryption 機能で外部 KMS と連携した鍵管理が可能ですが、OSS でも
--encryptによる暗号化は利用できるため、要件に応じて使い分けてください。
これらのベストプラクティスを実装すれば、最新バージョンの Consul 環境で 信頼性・コンプライアンス・運用効率 を同時に向上させた KV バックアップ体制が構築できます。
スポンサードリンク