BackWPup設定方法｜中小企業のWP資産を守る運用手順

「WordPressのサイトが急に真っ白になった」「昨日まで公開していた記事が、なぜか管理画面から消えた」。中小企業の発信担当者にとって、この瞬間は最悪の悪夢です。

しかも、影響を受けるのは目の前の1記事だけではありません。蓄積してきた数十本、数百本の記事は、企業にとって長期で効き続ける資産です。短期のバズではなく、信頼を積み重ねる発信を続けてきたほど、データ消失のダメージは深く刻まれます。

そこで現場で広く使われているのが、無料のバックアッププラグイン「BackWPup（バックダブリューピーアップ）」です。私たちハッシンラボでも、支援先のWordPress運用ではBackWPupを基本構成に組み込んでいます。毎週の自動バックアップと月次の状態確認をセットで運用する形が標準です。

本記事では、中小企業の発信担当者がBackWPupを自分の手で設定し、運用フローに乗せる手順を解説します。いざという時に復旧まで自走できる状態を、画面操作と判断軸の両方から整理します。公式情報はBackWPup公式（wordpress.org）、復旧フローはWordPress公式バックアップガイドもあわせて参照ください。

BackWPupとは｜中小企業のWordPress運用に必要な理由

BackWPupとは、WordPressサイトのデータを自動で保存する無料プラグインです。導入コストはゼロで、設定もWordPress管理画面から完結します。

中小企業の発信担当者にとって、BackWPupは記事という資産を守る最初の防衛線になります。例えば、毎週日曜の深夜に全記事とファイルをDropboxへ自動保存する運用が、管理画面のクリック操作だけで設計できます。

外部のサーバー業者に毎月料金を払って依頼するのと比べ、判断のスピードも自社で握れます。一方で、後述するように復旧操作にはFTPやphpMyAdminの知識が要ります。本章ではまず「BackWPupとは何か」と「なぜ今すぐ導入すべきか」を整理しておきましょう。

BackWPupでできること（ファイル・データベースの自動保存）

BackWPupが保存するのは、WordPressを構成する2種類のデータです。1つはテーマや画像などのファイル類、もう1つは記事本文や設定を格納したデータベースです。

データベースとは、記事や固定ページの本文・カテゴリ・コメント・各種設定を格納する保管場所のことです。例えば、WordPressに投稿した記事の文字データは、すべてこのデータベース内のテーブルに保存されています。

ファイル側で守られるのは、テーマフォルダ・プラグインフォルダ・wp-content/uploads配下の画像などです。記事に埋め込んだ写真や図表は、ここに置かれています。

BackWPupはこの2つを同時に取得し、ZIPファイルにまとめて保存します。保存先はサーバー内・FTP・Dropbox・Amazon S3など、用途と予算に合わせて複数から選べます。中小企業の標準構成は「サーバー内＋Dropboxの二重化」が現実解です。

つまりBackWPupは、記事本文と画像を切り離さず、まとめて時系列で保管してくれるツールです。発信を資産として積み上げる前提に、そのまま合った仕組みになります。

中小企業が今すぐ導入すべき3つの理由

中小企業がBackWPupを今すぐ導入すべき理由は、大きく3つあります。

1つ目は、サーバー障害やハッキングからの復旧手段を自社側で確保できる点です。レンタルサーバー側にも定期バックアップはありますが、復元範囲や保持期間が限定されるケースは少なくありません。自社でもう1セット持っておくほうが、判断スピードと安心感が違ってきます。

2つ目は、プラグイン更新やテーマ変更前の安全網になることです。更新直後に画面が真っ白になる「ホワイトアウト」と呼ばれるトラブルも、直前のバックアップがあれば数十分で元に戻せます。攻めの改修を躊躇なく進めるためにも、戻れる場所が要ります。

3つ目は、属人化を防げる効果です。発信担当者が異動・退職した後でも、運用ドキュメントとバックアップが残っていれば次の担当者が引き継げます。担当が代わるたびに発信がリセットされる事態を防げます。

蓄積した発信は、担当者個人ではなく企業の資産として位置づけるものです。BackWPupはその第一歩として、最も導入コストの低い選択肢になります。

蓄積した記事を失わないための「守りの発信運用」

発信は積み上がる資産です。だからこそ、攻めの記事制作と同じ熱量で「守りの運用」を整える必要があります。

実際、複数のWordPress解説チャンネルが、攻めではなく守りの観点からバックアップの重要性を発信し続けています。例えばウェブ職TVチャンネルの解説動画バックアップデータからブログ(WordPress)を復旧させる方法【BackwpUpとUpdraftPlus】では「バックアップは復旧できて初めて意味がある」というメッセージが語られています。設定して安心するのではなく、戻せる状態まで作って初めて防衛線になる、という指摘です。

蓄積した記事を失えば、SEOで積み上げてきた検索順位もリセットされます。被リンク・記事内の内部リンク構造・パンくず・カテゴリ設計、これらが一気に崩れます。再構築には、最初に積み上げた時間以上のコストがかかります。

守りの仕組みは、攻めの発信を続けるための土台です。BackWPupの導入は、その土台づくりの最初の一手として位置づけられます。

📌 この章のまとめ – BackWPupは無料でWordPressのファイルとデータベースを自動保存できる – 中小企業に必要な3理由は「復旧自走」「更新時の安全網」「属人化防止」 – 蓄積した記事を失えばSEO資産も同時に崩れるため、守りの運用が攻めの土台になる

💡 発信を続けるなら、まず「守りの基盤」から

蓄積した記事は中小企業にとって長期の資産です。私たちハッシンラボでは、WordPress運用とバックアップ戦略の伴走支援も行っています。設定だけでなく「復旧まで自走できる体制づくり」までを一緒に考えてみましょう。

→ 発信担当者向け運用支援を見る

BackWPupと他バックアッププラグインの違い

WordPress運用のバックアッププラグインは複数あります。代表格はBackWPupとUpdraftPlus（アップドラフトプラス）の2つです。どちらが優れているかではなく、運用負荷と復旧のしやすさで使い分けるのが現実的になります。

中小企業の発信担当者は「自分が復旧まで自走するか」「外部のサーバー担当に依頼する前提か」で選択肢が変わります。前者ならUI操作で完結するUpdraftPlus、後者なら細かい設定が効くBackWPup、と整理できます。

本章で扱うのは3点です。UpdraftPlusとの比較、無料版と有料版の差分、向く企業・向かない企業の見極め方を順に整理します。複数のYouTube解説動画から拾える現場感とあわせて見ていきましょう。

BackWPup vs UpdraftPlus｜運用負荷で比較

BackWPupは設定の自由度が高い反面、復旧操作はFTPやphpMyAdmin（公式サイト）を使う必要があります。UpdraftPlusは管理画面のボタン1つで復元まで完結するため、運用負荷の低さが特長です。

ウェブ職TVチャンネルの解説動画WordPressプラグイン「BackWPup」をオススメしない理由では、代替としてUpdraftPlusを推奨する内容が語られています。復旧のしやすさを優先する現場の判断軸が、リアルに見える事例と言えます。

両者の違いを表で並べると次のとおりです。

選定の軸は「障害発生時に誰が手を動かすか」です。この問いに答えてから選ぶと、運用の破綻を防げます。

無料版でできる範囲と有料版の差分

BackWPupの無料版でも、中小企業の運用に必要な機能はおおむね揃います。ファイル・DB両方の自動バックアップやスケジュール実行、Dropbox連携、複数ジョブ保存、世代管理などです。

有料版（BackWPup Pro）の追加機能としては、Amazon S3への暗号化保存、Google Drive連携、優先サポート、データベース単体の復旧支援などが挙げられます。最新の機能差分はBackWPup公式サイトで事前にご確認ください。事業規模が大きく、機密性の高い顧客データを扱う場合は検討対象に入ります。

中小企業の最初の一歩としては、無料版で十分に運用が回るのが実情です。私たちの支援先（中小企業10社規模）でも、まずは無料版で「サーバー内＋Dropbox」の二重バックアップを組む形を取っています。運用が安定してから必要に応じて有料版を検討する流れが多いです。

費用は本来、守りより攻めに回したい予算です。無料版でしっかり守りを固めれば、有料版にお金を回すかどうかをあとから冷静に判断できます。

BackWPupが向く企業・向かない企業の見極め方

BackWPupが向くのは、社内にIT担当がいるか、外部のサーバー業者やWeb制作会社と継続的に連携できる企業です。復旧時にFTPやphpMyAdminの操作が要る場面が出てくるためです。

逆のパターンもあります。発信担当者1人で運用し、技術トラブルも同じ人が抱える体制では、UpdraftPlusのほうが現実的です。管理画面で復元が完結する構造のため、属人化リスクと事故率の両方が下がります。

見極めの判断軸は3つに整理できます。1つ目は「障害発生時に誰が復旧を担うか」。2つ目は「FTPやphpMyAdminを触ったことがあるメンバーが社内にいるか」。3つ目は「外部パートナーへ復旧依頼を出せる予算と連絡経路があるか」です。この3つすべてがYesに近いほど、BackWPupの自由度が活きます。

逆に、3つともNoに近い場合は別の構成が現実的です。UpdraftPlus単独か「BackWPup＋月次の外部復旧テスト契約」を組み合わせる形になります。運用を破綻させない選択肢として機能します。

📌 この章のまとめ – BackWPupは設定自由度、UpdraftPlusは復旧操作の手軽さに優位がある – 中小企業の標準は無料版で十分回り、有料版は規模拡大後の検討で良い – 判断軸は「障害時に誰が手を動かすか」の1問に集約される

BackWPupのインストールと初期設定

BackWPupの導入は、WordPress管理画面から10分程度で完了します。本章ではプラグインのインストールから最初のジョブ作成、保存対象の選定までを画面操作に沿って順番に解説します。

ジョブとは、BackWPupが実行する1セットのバックアップ作業のことです。例えば「毎週日曜の深夜にデータベースだけをDropboxへ保存する」が1つのジョブにあたります。役割の違うジョブを複数組み合わせることで、ファイルとデータベースの保存頻度を分けて運用できます。

マーケの人チャンネルの解説動画BackWPupの設定方法（WordPressのバックアップができるプラグイン）でも、初期設定の流れはほぼ同じ順序で紹介されています。本章を読みながら、実際の管理画面で同時に手を動かしていただくと、初日から運用に乗せられます。

プラグインのインストール手順

インストール手順は3ステップです。難しい操作はなく、はじめてWordPressプラグインを入れる発信担当者でも、画面の流れに沿えば完了します。

まず、WordPress管理画面の左メニューから「プラグイン」→「新規追加」を開きます。画面右上の検索窓に「BackWPup」と入力すると、複数の関連プラグインが表示される画面に切り替わります。

次に、開発元が「WPMU DEV」と表示されているBackWPup本体を確認し、「今すぐインストール」をクリックします。よく似た名前の別プラグインを誤って入れないよう、開発元名の確認は1秒で済む大事な工程です。

最後に「有効化」を押せば導入は完了します。有効化後、管理画面の左メニューに「BackWPup」というメニューが追加されます。この時点ではまだバックアップは1度も走っていません。続いてジョブを作る工程に進みます。

なお、インストール後に英語表記が混ざることがあります。BackWPupは日本語化されているメニューと英語のままのメニューが混在しています。本記事の手順に沿えば操作位置は迷いません。

新規ジョブの作成（一般タブの設定）

新規ジョブの作成は、左メニューの「BackWPup」→「新規ジョブを追加」から行います。タブが横並びで複数表示されますが、最初に触るのは「一般」タブです。

一般タブではまず、ジョブ名を入力します。例えば「週次フルバックアップ」「日次DBバックアップ」のように、内容と頻度が一目で分かる名前を付けます。あとから複数ジョブを作った時に、管理画面の一覧で迷わない命名が運用効率を上げます。

次に、ジョブタスクの項目で3つにチェックを入れます。「データベースのバックアップ」「ファイルのバックアップ」「インストール済みプラグイン一覧」の3項目です。中小企業の標準構成はこの3つです。プラグイン一覧を保存しておくと、復旧時にどのプラグインを再導入すべきかが分かります。

さらに下の「アーカイブ形式」では、Zipを選びます。一般的なPCで開けるため、復旧時の扱いやすさが他形式より高いという利点があります。

最後に、保存先の項目を設定します。「フォルダーへバックアップ」「Dropboxへバックアップ」など、用途に応じて1つ以上をチェックします。保存先の選び方は次章で詳しく解説します。

保存対象ファイル・データベースの選び方

保存対象は、原則「全テーブル」「全ファイル」を選びます。ただし、サーバーのストレージ容量に制限がある場合は、キャッシュフォルダや一部のアップロード履歴を除外する判断もあります。

データベース側は、原則すべてのテーブルを保存します。記事本文・固定ページ・カテゴリ・タグ・コメント・各種設定など、サイトの中身がここに格納されているためです。テーブル単位での除外設定もできますが、中小企業の通常運用では「全選択」のままで問題ありません。

ファイル側は、テーマ・プラグイン・アップロード画像が中心です。WordPress本体のコアファイル（wp-includes、wp-adminなど）の扱いには注意点があります。公式サイトから同じバージョンを再ダウンロードできます。そのため、容量を節約したい場合はコアファイル群を除外する選択肢もあります。

逆に、毎回保存する必要がないファイルもあります。キャッシュ系プラグインの一時ファイルや、サムネイル画像の中間サイズなどです。これらを除外することでバックアップ容量が大きく削減でき、タイムアウトエラーの予防にもつながります。

判断の軸はシンプルです。「失ったら自社の手で再生成できないものか」を基準に保存対象を決めると、容量と安全性のバランスが取りやすくなります。

📌 この章のまとめ – インストールは「プラグイン新規追加→検索→有効化」の3ステップで10分 – 一般タブのジョブタスクは「DB／ファイル／プラグイン一覧」の3項目が中小企業標準 – 保存対象は「失ったら再生成できないもの」を軸に取捨選択する

BackWPupの保存先設定｜Dropbox・サーバー・メールの使い分け

BackWPupはバックアップの保存先を複数から選べる仕組みです。サーバー内・FTP・Dropbox・Amazon S3・メール送信などが選べます。

保存先の選び方によって、復旧スピードと安全性の両方が変わります。サーバー内だけに置いていれば、サーバー障害そのものが起きた瞬間にバックアップごと失います。Dropboxなど外部サービスに置いておけば、サーバー本体が止まっても手元のPCから復旧用ファイルを取り出せます。

中小企業の現実解は「サーバー内＋Dropboxの二重化」です。設定の手軽さと、災害対策（オフサイト保存）の両方を、無料の範囲でカバーできる構成だからです。本章では各保存先の使い分け方と、Dropbox連携の具体的な設定フローを順番に整理します。

保存先別のメリット・デメリットを先に表で押さえておきましょう。

サーバー内保存のメリットとリスク

サーバー内保存は、設定が最も簡単で、復旧時のファイル取り出しも最速という利点があります。BackWPupの「フォルダーへバックアップ」を選び、保存先ディレクトリを指定するだけで完了します。

一方で、無視できないリスクもあります。サーバー自体が物理障害を起こした場合、バックアップごと失うリスクが残ります。同じく、サーバーがハッキングされてファイルを改ざんされた場合、バックアップにも汚染が及ぶ事例も報告されています。

特に共用レンタルサーバーでは、同じサーバーに同居する他サイトの脆弱性経由で被害が波及する事例も知られています。「自社サイトは大丈夫でも、隣のサイト経由で影響を受ける」リスクがゼロではない、という前提を持っておきましょう。

つまり、サーバー内保存は「一次保存」として使い、別の場所にもう1つコピーを置く構成が安全です。これが後述する3-2-1ルールの考え方につながります。一次は早く取り出せるサーバー内、二次は別場所のDropbox、という役割分担で組むのが現実的です。

設定は最短ですが、これだけで安心しないことが運用の出発点になります。

Dropbox連携の設定手順と認証フロー

Dropboxへの保存は、サーバー外保存の代表的な選択肢です。設定は新規ジョブの「宛先: Dropbox」タブから行います。

龍市チャンネルの解説動画ワードプレスのバックアッププラグインBackWPupの設定方法！dropboxへの認証のやり方もでは、認証フローの具体的な操作手順が画面付きで紹介されています。実際の設定画面と動画を見比べながら進めると、初日でも迷わずに進められます。

手順の流れは以下です。まずBackWPupのジョブ設定画面で「宛先: Dropbox」タブを開きます。「Dropboxのアプリ認証コードを取得」のボタンをクリックすると、Dropboxのログイン画面に遷移します。

Dropboxにログインし、BackWPupからのアクセス許可を承認すると、ランダム文字列のコードが画面に表示されます。このコードをコピーし、BackWPupの設定画面に戻ります。「アプリへのアクセスコード」欄に貼り付け、保存ボタンを押します。これでBackWPupからDropboxへの自動アップロードが可能な状態になります。

保存先フォルダ名（例: /BackWPup/）を指定すれば、Dropbox内の決まった場所に整理されて保存されます。

無料のDropboxアカウントでも2GB程度の容量が使えるため、中小企業の最初の運用には十分です。容量が逼迫してきたら、有料プラン（Plus 2TB）か、Amazon S3への移行を検討する流れになります。

複数保存先を組み合わせた「3-2-1ルール」運用

データバックアップの世界には「3-2-1ルール」という考え方があります。データを3つのコピーで持ち、2種類の異なるメディアに保存し、1つはオフサイト（別の物理場所）に置く、という構成原則です。

BackWPupに当てはめてみます。サーバー内（一次）＋Dropbox（二次・オフサイト）の2箇所保存が、中小企業の現実的な落としどころです。3-2-1の「3コピー」までは到達しませんが、サーバー丸ごとの障害には十分耐えられる構成になります。

さらに月次の手動バックアップを担当者のローカルPCに保存しておくと、3-2-1ルールの構成がほぼ完成します。クラウドサービス側のアカウント停止という稀なリスクにも備えられます。ハッシンラボの支援先でも、年に1回の総点検時にこのローカル保存を運用に組み込むケースが増えています。

属人化リスクを下げつつ、復旧確度を上げる運用設計です。大事なのは「全部やろう」ではない設計です。サーバー内＋Dropboxを確実に回し、余力があればローカルも、という段階導入が現実的になります。

📌 この章のまとめ – 保存先は「サーバー内＋Dropbox」の二重化が中小企業の標準形 – サーバー内は一次保存に限定し、別場所にも複製を置く – 3-2-1ルール（3コピー／2メディア／1オフサイト）が運用設計の指針になる

BackWPupのスケジュール設定｜毎日・週次の最適な頻度

バックアップ頻度は、サイトの更新頻度に応じて決めます。週1更新の企業サイトと、毎日2本記事を出すオウンドメディアでは、最適なバックアップ頻度がまったく異なります。

頻度を上げすぎるとサーバー負荷とストレージ容量が増え、サーバー側のCPU上限に当たって他の処理が遅くなります。逆に低すぎると、障害発生時に「直近1週間分の更新がすべて消える」といった損失幅の大きい事故につながります。両極端のどちらも避けるため、自社の更新頻度から逆算して設計します。

本章では、中小企業の更新頻度別の推奨スケジュール、深夜帯に実行する設定、そして保存世代数の決め方を順番に整理します。すべて運用の現実に即した内容です。

更新頻度別の推奨バックアップ間隔

更新頻度別の目安は、大きく2パターンに分けて考えると判断しやすくなります。

週1〜2回更新の企業サイトは、週次でファイルとデータベースをまとめて保存する構成が向いています。例えば「毎週日曜の午前3時にフルバックアップを1回」というシンプルな組み方です。容量とサーバー負荷の両面で、最もバランスが取れた構成になります。

毎日記事を出すオウンドメディアの場合は、データベースを日次、ファイル全体を週次に分ける運用が現実的です。データベースは記事本文を含むため毎日更新されます。一方、ファイル側（画像・テーマ・プラグイン）は記事更新の頻度ほど変わりません。ジョブを2つに分けて、頻度の高いほうだけを日次に回すと、無駄なく守れます。

テクチューブチャンネルの解説動画超簡単！WordPressのバックアップを自動で行うプラグイン（BackWPup）でも、自動実行の基本的な考え方として、こうした頻度設計が紹介されています。

迷ったら、まず週次から始めて運用に慣れる流れが安全です。1〜2ヶ月運用してみて、更新頻度や記事数に応じて日次へ刻む、という段階設計が現場では事故率を下げます。

深夜実行で本番サイトに負荷をかけない設定

バックアップ実行中は、サーバーに一定の負荷がかかります。ファイルのZIP圧縮、データベースのダンプ取得、外部サービスへの転送、これらが並行で走るためです。日中に実行すると、サイト表示速度が落ちる事象が発生する事例があります。

そこで標準的な設定は、深夜帯（午前2時〜4時など）に自動実行する形です。アクセスの少ない時間帯に処理を寄せることで、本番ユーザーへの影響を抑えられます。

設定は、ジョブ編集画面の「スケジュール」タブで行います。「ジョブの開始方法」で「WordPressのcron」を選び、開始時刻を深夜帯に指定する形です。

cron（クロン）とは、決まった時刻に自動で処理を走らせる仕組みのことです。例えば「毎週日曜の午前3時に自動でバックアップを開始する」「毎日午前2時にデータベースだけ保存」といった指定が可能です。すべて画面のプルダウンから選べます。

注意点として、サイトへのアクセスが極端に少ない時間帯はWordPressのcronが発火しにくい場合があります。アクセス数の少ない深夜帯では、サーバー側のリアルcron（OS側のcron）に切り替える設定が安定します。レンタルサーバーの管理画面でcron設定が可能なケースでは、こちらの方式が確実です。

保存世代数の決め方（容量とコストのバランス）

BackWPupは、古いバックアップを自動削除する世代管理機能を持ちます。保存世代数とは、何回分のバックアップを残すかという設定値です。

中小企業の目安は、週次なら4世代（約1ヶ月分）、日次なら7世代（約1週間分）です。これより多く持っても、実際の復旧で使われるのは直近1〜2世代に集中する傾向があります。半年前のバックアップから戻すケースは、現場では稀です。

世代数を増やすほどストレージ容量を消費します。Dropbox無料プランの2GBはすぐ埋まりますし、有料サーバーのストレージ追加もコストがかさみます。「いつか使うかも」で世代を増やすより、直近を確実に守る設計のほうが、運用の費用対効果が高くなります。

設定は、ジョブ編集画面の「宛先: フォルダー」タブや「宛先: Dropbox」タブで個別に行います。「フォルダー内のファイル数」や「ファイル削除」の欄に、保存しておく回数を数値で入力する形です。

容量とコストのバランスを取り、不要な過去世代は自動削除する設定が運用効率を上げます。発信が積み上がるほど、守るべきデータも増えていきます。設計時に決めた世代数を、年1回見直す運用ルールを入れておくと安心です。

📌 この章のまとめ – 更新頻度別に「週次フル」or「DB日次＋ファイル週次」を使い分ける – 深夜帯の自動実行で本番サイトへの負荷を回避する – 世代数は週次4／日次7を目安に容量とコストでバランスを取る

BackWPupでよくあるエラーと対処法

BackWPupの運用では、タイムアウトや認証エラーが一定の頻度で発生します。中小企業の発信担当者がエラー類型と対処法を事前に把握しておけば、サーバー業者に頼らず一次対応ができます。

サイト引越し屋さんチャンネルの解説動画BackWPupプラグインで起きる８つのエラーとその解決方法が参考になります。現場で頻発する8類型のエラーが体系化されている内容です。エラーが多いことは、それだけ多くの企業が運用に乗せている裏返しでもあります。

本章では、その中でも中小企業のサイトで特に出やすい3つを取り上げます。「タイムアウト系」「Dropbox認証エラー」「メモリ不足エラー」の3類型です。先に対処法を表で俯瞰しておきましょう。

自分で対処する手順を、ログの読み方とあわせて順番に解説します。

ジョブが途中で止まる（タイムアウト系）

最も発生頻度が高いのが、ジョブが途中で停止するタイムアウトエラーです。PHPの実行時間制限（max_execution_time）に処理時間が引っかかるのが主因になります。

対処方法は3つあります。1つ目はジョブ分割で、ファイルとデータベースを別ジョブに分けて、それぞれの処理時間を短くします。2つ目は不要ファイルの除外です。キャッシュ・ログ・サムネイル中間サイズを保存対象から外し、扱うファイル総数を減らします。3つ目はサーバー側の調整で、php.ini（PHPの設定ファイル）のmax_execution_timeを延長します。

中小企業の場合、レンタルサーバーの管理画面からPHP設定を変更できるケースが多くあります。「php.ini設定」「PHP関連設定」といったメニューから操作します。max_execution_timeを300秒や600秒に延長する形です。ただし、まず1つ目と2つ目のジョブ側調整を試してから、それでも解決しない場合にサーバー側を触る順序が安全です。

ジョブログには、どこで処理が止まったかが時刻付きで記録されています。「ファイルの圧縮中」で止まっているのか、「Dropboxへの転送中」で止まっているのかで、原因の切り分けが変わります。ログを開く習慣をつけると、対処の精度が上がります。

Dropbox認証エラーの再認証手順

Dropboxへの保存が突然失敗するケースもあります。原因の多くは、認証トークンの期限切れか、Dropbox側のアプリ認証取り消しです。

対処はシンプルです。BackWPupのジョブ編集画面でDropboxタブを開きます。あとは「アプリへのアクセスコードを再取得」を実行するだけです。手順は新規認証時と同じで、所要時間は2分程度です。ボタンを押し、Dropboxにログインし、表示されたコードを設定画面に貼り付け、保存する流れになります。

ただし、認証エラーに気づかず数週間放置すると、その間バックアップが一切取れていない状態が続きます。設定画面のステータス表示は緑のままに見えても、実行ログを見ると失敗が積み重なっている、ということが起こり得ます。

これを防ぐ仕組みが、月次でのバックアップログ確認です。発信担当者がカレンダーに月1回のチェック枠を入れておきます。ジョブ一覧画面で「最終実行ステータス」と「次回実行予定」を目視で確認する形です。所要時間は3分程度です。

私たちの支援先（中小企業10社規模）でも、認証エラーを2週間気づかずに放置していた事例が1社ありました。その後、月次チェックを運用ルールに入れて以降、同じ事故は再発していません。発信を資産として守るうえで、こうした月次の点検は欠かせない手順になります。

メモリ不足エラーとサーバー側の調整ポイント

大規模化したサイトでは、メモリ不足エラー（Allowed memory size exhausted）が出ます。PHPのメモリ上限（memory_limit）が原因です。記事数や画像数が増えるほど、1回のバックアップ処理に必要なメモリも増えていきます。

対処は2方向あります。1つはサーバー側の対応で、memory_limitを256MBや512MBへ引き上げます。レンタルサーバーの管理画面で変更できるケースが多く、効果も即時的です。もう1つはBackWPup側の対応です。設定→ジョブの「最大スクリプト実行時間」と「リクエストごとの最大ファイル数」を小さい値に調整します。

これは、1回の処理で扱うファイル数を減らすことで、メモリ消費のピークを抑える狙いです。例えば「リクエストごとの最大ファイル数」を50に設定するとどうなるか。ファイル50個ごとに区切って処理が進むため、メモリ消費が平準化されます。

レンタルサーバー側で上限を上げられない場合は、ファイルとデータベースのジョブ分割で乗り切るのが現実解です。データベースのバックアップは比較的メモリ消費が小さく、ファイルの圧縮処理が重い傾向があります。この2つを別ジョブに分けるだけで、メモリ不足エラーが解消する事例も少なくありません。

容量が多くなったサイトほど、攻めの発信が積み上がってきた証でもあります。守りの設定もそれに合わせて見直す、という前提で運用すると安定します。

📌 この章のまとめ – タイムアウトは「ジョブ分割→不要ファイル除外→php.ini延長」の順で対処 – Dropbox認証エラーは月次のログ確認で早期発見できる – メモリ不足はmemory_limit拡張とジョブ分割の2方向で解消する

💡 「設定したのに事故が起きる」を防ぐには運用設計が要る

エラーの一次対応を内製化したい、復旧テストの仕組みまで整えたい、という発信担当者の方へ。ハッシンラボでは、月次チェックリストの整備から年2回の復旧テスト同伴までを支援メニューに含めています。

→ ハッシンラボの運用伴走支援を見る

BackWPupでバックアップから復旧する手順

バックアップは復旧できて初めて意味があります。これはウェブ職TVチャンネルの復旧解説動画（再生数9,286回時点）で繰り返し語られている、現場の鉄則です。

同動画では強い注意喚起も入っています。「サーバーとデータベースを操作するので、間違えるとデータが全部消えるリスクがあり、実践は自己責任で」という内容です。データベース復元の操作は、サイト全体の消失と隣り合わせの工程と言えます。

本章ではこの注意点を踏まえて3工程を解説します。復旧前のチェックポイント、ファイル復元の手順（FTP）、データベース復元の手順（phpMyAdmin）を順に整理します。実際に手を動かす前に、本章を最後までお読みください。

復旧前に確認したい3つのチェックポイント

復旧作業の前に、3つのチェックポイントを確認しておきましょう。ここを飛ばすと、復旧失敗時に手詰まりになるリスクが高くなります。

1つ目は、現在のサイト状態のスナップショットを取ることです。たとえ画面が真っ白でも、現状のファイルとデータベースをそのまま別フォルダにコピーしておきます。復旧作業で逆にデータを壊してしまった場合に、せめて現状には戻れる状態を確保しておくためです。

2つ目は、復旧に使うバックアップファイルの日付と完全性を確認することです。確認項目は3つあります。ZIPファイルが破損していないか、サイズが極端に小さくないか、解凍してSQLファイルが含まれているかを目視で確認します。バックアップ自体が壊れていれば、そもそも復旧できません。

3つ目は、作業時間の確保です。復旧は最低でも1〜2時間、慣れていない場合は半日を見込みます。途中で電話会議や別作業が入ると、操作ミスのリスクが跳ね上がります。可能なら、平日の午前など落ち着いた時間帯を確保してから着手するのが安全です。

この3点チェックは、私たちが支援先のWordPress復旧サポートに入る際にも、最初に確認する基本の型になっています。慌てて手を動かす前に5分の確認時間を取るだけで、復旧成功率は大きく上がります。

ファイル復元（FTPアップロード）の実演手順

ファイル復元は、FTPソフトを使ってバックアップZIPを展開・アップロードします。FTP（エフティーピー）とは、ファイルをサーバーへ転送する仕組みのことです。File Transfer Protocolの略になります。例えば、ローカルPCのファイルをレンタルサーバーへアップロードする際に使う、標準的な方法になります。

FTPソフトは無料の「FileZilla」や、Mac向けの「Cyberduck」が広く使われています。サーバー業者から発行されたFTPアカウント情報を入力します。ホスト名・ユーザー名・パスワード・ポート番号の4点です。入力後、サーバー内のファイル構成がエクスプローラのように表示されます。

手順は以下です。まずBackWPupで取得したZIPファイルをローカルPCで展開します。展開後のフォルダ構造を確認します。wp-content配下のテーマ・プラグイン・アップロード画像を、FTPで該当ディレクトリへアップロードします。アップロード先は通常/public_html/wp-content/です。

注意点があります。既存ファイルを上書きする形になるため、サーバー側の既存ファイルは別フォルダにバックアップしてから作業します。具体的には、サーバー上のwp-contentをwp-content_oldにリネームします。そのうえで新しいファイルをアップロードする形が安全です。問題があれば、リネームを元に戻すだけで現状復帰できます。

アップロード完了後、ブラウザでサイトを開いて表示確認します。テーマや画像が正しく反映されているかを目視チェックし、問題なければ次のデータベース復元工程に進みます。

データベース復元（phpMyAdmin操作）の注意点

データベース復元は、サーバーのphpMyAdminから行います。phpMyAdmin（ピーエイチピーマイアドミン）とは、データベースをブラウザから操作する管理ツールのことです。例えば、レンタルサーバーの管理画面からアクセスして、テーブルの中身を直接編集できます。詳細はphpMyAdmin公式を参照ください。

復元手順は以下です。phpMyAdminにログインします。次に対象データベースを選び、既存テーブルをすべて削除（DROP）します。最後にBackWPupが出力したSQLファイルを「インポート」タブから読み込ませます。

ここが復旧工程の中で最も慎重に進めるべき場面です。データベース操作のミスは、サイト全体のデータ消失に直結します。「既存テーブル削除」の段階で対象データベースを取り違えると、別サイトのデータを消す事故にもつながります。

本番作業の前に、テスト環境で一度同じ手順を試しておくと安心です。ステージング環境（本番と同じ構成のテスト環境）やローカル環境（自分のPC上のWordPress）が候補です。最初の1回で本番に挑むのは、自動車を初めて運転する人が高速道路に出るのと同じ危うさがあります。

中小企業の発信担当者が、復旧まで自力で担うのが不安なケースもあるはずです。その時は、月次で外部の開発パートナーや私たちのようなサポート先に復旧テストを依頼する選択肢があります。蓄積した発信を資産として守る前提なら、復旧の備えはコストではなく投資として位置づけられます。

📌 この章のまとめ – 復旧前の3点チェック（現状保全／ZIP完全性／作業時間）で成功率が上がる – ファイル復元はFTPでwp-contentをリネーム後にアップロードする – データベース復元はテスト環境で一度試してから本番に臨むのが安全

中小企業がBackWPupを「資産防衛の仕組み」にする運用設計

BackWPupは設定して終わりではなく、運用フローに組み込んで初めて資産防衛の仕組みになります。プラグインを入れた瞬間に守れる、というツールではありません。

蓄積した記事は、中小企業にとって長期的に価値を生み続ける資産です。一時的なバズではなく、信頼を積み重ねる発信ほど、守りの仕組みが効いてきます。記事が増えるほど、1本失った時の損失も大きくなります。

本章では3つの観点から整理します。月次バックアップ確認のチェックリスト、属人化を防ぐ運用マニュアル、年2回の復旧テストの3つです。すべて、私たちが支援先（中小企業10社規模）で実際に回している運用設計の型です。

月次バックアップ確認のチェックリスト

月次で確認する項目は5つに絞ります。多すぎると形骸化するため、本当に効く5項目に限定する形です。

1点目は、直近のバックアップが正常完了しているかのログ確認です。BackWPupのジョブ一覧画面で「最終実行ステータス」が緑（成功）になっているかを目視します。2点目は、Dropboxなど保存先の容量残量です。残り500MB以下なら世代数の見直しか、有料プランへの移行を検討します。

3点目は、認証トークンの有効期限です。Dropbox認証が切れていないか、ジョブ編集画面で確認します。4点目は、サーバー側のディスク使用率です。サーバー管理画面で空き容量が10%を切っていないかを見ます。5点目は、世代管理が想定通り動いているかです。古いバックアップが自動削除されず溜まり続けていないかをチェックします。

このチェックを30分の月次タスクとして固定するだけで、私たちの支援先で発生してきた運用事故の大半は事前に予防できています。発信担当者のカレンダーに「毎月第一営業日の午前」のように固定枠で入れておくと、実行率が上がります。

私たち自身、ハッシンラボの運用でも同じチェックを毎月行っています。形だけのチェックにしないコツは、結果を1〜2行でログに残すことです。「今月：問題なし」「先月との差分なし」と書き残すだけで、半年後に見返した時の安心感がまったく違ってきます。

属人化を防ぐための運用マニュアル作成

発信担当者が異動・退職した後でも引き継げる状態を作るには、運用マニュアルの作成が前提条件になります。担当者の頭の中だけに運用知識がある状態は、属人化リスクの典型例です。

マニュアルに含めるべき項目は5つに絞ります。1点目はジョブ設定の内容（ジョブ名・スケジュール・保存対象・保存先）です。2点目は保存先のアカウント情報の所在（Dropboxアカウントのメールアドレスとパスワード保管場所）。3点目は月次チェック手順。4点目は障害時の連絡フロー（外部サーバー業者の連絡先・対応時間）。5点目は復旧手順の概要です。

社内Wikiやスプレッドシート、Notionなど、複数人がアクセスできる場所で管理します。担当者個人のPC内に保存しないことが鉄則です。担当者が休んだ日に障害が起きても、別のメンバーが見られる場所に置く必要があります。

年に1回は、実際の担当者がマニュアル通りに作業できるかを試します。書いた本人ではない別メンバーがマニュアルを見ながら手順を追えるかを試すと、暗黙知の漏れが見つかります。「ここはマニュアルに書いていないが、実は重要だった」というポイントが出てきがちです。

これが属人化を防ぐ最も実効性の高い方法です。マニュアルは「作って終わり」ではなく、年1回の総点検で生きた状態を保ちます。

復旧テストを年2回入れる「実践運用」

復旧テストは年2回の実施が現実的な目安です。ステージング環境やローカル環境を使います。実際にバックアップファイルからサイトを復元してみる作業を、半年に1度、運用カレンダーに入れる形です。

テストで確認する観点は2つに絞れます。1つ目は、復旧手順がドキュメント通りに進められるかの再現性確認です。2つ目は、復元後のサイトが本番と同等に動作するかの動作確認です。記事の表示、画像の表示、お問い合わせフォームの送信、管理画面ログインなど、主要機能が動くかを目視で確認します。

このテストを運用に組み込むことで、本番障害時に慌てない体制が作れます。「半年前にやったあの手順だ」と思い出せる状態は、未経験で本番復旧に挑むのとはまったく別物になります。

発信を「思いつき」から「仕組み」へ移すうえで、守りの実践運用は欠かせない要素です。攻めの発信が蓄積するほど、守りの仕組みも段階的に強化していく必要があります。

私たちハッシンラボでも、自社サイトと支援先サイト（計11サイト）で半年に1度の復旧テストを継続しています。やってみると毎回小さな改善点が見つかり、その都度マニュアルを更新する流れが定着してきました。

📌 この章のまとめ – 月次5項目チェックを30分の固定枠で運用し、事故の芽を早期発見する – マニュアルは社内Wiki等で共有し、年1回別メンバーが追えるかを試す – 復旧テストは年2回・半年単位で運用カレンダーに固定する

まとめ｜BackWPupは中小企業の発信資産を守る最初の仕組み

BackWPupは、中小企業の発信資産を守る実用的な無料バックアッププラグインです。WordPressで蓄積した記事を時系列で保管できます。

設定は管理画面から10分、運用に乗せれば月30分のチェックで、発信資産を守る基盤として機能します。本記事で解説した運用の要点は、5つに整理できます。

具体的には、保存対象の選定、保存先の二重化、スケジュール設計、月次の点検、年2回の復旧テストとマニュアル化。この5要素を組み合わせると、攻めの発信を続けながら守りも回せる体制が作れます。私たちハッシンラボの支援先（中小企業10社規模）でも、ほぼ同じ運用設計が標準形として定着しています。

最後に、明日からの「最初の一歩」もあわせて整理しました。完璧を目指す前に、まず1ジョブを動かしてみるところから始めてみてください。発信運用の全体像については、ハッシンラボのSEO戦略入門、内製化の進め方は中小企業の発信内製化ガイドもあわせて参考にしてください。

運用の5要点と最初の一歩

1点目は、ファイルとデータベースの2種類を、サーバー内＋Dropboxの2箇所に保存する構成を取ること。2点目は、更新頻度に合わせて週次〜日次のスケジュールを組み、深夜帯に自動実行する設定にすることです。

3点目は、月次でバックアップログと認証状態を確認する運用を、カレンダーで固定すること。4点目は、復旧テストを年2回入れて「実際に戻せる状態」を担保すること。5点目は、運用マニュアルを社内Wikiで管理し、属人化を防ぐことです。

発信は積み上がる資産です。攻めの記事制作と、守りのバックアップ運用、この両輪が揃って初めて、企業の発信が長期的な力になります。短期のバズより、信頼の蓄積。その前提に立つほど、守りの設計は欠かせなくなります。

まずは今週、BackWPupの新規ジョブを1つ作るところから始めてみてください。サーバー内に週次フルバックアップを1ジョブ、これだけで防衛線が1本立ち上がります。気負わず、小さく始めて流れを作るのが長続きのコツです。

📌 この章のまとめ – 運用5要点（保存・スケジュール・月次・復旧テスト・マニュアル）が標準形 – まずは今週、週次フルバックアップ1ジョブを動かすところから始める – 「攻めの発信×守りの運用」の両輪で発信は長期資産になる

💡 発信資産を「守る仕組み」まで一気に整えるなら

本記事の運用設計を自社で1から組むには時間がかかります。私たちハッシンラボでは、BackWPup設定の伴走から月次チェック・年2回の復旧テスト同伴までをまとめたWordPress運用支援プランをご用意しています。一緒に考えてみましょう。

→ ハッシンラボの運用伴走プランを見る

よくある質問

BackWPupの設定と運用について、中小企業の発信担当者から実際によく寄せられる質問を5つ取り上げます。本文を補う形で、判断軸と具体操作の両面から回答します。

取り上げる質問は次の5つです。料金、頻度の決め方、UpdraftPlusとの選定基準、ジョブ停止の原因、復旧確認方法の5点です。いずれも私たちが支援先からよく相談を受けるテーマで、運用初期にぶつかりやすい論点です。

順番に1つずつ整理していきます。発信を資産として積み上げる前提に立つほど、これらの判断軸は記事制作と同じくらい重要なものになっていきます。

Q. BackWPupは無料で使えますか？

A. BackWPupは無料版で必要機能の大半を利用できます。ファイル・DBの自動バックアップ、Dropbox連携、スケジュール実行、世代管理まで含まれます。中小企業の標準的な運用は、無料版だけで十分にカバーできる範囲です。

追加機能が必要な場合は有料版（BackWPup Pro）が検討対象です。Amazon S3への暗号化保存、Google Drive連携、優先サポートなどが含まれます。最新情報はBackWPup公式で確認してください。事業規模が大きく、機密性の高い顧客データを扱う企業は、有料版の機能差分を比較したうえで判断するのが現実的です。

無料版で運用を回しながら、ボトルネックが見えた時点で有料版に切り替える流れが現実的です。費用対効果の観点で最も無駄がありません。

Q. BackWPupのバックアップはどれくらいの頻度で取るべきですか？

A. サイトの更新頻度に合わせて設定するのが原則になります。週1〜2回更新の企業サイトは週次、毎日記事を出すオウンドメディアは日次が目安です。

中小企業でよく採用されるのは、データベースを毎日・ファイル全体を週1という分割運用です。記事本文は毎日変わりますが、画像やテーマファイルは毎日は変わらないためです。ジョブを2つに分けることで、サーバー負荷とストレージ消費を最小化できます。

迷ったら、まず週次の1ジョブから始めて運用に慣れる流れが安全です。1〜2ヶ月運用してみて、更新頻度や記事数に応じて日次へ刻むのが、事故率を下げる段階設計になります。

Q. BackWPupとUpdraftPlusはどちらを選ぶべきですか？

A. 重視する軸で分かれます。細かいスケジュール制御と保存先の柔軟性ならBackWPup、復旧操作の手軽さならUpdraftPlusが向いています。

中小企業の発信担当者が自力で復旧まで担う前提を考えてみます。UI操作だけで復元が完結するUpdraftPlusのほうが、運用負荷と事故率の両方が下がります。逆に、外部のサーバー業者や制作会社と継続的に連携できる体制であれば、BackWPupの設定自由度が活きます。判断の軸は「障害発生時に誰が手を動かすか」の1点に絞れます。

Q. BackWPupでバックアップが途中で止まります。原因は何ですか？

A. PHPの実行時間制限、メモリ不足、ファイル数過多の3つが主な原因です。改善には3方向の対処があります。1つ目はサーバーのphp.ini設定でmax_execution_timeとmemory_limitを延長する方法です。2つ目はジョブをファイルとデータベースに分割するやり方です。3つ目は不要なキャッシュやサムネイル中間サイズを保存対象から除外する方法です。

まずジョブ分割と保存対象の見直しから試し、それでも解決しない場合にサーバー側の設定変更へ進む順序が安全です。ジョブログを開いて、どの工程で止まっているかを切り分けると、対処の精度が上がります。

Q. BackWPupで取ったバックアップから本当に復旧できるか確認する方法はありますか？

A. 年に2回、「復旧テスト」を実施するのが現実解です。ステージング環境やローカル環境で、バックアップファイルから実際にサイトを復元します。実行カレンダーに半年単位で固定枠を入れておくと、運用が継続します。

テストで確認するのは2点に絞ります。1点目は復旧手順がドキュメント通りに進められるかの再現性、2点目は復元後のサイトが本番と同等に動作するかの動作確認です。これを運用に組み込むことで、本番障害時に慌てない体制が作れます。蓄積した発信を資産として守る前提なら、復旧テストは保険料のような位置づけになります。