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

故障や操作ミスなどによって大切なデータが失われることがあるため、日頃からバックアップを取っておくことは重要です。しかし、データのバックアップは単にファイルを別の場所にコピーするだけでは十分とは限りません。ソフトウェアエンジニアのアレクサンダル・フィリポフスキー氏が、バックアップの仕組みを整えるにつれて増えていく課題を、自身の体験を交えて説明しています。

Backups aren't simple
https://filipovski.net/2026/09/16/backups-arent-simple.html

フィリポフスキー氏は「人間には2種類いる。壊滅的なデータ喪失を経験した人と、これから経験する人だ」というシステム管理者の間で語り継がれる言葉を紹介しています。これは「データの喪失は思う以上に起きやすく、多くの人は十分に備えていない」ということを意味します。

フィリポフスキー氏自身も家族の写真を失いかけた経験があるそう。自宅のPCの空き容量を増やすために家族の写真を外付けHDDに集めていたところ、父親がそのHDDをテレビ用セットトップボックスのストレージとして使うためにフォーマットしてしまったとのこと。その結果、ファイルの索引が削除され、HDDは見かけ上空になってしまいました。

しかしフィリポフスキー氏は、写真のデータが消えかけたのは父親だけの責任ではなく、写真を1カ所に集めたままバックアップを取っていなかったこと、そしてセットトップボックスに「フォーマットするとデータが失われることを明確に伝える警告」が出なかったことが原因だと指摘しています。さらに、技術に詳しくない人がフォーマットの意味を知っていると期待すること自体にも疑問を示しました。

HDDの写真は幸いにも復元できたそうですが、フィリポフスキー氏は「この経験から得た教訓は、重要なデータを1カ所だけに置かないことでした」と語ります。HDDは故障したり盗まれたりすることもあるほか、使わずに保管していても記録を担う磁気の状態が変化することがあります。SSDでもデータを保持する電荷が失われることで、データが破損する可能性があります。そのため、まず必要なのは「別の場所にファイルのコピーを用意すること」です。

ただし、コピーがあれば全て解決するわけではありません。接続中のドライブはランサムウェアに暗号化される可能性があり、利用者が誤ったファイルを削除したり、全てをゼロで上書きするスクリプトを実行したりすることも考えられます。元のドライブの変更をそのまま反映する仕組みでは、誤操作の結果までコピーに反映されてしまいます。

そういうわけで重要なのはコピーしているかどうかだけではなく、「過去の状態に戻せる仕組み」です。フィリポフスキー氏は、同じデータを複数のドライブに書き込むRAID 1のようなミラーリングだけではこの目的を満たせず、ある時点の状態を保存する「スナップショット」が必要になると説いています。

スナップショットを保存する上で問題になるのが「どのくらいの頻度で保存するか」です。どの時点までのデータを復旧できるようにするかという目標を「RPO(目標復旧時点)」と呼びますが、フィリポフスキー氏は「重要な金融機関で30秒未満、小規模な企業では24時間以上など、必要なRPOの水準は異なる」と説明しています。例えば、これまで撮りためた家族の写真をバックアップする場合は「最大6日と23時間分のデータを失うことは許容する」といった判断も下せます。

しかし、保存の頻度を決めると今度は保存容量が問題になります。毎日スナップショットを作っても古いものを削除しなければ、スナップショットは1週間で7個、1年で365個にもなります。そのままではバックアップのデータだけですさまじい保存容量が必要になるので、古いスナップショットを順次削除する運用が必要です。

例えば「直近14日分だけを残し、新しいものを作るたびに最も古いものを削除する」という運用も考えられますが、この方法ではデータの破損に2週間以上気付かなかった場合、破損前のバックアップが残っていない可能性があります。一方、1年分のバックアップを全て残すのは容量の面で難しく、古い時期についてそこまで細かい記録が必要とも限りません。

そこでフィリポフスキー氏は、「最近のバックアップは細かく残し、古いものは間隔を広げて保存する」という方法を紹介しています。例えば、日次バックアップを14日分・週次バックアップを7週分・月次バックアップを12カ月分残すという運用が効果的。このようにスナップショットを日・週・月の3世代に分けて保存する方式を「GFS(Grandfather-Father-Son)」と呼びます。

さらに、保存する内容の重複も減らせます。バックアップされるファイルの多くは変更されず、ごく一部のファイルが頻繁に更新されます。そこで、変更されたファイルのみを保存しつつ、すでに保存済みのデータを参照すれば容量を節約できるというわけ。

その方法の1つが、同じファイルの実体を複数の場所から参照する「ハードリンク」です。各スナップショットが同じ実体を参照するため、古いスナップショットを削除しても別のスナップショットから参照されているデータは残ります。重複排除は保存容量の節約だけではなく、別のマシンにデータを転送する際の通信量も減らせるというメリットもあります。特にクラウドサービスを保存先にする場合は、データ転送の通信量が運用コストに直結します。

フィリポフスキー氏は、ここまでの仕組みはファイル転送ツールの「rsync」と、処理を定期実行する「cron」を組み合わせて構築できると紹介しています。このバックアップ方法は前回から変更のないファイルをハードリンクで共有する増分保存とGFS方式の世代管理を備えており、保存先のマシンを追加することも可能。さらにファイルのアクセス権や所有者といった付随情報も保持できます。

ところが、この仕組みを自宅のサーバー環境に適用すると別の問題が発生します。例えば10個のDockerコンテナを動かす場合、Dockerコンテナが管理者のrootを所有者とするファイルを作成する一方で、バックアップ処理を一般ユーザーの権限で実行しているとファイルを読み取れずバックアップに失敗することがあります。

また、データベースも単純なファイルコピーでは問題が生じる場合があります。データベースは処理を速くするため、データを一時的にメモリに保持し、まとめてディスクに書き込むことがあります。コピーのタイミングによっては整合性の取れない状態が保存され、復元に失敗する可能性があります。そこで、データベースの内容をバックアップ用に書き出す「ダンプ」を作成し、Dockerのデータ保存領域を読み取るための権限も確保する必要が出てきます。

保存する機器や場所にも注意が必要です。特定のHDD製品で故障が多発するような事態を考えると、異なる種類の記録媒体に保存することが対策になります。さらに、クラウドや家族の家など離れた場所にもコピーを置けば、電源の異常や洪水、火災によって全てを失う危険を減らせます。このように、「データのコピーを3つ用意し、2種類の媒体に保存し、そのうち1つを別の場所に置く」という考え方が「3-2-1バックアップ」です。

不測の事態で重要なデータを失ってしまうのを防ぐ「3-2-1バックアップルール」とは？ - GIGAZINE

しかし、離れた保存先としてAmazon S3のようなオブジェクトストレージを選ぶと、ここまでの仕組みをそのまま使うことはできません。ファイルをそのままアップロードするだけでは、アクセス権や所有者などの情報は引き継がれず、小さなファイルを大量に送るとアップロードのリクエストにかかる費用もかさみます。

そこで、複数のファイルをtar形式のアーカイブにまとめれば、付随情報を保持しながらアップロードの回数を減らせます。ただし、全てを1つの巨大なアーカイブにすると、ハードリンクを利用して変更分だけを保存する仕組みの利点が失われます。フィリポフスキー氏は50MB程度の塊に分割する案も示していますが、安全性を確認できる形で実装するのは簡単なことではありません。

フィリポフスキー氏は「この段階まで来ると、自作を続ける負担は見合わない」と述べています。代わりに挙げているのが、「Borg backup」や「Restic」といったバックアップツールです。これらのツールは暗号化やファイルを分割した塊ごとの重複排除、データの破損を検出するためのチェックサムなどにも対応しています。フィリポフスキー氏は「こうした複雑な処理を利用者が扱いやすい形にするまでに、オープンソースの開発者たちによる多くの試行錯誤があった」としています。

そして、バックアップを作成しても実際に復元できるかを試さなければ意味がありません。そのため、バックアップの仕組みを整えるだけでなく、半年ごとに復元を実行するなどといった復元の確認も必要です。

バックアップはデータを誤って削除した場合や破損した場合に備えて過去の状態を残し、保存容量や費用を抑えながら、データの整合性や保管先の安全性も確保しなければなりません。さらに、実際に復元できるかを確かめる作業まで含めると、単純なコピーでは済まない多くの課題が生じます。フィリポフスキー氏は「バックアップが難しいのはファイルのコピーを作るだけでなく、必要なときに正しく復元できる状態を保たなければならないからだ」と述べました。