その障害の記録と、そこから海外VPS(レンタルサーバー)へ移った記録。壊れた機械からデータを転送するのではなく、毎晩取っていたクラウドバックアップからVPS側へ引っ張って復元したのが一番再利用できる部分だと思う。実際の停止時間は26分だった。そして移行後、自宅のルーターの内側にいたから気づかずに済んでいた穴が一気に表に出た。

前提

• 自宅のWindows機〈ノート型〉(WSL〈Windowsの中でLinuxを動かす仕組み〉上でサーバーを動かしていた)で、Immich(写真)・Nextcloud(ファイル)・Vaultwarden(パスワード)・Authentik(ログインの入口)など常時14コンテナを動かしている状態
• 外部公開はCloudflare Tunnel(ルーターに穴を開けずにサーバーを公開する仕組み)経由で、ルーターのポート開放は一切していない
• 毎晩rclone(いろいろなクラウドストレージへファイルを同期するコマンド)でBackblaze B2(安価なオブジェクトストレージ)へ日次バックアップを取っている
• 構築の土台は自分の「サーバー」を持つとはどういうことか、バックアップの設計はバックアップを「消されても戻せる」形にする

何が死んだのか

最初の症状は、自分のドメインを開くとCloudflare Error 1033(トンネルの出口であるサーバー側にCloudflareが接続できない時のエラー)が出たこと。Cloudflareの障害情報ページには何も出ていない。別経路のリモートデスクトップで見ると「最後のオンライン 12:07」でオフライン表示。トンネルが切れたのではなく、サーバーの入っているPC自体が落ちている。

遠隔からできることは何もなかった。SSHも入れない。Cloudflare Tunnelは「サーバーが生きていれば外から入れる」仕組みなので、サーバーが死ぬと一緒に死ぬ。

帰ってから見たPCの状態がこれ。電源は入っていて画面も出ているのに、マウスカーソルが一切動かない。 キーボードも効かない。ブルースクリーンも出ていない。電源ボタンの長押しで強制終了して再起動したら、何事もなかったように復旧した。

後日イベントログを調べて停止時間が確定した。

EventLog ID 6008
"The previous system shutdown at 11:11:13 AM on 9/21/2026 was unexpected."

このログが記録されたのは9/26 23:45(自分が強制再起動した時刻)。つまり9/21 11:11:13にハングして、そこから5日半固まったままだった。

• 9/21〜9/26の間、Systemログにイベントが1件も記録されていない。完全な空白。瞬断の繰り返しではなく、OSが本当に何も処理できない「サイレントハング」だった裏付けになる。
• ブルースクリーンのダンプファイルが無い(残っていたのは1年半前の古いものだけ)。ディスプレイドライバのクラッシュログも0件。写真の顔認識にGPU(画像処理用の高性能な部品)を使っていたのでGPUドライバのハングが一番疑わしい候補だったが、ログが書かれる前に固まった可能性もあり確定できなかった。

根本原因は今も分かっていない。 BSODもエラーログも残さず固まる種類の故障は、原因究明が原理的に難しい。

🔴 ここで一度、原因を誤診した。 強制再起動後に別のソフトの認証セッションが切れていたので、最初はそれが5.5日の原因だと分析した。実際は「PCが固まっていた」が唯一の原因で、セッション切れは再起動後に浮上した二次的な問題だった。復旧直後に見つかった不具合は、障害の原因ではなく結果であることがある。 時系列のログで裏を取るまで原因を名指ししない。

なぜVPSに移ることにしたか

最初に考えたのは、もっと安い対策ばかりだった。ウォッチドッグタイマー(固まったら自動でリセットする機能)、GPUドライバの更新、旅行時はSSHできる端末を必ず携帯する運用ルール。

🔴 「スマートプラグで遠隔から電源を入れ直す」案は、そもそも使えなかった。 サーバーにしていたのはノート型のWindows機で、内蔵バッテリーがあるのでコンセントを切っても電源は落ちない。ノートPCを常時稼働のサーバーに流用するのは「静かで省電力」という利点があって自分もそれで選んだのだが、固まったときに遠隔で殴る手段を一つ失うという代償がついてくる。これは置き場所を決める段階で知っておきたかった。「WindowsをやめてこのPCを素のLinux専用機にする」案も検討したが否定的な結論になった。マウスも効かないOS全体の停止なのでLinux側だけの不調ではなく、原因がGPUドライバなら素のLinuxでも再発しうるので、OS再インストール＋全サービス移行という大工事に見合う保証がない。

それでも移行を決めた理由は、数日後に同じサイレントフリーズが再発したこと。原因が分からない以上「次はいつ、どれだけ止まるか」が見積もれない。データセンターの機械なら、少なくとも電源とネットワークと物理的な復旧は他人の仕事になる。

VPSの比較で実際に効いた軸

2026年9月時点の調査値。今は変わっているはず。

効いた軸は4つ。

① ディスク容量が最優先。 写真のライブラリが実測115GB、ファイル同期が16.6GB。OS・Docker・データベースを含めて170〜180GBと見積もり、200GBのプランにした。「写真が増えるたびに月額が雪だるま式に増えるのが嫌だ」という条件があったので、同じ値段でどれだけディスクが付いてくるかが一番差の出る軸になった。

② メモリは写真の量ではなくコンテナの数で決まる。 ここは一度自分で間違えかけた。「古い写真をクラウドへ逃がすならメモリも小さくていいのでは」と考えたが違う。常時14コンテナが動いていて、以前メモリ不足で全サービスが繰り返し落ちた実績がある。しかもVPSにはGPUが無いので、顔認識や画像検索の処理をCPUとメモリでやることになり、必要メモリはむしろ増える。8GBではなく12GBから始め、安定を確認してから下のプランへ落とす順序にした。

③ リージョン(どの国のデータセンターか)は在庫で決まった。 第一候補にしていたリージョンは月+$4.90の追加料金がつく上に、申し込み画面で在庫切れだった。追加料金ゼロで常に在庫があるリージョンに変えたら、結果としてバックアップ先のB2との経路が短くなり、復元も移行後の日次バックアップも速くなるという副産物があった。「近いほうが良いに決まっている」と思い込んでいた軸が、実際には料金・在庫・バックアップ先との距離で裏返った。

④ 遅延は実測すると論点が変わる。 申し込み画面の「近いリージョン4ms、遠いリージョン158ms」は生のネットワーク遅延で、Cloudflare Tunnel経由の実構成には当てはまらない。自宅のPCで動かしていた時点ですでに写真サーバーの初期応答は73〜87msだった。DNSがCloudflareを指しているので、自宅のWiFiからでも一度エッジへ出て戻る経路になり、「目の前にあるから速い」状態には元々なっていなかった。移行後は0.55〜0.7秒(自宅PC時代は0.3秒前後)。比較のためにGoogle Photosのアプリ画面を測ると248〜255msで、「すでに受け入れている遅さ」と同程度だと分かったので許容できる論点に落ちた。

• 🔴 サムネイルをCloudflare側にキャッシュさせれば速くなるが、それは自分の写真をCloudflareに置かせることになるのでやらない。速度のために主権を手放すなら移行の意味がない。

契約は6vCPU / 12GB RAM / 200GB SSD / 転送量無制限、Ubuntu 24.04、1ヶ月契約で月$9.00、初期費用ゼロ。年契約の割引は見送った。原因不明の障害から逃げるための移行で、移行先が気に入らなかった時にすぐ降りられないのは本末転倒だから。

移行方式: 壊れた機械から運ぶのをやめる

ここが今回の中心。

普通に考えると、移行とは旧サーバー → 新サーバーへデータを直接転送することだ。ランブックの最初の案もそうなっていた。150GBをrsync(差分だけコピーするコマンド)で送る、数時間〜半日かかる、という計画。

これを見て思ったのが、**「毎晩クラウドにバックアップを取っているのだから、新サーバーがそこからダウンロードすればいいのでは?」**だった。採用した。

これまでの案:  自宅PC ──(細い家庭回線)──> 新VPS
採用した案:    自宅PC ──> B2(クラウド) ──(データセンター間)──> 新VPS

1. 自宅の細い上り回線に依存しない。VPS↔B2はデータセンター間なので桁違いに速く、実測で約30MB/sだった。
2. 旧サーバーが移行作業中ずっと安定している必要がない。これが決定的だった。5.5日固まる機械を、半日の転送が終わるまで無事でいてくれと祈りながら使うのは設計として間違っている。
3. 既にそこにあるので準備作業がゼロ。写真の本体もデータベースのダンプ(中身を1つのファイルに書き出したもの)も毎晩同期済み。
4. ついでに災害復旧の予行演習になる。「クラウドのコピーしか残っていない状態から戻せるか」を本番で一度やることになるので、バックアップが本当に使えるのかが確定する。

鶏と卵の問題は先に解いてあった

前提がある。B2から引っ張るにはB2へのアクセス鍵が必要で、その鍵が旧サーバーの中にしか無ければ、サーバーを失った時点で何も取り出せない。

ここは1ヶ月前に手を打ってあった。B2アクセス用のrclone設定、Cloudflare Tunnelの設定、docker-compose.yml一式、環境変数ファイルの内容を、Vaultwarden(自分のパスワード管理サーバー)にSecure Note 4件として複製保存していた。 Vaultwardenのモバイルアプリはオフラインキャッシュを持つので、サーバーに一切アクセスできなくてもスマートフォンから取り出せる。後日このメモに書かれた値だけでB2上の全データが見えることを実測で確認した。🔴 この検証は鍵を入れ替えるたびに毎回やる。 「保存したつもり」で中身が古い、という事故が一番ありそうな場所だから。

ランブックの形

手順はPhase A〜Hに分けて1つの文書にした。実行中にその場で考える余地を削るのが目的で、特にDNSの切り替えは後戻りの判断が数秒で要る。

Phase A  旧サーバーを止めて最終バックアップ
Phase B  Vaultwardenから鍵4件を取り出す
Phase C  新VPSの初期設定(ユーザー・SSH鍵・Docker)
Phase D  B2から rclone copy でデータを引っ張る
Phase E  データベースのダンプをリストア
Phase F  docker-compose を復元してコンテナ起動
Phase G  新しいトンネルを作ってDNSを1本ずつ切替
Phase H  移行後(バックアップの再構築・監視・検証)

書き上げた最初の版には穴が4つあり、実行前のレビューで直した。

• 稼働中のままコピーしたパスワードデータは壊れている可能性がある。 Vaultwardenのデータベースファイルは書き込み中にコピーすると不整合になりうる。当日はコンテナを止めてからバックアップを手動実行する手順に変えた。これで「日次バックアップから最大24時間分が欠ける」問題も同時に消える。
• 🔴 イメージのバージョンを固定せずに復元すると壊れる。 データベースのダンプは、取得した時点のソフトのバージョンの構造に紐づいている。docker compose pullで最新版を取ると構造が合わなくなる。
• 環境変数ファイルの復元元を間違って書いていた。 以前使っていたパスワード管理サービスは解約済みで、正しくはVaultwardenだった。手順書は、書いた時点では正しくても構成変更で腐る。
• 🔴 同じトンネルを2台のホストで同時に動かしてはいけない。 リクエストが2台にランダムに振り分けられて、「たまに繋がらない」という一番デバッグしづらい障害になる。新しいトンネルを別に作って、DNSを1本ずつ向け替える形にした。

他に決めておいたこと。

• rclone copyを使い、syncは使わない。syncは転送元に無いファイルを転送先から消す。過去にこれで必要なディレクトリを消して障害にした実績がある。
• 切替順序: 一番軽いパスワードサーバー → ログインの入口(最重要。落ちると他のサービスにログインできなくなる) → ファイル → 写真 → 残り。旧サーバーへのSSH経路は一番最後。 先に向け替えると旧サーバーに入れなくなって確認作業ができない。
• DNSのTTL(切替が反映されるまでの待ち時間)を事前に短くする手順は不要だった。 対象レコードは全部Cloudflareのプロキシを通る設定で、外に返るアドレスは切替前後で変わらない。振り分けはCloudflare内部で起きるので書き換えの数秒後に反映され、戻すのも数秒。TTLを下げる必要があるのは、プロキシを通さずサーバーのアドレスを直接返している場合だけ。

実際の停止時間は26分

15:19にサービスを止めて、15:45に全部復帰した。 写真150GBを運ぶ移行としては想定よりはるかに短い。クラウド経由にしたことで、一番重い写真の転送が「停止中にやる作業」から外れたのが効いている。

復元後の検証値は、写真59,104ファイル(rclone checkでB2との差分ゼロ)、写真サーバーの登録件数29,720件、ファイル同期サーバー144テーブル・16.6GB、ログイン入口のユーザー3件。

ランブックに書いていなかった落とし穴

• 🔴 浮動タグが他にもあった。 バージョン固定は写真サーバーだけ警告していたが、ファイル同期・データベース・パスワード管理も:latest(常に最新を取るタグ)のままだった。旧サーバーで実際に動いているイメージのダイジェスト(内容に対する一意の識別子)を全部調べて固定した。docker inspectの.Imageはそのマシンの中だけのIDでダウンロードには使えないのでRepoDigestsを使う。
• 🔴 写真サーバーが起動ループした。 Failed to read /data/encoded-video/.immich。サムネイルと変換済み動画のフォルダをバックアップ対象から外していたため、そのフォルダにある整合性チェック用の目印ファイルまで一緒に欠けていた。空のフォルダではなく「目印だけがある」状態が必要だった。
• ファイル同期サーバーがCannot write into "config" directory!で503。 rcloneはファイルの所有者情報を保持しないので、復元したファイルが全部自分のユーザーの所有になっていた。クラウド経由の復元では所有者が落ちることを前提に、復元後のチェック項目に入れておく。
• 🔴 ユーザーのIDが揃っていなかった。 新VPSに旧サーバーと同じ名前のユーザーを作ってパスを揃えたので、設定ファイルを無改造で使い回せた。これは正解だった。ただし名前は同じでも内部の数値のIDが1つずれていて、一部のコンテナ内でNo user exists for uid 1001で落ちた。名前だけでなく数値IDまで揃える必要がある。
• 「Dockerのデータとワークスペースを移せば終わり」ではなかった。 動画変換用のコマンドや日本語フォントといったホスト側のOSパッケージが新VPSに無く、移行の夜に機能が動かないことで発覚した。さらにcron(定時実行の仕組み)自体が未インストールで、登録コマンドが黙って失敗していた。バックアップの自動実行が最初から動いていないところだった。
• 🔴 写真46件が旧サーバーにしか存在しなかった。 復元結果をファイル単位で突き合わせて翌日見つけた。データベースには46件の記録があるのに、写真の実体がVPSにもB2にも無い。原因は、移行当日の最終バックアップでデータベースのダンプは成功し、写真の同期ステップが完走しないまま終わっていたこと。しかも旧スクリプトはステップごとの成否をログに出していなかったので無言で失敗した。旧サーバーがまだ生きていたので手元から押し出して復旧できたが、運が良かっただけ。
  • 教訓1: 復元の検証を「ファイル数の一致」でやってはいけない。 60,525件と60,619件で0.15%差。見逃す水準だった。データベースに記録されているパスが1件ずつ実在するかを全件突き合わせる必要がある。
  • 教訓2: バックアップスクリプトはステップごとにOK/FAILをログへ出す。 まさにこの欠陥を直すつもりだった移行当日に、その欠陥に刺された。

公開IPになって初めて出た問題

ここが一番多くの人が外すところだと思う。移行そのものより危ない。

自宅のPCはルーターの内側にいた。 だから、どのサービスが「外から直接届く形」で動いていようが、外からは届かなかった。Cloudflare Tunnelという1本の出口だけが外部との接点だった。VPSは公開IPを持っている。 全部のポート(通信の入口の番号)が、世界中から直接叩ける状態で始まる。ランブックにこの観点は1行も無かった。

① 中身が剥き出しで公開されていた

写真サーバーのログイン画面が生で公開されていた。Cloudflare側のログイン要求を通らない素の入口。ログイン入口サーバーのHTTPSポートも公開で、本来Cloudflare側の防御を通ってから届くはずのものが迂回できる状態。小さな静的サイトのポートも開いていた。

原因はdocker-compose.ymlのports:の書き方。

ports:
  - '2283:2283'            # 🔴 これは全てのネットワークに向けて開く
  - '127.0.0.1:2283:2283'  # ✅ 自分自身からしか届かない

自宅では両方とも同じ結果になるので、違いに気づく機会がなかった。トンネル経由で公開する構成なら、外に向けて開く必要は最初から無い。

応急処置としてファイアウォールで遮断し、後日、設定ファイル側を127.0.0.1に直して「ファイアウォールで塞いでいる」状態をやめた。この順序は意図的で、ファイアウォールなら数秒で塞げるがコンテナの作り直しは止まる時間が出るから。ただし応急処置で終わらせない。ファイアウォールは1行消えれば無防備に戻るが、そもそも誰も外向きに待ち受けていなければ消しようがない。

② SSHのパスワードログインが「無効にしたのに有効」だった

/etc/ssh/sshd_config.d/50-cloud-init.conf   ← PasswordAuthentication yes
/etc/ssh/sshd_config.d/99-hardening.conf    ← PasswordAuthentication no(自分が書いた)

SSHのサーバーは「最初に見つけた値」を採用する。 番号が小さいファイルが先に読まれるので、99番に書いた自分の設定は永遠に負ける。VPSの初期設定が置いていった50番のファイルを無効化して解決した。🔴 設定を書いたら、書いたことを確認するのではなく、効いているかを確認する。 鍵でログインできることと、パスワードが本当に拒否されることの両方を実測する。

③ IPv6が完全に丸腰だった

ここが一番ひやりとした。遮断はしたが、IPv4のファイアウォールだけだった。

VPSにはIPv6のアドレスも付いている。確認すると、IPv6側のファイアウォールのルールは空、ポリシーは全通過。コンテナはIPv4とIPv6の両方で待ち受けていたので、塞いだつもりの写真サーバーのログイン画面は、IPv6経由では公開されたままだった。🔴 IPv4を塞いだら必ずIPv6も確認する。 設定は完全に別物で、片方だけやっても「塞いだ」とは言えない。

④ 認証なしのポート19本が素通しだった

自分のアシスタントが外部サービスと喋るための中継プロセスが、ポート19本で認証なしで待ち受けていた。ファイアウォールのルールも無かった。この中の1本は自分のメールの受信箱に繋がっていた。 写真のログイン画面(少なくともパスワードは要求する)より危険度は上だった。

思い込みが穴を作った。「外に出ているポートはdocker-composeのports:に書いてあるものだけ」と思っていた。これらはコンテナではなくホスト上で直接動いているプロセスなので、Docker向けのファイアウォール設定では止まらない。棚卸しの書き方にも罠がある。

# 🔴 これでは漏れる
ss -tlnp | grep 0.0.0.0

# ✅ 「自分自身以外」を除外方式で全部出す
ss -tlnp | grep -vE "127\.0\.0\.|\[::1\]"

待ち受けアドレスの表記は0.0.0.0:PORTだけではない。*:PORTという表記(IPv4とIPv6の両方で待ち受け)もあり、0.0.0.0では引っかからない。 19本はこの形で見落とされていた。**「危ないものを探す」のではなく「安全なものを除外して残り全部を見る」**書き方にしないと漏れる。

後日これも応急処置をやめて根本を直した。使っていた中継ソフトには待ち受けアドレスを指定するオプションが存在しなかったので、ソフト側のコードを1行書き換える形になった。直した後の確認が気持ちよかった。公開IPへは「接続拒否」が返る — ファイアウォールで弾いているのではなく、そもそも誰も待ち受けていない状態になった。これが一番強い証明。

⑤ ファイアウォールの確認は、そのサーバー自身からでは絶対にできない

遮断ルールには「外部から来た通信に対して」という条件が付く。VPSの中から自分の公開アドレスに繋ごうとすると内部の経路を通るので、必ず「繋がる」と出る。 塞がっているのに塞がっていないように見える。

# 別のパソコンから実行する(VPS内からでは意味がない)
nc -vz <サーバーのアドレス> 2283   # → Operation timed out  が正しい
nc -vz <サーバーのアドレス> 22     # → succeeded!            が正しい
nc -vz -6 <IPv6アドレス> 2283      # IPv6も必ず測る

この外部からの実測を、VPSを再起動した後・ファイアウォールを触った後・docker-composeを触った後に回す定型チェックとして手順書に書き出した。

⑥ 監視が自分の死を通報できない

死活監視にUptime Kumaを使っているが、それが監視対象と同じVPSの上で動いている。VPSごと落ちたら監視も一緒に落ちて通知が飛ばない。一番知りたい障害だけ通報されない。 バックアップの記事で書いたデッドマンスイッチ(生存信号が途絶えたら警報を出す仕掛け)と同じ構造なので、B2の複製先を見張らせていたGitHub Actions(GitHubが決めた時刻にスクリプトを自動実行する仕組み)に死活監視を1本足して解決した。サーバーの外で動くので、サーバーが丸ごと死んでも黙らない。

再起動して自分で戻ってくるかを確かめる

移行が完了した状態は、一度も再起動していない状態でもある。「今動いている」と「電源が落ちても自分で戻ってくる」は別の話で、自宅サーバー時代は再起動のたびに何かが立ち上がらない問題に何度も遭遇していた。

事前に、systemdのユニット7件がすべてenabled(起動時に自動で立ち上がる設定)か、コンテナ14個の再起動ポリシーがunless-stoppedかalwaysかを確認した。ファイアウォールのルールを永続化する仕組みも必ず含める — ここが抜けると再起動で遮断ルールが消え、さっき塞いだ穴が全部開く。厄介な事情が1つあって、自分のアシスタント自身がこのVPSの上で動いているので、再起動すると自分との会話も切れる。1分の猶予を置いて再起動し、復旧手順をチャットの外に控えておく段取りにした。自分を再起動する作業は、自分以外の場所に手順を置いてから実行する。

結果は成功。22秒で起動し、systemd 7件・コンテナ14個すべて稼働、全9サービスがHTTP 200/302、データも再起動前と完全一致。そして外部のパソコンからのnc実測で、遮断したポートはOperation timed out、SSHはsucceeded! — 永続化が再起動をまたいで効いていることを外部視点で立証できた。

後日ディスクを増設した時にこちらの意図しない強制リセットが起きた(公式ヘルプには「再起動不要」と書かれていたが実態は違った)。その時も全部がデータ欠損ゼロで自動復帰したので、この検証が本物だったことは意図せず二重に確認できた。増設系の作業は、公式が無停止と書いていてもダウンタイムを見込む。

結果

• 原因不明の5.5日間停止から、26分の停止で海外VPSへ移行した。月額は$9.00から始まり、後にディスク増設で$12.60
• 応答は0.3秒前後から0.55〜0.7秒に落ちた。遅くなったのは事実で、これは引き受けた
• 公開IPになって初めて出た露出を6種類見つけて塞いだ。うち2種類(IPv6と、認証なしの19本)は最初の対処では見落としていた

旧サーバーはすぐ捨てずに2週間温存した。これは正解で、移行翌日に「写真46件が旧サーバーにしか無い」と判明した時に助かった。復元の検証が全部終わるまでは、古い機械を消してはいけない。

そしてハングの原因は今も分かっていない。分からないまま、分からないものに依存する構成をやめた、というのが今回やったことの全部だ。

更新履歴 — 2026-10-05: 初版

結論を先に書くと、自分は古い写真を安いオブジェクトストレージへ追い出す仕掛けを一晩かけて作り、動くところまで確認してから、全部捨てた。業者が月$3.60でディスクを足せると分かったからだ。その遠回りの中身を書く。

前提

• 写真はGoogle PhotosからImmichに移した状態（Immich = 自前サーバーで動かす写真管理ソフト）
• サーバーは自宅PCからVPSへ移した直後（VPS = 仮想専用サーバー。業者のデータセンターにある自分専用のLinuxマシンを借りる形）。Contaboの6vCPU / 12GB RAM / SSD 200GB のプランで月$9.00（2026年9月時点）
• バックアップ先はBackblaze B2（安価なオブジェクトストレージ。2026年9月時点で1TBあたり月$6.95）。構成はバックアップを「消されても戻せる」形にする
• 土台の考え方は自分の「サーバー」を持つとはどういうことか

まず現実を測った

移行直後のディスクはこうだった。

df -h /
# 使用 164GB / 193GB、空き 29GB

しかもこの時点でサムネイル（一覧表示用の縮小画像）がまだ生成されていなかった。以前のサーバーでは9.6GBあったので、それが戻ると空きは約19GB。200GBのプランを選んだ数日後にもう先が見えた。

次に増える速さを測った。Immichのデータベースに撮影年が入っているので、年ごとに集計できる。

select extract(year from a."fileCreatedAt"), count(*), pg_size_pretty(sum(e."fileSizeInByte"))
from asset a join asset_exif e on e."assetId" = a.id
where a."deletedAt" is null group by 1 order by 1;

実測（写真の実体は合計115GB）。

• 直近3年分の合計で約22GB。年あたり3〜10GBのペース
• それより古い分が約19,000件・約93GB

つまり今の撮り方で年10GB弱。29GBの空きは3年もたない。いずれRAW（カメラが記録した無加工のデータ。1枚25〜50MB）で撮り始めたら桁が変わる。「毎年ちょっとずつ月額が増えていく」のが一番嫌だったので、容量と月額を切り離す方法を探し始めた。

最初の案: 古い写真を安いストレージへ追い出す

サーバーのSSDには直近1〜2年の「よく見る」写真だけ置き、古い写真はB2に預けて見たいときだけ取り出す。 SSDの使用量が年によらず一定になるので月額が増えない。B2には毎晩のバックアップで全写真の実体がすでにあるから、アップロードすらいらないのが魅力だった。

方式をいくつか捨てた

• 🔴 Immichの「External Library」（外部ライブラリ）機能は使えない。サーバーの外のフォルダを読み込む機能だが、すでにImmichの中にある写真を引き取れず、新規の写真として再登録される。アルバム・顔認識の結果・お気に入りが失われる恐れがある。
• 🔴 「年ごとのフォルダを切り出す」はそもそも不可能。ディスク上の写真はlibrary/upload/<ユーザーID>/<16進2桁>/<16進2桁>/<ランダムな名前>.拡張子という形で、ランダムな名前のハッシュで256×256のフォルダに均等にばらまかれている。年ごとのフォルダは存在しない。

残ったのは、写真ファイル1個ずつをシンボリックリンク（ファイルの位置を指すだけのショートカット）に置き換え、リンク先をB2をフォルダとして見せた場所に向ける方式。データベースに一切触らないので、Immichから見れば何も変わらない。B2をフォルダとして見せる部分はrclone（いろいろなクラウドストレージへファイルを同期するコマンド）のマウント機能で、読み取り専用で常駐させた。

# /etc/systemd/system/rclone-immich-cold.service の要点
ExecStart=/usr/local/bin/rclone mount <リモート名>:<バケット>/immich-cold \
  /home/<user>/immich/library/cold \
  --read-only --allow-other --uid 1001 --gid 1001 \
  --vfs-cache-mode full --vfs-cache-max-size 3G --dir-cache-time 24h

ここで踏んだもの。

• rcloneの場所は/usr/local/bin/rcloneで、/usr/bin/rcloneではなかった。systemd（Linuxの常駐サービス管理）はそれだけの理由で203/EXECと言って起動に失敗する。which rcloneで確かめる。--allow-otherには/etc/fuse.confへのuser_allow_otherの追記も必要。
• --dir-cache-timeは必ず延ばす。既定の5分だと期限切れごとにフォルダ一覧の問い合わせが全件走る。24時間にした。
• 🔴 Immichのコンテナ設定で写真フォルダのマウント指定に:rslaveを付けないと見えない。docker-compose.ymlの${UPLOAD_LOCATION}:/dataを${UPLOAD_LOCATION}:/data:rslaveにする。コンテナ（ソフトを隔離した箱に入れて動かす仕組み）へのフォルダ受け渡しは既定で「あとから生えたマウントを伝えない」ので、ホスト側で後から作ったマウントはコンテナの中からは空に見える。ここで30分溶かした。なおdocker compose up -d immich_serverはno such serviceになる——設定上のサービス名はハイフンのimmich-server、コンテナ名がアンダースコアのimmich_server。

一番危なかったのはバックアップスクリプトだった

実験で確証を取った、本当の地雷。毎晩のバックアップはrclone sync（送り元に無いものは送り先からも消す片方向ミラー）で動いている。ローカルの写真をシンボリックリンクに置き換えると、rcloneはCan't follow symlink without -L/--copy-linksと言ってそれをスキップし、「送り元に無い」と判断してB2側の実体を削除する。

• 🔴 行き先が存在しない壊れたリンクでも同じ挙動で、しかも終了コードは0（＝成功として記録される）。失敗として検知できない。つまり最も危険な順序は「B2へコピーする前にシンボリックリンクを作ってしまう」ことで、やると、その夜のバックアップがB2にある唯一の実体を無言で消す。
• --copy-linksを付ける解決策は不可。B2に二重保存になって容量が倍になる。

正解は--exclude "cold/**"で追い出し先を同期対象から外し、かつ順序を守ること。

# 1. B2の中で複製（同一バケット内のサーバーサイドコピー＝転送ゼロ・一瞬）
rclone copyto REMOTE/immich/library/<rel> REMOTE/immich-cold/<rel>
# 2. 宛先のサイズを照合
rclone lsl REMOTE/immich-cold/<rel>
# 3. ローカルの実体は「削除」ではなく退避（ロールバックできるように）
mv library/upload/<rel> /root/poc-staging/<rel>
# 4. 相対パスのリンクを張る（library まで ちょうど4階層）
ln -s "../../../../cold/<rel>" library/upload/<rel>
chown -h <user>:<user> library/upload/<rel>
# 5. リンク越しに md5 を照合。違ったら即ロールバック
# 6. 全件の検証が終わってから、はじめて旧パスを削除
rclone deletefile REMOTE/immich/library/<rel>

• 存在確認にrclone lsjsonを使ってはいけない。存在しないファイルを渡すとフォルダとして扱われ、空の一覧と終了コード0を返す。これで一度「B2にある」と誤判断した。rclone lslの出力が空でないことを見る。

10枚で通して、確認したこと

PoC（Proof of Concept = 動くことを示すための小さな実装）として写真10枚・46MBで最後まで通した。ホストからもコンテナの中からも同じmd5で読め、ImmichのAPI経由でオリジナル画像が10/10でHTTP 200かつmd5一致、サムネイルは10/10がローカルから配信（一覧の表示速度は一切変わらない）、エラーログなし。B2からの初回読み込みは0.39秒（636KB）、キャッシュ後は0.017秒。

そして最も確認したかったこと: マウントが切れたらどうなるか。systemctl stopで接続を落として測った。

• オリジナル画像は404、サムネイルは200のまま
• 写真のレコード件数は前・中・後で29,716件のまま不変、該当写真の削除日時もnullのまま
• マウントを戻すと即座に200に復帰

つまりImmichは、ファイルが読めなくなっても勝手にレコードを消したりゴミ箱に落としたりしない。これが成立しなければ全部やめるつもりだった。

安全網が既にあったことも実測した。B2のバケットは「隠してから30日で削除」の設定にしてあり、rclone deletefileは既定でハード削除ではなく論理削除。だから消したファイルは30日間復元できる。15分前に消した2.1MBのHEICをrclone lsf --b2-versionsで版名（<名前>-v<日時>.<拡張子>）を調べて取り出し、md5一致まで確認した（--b2-versionsを付けても元のファイル名を渡すと失敗するので、必ず版名で指定する）。これで「スクリプトのミスで写真が消える」は永久喪失ではなく30日以内なら戻せるミスに格下げされた。残る課題は復元手段ではなく30日以内に気づくことになる。

途中で前提そのものを疑った

10枚が通った時点でB2からの読み出し速度を測り直して、気が変わった。197MBのデータベースダンプが6.58秒＝約30MB/s、17MBの写真が単一ストリームで0.52秒＝約33MB/s（265Mbps）。一方で手元の動画は535本・平均11.6MB、ビットレートは平均7.3Mbps・上位5%で17.9Mbps・最大67.5Mbps。最も重い動画でも4倍近い余裕がある。

それなら「古い写真を追い出す」のではなく、写真の置き場そのものをB2にすればいいのではないか。SSDの天井が消える。コストも、写真をB2に置けば月$10前後、1TBまで増えても月$16で、大きいディスクのプランへ引っ越す月$19より安い。安いほうが天井も無いという綺麗な結論になりかけた。

そこで手を止めて2つ調べた。

自分以外に誰がやっているのか

• 主流は「オリジナルはローカル、クラウドはバックアップ専用」。Immich公式のバックアップ手順もローカル本番を前提に書かれている。クラウドを本番の置き場にしている例は少数派・実験的で、数少ない実践者は「わずかなレイテンシのゆらぎでマウントが壊れる」「ローカルキャッシュがすぐ溢れる」と報告している。
• 「クラウドが唯一のコピー」でやっている人は、調べた範囲で1人も見つからなかった。 定番は3コピー（本番＋ローカルの2本目＋クラウド）。
• 🔴 Immichに未解決の不具合がある: issue #10480 — サムネイル生成が同じファイルを2回読むため、リモートストレージではダウンロード量が実データの8〜10倍に膨らむ。16,000ファイル・110GBで900GBという報告がある。B2の無料ダウンロード枠は保存量の3倍/月なので、サムネイルの全件再生成を一度回すと枠を超えて課金が出る。
• Immich本体のS3対応（オブジェクトストレージへの公式対応）は期待できない。2026年時点で未実装、ロードマップにも無い。**「待つ」は非現実的で、マウント方式が唯一の道（公式サポート外）**という整理になった。
• 追い風もあった。B2のAPI呼び出し課金が2026-05-01に全廃された（代わりに保存料が$6→$6.95/TB/月に値上げ）ので、「マウントが大量の一覧取得を発行して請求が爆発する」という有名な事故モード（過去に約$598の実例がある）は構造的に消えていた。

暗号化のコストを測った

クラウドに本番を置くなら預け先に中身を読まれない形にしたい。界隈の多数派も「上げる前に自分で暗号化する」だった。そして改めて気づいたのだが、自分の既存のバックアップは暗号化されていなかった。毎晩のバックアップを始めた時点で、預け先は写真59,000枚を読める状態だった。

17MBの写真で測った結果は、暗号化あり0.63〜0.95秒 / 平文0.46〜0.53秒。差は0.2〜0.4秒でボトルネックは回線のまま。暗号化は速度面の障害にはならない。

• ⚠️ 最初の計測では「暗号化7.01秒 vs 平文0.46秒＝15倍」と誤った結論を出した。原因は、比較した2つのマウントで--vfs-read-chunk-sizeなどの設定が揃っていなかったこと。ベンチマークは条件を揃える。 危うく「暗号化は無理」と誤った判断を下すところだった。
• 代償は速度ではなく別の2つ。①預け先のファイル名が不可読な文字列になり管理画面から中身を確認できない ②既存の115GBを暗号化し直すには全部アップロードし直す必要があり、「移行作業ゼロ」という最大の利点が消える。

本命の答えは、ボタンひとつだった

ここまで自分は「B2へ追い出す」「オブジェクトストレージを本番にする」「大きいプランへ引っ越す」の3つを丁寧に比較していた。そして契約しているVPSの管理画面を開いて、「ディスクだけ足す」という選択肢を一度も検討していなかったことに気づいた。

Contaboの管理画面には**「Extend SSD Storage」ボタン**がある。公式ヘルプにも、既存のVPSにSSDを足せる・再インストール不要・移行不要と書いてある。200GBを400GBにした。

月額の増分で並べるとこうなる（2026年9月時点）。

差額が月$2〜3しかないなら、その$2で複雑さを全部買い取れる。 一晩かけて作った仕掛けは、この表の2行目のためのものだった。

増設の実作業

公式ヘルプの「activated right away（即座に有効、再起動不要）」は実態と違った。⚠️ 増設は業者側の強制リセットを伴った——正常なシャットダウンの記録がなく、前のログが突然途切れている。増設するときはダウンタイムを見込むこと。 結果的に、予期しない電源断からの自動復旧が完全に機能することが実証できた（コンテナ14個・常駐サービス7件・公開している9サービスすべて復帰、写真のデータ欠損ゼロ）。棚からぼた餅の検証になった。

増えた分は既存ディスクの拡大として現れた（別のディスクとしてではない）。ただしパーティションとファイルシステムは自動では広がらないので、ここだけ手作業。

# 作業前に、必ず手動でバックアップを一度完走させる
/root/backup-scripts/backup-to-b2.sh

growpart --dry-run /dev/sda 1   # まず空振りで確認
growpart /dev/sda 1             # パーティションを広げる
resize2fs /dev/sda1             # ファイルシステムを広げる

• ルートのパーティションテーブルを書き換える操作なので、直前のバックアップは作法として必須。
• 対象が最後のパーティションで、直後に連続した空き領域がある理想的なケースだった。ext4にresize_inodeがあるのでマウントしたまま、無停止でオンライン拡張できた。
• 結果: パーティション199GB→399GB、ファイルシステム193GB→387GB、使用率93%→46%、空き16GB→209GB。RAWを30MB換算で約7,000枚の余裕。
• 料金の実績は月$9.00 → $12.60。100GBあたり月$1.80（＝$18/TB/月）。

仕掛けは完全に撤去した

増設で解決したので、一晩かけて作ったものは全部元に戻した。「使っていないだけ」で残すのが一番たちが悪い——あとでバックアップスクリプトを触ったときに、忘れた除外設定が事故になる。退避していた10枚の実体を元の場所に戻してB2へ再アップロードし、追い出し先のプレフィックスを削除。常駐マウントのサービスを停止・無効化・削除し、マウント用フォルダと/etc/fuse.confの追記も撤去。バックアップスクリプトの--exclude "cold/**"とコンテナ設定の:rslaveは、事前に取った.bakとの差分で元と一致することを確認してから.bakも消した。撤去後の検証は10枚のmd5一致・シンボリックリンク0件・API 10/10・B2側も10/10復元・レコード件数29,716件で不変。

残したのはメモだけ。実際に効いた相対パスとmd5の一覧を/root/notes/に置いてある。将来TB級になってオブジェクトストレージが本当に必要になったとき、この一晩をゼロからやり直さずに済むように。

単価で見ると、いつか判断が逆転する

増設が常に正解ではない。1TBあたりの単価では増設が一番高い（VPSのSSD増設 $18/TB ＞ 同社オブジェクトストレージ $11.96/TB ＞ B2 $6.95/TB）。200GBでは差額が月$2程度にしかならないから複雑さを避けるのが正解だった、という話にすぎない。分岐点は2つ決めてある。追い出したい古い写真が1TBを超えたらB2方式を再検討する（差額が年$132になり、ようやくマウント方式の複雑さを引き受ける価値が出る）。1TB規模ならプランごと乗り換えたほうが安い（現プラン＋800GB増設の月$23.40に対し、1TBのSSDが付いたプランは月$15前後。ただし数分の停止を伴うし、SSDからNVMeへの変更は再インストール必須なので絶対に選ばない）。

残っている課題も書いておく。写真の2本目のコピーは引き続きバックアップ先の1本だけで、以前使っていた自宅のPCに全量が残っているうちは3コピーだが、あれを片付けるときに決め直す必要がある。バックアップの暗号化も未着手——速度は問題にならないと測れたが、115GBを全部アップロードし直すコストが残っている。

この遠回りから取ったもの

一晩かけて作って、10枚で実証して、全部捨てた。月$3.60のボタンを先に押していれば丸ごと要らなかった作業だ。素直に書くと、「どう作るか」を考えるのが面白くて、「買えば済むか」を確かめる手順を飛ばしていた。

構成を変える検討を始めるときは、まず今契約しているサービスの管理画面に、その問題をそのまま解決するボタンが無いかを確認する。 自分は3つの案を丁寧に比較表にしておいて、「ディスクだけ足す」をその表に入れていなかった。選択肢の作り方を間違えると、どれだけ丁寧に比べても正解には当たらない。

捨てた作業から残ったものもある。マウントが切れてもImmichのレコードは壊れないこと、削除が30日間は取り返せること、rclone syncがリンクを見て送り先を消すこと、暗号化が速度の障害にならないこと、サムネイルの全件再生成が課金を踏むこと。これはどの方式を選んでも効く知識で、1TBを超えた日に取り出せる形でメモに残した。遠回りの元は取れていないが、ゼロでもない。

更新履歴 — 2026-10-05: 初版