前提

• 常時起動しているLinux環境と、そこからrclone(いろいろなクラウドストレージへファイルを同期するコマンド)で日次バックアップを取っている状態
• バックアップ先はBackblaze B2(安価なオブジェクトストレージ。1GBあたり月$0.005前後)
• 構築の土台は自分の「サーバー」を持つとはどういうことか

何が問題だったか

心配していたのはランサムウェア(侵入したうえでファイルを暗号化し、戻す鍵と引き換えに金銭を要求する攻撃)のような、サーバーを乗っ取られるケース。

「B2側に30日間のバージョン保持(上書き・削除された古い版を30日間取っておく設定)があるから、仮に荒らされても戻せる」と考えていた。これが成立していなかった。

サーバーに置いていたB2のアプリケーションキー(APIから操作するための鍵。権限を選んで発行できる)の権限を一覧してみると、18個の権限が付いていた。問題はこの3つ。

• deleteFiles — ファイルの版そのものを完全削除できる
• writeBucketLifecycleRules — ライフサイクルルール(古い版をいつ消すかの設定)を書き換えられる。「0日で消す」に変えれば30日の保持は即座に無意味になる
• writeBucketReplications — 複製ルールを止められる

つまり鍵を1本盗られたら、バックアップ本体も、それを守るはずの設定も、まとめて壊せる。実際に同期スクリプトが使っていたのはlistBuckets, listFiles, readFiles, writeFiles, deleteFilesの5つだけで、残りは余分だった。

もう1つ、根本的な制約を自分に課した。「予備のハードウェアをもう1台持つ」案は採らない。将来は拠点を移して身軽に暮らしたいと思っているので、機械を持ち続ける前提の設計にはしたくなかった。ハードウェア不要・手作業ゼロで回る形に限定して考えた結果、3層構成になった。

層0: 鍵の権限を必要最小限にする

まずサーバー上の鍵を、実際に使う5権限ちょうどの新しい鍵に差し替えた。

ここで分かった制約: B2のWeb管理画面の鍵発行UIでは権限を細かく選べない。「読み書き」のような粗い単位しかないので、b2コマンド(Backblaze公式のCLI = コマンドライン操作ツール)が必須になる。全権限を持つマスター鍵を扱う作業なので、サーバー上ではなく手元のPCから実行した。

b2 account authorize
b2 key create --bucket <バケット名> <鍵の名前> \
  listBuckets,listFiles,readFiles,writeFiles,deleteFiles
b2 key list --long     # 権限が5つちょうどか確認
b2 key delete <旧鍵のID>

• b2 account authorizeとb2 key createの出力は、どこにも貼り付けない。鍵の本体(パスワード相当の文字列)が含まれる。自分はこの作業中にターミナルの出力をそのままAIチャットに貼ってしまい、鍵が会話ログに残った。同日中にマスター鍵の再発行と露出した鍵の削除で無効化したので実害はなかったが、確認はb2 key list --longで行うのが正しい(鍵のIDと権限しか出さず、本体は出ない)。
• 鍵の状態確認はWeb管理画面を信じない。削除済みの鍵が残って見えたり、新規作成した鍵が出てこなかったりした。b2 key listを正とする。

層0は次の層1とセット。層0をやらずに複製ルールだけ作っても、writeBucketReplicationsを持った鍵でルールごと止められてしまう。

層1: 削除が伝播しない複製先を作る

B2にはCloud Replicationという、バケット(ストレージ上のフォルダのような入れ物)の内容を別のバケットへ自動複製する機能がある。決定的な仕様はこれ。

削除と hideマーカー(B2が「削除された」印として置く目印)は複製されない。

つまり複製先は、構造的にappend-only(追加だけができて削除が伝わらない)なミラーになる。元のバケットでファイルが消されても、複製先には残り続ける。これがランサムウェア対策の本体になる。

同一アカウント内の別バケットへの複製で十分と判断した。理由は、サーバー上の鍵は元のバケットに限定されているので、別バケットには構造的に届かないから。別アカウントが必須になるのは「別リージョンへ複製する場合」だけで、同一アカウント・同一リージョンの別バケットへの複製は普通にできる。別アカウント構成と差が出るのは「B2のログイン自体を乗っ取られた場合」と「リージョン障害」の2つだけで、前者は後述の2段階認証のほうが本質的な対策になる。

複製元を読む鍵・複製先に書く鍵はB2が自動で2本発行し、どちらもB2の内部にしか存在しない(サーバー上に置かれない)。侵害経路にならないのがこの構成の強み。

複製先のライフサイクル設定でUIに落とし穴が2つあった。

• 🔴 「Keep only the last version」(最新の版だけ残す)を選んではいけない。上書き攻撃を受けた瞬間に正常な旧版が消え、複製先を用意した意味がなくなる。必ずUse custom lifecycle rulesを選ぶ。
• 🔴 Days Till Hideは必ず空にする。ここに数字を入れると、現役のバックアップ本体が自動削除される。埋めるのは「古い版を何日後に消すか」の1箇所だけ。

自分は古い版を180日で削除に設定した。毎晩上書きされるデータベースのダンプ(写真サーバー188MB + ファイルサーバー18MB + 認証サーバー13MB ≒ 日220MB)が積み上がって年80GB増える計算だったため。180日なら約40GBで頭打ちになる。保護が弱まるわけではない——削除は複製されないので消されたファイルには無関係で、上書き攻撃は次の層2が1週間以内に検知する。

複製元141.5GB・118,503ファイルに対して、複製先は149.0GB・118,976ファイルで完了。複製先のほうが大きいのは設計どおり(元で消えた・上書きされたファイルが残り続けるので膨らむ)。初回コピーは数日かかった。

• 初回コピーの進捗はAPIでは測れない。B2が複製の状態フラグを付けるのはルール作成後に新規アップロードされたファイルだけで、既存ファイルの後追いコピー分は全件「未設定」のまま。進捗はWeb管理画面の複製先バケットのファイル数で見るしかない。
• 初回コピー完了を待つ必要はない(層2の判定は「減った/増えていない」なのでコピー中に誤報は出ない)。ただしライフサイクル設定は初回コピー完了まで触らない——コピー中の変更は直後のファイルが消える危険があると公式ドキュメントに明記されている。
• コストは複製分で月$0.70。複製の転送料は無料。

層2: サーバーの外に見張りを置く

複製が本当に続いているかを誰も見ていなければ、仕組みは静かに壊れる。そこでデッドマンスイッチ(定期的な生存信号が途絶えたら警報を出す仕掛け)を用意した。

肝はサーバーの外で動かすこと。サーバー監視には別途Uptime Kumaを使っているが、これはサーバー自身の上で動いているので、サーバーごと死んだら自分の死を通報できない。

実装はGitHub上の非公開リポジトリ1つ + GitHub Actions(GitHubが提供する、決めた時刻やイベントでスクリプトを自動実行する仕組み)。週1回、複製先バケットを走査して、次のどれかに当たったらTelegramへ通報する。

1. ファイル件数が前回より減った
2. 合計サイズが前回比1%を超えて減った
3. 21日間まったく増えていない
4. B2へ接続・認証できない

観測値はリポジトリ内のJSONファイルにコミットして、次回の比較基準にする。外部ライブラリは使わず標準ライブラリだけでB2のAPIを直接叩く作りにした(依存が増えると、それ自体が壊れる原因になる)。見張り用の鍵は複製先バケット限定・読み取り専用なので、こちらはWeb画面の発行UIで作れる。

• 件数の減少は「複製先を直接触られた」ことのシグナルとして意味が強い(削除は複製されないので、正常運用では減らない)。
• 上書き破壊の検知は不完全だと正確に理解しておく。同サイズ・より大きいサイズで上書きされた場合は検知できない。ただしその場合も版管理で旧版が残るので復元は可能で、守りは版管理側が担っている。
• GitHub Actionsの定時実行は大幅に遅れる。0 1 * * 1(毎週月曜01:00 UTC)と書いたジョブが実際に走ったのは06:16 UTCで、5時間16分遅れだった。:00は最も混雑する分なので、奇数分(17 1 * * 1など)にずらすと改善する。週次監視なら遅延自体は無害だが、時刻を当てにした説明を書かないこと。
• 通報が空振りする状態で放置してはいけない。鍵をGitHubのSecrets(リポジトリに暗号化して保存する秘密情報)に登録する前に初回の定時実行が走り、認証情報が無くて失敗した。設計どおりの挙動だが、これを放置すると毎週失敗通知が来て、デッドマンスイッチの警報を無視する習慣がつく。それが一番の実害。

踏んだ落とし穴: 「鍵の差し替え」が設定ファイルを作り直していた

層0の鍵差し替えには、以前自分で書いたrotate-b2-key.shというスクリプトを使った。これがrcloneの設定ファイル(rclone.conf)を丸ごと作り直す作りになっていた。

同じ日の朝に、送信前に自前で暗号化するための設定ブロックをこのファイルに追加していた。スクリプトはそのブロックを知らないので、鍵の差し替え自体は成功したのに直後のバックアップが「設定ブロックが見つからない」で全滅した。

• 教訓: 構成に新しい設定ブロックを足したら、そのファイルを書き換える既存スクリプトを洗い出す。「鍵の差し替え」という名前から、設定ファイル全体を作り直しているとは読み取れなかった。
• スクリプトは、丸ごと上書きをやめて該当2行だけを置換する形に直した。加えて書き込む前に「設定ブロックが減っていないか」「新しい鍵IDが入ったか」を検査し、1つでも失敗したら一切書かずに中止するようにした。
• 🔴 もう1つの地雷: 設定ファイルはroot用と一般ユーザー用の2箇所にあり、復旧を片方だけやって放置していた。バックアップはrootで動くので「成功」と出続け、一般ユーザーで実行したときだけ静かに失敗する状態になっていた。
• 教訓: 「両方必要」と書いた手順は、実施後に必ず両方を実測で確認する。grep "^\[" <設定ファイル1> <設定ファイル2>のようにセクション名だけ出すコマンドなら値が漏れないので、安心して結果を見られる。
• おまけの罠として、ssh サーバー 'bash -s' <<'EOF'形式のヒアドキュメント(複数行のスクリプトを流し込む書き方)はsshの標準入力と競合して出力が二重化し、成功したのか失敗したのか読めなくなった。サーバー操作は1行のssh サーバー '...'に分解して1つずつ流すのが確実だった。

2段階認証が1段階だった

作業中にもっと基本的な穴が見つかった。「2段階認証は済んでいる(ログインのたびにメールでコードが来る)」と認識していたが、これはBackblazeが既定で有効にしているメールMFA(多要素認証)だった。

コードの送り先も、パスワードリセットの送り先も、同じメールアドレス。つまりメールボックス1つ取られると2要素が1要素に潰れる。同一アカウント構成を選んだ結果、このアカウントが全データの唯一のオフサイトコピーを持っているので、ここが設計上の最大の残留リスクだった。

TOTP(認証アプリが30秒ごとに生成する6桁コード方式)に切り替えて解消した。

• 認証アプリはEnte Auth のオフラインモード(アカウント登録なしで使える)を選んだ。Google Authenticatorは、自分がGoogleアカウントを削除する方針で同期が使えないこと、Google Playが載らない端末への移行を検討していることの2点で不適だった。アプリ登録が必要なものだと、復旧手段がまた別の会社のアカウントに依存して、断ち切った鎖を作り直すことになる。
• バックアップコードは必ず生成してパスワードマネージャーに保存する。ただしTOTPそのものは同じ金庫に入れない(同じ場所に入れたら1要素に戻る)。TOTPはスマートフォンのアプリに、バックアップコードはVaultwardenに置いた。

残る「鶏と卵」

この構成にも、原理的に閉じない循環が残っている。

• B2に入るには → TOTP(スマートフォン)
• スマートフォンを失くしたら → バックアップコード(Vaultwarden)
• VaultwardenはサーバーVPS上 → サーバーを失ったらB2から復元が必要 → B2に入る必要がある

スマートフォンとサーバーを同時に失うと詰む。対処は「バックアップコードを紙でもう1箇所持つ」しかない。これはパスワードの移行の記事で書いた、バックアップの取り出し鍵自体をどこに置くかという問題とまったく同じ構造になっている。自前で持つほど、最後の1本をどこに置くかという問題に必ず行き着く。

結果と、やらなかったこと

鍵の権限削減・append-onlyな複製先・サーバー外の見張りの3層が稼働状態になった。追加費用は複製分の月$0.70だけで、ハードウェアは1台も増えていない。

やらなかったことも書いておく。Backblazeというプロバイダ1社に依存しているのは未対策のまま。アカウントの凍結や会社都合に備えるなら、別会社のストレージへもう1本(追記専用の設定で月€4前後)が答えになるが、今回は見送った。手を広げる前に、今ある3層が本当に回り続けるかを数ヶ月見ておきたかった。

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

結論を先に書くと、自分は古い写真を安いオブジェクトストレージへ追い出す仕掛けを一晩かけて作り、動くところまで確認してから、全部捨てた。業者が月$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: 初版

調べたら、どちらも完全ではなく、どちらも検証されていなかった。GitHub側を廃止して1系統に絞り、代わりに「本当に戻せるか」を確かめる作業を足した。

前提

• 常時起動しているLinuxサーバー1台に、パスワード管理・写真・ファイル置き場・認証を同居させた状態。土台は自分の「サーバー」を持つとはどういうことか
• 道具はrclone(いろいろなクラウドストレージへファイルを同期するコマンド)。送り先はBackblaze B2(安価なオブジェクトストレージ。1GBあたり月$0.006、最初の10GBは無料)
• もう1系統は、作業用ディレクトリ一式を毎日git commitして非公開リポジトリへpushする自作の仕組み

2系統が実際に守っていたもの

同じものを2箇所に置いているつもりだったが、並べたら役割が違っていた。GitHub側はテキスト類(会話ログ・設定・メモ)と添付ファイルで、強みは履歴——「このファイルは3週間前どう書かれていたか」を追える。B2側はデータベースのダンプ・写真ライブラリ・ファイル置き場の実データ・パスワードの保管庫で、強みは容量。つまり二重化ではなく分担で、片方だけでは静かに欠けが出る状態だった。

実際に測ったら、添付ファイルがB2に638件、GitHubに460件、重複ゼロ。時期で真っ二つに割れていた。git cloneだけで戻せば638件が消え、B2だけで戻せば460件が消える。

「2倍安全」ではなく「壊れたら困るものが2つ」

分担になっていた理由は単純で、2つあると、どちらも真剣に見なくなる。

B2側の同期スクリプトのログを読んだら、34回の起動のうち完走は5回だけだった。最後の処理でsudoがパスワードを求めて止まり、set -e(途中で失敗したらそこで中断する設定)で全体が終わっていた。データ本体の各工程は成功していたので実害はなかったが、問題はそこではない。「完走しました」のマーカーが1ヶ月出ていないのに、気づいていなかった。

これが冗長なバックアップ経路の本当のコストだと思う。ディスク代でもなく手間でもなく、どちらも検証されないこと。「もう片方があるから」と思っている限り、片方が壊れても痛みが出ないので、気づく機会そのものが無くなる。

GitHubがこの用途に向いていなかった理由

1. サイズと中身。Gitはテキストには強いが、画像のようなバイナリは版が増えるたびに丸ごと溜まる。.git(履歴の実体)が346MBあり、作業用ディレクトリ751MBの半分近くを占めていた(1年後には847MB)
2. 履歴は消せない。消さないことが価値の仕組みなので、間違って入れたものが残る。実際、秘密情報を含むディレクトリ(APIトークン類やサーバーの秘密鍵)が気づかないうちに毎日pushされ続けていた。「除外設定に入れてある」と自分のメモに書いてあったが、入っていなかった
3. 他人のアカウント方針の上に乗っている。容量制限も規約も将来どう変わるかは自分では決められない
4. そもそも用途が違った。置いていたのは日々の記録で、ソースコードではない。全ての版を永久に取っておく必要がない

一方で**「履歴が追える」価値は本物だったので代わりを用意した。B2のバージョン保持**(上書き・削除された古い版を一定期間取っておく設定)で、自分のバケット(ストレージ上のフォルダのような入れ物)は旧バージョンを30日保持している。実際にデータベースのダンプは26世代遡れた。30日の「取り消し」が成立していればGitの履歴機能の大部分は代替できる。なお公開しているもの(ブログ・ポートフォリオ)はGitHubのままにしている。廃止したのは「バックアップ置き場として使うこと」だけ。

一本化の本体は棚卸しだった

ここが一番再利用できる部分だと思う。片方を止める作業の本体は、「GitHub側にしか無いものが、B2側に全部入っているか」を1件ずつ確認すること。やらずに止めると、欠けたことに気づくのは復元が必要になった日になる。

1. 止める側の中身を、実物から列挙する

設計書ではなく実際のファイル一覧から出す。自分はここで一度間違えた。手元のメモの箇条書きだけを読んで「テキスト類がB2に入っていない」と誤判断したが、スクリプト本文を開いたら既に実装済みだった。メモで判断せず、スクリプト本文とファイル一覧を実見する。

2. 残す側の対象リストと突き合わせる

ここで本物の穴が見つかった。環境変数をまとめたファイル(.env。各種サービスのトークンが入っている)が、GitHubにもB2にも無かった。2系統あったのに、どちらにも無いものが存在した。

3. Gitの履歴そのものを、ファイルとして退避する

履歴は普通のファイル同期では運べない。git bundle(リポジトリ全体を1ファイルに固める機能)を使った。

git bundle create /tmp/history-20260928.bundle --all
git bundle verify /tmp/history-20260928.bundle
rclone copy /tmp/history-20260928.bundle <暗号化remote>:<保存先>/

• 🔴 rootでgitを叩くとdetected dubious ownershipで弾かれる。ディレクトリの所有者ユーザーで実行する
• 出来上がりは831MB。往復まで確認した——取り出してmd5(内容の指紋)が一致し、git clone <bundleファイル> <ディレクトリ>で162コミットが復元でき、履歴の中にしか無いPDFを元のサイズどおり取り出せた
• 🔴 一度きりのスナップショット。以後履歴が伸びても自動では更新されない

4. 止める前に「止める側にしか無いコミット」がゼロだと確認する

git rev-list --count <リモート>/main --not --allが0であること。

5. 浮いた分を別の軸に回す

テキスト類だけを対象にした軽い同期を1日4回動かすようにした(全体の同期は従来どおり夜1回)。これでRPO(障害時に失われる最大の時間幅)が最大24時間から最大6時間に縮んだ。重い写真ライブラリに触らないので約10秒で完走する。加えて30日を超える長期の記録として、テキスト類のみの日付付きtar.gzスナップショットを週1回置いた。実測16MBなので年0.8GB、費用はほぼゼロ。

• 🔴 バックアップを取る道具自体がバックアップ対象外だった。同期スクリプトを置いたディレクトリは、どちらの系統にも入っていなかった。サーバーが全損したらデータは戻るが戻し方を書いた道具が無い
• 🔴 データベースのダンプを取る行に管理者パスワードが直書きされていた。権限600の.envに切り出して読み込む形にし、読めなければexit 1、変数が空なら: "${VAR:?未設定}"で止める(黙って空のパスワードで走らせないため)。渡し方は-p'…'のような引数ではなく環境変数経由にする——引数はpsで他のユーザーから見える。なお平文の秘密はスクリプト本文を直しても消えない。過去の退避ファイルと稼働中のコンテナの環境変数に同じ値が残っており、本当に消すにはパスワードの変更が必要だった

何を金庫に入れるか

バックアップを復元するための鍵が、バックアップの中にしか無いと、永久に開かない。 いわゆるブートストラップ問題(起動するために起動済みの何かが必要になる循環)。自分の場合、B2から取り出すための接続情報(rcloneの設定ファイル)はサーバーの中だけにあった。毎日バックアップは成功していたが、サーバーが丸ごと壊れた瞬間に、無事なデータを開ける人が誰もいなくなる。

再発行できる鍵は金庫に入れない。再発行できない鍵だけ入れる。

• 入れる(再発行不能): 暗号化パスワード(失うとバックアップが永久に読めない石になる)、ストレージ事業者のアカウントの2段階認証バックアップコード、復元用の接続情報
• 入れない(再発行可能): 各種APIトークン、ストレージのアプリケーションキー。上位のアカウントにログインできれば1分で作り直せる
• 置くべきは鍵そのものではなく、上位の認証(アカウントのログイン情報と2段階認証)。それがあれば下位の鍵は何度でも生やせる
• 🔴 何でも放り込むと、金庫自体が肥大した単一障害点になる

置き場所はパスワードマネージャー(1PasswordからVaultwardenに移したもの)にした。スマートフォンのアプリは一度ログインすればオフラインのキャッシュが残るので、サーバーが全損してもそこから取り出せる。ただし金庫自身がサーバー上で動いているので、スマートフォンとサーバーを同時に失うと詰む。対処は「紙でもう1部持つ」しかない。

暗号化と、やらなかったこと

実査したら事業者側の暗号化(SSE)すら無効になっていて、写真は生のJPEGのままディスクに置かれていた。「バケットは非公開だから最低限守られている」という感覚は間違いだった。2種類あることを区別しておく。

• 事業者側の暗号化: 倉庫が金庫に入れてくれるが鍵は倉庫が持つ。退役ディスクの流出には効くが事業者自身には無力で、手間はゼロ。🔴 有効にしても遡らない
• 送る前に自分で暗号化: 自分で鍵をかけた箱を渡す。事業者にもアカウント乗っ取りにも強いが、鍵を失えば永久に読めないし、既存分は全量を再アップロードになる

やったのは前者を有効化したうえで、テキスト類・秘密情報・データベースのダンプだけを後者にすること。rcloneにはcryptという、送信前に暗号化して保存名も不可読にする仕組みがある。初回は6,710オブジェクト・69MBで5分43秒、以後は差分で数十秒だった。

やらなかったこと。

• 写真ライブラリ131GBは自分で暗号化していない。全量の再アップロードになるのと、暗号化する動機(「事業者に読まれたくない」のか「凍結で消えるのが嫌」なのか)を整理できていなかったため。後者ならもう達成済みで、前者ならまだ未達。整理できていないまま重い工事をしない
• 🔴 パスワードの保管庫も、意図的に暗号化していない。中身はそれ自体がゼロ知識暗号化(サービス側も読めない方式)済みで平文ではなく、何より暗号化パスワードの保管場所がその金庫なので、暗号化すると循環依存になる

誰も戻したことのないバックアップは、バックアップではない

1. 生のファイルから実際に復元して突き合わせる。 124ファイルが完全一致した。暗号化remote経由でちゃんと復号できることも同時に確かめられる。

rclone copy <暗号化remote>:<対象パス> /tmp/restore-test/
diff -rq /tmp/restore-test/ /home/<user>/<元のディレクトリ>

2. 週次スナップショットを取り出してtar xzfで展開する。 6,644ファイル・74MBが正常に展開でき、自動処理の定義ファイル16本まで含まれていた。

3. 全ファイルを照合する。 差分19件。中身を見たらすべて同期が走った時刻より後に生成されたファイルで、取りこぼしはゼロだった。

rclone check --one-way <ローカル> <暗号化remote>:<対象パス>

--one-wayはリモートにしかない古い版を差分に数えないので、検証にはこちらを使う。

併せて事業者からの通知メールの読み方を決めた。「マスターキーが生成されました」のような通知は、自分がコンソールを触っていた日なら本人操作、触っていない日なら本物の警戒シグナル。先に線引きしないと、通知を全部無視する習慣がつく。

残った1系統の弱いところ

• 事業者1社への依存は未対策。アカウントの凍結や会社都合には何の備えもない。別会社のストレージへ追記専用でもう1本(月€4前後)が答えだが、見送った
• 削除の伝播と容量の兼ね合いが未整理。送信側の鍵から削除権限を外すとrclone syncが使えずcopyしかできなくなり、ローカルで消したものが残り続けて容量が増える。守りと費用がここで正面衝突する
• 一番大きい穴は、サーバーを乗っ取られた場合。1系統しかないので、送信に使っている鍵を盗られたらバックアップ本体を消される。これは別テーマとして切り出し、鍵の権限削減・削除が伝播しない複製先・サーバーの外で動く見張りの3層で作り直した。そちらはバックアップを「消されても戻せる」形にするに書いた

費用は全バックアップ合計125GBで月約$0.69。一本化で減ったのは費用ではなく、気にかけておく仕組みの数だった。

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