JP5966466B2 - バックアップ制御方法、および情報処理装置 - Google Patents

Description

本発明はデータをバックアップする技術に関する。

近年は様々な仮想化技術が研究されている。ある種の仮想化技術によれば、物理的な資源を複数のプラットフォーム間で共有することも可能である。
例えば、複数のコンピューティングプラットフォームで資源を共有するための、次のような方法が提案されている。当該方法は、共有ディスク記憶をサポートする目的で使用することができる。

当該方法によれば、各プラットフォームに設けられたファームウェアは、ＯＳ（Operating System）の実行時に利用可能なようにロードされる。共有資源は、プラットフォームで動作するＯＳに対し、ローカル資源として示される。実際には、共有資源は通常、他のプラットフォームによりホストされる。

オペレーティング資源アクセス要求は、要求するプラットフォームにより受信され、資源アクセス要求にサービスを提供するために用いられるターゲット資源を実際にホストする他のプラットフォームへと送られる。グローバル資源マップは、適切なホストプラットフォームを決定する目的で用いられる。

プラットフォーム間の通信は、ＯＯＢ（Out-Of-Band）通信チャネルまたはネットワークを介して、可能になる。ＯＯＢチャネルを介したデータのルート変更を実現するために、隠し実行モードが実行される。それによって、当該方法は、プラットフォームで動作するＯＳに対し、トランスペアレントに実行される。

また、ある種の仮想化技術は、サーバ間の移行（マイグレーション）を容易にする。サーバ間のライブマイグレーションについても様々な研究が行われている。
例えば、仮想サーバ同士が別々のＳＡＮ（Storage Area Network）環境にあるために、仮想サーバ間でストレージ装置のボリュームを共有することができない場合がある。このような場合でも仮想サーバのライブマイグレーションを可能とするために、次のような仮想計算機システムが提案されている。

移行元仮想サーバと移行先仮想サーバのそれぞれは、ボリューム割当て部と、ボリューム情報管理部と、識別部と、仮想ＯＳ移行部を有する。ボリューム割当て部は、管理ＯＳが管理する論理ボリュームと、各仮想ＯＳが管理する論理ボリュームとを割り当てる。ボリューム情報管理部は、論理ボリュームを識別するボリューム識別情報と、それぞれの管理ＯＳが管理する論理ボリュームとを対応づけて管理する。識別部は、ボリューム識別情報に基づいて、移行元仮想サーバと移行先仮想サーバとが同一の論理ボリュームを対象論理ボリュームとして識別することを可能とする。

仮想ＯＳ移行部は、移行元仮想サーバの仮想ＯＳが使用するメモリ領域内のデータを、移行先仮想サーバに移行する。仮想ＯＳ移行部はさらに、移行中に更新されるメモリ領域内の更新データを、移行先仮想サーバに移行する。

以上例示したように、様々な仮想化技術が研究され、提案されている。しかし、仮想化されていない環境用に開発された技術の中には、そのままでは仮想環境で使用することができないものもある。仮想化されていない環境用に開発された技術を、仮想環境でも利用可能とするための研究の余地は、まだ残っている。

特表２００７−５２６５２７号公報 特開２００９−１４００５３号公報

記憶媒体と制御装置を含むストレージシステムは、第１の記憶領域から第２の記憶領域にデータをバックアップするためのバックアップ命令を、何らかのプロトコルにしたがってコンピュータから受け付ける。そして、ストレージシステムは、受け付けたバックアップ命令にしたがって、データをバックアップする。プロトコルによっては、第１と第２の記憶領域を指定する情報として、第１と第２の記憶領域を物理的に識別する情報しか使えないことがある。

一方で、第１の記憶領域を物理的に識別する情報は、常に利用可能だとは限らない。例えば、物理コンピュータ上のある環境内では、第１の記憶領域を物理的に識別する情報ではなく、当該環境内で第１の記憶領域を仮想的に識別する情報が使われるかもしれない。そして、第１の記憶領域のデータを利用するデータ利用プログラムが、そのような環境において実行されるかもしれない。

この場合、バックアップ命令は、上記環境中のデータ利用プログラムのプロセスからではなく、第１と第２の記憶領域を物理的に識別する情報を認識することの可能な他の環境で実行される他のプログラムのプロセスから、発行されてもよい。しかし、データ利用プログラムによる動作と独立して任意にバックアップ命令が発行されると、バックアップ処理の実行中にデータが更新されるおそれがあり、その結果として、データの整合性が保たれないおそれがある。

そこで、データの整合性を保つために、バックアップ命令の発行は、データ利用プログラムにしたがって行われる第１の記憶領域へのアクセスを制約または監視するための処理をともなっていてもよい。

ところが、データ利用プログラムが実行される環境の外部から、上記のような制約または監視を受けるためのインタフェイスは、データ利用プログラムに必ず備わっているとは限らない。つまり、バックアップ命令にしたがったデータのバックアップは、無条件に実行可能（feasible）な訳ではない。データ利用プログラムが実行される環境や、データ利用プログラムのインタフェイスによっては、データの整合性を保ちつつバックアップ命令を利用してデータをバックアップすることができない可能性がある。

本発明は、１つの側面では、所定の命令にしたがったデータのバックアップが実行可能な条件を緩和することを目的とする。

一態様によるバックアップ制御プログラムは、第１のプログラムモジュールと第２のプログラムモジュールとを含む。前記第１のプログラムモジュールは、コンピュータ上の第１の環境で実行される。また、前記コンピュータ上の環境であって、１つ以上の実記憶装置の各々を認識することが可能な第２の環境で、前記第２のプログラムモジュールが実行される。

前記バックアップ制御プログラムが前記コンピュータに実行させる処理は、停止命令を前記第１のプログラムモジュールにしたがって発行することを含む。前記停止命令は、前記第１の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第１の記憶領域を利用する、データ利用プログラムのプロセスに、前記第１の記憶領域に対する更新操作を一時的に停止させるための命令である。

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、第１の仮想識別情報と第２の仮想識別情報を、前記第２のプログラムモジュールのプロセスに対して、前記第１のプログラムモジュールにしたがって通知することを含む。前記第１の仮想識別情報は、前記第１の環境において認識される１つ以上の仮想記憶装置内において前記第１の記憶領域を識別する情報である。前記第２の仮想識別情報は、前記データのバックアップ先である第２の記憶領域を前記１つ以上の仮想記憶装置内において識別する情報である。

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、前記１つ以上の実記憶装置内において前記第１の記憶領域を識別する第１の実識別情報を取得することを含む。前記第１の実識別情報は、前記１つ以上の実記憶装置と前記１つ以上の仮想記憶装置との間の対応関係と、通知された前記第１の仮想識別情報とを用いて、前記第２のプログラムモジュールにしたがって取得される。

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、前記１つ以上の実記憶装置内において前記第２の記憶領域を識別する第２の実識別情報を取得することを含む。前記第２の実識別情報は、前記対応関係と、通知された前記第２の仮想識別情報とを用いて、前記第２のプログラムモジュールにしたがって取得される。

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、バックアップ命令を前記第２のプログラムモジュールにしたがって発行することを含む。前記バックアップ命令は、前記第１の記憶領域から前記第２の記憶領域に前記データをバックアップするための命令である。前記バックアップ命令は、取得した前記第１の実識別情報と取得した前記第２の実識別情報に基づいて発行される。

上記のバックアップ制御プログラムによれば、バックアップ命令のような所定の命令にしたがったデータのバックアップが実行可能な条件が緩和される。

第１実施形態のブロック図である。 第１実施形態におけるバックアップ制御のシーケンス図である。 第１比較例を説明する図である。 第２比較例を説明する図である。 第２実施形態のブロック図である。 システムのハードウェア構成図である。 バックアップ制御処理のフローチャートである。 処理に使われる値の例を示す図である。 仮想パーティションと仮想ディスクと実パーティションと実ディスクの例を説明する図である。 物理領域情報を取得する処理のフローチャートである。 デバイスの領域情報を取得する処理のフローチャートである。 ストレージシステムにデータのコピーを指示する処理のフローチャートである。

以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、図１〜２を参照して第１実施形態についてまず説明する。次に、図３〜４を参照して第１〜第２比較例について説明する。その後、図５〜１２を参照して第２実施形態について説明する。最後に、その他の変形例についても説明する。

図１は、第１実施形態のブロック図である。図１には、コンピュータ１００と、仮想記憶装置１１０と、実記憶装置１２０が図示されている。
図１では仮想記憶装置１１０が１つのブロックで示されているが、仮想記憶装置１１０の数は１でもよいし、２以上でもよい。同様に、図１では実記憶装置１２０が１つのブロックで示されているが、実記憶装置１２０の数は１でもよいし、２以上でもよい。

例えば、各実記憶装置１２０が実ディスクであってもよい。その場合、各仮想記憶装置１１０は仮想ディスクである。
各実記憶装置１２０は、コンピュータ１００にＤＡＳ（Direct Attached Storage）として接続された通常のＨＤＤ（Hard Disk Drive）のディスクであってもよい。あるいは、各実記憶装置１２０は、ＲＡＩＤ（Redundant Array of Independent DisksまたはRedundant Array of Inexpensive Disksの略）システムにおいて、外部からは１台の実ディスクドライブとして認識される、１つの論理ユニットであってもよい。

ＲＡＩＤシステムは、例えばＳＡＮなどのネットワークを介してコンピュータ１００に接続されていてもよい。また、ＲＡＩＤコントローラと複数の磁気ディスク媒体とを含む１つのＲＡＩＤシステムの全体が、1つのシャーシに収められた１つの装置として提供されてもよい。

ＲＡＩＤシステムが使われる場合、ＲＡＩＤレベルは任意である。例えば、ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５、ＲＡＩＤ０＋１、ＲＡＩＤ１＋０、ＲＡＩＤ０＋５、ＲＡＩＤ５＋０などのレベルが利用可能である。

以上例示したような、通常のＨＤＤとＲＡＩＤシステムは、どちらも、記憶媒体（例えば磁気ディスク媒体）だけでなく、制御装置（例えばＨＤＤ内の制御回路またはＲＡＩＤシステムにおけるＲＡＩＤコントローラ）を含む。ＨＤＤやＲＡＩＤシステムは、コンピュータ１００から命令を受け取り、受け取った命令に応じて、制御装置による制御のもとで動作する。

また、コンピュータ１００上には、第１の環境１０１と第２の環境１０２が構築されている。第２の環境１０２においては、１つ以上の実記憶装置１２０の各々を認識することが可能である。具体的には、例えば以下の（１ａ）や（１ｂ）のような場合があり得る。

（１ａ）第１の環境１０１がハイパーバイザ上で動作する第１の仮想マシンであり、第２の環境１０２がハイパーバイザ上で動作する第２の仮想マシンである場合。
（１ｂ）第１の環境１０１が、第２の環境１０２上または第２の環境１０２内に構築された環境である場合。

上記の（１ａ）と（１ｂ）のいずれの場合においても、第１の環境１０１においては、１つ以上の実記憶装置１２０は認識されなくてもよく、代わりに、１つ以上の仮想記憶装置１１０が認識されてもよい。

ところで、１つ以上の仮想記憶装置１１０のいずれかに含まれる記憶領域へのアクセスは、物理的には、いずれかの実記憶装置１２０上に割り当てられている当該記憶領域へのアクセスにより、実現される。

例えば、１つ以上の仮想記憶装置１１０のいずれかに含まれる第１の記憶領域１１１として、物理的には、１つ以上の実記憶装置１２０のいずれかに含まれる第１の記憶領域１２１が使われる。したがって、仮想記憶装置１１０上の第１の記憶領域１１１へのアクセスは、物理的には実記憶装置１２０上の第１の記憶領域１２１へのアクセスによって、実現される。換言すれば、「１１１」と「１２１」という参照符号は、どちらも、物理的には同じ第１の記憶領域を指す。

同様に、１つ以上の仮想記憶装置１１０のいずれかに含まれる第２の記憶領域１１２として、物理的には、１つ以上の実記憶装置１２０のいずれかに含まれる第２の記憶領域１２２が使われる。したがって、仮想記憶装置１１０上の第２の記憶領域１１２へのアクセスは、物理的には実記憶装置１２０上の第２の記憶領域１２２へのアクセスによって、実現される。換言すれば、「１１２」と「１２２」という参照符号は、どちらも、物理的には同じ第２の記憶領域を指す。

例えば（１ａ）の場合に、上記のとおり第１の仮想マシンは、１つ以上の実記憶装置１２０を認識しなくてもよい。この場合、第１の仮想マシンから仮想記憶装置１１０へのアクセスを実現するための実記憶装置１２０へのアクセスは、第２の仮想マシンのデバイスドライバを介して行われてもよい。

（１ａ）の場合、より具体的には、第１の環境１０１は、例えばＸｅｎハイパーバイザ上の「ドメインＵ」であってもよく、第２の環境１０２は、Ｘｅｎハイパーバイザ上の「ドメイン０」であってもよい（Ｘｅｎは登録商標）。仮想記憶装置１１０上の記憶領域へのドメインＵからのアクセスは、物理的には実記憶装置１２０上の記憶領域へのアクセスとして実現される。そして、実記憶装置１２０上の記憶領域へのアクセスは、ドメイン０のデバイスドライバを介して行われる。

もちろん、第１の環境１０１と第２の環境１０２は、Ｘｅｎ以外の他のハイパーバイザ上の仮想マシンであってもよい。ハイパーバイザ上で提供される環境は、「ドメイン」、「論理ドメイン」、「パーティション」など様々な名前で呼ばれる。また、例えば上記の（１ｂ）の場合のように、ハイパーバイザ以外の仮想化技術により、コンピュータ１００内に第１の環境１０１と第２の環境１０２が構築されていてもよい。

また、上記のとおり、（１ｂ）の場合も、１つ以上の仮想記憶装置１１０のいずれかに含まれる記憶領域への第１の環境１０１内からのアクセスは、物理的には、いずれかの実記憶装置１２０上に割り当てられている当該記憶領域へのアクセスにより、実現される。実記憶装置１２０へのアクセスは、上記（１ｂ）の場合には、第２の環境１０２を提供するＯＳを介して行われてもよい。

上記（１ｂ）の場合のより具体的な例として、例えば以下の（２ａ）〜（２ｃ）のような場合があり得る。

（２ａ）第１の環境１０１が、ホストＯＳ上で動作する仮想マシンであり、第２の環境１０２が、ホストＯＳが提供する環境（つまり仮想マシンより下のレイヤの環境）である場合。ホストＯＳ上で仮想マシンを実行する技術として、例えば、ＶＭｗａｒｅ Ｐｌａｙｅｒなどの製品が知られている（ＶＭｗａｒｅは登録商標）。
（２ｂ）第１の環境１０１が、第２の環境１０２内に含まれる実行環境（runtime environment）である場合。例えば、第１の環境１０１がＳｏｌａｒｉｓコンテナの非大域ゾーン（non-global zone）であり、第２の環境１０２がＳｏｌａｒｉｓコンテナの大域ゾーン（global zone）である場合（Ｓｏｌａｒｉｓは登録商標）。
（２ｃ）第２の環境１０２が、ホストＯＳにより提供される環境であり、当該ホストＯＳのカーネルにはＫＶＭ（Kernel-based Virtual Machine）用のモジュールが組み込まれている場合。この場合、第１の環境１０１は、ゲストＯＳが提供する環境である。

もちろん、コンピュータ１００上に第１の環境１０１と第２の環境１０２を構築するための仮想化技術は、上記の仮想化技術の例には限られない。
また、図１では図示の便宜上、第１の環境１０１が第２の環境１０２の左に描かれているが、上記（１ｂ）のとおり、第１の環境１０１は、第２の環境１０２上に構築されていてもよいし、第２の環境１０２内に構築されていてもよい。

さて、第１実施形態のバックアップ制御プログラム１０３は、第１の環境１０１と第２の環境１０２が構築されたコンピュータ１００により実行されるプログラムである。バックアップ制御プログラム１０３は、第１の環境１０１で実行される第１のプログラムモジュール１０４と、第２の環境１０２で実行される第２のプログラムモジュール１０５を含む。換言すれば、第１のプログラムモジュール１０４は、第１の環境１０１で動作する第１の制御プログラムであり、第２のプログラムモジュール１０５は、第２の環境１０２で動作する第２の制御プログラムである。

図１に示すように、第１の環境１０１上では、第１のプログラムモジュール１０４だけでなく、データ利用プログラム１０６も動作する。データ利用プログラム１０６は、例えば、ＤＢＭＳ（Database Management System）のプログラムであってもよい。

データ利用プログラム１０６は、仮想記憶装置１１０内の第１の記憶領域１１１を利用するプログラムである。上記のとおり、第１の記憶領域１１１は物理的には第１の記憶領域１２１であるから、第１の記憶領域１２１内のデータが、データ利用プログラム１０６にしたがってアクセスされることになる。

ここで、第１の記憶領域１１１に記憶されているデータを第２の記憶領域１１２へバックアップすることを、ユーザ（例えば、コンピュータ１００のアドミニストレータ）が望んだとする。

上記のとおり、各実記憶装置１２０は、例えば、ディスクであってもよい。この場合、各仮想記憶装置１１０は仮想ディスクである。
仮想ディスクの数は２以上でもよく、すなわち、少なくとも第１と第２の仮想記憶装置１１０があってもよい。そして、第１の記憶領域１１１は第１の仮想記憶装置１１０上の１つのパーティションであってもよく、第２の記憶領域１１２は第２の仮想記憶装置１１０上の１つのパーティションであってもよい。

第１の仮想記憶装置１１０用に、いずれかの実記憶装置１２０上の１つのパーティションが割り当てられていてもよい。同様に、第２の仮想記憶装置１１０用に、いずれかの実記憶装置１２０上の１つのパーティションが割り当てられていてもよい。

これら２つの実パーティションは、同じ実ディスクに含まれていてもよい。しかし、より安全にデータを保護するためには、これら２つの実パーティションは違う実ディスクにあることが好ましい。

つまり、より安全にデータを保護するためには、第１の記憶領域１１１に対応する第１の記憶領域１２１を含む実ディスクと、第２の記憶領域１１２に対応する第２の記憶領域１２２を含む実ディスクは、異なることが好ましい。なお、第１の記憶領域１２１を含む実ディスクと第２の記憶領域１２２を含む実ディスクは、同じ１台の装置（例えば、１つのシャーシに収容された１つのＲＡＩＤシステム）に含まれていてもよいし、２台の装置に分かれて存在していてもよい。

バックアップ制御プログラム１０３は、第１の記憶領域１１１から第２の記憶領域１１２へのデータのバックアップ（換言すれば第１の記憶領域１２１から第２の記憶領域１２２へのデータのバックアップ）を制御するためのプログラムである。具体的には、コンピュータ１００は、第１のプログラムモジュール１０４と第２のプログラムモジュール１０５にしたがって以下のように動作する。

コンピュータ１００は、第１のプログラムモジュール１０４にしたがって停止命令を発行する。停止命令は、データ利用プログラム１０６のプロセスに、第１の記憶領域１１１（つまりバックアップ対象のデータが記憶されている領域）に対する更新操作を一時的に停止させるための命令である。更新操作は、具体的には、新たなデータを追加する操作、既存のデータを削除する操作、既存のデータを書き換える操作などを含む。

ここで、第１のプログラムモジュール１０４のプロセスと、データ利用プログラム１０６のプロセスは、同じ第１の環境１０１内のプロセス同士である。よって、停止命令の発行と受領は、第１の環境１０１内でのプロセス間通信のためのインタフェイス（例えば、第１の環境１０１内で使われるＡＰＩ（Application Programming Interface）など）を介して行われてもよい。

コンピュータ１００はさらに、第１のプログラムモジュール１０４にしたがって、第２のプログラムモジュール１０５のプロセスに対して、下記（３ａ）と（３ｂ）の情報を通知する。

（３ａ）第１の環境１０１において認識される１つ以上の仮想記憶装置１１０内において、第１の記憶領域１１１を識別する、第１の仮想識別情報。
（３ｂ）第１の環境１０１において認識される１つ以上の仮想記憶装置１１０内において、第２の記憶領域１１２（つまりデータのバックアップ先）を識別する、第２の仮想識別情報。

第１の仮想識別情報は、例えば、第１の記憶領域１１１を含む１つの仮想記憶装置１１０を、１つ以上の仮想記憶装置１１０の中で識別する情報と、当該１つの仮想記憶装置１１０内での第１の記憶領域１１１の位置を表す情報を含んでいてもよい。同様に、第２の仮想識別情報は、第２の記憶領域１１２を含む１つの仮想記憶装置１１０を、１つ以上の仮想記憶装置１１０の中で識別する情報と、当該１つの仮想記憶装置１１０内での第２の記憶領域１１２の位置を表す情報を含んでいてもよい。

仮想記憶装置１１０内での記憶領域の位置を表す情報は、より具体的には、当該記憶領域の開始アドレスを含んでいてもよい。例えば、開始アドレスとサイズの組み合わせ、または、開始アドレスと終了アドレスの組み合わせが、記憶領域の位置を表す情報として使われてもよい。

第１の仮想識別情報と第２の仮想識別情報の通知は、異なる環境間の通知（具体的には、第１の環境１０１内から第２の環境１０２内への通知）である。よって、第１の仮想識別情報と第２の仮想識別情報の通知は、ネットワークプロトコルにしたがって行われてもよい。ネットワークプロトコルとしては、例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）が使われてもよいが、他のプロトコルが使われてもよい。

コンピュータ１００は、続いて、第２のプログラムモジュール１０５にしたがって、下記（４ａ）と（４ｂ）の情報を取得する。

（４ａ）１つ以上の実記憶装置１２０内において、第１の記憶領域１２１（すなわち第１の記憶領域１１１用に割り当てられている領域）を識別する、第１の実識別情報。
（４ｂ）１つ以上の実記憶装置１２０内において、第２の記憶領域１２２（すなわち第２の記憶領域１１２用に割り当てられている領域）を識別する、第２の実識別情報。

具体的には、コンピュータ１００は、１つ以上の実記憶装置１２０と１つ以上の仮想記憶装置１１０との間の対応関係と、通知された（３ａ）の第１の仮想識別情報とを用いて、（４ａ）の第１の実識別情報を取得する。同様に、コンピュータ１００は、１つ以上の実記憶装置１２０と１つ以上の仮想記憶装置１１０との間の対応関係と、通知された（３ｂ）の第２の仮想識別情報とを用いて、（４ｂ）の第２の実識別情報を取得する。

ここで、第２のプログラムモジュール１０５は、１つ以上の実記憶装置１２０を認識することの可能な第２の環境１０２内で実行される。そして、第２の環境１０２内においては、より具体的には、各仮想記憶装置１１０がどの実記憶装置１２０に対応するのかを認識することが可能である。よって、コンピュータ１００は、第２のプログラムモジュール１０５にしたがって、上記対応関係を用いて、（４ａ）と（４ｂ）の情報を取得することができる。

なお、第１の実識別情報は、例えば、第１の記憶領域１２１を含む１つの実記憶装置１２０を、１つ以上の実記憶装置１２０の中で識別する情報と、当該１つの実記憶装置１２０内での第１の記憶領域１２１の位置を表す情報を含んでいてもよい。同様に、第２の実識別情報は、第２の記憶領域１２２を含む１つの実記憶装置１２０を、１つ以上の実記憶装置１２０の中で識別する情報と、当該１つの実記憶装置１２０内での第２の記憶領域１２２の位置を表す情報を含んでいてもよい。

実記憶装置１２０内での記憶領域の位置を表す情報は、より具体的には、当該記憶領域の開始アドレスを含んでいてもよい。例えば、開始アドレスとサイズの組み合わせ、または、開始アドレスと終了アドレスの組み合わせが、記憶領域の位置を表す情報として使われてもよい。

コンピュータ１００は、続いて、第２のプログラムモジュール１０５にしたがって、バックアップ命令を発行する。バックアップ命令は、第１の記憶領域１２１から第２の記憶領域１２２にデータをバックアップするための命令である。

バックアップ命令の形式に応じて、バックアップ命令は、第１の記憶領域１２１を含む装置（例えばＲＡＩＤシステムまたはＨＤＤ）に対して発行されてもよいし、第２の記憶領域１２２を含む装置に対して発行されてもよい。なお、第１の記憶領域１２１と第２の記憶領域１２２が、同じ１つの装置（例えば同じ１つのＲＡＩＤシステムまたは同じ１つのＨＤＤ）に含まれる場合もあり得る。

具体的には、コンピュータ１００は、取得した第１の実識別情報と取得した第２の実識別情報を用いて、バックアップ命令を発行する。例えば、第１の実識別情報と第２の実識別情報そのものまたはその一部（例えば、位置を表す情報）が、バックアップ命令のパラメタとして使われてもよい。第１の実識別情報と第２の実識別情報から得られる他の情報（例えば、実識別情報よりもさらに物理的なレベルにおいて実記憶装置１２０に割り当てられている識別番号など）が、バックアップ命令のパラメタとして使われてもよい。第１の実識別情報と第２の実識別情報は、さらに、バックアップ命令の宛先を決めるために用いられてもよい。

バックアップ命令などの各種の命令は、特定のプロトコル（例えばＳＣＳＩ（Small Computer System Interface）プロトコル）にしたがった形式を持つ。しかし、プロトコルの種類によっては、仮想識別情報がバックアップ命令のパラメタとして使えないことがある。例えば、バックアップ命令が具体的にはＳＣＳＩコマンドである場合、パラメタとしては、実識別情報（または、実識別情報から得られる、より低レベルの情報）が使われる。

仮想識別情報がバックアップ命令のパラメタとして使えない場合にも、上記のバックアップ制御プログラム１０３によれば、データのバックアップが可能である。つまり、コンピュータ１００は、第１の実識別情報と第２の実識別情報を用いることによって、適切なバックアップ命令を発行することができる。

バックアップ命令の発行後、コンピュータ１００は、バックアップ命令に対する応答を、第２のプログラムモジュール１０５にしたがって待ち、応答を受信する。バックアップ命令に対する応答は、具体的には、１つ以上の実記憶装置１２０のうち、第１の記憶領域１２１または第２の記憶領域１２２を有する実記憶装置１２０を制御する制御装置から返される。制御装置の具体例は、ＲＡＩＤシステム内のＲＡＩＤコントローラや、ＨＤＤ内のコントローラなどである。

コンピュータ１００は、受け取った応答の内容を、第２のプログラムモジュール１０５にしたがって、第１のプログラムモジュール１０４のプロセスに対して通知してもよい。例えば、応答は、バックアップのための処理が正常に終了したか否かを示す結果情報を含んでいてもよく、結果情報が第１のプログラムモジュール１０４のプロセスに通知されてもよい。

また、受け取った応答が正常終了を示していれば、コンピュータ１００は、第１のプログラムモジュール１０４にしたがって、停止命令を解除する解除命令を、データ利用プログラム１０６のプロセスに対して発行してもよい。解除命令の受領に応じて、データ利用プログラム１０６のプロセスは、第１の記憶領域１１１に対する更新操作を再開する。

以上説明したように、コンピュータ１００は、第１のプログラムモジュール１０４と第２のプログラムモジュール１０５を含むバックアップ制御プログラム１０３にしたがって動作する。そして、コンピュータ１００がバックアップ制御プログラム１０３にしたがって動作することにより、バックアップ命令にしたがったデータのバックアップが実行可能な条件は緩和される。具体的には、下記（５ａ）〜（５ｃ）の３つの観点から、条件は緩和される。

（５ａ）バックアップ命令のパラメタとして使える情報の種類は何か、という観点。
（５ａ）データ利用プログラム１０６のプロセスが、第１の環境１０１の内部からしか停止命令を受け付けることができないのか、それとも第１の環境１０１の外部からも停止命令を受け付けることができるのか、という観点。
（５ｃ）第１の環境１０１内で、各実記憶装置１２０を認識することができるか否か、という観点。

これら３つの観点からの条件緩和と、その理由についてまとめれば、下記のとおりである。
バックアップ命令のパラメタとして仮想識別情報が使えなくても、バックアップ命令を使ったデータのバックアップが可能である。なぜなら、コンピュータ１００は、第１の実識別情報と第２の実識別情報を取得し、取得した第１の実識別情報と第２の実識別情報に基づいてバックアップ命令のパラメタを決定し、バックアップ命令を発行するからである。

データ利用プログラム１０６のプロセスが、第１の環境１０１内からしか停止命令を受け付けることができなくても、バックアップ命令を使ったデータのバックアップが可能である。なぜなら、第１の環境１０１内で実行される第１のプログラムモジュール１０４にしたがって、停止命令が発行される（すなわち、第１のプログラムモジュール１０４のプロセスから停止命令が発行される）からである。

第１の環境１０１内では各実記憶装置１２０を認識することができなくても、バックアップ命令を使ったデータのバックアップが可能である。なぜなら、バックアップ制御プログラム１０３は、第１の環境１０１内で実行される第１のプログラムモジュール１０４だけでなく、各実記憶装置１２０を認識することが可能な第２の環境１０２内で実行される第２のプログラムモジュール１０５も含むからである。そして、第１のプログラムモジュール１０４のプロセスと第２のプログラムモジュール１０５のプロセスの間で情報が送受信されるからである。

続いて、第１実施形態におけるバックアップ制御の例について、図２のシーケンス図を参照して説明する。
ステップＳ１０１で、第１の記憶領域１１１中のデータを第２の記憶領域１１２にバックアップする処理を開始するきっかけとなる、何らかのイベントが発生する。例えば、ステップＳ１０１では、下記（６ａ）または（６ｂ）のようなイベントが発生する。

（６ａ）予めスケジュールされていた日時になった、というイベント。
（６ｂ）ユーザが、バックアップ処理の開始を命じる入力を、入力装置を介して与えた、というイベント。

すると、ステップＳ１０２でコンピュータ１００は、第１のプログラムモジュール１０４にしたがって、停止命令を発行する。換言すれば、第１のプログラムモジュール１０４のプロセスが停止命令を発行する。上記のとおり、停止命令は、データ利用プログラム１０６のプロセスに、第１の記憶領域１１１に対する更新操作を一時的に停止させるための命令である。

そして、ステップＳ１０３でコンピュータ１００は、データ利用プログラム１０６にしたがって、第１の記憶領域１１１に対する更新操作を一時的に停止するための制御を行う。換言すれば、データ利用プログラム１０６のプロセスが、第１の記憶領域１１１に対する更新操作を一時的に停止するための制御を行う。

例えば、データ利用プログラム１０６が、第１の記憶領域１１１上のデータベース（ＤＢ）を利用するＤＢＭＳプログラムである場合、ステップＳ１０３では、例えば以下の（７ａ）〜（７ｃ）のような処理が行われてもよい。（７ａ）〜（７ｃ）の処理は、データの静止点（quiescent point）を作成するための処理の例である。

（７ａ）実行途中のトランザクションがある場合、実行途中の各トランザクションを、最後まで実行してコミットするか、または、強制的にロールバックする処理。
（７ｂ）第１の記憶領域１１１用のディスクキャッシュとして使われるメモリ上の領域に記憶されているデータを、第１の記憶領域１１１へ書き出す（つまりフラッシュ（flush）する）処理。
（７ｃ）ＤＢＭＳの動作モードを書き込み禁止モードに変更する処理。

なお、書き込み禁止モードは、具体的には、新たな書き込みアクセス要求を受け付けた場合に、要求に応じた書き込みアクセスはしないで、要求の内容をキューに記憶するモードであってもよい。あるいは、書き込み禁止モードは、新たな書き込みアクセス要求を受け付けた場合に、要求に応じた結果を、第１の記憶領域１１１へは書き込まずに、他の記憶領域に書き込むモードであってもよい。例えば、他の記憶領域は、第１の記憶領域１１１用のディスクキャッシュとして使われるメモリ上の領域であってもよいし、第１の記憶領域１１１とは別の、ディスク上の記憶領域であってもよい。

ステップＳ１０３の制御が完了すると、ステップＳ１０４において、データ利用プログラム１０６のプロセスから第１のプログラムモジュール１０４のプロセスへと完了通知が送られる。つまり、コンピュータ１００はデータ利用プログラム１０６にしたがって完了通知を送り、第１のプログラムモジュール１０４にしたがって完了通知を受け取る。

そして、ステップＳ１０５でコンピュータ１００は、第１のプログラムモジュール１０４にしたがって、第２のプログラムモジュール１０５のプロセスに対して、上記（３ａ）の第１の仮想識別情報と上記（３ｂ）の第２の仮想識別情報を通知する。換言すれば、第１のプログラムモジュール１０４のプロセスが、上記（３ａ）と（３ｂ）の情報を、第２のプログラムモジュール１０５のプロセスに通知する。

次のステップＳ１０６では、コンピュータ１００は、第２のプログラムモジュール１０５にしたがって、上記（４ａ）の第１の実識別情報と上記（４ｂ）の第２の実識別情報を取得する。換言すれば、第２のプログラムモジュール１０５のプロセスが、上記（４ａ）と（４ｂ）の情報を取得する。

さらに、ステップＳ１０７でコンピュータ１００は、第２のプログラムモジュール１０５にしたがって、バックアップ命令を発行する。換言すれば、第２のプログラムモジュール１０５のプロセスが、バックアップ命令を発行する。

上記のとおり、バックアップ命令は、第１の記憶領域１２１を含む装置（例えばＲＡＩＤシステムまたはＨＤＤ）に対して発行されてもよい。あるいは、バックアップ命令は、第２の記憶領域１２２を含む装置に対して発行されてもよい。

図２には、バックアップ命令の宛先の装置内の制御装置１２３（具体的には、例えば、ＲＡＩＤシステムにおけるＲＡＩＤコントローラ、あるいは、ＨＤＤにおける制御回路など）が図示されている。制御装置１２３は、受信した命令（例えば、バックアップ命令、リード命令、ライト命令など）に応じた制御を行い、命令に対して応答を返す。

具体的には、ステップＳ１０８では、制御装置１２３は、バックアップ命令にしたがった制御を行う。ステップＳ１０８での制御は、例えば、第１の記憶領域１２１のスナップショットを作成する処理を含んでもよい。

第１の記憶領域１２１が比較的大きい場合、第１の記憶領域１２１全体を第２の記憶領域１２２に実際にバックアップするには、ある程度長い時間がかかる。しかし、スナップショットを作成するのにかかる時間はわずかである。よって、ステップＳ１０８の制御はすぐに完了する。

なお、スナップショットの作成後、制御装置１２３は、第１の記憶領域１２１から第２の記憶領域１２２へ実際にデータをコピーする（つまりバックアップする）ためのバックグラウンド処理を開始する。このバックグラウンド処理は、具体的には、コピーオンライト（Copy-On-Write）にしたがった処理でもよい。

そして、次のステップＳ１０９で制御装置１２３は、第２のプログラムモジュール１０５のプロセスに対して、バックアップ命令に対する応答を返す。
例えば、ステップＳ１０８でスナップショットの作成が成功した場合、ステップＳ１０９での応答は、バックアップ処理の正常終了を表す通知であってもよい。つまり、実際にデータをコピーする処理は、ステップＳ１０９よりも後にバックグラウンドで行われるとしても、制御装置１２３は、コンピュータ１００に対して、あたかも実際のデータのコピーがステップＳ１０８で完了したかのように見せかけてもよい。図２の例では、ステップＳ１０９の応答が、バックアップ処理の正常終了を表すものとする。

すると、ステップＳ１１０でコンピュータ１００は、制御装置１２３から受け取った応答の内容を、第２のプログラムモジュール１０５にしたがって、第１のプログラムモジュール１０４のプロセスに対して通知する。換言すれば、第２のプログラムモジュール１０５のプロセスが、上記応答の内容を第１のプログラムモジュール１０４のプロセスに通知する。

例えば、上記のようにステップＳ１０９の応答が、バックアップ処理の正常終了を表す場合、ステップＳ１１０では、バックアップ処理の正常終了が第１のプログラムモジュール１０４のプロセスに対して通知される。

そして、以上のようにして正常終了が通知された場合、ステップＳ１１１でコンピュータ１００は、第１のプログラムモジュール１０４にしたがって、解除命令をデータ利用プログラム１０６のプロセスに対して発行する。換言すれば、第１のプログラムモジュール１０４のプロセスが解除命令を発行する。なお、上記のとおり、解除命令は、停止命令を解除するための命令である。

すると、ステップＳ１１２でコンピュータ１００は、データ利用プログラム１０６にしたがって、第１の記憶領域１１１に対する更新操作を再開するための制御を行う。換言すれば、ステップＳ１１２での制御は、データ利用プログラム１０６のプロセスにより行われる。

例えば、ステップＳ１０３で上記（７ｃ）のように動作モードを変更する処理が行われた場合、ステップＳ１１２では、ＤＢＭＳの動作モードを通常モードに戻すための処理が行われる。通常モードへの復帰にともなって、例えば以下のような処理がさらに行われてもよい。

書き込み禁止モードは、上記のとおり、実施形態に応じて、キューを使うモードであってもよいし、第１の記憶領域１１１とは別のキャッシュ領域（例えば、ディスクキャッシュとして使われるメモリ上の領域）を使うモードであってもよい。よって、ステップＳ１１２では、もしデータ利用プログラム１０６のキューに１つ以上の書き込みアクセス要求の内容が記憶されていれば、当該１つ以上の書き込みアクセス要求に順々にしたがって、第１の記憶領域１１１への書き込みアクセスが行われてもよい。あるいは、動作モードが書き込み禁止モードに設定されていた間に、上記キャッシュ領域に何らかの書き込みアクセス要求に応じて結果が書き込まれていた場合、当該結果がステップＳ１１２で第１の記憶領域１１１へ書き出されてもよい。

また、ステップＳ１１２以降に、データ利用プログラム１０６のプロセスが新たに別の書き込みアクセス要求を受け付けた場合、当該新たな書き込みアクセス要求に応じた書き込みアクセスも行われる。例えば、以上のようにして、データ利用プログラム１０６のプロセスは、解除命令の受領に応じて、第１の記憶領域１１１に対する更新操作を再開する。

続いて、以上説明した第１実施形態の利点についての理解を助けるため、図３〜４を参照して、第１〜第２比較例について説明する。図３は、第１比較例を説明する図であり、図４は、第２比較例を説明する図である。

図３の第１比較例では、物理サーバ２００上でゲストＯＳ２０１が動作する。物理サーバ２００内では、例えば「管理ＯＳ」または「ホストＯＳ」と呼ばれるような、特定のＯＳがさらに動作している。当該特定のＯＳからは、実ハードウェア（例えば実ディスク）が認識可能である。しかし、図３では、当該特定のＯＳは省略されている。物理サーバ２００内では、不図示の別のゲストＯＳがさらに動作していてもよい。

ゲストＯＳ２０１は、具体的には、物理サーバ２００内の仮想マシン上で動作する。また、ゲストＯＳ２０１上では、バックアップソフトウェア２０２と、バックアップ対象のデータを利用するアプリケーション２０３（例えばＤＢＭＳアプリケーション）が動作する。

また、物理サーバ２００は、ＳＡＮ２１０を介してストレージシステム２２０に接続されている。ストレージシステム２２０は実ディスク２２１と２２２を含む。例えば、ストレージシステム２２０はＲＡＩＤシステムであってもよく、実ディスク２２１と２２２のそれぞれは、物理的にはディスクアレイにより実現されてもよい。

説明の便宜上、アプリケーション２０３が利用するデータ（つまりバックアップ対象のデータ）は、物理的には実ディスク２２１上の記憶領域に記憶されているものとする。また、データのバックアップ先が、実ディスク２２２上の記憶領域であるものとする。

ところで、ある種の仮想化技術によれば、ゲストＯＳ２０１が動作する仮想マシンからも、実ディスクが認識可能である。例えば、Ｈｙｐｅｒ−Ｖの「パススルーディスク」オプションや、ＶＭｗａｒｅの「ＲＤＭ」（Raw Device Mapping）オプションは、仮想マシンが実ディスクを認識して利用することを可能にする技術の例である（Ｈｙｐｅｒ−ＶおよびＶＭｗａｒｅは登録商標）。

第１比較例では、例えば以上のような仮想化技術を用いることにより、ゲストＯＳ２０１が動作する仮想マシンから、実ディスクが認識可能になっているものとする。仮想マシンから実ディスクが認識可能な場合、仮想マシン上で動作するバックアップソフトウェア２０２にしたがったバックアップ処理は、実マシンにおけるバックアップ処理と同じ手順で実行することが可能である。理由は以下の（８ａ）〜（８ｂ）のとおりである。

（８ａ）アプリケーション２０３のプロセスに実ディスク２２１への書き込みアクセスを停止させるための命令（すなわち停止命令）が、定義されていてもよい。アプリケーション２０３のプロセスが停止命令として受け付けることのできる命令は、ゲストＯＳ２０１が動作する仮想マシン内から発せられた命令に限られるかもしれない。しかし、その場合も、第１比較例によれば、アプリケーション２０３のプロセスは、バックアップソフトウェア２０２のプロセスからの停止命令を受け付けることが可能である。なぜなら、バックアップソフトウェア２０２とアプリケーション２０３は、同じゲストＯＳ２０１上で動作するからである。
（８ｂ）ストレージシステム２２０が受け付け可能なバックアップ命令のパラメタとして、仮想ディスクを識別する情報が使えず、実ディスクを識別する情報しか使えないかもしれない。しかし、その場合も、第１比較例では、バックアップソフトウェア２０２のプロセスは、ストレージシステム２２０が受け付け可能なバックアップ命令を発行することができる。なぜなら、ゲストＯＳ２０１が動作する仮想マシンから、実ディスク２２１や２２２が認識可能であり、バックアップソフトウェア２０２はゲストＯＳ２０１上で動作するからである。

具体的には、第１比較例では、以下のようにして実ディスク２２１から実ディスク２２２へのデータのバックアップが行われる。
まず、バックアップソフトウェア２０２のプロセスが、アプリケーション２０３のプロセスに対して停止命令を発行する。例えばバックアップソフトウェア２０２がＤＢＳＭアプリケーションの場合、アプリケーション２０３のプロセスは、停止命令の受領に応じて上記（７ａ）〜（７ｃ）と類似の制御を実行する。その結果、データの静止点が作成される。こうして、アプリケーション２０３が利用する実ディスク２２１上のデータは、停止命令の発行と受領にともなって、バックアップ可能な状態になる。

静止点の作成後、アプリケーション２０３のプロセスは、バックアップソフトウェア２０２のプロセスに対して、静止点の作成が完了したことを通知する。このように、同じゲストＯＳ２０１上で動作するバックアップソフトウェア２０２のプロセスとアプリケーション２０３のプロセスは、互いに連携することができる。

ここで、実ディスク２２１と２２２は、ゲストＯＳ２０１上で動作するバックアップソフトウェア２０２のプロセスから認識可能である。換言すれば、バックアップソフトウェア２０２のプロセスは、実ディスク２２１と２２２上の記憶領域をそれぞれ識別する実識別情報を取得することができる。

よって、アプリケーション２０３のプロセスからの通知にともない、バックアップソフトウェア２０２のプロセスは、ストレージシステム２２０に対してバックアップ命令を発行する。バックアップ命令のパラメタとして、上記のようにして取得された実識別情報（または実識別情報から得られる他の情報）が使われる。また、バックアップ命令は、ＳＡＮ２１０を介してストレージシステム２２０へと送信される。

すると、ストレージシステム２２０は、バックアップ命令にしたがった制御を行う。例えば、ストレージシステム２２０は、図２のステップＳ１０８と同様に、実ディスク２２１上の、バックアップ対象のデータが記憶されている記憶領域のスナップショットを作成する。スナップショットの作成が完了したら、ストレージシステム２２０は、バックアップソフトウェア２０２のプロセスに完了を通知する。完了通知は、ＳＡＮ２１０を介して送信される。また、ストレージシステム２２０は、実ディスク２２１から実ディスク２２２へ実際にデータをコピーする処理を、バックグラウンドで実行する。

他方、ストレージシステム２２０からの完了通知の受信に応じて、バックアップソフトウェア２０２のプロセスは、バックアップ処理の完了をアプリケーション２０３のプロセスに通知する。すると、アプリケーション２０３のプロセスは、図２のステップＳ１１２と同様の制御を行う。その結果、実ディスク２２１への更新操作が再開される。

以上のようにして、第１比較例では実ディスク２２１から実ディスク２２２へのデータのバックアップが行われる。
そして、第１実施形態と第１比較例は「オンラインバックアップが可能である」という点で共通である。オンラインバックアップは、ホットバックアップとも言われ、例えばＤＢＭＳのようなシステムのシャットダウンを伴わずにデータをバックアップする処理のことである。換言すれば、第１実施形態と第１比較例は、「バックアップ対象のデータを利用するプログラムの実行を停止することなく、バックアップ命令に応じたバックアップ処理を行うことが可能である」という点で共通である。

しかしながら、第１比較例では、上記のとおり、ゲストＯＳ２０１が動作する環境から実ディスク２２１と２２２が認識可能でなくてはならない。つまり、第１比較例は、特定の仮想化技術（例えば「パススルーディスク」オプションなど）に依存している。特定の仮想化技術への依存は、「バックアップ命令に応じたバックアップ処理が実行可能な条件が限定されてしまう」ということを意味する。

それに対し、第１実施形態では、第１の環境１０１から実記憶装置１２０が認識可能である必要はない。つまり、第１実施形態には、第１比較例のような、特定の仮想化技術への依存性がない。そのため、第１実施形態では、バックアップ命令を用いたバックアップ処理が実行可能な条件が、第１比較例よりも緩和されている。

そして、以上の比較から分かるように、実システムから仮想システムへの移行を検討するユーザにとって、第１比較例は、バックアップ処理のために仮想ディスクの使用を諦めなくてはならないシステム構成である。他方、第１実施形態は、実記憶装置１２０を仮想化した仮想記憶装置１１０を使用することと、バックアップ命令を用いたオンラインバックアップを行うことが両立可能なシステム構成である。つまり、上記の条件の緩和は、オンラインバックアップの適用範囲の拡大であるとも言えるし、仮想化に関する選択肢の増加であるとも言える。したがって、第１実施形態は、第１比較例と比べて優れている。

次に、図４を参照して、第２比較例について説明する。図４の第２比較例では、第１比較例とは異なり、バックアップ対象のデータを利用するアプリケーションが動作する仮想マシンからは、実ディスクが認識されない。

具体的には、第２比較例では、物理サーバ３００上で管理ＯＳ３０１とゲストＯＳ３０２が動作する。そして、管理ＯＳ３０１上ではバックアップソフトウェア３０３が動作する。一方、バックアップ対象のデータを利用するアプリケーション３０４（例えばＤＢＭＳアプリケーション）は、ゲストＯＳ３０２上で動作する。

物理サーバ３００は、ＳＡＮ３１０を介してストレージシステム３２０に接続されている。ストレージシステム３２０は実ディスク３２１と３２２を含む。例えば、ストレージシステム３２０はＲＡＩＤシステムであってもよく、実ディスク３２１と３２２のそれぞれは、物理的にはディスクアレイにより実現されてもよい。

説明の便宜上、アプリケーション３０４が利用するデータ（つまりバックアップ対象のデータ）は、物理的には実ディスク３２１上の記憶領域に記憶されているものとする。また、データのバックアップ先が、実ディスク３２２上の記憶領域であるものとする。

ところで、第２比較例において、ゲストＯＳ３０２の動作する仮想マシンからは、実ディスク３２１上の領域に割り当てられた仮想ディスク３２３や、実ディスク３２２上の領域に割り当てられた仮想ディスク３２４が認識可能である。しかし、ゲストＯＳ３０２の動作する仮想マシンからは、実ディスク３２１や３２２自体は認識されない。

他方、第２比較例では、ストレージシステム３２０が受け付け可能なバックアップ命令のパラメタとして、仮想ディスクを識別する情報が使えず、実ディスクを識別する情報しか使えない。また、バックアップソフトウェア３０３は、ストレージシステム３２０に対してバックアップ命令を発行することを含む処理を、物理サーバ３００のＣＰＵ（Central Processing Unit）に実行させるプログラムである。よって、第２比較例のバックアップソフトウェア３０３は、管理ＯＳ３０１上で動作するようにインストールされる。

このようにバックアップソフトウェア３０３とアプリケーション３０４が異なるＯＳ上で動作する場合、オンラインバックアップができないことがある。なぜなら、ある種のアプリケーション３０４によれば、アプリケーション３０４のプロセスに書き込みアクセスを停止させるための停止命令は、アプリケーション３０４が動作するゲストＯＳ３０２内からのみ受け付け可能だからである。換言すれば、ある種のアプリケーション３０４には、アプリケーション３０４が動作する仮想マシンの外部から停止命令を受け付けるためのインタフェイスがない。

第２比較例では、上記のような種類のアプリケーション３０４が使われているものとする。例えば、アプリケーション３０４のプロセスは、ゲストＯＳ３０２により提供されるＡＰＩを介して、ゲストＯＳ３０２の内部から発行された停止命令を受け付けることはできるかもしれない。しかし、アプリケーション３０４には、ゲストＯＳ３０２の外部から発行された停止命令（例えば、ネットワーク経由で送信される停止命令）を受け付けるためのインタフェイスがないかもしれない。

上記のように、アプリケーション３０４のプロセスが、ゲストＯＳ３０２の外部から停止命令を受け付けることができないと、停止命令を用いたバックアップソフトウェア３０３とアプリケーション３０４の間の連携も不能である。そして、停止命令を用いた連携が不能な場合、停止命令の発行と受領に応じて静止点が作成されることもない。静止点が作成されないと、データの整合性を保ってオンラインバックアップを行うことができない。つまり、第２比較例では、オンラインバックアップがサポートされない。

したがって、第２比較例では、オフラインバックアップ（コールドバックアップともいう）が行われる。具体的には、実行中のアプリケーション３０４が先に停止され、その後、バックアップソフトウェア３０３のプロセスからバックアップ命令が発行される。バックアップ命令に対する応答がストレージシステム３２０から返された後、アプリケーション３０４は再起動される。

このように、オフラインバックアップが行われる場合、アプリケーション３０４が実行されない期間（すなわち、アプリケーション３０４のプロセスが外部から要求を受け付けることのできない期間）が生じる。例えば、アプリケーション３０４がＤＢＭＳアプリケーションの場合、オフラインバックアップの実行中は、ＤＢＭＳがシャットダウンされているので、データベースへの外部からのアクセス要求は受け付け不能である。

他方、アプリケーション３０４により提供されるサービスに高可用性が求められる場合は、オンラインバックアップがサポートされることが望ましい。換言すれば、オンラインバックアップがサポートされない第２比較例は、求められる可用性のレベルによっては、好ましくないことがある。

以上のような第２比較例を、図１〜２の第１実施形態と比較してみると、以下のことが言える。まず、「バックアップ対象のデータを利用するアプリケーションが動作する環境からは、仮想ディスクしか認識可能でなくてもよい」という点では、第２比較例と第１実施形態は共通である。しかし、第２比較例では上記のようにオンラインバックアップがサポートされないのに対して、第１実施形態ではオンラインバックアップがサポートされる。

つまり、仮に図１のデータ利用プログラム１０６が第１の環境１０１内からしか停止命令を受け付けることができないとしても、図１〜２の第１実施形態では、オンラインバックアップが可能である。それに対し、第２比較例では、アプリケーション３０４がゲストＯＳ３０２の外部から停止命令を受け付けることができないと、オンラインバックアップが不能である。したがって、第１実施形態の方が第２比較例よりも優れている。

換言すれば、ある特定のアプリケーションを仮想環境下で利用したいとユーザが望む場合、第２比較例によれば、ユーザはオンラインバックアップ機能を諦めなくてはならない。しかし、第１実施形態によれば、ユーザはオンラインバックアップ機能を諦める必要がない。

あるいは、ユーザが仮想環境下でのオンラインバックアップを望む場合、ユーザは、第２比較例のバックアップソフトウェア３０３を利用しようとする限りは、アプリケーション３０４のようなある種のアプリケーションを使うことを諦めなくてはならない。しかし、第１実施形態によれば、たとえデータ利用プログラム１０６が第１の環境１０１内からしか停止命令を受け付けることができないとしても、ユーザはデータ利用プログラム１０６を使うことを諦める必要はない。

以上のように、第１実施形態では、バックアップ命令を用いたバックアップ処理が実行可能な条件が、第２比較例のようにオフラインバックアップに限定されておらず、オンラインバックアップが可能である。また、第１実施形態では、バックアップ処理を実行可能にするための条件として、データ利用プログラム１０６に特に課される制約もない。

つまり、第１実施形態では、バックアップ命令を用いたバックアップ処理が実行可能な条件が、第２比較例よりも緩和されている。そして、条件が緩和されてユーザの選択肢が多いぶん、第１実施形態は第２比較例よりも優れている。

さらに、第１実施形態には次のような利点もある。
バックアップ制御プログラム１０３のユーザインタフェイスは、仮想化されていないコンピュータで実行されるバックアップ制御プログラムのものと同様でもよい。ユーザインタフェイスの１つの例は、例えば、バックアップ制御プログラム１０３の実行スケジュールを設定するためのインタフェイスである。ユーザインタフェイスの他の例は、ユーザ定義スクリプトにしたがってバックアップ制御プログラム１０３を実行するためのインタフェイスである。

具体的には、バックアップ制御プログラム１０３のユーザインタフェイスは、第１のプログラムモジュール１０４によって提供されてもよい。
仮想化されていないコンピュータでは、バックアップ対象のデータを利用するデータ利用プログラムと、バックアップ制御プログラムは、同じＯＳ上で動作する。また、第１実施形態において第１のプログラムモジュール１０４は、データ利用プログラム１０６と同じく、第１の環境１０１内で動作する。

このように、データ利用プログラムと同じ環境内で動作するという点で、第１実施形態の第１のプログラムモジュール１０４は、仮想化されていないコンピュータで実行されるバックアップ制御プログラムと類似である。よって、仮想化されていないコンピュータで実行されるバックアップ制御プログラムと同様のユーザインタフェイスを、第１のプログラムモジュール１０４に設けることが可能である。

そして、仮想化されていないコンピュータで実行されるバックアップ制御プログラムと同様のユーザインタフェイスを第１のプログラムモジュール１０４が提供する場合、次のような利点がある。すなわち、この場合、実システムから仮想システムへの移行に際して、今まで実システムで使用されていたユーザ定義スクリプト等のユーザ資産がそのまま利用可能である。よって、ユーザにとっては、「ユーザ資産を無駄にすることなく、実システムから仮想システムへ移行する」という選択肢が選択可能となる。

このように、第１実施形態は、ユーザ利便性に優れている。また、第１実施形態は、仮想システムへの移行を容易にするという効果がある。

続いて、図５〜１２を参照して第２実施形態について説明する。比較の詳細説明は省略するが、第２実施形態も第１実施形態と同様に、第１比較例よりも優れており、また、第２比較例よりも優れている。

図５は、第２実施形態のブロック図である。第２実施形態では、仮想化技術として具体的にはＸｅｎハイパーバイザが利用される。図５のコンピュータ４００では、不図示のＸｅｎハイパーバイザが動作する。

図５には、Ｘｅｎハイパーバイザ上で動作する２つの仮想マシン４１０と４２０が図示されている。また、図５には、ＳＡＮ４３０を介してコンピュータ４００と接続されたストレージシステム４４０も図示されている。

仮想マシン４１０は、具体的にはドメインＵであり、仮想マシン４２０は、具体的にはドメイン０である。仮想マシン４１０は図１の第１の環境１０１に対応し、仮想マシン４２０は図１の第２の環境１０２に対応する。

仮想マシン４１０上では、アプリケーション４１１が動作する。以下では説明の便宜上、アプリケーション４１１が具体的にはＤＢＭＳアプリケーションであるものとする。アプリケーション４１１は、図１のデータ利用プログラム１０６と対応する。

他方、仮想マシン４２０（すなわちドメイン０）は、仮想マシン管理部４２１とＸｅｎＳｔｏｒｅ４２２を含む。Ｘｅｎハイパーバイザが使われる場合、１つまたは複数のドメインＵが存在し得る。仮想マシン管理部４２１は、当該１つまたは複数のドメインＵに関する情報を管理する。ＸｅｎＳｔｏｒｅ４２２は、各ドメインに関する情報を格納する１種のデータベースである。ＸｅｎＳｔｏｒｅ４２２では名前空間が階層化されている。

ところで、上記のように第１実施形態では、バックアップ制御プログラム１０３が、第１の環境１０１上で動作する第１のプログラムモジュール１０４と、第２の環境１０２上で動作する第２のプログラムモジュール１０５を含む。同様に、第２実施形態のバックアップ制御プログラムは、仮想マシン４１０上で動作するフロントエンドコンポーネント４１２と、仮想マシン４２０上で動作するバックエンドコンポーネント４２３を含む。

フロントエンドコンポーネント４１２は連携部４１３と要求部４１４を含み、バックエンドコンポーネント４２３は受付部４２４とＡＰＩ群４２５を含む。

連携部４１３は、アプリケーション４１１とフロントエンドコンポーネント４１２の間の連携のためのモジュールである。例えば、連携部４１３は、第１実施形態と同様の停止命令や解除命令を、アプリケーション４１１のプロセスに対して発行する。連携部４１３は、ユーザインタフェイスも提供する。

要求部４１４は、バックエンドコンポーネント４２３への要求をフロントエンドコンポーネント４１２から送信し、バックエンドコンポーネント４２３からの応答を受信するためのモジュールである。要求部４１４から送信された要求は、受付部４２４により受信される。

詳しくは後述するが、受付部４２４は、要求部４１４から受け付けた要求に応じて様々な処理を行う。そして、受付部４２４は、要求部４１４からの要求に対する応答を、要求部４１４に送信する。

ＡＰＩ群４２５は、ストレージシステム４４０に関連するいくつかのＡＰＩを含む。例えば、コンピュータ４００からストレージシステム４４０に対してコマンドを与え、コマンドに対する応答をストレージシステム４４０から受け取るためのいくつかのＡＰＩが、ＡＰＩ群４２５には含まれる。コマンドは、具体的には例えばＳＣＳＩコマンドでもよく、コマンドに対する応答は、例えば、ＳＣＳＩコマンドに対して返されるステータスであってもよい。受付部４２４は、ＡＰＩ群４２５を用いていくつかの処理を行う。

フロントエンドコンポーネント４１２とバックエンドコンポーネント４２３が協働して行うバックアップ制御のさらなる詳細は、図７〜１２とともに後述する。

さて、ストレージシステム４４０は実ディスク４４１と４４２を含む。ストレージシステム４４０は、具体的にはＲＡＩＤシステムでもよく、実ディスク４４１と４４２のそれぞれは、物理的にはディスクアレイにより実現されてもよい。ＲＡＩＤレベルは任意である。

ストレージシステム４４０がＲＡＩＤシステムである場合、実ディスク４４１は、具体的には、仮想マシン４２０（すなわちドメイン０）から１台の実ディスクドライブとして認識される、１つの論理ユニットである。同様に、ストレージシステム４４０がＲＡＩＤシステムである場合、実ディスク４４２は、仮想マシン４２０から１台の実ディスクドライブとして認識される、もう１つの論理ユニットである。

実ディスク４４１と４４２は、仮想マシン４１０（すなわちドメインＵ）からは認識されない。その代わり、仮想マシン４１０からは、仮想ディスク４４３と４４４が認識される。仮想ディスク４４３は、物理的には、実ディスク４４１上の領域に割り当てられている。同様に、仮想ディスク４４４は、物理的には、実ディスク４４２上の領域に割り当てられている。

説明の便宜上、アプリケーション４１１が利用するデータ（すなわちバックアップ対象のデータ）が、仮想ディスク４４３に記憶されているものとする。そして、バックアップ先の領域は、仮想ディスク４４４にあるものとする。換言すれば、アプリケーション４１１が利用するデータは、物理的には実ディスク４４１に記憶されており、実ディスク４４１上のデータが実ディスク４４２にバックアップされる。

たとえアプリケーション４１１が仮想マシン４１０内からしか停止命令を受け付けることができなくても、また、たとえ仮想マシン４１０からは実ディスク４４１と４４２が認識されなくても、第２実施形態によれば、オンラインバックアップが可能である。なぜなら、バックアップ制御プログラムのフロントエンドコンポーネント４１２とバックエンドコンポーネント４２３は、仮想マシン４１０と４２０に分かれており、協働してバックアップ処理を制御するからである。

次に、図５のようなコンピュータ４００とＳＡＮ４３０とストレージシステム４４０を含むシステムのハードウェア構成の例について説明する。図６は、システムのハードウェア構成図である。

図６には、コンピュータ５００と、ネットワーク５１０と、ネットワーク５１０を介してコンピュータ５００に接続された他のコンピュータ５２０と、コンピュータ読み取り可能な記憶媒体５３０が示されている。ネットワーク５１０は、例えば、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、またはそれらの組み合わせであってもよい。

また、図６には、ＳＡＮ５４０と、ＳＡＮ５４０を介してコンピュータ５００に接続された２つのストレージシステム５５０および５６０も示されている。ＳＡＮ５４０は、例えば、ファイバチャネルによるネットワークでもよい。ストレージシステム５５０と５６０のそれぞれは、例えば、コントローラと複数の磁気ディスク媒体が１つのシャーシに収容されたＲＡＩＤシステムであってもよい。

また、ストレージシステム５６０はなくてもよい。逆に、３つ以上のストレージシステムがＳＡＮ５４０に接続されていてもよい。

図５のコンピュータ４００は、具体的には図６のコンピュータ５００であってもよい。また、図５のＳＡＮ４３０は図６のＳＡＮ５４０に対応する。図５では１つのストレージシステム４４０のブロックのみが図示されているが、図６に示すように、ＳＡＮ５４０には２つ以上のストレージシステムが接続されていてもよい。

例えば、図５の実ディスク４４１と４４２の双方が、具体的には図６のストレージシステム５５０に含まれていてもよい。あるいは、実ディスク４４１と４４２のうちの一方がストレージシステム５５０に含まれ、実ディスク４４１と４４２のうちの他方がストレージシステム５６０に含まれているのでもよい。

コンピュータ５００は、ＣＰＵ５０１と、ＲＡＭ（Random Access Memory）５０２と、ＬＡＮインタフェイス５０３を含む。なお、紙幅の都合上、図６では「インタフェイス」を「Ｉ／Ｆ」と表記している。コンピュータ５００は、ＬＡＮインタフェイス５０３を介して、ネットワーク５１０に接続されている。

コンピュータ５００はさらに、記憶媒体５３０の駆動装置５０４と、入力装置５０５と、出力装置５０６を有する。入力装置５０５は、例えば、キーボードを含み、さらに、マウスなどのポインティングデバイスを含んでいてもよいし、マイクを含んでいてもよい。出力装置５０６は、例えば、ディスプレイ、スピーカ、またはその組み合わせでもよい。

コンピュータ５００は、さらに、ホストバスアダプタ５０７と、ローカルＨＤＤ５０８も有する。ホストバスアダプタ５０７は、コンピュータ５００とＳＡＮ５４０を接続するインタフェイスである。

コンピュータ５００は、ストレージシステム５５０または５６０のディスク上のデータを用いてクライアントにサービスを提供するサーバであってもよい。例えば、コンピュータ５００は、図５のアプリケーション４１１によるデータベースサービスを提供するデータベースサーバであってもよい。

サービスに使われるデータは、上記のとおりストレージシステム５５０または５６０のディスクに記憶される。他方、コンピュータ５００自体の制御に使われるデータ（例えば、ＣＰＵ５０１が実行する種々のプログラム、ＸｅｎＳｔｏｒｅ４２２中のデータ、仮想マシン管理部４２１が管理するデータ、など）は、ローカルＨＤＤ５０８に記憶される。

ローカルＨＤＤ５０８の代わりに（あるいは、ローカルＨＤＤ５０８とともに）ＳＳＤ（Solid-State Drive）が使われてもよい。なお、コンピュータ５００内の上記構成要素同士は、バス５０９で互いに接続されている。

さて、コンピュータ５００のＣＰＵ５０１は、様々なプログラムをＲＡＭ５０２にロードし、ＲＡＭ５０２をワーキングエリアとしても使いながら、プログラムを実行する。ＣＰＵ５０１が実行するプログラムの例は、（９ａ）〜（９ｇ）に示すとおりである。

（９ａ）Ｘｅｎハイパーバイザのプログラム。
（９ｂ）仮想マシン４１０（つまりドメインＵ）のＯＳのプログラム。
（９ｃ）仮想マシン４２０（つまりドメイン０）のＯＳのプログラム。
（９ｄ）アプリケーション４１１のプログラム。
（９ｅ）フロントエンドコンポーネント４１２のプログラム。
（９ｆ）バックエンドコンポーネント４２３のプログラム。
（９ｇ）仮想マシン管理部４２１を実現するためのプログラム。

換言すれば、図５の連携部４１３は、ＣＰＵ５０１により実現される。また、要求部４１４もＣＰＵ５０１により実現される。

なお、要求部４１４と受付部４２４の間ではＴＣＰ／ＩＰ通信が行われるが、要求部４１４と受付部４２４を実現するために、物理的なＬＡＮインタフェイス５０３は必ずしも使われなくてもよい。なぜなら、ＬＡＮインタフェイス５０３も仮想化されるからである。要求部４１４と受付部４２４の間のＴＣＰ／ＩＰ通信は、物理的なＬＡＮインタフェイス５０３を介さずに、コンピュータ５００内の仮想ネットワークのレベルで行われてもよい。

受付部４２４の一部も、要求部４１４と同様に、ＣＰＵ５０１により実現される。また、受付部４２４は、ＡＰＩ群４２５を用いて、ＳＡＮ４３０を介して、命令を送信したり応答を受信したりする。ＳＡＮ４３０を介した通信は、具体的にはホストバスアダプタ５０７により実現される。

ところで、ＣＰＵ５０１が実行する（９ａ）〜（９ｇ）のような各種プログラムは、予めローカルＨＤＤ５０８に記憶されていてもよいし、ネットワーク５１０を介してコンピュータ５２０からコンピュータ５００にダウンロードされてもよい。あるいは、ＣＰＵ５０１が実行する各種プログラムは、記憶媒体５３０に記憶されて提供されてもよい。つまり、プログラムは、駆動装置５０４にセットされた記憶媒体５３０から読み取られ、ローカルＨＤＤ５０８にコピーされてもよい。あるいは、プログラムは、駆動装置５０４から直接ＲＡＭ５０２へロードされてもよい。

記憶媒体５３０は、具体的には、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスクでもよいし、光磁気ディスクでもよいし、磁気ディスクでもよいし、フラッシュメモリカードなどの不揮発性の半導体メモリでもよい。また、記憶媒体５３０だけでなく、例えばＲＡＭ５０２や、ローカルＨＤＤ５０８に含まれるディスク媒体なども、コンピュータ読み取り可能な記憶媒体の例である。そして、以上例示したような各種の記憶媒体は、いずれも、有形の（tangible）媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。

ところで、ストレージシステム５５０は、上記のとおり、例えばＲＡＩＤシステムでもよい。ストレージシステム５５０は、ストレージシステム５５０を制御するコントローラ５５１（より具体的には、例えばＲＡＩＤコントローラ）を含む。また、ストレージシステム５５０はＮ個のディスク５５２−１〜５５２−Ｎを含む。Ｎは１以上であれば任意である。図６には、例として２≦Ｎの場合が例示されている。

詳しくは図９とともに説明するが、ディスク５５２−１は、“／ｄｅｖ／ｓｄａ”というパス名のデバイスファイルに対応する実ディスクとして、コンピュータ４００上の仮想マシン４２０からは認識される。同様に、ディスク５５２−２は、“／ｄｅｖ／ｓｄｂ”というパス名のデバイスファイルに対応する実ディスクとして、コンピュータ４００上の仮想マシン４２０からは認識される。例えば、図５の実ディスク４４１が具体的には図６のディスク５５２−１であってもよく、実ディスク４４２がディスク５５２−２であってもよい。

ストレージシステム５６０の詳細は、図示を省略した。しかし、ストレージシステム５６０も、ストレージシステム５５０と同様に、コントローラと、１個または複数個のディスクを含む。

なお、第１実施形態の図１のコンピュータ１００も、具体的には、例えば図６のコンピュータ５００により実現されてもよい。つまり、ＣＰＵ５０１が、以下の(１０ａ）〜（１０ｅ）のような種々のプログラムを実行してもよい。

（１０ａ）第１の環境１０１を提供するためのプログラム。
（１０ｂ）第２の環境１０２を提供するためのプログラム。
（１０ｃ）第１のプログラムモジュール１０４。
（１０ｄ）第２のプログラムモジュール１０５。
（１０ｅ）データ利用プログラム１０６。

ＣＰＵ５０１は、第１のプログラムモジュール１０４を実行することにより、データ利用プログラム１０６のプロセスに対して第１の環境１０１内から停止命令を発行する停止命令発行部として動作してもよい。さらに、ＣＰＵ５０１は、第１のプログラムモジュール１０４を実行することにより、第１の仮想識別情報と第２の仮想識別情報についての通知を第１の環境１０１内から発行する通知部として動作してもよい。

一方で、ＣＰＵ５０１は、第２のプログラムモジュール１０５を実行することにより、第１の仮想識別情報と第２の仮想識別情報からそれぞれ第１の実識別情報と第２の実識別情報を第２の環境１０２内において取得する取得部として動作してもよい。さらに、ＣＰＵ５０１は、第２のプログラムモジュール１０５を実行することにより、第２の環境１０２内からバックアップ命令を発行するバックアップ命令発行部として動作してもよい。

換言すれば、コンピュータ１００は、停止命令発行部と通知部と取得部とバックアップ命令発行部を含む情報処理装置である。そして、停止命令発行部と通知部は、第１の環境１０１上に実装され、取得部とバックアップ命令発行部は第２の環境１０２上に実装される。

そして、図１の１つ以上の実記憶装置１２０のそれぞれは、具体的には、ストレージシステム５５０内のディスクでもよいし、ストレージシステム５６０内のディスクでもよい。例えば、第１の記憶領域１２１は、ディスク５５２−１上の領域であってもよいし、第２の記憶領域１２２は、ディスク５５２−２上の領域であってもよい。

ここで、第２実施形態の説明に戻る。以下では、第２実施形態で行われるバックアップ制御について、フローチャートと具体的なデータ例を参照して説明する。
図７は、バックアップ制御処理のフローチャートである。図７のバックアップ制御処理は、フロントエンドコンポーネント４１２が仮想マシン４１０にインストールされ、かつ、バックエンドコンポーネント４２３が仮想マシン４２０にインストールされた後、任意のタイミングで開始されてよい。図７のステップＳ２０１は初期化であり、初期化が終わった後、ステップＳ２０２〜Ｓ２０６が繰り返し実行される。

具体的には、ステップＳ２０１で、ユーザからの入力にしたがい、（１１ａ）と（１１ｂ）の情報が所定のファイルに登録される。

（１１ａ）バックエンドコンポーネント４２３（より具体的には受付部４２４）のＩＰアドレス。
（１１ｂ）バックエンドコンポーネント４２３（より具体的には受付部４２４）のポート番号。

ステップＳ２０１における上記所定のファイルは、具体的には、ドメイン０の管理ＯＳが使用する所定のファイルである。当該所定のファイルは、第２実施形態においては、例えば図８のファイル６０１のようなＣＳＶ（Comma Separated Values）形式のファイルである。図８の例では、ステップＳ２０１の結果として、ファイル６０１に、“１０．１０．１０．１０”という受付部４２４のＩＰアドレスと、“１２２６”という受付部４２４のポート番号が登録されている。

ステップＳ２０１の処理は、要求部４１４と受付部４２４の間の通信のための事前準備であり、より具体的には以下のように行われる。
連携部４１３が提供するユーザインタフェイスを介して、ユーザから、上記（１１ａ）と（１１ｂ）の入力が与えられる。ユーザは、例えば図６の入力装置５０５を用いて（１１ａ）と（１１ｂ）の情報を入力する。そして、連携部４１３が入力を受け取る。

ここで、ファイル６０１は、仮想マシン４２０上で管理ＯＳにより管理されるファイルである。したがって、ファイル６０１は、仮想マシン４２０の外部にある連携部４１３からは、直接にはアクセスされない。その代わり、例えば、仮想マシン４１０からファイル６０１に間接的にアクセスするための特定のドライバが、仮想マシン４１０にインストールされていてもよい。

連携部４１３は、入力された（１１ａ）と（１１ｂ）の情報をファイル６０１に登録することを、上記特定のドライバに要求してもよい。上記特定のドライバは、ＸｅｎＢｕｓを介して、（１１ａ）と（１１ｂ）の情報をファイル６０１に登録してもよい。

ＸｅｎＢｕｓは、ドメインＵとドメイン０の間の（例えば、図５の例では、仮想マシン４１０と４２０の間の）情報共有に使われる仕組みである。ＸｅｎＢｕｓへのアクセスがドメイン０において検出されると、ＸｅｎＳｔｏｒｅ４２２が参照される。

例えば、仮想マシン４２０内ではＸｅｎＢｕｓへのアクセスを監視するデーモンが動作していてもよい。当該デーモンが、上記特定のドライバからのＸｅｎＢｕｓへのアクセスを検出し、検出したアクセスに応じて、実際に（１１ａ）と（１１ｂ）の情報をファイル６０１に書き込んでもよい。

例えば以上のようにして、ユーザからの入力にしたがって、ファイル６０１に受付部４２４のＩＰアドレスと、受付部４２４のポート番号が登録される。その後、ステップＳ２０２に示すように、データバックアップのトリガが発生するまでは、特に何の処理も行われなくてよい。そして、データバックアップのトリガが発生するたびに、ステップＳ２０３〜Ｓ２０６の処理が実行される。

なお、フロントエンドコンポーネント４１２とバックエンドコンポーネント４２３を含むバックアップ制御プログラムの実行は、ステップＳ２０１の実行後、一旦終了してもよい。また、バックアップ制御プログラムの実行は、ステップＳ２０６の実行後にも、一旦終了してもよい。そして、データバックアップのトリガの発生に応じて、バックアップ制御プログラムが再度起動されてもよい。

逆に、ステップＳ２０１やＳ２０６の実行後、バックアップ制御プログラムは終了されなくてもよい。例えば連携部４１３がトリガの発生を監視し続けてもよい。

また、データバックアップのトリガは任意である。例えば、ユーザが、入力装置５０５を介してバックアップ制御プログラムを起動してもよい。ユーザはさらに、アプリケーション４１１が利用するデータをバックアップするための指示を、入力装置５０５を介して連携部４１３に与えてもよい。ユーザから連携部４１３に指示が与えられたというイベントは、トリガの一例である。

あるいは、決められたスケジュールにしたがってバックアップ制御プログラムを起動し、いくつかのパラメタを連携部４１３に与えるためのスクリプトが予め作成されていてもよい。この場合、決められた日時になったというイベントが、トリガである。

例えば上記のような何らかのトリガが発生すると、次に、ステップＳ２０３において、連携部４１３とアプリケーション４１１が連携して、静止点を作成する。なお、ステップＳ２０２におけるトリガの発生は、図２のステップＳ１０１に対応し、ステップＳ２０３における静止点の作成は、ステップＳ１０２〜Ｓ１０４に対応する。つまり、ステップＳ２０３では、ステップＳ１０２〜Ｓ１０４と類似の処理が行われる。

具体的には、ステップＳ２０３で連携部４１３は、実行中のアプリケーション４１１のプロセスに対して、停止命令を発行する。上記のとおり第２実施形態では、アプリケーション４１１は、仮想ディスク４４３上の記憶領域に記憶されたデータを利用する。よって、第２実施形態における停止命令は、具体的には、アプリケーション４１１のプロセスに、仮想ディスク４４３上の上記記憶領域に対する更新操作を一時的に停止させるための命令である。

なお、停止命令のパラメタとして、仮想ディスク４４３上の記憶領域を識別する情報が指定されてもよい。あるいは、当該記憶領域に記憶されているデータベースの名前や、当該データベースに含まれるテーブルの名前が停止命令のパラメタとして指定されてもよい。

アプリケーション４１１のプロセスは、停止命令に応じて、例えば第１実施形態における（７ａ）〜（７ｃ）の処理と類似の、（１２ａ）〜（１２ｃ）の処理を行ってもよい。

（１２ａ）実行途中のトランザクションがある場合、実行途中の各トランザクションを、最後まで実行してコミットするか、または、強制的にロールバックする処理。
（１２ｂ）仮想ディスク４４３上の、アプリケーション４１１の利用する上記記憶領域用のディスクキャッシュとして使われるＲＡＭ５０２上の領域に記憶されているデータを、仮想ディスク４４３上の上記記憶領域へとフラッシュする処理。
（１２ｃ）アプリケーション４１１（つまりＤＢＭＳアプリケーション）の動作モードを、書き込み禁止モードに変更する処理（書き込み禁止モードについては、第１実施形態に関連して説明したとおりである）。

例えば（１２ａ）〜（１２ｃ）のような処理により、バックアップ対象のデータ（すなわちコピー元のデータ）は、全体としてバックアップ可能な状態となる。なお、データをバックアップ可能な状態にするための処理は、（１２ａ）〜（１２ｃ）の処理に限られない。そして、停止命令は、データをバックアップ可能な状態に遷移させる処理をアプリケーション４１１のプロセスに行わせるための命令のうちの、一つの例である。

例えば、アプリケーション４１１のプロセスは、更新操作を一時的に停止する代わりに、更新操作のログをとることによって、データをバックアップ可能な状態にしてもよい。換言すれば、（１２ｃ）の処理の代わりに、アプリケーション４１１の動作モードをログモードに変更する処理が行われてもよい。この場合、アプリケーション４１１のプロセスに動作モードを書き込み禁止モードへ変更させることになる停止命令の代わりに、アプリケーション４１１のプロセスに動作モードをログモードへ変更させることになる別の命令を、連携部４１３が発行してもよい。

なお、ログモードにおいて、アプリケーション４１１のプロセスは、新たな書き込みアクセス要求を受け付けた場合に、次のように動作する。すなわち、アプリケーション４１１のプロセスは、書き込みアクセスによってデータがどのように更新されるかをログに記録するとともに、要求に応じた書き込みアクセスを実行する。

以上のようにして、ログモードでは、書き込みアクセスが監視され、記録される。つまり、仮想ディスク４４３から仮想ディスク４４４へとデータが実際にバックアップされている最中に起きる書き込みアクセスによるデータの変更は、ログモードを利用することで管理可能となる。このような管理が可能な場合、書き込みアクセスが禁止されていなくても、データの整合性を保ったバックアップ処理が可能である。換言すれば、ログモードへの遷移により、データはバックアップ可能な状態になる。

以上例示したように、データをバックアップ可能な状態にするための具体的な手法は、アプリケーション４１１の種類に応じて様々である。しかし、以下では説明の便宜上、連携部４１３から停止命令が発行され、停止命令に応じて書き込みアクセスが禁止され、その結果として、静止点が作成される（つまりデータがバックアップ可能な状態になる）ものとする。

アプリケーション４１１のプロセスは、静止点の作成に成功すると、図２のステップＳ１０４と同様に、連携部４１３に対して完了通知を送る。

完了通知に応じて、次のステップＳ２０４では、要求部４１４が、後のステップＳ２０５〜Ｓ２０６での受付部４２４との通信に使うための情報を取得する。具体的には、要求部４１４は、図８のファイル６０１に登録されている、受付部４２４のＩＰアドレスとポート番号を取得するとともに、仮想マシン４１０のドメイン名を取得する。

ステップＳ２０１に関して説明したとおり、仮想マシン４１０からファイル６０１に間接的にアクセスするための特定のドライバが、仮想マシン４１０にインストールされていてもよい。また、仮想マシン４２０内（つまり管理ＯＳ上）では、ＸｅｎＢｕｓへのアクセスを監視するデーモンが動作していてもよい。ステップＳ２０４では、上記ドライバとデーモンを介して、要求部４１４が情報を取得してもよい。

例えば、要求部４１４は、ファイル６０１に登録されているＩＰアドレスとポート番号と、仮想マシン４１０のドメイン名とを読み取るように、上記特定のドライバに要求する。すると、上記特定のドライバはＸｅｎＢｕｓにアクセスし、ＸｅｎＢｕｓへのアクセスをデーモンが検出する。

そして、検出に応じて、デーモンは、ＸｅｎＳｔｏｒｅ４２２を参照してファイル６０１を特定する。デーモンは、ＩＰアドレスとポート番号をファイル６０１から読み取るとともに、仮想マシン４１０のドメイン名をＸｅｎＳｔｏｒｅ４２２の“／ｖｍ／ｎａｍｅ”パスから読み取る。そして、デーモンは、読み取ったＩＰアドレスとポート番号とドメイン名を上記特定のドライバに返す。すると、上記特定のドライバは、以上のようにして得られたＩＰアドレスとポート番号とドメイン名を、要求部４１４に返す。

例えば以上のような一連の処理により、所定のファイル６０１に登録されているＩＰアドレスとポート番号と、仮想マシン４１０のドメイン名とが、要求部４１４からの要求に応じて、ＸｅｎＳｔｏｒｅ４２２を介して読み取られ、要求部４１４に返される。すなわち、要求部４１４は、以上のようにして、受付部４２４のＩＰアドレスとポート番号を取得する。よって、要求部４１４は今後のステップＳ２０５〜Ｓ２０６において、ＴＣＰ／ＩＰにしたがって、受付部４２４との間で通信を行うことができる。

さて、ステップＳ２０５は、図２のステップＳ１０５〜Ｓ１０６に対応し、ステップＳ２０６は図２のステップＳ１０７〜Ｓ１１１に対応する。また、ステップＳ２０５の詳細は図１０のとおりであり、ステップＳ２０６の詳細は図１２のとおりである。ここでは、ステップＳ２０５とＳ２０６の概要を説明する。

ステップＳ２０５では、要求部４１４が受付部４２４に要求を送る。そして、要求に応じて、受付部４２４は、コピー元の仮想デバイスとコピー先の仮想デバイスそれぞれについて、ストレージシステム４４０上での物理的な領域情報を取得する。

そして、ステップＳ２０６では、受付部４２４が、データをコピーする（すなわちバックアップする）ようストレージシステム４４０に指示する。換言すれば、受付部４２４は、物理的な領域情報に基づいて、ＡＰＩ群４２５中のあるＡＰＩを介して、バックアップ命令を発行する。バックアップ命令に応じて、ストレージシステム４４０は、データをバックアップするための処理を実行し、受付部４２４に応答する。

以上のようにしてステップＳ２０２〜Ｓ２０６でオンラインバックアップが行われた後、図７の処理は、ステップＳ２０２に戻る。なお上記のとおり、ステップＳ２０６の完了後、フロントエンドコンポーネント４１２とバックエンドコンポーネント４２３を含むバックアップ制御プログラムの実行は、一旦終了されてもよい。

続いて、上記のステップＳ２０５〜Ｓ２０６の詳細について、図８〜９の具体的な値の例と、図１０〜１２のフローチャートを参照しながら説明する。図８のファイル６０１は、ステップＳ２０１とＳ２０４に関して既に説明したとおりである。図８のコマンド実行例６０２については、図１０のステップＳ３０４〜Ｓ３０５とともに後述する。

図９は、仮想パーティションと仮想ディスクと実パーティションと実ディスクの例を説明する図である。
仮想パーティションは、仮想マシン４１０から認識されるパーティションであり、仮想ディスクは仮想マシン４１０から認識されるディスクである。仮想ディスクの例は、図５の仮想ディスク４４３と４４４である。

各仮想ディスクは、物理的には、いずれかの実ディスク上の領域に割り当てられている。実ディスクの例は、図５の実ディスク４４１と４４２や、図６のディスク５５２−１〜５５２−Ｎなどである。以下では参照符号「５５２−１」〜「５５２−Ｎ」のディスクのことを「実ディスク」とも表記する。

もちろん、実ディスクもパーティショニングされていてよい。実ディスク上のパーティションを、以下では実パーティションという。
一方、第２実施形態では、デバイスドライバのインタフェイスとして、デバイスファイルが使われる。したがって、デバイスは、ＯＳの標準的なシステムコールを介してアクセスされる。パーティションとディスクは、いずれも、デバイスの１種であり、各々のデバイスファイルと対応する。

つまり、仮想パーティションと仮想ディスクの各々は、仮想マシン４１０内で認識されるデバイスファイルと対応する。実パーティションと実ディスクの各々は、仮想マシン４２０内で認識されるデバイスファイルと対応する。

以下では説明の便宜上、以下の（１３ａ）〜（１３ｈ）のように仮定する。

（１３ａ）バックアップ対象の記憶領域は、仮想マシン４１０から認識される仮想ディスク４４３上の１つのパーティション全体である。当該パーティションは、具体的には、仮想マシン４１０において“／ｄｅｖ／ｘｖｄａ３”というパス名で識別されるデバイスファイルに対応する、図９の仮想パーティション６０３−１である。
（１３ｂ）データのバックアップ先の記憶領域は、仮想マシン４１０から認識される仮想ディスク４４４上の１つのパーティション全体である。当該パーティションは、具体的には、仮想マシン４１０において“／ｄｅｖ／ｘｖｄｂ３”というパス名で識別されるデバイスファイルに対応する、図９の仮想パーティション６０３−２である。
（１３ｃ）仮想パーティション６０３−１は、仮想マシン４１０において認識される仮想ディスク６０４−１上のパーティションのうちの１つである。仮想ディスク６０４−１は、仮想マシン４１０において“／ｄｅｖ／ｘｖｄａ”というパス名で識別されるデバイスファイルに対応する。図５の仮想ディスク４４３は、具体的には仮想ディスク６０４−１である。
（１３ｄ）仮想パーティション６０３−２は、仮想マシン４１０において認識される仮想ディスク６０４−２上のパーティションのうちの１つである。仮想ディスク６０４−２は、仮想マシン４１０において“／ｄｅｖ／ｘｖｄｂ”というパス名で識別されるデバイスファイルに対応する。図５の仮想ディスク４４４は、具体的には仮想ディスク６０４−２である。
（１３ｅ）物理的には、実パーティション６０５−１の全体が仮想ディスク６０４−１用に使われる。実パーティション６０５−１は、仮想マシン４２０において“／ｄｅｖ／ｓｄａ６”というパス名で識別されるデバイスファイルに対応する。
（１３ｆ）物理的には、実パーティション６０５−２の全体が仮想ディスク６０４−２用に使われる。実パーティション６０５−２は、仮想マシン４２０において“／ｄｅｖ／ｓｄｂ６”というパス名で識別されるデバイスファイルに対応する。
（１３ｇ）実パーティション６０５−１は、仮想マシン４２０において認識される実ディスク５５２−１上のパーティションのうちの１つである。図６にも示したように、実ディスク５５２−１は、仮想マシン４２０において“／ｄｅｖ／ｓｄａ”というパス名で識別されるデバイスファイルに対応する。図５の実ディスク４４１は、具体的には実ディスク５５２−１である。
（１３ｈ）実パーティション６０５−２は、仮想マシン４２０において認識される実ディスク５５２−２上のパーティションのうちの１つである。図６にも示したように、実ディスク５５２−２は、仮想マシン４２０において“／ｄｅｖ／ｓｄｂ”というパス名で識別されるデバイスファイルに対応する。図５の実ディスク４４２は、具体的には実ディスク５５２−２である。

ところで、ディスクやパーティションなどのデバイス上のアドレスは、例えば、５１２バイトのセクタを単位としたＬＢＡ（Logical Block Addressing）番号で表されてもよい。図９には、アドレスも例示されている。具体的には以下のとおりである。

実ディスク５５２−１上のアドレスＡ１から始まる領域が、実パーティション６０５−１として使われる。実ディスク５５２−１のサイズはＡ２である。
また、仮想ディスク６０４−１上のアドレスＢ１から始まる領域が、仮想パーティション６０３−１として使われる。仮想ディスク６０４−１のサイズはＢ２である。

なお、第２実施形態では、実パーティション６０５−１の全体が、仮想ディスク６０４−１用に割り当てられている。そのため、実パーティション６０５−１のサイズもＢ２であり、仮想パーティション６０３−１が物理的に位置する領域は、実パーティション６０５−１上のアドレスＢ１から始まる領域である。

図９のとおり、仮想パーティション６０３−１のサイズをＣとする。すると、仮想パーティション６０３−１は、仮想ディスク６０４−１上の、アドレスＢ１からアドレス（Ｂ１＋Ｃ−１）までの領域である。また、仮想パーティション６０３−１は、物理的には、実パーティション６０５−１上の、アドレスＢ１からアドレス（Ｂ１＋Ｃ−１）までの領域を占める。そして、当該領域の開始アドレスと終了アドレスを、実ディスク５５２−１上のアドレスにより表すと、それぞれ、アドレス（Ａ１＋Ｂ１）とアドレス（Ａ１＋Ｂ１＋Ｃ−１）である。

さて、実ディスク５５２−２上のアドレスＤ１から始まる領域が、実パーティション６０５−２として使われる。実ディスク５５２−２のサイズはＤ２である。
また、仮想ディスク６０４−２上のアドレスＥ１から始まる領域が、仮想パーティション６０３−２として使われる。仮想ディスク６０４−２のサイズはＥ２である。

なお、第２実施形態では、実パーティション６０５−２の全体が、仮想ディスク６０４−２用に割り当てられている。そのため、実パーティション６０５−２のサイズもＥ２であり、仮想パーティション６０３−２が物理的に位置する領域は、実パーティション６０５−２上のアドレスＥ１から始まる領域である。

ところで、仮想パーティション６０３−２は、仮想パーティション６０３−１上のデータをバックアップするために使われるので、仮想パーティション６０３−２は仮想パーティション６０３−１と同じか、それより大きいサイズである。以下では簡単のため、仮想パーティション６０３−１と６０３−２は同一サイズであるとする。

したがって、仮想パーティション６０３−２は、仮想ディスク６０４−２上の、アドレスＥ１からアドレス（Ｅ１＋Ｃ−１）までの領域である。また、仮想パーティション６０３−２は、物理的には、実パーティション６０５−２上の、アドレスＥ１からアドレス（Ｅ１＋Ｃ−１）までの領域を占める。そして、当該領域の開始アドレスと終了アドレスを、実ディスク５５２−２上のアドレスにより表すと、それぞれ、アドレス（Ｄ１＋Ｅ１）とアドレス（Ｄ１＋Ｅ１＋Ｃ−１）である。

続いて、図９の仮想パーティション６０３−１から仮想パーティション６０３−２へのデータのバックアップを具体例として参照しながら、図７のステップＳ２０５の詳細を説明する。図１０は、ステップＳ２０５において物理領域情報を取得する処理のフローチャートである。

なお、説明の便宜上、図１０では、コピー元の仮想デバイスの名前を“ｓｒｃ”と表記し、コピー先の仮想デバイスの名前を“ｄｓｔ”と表記してある。また、以下では、特に断らない限り、デバイスの名前として当該デバイスに対応するデバイスファイルのパス名が使われるものとする。

したがって、図９の例においては、コピー元の仮想デバイスの名前ｓｒｃは、コピー元の仮想パーティション６０３−１に対応するデバイスファイルの、“／ｄｅｖ／ｘｖｄａ３”というパス名である。そして、コピー先の仮想デバイスの名前ｄｓｔは、コピー先の仮想パーティション６０３−２に対応するデバイスファイルの、“／ｄｅｖ／ｘｖｄｂ３”というパス名である。

なお、コピー元の仮想デバイスの名前ｓｒｃと、コピー先の仮想デバイスの名前ｄｓｔは、図７のステップＳ２０２でトリガイベントが検出されたときに、連携部４１３により取得される。例えば、これらの名前ｓｒｃとｄｓｔは、入力装置５０５を介して入力されてもよいし、スクリプトに記載されていてもよい。

そして、これらの名前ｓｒｃとｄｓｔは、連携部４１３から要求部４１４に通知される。したがって、要求部４１４は、これらの名前ｓｒｃとｄｓｔを用いて図１０の処理を開始することができる。

まず、ステップＳ３０１で要求部４１４は、コピー元の仮想デバイスについての領域情報を、コピー元の仮想デバイスの名前ｓｒｃから取得する。ステップＳ３０１で取得される領域情報は、ゲストＯＳにより認識される領域情報（つまり、要求部４１４が含まれる仮想マシン４１０から認識される領域情報）であって、具体的には、例えば以下の（１４ａ）〜（１４ｃ）を含む。

（１４ａ）仮想デバイスが存在する仮想ディスクを識別する情報（例えば、仮想ディスクに対応するデバイスファイルのパス名）。
（１４ｂ）仮想デバイスの、仮想ディスク上での開始位置（例えば、ＬＢＡ番号により表される開始アドレス）。
（１４ｃ）仮想デバイスのサイズ（例えば、ＬＢＡ番号と同様に５１２バイトのセクタを単位として表されるサイズ）。

以上の領域情報は、仮想マシン４１０において認識される１つ以上の仮想ディスク（図９の場合、少なくとも２つの仮想ディスク６０４−１と６０４−２）の中で、仮想パーティション６０３−１を識別する情報の例である。したがって、（１４ａ）〜（１４ｃ）を含む領域情報は、第1実施形態の（３ａ）に示した第１の仮想識別情報に対応する。

また、例えば、図９の例の場合、要求部４１４はステップＳ３０１で、コピー元の仮想パーティション６０３−１の名前（すなわち“／ｄｅｖ／ｘｖｄａ３”）から、以下の（１５ａ）〜（１５ｃ）を含む領域情報を取得する。

（１５ａ）仮想ディスク６０４−１の名前（すなわち“／ｄｅｖ／ｘｖｄａ”）。
（１５ｂ）仮想パーティション６０３−１の、仮想ディスク６０４−１上での開始位置を示すアドレスＢ１。
（１５ｃ）仮想パーティション６０３−１のサイズＣ。

なお、ステップＳ３０１における領域情報の取得のための具体的方法は実施形態に応じて様々であってよい。ここで、一例として、図１１の方法について説明する。図１１は、デバイスの領域情報を取得する処理のフローチャートである。

図１１に示す処理は、フロントエンドコンポーネント４１２内の要求部４１４によって実行されてもよいし、後述するように、バックエンドコンポーネント４２３内の受付部４２４によって実行されてもよい。要求部４１４が図１１の処理を実行する場合は、仮想デバイス（具体的には仮想パーティションまたは仮想ディスク）の名前から、当該仮想デバイスについての領域情報が得られる。他方、受付部４２４が図１１の処理を実行する場合は、実デバイス（具体的には実パーティションまたは実ディスク）の名前から、当該実デバイスについての領域情報が得られる。以下では、図１０のステップＳ３０１において要求部４１４が図１１の処理を実行する場合を例として、説明する。

なお、説明の便宜上、図１１では、領域情報を取得する対象のデバイスの名前を“ｄ”と表記してある。例えば、要求部４１４がステップＳ３０１で、仮想パーティション６０３−１の名前（すなわち“／ｄｅｖ／ｘｖｄａ３”）から領域情報を取得しようとする場合、図１１におけるデバイス名ｄは、“／ｄｅｖ／ｘｖｄａ３”である。

ステップＳ４０１で要求部４１４は、デバイス名ｄのデバイスをオープンして、ファイルディスクリプタを取得する。以下では説明の便宜上、取得されたファイルディスクリプタを、“ｆ”という符号で参照する。要求部４１４は、仮想マシン４１０のゲストＯＳが提供するシステムコールを利用することで、デバイス名ｄのデバイスをオープンすることができる。

次に、ステップＳ４０２で要求部４１４は、例えばｉｏｃｔｌ（ｆ，ＨＤＩＯ＿ＧＥＴＧＥＯ）というシステムコールを実行することによって、上記デバイスの開始位置とサイズを取得する。

そして、ステップＳ４０３で要求部４１４は、取得した開始位置が０であるか否かを判断する。
開始位置が０の場合、上記デバイスは、ディスクの一部のパーティションではなく、ディスク全体である。そこで、図１１の処理はステップＳ４０４へと移行する。

逆に、開始位置が０ではない場合（より具体的には開始位置が０より大きい場合）、上記デバイスは、ディスク上のパーティションである。そこで、図１１の処理は、ステップＳ４０５へと移行する。

ステップＳ４０４で要求部４１４は、デバイス名ｄで識別されるデバイスについての領域情報として、以下の（１６ａ）〜（１６ｃ）の組を取得する。そして、図１１の処理は終了する。

（１６ａ）ディスク名であるデバイス名ｄ。
（１６ｂ）０という開始位置。
（１６ｃ）ステップＳ４０２で取得したサイズ。

例えば、図９の例では、コピー対象（つまりバックアップ対象）のデバイスは仮想パーティション６０３−１である。しかし、実施形態によっては、アプリケーション４１１が仮想ディスク６０４−１全体を利用してもよい。

アプリケーション４１１が仮想ディスク６０４−１全体を利用する場合、仮想ディスク６０４−１全体がバックアップ対象として指定される。つまり、実施形態によっては、図１０のステップＳ３０１におけるコピー元の仮想デバイスが、仮想ディスク６０４−１全体であるかもしれない。例えば、コピー元の仮想デバイスが仮想ディスク６０４−１全体である場合、ステップＳ４０４では、“／ｄｅｖ／ｘｄｖａ”という仮想ディスク６０４−１の名前と、０という開始位置と、Ｂ２というサイズが取得される。

さて、開始位置が０ではない場合、ステップＳ４０５で要求部４１４は、以下の（１７ａ）と（１７ｂ）から、ディスク名（すなわち、デバイス名ｄで識別されるパーティションが存在するディスクの名前）を取得する。

（１７ａ）パーティションを示すデバイス名ｄ。
（１７ｂ）パーティション名とディスク名の間の対応関係。例えば、「ディスク名の末尾に数字をつけた名前が、パーティション名として使われる」などの既知の規則により表される対応関係。

例えば、デバイス名ｄが仮想パーティション６０３−１の名前（すなわち“／ｄｅｖ／ｘｖｄａ３”）である場合、（１７ｂ）の対応関係から、要求部４１４は、“／ｄｅｖ／ｘｖｄａ”というディスク名を取得する。このディスク名は、図９から理解されるように、仮想パーティション６０３−１が存在する仮想ディスク６０４−１の名前である。

そして、次のステップＳ４０６で要求部４１４は、デバイス名ｄで識別されるデバイスについての領域情報として、以下の（１８ａ）〜（１８ｃ）の組を取得する。そして、図１１の処理は終了する。

（１８ａ）ステップＳ４０５で取得したディスク名。
（１８ｂ）ステップＳ４０２で取得した開始位置。
（１８ｃ）ステップＳ４０２で取得したサイズ。

例えば、デバイス名ｄが“／ｄｅｖ／ｘｖｄａ３”である場合、図９の例によれば、ステップＳ４０２で要求部４１４は、開始位置としてアドレスＢ１を取得するとともに、サイズとしてＣという値を取得する。また、この場合、上記のとおり要求部４１４は、ステップＳ４０５で仮想ディスク６０４−１のディスク名（つまり“／ｄｅｖ／ｘｖｄａ”）を取得する。よって、要求部４１４は、“／ｄｅｖ／ｘｖｄａ”というディスク名と、アドレスＢ１と、サイズＣとの組を、仮想パーティション６０３−１の領域情報として取得する。

以上、図１０のステップＳ３０１の処理の一例として、図１１のフローチャートについて説明した。しかし、もちろん、実施形態に応じて、ステップＳ３０１の処理の詳細は様々であってよい。

例えば、図１１のフローチャートは、ＬＶＭ（Logical Volume Manager）などのボリューム管理ソフトウェアが仮想マシン４１０において使われていない場合に行われる処理を示す。しかし、場合によっては、ボリューム管理ソフトウェアが使われていてもよい。その場合、ステップＳ３０１で要求部４１４は、ボリューム管理ソフトウェアのＣＬＩ（Command Line Interface）を介して、コピー元の仮想デバイスの名前から、コピー元の仮想デバイスについての領域情報を取得してもよい。

ここで、図１０の説明に戻る。ステップＳ３０２で要求部４１４は、コピー先の仮想デバイスについての領域情報を、コピー先の仮想デバイスの名前ｄｓｔから取得する。ステップＳ３０２で取得される領域情報も、ゲストＯＳにより認識される領域情報である。ステップＳ３０２の処理の詳細は、ステップＳ３０１と同様である。

ステップＳ３０２で取得される領域情報は、仮想マシン４１０において認識される１つ以上の仮想ディスク（図９の場合、少なくとも２つの仮想ディスク６０４−１と６０４−２）の中で、仮想パーティション６０３−２を識別する情報の例である。したがって、ステップＳ３０２で取得される領域情報は、第1実施形態の（３ｂ）に示した第２の仮想識別情報に対応する。

例えば、図９の例の場合、要求部４１４はステップＳ３０２で、コピー先の仮想パーティション６０３−２の名前（すなわち“／ｄｅｖ／ｘｖｄｂ３”）から、以下の（１９ａ）〜（１９ｃ）を含む領域情報を取得する。

（１９ａ）仮想ディスク６０４−２の名前（すなわち“／ｄｅｖ／ｘｖｄｂ”）。
（１９ｂ）仮想パーティション６０３−２の、仮想ディスク６０４−２上での開始位置を示すアドレスＥ１。
（１９ｃ）仮想パーティション６０３−２のサイズＣ。

そして、次のステップＳ３０３で要求部４１４は、以下の（２０ａ）〜（２０ｄ）の情報を、ＴＣＰ／ＩＰにしたがって受付部４２４に通知する。ステップＳ３０３での通知は、換言すれば、コピー元の仮想デバイスとコピー先の仮想デバイスについての物理的な領域情報を取得するよう、受付部４２４に求める要求である。また、ステップＳ３０３は図２のステップＳ１０５に対応する。

（２０ａ）ステップＳ３０１で取得した、コピー元の仮想デバイスについての領域情報のうち仮想ディスクの名前（例えば、（１５ａ）の“／ｄｅｖ／ｘｖｄａ”という名前）。
（２０ｂ）ステップＳ３０２で取得した、コピー先の仮想デバイスについての領域情報のうち仮想ディスクの名前（例えば、（１９ａ）の“／ｄｅｖ／ｘｖｄｂ”という名前）。
（２０ｃ）要求部４１４が含まれる仮想マシン４１０のドメイン名。
（２０ｄ）要求部４１４がステップＳ３０３で受付部４２４に要求する処理に対応する特定のＡＰＩを、ＡＰＩ群４２５の中で識別する識別情報（例えば、“７”などの番号で表されるＩＤ（identifier））。

なお、要求部４１４は、図７のステップＳ２０４で受付部４２４のＩＰアドレスとポート番号を既に取得している。よって、要求部４１４は、取得したＩＰアドレスとポート番号を用いて、受付部４２４との間でＴＣＰ／ＩＰ通信を行うことができる。ＴＣＰ／ＩＰを利用することにより、互いに異なる仮想マシンに含まれる要求部４１４と受付部４２４との間での通信が可能となる。

受付部４２４は、要求部４１４からの通知を受信すると、ステップＳ３０４〜Ｓ３０９の処理を行い、ステップＳ３１０で要求部４１４に応答する。ステップＳ３０４〜Ｓ３０９は、図２のステップＳ１０６に対応し、具体的には以下のとおりである。

ステップＳ３０４で受付部４２４は、コピー元について通知された（２０ａ）の情報（すなわち仮想ディスク名）から、コピー元の実デバイスを識別する識別情報を取得する。具体的には、受付部４２４は、例えば、“ｌｉｓｔ −−ｌｏｎｇ”オプションを指定したｘｍコマンドを利用して、コピー元の実デバイスの識別情報を取得してもよい。受付部４２４は、管理ＯＳの動作する仮想マシン４２０内にあるので、ｘｍコマンドを呼び出して使うことができる。

例えば図８のコマンド実行例６０２に示すように、受付部４２４は、要求部４１４から通知されたドメイン名（例えば“ｄｏｍＡ”）をパラメタとして、ｘｍコマンドを呼び出してもよい。参照の便宜のため、図８では適宜改行と空白を加えて、コマンド実行例６０２をＳ式（S-expression）の形式で示している。

受付部４２４は、コマンドの実行結果の中から、次の条件（２１ａ）〜（２２ｂ）をともに満たすようなＳ式を検索する。

（２１ａ）“ｄｅｖｉｃｅ”タグを持っている。
（２１ｂ）要求部４１４から通知された仮想ディスク名を“ｄｅｖ”タグと対応づけるＳ式を含んでいる。

コマンド実行例６０２の場合、“ｄｅｖｉｃｅ”タグを持っており、かつ、“（ｄｅｖ ｘｖｄａ：ｄｉｓｋ）”というＳ式を含むＳ式が見つかる。そして、受付部４２４は、見つかったＳ式の中で、“ｕｎａｍｅ”タグを含むＳ式を検索する。コマンド実行例６０２の場合、“（ｕｎａｍｅ ｐｈｙ：／ｄｅｖ／ｓｄａ６）”というＳ式が見つかる。

受付部４２４は、見つかったＳ式において“ｕｎａｍｅ”タグと対応づけられている実デバイス名を取得する。コマンド実行例６０２の場合、“／ｄｅｖ／ｓｄａ６”という実デバイス名が取得される。こうして取得される“／ｄｅｖ／ｓｄａ６”という実デバイス名は、図９に示すように、実パーティション６０５−１（すなわちコピー元の仮想パーティション６０３−１が物理的に位置している実デバイス）の名前である。

受付部４２４は、例えば以上のようにして、ｘｍコマンドを利用することで、コピー元の実デバイスの識別情報を取得する。もちろん、実施形態によっては、ｘｍコマンド以外のコマンドが使われてもよい。

次に、ステップＳ３０５で受付部４２４は、コピー先について通知された（２０ｂ）の情報（すなわち仮想ディスク名）から、コピー先の実デバイスを識別する識別情報を取得する。例えば、受付部４２４は、ステップＳ３０４で実行したｘｍコマンドの結果を用いて、ステップＳ３０４と同様の方法により、ステップＳ３０５でコピー先の実デバイスの識別情報を取得してもよい。

図８のコマンド実行例６０２によれば、“／ｄｅｖ／ｘｖｄｂ”という仮想ディスク名から“／ｄｅｖ／ｓｄｂ６”という実デバイス名が取得される。こうして取得される“／ｄｅｖ／ｓｄｂ６”という実デバイス名は、図９に示すように、実パーティション６０５−２（すなわちコピー先の仮想パーティション６０３−２が物理的に位置している実デバイス）の名前である。

そして、ステップＳ３０６で受付部４２４は、コピー元の実デバイスについての領域情報を、ステップＳ３０４で取得した識別情報から取得する。ステップＳ３０６で取得される領域情報は、管理ＯＳにより認識される領域情報（つまり受付部４２４が含まれる仮想マシン４２０から認識される領域情報）であって、具体的には、例えば以下の（２２ａ）〜（２２ｃ）を含む。

（２２ａ）実デバイスが存在する実ディスクを識別する情報（例えば、実ディスクに対応するデバイスファイルのパス名）。
（２２ｂ）実デバイスの、実ディスク上での開始位置（例えば、ＬＢＡ番号により表される開始アドレス）。
（２２ｃ）実デバイスのサイズ（例えば、ＬＢＡ番号と同様に５１２バイトのセクタを単位として表されるサイズ）。

例えば、図９の例の場合、受付部４２４はステップＳ３０６で、コピー元の実パーティション６０５−１の名前（すなわち“／ｄｅｖ／ｓｄａ６”）から、以下の（２３ａ）〜（２３ｃ）を含む領域情報を取得する。

（２３ａ）実ディスク５５２−１の名前（すなわち“／ｄｅｖ／ｓｄａ”）。
（２３ｂ）実パーティション６０５−１の、実ディスク５５２−１上での開始位置を示すアドレスＡ１。換言すれば、仮想ディスク６０４−１が実ディスク５５２−１上に占める領域の開始位置を示すアドレスＡ１。
（２３ｃ）実パーティション６０５−１のサイズＢ２。

なお、ステップＳ３０６における領域情報の取得のための具体的方法は実施形態に応じて様々であってよい。例えば、仮想マシン４２０においてＬＶＭなどのボリューム管理ソフトウェアが使われていなければ、受付部４２４は、図１１のフローチャートにしたがって上記の（２２ａ）〜（２２ｃ）を含む領域情報を取得してもよい。図１１に関しては、要求部４１４が図１１の処理を行う場合について具体的に説明したが、上記のとおり受付部４２４が図１１の処理を行うこともできる。

あるいは、仮想マシン４２０においてボリューム管理ソフトウェアが使われていれば、受付部４２４は、ボリューム管理ソフトウェアのＣＬＩを介して、コピー元の実デバイスの名前から、コピー元の実デバイスについての領域情報を取得してもよい。

次に、ステップＳ３０７で受付部４２４は、コピー先の実デバイスについての領域情報を、ステップＳ３０５で取得した識別情報から取得する。ステップＳ３０７で取得される領域情報も、管理ＯＳにより認識される領域情報である。ステップＳ３０７の詳細は、ステップＳ３０６と同様である。

例えば、図９の例の場合、受付部４２４はステップＳ３０７で、コピー先の実パーティション６０５−２の名前（すなわち”／ｄｅｖ／ｓｄｂ６”）から、以下の（２４ａ）〜（２４ｃ）を含む領域情報を取得する。

（２４ａ）実ディスク５５２−２の名前（すなわち“／ｄｅｖ／ｓｄｂ”）。
（２４ｂ）実パーティション６０５−２の、実ディスク５５２−２上での開始位置を示すアドレスＤ１。換言すれば、仮想ディスク６０４−２が実ディスク５５２−２上に占める領域の開始位置を示すアドレスＤ１。
（２４ｃ）実パーティション６０５−２のサイズＥ２。

そして、次のステップＳ３０８で受付部４２４は、コンピュータ４００に接続された１つまたは複数のストレージシステム４４０（例えば図６では２つのストレージシステム５５０と５６０）の中でコピー元の実ディスク５５２−１を識別する識別情報を取得する。ステップＳ３０８における識別情報の取得は、具体的には、ＡＰＩ群４２５のうちで、ステップＳ３０３の通知中の（２０ｄ）の識別情報で識別される特定のＡＰＩを介して、行われる。以下では説明の便宜上、この特定のＡＰＩを「ボリューム取得ＡＰＩ」と呼ぶことにする。

例えば、図６のストレージシステム５５０と５６０が、いずれも、ＳＣＳＩコマンドを受け付けるＲＡＩＤシステムであるとする。この場合、ステップＳ３０８で受付部４２４は、具体的には、実ディスク５５２−１に対するＳＣＳＩコマンドを、ボリューム取得ＡＰＩを介して発行する。

例えば、ＳＣＳＩコマンドは、次のようにして発行されてもよい。受付部４２４は、実ディスク５５２−１の名前をパラメタに指定して、ボリューム取得ＡＰＩを呼び出す。すると、ボリューム取得ＡＰＩにより、指定された名前のデバイスファイルがオープンされて、ファイルディスクリプタが取得される。さらに、取得されたファイルディスクリプタとＳＣＳＩコマンドの内容がパラメタとして指定されたｉｏｃｔｌ（）システムコールが、ボリューム取得ＡＰＩから呼び出される。

ＳＣＳＩコマンドの発行は、例えば以上のような一連の処理によって実現されてもよい。発行されたＳＣＳＩコマンドは、ホストバスアダプタ５０７とＳＡＮ５４０を介して送信される。

受付部４２４は、ＳＣＳＩコマンドに対する応答として、ストレージシステム５５０と５６０の中で実ディスク５５２−１を識別する識別情報を、実ディスク５５２−１を含む方のストレージシステム５５０から取得する。取得される識別情報は、具体的には、以下の（２５ａ）〜（２５ｂ）を含む。

（２５ａ）コピー元の実ディスクを有するストレージシステムの識別情報（以下、ストレージシステムＩＤともいう）。例えば、実ディスク５５２−１を含むストレージシステム５５０のＩＤ（例えば、“１”などの番号で表されるＩＤ）。
（２５ｂ）上記（２５ａ）の識別情報で識別されるストレージシステムのディスクアレイ内において、コピー元の実ディスクに対応するボリュームを識別する識別情報（以下、ボリュームＩＤともいう）。例えば、ストレージシステム５５０内で実ディスク５５２−１に対応するボリュームを識別するために使われ、ストレージシステム５５０内で一意のＩＤ（例えば、“２”などの番号で表されるＩＤ）。ボリュームＩＤは、具体的にはＬＵＮ（Logical Unit Number）であってもよい。

さらに、ステップＳ３０９で受付部４２４は、コンピュータ４００に接続された１つまたは複数のストレージシステム４４０（例えば図６では２つのストレージシステム５５０と５６０）の中でコピー先の実ディスク５５２−２を識別する識別情報を取得する。ステップＳ３０９の詳細はステップＳ３０８と同様である。受付部４２４は、ボリューム取得ＡＰＩを介して、例えば以下の（２６ａ）〜（２６ｂ）を含む識別情報を、実ディスク５５２−２を含むストレージシステム５５０から取得する。

（２６ａ）実ディスク５５２−２を含むストレージシステム５５０のストレージシステムＩＤ。
（２６ｂ）ストレージシステム５５０のディスクアレイ内において、実ディスク５５２−２に対応するボリュームを識別するボリュームＩＤ。

そして、次のステップＳ３１０で受付部４２４は、ステップＳ３０４〜Ｓ３０９の処理により取得した情報を、要求部４１４に通知する。ステップＳ３１０の通知はステップＳ３０３の要求に対する応答である。

ステップＳ３１０での通知も、ＴＣＰ／ＩＰにしたがって行われる。また、ステップＳ３１０では、具体的には以下の（２７ａ）〜（２７ｇ）の情報が通知される。

（２７ａ）処理結果を示す情報（例えば、復帰コードとエラー番号の組み合わせ）。
（２７ｂ）ステップＳ３０８で取得されたストレージシステムＩＤ（例えば、ストレージシステム５５０のＩＤ）。
（２７ｃ）ステップＳ３０８で取得されたボリュームＩＤ（例えば、ストレージシステム５５０内で実ディスク５５２−１に対応するボリュームのＩＤ）。
（２７ｄ）ステップＳ３０６で取得された開始位置（例えば、アドレスＡ１）。
（２７ｅ）ステップＳ３０９で取得されたストレージシステムＩＤ（例えば、ストレージシステム５５０のＩＤ）。
（２７ｆ）ステップＳ３０９で取得されたボリュームＩＤ（例えば、ストレージシステム５５０内で実ディスク５５２−２に対応するボリュームのＩＤ）．
（２７ｇ）ステップＳ３０７で取得された開始位置（例えば、アドレスＤ１）。

なお、今までの説明においては、簡単化のためエラー処理について特に言及しなかった。しかし、場合によっては、何らかのエラーが生じることもあり得る。何らかのエラーが生じた場合、上記（２７ｂ）〜（２７ｇ）の項目はすべて無効な値でもよい。

以下では説明の簡単化のため、エラーが生じなかったものとする。つまり、（２７ａ）の復帰コードは成功を示す値であるものとする。

受付部４２４からの応答を受信すると、要求部４１４はステップＳ３１１で、コピー元の仮想デバイスの実ディスク上での開始位置を計算する。具体的には、要求部４１４は、受付部４２４からの応答に含まれる（２７ｄ）の開始位置と、ステップＳ３０１で取得した（１４ｂ）の開始位置とを足す。

図９の例によれば、コピー元の仮想デバイスは仮想パーティション６０３−１であり、（２７ｄ）の開始位置はアドレスＡ１であり、（１４ｂ）の開始位置は（１５ｂ）に例示したとおりアドレスＢ１である。よって、要求部４１４は、アドレスＡ１とＢ１を足す。その結果、仮想パーティション６０３−１の実ディスク５５２−１上での開始位置である、アドレス（Ａ１＋Ｂ１）が得られる。

以上のようにして、第２実施形態においても、第１実施形態の（４ａ）に示した第１の実識別情報に相当する情報が取得される。つまり、１つ以上の実ディスク（図９の場合、少なくとも２つの実ディスク５５２−１と５５２−２）の中で、仮想パーティション６０３−１が占める記憶領域を識別する情報が取得される。

１つの観点から見れば、（２３ａ）の実ディスク名（すなわち“／ｄｅｖ／ｓｄａ”）と、ステップＳ３１１で計算されたアドレス（Ａ１＋Ｂ１）の組み合わせが、第１の実識別情報に相当する。別の観点から見れば、（２５ａ）のストレージシステムＩＤと、（２５ｂ）のボリュームＩＤと、ステップＳ３１１で計算されたアドレス（Ａ１＋Ｂ１）の組み合わせが、第１の実識別情報に相当する。しかし、いずれにしろ、第１の実識別情報に相当する情報は、コンピュータ４００がバックエンドコンポーネント４２３にしたがって動作した結果に基づいて、取得される。

また、要求部４１４はステップＳ３１２で、コピー先の仮想デバイスの実ディスク上での開始位置を計算する。具体的には、要求部４１４は、受付部４２４からの応答に含まれる（２７ｇ）の開始位置と、ステップＳ３０２で取得した開始位置（例えば（１９ｂ）に例示した開始位置）とを足す。

図９の例によれば、コピー先の仮想デバイスは仮想パーティション６０３−２であり、（２７ｇ）の開始位置はアドレスＤ１であり、ステップＳ３０２で取得した開始位置は（１９ｂ）に例示したとおりアドレスＥ１である。よって、要求部４１４は、アドレスＤ１とＥ１を足す。その結果、仮想パーティション６０３−２の実ディスク５５２−２上での開始位置である、アドレス（Ｄ１＋Ｅ１）が得られる。

以上のようにして、第２実施形態においても、第１実施形態の（４ｂ）に示した第２の実識別情報に相当する情報が取得される。つまり、１つ以上の実ディスク（図９の場合、少なくとも２つの実ディスク５５２−１と５５２−２）の中で、仮想パーティション６０３−２が占める記憶領域を識別する情報が取得される。

１つの観点から見れば、（２４ａ）の実ディスク名（すなわち“／ｄｅｖ／ｓｄｂ”）と、ステップＳ３１２で計算されたアドレス（Ｄ１＋Ｅ１）の組み合わせが、第２の実識別情報に相当する。別の観点から見れば、（２６ａ）のストレージシステムＩＤと、（２６ｂ）のボリュームＩＤと、ステップＳ３１２で計算されたアドレス（Ｄ１＋Ｅ１）の組み合わせが、第２の実識別情報に相当する。しかし、いずれにしろ、第２の実識別情報に相当する情報は、コンピュータ４００がバックエンドコンポーネント４２３にしたがって動作した結果に基づいて、取得される。

以上説明したようにして、図１０のフローチャートにしたがって物理領域情報が取得される。なお、図１０の処理におけるステップの実行順序は、矛盾が生じない限り適宜入れ替えられてもよい。例えば、ステップＳ３０１とＳ３０２の順序は逆でもよい。ステップＳ３１１とＳ３１２の順序も、逆でもよい。ステップＳ３０４〜Ｓ３０９の順序は、様々に変更可能である。例えば、ステップＳ３０５、Ｓ３０７、Ｓ３０９、Ｓ３０４、Ｓ３０６、Ｓ３０８という実行順序も可能である。

図１０の処理の終了後、次に、図７のステップＳ２０６に相当する図１２の処理が行われる。図１２は、ストレージシステムにデータのコピーを指示する処理のフローチャートである。

ステップＳ５０１で要求部４１４が、受付部４２４にコピー処理を要求する。要求に際して、要求部４１４は、受付部４２４に以下の（２８ａ）〜（２８ｊ）のパラメタを通知する。ステップＳ５０１での要求も、具体的にはＴＣＰ／ＩＰにしたがって行われる。

（２８ａ）要求部４１４が存在する仮想マシン４１０のドメイン名。
（２８ｂ）要求部４１４がステップＳ５０１で受付部４２４に要求する処理に対応する特定のＡＰＩ（以下では説明の便宜上、コピー開始ＡＰＩという）を、ＡＰＩ群４２５の中で識別する識別情報（例えば、“３”などの番号で表されるＩＤ）。
（２８ｃ）データをコピーするためのＳＣＳＩコマンドを発行する対象となる仮想ディスクの名前。図９の例では、コピー元の仮想ディスク６０４−１の名前である“／ｄｅｖ／ｘｖｄａ”か、または、コピー先の仮想ディスク６０４−２の名前である“／ｄｅｖ／ｘｖｄｂ”。
（２８ｄ）コピー元の仮想デバイスに対応して、図１０のステップＳ３１０で通知された（２７ｂ）のストレージシステムＩＤ（例えば、ストレージシステム５５０のＩＤ）。
（２８ｅ）コピー元の仮想デバイスに対応して、図１０のステップＳ３１０で通知された（２７ｃ）のボリュームＩＤ（例えば、ストレージシステム５５０内で実ディスク５５２−１に対応するボリュームのＩＤ）。
（２８ｆ）コピー元の仮想デバイスに関して、図１０のステップＳ３１１で計算した開始位置（例えば、アドレス（Ａ１＋Ｂ１））。
（２８ｇ）コピー元の仮想デバイスに関して、図１０のステップＳ３０１で取得したサイズ（例えば、サイズＣ）。
（２８ｈ）コピー先の仮想デバイスに対応して、図１０のステップＳ３１０で通知された（２７ｅ）のストレージシステムＩＤ（例えば、ストレージシステム５５０のＩＤ）。
（２８ｉ）コピー先の仮想デバイスに対応して、図１０のステップＳ３１０で通知された（２７ｆ）のボリュームＩＤ（例えば、ストレージシステム５５０内で実ディスク５５２−２に対応するボリュームのＩＤ）。
（２８ｊ）コピー先の仮想デバイスに関して、図１０のステップＳ３１２で計算した開始位置（例えば、アドレス（Ｄ１＋Ｅ１））。

次に、ステップＳ５０２で受付部４２４は、要求部４１４から（２８ｃ）のパラメタとして通知された、コピー元またはコピー先の仮想ディスクの名前から、対応する実デバイス名を取得する。

例えば、（２８ｃ）のパラメタとして、コピー元の仮想ディスク６０４−１の名前である“／ｄｅｖ／ｘｖｄａ”が通知された場合、受付部４２４は、仮想ディスク６０４−１に対応する実パーティション６０５−１の名前を取得する。受付部４２４は、図１０のステップＳ３０４と同様にして、例えばｘｍコマンドを利用することにより、実パーティション６０５−１の名前である“／ｄｅｖ／ｓｄａ６”を取得することができる。

あるいは、（２８ｃ）のパラメタとして、コピー先の仮想ディスク６０４−２の名前である“／ｄｅｖ／ｘｖｄｂ”が通知された場合、受付部４２４は、仮想ディスク６０４−２に対応する実パーティション６０５−２の名前を取得する。受付部４２４は、図１０のステップＳ３０５と同様にして、実パーティション６０５−２の名前である“／ｄｅｖ／ｓｄｂ６”を取得することができる。

次に、ステップＳ５０３で受付部４２４は、ストレージシステム４４０に対して、データをコピー（すなわちバックアップ）するよう指示するための命令を発行する。具体的には受付部４２４は、要求部４１４から通知されたパラメタと、ステップＳ５０２で取得した実デバイス名を使って、ストレージシステム４４０に対して命令を発行する。命令の発行は、ＡＰＩ群４２５のうち、（２８ｂ）のパラメタにより指定されているコピー開始ＡＰＩを介して、行われる。ステップＳ５０３は、図２のステップＳ１０７に対応し、ステップＳ５０３で発行される命令は、第１実施形態のバックアップ命令に相当する。

より具体的には、コピー開始ＡＰＩを介してＳＣＳＩコマンドを発行するために、ステップＳ５０３で受付部４２４は、コピー開始ＡＰＩに対して以下の（２９ａ）〜（２９ｈ）のパラメタを指定する。

（２９ａ）ＳＣＳＩコマンドを発行する対象となる実デバイスの名前（すなわち、ステップＳ５０２で取得した名前）。
（２９ｂ）コピー元の仮想デバイスに対応するストレージシステムＩＤ（すなわち、要求部４１４から通知された（２８ｄ）のストレージシステムＩＤ）。
（２９ｃ）コピー元の仮想デバイスに対応するボリュームＩＤ（すなわち、要求部４１４から通知された（２８ｅ）のボリュームＩＤ）。
（２９ｄ）コピー元の仮想デバイスの実ディスク上での開始位置（すなわち、要求部４１４から通知された（２８ｆ）のアドレス）。
（２９ｅ）コピー元の仮想デバイスのサイズ（すなわち、要求部４１４から通知された（２８ｇ）のサイズ）。
（２９ｆ）コピー先の仮想デバイスに対応するストレージシステムＩＤ（すなわち、要求部４１４から通知された（２８ｈ）のストレージシステムＩＤ）。
（２９ｇ）コピー先の仮想デバイスに対応するボリュームＩＤ（すなわち、要求部４１４から通知された（２８ｉ）のボリュームＩＤ）。
（２９ｈ）コピー先の仮想デバイスの実ディスク上での開始位置（すなわち、要求部４１４から通知された（２８ｊ）のアドレス）。

上記のパラメタのうち、（２９ｂ）〜（２９ｈ）のパラメタは、ＳＣＳＩコマンドのパラメタとして使われる。他方、（２９ａ）のパラメタは、実デバイスのデバイスファイルをオープンしてファイルディスクリプタを取得するために使われる。

取得されたファイルディスクリプタと、（２９ｂ）〜（２９ｈ）のパラメタが指定されたＳＣＳＩコマンドの内容が、オープンされたデバイスファイルに対するｉｏｃｔｌ（）システムコールにパラメタとして指定される。その結果、第１実施形態のバックアップ命令に相当するＳＣＳＩコマンドが、コピー開始ＡＰＩを介して発行される。ＳＣＳＩコマンドは、ホストバスアダプタ５０７とＳＡＮ５４０を介して送信される。

なお、ステップＳ５０１で要求部４１４が受付部４２４に通知する（２８ｃ）のパラメタとしては、コピー元の仮想ディスクの名前とコピー先の仮想ディスクの名前のうちの、一方だけで十分である。そのため、受付部４２４がステップＳ５０３でコピー開始ＡＰＩに指定する（２９ａ）のパラメタも、コピー元の実デバイスの名前とコピー先の実デバイスの名前の、いずれか一方である。このように、コピー元とコピー先のいずれかの実デバイスの名前だけで十分な理由は、以下のとおりである。

例えば図６と図９に示すように、コピー元の実デバイスとコピー先の実デバイスが同じストレージシステム５５０に含まれている場合がある。この場合、当該ストレージシステム５５０がＳＣＳＩコマンドを受信すれば十分である。

また、場合によっては、コピー元の実デバイスとコピー先の実デバイスのうち、一方がストレージシステム５５０に含まれ、他方がストレージシステム５６０に含まれることもあり得る。しかし、コピー元とコピー先の実デバイスがストレージシステム５５０と５６０に分かれていても、ストレージシステム５５０と５６０のうち一方のみがＳＣＳＩコマンドを受信すれば十分である。

例えば、コピー元の実デバイスがストレージシステム５５０に含まれ、コピー先の実デバイスがストレージシステム５６０に含まれ、ＳＣＳＩコマンドがストレージシステム５５０に送信されたとする。このような場合でも、ストレージシステム５５０がＳＡＮ５４０を介してストレージシステム５６０に適宜の制御情報を送信すれば、ストレージシステム５５０と５６０が協働してコピー処理（すなわちバックアップ処理）を行うことができる。

逆に、ＳＣＳＩコマンドがストレージシステム５６０に送信された場合は、ストレージシステム５６０がＳＡＮ５４０を介してストレージシステム５５０に適宜の制御情報を送信すればよい。いずれの場合も、制御情報の送信は、ＳＣＳＩプロトコルにしたがって行われてもよい。

したがって、受付部４２４は、ストレージシステム５５０と５６０の一方にのみ、コピー制御ＡＰＩを介してＳＣＳＩコマンドを送信すれば、十分である。
以下では説明の簡単化のため、図６のように１つのストレージシステム５５０の中にコピー元の実ディスク５５２−１とコピー先の実ディスク５５２−２の双方が含まれるものとする。この場合、ステップＳ５０３で送信されるＳＣＳＩコマンドに応じて、ストレージシステム５５０は、コントローラ５５１による制御にしたがい、データをコピーする（つまりバックアップする）。具体的には、ストレージシステム５５０は、例えば以下のように動作してもよい。

ストレージシステム５５０は、（２９ｂ）〜（２９ｅ）のパラメタによって特定される第１の記憶領域（例えば、図９の実ディスク５５２−１上の灰色の領域）のスナップショットを作成する。スナップショットの作成は、図２のステップＳ１０８に対応する。スナップショットの作成後、ストレージシステム５５０は、第１の記憶領域から、（２９ｅ）〜（２９ｈ）のパラメタによって特定される第２の記憶領域（例えば、図９の実ディスク５５２−２上の灰色の領域）へと、実際にデータをコピーする。

なお、第２の記憶領域のサイズは第１の記憶領域のサイズと同じである。そのため、どちらのサイズも（２９ｅ）のパラメタによって示されている。
第１の記憶領域から第２の記憶領域に実際にデータをコピーする上記の処理は、バックグラウンドで行われる。ストレージシステム５５０は、スナップショットの作成後、バックグラウンド処理が完了しないうちに（例えばバックグラウンド処理を開始する前に）、受付部４２４に応答を返す。当該応答は、データをコピーする処理の完了を示す。また、当該応答を返す処理は、図２のステップＳ１０９に対応する。

以上のようにストレージシステム５５０が動作することにより、実際にはストレージシステム５５０がバックグラウンドでデータをコピーする処理を実行中であっても、受付部４２４は、実際にデータをコピーする処理があたかも完了したかのように認識する。

また、第１の記憶領域のサイズが大きい場合、第１の記憶領域から第２の記憶領域に実際にデータをコピーするには、ある程度長い時間がかかる。しかし、たとえ第１の記憶領域のサイズが大きくても、スナップショットの作成には短い時間しかかからない。よって、以上のようにストレージシステム５５０が動作することにより、受付部４２４は、「第１の記憶領域から第２の記憶領域へのデータのバックアップが短い時間で完了した」と認識することになる。

図１２におけるステップＳ５０４は、受付部４２４がストレージシステム４４０（具体的には例えばストレージシステム５５０）からの応答の受信を待つことを示す。受付部４２４が、例えばコピー開始ＡＰＩを介して応答を受信すると、図１２の処理はステップＳ５０５へと移行する。

ステップＳ５０５で受付部４２４は、要求部４１４に対して処理結果を通知する。ステップＳ５０５は図２のステップＳ１１０に対応する。
例えば、スナップショットの作成が成功した場合、ストレージシステム４４０からの応答は、データをコピーする処理が正常に終了したことを示す。したがって、この場合、受付部４２４は、正常終了を要求部４１４に通知する。逆に、何らかの理由によりスナップショットの作成が失敗した場合、ストレージシステム４４０からの応答はエラーを示すので、受付部４２４も要求部４１４に対してエラーを通知する。なお、ステップＳ５０５の通知もＴＣＰ／ＩＰにしたがって行われる。

最後に、ステップＳ５０６で連携部４１３が、アプリケーション４１１のプロセスに対して、処理結果を通知する。ステップＳ５０６は図２のステップＳ１１１に対応する。
つまり、連携部４１３は、要求部４１４が受付部４２４からステップＳ５０５で受信した処理結果を、アプリケーション４１１のプロセスに通知する。ステップＳ５０６での通知は、例えば、仮想マシン４１０上で動作するゲストＯＳにより提供される、仮想マシン４１０内でのプロセス間通信のための標準的なＡＰＩを介して行われてもよい。

連携部４１３からの通知が正常終了を示していれば、アプリケーション４１１のプロセスは、仮想パーティション６０３−１に対する更新操作を再開する。つまり、正常終了を示す連携部４１３からの通知は、第１実施形態における解除命令に相当する。

より具体的には、アプリケーション４１１のプロセスは、例えば、動作モードを書き込み禁止モードから通常モードに変更する。動作モードの変更にともなって、アプリケーション４１１のプロセスは、書き込み禁止モードで動作していた間に受け付けた書き込みアクセスの結果がキャッシュされているキャッシュ領域中のデータを、仮想パーティション６０３−１にフラッシュしてもよい。更新操作の再開のための以上のような処理は、図２のステップＳ１１２に対応する。

そして、アプリケーション４１１のプロセスは、新たな書き込みアクセス要求を受け付けた場合、当該書き込みアクセス要求に応じて、仮想パーティション６０３−１への書き込みアクセスを実行する。

ところで、本発明は上記実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することもできる。上記および下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。

第２実施形態ではＸｅｎハイパーバイザが利用されており、第２実施形態の仮想マシン４１０は第１実施形態の第１の環境１０１に対応し、第２実施形態の仮想マシン４２０は第１実施形態の第２の環境１０２に対応する。しかし、第１実施形態に関して上記（１ａ）〜（１ｂ）と（２ａ）〜（２ｃ）で説明したように、第１の環境１０１と第２の環境１０２を提供する仮想化技術は、別にＸｅｎハイパーバイザに限定されるわけではない。したがって、Ｘｅｎハイパーバイザを利用する第２実施形態は、仮想化技術の違いに応じた適宜の変更を加えれば、Ｘｅｎハイパーバイザ以外の仮想化技術が使われる場合にも適用可能となる。

例えば、第２実施形態においては、Ｘｅｎハイパーバイザが使われる場合に特有のＸｅｎＳｔｏｒｅ４２２やｘｍコマンドが使われる。しかし、他の仮想化技術が使われる場合、仮想化技術の種類に応じて、第２実施形態におけるＸｅｎＳｔｏｒｅ４２２やｘｍコマンドの利用は、他のコンポーネントあるいは他のコマンドの利用に適宜置き換えられてよい。そのような適宜の置き換えがなされれば、Ｘｅｎハイパーバイザ以外の仮想化技術が使われる場合においても、第２実施形態と類似のバックアップ制御が可能である。

また、図１のデータ利用プログラム１０６と図５のアプリケーション４１１は、上記のとおり、いずれも例えばＤＢＭＳアプリケーションであってもよいが、他の種類のアプリケーションであってもよい。

また、図９の例では、仮想ディスクと実ディスクのサイズが異なり、実ディスクの一部である実パーティションの１つが、１台の仮想ディスクに割り当てられている。しかし、実施形態によっては、実ディスクと仮想ディスクのサイズが同じでもよい。つまり、１台の実ディスク全体が、１台の仮想ディスクに割り当てられていてもよい。第２実施形態は、そのような場合にも適用可能である。

もし実ディスクと仮想ディスクのサイズが同じであれば、図１０のステップＳ３０６とＳ３０７で受付部４２４が行う図１１の処理において、ステップＳ４０２で０という開始位置が取得され、ステップＳ４０４が実行される。しかし、図７および１０〜１２に示したフローチャート自体には、何の変更もいらない。

また、第２実施形態に関しては、１つの仮想パーティション全体がバックアップ対象の場合について具体的に説明した。しかし、バックアップ対象の記憶領域は、仮想パーティションの一部であってもよい。

第２実施形態に関して、ＳＣＳＩコマンドのパラメタの具体例を説明したが、実施形態によっては、さらに別のオプションがＳＣＳＩコマンドにパラメタとして指定されてもよい。また、実施形態によっては、ＳＣＳＩプロトコル以外の他のプロトコルにしたがってコマンドを受け付けるストレージシステムが使われてもよい。ＳＡＮの種類も実施形態に応じて任意である。

また、第１実施形態においてコンピュータ１００は、第１の記憶領域１１１と第２の記憶領域１１２のサイズが等しいか否か（換言すれば第１の記憶領域１２１と第２の記憶領域１２２のサイズが等しいか否か）をチェックしてもよい。同様に、第２実施形態において要求部４１４は、例えばステップＳ３０１とＳ３０２でそれぞれ取得したサイズ同士が等しいか否かをチェックしてもよい。

あるいは、第２の記憶領域１１２は第１の記憶領域１１１よりも大きくてもよい。同様に、仮想パーティション６０３−２は、仮想パーティション６０３−１よりも大きくてもよい。

第２実施形態では、ステップＳ３１０で受付部４２４が要求部４１４に通知した情報の一部が、ステップＳ５０１で要求部４１４から受付部４２４に通知される。つまり、第２実施形態では多少冗長な通信が行われる。しかし、実施形態によっては、ステップＳ３１０で受付部４２４が要求部４１４に既に通知した情報は、ステップＳ５０１では送信されなくてもよい。

また、第２実施形態では、ステップＳ３１１〜Ｓ３１２で要求部４１４が開始位置の計算を行う。しかし、実施形態によっては、要求部４１４が、ステップＳ３０１とＳ３０２でそれぞれ取得した２つのアドレスを受付部４２４に通知し、受付部４２４がステップＳ３１１〜Ｓ３１２と同様の計算を行ってもよい。

最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータ上の第１の環境で実行される第１のプログラムモジュールと、前記コンピュータ上の環境であって、１つ以上の実記憶装置の各々を認識することが可能な第２の環境で実行される第２のプログラムモジュールとを含むバックアップ制御プログラムであって、前記コンピュータに、
前記第１の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第１の記憶領域を利用する、データ利用プログラムのプロセスに、前記第１の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第１のプログラムモジュールにしたがって発行し、
前記第１の環境において認識される１つ以上の仮想記憶装置内において前記第１の記憶領域を識別する第１の仮想識別情報と、前記データのバックアップ先である第２の記憶領域を前記１つ以上の仮想記憶装置内において識別する第２の仮想識別情報を、前記第２のプログラムモジュールのプロセスに対して、前記第１のプログラムモジュールにしたがって通知し、
前記１つ以上の実記憶装置と前記１つ以上の仮想記憶装置との間の対応関係と、通知された前記第１の仮想識別情報とを用いて、前記１つ以上の実記憶装置内において前記第１の記憶領域を識別する第１の実識別情報を、前記第２のプログラムモジュールにしたがって取得し、
前記対応関係と、通知された前記第２の仮想識別情報とを用いて、前記１つ以上の実記憶装置内において前記第２の記憶領域を識別する第２の実識別情報を、前記第２のプログラムモジュールにしたがって取得し、
前記第１の記憶領域から前記第２の記憶領域に前記データをバックアップするためのバックアップ命令を、取得した前記第１の実識別情報と取得した前記第２の実識別情報に基づいて、前記第２のプログラムモジュールにしたがって発行する
ことを含む処理を実行させるバックアップ制御プログラム。
（付記２）
前記プログラムが前記コンピュータに実行させる前記処理が、
前記１つ以上の実記憶装置のうち、前記第１の記憶領域または前記第２の記憶領域を有する実記憶装置を制御する制御装置から、前記バックアップ命令に対する応答を、前記第２のプログラムモジュールにしたがって受け取り、
前記応答の内容を、前記第２のプログラムモジュールにしたがって、前記第１のプログラムモジュールのプロセスに対して通知し、
前記応答が正常終了を示していれば、前記第１のプログラムモジュールにしたがって、前記停止命令を解除する解除命令を、前記データ利用プログラムの前記プロセスに対して発行する
ことをさらに含むことを特徴とする付記１に記載のバックアップ制御プログラム。
（付記３）
前記第１の仮想識別情報と前記第２の仮想識別情報の通知は、ネットワークプロトコルにしたがって行われる
ことを特徴とする付記１または２に記載のバックアップ制御プログラム。
（付記４）
前記１つ以上の実記憶装置の各々は、ディスクであり、
前記１つ以上の仮想記憶装置は、少なくとも第１と第２の仮想記憶装置を含み、
前記第１の記憶領域は、前記第１の仮想記憶装置上のパーティションであり、
前記第２の記憶領域は、前記第２の仮想記憶装置上のパーティションである
ことを特徴とする付記１から３のいずれか１項に記載のバックアップ制御プログラム。
（付記５）
前記第１の環境は、ハイパーバイザ上で動作する第１の仮想マシンであり、
前記第２の環境は、前記ハイパーバイザ上で動作する第２の仮想マシンであり、
前記第１の仮想マシンから前記１つ以上の実記憶装置へのアクセスは、前記第２の仮想マシンのデバイスドライバを介して行われる
ことを特徴とする付記１から４のいずれか１項に記載のバックアップ制御プログラム。
（付記６）
前記第１の環境は、前記第２の環境上または前記第２の環境内に構築された環境であり、
前記第１の環境内からの前記１つ以上の実記憶装置へのアクセスは、前記第２の環境を提供するオペレーティング・システムを介して行われる
ことを特徴とする付記１から４のいずれか１項に記載のバックアップ制御プログラム。
（付記７）
コンピュータが、
前記コンピュータ上の第１の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第１の記憶領域を利用する、データ利用プログラムのプロセスに、前記第１の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第１の環境で動作する第１の制御プログラムにしたがって発行し、
前記コンピュータ上の環境であって、１つ以上の実記憶装置の各々を認識することが可能な第２の環境で動作する、第２の制御プログラムのプロセスに対して、前記第１の環境において認識される１つ以上の仮想記憶装置内において前記第１の記憶領域を識別する第１の仮想識別情報と、前記データのバックアップ先である第２の記憶領域を前記１つ以上の仮想記憶装置内において識別する第２の仮想識別情報を、前記第１の制御プログラムにしたがって通知し、
前記１つ以上の実記憶装置と前記１つ以上の仮想記憶装置との間の対応関係と、通知された前記第１の仮想識別情報とを用いて、前記１つ以上の実記憶装置内において前記第１の記憶領域を識別する第１の実識別情報を、前記第２の制御プログラムにしたがって取得し、
前記対応関係と、通知された前記第２の仮想識別情報とを用いて、前記１つ以上の実記憶装置内において前記第２の記憶領域を識別する第２の実識別情報を、前記第２の制御プログラムにしたがって取得し、
前記第１の記憶領域から前記第２の記憶領域に前記データをバックアップするためのバックアップ命令を、取得した前記第１の実識別情報と取得した前記第２の実識別情報に基づいて、前記第２の制御プログラムにしたがって発行する
ことを含むバックアップ制御方法。
（付記８）
第１の環境と、１つ以上の実記憶装置の各々を認識することが可能な第２の環境が構築された情報処理装置であって、
前記第１の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第１の記憶領域を利用する、データ利用プログラムのプロセスに対して、前記第１の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第１の環境内から発行する停止命令発行部と、
前記第１の環境において認識される１つ以上の仮想記憶装置内において前記第１の記憶領域を識別する第１の仮想識別情報と、前記データのバックアップ先である第２の記憶領域を前記１つ以上の仮想記憶装置内において識別する第２の仮想識別情報についての通知を、前記第１の環境内から発行する通知部と、
前記通知を前記第２の環境において受け取り、前記１つ以上の実記憶装置と前記１つ以上の仮想記憶装置との間の対応関係と、通知された前記第１の仮想識別情報とを用いて、前記１つ以上の実記憶装置内において前記第１の記憶領域を識別する第１の実識別情報を取得し、前記対応関係と、通知された前記第２の仮想識別情報とを用いて、前記１つ以上の実記憶装置内において前記第２の記憶領域を識別する第２の実識別情報を取得する取得部と、
前記第１の記憶領域から前記第２の記憶領域に前記データをバックアップするためのバックアップ命令を、取得された前記第１の実識別情報と取得された前記第２の実識別情報に基づいて、前記第２の環境内から発行するバックアップ命令発行部
を備えることを特徴とする情報処理装置。

１００、４００、５００、５２０ コンピュータ
１０１ 第１の環境
１０２ 第２の環境
１０３ バックアップ制御プログラム
１０４ 第１のプログラムモジュール
１０５ 第２のプログラムモジュール
１０６ データ利用プログラム
１１０ 仮想記憶装置
１１１、１２１ 第１の記憶領域
１１２、１２２ 第２の記憶領域
１２０ 実記憶装置
１２３ 制御装置
２００、３００ 物理サーバ
２０１、３０２ ゲストＯＳ
２０２、３０３ バックアップソフトウェア
２０３、３０４、４１１ アプリケーション
２１０、３１０、４３０、５４０ ＳＡＮ
２２０、３２０、４４０、５５０、５６０ ストレージシステム
２２１、２２２、３２１、３２２、４４１、４４２、５５２−１〜５５２−Ｎ 実ディスク
３０１ 管理ＯＳ
３２３、３２４、４４３、４４４、６０４−１、６０４−２ 仮想ディスク
４１０、４２０ 仮想マシン
４１２ フロントエンドコンポーネント
４１３ 連携部
４１４ 要求部
４２１ 仮想マシン管理部
４２２ ＸｅｎＳｔｏｒｅ
４２３ バックエンドコンポーネント
４２４ 受付部
４２５ ＡＰＩ群
５０１ ＣＰＵ
５０２ ＲＡＭ
５０３ ＬＡＮインタフェイス
５０４ 駆動装置
５０５ 入力装置
５０６ 出力装置
５０７ ホストバスアダプタ
５０８ ローカルＨＤＤ
５０９ バス
５１０ ネットワーク
５３０ 記憶媒体
５５１ コントローラ
６０１ ファイル
６０２ コマンド実行例
６０３−１、６０３−２ 仮想パーティション
６０５−１、６０５−２ 実パーティション

Claims (2)

1. コンピュータが、
   前記コンピュータ上の第１の仮想マシン上で動作し、かつ、バックアップ対象のデータが記憶されている第１の記憶領域を利用する、データ利用プログラムのプロセスに、前記第１の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第１の仮想マシンで動作する第１の制御プログラムにしたがって発行し、
   前記コンピュータ上の仮想マシンであって、１つ以上の実記憶装置の各々を認識することが可能な第２の仮想マシンで動作する、第２の制御プログラムのプロセスに対して、前記第１の仮想マシンにおいて認識される１つ以上の仮想記憶装置内において前記第１の記憶領域を識別する第１の仮想ディスクに対応するデバイスファイルのパス名と、前記データのバックアップ先である第２の記憶領域を前記１つ以上の仮想記憶装置内において識別する第２の仮想ディスクに対応するデバイスファイルのパス名を、前記第１の制御プログラムにしたがって通知し、
   前記１つ以上の実記憶装置と前記１つ以上の仮想記憶装置との間の対応関係と、通知された前記第１の仮想ディスクに対応するデバイスファイルのパス名とを用いて、前記１つ以上の実記憶装置内において前記第１の記憶領域を識別する第１の実識別情報を、前記第２の制御プログラムにしたがって取得し、
   前記対応関係と、通知された前記第２の仮想ディスクに対応するデバイスファイルのパス名とを用いて、前記１つ以上の実記憶装置内において前記第２の記憶領域を識別する第２の実識別情報を、前記第２の制御プログラムにしたがって取得し、
   前記第１の記憶領域から前記第２の記憶領域に前記データをバックアップするためのバックアップ命令を、取得した前記第１の実識別情報と取得した前記第２の実識別情報に基づいて、前記第２の制御プログラムにしたがって発行する
   ことを含むバックアップ制御方法。
2. 第１の仮想マシンと、１つ以上の実記憶装置の各々を認識することが可能な第２の仮想マシンが構築された情報処理装置であって、
   前記第１の仮想マシン上で動作し、かつ、バックアップ対象のデータが記憶されている第１の記憶領域を利用する、データ利用プログラムのプロセスに対して、前記第１の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第１の仮想マシン内から発行する停止命令発行部と、
   前記第１の仮想マシンにおいて認識される１つ以上の仮想記憶装置内において前記第１の記憶領域を識別する第１の仮想ディスクに対応するデバイスファイルのパス名と、前記データのバックアップ先である第２の記憶領域を前記１つ以上の仮想記憶装置内において識別する第２の仮想ディスクに対応するデバイスファイルのパス名についての通知を、前記第１の仮想マシン内から発行する通知部と、
   前記通知を前記第２の仮想マシンにおいて受け取り、前記１つ以上の実記憶装置と前記１つ以上の仮想記憶装置との間の対応関係と、通知された前記第１の仮想ディスクに対応するデバイスファイルのパス名とを用いて、前記１つ以上の実記憶装置内において前記第１の記憶領域を識別する第１の実識別情報を取得し、前記対応関係と、通知された前記第２の仮想ディスクに対応するデバイスファイルのパス名とを用いて、前記１つ以上の実記憶装置内において前記第２の記憶領域を識別する第２の実識別情報を取得する取得部と、
   前記第１の記憶領域から前記第２の記憶領域に前記データをバックアップするためのバックアップ命令を、取得された前記第１の実識別情報と取得された前記第２の実識別情報に基づいて、前記第２の仮想マシン内から発行するバックアップ命令発行部
   を備えることを特徴とする情報処理装置。