本当に復元できるVPSをバックアップ

誰に尋ねても、バックアップする理由はたいてい「ディスクが壊れたときのため」と返ってきます。現代のVPSにおいて、それはあなたの身に起こる可能性が最も低いことの一つです。あなたのボリュームは冗長化されたアレイ上のNVMeに置かれており、ハイパーバイザーは、あなたが気づく前に障害の出たホストからマイグレーションを済ませてしまいます。ドライブ障害はプロバイダー側の問題であり、しかもすでに解決済みの問題です。それを中心にバックアップ戦略のすべてを組み立てるのは、洪水になる家のために消火器を買うようなものです。

実際に人々のデータを奪っているものを、おおよその頻度順に挙げます。まず、圧倒的多数を占めるのがあなた自身です。空文字列に展開された変数を伴うrm -rf。二つのタブが見分けられなかったせいで間違った端末で実行されたDROP DATABASE。二回実行されたマイグレーションスクリプト。-vが指癖になっていたdocker compose down -v。これらは特殊な事例ではありません。ただの火曜日です。

二番目は、アプリケーション自身が自分のデータを削除するケースです。破壊的なマイグレーションを実行して途中で失敗するアップグレード。キャッシュではなかったことが判明したディレクトリをクリアしてしまうプラグイン。誤ったパスに対して設定されたログローテーション。三番目は侵害です――そしてこれは、攻撃者がバックアップの消去を望んでいるケースであり、それが以下で立ち返ることになる設計上の変化をもたらします。四番目は、no-KYCホストでは忘れがちなアカウントの喪失です。不在の間にゼロになった残高、書き留めなかったパスワードマネージャーのエントリー、放棄したメールアドレス。私たちは残高がゼロになってから数時間以内に停止し、7日後には破棄します。これは意図的に容赦のない仕様であり、あなたが誰であるかを尋ねずに済ませるための算術です。あなたの身元を調べて例外を作ってくれるサポート担当者はいません。そもそも調べるべき身元が存在しないからです。

この最後のカテゴリーこそが、プライバシー最優先のホスティングと主流派のホスティングを分けるものであり、あなたの計画を形作るべきものです。このサーバーをあなたに結びつけにくくする制御はすべて、私たちを含めた誰にとっても、それをあなたに返しにくくします。バックアップこそが、その取引をリスクから選択肢へと変えてくれるものなのです。

スナップショットは素晴らしいものであり、ぜひ使うべきです。カーネルのアップグレードの前、データベースのマイグレーションの前、取り消せるようにしておきたい何かを行う前には、必ず一つ取っておいてください。数秒で復元でき、コストはほとんどかからず、年に十数回はあなたの午後を救ってくれます。

それでも、三つの構造的な理由により、スナップショットはバックアップではありません。これはプロバイダーがどれだけマーケティングをしても変わりません。まず、同じアカウントの内側に存在します。パネルにログインできる者なら誰でも削除できますし、アカウントが機能しなくなれば、スナップショットもそれとともに消滅します。次に、同じ障害ドメインに存在します。同じプロバイダー、同じコントロールプレーン、しばしば同じストレージクラスターであり、一つの悪い出来事がオリジナルとコピーの両方を道連れにしうるということです。そして、不透明です。稼働中のマシンのスナップショットは、書き込み途中のデータベースを、それ以外のすべてとまったく同じように忠実に捉えてしまいます。したがって、稼働中のMySQLサーバーのスナップショット復元が与えてくれるのは、クリーンなデータベースではなくクラッシュリカバリーのシナリオです。

昔ながらの3-2-1ルール――三つのコピーを、二種類のメディアに、うち一つはオフサイトに――は、真ん中の条項がレンタルインフラ上では意味をなさないことに気づかないまま唱えられがちです。あなたには二種類のメディアなど存在しません。あるのは仮想ブロックデバイスと、もう一つの仮想ブロックデバイスであり、どちらも誰かのSANです。VPSへの翻訳を生き延びる部分は、もともと重要だった部分です。すなわち少なくとも一つのコピーは、一つの悪い出来事が届かない場所になければならないということです。別のプロバイダー、少なくとも別のリージョン、別の認証情報、別のアカウント――そして、あなたがオフショアでホスティングする理由が技術的なものではなく法的なものであるなら、別の法域も必要です。そうすれば、一通の裁判所命令が両方のコピーに同時に届くことはありません。

この節は、他のバックアップチュートリアルには存在しない節であり、このサーバーの代金をMoneroで支払ったのであれば、最も重要な節でもあります。

インターネット上のどこでも見かけるデフォルトのアドバイスは、バックアップをオブジェクトストレージにpushすることです。Backblaze B2、Amazon S3、Wasabi、rclone経由のGoogle Driveなどです。安価で、耐久性があり、実際に機能します。しかしそれは同時に、たった一つのコマンドで、あなたがこれまでやってきたことの多くを台無しにします。そのアカウントを開設するにはカードと、たいていは身分証明書が必要だったはずです。最初のスナップショットがアップロードされた瞬間から、そのプロバイダーはあなたの名前と支払い情報をあなたのサーバーのIPアドレスに結びつけたタイムスタンプ付きの記録を、毎時間更新しながら、永遠に保持し続けます。あなたは私たちに対して身元を確認したのではありません。あなたは彼らに対して身元を確認し、その二つの間に線を引いてしまったのです。

後半はさらに悪く、しかも人々が見落としがちな部分です。そのアップロードを認可するAPIキーは、本番サーバー上のただのファイルです。そのマシンでrootを奪った者――あるいは合法的にディスクを入手した者――は、あなたのデータを手に入れるだけでは済みません。彼らは、たった一回のAPI呼び出しで課金上の身元にたどり着ける認証情報を手に入れることになります。匿名だったはずのサーバーが、あなたの銀行口座を指し示す道標に変わってしまうのです。

だからといってオブジェクトストレージが間違っているわけではありません。それをデフォルトではなく、一つの意思決定にするというだけのことです。もともとあなたが持っていたものをどれだけ保てるか、その順に並べた三つの逃げ道があります。

• 二台目のno-KYC VPSを、できれば本番とは別の法域に用意し、同じ暗号資産残高から支払います。保存先は元のサーバーが持つ匿名性を打ち消すのではなく、そのまま引き継ぐことになります。これが私たちの実践方法であり、このガイドの残り部分もこれを前提としています。
• 身元確認なしで暗号資産を受け付けるストレージプロバイダー。実在はしますが、規模は小さめです。マーケティングの文句を鵜呑みにする前に、支払い経路が本当に身元不要かどうかを確認し、復元のときになって初めて知ることがないよう、事前にエグレス料金を確認してください。
• 物理的に所有しているマシンで、自宅の回線の裏からWireGuard経由でpullします。匿名性の面では申し分ありませんが、可用性は低く、復元速度が自宅のアップロード速度に縛られることを意味します。三つ目のコピーとしては妥当ですが、唯一のコピーとしては心もとないものです。

どれを選ぶにせよ、バックアップを保持するアカウントは、本番環境を保持するアカウントと認証情報、メールアドレス、リカバリー経路を共有すべきではありません。肝心なのは、一つのログインが侵害されても両方には届かないようにすることです。これは他の場所で身元を分離しておくのと同じ規律を、システムの中で最も地味な片隅に適用しただけのことです。

ほとんどすべてのバックアップチュートリアルは、同じアーキテクチャに行き着きます。本番サーバー上のcronジョブが、リモートのリポジトリに対して認証し、そこへ書き込むというものです。単純で、実際に機能しますが、誰も指摘しない性質を一つ抱えています――本番サーバーがリポジトリ全体を削除できる認証情報を保持しているという点です。古いスナップショットのプルーニングには削除権限が必要なので、あなたの夜間ジョブを実行する鍵は、金庫を空にする鍵でもあるのです。

これが侵害の最中に何を意味するか考えてみてください。マシンでrootを奪った攻撃者は、あなたのバックアップを探し出す必要すらありません。あなたが親切にも、動作する認証情報とリポジトリ名を記したコンフィグファイルを残しておいてくれたからです。何か目に見える行動を起こす前にバックアップを列挙して破壊することは、仮説上の洗練された手口ではありません。標準的な手順です。なぜならそれが、インシデントを交渉の場に変えるものだからです。あなたの夜間ジョブは、いわば偵察だったのです。

設計には三種類あり、その違いはひとえに、どのマシンがどの鍵を保持しているかにかかっています。

単純なpushが、先ほどのものです。本番サーバーが読み書き削除の権限をすべて持っています。便利ではありますが、まさにバックアップが最も必要になる場面で完全に破綻します。あなたが本当に気にかけている脅威が自分自身の指先だけである場合に限って使ってください。

append-onlyなpushは同じ形を保ちつつ、危険な動詞だけを取り除きます。リポジトリは、プロトコルを理解し削除を拒否する仕組みによって提供されます。resticならrest-server --append-only、Borgならauthorized_keysから強制したborg serve --append-onlyです。本番サーバーは新しいスナップショットを作成できますが、古いものを削除することはできません。プルーニングは後で、別の場所から、別の鍵を使って行われます。これはわずか20分ほどの作業で得られる大きな改善であり、たいていの人にとってはここで止めておくのが適切です。

pullは接続の向きを逆転させます。バックアップホストがSSH経由で本番環境に手を伸ばし、必要なものをコピーして、自分自身のディスク上でローカルにバックアップツールを実行します。本番サーバーはバックアップ用の認証情報を一切保持しません――そのマシンには見つけ出せるものが何もないのです。自分のバックアップがどこにあるのかを、そのマシン自身が知らないからです。これが最も強力な構成であり、以下のステップバイステップで組み立てていくものです。

pullの代償についても正直になっておきましょう。タダではないからです。鍵を消し去ったのではなく、移動させただけです。バックアップホストが今度は本番環境へのSSH鍵を保持することになるため、バックアップホストの侵害は稼働中のシステムにまで及びます。それでもこちらの方が良い取引です――バックアップホストは何も稼働させず、SSH以外は何も公開しておらず、公開Webサーバーよりもはるかに小さな標的だからです。とはいえこれも取引であることに変わりはなく、その鍵をファイルの読み取り以外には使えない読み取り専用コマンドに強制することで、残ったギャップの大部分を塞ぐことができます。

三つのツールで、事実上あらゆるケースをカバーできます。フォーラムのスレッドが示唆するほど、悩ましい選択ではありません。

resticはデフォルトで暗号化を行い、スナップショット間で重複排除を行い、SFTP、S3、RESTをはじめ十数種類のバックエンドを話し、どこにでも置ける単一の静的バイナリとして配布されます。リポジトリ形式はコンテンツアドレス方式なので、スナップショット作成は安上がりであり、何台のマシンから送られてきても同一データは一度しか保存されません。コストは実在するものの控えめです。リポジトリのインデックスに比例したメモリを要求しますし、中断された実行は古いロックを残すことがあり、次の実行はrestic unlockで解除するまでそれを乗り越えようとしません。これがデフォルトの推奨であり、以下のステップで使用するものです。

Borgは重複排除と圧縮の性能がより高く、数百万個の小さなファイルを含むリポジトリでは体感できるほど高速です。その代償は結合度の高さです。Borgは両端にインストールしなければならず、バージョンを密接に一致させる必要があり、一つのリポジトリは本来一つのクライアント向けに設計されており、ヘルパー層なしではオブジェクトストレージバックエンドをネイティブには持ちません。バックアップ元が大きなメールスプールや小さなファイルだらけのファイルシステムで、かつ両方のマシンを自分で管理しているなら、Borgは使用容量を半分にしてくれるでしょう。その--append-onlyモードも、両ツールの中でこの発想を最もクリーンに実装したものです。

rsyncはバックアップツールではなく、そうでないふりをすると、壊れたディレクトリを忠実にミラーリングしたコピーが一つできあがるだけです。バージョニングも、重複排除も、保存時の暗号化もありません。rsync --deleteは、あなたの間違いを回線速度でコピー先にも伝播させます。それでもなお、自分が管理する二台のマシンの間でバイト列を移動させる用途には正しいツールであり、それこそがpull構成の中でrsyncが担う仕事です。バイト列が到着した後のバージョニングと暗号化はresticが担当します。それぞれを、それぞれの本分どおりに使ってください。

一つだけやってはいけないことがあります。tarと日付入りファイル名で自前の仕組みを組み立てることです。それは四か月ほどはうまくいきますが、やがて何も期限切れにならないせいでディスクが満杯になる日か、40GBのデータセットを毎晩フルコピーすると月1.2TBものストレージ代を、ほぼ同一のものを30個保持するために払い続けていたと気づく日がやってきます。

本能的には、ファイルシステム全体をバックアップしたくなります。それに逆らってください。ルートファイルシステムの大部分は、90秒で再インストールできるディストリビューションのパッケージであり、それらを含めることはストレージと転送時間、そしてさらに悪いことに注意力を消費します。誰もテストしたがらない40GBのバックアップは、四半期ごとに復元される900MBのバックアップよりも役に立ちません。

本当に再構築できないものは、実はそう多くありません。/etc（あなたの設定一式であり、再構築が週末仕事ではなく1時間仕事で済む理由です）、/homeと/root、/srvと/var/www、/var/lib/や/opt/配下のアプリケーション状態、名前付きのDockerボリューム、あなたが書いたcronとsystemdのunit、そしてデータベースのダンプです。/proc、/sys、/dev、/run、/tmp、/var/cache、スワップファイル、ソケット、そして/var/lib/docker/overlay2は飛ばしてください――最後のものはcomposeファイルから再構築でき、しかもディスク上で単独最大のディレクトリになっていることがよくあります。

ここからが、静かに復元を台無しにする部分です。データベースを稼働させたままデータディレクトリをコピーすると、まず使い物にならないファイル一式ができあがります。エンジンは状態をメモリ上に保持し、順序が重要な形で複数のファイルにまたがって書き込みを行いますが、あなたのコピーはそのツリーを数分かけて歩き回り、異なる瞬間に異なるファイルを捉えてしまいます。InnoDBはそこからクラッシュリカバリーできることもあれば、できないこともあります。その失敗は何か月も経ってから、すでに散々な一日になっている最中の復元作業で表面化します。

代わりにエンジンを通してダンプし、そのダンプをバックアップしてください。

# MariaDB / MySQL — InnoDB gets a consistent snapshot from one transaction
mariadb-dump --single-transaction --quick --routines --triggers --events \
  --all-databases | zstd -T0 > /var/backups/db/all-$(date -u +%F).sql.zst

# PostgreSQL — pg_dump is consistent by design; grab roles separately
pg_dumpall --globals-only > /var/backups/db/globals.sql
pg_dump -Fc -Z6 mydb    > /var/backups/db/mydb.dump

# SQLite — never cp a live database; WAL mode makes that a torn file
sqlite3 /var/lib/app/app.db ".backup /var/backups/db/app.db"

持っておく価値のある補足が二つあります。--single-transactionが保証する整合性はInnoDBに対してのみです――もしまだMyISAMのテーブルが残っていれば、それはトランザクションの外でコピーされ、残りの部分と整合しない可能性があります。そうしたテーブルは変換するかロックしてください。そしてダンプを取るようになったら、稼働中のデータディレクトリはファイルバックアップの対象から除外してください。両方をバックアップするということは、正しいコピーの隣に大きな破れたコピーを保存することになり、将来の復元に、片方がひそかに間違っている二つの候補を与えることになります。

コンテナであっても原則は変わらず、変わるのはパスだけです。docker compose exec -T db mariadb-dump …でダンプを実行し、その下にあるボリュームではなく、結果として得られるファイルをバックアップしてください。

クライアントサイド暗号化こそが、データの出所とは異なるマシンにそれを保存してもよい、唯一の理由です。resticとBorgはどちらも、何かが送信元を離れる前に暗号化を行うため、バックアップホストは暗号文だけを保持することになり、信頼できないストレージとして扱うことができます。この性質の価値は、あなたが鍵をどう扱うかとまったく同じだけの価値しかなく、それ以上ではありません。

この失敗パターンは、うんざりするほどよくあります。リポジトリのパスワードは本番サーバー上の/etc/restic/envに置かれており、それ自体は自動化のために問題なく、むしろ必要なことです。そして、失うのが本番環境そのものになったとき――破壊され、押収され、あるいはアカウントごと消えたとき――あなたは数百ギガバイトの暗号化されたブロックを前にして、鍵の唯一のコピーが、まさに失うことから自分を守ろうとしていたそのものの中にあったのだという事実に、じわじわと気づくことになります。

つまり、サーバー上のパスワードは作業用のコピーであって、記録の正本ではありません。正本は、サーバーが失われても残る場所に置いてください――それ自体が別の場所にバックアップされているパスワードマネージャーの保管庫、あるいは引き出しの中の紙、あるいはその両方です。リポジトリの場所と、その隣に正確な復元コマンドを書き留めておいてください。文脈のないパスフレーズは、18か月後にストレスの中で解くことになるパズルだからです。そして5分だけ時間を取って検証してください。本番とは別のマシンから、パスワードマネージャーの中身だけを使って、そのリポジトリに対してrestic snapshotsを実行するのです。それがうまくいけば、あなたにはバックアップがあります。本番にしか存在しない何かが必要になるなら、あなたが持っているのはとても高価なフォルダにすぎません。

どちらのツールも、一つのリポジトリに複数の鍵を持たせることをサポートしており（restic key add）、これはプルーニングジョブや二人目の管理者に、元のパスフレーズを共有せずにアクセス権を与えるためのきれいな方法です。また、本番のディスクがLUKSで暗号化されている場合は、二つの秘密を本当の意味で分離しておいてください――resticのパスフレーズをLUKSボリュームの中に、LUKSのパスフレーズをresticリポジトリの中に保存してしまうと、両側とも締め出されて開かなくなるループになります。

保持期間は、一見ストレージコストの問題に見えますが、実際には検知までの遅延の問題です。重要な数字は、どれだけディスクを費やしたいかではなく、あなたのシステムの中で問題がどれだけ長く気づかれずにいられるかです。その期間がどれほどであれ、あなたの最も古いバックアップは、それより古くなければなりません。

7日分の日次スナップショットは、一見十分なようでいて、実際には心もとないものです。誰もクエリしない壊れたテーブル、誤動作するcronジョブによる緩慢な削除、何か目に見えることをする前に1か月静かに潜んでいた侵入――これらはどれも、表面化するまでに1週間より長くかかるのが常であり、あなたの履歴が7日分しかなければ、保持しているスナップショットはすでにすべて汚染されていることになります。実際の侵入における滞留時間は、日常的に数週間単位で計測されます。安価な月次スナップショットは、まさにそれに対する防御であり、重複排除のおかげで実に安上がりです。1年分保持する月次スナップショットが追加で消費する容量は、フルコピー1個分のごくわずかな割合にすぎません。実際に変化したブロックだけが二重に保存されるからです。

restic forget \
  --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 2 \
  --prune

この階段状の構成――1週間分の日次、1か月分の週次、1年分の月次、数年分の年次――は、スナップショットにしておよそ26個であり、典型的なデータであればフルコピー1個分の2倍を大きく下回ります。特別な理由がない限り、これをデフォルトとして推奨します。

運用上の注意点が二つあります。--pruneを伴わないforgetはラベルを削除するだけなので、プルーニングするまで容量は解放されません――これは、いつまでも縮まらないディスクを眺めている人を驚かせます。そして--pruneにはリポジトリへの削除権限が必要なので、append-onlyやpullの構成では本番サーバー上では実行されません。実行されるのはバックアップホスト上、あるいはあなたのノートパソコンからであり、本番サーバーが一度も目にしたことのない鍵を使います。この分離こそが肝心な点です。最後のステップで、利便性のためにそれを台無しにしないでください。

典型的なバックアップの大惨事とは、クラッシュするジョブのことではありません。動かなくなったのに誰にも知らせず、11か月後にそれを必要とした誰かによって発見されるジョブのことです。以下の要素はすべて、まさにその結末を起こりえなくするために存在しています。

cronではなくsystemdタイマーを使ってください。終了ステータス付きの本物のログがジャーナルに残り、Persistent=trueにしておけば、マシンの電源が落ちていた間に逃した実行は、永遠にスキップされるのではなく次回起動時に行われます。そしてRandomizedDelaySecにより、大量のマシンが03:00ちょうどにバックアップホストへ殺到することもありません。cronの失敗通知はローカルのメールボックス宛のメールであり、現代的なサーバーではまさにどこにも届きません。

# /etc/systemd/system/backup.timer
[Unit]
Description=Nightly encrypted backup

[Timer]
OnCalendar=*-*-* 03:17:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target

次に、デッドマンスイッチを追加してください。これは、このガイド全体の中で単独では最も価値の高い一行です。スクリプトのまさに末尾で――バックアップが成功した後に、前にではなく――毎日連絡があることを期待し、なければ警告するモニターに対してHTTPSリクエストを送ります。これは通知のロジックを反転させます。失敗がメッセージを生成することに頼るのではなく、不在そのものが警報になるのです。3日間動いていないジョブは、危機的状況での発見ではなく、あなたの受信箱の中の一通のメッセージになります。サードパーティのアカウントをこれ以上作りたくなければ、モニター自体をバックアップホスト上でセルフホストしてください。数行のコードと、それ自身のタイマーがあれば済みます。

最後に、私たち自身が少なくとも一度はぶつかったことのある、小さな運用上の落とし穴です。中断された実行はロックを残し、以降のすべての実行は、4日目の夜以降はもう読まなくなるメッセージとともに失敗し続けます――restic unlockは反射的にではなく、意図的に扱ってください。保存先のディスクが満杯になれば、誰かが気づくまですべてのジョブが失敗します。ジョブの状態だけでなく、空き容量についても警告してください。有効期限の切れたSSH鍵、ローテーションされたホスト鍵、関係のない作業中に追加されたnftablesのルール――そのどれもが、pullを静かに断ち切ります。そしてstartだけでなくsystemctl enable --nowを使ってください。一度も有効化されなかったタイマーは、最初の再起動までは見事に動作し、その後は二度と実行されません。

ここまで述べてきたことはすべて準備にすぎません。これをバックアップへと変える部分であり、ほとんど誰もが省略してしまう部分です。

四半期に一度、新しいVPSをデプロイしてください――5ドルのStarterプランで十分であり、料金は時間単位で秒割りなので、この演習全体でかかるのはわずか数セントです。実際の災害時に手元にあるはずのものだけを使って、そこへ復元してください。リポジトリのアドレス、パスワードマネージャーに入っているパスフレーズ、そして書き留めておいた手順です。本番環境にあるものは意図的に一切使わないでください。あなたがリハーサルしているシナリオでは、本番環境は存在しないことになっているからです。アプリケーションを起動し、hostsファイルのエントリーを新しいIPに向け、実際にクリックして回ってください。それが済んだら破棄してください。

# on a throwaway machine, with nothing but the passphrase
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/prod
restic snapshots                      # can you even see the history?
restic restore latest --target /restore
restic check --read-data-subset=10%   # verify stored blocks, not just metadata

これが捕まえてくれるものは、決してあなたが予想したものではありません。includeリストがカバーしていなかったディレクトリにあった設定ファイル。パスワードが変更されたのにスクリプトが終了ステータスをチェックしていなかったせいで、5週間もの間ゼロバイトのままだったデータベースダンプ。オーケストレーターが保持する環境変数にシークレットが存在し、ファイルシステム上にはそもそも一度も存在しなかったせいで起動しないアプリケーション。文書化されていないDNSレコード。443番ポートが何か応答する前に再発行しなければならない証明書。そのどれもが、静かな午後であれば10分で直せるものであり、朝の3時であれば見苦しい2時間になるものです。

この訓練が最初から最後までどれだけかかったかを書き留めてください。その数字こそが――バックアップの頻度ではなく――あなたの本当の復旧時間であり、どれだけ止まるのかと聞かれたときの唯一の誠実な答えです。restic check --read-data-subset=5%も月次タイマーに加えてください。インデックスだけでなく、実際に保存されたブロックのローテーションするサンプルを読み込んで検証してくれるので、まだ頼れる良いコピーが残っているうちに、静かな破損を発見できます。もしいつかサーバー全体を新しいホストへ移行することになれば、リハーサル済みの復元は、その移行作業の大部分をすでに終わらせてくれているということでもあります。