バックアップが不安な本番DBを改善する方法
「バックアップは一応取っているはずだが、最後に復元したのがいつか分からない」——こう聞くと多くの発注者が言葉に詰まります。設定した記憶はあるが、その後誰も触っていない。担当者が異動・退職して、今の設定が正しいのか誰も検証できない。そんな状態のまま本番運用が続いているケースは珍しくありません。
バックアップは「取っていること」ではなく「復元できること」が価値です。この記事では、本番DBのバックアップに不安がある状態をどう洗い出し、どこまで整備すれば実用上安全と言えるのかを、発注者向けに整理します。
なぜ「バックアップ不安」を放置してはいけないのか
DBのデータ消失は、他の障害と質が違います。サーバーがダウンしても再起動すれば復旧しますが、データが消えたら、バックアップがない限り二度と戻りません。想定される引き金は以下のようなものです。
- オペレーションミス(
DELETE文のWHERE句漏れ、誤ったマイグレーション、本番と検証環境の取り違え) - クラウド側の障害・アカウント誤操作(インスタンスの誤削除、ストレージボリュームの破損)
- ランサムウェアやアカウント乗っ取りによるデータ破壊
- アプリケーションのバグによる大量データの上書き・欠損
このどれか一つが起きたとき、バックアップがなければ「事業の記録が丸ごと消える」ことを意味します。決済履歴・顧客データ・在庫情報が消えれば、単なる障害ではなく事業継続そのものが止まります。復旧に数週間かかれば、その間に顧客離反や契約解除が発生し、金銭的な損害は障害対応コストをはるかに超えます。
まず確認すべき5つのポイント
バックアップの不安を解消する第一歩は、「今何が設定されているか」を事実ベースで洗い出すことです。私たちが既存プロダクトを引き継ぐとき、必ず確認する項目は次の5つです。
1. 自動バックアップが有効か
手動バックアップだけに依存している状態は、担当者の記憶とタスク管理に依存しているのと同じで、実質的に「取れていない」のと大差ありません。
- マネージドDB(RDS、Cloud SQL、Supabase等)なら、自動バックアップの有効/無効を管理コンソールで直接確認する
- 自前運用のDB(EC2上のPostgreSQL/MySQL等)なら、
pg_dumpやmysqldumpを叩く cron ジョブが実際に動いているか、直近の実行ログを見る - 「設定した」という証言ではなく、「直近7日間、実際に成功した実行履歴があるか」を見る。cron が数ヶ月前から失敗し続けているのに誰も気づいていない、というケースは実際によくあります
2. 保持期間(リテンション)が事業要件に見合っているか
バックアップは何世代分保持しているかで、防げる事故の範囲が変わります。
- 保持が1〜2世代しかないと、「データ破損に気づくのが数日後だった」場合、壊れたデータで上書きされたバックアップしか残らず詰みます
- 目安として、日次バックアップを最低7〜14日、週次または月次のスナップショットを1〜3ヶ月は残す構成が現実的な最低ラインです
- 法的要件(会計データの保存年数など)がある業種は、事業要件からリテンション期間を逆算する必要があります
3. オフサイト(別リージョン・別アカウント)に保管されているか
同一サーバー・同一リージョン・同一クラウドアカウントにしかバックアップがない構成は、「バックアップ元と一緒に消える」リスクを抱えています。
- 本番DBと同じEC2インスタンス内にバックアップファイルを置いているだけ、というのは典型的な落とし穴です。インスタンスが飛べば両方消えます
- 最低限、別のストレージ(S3等)への転送、可能であれば別リージョン・別アカウントへのレプリケーションを行う
- アカウント自体が乗っ取られた場合に備えるなら、バックアップの削除権限を本番運用アカウントと分離しておくとより堅牢です
4. PITR(Point-in-Time Recovery)が使えるか
日次バックアップだけでは、「今朝9時に事故が起きた」場合、前日深夜時点までしか戻せず、当日の正常なデータもすべて失います。
- PITRは、WAL(Write-Ahead Log)などのトランザクションログを継続的に保存し、任意の秒単位の時点まで復元できる仕組みです
- RDS・Cloud SQLなどのマネージドDBは、多くの場合オプションで有効化できます。既存プロダクトで無効になっているケースは頻繁に見かけます
- オペレーションミスによる部分的なデータ破損(全体消失ではなく特定テーブルの誤更新など)への対応力が、日次バックアップのみとPITR併用とでは大きく変わります
5. 復元テストを実施した記録があるか(最重要)
ここが最も見落とされているポイントです。バックアップは「取れているか」ではなく「復元できるか」で評価しなければ意味がありません。
- バックアップファイルが破損していた、暗号化キーが失われていた、復元手順が古いバージョン前提で今の構成と合わない——これらは「実際に復元してみるまで」発覚しません
- 復元テストを一度も実施していない場合、それは「バックアップがない」のとリスクの水準がほぼ同じです
- 目安として、四半期に1回は本番と隔離された環境でリストア訓練を行い、「復元にかかった時間」「復元後のデータ整合性」を記録に残すべきです
最小構成での立て直し方
予算やスケジュールの制約がある中で、何から着手すべきかの優先順位です。
- 自動バックアップの有効化と実行確認(最優先・即日〜数日で対応可能)。ここが崩れていると他の対策は無意味です
- オフサイトへの転送設定。同一環境依存のリスクを最初に排除します
- 復元テストの実施と手順書化。1回動かしてみるだけで「復元できない」問題が見つかることが多く、ここで発覚した手順の穴を潰します
- PITRの有効化。日次バックアップの運用が安定してから追加するのが現実的です
- リテンション期間の見直しと定期訓練の仕組み化(四半期ごとの復元訓練をカレンダーに組み込む)
小規模なプロダクトであれば、1と2は数日、3を含めても1〜2週間程度で最低限の安全網は構築できます。「全部を一気に完璧にする」必要はなく、まず復元できることを1回確認することが最も費用対効果の高い一歩です。
外注するときの進め方
バックアップ・復元の整備を外部に依頼する場合、次の流れが現実的です。
- 現状の自動バックアップ設定・保持期間・保存先を棚卸しし、事業要件(許容できるデータ損失範囲=RPO、復旧までの許容時間=RTO)を確認する
- 不足している設定(オフサイト転送、PITR、リテンション)を洗い出し、優先順位をつけて段階的に整備する
- 復元テストを実際に実施し、手順書として残す。ここまでやって初めて「バックアップが機能している」と言えます
- 定期的な復元訓練をCI/CDや運用フローに組み込み、担当者が変わっても仕組みとして維持できるようにする
この一連の流れは、既存プロダクトの改善で最初に確認すべき観点の一つでもあります。バックアップは地味な項目ですが、確認を怠ると事業継続そのものを揺るがすため、監視体制の整備(監視がない本番システムを改善する最初の一歩)と並んで最優先で手をつけるべき領域です。
torcheees では データベース を中心とした既存プロダクトのインフラ診断・改善を、保守・運用のサービスとして提供しています。
まとめ
- バックアップは「取っていること」ではなく「復元できること」で評価する。復元テストを一度もしていない状態は、バックアップがないのとリスク水準がほぼ同じ
- 自動化・保持期間・オフサイト保管・PITR・復元テストの5点を事実ベースで棚卸しし、自動バックアップの有効化と復元テストの実施から着手するのが最も費用対効果が高い
- 復元訓練は一度きりで終わらせず、四半期ごとなど定期的な仕組みとして運用に組み込むことで、担当者が変わっても安全網が維持される
「バックアップが取れているか自信がない」という段階でも、torcheees はご相談を受け付けています。まずは1〜4週間の「開発診断」で、現状のバックアップ・復元体制を一通り確認し、改善の優先順位と概算費用をご提示します。お問い合わせフォームからお気軽にご連絡ください。