STEP 4 — Backup / 4-4

もしもに、
備えておく。

サイトを育てていくほど、それは大切な資産になります。だからこそ、「壊れたとき・消えたときに、元に戻せる」備えが要ります。それがバックアップです。難しい話ではありません。実は、この講座でやってきたことの多くが、すでにバックアップの役割を果たしています。この章では、何をどう守ればいいかを、やさしく整理します。git の知識が、ここで頼もしい味方になります。

この章のゴール

  • なぜバックアップが必要なのか、守るべきものが何かわかる
  • コード・データ・WordPress、それぞれの守り方を知っている
  • バックアップを自動で取る仕組みの作り方がわかる
  • 戻せることを確かめる大切さを理解している

なぜ、バックアップが要るのか

「うちのサイトに限って、消えたりしない」——そう思いたいですよね。でも、トラブルは突然やってきます。操作ミスでファイルを消した、サーバー会社の障害、間違った更新で全部おかしくなった、誰かに不正侵入された……。どれも、現実に起きていることです。

そのとき、バックアップがあるかないかで、結末はまるで違います。バックアップがあれば、「少し前の正常な状態」に戻すだけ。なければ、ゼロから作り直しか、最悪そのまま失います。バックアップは、サイトという資産にかける“保険”です。

となりに座って一言

バックアップでいちばん大事な考え方は、「1か所だけに置かない」ことです。本番サーバーの中だけにデータがあると、そのサーバーが倒れたら全部おしまい。本番とは“別の場所”にコピーを持っておく——これが効く備えの基本です。難しく考えず「卵を1つのカゴに盛らない」と同じ、と思ってください。

守るべきものは、大きく3つ

サイトを構成するものは、性質ごとに分けて考えると守りやすくなります。あなたのサイトに当てはまるものだけ、対応すればOKです。

  1. コード(プログラム・HTML/CSS):あなたが作ったサイトの本体。
  2. データ(データベースの中身):問い合わせ・予約・記事など、あとからたまっていく情報。
  3. アップロードした画像など:写真やPDFといった、ファイルとして置いたもの。

① コードは、もう守られている(GitHub)

うれしいお知らせです。コードのバックアップは、この講座ですでにできています。git の章で、変更をコミットして GitHub に push しましたね。あれが、まさにコードのバックアップです。手元のパソコンが壊れても、GitHub に“別の場所のコピー”が残っています。

しかも git は、過去のどの時点にも戻せる「履歴つきバックアップ」。「3日前の状態に戻したい」もできます。だから、コードについては——こまめにコミットして push する。それ自体が、最良のバックアップなのです。

となりに座って一言

「コミットして push」は、もはや“保存”であり“バックアップ”であり“やり直しの保険”。この3役をこなしてくれます。だから講座でしつこく「こまめにコミット」と言ってきたわけです。ここまで来たあなたは、コードのバックアップは合格点。あとは下の「データ」を足すだけです。

② データ(データベース)を守る

注意が要るのがデータベースの中身です。問い合わせや予約のように、あとからお客さまの操作でたまっていく情報は、コードとは別に守る必要があります。これは GitHub には入っていません。

フォームの章で使った Supabase なら、管理画面からバックアップが取れます。やり方は大きく2つです。

  1. 自動バックアップを確認する:Supabase は、プランに応じて自動で日次バックアップを取ってくれます。まず管理画面で「Database → Backups」を開き、どこまで自動で守られているか確認しましょう。
  2. 手動で書き出す(エクスポート):大事な節目では、自分でもデータを書き出して手元に保存しておくと安心です。テーブルのデータを CSV やファイルとして取り出せます。

具体的な操作は、Claude に聞きながら進めるのが確実です。

Claude Code へのプロンプト
Supabaseに保存している問い合わせデータを、定期的にバックアップしたいです。
・自動バックアップが今どうなっているかの確認方法
・手動でデータを書き出して手元に保存する方法
を、初心者向けに一つずつ教えてください。

独学だと、ここで止まる

コードは守ったのに、データを忘れる

「GitHub に push しているから安心」——コードはそうですが、お客さまの問い合わせや予約データは、GitHub には入っていません。ここを忘れると、いざという時に「サイトは戻ったけど、お客さまの情報は全部消えた」となりかねません。コードは GitHub、データはデータベース側で別に守る。この“二本立て”を、セットで覚えておきましょう。

③ WordPress の場合

WordPress のサイトは、ファイル(テーマ・プラグイン・画像)とデータベース(記事・設定・コメント)の2つでできています。両方そろって初めて元に戻せるので、両方をバックアップします。やり方は主に2通りです。

  1. プラグインで自動化する:「UpdraftPlus」などのバックアップ用プラグインを入れると、ファイルとデータベースをまとめて、定期的に自動バックアップできます。保存先を Google Drive など“別の場所”に指定できるのが利点です。
  2. サーバーの機能を使う:多くのレンタルサーバーには、自動バックアップ機能が備わっています。まず管理画面で、それが有効になっているか・何日分残るかを確認しましょう。

となりに座って一言

自作テーマを GitHub で管理している方は、テーマのコードはすでに GitHub にバックアップ済みです。残るは「データベース」と「管理画面から入れた画像」。そこをプラグインかサーバー機能でカバーすれば、抜けがなくなります。自分の構成に何が足りないか、Claude に整理してもらうのもおすすめです。

④ 大事なのは「自動で」取ること

テストの章でもお話しした通り、「手で思い出してやる」運用は、必ず続きません。バックアップも同じです。「毎週月曜にバックアップしよう」と決めても、忙しい週は飛ばし、そういう時に限ってトラブルが来ます。

だから、バックアップは仕組みに任せて自動化します。Supabase の自動バックアップ、WordPress プラグインの定期実行、サーバーの自動バックアップ——どれも「一度設定すれば、あとは勝手に取り続けてくれる」ものです。コードについても、CI/CD の仕組みで「push のたびに GitHub にコピーが残る」状態が、すでに自動バックアップになっています。

⑤ いちばん忘れがち — 「戻せるか」を試す

最後に、最も大切で、最も忘れられていることを。バックアップは「取ること」がゴールではありません。「戻せること」がゴールです。

毎日きちんとバックアップを取っていても、いざ復元しようとしたら「ファイルが壊れていた」「手順が分からず戻せなかった」——これでは保険になっていません。だから、一度でいいので“戻す練習”をしておきましょう。たとえばテスト用の環境にバックアップから復元してみる。これで「本当に戻せる」と確認できて、はじめて安心できます。

独学だと、ここで止まる

取りっぱなしで、戻せるか確かめていない

バックアップを取って満足し、一度も復元を試したことがない——これは非常に多く、そしていざという時に泣くパターンです。「取れている」と「戻せる」は別物。最低でも一度は、バックアップから戻す手順を最後まで通してみてください。やり方が不安なら、「このバックアップから元に戻す手順を、初心者向けに教えて。途中で確認すべき点も」と Claude に聞きながら、安全な環境で練習しましょう。

この章で出てきた言葉

バックアップ
壊れたり消えたりしたときに備えて、データのコピーを別の場所に取っておくこと。
復元(リストア)
バックアップから、元の状態に戻すこと。「戻せる」ことを確かめてこそ意味があります。
エクスポート
データベースなどの中身を、ファイルとして書き出すこと。手元に保存できます。
自動バックアップ
決めた間隔で勝手にバックアップを取り続ける仕組み。手作業より確実で、忘れません。
UpdraftPlus
WordPress 向けの代表的なバックアップ用プラグイン。ファイルとデータをまとめて守れます。

この章のまとめ

  • バックアップは資産にかける保険。本番とは別の場所にコピーを持つ
  • コードは GitHub への push がそのままバックアップ。データは別に守る
  • WordPress はファイルとデータベースの両方を。プラグインやサーバー機能で
  • 必ず自動化し、一度は「戻せるか」を試す。取るだけでは保険にならない

Support

備えで、迷ったら。

「自分のサイトは、何をどう守ればいいのか」——構成によって最適な備えは変わります。受講中の方は、あなたのサイトに合わせて一緒に組みましょう。

電話で相談 080-6946-4006