内科・循環器内科・呼吸器内科・小児科 / 歯科・小児歯科・歯科口腔外科
内科 058-277-7757 歯科 058-277-7758 医科WEB予約 歯科予約(事前問診) 事前問診

ホーム ／ 院長のお話 ／ 備忘録⑤

備忘録⑤

2026年8月6日（木）　PBS復旧の一日

はじめに

自宅に置いていた Proxmox Backup Server（PBS）をクリニックへ持ち込み、朝から夜まで復旧作業をおこないました。結果として、止まっていたバックアップが戻っただけでなく、7月28日から残っていた懸案まで片付き、さらに自宅側の電源対策まで終える一日となりました。忘れないうちに、順を追って記録しておきます。

1. 発端 — バックアップが12日間止まっていた

PBS を院内に持ち込み、電源を入れてコンソールに root でログインするところから始めました。当初は「PBS の設定が壊れているのだろう」と考えていましたが、これは誤りでした。

最終的に判明した原因は単純で、PBS の電源が入っていなかった（ネットワークに繋がっていなかった）だけでした。PVE 側の設定は7月24日の時点で完成しており、直すものは何もありませんでした。

最後にバックアップが取れていたのは 7月25日 02:06。つまり7月26日から8月5日までの約12日間が空白になっていました。

2. ネットワークが無い状態からの切り分け

最初、PBS には IPv4 アドレスが 127.0.0.1 しか付いておらず、nic0・nic1 とも DOWN の状態でした。ここから順に調べていきました。

わかったことを並べます。

ここが最大の落とし穴でした。「起動時に DHCP で取れ」と書いてあるのに、取るための道具が入っていない。だから毎回、手で dhcpcd -t 10 nic0 を打つ羽目になっていたわけです。

なお、当初 172.30.214.164 というアドレスにこだわっていましたが、これは /etc/issue（ログイン画面の案内文）と /etc/hosts に残っていた自宅時代の残骸でした。IP を設定している箇所はどこにもありませんでした。

ゲートウェイは 172.30.214.1 で、ping の応答は 0.5ms。実測で確定させました。

3. 設計を一段上げた — Tailscale で指す

PBS は院内と自宅を持ち運ぶ機械です。LAN の固定 IP で指定していると、場所が変わるたびに壊れます。

そこで、PVE のバックアップ先を Tailscale アドレス 100.113.149.62 にする方針としました。院内でも自宅でも変わらない値です。しかも同一 LAN にいるときは直接接続に切り替わるため、速度も落ちません。

確認したところ、PVE 側の /etc/pve/storage.cfg には既にこの構成が入っていました。

pbs: pbs
        datastore main
        server 100.113.149.62
        username root@pam!pve

自分で書いた設定が、そのまま正解だったということです。

4. バックアップ復旧 — 13秒

pvesm status --storage pbs が active になり、容量も見えました（7.6TB 中 823GB 使用、10.74%）。

テストバックアップを1本流しました。

vzdump 103 --storage pbs --mode snapshot --compress zstd

13秒で完了。しかも7月25日のバックアップからの増分として動き、85.8%を再利用、実際に送ったのは 327MiB だけでした。過去のデータもすべて生きていました。

これで12日間の空白が埋まりました。

5. CT100 の DICOM は対象外だった

夜間ジョブは all 1（全ゲスト対象）で毎日 2:00。CT100 には DICOM が 954GB 入っているため、毎晩これを送っていたら破綻します。

調べたところ mp0: /data,mp=/mnt/data はバインドマウント形式で、vzdump の対象外でした。念のため実測で裏を取っています。

DICOM は含まれていません。対処不要でした。

6. 大きな発見 — 192.168.1.1 の不正 DHCP

dhcpcd のログに、見逃せない行が出ていました。

nic0: rebinding lease of 172.30.215.53
nic0: NAK: from 192.168.1.1

院内ルータ以外の DHCP サーバーが応答している証拠です。これは7月28日から未解決だった、オンライン資格確認のルータと同じアドレスでした。「疑わしい」ではなく「今この瞬間に実際に応答している」ことが確認できた形です。

そのまま VLAN30 の物理配線を追い、Omada で切り離しました。

効果は即座に出ました。同じ操作を繰り返しても、NAK が挟まらなくなりました。2週間近く残っていた案件が、この日に片付きました。

粘り強いクライアントは取り直せますが、そうでない機器は取得に失敗します。医療機器や受付端末が同じ目に遭えば、朝いちばんに業務が止まります。芽を摘めたのは大きな収穫でした。

7. 副産物 — Tailscale が直接接続に戻った

切り離しの直後、PVE から PBS への Tailscale が中継経由から直接接続に戻りました。

192.168.1.1 の干渉が、直接接続まで妨げていたということです。バックアップの転送速度に直結する部分なので、これも収穫でした。

8. 起動時の IPv4 自動取得

dhcpcd-base は入っていましたが、これはコマンド本体だけのパッケージで、サービスを含みません。だから起動時に走らなかったのです。

apt install -y dhcpcd

これでサービス付きの本体が入り、enabled / active を確認。あわせて /etc/network/interfaces の nic0 を inet manual に変更し、ifupdown2 と dhcpcd の二重管理をやめました。

再起動後、手を触れずに 172.30.215.53/23 が付きました。これで手打ちは不要になりました。

9. 停電対策 — BIOS の自動起動

PBS の BIOS（AMI Aptio 2.22.1287）の Advanced タブで、停電復帰時の自動起動を On にしました。

今回の「電源が入っていなかっただけで12日間止まっていた」という事態は、まさにこれで防げます。誰も見ない機械だからこそ、自力で戻ってくる設定は必須だと感じました。

10. メモリの謎が解けた

しばらく再起動していなかった MINISFORUM を再起動したところ、VM101 のメモリ使用表示が 19〜20GiB から 2.64GiB へ激減しました。

理由は2つ重なっていました。

  1. Linux は空きメモリをファイルキャッシュとして使い切る（8日間動いていれば 20GiB を埋めるのは当然）
  2. Guest エージェントが未設定のため、Proxmox にはゲスト内部の内訳が見えず、QEMU が確保したページの総量しか分からない。この数字は一度触ったら減らない

つまり、あの「95%」は不足のサインではありませんでした。

対策として VM101 に qemu-guest-agent を導入し、active を確認しました。PVE 側で qm set 101 --agent enabled=1 を入れ、VM の再起動で有効になります。これで表示が実態を反映するようになり、バックアップ時のファイルシステム静止も効くようになります。

11. メモリ 128GB を購入

Crucial CT2K64G56C46S5（DDR5 SO-DIMM 64GB×2 ＝ 128GB）を購入しました。明日到着します。

N5 Pro の公称上限は 96GB ですが、Amazon のレビューに 128GB が認識されて動作しているとの報告があり、人柱を承知で採用しました。ECC は入手困難のため非 ECC です。

換装前に控えた現状は以下の通りです。

Reddit に、F8NAB の機体に F8NAA 用の BIOS パッケージが送られて ROMID mismatch になった事例がありました。基板系統ごとに BIOS のバージョン番号は別系列なので、単純比較できません。

方針としては、まず 1.04 のまま 128GB を挿す。認識すれば BIOS には触らない。診療の中核が乗っている機械なので、触らずに済むなら触らないのが正解と判断しました。

なお 64GB モジュールは Dual Rank のため、速度は 3600〜4400 MT/s あたりに落ちる可能性があります。容量が取れていれば成功と考えます。

12. 自宅へ移設 — 遠隔バックアップの確立

夜、PBS を自宅へ持ち帰りました。設定を何も変えずに立ち上がりました。狙い通りです。

院内の PVE から確認したところ、

グローバル IP 宛の直接接続で 24ms。中継経由ではありません。心配していた MappingVariesByDestIP: true の影響は出ませんでした。

これで 3-2-1 が本来の形に戻りました。火災・盗難・機器故障には対応できます。

ただし距離が近いため、広域災害には無力です。3つ目として遠隔地への複製を検討中で、候補はさくらインターネットと Cloudflare R2。患者データを扱う以上、国内保管で説明しやすいさくらを軸に考えています。PBS 4.2 は S3 データストアが正式対応になっているため、技術的にはどちらも素直に繋がります。着手は、今の形を数日回して安定を確認してからにします。

13. UPS 導入 — CyberPower CPJ500

自宅の PBS 用に UPS を導入しました。500VA/300W、常時商用給電、バッテリ動作時も正弦波出力です。

Debian 13 の NUT（2.8.1）で監視設定をおこないました。

upsc cpj500 の実測値は以下の通りでした。

項目 値
ups.load 11%（300W 中およそ33W）
battery.runtime 5375秒（約89分）
battery.charge 100%
input.voltage 101.0V
ups.status OL

カタログの「半負荷時11分」に対し、負荷が軽いため大幅に伸びています。89分持てば、たいていの停電は乗り切ってしまいます。

実地テストとしてコンセントを抜いたところ、ups.status: OB DISCHRG に変化。戻すと OL に復帰。検知は正常でした。

なお input.voltage.nominal: 220 と表示されますが、これは CyberPower 側の申告値の癖で異常ではありません。

これで、停電を検知 → 89分粘る → 復電しなければ自動で安全にシャットダウン → 復電したら BIOS の設定で自力起動という流れが完成しました。自宅に誰もいなくても、勝手に守って勝手に戻ります。

14. 電話筐体の確定

FreePBX の移設先を Getorli miniPC（Ryzen 7 255）＝ PVE2（電話筐体） に決めました。当初からの「PVE2 = 電話筐体 / PVE1 = バックエンド、クラスタは組まない」という構想通りです。

今日 PVE を一日止めていましたが、もし FreePBX が本稼働中だったら、その間ずっと電話が不通でした。まだ本稼働前なので、動かすなら今が最適です。

方針として決めたこと。

また、FileMaker サーバー（Minisforum の miniPC、Windows Server 運用）が不要になりました。データを PostgreSQL に移行してからリセットする予定です。この筐体が空けば、3台体制が組めます。

OCuLink で GPU を試すのも、ComfyUI を入れて消すのも、3台目でやれます。買い足す必要がありません。

15. 残っている宿題

おわりに

朝の「さあ復旧しましょう」から、ずいぶん遠くまで進んだ一日でした。

今日いちばんの教訓は、思い込みで原因を決めないということだったように思います。「PBS の設定が壊れている」も、「Omada の DHCP が止まっていた」も、「.164 が衝突している」も、すべて外れでした。実測を1つずつ積み上げていった結果、真犯人は「電源が入っていなかった」「dhclient が無い」「別のルータが DHCP を返していた」という、いずれも地味な事実でした。

そして、趣味として調べていたことが、そのまま診療の安全につながりました。バックアップの12日間の空白が埋まり、患者さんのデータについて「最悪でも前日まで戻せます」と言い切れる状態に戻りました。

明日はメモリ換装です。

← 院長のお話一覧へ戻る