「毎日自動バックアップは取れていた」という安心の作り方
K3sのetcdスナップショットは、デフォルトで12時間おきに自動実行され、直近5世代がローカルまたはS3に保存される。監視ダッシュボードにスナップショット成功のログが並んでいれば、多くのチームは「バックアップは万全」と判断するだろう。
だが実際にK3sクラスタが本番障害でリストアを必要とした瞬間、そのスナップショットが役に立たないケースが少なくない。Kubernetes公式ドキュメントも「etcdを使うクラスタでは必ずバックアップ計画を持つこと」と明記しているが、計画の中身、特にリストア手順まで検証しているチームは意外と少ない。K3s etcd リストア 失敗の典型パターンを3つ、実際の障害報告をもとに整理する。
罠1: サーバートークンを控えていないと、スナップショットはただの暗号化データになる
K3sのetcdスナップショットは、サーバー参加トークンから導出したAES-256鍵で暗号化されている。K3s公式のetcd-snapshotドキュメントによれば、新しいホストにリストアする際は元のトークン値を明示的に指定する必要があり、Backup and Restoreドキュメントでも「/var/lib/rancher/k3s/server/token を必ずバックアップ対象に含めること。同じトークン値を使わないとスナップショットが使用不可になる」と警告されている。
この落とし穴が実際に問題化した例がK3sのGitHub Issue #4522だ。トークンフラグを指定せずにリストアを実行すると、原因を示さない空白のFATALエラーで処理が止まる。スナップショットファイル自体は無傷でも、トークンという「鍵」を紛失していれば復元は成立しない。バックアップ対象をetcdスナップショットのファイルだけに絞っているチームは、まずここを見直す価値がある。
こうしたトークンやスナップショットの保管・世代管理を人力の手順書に依存させず、運用そのものを構造化したいなら、KuboのようなマネージドK3sという選択肢もある。
罠2: S3からのリストアが、逆に全データを消すことがある
K3sはオンデマンド・定期スナップショットをS3互換ストレージへ自動アップロードできる。Backup and Restoreドキュメントによればリストア処理はS3からのダウンロード→展開→既存etcdディレクトリの削除・退避→スナップショット内容の抽出、という順序で進む。
この手順のどこかで設定や前提を誤ると、復旧のつもりが新たなデータ損失を招く。実際にrancher/rancherのGitHub Issue #42251では、S3からのetcdスナップショットリストアがクラスタの全データを消してしまう不具合が報告されている。etcd公式の障害復旧ガイドも、リストア後は全メンバーが同一スナップショットを使い、新しい論理クラスタとして起動する必要があると強調しており、この前提がずれるとクラスタ全体が不整合な状態に陥る。
中盤のCTAとしても触れておきたいが、こうしたリストア手順そのものを可視化し、ブラックボックスにしないという点で、Kubo CloudのKuboはCaptain UIによる運用状態の可視化を標準搭載している。手順書と実際のクラスタ状態が乖離するリスクを減らしたいチームには参考になるはずだ。
罠3: cluster-resetのreset-flagを甘く見ると、復旧のはずが詰む
全ノード喪失など深刻な障害からの復旧では、k3s server --cluster-reset --cluster-reset-restore-path=<snapshot> でリセットとリストアを同時実行する。K3sのserverコマンドリファレンスでは、--cluster-reset は「既存のピア情報をすべて忘れ、新しいクラスタの唯一のメンバーになる」機能と説明されている。
# 全ノード喪失時のリセット＋リストア例
k3s server --cluster-reset --cluster-reset-restore-path=/var/lib/rancher/k3s/server/db/snapshots/etcd-snapshot-xxxx
このリセット処理は、誤って複数回実行されることを防ぐための安全機構を伴う。K3sのGitHub Discussionでは --cluster-init と --cluster-reset の挙動の違いが議論されており、フラグの意味を正確に理解しないまま手順を進めると、リセット後にクラスタが正常起動しない状態にはまりやすいことが分かる。障害対応の緊張状態でこの種のフラグの意味を初めて調べることになれば、復旧時間はさらに伸びる。
HAクラスタが守るのは「ノード障害」であって「データ損失」ではない
K3sのHA embedded etcd構成では、n台のサーバーノードに対してクォーラムは (n/2)+1 で計算される。K3s公式のHA embedded etcdドキュメントは奇数ノード構成を推奨しており、3ノードなら1台、5ノードなら2台までの障害に耐えられると説明する。Kubernetes公式ドキュメントも本番環境では奇数メンバー構成、できれば5メンバークラスタを推奨し、さらに「etcdへのアクセスはクラスタのroot権限と同等」であるとして、アクセス制御の重要性を強調している。
ここで陥りやすい誤解が、「3台構成でHAにしているから安心」という思い込みだ。HAが守るのは特定ノードの物理的・一時的な障害であり、設定ミスの横展開や同時多発的なストレージ障害、あるいは3台すべてを巻き込む人為的ミスにはHAだけでは対応できない。Rancherの公式リストアガイドでも、control planeとetcdノードが完全に失われた場合の復旧手順は「既存のetcdノードをすべて削除してから新規ノードを追加する」という、通常のノード交換とは異なる複雑な手順が必要になると説明されている。こうした複雑な復旧手順を運用チームの暗黙知に頼るのではなく、Kubo On-Premiseのようにデータ主権を保ちながら運用そのものをマネージド化する選択肢を検討する価値もある。
まとめ: リストアは訓練されて初めてバックアップになる
K3sのembedded etcdバックアップには、少なくとも3つの構造的な罠がある。
- トークン管理: スナップショットはトークン由来の鍵で暗号化されており、トークンを控えていなければ復号できない
- S3リストアの手順: ダウンロード→展開→削除→抽出という流れのどこかでミスがあれば、復旧が新たなデータ損失に変わりうる
- cluster-resetの理解不足: フラグの意味を正確に把握していないと、緊急時に復旧そのものが止まる
いずれも「スナップショットが取れているか」ではなく「そのスナップショットを実際にリストアできるか」という一段深い問いに関わる。四半期に一度でもステージング環境でリストア訓練を行い、トークン管理・手順書・所要時間を検証しておくことが、本番障害での復旧時間を左右する。
こうした検証・運用そのものを自前で回し続ける負荷を減らしたいなら、KuboのマネージドK3sという選択肢を検討してみてほしい。まずはお問い合わせから、現在のバックアップ・リストア運用について相談することもできる。