更新したら真っ白、プラグインを入れたらエラー、サーバー移転でURLが崩れた——そんな“もしも”の瞬間に 最速で元に戻せるか は、日ごろのバックアップ設計で決まります。
バックアップは「取った気になる」だけでは不十分。何を・どこへ・何世代・どう復元するかまで決めて初めて“保険”として機能します。
この記事は、初心者でも迷わないように プラグイン/サーバー機能/手動(FTP+DB) の3系統で「確実に戻せる手順」を一本化。特にトラブル時の現場で役立つよう、復元の順序・事前準備・確認ポイントをチェックリスト化しました。
こんな悩みを解決します。
- バックアップの対象は?(DBだけ?wp-contentも?wp-config.phpは?)
- 頻度と世代管理はどのくらいが妥当?(毎日/週1、保持数の目安)
- 保存先の最適解は?(同一サーバーNG、クラウド多重化と暗号化)
- 復元で詰まりやすい箇所は?(インポート容量制限、URL置換、パーマリンク)
- 最速で復旧する手順は?(メンテ表示→復元→動作確認→公開)
記事の流れは、まず 「30秒でわかる全体像」 で復元フローを掴み、つづいて “何を取るか”の最小セット を明確化。
その後、
- 方法1:プラグインで自動化&ワンクリ復元
- 方法2:サーバーの自動バックアップで日時指定復元
- 方法3:手動バックアップと差分復元のコツ
を実例ベースで解説し、本番切替前後のチェックリストとありがちトラブルの即解まで網羅します。
「取れる」よりも「戻せる」に焦点を当てた実践ガイド。読み終わる頃には、あなたのサイトが “壊れてもすぐ戻せる” 状態になっています。
まずは全体像(30秒で把握)
バックアップの種類と復元フロー(ファイル/データベース)
- WordPressは「ファイル」+「データベース(DB)」の2本立てで成り立っています。
- ファイル:
wp-content/uploads/(画像)、themes/(テーマ)、plugins/(プラグイン)ほか - DB:投稿・固定ページ・設定・メニュー・ウィジェットの中身
- ファイル:
- 復元の基本フロー
- 影響範囲の特定(テーマ更新だけか、サイト全体か)
- DB → ファイル の順で戻す(整合性を保ちやすい)
- パーマリンク再生成・キャッシュ削除・動作確認
- メンテナンス解除・公開
緊急時の優先順位:表示停止→復元→動作確認→再開
- 表示停止(メンテナンス表示):被害拡大や不完全表示を防止
- 復元:直近の正常時点へ最短距離で戻す(“最小限の差し戻し”を意識)
- 動作確認:ログイン/固定リンク/フォーム/画像/決済など“公開前テスト”
- 再開:監視を強め、直後数時間はアクセス・エラーログを注視
失敗しないための事前準備(メンテナンス表示・キャッシュ停止・作業記録)
- メンテナンス表示:プラグイン or
.maintenanceで一時的に告知 - キャッシュ系を停止:WP・サーバー・CDN いずれも一時無効化
- 作業記録:復元対象・日時・差し戻し範囲・確認結果をメモ(再発調査に必須)
- ディスク残量の確認:復元ファイル展開で容量を使うため、空き容量を確保
- ログの退避:エラーログは別保存しておくと原因分析に役立つ
何をバックアップすべきか(最低限と推奨の範囲)
必須:データベース(投稿・設定)/wp-content(テーマ・プラグイン・アップロード)
- DB(必須):すべての“中身”が入る。エクスポート(
sql)で取得 wp-content/(必須):uploads/:画像・PDFなどアップロード資産themes/:適用テーマ・子テーマ(カスタマイズ含む)plugins/:利用プラグイン(設定はDB側だが、バージョン整合に重要)
推奨:wp-config.php・.htaccess・使用テーマの子テーマ
wp-config.php:DB接続、キー、特別な定数(デバッグ、メモリ制限等).htaccess:パーマリンクやセキュリティ・リダイレクト設定- 子テーマ:
functions.phpやテンプレート上書きの差分を保持
除外推奨:キャッシュ・バックアップの多重保存・不要ログ
- キャッシュ:
wp-content/cache/などは除外(復元後に再生成される) - バックアップのバックアップ:
/backup/配下など“自己多重”は容量を圧迫 - 不要ログ:
debug.log等は必要に応じて別保管し、本体バックアップからは除外
方法1:プラグインで自動化&ワンクリック復元
UpdraftPlus:クラウド連携(Google Drive/Dropbox)と復元手順
特長
- スケジュール自動化(DB・ファイルで頻度を分けられる)
- クラウド保存(Google Drive / Dropbox / S3 など)
- 管理画面から“構成単位(DB/プラグイン/テーマ/アップロード)ごとにワンクリック復元”
おすすめ設定例
- スケジュール:DB=毎日/ファイル=週1
- 世代管理:最低3〜7世代(更新頻度・投稿量に応じて増減)
- 除外:
cache/、backup*/、大容量一時フォルダ
復元手順(例)
- 「既存のバックアップ」から正常時点を選択
- 復元する要素にチェック(DB → テーマ → プラグイン → アップロードの順推奨)
- 実行 → 完了後に パーマリンク再生成・キャッシュ削除・表示確認
ポイント
- クラウド認証切れに注意(定期的に連携を再確認)
- 大容量サイトは分割・圧縮を有効にしてタイムアウト回避
BackWPup:定期ジョブと復元時のポイント(DB/ファイルの順序)
特長
- 取得の自動化に強い(ジョブ作成でDB・ファイル・送信先を細かく設定)
- ZIP/TAR.GZ などでアーカイブ化して外部送信(S3/FTP等)
基本手順(取得)
- ジョブ作成:対象(DB・ファイル)と保存先、スケジュールを設定
- 除外設定:
cache/や バックアップフォルダを除外 - 実行・通知設定:メール通知やログ保存で取得失敗に即気づける体制へ
復元の考え方
- BackWPupは取得特化。復元は手動が基本(方法3の手順で戻す)
- 順序はDB→ファイルを意識。テーマやプラグインのバージョン差を埋めるため、対象時点でのファイル一式を戻すとトラブルが少ない
All-in-One WP Migration/Duplicator:丸ごとエクスポート・インポートの使いどころ
共通の強み
- **サイト“丸ごと”**を1ファイル(+インストーラ)で移行/復元しやすい
- URL置換やシリアライズ対応が組み込まれており、ドメイン変更にも強い
All-in-One WP Migration
- エクスポート→インポートの操作で復元がシンプル
- アップロード上限に注意(分割インポートや拡張の検討)
- 小〜中規模サイトのクイック復元向け
Duplicator
installer.php+アーカイブで新環境・復元を実行- 事前の要件チェックでサーバー設定・権限を確認できる
- 再現性の高い移行/ステージングに向く(復元リハーサルにも◎)
使い分けの指針
- “いま壊れたのを最速で戻す”:管理画面に入れるなら UpdraftPlus
- 計画的な丸ごと復元/移行:AIOM/Duplicator
- 取得は自動・復元は手動で厳密に:BackWPup+方法3(手動)
方法2:サーバーの自動バックアップ機能を使う
主要レンタルサーバーの復元手順の共通点(日時選択→DB/ファイル選択→実行)
多くの国内ホスティングは、自動で世代管理されたバックアップを保持しています。操作画面は違っても、基本フローは共通です。
- 保持世代から日時を選ぶ
「昨日 03:00」「3日前」などのスナップショットを選択。 - 対象を選ぶ
ファイル一式 / データベース(特定DB)を個別に復元できるケースが一般的。 - 復元先の指定
そのまま上書き/別ディレクトリへ復元して差分確認 の2択を提供する場合あり。 - 実行→進捗表示
容量によって数分〜数十分。完了後にメール通知が来ることもあります。 - 整合確認
wp-config.php のDB名/接続、パーマリンク再生成、キャッシュ削除を実施。
失敗リスクを下げるなら、まず別領域(サブディレクトリ)へ復元→動作確認→本番へ反映が安全です。
注意点:メール・別DBへの影響/上書き範囲/復元後のドメイン整合
- メール影響:同一サーバーでメールも運用している場合、アカウントやメールボックスまで巻き戻る仕様か要確認。可能ならWeb領域のみを対象に。
- DBの上書き範囲:対象DBを誤らないこと。マルチサイト/複数サイト同居環境では特に注意。
- 復元後のドメイン整合:サブディレクトリへ復元した場合は一時URLで表示。本番切替時はサイトURL/ホームURLの整合とURL置換を忘れずに。
- プラグイン・テーマのバージョン差:自動更新がONだと、復元直後にまた更新されることがあるため、一時的に自動更新を停止して検証を行う。
コストと安全性:世代管理・保持期間・サポート窓口の活用
- 保持世代:最低でも7世代、できれば14〜30世代が安心(更新頻度が高いサイトは多めに)。
- 保持期間:7〜30日が一般的。重要リリース前後は手動で別保管も推奨。
- サポート:復元トラブル時はホスティングのサポート窓口が最短ルート。操作代行や失敗時のリカバリ手順を事前に確認しておくと安心です。
方法3:手動バックアップと復元(FTP+phpMyAdmin)
取得手順:必要ディレクトリのダウンロードとDBエクスポート
- ファイル(FTP/SFTP)
- 最低限:
wp-content/uploads/wp-content/themes/wp-content/plugins/ - 可能なら:サイトルート全体(
wp-admin/wp-includes/も含む) - 除外:
wp-content/cache/、バックアップ生成フォルダ、巨大な一時ファイル
- 最低限:
- DB(phpMyAdmin)
- 対象DBを選択 → エクスポート(SQL)
- 方式:カスタムでテーブル選択、圧縮(gzip)を有効にすると転送が軽い
取得の前にメンテナンス表示とキャッシュOFF。書き込みが続く会員サイトは、短時間の書き込み停止も検討。
復元手順:ファイル差し戻し→DBインポート→wp-config.php確認
- DBインポート(先にDB)
- phpMyAdminで対象DBを空にするか、該当テーブルをDROP→インポート。
- 文字コード/照合順序(utf8mb4系)を確認。
- ファイル差し戻し
- 破損原因がテーマ/プラグインに起因するなら、対象時点の
wp-content一式を戻す。 - ルート直下の**
wp-config.phpは現行の接続情報を維持**するか、復元後に再調整。
- 破損原因がテーマ/プラグインに起因するなら、対象時点の
- 整合・最終調整
- ログイン→固定リンク再生成→キャッシュ削除
- 画像表示/フォーム送信/決済/検索まで確認
- エラーログを確認し、警告・未定義関数などを洗い出す
速度を上げるコツ:差分復元/圧縮アーカイブ/タイムアウト対策
- 差分復元:
uploads/は期間を絞る、壊れた可能性の高いテーマ/プラグインのみに限定する。 - 圧縮転送:ディレクトリを事前にzip化→サーバーで展開(SSHやファイルマネージャ)。
- タイムアウト回避:大容量SQLは分割インポート、
max_execution_timeやupload_max_filesizeを一時調整。
保存先と頻度設計(クラウド/世代管理/容量対策)
スケジュール例:DBは毎日/フルは週1/主要更新前は手動取得
- DB(差分が多い):毎日。投稿や注文の増えるEC/会員サイトは1日2回も検討。
- フル(ファイル+DB):週1。大規模サイトは隔日〜週2。
- 重要更新前(本体/テーマ/プラグイン):直前に手動バックアップを1世代確保。
クラウド保存の設計:多重化・暗号化・期限付き共有
- 多重化:同一サーバー内のみ保存はNG。クラウド(Drive/Dropbox/S3)+ローカルの二重化が基本。
- 暗号化:アーカイブにパスワードやKMS。リンク共有は期限付きに。
- 命名規則:
site-env_YYYYMMDD_HHMM_full.sql.gzのように日時と種別を明記。
容量を膨らませない:除外設定・圧縮率・ログローテーション
- 除外:
cache/、node_modules/、バックアップ生成フォルダ、巨大ログ。 - 圧縮:画像やアーカイブはgzip/zip、DBは圧縮エクスポート。
- ローテーション:自動削除ポリシー(例:7世代を超えたら削除)を設定してストレージ費用を固定化。
復元チェックリスト(本番切替の前後で確認)
事前:メンテナンスモード・ブロック・キャッシュ停止
- メンテ表示ON(プラグイン or
.maintenance) - 検索エンジンを一時ブロック(設定 → 表示設定 → 検索エンジンでの表示を許可しない)
- WP/サーバー/CDNのキャッシュ停止(Object Cache/WAFの一時無効化も検討)
- 自動更新OFF(本体・テーマ・プラグインの自動更新を一時停止)
- 空き容量チェック(復元に必要な容量+α)
- 取得元の特定(どの日時のバックアップを使うかを決める)
復元直後:機能・表示・パフォーマンスの基本確認
- ログイン可能か(パスワードリセットが必要か)
- 固定リンク再生成(設定 → パーマリンク → 何も変えず保存)
- 画像・CSS/JSの読み込み(404やミスマイムタイプがないか)
- フォーム送信・メール送達(問い合わせ・会員登録・注文)
- 検索・カテゴリページ(内部リンク・パンくずの整合)
- 決済/会員機能(テスト環境ならサンドボックスで確認)
- エラーログ(
error_log/debug.log/ サーバーログ)
公開前最終確認:SEO/計測・セキュリティ・監視
- 検索エンジンブロック解除(公開時に必ずOFF)
- キャッシュ再有効化(WP/サーバー/CDNを段階的にON)
- 計測タグ/コンバージョン(GA4・広告タグ・GTM)
- sitemap.xml・robots.txt(URL整合・noindexの混入なし)
- WAF/ファイアウォール(復旧後の誤検知・除外ルール)
- アラート監視強化(数時間〜1日は応答・エラーレートを注視)
ありがちトラブルとFAQ(最速リカバリーの勘所)
インポートサイズ超過/タイムアウトの対処
- 分割アップロード(プラグインの分割機能 or SQLを日付で分ける)
- サーバー上で展開(zipをアップ→ファイルマネージャ/SSHで解凍)
- php.ini 一時調整(
upload_max_filesize/post_max_size/max_execution_time) - CLI活用(WP-CLI / mysqlコマンドでのインポートは高信頼)
URL置換・シリアライズ問題を避ける
- シリアライズ対応の置換ツールを使用(専用プラグイン/スクリプト)
- 置換対象は**
siteurl/homeだけでなく**、ウィジェット/メタにも埋まる点に注意 - 画像CDNやプロキシ導入時は**混在コンテンツ(HTTP/HTTPS)**も点検
「頻度・何世代保存?」の目安
- 通常サイト:DB=毎日(7世代以上)/フル=週1(4〜8世代)
- EC/会員サイト:DB=1日2回以上/フル=隔日〜週2(10世代以上)
- 大規模メディア:差分+週次フル/月次アーカイブを長期保管
- 重要イベント(大型アップデート前)は臨時で別保管
無料で十分? 有料の価値は?
- 無料で対応可:小〜中規模、単純構成、復元に自信がある場合
- 有料が有利:
- 差分/増分バックアップで高速・省容量
- 遠隔ストレージの自動多重化(SLA/冗長化)
- ワンクリック復元・サポート(時間単価で見ると実質安いことが多い)
- 長期保持/監査要件(業務サイトのレギュレーション対応)
付録・参考情報
復元リハーサルのやり方(ステージング/一時ドメイン)
- 別環境を作る(サブドメイン or 一時ディレクトリ、Basic認証をかける)
- バックアップから展開(サーバー復元の「別領域」機能 or まるごと系プラグイン)
- URL整合(
siteurl/homeをステージングURLに変更) - noindex設定(検索流入を防ぐ)
- 本番さながらにテスト(決済はサンドボックス、外部APIはテストキー)
復元チェックリスト(コピー用)
[事前] メンテON / 検索エンジンブロック / キャッシュOFF / 自動更新OFF / 空き容量OK
[復元] DB→ファイルの順 / 固定リンク再生成 / 画像・CSS/JS / フォーム / 決済 / 検索
[公開] ブロック解除 / キャッシュON / GA4・広告タグ確認 / sitemap・robots / 監視強化
コメントを残す