etcdクラスタのスナップショット運用を本番設計する｜取得頻度とメンバー障害時の復元手順確認

etcdスナップショットが本番設計で欠かせない理由

Kubernetesクラスタの設定情報・状態データはすべてetcdに集約されます。Deployment・ConfigMap・Secret・RBAC設定といったリソース定義はAPIサーバーを経由してetcdに書き込まれ、etcdが失われるとクラスタは実質的に機能を停止します。コントロールプレーンのノードを再構築しても、etcdのデータが失われていれば元の状態には戻りません。

スナップショットはetcdが保持するデータ全体の論理コピーです。WAL（Write-Ahead Log）ではなくアプリケーション層のスナップショットとして実装されているため、特定時点のデータベース全体を1ファイルとして取り出せます。このファイルさえあれば、クラスタを別のメンバーセットで再構築したり、意図しない変更を加える前の状態へ戻したりすることが原理的に可能です。

問題は「取れる」と「本番で確実に復元できる」の間に大きな溝があることです。取得頻度・保管先・復元手順の事前検証・クォーラム障害時の対応方針まで設計しておかないと、実際の障害対応で手順書を読み返しながら操作することになります。2026年時点ではetcd v3.5系が主流となり、v3.4以前の手順と細部が異なる箇所も増えています。本記事ではこれらを一本の運用フローとして整理します。

スナップショット取得頻度の設計指針

取得頻度を決める主な要素はRPO（Recovery Point Objective：許容できるデータ損失の最大時間）とetcdへの書き込み量です。多くの本番クラスタでは「1時間ごと」が実用的な出発点になりますが、頻繁にリソースが作成・削除されるCIパイプラインが稼働しているクラスタでは30分や15分を選ぶ現場も増えています。

一方、取得頻度を上げるほどスナップショットファイルが増え、ストレージコストと管理負荷も比例して増加します。現実的な設計として、以下の考え方がよく採用されます。

• 直近24時間分は1時間おきに保持する
• それ以前は1日1回の日次スナップショットを7〜14日分保持する
• 月次のアーカイブを別ストレージ（オブジェクトストレージ等）に長期保管する

保管先はetcdメンバーと同一ホストに置くべきではありません。ノード障害と同時にスナップショットを失うリスクがあるためです。S3互換ストレージやNFS、あるいはクラスタ外のオブジェクトストレージへの転送をスクリプトに組み込んでおくのが標準的な構成です。暗号化については、Secretの内容がetcdに平文で入っている（クラスタ側の暗号化機能を有効にしていない）場合、スナップショットファイル自体も機密情報を含むことになるため、転送時・保管時ともに暗号化が必要です。

スナップショット取得の実行例

etcdctl を使ったスナップショット取得の基本形は以下のとおりです。コントロールプレーンノード上でエンドポイント・証明書を明示して実行します。

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d%H%M).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

取得直後に etcdctl snapshot status でハッシュ・リビジョン・サイズを確認する習慣をつけておくと、破損スナップショットを保管してしまうリスクを減らせます。自動化する場合はこのステータス確認と外部ストレージへの転送・古いファイルの削除をひとつのシェルスクリプトにまとめ、systemd timer で定期実行するのが現在の主流です。

メンバー障害時の判断フローと復元手順

etcdクラスタのメンバー障害には「クォーラムが維持されているか否か」で対応方針が大きく異なります。3メンバー構成なら2台が正常であればクォーラムは維持されており、障害メンバーを etcdctl member remove で除去してから新しいメンバーを追加するだけで済みます。この場合、スナップショットからの復元は不要です。

問題はクォーラムを失ったケース、すなわち3メンバー構成で2台以上が同時に失われた場合です。etcdはリーダー選出もデータ書き込みも不可能になります。このときスナップショットからの復元が必要になります。

クォーラム喪失時のスナップショット復元

手順の全体像は次のとおりです。作業前にKubernetesのAPIサーバーを含むコントロールプレーンコンポーネントを停止し、既存のetcdデータディレクトリを退避させてから復元を行います。

まず、すべてのメンバーノードで既存のetcdデータディレクトリを退避します。

mv /var/lib/etcd /var/lib/etcd.bak.$(date +%Y%m%d)

次に、各メンバーノードで etcdctl snapshot restore を実行します。ここで重要なのは各メンバーに対して異なる --name・--initial-advertise-peer-urls を指定することです。すべてのメンバーに同じ引数を与えるとデータ不整合が発生します。

ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-20260828120000.db \
  --name etcd-member-1 \
  --initial-cluster "etcd-member-1=https://192.168.0.11:2380,etcd-member-2=https://192.168.0.12:2380,etcd-member-3=https://192.168.0.13:2380" \
  --initial-cluster-token etcd-cluster-restore-$(date +%s) \
  --initial-advertise-peer-urls https://192.168.0.11:2380 \
  --data-dir /var/lib/etcd

--initial-cluster-token は復元ごとに新しい値を使います。古いトークンを使い回すと、同一ネットワーク上の生き残りメンバーが誤った認識でクラスタに参加しようとする事故を防げます。全メンバーで復元が完了したらetcdプロセスを起動し、etcdctl member list でクラスタが正常に形成されたことを確認します。

復元後の検証と切り戻し判断

etcdが起動してKubernetesのAPIサーバーが接続を受け付けるようになったら、以下の観点で状態を確認します。

• kubectl get nodes でノード一覧が取得できるか
• 重要なNamespaceおよびDeploymentが存在するか
• スナップショット取得時刻以降に変更されたリソースが想定どおり巻き戻っているか

スナップショットのタイムスタンプよりも後に作成・変更されたリソースは復元後に存在しません。これは設計上の挙動ですが、本番環境では「復元後に失われるリソース」をスナップショット取得時刻から逆算して洗い出し、必要なものはGitOpsのリポジトリから再適用する手順をあわせて用意しておく必要があります。

復元後にクラスタの挙動が不審な場合（リーダー選出が安定しない・APIサーバーが頻繁に再起動するなど）は、退避した /var/lib/etcd.bak.* ディレクトリに戻す切り戻しが最終手段になります。ただしクォーラム喪失の原因がハードウェア障害であれば、バックアップディレクトリを戻してもデータが壊れている可能性があるため、切り戻しより別のスナップショットからの再復元を優先するのが現場での判断です。

定期的な復元訓練（Disaster Recovery Drill）を半年〜1年に1回実施し、手順書の手順が実際に動作することを確認しておくことが、実効性のある運用設計の前提になります。

2026年現行環境での注意点

2026年8月時点で主流のetcd v3.5系では、いくつかの点で過去の手順書と動作が変わっています。

まず、etcdctl snapshot restore の --skip-hash-check オプションは引き続き存在しますが、v3.5以降はスナップショット保存時にCRCチェックが強化されており、正常に取得されたファイルであればハッシュチェックをスキップする必要はほぼありません。古い手順書でこのオプションがデフォルトで付いている場合、スキップを前提にした運用は見直しが推奨されます。

次に、kubeadm管理のクラスタでは静的Pod（Static Pod）としてetcdが動作しているため、復元作業中のetcd停止は /etc/kubernetes/manifests/etcd.yaml をマニフェストディレクトリ外へ移動することで行います。systemdサービスとして動作しているetcdと操作が異なる点に注意が必要です。

また、マネージドKubernetes（EKS・GKE・AKSなど）を利用している場合、etcdはコントロールプレーンの管理範囲外になるため、ユーザーが直接スナップショットを取得・復元することはできません。これらの環境ではプラットフォームが提供するバックアップ機能（EKSであればAPIのリソースエクスポートやVeleroとの組み合わせ）を活用するアーキテクチャへの切り替えが現実的です。

セルフホスト型のKubernetes、特にkubeadmやk3s・RKE2で構築した環境では引き続きetcdの直接管理が必要であり、本記事で扱ったスナップショット運用の設計は直接適用できます。k3sはSQLite/kineバックエンドを採用している場合もあるため、バックエンドがetcdかどうかを先に確認してから手順を選択してください。

etcdのスナップショット運用は「仕組みは理解した」から「本番で確実に復元できる」まで到達するには、設計・自動化・定期検証の三つが揃って初めて完結します。スナップショットが取れているかどうかだけを監視している状態から一歩進め、定期的な復元訓練と手順の更新サイクルを組み込むことが、実質的な可用性向上につながります。