MENU

問い合わせ


    「バックアップは取っています」と言われたけれど、本当に戻せる?復元テストを誰がどう行うか、発注者が確認する5つのこと

    システムの運用を任せている開発会社から「バックアップは毎日取っています」と報告を受けた。安心したいところですが、「では、実際に元に戻した人はいるのだろうか」と気になったことはありませんか。

    「バックアップは取っていると言われたが、本当に元に戻せるのか確認したい。復元テストは誰がどう行うのか分からない」

    先に結論をお伝えします。バックアップは「取っている」だけでは足りず、「戻せた」ことが確認できて初めて役に立ちます。 発注者がITの操作をする必要はありませんが、「いつ・誰が・どのデータを・どのくらいの時間で戻せたか」の記録を、定期的に見せてもらう約束をしておくことが大切です。

    この記事では、復元テスト(=取ったバックアップから実際にデータを戻せるかを試すこと)の考え方と、AWSでの自動化の例、発注者が開発会社に確認したい5つのこと、そのまま使えるチェックリストと質問例を解説します。(情報は2026年10月時点のものです)

    目次

    なぜ「取っている」だけでは安心できないのか

    バックアップが壊れていても、取った時点では分からない

    バックアップは、取った時点では「ファイルができた」ことしか分かりません。そのファイルから本当にシステムが元通りになるかは、戻してみるまで分からないのです。

    たとえば、次のようなことが戻す段になって初めて見つかることがあります。

    • バックアップの中に、肝心のデータ(画像ファイルや添付書類など)が含まれていなかった
    • 暗号化に使った鍵へのアクセス権がなく、開けなかった
    • 戻す手順を書いた人が異動・退職していて、誰も手順を知らなかった
    • 戻すのに想定の何倍も時間がかかり、業務の再開が間に合わなかった

    公式の設計指針も「取るだけ」では終わらせない

    AWS(Amazon Web Services)が公開しているクラウド設計の指針(Well-Architected フレームワーク)では、バックアップは人手に頼らず自動で、システムの許容できるデータ損失の範囲(RPO)に合わせて取ることが推奨されています。

    📰 出典:AWS Well-Architected フレームワーク「REL09-BP03 データバックアップを自動的に実行する」

    RPO(=直前のどの時点までのデータに戻せればよいかの目標。「最大で1日分は失ってもよい」など)を決めたうえで、その頻度で自動的に取る、という考え方です。そして、その先の「戻せるか」を確かめる手段として、AWSは復元テストの仕組みも用意しています。

    復元テストとは何か:AWSの機能を例に

    AWSには、バックアップを一元管理する AWS Backup というサービスがあり、その機能のひとつに「復元テスト」があります。公式ドキュメントでは次のように説明されています。

    📰 出典:AWS Backup 開発者ガイド「Restore testing」

    ドキュメントによると、この機能は復元できる見込みを自動で定期的に評価し、復元にかかった時間も記録します。流れは次のとおりです(執筆時点)。

    1. 復元テストの計画を作る(テストの頻度と開始時刻を決める)
    2. テスト対象のデータを割り当てる(データベース、ファイルの保管場所、サーバーのディスクなど)
    3. 予定の時刻になると、取ったバックアップのうち最新の1つ、または無作為に選んだ1つを実際に復元する
    4. 復元にかかった時間などの結果が記録される
    5. 任意の「検証」を行い、復元したデータが正しいかを確認する(検証はコンソールの画面からではなく、プログラムから実行する仕組みです)
    6. テスト用に復元したデータは、確認後に自動で削除される

    つまり、本番のデータとは別の場所に復元して中身を確かめ、終わったら片づけるという作業を自動化できます。結果は「復元が成功したか」「何時間かかったか」の記録として残るため、発注者への報告や社内の監査の材料にもなります。

    ここで押さえておきたい点が3つあります。

    • 対象のサービスは決まっている:ドキュメント上、Aurora・RDS・DynamoDB・EBS・EC2・EFS・S3など主要なものが対象ですが、すべてのデータが対象とは限りません。自社のシステムのどのデータが対象になっているかの確認が必要です
    • 費用がかかる:復元テストには1回ごとの料金があり、復元したデータの保管にも一時的な費用がかかります。ドキュメントでも、最初は対象を絞って始め、平均的な費用を把握することが勧められています
    • 「検証」は別途の作り込みになる:復元が成功することと、中身が正しいことは別の話です。注文データの件数が合うか、といった確認は、システムの中身を知る開発会社が検証の仕組みを用意する必要があります

    ※ AWS以外のクラウドやレンタルサーバーにも似た仕組みがありますが、機能や料金は各社で異なります。ご利用の環境の公式情報を確認してください。

    「戻せる」を確認する5つのこと

    1. 何を、どこまで戻せる約束か(RPOとRTO)

    まず「どこまで戻せればよいか」を、発注者と開発会社で言葉にしておきます。

    用語意味決め方の例
    RPO(目標復旧時点)障害の直前のどの時点までのデータに戻せるか「最大で前日の夜まで」「1時間前まで」
    RTO(目標復旧時間)障害からどのくらいの時間で業務を再開できるか「半日以内」「翌営業日の朝まで」

    短くするほど費用は上がります。業務への影響(売上・信用・法令上の義務)から逆算して決めるのが発注者の役割です。

    2. 復元テストを「誰が・いつ・どの頻度で」行うか

    「やっています」ではなく、担当者と頻度を決めてもらいます。

    • 担当:開発会社か、保守会社か、自社か。自動化されている場合は、その結果を見る担当は誰か
    • 頻度:たとえば「四半期に1回」「システムの大きな変更の後」。AWSの復元テストのように自動化すれば、月1回など高い頻度でも負担が少なくなります
    • 対象:データベースだけでなく、アップロードされたファイルや設定ファイルも含むか

    3. 「戻せた」と言える合格基準

    復元が「完了」しただけでは合格とは言えません。何を見て合格とするかを事前に決めておきます。

    • 復元にかかった時間が、1で決めたRTOに収まっているか
    • 主要なデータの件数・最新の日付が、バックアップ時点と合っているか
    • 復元したデータでシステムが起動し、ログインや主要な画面が動くか

    4. テスト結果の記録と報告

    結果は残し、発注者が見られるようにします。最低限、次の項目が分かれば十分です。

    • 実施日、対象のデータ、使ったバックアップの日時
    • 復元にかかった時間
    • 合格・不合格と、不合格なら原因と直した内容

    AWSの復元テストは、復元にかかった時間などが記録として残る仕組みです。契約や保守報告書に「復元テストの結果を定期報告に含める」と書いておくと、確認が習慣になります。

    5. 費用と、本番への影響

    復元テストにも費用と手間がかかります。見積もりの段階で、次を確認しておくと後から驚きません。

    • 復元テストの費用は、保守費に含まれるか、別途かかるか
    • テストは本番のシステムとは別の場所で行い、本番の動作に影響しないか
    • 本番のデータをテストに使う場合、個人情報の扱い(アクセスできる人・削除のタイミング)はどうなるか

    やりがちな失敗

    • 「バックアップ完了」の通知だけで安心する:通知は「ファイルができた」ことしか示しません
    • 最初に1回試して、それきりにする:システムは作り替えられていきます。変更のたびに戻せる内容も変わるため、定期的に確認する必要があります
    • 復元手順が一人の頭の中にしかない:担当者が不在でも戻せるよう、手順書として残してもらいます
    • 本番と同じ場所に復元して、本番を上書きしてしまう:テストは別の場所で行うのが基本です

    発注者がやることチェックリスト

    • ☐ 「どこまでのデータに戻せればよいか(RPO)」を決めた
    • ☐ 「どのくらいの時間で再開したいか(RTO)」を決めた
    • ☐ 復元テストを行う担当者と頻度を、開発会社と合意した
    • ☐ 復元テストの合格基準(時間・件数・画面の動作)を書面にした
    • ☐ 結果を定期報告に含めてもらう約束をした
    • ☐ 直近の復元テストの実施日と結果を見せてもらった
    • ☐ 復元テストの費用が見積もりや保守費に含まれているか確認した
    • ☐ 戻し方の手順書が、担当者以外でも読める形で残っている

    開発会社への質問例

    • 「バックアップから実際にデータを戻したテストは、いつ・どの範囲で行いましたか?その結果を見せていただけますか?」
    • 「障害が起きた場合、直前のどの時点まで戻せて、業務再開までにどのくらいかかる想定ですか?」
    • 「復元テストは今後どのくらいの頻度で行い、結果はどのように報告いただけますか?」
    • 「データベース以外のアップロードファイルや設定も、復元テストの対象に入っていますか?」
    • 「復元テストの費用は現在の保守費に含まれていますか?別途かかる場合の目安を教えてください」

    答えが「毎日取っているので大丈夫です」だけの場合は、悪気があるとは限りません。復元テストが契約や見積もりの範囲に入っておらず、手が回っていない場合もよくあります。責める必要はなく、「確認の仕組みを一緒に決めたい」という姿勢で相談すると進めやすくなります。

    まとめ:バックアップは「戻せた記録」までがセット

    • バックアップは取った時点では、戻せるかどうか分からない
    • まず、どこまで・どのくらいの時間で戻したいか(RPO・RTO)を決める
    • 復元テストの担当・頻度・合格基準を決め、結果を記録に残す
    • AWSなど、復元テストを自動化できる仕組みもある。費用と対象範囲は事前に確認する

    なお、サーバーを複製して冗長化していても、誤ってデータを消してしまえば複製も一緒に消えます。複製とバックアップの違いについては冗長化したのにデータを消したら戻せなかった…複製とバックアップの違いと、発注時に決める4つのこともあわせてご覧ください。

    あわせて読みたい関連記事

    システム制作・運用・保守のお問い合わせはこちら


      よかったらシェアしてね!
      • URLをコピーしました!
      • URLをコピーしました!

      この記事を書いた人

      株式会社THIRD HERO代表取締役 朝野貴朗
      Webシステム開発を中心に、toC向けサービスサイトの運営、ツール開発などを行ってまいりました。

      コメント

      目次