ホームページのバックアップは何をどこまで取れば足りるか｜「戻せる状態」の具体的な条件

ホームページのバックアップについて調べると、プラグインの入れ方やサーバーの自動バックアップの説明が出てきます。ただ、実務で本当に問われるのは「取ったかどうか」ではありません。壊れた日に、実際に戻せるかどうかです。先に結論を書きます。

バックアップが役に立つ状態とは、次の4つが同時に満たされている状態です。

1. ファイルとデータベースの両方が揃っている（どちらか一方では元に戻りません）
2. 過去の複数時点（世代）が残っている（最新の1本だけでは、壊れた状態を上書きしたときに戻す先がありません）
3. サイトとは別の場所に置いてある（サーバーが丸ごと使えなくなる事態を想定します）
4. 実際に復元して、中身が開けるところまで確認してある（ここを飛ばすと「取れているつもり」になります）

そして、そのバックアップに復旧手順を書いたメモを添えておくこと。半年後の自分、あるいは別の担当者が読んで戻せる状態にして、はじめて資産として機能します。

弊社は名古屋でホームページの制作・運用と、サーバー移転やサイトの保全作業を行っています。数百MB規模のサイトを丸ごと保全して閉じた実務から、確認すべき点を順に整理します。

そもそも何を取るのか：ホームページの中身は2つに分かれている

WordPressで作られたホームページの中身は、大きく2つに分かれています。ここを理解していないと、バックアップの範囲を間違えます。

種類	中に入っているもの	取り方	欠けると失われるもの
ファイル	テーマ、プラグイン、アップロードした画像やPDF	FTPで丸ごとダウンロード、またはサーバー上で圧縮して取得	デザイン、写真、資料
データベース	記事の本文、固定ページ、カテゴリ、メニュー、各種設定、フォームの設定	管理画面のツール、プラグイン、またはサーバーのデータベース機能から書き出す	文章と設定のすべて

よくある誤解が、FTPでファイル一式を落として安心してしまうケースです。WordPressの記事本文はファイルの中にはありません。データベース側にあります。ファイルだけ持っていても、記事は1本も戻ってきません。逆にデータベースだけ持っていても、写真が全部消えたサイトになります。

規模感の実測を1つ出します。運用歴のあるサイトを1件、丸ごと保全したときの内訳は、ファイルが約1万3千件・合計およそ400MB、データベースが22テーブル・記事408件でした。容量の大半は画像などのアップロードファイルで、文章はデータベース側にごく小さく収まっています。容量が大きい側と、失うと痛い側は一致しない。両方取る、が唯一の正解です。

ファイルとデータベースの外にも「戻せないと困るもの」がある

サイトのデータを取っていても、これらが欠けると復旧作業が止まります。バックアップと同じ扱いで保管しておく対象です。

• 各種アカウント情報：サーバーの管理画面、FTP、ドメイン管理会社、WordPressの管理者アカウント、DNSを操作できる権限。実務で最も詰まるのは技術ではなく「そのドメインを誰が管理しているか分からない」という状態です
• メールボックス：問い合わせメールは、サイトと同じサーバーに入っていることがよくあります。サーバーを移す・解約するとサイトと一緒に消えます。弊社では一括整理の前に必ず圧縮してダウンロードし、壊れていないかの検査と件数の一致を確認してから消します
• 外部サービス側の設定：フォームの送信先アドレス、予約システムのURL、アクセス解析や広告の計測タグ。サイトを復元しても、これらが元に戻らないと問い合わせが届きません
• ドメインそのもの：旧ドメインから新ドメインへの転送設定は、旧ドメインを保有している間しか効きません。解約した瞬間に転送も消え、過去のリンクやブックマークからの流入が全部途切れます。ドメイン移転後、旧ドメインをいつまで維持するかは意識して決める必要があります

頻度と世代の決め方は「更新のペース」で決まる

バックアップの頻度に絶対の正解はありません。判断基準は「最後のバックアップ以降に失った更新を、手作業でやり直せるか」です。

サイトの更新ペース	推奨する頻度	世代の目安
ブログや商品情報をほぼ毎日更新	日次	直近2週間ぶん程度
月に数回更新	週次	直近1〜2か月ぶん
ほとんど更新しない会社案内型	月次＋作業の前	数世代

重要なのは世代を複数持つことです。バックアップが常に最新の1本しかない構成には、大きな穴があります。不具合に気づかないまま次のバックアップが走ると、壊れた状態でバックアップが上書きされ、正常な時点が消えるからです。

改ざんや設定ミスは、当日中に気づけるとは限りません。画像が数枚表示されなくなった、フォームのメールだけ届かなくなった、といった症状は数週間気づかれないことがあります。「何日前まで戻れるか」は、バックアップを設計するときに必ず決めておく項目です。

同期はバックアップではない

誤解が多いところなので、はっきり書きます。クラウド同期やミラーリングは、バックアップの代わりになりません。

同期の役割は「複数の場所を最新の状態に揃えること」です。削除も上書きもそのまま相手側へ伝わり、片方で消せばもう片方からも消えます。バックアップに求められるのは「過去の時点を保持すること」で、両者は目的が正反対です。

さらに注意したいのが、同期サービスによっては、競合したファイルのコピーが残らないことです。あとから書いた内容が前の内容を静かに置き換え、置き換わったこと自体が記録に残らない挙動を、弊社は実際に計測して確認しています。この性質を知らずに同期フォルダだけを保管先にしていると、失ったことに気づくのが遅れ、気づいても戻せません。

「サーバーとパソコンの2か所にあるから安全」という考え方も同じ理由で危険です。2か所にあることと、過去の時点が残っていることは別の話です。世代を持つ仕組みを、同期とは別に用意してください。

サーバーの自動バックアップだけで足りるか

多くのレンタルサーバーには自動バックアップ機能があります。有用ですが、これ1本に寄せる前に3点を確認してください。

1. 保持期間は何日か。上限があるのが普通です。気づくのが遅れると期限切れで戻せません
2. 復元の手順と費用。管理画面から自分で戻せるのか、申請が必要なのか、費用がかかるのかは契約プランによって異なります。トラブルの最中に初めて調べる事態は避けたいところです
3. ファイルとデータベースが両方対象か。別々に取得・復元する仕様のことがあり、片方だけ戻すと不整合が起きます

サーバー側の自動バックアップは最終手段と考え、日常的な戻し作業は自分の手元にあるバックアップで完結できるようにしておく。この二重化が現実的な構えです。

プラグインを入れて終わりにしない：復元まで通して確かめる

バックアップ系プラグインの導入は、多くの場合で正しい選択です。ただし導入した時点では、まだ「戻せる状態」になっていません。

広く使われている移行・バックアップ系プラグインの無料版には、扱えるファイルサイズの上限が設けられていることがあります。画像の多いサイトや長年運用したサイトでは、バックアップの作成はできるのに、復元の段階で上限に当たって止まるという事態が起こり得ます。復元機能そのものが有料版の対象になっている製品もあります。実際にこの状況に当たったときは、別のプラグインへ切り替えて作業を完了させました。

プラグインを選ぶときは、次を確認してください。

• 扱えるサイズの上限があるか。自分のサイトの容量はその範囲に収まるか
• 復元が無料の範囲でできるか（作成は無料、復元は有料という区切りが実在します）
• データベースも対象に含まれるか
• 保存先をサーバー外（クラウドストレージなど）に指定できるか

そして、一度だけでいいので実際に復元を通してみること。テスト用の場所へ戻して開けるところまで確認して、はじめてそのプラグインが自分のサイトで使えると言えます。

「取れているつもり」を防ぐ4つの確認

弊社がサイトを丸ごと保全するときに実施している確認手順です。

1. ファイル件数の突き合わせ。サーバー側のファイル一覧とダウンロードしたファイル一覧を作り、双方向で比較して「不足0件・余分0件」を確認します。合計件数が一致しただけでは、別のファイルが混ざっていても気づけません
2. 合計バイト数の一致。件数と容量の両方が合っていれば、取得漏れはほぼ潰せます
3. データベースの書き出しファイルが途中で切れていないかの確認。書き出しファイルの末尾には完了を示す行が入ります。この行の有無と、テーブル数と定義文の数が一致するかを見れば、途中で切れた不完全なデータを掴まずに済みます
4. 別の場所へ実際に復元して開く。隔離した場所へ展開し、データが読めること、件数が元と一致することまで確認します

もう1つ、判定の落とし穴があります。サイトの状態をHTTPのステータスコードだけで判定しないでください。 削除したはずのディレクトリにアクセスして正常応答が返ることは実際にあります（別のページが代わりに応答しているだけ）。復元後の確認も同じで、ページが表示されたかどうかではなく、記事本数、画像の表示、フォーム送信、管理画面へのログインまで見て判断します。

定期バックアップとは別に「作業前バックアップ」を取る

定期バックアップがあっても、作業の直前にもう1本取るのが安全です。サイトが壊れる原因の多くは自然発生ではなく、更新作業や改修作業そのものだからです。対象は、デザイン改修、テーマやプラグインの更新、サーバー移転、記事の一括置換です。

公開中のサイトへファイルを上げる前の手順は、次の順で固定しておくと事故が減ります。

1. アップロード先の中身をまず一覧で確認する（空だと決めつけない）
2. 実ファイルがあれば、先に丸ごとダウンロードして保管する
3. 取得できたことを件数で照合する
4. そのうえで作業する

特に注意が必要なのが、同期ツールの「送信先にあってローカルに無いファイルを削除する」オプションです。既存の公開サイトにこの指定を向けると、意図していないファイルまで一括で消えます。取り消しはできません。このオプションは、バックアップ済みであることを確認した対象にだけ使うと決めておくのが安全です。

あわせて、切り戻せる形で更新するのも有効です。ファイルを差し替えるとき、旧ファイルを残したまま新ファイルを別名で置き、参照先だけを切り替える。問題が出たら参照を戻すだけで復旧でき、バックアップから戻すより速く、サイトを止めずに済みます。

サイトを閉じるときこそ保全する

使わなくなったサイトを整理する場面でも、バックアップの考え方は同じです。削除ではなく、まず保全してから閉じるのが原則です。

弊社が実際に使っている手順は、①ファイルとデータベースを取得して照合する ②公開ディレクトリの外へ移動して外部から見えない状態にする ③手元にもダウンロードして内容を照合する ④復旧手順を書いたメモを一緒に置く、という流れです。移動であって削除ではないので、必要になれば戻せます。

「今は使っていないが、また使うかもしれない」というサイトほど、判断を保留したまま放置されがちです。放置は保全ではありません。保全して閉じると決めるだけで、資産を失わずにリスクだけを外せます。

制作会社に任せている場合に確認する4項目

運用を制作会社に任せている場合、次の4点を確認しておくと、いざというときの対応速度が変わります。

1. 何を取っているか（ファイルのみか、データベースを含むか）
2. どの頻度で、何世代・何日分残っているか
3. どこに保管しているか（同じサーバー内だけなのか、別の場所にもあるか）
4. 復元は誰が行い、どれくらいの時間と費用がかかるか

加えて、契約終了時にサイトのデータ一式を受け取れるかも先に確認してください。ファイル、データベース、ドメインとサーバーの管理権限。この3つが揃っていれば、どこへでも移せます。揃っていないと、作り直しになります。

よくある質問

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

更新のペースで決めます。判断基準は「最後のバックアップ以降の更新を、手作業でやり直せるか」です。ブログを毎日更新しているなら日次、月数回の更新なら週次で足ります。加えて、改修作業の直前には必ず1本取ってください。

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

両方持つのが理想です。サーバーの自動バックアップは保持期間や復元手順に制約があるため最終手段と位置づけ、日常的に戻せる手段を自分の側にも用意しておくと対応が早く済みます。

Q. バックアップはどこに保存するのが安全ですか

サイトが動いているサーバーとは別の場所です。同じサーバー内のバックアップは、サーバー自体に問題が起きたときに一緒に失われます。クラウドストレージや手元のパソコンなど、少なくとも1か所は別系統に置いてください。ただし同期フォルダは世代を持たないため、それ単独では保管先になりません。

Q. 復元テストは毎回必要ですか

毎回は不要です。ただしバックアップの取り方を決めた最初の1回と、サーバーやプラグインを変えたときは必ず通してください。この2回さえ押さえておけば、「作れているのに戻せない」状態はほぼ防げます。

まとめ

ホームページのバックアップで確認すべきことは、次の形に整理できます。

1. ファイルとデータベースの両方を取る
2. 世代を複数残す（最新1本だけにしない）
3. サイトとは別の場所に保管する（同期フォルダ単独は不可）
4. 実際に復元して開けるところまで一度確認する
5. アカウント情報・メール・外部サービス設定・ドメインも保全の対象に含める
6. 定期バックアップとは別に、作業前バックアップを習慣にする

バックアップは、取った日には何の成果も生みません。価値が出るのは、トラブルが起きた1日だけです。だからこそ「取ってあります」で止めず、戻せる状態になっているかを一度確認しておくことをおすすめします。

弊社では、ホームページの制作・運用のほか、サーバー移転やサイトの保全作業も行っています。現状のバックアップで本当に戻せるか不安な場合は、構成の確認からご相談ください。