復元で確かめていないバックアップは、ただの主張だ
要点
- 検証の各段階が、前の段階では捕まえられないものを捕まえた。34個のファイルはチェックサムが一致したのに開けず、ハッシュの差分は不良セクタ上の動画クリップを示したが、SMARTは「Verified」のままだった。
- 保存先ごとに障害シナリオを書くと、最大の単一障害点はAppleアカウントだった。チェックを実行したAIエージェントも、データの読み手に数える。
- オフサイトのコピーは4つの構成を比べ、ArqからBackblaze B2への構成を選んだ。Mac上で暗号化し、メールとは別のアカウントに置いて、月1ドルほど。
- 復元テストでは760 MBが12秒でB2から戻り、すべてのファイルが最初に保存したときに記録したチェックサムと一致した。
私のキャリアの多くはデータベースとストリーミングシステムで、そこではレプリケーション、テスト済みの復元、バックアップが古くなったときのアラートなしには何も出荷しない。9月、自分のストレージを同じ監査にかけた。その仕事から持ち込んだルールは次の4つだ。
- データがある場所はすべて1行にし、障害シナリオを付ける。
- コピーはチェックを経て初めてバックアップと数える。チェックは3段階で、ファイルを数え、ハッシュを取り、開く。各段階は前の段階が捕まえられないものを捕まえる。
- 遅れたバックアップはアラームを鳴らす。
- 作業するAIエージェントもデータの読み手に数える。
保存先ごとに1行と障害シナリオ
台帳はTOMLファイルで、Mac、外付けドライブ、iCloud、Google、GitHub、エージェントのトランスクリプトがそれぞれ1行になっている。各行には、Macが壊れたとき、家が燃えたとき、アカウントから締め出されたときに何を失うかを書き、スクリプトがこのファイルを障害別に整理したページとして描画する。
そう書き出してみると、最大の単一障害点はアカウントだった。「Macのストレージを最適化」がオンだと、Macは収まる分しか写真のオリジナルを保持せず、残りのライブラリはiCloudにしかない。「高度なデータ保護」をオンにしていたので、Appleは鍵を持たず、私の代わりにアカウントを復旧することもできない。アカウントの保護は対策の半分で、残り半分はアカウントの外にあるコピーだ。
そのコピーは、osxphotosでオリジナルをローカルドライブに書き出す四半期ごとのエクスポートだ。osxphotosは書き出し済みのものを覚えているので、2回目以降は新しい写真だけをコピーする。初回は、速度テストで909出た回線で25 Mbit/sしか出なかった。「写真」はiCloudから欠けているオリジナルを1枚ずつダウンロードするので、1件ごとの待ち時間が大半を占める。
検証は3段階：数える、ハッシュ、開く
段階が上がるごとにコストも上がる。マニフェストと突き合わせて数えるのは安い。最初のTime Machineバックアップは、スナップショットを読み取り専用でマウントし、ファイルを数え直して確認した。数えるだけでは、切り詰められたファイルは見えない。ハッシュでは、コピー前から壊れていたファイルは見えない。
SMARTが「Verified」と表示する中、ハッシュの差分が不良セクタを捉えた
動画を入れたドライブには、2台目のドライブに完全なコピーがあるはずだった。安いデュアルベイのドックは3.5インチドライブを2台同時に動かせない（2台目がバスから落ちる）ので、比較は1台ずつ行った。全ファイルのハッシュをMac上のマニフェストに書き、ドライブを差し替え、もう一度ハッシュを取り、マニフェストの差分を取る。1台につき一晩。
一致しなかったのは252 MBのクリップ1つだけで、夜通しの処理はそれを最初から最後まで読み切っていた。翌朝それをコピーすると76.5 MBの地点でI/Oエラーになり、2回とも同じバイトで止まった。ドライブのSMART概要はまだ「Verified」だった。私はそのクリップを諦めた。差分は未知を1件の既知の損失に変えた。それがなければ、ほかのどのファイルが無事なのかも言えなかった。
34個のファイルはチェックサムが一致し、開けなかった
古いSSDはTime Machineディスクの当然の候補だったが、残しておきたい写真と動画が入っていた。消去する前に2回コピーし、両方のコピーをSHA-256のマニフェストと照合した。すべて一致した。次に全ファイルを開いた。画像はすべてデコードし、動画は最後まで再生し、文書はパースした。34個が失敗した。
コピーはハッシュで元と一致していたので、損傷は元のドライブにあり、おそらく何年も前からのものだ。書き込まれて以来、誰もそのファイルを開いていなかった。その後ドライブは暗号化APFSとして消去され、Time Machineディスクになった。
エージェントはデータの読み手に数える
作業の大半はエージェントがやった。ドライブを計測し、台帳を書き、ページを作り、エクスポートを実行した。エージェントが開いたものはすべてモデル提供元に送られ、その保持規約のもとで保存される。さらに、私が手元に残しているMac上のトランスクリプトにも残る。
そこで、個人の書類があるフォルダは「先に確認」にした。読むたびに私の承認がいる。最も機密性の高いファイルは暗号化ディスクイメージに移し、オリジナルを消す前にハッシュで確認した。そのイメージには手を出させない。マウントには、私しか入力しないパスワードが必要だからだ。
最初はそうなっていなかった。テストのためにイメージを開くと、プロンプトなしでマウントされた。イメージを作ったときにmacOSがパスワードをログインキーチェーンに保存していたので、暗号化が守れていたのは、ロック解除された私のMacの前に座る人以外の全員からだけだった。エージェントが保存されたパスワードを探そうとキーチェーンの項目を読もうとすると、エージェント自身の権限チェックがそのコマンドを認証情報の探索として拒否したので、その手順は私が手作業でやった。項目は「キーチェーンアクセス」にあった（最初は新しい「パスワード」アプリを探して見落とした）。それを削除すると、プロンプトが戻った。
オフサイトバックアップは月1ドルほど、手間がかかったのは選ぶこと
重要な保存先には今どれもコピーが2つあるが、どちらも同じ部屋にある。オフサイトのコピーが何をカバーすべきかは、障害シナリオが決めた。
- 拠点の喪失（火事、盗難）：別の建物にあるコピー。
- 削除とランサムウェア：日付付きのスナップショット。フォルダを先週の火曜日の状態に戻せる。iCloud DriveやGoogle ドライブのアプリのような同期フォルダは、削除まで同期してしまう。
- アカウントの喪失：メールがあるアカウントの外に置く。
- 提供元への侵入：Mac上で暗号化し、鍵は私だけが持つ。
- 復旧：1時間ごとの復旧ポイントと、新しいMacでターミナルを使わずに実行できる復元。
オフサイトに置くのは書類、スキャン、プロジェクトデータ、エージェントのトランスクリプトで、動画は対象外だ。10月10日に4つの選択肢を調べた。
| 選択肢 | 100 GBでの費用 | 鍵を持つのは誰か | 落とし穴 |
|---|---|---|---|
| Arq 7からGoogle ドライブへ | 買い切り$59.99、加えてGoogleの2 TBプランが月$9.99 | 自分 | Arqのリリースノートに、2021年、2023年、2024年のGoogleクォータ関連の修正 |
| Arq 7からBackblaze B2へ | 買い切り$59.99、加えて月約$0.70（1 TBあたり$6.95） | 自分 | 支払い続ける業者が2社になる |
| resticまたはKopiaからB2へ | フリーソフトウェア、加えて月約$0.70 | 自分 | resticにはアプリがないので、スケジュールは自分で組み、復元はターミナルから行う。Kopiaにはアプリがあるが、まだバージョン0.23 |
| Backblaze Personal Backup | 年$99、容量無制限 | Backblaze（プライベートキーを設定しない限り） | 既定の30日間の履歴では、30日間接続しなかったドライブは削除される可能性がある |
Google ドライブは手軽な選択だったが、アカウントの要件を満たさない。一度締め出されれば、メールとバックアップが一緒に失われる。
お金で買えるのは使いやすさで、安全性ではない。B2上の暗号化データは、2015年から出荷されているresticでも、Arqでも同じくらい安全だ。Arqは小さな会社Haystack Softwareの製品だが、データ形式が公開されているので、会社がなくなってもバックアップは読める。$60で買えるのは、新しいMacでターミナルもエージェントも使わずにクリックで進められる復元だ。
ツールの選択はやり直せる。乗り換えのコストは再アップロードで、約1日。暗号化パスワードを失えば取り返しがつかない。誰もリセットできず、ベンダーも例外ではないからだ。
私はArqからB2への構成を選んだ。弱点はBackblazeのアカウントだった。2要素認証のコードがGmailに届いていたので、私のGmailに入れる人なら誰でもログインしてバックアップを削除できた。今は認証アプリを使っていて、同じ理由で「Googleでログイン」も使わなかった。
バックアップツールは各チャンクを一度だけアップロードし、全バージョンを残す
Arqのスナップショットは、すべてのファイルとそれを構成するチャンクの完全な一覧だが、各チャンクは一度しかアップロードされない。Arqはチャンクに内容のハッシュで名前を付け、バケットにすでにあるチャンクは飛ばすので、初回アップロード後の1時間ごとの実行で送るのは15〜45 MBだ。古いスナップショットのコストは小さい。新しいスナップショットとチャンクを共有しているからだ。
| Arq 7 | restic | Kopia | |
|---|---|---|---|
| チャンクの分割位置 | 非公開（Arq 5はローリングチェックサムを使っていた） | コンテンツ定義（Rabin）、平均約1 MiB | コンテンツ定義（buzhash） |
| チャンク名 | 秘密のソルトを混ぜたハッシュ。式は非公開 | 素のSHA-256。暗号化されたインデックスファイル内に保持 | 秘密鍵によるHMAC |
| 暗号化 | AES-CBCとHMAC-SHA256 | AES-256-CTRとPoly1305 | AES-256-GCMまたはChaCha20-Poly1305 |
| パスワードから鍵へ | PBKDF2、200,000回 | scrypt | scrypt |
| 古いデータの削除 | 毎回のバックアップの後 | prune。実行中はバックアップを完了できない |
安全のための待機期間の後にガベージコレクション |
コンテンツ定義チャンキングでは、ファイルの途中に挿入しても動くのはその付近のチャンク境界だけで、ファイルの残りは保存済みのデータと一致したままになる。
チャンク名が重要なのは、ストレージ提供元から見えるからだ。素のハッシュだと、バケットを持つ誰もが、自分の手元にあるファイルを私が保存しているかどうかを確認できる。KopiaとArqは名前に秘密を混ぜる。resticは素のハッシュを暗号化されたインデックスファイルの中に隠し、その設計文書は残る漏洩についても記している。B2のコンソールで見ると、私のバケットは番号付きのフォルダにランダムな名前のオブジェクトが並んでいるだけで、クライアント側暗号化を外から見ればそうなっているべき姿だ。
古いデータの削除は危険な工程だ。スナップショットを期限切れにするとは、残るどのスナップショットも使っていないチャンクをすべて見つけ、それだけを削除することを意味する。間違えれば、後の復元で欠けるピースが出る。resticは削除処理の間バックアップを止め、Kopiaは削除前に安全期間を待つ。
次に、同じハッシュの段階で復元をテストした。スキャンした新聞5紙、約760 MBが12秒でB2から戻り、およそ500 Mbit/sで、5紙すべてがスキャンを取り込んだときに書いたSHA-256マニフェストと一致した。この速度なら、バックアップ全体も1時間以内に戻る。フルリストアの時間は計っていないし、何千もの小さなファイルは5つの大きなファイルより遅くなる。
バックアップが遅れるとページが赤くなる
台帳ページはディスクをライブで読むので、遅れたTime Machineは誰が確認しなくても赤くなる。黙って止まったバックアップは、復元が必要になるその日まで、動いているバックアップと見分けがつかない。
10月に一度、復元でB2のコピーを確認した。それがまだ動いているかをチェックする仕組みはまだなく、そのアラームが次の作業だ。