“ 万が一 ” という非常事態は、実際にやって来るのだ。 連載第1回では、戸籍の滅失に見舞われた4市町の実例を紹介した。別の場所に保管されていた戸籍の副本で一定の回復には至ったものの、直近の届けなどを中心に、住民は婚姻届や出生届けなどの重要書類を再度提出しなくてはならなかった。今回詳しく紹介するのは、「ベアメタル復旧」でカルテを回復したA病院の事例である。
カルテデータが流された病院は、なぜ診療をただちに再開できたのか
東北地方太平洋沿岸のA病院では、津波によってカルテデータを格納する医療情報システムが流されてしまった。だがこの病院は、同じ経営グループに所属する日本海側のB病院へシステムおよびデータのまるごとバックアップを行っており、OS、アプリケーションを1つずつリストアする手間をかけることなく、すばやくシステムを復旧することができた。ここでのシステム構成を具体的に示すと、次のようになる。
まずメインサイトで稼働する本番サーバに対してサイト内でイメージバックアップを持つ。これは主にサーバ障害や世代管理、データの長期保管を意図したものである。たとえば、Windowsプラットフォームであれば、Windows Storage Serverを搭載したNAS(Network Area Storage)に、CA ARCserve D2Dというディスクベースのシステム保護ソリューションでバックアップを行っておく。
しかし、バックアップデータごと被災してしまっては意味がない。そこで、メインサイトに何かあった場合の対策として、このCA ARCserve D2Dで取得したバックアップデータを災害時稼働サイトのNASへ向けてレプリケーションしておく。これには、CA ARCserve D2Dと連携活用可能なCA ARCserve Replicationという製品を用いることができる。 こうすれば、いざ災害が発生してメインサイトがダウンした際にも、災害時稼働サイトにサーバを構築し、レプリケーションしておいたバックアップデータを使ってベアメタル復旧を行えば、今までと同様にシステムを利用できるようになる。
ここでいうベアメタル復旧だが、ベアメタルリストアやベアメタルリカバリと呼ばれることもある。ベアメタルというのは“裸の金属”という意味の英語で、IT用語ではハードディスクがまっさらで何も書き込まれていない状態のことを指している。その状態からシステムを元の状態に戻すことをベアメタル復旧というのだ。文字どおり完全復旧で、OSから、アプリケーション、各種システム上の設定、個人設定、システムに格納されたデータまで、そっくりそのまま再現することができる。
そして、まずは業務を再開する。サイトこそ遠隔地に移ったが、システムは以前の状態と同じであるため、いつもと同じように業務を遂行することができる。戸籍データの事例のように業務に支障をきたすような空白期間を生じさせないという意味で、これは非常に重要なことである。ましてやこの事例のように、システムが医療情報の提供を担っているなら、このような大災害でさらに重要性が増すだけになおさらだ。
メインサイトの復旧は、ひと段落して、余裕が生まれてきたところで取りかかる。こちらもイメージバックアップがNASに取ってあるから、災害時稼動サイトからNASを輸送するなどして運び、サーバを新たに立て直してベアメタル復旧を行えばいい。
次回お送りするのは、自動車関連メーカーC社だ。同社は計画停電の実施が再度発表されても対応できるよう、大阪支店に複製サーバを持ち、東京支店のサーバデータをレプリケーションして保管することにした。 その詳細と具体的な採用ソリューションを、今回紹介したA病院の場合とあわせ紹介する。
