サーバーが壊れて、サイトのデータがすべて消えた。そういう復旧のご相談を受けたことがあります。サーバー会社に聞くと、機械そのものが壊れていて、中のデータは戻せない。サーバー側のバックアップもない。残っていたのは、検索エンジンやアーカイブにある過去のページだけでした。
先に結論を言います。バックアップは「取ってある」だけでは役に立ちません。ファイルとデータベースの両方を、サーバーの外に、長めに残しておく。そして年に何回かは、本当に別の場所へ戻してみる。戻せることを確かめたバックアップだけが、壊れたときに頼りになります。
何から始めたか
最初にしたのは、何が残っているかを確かめることです。検索エンジンやアーカイブに、過去のページがどれだけあるか。主なページの文章は、Internet Archive の Wayback Machine から拾えました。1Note 1Google の検索結果にあった「キャッシュ」は、2024年に提供が終わっています。いま過去のページを探すなら、Internet Archive の Wayback Machine などが頼りになります。ただし、残っているのは一部のページだけで、画像は欠けていることがほとんどです。
写真はほとんど残っていなかったので、お客さまの手元の資料と、印刷物の入稿データから集め直しました。作り直しに近い作業です。それでも、文章が残っていたのは大きかった。ゼロから書くのと、あるものを直すのとでは、かかる時間がまるで違います。
サイトは壊れる。前提はそれだけです。壊れないように祈るより、壊れたときに戻せる準備をしておく方が、ずっと確実です。
「バックアップはあります」と言われたとき、私が聞き返すこと
保守のご相談で「バックアップはサーバー会社が取ってくれているはず」「プラグインで自動で取っています」と聞くことがよくあります。それ自体は良いことです。ただ、私はそこで必ず聞き返します。「それ、戻したことはありますか」。戻そうとして初めて困るのは、だいたい次のどれかです。
- バックアップが同じサーバーの中にしかなく、サーバーと一緒に失われた
- 自動で取れているはずが、容量不足や設定の変更で、いつからか止まっていた
- ファイルだけ、またはデータベースだけしかない（WordPress は両方がそろって初めて戻る）
- 保存期間が短く、不具合に気づいたときには、壊れたあとの状態しか残っていない
- 戻し方を誰も知らない
どれも、「取れている」ことは確かめていても、「戻せる」ことを確かめていないときに起きます。とくに4つ目は、サイトが改ざんされたときに起きやすい問題です。改ざんは気づくまでに何週間もかかることがあり、そのあいだに、きれいな状態のバックアップが古い順に消えていきます。
WordPress のバックアップに必要なもの
WordPress のサイトを元に戻すには、次の2つが両方とも要ります。
- ファイル
- wp-content フォルダ（アップロードした画像、テーマ、プラグイン）と、wp-config.php、.htaccess。WordPress 本体のファイルは、あとから入れ直せます。
- データベース
- 記事・固定ページ・設定・ユーザー・プラグインの設定など、文章と設定のほぼすべて。プラグインが作った表も含めて、まるごと書き出します。
画像だけ、データベースだけでは戻りません。容量がいちばん大きいのは画像のフォルダですが、いちばん失って困るのはデータベースです。
どこに、どれだけ残すか
バックアップの考え方として、「3-2-1」という目安がよく使われます。データを3つ持ち、2種類の媒体に保存し、そのうち1つは離れた場所に置く、というものです。小さな事業者のサイトなら、次のくらいで十分です。
- 本番のサーバー（自動のバックアップ。数日〜2週間ぶん）
- サーバーの外のクラウドの保存場所（毎月の手動バックアップ。1年ぶん）
- 手元のパソコンや外付けの記録装置（大きな作業の前に取ったもの）
保存期間を長めにとるのは、さきほどの改ざんのように、気づくのが遅れた場合に備えるためです。
私のやり方
自動のバックアップがあっても、私は手作業のバックアップを別に取っています。月に2回と、更新の前。取ったら、ファイルの数と大きさ、データベースの中身をその場で見ます。理由は3つあります。
- 人の目で、取れたことを確かめられる。ファイルの数と大きさ、データベースの中身を見て、ちゃんと取れているかをその場で確かめます。
- サーバーの外に置ける。サーバーが壊れても、乗っ取られても、外にある控えは無事です。
- 作業の直前に取れる。WordPress 本体やプラグインを更新する前に取っておけば、更新で表示が崩れても、すぐに戻せます。
元に戻せるかを確かめる
いちばん大事なのは、バックアップから実際に戻してみることです。私は本番のサイトには触らず、別の場所（テスト用の環境や手元のパソコン）に戻して、次のところまで確かめます。
- 表示トップページと主なページが、崩れずに表示される。
- 画像画像が欠けていない。古い記事の画像まで見る。
- 管理画面ログインでき、記事を編集・保存できる。
- お問い合わせお問い合わせの送信まで通る。
これを年に数回でも行って、記録を残しておいてください。記録は、次のくらいで十分です。
- 日付
- 2026年10月1日
- どのバックアップか
- 9月30日の手動バックアップ（クラウドの保存場所）
- 戻した先
- 手元のテスト用の環境
- 結果
- 表示・画像・管理画面・お問い合わせの送信まで確認
一度でも戻せたことを確かめておくと、いざというときに「どの手順で、どれくらいの時間で戻せるか」がわかります。それだけで、慌て方がまったく違います。
今日できること
自社のサイトについて、次の3つに答えられますか。
- バックアップは、どこにあるか（サーバーの中か、外か）
- 最後に取ったのは、いつか
- そこから実際に戻したことはあるか
ひとつでも答えに詰まったら、それが見直しどきです。制作会社や保守の担当者に、この3つを聞いてみてください。
よくある質問
- レンタルサーバーの自動バックアップがあれば十分ですか？
- ある方がずっと安心ですが、それだけに頼らない方が安全です。同じ会社の設備の中にあることが多く、保存期間にも限りがあるためです。サーバーの外にも控えを置いておいてください。
- バックアップのプラグインは、何を使えばいいですか？
- どれを使うかより、設定と確認が大切です。保存先がサーバーの外になっているか、失敗したときに通知が届くか、そこから戻す手順を一度試したか。この3つを確かめてください。
- どれくらいの間隔で取ればいいですか？
- 更新の頻度で決めます。記事をよく足すサイトなら、毎日の自動のバックアップに加えて月に1回の手動、あまり更新しないサイトなら、更新したときと月に1回が目安です。
備えがあれば、サイトが壊れたという連絡は「大丈夫です、戻せます」の一言で終わります。私の運用・保守では、手動のバックアップと、戻せることの確認を作業の基本にしています。他社が作ったサイトも、最初に現状を診断したうえでお引き受けします。