どんなバックアップも、実際に必要になる日までは機能しているように見えます。スナップショットは、まさに落ちたそのプラットフォーム上に置かれています。毎晩のtarballは、3月にディスクが満杯になって以来、誰にも気づかれないまま失敗し続けています。データベースのダンプは書き込みの途中でファイルをコピーしたもので、復元しても何も戻りません。バックアップはサーバーの中でも唯一、見ただけでは良し悪しを判断できない部分であり、判断できるのは復元してみたときだけです。本稿では、ハードウェア障害、自分自身のミス、そして認証情報を他人に握られる事態を乗り越えて生き残るバックアップを、保管先の相手に読み取り可能なマシンのコピーを渡すことなく作る方法を解説します。
サーバーを破壊する4つの原因、それぞれに必要な備えは異なる
バックアップはツールを中心にではなく、想定される障害を中心に設計してください。実際に起きる損失は、ほぼすべてこの4つのシナリオに集約され、それぞれが保持しておくコピーに異なる要件を求めます。そのうちの1つに対応できている構成は、別のシナリオに直面するまでは完璧に見えるものです。
ハードウェアまたはホストの障害
ディスク、ノード、あるいはデータセンターそのものが失われるケースです。他のどこかに保管されたコピーがあれば、それだけで復旧できます。同一プラットフォーム上のスナップショットが確実に対応できるのはこの障害だけであり、だからこそ多くの人が「スナップショットで十分」だと思い込んでしまうのです。
自分自身の手によるミス
誤ったフラグ、本番環境に向けて実行してしまったマイグレーションスクリプト、意図した以上に削除してしまったクリーンアップ作業。こうした被害はミラーリングしているものすべてに即座に伝播するため、あなたを救うのは履歴です — ミスの後の現在のコピーではなく、ミスより前のバージョンです。
侵害とランサムウェア
rootを奪った攻撃者は、あなたのバックアップジョブとまったく同じ到達範囲を手にします。同じ認証情報、同じ保存先、同じスケジュールです。サーバー自身が自分のバックアップを削除できるなら、それは削除されます。生き残れるかどうかは、コピーが追記専用であるか、あるいはサーバーの手が完全に届かない場所にあるかにかかっています。
サーバーではなくアカウントを失う
支払いの失効、アカウントの停止、望ましくない法域でのテイクダウン。ハードウェア自体は無事でも、単純にそこへ到達できなくなります。ここで役立つのは、別のプロバイダーの下に、別の支払い経路で置かれたコピーだけです。
何かを選ぶ前に、自分が実際にこの4つのうちどれから身を守ろうとしているのかを書き出してください。同じディスク上の別ディレクトリへ毎晩コピーするだけの構成は、この4つのうちのたった1つ — しかも最も起こりにくいもの — にしか対応していないにもかかわらず、完全にバックアップをしている気にさせてくれます。本番環境で失敗するバックアップ構成の多くは、誰もそのシナリオを名指ししてこなかったことが原因です。
スナップショットはバックアップではない
この2つの言葉はしばしば同じ意味で使われますが、実際には障害の影響範囲が異なる別々のものを指しています。自分が手にしているのがどちらなのかを知ることが、そもそも何かを持っているかどうかの分かれ目になります。
スナップショットは、それが本当に得意なことのためだけに使ってください。つまり、カーネルやブートローダー、データベースのスキーマに手を入れる前の、5秒で済む取り消し手段としてです。取得し、リスクのある作業を行い、うまくいったら削除する。絶対にやってはいけないのは、「スナップショットがあるから」という理由でバックアップを取らないことです。スナップショットは、それを保持しているプラットフォームと運命を共にするものであり、アカウントが停止されればその両方が同時に失われます。
3-2-1ルールと、誰もが省いてしまう2つの数字
この古いルールが今も通用しているのは、単なる保存の仕組みではなく「独立性」を表しているからです。データのコピーを3つ、2種類の異なるストレージに、そのうち1つはどこか別の場所に置く。さらに2つの追加要素が、このルールが作られた当時には稀だったものの、今では日常的になった障害に対応します。
- コピーを3つ。稼働中のデータに加えて、バックアップを2つ。コピーが2つしかなければ、1回の復元の失敗であなたは何も持たない状態になります。
- 2種類のメディア、あるいは2つのプロバイダー。レンタルインフラにおいて「メディア」が本当に意味するのは、管理上の独立性です — 同じアカウント、同じプラットフォーム、同じ残高から支払われた2つ目のコピーは、手間が増えただけの1つのコピーにすぎません。
- 1つはオフサイトに。異なる建物、異なるネットワーク、そしてそれが重要であれば異なる法域に。/locations はこれを実践するための選択肢です。守ろうとしているリージョンとは独立して障害が起きるリージョンを選んでください。
- 1つは不変であるか、オフラインに。サーバー自身には削除できないコピーです。サーバーを掌握した者は、その認証情報も同時に手にしてしまうからです。
- 未検証の復元はゼロに。一度も復元したことのないバックアップは、単なる仮説にすぎません。意味を持つ数字は、成功したと報告されたジョブの回数ではなく、実際に完了させた復元の回数です。
データはバックアップし、それ以外は再構築する
つい、すべてをイメージ化したくなるものです。しかしそれはコストがかかり、復元も遅く、しかも侵害されたバイナリや壊れたパッケージの状態、いつ作ったのかも覚えていない設定のずれまで、忠実に保存してしまいます。サーバーが抱えているコンテンツは3種類あり、バックアップに含めるべきなのはそのうちの1つだけです。
- /etc、/home、/root、/srv、Webルート、アプリケーションの状態を保持するディレクトリ、名前付きのコンテナボリューム、最新のデータベースダンプを置いたディレクトリを含めてください。
- デプロイの手順そのものも含めてください — composeファイル、Ansibleやシェルスクリプト、夜中の2時に書いたメモなどです。バージョン管理にも残しておくべきですが、コピーをバックアップの中にも置き、復旧作業が別のサービスへの到達可能性に依存しないようにしてください。
- /proc、/sys、/dev、/run、および一時ディレクトリ群は除外してください。これらはカーネルのインターフェースや作業用の領域にすぎず、コピーしても時間の無駄になるか、ジョブがそのまま止まってしまいます。
- パッケージのキャッシュ、ビルドディレクトリ、依存関係のツリー、virtualenvなど、ビルド処理で再生成されるものはすべて除外してください。典型的なアプリケーションサーバーでは、これがディスクの大部分を占めています。
- データベースを正しくダンプしているなら、稼働中のデータベースファイル自体は除外してください。両方をバックアップしてしまうと、誰かが夜中の3時に復元してしまうのは、大きいだけで役に立たない方のコピーです。
- 隠しファイルは除外しないでください。Linuxマシンで重要なものの半分は、ドットから始まります。
データベースはファイルコピーでは生き残れない
復元が失敗する原因として、これが最も多いものです。稼働中のデータベースは状態をメモリ上に保持し、書き込みも順序どおりには行われません。稼働中にファイルをコピーすると、断片的で書き込み途中の状態を捉えてしまい、それは復元できるかもしれませんし、気づかないまま壊れた状態で復元されるかもしれませんし、まったく復元できないかもしれません。きちんとしたダンプを取得し、そのダンプをバックアップしてください。
- PostgreSQL: データベースごとにpg_dump、あるいはロールも含めたクラスタ全体にはpg_dumpallを使います。1日分の損失も許容できない場合は、WALアーカイビングを追加し、前日の夜ではなく任意の時点まで復旧できるようにしてください。
- MySQLまたはMariaDB: --single-transactionを付けたmysqldumpは、InnoDBであれば書き込みをブロックせずに一貫性のあるスナップショットを取得できます。MyISAMではそうはいきません — MyISAMを使うべきではないもう1つの理由です。データセットが大きい場合、mariabackupのような物理バックアップツールの方が、ダンプを再生するよりはるかに速く復元できます。
- SQLite: ファイルを直接コピーしてはいけません。ロックを正しく扱う .backup コマンドか VACUUM INTO を使ってください。書き込み中のWAL(先行書き込みログ)があるデータベースをそのままコピーするのは、いつか必ず負ける賭けをしているようなものです。
- Redis: バックグラウンドセーブを実行して、生成されたスナップショットファイルをバックアップするか、追記専用モードで動かしてログをバックアップしてください。書き込みの途中で稼働中のスナップショットをコピーすると、途中で切れたファイルになり、読み込むと空のデータセットになってしまいます。
- コンテナ: ボリュームそのものがデータです。コピーにかかる数秒間だけスタックを停止するか、コンテナの中でダンプツールを実行してください — ただし、稼働中のデータベースのボリュームをtarで固めただけのものをバックアップと呼んではいけません。
- 常駐プロセスを持つそれ以外のもの — 検索インデックス、メッセージキュー、台帳デーモンなど — にも、それぞれ専用の一貫性のあるエクスポートコマンドがあります。障害が起きてからではなく、今のうちに見つけておいてください。
ファイルシステムのスナップショットは、これを逆の方向から解決します。LVM、ZFS、btrfsは、ボリュームの一貫性のあるビューをミリ秒単位で凍結でき、データベースを稼働させたまま、その凍結されたビューをバックアップできます。ダンプに何時間もかかるようなデータセットには、これが正しい答えです。ただし、200MB程度のデータベースでダンプを省略していい理由にはなりません。そうした規模であれば、ダンプの方が単純で、エンジンのバージョンをまたいで持ち運べ、何かがおかしくなったときに人間が読んで確認することもできます。
ツールを選ぶ
ほとんどのケースは、この4つのツールでカバーできます。最も重要な性質は、暗号化がどこで行われるかです。データが転送中にのみ暗号化され、保存時にはストレージプロバイダー側で暗号化されているだけなら、ストレージプロバイダーはそのデータを読むことができます — つまり、他のすべての場所を堅牢にしたはずのシステムの中で、バックアップだけが知らないうちに最も弱い部分になってしまっているのです。
何を選ぶにせよ、パスフレーズや鍵は、バックアップ対象のサーバー以外のどこかに存在していなければなりません。これは注意深い人ほどはまりがちな罠です。/root に保存されたリポジトリの鍵が、その鍵で開くはずのリポジトリの中に、律儀に一緒にバックアップされてしまうのです。印刷しておくか、まだ無事なマシンから開けるパスワードマネージャーに保管してください。復号できないリポジトリは、バックアップが存在しないのと見分けがつきません。
2つ目のコピーはどこに置くべきか
保存先は、単なるディスク容量であると同時に、1つの法域であり1つの支払い関係でもあります。ここでは4つの選択肢を、保護対象のサーバーからの独立性がおおよそ高い順に紹介します。
別リージョンにある2台目のサーバー
最もシンプルな答えです。別の国にある安価なインスタンスをSSH経由で使い、sshdとリポジトリ以外は何も動かしません。1GBの /vps プランでも小規模なサーバー群のバックアップを十分にまかなえますし、アカウントを単一の強制コマンドに制限しておけば、鍵が盗まれてもシェルは開けません。
ストレージクラスのディスク
データセットが数百ギガバイトの規模になると、無制限帯域のアップリンクを備えたHDD容量の方が、テラバイトあたりの単価はNVMeよりはるかに安くなります。バックアップの書き込みにNVMe並みのレイテンシは必要ありません。/storage はまさにこの用途のために作られています。テラバイト級のRAID保護されたディスク、フルroot権限、コンテンツの検査もありません。
S3互換のオブジェクトストレージ
手軽で、ギガバイト単位で課金され、本物の不変性をもたらすオブジェクトロックに対応していることも少なくありません。頼りにする前にエグレス(送出)料金を確認しておいてください。緊急時に1テラバイトを取り戻そうとしている最中に、取得コストの高さに気づくのは最悪のタイミングです。
自分が所有するハードウェア
外付けディスクや自宅のマシンに、送り込むのではなく引き取る形で保存します。速度は遅く手作業も必要になりますが、このリストの中で唯一、どのプロバイダーも、裁判所の命令も、支払いをめぐるトラブルも手を出せないコピーです。1週間遅れになったとしても、本当に再現不可能なデータについては維持しておく価値があります。
バックアップのプライバシー特性は、サーバー本体のそれと揃えてください。LUKSでディスクを暗号化しておきながら、毎晩平文のバックアップを自分のカードで登録したバケットへ送っていては、これまでの取り組みがすべて無意味になります。データは読める状態になり、しかもあなたの名前で記録されてしまいます。サーバーを匿名で支払う価値があったなら、そのコピーにも同じだけの価値があります — クライアント側で暗号化し、保存先も元のサーバーを購入したのと同じ方法で購入してください。
実際に構築する: 手順を追って
- 1
最初に2つの数字を決める
どれだけのデータなら失っても構わないか — つまり実行間隔の許容範囲 — と、どれだけの停止時間なら許容できるかです。それ以外のすべては、この2つの答えから導かれます。静的サイトを毎時バックアップするのは見せかけにすぎません。注文データベースを毎晩バックアップするかどうかは、チュートリアルをそのまま踏襲するのではなく、自分で意図的に下すべき判断です。
- 2
保存先を用意する
別リージョンに2台目のインスタンスを用意し、専用のSSH鍵と、ホームディレクトリがリポジトリになっている専用の非特権ユーザーを設定します。そこでは他に何も動かしません。鍵を強制コマンドに制限し、認証情報が盗まれてもバックアップの追記しかできず、シェルは開けないようにしてください。
- 3
鍵を生成し、別の場所に保管する
長くランダムなパスフレーズを、サーバーを失っても残る場所に記録してください。リポジトリを初期化したら、書き留めた情報だけを使って3台目のマシンから中身を一覧表示できることを確認します。それができないなら、1件もバックアップを書き込む前に直しておいてください。
- 4
先にデータベースをダンプする
ステージング用のディレクトリに一貫性のあるダンプを書き出し、どれか1つでも失敗したら非ゼロで終了する短いスクリプトを用意してください — ファイルのバックアップと同時にではなく、その前に実行します。ダンプが失敗してもそのまま処理を続けるジョブは、気づけば30日分のゼロバイトファイルが並ぶ結果を招きます。
- 5
重要なパスをバックアップする
ツールに含めるリストを指定し、除外設定を適用したうえで、最初の実行結果が妥当かどうかを確認してください。40GBのサーバーから作った新規リポジトリが300MBにしかならないなら、何かが気づかれないままスキップされています。逆に38GBになるなら、除外設定が機能していません。
- 6
スケジュールを組み、失敗を目立たせる
ランダムな遅延を持たせたsystemdタイマーを使うか、慣れているならcronでも構いません。そのうえでジョブに報告させてください。成功時にはハートビートを監視先へ送り、ハートビートが届かなくなったらアラートを出します。バックアップにとって静かな失敗こそが通常の失敗のあり方です。止まっても目に見える形では何も壊れないからです — すべてが壊れるその瞬間までは。
- 7
保持期間を設定し、実際にプルーニングする
1日分は毎時、2週間分は毎日、2か月分は毎週、1年分は毎月。そのうえでプルーニングを実行し、リポジトリの肥大化が止まることを確認してください。設定しただけで一度も実行されない保持ポリシーは、保存先を埋め尽くし、バックアップごと道連れにします。
- 8
今日、何かを復元してみる
テスト用のジョブではなく、実在するファイルを、作業用のディレクトリに復元し、開いて確認してください。そのうえで、マシン全体を対象にした復元の日付をカレンダーに書き込んでおきます。初めての完全復元では、必ず何かが表面化します。抜けていたパス、パーミッション、証明書、あるいは古いマシンにしか存在しなかったデータベースユーザーなどです。
サーバーから外へバックアップをプッシュする方式を選んだ時点で、そのサーバーでrootを握った者が全コピーを破壊できることを受け入れたことになります。逆の方式を取れば — バックアップ用のホストが接続してきて、取得し、切断する — 侵害されたサーバーはリポジトリの認証情報を一切持たないため、そこに到達すること自体ができません。プル方式は構築の手間が増えますが、ほとんどの構成にとって、これこそが最も効果の大きい改善です。
保持期間 — 長く残す方が見た目より安く済む理由
保持期間は、たいていディスク容量に収まる範囲で適当に決められ、そのまま忘れ去られます。しかしこれは、どのミスなら取り返しがつくのかを左右するため、一度は本気で考える価値があります。7日間のウィンドウでは、火曜日に削除したファイルは救えます。しかし6週間前に始まり、レポートの数字がおかしいことで発覚した破損や、行動を起こす前に1か月も静かにマシンに潜んでいた侵入者は救えません。
重複排除のおかげで、実際のコストは上の表が示すよりもはるかに安く済みます。ほとんど変化のないサーバーに対する2回目以降の実行では、変化した部分だけが保存されるため、40GBのマシンで1年分の毎月の復元ポイントを持っていても、通常は半テラバイトではなく数ギガバイト程度で済みます。まず何から復旧できる必要があるかを基準にポリシーを決め、それから請求額を確認してください。たいていの場合、余裕を持った設定でも十分に払える範囲だとわかるはずです。
不変性 — ランサムウェアを止める部分
ここまでの話はすべて、敵がエントロピー(偶発的な劣化)であることを前提にしています。もし敵がrootを握った人間だとしたら、ふつうのバックアップジョブはむしろ攻撃者向けの手順書になってしまいます。認証情報はサーバー上にあり、保存先は設定ファイルに書かれており、暗号化が始まる前にリポジトリが消去されてしまうからです。この連鎖を断ち切る仕組みは4つあり、そのどれか1つを導入するだけでも結果は変わります。
- 追記専用のリポジトリ。Borgのサーバー側追記専用モード、あるいは追記専用モードで動かしたresticのRESTサーバーは、新しいデータの受け入れは行いますが削除は拒否します。サーバー側は書き込みだけができ、プルーニングができるのは別の場所にいるあなただけです。
- プル方式のバックアップ。バックアップ用のホストが接続を開始し、認証情報を保持するのもそちらだけです。本番サーバー側には鍵も、保存先のアドレスも、リポジトリへの経路も一切存在しません。
- オブジェクトロック。バケット単位で保持期間が強制されるS3互換ストレージでは、たとえ認証情報がそれ以外を許可していたとしても、ストレージ層そのものが削除を拒否します。
- ホストごとに別々の認証情報を使う。1台のマシンが侵害されたからといって、他のすべてのマシンの履歴まで危険にさらされるべきではありません。鍵も、パスも、制限も、それぞれ独立させてください。
- 本当にオフラインなコピーを1つ持つ。電源を抜いたディスクは、これまでに書かれたどんなリモート攻撃に対しても無敵です。流行遅れではありますが、いまだに負けなしです。
復元訓練
復元とは1つの手順であり、誰も実行したことのない手順はフィクションにすぎません。これを今すぐ一度、そしてその後は半年ごとに実行し、そこで学んだことを書き留めてください。そのメモは、いずれデータそのものと同じくらい価値を持つようになります。
- 1
まっさらなインスタンスをデプロイする
同じOSバージョンで、それ以外は何もインストールしません。短命なVPSで十分であり、この演習全体にかかる費用はランチ1回分にも届きません。
- 2
書き留めた情報だけを使って復元する
リポジトリのアドレス、パスフレーズ、コマンド。もし、死んだと仮定しているそのサーバー上にしか存在しない何かが必要になったなら、あなたはまさに欠陥を見つけたことになります — しかも、それを見つけても何のコストもかからない日にです。
- 3
アプリケーションより先にデータを戻す
データベースのダンプを読み込み、ファイルを本来あるべき場所に置き、そのうえで所有者とパーミッションを修正してください。だいたいいつも驚かされるのは所有者の設定です。古いマシンの数値ユーザーIDが、新しいマシンでもそのまま一致することはめったにありません。
- 4
サービスを起動し、実際に使ってみる
ステータスを確認するコマンドを実行するだけでは不十分です。実際にログインし、ページを読み込み、クエリを実行し、メッセージを送ってください。起動するサービスと、機能するサービスは、同じものではありません。
- 5
時間を計測し、その数字を書き留める
全体でどれくらいの時間がかかったか。それがあなたの本当の復旧時間であり、たいていの場合、事前の見積もりの何倍にもなります。このメモはパスフレーズのそばに保管し、スタックが変わるたびに両方を更新してください。
実際にかかる費用
バックアップは、インフラにおいて最も安価な保険でありながら、価格を理由に日常的に省略されています。ここでは、一般的なデータと同じように圧縮・重複排除されると仮定した場合の、小規模なサーバーにおける具体的な数字を示します。
これらの金額を、それによって防げる障害のコストと比べてみてください。数字を具体的に示すこと自体に意味があります。金額をいざ書き出してみると、バックアップに反対する理由が本当にお金の問題だったことなど、ほとんどないとわかるはずです。
ホスティング事業者が果たす役割
バックアップ計画には、それが守っているサーバー自体と同じ2つの依存関係があります。コピーを置く独立した場所と、それに対して自分が誰であるかという新たな記録を残さずに支払う方法です。バックアップは元のサーバーが守っていたものすべての完全なコピーであるため、この2つは元のサーバー以上に重要になります。
当社の /vps と /storage の各プランはすべて、KYCなしのプリペイド暗号資産残高からデプロイでき、/locations に掲載されている15のリージョンにまたがっています — つまり、2つ目のコピーを、身元確認を一度も挟むことなく、1つ目とは異なる法域の下に置けるということです。すべてのインスタンスには5秒で済む取り消し操作のためのインスタントスナップショットが含まれており、無制限帯域のおかげで最初のアップロードも緊急時の復元も従量課金の対象にはなりません。また /storage では、コンテンツ検査なしのテラバイト級RAID保護ディスクを$8.99/moから追加できます。/pay-with では対応コインを、/offshore-hosting では法域によって実際に何が変わるのかを、/guides ではディスク暗号化や、ホスティング事業者がマシンについて何を見ることができて何を見ることができないのかを扱った関連記事をそれぞれ紹介しています。
チェックリスト
- ツールを選ぶ前に、自分が何の障害から身を守ろうとしているのかを明確にする。
- スナップショットは取り消しボタンとして扱い、バックアップそのものとは決して考えない。
- データと設定はバックアップし、OSはスクリプトから再構築する。
- すべてのデータベースを、それぞれ専用の一貫性のあるエクスポートコマンドでダンプし、そのダンプをバックアップする。
- データがマシンを離れる前に、クライアント側で暗号化する。
- リポジトリのパスフレーズは、サーバーを失っても残る場所に保管する。
- 少なくとも1つのコピーは、別のプロバイダー、別のリージョン、別の支払い経路の下に置く。
- 1つのコピーは追記専用、プル方式、またはオフラインにし、rootを奪われても消去できないようにする。
- 成功した実行が確認できないことをアラートの対象にする — 失敗は静かに起こるものであり、その静けさこそが症状である。
- 今日1つのファイルを復元し、マシン全体は年に2回復元する。時間を計測し、記録する。
プロバイダーのスナップショットだけで十分ですか。
いいえ、そしてこれは、他の点では注意深く構築された環境でも最もよく見られる抜け穴です。スナップショットは、それがコピーしているボリュームと同じプラットフォーム上に存在するため、プラットフォームレベルの障害、アカウントの停止、支払いの失効といった、まさに最も必要とされる3つの場面を生き延びられません。また通常は短い履歴しか保持しないため、先月削除したファイルや、6週間前から始まっていた破損を回復することもできません。スナップショットは、リスクのある変更の前に使う5秒の取り消し手段としては優秀です。日常的に活用しつつ、本物のバックアップは別の場所に必ず持っておいてください。
resticとBorg、どちらを使うべきですか。
保存先がオブジェクトストレージか、素のSSHアカウントであるならresticです。相手側に何もインストールする必要がなく、S3をネイティブに扱えるからです。保存先が自分の管理するLinuxマシンで、追記専用のサーバーモードとやや高い圧縮率が欲しいならBorgです。どちらも重複排除を行い、どちらもクライアント側で暗号化と認証を行い、どちらも成熟していて広く使われており、どちらを選んでも十分に理にかなっています。間違った答えは、サーバーにバックアップが1つもない状態のまま、1か月かけて両者を比較し続けることです — 今日の午後にはどちらか1つを選び、必要になったら後で気を変えれば十分です。
VPSはどのくらいの頻度でバックアップすべきですか。
この間隔は、単純に、やり直してもいいと思える作業量の上限で決まります。静的サイトなら週1回で十分正直な答えです。ユーザーが書き込みを行うものであれば、毎晩が最低ラインであり、重複排除が働き始めれば毎時実行してもコストはわずかです — 1日の2回目以降の実行では、たいてい数メガバイト程度しか保存されません。1日分のデータの価値と、1つではなく24個の復元ポイントを保存するコストを天秤にかければ、たいてい答えは自明です。
ディスク全体をバックアップすべきですか、それとも自分のデータだけで十分ですか。
ほとんどの場合、データと設定だけで十分です。ディスクの完全なイメージは、マシンをあった通りに正確に復元しますが、そこには今まさに回復しようとしている侵害の痕跡や、もはや把握していないパッケージの状態まで含まれてしまい、作成にも復元にも時間がかかります。/etc、アプリケーションのデータ、データベースのダンプをファイル単位でバックアップし、OSを再構築するスクリプトと組み合わせる方が、より速く、よりきれいに復元できます。ビット単位で正確なフォレンジック保存が必要な場合や、そのマシンが他人が構築したブラックボックスである場合には、ディスクをイメージ化してください。
プロバイダーはディスクが暗号化されていると言っています。私のバックアップも暗号化されていることになりますか。
あなたの役に立つという意味では、なっていません。プロバイダー側の暗号化が守るのは、ドライブがラックから持ち出されるような場面です。鍵はプロバイダーが保持しているため、データはプロバイダー自身、そしてプロバイダーに強制力を行使できる者にとっては読める状態のままです。クライアント側の暗号化 — restic、Borg、rcloneのcryptレイヤー、あるいは暗号化されたアーカイブ — であれば、保存先に届くものは、あなたのマシンから一度も出ていないパスフレーズなしには意味を持ちません。プライバシーが重要なスタックにおいては、この違いがすべてです。なぜなら、バックアップとはサーバーが守っていたものすべての完全なコピーだからです。
ランサムウェアにバックアップまで暗号化されないようにするにはどうすればよいですか。
サーバーが到達できるものはすべて、rootを奪った攻撃者も破壊できると考えてください。認証情報も、保存先も、スケジュールも、すべてそのマシンの上にあるからです。この到達範囲を断ち切る方法は3つあります。書き込みは受け付けるが削除は拒否する追記専用のリポジトリ、バックアップ用のホストが内向きに接続しサーバー側は認証情報を一切持たないプルモデル、そしてストレージ層自体がロックを強制するオブジェクトストレージです。そのうえで保持期間を長く設定し、静かにゆっくり進む侵害が誰にも気づかれないままウィンドウの外に流れ去ってしまわないようにし、さらにリモート攻撃が絶対に届かないオフラインのコピーも1つ持っておいてください。
