ワードプレス バックアップ｜中小企業の発信担当者が月1回安全に運用する手順

「もしサイトが消えたら、復旧できますか？」

中小企業の経営者や発信担当者と話していると、この質問への答えが詰まる方が本当に多くいらっしゃいます。

ワードプレスのバックアップは、面倒な作業に見えて後回しになりがちな運用業務です。一方で、サーバー障害・プラグインの不具合・乗っ取りなど、想定外の事故は突然やってきます。

ハッシンラボが中小企業のサイト運用を支援する中で見えてきたのは、バックアップは月1回5分の習慣に絞れるという事実でした。完璧な体制を目指すのではなく、続けられる仕組みに落とし込むことが、企業の資産を守る最短ルートになります。

この記事では、守るべき3つのデータ、無料プラグインの選び方、復元手順、月1回5分の運用フローまでを一気通貫で整理します。あわせてホームページ運営7原則もご参照ください。

まずはバックアップ運用の全体像を、1枚の図で押さえましょう。

この記事の著者

飯塚 昭博

Akihiro Iitsuka

コントリ株式会社 代表取締役

青山学院大学卒業後、自動車会社にて年間180億円規模の設備調達を担当。中小企業経営者の想いに触れる中でその価値を伝えることに使命を感じ、2023年独立。経営者インタビューメディア「コントリ」を運営し、100社以上の経営者を取材。SEO・AI活用・発信設計を通じて中小企業の「伝わる発信」を支援している。

comtri.jp ハッシンラボ note

ワードプレス バックアップとは｜中小企業が必ず取るべき理由

ワードプレス バックアップは、サイトのデータを別の場所に複製して保存する作業です。プラグインの不具合・サーバー障害・誤操作・ハッキングなど、想定外のトラブルから自社サイトを守る最後の砦になります。

中小企業の発信現場では、バックアップは「面倒で後回しになる業務の代表格」です。発信担当者が1人で兼務しているケースが多く、緊急性が低く見えるためです。ただ、事故は予兆なく起きます。

ハッシンラボの支援先でも、バックアップなしでプラグイン更新を行い、画面が真っ白になった企業様を複数見てきました。「攻撃されてから取る」では遅いのがバックアップ業務の難しさです。

バックアップなしで起こる3つの典型トラブル

中小企業のサイトで実際に発生しているバックアップなしのトラブルは、大きく3つに分類できます。プラグイン更新後の不具合・サーバー障害・乗っ取り（ハッキング）の3パターンです。

最も頻発するのは、プラグイン更新後の不具合です。WordPress本体や個別プラグインの更新後、別プラグインとの相性問題で画面が真っ白になる現象。専門用語で「White Screen of Death」と呼ばれます。バックアップがあれば数分で戻せますが、なければ復旧に数日〜数週間かかります。

サーバー障害はレンタルサーバー側の不具合や障害です。サーバー会社のバックアップから戻せる事例はありますが、保管期間や復元範囲はサーバー会社の規約に依存します。自社の手元にもバックアップを置いておく備えが安全策になります。

中小企業ほど早めに仕組み化すべき理由

中小企業はサイト復旧の遅れがそのまま事業損失に直結します。大企業のように複数の販売チャネルやIT専門部署があるわけではないため、サイトが止まる＝集客が止まる構造です。

ハッシンラボの支援現場でも、サイト復旧に3日かかった企業様で、月の問い合わせの3割を失った事例があります。問い合わせフォームが動かないだけで、見込み客は競合のサイトに流れていきます。

逆に言えば、月1回のバックアップという地味な習慣が、企業の資産を長期的に守る投資になります。一時的な対応ではなく、蓄積型の備えとして位置づけるのが現実的な発想です。

バックアップで守るべき3つのデータ｜DBとファイルの違い

ワードプレスのバックアップ対象は、大きく3種類に分かれます。「データベース」「アップロードファイル」「テーマ・プラグイン」の3つです。それぞれ役割が違い、何を守れば何が復元できるかを理解しておくと、いざという時の判断が早くなります。

中小企業の発信担当者が陥りがちなのが、データベースだけバックアップしてファイルを取り忘れるパターンです。投稿は戻ったが画像が全部消えた、という事故が現場で繰り返されています。

本章で扱う3種類は、まずは「何が含まれているか」を頭に入れておくだけで十分です。具体的な取り方は次章で1ファイルにまとめる方法をご紹介します。

データベース：投稿・固定ページ・コメント

データベースとは、サイトのテキストデータを保管している場所です。投稿記事・固定ページ・カテゴリ・タグ・コメント・ユーザー情報など、文章ベースのデータがすべて入っています。

WordPressは内部的にMySQLまたはMariaDBというデータベースシステムを使ってデータを管理しています。MySQLとは、世界で広く使われているオープンソースのデータベース管理システムです。例えば、AmazonやFacebookなどの大規模サイトでも採用されている信頼性の高い仕組みになります。

データベース単独のバックアップは容量が小さい（数MB〜数十MB程度）ため、頻繁に取りやすい特徴があります。投稿頻度が高いサイトほど、データベースの優先度が上がります。

uploadsフォルダ：画像・PDF等のメディア

uploadsフォルダは、投稿に挿入した画像・PDF・動画などのメディアファイルを保管している場所です。WordPressのファイル構成上、wp-content/uploads/ というパスに格納されています。

メディアファイルの容量はサイトによって大きく変わります。テキスト中心のサイトで数百MB、画像を多用するサイトで数GBから10GBを超えるケースもあります。データベースより重いため、バックアップ時間が長くなりやすい部分です。

中小企業のサイトで画像を多く使う場合、uploadsフォルダの取り漏れが致命的になります。記事の本文は戻っても、画像がすべて表示されない状態になるため、ユーザー体験が大きく損なわれます。

テーマ・プラグイン：見た目と機能

テーマ・プラグインのフォルダは、サイトの見た目（テーマ）と機能（プラグイン）を構成するファイル群です。wp-content/themes/とwp-content/plugins/に格納されています。

このカテゴリは、WordPressの管理画面から再インストールできるという特徴があります。公式テーマや公式プラグインなら、復旧時に管理画面から入れ直せます。ただし、カスタマイズしたテーマや有料テーマは別途バックアップが必要です。

中小企業の場合、子テーマで独自デザインを実装しているケースが多くあります。子テーマとは、既存テーマの一部だけ書き換えたカスタマイズ版です。子テーマファイルは公式から再取得できないため、必ずバックアップ対象に含めてください。

プラグインでの取り方｜All-in-One WP Migrationの基本

中小企業の発信担当者に最適なのは、無料プラグイン「All-in-One WP Migration」です。専門知識がなくても、ボタン数クリックで全データを1ファイルに固められます。本章では基本手順とほかプラグインとの使い分けを整理します。

YouTubeのWordPress解説チャンネルでも、初心者向けの定番として広く推奨されています。Mizuna・狩生孝之・Upnet Japan等。中小企業の発信現場でも、迷ったらこれで運用開始するのが最短ルートです。

All-in-One WP Migrationの導入と初回バックアップ手順

All-in-One WP Migrationの導入手順はシンプルです。WordPress管理画面の「プラグイン → 新規追加」から検索してください。インストール・有効化まで3分以内に完了します。

導入後の初回バックアップ手順もシンプルです。左メニューの「All-in-One WP Migration」を開きます。「エクスポート」→「エクスポート先：ファイル」と選ぶだけ。サイト容量に応じて1〜10分でファイルが生成されます。

生成されたファイル（拡張子 .wpress）には、4要素がすべて1つに圧縮されます。データベース・ファイル・テーマ・プラグインを別々に取る必要がない手軽さが、このプラグインの最大のメリットです。

他の主要プラグイン（UpdraftPlus・BackWPup）との使い分け

WordPressバックアップの主要プラグインは3種類です。All-in-One WP Migrationのほかに「UpdraftPlus」「BackWPup」が定番。それぞれ得意分野が違うため、サイトの規模で使い分けるのが現実的になります。

UpdraftPlusはクラウド連携が強みです。Google Drive・Dropbox・Amazon S3などへ自動転送できます。サイトを開かずにバックアップが回り続けるため、運用負荷が下がります。

BackWPupは大規模サイト向けの選択肢です。データベースとファイルを別々にスケジュールしたり、差分バックアップが可能です。EC機能やフォーラムなど、毎日大量に更新が入るサイトに向いています。中小企業の標準サイトなら、All-in-One WP Migrationで十分です。

保存先の選び方｜PC・クラウド・サーバー外の3択

バックアップファイルの保存先は、「サーバーと違う場所」に必ず1つは置くのが鉄則です。サーバー上だけだと、サーバー障害時に同時消失します。

中小企業の現実的な選択肢は3つ。担当者のPC（社内NASも含む）・クラウドストレージ（Google Drive・Dropbox等）・外部HDDです。2か所以上に複製するのが安全運用の最低ラインになります。

筆者が支援する企業様の多くは、PC＋Google Driveの2か所体制で運用しています。Google DriveやDropboxの容量を活用すると、無料〜数百円の月額コストで現実的な仕組みが組めます。

バックアップから復元する手順｜万一の時に慌てない準備

バックアップは「取って終わり」では意味がありません。年に1回は復元のリハーサルをして、本当に戻せるか確認するのが本質的な備えです。本章では復元の基本手順と、テスト復元のすすめ方を解説します。

中小企業の現場で最も多い後悔は、「バックアップは取っていたが、復元のやり方を知らなかった」というパターンです。事故が起きてから初めて復元手順を調べると、復旧時間が数倍に伸びます。

筆者の支援先でも、年1回のテスト復元を導入して以降、復旧時間の見積もりが明確になった企業様が複数あります。「いざ」のための準備は、平時にこそ価値が出ます。

All-in-One WP Migrationでの復元手順

All-in-One WP Migrationでの復元はシンプルです。復元先サイトに同じプラグインを入れて、エクスポートファイルをインポートするだけ。3〜4ステップで完了します。

具体的な手順は4ステップです。①復元先にプラグインをインストール、②「インポート」を選択。③保存した .wpress をアップロード、④「続行」を押す。サイト容量に応じて5〜30分で復元が完了します。

注意点は、復元先のWordPress本体は事前にインストールしておく必要があることです。サーバーが完全に消えた場合、まずWordPress本体を入れ直してから、復元作業に移ります。

復元前に必ず確認したい3つのチェック項目

復元作業の前に、3つの項目を確認しておくと事故を防げます。「PHPバージョン」「WordPress本体のバージョン」「サーバー容量」の3点です。

PHPバージョンは、バックアップ取得時と復元先で大きく違うとエラーが出ます。たとえばPHP 7.4で取ったバックアップをPHP 8.2の新サーバーに戻す場合。古いプラグインが動かないケースがあります。

WordPress本体のバージョンも近い方が安全です。バージョン違いが3つ以上開くと、復元後にデータベースのアップグレード処理が必要になります。サーバー容量はバックアップファイル容量の3倍程度の空きを確保しておくと安全です。

年1回のテスト復元で備えを確実にする

年1回のテスト復元は、本番に影響を与えない方法で実施します。サブドメイン（例：test.your-site.com）を一時的に作成し、そこに復元する流れが最も安全です。

サブドメインの作成は、レンタルサーバーの管理画面から数クリックで可能です。テスト復元の完了後は、画面表示・画像表示・問い合わせフォームの動作を確認します。点検が終わったらサブドメインごと削除して終了です。

このテスト復元は年1回30分程度の作業です。地味ですが、本番障害が起きた時の精神的余裕が大きく変わります。中小企業のリスク管理として、年間カレンダーに必ず組み込んでおく価値があります。

中小企業が陥りがちな失敗パターン｜3つの落とし穴

中小企業のサイト運用支援の現場で頻発する、バックアップの取り方を誤って事故につながった3つのパターンを共有します。同じ轍を踏まないためのチェックポイントとして読み解いてください。

これらは特殊な失敗ではなく、業界一般のWordPress運用でも繰り返し指摘されているパターンです。中小企業の発信現場で起こりがちな構造として、3つに整理しました。

3つのパターンを把握しておくだけで、自社の運用ルールを見直す視点が得られます。次の図表でNG運用とOK運用を対比させて整理しました。

サーバー上だけに保存して同時に消えるパターン

最も多いのが、バックアップファイルをサーバー上の同じ場所に保存し続けるパターンです。一見「自動で取れている」状態ですが、サーバー側に障害が起きると、本体もバックアップも一緒に消えます。

たとえば、レンタルサーバーのディスク物理故障や、サーバー会社からのアカウント停止。これらが起きるとサーバー内の全ファイルが失われます。バックアップだけサーバー外に保管しておけば、別のサーバーで復元できますが、同じ場所だと打つ手がなくなります。

筆者の支援先でも、サーバー乗っ取り被害でアカウント停止された企業様の事例がありました。サーバー上のバックアップに全くアクセスできず、別の手段で集めた画像から再構築する事態に。月1回のダウンロードという地味な手間が、最後の保険になります。

プラグイン更新だけして取り忘れるパターン

「プラグイン更新の直前にバックアップを取る」という運用ルールがあっても、忙しさで忘れがちです。それがこのパターン。プラグイン更新で不具合が起きた時に、戻す手段がなくなります。

WordPressのプラグインは数百種類が日々更新されています。複数プラグインの相性問題が後から顕在化するケースも頻発しています。更新後すぐ動いていても、1週間後に別操作と組み合わさってエラーが出るパターンもあります。

対策は「更新前バックアップを必ず取る」という運用ルールを機械的に守る仕組み化です。月1回の定期バックアップに加えて、大きな更新作業の前は別途取る、という二段構えが現実的になります。

復元できるか試したことがないパターン

3つ目は、バックアップは取っているが復元手順を試したことがないパターンです。事故時に初めて手順書を読みながら作業することになり、復旧時間が数倍に伸びます。

このパターンの怖いところは、本人が「備えている」と思い込んでいる点です。バックアップファイルが破損して使えないケースがあります。復元手順を読み違えて状況を悪化させるケースも現場で発生しています。

年1回のテスト復元を組み込むだけで、このリスクは大幅に下がります。実際に手を動かしておくと、復元の感覚がつかめて、本番障害時の判断スピードが変わります。地味な準備が、事業の継続性を支える基盤になります。

月1回×5分の運用フロー｜発信担当者が継続できる仕組み化

中小企業のリソースで継続できるバックアップ運用の型をご紹介します。月1回5分で回せる手順と、年1回のテスト復元を組み合わせた最小単位の仕組みです。多忙な経営者・担当者でも回せます。

「やらないこと」を増やす設計でもあります。毎日取らない、自動化に頼り切らない、複雑なツールを使わない。絞り込みこそが継続の鍵になります。

筆者の支援先でも、複雑な自動化を組んだ企業様より、月1回手動の企業様の方が継続率が高い傾向です。シンプルな型を回し続ける方が、長期的な備えとして機能します。

STEP 1: 毎月◯日に手動バックアップを取る

最初のステップは、毎月決まった日にAll-in-One WP Migrationでバックアップを取ることです。所要時間は3分。日付を固定する（例：毎月1日）と運用が定着します。

ポイントは、カレンダーに繰り返し予定として登録しておくことです。Googleカレンダー等の普段使うツールに「ワードプレス バックアップ」を月初の予定として登録してください。通知が来たら3分の作業で完了です。

筆者の支援先では、給与振込日や月次レポート日と組み合わせている企業様が多くいらっしゃいます。既にある月次ルーチンに紐づけると、忘れにくくなります。

STEP 2: 保存先2か所に複製する

取得したバックアップファイルを、保存先2か所に複製します。所要時間は1分。PC（社内NAS）とクラウド（Google Drive・Dropbox等）の組み合わせが推奨です。

複製の意義は、片方が消えてももう片方が残るという冗長性にあります。PCが壊れてもクラウドに残る、クラウドのアカウントトラブルでもPCに残る、という構造です。

具体的にはGoogle Driveに月別フォルダ（例：2026-05/）を作り、その月のファイルを保存。同じファイルをPCのバックアップフォルダにもコピー。これで2か所体制が完成します。月3〜6か月分を保管しておくと、過去への巻き戻しも可能です。

STEP 3: 年1回のテスト復元で備えを点検する

最後のステップは、年1回のテスト復元です。所要時間は30分。前述のサブドメインを使ったテスト復元を、年1回のカレンダー予定として組み込みます。

実施タイミングは、サイトのリニューアル前後・年度切り替え時期・繁忙期前など、節目に合わせると忘れにくくなります。1月か4月のどちらかをテスト復元月として固定するのも一つの方法です。

テスト復元の結果は、簡単なメモ（A4用紙1枚）に残しておきます。実際の所要時間・気づいたエラー・修正したい運用ルールの3点を書き留めておくだけで十分です。翌年のテスト復元がさらにスムーズになります。月1回5分＋年1回30分という最小単位が、企業の資産を守る最も現実的な仕組み化につながります。

ワードプレス バックアップ｜よくある質問

中小企業の発信担当者・経営者から特によく寄せられる質問に、ハッシンラボの支援現場の視点で回答します。社内で同じ疑問が出たときの判断材料として、自由に持ち帰っていただいて結構です。

各回答は3分以内で読める短さに整理しました。気になるQから先に読んでも構いません。

ここで取り上げる5つの質問は、ハッシンラボの個別相談で実際に頻出するテーマを選びました。同じ疑問を抱える企業様が多い問いほど、共通の判断軸として組織内で共有しておく価値があります。

Q1: バックアップは月1回で十分ですか？

更新頻度が月数回の中小企業サイトであれば、月1回で十分です。週に複数本の記事を投稿するメディア型サイトの場合は週1回が目安になります。

プラグイン更新やテーマ変更など大きな作業の直前にも、追加で取るのが安全です。月次の定期＋作業前の追加、という二段構えが現実的な運用フローになります。

更新頻度が高くなれば、UpdraftPlus等のクラウド自動転送機能で日次バックアップに切り替える選択肢もあります。サイトの規模と運用負荷のバランスで判断してください。

Q2: 無料プラグインで本当に大丈夫ですか？

中小企業サイト（メディアサイズが小さく、複雑なEC機能等がないサイト）であれば、無料プラグインで十分実用に耐えます。All-in-One WP Migrationの無料版で全データを1ファイルに固められます。

サイト容量が大きい場合（数GB以上）や、差分バックアップが必要な場合は、有料版や別プラグインを検討してください。具体的には、サイト容量が500MB以上になったら、無料版のアップロード制限に注意が必要です。

判断基準としては、月の更新件数が10件未満で容量500MB以下なら無料版で十分。それ以上なら有料版や別プラグインに段階的に移行する流れが現実的です。

Q3: バックアップはどこに保存するのが安全ですか？

「サーバーと違う場所」に必ず1つは置いてください。具体的にはPC（社内NAS）+ クラウド（Google Drive、Dropbox等）の2か所が最低ラインです。

サーバー上だけだと、サーバー障害時に同時消失します。物理的に離れた2か所に複製することが、バックアップ運用の本質です。

特にGoogle Driveのビジネスプランは、5TBから容量を確保できるためコストパフォーマンスに優れています。中小企業の発信担当者が個人アカウントで保管するのではなく、組織アカウントで管理するのが運用上も安全です。

Q4: レンタルサーバーの自動バックアップ機能と何が違いますか？

レンタルサーバーの自動バックアップは便利な機能ですが、サーバー側のトラブル時に復元できなかった事例も報告されています。サーバー会社のシステム障害でバックアップごと消失するケース、保管期間が短くて遡れないケースが現場で発生しています。

プラグインでの自社バックアップを「自分の手元に置く保険」として併用するのが安全な運用です。サーバーの自動バックアップは「日常の保険」、プラグインは「最終手段の保険」と役割を分けると判断軸がブレません。

両方を運用していれば、片方が機能しなくてももう片方で復旧できます。中小企業のリスク管理として、この二段構えが現実的になります。

Q5: 復元にはどのくらい時間がかかりますか？

サイト容量100MB程度の小規模サイトなら、All-in-One WP Migrationで5〜15分ほどで完了します。容量500MBで15〜30分、1GB以上で30分〜1時間が目安です。

ただしこれは、復元先のサーバーが正常に動いている状態での時間です。サーバー自体に問題がある場合は、サーバー復旧から含めて数時間かかるケースもあります。

年1回のテスト復元で実際の所要時間を測っておくと、本番障害時の見積もりが正確に出せます。事業として「何時間で復旧できるか」を経営判断に組み込めば、その他の対応との優先順位が明確に整理できます。

まとめ｜月1回×5分の習慣で、企業の資産を守る

ワードプレス バックアップは、月1回5分の手動運用＋年1回のテスト復元という最小単位で十分です。中小企業のリソースで継続できる仕組みになります。完璧を目指すより、続けられる型を作ることが本質です。

All-in-One WP Migrationを軸に、PC＋クラウドの2か所保管、年1回のテスト復元を組み合わせる。3つの要素を回せば現実的なリスク管理が成立します。

まずは今月から、カレンダーに「ワードプレス バックアップ」の月次予定を入れてみてください。気負わず、小さく始めて流れを作ることが、半年後の事業継続性を支える第一歩になります。SNS発信の運用判断についてはこちらのインスタ インサイトの見方も参考になります。