コンテナとその中のファイル、どちらをバックアップするか——復元の形で決める
イメージ単位とファイル単位のバックアップは復元できるものが違い、必要な鍵も異なります。保管する対象を、実際に必要とする復元に合わせてください。
暗号化コンテナは、ひとつの対象としてまるごとバックアップすることも、マウントして中のファイルをバックアップすることもできます。どちらも VPN を問題なく通過しますが、似ているのはそこまでです。復元できるものが違い、依存する鍵も違い、必要な容量も違い、データを戻す必要が生じたときの失敗の仕方も違います。まず復元する対象を決め、次に転送手段を、最後に保管コピーの暗号化を決めます。以下のチェックリストもその順序で進みます。バックアップをめぐる争点のほとんどは、実はこの三つのどれを最初に決めたかという不一致だからです。
二つの対象、二つの復元の形
イメージ単位のバックアップが復元するのはコンテナです。暗号化されたボリュームは戻りますが、開くには復元用の材料が別に必要です。ファイル単位のバックアップが復元するのはファイルとディレクトリの木であり、それを守る暗号化は元のコンテナではなくバックアップリポジトリの性質です。リモートフォルダへの単純なコピーは第三の場合で、そのフォルダがたまたま備えている保護をそのまま引き継ぎます。
| Object | What a restore gives you | Where the encryption question lands |
|---|---|---|
| Encrypted container image | The volume, still locked | The container format and its recovery key material |
| Mounted files into a backup tool | Selected files and metadata | The backup repositorys own keys and design |
| Plain copy to a remote folder | Whatever the copy process kept | Whatever protects that storage afterwards |
真ん中の行は、人が読み違えるところです。これは十分に良い設計になり得ます。バックアッププログラムがローカルで平文を読み、暗号化・認証されたリポジトリを書き出します。その場合の安全性はプログラムとその資格情報に依存し、元のコンテナのパスワードには依存しません。両者を同じ制御として語るべきではありません。
チェック1：復元は何を再構築すべきか
質問はバックアップではなく、復元の形で立てます。要件が「このサービスを別のホストで戻す」なら、イメージと復元用の材料が筋の通った答えです。「三月の財務表を取り戻す」なら、ひとつのファイルを取り出すために数ギガバイトのイメージを復元するのは割高な答えです。どちらも正当な復元であり、互いに置き換えられる予算ではありません。片方だけを挙げた計画は、いずれもう片方で試されます。
復元の対象を計画に書き出します。ボリューム全体、ディレクトリの木、個々のファイルのいずれかです。さらに、どのメタデータを一緒に運ぶ必要があるかを記します。所有者、権限、拡張属性、タイムスタンプはファイル単位の復元の一部であり、試験時に十分に見えたコピー中心の手順ではしばしば落ちるからです。
誰が復元を行うかも決めます。どの運用者でもマウントできるファイル単位のリポジトリは、鍵の保有者の立ち会いを要するイメージとは異なるアクセスモデルであり、どちらが自動的に優れているわけでもありません。重要なのは、選択が意図的で文書化されていることです。
チェック2：保管コピーを守るのは何か
VPN が守るのは転送の区間にすぎません。転送が終わったあとの保管コピーについては何も語らず、「トンネルを通った」はバックアップ運用者があなたのデータを読めるかどうかという話ではありません。リモート側を別の誰かが運用しているなら、問うべきは相手が何を読めるかであり、回線が暗号化されていたかではありません。
イメージの場合、コンテナの鍵素材をイメージ本体とは別に守るということです。ヘッダーを失えばボリュームを失うので、イメージのない場所にヘッダーをバックアップします。
cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20ファイル単位のリポジトリでは、ホストを離れる前に内容とメタデータを暗号化し認証しているかを確認し、鍵を誰が持つのかを把握します。Restic の 設計文書 には、信頼できるソースホストを前提とし、暗号化はストレージへのアクセスを持つ者がバックアップを削除することを妨げないと明言されています。どちらの但し書きも重要です。リポジトリは機密でありながら、破壊され得るからです。
チェック3：コピーは整合しているか
変化し続けるファイルシステムを写したバックアップはコピーであって、復元ポイントではありません。イメージの場合は、ボリュームツールが対応する方法で安定したスナップショットを取ります。大きなファイルが変わり続ける間に読むのではなく、スナップショット操作やアンマウントを用いるのが普通です。
lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonlyマウントしたファイルの場合は、稼働中のデータベースやその他の整合の取れたデータについて、アプリケーションが対応する整合性手順を用います。ファイルシステム単位のコピーとアプリケーション整合の復元ポイントは別の説明であり、その差は復元したコピーからアプリケーションを起動しようとして初めて見えます。
復元用の材料は独立した保護経路に置きます。元のマシンを失うことが、そのバックアップを開く唯一の資格情報まで失うことを意味してはなりません。鍵ファイルがバックアップ対象のボリューム上にあると、まさにそうなります。この分離は意図的に試します。元のマシンを見たことのないホストで、計画が利用可能としているものだけを使って復元します。
チェック4：この対象で変更検出は成り立つか
暗号化コンテナは、ほとんどの転送ツールには大きな不透明なファイル一つに見えます。そのため平文の小さな編集が、ツールと形式によっては大きな再読み込みや完全な再アップロードを招きます。restic が文書化している可変長のチャンク分割と重複排除はそれを減らせますが、それはそのツールの性質であり、暗号化コンテナ一般の性質ではありません。
仮定せずに測ります。小さく無害な変更のあとで一度目と二度目の実行を比べ、転送バイト数と経過時間の両方を記録します。実験中は正常と分かっているバックアップを残し、試験が唯一の復元ポイントを消費しないようにします。
最後に、意味のある唯一の試験でチェックリストを締めます。元のマシンなしで復元することです。復元したコンテナを開くか、選んだファイルをメタデータごと復元し、アプリケーションや利用者が結果を使えることを確かめます。この試験に答えられない高速でよく暗号化された転送は、データのコピーであってバックアップではありません。