「危機管理」の具体策

「危機管理」の具体策

ITシステムを預かるシステム管理者にとって、バックアップをとるということは「危機管理」に相当します。つまり、日々システムやデータをバックアップするのは、有事が発生した後のことを念頭に置いているわけです。データを退避しておくことで、有事の際はそのバックアップを使って復旧できます。

バックアップと言えば、まずは磁気テープが思い浮かびます。現在ではテープではなくディスクへのバックアップという手法も取り入れられていますが、磁気テープが備える可搬性（ポータビリティ）の利点を生かして遠隔地に保管する用途で使われるケースもまだまだあります。

方法にもよりますが、一般にバックアップは業務システムに負荷をかけるジョブということもあり、業務運用中のバックアップは避けるのが普通です。こうした理由から、業務が停止している夜間にバックアップ処理を実施するという運用も、旧来からあまり変わっていません。

このように、バックアップを支える仕組み（バックアップ・ソフトや磁気テープなどが備える個々の機能やオプション機能）こそ充実／向上していても、その根本的な側面では大きな変化はなく、運用スタイルもあまり変わることなくきています。

しかし、バックアップの周辺事情は大きく変わりました。いくつかある課題の1つは、「バックアップが終わらない」という問題です。これは、取り扱うデータの量が、現在主流のバックアップ運用の仕組みや考え方が確立されたころとは比べ物にならないほど増えたことです。昨今の調査データの多くは企業が抱えるデータの年間増加率を50～60％としており、バックアップ・ジョブの時間も増え続けていることが否めません。

また、2006年の米国での調べ（参考文献）では、Fortune 1000にリストアップされる企業では「ITスタッフの約20％がバックアップ／リカバリ運用に従事しており、バックアップの失敗の調査のために2名のスタッフが張り付く」という調査結果が出ています。日本の実態は残念ながらつかめていませんが、総じてバックアップには手間がかかっている模様です。

危機管理を支える具体策としてバックアップ／リカバリを解説してきましたが、バックアップを実施する仕組みが旧来通りのままであることを前提条件にしてしまうと、「危機管理」を支えるには課題がありそうです。

「危機管理」はリカバリ要件から

危機管理における本質はバックアップを実施することではなく、リカバリ（復旧）ができて初めてその意義を評価されます。リカバリの評価指標には「RPO （復旧時点目標）」と「RTO（復旧時間目標）」があります。これがリカバリ要件です。RPOは「いつの時点のシステム、データが復旧できればいいのか」、RTOは「いつまでにシステム、データが復旧できればいいのか」を示し、いずれも時間軸で評価されます。

「新しいこと」（RPO）と「短いこと」（RTO）を目標に設定する以上、バックアップそのものは確実にできていることが前提です。RPOやRTOは、経営的な判断（投資効果を考慮）とのすり合わせで決めますが、この一方で現在採用しているバックアップ／リカバリ手法にも左右されます。危機管理の側面では、現場のシステム運用担当者から経営上層部への提案材料になるので、バックアップ／リカバリ手法の概要をつかんでおきましょう。

図3には、主だったバックアップ／リカバリ手法に対し、リカバリ要件を軸に評価した例を示します。

テープ・バックアップとディスク・バックアップは、従来からあるバックアップのアーキテクチャーを踏襲する技術です。システムの2重化は、リスク管理の側面で考慮される技術であり、まさに止めてはならない分野のシステムに適用されます。

これら2つの技術については言うまでもないので、次回からは、この2つの技術とは異なる「CDP」（継続的データ保護）に注目し、危機管理とBCPを支える技術としての可能性について考えてみます。

【参考文献】
「Backup Redesign is Top Storage Initiative with 25 percent of Fortune 1000, Says TheInfoPro」（アクセス、2009.12）