独立系サイトのデータバックアップ：データベース・ファイル・設定のバックアップ戦略と遠隔地保管

独立系サイトのデータバックアップ：データベース・ファイル・設定のバックアップ戦略と遠隔地保管

一、なぜ「丸ごと1本取れば済む」わけではないのか

多くのサイト運営者のバックアップ戦略は「毎日サーバー全体を固めて保存する」というものです。聞こえは堅実ですが、実際には3つの問題があります。

第一に、丸ごとのパッケージは大きすぎて、1回のバックアップに何時間もかかり、差分を細かく取れません。第二に、3つの資産の変化頻度は大きく異なります。データベースは毎時変わりますが、ファイルはたまに変わり、設定は数か月動きません。同じ頻度で取ると、無駄になるか足りなくなるかのどちらかです。第三に、丸ごと復旧するとゴミファイルやマルウェアを仕込まれたコードまで一緒に戻り、事故ごと復旧することになります。

ここでの直感に反する判断はこうです。バックアップの価値は「どれだけ取ったか」ではなく、「復旧できるか、どれだけ速く復旧できるか」で決まります。「毎日バックアップしている」サイトを数多く見てきましたが、いざサーバーが落ちた日に、バックアップファイルが壊れている、パスワードが分からない、遠隔地の分は一度も転送に成功していない、といった事態に気づくのです。

バックアップ戦略の合格基準はただ一つです。そのバックアップを新品のマシンに持って行き、4時間以内にサイトを動かせるかどうか。これがサイトのバックアップと復元演習が「復旧可能性の検証」を強調する理由です。

二、データベースのバックアップ：フルと差分で、RPOを1時間以内に抑える

データベースは3つの資産の中で最も重要で、失ってはいけないものです。戦略は「全量＋増分」です。毎日未明に論理フルバックアップ（mysqldumpまたは同等のツール）を1回実行し、binlogを有効にして毎時増分を取ります。これなら最悪でも直近1時間分のデータしか失いません。この指標をRPO（目標復旧時点）と呼びます。

必ず押さえるべき点が2つあります。1つ目は、フルバックアップは業務のピーク時間帯を避け、未明3時から5時に行うこと。2つ目は、バックアップファイルの完全性を検証することです。「ファイルが生成された」だけで安心せず、一時データベースへ復元してサンプル検証してください。そうしないと、ある時点からバックアップファイルが壊れている可能性があります。データベースの容量が大きくなると論理バックアップは遅くなるため、その段階で物理バックアップやクラウドデータベース標準の自動バックアップを検討します。

シナリオ例：午前4時にデータベースの注文テーブルが誤って削除されました。復旧手順は、まず前日未明のフルバックアップを一時データベースへ復元し、次に前日4時以降から事故直前までのbinlogを再生します。これでデータベースは事故の1分前の状態に戻ります。所要時間は約1時間で、損失を最小限に抑えられます。

三、ファイルと設定：分けてバックアップし、データベースバックアップに混ぜない

ファイル（ユーザーがアップロードした問い合わせ添付、製品画像、メディア）は容量が大きく変化が遅いため、毎日のデータベースバックアップに含めるのは不向きです。増分同期ツールを別途使い、アップロードディレクトリを遠隔のオブジェクトストレージへ毎日1回同期すれば十分です。画像や動画のような大きなファイルの管理については、次を参照してくださいメディア資産の管理。

設定とコードは最も見落とされがちです。多くの人はデータベースのバックアップは完璧でも、Nginxの設定、プラグインのバージョン、環境変数がサーバーのあちこちに散らばっていることを忘れています。再インストール後に元の動作を再現できません。

正しい方法は、コードと設定をすべてGitのバージョン管理に入れ、環境変数とシークレットは別途パスワードマネージャーに保存し、Gitには入れないことです。これで設定は「バックアップ」するものではなく、変更のたびにバージョンが残り、いつでも任意の過去の状態に戻せます。

四、遠隔ストレージ：3-2-1原則の実践方法

3-2-1 はバックアップの世界では昔からある原則ですが、ひとり運用のチームは前半だけで終わりがちです。本来の意味はこうです。データを 3 つのコピーで保持し、2 種類の異なる媒体に保存し、そのうち 1 つを別の場所に置く。「別の場所」で大事なのは「別のハードディスク」ではなく、「同じ事故で一緒に失われない場所」だという点です。

これを 1 台のクラウドサーバーで実践すると、こうなります。ローカルディスクに直近のバックアップを 1 つ残し（復旧が最速）、サーバーがあるデータセンターにも 1 つ、さらに別の都市のオブジェクトストレージへ 1 つ転送します。同じアカウント・同じリージョンのブロックストレージのスナップショットは、本当の意味での別の場所とは言えません。データセンターが火事になったり、アカウントがロックされたりすれば、それらは一緒に失われます。別の場所のコピーは最低 30 日保持し、半年ほど前の長期アーカイブを月 1 回残しておけば、ランサムウェアに古いバックアップまで暗号化されるのを防げます。

シナリオ例：サーバーがランサムウェアに暗号化されました。ローカルのバックアップもサーバー上のバックアップも暗号化されましたが、別の都市のオブジェクトストレージにある 30 日前のコピーはオフラインで、暗号化ソフトの手が届きません。このコピーで新しいマシンに復元すれば、失うデータは最大 30 日分で、サイトは残ります。

これが別の場所のコピーの意義です。より速く復旧するためではなく、「すべてのオンラインコピーが失われた」ときに 1 つだけ残るためです。攻撃を受けた後のクリーンアップ手順はこちらサイトが攻撃を受けた後。

5. 落とし穴：バックアップで最もよくある 4 つの偽りの安心

1 つ目の落とし穴は「バックアップが同じマシン上にある」ことです。バックアップファイルをサーバーの別のディレクトリに置いても、サーバーが落ちたり削除されたりすれば、2 つとも一緒に失われます。バックアップはこのマシンの外に出す必要があります。2 つ目の落とし穴は「復元検証を一度もしない」ことです。スクリプトは毎日バックアップ成功と表示していても、実際に復元したことがなければ、半年前から壊れていた可能性が十分あります。

3 つ目の落とし穴は「データだけバックアップして設定をバックアップしない」ことです。データベースは復元できても、使っていたプラグインのバージョンや Nginx の設定を思い出せず、サイトは動きません。4 つ目の落とし穴は「バックアップにアラートがない」ことです。バックアップスクリプトが 3 週間こっそり止まっていても誰も気づかず、復元が必要になった日に空だと分かります。バックアップタスクには失敗アラートを必ず設定し、2 日連続で成功しなければ通知が届くようにしましょう。

FAQ よくある質問

最後に

データバックアップは自己満足に陥りやすい。スクリプトは動き、ファイルは保存され、見た目は安全だ。しかし本当の検収は復元のその一度だけ。個人運営の独立サイトなら、3種類の資産を分けて備え、3-2-1で遠隔地にコピーを残し、四半期ごとに復元訓練を1回行う。この流れは半日で組み終わり、あとは毎日自動で走らせ、週に一度アラートを確認するだけだ。

実行は3ステップ。第一に、データベースは毎日フルバックアップと毎時増分バックアップを行い、目標RPOは1時間。第二に、ファイルと設定を分け、ファイルは毎日遠隔地のオブジェクトストレージへ同期し、コードと設定はGitで管理する。第三に、四半期ごとに復元訓練を1回行い、4時間以内に収まるか計測し、バックアップタスクには失敗アラートを設定する。

この3ステップを終えれば、サーバー障害に立ち向かう自信は「バックアップが正常であってほしい」から「半日以内に確実に復旧できる」へと変わる。メンテナンスのリズムは次と照らし合わせて公式サイト保守期間一緒に並べよう。

覚えておきたい一言。バックアップとはファイルを複製することではなく、あなたのサイトに「トラブルが起きてもやり直せる」という保険をかけることだ。保険金請求の訓練をしていない保険証券は、紙切れと同じである。