※本記事には広告・アフィリエイトリンクが含まれる場合があります。
WordPressのバックアップは、ファイルを1個保存すれば終わりではありません。データベースとファイルの両方を戻せる状態にする必要があります。
結論｜この4点だけは確認
- データベースとファイルの両方を対象にする
- 自動取得だけでなく復元方法を確認する
- サーバーとは別の場所にも1系統残す
- 更新・テーマ変更・サーバー移行前は追加バックアップを取る
バックアップで最も重要なのは「取れていること」ではなく「必要な時点へ復元できること」です。
WordPressでバックアップするものは2種類
| 種類 | 主な内容 | 失うとどうなる |
|---|---|---|
| データベース | 投稿・固定ページ・設定・コメント | 記事や設定が戻せない |
| ファイル | 画像・テーマ・プラグイン・wp-config.php等 | 見た目や画像・機能が戻せない |
WordPress公式もバックアップをデータベースとファイルに分けて説明しています。片方だけでは完全な復元にならないケースがあります。
初心者向け｜安全なバックアップ3段構え
1｜レンタルサーバーの自動バックアップ
最初に、使っているサーバーが何日分保存するか、復元は無料か、WebとDBの両方が対象か確認します。
2｜WordPress側または外部保存
重要サイトでは、サーバー障害やアカウントトラブルに備えて別系統も持ちます。クラウドストレージやローカル保存など、同じサーバーの中だけに置かないことがポイントです。
3｜大きな変更直前のスナップショット
- WordPress本体の大型更新前
- テーマ変更前
- 重要プラグイン更新前
- PHP変更前
- サーバー移行前
- 大量記事の一括更新前
頻度は「何日分失っていいか」で決める
| サイトの変化 | 目安 |
|---|---|
| 注文・会員データが毎日増える | 日次以上を検討 |
| 週に数回記事更新 | 日次〜週次 |
| ほぼ更新しない小規模サイト | 週次〜月次でも運用次第 |
| 大きな変更日 | 直前に追加取得 |
保存先は同じサーバーだけにしない
保存先の考え方
- サーバー標準の自動バックアップ
- クラウドストレージなど別サービス
- ローカルPC・外部ストレージ
- 少なくとも1系統はサーバー障害と切り離す
復元テストを1回はやっておく
緊急時に初めて復元画面を見ると、どの日時・どの範囲を戻せばいいか迷います。テスト環境や低リスクなタイミングで、復元導線と必要な認証情報を確認しておくと安心です。
サーバー移行前は追加バックアップ
サーバー乗り換えでは通常の自動バックアップとは別に、移行直前のファイルとDBを残します。具体的な流れはWordPressのサーバー移行方法を確認してください。
サーバーの自動バックアップを比較する
各社の保存期間・復元条件を比べるならレンタルサーバー自動バックアップ比較、サーバー自体を見直すならWordPress向けレンタルサーバー比較へ進めます。
よくある質問
記事だけエクスポートすれば十分？
十分ではありません。WordPressのエクスポートは便利ですが、画像・テーマ・プラグイン・各種設定を完全復元する用途とは別です。
バックアッププラグインは必須？
必須ではありません。サーバー標準バックアップで要件を満たすこともあります。重要なのは保存範囲・期間・復元方法です。
3-2-1の考え方をそのまま使う必要はないが「別系統」は持つ
バックアップでは3-2-1ルールが紹介されることがありますが、個人ブログで形式だけ守る必要はありません。重要なのは、同じサーバー・同じアカウント障害で全部失わないことです。
サーバー自動バックアップ＋外部ストレージの2系統でも、何も分けていない状態より復旧可能性は上がります。
復元ポイントは「いつに戻すか」まで決める
サイトが壊れた直後に最新バックアップへ戻せばいいとは限りません。マルウェア感染や設定ミスが数日前から起きていた場合、最新バックアップにも問題が入っている可能性があります。
- 更新直前のバックアップ
- 前日
- 7日前
- 30日前など
- サーバー側の保存世代を確認する
EC・会員サイトはバックアップ頻度を上げる
注文・会員情報・予約などが増えるサイトは、記事中心のブログより失うデータの価値が高くなります。更新頻度ではなく『何時間分の注文を失って許容できるか』で頻度を決めます。
バックアップ直後に確認する3点
WordPress公式もファイルとDBを分けて説明
WordPress公式のバックアップガイドでも、WordPressサイトのバックアップはDatabaseとFilesの2つに分けて説明されています。
復元手順をメモしておく
- 障害がサイト全体か特定プラグインか確認
- 復元する日時を決める
- 現在状態も念のため別バックアップ
- ファイル・DBのどちらを戻すか決める
- 復元後にログイン・記事・画像・フォームを確認
- 原因になった更新や設定を再適用する前に検証
バックアップがあっても、緊急時に手順が分からないと復旧に時間がかかります。管理画面URL、サーバーの復元画面、連絡先まで簡単にメモしておくと対応が速くなります。
よくあるバックアップ失敗
- DBだけ保存して画像・テーマがない
- 同じサーバー内にしかバックアップがない
- 保存容量不足で数週間前から失敗していた
- 自動バックアップはあるが復元方法を一度も確認していない
- 更新後に不具合が出てからバックアップを取り直してしまう
バックアッププラグインを増やしすぎない
サーバー側ですでに日次バックアップがあり、外部保存も確保できているなら、同じ役割のバックアッププラグインを複数入れる必要はありません。
バックアップ処理自体がサーバー負荷や容量を増やすこともあるため、役割が重複していないか確認します。
WordPressのエクスポートは完全バックアップではない
WordPress標準のエクスポートは投稿などを移す用途には便利ですが、テーマ・プラグイン・サーバー設定まで元通りに戻す完全バックアップとは役割が違います。復旧目的ではファイルとデータベースの両方を確保します。
復旧目標を決めるとバックアップ頻度が決まる
バックアップ頻度を決める時は、専門用語ではRPO（どこまでのデータ損失を許容するか）とRTO（どれくらいで復旧したいか）の考え方が役立ちます。
| サイト | 許容しにくい損失 | 考え方 |
|---|---|---|
| 更新少なめブログ | 数日分 | 日次〜週次でも運用次第 |
| 毎日更新メディア | 1日分でも痛い | 日次中心 |
| EC・予約 | 数時間の注文損失も痛い | より短い間隔を検討 |
| 会員サイト | 会員・決済データ | DB側の頻度を特に重視 |
バックアップは暗号化・アクセス権も確認
外部ストレージへコピーする場合、バックアップ自体に個人情報・設定ファイル・APIキーが含まれることがあります。共有リンクを公開しない、MFAを使う、不要な古い世代を放置しないなど保存先のセキュリティも必要です。
復元後に確認する項目
- トップと主要記事が表示される
- 画像・CSSが欠けていない
- 管理画面へログインできる
- フォーム送信が届く
- プラグインの設定が戻っている
- SSL・リダイレクトが正常
- 更新前の問題が再発していない
まとめ
WordPressバックアップは、ファイル＋DB、保存先、頻度、復元方法の4点をセットで考えます。大きな変更前に直前バックアップを残すだけでも、事故時に戻せる可能性が大きく変わります。
コメント