WordPress活用

WordPressのバックアップ方法|手動と自動

最終更新日:2026年8月12日 ZenWeb Japan 編集部
結論:WordPressのバックアップ方法は、手動・プラグイン・サーバー機能の3つです。保存するのはファイルとデータベースの両方。ただし大事なのは取る作業ではなく、戻せる状態かどうかです。保管先をサーバーの外にも1つ持ち、年に一度は復元を試してください。取っていたのに戻せなかった現場は、ほぼここを飛ばしていました。

01はじめに|この記事でわかること

要点:この記事では、WordPressのバックアップ方法を手動と自動の両面から整理します。手順だけでなく、取っていたのに戻せなかった原因まで見ていきます。WordPress制作の運用を任されている方に向けた内容です。

「バックアップは取っています」。メンテナンスを引き継ぐとき、ほとんどの担当者からこの返事をいただきます。

ところが、いざ戻す場面になると半分くらいで手が止まります。ファイルはあるのにデータベースがない。両方あるのに、サーバーごと止まっていて取り出せない。

取る話と、戻す話は別ものです。この記事は後者から逆算して書きました。順番も、その考え方に沿って並べています。

読み手として想定しているのは、社内でWordPressの窓口を任されている方です。専門用語は最小限にしました。

ご紹介するのは、2000年創業のWeb制作会社ZenWeb Japanがメンテナンスの現場で使っている進め方です。プラグイン側の判断はWordPressプラグインの選び方でも整理しています。

この章のポイント:バックアップの目的は「取ること」ではなく「戻せること」です。まずは、いま戻せる状態かどうかを確かめてください。

まずは全体像を、動画で押さえておきましょう

プラグイン UpdraftPlus を使ったWordPress 自動バックアップの設定と検証環境の作り方

出典動画:YouTube


02保存するのはファイルとデータベースの2つ

要点:WordPressはファイルとデータベースの2つでできています。片方だけでは元に戻りません。画像やテーマはファイル側、記事の本文や設定はデータベース側にあります。この2つを同じタイミングで揃えるのが基本です。

まず、どこに何が入っているかを押さえてください。ここを取り違えると、あとの手順がすべてずれます。

保存先 入っているもの 取り出し方
ファイル WordPress本体、テーマ、プラグイン、アップロードした画像やPDF、wp-config.php FTPソフトでダウンロード
データベース 投稿と固定ページの本文、カテゴリー、コメント、ユーザー情報、各種の設定値 phpMyAdminなどから書き出し

間違えやすいのは、ファイル一式を落とせばデータベースも一緒についてくる、という思い込みです。データベースはサーバーの別の場所にあるため、フォルダをまるごとダウンロードしても含まれません。WordPress公式のバックアップ解説でも、この2つは別ものであり両方が必要だと明記されています。

ファイルだけ残っていて記事が戻らない。この相談が、復旧依頼のなかで最も多い入り口です。
この章のポイント:ファイルとデータベースは別ものです。どちらか一方だけのバックアップは、戻すときに使えません。

いまの取り方で戻せるか、確かめたいときは。

設定内容をうかがったうえで、足りない部分を整理してお伝えします。 WordPress制作・保守の内容を見る →


03手動でバックアップを取る手順

要点:手動の手順は、データベースを書き出し、ファイルを丸ごと落とす2本立てです。順番はデータベースが先。取り終えたら2つを同じフォルダにまとめ、日付をつけて保管します。詳しい前提はWordPress制作の運用でもお伝えしています。

手動でバックアップを取る手順

大きな更新の直前など、その場で1回だけ取りたいときの進め方です。慣れれば30分ほどで終わります。

  1. データベースを書き出す。サーバーの管理画面からphpMyAdminを開き、対象のデータベースを選んで「エクスポート」を実行します。形式はSQLのままで構いません。
  2. ファイルを丸ごと落とす。FTPソフトでサーバーに接続し、WordPressが入っているフォルダをまるごとダウンロードします。時間がかかるので、回線の安定した時間帯に行ってください。
  3. 2つを1つのフォルダにまとめる。書き出したSQLとファイル一式を、日付を名前にした同じフォルダへ入れます。別々に置くと、あとから組み合わせが分からなくなります。
  4. 抜けがないかを確かめる。ダウンロードが途中で止まっていないかを見ます。画像の枚数がサーバー側と合っているかまで確認できると安心です。
  5. サーバー以外の場所にも1つ置く。社内のNASやクラウドストレージなど、サーバーとは別の場所にコピーを残します。ここまでで1回分の完成です。

手動は中身が見えるぶん確実です。ただ、続きません。3か月もすると「先月は取ったかな」という状態になります。社内で抱え込んで止まってしまう流れは、WordPressの自作でつまずくパターンとよく似ています。

公式ドキュメントでも、更新の少ないサイトは週に1回、更新の多いサイトは毎日を目安としています。手で毎日は現実的ではないので、次の自動化へ進んでください。

この章のポイント:手動は大きな作業の直前に使う方法です。日常の備えとしては、続かないことを前提に考えてください。

04方法別・手間と戻しやすさの比較

要点:手動・プラグイン・サーバー機能・メンテナンス契約の4つを、手間と復旧の速さで比べました。取る手間が軽い方法ほど戻すのが速いとは限りません。判断の軸は、保管先を分けられるかどうかです。

実際に復旧を担当した記録から、方法ごとの傾向をまとめました。復旧時間は、依頼を受けてから表示が元に戻るまでの目安です。

方法別・手間と復旧時間の比較
WordPressのバックアップ方法4種類について取得の手間と復旧時間を比較したデータ
方法 取得の手間 保管先を分けられるか 復旧までの目安 向いているサイト
手動(FTP+phpMyAdmin) 1回あたり30分〜2時間 分けられる 半日〜1日 更新がほとんどないサイト
プラグインで自動化 初期設定に1時間、以降は自動 分けられる 1〜3時間 週1回以上更新するサイト
サーバーの自動バックアップ 設定なしで動く 分けにくい 2〜6時間(申請が要る場合あり) 補助として組み合わせる
メンテナンス契約で任せる 依頼のみ 分けられる 1時間以内 止まると業務に響くサイト

出典:ZenWeb Japanが対応したWordPressサイトの復旧記録、2024〜2026年、日本国内。

3列目に注目してください。サーバー機能だけが「分けにくい」となっています。取る手間はいちばん軽いのに、復旧の目安はいちばん長い。この逆転の理由は、次の章で扱います。

この章のポイント:選ぶ基準は取る手間ではなく、保管先を分けられるかどうかです。ここが分かれ目になります。

05プラグインで自動化する方法

要点:プラグインを使うと、取得の頻度と保管先をまとめて決められます。管理画面から設定できるので、FTPやデータベースの知識は要りません。ただし入れっぱなしにせず、月に一度は結果を見てください。

設定画面で決めることは、だいたい次の4つです。ここを決めておけば、あとは動き続けます。

  • 取得する対象。ファイルとデータベースの両方が対象になっているかを確認します。初期設定ではデータベースだけ、という場合があります。
  • 頻度と時間帯。アクセスの少ない深夜に寄せます。取得中はサイトが重くなることがあるためです(表示が遅い原因と高速化もあわせてどうぞ)。
  • 保管先。サーバー内ではなく、外部のクラウドストレージを指定します。ここが自動化のいちばんの利点です。
  • 残す世代数。何回分を保持するかを決めます。古いものから自動で消える設定にしておくと、容量が膨らみません。

プラグインはWordPress公式ディレクトリのバックアップ一覧から選べます。選ぶときは、更新が続いているかを最初に見てください。

もう一点。バックアップのために新しくプラグインを増やすなら、既存の構成と重ならないかを確かめてください。同じ役割が2つ動くと、かえって不具合の元になります。詳しくはプラグインの選び方と入れすぎの注意点をご覧ください。

この章のポイント:自動化の価値は、手間が減ることより保管先を外に置けることです。設定したら、月に一度は結果を確認してください。

06サーバーの自動バックアップだけに頼らない

要点:レンタルサーバーの自動バックアップは便利ですが、これだけでは足りません。保管先がサーバーと同じ場所にあること、取り出しに申請と時間が要ること、保持期間が短いことが理由です。補助として数えてください。

足りない理由は3つあります。どれも、いざというときに響いてきます。

  • 保管先が同じ場所にある。サーバー側で障害が起きると、バックアップも一緒に取り出せなくなります。サイトが表示されない原因の多くは、この状況で起こります。
  • 取り出しに時間がかかる。申請してから数時間、プランによっては別料金という場合もあります。急いでいるときほど、この待ち時間が響きます。
  • 保持期間が短い。直近数日分だけ、という設定が一般的です。改ざんに数週間気づかなければ、正常な状態のデータはもう残っていません。

3つ目は軽く見られがちですが、実害が大きい部分です。IPAの「情報セキュリティ10大脅威 2026」では、組織向けの1位がランサム攻撃による被害でした。暗号化されると、同じサーバー上のバックアップも巻き込まれます。

狙われ方の実例は放置したWordPressが危険な理由で、引っ越し時の注意はサーバー移転の手順でまとめています。

この章のポイント:サーバー機能は「あると助かる保険」です。本体のバックアップは、別の場所に自分で持ってください。

07原因別・バックアップから戻した理由の内訳

要点:実際に戻すことになった理由を集計すると、更新後の不具合が最も多く、次いで操作ミスでした。攻撃を受けたケースは1割ほどです。バックアップは、日常の作業でこそ使います。WordPressの更新の判断とあわせてご覧ください。

復旧の依頼を受けた案件を、きっかけごとに分類しました。あわせて、異常に気づくまでの時間も並べています。

原因別・バックアップから戻した理由
WordPressサイトをバックアップから復元することになった原因の内訳と気づくまでの時間を集計したデータ
きっかけ 割合 気づくまでの時間
更新後の表示不具合 38% 当日中
誤って消した・上書きした 27% 数時間〜数日
プラグイン同士の競合 16% 当日〜数日
不正アクセス・改ざん 11% 数日〜数週間
サーバー側の障害 8% 即時

出典:ZenWeb Japanが対応したWordPressサイトの復旧記録、2024〜2026年、日本国内。

上の2つで6割を超えます。大半は、自分たちの作業がきっかけです。

右の列も見てください。改ざんだけ、気づくまでが数週間に伸びています。保持期間の短いバックアップでは間に合わない理由が、ここにあります。

この章のポイント:バックアップが要るのは、攻撃されたときより日常の更新作業のときです。作業の直前に1回取る習慣が、いちばん役に立ちます。

更新のたびに不安になる状態を、やめませんか。

取得から復元までを含めた月額の目安をお伝えします。 保守費用の内訳を確認する →


08頻度と世代数の決め方

要点:頻度は更新の多さで決めます。世代数は3〜5回分が目安です。「どこまで巻き戻れれば困らないか」から逆算すると決めやすくなります。WordPress制作でも、この順番でご提案しています。

決め方は、次の2つを考えるだけです。

  • 頻度は「やり直せる作業量」で決める。週1回しか更新しないサイトなら、月1回でも失うのは数記事です。毎日更新するサイトで月1回なら、1か月分が消えます。
  • 世代数は「気づくまでの遅れ」で決める。1世代だけだと、壊れた状態のまま上書きされる危険があります。改ざんは気づくのが遅れがちです。

公式ドキュメントでも、3〜5世代を別々の場所に持つことが勧められています。手元に3世代あれば、1つが壊れていても次を試せます。

この章のポイント:頻度は「やり直せる作業量」、世代数は「気づくまでの遅れ」から決めます。どちらも3世代を下限に考えてください。

09更新頻度の帯別・取得間隔と世代数の目安

要点:更新の頻度ごとに、実際に設定している取得間隔と世代数をまとめました。自社サイトがどの行に近いかを見て、そのまま目安として使ってください。

メンテナンスしている企業サイトの設定を、更新の頻度で4つの帯に分けて集計しました。右端は、最悪の場合に巻き戻る量です。

更新頻度の帯別・設定の目安
サイトの更新頻度ごとにバックアップの取得間隔と保管世代数と保管先の数を集計したデータ
更新の頻度 取得の間隔 残す世代 保管先の数 最大の巻き戻し
月1回未満 月1回+作業前 3世代 2か所 約1か月分
月2〜3回 週1回+作業前 4世代 2か所 約1週間分
週1回以上 毎日 7世代 2か所 約1日分
ほぼ毎日(ECや会員サイト) 毎日+データベースは数時間おき 14世代 3か所 数時間分

出典:ZenWeb JapanがメンテナンスしているWordPressサイトの設定記録、2026年時点、日本国内。

いちばん下の行だけ、データベースを別枠で取っています。注文や会員登録は、ファイルではなくデータベース側に積み上がるためです。

この章のポイント:更新が週1回を超えたら、毎日の自動取得に切り替えどきです。世代は7回分を目安にしてください。

10保管先はサーバーの外にも1つ持つ

要点:保管先は、サーバー内とサーバー外の2か所以上に分けてください。同じ場所に置いたバックアップは、サーバーが止まった瞬間に一緒に使えなくなります。分けるだけで、戻せる確率がはっきり変わります。

データを守る分野では、3-2-1という考え方が広く使われています。コピーを3つ持ち、2種類の媒体に置き、うち1つは別の場所に保管する、というものです。

WordPressに置き換えると、こうなります。

  • サーバー内に1つ。いちばん早く戻せる場所です。日常の巻き戻しはここから行います。
  • クラウドストレージに1つ。サーバーが止まっても取り出せます。自動化するなら、ここを既定の保管先にしてください。
  • 手元やNASに1つ。月次など節目のものだけで構いません。クラウド側のアカウント事故に備える枠です。

WordPress公式のバックアップ解説でも、少なくとも3〜5世代を、サーバー・クラウド・手元のパソコンなど場所を分けて保管することが勧められています。特別な運用ではなく、標準的な考え方です。

あわせて、保管先そのものの守りも確認してください。管理画面の入口が弱いままだと、バックアップの設定ごと書き換えられます。WordPressのセキュリティ対策で最低限の項目をまとめています。

この章のポイント:2か所目をサーバーの外に置いてください。この1手間だけで、サーバー障害と改ざんの両方に備えられます。

11復元テストをして、はじめて完成する

要点:取ったバックアップは、一度戻してみるまで使えるかどうか分かりません。年に一度でいいので、本番とは別の場所に戻す練習をしてください。ここを飛ばした現場ほど、いざというときに時間がかかっていました。

復元テストとは、バックアップからサイトを別の場所に組み立て直してみることです。テスト用のサーバーやローカル環境を使い、本番には触れずに行います。

見るのは次の4点です。どれか1つでも引っかかったら、その設定はまだ完成していません。

  • データベースが読み込めるか。文字コードの違いで、日本語が文字化けすることがあります。書き出しの設定を見直す合図です。
  • 画像が欠けずに表示されるか。アップロード済みのファイルが多いサイトほど、取りこぼしが起きます。
  • 業務に直結する機能が動くか。フォーム、予約、会員ログインなど。表示が戻っても、ここが動かなければ復旧とは言えません。
  • 戻し終わるまでに何時間かかるか。この数字を知っているかどうかが、当日の判断を変えます。

戻せずに作り直すとなれば、ワイヤーフレームの作成から設計をやり直し、原稿と画像も集め直しです。年に一度のテストとは、時間も費用も比べものになりません。

この章のポイント:戻したことがないバックアップは、まだバックアップではありません。年に一度、練習の時間を取ってください。

12年別・復元にかかった時間の推移

要点:復元にかかった時間は、事前にテストをしている現場ほど短くなります。2024年から2026年までの平均を並べました。ツールが良くなっても、この差は縮まっていません。

復旧を担当した案件を、直近1年以内に復元テストをしていたかどうかで2つに分け、実際にかかった時間の平均を年ごとに出しました。

年別・復元にかかった時間の平均
復元テストの実施有無ごとに復旧にかかった時間の平均を年別に集計したデータ
テストあり テストなし
2024年 1.8時間 9.4時間 7.6時間
2025年 1.5時間 8.7時間 7.2時間
2026年 1.2時間 8.1時間 6.9時間

出典:ZenWeb Japanが対応したWordPressサイトの復旧記録、2024〜2026年、日本国内。

どちらの列も少しずつ短くなっています。それでも差は7時間前後のまま、ほとんど動いていません。

テストなしの側で時間を取られているのは、復元の作業そのものではありません。どのファイルが最新かを探す時間です。

この章のポイント:差を生むのは道具ではなく、一度やったことがあるかどうかです。年1回のテストが、7時間分の余裕になります。

13制作会社に任せるときの進め方

要点:メンテナンスを任せる場合は、取得の頻度・保管先・世代数・復元の担当と目標時間を契約前に確認してください。「バックアップあり」の一言では、中身がまったく違います。

見積書に「バックアップ対応」と書かれていても、サーバー機能に任せているだけの場合があります。次の5点を聞けば、実態が分かります。

  • 取得の頻度と対象。毎日か週1回か。ファイルとデータベースの両方が入っているか。
  • 保管先の数と場所。サーバー外に1つあるかどうかが、いちばん大事な質問です。
  • 残す世代数。3世代未満なら、その理由を確認してください。
  • 復元の担当と目標時間。誰が作業し、何時間以内に戻す約束かを書面に入れます。
  • 復元テストの頻度。年1回でも実施しているかどうかで、実力が見えます。

費用の考え方はホームページ保守費用の相場で整理しています。見えにくい項目ですが、止まったときの損失で見れば、いちばん安い保険です。

この章のポイント:「バックアップあり」で終わらせず、頻度・保管先・世代数・復元時間の4つを書面で確認してください。

14まとめ|WordPressのバックアップ方法

要点:WordPressのバックアップ方法は、手動・プラグイン・サーバー機能の3つです。ファイルとデータベースの両方を取り、保管先をサーバーの外にも1つ持ち、年に一度は戻す練習をしてください。

ここまでの内容を整理します。

  • 保存するのは2種類。ファイルとデータベース。片方だけでは元に戻りません。
  • 手動は作業前の1回に使う。日常の備えとしては続かないことを前提に考えます。
  • 自動化の価値は保管先にある。手間が減ること以上に、サーバー外へ置けることに価値があります。
  • 出番の6割は日常の作業。更新後の不具合と操作ミスが、戻す理由の上位でした。
  • 戻したことがあるかどうかで7時間の差。年1回のテストが、当日の余裕になります。

バックアップは、使わずに済むのがいちばんです。ただ、使う日は前触れなく来ます。今日のうちに、保管先が2か所あるかだけでも確かめてみてください。


15よくある質問

要点:WordPressのバックアップ方法について、よくいただく質問をまとめました。

1. バックアップはどれくらいの頻度で取ればいいですか?

更新の多さで決めてください。月に1回程度しか更新しないサイトなら月1回、週1回以上更新するなら毎日が目安です。加えて、プラグインやテーマを更新する直前にも1回取ってください。戻すことになる理由でいちばん多いのが、この更新後の不具合です。

2. プラグインとサーバーの自動バックアップ、どちらを使うべきですか?

両方あると安心ですが、主役はプラグイン側にしてください。サーバー機能は保管先がサーバーと同じ場所にあり、取り出しに申請と時間がかかる場合があります。プラグインなら、クラウドストレージなど外部を保管先に指定できます。サーバー機能は補助として数えてください。

3. バックアップファイルはどれくらい残しておけばいいですか?

3〜5世代が目安です。1世代だけだと、壊れた状態や改ざんされた状態のまま上書きされる危険があります。改ざんは気づくまでに数週間かかることもあるため、更新の多いサイトでは7世代ほど持っておくと安心です。古いものから自動で消える設定にしておけば、容量も膨らみません。

4. 復元テストは本番サイトでやっても大丈夫ですか?

本番では行わないでください。テスト用のサーバーやローカル環境に戻して確認します。本番に上書きすると、正常な現在の状態まで消えてしまいます。当社のメンテナンスでは、検証用の環境を別に用意して年1回試しています。手順が分からない場合は、制作会社に相談してみてください。

5. サイトが真っ白になりました。すぐバックアップから戻すべきですか?

戻す前に、いまの状態のバックアップを1つ取ってください。原因を調べる材料になりますし、戻した結果さらに悪くなった場合の退路にもなります。そのうえで、直前に何をしたかを思い出してください。更新やプラグイン追加の直後なら、その1つ前の世代に戻すのが最短です。

戻せる状態かどうか、一度確かめませんか。

ZenWeb Japanは2000年創業、日本品質を適正価格でご提供しています。バックアップの設定確認から保管先の見直し、復元テスト、公開後のメンテナンスまで一貫して対応します。お気軽にお問い合わせください。

無料で相談する →

まずは、いまお困りのことを聞かせてください

ご相談は無料です。要件が固まっていない段階でも構いません。内容をうかがったうえで、進め方とお見積りをご提案します。