(57)【要約】【課題】バックアップデータのサイズ削減と高速化を実現し、リストア時に不要な書き込みが膨れ上がり、仮想ボリュームのサイズ以上の物理ディスク容量が必要となる問題を解決する。【解決手段】バックアップ・リストア対象となる仮想ボリュームをマウントしたバックアップサーバにおいて、仮想ボリュームのデータマッピング情報を元に、ファイルシステムからデバイスへのＩ／Ｏをフィルタリングするデバイスドライバで、データ領域部分のブロックのみ読み込み・書き込み処理を行うことにより、不要な部分の読み込み・書き込み処理を回避することで、バックアップデータサイズの削減と高速化、およびリストア時の仮想ボリュームに対する不要な書き込みの膨れ上がりを防止する。【選択図】図２
2010086474.tif 000002
【特許請求の範囲】
【請求項１】
複数のディスク装置に分散配置された部分記憶領域の集まりを単一の論理ボリュームとして構成して管理するストレージシステムに接続され、前記論理ボリュームのバックアップ処理及びリストア処理を実行する情報バックアップ／リストア処理装置であって、
前記論理ボリューム内の有意データのブロックアドレスを含むデータ構成情報を取得する論理ボリューム構成情報取得手段と、
前記ブロックアドレスに対応する前記有意データを記憶手段にバックアップするバックアップ手段と、
前記バックアップ手段が前記論理ボリュームにアクセスする際にその読み込み及び書き込み処理をフックし、前記データ構成情報に基づいて、前記ブロックアドレスに対応する有意データを前記論理ボリュームから読み込み、読み込んだ前記有意データを前記バックアップ手段に受け渡すボリューム制御手段と、
を備えることを特徴とする情報バックアップ／リストア処理装置。
【請求項２】
前記論理ボリューム構成情報取得手段は、マウントされたファイルシステムに対して前記論理ボリュームのファイルフォーマットを問い合わせることにより、前記データ構成情報を取得することを特徴とする請求項１に記載の情報バックアップ／リストア処理装置。
【請求項３】
前記論理ボリューム構成情報取得手段は、前記ストレージシステムが有する論理ボリュームマッピング情報格納部から前記データ構成情報を取得することを特徴とする請求項１に記載の情報バックアップ／リストア処理装置。
【請求項４】
前記ボリューム制御手段は、前記有意データが割り当てられたブロック以外のブロックにはＮＵＬＬ値を補完し、前記有意データと前記ＮＵＬＬ値によって構成されるバックアップイメージを前記バックアップ手段に受け渡すことを特徴とする請求項１に記載の情報バックアップ／リストア装置。
【請求項５】
リストア処理時には、前記バックアップ手段が前記記憶手段から前記有意データを含むバックアップデータを取得し、
前記ボリューム制御手段が、ＮＵＬＬ値で初期化された新規論理ボリュームに対して、前記有意データのみを対応するブロックに書き込み、
前記有意データが書き込まれた新規論理ボリュームは、ストレージシステム内で正規ボリュームに切り替えられることを特徴とする請求項１に記載の情報バックアップ／リストア装置。
【請求項６】
複数のディスク装置に分散配置された部分記憶領域の集まりを単一の論理ボリュームとして構成して管理するストレージシステムと、
前記ストレージシステムに接続され、前記論理ボリュームのバックアップ処理及びリストア処理を実行するバックアップサーバと、を備える情報バックアップ／リストア処理システムであって、
前記ストレージシステムは、前記論理ボリュームに対応する第１の仮想ボリュームを有し、バックアップ処理時に前記第１の仮想ボリュームの複製である副ボリュームを作成し、
前記バックアップサーバは、
前記副ボリューム内の有意データのブロックアドレスを含むデータ構成情報を取得するボリューム構成情報取得手段と、
前記ブロックアドレスに対応する前記有意データを記憶手段にバックアップするバックアップ手段と、
前記バックアップ手段が前記副ボリュームにアクセスする際にその読み込み及び書き込み処理をフックし、前記データ構成情報に基づいて、前記ブロックアドレスに対応する有意データを前記副ボリュームから読み込み、読み込んだ前記有意データを前記バックアップ手段に受け渡すボリューム制御手段と、
を備えることを特徴とする情報バックアップ／リストア処理システム。
【請求項７】
前記ボリューム構成情報取得手段は、マウントされたファイルシステムに対して前記副ボリュームのファイルフォーマットを問い合わせることにより、前記データ構成情報を取得することを特徴とする請求項６に記載の情報バックアップ／リストア処理システム。
【請求項８】
前記ボリューム構成情報取得手段は、前記ストレージシステムが有する論理ボリュームマッピング情報格納部から前記データ構成情報を取得することを特徴とする請求項６に記載の情報バックアップ／リストア処理システム。
【請求項９】
前記ボリューム制御手段は、前記有意データが割り当てられたブロック以外のブロックにはＮＵＬＬ値を補完し、前記有意データと前記ＮＵＬＬ値によって構成されるバックアップイメージを前記バックアップ手段に受け渡すことを特徴とする請求項６に記載の情報バックアップ／リストアシステム。
【請求項１０】
リストア処理時に、前記ストレージシステムは、ＮＵＬＬ値で初期化された新規論理ボリュームである第２の仮想ボリュームを作成し、
前記バックアップ手段は、前記記憶手段から前記有意データを含むバックアップデータを取得し、
前記ボリューム制御手段は、前記第２の仮想ボリュームに対して、前記有意データのみを対応するブロックに書き込み、
前記ストレージシステムは、前記有意データが書き込まれた第２の仮想ボリュームを、ストレージシステム内で正規ボリュームに切り替えられることを特徴とする請求項６に記載の情報バックアップ／リストアシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報バックアップ／リストア処理装置、及び情報バックアップ／リストア処理システムに関し、例えば、論理ボリュームをイメージ単位でバックアップ及びリストア処理するための装置及びシステムに関するものである。
【背景技術】
【０００２】
近年、企業内における情報の電子化が進み、企業内を流通する文書ファイル・画像ファイル・動画ファイル等、電子データの量が急激に増加している。データセンタや企業の情報システム部門等、組織・企業内の電子データを保管、管理している組織・部門にとって、このような大規模な電子データの保管用として、大規模ストレージのニーズは非常に大きなものとなってきている。
【０００３】
一般的に、ストレージ製品は高速アクセス可能な物理ディスクを複数搭載・管理しており、大規模な記憶領域を提供する。ストレージの一機能として、この複数の物理ディスクを統合して、論理的に複数のボリューム領域を定義し、ストレージに接続しているホスト機に論理ボリュームを見せる機能として、ストレージ仮想化機能がある。このストレージ仮想化機能を用いると、例えば、物理ディスクの容量としては、トータルで１０ＧＢしかない場合でも、論理的に１００ＧＢの論理ボリュームを割り当て、ホスト機のＯＳに１００ＧＢのボリュームとして認識させることができる。その後、１００ＧＢの論理ボリュームが１０ＧＢ以上のデータを格納する時期になったときに、必要な物理ディスクをストレージに追加することで、ホスト機側では、その追加を全く意識することなく、継続的にサービスを提供できる。ストレージ価格は、物理ディスクの搭載数・容量に関係しているが、このストレージ仮想化機能を利用することで、導入時には将来的に必要な容量に対して少なめのディスク容量にしておき、将来必要になった時点で追加していく方法を取ることで、低コストでストレージを導入することができる。
【０００４】
ストレージのデータ保護として、バックアップ・リストア技術がある。バックアップとは、定期的にストレージ内のデータを、ディスクやテープ等の別の記憶媒体にコピーする処理である。リストアとは、バックアップしたデータをストレージ内に戻す処理である。バックアップの単位として、大きくファイル単位とボリュームイメージ単位の２種類があるが、このストレージ仮想化により構築された論理ボリュームのボリューム単位のバックアップ・リストア処理において、以下の課題がある。
【０００５】
第一に、ボリュームのイメージ単位のバックアップ処理において、バックアップアプリケーションは、ボリュームの先頭セクタから順に最終セクタまでデータ読み込み処理を行うが、実際に割り当てられている物理ディスクの全体容量ではなく、論理的に割り当てられたボリューム全体のデータが読み取られる。従って、本来データとして割り当てられている部分以外の余分な部分のデータ読み取りが発生し、バックアップ時間がかかりすぎてしまう問題がある。
【０００６】
第二に、ボリュームのイメージ単位のリストア処理において、バックアップアプリケーションは、バックアップされたイメージデータを対象となる仮想化された論理ボリュームに書き込み処理を行うが、この書き込みも、ボリュームの先頭セクタから順に最終セクタまで書き込みが発生し、以前には物理ディスクの割り当てられていなかった領域にまで書き込みアクセスが発生し、実質的に割り当てられた論理ボリューム以上の物理ディスクを用意しない限り、リストアできない問題がある。
【０００７】
更に、例えばＷｉｎｄｏｗｓのＮＴＦＳなどのファイルフォーマットでは、一旦作成したファイルを削除した場合、ファイルを管理するテーブルに対する書き換えだけ発生して、実際のファイルデータ内容は、残骸としてディスク上に残ったままとなり、仮想化されたボリュームにおけるファイルの残骸部分のデータに対応する物理ディスク割り当ては開放されない問題がある。従って、仮想化されたボリュームに対するバックアップ・リストア時には、このような無駄なデータのＲＥＡＤ／ＷＲＩＴＥが発生し、非効率となる。
【０００８】
このような問題を解決しようとする技術として、例えば、特許文献１に記載された方法がある。特許文献１では、仮想記憶媒体の実際に記録された記憶領域のみの複製により、中間仮想記憶媒体をストレージ側に作成し、その中間仮想記憶媒体の記録データをバックアップ媒体に保存する。バックアップデータを正しく復元するために、仮想記憶媒体と中間記憶媒体のデータの記録アドレス間対応を示すブロック対応表を作成して、中間記憶媒体に保存しており、このブロック対応表利用することで、データを元の仮想記憶媒体に復元することを可能にしている。
【０００９】
【特許文献１】特開２００５−１８２３３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、特許文献１に示された方式は、ストレージシステムに依存し、ストレージ内で閉じた方式である。そのため、ホスト機搭載ＯＳに依存したファイルフォーマットに応じたディスクの利用領域特定ができておらず、例えば前述のＮＴＦＳにおけるファイル削除後の残骸データ領域についても、バックアップ・リストア対象となってしまうため、効率的ではない。また、復元（リストア）時にストレージ側でバックアップフォーマットを認識して、リストアしなければならず、他のストレージにリストアすることができない問題がある。リストアの目的がデータの破壊に対する復元だけでなく、災害時にストレージ自身が物理的に壊れてしまうことによるデータ保護対策であることを勘案すると、異機種のストレージにリストア可能でなければならない。
【００１１】
本発明はこのような状況に鑑みてなされたものであり、ストレージシステムの構成に依存せずに仮想ボリュームのイメージデータを効率よくバックアップ及びリストアすることができる装置及びシステムを提供するものである。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明では、ホスト機側でバックアップ対象となる仮想化されたボリュームへのＩ／Ｏをフィルタリングするデバイスドライバを構成し、マウントされたファイルシステムと連携して、ファイルとして使用されているセクタ領域部分のみＲＥＡＤ／ＷＲＩＴＥさせるように処理することにより、仮想化ボリュームに対してバックアップに必要な部分のみのＲＥＡＤ／ＷＲＩＴＥを実現し、効率的なバックアップ・リストアの仕組みを提供する。また、バックアップ時の仮想化ボリュームのデータ構造を全く変えず、ストレージに特化した特殊なバックアップフォーマットにもしない方式であるために、異機種のストレージに対する復元も可能にする。
【００１３】
別の態様として、本発明では、ホスト機側でバックアップ対象となる仮想化されたボリュームへのＩ／Ｏをフィルタリングするデバイスドライバを構成する点に加え、ストレージ内部で保持している物理ディスク群と仮想化ボリュームの間のブロックのマッピング情報を取得して、仮想化ボリューム内部のブロックのうち、実際に物理ディスクに割当てられている部分についてＲＥＡＤ／ＷＲＩＴＥを実現し、効率的なバックアップ・リストアの仕組みを提供する。本方式では、物理ディスク群と仮想化ボリューム間のブロックのマッピング情報が取得できるようなインタフェースがストレージ側に必要だが、そのようなインタフェースが存在するストレージ間であれば、異機種間のバックアップデータの復元が可能となる。
【００１４】
即ち、本発明は、複数のディスク装置に分散配置された部分記憶領域の集まりを単一の論理ボリュームとして構成して管理するストレージシステムに接続され、論理ボリュームのバックアップ処理及びリストア処理を実行する情報バックアップ／リストア処理装置であり、論理ボリューム内の有意データのブロックアドレスを含むデータ構成情報を取得する論理ボリューム構成情報取得手段と、ブロックアドレスに対応する有意データを記憶手段にバックアップするバックアップ手段と、バックアップ手段が論理ボリュームにアクセスする際にその読み込み及び書き込み処理をフックし、データ構成情報に基づいて、ブロックアドレスに対応する有意データを論理ボリュームから読み込み、読み込んだ有意データをバックアップ手段に受け渡すボリューム制御手段と、を備えている。
【００１５】
論理ボリューム構成情報取得手段は、マウントされたファイルシステムに対して論理ボリュームのファイルフォーマットを問い合わせることにより、データ構成情報を取得する。或いは、論理ボリューム構成情報取得手段は、ストレージシステムが有する論理ボリュームマッピング情報格納部からデータ構成情報を取得する。
【００１６】
ボリューム制御手段は、有意データが割り当てられたブロック以外のブロックにはＮＵＬＬ値を補完し、有意データとＮＵＬＬ値によって構成されるバックアップイメージをバックアップ手段に受け渡す。
【００１７】
また、リストア処理時には、バックアップ手段が記憶手段から有意データを含むバックアップデータを取得し、ボリューム制御手段が、ＮＵＬＬ値で初期化された新規論理ボリュームに対して、有意データのみを対応するブロックに書き込む。そして、有意データが書き込まれた新規論理ボリュームは、ストレージシステム内で正規ボリュームに切り替えられる。
【発明の効果】
【００１８】
本発明によれば、ストレージシステムの構成に依存せずに仮想ボリュームのイメージデータを効率よくバックアップ及びリストアすることができるようになる。
【発明を実施するための最良の形態】
【００１９】
本発明は、ストレージの仮想化機能において、ボリュームのイメージバックアップ、リストアにおけるボリュームへの読み込み、書き込みデータを低減し、仮想ボリュームのバックアップ・リストアの効率化を図る方式に関するものである。
【００２０】
以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
【００２１】
１）第１の実施形態
＜イメージバックアップ／リストアシステムの構成＞
図１は、本発明の第１の実施形態によるイメージバックアップ／リストアシステムの概略構成を示す図である。本実施形態では、一般的な副ボリュームを利用したバックアップ方法について説明する。
【００２２】
イメージバックアップ／リストアシステム１００は、利用者端末１０１と、ホストコンピュータ（以下、ホストと称す）１０３と、バックアップサーバ１０４と、テープ装置１０５と、ストレージシステム１０７と、を含み、利用者端末１０１とホスト１０３及びバックアップサーバ１０４とはＬＡＮ１０２によって接続され、ホスト１０３及びバックアップサーバ１０４とストレージシステム１０７とはＳＡＮ（Storage Area Network）によって接続されている。なお、論理ボリュームのイメージバックアップ及びリストア処理の中心的構成は、バックアップサーバ１０４及びストレージシステム１０７である。
【００２３】
ホスト１０３は、利用者端末１０１にサービスを提供するサーバ機である。バックアップサーバ１０４は、ストレージシステム１０７内部のデータをテープ装置１０５にバックアップするためのサーバ機である。
【００２４】
ストレージシステム１０７は、複数の物理ディスク１１０からなるディスクプール１１１と、メインで使用される仮想ボリューム１０８と、仮想ボリューム１０８の複製である副ボリューム１０９と、によって構成されている。副ボリューム１０９の作成方法として、単純なボリューム全体の複製と、スナップショットと呼ばれる、ある時点からの差分書き込みのみ随時キャッシュしておき、書き込みのあった部分の参照の場合はキャッシュ、書き込みのない部分の参照の場合はオリジナルのボリュームを参照する仕組みにすることで、論理的に複製ボリュームを作成する方式の２通りがあるが、本実施形態ではその方式は特に限定されるものではない。
【００２５】
通常、利用者は利用者端末１０１からホスト１０３経由で、ホスト１０３内にマウントされた仮想ボリューム１０８にアクセスして、仮想ボリューム１０８上のデータを利用し、仮想ボリューム１０８上にデータを保存する。バックアップ時には、ホスト１０３上で仮想ボリューム１０８にアクセスしているサービスをすべて停止し、副ボリューム１０９を作成後、サービスを再開する。作成した副ボリューム１０９にバックアップサーバ１０４からアクセスし、副ボリューム１０９内のデータをテープ装置１０５にコピーする。
【００２６】
＜バックアップサーバの内部構成＞
図２は、バックアップサーバ１０４の内部構成を示す図である。バックアップサーバ１０４には、既存のバックアップアプリケーション２０５の他に、ボリューム管理サービス２０６、ボリューム制御ドライバ２０８がインストールされている。
【００２７】
バックアップアプリケーション２０５は、副ボリューム１０９にアクセスしてバックアップすべきデータを吸い上げる機能を有している。副ボリューム１０９にアクセスするのは、バックアップしている間にシステムを停止しなくても良いからである。前述のように、副ボリューム１０９は、仮想ボリューム１０８の複製なので、同様に仮想ボリュームと同じ属性を有している。従って、バックアップ中に仮想ボリューム１０８を使用できなくてもよいようなシステム構成の場合には、わざわざ副ボリューム１０９のデータをバックアップしなくても良い。
【００２８】
ボリューム制御ドライバ２０８は、バックアップサーバ１０４上で稼動するＯＳが提供するファイルシステム２０７と副ボリューム２１０との間に位置するフィルタドライバであり、ファイルシステム２０７から副ボリューム２１０への読み込み・書き込み処理をフックして、独自処理を追加する機能を持つ。例えば、Ｗｉｎｄｏｗｓ（登録商標）の場合は、ボリュームクラスドライバの上位フィルタドライバとして実現可能であり、Ｕｎｉｘ系ＯＳの場合は、副ボリュームをマウントしてデバイスファイルとして見せるためのデバイスドライバとして実現可能である。
【００２９】
ボリューム管理サービス２０６は、副ボリューム２１０がマウントされた際に、ファイルシステム２０７に問い合わせて、副ボリューム２１０上のデータ構成（バックアップが必要なデータ（有意データ）のみのアドレス情報）を取得するプロセスを実行する手段である。また、ボリューム管理サービス２０６は、取得したデータ構成情報をボリューム制御ドライバ２０８に通知して、そこで副ボリューム２１０への読み込み・書き込み処理の制御が行われる。ここで、副ボリューム２１０上のデータ構成とは、保存されているファイル群が占めているデータブロックが、副ボリューム２１０上のどのブロックなのかを示す構成情報であり、ビットマップ情報とも呼ばれる。
【００３０】
ボリューム制御ドライバ２０８は、ボリューム管理サービス２０６から通知されたデータ構成情報に基づいて、副ボリューム１０９に含まれるイメージのうち有効なデータ部分（有意データ）だけを取得し、削除データ対応ブロック（いわゆる残骸データ）及び未書込ブロック（図３参照）についてはＮＵＬＬ値にしてバックアップアプリケーション２０５に読み込んだデータ及び補充したＮＵＬＬ値を受け渡す。
【００３１】
＜バックアップイメージの構成例＞
図３は、仮想ボリューム上のデータ配置状況と対応するバックアップイメージの例を示す図である。図３にあるように、仮想ボリューム３０１は、未書込ブロック３０２とデータ割当ブロック３０３、及び削除データ対応ブロック３０４で構成される。
【００３２】
ファイルシステムのビットマップ情報は、データ割当ブロック３０３が実際に、ボリューム上のどのブロックなのかを管理する情報であり、本質的にバックアップが必要な部分はデータ割当ブロック３０３である。
【００３３】
従って、従来のイメージバックアップ方式では、データ割当ブロック３０３だけでなく、削除データ対応ブロック３０４の部分もバックアップ対象となってしまっていたが、本発明の方式により、バックアップ対象のイメージは、図３にあるようにデータ割当ブロック３０３のみとなる。具体的には、バックアップ時に仮想ボリューム３０１への読み込み処理があった場合、データ割当ブロック３０３の構成情報を元に、ボリューム制御ドライバにて、データ割当ブロック３０３のみ読み取り、削除データ対応ブロック３０４については、未書込ブロック３０２と同じＮＵＬＬ値を返す処理を行うことで実現する。リストア時には、データ割当ブロック３０３の部分しか戻らないが、ホスト上のファイルシステムにとって、本質的にはデータ割当ブロック３０３の部分しか意味をなさないため、正しく復元することができる。
【００３４】
＜バックアップ処理のシーケンス＞
図４は、バックアップ時の処理を説明するためのフローチャートである。仮想ボリュームをバックアップする場合、まず、ストレージシステム１０７は、仮想ボリュームにアクセスしているホスト上のサービスを止めて、書き込みデータをフラッシュし、仮想ボリュームのデータ整合性を確保した後、仮想ボリュームの複製である副ボリューム１０９を作成する（ステップＳ４０１）。
【００３５】
次に、ストレージシステム１０７は、ステップＳ４０１で作成した副ボリューム１０９をバックアップサーバ１０４にマウントして、バックアップサーバ１０４に副ボリューム１０９を認識させる（ステップＳ４０２）。また、副ボリューム１０９のマウント時には、ボリューム管理サービス２０６が、副ボリューム１０９のデータ構成をチェックする（ステップＳ４０３）。具体的には、副ボリューム１０９がマウントされたときにファイルシステム２０７に問い合わせ、ファイルデータとして割当てられているブロックがどこなのかを示すビットマップ情報（データ構成）を問い合わせる。例えばＮＴＦＳの場合、＄Ｂｉｔｍａｐファイルと呼ばれるメタ情報格納ファイルにビットマップ情報が格納されている。
【００３６】
そして、ボリューム管理サービス２０６は、取得したデータ構成情報をボリューム制御ドライバに通知する（ステップＳ４０４）。
【００３７】
続いて、バックアップアプリケーション２０５がイメージバックアップ処理を開始し、副ボリューム１０９からデータの読み込み処理を実行すると（ステップＳ４０５）、ボリューム制御ドライバ２０８は、ボリューム管理サービス２０６から通知されたビットマップ情報を参照し、ファイルデータに割当てられたブロックに対する読み込みのみ実行する（ステップＳ４０６）。ボリューム制御ドライバ２０８は、割当てられたブロック部分の読み込みデータは、そのままファイルシステム２０７経由でバックアップアプリケーション２０５に渡し、未割当ブロックの読み込み要求については、ＮＵＬＬデータのブロックを作成し、ファイルシステム経由でバックアップアプリケーション２０５に返す（ステップＳ４０７）。
【００３８】
最後に、バックアップアプリケーション２０５は、読み込んだイメージデータを圧縮してテープに保存する（ステップＳ４０８）。ここで、圧縮アルゴリズムは特に規定しないが、バックアップアプリケーションやテープ装置が保持している圧縮機能を利用するものとする。
【００３９】
＜リストア処理のシーケンス＞
図５は、リストア時の処理を説明するためのフローチャートである。仮想ボリューム１０８にバックアップしたイメージをリストアする場合、まず、リストア開始の命令に従って、ストレージシステム１０７は、その内部にリストア先となる仮想ボリュームを新規作成してマウントする（ステップＳ５０１）。ここで、この新規作成された仮想ボリュームは、ＮＵＬＬ値で初期化されたものとして構築される。つまり、仮想ボリュームの全データはＮＵＬＬ値となっている。イメージとしてリストアしたいものと全く同じものを構成するには、新規なボリュームは全てＮＵＬＬ値でないとならないからである。
【００４０】
次に、バックアップアプリケーション２０５は、テープ装置１０５から新規作成した仮想ボリュームに、バックアップデータをコピーする（ステップＳ５０２）。このコピー処理時にボリューム制御ドライバ２０８が仮想ボリュームへの書き込みをフックし（ステップＳ５０３）、ＮＵＬＬ値でないブロックのみを仮想ボリュームに書き込む（ステップＳ５０４）。
【００４１】
最後に、ストレージシステム１０７は、正規ボリュームであるその時点での仮想ボリュームにアクセスしているホスト上のサービスを停止して、復元（リストア）を完了した仮想ボリュームを正規ボリュームに切り替える（ステップＳ５０５）。
【００４２】
２）第２の実施形態
＜イメージバックアップ／リストアシステムの構成＞
イメージバックアップ／リストアシステムの構成は図１（第１の実施形態）とほぼ同様であるが、相違点としては、ストレージシステム内部に保持された、仮想ボリューム１０８と物理ディスク１１０の各ブロックの対応情報を格納した仮想ボリュームマッピング情報（図１には図示されていないが、第１の実施形態の構成にも存在している）を、バックアップサーバ側のアプリケーションに提供するための仕組みとして用いる点である。具体的には、例えばストレージシステム１０７の仮想ボリューム１０８の特定領域に仮想ボリュームマッピング情報を保管し、バックアップサーバ内のアプリケーションが、その記録された特定領域を読み込むことで、仮想ボリュームマッピング情報を取得する方式が実現可能である。
【００４３】
＜バックアップサーバの内部構成＞
図６は、本発明の第２の実施形態によるバックアップサーバ６０１の構成図である。バックアップサーバ６０１には、既存のバックアップアプリケーション２０５の他に、ボリューム管理サービス６０２、ボリューム制御ドライバ２０８がインストールされている。
【００４４】
ボリューム制御ドライバ２０８は、バックアップサーバ６０１上で稼動するＯＳが提供するファイルシステム２０７と、副ボリューム６１０との間に位置するフィルタドライバである。また、ボリューム制御ドライバ２０８は、ファイルシステム６０７から副ボリューム６１０への読み込み・書き込み処理をフックして、独自処理を追加する機能を持っている。
【００４５】
ボリューム管理サービス６０２は、副ボリューム１０９がマウントされた際に、ストレージシステム１０７に問い合わせて、仮想ボリュームマッピング情報（データ構成情報）６０３を取得するプロセスを実行する。そして、ボリューム管理サービス６０２は、取得したデータ構成情報をボリューム制御ドライバ２０８に通知する。上述した第１の実施形態では、ボリューム管理サービス２０６がファイルシステム２０７に問い合わせてデータ構成情報を取得したが、第２の実施形態では、ボリューム管理サービス６０２が仮想ボリュームマッピング情報６０３を参照してデータ構成情報を取得する。このように仮想ボリュームマッピング情報６０３を参照することによって、ファイルシステムの構成に依存せずにデータ構成情報を取得することができるが、その一方で第１の実施形態とは異なり、ＯＳからは認識できない消去済みの残骸データがデータ構成として残ってしまう可能性はある。残骸データは、ＯＳから見た場合には意味がないと認識されても、ストレージシステムでは一旦書き込まれると有効とされてしまうからである。
【００４６】
ボリューム制御ドライバ２０８は、そのデータ構成情報を基にして、副ボリューム１０９に対する読み込み・書き込み処理の制御を行う。
【００４７】
＜仮想ボリュームマッピング情報＞
図７は、仮想ボリュームマッピング情報を示したテーブルの例を示す図である。本テーブルは、仮想ボリュームブロック番号７０１、物理ディスク識別番号７０２、物理ディスクブロック番号７０３の３つの属性で構成される。例えば、テーブルの第２行にあるように、仮想ボリュームブロック番号７０１の値が１０１、物理ディスク識別番号７０２の値が４、物理ディスクブロック番号７０３の値が２１１９の場合、仮想ボリュームのブロック番号１０１のブロックは、物理ディスクプール内の複数台の物理ディスクのうち、識別番号が４の物理ディスクの２１１９ブロックと対応していることを示している。
【００４８】
このテーブルにより、ストレージシステムは、仮想ボリューム１０８の該当ブロックに対する読み込み・書き込み処理を、対応する物理ディスク１１０上のブロックアドレスに変換して読み込み・書き込み処理を行う。仮想ボリューム１０８上で実際に物理ディスクブロックを割当てられているブロック番号は、仮想ボリュームマッピング情報テーブル６０３の、仮想ボリュームブロック番号属性７０１にあるすべての値となる。
【００４９】
＜バックアップ処理＞
図８は、本発明の第２の実施形態におけるバックアップ時の処理を説明するためのフローチャートである。仮想ボリュームをバックアップする場合、まず、ストレージシステム１０７は、仮想ボリュームにアクセスしているホスト上のサービスを止めて、書き込みデータをフラッシュし、仮想ボリュームのデータ整合性を確保した後、仮想ボリュームの複製である副ボリューム１０９を作成する。そして、ストレージシステム１０７は、作成した副ボリューム１０９をバックアップサーバ６０１にマウントして、バックアップサーバ６０１に副ボリューム１０９を認識させる（ステップＳ８０１）。
【００５０】
次に、ボリューム管理サービス６０２が、ストレージシステム１０７から仮想ボリュームマッピング情報６０３を取得する（ステップＳ８０２）。また、ボリューム管理サービス６０２は、取得した仮想ボリュームマッピング情報を、ボリューム制御ドライバ２０８に通知する（ステップＳ８０３）。
【００５１】
その後、バックアップアプリケーション２０５が副ボリューム１０９からデータの読み込み処理を実行すると（ステップＳ８０４）、ボリューム制御ドライバ２０８は、仮想ボリュームマッピング情報（データ構成情報）を基に、仮想ボリューム１０８のブロックの内、物理ディスク１１０に割当てられたブロックのみを副ボリューム１０９から読み込みを行う（ステップＳ８０５）。未割当ブロックの読み込み要求に対しては、ボリューム制御ドライバ２０８はＮＵＬＬデータを補完して、ファイルシステム２０７経由でバックアップアプリケーション２０５に返す（ステップＳ８０６）。
【００５２】
最後に、バックアップアプリケーション２０５は、読み込んだバックアップイメージデータを圧縮してテープ装置１０５に保存する（ステップＳ８０７）。ここで、圧縮アルゴリズムは特に規定しないが、バックアップアプリケーション２０５やテープ装置１０５が保持している圧縮機能を利用するものとする。
【００５３】
なお、リストア処理については、本発明の第１の実施形態におけるリストア処理（図５参照）と同じであるので、説明を省略する。
【００５４】
３）まとめ
以上の構成を採ることにより、既存のバックアップアプリケーションを活かしつつ、仮想ボリュームのバックアップ・リストアの高速化とデータの圧縮、及びリストア時に書き込みデータが膨れ上がる問題を回避する。
【００５５】
また、異機種のストレージへのリストアでは、バックアップイメージデータ自身はオリジナルボリュームと全く遜色無いデータであり、ストレージサイズが一致すれば、上書きしたボリュームは、バックアップ元の正規ボリュームと同等のデータ構成を持つことになる。つまり、バックアップデータのフォーマットはストレージに依存しないため、異機種のストレージへのリストアが可能となる。
【００５６】
本発明では、仮想ボリュームに対する読み込み・書き込みを監視するドライバを構築し、オンデマンドに必要なブロック部分だけを読み込み・書き込み実行し、ストレージに対する読み込み、書き込みコマンドを最小限にすることにより、バックアップの高速化やバックアップデータ削減、及びリストア時の仮想ボリュームへの不必要な書き込みの膨張を防ぐことができる。
【００５７】
なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【００５８】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【００５９】
また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【図面の簡単な説明】
【００６０】
【図１】本発明による情報バックアップ／リストア処理システムの概略構成を示す図である。
【図２】第１の実施形態によるバックアップサーバの内部構成を示す図である。
【図３】仮想ボリューム上のデータ配置状況と対応するバックアップイメージ例を示す図である。
【図４】第１の実施形態によるバックアップ時の処理を説明するためのフローチャートである。
【図５】リストア時の処理を説明するためのフローチャートである。
【図６】本発明の第２の実施形態によるバックアップサーバの内部構成を示す図である。
【図７】仮想ボリュームマッピング情報を示したテーブル例を示す図である。
【図８】第２の実施形態によるバックアップ時の処理を説明するためのフローチャートである。
【符号の説明】
【００６１】
１０１…利用者端末
１０２…ＬＡＮ
１０３…ホスト
１０４、６０１…バックアップサーバ
１０５…テープ装置
１０６…ＳＡＮ
１０７…ストレージシステム
１０８…仮想ボリューム
１０９…副ボリューム
１１０…物理ディスク
１１１…ディスクプール
２０５…バックアップアプリケーション
２０６、６０２…ボリューム管理サービス
２０７…ファイルシステム
２０８…ボリューム制御ドライバ
３０２…未書込ブロック
３０３…データ割当ブロック
３０４…削除データ対応ブロック
３０５…バックアップイメージ
６０３…仮想ボリュームマッピング情報
７０１…仮想ボリュームブロック番号
７０２…物理ディスク識別番号
７０３…物理ディスクブロック番号
【図１】
2010086474.tif 000003
【図２】
2010086474.tif 000004
【図３】
2010086474.tif 000005
【図４】
2010086474.tif 000006
【図５】
2010086474.tif 000007
【図６】
2010086474.tif 000008
【図７】
2010086474.tif 000009
【図８】
2010086474.tif 000010