「本当に戻せる」を確かめるバックアップ復元テストの手順
「バックアップは毎日取れています」。 そう答えられる現場は多いと思います。でも、「そのバックアップから、本当に元へ戻せますか」と聞かれると、少し言葉に詰まる——そんな経験はないでしょうか。
バックアップは、取ることがゴールではありません。いざというときに戻せて、はじめて意味があるものです。ところが、取る仕組みは自動化されていても、戻す手順を一度も試していない現場は、実はとても多いのです。そして、戻せないと気づくのは、たいてい一番戻したい瞬間だったりします。
この記事では、そんな「取れているけど、戻したことはない」状態から一歩進んで、こわくないリストア（復元）テストの進め方を一緒に整理します。壊す練習ではなく、「戻せる」と自分で確かめて安心するための手順です。
結論：復元テストは、①戻す先（検証環境や別の場所）を用意する → ②バックアップから実際に戻してみる → ③戻したものが正しく動くか確認する → ④かかった時間と手順をメモに残すの順で進めます。いきなり本番で試す必要はありません。「別の場所に、戻してみる」だけで、バックアップが生きているかどうかは確かめられます。
バックアップの形式（データベースのダンプか、ファイル一式か、まるごとイメージか）や道具は現場でさまざまです。手順の中身より、「取る」と同じくらい「戻す」を確かめておくという考え方を持ち帰ってもらえたら十分です。
何が起きているか：バックアップが「戻せない」よくある理由
バックアップから戻せない、というと大げさに聞こえますが、原因の多くは特別なものではありません。「ちゃんと取れているはず」の思い込みと、確かめる機会がなかっただけ、ということがほとんどです。
- バックアップが途中で壊れている / 空になっている：ジョブは動いていても、容量不足やエラーで中身が欠けていることがあります。ログが「成功」でも、ファイルの中身までは保証してくれません。
- 戻す手順を誰も知らない：取る設定はしたけれど、戻すコマンドや順番を書いた紙が一枚もない。いざというとき、手が止まります。
- 一部しか取れていない：データベースは取れているが、アップロードされた画像や設定ファイルは対象外だった——という「取り漏れ」も定番です。
- 復元に想像以上の時間がかかる：戻せたけれど、丸一日かかった。それでは間に合わない、という時間の問題もあります。
これらは、どれも一度戻してみれば事前に気づけることばかりです。次から、その「一度戻してみる」を、安全に進める手順を見ていきます。
リストアテストを安全に進める4ステップ
大事なのは、本番を触らない場所で試すことです。検証環境、使っていないサーバー、手元の仮想環境——どこでもかまいません。「別の場所に戻して、動くか見る」だけで、テストとしては十分に価値があります。
① 戻す先（復元先）を用意する
まず、バックアップを戻しても本番に影響しない場所を1つ決めます。ここが決まらないと、テスト自体がこわくて踏み出せません。
- 検証環境があるなら、それが一番自然です。
- なければ、クラウドで一時的にサーバーを1台立てる、手元のPCに仮想環境を作る、などでも構いません。
- データベースだけなら、別名のデータベースを1つ作って、そこへ戻すだけでもテストになります。
ポイントは、「戻す先は本番とは別」という一線を守ることです。ここさえ守れば、失敗しても本番は無傷なので、落ち着いて試せます。
② バックアップから実際に戻してみる
用意した場所に、普段取っているバックアップから、実際に復元します。ここで初めて、「戻す手順」が言葉になります。
- どのファイル（どの日付のバックアップ）を使うかを決める。
- 復元のコマンドや操作を、一つずつ実行しながらメモに書き起こす。
- 途中でエラーが出たら、それ自体が大きな収穫です。「本番で困る前に、テストで見つかった」と考えてください。
初めてだと、コマンド一つに何分も悩むかもしれません。それで大丈夫です。この「悩んだ跡」こそ、次に戻すときの手順書になります。頭の中にしかなかった手順が、初めて外に出た瞬間です。
③ 戻したものが正しく動くか確認する
戻せた、で終わりにしないのがコツです。戻したデータやファイルが、ちゃんと使える状態かを確認します。
- データベースなら、件数がだいたい合っているか、最新のデータまで入っているかを見る。
- アプリなら、ログインできるか、主要な画面が表示されるか、画像が欠けていないかを見る。
- 「取れていたつもりで、実は対象外だったもの」がここで見つかることがよくあります（設定ファイル、アップロード画像、cronの設定など）。
全項目を厳密に検査する必要はありません。「これが動けば、まず業務は再開できる」という数点に絞って確認すれば十分です。
④ かかった時間と手順をメモに残す
最後に、「どれくらいの時間で、どうやって戻せたか」を1枚に残します。これがリストアテストの一番の成果物です。
- 復元にかかった時間（30分か、半日か、で心構えが変わります）。
- 実行したコマンドや操作の順番。
- つまずいた点と、その回避方法。
- 「取れていなかったもの」があれば、バックアップ対象に追加する。
この1枚があれば、次に戻すときは「初めて」ではなくなります。自分が倒れても、引き継いだ人が同じ手順でたどれる。バックアップが、本当の意味で「保険」になる瞬間です。
具体例：小さなECサイトで「別DBに戻してみる」
WordPressで動く小さなECサイトを、一人で保守しているとします。毎晩、データベースのダンプとファイル一式が自動で保存されている——でも、戻したことは一度もない、という状況で考えてみます。
- ①戻す先：本番と同じサーバー内に、
shop_restore_testという別名のデータベースを1つ作る。ファイルは本番とは別のフォルダに展開する。 - ②復元：昨夜のダンプを、その別DBへ読み込む。コマンドを1行ずつメモしながら実行。途中で文字コードの指定を忘れて文字化けし、そこで「復元時は文字コードを合わせる」という一行がメモに増える。
- ③確認：別フォルダに置いたWordPressから、この別DBを一時的に参照して表示テスト。トップと商品ページは出たが、商品画像が一部欠けていた → 画像フォルダがバックアップ対象から漏れていたと判明。
- ④記録：復元は約40分。手順とつまずきをメモに残し、翌日にバックアップ設定へ画像フォルダを追加した。
「戻せるか不安」だった状態が、「40分で戻せる。ただし画像フォルダの取り漏れを直す」という具体的な現在地に変わりました。テストをしなければ、この取り漏れは本番障害のときに初めて分かっていたはずです。
影響：一度戻しておくと、何が変わるか
リストアテストを一度やっておくと、技術力そのものより先に、気持ちの余裕が変わります。
- 「たぶん戻せる」ではなく「40分で戻せる」と、根拠を持って言える。
- 障害やデータ消失のとき、手順書を見ながら落ち着いて動ける。
- 「取れているつもりで取れていなかったもの」を、平時のうちに直せる。
- 上司や取引先に「復旧にかかる時間の目安」を、憶測でなく実測で伝えられる。
逆に、一度も戻していないバックアップは、いざというとき「戻せるかどうか、やってみないと分からない」状態のままです。一番あわてている瞬間に初挑戦することになり、これが一番こわいパターンです。平時の落ち着いた30分が、有事の消耗した半日を救ってくれます。
明日やること：ひとつのバックアップを「別の場所」に戻してみる
大がかりな訓練は要りません。明日できる、いちばん小さな一歩はこれです。
- 今取れているバックアップの中から、戻しやすいもの1つを選ぶ（データベースのダンプが手軽です）。
- 本番に影響しない戻す先を1つ用意する（別名のDB、別フォルダ、手元の仮想環境など）。
- そこへ実際に戻してみて、コマンドや操作をメモに書き起こす。
- 戻したものが動くか、主要な数点だけ確認する。
- かかった時間と、つまずいた点を1行ずつ残す。
全部を一日でやろうとしなくて大丈夫です。まずは「別DBにダンプを1つ戻してみる」だけでも、バックアップが生きているかどうかは分かります。それが確認できただけで、今夜は少し安心して眠れます。
「リストアテスト」チェックリスト
復元テストをするとき、これだけ押さえられているかを見る項目です。コピーして、自分のメモに当ててみてください。全部を毎回そろえる必要はありません。
まず外せない最低ラインはこの3つです。時間がなくても、ここだけは確かめます。
- 【最低ライン】本番に影響しない「戻す先」を用意したか
- 【最低ライン】バックアップから実際に戻せたか（エラーなく完了したか）
- 【最低ライン】戻したものが、主要な部分だけでも正しく動いたか
次の項目は、余裕があるとき・より確実にしたいときに追加で確認します。当てはまらなければ飛ばして大丈夫です。
- データベースだけでなく、ファイル・画像・設定も対象に含まれているか
- 復元にかかった時間を計り、記録したか
- 実行した手順（コマンド・順番）をメモに書き起こしたか
- 「取れていなかったもの」が見つかったら、バックアップ対象に足したか
- 手順書を、自分以外の人でもたどれる形にしたか
- バックアップは、本番とは別の場所（別サーバー・別リージョン等）にも置いてあるか
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「別の場所に戻せた」さえ確かめられれば、取りっぱなしのバックアップより、ずっと心強い一歩になります。
よければ、こちらも
バックアップと復元は、作業前・障害時の「戻す備え」とセットにしておくと、いざというとき慌てずに済みます。前後の手順も軽く整えておくと安心です。
- 本番反映前のチェックリストと作業前バックアップの取り方：変更のたびに「戻せる状態」を作っておくための、作業前バックアップの手順です。
- 「すぐ戻せる」リリース設計｜ロールバック手順の用意：リリースを一手で戻すための、ロールバックの考え方をまとめています。
- 障害対応 runbook テンプレート｜初動・切り分け・連絡・記録：復元が必要になる障害の場面で、落ち着いて動くための型です。
バックアップが不安なのは、取れているか分からないからではなく、戻せるか確かめていないからです。でも、別の場所に一度戻してみるだけで、その霧はかなり晴れます。 今日は、ダンプを1つ、別のDBに戻してみるところからで十分です。その40分が、いつか一番あわてている自分を、静かに助けてくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。