
サイトのバックアップの取り方と復元|本番に出す前の備え
「サーバーの作業をしていて、ふと手が止まる。——もし今、操作を間違えてサイトが消えたら、自分はこれを元に戻せるんだろうか」。 制作会社に作ってもらったサイトを、いまは一人で預かっている。でも、バックアップって誰がどう取っているのか、はっきりとは知らない。いざというときに戻せるのか、自信がない。その不安、とても自然なものです。
バックアップは、ふだんは忘れていて、トラブルの瞬間にだけ「あってよかった」と思うもの。だからこそ、何かが起きてからでは間に合いません。今日は、何を・どこに・どう残すかと、「ちゃんと戻せるかの確かめ方」までを、現場で無理なく回せる形に整えます。まずは「いまどこに・いつの控えがあるか」を見える化するだけで十分です。
結論:失敗しないコツは、①ファイル一式とデータベースの両方を取る → ②サーバー以外の安全な場所にも1つ控える → ③定期的に「戻せる」を軽く確認、の3つです。完璧でなくてOK。できるところから。
何が起きているのか
サイト(とくにWordPressなどのCMS)は、主に次の2つで成り立っています。片方だけでは完全には戻りません。
- ファイル一式:画像、テーマ、プラグイン、設定ファイルなど(見た目と部品)
- データベース:記事本文、固定ページ、各種設定(中身と文章)
画像はファイル側、文章はデータベース側にある——だから両方が必要です。そして「取ること」より「戻せること」が本体。控えが壊れていたり、手順が分からなかったりすると使えません。「取れているつもり」を「戻せるに変える」が安心のコツです。
手順を小さく分ける

- いまのバックアップ状況を確認
- サーバー管理画面で、自動バックアップの有無・保存世代(日数)・復元方法を確認。注意:一部のレンタルサーバーは「復元が有料」「保持期間が短い」ことがあります。費用と保存日数はメモに残しておくと後で迷いません。
- 既存のバックアップ系プラグインの有無も確認。
- 「ファイル一式」と「データベース」を同じ日時でそろえて取得
- サーバー外にも1つ控える(情報セキュリティ規程に沿って)
- 個人PCや私物クラウドへの保管は避け、組織管理の共有ストレージ/NAS/社内クラウド、または暗号化を有効化したオブジェクトストレージ(例:S3等)に保存。アクセス権は最小限、MFA必須。
- 規程上「持ち出し不可」の場合は、同一事業者内の別リージョン/別ゾーンのスナップショット等で代替(詳細は契約の公式情報で確認)。
- 保存場所・世代・担当・手順URLをメモ化
- 復元できるかを定期的に軽く確認
- 最低ラインは「復元ボタンの位置」と「手順URL」を一度開いて把握(5分)。余裕があればステージングで試行。
小さく始めるほど回ります。まずは「1」を今日やれたら十分です。
最小運用モデル(所要時間の目安)
- 今日:自動バックアップの有無/保存日数を確認(5–10分)+大作業前に手動バックアップ1つ取得(5–10分)
- 毎月:オフサイト控えを1回(または自動化の確認)(10–15分)
- 四半期:テスト復元を1回(ステージング等で一括、15–30分)※時間が取れない月は「大作業前のみ」で可
自分の環境での「取り方」を選ぶ
バックアップの手段は複数あります。大切なのは「ファイル+DBの両方が揃うこと」と「サーバー外控えが組織管理で安全に置けること」です。
| 取り方 | 向いている人 | ファイルとDB両方 | サーバー外控え |
|---|---|---|---|
| サーバーの自動バックアップ | まず現状把握 | プランにより異なる(要確認) | 多くは手動DLが必要(注意:復元有料/保持短い場合あり) |
| バックアップ系プラグイン | WordPressの単独運用 | まとめて取得可のものが多い | 組織管理のクラウド/NASへ。暗号化+MFA |
| サーバー管理画面から手動 | たまに確実に取りたい | 同一時点で揃える | 組織管理ストレージへ保管 |
| 制作会社・保守契約に依頼 | 自分で触るのが不安 | 契約範囲を確認 | 保存場所・世代・費用を必ず把握 |
ポイントは方法より運用。どの手段でも「両方取れているか」「安全な控えがあるか」を毎月一度は見直します。
SaaS / ヘッドレス / 静的サイトの分岐
- SaaS型(例:ShopifyやWix等)
- まずは管理画面のエクスポート機能で取得できる範囲を把握(商品/コンテンツ/テーマ等)。不足分は公式アプリや連携で補えるかを確認。
- 事業者のSLAで冗長化が提供されているかを確認。社内で月次にSLAを確認できている場合は、物理的な持ち出し控えは免除扱いにしてよいことがあります(社内規程に従う)。
- ヘッドレスCMS
- コンテンツはCMS側のエクスポート、フロントはリポジトリ(Git)とビルド設定をスナップショット。画像等のアセットはストレージ(バケット等)も合わせて控えを取る。
- 静的/Jamstack
- 基本は「Gitリポジトリ+画像/ダウンロード等のバケット」のスナップショットが主。プレビュー/ローカルで本番と同構成にデプロイできるかを定期確認。
いずれも「戻せる単位」を先に決め、毎月1回はその単位で控えが揃っているかを見ると迷いません。
バックアップの回転と容量対策
- 保持世代数:最低「月次3世代+直近作業前1世代」を目安(社内規程に合わせ調整)
- 除外フォルダ例:wp-content/cache、backwpup-temp、ビルドの一時出力など「再生成できるもの」は除外
- 圧縮:ファイルはアーカイブ化し、古い世代から順に削除するルールをメモに明記
- データベースはダンプを圧縮し、機微情報の持ち出し可否を規程で確認
具体例:いざ復元するときの、落ち着いた進め方

ステップ1:戻す範囲を決める
- 全体が崩れた:直前のバックアップから丸ごと復元
- 一部だけ消えた:ピンポイント復元を検討
- 例1)消えた画像だけを、uploads配下から該当ファイルを再配置
- 例2)一部のテーブルだけ戻せる機能があるバックアッププラグインもあります(利用中のプラグインの公式情報で確認)
ステップ2:可能なら、まずテスト環境で試す
- いきなり本番を上書きしない。ステージングやテスト環境があればそこで一度試す
- テスト環境が無い場合の代替
- 同一サーバー内のサブディレクトリ/テスト用サブドメインに隔離復元
- ホスティングのステージング機能があればそれを利用
- 復元前に「現状のスナップショット(控え)」を必ず取得
ステップ3:本番を復元し、動作を確認 1) 復元実行 → 2) 表示/機能の確認 → 3) 記録
- 確認項目:トップ/主要導線のページ表示、フォーム送信テスト、通知メール/受信の動作、キャッシュ/セキュリティ系プラグインの再有効化、サイトURL/SSLの有効性、管理画面ログイン
ポイント:焦って連打しない。一手ずつ結果を見てから進めれば、多くは落ち着いて戻せます。
個人情報・機微情報を含むDBの扱い
- 含まれる場合、持ち出しは社内規程に従い最小化。暗号化を前提にし、アクセス権限は限定、MFA必須
- 保存期間を決め、不要になった控えは確実に削除
- アクセスログ(誰がいつ取得/復元したか)を残す
- 外部保管や検証用に使う場合は匿名化/マスキングの可否を検討
メモ用テンプレ(コピペして使えます)
- 保存場所(サーバー内/組織管理クラウド/NAS/別リージョン 等):
- 保存形式(ファイル/DB/両方、圧縮の有無):
- 保持世代数・保存日数:
- 除外対象(cache、backwpup-temp 等):
- 取得方法(自動/手動/プラグイン/保守会社):
- 復元手順URL(サーバー/プラグインの公式ドキュメント):
- 直近の取得日・取得者:
- 復元テストの最終実施日・環境:
- サーバーの自動バックアップ:有無/保持日数/復元費用の有無:
- 月次のオフサイト控え:方法/保存先/暗号化・MFA確認済み:
- 緊急連絡先(社内/制作会社/ホスティング):
あなたへの影響
- 「どこに・いつの控えがあるか」が分かると、不安が「戻せるので大丈夫」に変わる
- 両方(ファイル+DB)を安全な場所にも控える習慣で、障害や操作ミスでも復旧が早い
- 大作業の直前に必ず1つ取る——このルールが、更新や移行を落ち着いて進める土台になる
- 「取れていて、戻し方も確認済み」と言えることは、社内説明の強い裏付けになる
明日やること
- サーバーの自動バックアップの有無・保存日数・復元費用を確認し、メモに記録
- いまの控えが「ファイル一式」と「データベース」の両方を含むか確認
- 月1回のサーバー外控えを、組織管理の保存先(暗号化+MFA)で用意。規程で持ち出し不可なら別リージョン等のスナップショットで代替
- 復元手順URLと復元ボタンの位置を一度だけ開いて確認(5分)
チェックリスト(必須/できれば)
必須(まずはここから)
- サーバーの自動バックアップの有無・保存日数・保存場所・復元費用を確認した
- バックアップに「ファイル一式」と「データベース」の両方が含まれている
- 大きな作業の直前に、同一時点のバックアップを必ず1つ取得する運用にした
- 保存場所・保持世代・取得者・手順URLをメモに一覧化した
できれば(余力に応じて)
- サーバー外への控えを作成(組織管理クラウド/NAS/社内クラウド、暗号化+アクセス権+MFA)
代替:持ち出し禁止なら、同一事業者の別リージョン/スナップショットで代替 免除条件:SaaSで事業者SLAに冗長化があり、かつ社内で月次のSLA確認を行っている場合は物理的持ち出し免除
- 復元手順URLと復元ボタン位置の確認(最低ライン/5分)
- 四半期に1回、ステージングで一括復元テスト(15–30分)
静的/Jamstackは「本番と同構成でローカル/プレビューにデプロイできるか」を確認
- バックアップの回転ルール(保持世代・除外・圧縮・削除)を設定
- 保守契約の範囲(取得・保存先・費用・復元対応)を確認
- 復元後チェック(表示・フォーム送信・メール送受信・キャッシュ/セキュリティ再有効化・URL/SSL)をリスト化

サイトのバックアップは、毎日は気にしなくていい仕事です。でも、ふと不安になったその気持ちは、サイトを大切に預かっている証拠。今日は「いまの状況を確認して、両方そろっているかを見る」——その一歩だけで十分です。戻せる備えがあると分かっているだけで、明日の作業に少し落ち着きが生まれます。
バックアップとあわせて押さえておきたいWordPressの更新で事故らない手順や、本番に出す前に確認したい自社サイトの更新を公開前に確認するチェックリストも、日々の運用を守る助けになるはずです。「うちのサーバーの場合はどうすれば?」と迷ったら、お問い合わせからいつでも声をかけてくださいね。