午前3時、サーバーの警告アラートが担当者のスマートフォンを鳴らした。ディスクアレイの障害で、基幹システムのデータベースが読み込み不能になっていた。焦りながらも、彼は落ち着いていた。3年間、毎晩欠かさずバックアップを取り続けてきたからだ。深夜のバッチジョブが正常終了したという通知メールも、毎朝欠かさず確認していた。だから今回も、いつも通りバックアップから復元すれば数時間で元に戻せるはずだった。
しかし、いざ復元コマンドを実行すると、エラーメッセージが表示された。バックアップファイルが破損していて読み込めない。念のため1週間前のファイルを試したが、同じエラーが出た。1ヶ月前まで遡っても結果は同じだった。原因を調べると、3ヶ月前のストレージ設定変更の際に、バックアップの書き込み先パスがわずかに変わっており、それ以降のバックアップは実際には空のファイルか壊れたファイルとして保存され続けていたことが判明した。ジョブの成功通知は、ファイルの中身までは検証していなかったのだ。結局、復元できたのは3ヶ月以上前のデータまでで、その間に積み重ねた受注データや顧客とのやり取りの記録は、二度と戻らなかった。
この担当者を責めることは誰にもできない。彼は毎晩、決められた時間にバックアップジョブが動いていることを確認し、ディスク容量にも気を配り、業務終了後もログをチェックしていた。真面目に、地道に、誰に褒められるわけでもなく毎日その作業を続けてきた。それでも、いざという瞬間に会社を守れなかった。この理不尽さこそが、バックアップ運用という仕事の本当の怖さであり、同時に、多くの中小企業の情報システム担当者が抱える見えない不安の正体でもある。壁を越えて働いてきた人ほど、この落とし穴に気づいていないことが多い。
「バックアップを取っている」ことと「復元できる」ことは別問題である
多くの企業がバックアップ体制について語るとき、話題の中心は取得の頻度や保存先、世代管理の設計に集中しがちだ。毎日取得している、クラウドにも保存している、3世代残している。こうした説明を聞くと、一見盤石な体制に見える。しかし、これらはすべて「バックアップを取得できているかどうか」の話であって、「そのバックアップから実際にシステムを復元できるかどうか」とは、まったく別の話である。
バックアップジョブが正常終了のログを吐き出したからといって、そのファイルが完全であるとは限らない。書き込み中にディスクの空き容量が不足していた、ネットワークが瞬断してファイルの一部だけが転送された、暗号化キーが途中でローテーションされて復号できなくなった。こうした事態が起きても、ジョブ自体は「エラーなく終了」したという記録だけが残ることは珍しくない。ファイルは確かに存在する。しかし中身が壊れている。この状態に気づく唯一の方法は、実際にそのファイルを使って復元を試みることだけだ。
言い換えれば、バックアップの取得は「保険料を払っている」段階に過ぎない。保険は、いざ事故が起きたときに保険金が実際に支払われて初めて意味を持つ。契約書だけを大切に金庫にしまっておいても、請求手続きの窓口が分からなければ、いざという時に一円も受け取れない。バックアップも同じで、復元という「請求手続き」を一度も経験していない状態は、実質的に保険に入っていないのと変わらない。
復元できない・失敗する典型的な原因
実際に障害対応の現場で復元に失敗する原因を分解すると、いくつかの典型的なパターンに集約される。いずれも、日常業務の中では見過ごされやすい落とし穴だ。
バックアップファイルの破損に誰も気づいていない
冒頭の事例のように、バックアップジョブの成否は「プロセスが正常終了したかどうか」だけで判定されていることが多い。ファイルサイズが極端に小さくなっていないか、チェックサムが一致しているか、そもそもファイルを開いて中身を検証できるか。こうしたチェックまで行っている企業は驚くほど少ない。破損は静かに進行し、誰かが実際に復元を試みるまで表面化しない。そしてその「誰かが試みるとき」は、たいてい本番障害の真っ只中である。
復元手順書が存在しない、あるいは古い
バックアップの取得手順は誰かが整備していても、復元の手順書は一度も作られていない、というケースは非常に多い。あるいは数年前に作成されたきり、サーバーの構成やソフトウェアのバージョンが変わっているのに更新されていない。障害発生時は担当者の頭の中も真っ白になりやすい。そんな状況で「このコマンドで復元できるはずだ」という曖昧な記憶を頼りに作業を進めると、手順を一つ間違えるだけで復元自体が失敗したり、さらにデータを壊してしまうことすらある。
復元にかかる時間を誰も計測していない
データ量が数十ギガバイトから数百ギガバイト、あるいはテラバイト単位に膨らんでいる場合、復元には想定以上の時間がかかることがある。取引先への納期回答や、店舗のレジシステム、受発注システムなど、止まっている時間そのものが売上や信用に直結する業務であれば、復元に半日かかるのか、8時間かかるのか、あらかじめ把握しているかどうかで経営判断はまったく変わってくる。多くの企業では、この所要時間を一度も実測したことがなく、障害発生後に「あと何時間かかるのか分からない」という状態で、取引先への説明にも窮することになる。
担当者の異動・退職で復元できる人がいなくなる
バックアップの仕組みを構築した担当者が異動や退職でいなくなり、後任者が仕組みの詳細を引き継いでいないケースもある。ジョブは動き続けているが、いざという時にどう復元すればよいのか分かる人が社内に誰もいない。属人化したバックアップ運用は、担当者がいなくなった瞬間に機能を失う。
復旧訓練(リストアテスト)とは何か
こうした落とし穴を防ぐ唯一の方法が、復旧訓練、いわゆるリストアテストである。復旧訓練とは、本番環境とは別の場所に、実際に取得したバックアップファイルを使ってシステムを復元し、正しく動作するかどうかを確認する取り組みを指す。取得したバックアップを「本当に使えるかどうか」を、平時のうちに、緊急性のない状況で検証しておくということだ。
具体的には、次のような要素を確認する。
- バックアップファイルが破損せずに読み込めるか
- 復元手順書の通りに作業を進めて、実際にシステムが起動するか
- 復元後のデータが、想定した時点の内容と一致しているか
- 復元にかかった実際の所要時間はどれくらいか
- 復元作業を、手順書だけを見て、担当者以外の人間が実施できるか
これらを一つずつ確認していくと、平時には見えていなかった問題が次々と表面化する。手順書に書かれたコマンドがすでに古いバージョンのソフトウェアのものだった、復元先のサーバーのディスク容量が足りなかった、そもそも復元後にアプリケーションを再起動する手順が抜け落ちていた。こうした発見は、復旧訓練を実施した企業のほぼすべてが経験するといっていい。逆にいえば、一度も復旧訓練をしていない企業は、これらの問題に気づかないまま、本番障害の当日に初めてそれを知ることになる。
中小企業でも無理なくできる復旧訓練の始め方
復旧訓練と聞くと、大規模なシステムを持つ企業だけが行う特別な取り組みだと感じるかもしれない。しかし実際には、中小企業こそ限られた人員と予算の中で、無理のない範囲から始めることができる。重要なのは、完璧な訓練を一度に実現しようとせず、小さく始めて習慣化することだ。
頻度は年2回から始める
理想をいえば四半期に一度が望ましいが、まずは年2回、半期に一度のペースで構わない。重要なのは「継続すること」であり、頻度の高さよりも、確実に実施され続けることの方が価値がある。カレンダーに固定の予定として登録し、担当者の異動があっても引き継がれる仕組みにしておくとよい。
範囲は重要度の高いシステムから絞り込む
すべてのシステムを一度に訓練対象にする必要はない。まずは、止まったときに事業への影響が最も大きいシステム、たとえば受発注システムや会計システム、顧客データベースなど、一つか二つに絞って始める。範囲を絞ることで、担当者の負担を抑えながら、確実に実施できる体制を作れる。
誰が担当するかを明文化する
復旧訓練は、バックアップを取得している担当者本人だけでなく、可能であれば別のメンバーにも実施してもらうことが望ましい。手順書だけを渡し、担当者以外の人間が復元できるかどうかを確認することで、属人化のリスクを同時に洗い出せる。社内に人員が限られている場合は、外部の情報システム支援会社やITベンダーに依頼して、第三者の視点で復元作業を実施してもらうという方法も有効だ。
訓練環境は本番と切り離す
復旧訓練は、本番環境に影響を与えない別のサーバーやクラウド上の仮想環境で行う。使い終わった後に破棄できるテスト用の環境を用意しておけば、コストを抑えながら安全に実施できる。近年はクラウドサービスを使えば、必要な時間だけ仮想サーバーを借りて訓練し、終わったら削除するという運用が現実的なコストで可能になっている。
結果を記録し、次回に活かす
訓練で見つかった問題点は、必ず記録に残し、手順書やバックアップ設定の見直しに反映する。復元にかかった時間、途中でつまずいた箇所、手順書の不備。これらを蓄積していくことで、訓練を重ねるたびに復旧手順は磨かれていく。一度きりの訓練で終わらせず、PDCAとして回し続けることが、真に機能するバックアップ体制を作る。
よくある失敗パターン
復旧訓練を始めようとした企業が陥りやすい失敗もいくつか存在する。あらかじめ知っておくことで、無駄な回り道を避けられる。
- 訓練を「本番環境の一部」で実施してしまい、誤って本番データに影響を与えてしまう。訓練は必ず隔離された環境で行う。
- 一度訓練を実施しただけで満足し、その後数年間放置してしまう。システム構成やデータ量は常に変化するため、定期的な実施が不可欠である。
- 訓練の実施自体が目的化し、結果として見つかった問題点を是正しないまま終わってしまう。訓練は「問題を見つけて直す」ところまでがワンセットである。
- 復元にかかる時間だけを測定し、データの整合性の確認を省略してしまう。動いているように見えても、一部のデータが欠落しているケースもあるため、内容の確認まで必ず行う。
- 担当者一人だけで訓練を完結させ、手順書のわかりやすさを検証しないまま終える。第三者が手順書だけを頼りに再現できるかを、必ず確認する。
まとめ
バックアップを毎日欠かさず取得し続けることは、決して簡単な仕事ではない。地味で、目立たず、うまくいって当たり前とされる作業を、日々真面目に積み重ねてきた担当者は多いはずだ。しかしその努力が、いざという瞬間に報われるかどうかは、復元を実際に試したことがあるかどうかにかかっている。取得の成功と復元の成功は、まったく別の物語だ。
復旧訓練は、平時の穏やかな時間の中で、緊張感のない状態でこそ実施できる備えである。年に一度、あるいは半年に一度、重要なシステムから範囲を絞り、担当者以外の人間も含めて実際に復元を試す。その積み重ねが、本番障害という壁に直面したときに、これまで積み上げてきた努力を確かな成果に変えてくれる。バックアップという地道な仕事を続けてきたすべての担当者に、その努力が正しく報われる仕組みを、ぜひ今のうちに整えてほしい。