WordPressバックアップの方法と確認ポイント｜復元できる状態で運用するための実務ガイド

WordPressで会社のホームページを運用していると、「バックアップは取っておいた方がよい」と聞くことは多いと思います。

しかし実務上は、バックアップを取っているつもりでも、いざトラブルが起きたときに復元できないケースがあります。

ファイルだけ保存していてデータベースが残っていない、サーバー内にしか保存していない、バックアップはあるが戻し方がわからない、といった状態です。

WordPressのバックアップで重要なのは、単にデータを保存することではありません。

更新や改修、不具合発生時に、必要な状態へ戻せるように管理しておくことです。

この記事では、中小企業の経営者やWeb担当者向けに、WordPressバックアップで保存すべきもの、主なバックアップ方法、確認すべき運用ポイント、自社対応と専門家に相談すべき境界線を解説します。

WordPressのバックアップは「ファイル」と「データベース」の両方が必要

WordPressのバックアップでは、サイトを構成しているデータを一式保存する必要があります。

ここで押さえておきたいのは、WordPressサイトは大きく「ファイル」と「データベース」に分かれているという点です。

WordPress公式でも、WordPressサイトのバックアップは「データベース」と「ファイル」の2つに分かれ、一般的なWordPressサイトを復元するには両方が必要だと説明されています。

どちらか一方だけを保存していても、サイト全体を正しく復元できない場合があります。

たとえば、見た目のデザインや画像は残っていても、投稿記事や固定ページの本文が戻らないことがあります。

逆に、投稿データは残っていても、テーマや画像が消えてしまい、ページ表示が崩れることもあります。

ファイルに含まれるもの

WordPressのファイルには、主にサイトの見た目や機能に関わるデータが含まれます。

企業サイトで特に注意したいのは、画像やPDFなどのアップロードファイルです。

施工事例、実績紹介、採用ページの写真、ホワイトペーパーなどを多く掲載している場合、これらが失われると復旧に時間がかかります。

また、制作会社や担当者がテーマファイルを直接編集している場合、その変更内容がバックアップされていないと、復元後にデザインや機能が元に戻らないことがあります。

データベースに含まれるもの

データベースには、WordPress管理画面から登録・編集した情報が保存されています。

データベースが失われると、記事本文や固定ページの内容、各種設定が戻らなくなる可能性があります。

企業サイトでは、サービスページ、採用情報、コラム、導入事例など、日々の運用で蓄積した情報が大きな資産になります。

特にECサイト、予約サイト、会員サイト、問い合わせ履歴をWordPress内に保存しているサイトでは、データベースの扱いに注意が必要です。

復元のタイミングを誤ると、直近の注文や問い合わせ情報まで上書きしてしまう可能性があります。

片方だけでは復元できない理由

WordPressのバックアップでよくある失敗は、「ファイルだけ」「データベースだけ」のどちらかしか保存していない状態です。

ファイルだけを保存している場合、テーマや画像は残っていても、投稿や固定ページの本文、管理画面上の設定が戻らないことがあります。

反対に、データベースだけを保存している場合、記事の内容は残っていても、画像やテーマファイルが不足して正しく表示されないことがあります。

自社のバックアップ状況を確認する場合は、まず次の2点を確認してください。

1. WordPressのファイル一式が保存されているか
2. データベースのバックアップも保存されているか

この2つが確認できない場合、「バックアップを取っている」とは言い切れません。

特に、サーバー管理画面やプラグインで自動バックアップを設定している場合でも、何が保存対象になっているかまでは確認しておく必要があります。

WordPressでバックアップが必要になるタイミング

バックアップは、トラブルが起きてから取るものではありません。

サイトに変更を加える前に、戻せる状態を作っておくためのものです。

特にWordPressは、テーマ、プラグイン、サーバー環境、PHPバージョンなどが組み合わさって動いているため、小さな変更に見えても、サイト全体に影響が出ることがあります。

WordPress本体・テーマ・プラグインを更新する前

WordPress本体、テーマ、プラグインを更新する前には、事前にバックアップを確認しておくのが基本です。

特に、長期間更新していないサイトや、フォーム・予約・EC機能があるサイトでは、更新後の不具合に備えて、作業前の状態へ戻せるかを確認してから進めるべきです。

更新そのものは、セキュリティや機能改善のために必要です。ただし、更新後に以下のような不具合が起きることがあります。

• サイトの一部が表示されなくなる
• 管理画面にログインできなくなる
• お問い合わせフォームが動かなくなる
• レイアウトが崩れる
• プラグイン同士が干渉する

特に、長期間更新していなかったWordPressを一気に更新する場合は注意が必要です。

バージョン差が大きいほど、テーマやプラグインとの互換性問題が起きやすくなります。

自社で更新する場合は、少なくとも

「更新前のバックアップがあるか」
「管理画面に入れなくなった場合の復元方法がわかるか」

を確認してから作業するべきです。

どちらも不明な場合は、更新ボタンを押す前に確認した方が安全です。

デザインやコードを変更する前

トップページの見た目を変える、ボタンを追加する、CSSを修正する、テーマファイルを編集する。

このような作業前にもバックアップは必要です。

WordPressの編集作業では、1か所の変更が予想外の箇所に影響することがあります。

たとえば、ヘッダーのデザイン調整をしたつもりが、スマホ表示だけ崩れる。

フォームの文言を変えたつもりが、自動返信メールの設定に影響する。こうしたことは実務で珍しくありません。

管理画面上で完結する軽微なテキスト修正であれば、毎回フルバックアップまでは不要な場合もあります。

ただし、テーマファイル、functions.php、CSS、JavaScript、プラグイン設定に触る場合は、作業前の状態へ戻せるようにしておいた方が良いでしょう。

判断基準としては、次のように考えるとよいです。

「少しだけ直すつもりだった」という作業ほど、事前バックアップが抜けやすくなります。

社内担当者が作業する場合でも、外部に依頼する場合でも、作業前にバックアップの有無を確認する流れを作っておくことが重要です。

サーバー移転・不具合対応・リニューアルの前

サーバー移転、ドメイン変更、リニューアル、不具合対応の前には、通常の更新作業以上にバックアップが重要になります。

これらの作業では、WordPress本体だけでなく、サーバー設定、データベース、ドメイン、SSL、メール設定などが関係する場合があります。

バックアップが不十分なまま作業を進めると、サイトが表示されないだけでなく、メールやフォーム送信にも影響することがあります。

不具合対応時も注意が必要です。すでにサイトが壊れている場合、焦って復元や更新を行うと、原因の切り分けが難しくなることがあります。

たとえば、表示崩れの原因がテーマなのか、プラグインなのか、サーバー環境なのかを確認しないまま復元すると、別の問題を引き起こす可能性があります。

サーバー移転やリニューアルでは、作業前のバックアップに加えて、作業後の動作確認も必要です。

表示、フォーム送信、管理画面ログイン、SSL、スマホ表示、主要ページのリンク切れなどを確認して、初めて安全に移行できたと判断できます。

WordPressバックアップの主な方法を比較

WordPressのバックアップ方法には、主に

1. サーバーの自動バックアップ
2. プラグインによるバックアップ
3. FTPやphpMyAdminを使った手動バックアップ

があります。

どの方法が正解というよりも、自社の運用体制、担当者のスキル、サイトの重要度、復元時の対応力によって選ぶべき方法が変わります。

サーバーの自動バックアップ

多くのレンタルサーバーには、自動バックアップ機能が用意されています。サーバー側で一定期間分のデータを保存してくれるため、設定が簡単で、WordPress管理画面に入れない場合でも復元できる可能性があります。

ただし、サーバーの自動バックアップは、契約しているサーバー会社やプランによって内容が異なります。

サーバー自動バックアップは便利ですが、「サーバーに機能があるから安心」とは限りません。

復元できる範囲や条件を確認していないと、必要なタイミングで使えない可能性があります。

特に複数サイトを同じサーバーで管理している場合は、復元によって他サイトに影響が出ないか確認が必要です。

プラグインによるバックアップ

WordPress管理画面からバックアップを設定したい場合は、バックアップ用プラグインを使う方法があります。

代表的なものとして、BackWPupなどのプラグインがあります。

プラグインを使うメリットは、WordPress管理画面内でバックアップ設定やスケジュール管理がしやすいことです。

自動バックアップを設定すれば、定期的にファイルやデータベースを保存できます。

一方で、プラグインによるバックアップにも注意点があります。

1. バックアップファイルがサーバー容量を圧迫する場合がある
2. 保存先がサーバー内だけだと、サーバートラブル時に弱い
3. プラグイン自体の不具合や更新停止リスクがある
4. 復元作業は別途手順を理解しておく必要がある
5. 大規模サイトではバックアップ処理が途中で止まる場合がある

プラグインを入れているだけでは不十分です。

バックアップが正常に作成されているか、どこに保存されているか、復元時にどのファイルを使うのかまで確認しておく必要があります。

あまり容量が大きくないサイトであれば、プラグインによる自動バックアップは有効な選択肢です。

ただし、問い合わせや売上に直結するサイトでは、サーバー側のバックアップや外部保存と組み合わせた方が安全です。

FTP・phpMyAdminによる手動バックアップ

FTPを使ってファイルを取得し、phpMyAdminなどでデータベースをエクスポートする方法もあります。

この方法は、制作会社や技術者が対応する場合には有効です。

必要なファイルやデータベースを細かく確認でき、サーバー移転や復元作業でも使われます。

ただし、初心者や社内担当者がいきなり手動バックアップを行うには、ややハードルがあります。

特にデータベース操作を誤ると、サイトの内容に大きな影響が出る可能性があります。

自社で選ぶ場合は、「バックアップを取れるか」だけでなく、「トラブル時に誰が復元するのか」まで考える必要があります。

復元担当者がいない場合は、プラグインだけに頼るよりも、保守会社や制作会社と復旧手順を確認しておく方が現実的です。

WordPressバックアップ設定で確認すべき保存先・頻度・保持期間

バックアップ方法を決めたら、次に確認すべきなのは運用面です。

実務では、バックアップ設定を一度入れて終わりにしてしまうケースがあります。

しかし、保存先、頻度、保持期間、成功確認が曖昧なままだと、必要なときに使えない可能性があります。

保存先・頻度・保持期間を決める

バックアップ運用では、保存先、頻度、保持期間をセットで考える必要があります。

たとえば、月に1回しか更新しない会社案内サイトであれば、週1回程度のバックアップでも足りる場合があります。

一方で、コラムを頻繁に更新しているサイト、問い合わせフォームの送信履歴を保存しているサイト、ECサイトなどは、より短い間隔でのバックアップが必要です。

保持期間も重要です。直近1回分しか残していない場合、問題に気づいた時点ですでに壊れた状態のバックアップしか残っていない可能性があります。

最低でも複数世代を残しておくと、問題発生前の状態に戻しやすくなります。

バックアップ成功ログを確認する

自動バックアップを設定していても、実際には失敗していることがあります。

よくある原因としては、

• サーバー容量不足
• タイムアウト
• プラグインの不具合
• 保存先の認証エラー
• データ量の増加

などがあります。

特に画像が多いサイトでは、バックアップファイルが大きくなり、処理が途中で止まることがあります。

バックアップ設定後は、次の点を定期的に確認してください。

• 最新のバックアップ日時
• バックアップ成功・失敗のログ
• バックアップファイルの容量
• 保存先にファイルが残っているか
• エラーメールや通知が届いていないか

確認頻度は、サイトの重要度によって変わります。

会社案内サイトであれば月1回程度の確認でもよい場合がありますが、EC機能が入っているなど、問い合わせや売上に直結するサイトでは、更新作業前後や定期保守時に確認するのが安全です。

「自動だから見なくてよい」と考えると、いざというときに使えないバックアップを何か月も取り続けていた、という状態になりかねません。

サーバー内だけに保存しない

バックアップファイルを同じサーバー内にだけ保存している場合、そのサーバーに障害が起きたときにバックアップも取り出せなくなる可能性があります。

また、バックアップファイルがサーバー容量を圧迫し、サイト表示やメール運用に影響することもあります。

WordPressの画像、PDF、動画、バックアップファイルが積み重なると、想定以上に容量を使うことがあります。

重要度の高いサイトでは、以下のような保存方法を検討するとよいです。

1. サーバー自動バックアップ
2. WordPressプラグインによるバックアップ
3. クラウドストレージへの外部保存
4. 制作会社・保守会社側でのバックアップ保管

ただし、外部保存を増やせばよいというわけではありません。

保存先が多くなるほど、管理アカウント、権限、削除ルール、個人情報の扱いも整理する必要があります。

実務上は、「誰が」「どこに」「何日分を」「どの手順で戻せる状態で」管理しているかを明確にしておくことが重要です。

WordPressバックアップは「復元できる状態」か確認することが重要

WordPressバックアップで最も見落とされやすいのが、復元できるかどうかです。

バックアップファイルが存在していても、復元方法がわからなければ実務では使えません。

また、復元するタイミングや対象を誤ると、正常なデータまで失う可能性があります。

バックアップファイルがあるだけでは不十分

バックアップファイルがある状態と、復元できる状態は違います。

たとえば、以下のような状態では、バックアップがあっても安心とは言えません。

• どのバックアップが最新かわからない
• ファイルだけでデータベースがない
• バックアップファイルの保存場所が担当者しかわからない
• 復元手順を確認したことがない
• 復元すると直近の問い合わせや注文が消える可能性がある
• バックアップファイルが壊れているか確認していない

特に企業サイトでは、担当者の退職や外注先の変更によって、管理情報がわからなくなることがあります。

サーバー契約者、ドメイン管理者、WordPress管理者、バックアップ保存先がバラバラになっている場合、復元作業の前に情報整理から始めなければなりません。

バックアップ運用を確認する際は、「ファイルがあるか」ではなく、「誰が見ても復元に必要な情報へたどり着けるか」を基準にしてください。

復元前に確認すべきこと

トラブルが起きたときに、すぐバックアップから戻せばよいとは限りません。

復元前には、少なくとも次の点を確認する必要があります。

たとえば、プラグイン更新後に表示崩れが起きた場合、サイト全体を数日前に戻すより、該当プラグインやテーマ周辺を確認した方がよい場合があります。

一方で、誤って固定ページを削除した場合は、データベースの復元が関係する可能性があります。

ECサイトや予約サイトでは、復元によって注文や予約情報が巻き戻るリスクがあります。

このようなサイトでは、安易に全体復元を行うのではなく、どのデータを残し、どの範囲を戻すのかを慎重に判断する必要があります。

復元テスト・ステージング環境の考え方

重要なサイトでは、バックアップを取るだけでなく、復元テストを行うことも検討すべきです。

復元テストとは、バックアップデータを使って、実際にサイトを戻せるか確認する作業です。

本番サイトで直接試すのではなく、ステージング環境と呼ばれる検証用の環境で行うのが一般的です。

ステージング環境があると、次のような確認がしやすくなります。

1. バックアップファイルが正常に使えるか
2. 復元後にページが表示されるか
3. フォームやボタンが動くか
4. スマホ表示が崩れていないか
5. 更新や改修を本番反映前に検証できるか

復元テストまで行う余裕がない場合でも、最低限

• バックアップの保存場所
• 復元に使う管理画面
• 復元担当者
• 復元後の確認項目

は整理しておくべきです。

WordPressバックアップを自社で対応してよいケース・相談すべきケース

WordPressのバックアップは、自社で対応できる範囲もあります。

ただし、すべてを社内で対応しようとすると、かえって復旧が難しくなるケースもあります。

判断のポイントは、作業の難易度ではなく、失敗した場合の影響範囲です。

会社案内サイトの軽微な作業と、問い合わせ・注文・予約に関わるサイトでは、同じバックアップ作業でもリスクが異なります。

自社で対応しやすいケース

次のようなケースであれば、自社でバックアップ設定や確認を進めやすい場合があります。

1. 会社案内中心のシンプルなサイト
2. 更新頻度が少ないサイト
3. サーバー管理画面にログインできる
4. WordPress管理者情報が整理されている
5. バックアッププラグインの基本設定を理解できる
6. トラブル時にすぐ相談できる相手がいる

自社で対応する場合は、まずサーバーの自動バックアップ機能を確認し、そのうえでWordPress側でもバックアップを設定する流れが現実的です。

ただし、自社対応する場合でも、復元方法まで一度確認しておく必要があります。

専門家に相談した方がよいケース

次のような場合は、バックアップや復元を自社だけで判断しない方が安全です。

特に復元作業は、誤ると現在のデータを上書きしてしまう可能性があります。バックアップファイルがあるからといって、すぐに全体を戻すのではなく、何を戻すべきかを判断することが重要です。

専門家に相談する場合は、以下の情報を事前に整理しておくと話が早くなります。

1. サイトURL
2. 不具合が起きた日時
3. 直前に行った作業
4. サーバー会社名
5. WordPress管理画面にログインできるか
6. バックアップの有無と保存場所
7. 問い合わせや注文など、消えて困るデータの有無

これらが整理されていると、復元すべきか、原因調査を優先すべきか、部分的な修正で済むのかを判断しやすくなります。

まとめ

WordPressのバックアップは、単にデータを保存しておけばよいものではありません。

ファイルとデータベースの両方を保存し、必要なタイミングで復元できる状態にしておくことが重要です。

特に中小企業のサイトでは、担当者が兼任だったり、サーバーやドメインの管理情報が整理されていなかったりすることがあります。

その状態でトラブルが起きると、復元作業そのものよりも、必要な情報を探すことに時間がかかります。

まずは、次の項目を確認してみてください。

• ファイルとデータベースの両方がバックアップされているか
• 直近のバックアップ日時を確認できるか
• 保存先がサーバー内だけになっていないか
• 復元方法と復元担当者が明確になっているか
• WordPress更新前にバックアップを確認する運用になっているか

自社で判断が難しい場合や、すでに不具合が起きている場合は、復元作業を進める前に、現在のバックアップ状況と不具合の原因を確認することをおすすめします。

特に、管理画面にログインできない、サイトが表示されない、問い合わせや注文データが関係する場合は、安易にバックアップを戻す前に、保存先・復元方法・影響範囲を専門家に確認した方が安全です。

バックアップの有無だけでなく、保存先、復元方法、更新前の確認手順まで整理したい場合は、WordPressの保守・管理状況を一度点検しておくと安心です。

自社サイトの状態を一度確認し、必要に応じてバックアップ体制を見直しておきましょう。