バックアップはなぜ難しいのか｜ファイルをコピーするだけでは済まない理由

情報漏洩のニュースが途切れない。身代金要求型ウイルスによる業務停止も同じだ。そして対策として必ず挙がるのが「バックアップを取りましょう」である。だが、この一言ほど現場を甘く見た言葉もない。

ソフトウェアエンジニアのアレクサンダル・フィリポフスキー氏が2026年9月16日に公開した記事「Backups aren't simple」は、その「簡単そうに見える作業」がどこでどう破綻していくのかを、一本道で描いている。今回はこの論考を軸に、バックアップという厄介な代物を考えてみよう。

データを失うのは「いつか」ではなく「必ず」

フィリポフスキー氏は、ある言い回しを引用している。世の中には致命的なデータ消失を経験した人間と、これから経験する人間の二種類しかいない、というものだ。出典を探しても管理者の数だけ言い換えがある。誰もが同じ結論に辿り着いている、ということだろう。

氏自身の体験も生々しい。家族写真をパソコンから外付けハードディスクに移し、容量を空けた。ある日、父親がそのドライブをテレビの録画用に挿したところ初期化を求められ、そのまま実行してしまう。索引情報は消え、ドライブは空になった。

ここで父親を責めるのは筋が違う、と氏は書く。問題は連鎖している。写真を一か所にしか置かなかったこと。家電側に、初期化でデータが消えるという警告が出なかったこと。そもそも技術者でない人間がその知識を持っている前提自体がおかしい。

ドライブは壊れる。盗まれる。ハードディスクの磁性体は理由もなく向きを変え、SSDのNAND素子は電荷を漏らして中身を静かに腐らせていく。だから別の場所に複製を置く。ここまでは誰でも辿り着く。

コピーは、バックアップではない

問題は、その複製が「つながったまま」である場合だ。暗号化型の攻撃は、接続されたドライブごと巻き込む。人間の側も、消すべきでないファイルを消し、最悪の場合は全体をゼロで上書きする処理を走らせる。

つまりバックアップは、元のディスクの鏡であってはならない。過去に戻れる必要がある。この時点で RAID 1 のようなミラーリング（二重書き）は候補から外れる。必要なのは、ある瞬間を切り取って保存する仕組み、すなわちスナップショット（時点コピー）である。

どこまで巻き戻せればよいのか

では、どのくらいの頻度で切り取るのか。家族写真なら週に一度でもよい。六日と二十三時間分を失っても生きていける、という判断だ。この「どこまでのデータ消失を許容するか」が、業界でいう RPO（目標復旧時点）である。

現実の幅は広い。データ消失が許されない金融機関では30秒を切る水準が求められ、小規模な企業では24時間以上ということもある。そもそも災害復旧の計画自体が無い組織も珍しくない。

世代管理という、終わらない宿題

スナップショットを取り続ければ、保存容量は増え続ける。RPOが24時間なら、週に7世代、月に30世代、年に365世代。放置すれば破綻するので、世代を回していく（ローテーション）必要がある。

素朴に「14日分を保持し、新しいものを足すたびに最古を消す」とする。単純だが、二週間より前に壊れていたら気づけない。かといって一年分を等間隔で持つのも無駄だ。364日目に、2日目と3日目の差が何の意味を持つのか。

結論として、粒度を変えるしかない。直近は細かく、過去は粗く。日次を14日分、週次を7週分、月次を12か月分。こうして出来上がるのが「祖父・父・子（GFS）方式でローテーションされる、スナップショット型バックアップ」という長い名前の代物だ。そしてこの形容詞の列は、この先もまだ伸びていく。

重複排除 — 動画圧縮と同じ発想

次に気づくのは、スナップショット同士がよく似ているという事実だ。動画圧縮では、静止した背景の前で人物が喋るだけの場面を、フレーム間の差分として小さく表現できる。ファイルも同じで、変更の分布は極端に偏る。大半は一度も変わらず、ごく一部だけが頻繁に変わる。

ならば同じ中身を何度も保存する理由はない。既存ファイルへの参照（ハードリンク）を張れば、実体は一つで済む。削除されるのはディレクトリ上の登録情報だけなので、世代の入れ替えにも耐える。rsnapshot が採用している方式で、直前の世代との差分だけを持つ「増分バックアップ」にあたる。

効果は容量だけではない。バックアップは別の機器へ転送する以上、通信量も削減される。保存先がクラウドなら、これはそのまま請求金額に効いてくる。

ここで、現場の前提が崩れる

氏の記事が面白いのは、ここから躓き始めるところだ。自宅の検証環境でコンテナを10個動かし、同じ仕組みでバックアップすると失敗する。Docker のコンテナは管理者所有のファイルを作りたがり、一般利用者の権限で定期実行を仕掛けていると読み取れない。

さらに厄介なのがデータベースだ。性能のために内容をメモリに溜め、まとめてディスクへ書き出すものがある。つまりファイルをそのまま写し取っても、復元時に壊れている可能性がある。だからダンプ（内容の書き出し）を併用し、保存領域への権限も与える。これでようやく動く。

3-2-1ルールと、クラウドという壁

特定の型番のハードディスクが集中的に壊れた事例を知れば、保存媒体の種類を分けたくなる。電源異常や水害、火災まで考えれば、一つは離れた場所に置きたい。複製を3つ、媒体を2種類、うち1つは遠隔地。これが 3-2-1 ルールである。

では遠隔地をクラウドのオブジェクトストレージにしよう、と考えると、また壁に当たる。アップロードすると権限や所有者といった付帯情報が失われる。小さなファイルを大量に置くと課金が跳ね上がる。ならばまとめて書庫（アーカイブ）にするしかないが、全部を一つに固めれば増分の仕組みが無意味になる。50MB程度に分割するのが筋だが、それを検証可能な形で安全にやるのは、まったく容易ではない。

自作を捨てる、という正解

フィリポフスキー氏は、ここで降参すると書いている。一晩でできそうに見えた作業が、どう考えても割に合わない。素直に Borg や Restic といった実績のあるツールを使えばよい、と。暗号化も、塊単位の重複排除も、検査値による検証も、すでに中に入っている。

そのうえで氏は、この複雑さを引き受けて作り、保守し続けてきた開発者たちへの感謝を書き添えている。抽象化されて見えなくなったものの裏には、膨大な試行錯誤がある。実に誠実な書き方だと思う。

そして最後に、最も重要な一行が来る。復元を実際に試していないなら、ここまでの全部に価値はない。半年に一度は戻してみること。それでようやく、暗号化され、塊単位で重複排除され、世代管理され、時点復元が可能で、遠隔地にも置かれたバックアップ、と名乗れる。

ついでに、定期実行を午前2時台と3時台に置くな、という注意もある。夏時間の切り替えで、その一時間は消えたり二度来たりするからだ。日本では無縁に見えるが、海外拠点の時刻設定で踏む人は今でもいる。

日本の現実 — 復旧に1か月、費用1000万円超

ここまでは技術の話だ。だが数字を見ると背筋が寒くなる。警察庁が2026年9月10日に公表した「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」によれば、国内の被害報告は123件。統計開始の2020年下半期以降、半期として最多である。

実例もある。2025年10月に被害を受けたアスクルは、全物流センターでの出荷再開が2026年2月。主要な機能が従来水準に戻るまで、およそ4か月を要した。流出が確認された情報は約74万件に及ぶ。相手と接触せず、身代金の支払いも交渉も行わなかったと明言している点は、評価されてよい姿勢だと思う。

IT小僧の結論

フィリポフスキー氏の記事が優れているのは、「正解」を売りつけないところだ。素朴な発想から出発し、一歩進むたびに新しい問題が顔を出す。現実には、確かにそれだけの細部がある。

障害の切り分けという発想で言えば、話は単純だ。本番と同じ権限で、同じ回線につながり、同じ時刻に動くバックアップは、本番と一緒に死ぬ。切り離されているからこそ意味がある。権限は最小限に、経路は分離し、保存先は手の届かない場所に。金融系のシステム設計では当たり前の考え方で、別に新しくもない。

今日できることを三つだけ挙げておく。一つ、保存先が常時つながったままになっていないか確認する。二つ、世代が何日分残っているかを数える。三つ、適当なファイルを一つ、実際に戻してみる。三つ目をやったことがない組織は、驚くほど多い。

バックアップは保険ではない。保険は請求すれば払われるが、バックアップは試していなければ払われない。それだけの違いが、1か月の業務停止と1000万円を分ける。