データ消失で事業継続が困難になる恐れも

効率的な企業経営を実現するためには、コンピュータを利用したシステムの活用は不可欠であり、今やそれがなければ業務が成り立たない状態にあると言っても過言ではありません。例えば、本社の基幹システム、工場の生産システム、人事総務部の給与計算システム、経理部の会計システム、財務部のインターネットバンキング・システムなど様々なシステムが、相互に連携しながらデータの入出力・加工・保存を行っており、各部署の業務はそういったシステムに大きく依存しています。また、生産システムのように他社のシステムとも連携を図る場合もあります。

もし、地震などの災害や人為的なミスなどにより、システムが動かなくなったり、あるいは、システムに蓄積された顧客データ、注文データ、製造量データ、会計データ等のデータがなくなったりしてしまうと、全社的に業務に混乱が生じてしまうばかりか、事業継続そのものが困難になる恐れもあります。設計図、研究開発の記録、顧客情報等のデータの消失は、会社のノウハウの消失を意味します。製品の製造が滞れば、納期遅延により取引先に多大な迷惑をかけてしまうことになり、場合によってはSCM（サプライ・チェーン・マネジメント）全体に影響が連鎖することになります。

また、システムを業務に組み込む中で、各種帳票類のペーパーレス化が進んだ結果、データ消失時の被害が拡大する傾向にあります。データの消失により各種帳票類が利用できなくなってしまうと、そういった帳票類を利用して行われていたディスクロージャーや納税等の業務が滞ってしまい、コンプライアンスの観点から問題が生じることになるからです。例えば、上場会社が自社の会計データを消失してしまい、その復旧に時間がかかり決算確定や会計監査が遅延した結果、有価証券報告書を法定期限（＊）の経過後１か月以内に財務（支）局に提出できなければ、上場廃止になってしまいます。

また、決算確定が滞ると税額を確定することができず、納税に支障が生じることになります。納税に関しては、納税に関連する帳簿書類の保存に係る負担の軽減を図るために、電子帳簿保存法が整備されており、納税者が帳簿書類を電磁的記録により保存することが容認されています。適用を受けるには、あらかじめ税務署長等の承認を受け、かつ、適正公平な課税の確保に必要な一定の要件に従った形で、電磁的記録等の保存等を行うことが条件とされています。その要件にバックアップ・データの保存は求められていません。しかし、電磁的記録は、記録の大量消失につながる危険性が高く、経年変化等による記録状態の劣化等が生じる恐れもあることからすれば、保存期間中の可視性の確保という観点から、バックアップ・データを保存することが望まれます。

電磁的記録　：　情報（データ）それ自体あるいは記録に用いられる媒体のことではなく、一定の媒体上にて使用し得る（一定の順序によって読みだすことができる）情報が記録・保存された状態にあるものをいう。具体的には、情報がフロッピーディスク、コンパクトディスク、DVD、磁気テープ等に記録・保存された状態にあるものをいう。

以前、大手レンタルサーバー会社のサーバーのデータが従業員の過失により上書きされ、同社のサービスを利用していた企業のウェブサイトやメールなどのデータが消失したうえ、復旧もできなくなるという事件が発生したのは記憶に新しいところです。このとき被害にあった企業の明暗を分けたのが、手元にバックアップ・データを持っていたか否かでした。株主をはじめとするステークホルダーに対しゴーイングコンサーンが求められる上場企業としては、データの消失に備え、データ（場合によってはシステムそのもの）のバックアップを図っておくことは最低限の義務と言えるでしょう。

ゴーイングコンサーン　：　企業が継続して存続すること。

ただ、一口に「バックアップ」と言っても、どのデータを、どこに、どれくらいの頻度で、どれくらいの期間に渡り保存するのかなど、検討しなければならないことはたくさんあります。また、データが大きくなればなるほど、そのバックアップに要する費用負担も重くなりますので、コストの検討も欠かせません。

以下、バックアップを実施する際に検討すべき事項について解説します。

BCPに欠かせないデータのバックアップ

まず、データのバックアップを検討する際に併せて策定しておきたいのがBCP（事業継続計画＝Business Continuity Planning）です。BCPとは、自然災害やテロなど、突発的な緊急事態の発生により事業活動が中断した場合でも、目標復旧時間（RTO：Recovery Time Objective）内に重要な機能を再開させるとともに、業務中断に伴うリスクを最小低限に抑えるために、平時から事業継続について戦略的に準備しておくことです（BCPの詳細は「工場が被災した」を参照してください。また、RTOについては、後述の「バックアップの頻度はRTOとコスト次第」を参照してください）。上述のように、重要なデータについていかに確実にバックアップを取り、万が一の際に問題なくリストアー（復元）をすることができ、迅速にリカバリー（復旧）できるかが、BCP策定時の重要課題となります。

リストアー　：　バックアップした時点の状態に戻すこと

リカバリー　：　リストアーしたデータに追加入力等何らかの処理を行い、システムに障害が起きる直前の状況まで戻すこと。バックアップした時点に戻すことで復旧が終わるのであれば、リストアーとリカバリーは同義となる。

このようにデータのバックアップがBCPの一環として策定されることは、バックアップが迷走（＊）しないためにも必要なことです。いかなるデータをどのようにバックアップするのかといった計画案に、BCPの視点で検討を加えることにより、芯の通ったぶれない計画になります。その計画に基づき構築されたデータのバックアップ体制は、万が一の事態への“備え”としての役目を適切に果たすことになります。いわば、BCPとデータのバックアップは密接に相互依存する関係にあると言えます。

データによっては「バックアップしない」という経営判断も

それでは 、どういったデータをバックアップすればよいのでしょうか。

すべてのデータについてバックアップを取ることは不可能ではありませんが、それにはかなりの時間を要するだけでなく、金額的にも相当の負担を強いられることになります。そこで、バックアップすべきデータの峻別が必要になります。具体的には、各データに、「なくてはならないデータ」「なくても業務に重大な支障をきたすわけではないが、あった方がベターなデータ」「不要なデータ」といったようなプライオリティをつけて、バックアップの対象を選定することになります。コストが予算を超えるようであれば、「なくても業務に重大な支障をきたすわけではないが、あった方がベターなデータ」のバックアップは見送るか、バックアップの頻度を減らすといった経営判断もあり得るでしょう（バックアップの頻度については「バックアップの頻度はRTOとコスト次第」を参照してください）。リカバリー可能性という観点からは、紙に出力済みかどうかも重要な判断要素になります。

具体例を挙げると、「なくてはならないデータ」としては、例えば上述した設計図、研究開発の記録、顧客情報、生産データ、会計データ等といったビジネスの根幹となる情報が該当します。「なくても業務に重大な支障をきたすわけではないが、あった方がベターなデータ」としては、社内外とやり取りされたメールのデータ（＊）、「不要なデータ」としては社員向けニュース記事のデータや紙に出力済みの注文データなどが考えられます。

＊　電子帳簿保存法の要件を満たしたうえで電磁的記録によりデータを保存している会社は、電子取引を行った場合、その電子取引に係る取引情報の電磁的記録を保存する必要があります。

電子取引　：　取引情報の受け渡しをメールなどの電磁的方式により行う取引

取引情報　：　取引に関して受領し、又は交付する注文書、契約書、送り状、領収書、見積書その他これらに準ずる書類に通常記載される事項

システムのバックアップは必要か？

バックアップというと、一般的には「データのバックアップ」を想定しがちですが、システム（ソフト）に不作動や一部の機能停止といった不具合が生じてしまったときに備えて、システム自体のバックアップも検討する必要があります。以下、市販のソフトと自社開発のソフトに分けて考えてみます。

市販のソフトというと、例えばMicrosoft社のWindowsなどのOS（オペレーティング・システム）やワープロソフト、表計算ソフト、メールソフト、文書管理ソフト、勤怠管理ソフト、会計ソフトといった様々なソフトがありますが、それらは、端末にソフトをインストールした際のCD-ROM等を使うことで容易にリカバリー（ソフトを復旧すること）することができます。そのため市販のソフトは、それ自体のバックアップは不要です。

一方、自社開発のソフトの場合、システムをリカバリーするためのバックアップ・プログラムが必要になります。そして、自社開発のソフトの開発時や更新時に、開発用の端末に保存されているプログラムのデータを丸ごとバックアップすることになります。

なお、ASPのようにブラウザー上で動くシステムであれば、システム自体のバックアップはASPのサービス提供業者が行うことから、利用者は特段の作業をする必要ありません。

ASP　：　“Application Service Provider”の略で、ネットワーク経由でグループウェアや給与計算、会計等のアプリケーション（ソフト）のサービスを提供する業者

ブラウザー　：　ウェブのページをPCの画面で表示するためのアプリケーション（ソフト）。Microsoft社のInternet Explorer、Google社の Chrome、Mozillaの Firefoxなどがある。

どんな方法でバックアップする？

バックアップの対象となるデータやシステムが決まったら、次にバックアップの方法を検討します。

各社員のPCにある作成途中の提案書、企画書、資料、精算書などのファイルや過去の作成データについては、PCのハードディスク（場合によってはサーバー）にバックアップ用のフォルダを作り、そこに必要に応じてバックアップ用のデータを各社員の自己責任で保存するケースがよく見受けられます。バックアップの際、圧縮用のソフトを用いて、ファイルサイズを圧縮するケースも少なくありません。一方、USBメモリのような盗難・紛失のリスクが高い媒体にバックアップ用のデータを保存することは、情報流出のリスクがあることから、社内規程やシステム対応（＊）で規制すべきです。

圧縮用のソフト　：　データサイズを小さくするためのアプリケーション。自己解凍機能のオプションやパスワードの設定が可能。

＊　PCにUSBメモリへのデータ・コピーを制限するソフトをインストールすることが考えられます。ハードディスク中のデータの暗号化やデータへのアクセス制限と組み合わせることで、より安全な態勢となります。

社内のシステムに入力・生成・保存されるデータは、上記のような各社員が作成したファイルのデータと異なり、システム部等が主体となり、市販のバックアップ・ツールや、社内のシステムに組み込まれたバックアップ機能を利用して、データのバックアップを取ることになります。その際、自動バックアップ（＊）を利用するのが通常ですが、自動バックアップを利用できない場合は、バックアップ・データの取得に人手が必要となります。ただ、そうなると、バックアップ自体を失念したり、バックアップ対象を間違えたりといった人的ミスが生じやすいという問題があることから、マニュアル化が必須となります。

＊　「土曜・日曜を除く日の午前０時に○○のフォルダの○○というデータのバックアップを取り、●●というファイル名で●●のフォルダに保存しておく」といった具合に、定期的にバックアップを実行するスケジュールをシステム上設定することで、バックアップの作業を自動化すること。

また、RAIDという方法を採用している企業もあります。RAIDとは、システムの稼働に伴うデータの書き込みを複数のハードディスクに対して行い、１台のハードディスクが故障してもデータが別のハードディスクに残る仕組みのことです。システム部門の担当者から「RAID1でミラーリングしています」といった会話を聞いたことがあるのではないでしょうか。RAIDは過去の一定時点のデータを保つ仕組みではないので、バックアップとは異なります。バックアップと比べると、ハードディスクの故障という事態に備える（＊）とともに、最新のデータが保存されているといったメリットがありますが、通常のバックアップのようにハードディスク同士を離れた場所に保管することが難しく、自然災害への対応としては弱いとされています。また、バックアップと異なり、システム稼働中に人的ミスでデータを削除してしまった場合に、複数のハードディスクにおいて同時に削除が行われることから、リカバリーすることができません。

RAID　：　“Redundant Arrays of Inexpensive Disks”の略でレイドと読む。RAID 0からRAID 6まで７つのレベルがある。RAID 1は複数のハードディスクに、同時に同じ内容を書き込む技術であり、ミラーリングと言われる。

ミラーリング　：　２台以上のディスクに同時にデータを書き込むこと

＊　複数台のディスクが同時に故障する可能性は限りなく低いため。

こういったデメリットを解決するために、RAID対応のNASにデータを保管し、それをバックアップすることで、RAIDとバックアップ双方のメリットが享受でき、より手厚く万が一の事態に備えることが可能になります。

NAS　：　“Network Attached Storage”の略で、ネットワークに直接接続されているファイルサーバーを指す。

一方、データセンターを利用している場合、そのデータセンターの責任で、冗長化が図られることになります。データセンターにデータを預けている側としては、バックアップ（オプションの場合があります）したデータの保存期間やデータ復旧までの時間といったことを定めたSLAを確認すべきです。

冗長化　：　同じものを複数用意し稼働させておくことで、万が一の事態に備えること

SLA　：　“Service Level Agreement”の略で、サービスの提供者と利用者の間で交わされる「サービスの水準」に関する合意を指す。

また、上述したASPのデータがサービス提供業者のクラウドサーバーに保存される場合、会社はサーバーを管理しようがありませんので、そのバックアップはサービス提供業者の責任により行われることになります。IT担当取締役としては、ASPの入力担当者やその上長にASP業者の信頼性やバックアップ体制の確認を指示することが必要になります。

クラウドサーバー　：　クラウド上（「雲」という意味で、インターネットでつながれたコンピュータのネットワークを指す）に置かれたサーバー。インターネットを経由してアクセスすることになる。

どこにバックアップ・データを保管する？

次に、バックアップしたデータをどこに保存するかを決めなければなりません。

バックアップの容易さという観点からは、手動またはバックアップ・ツールを用いて作成したバックアップ・データを、オリジナルのデータが保存されているPCやサーバーのハードディスクに保存する方法が容易です。しかし、その方法では、オリジナル・データが保管されているPCやサーバーが雷・火災・水害等により物理的被害を受けたり、コンピュータ・ウィルスの侵入を許してしまったりした場合に、オリジナル・データとともにバックアップ・データまで損失するリスクがあります。

バックアップ・ツール　：　バックアップを実行することを目的として導入するソフト

そこで、バックアップ・データはオリジナル・データとは別のストレージに保存して、そのストレージはオリジナル・データが保存されているサーバーから離れた場所で保管しておく方法や、遠隔地のサーバーにデータを転送して保存する方法などを検討する必要があります。

ストレージ　：　データを永続的に保存するための装置。ハードディスクやサーバーが代表例。

サーバー以外の保存先として考えられるストレージには、扱いが容易なハードディスクやDVD、USBメモリ、容量あたりの単価が安いテープ（DAT、LTO）といったメディア、あるいは最近普及が進んでいるクラウドサーバーがあります。それぞれのストレージの長所、短所を踏まえたうえで、データの保存先を決定することになります。

DAT　：　“Digital Audio Tape”の略。磁気テープ方式の記録媒体の一種

LTO　：　“Linear Tape-Open”の略。磁気テープ方式の記録媒体の一種

具体的には、各社員が作成した提案書、企画書、資料、精算書などのように容量が小さくて機密性も低く、頻繁にアクセスする可能性があるデータはハードディスクやDVDなどに、システムやデータベースなど容量が大きくなるものはテープに、メールのデータはクラウドサーバー上に保存するなど、データの性質によって保存先を変更することで、より運用しやすく、かつコストを抑えることができます。ただし、上述のとおり、USBメモリはデータが漏えいするリスクが高いため、避けるべきです。

また、ストレージを、PCやサーバーに近接した場所（建物、地域）で保管することは避けるべきです。火災や地震などの予期しない災害が発生した場合、PCやサーバーとともにバックアップ・データが被災してしまうリスクがあります。実際、東日本大震災の際に岩手、宮城両県の４市町村では戸籍データ（正本）が消失し、管轄の法務局に残っていた副本をもとに手作業でデータを再入力したものの、完全に復元することはできませんでした。こうした事例を鑑みると、ストレージを保管する場所は一か所に集中させず、分散させるべきです。保管場所を複数確保することが難しい場合には、データセンターの活用も検討する必要があるでしょう。

バックアップの頻度はRTOとコスト次第

バックアップされたデータは、データが更新された瞬間から陳腐化が始まります。つまり、バックアップは「定期的に」「繰り返し」行われてこそ、実効性があると言えます。

では、具体的にどれぐらいの頻度でバックアップを実施すべきでしょうか。

バックアップには時間的、金銭的コストを伴いますので、コストを抑制する観点から、重要度に応じて、データやシステムの種類ごとにリアルタイム、１日に１回、週に１回、月に１回、四半期に１回など適切な頻度を設定し、それに従ってバックアップを行っていくことになります。バックアップを取る頻度は、目標復旧時間（RTO：Recovery Time Objective）の視点に基づき決定します。RTOとは、業務を復旧するために目標とする時間のことです。RTOが１日ということになれば、１日前のバックアップが取れていれば十分ということになります。一方、大量のデータをやり取りする金融機関の口座取引データのRTOは秒単位になります。RTOをどれほどの時間に設定すべきかについては、データの性質や会社の考え方に応じて変わってくるため、一律に述べることはできません。例えば、仮にデータを消失しても、過去のどの時点のデータがあれば、業務の大幅な停滞を招かない程度の時間で人力によりリカバリーすることが可能であるかという視点から検討を行うことが考えられます。仮に購買の注文データが消失し、そのリカバリーのためには、購買の担当者が紙に出力しておいた注文書（控）をもとに、購買システムに手入力する必要があるとします。そのリカバリーのための作業時間は、消失したデータの量に比例します。もし業務の大幅な停滞を招かない程度の時間でデータをリカバリーすることができる量が１日分であれば、１日に１度のバックアップの実施が適切ですし、それが５日分であれば１週間に１度のバックアップの実施で十分という判断になります。

ただし、バックアップの頻度を増やせば、データの保存媒体や保管場所の確保により多くのコストがかかることになりますし、システムによっては、バックアップ処理中にデータが書き換えられることによりデータが不整合となることを防ぐためオンラインの停止を伴ったり、CPUに負荷がかかってレスポンスが遅くなったりといった具合に業務やシステムに対して負担をかけることもあります。そういった負担を回避するため、フルバックアップ（＊１）だけでなく、差分バックアップ（＊２）や増分バックアップ（＊３）を組み合わせる方法が考えられます。例えば、会計データであれば毎月の月次決算処理後のデータと過去１週間分（ウィークデーは差分バックアップ、週末にフルバックアップ）といった方法の組み合わせがよく見かけられます。

＊１　すべてのデータをバックアップ取り直すこと。それだけでリストアーが可能ですが、バックアップを取るのに時間がかかることが欠点です。
＊２　前回フルバックアップを取った時からの変更分だけバックアップを取ること。フルバックアップより短い時間で済みますが、日数を経過するごとにバックアップの量が増えることになります。たとえば日曜日にフルバックアップを取り、ウィークデーは差分バックアップを取る場合、月曜日の差分バックアップは１日分のバックアップで済みますが、金曜日の差分バックアップは５日分のバックアップが必要になります。リストアーするためにはフルバックアップのデータも不可欠となります。
＊３　前回フルバックアップや増分バックアップを取った時からの変更分だけバックアップを取ること。たとえば日曜日にフルバックアップを取り、それ以降は増分バックアップを取る場合、月曜日から土曜日はその日の分のバックアップで済みます。リストアーするためにはフルバックアップのデータと、各曜日の増分バックアップのデータすべてが必要になります。

バックアップは何世代保管すべきか

また、何世代のバックアップを保管するべきかという点も検討しなければなりません。これは、どれくらい過去に遡及してデータを復元する必要があるかといった業務上の要望に応じて検討すべきテーマと言えます。最新のデータさえリストアーできれば十分ということであれば１世代分で十分の様に思えるかも知れませんが、バックアップ・データに不具合が生じている可能性もあることから数世代分を保管するケースが良く見かけられます。保存する世代が多いほど安心と言えますが、その分記憶領域もかさむことになり、コスト増となります。

なお、古いバックアップ・データに新しいデータを上書きしない設定にしていると、ハードディスク等の記憶領域をすべて使い果たしてしまい、容量不足により最新のバックアップ・データが取得できていないという事態が発生することになりかねません。そこで、このような設定をしている場合には、古いデータは定期的に削除するなどのオペレーションを検討する必要があります。なお、こうしたオペレーションを自動で行えるのか、手作業で行う必要があるのかは企業やシステムによってまちまちとなっています。

どうやってリカバリーする？

社内のシステムに入力・生成・保存されるデータのバックアップを実施した場合、バックアップ・データのリストアーとリカバリーの手順についても明確に定めてマニュアル化しておく必要があります。

いくらバックアップ・データを取っても、これをリストアーして、通常のデータ（あるいはシステム）にリカバリーするための操作手順が分からないというのでは、これまで検討してきたバックアップの作業やコストが無駄になってしまいます。また、リストアーの過程でバックアップ・データを誤って消去してしまい、リストアーできなくなってしまうという事故も考えられます。データのリストアーやリカバリーはイレギュラーな作業であり、担当者がこれに従事する機会は少ないことから、“習熟しにくい作業”と言えます。そのため、いざリカバリーが必要な事態になった場合、ミスを犯してしまう可能性が高いと言えます。こうした事態を避けるため、まずリカバリーの操作手順の確立とその文書化が必須となります。その際、定期的にリストアーおよびリカバリーのテストを実施し、手順を検証することができればベストですが、テスト環境が用意できない場合、手順が陳腐化していないかという観点から机上レビューを定期的に行うことが必要です。

なお、OSやソフトの更新によって、データのリカバリー方法が変更される可能性もあるので注意してください。

また、初めてバックアップを行った際や、例えばシステム構成を変更したといった理由でバックアップ手続を変更した場合には、適切にバックアップが取れているか、そして、バックアップしたデータが問題なくリストアーできているかを確かめておかなければなりません。バックアップの目的は、データをリカバリーできてはじめて達成されます。せっかくバックアップを実施しても、リカバリーできなければまったく意味がありません。そこで、上述したリカバリーのための段取りの確認が不可欠となります。

バックアップとJ-SOX

「財務報告に係る内部統制の評価及び監査に関する実施基準」では、バックアップについて、次のように言及されています。

監査人は、財務報告に係るシステムの運用・管理の有効性を確認する。その際、例えば、以下の点に留意する。 ・システムを構成する重要なデータやソフトウェアについて、障害や故障等によるデータ消失等に備え、その内容を保存し、迅速な復旧を図るための対策が取られていること

J-SOX対応においても、財務報告に係るデータが消失した場合に復旧できないリスクを識別・評価し、そういったリスクを軽減するような内部統制を整備し、それを運用していくことが必要とされます。

IT担当取締役としては、「BCPに欠かせないデータのバックアップ」でも上述したようにBCPとも整合をとりながら、コストを抑制しつつ、万が一の事態に備えるための仕組みを作り、それが陳腐化していないか定期的に見直しを図ることが望まれます。