この記事の結論：業務システムのバックアップで確かめるべきなのは、「毎日取れているか」ではなく、「決めた時点まで、決めた時間内に、実際に戻せるか」です。確かめ方は、本番とは別の名前でデータを戻し、中身と動きを見て、かかった時間を記録する「復元テスト」です。そのために、先に「どこまで戻せればよいか」と「どのくらいで戻したいか」を業務の言葉で決めておきます。AWS のデータベース（Amazon RDS）なら、時点を指定した復元で元のデータベースに触れずにテストができ、AWS Backup の復元テストを使えば定期的な実行も自動にできます（どちらも AWS の公式ドキュメントに手順あり）。
株式会社bundlyzeでは、要件定義から開発、保守運用まで、業務システムを一通り手がけています。この記事は、システムを使っている会社の担当者や、保守を受け持つ開発者が、バックアップを「本当に戻せる状態」にしておくための作業の手順です。特定の会社の事例ではなく、AWS の公式ドキュメントと、IPA（情報処理推進機構）のガイドラインをもとにした一般的な進め方です。
「取れている」と「戻せる」の間にある落とし穴
バックアップの設定画面で「有効」と表示されていても、いざ戻すときに困ることがあります。よくあるのは次のような場面です。
| 安心していた状態 |
戻そうとしたときに分かること |
| データベースの自動バックアップを使っている |
保持期間が 0 日になっていて、自動バックアップ自体が無効だった |
| 古いデータベースを削除しても、バックアップは残ると思っていた |
削除のときに保持を選ばなかったので、自動バックアップも一緒に消えていた |
| 戻せば元どおりに動くと思っていた |
戻した先は新しいデータベースで、システムの接続先を切り替える作業が別に要る |
| データベースを戻せば全部戻ると思っていた |
添付ファイルや画像は別の保存先にあって、そちらは戻っていない |
| 手順書がある |
手順書を書いた人しか実際に戻したことがない |
Amazon RDS の場合、自動バックアップの保持期間は DB インスタンスで 0〜35 日の間で設定でき、0 にすると自動バックアップが無効になります（出典：Amazon RDS ユーザーガイド：バックアップ保持期間）。また、DB インスタンスを削除するときに「自動バックアップの保持」を選ばないと、自動バックアップはインスタンスと一緒に削除されます（出典：Amazon RDS ユーザーガイド：自動バックアップの管理）。
どれも、一度戻してみれば先に気づけることです。
IPA が中小企業向けに公開しているセキュリティ対策のガイドラインは第4.0版で、最初に取り組む対策を「情報セキュリティ6か条」とし、バックアップを新たに加えています（出典：IPA：中小企業向けセキュリティ対策ガイドライン（第4.0版））。取るだけでなく、戻せることまでを確かめておくのが、この記事の範囲です。
先に決める2つのこと：どこまで戻すか、どれくらいで戻すか
復元テストの合格・不合格は、先に決めた基準と比べて判断します。決めるのは次の2つです。
| 決めること |
業務の言葉での問い |
一般的な呼び方 |
| どの時点まで戻せればよいか |
最悪の場合、どのくらい前の状態に戻っても業務を続けられるか（何時間分の入力をやり直せるか） |
目標復旧時点（RPO） |
| どのくらいの時間で戻したいか |
システムが止まってから、何時間までなら紙や電話でしのげるか |
目標復旧時間（RTO） |
数字は業務によって違うので、システムを使う部署の人と一緒に決めます。開発者だけで決めると、技術的に楽な値になりがちです。
Amazon RDS の時点を指定した復元では、トランザクションログが5分ごとに保存されるため、通常は直近の数分前までの任意の時点に戻せます。いつまで戻せるかは LatestRestorableTime で確かめられます（出典：Amazon RDS ユーザーガイド：DB インスタンスを特定の時点に復元する）。「どこまで戻せるか」は設定で決まり、「どれくらいで戻せるか」は実際に戻してみないと分かりません。後者を測るのが復元テストです。
復元テストの手順
ここでは Amazon RDS を例に、手で行う場合の流れを書きます。ほかのデータベースでも、考え方は同じです。
- 対象の一覧を作る。 データベース、アップロードされたファイルの保存先、設定値、外部サービスの連携設定。どれが、どこに、どの方法でバックアップされているかを1枚の表にします
- 今の設定を確かめる。 保持期間が 0 になっていないか、戻せる最新の時刻がいつかを確かめます
- 別の名前で戻す。 本番のデータベースは変えずに、テスト用の名前で新しく作ります
- 中身を確かめる。 主な表の件数、いちばん新しいデータの日時、決めた時点の前後のデータがあるかを見ます
- システムをつないで動かす。 検証用の環境の接続先を、戻したデータベースに向けて、画面を開き、検索や一覧表示、添付ファイルの表示まで試します
- かかった時間を記録する。 作業を始めてから、システムが使える状態になるまでの時間を測ります。データベースの作成時間だけでなく、接続先の切り替えや確認の時間も含めます
- 片付ける。 テスト用に作ったデータベースを削除します。残したままにすると費用がかかり続けます
手順2と3は、AWS CLI なら次のような形です（mydb は実際の識別子に置き換えます）。
保持期間と、戻せる最新の時刻を確かめるbash aws rds describe-db-instances \
--db-instance-identifier mydb \
--query "DBInstances[0].[BackupRetentionPeriod,LatestRestorableTime]"
本番を変えずに、別の名前で時点を指定して戻すbash aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier mydb \
--target-db-instance-identifier mydb-restore-test \
--restore-time 2026-10-01T09:00:00Z
戻した先は新しいデータベースなので、本番で障害が起きたときも、システムの接続先を新しいほうへ向け直す作業が要ります。手順5でこの切り替えを一度通しておくと、本番のときに迷いません。
確かめる項目と、残しておく記録
復元テストは、記録が残っていないと「やったはず」で終わってしまいます。毎回、同じ形で残します。
| 記録する項目 |
書く内容 |
| 実施日と担当者 |
誰がいつ行ったか。毎回同じ人にしない |
| 対象 |
どのデータベース・保存先を戻したか |
| 戻した時点 |
指定した時刻と、実際に入っていた最新データの日時 |
| かかった時間 |
開始から、画面で使える状態になるまで |
| 確かめた内容 |
件数、最新データ、画面の動き、添付ファイル |
| 基準との比較 |
先に決めた2つの基準を満たしたか |
| 気づいたこと |
手順書と違った所、迷った所、直すこと |
「気づいたこと」の欄で出てきた点は、手順書に戻して直します。次に担当する人が、この記録と手順書だけで戻せるようになっていれば、テストの目的は果たせています。
定期的に回すなら、AWS Backup の復元テスト
手で行う復元テストは、忙しい時期に後回しになりがちです。AWS Backup には、決めた頻度と時刻で復元を自動で実行し、復元にかかった時間を記録する「復元テスト」の機能があります。対象には Amazon RDS や Amazon S3、Amazon DynamoDB などが含まれ、テストで作られたリソースは、検証が終わるか検証の時間枠が過ぎると削除されます（出典：AWS Backup デベロッパーガイド：復元テスト）。
ただし、自動のテストで分かるのは「戻る処理が成功したか」と「どのくらいかかったか」までです。システムをつないで画面を開く確認や、接続先を切り替える練習は、自動では代わりにならないので、手で行う回も残しておきます。
保守の範囲として決めておく
復元テストは、誰かが決めないと誰もやらない作業です。システムを使う会社の側から、保守を受け持つ相手に、次の3つを確かめておくと安心です。
- バックアップの対象の一覧と、それぞれの保持期間
- 復元テストを行う頻度と、記録を共有してもらう方法
- 本番で戻すときの判断を、誰がするか
クラウドの構成やバックアップの設定が、担当者しか分からない状態になっているなら、まず今の状態を一覧にするところから始めます。監視・バックアップの仕組みづくりや、運用手順の整理については、会社サイトのクラウド構築・移行・運用支援のページで紹介しています。
※出典のページは、どれも2026年10月2日に開いて内容を確かめました。AWSの仕様や画面は更新されるので、作業の前に最新版を見てください。
