前提

• 常時起動している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: 初版

調べたら、どちらも完全ではなく、どちらも検証されていなかった。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: 初版