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

バックアップは単純ではありません アレクサンダル・フィリポフスキ, 2026-09-16 関連情報：ジョン・サルバティアの優れたブログ、現実は驚くほど詳細である どこかで読んだコメントが心に残り、それは次のようなものでした。「人は二種類いる。壊滅的なデータ損失を経験したことがある人と、これから経験する人だ。」このブログのために出典を探そうとしましたが、他のシステム管理者が引用を様々に言い換えていることがわかりましたが、その要点はどこでも同じです。データ損失は、私たちが望むよりも頻繁に発生するものであり、ほとんどの人はそれが（ほぼ常に最悪のタイミングで）発生したときに、ひどく準備ができていません。 私もかつて同様の経験をしたことがあります。子供の頃、家族の写真を家のラップトップやPCから外付けハードドライブにすべてコピーして、スペースを空けました。これはうまくいっていましたが、ある日、父がそのドライブをテレビのセットトップボックス（古いタイプのもの）のストレージとして使おうとしたとき、フォーマットを促されました。彼はそのままフォーマットを進め、ディスクは再フォーマットされました。ファイルのインデックスが削除され、私たちは名目上空のドライブだけが残されました。彼を責めるのは簡単ですが、このような間違いにつながる一連のエラーを理解するには、テクノロジー分野でのキャリアを始める必要があります。まず、すべての写真を一箇所に集め、バックアップを怠っていました。第二に、ほとんどの一般消費者向けソフトウェアには、ディスクのフォーマットはデータの損失を意味するという大胆な免責事項が表示されます（セットトップボックスにはそれがなく、ひどいUIでした）。それに、非技術的な人がそのようなことを知っている必要があると期待すべきでしょうか？幸いなことに、写真を復元することができ、それはデータを扱う上での安価な教訓となりました。 重要なものを一つの場所にだけ保管してはいけません。数百万ものことが起こり得ます。ドライブが故障するかもしれませんし、盗まれるかもしれません。コールドストレージではビットが腐敗する可能性があります（ハードドライブには説明不能に移動する可能性のある磁性粒子があり、SSDは電気を漏らし、時間の経過とともにデータを破損させるNANDトランジスタでできています）。したがって、私たちの最初の原則は、バックアップ、つまりファイルのコピーを別の場所に持つことです。ここまでは順調です。 これは、接続されたドライブが引き起こす可能性のある頭痛の種をカバーしていません。ランサムウェアはファイルを暗号化する可能性があり、正直な間違いでファイルを削除することから、すべてをゼロで上書きするスクリプトを実行するような壊滅的な間違いまで、何でも起こり得ます。そのため、バックアップは最初のドライブのミラーであってはなりません。なぜなら、私たちがミスをした場合に時間を巻き戻せるようにしたいからです。重要なのは、これはRAID 1のようなディスクのミラーリングは除外されるということです。私たちはスナップショットを取る別の方法が必要です。 どのくらいの頻度でスナップショットを取りたいでしょうか？おそらく、写真の場合、毎週バックアップを実行すべきでした。6日と23時間のデータを失っても、それは問題なく、私たちはそれに耐えることができます。これはITではリカバリーポイント目標（RPO）と呼ばれ、実際のケースでは、データを失う余裕のない重要な金融機関では30秒未満から、一部の中小企業では24時間以上（災害復旧戦略を持っている場合でも）まで様々です。 スナップショットを取るということは、ストレージに増加する負担がかかることを意味します。RPOが24時間の場合、週に7つのスナップショット、月に30、年に365のsnapshotsを持つことになります（スナップショットを削除しない場合）。そのため、バックアップをローテーションする必要があります。単純なアプローチで14日分のスナップショットを保持することにしたとしましょう。新しいスナップショットを取るとき、最も古いものを削除し、新しいものを追加します。非常にシンプルですが、これには注意が必要です。多くのデータを保持していて、過去2週間に何かが破損したかどうかを確認するのが面倒な場合はどうでしょうか？しかし、1年分のバックアップを保存するわけにはいかず、それらはほとんど役に立ちません。年の2日目と3日目の間に起こったことは、364日目にはほとんど意味がありません。したがって、バックアップを取る粒度は変更する必要があります。今日に近いほど、スナップショットは頻繁になります。遠いほど、スナップショットは少なくなります。したがって、毎日のバックアップを14日間ローテーションし、毎週のバックアップを7週間ローテーションし、毎月のバックアップを12ヶ月ローテーションするかもしれません。これははるかに効率的になるはずです。しかし、また複雑さが増します。私たちは今、GFS（Grandfather-Father-Son）ローテーションされた、スナップショットベースのバックアップと呼ばれるものを持っています。この形容詞のリストは、後で見るように増え続けます。 もしかしたら、MPEGがビデオをどのように圧縮するかを見て、映画の静止したシーンで、主人公が話すが、それ以外は完全に静止した背景に対して動かない場合、ビデオ圧縮にどのように使用できるかに魅了されるかもしれません。ビデオはフレームで構成されており、ほとんどが互いに似ており、ベクトルとして表現できる特定の動きでのみ変化するため、ストレージのほんの一部で済むことに気づきます。これは、スナップショットも同じパターンに従うという非常に論理的な結論につながります！さらに、ファイル変更はファットテール分布に従うことが判明しており、特定の期間において、変更されないファイルの大部分と、常に変更されるごく一部のファイルがあります。したがって、同一のファイルのコピーを保存するのではなく、重複排除を行うべきであることは明らかです。既に存在するファイルを参照する必要がある場合は、ハードリンクを使用できます。これにより、ディスク上には1つのファイルを保存し、各スナップショットからそれを参照します。これはバックアップローテーションでも機能します。なぜなら、ファイルを削除するのではなく、ディレクトリエントリのみを削除するからです。この正確なアプローチはrsnapshotによって使用されており、最新のフルバックアップ以降のすべての変更ではなく、隣接する2つのスナップショット間の変更のみを保存するため、増分バックアップとして最もよく説明されます（これらは差分バックアップと呼ばれ、復元時にはより堅牢ですが、簡潔さのためにここでは触れません）。ストレージの節約は、私たちが得る唯一の利点ではありません。私たちは最初に、すべてを単一の機械に保存しないことを述べました。明らかに、このプロセスにはネットワークも関わってきます。なぜなら、ファイルをある機械から別の機械に実際に転送する必要があるからです。重複排除されたバックアップは、多くの帯域幅を節約します。これは、クラウドサービスを2番目の機械として使用する場合、特に重要です。それは直接的に財政に影響します。 要約すると、この時点で、増分、重複排除、GFSローテーションされた、スナップショットベースのバックアップを作成しました。rsyncを使用してメインマシンからファイルをプルし、cronジョブでバックアップスクリプトを実行できます。好きなだけ多くのマシンでバックアップを実行でき、新しいマシンを追加するのは簡単です。さらに良いことに、ファイルメタデータが保持されるため、アクセス権限やファイル所有権のようなものも問題ありません。 このソリューションを開発した成功に触発され、10個のDockerコンテナを持つホームラボのバックアップに使用しようとします。しかし、後で個々のマシンのログからバックアップが失敗していることを発見します。その理由は、多くのDockerコンテナがroot権限でファイルを生成する傾向があり、注意しないとデフォルトユーザーとして実行されるcronジョブを作成してしまう可能性があることです。さらに悪いことに、ほぼすべてのWebアプリケーションは、何らかの種類のデータベースを使用しています。データベースは、パフォーマンスを向上させるために、メモリにデータを格納し、バッチでディスクにフラッシュすることがあります。これは、運が悪ければ、バックアップからの復元がデータ破損のために失敗する可能性があることを意味します。そこで、バックアップにデータベースのダンプも追加し、Dockerボリュームに対する完全なファイルシステム権限を与えます。これでうまくいくはずです！ その後、特定のハードドライブモデルが非常に高い故障率で有名だったというインシデントについて読み、バックアップを異なる種類のメディアを持つ2台のマシンに保存すべきではないかと考え始めます。そうすれば、ハードウェア固有の障害でバックアップが消去される可能性は低くなります。物理的なセキュリティの話をしているついでに、クラウドまたはマ...