バックアップと障害復旧 ― 何があってもデータを失わないSaaS運用

公開フェーズの最後にして，最も重要なテーマがバックアップと障害復旧だ．第9回でデータベースのバックアップに触れたが，本記事では，サービス全体を最悪の事態から守り，立ち直るための備えを，改めて正面から扱う．

なぜこれが最重要かというと，データを失えば，事業そのものが終わるからだ．サーバー障害，操作ミス，攻撃，データ破損── データが消える原因はいくらでもある．そのとき，バックアップと復旧の備えがあるかどうかが，事業の生死を分ける．

この記事は，サービスを公開し，それを長く安全に運用したい個人開発者に向けて書いている．バックアップの原則，自動化，復元テスト，復旧目標の考え方，各種障害への備え，障害対応の手順まで，データを守り抜くための知識を解説する．

扱う範囲は，備えの重要性 → 3-2-1ルール → 自動バックアップ → 復元テスト → 復旧目標(RPO/RTO) → 障害のパターン別対応 → サーバー全体の復旧 → 障害対応の手順 → よくある失敗，だ．読み終えたとき，あなたは何があってもデータを失わない運用体制の作り方を理解している．

なぜ「バックアップ」が事業の生命線なのか

SaaSが預かるのは，ユーザーが時間をかけて蓄積した大切なデータだ．それは，第1回で見た通りサービスの価値そのものであり，失えば顧客は二度と戻ってこない．バックアップは，その最重要資産を守る最後の砦だ．

そして，データが失われる事態は『起きるかもしれない』ではなく『いつか必ず起きる』前提で備えるべきだ．ハードウェアは故障し，人間はミスをし，攻撃は来る．『うちは大丈夫』という油断こそが，最も危険だ．実際に，バックアップを取っていなかったために事業が消えた例は，後を絶たない．

重要なのは，バックアップは『取る』だけでなく『戻せる』ところまでが備えだということだ．第9回でも強調したが，取っているつもりで実は壊れていて戻せない，というのは悲劇的によくある．『確実に復旧できる』状態を作って，初めて備えは完成する．

本記事のメッセージは，『データは必ずいつか危機に瀕する．自動でバックアップし，確実に復旧できる備えを，何があっても保つ』ことだ．これは個人開発の運用で，唯一妥協が許されない領域だと言ってよい．

バックアップの大原則 ― 3-2-1ルール

バックアップの世界で，最も有名で確実な指針が『3-2-1ルール』だ．第9回でも触れたが，本記事で改めて詳しく見ていこう．これは，データのコピーをどう持つべきかの黄金律であり，個人開発でも目指すべき基準だ．

3-2-1ルールとは，『データのコピーを3つ持ち，2種類の異なる媒体に保存し，うち1つは別の場所(オフサイト)に置く』というものだ．元データに加えてバックアップを2つ，保存先を分散し，災害でも生き残るコピーを遠隔地に確保する，という考え方だ．

なぜここまでするかというと，一つの保存先は，必ず一緒に失われうるからだ．同じサーバーにバックアップを置いても，サーバーが飛べば一緒に消える．同じ場所の別ディスクでも，災害なら共倒れだ．コピーを分散し，別の場所に逃がすことで，どんな事態でも生き残るコピーを確保する．

個人開発で完璧な3-2-1を実現するのが難しくても，最低限『本番とは別の場所に，自動でバックアップを保存する』ことは必ず実現したい．同じサーバーにしかバックアップがない状態は，最も避けるべき危険な状態だ．別の場所に逃がすことが，何よりの肝だ．

「別の場所」が最重要

3-2-1の中で，個人開発でとくに重要なのが『1つは別の場所に』だ．安価なクラウドストレージ(第15回で触れたオブジェクトストレージ等)に，自動でバックアップを転送しておく．これだけで，サーバーごと失われても復旧できる．

別の場所への保存は，災害だけでなく，サーバーの乗っ取りやランサムウェア(第42回)への備えにもなる．本番から隔離された場所にコピーがあれば，本番が汚染されても，きれいなコピーから戻せる．

複数世代を保持する

バックアップは，最新の1つだけでなく複数の世代(過去数日〜数週間分)を保持する．なぜなら，『データ破損やミスに，しばらく気づかない』ことがあるからだ．最新が既に壊れていても，過去の正常な世代に戻せる．

たとえば『毎日バックアップを取り，過去2週間分を保持』しておけば，いつ問題が起きても，その前の正常な状態に戻せる．最新だけだと，壊れたデータでバックアップが上書きされる危険がある．世代の保持が，これを防ぐ．

自動バックアップ ― 手動は必ず忘れる

バックアップで最も重要な実践は，『自動化する』ことだ．第9回でも強調したが，これは何度でも繰り返す価値がある．手動のバックアップは，忙しいとき・疲れているときに必ず忘れる．そして，そういうときに限って事故は起きる．

自動化の方法はシンプルだ．第14回・第15回で触れたサーバーの定期実行機能を使い，決まった時刻に自動でバックアップを取り，別の場所へ転送するスクリプトを組む．一度仕組みを作れば，あとは人手をかけずに，毎日確実にバックアップが取られる．

自動化すべきは，データベース(第9回)だけでなく，ユーザーがアップロードしたファイルや，重要な設定も含む．サービスを復旧するために必要なものは，すべてバックアップの対象だ．何を失うと困るかを洗い出し，それらを漏れなく自動バックアップに含めよう．

自動バックアップを組んだら，『本当に動いているか』を確認する．設定したつもりで動いていなかった，では意味がない．最初に動作を確かめ，その後も時々『最新のバックアップがちゃんと作られているか』を確認する習慣をつけたい．

バックアップの成否を通知する

自動バックアップが成功したか，失敗したかを通知する仕組みを入れると安心だ(第18回の監視と連携)．失敗に気づかず，いざというときにバックアップがなかった，という最悪を防げる．

とくに『失敗したら必ず通知が来る』ようにしておく．バックアップは，普段は意識しないが，失敗していると致命的だ．沈黙が成功を意味するのではなく，成否を能動的に把握できる状態にしておこう．

バックアップ自体も安全に保つ

バックアップには，本番と同じ重要なデータ(個人情報を含む)が入っている．だからバックアップ自体も，安全に保管する必要がある．保存先のアクセスを厳しく制限し，できれば暗号化する．

バックアップが漏洩すれば，本番が漏洩したのと同じことだ．第7回・第15回のセキュリティの考え方を，バックアップにも適用する．守るべきデータのコピーなのだから，コピーも同じく守るのは当然だ．

復元テスト ― 「戻せる」を確かめる

本記事で，バックアップの自動化と並んで強調したいのが『復元テスト』だ．第9回でも触れたが，これは本当に見落とされやすく，しかし決定的に重要なので，改めて正面から扱う．バックアップは『戻せて』初めて意味がある．

復元テストとは，実際にバックアップから，データやサービスを復元してみることだ．取ったバックアップが壊れていないか，復元の手順は正しいか，どれくらい時間がかかるか── これらは，実際に試して初めて分かる．机上で『バックアップを取っている』と安心していると，いざというとき戻せない．

悲劇的によくあるのが，『何年もバックアップを取っていたのに，いざ復元しようとしたら壊れていて戻せなかった』というケースだ．これでは，バックアップを取っていなかったのと同じだ．定期的に『別の環境に復元してみる』テストをして，確実に戻せることを確かめておく．

復元テストは，『復元手順を実際に経験しておく』意味でも重要だ．障害でパニックになっているときに，初めて復元手順を調べるのでは，焦ってミスを重ねる．平時に一度でも復元を経験しておけば，いざというとき落ち着いて対処できる．

定期的に復元を試す

復元テストは，一度きりでなく定期的に行うのが理想だ．バックアップの仕組みやデータ構造は変化するので，以前は戻せても今は戻せない，ということもある．第15回の定期メンテナンスの一環として，復元テストを組み込みたい．

毎回完璧にやる必要はないが，『最新のバックアップから，別環境に復元してみて，ちゃんと動くか』を時々確かめる．この習慣が，いざというときの確実な復旧を保証する．

復元手順を記録しておく

復元の手順は，記録(ドキュメント化)しておく．第6回・第14回で繰り返した『再現可能にする』が，復元でも効く．手順が残っていれば，障害時に迷わず復元でき，復元時間も短縮できる．

障害は，いつ起きるか分からない．疲れているとき，出先のとき，忘れた頃に起きる．そんなとき，明文化された復元手順があれば，それに従うだけで確実に戻せる．未来の自分への，最高の備えになる．

復旧目標 ― RPOとRTOを考える

障害復旧を考えるとき，2つの重要な指標がある．RPO(目標復旧時点)とRTO(目標復旧時間)だ．難しそうな用語だが，考え方はシンプルで，自分のサービスにどれだけの備えが必要かを判断する物差しになる．

RPOは『最大，いつ時点まで戻ってよいか(=どれだけのデータ損失を許容できるか)』だ．1日1回バックアップなら，最悪1日分の更新が失われうる．それが許容できないなら，もっと頻繁なバックアップが必要になる．サービスの性質に応じて，許容できるデータ損失を決める．

RTOは『障害から，どれくらいの時間で復旧すべきか』だ．復旧に半日かかってよいのか，1時間以内に戻すべきか．RTOが短いほど，迅速に復旧できる備え(手順の整備，復元の高速化など)が必要になる．これも，サービスの重要度に応じて決める．

個人開発の初期は，これらを厳密に設定する必要はない．だが，『最悪どれだけのデータが失われ，どれだけの時間で戻せるか』を把握しておくことは重要だ．それが許容範囲かを考え，足りなければバックアップの頻度や復旧の備えを強化する．漠然とした不安を，具体的な目標に変えよう．

サービスの重要度で水準を決める

RPO・RTOの水準は，サービスの重要度や，データ損失・停止が顧客に与える影響で決める．業務に深く組み込まれた重要なサービスなら，損失も停止も最小に抑えたい．趣味的なサービスなら，もう少し緩くてもよい．

過剰な備えはコストと手間がかかる．自分のサービスにとって『どこまでの損失・停止が許されるか』を見極め，それに見合った備えをする．第6回の『コストは収益に対する割合で』の判断が，ここでも効く．

障害のパターン別対応 ― 原因で備えが変わる

データが失われたり，サービスが止まったりする障害には，いくつかのパターンがある．原因によって，必要な備えと対処が変わる．主なパターンを知り，それぞれに備えておこう．

代表的なのは，『サーバー障害(ハードの故障など)』『操作ミス(誤ってデータを消す等)』『データ破損』『攻撃(乗っ取り・ランサムウェア)』だ．これらは，それぞれ異なる形でデータやサービスを脅かす．第9回の『操作ミスにこそ備える』でも触れたが，自分自身のミスも大きなリスク要因だ．

幸い，これらの多くは『別の場所にある，複数世代のバックアップ』があれば対処できる．サーバーが飛んでも別の場所から，ミスで消しても過去の世代から，破損しても正常な世代から，攻撃で汚染されても隔離されたコピーから戻せる．3-2-1ルールが，これら全てへの備えになっているのだ．

重要なのは，『どんな障害でも，最終的にはバックアップから戻せる』状態を作っておくことだ．個別の障害への対処も大切だが，最後の砦は常にバックアップ．だからこそ，本記事は何度もバックアップの重要性を強調している．攻撃対策は第40〜42回でさらに深掘りする．

自分の操作ミスを最も警戒する

意外かもしれないが，個人開発で最も頻繁な障害原因は自分自身の操作ミスだ．本番データを誤って消す，間違ったコマンドを実行する── サーバー障害より，こうしたヒューマンエラーの方がよく起きる．

だからこそ，危険な操作の前にはバックアップを取り(第9回・第14回)，本番への操作は慎重に行う．複数世代のバックアップは，自分のミスから自分を守る保険でもある．『自分が最大のリスク』と心得て備えよう．

ランサムウェアへの備え

攻撃の中でも，データを人質に取るランサムウェアは深刻だ．本番が汚染されると，つながった場所のバックアップまで暗号化されることがある．だからこそ，本番から隔離された別の場所のバックアップが，最後の命綱になる．

本番から書き換えられない形でバックアップを保つ(隔離・読み取り専用化など)ことが，ランサムウェア対策の要だ．詳しくは第42回で扱うが，3-2-1の『別の場所に』が，ここでも効いてくる．

サーバー全体の復旧 ― 再構築できる状態に

データのバックアップだけでなく，サーバー環境そのものを復旧・再構築できる備えも重要だ．サーバーが完全に失われたとき，新しいサーバーに，同じ環境を素早く再現できるか．これも障害復旧の一部だ．

ここで効くのが，第6回・第14回で繰り返した『環境を再現可能にしておく』ことだ．サーバーの構築手順を記録し，設定をコード化し，コードをGitで管理しておけば，新しいサーバーに同じ環境を再構築できる．第14回のスナップショットも，サーバー全体を素早く復元する手段になる．

つまり，サーバー障害からの完全な復旧には，『データのバックアップ』＋『環境の再現手段』の両方が要る．データだけ戻せても，それを動かす環境がなければサービスは復旧しない．両方を備えておくことで，サーバーごと失われても，別のサーバーで事業を再開できる．

個人開発では，ここまで完璧に備えるのは大変かもしれない．だが，最低限『データは別の場所にバックアップ』『環境構築の手順は記録』の2つがあれば，サーバーが飛んでも，時間はかかっても復旧できる．この2点を，運用の土台として持っておきたい．

スナップショットを活用する

第14回で触れたVPSのスナップショット機能は，サーバー全体の状態をまるごと保存・復元できる．大きな変更の前や，定期的にスナップショットを取っておけば，サーバーごと素早く復元できる．

ただしスナップショットは，多くの場合同じ事業者の環境内に保存されるため，3-2-1の『別の場所』としては不十分なこともある．スナップショット(素早い復元)と，別の場所へのバックアップ(確実な保全)を，用途で使い分けよう．

障害対応の手順 ― 慌てず，確実に

備えがあっても，いざ障害が起きたときにどう動くかが決まっていなければ，慌ててミスを重ねる．第17回・第18回でも触れた障害対応の手順を，バックアップ・復旧の観点から，改めて整理しておこう．

基本の原則は，第17回でも強調した『まず復旧，原因究明は後』だ．障害時は，まずサービスとデータを正常な状態に戻し，ユーザーへの影響を止める．原因の調査は，サービスを復旧させてから，第15回・第18回のログやエラー情報をもとに落ち着いて行う．

そして，復旧の判断において重要なのが『どこまで戻すか』だ．最新のバックアップに戻すのか，もっと前の世代か．データ破損なら，破損前の正常な世代を選ぶ．複数世代のバックアップがあるからこそ，この判断ができる．慌てず，状況を見極めて，適切な復旧点を選ぶ．

障害対応は，『気づく(第18回の監視)→止める・戻す(バックアップ・復旧)→原因を追う(ログ・エラー監視)→再発を防ぐ』という流れになる．本記事の備えは，この流れの『戻す』を支える．すべての備えが連携して，初めて障害から確実に立ち直れる．

障害対応も平時に準備する

障害対応の手順，連絡先，復旧の判断基準── これらは平時に準備しておく．障害の最中に考えるのでは遅い．簡単なメモでよいので，『何が起きたら，どう動くか』を事前に整理しておこう．

個人開発でも，最低限『サービスが落ちたら，まず何を確認し，どう復旧するか』を決めておくだけで，いざというときの動きが変わる．備えあれば憂いなし，を，障害対応でも実践したい．

復旧後に振り返る

障害から復旧したら，第18回でも触れた通り『何が起きて，どう対処し，どう防ぐか』を振り返る．同じ障害を繰り返さないための学びにする．バックアップや復旧手順に改善点があれば，すぐ反映する．

障害は，備えの弱点を教えてくれる機会でもある．振り返りを通じて，バックアップ・復旧の体制を継続的に強化する．一度の障害を，より強い運用への糧にしよう．

バックアップ・復旧でやりがちな失敗

最後に，個人開発のバックアップ・障害復旧でありがちな失敗を確認しよう．いずれも，最悪の事態にデータや事業を失うことにつながる．

• そもそもバックアップを取っていない：一度の事故で全データと事業を失う
• 同じサーバーにしかバックアップがない：サーバーごと失うと一緒に消える
• 復元を試したことがない：いざというとき壊れていて戻せない
• 最新の1世代しか保持しない：破損データで上書きされ戻せない
• 障害対応を決めていない：いざというとき慌ててミスを重ねる

共通する最大の教訓は，繰り返し述べてきた通り『自動でバックアップを取り，別の場所に複数世代を保存し，定期的に復元を試す』ことだ．そして障害対応の手順を平時に備える．データを守れることが，顧客の信頼と事業の継続を守る．ここだけは，何があっても妥協してはいけない．

今日，バックアップ体制を点検する

この記事を読み終えたら，今すぐ『自分のサービスは，自動でバックアップが取れているか・別の場所に保存されているか・一度でも復元を試したか』を点検してほしい．一つでも欠けていたら，それは最優先で対処すべき課題だ．

他のどんな機能改善より，バックアップ体制の確立が優先される．データを失えば，すべてが無に帰す．地味で目立たないが，これこそがSaaS運用の最も重要な土台だ．今日，確実に固めよう．

補論 ― データを守る備えは「自分の手の内」で

バックアップと障害復旧── データを守るこれらの備えは，サーバーとバックアップの保存先を自分でコントロールできることで，確実に・柔軟に組める．自動バックアップのスクリプト，別の場所への転送，復元の手順── これらを自分の責任で設計できることが，確実なデータ保全につながる．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─のような自分で制御できる高速VPSなら，定期的な自動バックアップを自由に組み，別の場所(クラウドストレージ等)への転送も設定でき，スナップショットでサーバー全体を素早く復元できる．データという最重要資産を，他人任せにせず自分の手で守れるのは，長期運用の大きな安心だ．そして，その守るべきサービスの顔となる独自ドメインは取り扱い400種類以上のドメイン取得サービス─ムームードメイン─で取得・管理し，第13回の通り失効させないことも，広い意味での『事業資産の保全』の一部だと心得たい．

『自動でバックアップし，別の場所に複数世代を保ち，確実に復旧できる備えを持つ』── これが，何があってもデータを失わないSaaS運用の正解だ．これで公開フェーズは完了．あなたのサービスは，安全に公開され，守られている．次回からは集客フェーズ．まずは申し込まれる『ランディングページ』の作り方を解説する．

よくある質問(FAQ)

Q1．バックアップは本当にそこまで重要ですか？

SaaSの最重要資産はユーザーが蓄積したデータで，失えば顧客は二度と戻りません．データ損失は『起きるかも』でなく『いつか必ず起きる』前提で備えるべきです（ハード故障・操作ミス・攻撃）．バックアップを取っていなかったため事業が消えた例は後を絶ちません．個人開発の運用で唯一妥協が許されない領域です．

Q2．3-2-1ルールとは何ですか？

『コピーを3つ持ち，2種類の異なる媒体に保存し，うち1つは別の場所（オフサイト）に置く』というバックアップの黄金律です．一つの保存先は必ず一緒に失われうるため，分散と遠隔保存で，どんな事態でも生き残るコピーを確保します．個人開発では最低限『本番とは別の場所に自動で保存』を必ず実現しましょう．

Q3．バックアップで一番重要なことは？

二つあります．一つは『別の場所に保存する』こと．同じサーバーにしかなければサーバーごと失うと一緒に消えます．もう一つは『複数世代を保持する』こと．データ破損やミスにしばらく気づかないことがあり，最新が壊れていても過去の正常な世代に戻せるようにします．そして必ず自動化してください．手動は必ず忘れます．

Q4．バックアップを取っていれば安心ですか？

いいえ．『取る』だけでなく『戻せる』ところまでが備えです．何年も取っていたのに，いざ復元しようとしたら壊れていて戻せなかった，という悲劇は本当によくあります．定期的に別の環境へ実際に復元するテストをして，確実に戻せること・手順・所要時間を確かめてください．復元手順は記録もしておきましょう．

Q5．RPOとRTOとは何ですか？

RPO（目標復旧時点）は『最大いつ時点まで戻ってよいか＝どれだけのデータ損失を許容できるか』，RTO（目標復旧時間）は『障害からどれくらいの時間で復旧すべきか』です．サービスの重要度で水準を決めます．個人開発の初期は厳密でなくとも，『最悪どれだけ失い，どれだけで戻せるか』を把握し，許容範囲かを考えましょう．

Q6．どんな障害に備えればいいですか？

サーバー障害・操作ミス・データ破損・攻撃（乗っ取り・ランサムウェア）が主なパターンです．幸い，その多くは『別の場所にある複数世代のバックアップ』で対処できます．とくに個人開発で最も頻繁なのは自分自身の操作ミスなので，危険な操作の前は必ずバックアップを．攻撃対策は第40〜42回でも深掘りします．

Q7．サーバーが完全に壊れたら復旧できますか？

『データのバックアップ』＋『環境の再現手段』の両方があれば復旧できます．データだけ戻せても動かす環境がなければ復旧しません．第6回・第14回の通り構築手順を記録し設定をコード化してGit管理しておけば，新サーバーに同じ環境を再構築できます．スナップショットも素早い復元に役立ちます．

Q8．障害が起きたとき，まず何をすべき？

『まず復旧，原因究明は後』が原則です．先にサービスとデータを正常な状態に戻し，ユーザー影響を止めてから，ログやエラー情報で原因を調べます．複数世代のバックアップがあれば『どこまで戻すか』（データ破損なら破損前の正常な世代）を選べます．対応手順・判断基準は平時に準備し，復旧後は振り返って再発を防ぎましょう．

まとめ ― データを守れることが，事業を守ること

バックアップと障害復旧は，SaaSの最重要資産であるデータを守る最後の砦だ．データが失われる事態は『いつか必ず起きる』前提で備えるべきで，その備えがあるかどうかが，事業の生死を分ける．

鍵は，『3-2-1ルールで分散保存』『自動でバックアップ』『別の場所に複数世代』『定期的に復元を試す』『環境も再現できるように』『障害対応を平時に備える』ことだ．そして『取る』だけでなく『戻せる』ところまでを必ず確認する．

これは個人開発の運用で，唯一妥協が許されない領域だ．他のどんな機能改善より，バックアップ体制の確立が優先される．今すぐ，自分のサービスのバックアップが『自動・別の場所・複数世代・復元確認済み』かを点検しよう．

これで，開発から公開，そしてサービスを守る運用基盤までが整った．あなたのサービスは，安全に公開され，何があっても守られている．だが，良いサービスも知られなければ使われない．次回からは集客フェーズ．まずは，訪問者を顧客に変える『ランディングページ』の設計を解説する．