バックアップは単純ではない

バックアップは単純ではない

Aleksandar Filipovski, 2026-09-16

こちらも参照: John Salvatier の優れたブログ、現実は驚くほど詳細に満ちている

---

どこかで読んだコメントが心に残り、それは次のようなものでした。

「人は二種類に分けられる。壊滅的なデータ損失を経験したことがある人と、これから経験する人だ。」

この記事のために出典を探してみたところ、どのシステム管理者もこの引用を自分なりに言い換えていますが、その要点はどこでも同じです。データ損失は、私たちが望むよりも頻繁に起こるものであり、ほとんどの人はそれが（ほとんどの場合、最悪のタイミングで）発生したときに、ひどく準備ができていません。

私もかつて同様の経験をしたことを確認できます。子供の頃、家族の写真をすべて家庭のラップトップやPCから外付けハードドライブに移動させ、スペースを空けようとしたことがありました。これはうまくいっていましたが、ある日、父がテレビのセットトップボックス（これらの古いものの一つ）のストレージとしてそのドライブを使いたいと思ったとき、ドライブのフォーマットを求められました。彼はそのまま進み、ディスクは再フォーマットされました。ファイルのインデックスが削除され、私たちは名目上空のドライブだけが残されました。

彼を責めるのは簡単ですが、このような間違いにつながる一連のエラーを理解するには、テクノロジー分野でのキャリアを始める必要があります。まず、私たちはすべての写真を一箇所にまとめ、バックアップを取ることを怠っていました。第二に、ほとんどの一般消費者向けソフトウェアには、ディスクをフォーマットするとデータが失われるという（セットトップボックスにはなかった、ひどいUIの）注意書きが大きく表示されています。それに、非技術的な人がこれを知る必要があると期待すべきでしょうか？

幸いなことに、私たちは写真を復元することができ、それはデータを扱う上での安価な教訓となりました。重要なものを一つの場所にだけ保管してはいけません。数百万ものことが起こり得ます。ドライブが故障したり、盗まれたり、コールドストレージでビットが劣化したり（ハードドライブには磁性粒子があり、不可解に移動することがあります。SSDはNANDトランジスタでできており、電気を漏らし、時間の経過とともにデータを破損させます）。

したがって、私たちの最初の原則は、バックアップ、つまりファイルのコピーをどこか別の場所に持つことです。ここまでは順調です。

これは、接続されたドライブが何をする可能性があるかという頭痛の種をカバーしていません。ランサムウェアがファイルを暗号化する可能性があり、間違ったファイルを削除するような正直な間違いから、すべてをゼロで上書きするスクリプトを実行するような壊滅的な間違いまで、何でも起こり得ます。

したがって、バックアップは最初のドライブのミラーであってはなりません。なぜなら、私たちがミスをした場合に過去に戻れるようにしたいからです。重要なのは、これはRAID 1のようなものでディスクをミラーリングすることができないことを意味します。私たちはスナップショットを取る別の方法が必要です。

どのくらいの頻度でスナップショットを取りたいでしょうか？おそらく、写真の場合、毎週バックアップを実行すべきでした。6日と23時間のデータを失っても、それは問題なく、私たちはそれに対処できます。これはITにおけるリカバリーポイント目標（RPO）と呼ばれるもので、実際のケースでは、データを失う余裕のない重要な金融機関では30秒未満から、一部の小規模企業では24時間以上（災害復旧戦略を持っている場合）まで様々です。

スナップショットを取るということは、ストレージへの負担が増加することを意味します。RPOが24時間の場合、週に7つのスナップショット、月に30、年に365（スナップショットを削除しない場合）を持つことになります。したがって、バックアップローテーションが必要です。

例えば、私が単純なアプローチを取り、14日分のスナップショットを保持することにしたとしましょう。新しいスナップショットを取るとき、最も古いものを削除し、新しいものを追加します。非常にシンプルですが、これでは常に注意を払う必要があります。おそらく大量のデータを保持していて、過去2週間に何かが破損したかどうかを確認するのにうんざりしているかもしれません。しかし、1年分のバックアップを保存することもできず、それらは私にとって関連性がありません。年の2日目と3日目の間に起こったことは、364日目にはほとんど意味がありません。したがって、バックアップを取る粒度は変更する必要があります。今日に近いほど、スナップショットは頻繁になります。過去に遡るほど、スナップショットは少なくなります。

そこで、毎日バックアップを14日間ローテーションし、さらに週次バックアップを7週間ローテーションし、月次バックアップを12ヶ月ローテーションすることにします。これははるかに効率的になるはずです。しかし、また複雑さが増します。私たちは今、GFSローテーションされたスナップショットベースのバックアップと呼ばれるものを持っています。この形容詞のリストは、後で見るように、増え続けるでしょう。

もしかしたら、MPEGがビデオをどのように圧縮するかを見て、映画の穏やかなシーンで、主人公が話しているが他に動かず、背景が完全に静止している場合に、ビデオを圧縮するために使用できることに魅了されるかもしれません。ビデオは、ほとんど互いに似ており、特定の動きでのみ変化するフレームで構成されており、その動きはストレージのほんの一部でベクトルとして表現できることに気づきます。これは、スナップショットも同じパターンに従うという非常に論理的な結論につながります！さらに、ファイル変更はファットテール分布に従うことが判明しており、特定の期間において、変更されないファイルが圧倒的多数を占め、常に変更されるファイルはごくわずかです。

したがって、同一のファイルコピーを保存するのではなく、重複排除すべきであることは明らかです。既存のファイルを参照する必要がある場合は、ハードリンクを使用できます。これにより、ディスク上には1つのファイルを保存し、各スナップショットからそれを参照します。これはバックアップローテーションでも機能します。なぜなら、ファイルを削除するのではなく、ディレクトリエントリのみを削除するからです。この正確なアプローチはrsnapshotによって使用されており、増分バックアップとして最もよく説明されています。なぜなら、最新のフルバックアップ以降のすべての変更（これらは差分バックアップと呼ばれ、復元時に、より堅牢ですが、簡潔さのためにここでは触れません）ではなく、隣接する2つのスナップショット間の変更のみを保存するからです。

ストレージの節約だけが、これを行うことから得られる利点ではありません。最初に、すべてを単一のマシンに保存しないことに briefly 言及しました。明らかに、このプロセスにはネットワークも関わってきます。なぜなら、ファイルをあるマシンから別のマシンに実際に転送する必要があるからです。重複排除されたバックアップは、多くの帯域幅を節約します。これは、2番目のマシンとしてクラウドサービスを使用している場合に特に重要です。それは直接的に財政に影響します。

要約すると、この時点で、私たちは増分、重複排除、GFSローテーション、スナップショットベースのバックアップを作成しました。rsyncを使用してメインマシンからファイルをプルし、cronジョブでバックアップスクリプトを実行できます。好きなだけ多くのマシンでバックアップを実行でき、別のマシンを追加するのは簡単です。さらに、ファイルメタデータが保持されるため、アクセス権限やファイル所有権なども問題ありません。

このソリューションを開発した成功に触発され、10個のDockerコンテナを持つホームラボのバックアップに使用しようとします。しかし、後で個々のマシンのログからバックアップが失敗していることを発見します。その理由は、多くのDockerコンテナがroot権限のファイルを作成することを好み、デフォルトユーザーとして実行されるcronジョブを作成しないように注意しない場合があるためです。

さらに悪いことに、ほとんどすべてのWebアプリケーションは何らかのデータベースを使用します。データベースは、パフォーマンスを向上させるために、メモリ内にデータを保存し、バッチでディスクにフラッシュすることがあります。これは実質的に、運が悪ければデータ破損によりバックアップからの復元が失敗することを意味します。そのため、バックアップでデータベースもダンプし、Dockerボリュームに完全なファイルシステム権限を与えます。これでうまくいくはずです！

その後、ハードドライブのあるモデルが非常に高い故障率で有名だったインシデントについて読んだり、バックアップを異なる種類のメディアを持つ2台のマシンに保存すべきか疑問に思ったりします。そうすれば、ハードウェア固有の障害でバックアップがすべて消去される可能性は低くなります。そして、物理セキュリティの話をしているうちに、オフサイトに1つのバックアップをクラウドまたは親戚の家のマシンに保管しておきましょう。そうすれば、電力サージ、洪水、火災ですべてが破壊される可能性を非常に低くすることができます。これが3-2-1バックアップの名前の由来です：3つのコピー、2つの異なるメディアタイプ、1つのオフサイト。

オフサイトバックアップのためにクラウドプロバイダーを選択したとしましょう。特にAmazon S3のようなオブジェクトストレージです。現在のセットアップが機能しないことにすぐに気づきます。1つ目は、S3にアップロードするとファイルがメタデータを失うこと、2つ目は、S3に多数の小さなファイルをアップロードする際の料金が非常に高いことです（ファイルサイズもファットテール分布に従います）。これらの2つの事実により、多くのファイルをtarballにまとめるのが最善です。そうすれば、ファイルメタデータと低コストの両方を維持できます。しかし、問題は、それをどのように行うかです。すべてを1つの巨大なtarballにまとめますか？明らかにそうではありません。そうすると、ハードリンクを使用した増分バックアップの意味がなくなります。すべてをクリーンな50MBのチャンクに分割するのが最善ですが、検証可能な安全な方法でそれを行うのは運次第です！

これまでのところ、自分でバックアップをロールアウトするのは午後にできることのように思えるかもしれませんが、ここで私は諦めます。単に、これらすべてを行うのに精神的な負担が大きすぎます。代わりに、BorgやResticのような、暗号化、チャンクレベルの重複排除、チェックサムなど、これらすべてをはるかに超える機能を処理する、試行錯誤されたツールを使用します。そして、このすべての複雑さが私たちにとって抽象化されるポイントに到達するためにどれだけの試行錯誤が必要だったかを尊重しながら、これらのツールを構築、維持、ライブテストしてくれた素晴らしいオープンソースコミュニティに最大限の感謝を捧げます。

明らかに、復元を実際にテストしない限り、これらすべてに価値はありません。したがって、それもあなたのToDoリストに追加された小さなデジタル衛生記事です。したがって、6ヶ月ごとに復元を実行する限り、次のものを楽しむことができます。

暗号化された、チャンクレベルで重複排除された、GFSローテーションされた、ポイントインタイムアーカイブされた、クラウド、3-2-1バックアップソリューション

また、午前2時または午前3時にバックアップを実行しないようにしてください。そうしないと、恐ろしいことになる可能性があります。

---

このトピックについて議論してくれたすべての人に心から感謝します。私の心から抜け落ちた、あるいは私が知らなかった、あるいはメインの記事から省略された重要な事項をいくつか紹介します。

1. 午前2時から3時まで、またはその間にcronジョブを実行すべきではありません。明らかに、1時間をスキップするときは、その時間全体をスキップします。または、戻るときに2回実行します。
2. バックアップに関するこのすべての話の中で、ZFSに言及すべきでした。これは、データ整合性とスナップショットの強制を中心に構築された完全なファイルシステムです。
3. HNユーザーcrabboneの言葉を直接引用します。

一貫性グループ。記事はほとんどそれに到達していますが、問題に気づく直前で止まります。複数のプログラムがストレージにアクセスしている場合（例：データベース（スナップショットを取っている）とデータベースを使用しているアプリケーション）、データベースの状態がアプリケーションの状態より先行または遅延している場合、スナップショットの一貫性が失われるリスクがあります。スナップショットデータが有用であることを保証するために、スナップショット以外のすべてのI/Oを凍結するメカニズムが必要です。

ACL。およびストレージの使用状況への同様の外部マッピング。たとえば、ユーザーがLDAPサーバーから来ている場合はどうなりますか？スナップショットの外部にあるシンボリックリンクも同様の問題です。

スパースファイルサポート。たとえば、スナップショットにいくつかのVMイメージがあるとします。ツールがスパースファイルをサポートしていない場合、イメージサイズが大幅に膨張する可能性があります。

要するに、製品固有のスナップショット機能（ZFSにはそれがあります）を使用するか、製品を切り替えるかのどちらかです。