この記事でわかること
- ファイルとデータベースを組で保存する
- 許容できるデータ損失から保存頻度を決める
- 復元は独立した環境で確かめる
どこまで戻れれば困らないかを決める
バックアップの計画は、保存ボタンの場所を探す前に始まります。障害が起きたとき、何時間分の投稿や問い合わせを失うと困るか、何時間以内に主要ページを戻したいかを言葉にしてください。毎日更新するサイトと月一回更新するサイトでは必要な保存頻度が変わり、同じ設定がすべてに適するわけではありません。
計画例は「公開記事の更新分は一日以内／問い合わせは別途受信記録を保管／当日中に閲覧を再開」です。これは運営条件を考えるための例で、達成済みの復旧実績ではありません。サーバー会社へ確認が必要な項目と、自分で操作できる項目を分け、夜間や休日に使える連絡手段も残しましょう。
保存対象と保存先をそろえる
WordPress公式は、典型的なサイト全体の復元にはファイルとデータベースの両方が必要と説明しています。記事データだけでなく、画像、テーマ、プラグイン、設定ファイルなどを対象に含めます。同じ時点の組として管理し、いつのファイルといつの記事を戻すのかが分かる名前を付けてください。
台帳には「日時／対象サイト／データベース／ファイル／保存先／復元方法」を記録します。サイトと同じサーバーにしか保存がない場合、そのサーバーへ入れないと取り出せません。別の保存先へ必要な控えを置き、閲覧できる人を限定します。バックアップには個人情報や接続情報が含まれ得るため、公開フォルダへ置きっぱなしにしない運用が必要です。
復元テストで不足を見つける
復元は本番を上書きせず、独立した検証環境で試します。保存データを選び、提供元の手順に沿って戻し、記事数、画像、ログイン、メニュー、フォーム設定を確認してください。検証環境から読者へメールが送られたり、本番の外部サービスへ処理が走ったりしないよう、接続先も事前に切り替えます。
記録例は「開始時刻／使った保存セット／手順で迷った箇所／閲覧確認／残った問題」です。時間を測れば、契約時に想定した復旧時間とのずれを把握できます。成功しなかったときは、データ不足、権限不足、容量制限、手順の不明点を分けて、次回試す前に原因を一つずつ埋めましょう。
復旧後に失われる変更も確認する
古い状態へ戻すと、保存以降に追加された記事や問い合わせが失われる可能性があります。復元直前の状態も保全し、戻した後にどの更新を取り込むかを決めてください。感染が疑われる場合は、単に最新データへ戻すだけでなく、安全な保存時点と侵入原因の調査を担当者へ相談する必要があります。
毎回すべてを練習するのが難しければ、大きな更新前や運営体制の変更時に復元手順を見直します。成功通知が来ない日や、保存容量が急に変わった日も調査のきっかけです。計画書をサイトの管理画面以外からも読める場所へ保管し、管理画面が使えない状況で手順を取り出せる状態にしておきます。
- 許容する損失期間と復旧の目標を書いた
- ファイルとデータベースの組を保存した
- 別の保存先とアクセス権限を確認した
- 独立した環境で復元を試す手順を用意した
- 復元後に取り戻す更新と点検項目を決めた
参考にした公式情報
確認日：2026-09-11。提供条件や仕様は変更される場合があります。
広告・アフィリエイトリンクを含む場合があります。編集・掲載方針