ホームページのバックアップは週1回・外部保存・ファイルとDBの両方が正解

バックアップを取っていますかと聞かれて、即答できる中小企業は多くありません。プラグインを入れた記憶はあるが最後にいつ実行されたか分からない、サーバーの自動バックアップがあるらしいが復元したことはない、という状態が大半です。この記事では、どこに・何を・どの頻度でバックアップを取るべきかを、復旧できるかどうかという基準で整理します。

バックアップの正解は週1回・外部保存・ファイルとDBの両方

先に結論を書きます。中小企業のホームページであれば、以下の条件を満たしていれば実用上十分です。

失っても許容できる期間から頻度を決める

頻度は「何日分のデータを失っても事業に支障がないか」で決めます。毎日ブログを更新し、日々問い合わせが入るサイトなら毎日、月に数回お知らせを出す程度なら週1回で足ります。頻度を上げるほど安全ですが、その分サーバー容量と処理負荷を消費します。

ファイルとデータベースは片方だけでは意味がない

WordPressサイトは、画像やテーマファイルなどの「ファイル」と、記事本文や設定を保存する「データベース」の2つで構成されています。データベースだけ復元しても画像が表示されず、ファイルだけ復元しても記事が消えます。WordPress公式もこの2要素を対象とすることを示しています（出典 WordPress Developer Resources Backing Up Your WordPress Site）。

保存先をサーバー内だけにすると全損する

最も多い設定ミスが、バックアップの保存先です。

同じサーバー内の保存は「金庫を家の中に置く」のと同じ

バックアッププラグインの初期設定では、保存先がサーバー内のフォルダになっていることがあります。この状態では、サーバー障害・アカウント停止・重大な改ざんが起きた際に、本体もバックアップも同時に失われます。火事に備えて金庫を買ったが、その金庫を燃える家の中に置いている状態です。

クラウドストレージへの自動保存を設定する

UpdraftPlusやBackWPupなどの主要なバックアッププラグインは、Google Drive・Dropbox・Amazon S3などへの自動送信に対応しています。無料枠でも中小企業サイト数世代分は十分保存できます。設定時に注意すべき点は以下です。

• 連携アカウントは会社管理のものを使う（個人アカウントは退職時に失われる）
• 保存世代数を設定し、古いものが自動削除されるようにする
• 初回実行後、実際にクラウド側にファイルが届いているか目視で確認する
• クラウド側の容量が上限に達していないか定期的に確認する
• バックアップ失敗時にメール通知が届く設定にする

個人のGoogleアカウントに保存しているケースが多い

実務で頻繁に見かけるのが、担当者個人のGoogleアカウントにバックアップが保存されているパターンです。その担当者が退職した瞬間、バックアップへのアクセス権が失われます。会社として管理するアカウントを用意してください。

レンタルサーバーの自動バックアップだけでは不十分な理由

主要なレンタルサーバーには自動バックアップ機能が備わっています。ただしこれを唯一の備えにするのは危険です。

保持期間が7日から14日と短い

サーバー標準のバックアップは、保持期間が7日〜14日程度に設定されていることが一般的です。改ざんやデータ破損に気づくのが遅れると、保持期間を過ぎて正常な状態のバックアップが消えていることがあります。改ざんは平均して数週間気づかれないという現実を踏まえると、この期間は短すぎます。

復元に手数料や時間がかかる場合がある

サーバー会社によっては、バックアップからの復元に手数料が発生したり、申請から復元完了まで数営業日かかったりします。緊急時に「復元を申請したが3日後」では、事業への影響が大きくなります。契約中のサーバーの復元条件を、平時のうちに確認しておいてください。

サーバーアカウント自体が停止すると使えない

支払い遅延やクレジットカードの期限切れでアカウントが停止すると、サーバー内のバックアップにもアクセスできなくなります。サーバーの外に1系統持っておくことが、この種の事故への唯一の備えです。

取れているだけで復元できないバックアップが実在する

運用保守の現場で最も多い誤解は、バックアップが取れている状態と復旧できる状態を同一視していることです。

復元できない典型的なパターン

年1回は必ず復元テストを行う

テスト用のサブドメインやローカル環境にバックアップから復元してみると、実際に使えるかどうかが確認できます。この作業をしたことがない状態は、消火器を買ったが使い方を知らないのと同じです。本番で初めて復元を試すのは、最も避けるべき状況です。

復元手順を紙で残しておく

サイトが停止している状況では、サイト内に保存した手順書は読めません。復元手順・サーバーのログイン情報の保管場所・バックアップの保存先・連絡すべき担当者を、紙またはオフラインで参照できる形で残してください。

更新頻度別のバックアップ設計を業種で考える

実際にどう設定すべきかを、更新頻度別に整理します。

ほとんど更新しないサイトは月1回でも成立する

会社案内中心で年に数回しか更新しないサイトであれば、月1回のバックアップで実害はほとんどありません。ただしその場合でも、更新作業を行う直前には必ず手動でバックアップを取ってください。事故が起きるのは、まさに更新した瞬間だからです。

ブログや実績を更新するサイトは週1回

月に数本の記事や施工事例を追加するサイトは、週1回が標準です。失っても最大1週間分で済み、サーバー負荷も許容範囲に収まります。中小企業サイトの大半はこの設計で足ります。

ECサイト・予約サイトは毎日かつ差分取得

注文データや予約データが日々蓄積するサイトは、1日分の損失が実損になります。毎日のバックアップに加え、データベースのみ1日複数回取得する構成が望ましいです。この規模になると、専門的な運用設計が必要です。

更新作業の直前は必ず手動バックアップを取る

定期バックアップとは別に、WordPress本体の更新・プラグインの一括更新・テーマの変更・サーバーのPHPバージョン変更を行う前は、必ず手動でバックアップを取ってください。事故の大半は更新作業の直後に起こります。直前のバックアップさえあれば、数十分で元通りになります。

最後に

バックアップは、何もなければ一度も使わないまま費用と手間だけがかかる仕組みです。しかし改ざん・誤操作・サーバー障害が起きたとき、あるかないかで復旧費用が数万円と数十万円に分かれます。週1回・外部保存・ファイルとDBの両方・年1回の復元テスト。この4点を満たしているかを、今日確認してみてください。

Web管理では、月額1万円からホームページの運用保守を代行しています。バックアップ体制の構築と定期的な取得状況の確認も対応範囲に含まれます。「バックアップが取れているか分からない」という状態の診断からでも承ります。お気軽にご相談ください。