独立サイトのバックアップ戦略：フル・増分、頻度、保存先、リストア演習

独立サイトのバックアップ戦略：フル・増分、頻度、保存先、リストア演習

1. 何をバックアップするか：データベースとファイルは分けて備える

独立サイトのバックアップで備えるものは2種類、データベースとファイルです。データベースはWordPressのwp_posts、wp_options、wp_usersなどの内容で、ファイルはwp-content/uploads内の画像、テーマ、プラグインのコードです。2種類は変化する頻度もバックアップ方法もまったく違うため、まとめて備えると問題が起きます。

データベースはmysqldumpまたはwp-cliでエクスポートし、毎回–single-transactionを付けてテーブルロックで本番に影響が出ないようにします。ファイルはrsyncで増分同期し、変化した部分だけを同期します。毎回フルコピーは避けてください。10GBのwp-contentディレクトリなら、フルコピーは1回十数分かかりますが、増分同期は数秒で済みます。

シナリオ例：WordPressを使った産業機器の海外展開サイトで、毎日3〜5件の問い合わせと2〜3枚の製品画像が増えます。データベースはスクリプトで4時間ごとにエクスポートし、ファイルは毎日午前3時にrsyncで遠隔地のオブジェクトストレージへ増分同期します。1週間でデータベースのバックアップは約500MB、ファイルの増分バックアップは約200MB、ストレージ費用は月20元未満です。この構成は有料のバックアッププラグインより信頼できます。

バックアップスクリプトの書き方は、環形山テックスタックの自動運用の考え方と同じです。GUIプラグインに頼らず、cronとスクリプトを使い、失敗したらアラートを送ります。

2. 頻度と保持方針：バックアップは頻繁ならよいわけではない

直感に反する判断だが、バックアップは頻度が高ければ高いほど良いわけではない。頻繁すぎるとストレージとIOを大量に消費し、復元時にかえって混乱する。似たようなバックアップが山ほどあって、どれがクリーンなのか分からなくなるからだ。適切な頻度は業務の変化速度で決める。データベースは4時間ごと。問い合わせはいつ来るか分からないからだ。ファイルは毎日1回。画像アップロードは頻繁ではないからだ。

保持ポリシーは祖父・父・子の3層で設計する。日次バックアップは30日、週次バックアップは12週、月次バックアップは12か月、年次バックアップは3年保持する。これなら昨日誤って削除した記事も、半年前に攻撃を受ける前のクリーンな状態も復元できる。

シナリオ例:海外向けサイトで3月15日の午後、データベースに悪意ある内容が注入された。binlog増分バックアップがあれば、データベースを3月15日の正午12時、つまり攻撃発生前の状態に復元できる。失うのは半日分の問い合わせ記録だけだ。日次完全バックアップしかなければ、3月15日の午前3時にしか戻せず、丸1日分の問い合わせを失う。これが4時間増分と日次完全の違いだ。

三、保存場所:3-2-1原則、遠隔地は必須条件

3-2-1バックアップ原則とは、重要データの複製を3つ保持し、2種類の異なる媒体に保存し、そのうち1つを遠隔地に置くという意味だ。これは理論ではなく、数え切れないランサムウェア事件から導き出されたものだ。実際の事故では、攻撃者はサーバーを暗号化すると同時にローカルバックアップも暗号化する。バックアップとサイトが同じマシン上にあるからだ。

3層ストレージの選び方。第1層はローカルバックアップで、サーバーの別ディスクパーティションに置く。復元は最速だがリスク耐性は最も低い。第2層は遠隔地のオブジェクトストレージで、AWS S3やAlibaba Cloud OSSを使う。アベイラビリティゾーンをまたいで冗長化され、1台のサーバー障害では止まらない。第3層はコールドアーカイブで、S3 GlacierやOSSアーカイブを使う。安価だが復元は遅く、年次コンプライアンスと長期保管に使う。

逆説的な注意点：バックアップファイルはwebディレクトリに置かないこと。多くの人がwp-content/backup/にバックアップを置き、コピーが増えたと安心していますが、実際には攻撃者がこのパスをスキャンして直接ダウンロードし、データベース名やテーブル名がすべて漏洩します。正しい方法は、バックアップファイルをwebルートの外に置くか、バックアップ完了後に自動でオブジェクトストレージへアップロードしローカルコピーを削除することです。攻撃を受けた後のクリーンアップ手順はこちらサイトが攻撃を受けた後。

とCDNグローバル高速化併用時の注意：CDNキャッシュはバックアップではありません。静的コンテンツをエッジノードに複製しているだけで、オリジンサーバーが落ちればCDNキャッシュも期限切れになります。CDNキャッシュを災害復旧策と考えないでください。

四、復旧訓練：四半期に一度、バックアップが本当に使えるか検証する

バックアップ戦略で最も見落とされがちなのが復旧訓練です。多くの企業がバックアップスクリプトを一年間動かし続けても一度も復旧したことがなく、いざという時にバックアップファイルの破損、解凍パスワードの失念、復旧手順がそもそも動かないことに気づきます。実際の事故では、バックアップ復旧の失敗の40%以上がこの3つの原因です。

復旧訓練のやり方：四半期ごとにメンテナンスウィンドウを選び、遠隔地のオブジェクトストレージから最新のバックアップを取得し、まったく新しいテスト環境に復旧して「ファイル復旧、データベースインポート、nginx設定、サイトアクセス、問い合わせフォーム送信の検証」の全工程を実行します。所要時間を計測し、実際のRTO（目標復旧時間）とRPO（データ損失量）を記録します。具体的なRTO/RPOの決め方はこちら独立サイトの災害復旧とRTO/RPOの定義。

シナリオ例：あるチームが半年間復旧訓練を行わず、サーバーのハードディスクが壊れてから遠隔地のバックアップを取得したところ、解凍の途中でエラーが発生——なんと3ヶ月前のバックアップスクリプトのgzipパラメータが間違っており、その後2ヶ月分のバックアップはすべて破損ファイルでした。最終的にそれより前のクリーンなバックアップから復旧するしかなく、2ヶ月分のコンテンツを失いました。このような事故は四半期ごとに復旧訓練を一度行うだけで事前に発見できます。

バックアップ監視の設定方法はこちらサイト監視とアラート：バックアップタスクの失敗時は企業WeChatにアラート、バックアップファイルサイズの急減時はアラート、バックアップの経過時間が24時間を超えたらアラートを送信します。日常メンテナンスのチェックリストはこちら公式サイト保守で毎月やる6つのこと。

FAQ よくある質問

最後に

バックアップで最も避けたいのは「プラグインを入れたからもう安心」という思い込みです。プラグインは毎日動き、バックアップファイルは毎日生成されますが、一度も復元したことがなければ、いざというときにバックアップの破損、パスワードの紛失、手順の不通に気づきます。バックアップ戦略の半分はどう保存するか、もう半分はどう復元するかです。後者は前者より10倍重要です。

実行は3ステップです。1つ目、3-2-1の原則に従って3層のバックアップを構築します。ローカル、遠隔地のオブジェクトストレージ、コールドアーカイブをそれぞれ1部ずつ。2つ目、頻度と保持ポリシーを決めます。データベースは4時間ごとの増分と毎日の全量、ファイルは毎日の増分、保持期間は30日から3年。3つ目、四半期ごとに復元訓練を実施し、テスト環境で復元手順を最後まで通し、実際のRTOとRPOを記録します。この3ステップを終えて初めて、バックアップがあると言えます。

覚えておきたい一言。復元したことのないバックアップは、バックアップがないのと同じです。バックアップスクリプトを1年動かすより、1回の完全な復元訓練のほうが価値があります。実際の事故では、40%のバックアップが肝心なときに開けません。