WordPressのバックアップは、ファイルを保存したという通知だけで安心しないことが大切です。必要な情報が揃い、障害時に取り出せて、実際に復元できることを確認して初めて備えになります。画像は戻ったが記事が戻らない、保存先へログインできない、といった事態を避けるには、保存と復元を一つの手順で考えます。
この記事は、運営中のブログでバックアップ計画を作るための案内です。本番データの削除や置換をその場で勧めるものではありません。復元の検証は本番とは分けた環境で行い、現在のデータを保全してから進めてください。具体的な操作は、利用するサーバーやバックアップ機能の公式手順に従います。
保存する対象を二つに分ける
WordPressでは、記事などの情報を持つデータベースと、画像・テーマ・プラグインなどのファイルを区別します。一般的な復元には両方が必要です。サーバー上のフォルダーをダウンロードしただけで、データベースも保存したことになるとは限りません。
管理画面のエクスポート機能も、サイト全体の復元用バックアップと同じとは限りません。使っている機能が何を保存し、何を保存しないかを確認してください。独自の設定ファイルや、WordPressの外に置いた静的ページがある場合も、対象一覧へ加えます。最初に保存範囲を確認することで、後の抜けを防げます。
公式情報：WordPress公式：Backups。
どこまで戻れればよいかを決める
毎日更新するサイトと、月に数回しか変更しないサイトでは、必要な頻度が違います。最後の保存以降に失って困る変更は何かを考えます。記事だけでなく、コメント、問い合わせ情報、設定変更など、運用によって戻す必要のある情報は異なります。
例えば前日の状態へ戻せればよいのか、数時間分の変更も失えないのかを決めます。これは希望する復旧条件であって、現在の仕組みが満たしているとは限りません。保存頻度と実際の更新量を照合し、必要なら計画を見直します。細かく保存するほど、容量や管理の負担も増えるため、重要度に合わせて決めてください。
サーバーの自動保存の条件を確認する
自動バックアップがある場合は、保存対象、保存期間、取得時刻、復元方法、費用の有無を確認します。標準で付いていると聞いただけで、すべてのファイルやデータが対象だと思わないようにします。契約プランや機能によって条件が異なるため、現在の公式案内を確認してください。
復元を管理画面で行えるのか、サポートへの依頼が必要なのかも確認します。障害時にサーバー管理画面へ入れなかった場合、どう連絡するかも記録します。担当者が変わった時にログイン方法が分からなくならないよう、認証情報は適切に管理し、必要な権限を持つ人を明確にします。
同じ障害で失わない保存先を考える
本番サーバーだけに保存していると、そのサーバーへアクセスできない時に取り出せない可能性があります。必要に応じて別の保存先を用意し、障害の影響が重ならないようにします。どの保存先を使うかは、情報の機密性、アクセス管理、容量、費用から選びます。
バックアップには個人情報や設定情報が含まれる場合があります。誰でも開ける公開フォルダーへ置いたり、共有リンクを無制限に配ったりしないでください。保存先の権限と保持期間を決め、不要な複製が増え続けないようにします。保存先を増やすことと、安全に管理できることは別の課題です。
取得した一組を識別できるようにする
データベースとファイルは、どの時点の組み合わせか分かるように保存します。別々の日のものを適当に組み合わせると、記事が参照する画像がないなどの不整合が起きる場合があります。取得日時、対象サイト、使った方法、含む範囲を記録してください。
ファイル名だけで分からない場合は、同じ管理台帳で対応付けます。自動処理が完了したという通知に加え、保存物が存在するか、極端に小さくないか、必要な構成が含まれるかを確認します。ただし、容量が十分に見えることだけでは復元可能性を保証できません。後の復元テストで確かめる必要があります。
大きな変更の直前には保存状態を確認する
テーマ変更、プラグイン更新、データの一括修正などの前には、変更直前の状態を戻せるか確認します。毎日自動保存していても、最後の取得後に重要な記事を追加している可能性があります。変更対象と、どの時点へ戻すかを記録してから作業してください。
バックアップが失敗している場合は、大きな変更を進める前に原因を確認します。急いでいるから保存を省くという判断は、問題発生時の負担を増やす可能性があります。外注先へ変更を依頼する場合は、誰が取得し、誰が復元を判断するかを合意しておくと、緊急時に確認が遅れにくくなります。
外注先の作業権限を整理する際は、WordPressの権限を外注先に渡す方法に沿って必要なアクセス範囲を確認します。
復元テストの環境を準備する
本番サイトとは別の検証環境を用意します。検証用のサイトを検索へ公開しないようにし、必要なアクセス制限を設定します。復元したサイトがメールを送ったり、外部サービスへ通知したりしないよう、連携の扱いも確認してください。データを複製する許可と管理範囲を明確にします。
検証環境へ戻す操作でも、接続先のデータベースや保存先を取り違えると本番へ影響します。作業前に対象名とURLを確認し、曖昧な場合は管理者へ依頼してください。復元機能の画面で選ぶ日付や対象も、実行前にもう一度確認します。練習だから安全だと考えず、対象の分離を確かめます。
復元後は代表的な動作を確認する
トップページが開くだけでは十分ではありません。新しい記事、古い記事、画像を使う記事、カテゴリーなどを確認します。画像が欠けていないか、文字が正しく表示されるか、管理画面へ入れるかを見ます。プラグインや独自機能があるなら、必要な動作を確認項目へ加えます。
フォームや外部連携のテストは、誤送信を防ぐ条件を整えてから行います。検証環境に本番の認証情報や実際の宛先をそのまま使うことは避け、担当者と確認方法を決めます。復元にかかった時間、つまずいた箇所、追加で必要だった資料も記録すると、障害時の作業見積もりに役立ちます。
復元できない場合の原因を切り分ける
保存物が足りないのか、手順が違うのか、環境条件が合わないのかを分けて確認します。途中でエラーが出た場合は、メッセージと実行した操作を記録し、同じ操作を無闇に繰り返さないようにします。最新の保存物だけでなく、別の正常な世代を使えるかも検討します。
不正アクセスが疑われる場合は、壊れた状態をそのまま復元するだけでは再発する可能性があります。原因の調査と保全が必要になるため、通常の復元手順だけで対応しようとせず、適切な担当者へ相談します。復元すれば必ず問題が解決するという前提を置かないことが重要です。
復元テストの結果を残す例
記録には、使用した保存物の日時、復元先の識別、確認したページ、動かなかった機能、追加した設定を記載します。例えば「新しい記事は表示、添付画像も表示、問い合わせは検証用宛先で確認」という形です。単に成功とだけ書くより、どの範囲を確かめたかが分かります。
復元先の環境が本番と違う場合は、その差も残します。検証では正常でも、本番へ戻す際に同じ手順だけで足りるとは限りません。担当者が不在の場合に備えて、操作に使う公式手順と連絡先を記録します。保存物の置き場所だけを知っている人と、復元を実行できる人が別なら、その役割も明確にします。
検証が終わった環境を放置すると、古いデータや認証情報が残り続けます。保持が必要かを確認し、管理者の方針に沿って整理してください。片付ける際も、本番ではなく検証対象であることを確認します。復元テストは起動できた瞬間で終わらず、結果の記録と検証環境の管理までを一つの作業として扱います。
バックアップ台帳を運用へ組み込む
台帳には取得日、保存範囲、保存先の識別、保持期限、復元確認日、担当者を記録します。パスワードや秘密情報をその表へ直接書かず、管理方法を分けます。期限を過ぎた保存物の削除も、業務上必要な記録を失わないよう、決めた方針に沿って行います。
定期確認では、自動処理の成功だけでなく、取り出せることと復元手順が使えることを点検します。サイトの構成や担当者が変わったら、対象範囲と連絡先も更新します。バックアップは保存ボタンを押す作業ではなく、障害時に戻れる状態を維持する運用として整えてください。
制作後も管理しやすいWEBメディアを構築したい方は、納品後の対応範囲も含めてサービス内容をご確認ください。
参考資料・公式情報
公式情報の確認日：2026年9月12日。サービスの仕様・掲載条件は変更されるため、実行時は最新の公式案内を確認してください。
当社独自の累計収益保証付き！
丸投げで収益を狙う
アフィリエイトサイトを
手に入れませんか？
アフィリエイト専門のプロが、
企画からサイト構築・記事制作・収益設計まで一括対応。
