バックアップは「取れている」と「戻せる」が別物
結論：バックアップの成否は、戻したときにしか分からない
「バックアップは毎日取っています」— 保守の打ち合わせで最もよく聞く言葉です。そして、最も検証されていない言葉でもあります。
バックアップには、別々の 2 つの問いがあります。取れているかと、戻せるかです。前者は仕組みの話、後者は運用の話で、障害のときに必要になるのは後者だけです。
ところが日々の運用で確認されるのは、ほぼ前者だけです。管理画面に「成功」と並んでいるのを見て安心する。その状態で数年が過ぎ、いざ戻す段になって初めて、戻せないことが分かります。
「取れている」は、思っているより頼りない
1. 「成功」と記録されているのに、中身が空
バックアップ処理の「成功」は、多くの場合コマンドが終了コード 0 で終わったことしか意味しません。出力されたファイルの中身までは見ていません。
実際に起きるのは、こういう形です。存在しないサブコマンドを叩いている、あるいは認証に失敗している。それでも処理全体は続行し、出力先には0 バイトのファイルが残る。ログには「成功」と記録される。翌日も、その翌日も、同じことが繰り返されます。
防ぐのは難しくありません。出力そのものを確かめることです。
- データベースのダンプなら、末尾に完了を示す行があるか
- ファイルの書庫なら、展開できるか・想定した数のファイルが入っているか
- 最低限、サイズが 0 でないか
最後の 1 つだけでも、かなりの事故は防げます。
2. 終了コードが、成否を表していないことがある
サーバー管理ツールのコマンドラインには、内部で失敗しているのに 0 で終了するものがあります。本当の結果は、まったく別のログファイルにしか書かれていない、ということが起こります。
終了コードを成否の判定に使っているなら、それが本当に失敗を捕まえられるのかを一度確かめてください。確実なのはわざと失敗させてみることです。存在しないデータベースを指定する、書き込めない場所を出力先にする。それで検知の仕組みが鳴らなければ、その仕組みは本番でも鳴りません。
これは監視全般に言えることですが、鳴らない監視と、異常が無い状態は、外から見分けがつきません。
3. 対象から漏れている
WordPress を戻すには、ファイルとデータベースの両方が要ります。片方だけでは戻せません。
| どこにあるか | 何が入っているか |
|---|---|
| データベース | 投稿・固定ページ・カテゴリ・各種設定・プラグインの設定・問い合わせの記録 |
| ファイル | アップロードした画像や PDF・テーマ・プラグイン本体・wp-config.php |
どちらかが欠けると、戻した結果は「記事はあるが画像が全部消えている」「画像はあるが記事が数か月前」という状態になります。どちらも、お客様に説明できる状態ではありません。
「戻せる」を確かめる 3 つの問い
1. 何分で戻せるか
手順書があるかではなく、実際に測ったことがあるかです。
復旧には、バックアップの取得場所へのアクセス、転送、展開、データベースの投入、URL やパスの書き換え、動作確認が含まれます。書庫が数 GB あれば転送だけで時間が溶けますし、保管先の認証情報が誰も分からない、ということも起こります。
復旧手順は、試していなければ手順ではありません。
2. どの時点に戻せるか
日次バックアップであれば、最悪の場合24 時間分が失われます。これはコーポレートサイトなら許容できることが多い一方、問い合わせフォームが主要な導線になっているサイトでは、失うのは記事ではなくお客様からの連絡です。
「何日分の世代を保持しているか」も同じくらい重要です。改ざんや設定ミスは、当日中に気づくとは限りません。1 週間後に気づいたときに、1 週間前の状態が残っていなければ、バックアップはあっても使えません。
3. 戻した後に、動くか
戻す作業が完了することと、戻したサイトが正しく動くことは別です。よくあるのは次のような食い違いです。
- データベースの中に、旧環境の URL やサーバー上のパスがそのまま残っている
- PHP のバージョンが当時と違い、古いプラグインが動かない
- 有料プラグインのライセンスが、戻した環境では認証されない
- フォームからのメールが送られない（送信の設定はサーバー側にあり、バックアップに含まれない）
最後の 1 つは特に見落とされます。サイトは表示されるのに、問い合わせだけが届かない状態は、復旧したつもりの後に起こりうる最も厄介な形です。
バックアップそのものが、リスクになるとき
ここはあまり語られませんが、実務では無視できない論点です。
公開されている場所に置かれた控え
引き継いだサイトを外側から調べると、誰でもダウンロードできる場所にデータベースのダンプが置かれていることがあります。移行作業やプラグインの操作で作られたものが、そのまま残っている形です。
データベースのダンプには、利用者のメールアドレスとパスワードのハッシュ、問い合わせの内容、場合によってはデータベースの接続情報まで含まれます。バックアップは、サイトの中身がひとまとめになったファイルです。置き場所を間違えれば、それ自体が情報漏洩の経路になります。
ファイル名を推測されにくくしても、対策にはなりません。多くの場合、作成時のログや設定ファイルが同じ場所に残っており、そこから辿れます。公開領域には置かない、これだけです。
本番と同じ場所にしかない控え
同じサーバーの中にバックアップを置いているだけの構成は、サーバーそのものが失われる事態に対応できません。ディスク障害、アカウントの停止、そして侵入されたときの意図的な削除。バックアップを消してから本番を壊すのは、身代金要求型の攻撃では基本の手順です。
最低でも 1 世代は、本番とは別の場所・別の認証情報で保管されている必要があります。
消えない控えが溜まっていく
プラグインが作るバックアップは、アップロード先のフォルダに置かれることが多く、世代管理から外れて溜まり続けます。数 GB 単位でディスクを圧迫し、しかもそれ自体が公開領域に近い場所にあります。
「バックアップが増えるのは安全」ではありません。管理されていない控えは、資産ではなく負債です。
控えが取れなければ、更新しない
ここまでの話を、運用の設計にどう落とすか。CloudHonu での実例を 1 つ挙げます。
2026 年 8 月、自動更新が失敗した実行は 3 件ありました。3 件とも、原因は同じです。バックアップの作成に失敗したため、更新を実行せずに停止した。プラグインもテーマも、1 件も更新されていません。
これは障害ではなく、設計どおりの動作です。更新は、失敗したときに戻せることが前提の作業です。戻せない状態で当てるくらいなら、当てないほうがよい。控えが取れないこと自体が、更新を止める理由になります。
逆に言えば、この 3 件は「バックアップが取れていないサイトが 2 つある」という報告でもあります。更新が止まったことよりも、そちらのほうが重要な情報です。バックアップの失敗は、それ単体で対応すべき事象として扱う必要があります。
まとめ
バックアップについて確認すべきことは、「取っているか」ではありません。
- 出力の中身を確かめているか（成功の記録ではなく、ファイルそのものを）
- ファイルとデータベースの両方が揃っているか
- 実際に戻したことがあるか（何分かかり、どの時点に戻り、戻した後に動いたか）
- 置き場所は安全か（公開領域にない、本番とは別の場所にもある、溜まり続けていない）
この 4 つのうち、3 番目だけが「戻せる」を証明します。残りは「取れている」の話です。試したことのない復旧手順は、まだ手順ではありません。
