ホームページのバックアップは必要？保存頻度・範囲・復元方法を解説
2026/09/08
リニューアル・運用ノウハウホームページのバックアップはなぜ必要？
ホームページは、一度公開したら同じ状態が永久に維持されるわけではありません。
例えば、
- WordPressの更新
- プラグインの更新
- 記事・画像の追加
- プログラム修正
- サーバー設定変更
- 担当者による操作
など、日々さまざまな変更が行われます。
その中で不具合や操作ミスが発生した場合、元の状態に戻すために必要なのがバックアップです。
バックアップがあれば、
更新前の状態へ戻す
消してしまったデータを復元する
サイト改ざん前の状態へ戻す
サーバートラブルから復旧する
といった対応ができます。
逆に、バックアップがなければ、過去の状態を再現できず、サイトを一から作り直さなければならない可能性もあります。
バックアップが必要になる代表的なトラブル
ホームページでバックアップが必要になる原因は、サーバー障害だけではありません。
例えば、
WordPress更新後にサイトが表示されなくなった
プラグイン同士が干渉してエラーが発生した
誤ってページや画像を削除した
コード修正でレイアウトが崩れた
不正アクセスによってファイルを書き換えられた
データベースが破損した
サーバー移行時にデータが欠損した
などがあります。
つまりバックアップは、「もしサーバーが壊れたら」という特殊なケースだけの対策ではありません。
普段の更新作業そのものに伴うリスクを減らすための運用対策です。
WordPressは「ファイル」と「データベース」の両方を保存する
WordPressサイトで特に理解しておきたいのが、バックアップ対象です。
WordPress公式ドキュメントでは、WordPressサイトのバックアップは大きくファイルとデータベースの2つに分かれると説明されています。
完全に復元するためには、一般的に両方が必要です。
ファイルに保存されているもの
WordPressのファイルには、例えば次のようなものがあります。
- WordPress本体
- テーマ
- プラグイン
- アップロードした画像・PDF
- JavaScript・PHPなどのプログラム
- 設定ファイル
- 独自に追加したファイル
特に、
wp-content
wp-config.php
などは、サイト固有の設定・画像・テーマ・プラグインと深く関係します。
WordPress公式でも、サイトのファイルとデータベースは別々に保存されており、ファイルをダウンロードしただけでは通常データベースまでバックアップされないと説明されています。
データベースに保存されているもの
データベースには、主に次のような情報が保存されています。
- 投稿
- 固定ページ
- コメント
- WordPress設定
- プラグイン設定
- ユーザー情報
- フォームやシステムによって保存されたデータ
WordPress公式でも、投稿やページなど多くのコンテンツはデータベース側に保存されるため、定期的なデータベースバックアップが推奨されています。
片方だけでは完全復元できない場合がある
例えば、
ファイルだけバックアップ
→ デザインや画像は戻せても投稿内容が戻らない
データベースだけバックアップ
→ 記事は戻っても画像・テーマ・プログラムが不足する
という可能性があります。
そのため、基本的には、
同じタイミングの「ファイル＋データベース」を1セットとして管理する
ことが重要です。
WordPress公式も、ファイルとデータベースを同じバックアップセットとして扱う方法を案内しています。
バックアップ頻度はどのくらいが適切？
バックアップ頻度に「すべてのサイトで毎日が正解」という決まりはありません。
重要なのは、
「どこまでデータが失われても許容できるか」
から逆算することです。
更新頻度が低い企業サイト
月に数回程度しか更新しないコーポレートサイトであれば、
定期バックアップ＋サイト更新前後のバックアップ
という設計でも対応できる場合があります。
例えば、
- 週次
- 月次
- 更新作業前
など、サイトの更新頻度に合わせて設定します。
ブログ・お知らせを頻繁に更新するサイト
毎日のように記事を投稿するサイトでは、バックアップ頻度も高める必要があります。
仮に1週間に1回しかバックアップしていなければ、障害発生時に最大1週間分の記事更新を失う可能性があります。
そのため、
毎日更新する
↓
毎日バックアップする
というように、更新頻度を基準に考えると分かりやすくなります。
EC・予約・会員サイトなどデータ更新が多いサイト
ECサイトや予約システムでは、
- 注文情報
- 顧客情報
- 予約情報
- 会員データ
などが継続的に増えていきます。
このようなサイトでは、「1日前の状態に戻せればよい」とは限りません。
バックアップ頻度だけでなく、
どの時点までデータ損失を許容できるか
まで含めて、より慎重に設計する必要があります。
WordPress・プラグイン更新前は別途取得する
定期バックアップとは別に、重要な作業前にはバックアップを取得しておくと安全です。
特に、
- WordPress本体の更新
- プラグイン更新
- テーマ更新
- PHPバージョン変更
- 大規模なページ修正
- プログラム改修
などです。
WordPress公式も、データベースについて定期的なバックアップに加え、アップグレード前にバックアップすることを強く推奨しています。
問題が起きた場合に、
「変更直前の状態」
へ戻せるようにしておくことが重要です。
「世代管理」が重要｜最新バックアップ1つだけでは危険
バックアップでは、最新ファイルを1つだけ保存するのではなく、複数世代を残すことが重要です。
例えば、サイトが改ざんされていたものの、1週間気づかなかったとします。
毎日バックアップしていても、
昨日のバックアップだけ保存
↓
昨日のデータもすでに改ざん済み
なら、正常な状態へ戻せません。
そこで、
- 昨日
- 3日前
- 1週間前
- 1か月前
など、複数の時点を残しておく世代管理が役立ちます。
具体的な保存期間・世代数は、
- 更新頻度
- データ量
- サイトの重要性
- 保管コスト
によって決めます。
バックアップはどこに保存する？3-2-1の考え方
バックアップは、サイトと同じサーバーだけに保存するのではなく、別の保管先にも持つことが重要です。
バックアップ設計では「3-2-1ルール」と呼ばれる考え方があります。
3：重要なデータを3つ持つ（本番＋バックアップ2つ）
2：異なる種類・環境の媒体に保存する
1：そのうち1つを別拠点・オフサイトに保存する
CISAのバックアップ資料でも、データ消失・破損からの復旧可能性を高める方法として3-2-1ルールが紹介されています。
ホームページであれば、例えば、
本番サーバー
↓
サーバー会社のバックアップ
↓
別クラウド・別ストレージ
というように、同じ障害で全部消えない構成を考えます。
サーバー会社の自動バックアップだけで十分？
レンタルサーバーには、自動バックアップ機能が付いていることがあります。
非常に便利な機能ですが、
「サーバー会社がバックアップしているから何もしなくていい」
とは限りません。
確認したいのは、
- 何日前まで保存されるか
- ファイルとデータベースの両方が対象か
- 復元操作を誰が行えるか
- 復元に追加料金が必要か
- バックアップ対象外のデータはないか
- 障害時に利用できる保証範囲はどこまでか
です。
サーバー会社によって条件は異なります。
特に企業サイトでは、契約しているサーバーのバックアップ仕様を一度確認しておくことをおすすめします。
バックアップから復元できる状態か確認する
バックアップ運用で最も重要なのは、
「データがあること」ではなく「実際に戻せること」
です。
復元対象を確認する
トラブルの内容によって、戻す範囲は異なります。
画像を1枚削除した
→ ファイルだけ復元
記事を削除した
→ データベース側の復元が必要になる可能性
サイト全体が改ざんされた
→ ファイル・データベースの両方を確認
というように判断します。
復元ポイントを判断する
「最新バックアップへ戻せばよい」とは限りません。
不具合や改ざんが発生した時点を調べ、
問題が発生する前の正常なバックアップ
を選ぶ必要があります。
そのためにも、複数世代の保存が重要です。
復元後にサイトを確認する
復元が完了しても、それで終了ではありません。
- トップページ
- 主要サービスページ
- 画像
- 問い合わせフォーム
- WordPress管理画面
- SSL
- リンク
- 計測タグ
などが正常に動作するか確認します。
データベースを復元した場合、バックアップ取得後に追加された記事・問い合わせデータ等が失われていないかも確認が必要です。
定期的に復元テストを行う
バックアップファイルが存在していても、
- データが破損している
- 必要なファイルが含まれていない
- 復元方法が分からない
- 担当者が退職して手順が分からない
というケースがあります。
そのため重要なサイトでは、テスト環境などを使って復元できることを定期的に確認するのが理想です。
バックアップは、復元できて初めて意味があります。
バックアップ運用でよくある失敗
サーバー内にしかバックアップがない
サーバー自体に障害が起きると、本番データとバックアップを同時に失う可能性があります。
ファイルだけ保存してデータベースを保存していない
WordPressではファイルとデータベースが別管理です。
最新1世代しか保存していない
不具合に気づくのが遅れた場合、正常な時点まで戻せない可能性があります。
自動バックアップを設定しただけで確認していない
容量不足や設定ミスで、実際にはバックアップが取れていないケースも考えられます。
復元方法を誰も知らない
緊急時に手順確認から始めると、サイト停止時間が長くなります。
バックアップと保守契約の範囲が曖昧
「バックアップされていると思っていた」「復元まで保守費用に含まれると思っていた」という認識違いは、事前に防ぐ必要があります。
保守契約で確認しておきたいバックアップ範囲
制作会社や保守会社へサイト管理を依頼している場合は、契約時にバックアップ条件を確認しましょう。
最低限確認したいのは、
- バックアップの有無
- 取得頻度
- 保存世代数・保存期間
- ファイルとデータベースの両方が対象か
- 外部保存の有無
- 障害発生時の復元作業が契約内か
- 復元対応可能な時間帯
- 復元作業に別途費用が発生するか
です。
「保守契約＝必ずバックアップ・復元まで含まれる」とは限りません。
契約書・見積書で対応範囲を明文化しておくことが、制作会社とクライアント双方のトラブル防止につながります。
個人情報を含むバックアップの管理にも注意する
バックアップはセキュリティ対策である一方、バックアップデータ自体が情報漏えいの原因になる可能性もあります。
特に、
- 問い合わせ内容
- 顧客情報
- 会員情報
- 注文情報
- 採用応募情報
などをデータベースに保存しているサイトでは、バックアップにも同じ情報が含まれる可能性があります。
そのため、
- 誰がアクセスできるか
- どこへ保存するか
- 不要になったデータをどう削除するか
- クラウドストレージを適切に管理しているか
まで考える必要があります。
例えば、バックアップファイルを誰でもアクセスできるWeb公開領域へ置くような運用は避けるべきです。
「バックアップだから安全」ではなく、バックアップも重要な情報資産として管理することが大切です。
ホームページバックアップチェックリスト
保存対象
- WordPressファイルをバックアップしている
- データベースもバックアップしている
- 画像・PDFなどアップロードデータが含まれている
- 独自プログラム・設定ファイルも対象になっている
頻度
- サイトの更新頻度に合わせて取得している
- 重要な更新作業前にバックアップしている
- WordPress・プラグイン更新前に取得している
- 許容できるデータ損失期間から頻度を決めている
世代・保管
- 複数世代を保存している
- 本番サーバー以外にも保存している
- バックアップ保存先の容量を確認している
- バックアップデータへのアクセス権限を管理している
復元
- 復元方法が決まっている
- 誰が復元を担当するか決まっている
- 正常なバックアップを判断できる
- 復元後の確認項目を決めている
- 必要に応じて復元テストを実施している
契約・運用
- サーバー会社のバックアップ仕様を確認している
- 制作・保守会社の対応範囲を確認している
- 復元費用の有無を確認している
- 保存期間・世代数が明確になっている
- 個人情報を含むバックアップを適切に管理している
まとめ：バックアップは「取れている」ではなく「戻せる」ことが重要
ホームページのバックアップは、サーバー障害だけではなく、
操作ミス
WordPress・プラグイン更新の不具合
サイト改ざん
データベース破損
サーバー移行トラブル
など、さまざまなリスクに備えるために必要です。
特にWordPressでは、ファイルとデータベースの両方をバックアップすることが基本です。
そして、
更新頻度に合わせて取得する
複数世代を残す
本番サーバーとは別の場所にも保存する
重要な作業前にバックアップする
実際に復元できる状態を確認する
という運用まで設計しておきましょう。
バックアップで最も重要なのは、
「バックアップファイルが存在すること」ではなく、「トラブル時に必要な状態へ戻せること」
です。
ホームページを事業の重要な窓口として利用しているのであれば、バックアップも日常的なサイト運用の一部として考えておくことをおすすめします。
WordPressのバックアップ・保守ならRefuへ
Refuでは、WordPressサイトの保守・運用に加え、バックアップ環境の確認、サーバー設定、WordPress更新前のバックアップ、障害発生時の復旧などにも対応しています。
「現在バックアップが取れているのか分からない」
「サーバー会社の自動バックアップだけで大丈夫か確認したい」
「万が一のときに復元できる体制を整えたい」
など、お気軽にご相談ください。
その他おすすめ記事はこちら
セキュリティ最低限チェックリスト｜改ざん・乗っ取りを防ぐ運用習慣
