確実に復元できるVPSバックアップ

バックアップ戦略が試されるのは、サーバーが死んだその夜ではない。実際に試されるのはその数週間前、誰も書き留めない3つの静かな決断の中でだ。コピーをどこに置くか、それを削除できるのは誰か、そして誰かが実際にそれを読み戻したことがあるか。

本人確認を一切求めないホスティングは、その引き換えに何かを手放している。それを正直に言うべき場所がここだ。電話をかけられるアカウント担当者はいないし、消去済みボリュームを復活させるチケットも存在しない。当社の保持ポリシーはその理由をはっきり述べている。サーバーデータは解約から24時間以内に破棄され、ディスクはフォーマットではなく暗号学的に消去され、バックアップは一切保持されない。これは、このプラットフォームを購入する価値がある性質と、裏表の関係にある。悪い夜のあとに取り戻したいものは、すでにどこか別の場所にあるべきで、そこに置くのはあなた自身だ。

サーバーを実際に壊すもの

想像しているような形でサーバーを失う人はほとんどいない。壊滅的なハードウェア障害は実在するが稀であり、優れたホストならすでに対策済みのケースだ。実際に起きる損失はもっと地味で、それぞれが異なる種類のコピーを無力化する。だからこそ「バックアップはあります」は、そのどれに耐えるかを言うまでは答えになっていない。

この表は不安のリストではなく、チェックリストとして読んでほしい。同じマシン内の2台目のディスクへの毎晩のコピーは、1行目にしか答えない。同じパネル内のスナップショットは1行目と2行目に答える。サーバーが手を出せない場所に置かれ、なお手元にある鍵で守られたコピーだけが、5行すべてに答える。

スナップショットはバックアップではなく、ホストもバックアップ係ではない

スナップショットは得意なことに関しては優秀だ。失敗したアップグレードを、転送なしで数秒でロールバックできる。できないのは、サーバーそのものを奪った出来事を生き延びることだ。同じプロバイダー、同じアカウント、同じ請求トークン、同じ国、しばしば同じストレージクラスタと、あらゆる障害ドメインを共有しているからだ。スナップショットが守ってくれるのは自分自身からであり、バックアップが守ってくれるのはそれ以外のすべてからだ。

この区別は、一般的なホストよりもここでは重要になる。通常のセーフティネットが意図的に取り除かれているからだ。顧客のサーバーに誰もログインしないので、あなたのバックアップジョブが3月から失敗し続けていても誰も気づかない。アカウントに紐づく本人確認情報がないので、「本人であることを証明すれば復元します」という人力の道も存在しない。そして解約は文字通り終わりを意味する。残高切れはデータ消失イベントであって、単なる請求イベントではない。

3-2-1ルールを、身分証を見せたことがない人向けに書き換える

古典的なルールは、2種類のメディアに3つのコピーを持ち、そのうち1つはオフサイトに置けと言う。これはテープと回転式ディスクの時代に書かれたもので、「メディアの種類」という条項はいつの間にか意味を失っている。本番のディスクもNVMe、バックアップ先のディスクもNVMeで、それを「2種類のメディア」と呼ぶのは自分に言い聞かせているだけの話だ。残す価値がある条項は距離についてのものであり、オフショアインフラにとって距離はキロメートルでは測れない。

これを3つのコピー、2つのプロバイダー、2つの法域と書き換えよう。両方のコピーを同時に奪う障害は、物理的なものであることはほとんどない。アクセスを失ったアカウント、調子の悪い週を過ごしたプロバイダー、ある国には及ぶが別の国には及ばない法的手段、といったものだ。同じラックの2台のサーバーは、余計な手間がかかる1つのコピーにすぎず、同じ法制度下の2台のサーバーもほとんど変わらない。法域選びのガイドでは、最初の法域と同じリスクを単純に映さない2つ目の選び方を扱っている。

実際には、これは安上がりだ。バックアップ先にコア数は要らず、ネットワークすらほとんど要らない。必要なのはディスクとアドレスだけだ。最小のVPSプランでも、7つのロケーションのうち本番とは別の場所で使えば、resticやBorgの保存先として十分な性能になる。テラバイト単位のアーカイブなら、実ドライブを積んだ専有サーバーのほうが、どのオブジェクトストレージよりもテラバイト単価が安い。データが本当に大きく、めったに読み出されない場合、経済性は大差でベアメタルに軍配が上がる。

本番環境では正しくできているのに、バックアップ先では間違えがちなことが一つある。同じ方法で支払うことだ。自分の名前のカードで買った2台目のサーバーは、1台目から苦労して切り離した身元情報を静かに再び結びつけてしまい、しかもそこには全データの完全なコピーが置かれる。本番機の支払いをMoneroで行っているなら、バックアップ機にも同じ扱いがふさわしい。

3つ目のコピーは、ほとんどの人が省略してしまうものであり、しかも遠隔障害をすべて同時にかわせる唯一のコピーだ。物理的に手元に持ち、たまに更新し、オフラインで保管するディスクである。月に1回で十分な人がほとんどだろう。コーヒー1杯分の手間で済み、他の2つが共有してしまうシナリオを生き延びるコピーになる。

プッシュ型・プル型、そして一晩の事故で両方のコピーを失う間違い

ほぼ誰もが最初に組む構成はこうだ。本番サーバー上のジョブが毎晩動き、バックアップ先の鍵やトークンを保持し、接続してプッシュする。これは機能するしシンプルだが、サーバーの人生で最悪の日にだけ姿を現す性質を持っている。本番機を制御できる者は、バックアップも制御できる。

これは仮定の話ではない。名乗り出る前に被害者のバックアップを削除または暗号化するのは、これを商売にしている者にとって標準的な手口だ。認証情報はcronジョブや環境ファイルの中に置かれていて、見つけるのに1分もかからない。攻撃者が削除できるコピーは、2つ目のコピーとは呼べない。それは遅延付きの1つ目のミラーにすぎない。

すっきりした解決策が2つあり、どちらもすでに済ませているはずの基本的な堅牢化とよく組み合う。

• 追記専用の保存先にする。主要な2つのツールはどちらも、クライアントがデータを追加できるが削除はできないモードを備えている。Borgは保存先のSSH鍵をborg serve --append-onlyに固定することで、resticは--append-only付きで起動したRESTサーバーでこれを実現する。本番サーバーは毎晩書き込むだけで、構造的に履歴を破壊できない。古いスナップショットの削除はその後、本番機が開始できないセッションの中で保存先側が行う。
• プッシュではなくプルにする。方向を逆転させる。バックアップ側のホストが本番に接続し、読み取り、保存する。本番側は保存先の認証情報を一切持たないので、盗む対象が存在しない。本番側で使う鍵はrestrictと強制的なcommand=で制限し、盗まれたバックアップ用の鍵がシェルに化けないようにする。

プル型はより強固なモデルだが運用の手間はやや増える。追記専用は、すでにBorgかresticを使っているならほぼ無料で実現できる。どちらの方法でも、「攻撃者にバックアップを消された」は結果ではなく未遂に変わる。このガイドから一つだけ持ち帰るなら、この節にしてほしい。

まず送信元で暗号化し、それから鍵を誰が持つかを決める

本格的なツールはどちらも、何かがネットワークを渡る前に、バックアップ対象のマシン上で暗号化する。保存先には解読できないブロブが保存される——これこそがプロバイダーをまたいだコピーを安全にしている理由だ。2台目のホストは信頼できる必要も、友好的である必要すらなく、到達可能でディスクさえあればいい。この一つの性質だけで、「まったく知らない国にあるサーバー」がリスクからインフラへと変わる。

これはサーバー自身のディスクを暗号化するのとは異なる仕組みで、答える問いも違う。当社のVPSでのフルディスク暗号化ガイドでは、マシンが稼働している間にディスク暗号化が何を守り何を守らないかを扱っている。バックアップの暗号化のほうが簡単で価値も高い。脅威モデルが素直だからだ。データは静止状態にあり、自分が制御していないハードウェア上にあり、鍵はそこには決して渡らない。

その結果、リスクはすべて鍵の管理に集約される。パスフレーズは今や唯一の完全喪失ポイントであり、それは人が思う以上にたちの悪い単一障害点だ。失うことが静かに起きるからだ——何も壊れず、バックアップは動き続け、まさに必要になった瞬間にそれと気づく。これを直す習慣は3つある。

• パスフレーズはサーバー上ではrootだけが読めるファイルとしてのみ保持し、--password-fileで参照する。プロセス一覧やシェル履歴に決して現れないようにするためだ。
• 人が読める形のコピーを、関係するすべてのマシンの外に保管する。引き出しの中の紙は、自分もアクセスを失うかもしれないアカウントに同期するパスワードマネージャーより、実際に優れている。
• リポジトリに2つ目の鍵を追加する——restic key add、あるいはエクスポートしたBorgの鍵など。これにより、パスフレーズを一つ忘れても不便で済み、アーカイブの終わりにはならない。

この3つすべての土台にあるルールはこうだ。鍵の唯一のコピーが、そのバックアップが置き換えるはずのマシン上にしかないなら、それはバックアップではない。それはただの暗号化されたブロックの山であり、それについての物語にすぎない。

ツール選び、一枚の表で

ツールの選択は、接続の方向や鍵の状態ほど重要ではない。だからこそこの節は1番目ではなく6番目に置いている。とはいえ違いは確かに存在し、用途に合わない形を選ぶと後で余計な作業が発生する。

単一サーバーなら、2台目のVPSへのresticが正解への最短ルートだ。シードボックスやメディアアーカイブ、似たような大きなファイルが多い用途では、Borgの重複排除がディスクの空き具合を大きく左右する——その種のワークロードのストレージ面についてはシードボックス構築ガイドで詳しく扱っている。

動いているものはファイルではない

世界で最もよくある壊れたバックアップは、稼働中のデータベースをそのままファイルコピーしたものだ。エラーもなく完了し、サイズも妥当で、それなのに復元するとエンジンが開こうとしないテーブルになる。コピーが通過した瞬間、データベースは書き込みの途中だった。保存されたのは、ページがめくられている最中の写真にすぎない。

抜け出す方法は3つあり、手間の順に並べるとこうなる。ダンプする——mysqldump --single-transactionは書き込みをロックせずに一貫性のあるInnoDBダンプを得られ、pg_dumpはPostgreSQLで同じことをする。スナップショットを取る——ファイルシステムを凍結するか、LVMやZFSのスナップショットを取り、そのスナップショットからコピーして解放する。これは、毎晩ダンプするには大きすぎるデータセットの扱い方だ。あるいは止める——小規模なサービスなら、04:00の2分間のダウンタイムは十分に立派な一貫性戦略であり、しかも例外ケースが一切ない唯一の方法だ。

同じ論理はデータベースの先にも及ぶ。コンテナの書き込み可能レイヤーは使い捨てだが、そのボリュームはそうではなく、隣にあるdocker composeファイルと環境変数も同様だ。データは復元できても定義が復元できないバックアップは、記憶を頼りにスタックを再構築する羽目になる。メッセージキュー、永続化を有効にしたRedis、MTAが書き込み中のメールスプールも、すべて同じ扱いに値する。静止させるか、スナップショットを取るか、ダンプするか。決して、そのままコピーして無事を祈ってはいけない。

何をバックアップすべきか、そして誰もが忘れる部分

ほとんどの人は明らかなペイロード——データベースとアプリケーションディレクトリ——だけをバックアップし、残りは緊急事態の中で手作業で再構築する。時間を食うのはその再構築だ。正しいデータの山ではなく、動くシステムに戻してくれるバックアップには、地味な層が含まれている。

• /etc一式に加え、自分で書いたsystemdのユニットとタイマー、そしてその外にあるすべてのcrontab。
• TLS証明書とその秘密鍵、少なくともACMEアカウント鍵。これがあれば証明書はゼロからではなく更新で済む。
• ファイアウォールルールとパッケージ一覧。この2つを合わせると、記憶に頼るよりも速くマシンの形を再現できる。
• アプリケーションのシークレットと環境ファイル——意図的にコードリポジトリから除外されているため、他のどこにも存在しないもの。
• テキストとしてエクスポートしたDNSレコード。逆引きDNSやPTRエントリも含め、これらはサーバー上ではなくプロバイダー側にある。

試したことのない復元は、噂話にすぎない

バックアップソフトウェアは自分自身について報告するが、正直に報告しているのは違うことについてだ。「スナップショット完了」が意味するのは、リポジトリにデータが書き込まれたということだけだ。そのリポジトリが、これとは別のマシンで、11か月前に何を設定したか覚えていない人間によって読み出せるかどうかについては、何も語っていない。

まずは安価な整合性チェックから始めよう——定期的なrestic check --read-data-subset=5%やborg check --verify-dataだ。ただし、これらが検証するのはアーカイブであって、あなたがそれを使いこなせるかではない、と理解しておくこと。本当の訓練は違うもので、一度だけ午後をまるごと使う。普段使わないロケーションで、時間課金の新品サーバーを注文する。リポジトリのアドレスとパスフレーズ、そして自分のメモだけを頼りにそこへ復元する。サービスを立ち上げる。全体の所要時間を計る。それからマシンを破棄する。総費用は数ドル、そしてこれだけが信頼できる数字を生む唯一の演習だ。

この訓練が確実にあぶり出すのは、データそのものではない。誰も書き留めなかった不足パッケージ、バックアップ対象のパス外にあった設定、置き換えようとしているサーバーのシェル履歴にしか存在しなかったパスフレーズ、そしてリポジトリの形式を読めるツールのバージョン。そのどれもが、事前なら直すのは簡単で、障害中に発見するのは悲惨だ。

この訓練が与えてくれる2つの数字を書き留めておこう。復元にかかった時間と、そのスケジュールで失いうる作業量だ。それがバックアップポリシーそのものであり、それ以外はすべて、その2つに奉仕する実装の細部にすぎない。

ずっと動き続けるように自動化する

ジョブはcronではなくsystemdタイマーから実行しよう。ログが一箇所にまとまり、最後の実行についての本物の記録が残り、再起動を生き延びるスケジュールが手に入る——これらはどれもcronが余計な作業なしには与えてくれないものだ。パスフレーズはユニットファイル自体には置かないこと。シェルアクセスさえあれば誰でもsystemctl catでそのまま読めてしまう。

次に、実際に人を苦しめる失敗モードを解決しよう。それはエラーではなく、沈黙だ。6週間前に止まったバックアップは、完璧に動いているバックアップとまったく同じに見える。どちらも出力を何も生まないからだ。失敗ではなく、不在にアラートを出す。ジョブには成功時に監視サービスへpingを送らせ、そのpingが届かないときに監視サービス側が文句を言うようにする。そしてその監視サービスは、見張っている対象のサーバー以外のどこかに置く。落ちているマシンは、自分が落ちていることを報告できないからだ。

保持期間はデフォルト任せではなく意図的に設定しよう。--keep-daily 7 --keep-weekly 4 --keep-monthly 6のようなものなら、今夜気づくミスも春になって気づく破損も、永遠に肥大化することなくカバーできる。追記専用にしているなら、削除は保存先側で行う。それこそが追記専用にした意味だ。当社のネットワークでは転送量が制約になることはめったにない——帯域は全プランで無制限だ——のでクォータではなく一貫性を基準にスケジュールを組み、その時刻を自分の静かな時間帯と照らし合わせよう。この周辺のより広い習慣についてはサーバーOpSecガイドで扱っている。

要約

このページから何か一つだけ実行するなら、だいたいこの順番で次の6つをやってほしい。

• 1つのコピーを、2つ目のプロバイダー、2つ目の法域に置き、1台目と同じくらいプライベートな方法で支払う。
• そのコピーを追記専用にするか、保存先側からプルする形にし、侵害されたサーバーがそれを破壊できないようにする。
• ツールに送信元で暗号化させ、鍵は関係する両方のマシンの外に保管する。
• データベースはダンプし、動いているものは止めるかスナップショットを取る。稼働中の状態を決してそのままコピーしない。
• 身元に関わる鍵は別に分けてバックアップする——オニオン、WireGuard、DKIM、ノードのシードなど。これらは再生成できない。
• 使い捨てのサーバーへ一度復元してみて、時間を計り、何が足りなかったかを書き留める。

これらのどれも特別なものではなく、週末をまるごと使うようなものでもない。プロジェクトを終わらせてしまう類の損失に対して、必要なのは設定に半日と訓練を一度だけだ。あなたについて意図的に何も残さないプラットフォームでは、自分自身が作ったコピーだけが唯一存在するものになる——それがこの仕組みの代償であり、公平な代償でもある。最初の法域とは違う場所で2台目のサーバーを立ち上げ、今夜のバックアップに行き先を用意しよう。