WADA-DEV(7) $ /ja/blog/home-server-random-freeze-extra-disposable-server/

NAME

home-server-random-freeze-extra-disposable-server — 自宅サーバがランダムフリーズした話 (番外) ─ 使い捨てられるサーバ

SYNOPSIS

RAM 不良が確定した故障機を修理に送り出す準備をしたら、304GB のディスクのうち守る価値があるのはログ 2.8GB だけだった。GitOps / 宣言的構成が受けた最終試験の話。

DESCRIPTION

本編のあとで

本編(第 1 回第 3 回)で自宅 AI サーバの RAM 不良が確定し、保証対応が始まりました。そこで現実的な問題が発生します。本体ごと修理に送る展開があり得る。 SSD には何が入っている? 消すべき秘密は? バックアップは何を取る?

答えを先に言うと、この棚卸しはシリーズで一番あっけない作業になりました。そしてそのあっけなさ自体が、この 1 か月で一番の収穫だったかもしれません。

304GB を棚卸しする

このサーバは NixOS で、構成は GitOps(git リポジトリへの push が自動でデプロイされる)、dotfiles は yadm で管理しています。ディスク使用量は約 304GB。内訳を du で洗うと、こう分類できました。

分類サイズ復元手段
コンテナイメージ約 95GBレジストリから再 pull
LLM モデル類177GB再ダウンロード
退役サービスの残骸50GBそもそも削除対象
OS・サービス設定git リポジトリから再構築
dotfilesyadm から復元
検証用コード4.8GB使い捨てのロード試験コード
ログ (/var/log)2.8GB代替なし ← これだけ

※ 各行のサイズは du のファイルサイズベース。btrfs の透過圧縮と共有エクステントのため、単純合計(約 330GB)は実ディスク消費(df で 304GB)より大きくなります。

304GB のうち、この世に 1 部しか存在しないデータは 2.8GB のログだけでした。しかもその中身は、journal(=本シリーズの法医学記録そのもの)と、別件で調査中のネットワーク機器の syslog。つまりこのマシンが持っていた唯一の固有データは、自分の病歴と、他人の事件の証拠だったわけです。バックアップは tar 一発、数分で終わります。

消すべき秘密は 5 点で列挙できた

送付前に消すべき秘密情報の洗い出しも、拍子抜けするほど短いリストになりました。

  1. ホストの SSH 鍵 ─ secrets 復号鍵(sops-nix の age 鍵)を兼ねているので最重要
  2. 構成リポジトリのローカルクローン ─ 暗号化された secrets ファイルを含み、1 と同居するとディスク単体で復号が成立してしまう
  3. Git 認証トークンの類
  4. シェル履歴・エージェント系ツールの履歴
  5. 実行時 secrets ─ RAM 上(ramfs、swap にも落ちない)なので電源断で消える(対応不要)

ポイントは「短い」ことではなく、「これで全部だ」と確信を持って言い切れることです。secrets 管理を sops-nix の 1 系統に集約してあったから、所在の特定に探索が要らなかった。逆に言うと、1 と 2 の組み合わせが 1 台のディスクに同居している事実はこの棚卸しで初めて直視したので、返却後はホスト鍵の再生成と secrets の re-key、トークンのローテーションが必須になります(ファイルを消しても、発行済みのトークンは生きているので、無効化まででワンセット)。

宣言的構成の価値は、手放せることだった

NixOS + GitOps + yadm という構成を選んだとき、期待していた価値は「再現性」や「デプロイの楽さ」でした。実際に 1 か月使って一番効いたのは、それらの土台にある別の性質です。

マシンを、いつでも手放せる。

  • 故障機の修理送付が「ログ退避 → 秘密 5 点消去 → 発送」の 30 分コースになる
  • 「何が消えたら困るか」という問いに、探索でなく設計から即答できる
  • 診断作業(memtest のブートエントリ追加)すら PR として履歴に残っていて、ベンダーへの説明材料になる

サーバが物理的に壊れて機体を手放す ─ 宣言的構成にとってこれ以上の最終試験はありません。結果は「失うものはログだけ、それも 2.8GB」でした。

限界も 2 つ見えた

いいことばかり書くのはフェアでないので、限界も。

「復元可能」と「復元が速い」は別物です。 モデル 177GB の再ダウンロードとコンテナの再 pull には、回線なりの時間がかかります。構成は数十分で戻っても、データの再取得は半日仕事になり得る。

ログのような「本当に固有な状態」はゼロにはなりません。 今回は 2.8GB でしたが、録画や DB を持たせる運用ならこの層は育ちます。だから本質は「固有データをゼロにする」ことではなく、使い捨てられる層(OS・構成)と守る層(データ)の境界を、事前に・構造として引いておくことです。次の改善として、OS 用とデータ用で SSD を物理的に分ける構成や、NixOS の impermanence(永続化するパスを明示列挙し、root を揮発にする)を検討しています。そこまでやれば「守る層」が設定ファイルに強制的に書き出され、今回のような棚卸し自体が不要になります。

シリーズの締め

ランダムフリーズから始まった 1 か月を振り返ると:

  1. journal の法医学で仮説を立て
  2. 実測で思い込みを潰し
  3. memtest で 1 分で物証を取り
  4. そして機体を、いつでもためらいなく送り出せる状態にした

不良メモリを引いたのは運ですが、この 4 点セットで返せたのは構成の力です。ハードは壊れるものとして設計する ─ 自宅サーバでも、それは十分に元が取れる投資でした。

SEE ALSO

COMMENTS