こんにちは、須賀です。
WordPressのテーマやプラグインを更新するとき、「もしサイトが表示されなくなったら、元に戻せるだろうか」と不安になることはありませんか。
プラグインを使わずにWordPressをバックアップするには、サイトの「ファイル」と「データベース」の両方を保存します。管理画面の「エクスポート」だけでは、サイト全体を元の状態に戻すための備えにはなりません。
この記事では、一般的なレンタルサーバー上のWordPressを対象に、手動で保存する手順と、復元までに確認したいことを整理します。サーバーごとに画面や提供機能が異なるため、操作名は契約先のマニュアルと照らし合わせてください。
WordPressのバックアップで保存するもの
まずは、次の2つをひと組で保存すると覚えておきましょう。
- ファイル：WordPress本体、テーマ、プラグイン、アップロードした画像、設定ファイルなど。
- データベース：記事や固定ページの本文、コメント、サイトの各種設定など。
画像やテーマをダウンロードしても、データベースまで一緒に保存されるわけではありません。反対に、データベースだけでは画像ファイルやテーマのコードが足りません。WordPress公式のバックアップガイドでも、通常のサイトを復元するには両方が必要と説明されています。
「ツール→エクスポート」で保存できる範囲
WordPressの標準エクスポートは、投稿や固定ページ、コメント、カテゴリーなどをXML形式（WXR）で書き出す機能です。記事の移行や、本文を別途保存したいときに役立ちます。
ただし、画像ファイルそのものや、サイト全体の設定を丸ごと収めたバックアップではありません。記事に画像の情報が含まれていても、画像の実体を保存したことにはならない点に注意してください。WXRの制限はWordPress公式のエクスポート解説でも確認できます。
以前の本記事では、標準エクスポートを中心にバックアップを紹介していました。サイト全体を復元できると受け取られかねない説明だったため、ファイルとデータベースを保存する内容に見直しました。
作業前に確認すること
最初に、契約サーバーの管理画面でバックアップ機能を確認してください。ファイルとデータベースを保存・復元できる機能があれば、それもプラグインを使わない方法のひとつです。
確認したいのは、「何を保存しているか」「いつの状態まで戻せるか」「自分で復元できるか」「ダウンロードできるか」の4点です。「自動バックアップあり」という表示だけで判断せず、保存対象と復元方法まで把握しておきましょう。
以下では、手動で保存する場合の流れを紹介します。サーバーの管理画面、ファイルを取得する手段、データベースをエクスポートする手段が必要です。WordPress管理画面のログイン情報とは別の場合があります。
- パソコンに「サイト名＋取得日時」の保存フォルダーを用意する。
- 作業中は記事の編集、画像の追加、テーマやプラグインの更新を控える。
- 注文・会員登録などが随時入るサイトは、運用担当者と整合性を保てる取得方法を決める。
手順1：データベースをSQL形式で保存する
サーバーにデータベースのバックアップ機能がある場合は、契約先の手順を使います。phpMyAdminを使う場合の基本的な流れは次のとおりです。
- サーバーの管理画面からphpMyAdminを開く。
- 対象のWordPressが使っているデータベースを選ぶ。
- 「エクスポート」を開き、対象テーブルとSQL形式を確認する。
- 実行して、作成されたSQLファイル（または圧縮ファイル）を保存する。
同じサーバーで複数のサイトを運営している場合は、データベースの選び間違いに注意しましょう。接続先はWordPressのwp-config.phpで確認できますが、確認のためにファイルを書き換える必要はありません。
ひとつのWordPress専用のデータベースなら、通常はすべてのテーブルが保存対象です。別サイトや他のシステムと共有している場合は、必要なテーブルを管理者に確認してください。プラグインが追加したテーブルの取りこぼしにも注意が必要です。
詳しくはWordPress公式のデータベース保存・復元ガイドを参照してください。容量制限やタイムアウトで保存できない場合は、サーバー側のバックアップ機能やサポートを利用しましょう。
手順2：WordPressのファイルを保存する
続いて、サーバーのファイルマネージャーや、契約先が案内するSFTP・FTPSなどの接続方法で、WordPressの設置フォルダーをパソコンにダウンロードします。転送方向は「サーバーからパソコンへ」です。
保存漏れを減らすには、設置フォルダー内のファイルとサブフォルダーをまとめて取得し、次の内容が含まれることを確認します。
wp-content：テーマ、プラグイン、アップロード画像など。wp-config.php：データベースへの接続情報など。wp-admin、wp-includesなど：WordPress本体。.htaccessなど：その環境で使っている設定ファイル。
隠しファイルが一覧に表示されない場合は、表示設定も確認してください。構成によってはwp-config.phpがひとつ上の階層に置かれていたり、画像を外部ストレージで管理していたりします。その場合は、別の場所にあるデータも保存対象に加えます。
転送が終わったら、失敗・未転送のファイルが残っていないか確認しましょう。保存対象の考え方はWordPress公式のファイルバックアップ解説も参考になります。
手順3：保存したデータを確認・保管する
ダウンロードが終わっただけで、バックアップ完了と判断しないことが大切です。最低限、次を確認してください。
- 同じ作業で取得したファイルとデータベースが、ひと組になっている。
- ファイルが空ではなく、圧縮した場合は展開できる。
- 取得日時、対象サイト、作業前後のどちらの状態かをメモしている。
- 直前の正常なバックアップも残している。
例えば「テーマ更新前」「記事整理前」と名前やメモに残しておけば、戻したい状態を探しやすくなります。保存先は稼働中のサーバーだけに集中させず、アクセスを制限した別の場所にもコピーを置きましょう。
バックアップには接続情報や個人情報が含まれることがあります。公開フォルダーに放置したり、誰でも開ける共有リンクを作ったりせず、保存先の権限を確認してください。
復元するときの流れと注意点
保存データを開けることと、サイトを正常に復元できることは別です。可能であれば、本番とは別のテスト環境で復元し、表示と動作を確認しておくと安心です。
同じURL・同じ構成へ手動で戻す場合、一般的にはファイルを戻してから、対応するデータベースをインポートします。データベースの接続先や認証情報が変わる場合は、wp-config.phpとの一致も必要です。
データベースのインポート先や、既存テーブルをどう扱うかは、保存時のSQLと環境によって異なります。本番のデータをいきなり削除・上書きせず、復元前の状態も退避し、契約サーバーの復元手順を確認してください。バックアップ取得後の記事・コメント・注文などが失われる可能性があります。
復元後は、トップページだけでなく、記事、画像、管理画面へのログイン、フォームなど実際に使う機能を確認します。別ドメインへの移行やマルチサイトでは追加の作業が必要になるため、この記事の流れだけで作業を進めないでください。
記事のXMLエクスポートも補助として残したい場合
本文の控えを追加で保存したい場合は、WordPress管理画面で次の操作をします。
- 「ツール」→「エクスポート」を開く。
- 「すべてのコンテンツ」、または保存したい投稿・固定ページを選ぶ。
- 「エクスポートファイルをダウンロード」を押し、XMLファイルを保存する。
保存対象を絞るときは、期間や投稿者などの条件も確認しましょう。操作の詳細はWordPress公式のエクスポート画面の説明にまとめられています。XMLは本文の移行用として、ファイル・データベースのバックアップと区別して保管してください。
保存したつもりを防ぐ、作業後の確認ポイント
記事・画像・設定は別々に確認する
例えば、昨日公開した記事に写真を3枚追加し、今日テーマの設定を変更したとします。記事の本文が入ったデータベースを保存していても、写真のファイルを取得していなければ、復元後に画像が欠けることがあります。反対に、写真だけを保存しても、記事本文や画像を配置した位置まで元に戻せるわけではありません。
このように、普段はひとつのページとして見えていても、WordPressでは複数の場所にある情報を組み合わせて表示しています。確認するときは「記事がある」「画像がある」「利用中のテーマや設定がある」と分けて考えると、足りないものに気づきやすくなります。直近に更新した記事と画像をひとつ決め、復元テストの確認対象としてメモしておきましょう。
ファイルの大きさだけで成功と判断しない
保存したSQLや圧縮ファイルが0バイトなら、正常に保存できていない可能性があります。ただし、容量が大きいことだけで完全なバックアップと判断することもできません。古い写真が大量に入っていても、最新の記事を保存したデータベースが抜けている場合があるためです。
前回と比べて容量が急に小さくなったときは、対象フォルダーやデータベースの選択、エクスポート時のエラーを確認します。一方、画像を整理したなどの理由で小さくなることもあります。容量は異常に気づく手掛かりとして使い、取得対象と完了表示、転送結果を合わせて確認してください。
転送失敗やエラーがあったときの対応
画像が多いサイトでは、ファイルの取得に時間がかかります。途中で接続が切れた場合は、転送ソフトの失敗一覧や履歴を確認し、未取得のファイルがない状態にしてから保存完了とします。「途中まで取れたから大丈夫」と判断して、直前の正常なバックアップを消さないようにしましょう。
データベースの書き出しでエラーが出たときも、ダウンロードされたファイルがあるだけでは完了といえません。エラー文、実行した日時、対象データベースを控えてサーバーのサポートへ相談すると、状況を説明しやすくなります。接続パスワードやSQLの中身を、公開の質問サイトにそのまま貼り付ける必要はありません。
バックアップを迷わず探せる保存方法
取得日時ごとにひと組のフォルダーを作る
おすすめは、取得するたびに専用フォルダーを作り、その中にファイル一式、データベース、作業メモをまとめる方法です。例えば「site-backup-20260923-before-theme-update」のように、サイトと日付、作業目的が分かる名前にします。複数のサイトがある場合は、最初にサイトごとの保存場所を分けると取り違えを減らせます。
フォルダー内では、ファイル一式を入れる場所とSQLを置く場所を分け、補助のXMLには「記事移行用」と分かる名前を付けます。SQLだけを別の日のフォルダーへ移したり、新しい画像だけを古い保存セットへ混ぜたりすると、どの時点の状態なのか分からなくなります。取得した時点の組み合わせを、そのまま残すことを意識してください。
作業メモに残したい項目
- 対象サイトのURLと、取得した日時。
- テーマ更新前など、どの作業に備えて取得したか。
- 対象の設置フォルダーとデータベースを識別できる情報。
- 保存したファイル名、転送結果、エラーの有無。
- 復元手順を確認できるサーバーのマニュアルの場所。
- 復元テストを実施した場合は、その日付と確認結果。
メモの目的は、数か月後の自分や引き継いだ担当者が判断できるようにすることです。パスワードを平文で並べる必要はありません。認証情報は普段使っている適切な管理方法で保管し、バックアップの作業記録とは役割を分けましょう。
SQLや設定ファイルを、誰でもアクセスできる公開フォルダーに置かないでください。保存先の共有設定も確認します。また、ZIPに圧縮しただけで内容が暗号化されるわけではありません。容量を小さくすることと、第三者から内容を守ることは、それぞれ別に考える必要があります。
本番へ戻す前に、復元テストで確認したいこと
初めてバックアップを取る場合は、可能な範囲でテスト環境へ復元してみると、保存漏れだけでなく、手順の分からない箇所も見つけられます。ただし、別のURLで動かすにはURL変更などの追加作業が必要になる場合があります。サーバーに検証環境を作る機能があれば、その案内に沿って準備してください。
テスト用サイトには、本番の記事や利用者の情報が複製されることがあります。一般公開しない環境で扱い、フォームや外部サービスとの連携によって、実際の利用者へ通知が送られないかも確認します。設定が分からない場合は、担当者やサーバー会社へ相談してから試しましょう。
表示確認では、トップページだけを見て終わりにせず、次のような対象を選ぶと実用的です。
- 最新の記事と、古い画像を含む過去の記事。
- 固定ページ、カテゴリーの一覧、サイト内の主要なリンク。
- スマートフォンで見たときの本文とメニュー。
- 管理画面へのログインと、記事を編集できること。
- 利用中のフォームや会員機能など、サイト固有の機能。
テストの結果は「問題なし」だけでなく、確認したページと機能を短く記録しておくと役立ちます。画像が出ない場合はファイルの不足、記事が古い場合はデータベースの取得時点など、原因を切り分ける手掛かりにもなります。ただし、症状だけで原因を断定せず、保存した組み合わせや環境の違いを確認してください。
バックアップのゴールは、必要な状態へ戻す方法が分かっていることです。復元テストが難しい場合でも、どの画面で復元を開始するのか、誰に依頼できるのか、どの保存データを指定するのかまでは把握しておきましょう。
バックアップはいつ取る？更新頻度に合わせた決め方
保存頻度に、すべてのサイトに共通する正解はありません。月に数本の記事を更新するブログと、毎日注文が入るサイトでは、失って困るデータの量が異なります。「前回の保存以降に変更した内容を、もう一度作り直せるか」を考えると、自分の運用に必要な頻度を決めやすくなります。
個人ブログなら、日常の定期保存に加えて、テーマ・プラグインの更新前や記事を大量に整理する前に保存する、という運用が考えられます。更新が少ない期間でも、WordPress本体や設定に変更が入っていないかを確認しましょう。記事を書いた日だけが、サイトの状態が変わる日とは限りません。
テーマの変更を予定している場合は、事前の保存と復元方法の確認を作業予定に含めてください。DOWELLのAFFINGER7に関する記事を参考に設定を見直す際も、現在の状態へ戻せる準備をしておくと、変更後に落ち着いて比較できます。
新しいバックアップを取ったら古いものをすべて消すのではなく、正常に動いていた時点の保存セットを複数残します。不具合に気づくまで時間がかかった場合、直近のデータだけでは問題が起きる前へ戻せないことがあるためです。保管できる容量と更新頻度を考えて、残す世代と整理する時期を決めましょう。
プラグインなしのバックアップでよくある疑問
WordPressの管理画面に入れれば、全部保存できる？
管理画面の標準機能だけで、サイト全体のファイルとデータベースを丸ごと取得できるとは限りません。この記事で紹介する手動保存には、サーバー側の管理権限やファイルへ接続する手段が必要です。制作会社などに管理を任せている場合は、自己判断で設定を変える前に、取得と復元を誰が担当するか確認してください。
サーバーの自動バックアップがあれば手動保存は不要？
保存対象や保持期間、復元方法が運用に合っていれば、サーバーの機能を中心に運用することもできます。ただし、契約を終了したあとも取得できるか、障害時に自分で取り出せるかなど、利用条件によって判断が変わります。自動か手動かだけで優劣を決めず、必要なデータを必要な時点へ戻せるかで確認しましょう。
サイトが壊れてから保存しても意味はある？
不具合がある状態の保存データでも、原因の調査や直前までの変更内容を確認する助けになる場合があります。ただし、それを「正常なバックアップ」として扱ってはいけません。取得した状況を明記し、正常だった時点の保存セットとは分けて保管してください。復元作業に入る前に現在の状態も退避しておくと、必要な情報を失うリスクを減らせます。
バックアップは「戻せる状態」で残しておこう
プラグインを使わない方法でも、ファイルとデータベースをそろえて保存すれば、復元に必要なデータを確保できます。大切なのは、保存対象、取得日時、復元方法を自分で把握しておくことです。
まずは契約サーバーのバックアップ機能を確認し、テーマやプラグインの更新前には、正常な状態のひと組を残しましょう。日常の保存頻度は「どこまでの記事や変更なら失っても戻せるか」を基準に決めると、運用に合った備えになります。
※2026年9月23日にWordPress公式資料を確認して内容を更新しました。
