WordPressをバックアップする方法｜復元できる保存内容と手順

WordPressを元の状態へ戻すには、サーバー上のファイルだけでなく、投稿や設定を持つデータベースも保存する必要があります。本記事では、2026年9月22日時点の公式情報を基に、プラグイン、レンタルサーバー、phpMyAdmin・SFTP、WP-CLIを使う方法と、障害発生時の復元手順を具体的に解説します。管理画面の名称や機能仕様も同日時点のものです。

WordPressの復元には何をバックアップすればよい？

一般的なWordPressサイトは「ファイル」と「データベース」の組み合わせで動作します。WordPress公式のバックアップ解説も、完全な復元には両方が必要だと説明しています。

ファイルに保存されている内容

WordPressを設置したディレクトリには、WordPress本体、テーマ、プラグイン、アップロードしたメディア、PHPやJavaScript、設定ファイルなどがあります。特に重要なのは、独自データが集まるwp-contentディレクトリ、データベース接続情報を持つwp-config.php、URL転送などに使われる.htaccessです。公式のWordPressファイルのバックアップ手順では、サブディレクトリや.htaccessを含めて保存するよう案内しています。

データベースに保存されている内容

MySQLまたはMariaDBのデータベースには、投稿、固定ページ、コメント、ユーザー、カテゴリー、タグ、各種設定、プラグインが作成したテーブルなどが入っています。記事本文はテーマのファイル内ではなく、通常はデータベースのposts系テーブルに保存されます。ファイルだけを戻しても、投稿や管理画面の設定は復元されません。

「ツール」→「エクスポート」で作るWXR形式のXMLには、投稿、固定ページ、コメント、カスタムフィールド、分類、ユーザーなどが含まれます。ただし、これはサイト全体の完全なバックアップではありません。公式の「ツール→エクスポート」解説を参照し、記事を別サイトへ移す補助データとして使いましょう。

ファイルとデータベースを同じ日時の一組として管理すると、復元時の内容ずれを防ぎやすくなります。

UpdraftPlusで手動・自動バックアップを設定するには？

WordPress管理画面だけで作業したい場合は、バックアッププラグインが取り組みやすい方法です。ここでは公式プラグインディレクトリで公開されているUpdraftPlusを例にします。2026年9月22日時点では、手動バックアップ、定期実行、復元、外部ストレージへの保存に対応しています。無料版と有料版では利用できる保存先や機能が異なるため、導入時点の公式表示も確認してください。

インストールから手動バックアップまで

1. WordPress管理画面で「プラグイン」→「新規プラグインを追加」を開きます。
2. 検索欄へ「UpdraftPlus」と入力し、提供者がDavid Anderson / Team Updraftであることを確認します。
3. 「今すぐインストール」→「有効化」を選びます。
4. 「設定」→「UpdraftPlus Backups」を開き、「Backup Now」を選びます。
5. データベースとファイルを含める項目を選択し、実行します。
6. 処理終了後、「Existing Backups」にデータベース、プラグイン、テーマ、アップロード、その他の構成要素がそろっているか確認します。

上記の画面名は2026年9月22日時点です。日本語訳や管理画面の表示は、プラグイン版、WordPress本体の言語、翻訳データによって一部英語になる場合があります。

自動バックアップと外部保存先の設定

「Settings」タブで、ファイルとデータベースの実行間隔、保持数、外部保存先を設定します。UpdraftPlus公式プラグインページによると、2026年9月22日時点ではDropbox、Google Drive、Amazon S3互換ストレージ、FTPなどを保存先に利用でき、短時間間隔、日次、週次、隔週、月次のスケジュールが案内されています。有料版限定の保存先や機能もあるため、無料版だけで設計する場合は設定画面で選択可能か確認します。

更新頻度が低い企業案内サイトなら週次を基準にし、毎日注文や問い合わせが入るサイトならデータベースをより短い間隔にします。バックアップ中にタイムアウトする場合は、アクセスの少ない時間帯へ変更し、不要なキャッシュやログを対象から外し、分割アーカイブのサイズを下げます。それでも失敗するときは、サーバーのPHPメモリ、実行時間、空き容量を確認してください。

自動化した後も、初回は外部ストレージに実ファイルが届いたことまで確認しましょう。

レンタルサーバーの自動バックアップはどこまで使える？

レンタルサーバーの自動バックアップは、WordPressへログインできない障害でも復元を依頼・実行できる点が強みです。一方、保存日数、対象データ、復元方法、復元料金、申請期限は事業者とプランで異なります。これらの仕様・料金は2026年9月22日時点でも変更され得るため、契約中プランの公式マニュアルと管理画面を確認してください。

確認する項目

• Web領域とデータベースの両方が対象か
• バックアップが毎日作成されるか、何世代残るか
• 利用者が管理画面から復元できるか、サポートへの申請が必要か
• 特定ファイルだけ戻せるか、領域全体の巻き戻しになるか
• メール、SSL証明書、DNS設定が対象に含まれるか
• 障害発生日より前の世代を選択できるか
• 復元操作によって現在のデータが上書きされるか

比較時はLUFTMEDIAのレンタルサーバー比較も参考になります。ただし、最終判断は各サーバー会社の公式仕様、契約画面、利用規約で行ってください。

サーバー任せにしない方がよい理由

同じ契約領域だけにバックアップを置くと、アカウント停止、誤削除、侵害、サーバー側の重大障害によって本番データと同時に利用できなくなる可能性があります。また、感染や不正な変更に気付くまで時間がかかると、保存されている全世代が変更後の状態になることもあります。

レンタルサーバーの自動保存を第一の復旧手段、プラグインから外部ストレージへ送るデータを第二の手段、更新前にPCへ取得するデータを第三の手段とすると、単一障害に依存しにくくなります。サーバー機能とプラグインを併用する場合は、同時刻に重い処理が重ならないよう開始時刻をずらします。

契約プランの保存世代と復元条件を、障害が起きる前に管理画面で確認しておきましょう。

phpMyAdminとSFTPで手動バックアップする手順は？

プラグインを追加できない環境や、更新前の完全な控えを自分で作りたい場合は、データベースをphpMyAdmin、ファイルをSFTPで保存します。FTPは通信内容を平文で送る方式のため、サーバーが対応しているならSFTPまたはFTPSを選びます。

phpMyAdminでデータベースをエクスポートする

1. サーバーの管理画面からphpMyAdminを開きます。
2. wp-config.phpのDB_NAMEと一致するデータベースを選びます。複数サイトを運営している場合は取り違えに注意します。
3. 上部の「エクスポート」を開きます。
4. 小規模なデータベースは「簡易」、テーブルや圧縮方式を確認する場合は「詳細」を選びます。
5. 形式を「SQL」にします。「詳細」ではWordPressに属するテーブルを選び、必要に応じてgzip圧縮を指定します。
6. 「エクスポート」を実行し、.sqlまたは圧縮されたSQLファイルをPCへ保存します。

画面名は2026年9月22日時点の一般的なphpMyAdmin表記で、サーバー会社の採用版によって「実行」「エクスポート」などの表示が異なる場合があります。wp_は初期値にすぎず、実際の接頭辞はwp-config.phpの$table_prefixで確認します。WordPress公式も、データベースの書き出しだけではテーマ、プラグイン、アップロードファイルを保存できないと説明しています。

SFTPでWordPressファイルを取得する

1. サーバー会社の管理画面で、SFTPのホスト名、ポート、ユーザー名、認証方法、WordPress設置先を確認します。
2. WindowsではWinSCPなど、macOSではSFTP対応クライアントを開きます。アプリが違っても、転送方向はサーバー側からPC側です。
3. wp-admin、wp-includes、wp-contentが並ぶWordPressルートを特定します。
4. 隠しファイルを表示し、.htaccess、wp-config.phpを含むルート全体を取得します。
5. 転送失敗件数が0であることをログで確認し、SQLファイルと同じ日時のフォルダーへまとめます。

macOSではファイル名の先頭がピリオドの項目がFinder上で見えにくく、Windowsでもクライアント設定によって隠しファイルが表示されないことがあります。SFTPクライアント側の「隠しファイルを表示」を有効にしてください。テーマを変更する場合は、関連するWordPressテーマの解説も確認し、子テーマと親テーマを両方保存します。

手動保存では、SQLファイルの取得だけで完了とせず、隠しファイルを含むWordPressルートも保存してください。

WP-CLIでデータベースとファイルを保存するには？

SSHを利用できる環境では、WP-CLIを使うと手順を再現しやすくなります。実行前にWordPressルートへ移動し、wp core is-installedなどで対象サイトを確認します。共有サーバーではSSHやWP-CLIが提供されない場合があるため、2026年9月22日時点の契約プランの仕様を確認してください。

データベースを書き出す

WP-CLI公式のwp db exportでは、wp-config.phpの接続情報を利用してデータベースをSQLへ書き出せます。

wp db export backup-2026-09-22.sql --add-drop-table

成功時に出力先が表示されます。WordPressルート内へ一時出力した場合は、SFTPなどでPCまたは外部ストレージへ移し、サーバー上の公開可能な場所に放置しません。SQLにはユーザー情報、メールアドレス、注文情報などが含まれる可能性があります。

ファイルをまとめる

Linux系サーバーなら、権限がある場合にWordPressルートの一つ上からアーカイブを作成できます。次は設置ディレクトリ名がpublic_htmlである例です。

tar -czf wordpress-files-2026-09-22.tar.gz public_html

サイト容量と同等以上の空き容量を消費する場合があるため、先にdf -hやサーバーの容量画面を確認します。容量が不足するなら、SFTPで直接PCへ取得するか、wp-content、wp-config.php、.htaccessを優先します。独自にWordPressルート外へ置いたファイル、環境変数、Webサーバー設定は別途保存が必要です。

SQLを戻すコマンド

復元にはWP-CLI公式のwp db importを利用できます。

wp db import backup-2026-09-22.sql

既存データベースへ実行すると内容が変更されます。本番環境で直接試さず、復元先のデータベース名と接続先を確認し、直前の現状バックアップも取得します。URLを変更する移行では、シリアライズされたデータを単純なテキスト置換で壊さないよう、移行機能またはwp search-replaceを使います。

CLIではカレントディレクトリと接続先を確認し、日時を含むファイル名で実行結果を識別しましょう。

バックアップを安全に保管し世代管理するには？

バックアップが本番サーバー内に一つだけある状態では、復旧手段として不十分です。WordPress公式は、複数の最近のバックアップを異なる場所へ保存する考え方を示しています。実務では「本番とは別の媒体」「複数世代」「復元可能性」の三点で管理します。

保存場所を分散する

• レンタルサーバーの自動バックアップ
• Google DriveやDropbox、S3互換ストレージなどの外部保存先
• 管理者のPCまたは暗号化された外付けストレージ

外部ストレージの同期フォルダーだけに置くと、誤削除が同期されたり、PCのランサムウェアによる変更が反映されたりする可能性があります。バージョン履歴、保持期間、削除保護、アクセス権を確認し、バックアップ用アカウントには多要素認証を設定します。

更新頻度から保存間隔を決める

失ってよいデータ量を先に決めます。週1回しか更新しないサイトなら週次でも候補になりますが、毎日注文が入るECサイトで日次だけにすると、障害時刻によっては当日分を失います。ファイルは変更時と定期、データベースは投稿・注文・会員登録の頻度に合わせると設計しやすくなります。

保持例として、短い間隔の世代、日次、週次、月次を組み合わせる方法があります。ただし必要世代数は、保存容量、個人情報の保持方針、改ざんを発見するまでの時間によって変わります。古いバックアップを削除する前に、法令、社内規程、取引データの保存要件も確認してください。

ファイル名と記録をそろえる

example-com_20260922_0200_db.sql.gz、example-com_20260922_0200_files.tar.gzのように、サイト名、日時、対象を統一します。記録表には取得日時、WordPress・PHP・テーマ・主要プラグインの版、保存場所、取得方法、結果、検証日を残します。暗号化する場合は、復号鍵をバックアップと同じ場所にだけ置かないようにします。

保存間隔は「何日前へ戻れるか」ではなく「最大で何時間分を失ってよいか」から決めると明確です。

故障・改ざん・移行時にWordPressを復元する手順は？

復元前に原因と戻す時点を決めます。更新直後の不具合なら更新前、改ざんの疑いがあるなら侵入前の世代が候補です。原因を確認せず最新バックアップを上書きすると、問題のあるファイルまで戻すことがあります。

管理画面へ入れる場合のプラグイン復元

1. 新規投稿、注文、問い合わせの受付を止めるか、メンテナンス中であることを案内します。
2. 現在の状態を別名で保存します。障害調査や、バックアップ後に追加されたデータの救出に使えます。
3. 「設定」→「UpdraftPlus Backups」→「Existing Backups」を開きます。
4. 対象日時の「Restore」を選び、プラグイン、テーマ、アップロード、その他、データベースから必要な項目を指定します。
5. 確認画面を進め、完了ログにエラーがないか確認します。
6. 管理画面へ再ログインし、パーマリンク、フォーム、検索、主要ページを確認します。

画面名と復元仕様は2026年9月22日時点です。データベースを戻すと、バックアップ取得後に作成された投稿、ユーザー、注文、設定が失われる可能性があります。ファイルだけの障害なら、最初からデータベースまで巻き戻さず、破損した構成要素に限定します。

管理画面へ入れない場合の手動復元

1. DNS変更や削除を急がず、障害時点のファイルとログを保全します。
2. SFTPまたはサーバーのファイルマネージャーで、バックアップしたファイルを復元します。公式が示す一般的な順序は、ファイルを先に、データベースを後に戻す流れです。
3. phpMyAdminで対象データベースを確認し、「インポート」からSQLまたは対応する圧縮SQLを選びます。形式は「SQL」にします。
4. 新しいデータベースを作った場合は、データベース名、ユーザー名、パスワード、ホストをwp-config.phpと一致させます。
5. 別URLへ移行した場合は、ホームURLとサイトURL、内部URL、パーマリンクを確認します。
6. キャッシュプラグイン、サーバーキャッシュ、CDNを消去し、シークレットウィンドウでも確認します。

phpMyAdminでアップロード上限や実行時間のエラーが出る場合は、圧縮形式を確認し、サーバー会社のインポート機能またはWP-CLIへ切り替えます。「Error establishing a database connection」が表示されたら、wp-config.phpの接続情報、データベースユーザーの権限、DBホストを確認します。個別ページだけ404になる場合は、管理画面の「設定」→「パーマリンク」で現在の設定を保存し直します。

復元前の現状も保存し、戻す対象をファイルだけ・データベースだけ・両方の三択で判断してください。

バックアップから本当に復元できるか検証するには？

「処理完了」と表示されたことと、サイトを復元できることは同じではありません。少なくとも初回導入時、大規模更新前後、保存先やサーバーを変更した後には、本番と分離したステージング環境で復元テストを行います。

復元テストのチェック項目

• トップページ、投稿、固定ページ、カテゴリー、検索結果が表示される
• 管理者がログインでき、ユーザー権限が想定どおりである
• テーマの外観、子テーマの変更、プラグイン機能が反映される
• メディアの実ファイルが開き、リンク切れがない
• 問い合わせフォームをテスト送信できる
• ECサイトでは商品、在庫、注文、会員情報を権限に配慮して確認できる
• HTTPS、リダイレクト、パーマリンク、定期処理が正常に動く
• PHPエラーログ、WordPressのサイトヘルス、バックアップログに重大なエラーがない

ステージング環境から顧客へメールが送られたり、検索エンジンに公開されたりしないよう、メール送信の停止、Basic認証、検索エンジンへの公開抑制を設定します。本番と同じURLをローカル環境で再現する場合はhostsファイルを使う方法がありますが、Windowsでは管理者権限、macOSでは管理者パスワードが必要です。作業後は設定を元へ戻します。

バックアップファイルが空でないこと、圧縮ファイルを展開できること、SQL内に想定テーブルがあることも確認します。可能ならハッシュ値を保存し、転送後のファイルが変化していないか比較します。検証結果には、復元に要した時間、使った世代、失敗箇所、追加で必要だった認証情報を記録します。

失敗したときの分岐

ファイル展開で失敗するなら、空き容量、ファイル権限、アーカイブ破損を確認します。データベースのインポートで文字コードや照合順序のエラーが出るなら、元環境と復元先のMySQL・MariaDB仕様を比較します。白い画面や重大なエラーになるなら、wp-content/pluginsを一時的に改名してプラグインを停止し、PHPエラーログから原因を絞ります。ログイン後に表示が崩れる場合は、テーマ、キャッシュ、アップロードファイルの順に確認します。

検証で不足が見つかったら、対象範囲、保存間隔、保持世代、外部保存先を修正し、もう一度テストします。バックアップ運用は「取得」「外部転送」「世代保持」「復元テスト」までを一つの手順として扱うことが重要です。

参照した公式情報

• WordPress Developer Resources：Backups
• WordPress Developer Resources：Backing Up Your WordPress Files
• WordPress Developer Resources：Backing Up Your Database
• WordPress.org Documentation：Tools Export screen
• WP-CLI：wp db export
• WP-CLI：wp db import
• WordPress.org Plugin Directory：UpdraftPlus

少なくとも初回設定時に一度復元し、所要時間と不足データを記録して運用手順を完成させましょう。