WordPress保守では、更新前にDBバックアップを取るのが基本です。
プラグイン更新で不具合が起きたとき、設定や投稿データまで戻せる状態にしておくためです。
ただし、ここでひとつ見落とされがちなことがあります。
バックアップは、取ればそれで安全になるわけではありません。
置き場所を誤ると、今度はそのバックアップファイル自体が情報漏えいの入口になります。
要点: DBバックアップは「戻すための保険」であると同時に、「守るべき機密データの塊」でもあります。サーバー上に置くなら、保存場所、外部アクセス防止、世代管理まで一緒に設計する必要があります。
レイヤーワークスでは、WordPress保守ツールの開発を通じて、DBバックアップをただ生成するだけでなく、どこに置き、どう守り、どれだけ残すかまで含めて設計してきました。
今回は、WordPressのDBバックアップをサーバー上に置くなら、最低限どこまで考えたいかを整理します。
DBバックアップには何が入っているのか
WordPressのDBバックアップには、投稿本文だけが入っているわけではありません。
サイトによっては、次のような情報も含まれます。
- ユーザー情報
- お問い合わせデータ
- 各種設定値
- プラグインの保存データ
- 会員情報や注文関連データ
- API連携に関する設定値
つまり、公開ページよりむしろ慎重に扱うべき情報がまとまっていることがあります。
それを .sql ファイルとしてサーバー上へ置くなら、「復元しやすいか」だけでなく、「外から取られないか」を同時に考える必要があります。
WPルート直下に置きっぱなしは避けたい
保守スクリプトを作るとき、もっとも単純なのは WordPress のルート直下に backup_20260517.sql のようなファイルを出す方法です。
しかし、この置き方はできれば避けたいところです。
理由は単純で、WordPressのルートは基本的にWeb公開領域だからです。
ファイル名が推測されやすかったり、サーバー設定やプラグインの不備が重なったりすると、本来見せたくないバックアップファイルに外部からアクセスできる余地が生まれます。
実際にはサーバー設定で .sql がそのままダウンロードできないケースもありますが、保守設計として「たまたま見えないはず」に依存するのは弱いです。
少なくとも、バックアップ用の専用ディレクトリを分ける。
まずはここから考えたいところです。
置くなら専用ディレクトリに分ける
サーバー上へ残すなら、バックアップは専用ディレクトリへ寄せた方が管理しやすくなります。
たとえばイメージとしては、次のような形です。
wp-root/
├── wp-admin/
├── wp-content/
├── wp-includes/
└── backups/
├── backup_20260515.sql
├── backup_20260516.sql
└── backup_20260517.sql専用ディレクトリにしておくと、
- アクセス制御をまとめて掛けやすい
- 世代管理しやすい
- 古いファイルの掃除漏れに気づきやすい
- 復元対象を見つけやすい
という利点があります。
レイヤーワークスの実装でも、バックアップはWordPressルート直下ではなく、専用ディレクトリへ寄せる設計にしています。
外部アクセスは二重に防ぐ
専用ディレクトリへ分けても、それだけでは十分ではありません。
次に必要なのは、Webから直接見えないようにすることです。
実務上は、複数の守りを重ねた方が安全です。
たとえばApache環境なら、ディレクトリ側で外部アクセスを拒否する設定を置く。
さらに、万一ディレクトリへアクセスされた場合でも、一覧表示や直接閲覧を防ぐためのファイルを置いておく。
イメージとしては、
.htaccessでアクセス拒否index.phpで直接アクセス時に403を返す
のように、ひとつの防御に依存しすぎない構成です。
どちらか一方だけでも何もしないよりは良いですが、サーバー設定の差や移設時の想定外を考えると、複数の壁を重ねる方が堅実です。
バックアップは残しすぎても危ない
バックアップは、多いほど安心に見えます。
ただ、サーバー上に何十世代も積み上がると、別の問題が出ます。
- ディスクを圧迫する
- 古い情報を長期間抱え続ける
- どれを戻せばよいか判断しにくくなる
- 万一漏れたときの影響範囲が広がる
そのため、サーバー側に残す世代数は、必要最小限に決めておく方が扱いやすいです。
たとえば直近数世代だけをサーバーに残し、それ以上の長期保管は別の安全な場所へ逃がす。
レイヤーワークスの実装でも、サーバー側は最新3世代、ローカル側も最新3世代というように、残し方を固定して管理しています。
「取る」だけでなく、「いつ消すか」まで決める。
ここまで入って、ようやく運用として安定します。
サーバーだけに置かない
サーバー上のバックアップは、更新直後の復旧には便利です。
ただし、サーバーそのものに障害が起きた場合、そのサーバー内にしかないバックアップは一緒に失われます。
そのため、サーバー側とは別に、ローカルや別保管先にもコピーを持っておく方が安全です。
ここで大事なのは、単に二重化することではなく、役割を分けることです。
| 保存先 | 主な役割 |
|---|---|
| サーバー上 | 更新直後にすぐ戻すため |
| ローカル / 別保管先 | サーバー障害や長期保管に備えるため |
同じバックアップでも、使う場面が違います。
だからこそ、片方だけで安心しないことが大切です。
不完全なバックアップを残さない
もうひとつ、意外と見落とされるのが「途中で失敗したバックアップ」です。
DBエクスポート中にSSH接続が切れたり、タイムアウトしたりすると、途中まで書き出された .sql ファイルだけが残ることがあります。
そのファイルは、見た目にはバックアップらしく見えても、実際には復元に使えないかもしれません。
さらに、それが積み重なると、ディスク圧迫や復旧時の判断ミスにつながります。
そのため、
- エクスポート失敗時は途中ファイルを削除する
- 正常完了したものだけを世代管理の対象にする
- 失敗はログに残す
という扱いまで決めておくと、バックアップ運用の質が一段上がります。
最低限のチェックリスト
サーバー上にDBバックアップを置くなら、最低限このあたりは確認したいところです。
- WordPressルート直下へ雑に置いていないか
- 専用ディレクトリへ分けているか
- 外部アクセスを拒否する仕組みがあるか
- 直接アクセス時の保険も置いているか
- 残す世代数を決めているか
- サーバー外にもコピーを持っているか
- 失敗した途中ファイルを残さないか
- 復元時にどれを使うか判断できるログがあるか
バックアップは、作成処理だけを見ると簡単に見えます。
でも、本当に難しいのは、その後も安全に扱い続けることです。
まとめ
WordPressのDBバックアップは、保守作業の前提です。
ただし、バックアップを取っただけで安心してしまうと、別のリスクを抱えることになります。
置き場所を分ける。外部アクセスを防ぐ。残す世代を決める。サーバー外にも持つ。不完全なファイルは残さない。
こうした地味な設計が、いざというときに「戻せる」だけでなく、「漏らさない」運用につながります。
DBバックアップは、保険である前に機密データです。
だからこそ、生成方法だけでなく、保管方法まで含めて設計したいところです。
