JP5156682B2 - ストレージシステムにおけるバックアップ方法 - Google Patents

Description

本発明は、ストレージシステムに関し、特に、計算機システムにおけるアプリケーションによって使用されるデータのバックアップ方法に関する。

「ストレージ装置の障害」、「コンピュータウィルスによるデータ破壊」、「ユーザによる誤操作」などによって、ホスト計算機におけるアプリケーション（以下、「ＡＰ」とよぶ）によって使用されるデータを喪失してしまうことがある。ストレージ装置においては、該データを喪失する場合に備え、該データをコピーして保存する「バックアップ」を実施している。ＡＰによって使用されるデータが喪失した場合には、ストレージ装置はバックアップしたデータを復旧する「リカバリ」を実行する。

データのバックアップ手法として様々な方法がある。その１つに、バックアップによる業務ホストへの影響を抑えるために、ストレージ装置のコピー機能を用いるバックアップ方法がある。該コピー機能により、ＡＰにより使用されているストレージ装置の主記録領域にデータの書き込みが発生した場合、同じ書き込みデータを同じストレージ装置内の副記録領域へ書き込む。つまり、常に、主記録領域に格納されるデータに対応するデータを格納する副記憶領域を作成することができる。そして、ある時点で該コピー機能を停止すると、主記憶領域に格納されるデータに関して、副記録領域にコピー機能停止した時点でのバックアップのデータを作成することができる。

リカバリ時点におけるデータを回復するためには、データの整合性が保たれた状態を保存しなければならない。一般的に整合性を保つためには、ＡＰを「静止化」する。ＡＰの「静止化」とは、該当ＡＰに関連する新規トランザクションの受付けを停止してから、メモリ内の更新情報をディスクに強制出力する処理である。この処理には、ＡＰ特有の処理が必要になるため、バックアップ対象のＡＰと連携したバックアップソフトウェアを用意しなければならない。さらに、ＡＰを「静止化」させることにより、一定時間の業務処理もあわせて停止しければならず、業務効率が低下する。

リカバリして回復できるＡＰの時刻（以下、「リカバリ可能時刻」とよぶ）は、バックアップした時刻に依存する。通常、バックアップした時刻は、バックアップ対象を静止化した時刻である。この時刻により、障害時にシステムが停止した時に、Ｒｅｃｏｖｅｒｙ Ｐｏｉｎｔ Ｏｂｊｅｃｔｉｖｅ（以下、「ＲＰＯ」と呼ぶ）を管理することができる。ＲＰＯとは、データが喪失しシステム停止時に、どの時点までのデータが回復できるか、という目標時点を意味する。

ＡＰの静止化を行わずにバックアップを取得する手段の一つとして、サーバ仮想化技術を用いた手法がある。サーバ仮想化技術は、一台のサーバコンピュータによって、一台以上の仮想的なコンピュータ（以下、「仮想サーバ」又は「Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＶＭ）」とよぶ）を構築する技術である。そして、複数の仮想サーバ上では、それぞれに異なるＯＳやＡＰを動作させることができる。ＶＭ単位でバックアップを行う場合には、ＡＰ同様にＶＭの静止化機能を使用してバックアップを行う。そのため、サーバ仮想化技術を用いてＶＭのバックアップを取得するとＶＭ上に存在するＡＰのデータをＡＰ特有のバックアップソフトを使用することなくバックアップすることができる。

米国特許第７３７０２３３号明細書

「Ｕｎｄｅｒｓｔａｎｄｉｎｇ ＶＭｗａｒｅ Ｃｏｎｓｏｌｉｄａｔｅｄ Ｂａｃｋｕｐ」、ＶＭｗａｒｅ、２００７年

従来技術のようにＶＭ単位でバックアップを行う場合には、ＶＭ上のＡＰは静止化されていないため、ＡＰに関するトランザクション処理が途中の状態でバックアップされる場合がある。その場合、リカバリ時にＡＰの回復処理（例えば、ロールバック）によりトランザクション処理のやり直し等が発生し、ＶＭのバックアップ時刻とＡＰのリカバリ時刻が異なることがある。

これまでユーザはバックアップカタログを参照して、戻りたい時刻のデータを示すことで、ＡＰのリカバリを行っていた。しかし、ＡＰを静止させずにＶＭ単位でバックアップする場合には、バックアップカタログを参照してもＶＭのバックアップ時刻のみしか管理できず、ＡＰのリカバリ時刻を把握することができない問題があった。よって、ユーザにとって、ＡＰのリカバリ時刻によるリカバリ管理ができないなどの、リカバリ時刻に依存した処理ができないという課題が発生する。

同様に、ＶＭ単位でバックアップを実行する場合に限らず、ＡＰを静止化せずにバックアップを実行した場合には、バックアップ開始時刻とＡＰのリカバリ時刻とが異なることがある。そのため、ユーザにとって、ＡＰのリカバリ時刻によるリカバリ管理ができないなどの、リカバリ時刻に依存した処理ができないという課題が発生する。

上記課題を解決するための計算機システムは、アプリケーションを実行する第１のホスト計算機と、第２のホスト計算機と、前記第１のホスト計算機と前記第２のホスト計算機に接続し、前記アプリケーションに割り当てられる第１のボリュームを含む複数のボリュームを形成する複数の記憶装置を有するストレージシステムと、前記第１のホスト計算機、前記第２のホスト計算機と前記ストレージシステムを管理し、前記ストレージシステムに対し第１の指示を発行し、前記第２のホスト計算機に第２の指示を発行する管理計算機と、を有し、前記ストレージシステムは、前記第１の指示に応じて、前記第１のホスト計算機の前記アプリケーションの処理の継続中に、前記第１の時間に前記第１のボリュームを第２のボリュームにバックアップし、前記第２のホスト計算機は、前記第２の指示に応じて、前記第２のボリュームのデータを読み出し、前記アプリケーションがリカバリ可能な時間である第２の時間を取得し、管理計算機は、前記バックアップと前記第２の時間との関係をバックアップカタログ情報に格納する、ことを特徴とする計算機システムである。

また、上記課題を解決するためのバックアップ方法は、アプリケーションを実行する第１のホスト計算機と、第２のホスト計算機と、前記アプリケーションに割り当てられる第１のボリュームを含む複数のボリュームを形成する複数の記憶装置を含むストレージシステムと、に接続される管理計算機によるバックアップ方法であって、前記ストレージシステムに対して、前記第１のホスト計算機の前記アプリケーションの処理の継続中に、前記第１の時間に前記ボリュームを第２のボリュームにバックアップする指示を出し、前記第２のホスト計算機より、前記第２の計算機が前記第２のボリュームのデータを読み出し、取得された前記アプリケーションがリカバリ可能な時間である第２の時間を取得し、前記バックアップと前記第２の時間との関係を管理するバックアップカタログ情報に格納する、ことを特徴とするバックアップ方法である。

ＡＰを静止化せずにバックアップしたときに、ＡＰのリカバリ可能時刻を把握することができる。

第１の実施形態における計算機システム１の構成の一例を示す図である。 本実施形態におけるバックアップスケジュール情報の一例を示す図である。 本実施形態におけるバックアップカタログ情報の一例を示す図である。 本実施形態におけるＡＰ構成情報の一例を示す図である。 本実施形態におけるストレージ管理情報の一例を示す図である。 本実施形態におけるバックアップ管理のフローチャートの一例を示す図である。 本実施形態におけるバックアップ条件設定処理のフローチャートの一例を示す図である。 本実施形態におけるバックアップ条件の設定画面の一例を示す図である。 本実施形態におけるバックアップ処理のフローチャートの一例を示す図である。 本実施形態における事前リカバリ処理のフローチャートの一例を示す図である。 本実施形態におけるＲＰＯ補正処理のフローチャートの一例を示す図である。 本実施形態におけるリカバリ処理のフローチャートの一例を示す図である。 本実施形態におけるリカバリの設定画面の一例を示す図である。 第２の実施形態における計算機システムの構成の一例を示す図である。 第２の実施形態におけるバックアップ処理のフローチャートの一例を示す図である。 第３の実施形態における計算機システムの構成の一例を示す図である。 第３の実施形態におけるバックアップスケジュール情報の一例を示す図である。 第３の実施形態におけるバックアップカタログ情報の一例を示す図である。 第３の実施形態におけるＡＰ構成情報の一例を示す図である。 第３の実施形態におけるバックアップ条件設定処理のフローチャートの一例を示す図である。 第３の実施形態におけるバックアップ処理のフローチャートの一例を示す図である。 第３の実施形態における事前リカバリ処理のフローチャートの一例を示す図である。 第４の実施形態におけるバックアップ条件設定処理のフローチャートの一例を示す図である。 第４の実施形態におけるバックアップ処理のフローチャートの一例を示す図である。 第５の実施形態における代替用ホスト計算機情報の一例を示す図である。

以下、図面を参照しつつ実施の形態について説明する。
＜＜第1の実施形態＞＞
まず、本発明の第1の実施形態について、図1を用いて説明する。

図１は、本発明の第１の実施形態に係る計算機システムの構成を示す図の一例である。

第１の実施形態の計算機システム１は、ストレージシステム１１０と、ホスト計算機（業務サーバ）１３０と、代替用ホスト計算機１４０と、管理計算機１５０にて構成される。第１の実施形態では、ストレージシステム１１０に加えて、ストレージシステム１２５がホスト計算機（業務サーバ）１３０、代替用ホスト計算機１４０、管理計算機１５０に接続されている。しかし、計算機システム１は、該ストレージシステムの構成に限定されるものではない。計算機システム１は、少なくとも１つ以上のストレージシステムにより構成されていればよい。さらに、第１の実施形態の計算機システム１は、ホスト計算機１３０と管理計算機１５０とを別々の計算機により構成する。しかし、この構成に限定されるものではなく、ホスト計算機１３０と管理計算機１５０とを同一の計算機に同様の機能を搭載する構成としてもよい。ストレージシステム１１０と、ホスト計算機１３０と、代替用ホスト計算機１４０と、管理計算機１５０は、各々のネットワークインターフェイス（以下、Ｉ／Ｆ）（ストレージシステム１１０のＩ／Ｆ１１５、ホスト計算機１３０のＩ／Ｆ１３３、代替用ホスト計算機１４０のＩ／Ｆ１４３、管理計算機１５０のＩ／Ｆ１５５）から、例えばＬＡＮなどのネットワークを介して接続される。

ストレージシステム１１０は、データを格納するストレージ装置１１１と、ストレージシステム１１０を制御するコントローラ１１２とを含む。ストレージ装置１１１は、ストレージＩ／Ｆ１１８を介して、コントローラ１１２と接続する。

ストレージ装置１１１は、少なくとも１以上の記憶装置１１４を含む。記憶装置１１４は典型的にはハードディスクドライブであるが、これに限定されるものではなく、フラッシュメモリなど他の記憶メディアであってもよい。記憶装置は、計算機（例えば、ホスト計算機１３０）によって読み書きされるデータを格納する物理的な記憶領域を有する。ボリューム１１３は、物理的な記憶領域を割り当てられた論理的な記憶領域であって、ホスト計算機に提供される（ホスト計算機が認識可能な）記録領域である。例えば、複数台の記憶装置によりＲＡＩＤグループを構成し、ＲＡＩＤグループに含まれる記憶領域を割り当てて、ボリューム１１３を実現してもよいが、これに限定されるものではない。また、本実施例では、このボリュームには、ホスト計算機１３０上のAP１３４で使用されているデータなどが格納されている。

コントローラ１１２は、データの読み書きに関するＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）リクエストを発行するホスト計算機１３０やストレージシステムを管理する管理計算機１５０などに接続するＩ／Ｆ１１５と、メモリ１１７と、Ｉ／Ｏリクエストを制御するＣＰＵ１１６と、ストレージ装置１１１に接続され通信を行うためのストレージＩ／Ｆ１１８と、を含む。ここで、Ｉ／Ｏリクエストとは、読み出し要求と、書き込み要求を含み、書き込み要求には書き込みデータを含むものとする。本実施形態においては、Ｉ／Ｆ１１５は、１台のＩ／Ｆにより構成されている。しかし、Ｉ／Ｆ１１５は、通信形態（例えば管理計算機１５０との通信がＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ホスト計算機１３０との通信がＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ））ごとに別々に配置してもよい。また、同じ通信形態であっても、管理計算機１５０と接続し通信するＩ／Ｆと、ホスト計算機１３０と接続し通信するＩ／Ｆとを別々に配置してもよい。メモリ１１７には、ストレージマイクロプログラム１１９と、ストレージマイクロプログラム１１９が管理するストレージ管理情報１２０が格納される。ＣＰＵ１１６は、メモリ１１７に格納されたプログラムを実行するプロセッサである。ＣＰＵ１１６は、ストレージマイクロプログラム１１９を読み出して実行し、ストレージ装置１１１の構成を管理する。例えば、ボリューム１１３に格納されるデータを他のボリュームにコピーをする機能や、論理的な記憶領域であるボリューム１１３をＩ／Ｆ１１５経由でホスト計算機１３０に認識させる機能などを実現する。ストレージ管理情報１２０は、ストレージのシステム構成情報など、ストレージマイクロプログラム１１９が利用する情報などであり、例えばテーブルなどで管理される。ストレージ管理情報１２０の一例を、図５にて説明する。

ホスト計算機１３０は、ストレージシステム１１０の論理的な記憶領域であるボリューム１１３を認識することができ、該ボリュームに対してＩ／Ｆ１３３を介してＩ／Ｏリクエスト発行する。ホスト計算機１３０は、ＣＰＵ１３１、メモリ１３２、Ｉ／Ｆ１３３、及びキャッシュ１３８を含む。ＣＰＵ１３１は、メモリ１３２に格納されたプログラムを実行するプロセッサである。メモリ１３２には、アプリケーション（以下、ＡＰ）１３４、オペレーティングシステム（以下、ＯＳ）１３５、ＯＳ静止化プログラム１３６、エージェント１３７が格納される。ＡＰ１３４は、ホスト計算機１３０上で動作し、業務を実行するプログラムである。メモリ１３２には、少なくとも１つ以上のＡＰ１３４が格納される。ＯＳ１３５は、ホスト計算機１３０上で動作する計算機全体を管理する基本ソフトウェアである。ＯＳ静止化プログラム１３６は、ＯＳの静止化を行うプログラムである。ＯＳの静止化とは、該当ＯＳに関連する新規トランザクションの受付けを停止してから、メモリ内の更新情報をディスクに強制出力する処理である。この処理を行うことによって、ＯＳの整合性を保つことができる。エージェント１３７は、ホスト計算機１３０上のＡＰの構成とＡＰが使用しているボリュームを特定し管理計算機へ通知する機能を持つ。Ｉ／Ｆ１３３は、ネットワークを介してストレージシステム１１０と、後述する代替用ホスト計算機１４０、及び管理計算機１５０に接続される。Ｉ／Ｆ１３３は、通信形態（例えば管理計算機１５０や代替用ホスト計算機１４０との通信はＴＣＰ／ＩＰ、ストレージシステム１１０との通信はＦＣ）ごとに別々に配置してもよい。また、同じ通信形態であっても、管理計算機１５０と接続し通信するＩ／Ｆと、代替用ホスト計算機１４０と接続し通信するＩ／Ｆと、ストレージシステム１１０と接続し通信するＩ／Ｆと、を別々に配置してもよい。キャッシュ１３８は、メモリ１３２上のAP１３４のデータを変更されたときストレージシステム１１０のボリューム１１３にデータを格納する前に、一時保存しておく記憶領域である。

代替用ホスト計算機１４０は、ホスト計算機１３０のＡＰにより使用されストレージシステム１１０のボリュームに格納されるデータをバックアップした後に、リカバリして検証するための計算機である。代替用ホスト計算機１４０は、ＣＰＵ１４１、メモリ１４２、及びＩ／Ｆ１４３を備える。ＣＰＵ１４１は、メモリ１４２に格納されたプログラムを実行するプロセッサである。メモリ１４２には、ホスト計算機１３０のメモリ１３２に格納されるＡＰ１３４やＯＳ１３５に対応し、同じ種類のＡＰ１４４とＯＳ１４５が格納される。したがって、代替用ホスト計算機１４０は、ホスト計算機１３０と同様のＡＰ及びＯＳの条件を提供することができる。メモリ１４２には、バックアップデータをリカバリする際に、ＡＰの回復処理を行うＡＰ回復処理プログラム１４６と、ＡＰの最終更新時刻を確認するＡＰ時刻確認プログラム１４７が格納される。

管理計算機１５０は、ＣＰＵ１５１、メモリ１５２、入力装置１５３、表示装置１５４、及びＩ／Ｆ１５５を含む。入力装置１５３は、ユーザ（管理者）がデータを入力するための装置であり、例えば、キーボードやマウス等である。表示装置１５４は、ユーザに対してバックアップ条件設定画面（図８）やリカバリ設定画面（図１３）などを表示する画面であり、例えば、ＣＲＴ等の画面表示装置である。ＣＰＵ１５１は、メモリ１５２に格納されたプログラムを実行するプロセッサである。メモリ１５２には、バックアッププログラム１５６、リカバリプログラム１５７、ＲＰＯ補正プログラム１５８、バックアップスケジュール情報１５９、バックアップカタログ情報１６０、およびＡＰ構成情報１６１が格納される。

バックアッププログラム１５６は、ＡＰ１３４により使用されるボリューム１１３を副ボリュームにバックアップし、バックアップカタログ情報などを作成するプログラムである。リカバリプログラム１５７は、代替用ホスト計算機１４０上のＡＰ回復処理プログラムを使用して、ＡＰ１３４によって使用されるボリューム１１３に格納されるデータのバックアップデータをリカバリするプログラムである。ＲＰＯ補正プログラムは、代替用ホスト計算機１４０上のＡＰ時刻確認プログラムを使用して、設定されているＲＰＯを修正するプログラムである。なお、これらのプログラムの動作は、フローチャートなどを用いて以下に詳述する。

次に、本実施形態において参照される各情報について説明する。

図２に、管理計算機１５０のメモリ１５２に格納されるバックアップスケジュール情報１５９の一例を示す。なお、図２に記載のバックアップスケジュール情報１５９のフォーマットは一例であって、図２に示したフォーマットに限定されるものではない。バックアップスケジュール情報１５９は、管理計算機１５０で実行されるバックアッププログラム１５６などによって参照される。

バックアップスケジュール情報１５９には、スケジュールＩＤ１５９０１、バックアップ開始時刻１５９０２、ＯＳＩＤ１５９０３、コピーペアＩＤ１５９０４が格納される。スケジュールＩＤ１５９０１には、各バックアップスケジュールを識別する情報（例えば、識別子）が格納される。バックアップ開始時刻１５９０２には、バックアップの開始時間が格納される。ＯＳＩＤ１５９０３には、バックアップ対象ボリュームを使用するＯＳを識別する情報（例えば、識別子）が格納される。コピーペアＩＤ１５９０４には、正副ボリュームのコピーペアを識別する情報（例えば、識別子）が格納される。コピーペアＩＤを用いて、ストレージ管理情報１２０（図５）に含まれるコピーペア情報１２０２を参照することにより、コピーペアで使用されている正副ボリュームＩＤを取得することができる。

図３に、管理計算機１５０のメモリ１５２に格納されるバックアップカタログ情報１６０の一例を示す。なお、図３に記載のバックアップカタログ情報１６０のフォーマットは一例であって、図３に示したフォーマットに限定されるものではない。バックアップカタログ情報１６０は、管理計算機１５０で実行されるバックアッププログラム１５６、およびリカバリプログラム１５７などによって参照される。

バックアップカタログ情報１６０には、バックアップＩＤ１６００１、ＯＳＩＤ１６００２、バックアップ時刻１６００３、ＡＰＩＤ１６００４、ＡＰのリカバリ可能時刻１６００５、バックアップデータ格納ボリュームＩＤ１６００６が格納される。バックアップＩＤ１６００１には、各バックアップを識別する情報（例えば、識別子）が格納される。ＯＳＩＤ１６００２には、バックアップ対象ボリュームを使用するＯＳを識別する情報（例えば、識別子）が格納される。バックアップ開始時刻１６００３には、バックアップの開始時間が格納される。ＡＰＩＤ１６００４には、バックアップ対象ボリュームを使用するＡＰを識別する情報（例えば、識別子）が格納される。ＡＰのリカバリ可能時刻１６００５には、ホスト計算機１３０がバックアップした副ボリュームを使用してＡＰをリカバリする場合に、リカバリ可能な時間を格納する。バックアップデータ格納ボリュームＩＤ１６００６には、バックアップ対象ボリュームをバックアップしたデータを格納するボリューム（副ボリューム）を識別する情報（例えば、識別子）を格納する。

バックアップ時刻１６００３だけでなく、ＡＰのリカバリ可能時刻１６００５を管理することで、ＡＰを静止化せずにバックアップをした場合であっても、ユーザ（管理者）が、正確なＡＰのリカバリ可能時刻を把握して運用することができる。

図４に、管理計算機１５０のメモリ１５２に格納されるＡＰ構成情報１６１の一例を示す。なお、図４に記載のＡＰ構成情報１６１のフォーマットは一例であって、図４に示したフォーマットに限定されるものではない。ＡＰ構成情報１６１は、管理計算機１５０で実行されるバックアッププログラム１５６によって参照される。

ＡＰ構成情報１６１は、ＡＰＩＤ１６１０１、ホストＩＤ１６１０２、ＯＳＩＤ１６１０３、静止化プログラム有無１６１０４、ストレージＩＤ１６１０５、使用ＶＯＬＩＤ１６１０６、ＲＰＯ１６１０７、ＲＰＯ補正有無１６１０８、事前リカバリ処理優先度１６１０９、リカバリデータ保存有無１６１１０が格納される。ＡＰＩＤ１６１０１には、アプリケーションを識別する情報（例えば、識別子）が格納される。ホストＩＤ１６１０２には、ＡＰが実行されるホスト計算機を識別する情報（例えば、識別子）が格納される。ＯＳＩＤ１６１０３には、ＡＰが実行される基盤となるＯＳを識別する情報（例えば、識別子）が格納される。静止化プログラム有無１６１０４には、アプリケーションが実行される基盤となるＯＳを静止化するためのプログラムの有無を示す情報が格納される。使用ＶＯＬＩＤ１６１０６には、アプリケーションにより使用されるボリュームを識別する情報（例えば、識別子）が格納される。ＲＰＯ１６１０７には、どの時点までのデータを保証する情報であるＲＰＯが格納される。この時間が、アプリケーションにより使用されるボリュームのバックアップをとる時間間隔となる。ＲＰＯ補正有無１６１０８には、図１１に示すＲＰＯ補正処理を実行するか否かの情報が格納される。事前リカバリ処理優先度１６１０９には、複数のＡＰが同時にバックアップされた場合、事前リカバリ処理を行う順番の優先度が格納される。リカバリデータ保存有無１６１１０には、図１０に示す事前リカバリ処理を実行するか否かの情報が格納される。

ＡＰ構成情報１６１に格納される情報はホスト計算機１３０上のエージェント１３７によって取得され、管理計算機１５０のメモリ１５２に格納される。更に、図８に示す「バックアップ条件の設定」画面よりユーザが入力した情報を基に、ＲＰＯ１６１０７と、ＲＰＯ補正有無１６１０８と、事前リカバリ処理優先度１６１０９と、リカバリデータ保存有無１６１１０を格納する。これらのＲＰＯ１６１０７とＲＰＯ補正有無１６１０８と事前リカバリ処理優先度１６１０９と、リカバリデータ保存有無１６１１０は、事前に指定されてもよい。

また、ＡＰ構成情報１６１に格納される情報の取得方法は一例であって、これに限定されるものではない。

図５に、ストレージシステム１１０のメモリ１１２に格納されるストレージ管理情報１２０の一例を示す。なお、図５に記載のストレージ管理情報１２０のフォーマットは一例であって、図５に示したフォーマットに限定されるものではない。ストレージ管理情報１２０は、ストレージシステム１１０にて実行されるストレージマイクロプログラムや管理計算機１５０で実行されるバックアッププログラム１５６などによって参照される。ストレージ管理情報１２０には、ボリューム情報１２０１とコピーペア情報１２０２とが含まれる。

ボリューム情報１２０１には、ストレージ装置ＩＤ１２０１１、ボリュームＩＤ１２０１２、使用可否１２０１３により構成される。ストレージ装置ＩＤ１２０１１には、ストレージ装置１１１を識別する情報（例えば、識別子）が格納される。ボリュームＩＤ１２０１２は、ストレージ装置１１１に含まれるボリュームを識別する情報（以下、識別子）が格納される。使用可否１２０１３には、ボリュームが使用可能であるか否かを示す情報が格納される。使用可否１２０１３では、例えば何にも使われていない、すなわち現在いずれのＡＰによっても使用されていないボリュームに対しては、「可」を示す情報を格納する。未使用のボリュームだけでなく、使用履歴があっても現在は使用されていないボリュームも含まれる。「可」を示す情報が格納されるボリュームは、新しくコピーペア構築が指示されたときの副ボリュームとして使用することができる。

コピーペア情報１２０２には、コピーペアＩＤ１２０２１、正ストレージ装置ＩＤ１２０２２、正ＶＯＬＩＤ１２０２３、副ストレージ装置ＩＤ１２０２４、副ＶＯＬＩＤ１２０２５、コピー種別１２０２６とが含まれる。コピーペアＩＤ１２０２１には、正副ボリュームのコピーペアを識別する情報（例えば、識別子）が格納される。正ストレージ装置ＩＤ１２０２２には、コピーペアにおける正ストレージ装置を識別する情報（例えば、識別子）が格納される。正ＶＯＬＩＤ１２０２３には、コピーペアにおける正ボリュームを識別する情報（例えば、識別子）が格納される。副ストレージ装置ＩＤ１２０２４には、コピーペアにおける副ストレージ装置を識別する情報（例えば、識別子）が格納される。副ＶＯＬＩＤ１２０２５には、コピーペアにおける副ボリュームを識別する情報（例えば、識別子）が格納される。コピー種別１２０２６には、コピーペア間のコピーの種別を示す情報が格納される。
＜バックアップ管理処理＞
次に、本実施形態に係るバックアップ管理処理について図６乃至図１３を用いて説明する。

図６は、ＡＰの静止化を行わずにバックアップを取得する場合に、ＡＰのバックアップ時刻を管理する処理の一例を示すフローチャートである。ＡＰの「静止化」とは、該当ＡＰに関連する新規トランザクションの受付けを停止してから、メモリ内の更新情報をディスクに強制出力する処理である。

図６において、ステップ６０１からステップ６０７の処理は、管理計算機１５０のメモリ１５２に格納されるバックアッププログラム１５６をＣＰＵ１５１により実行することにより実現される処理である。但し、ステップ６０１からステップ６１１の各処理においては、以下に示すプログラムによる処理も含む。各メモリに格納されるプログラムの処理は、ＣＰＵがメモリから各プログラムを読み出して実行することにより実現される。以下、プログラムを主語にして説明する場合もあるが、実際にはそのプログラムを実行する処理部であるＣＰＵが該プログラムを実行し、処理を行う。

ステップ６０３では、ホスト計算機１３０のメモリ１３２に格納されるＯＳ静止化プログラム１３６によって処理される。ステップ６０５では、管理計算機１５０のメモリ１５２に格納されるリカバリプログラム１５７と、代替用ホスト計算機１４０のメモリ１４２に格納されるＡＰ回復処理プログラム１４６と、ＡＰ時刻確認プログラム１４７によって処理される。ステップ６１１では、管理計算機１５０のメモリ１５２に格納されるリカバリプログラム１５７によって処理される。ステップ６０９では、管理計算機１５０のメモリ１５２に格納されるＲＰＯ補正プログラム１５８によって処理される。

但し、具体的にどの処理ステップが、どのプログラムによって実現されるかは、システム設計上の要請等により適宜決定すれるものであり、これに限定されるものではない。

ステップ６０１のバックアップ条件設定処理では、バックアップを実行する際の条件を設定する。ステップ６０１については、図７にて詳細な動作を説明する。

ステップ６０３のバックアップ処理では、ステップ６０１にて設定されたバックアップ条件にもとづきバックアップを実行する。ステップ６０３については、図９にて詳細な動作を説明する。

ステップ６０５の事前リカバリ処理では、代替用ホスト計算機１４０を利用して、バックアップしたデータを事前にリカバリする。そして、ＡＰのリカバリ可能時刻を確認し、バックアップカタログ情報１６０を修正する。ステップ６０５については、図１０にて詳細な動作を説明する。

ステップ６０７のリカバリ処理では、ユーザによって指定されたバックアップＩＤを参照し、バックアップデータをリカバリする。ステップ６０７については、図１２にて詳細な動作を説明する。
＜バックアップ条件設定処理＞
図７に、バックアップ時に使用するバックアップ条件の設定処理（条件設定処理）フローの一例を示す。バックアッププログラム１５６は、ユーザからのバックアップの要求を受けて、バックアップ条件の設定画面を表示し、処理を開始する。

ステップ７０１では、バックアッププログラム１５６は、バックアップ条件の設定画面から、ユーザによって入力されたＡＰＩＤ、コピー種別、ＲＰＯなどの情報を取得する。そして、取得した情報に基づき、ＡＰ構成情報１６１を修正する。

バックアップ条件の設定画面の一例を図８に示す。なお、図８に記載のバックアップ条件の設定画面のフォーマットは一例であって、図８に示したフォーマットに限定されるものではない。バックアップ条件の設定画面は、バックアップ対象とする「ＡＰＩＤ」（ＡＰを識別する情報）を指定する項目８０１と、バックアップポリシーを入力する項目８０２と、設定ボタン８０８と、バックアップ条件設定を中止するキャンセルボタン８０９を含む。

バックアップ対象とする「ＡＰＩＤ」（ＡＰを識別する情報）を指定する項目８０１には、ユーザがバックアップ対象とするＡＰＩＤを選択する。実際には、バックアップ対象のＡＰにより使用されるボリュームをバックアップすることとなる。バックアップポリシー８０２には、コピー種別８０３と、ＲＰＯ８０４と、ＲＰＯ補正処理有無８０５と、事前リカバリ処理優先度８０６と、事前リカバリデータ保存処理有無８０７の各項目を含む。コピー種別８０３には、「フルコピー」や「差分コピー」などのコピー種別を入力する。ＲＰＯ８０４には、ＡＰＩＤ８０１で指定されたＡＰのＲＰＯを入力する。ＲＰＯ補正処理有無８０５には、図１１に示すＲＰＯの補正処理を行うか否かを入力する。事前リカバリ処理優先度８０６には、複数のＡＰが同時にバックアップされた場合、事前リカバリ処理を行う順番の優先度を入力する。事前リカバリデータ８０７では、図１０において事前リカバリ処理のデータの保存の有無を入力する。

図８のバックアップ条件の設定画面の例では、「ＡＰ＿０２が使用するボリュームを１０分間隔でフルコピーのバックアップを行い、ＲＰＯ補正処理も行う。事前リカバリ処理優先度は２である。事前リカバリ処理でリカバリした状態のデータを保存する。」と、条件が設定される。そして、図４のＡＰ構成情報１６１のAPＩＤ１６１０１のＡＰ＿０２を参照し、条件の変更がある場合には、ＲＰＯ１６１０７と、ＲＰＯ補正有無１６１０８、事前リカバリ処理優先度１６１０９と、リカバリデータ保存有無１６１１０項目を修正する。

ステップ７０３では、バックアッププログラム１５６が、ＡＰ構成情報１６１を使用して、ステップ７０１で取得したＡＰＩＤに対応するＡＰＩＤを検索する。そして、ＡＰ構成情報１６１の使用ＶＯＬＩＤ１６１０６を参照し、検索されたＡＰＩＤによって使用されるボリュームを特定する。図８のようにバックアップ条件の設定画面によりＡＰ＿０２が指定された場合には、ＡＰ構成情報１６１のＡＰＩＤ１６１０１及び対応する使用ＶＯＬＩＤ１６１０６を参照し、ＡＰ＿０２により使用されるボリュームはＶＯＬ＿０２であると特定される。

ステップ７０５では、ストレージシステム１１０のストレージマイクロプログラム１１９が、コピーペアの構築を行う。このペアの構築では、ストレージマイクロプログラム１１９がペア機能を操作するための設定ファイルを作成する。具体的には、ストレージマイクロプログラム１１９が、ステップ７０３で特定されたＡＰにより使用されるボリュームを正ボリューム（バックアップ元ボリューム）とし、図５のボリューム情報１２０１の使用可否１２０１３から「可」のボリュームを検索し、検索されたボリュームを副ボリューム（バックアップ先ボリューム）とする。ここで、副ボリュームはユーザにより指定されてもよい。そして、コピーペア情報１２０２に、ストレージマイクロプログラム１１９によって構築された新規コピーペアの情報を追加する。さらに、副ボリュームとして設定されたボリュームに関して、ボリューム情報１２０１の使用可否１２０１３の情報を「否」とする。図８の例では、コピーペア情報１２０２に例えばＰＡＩＲ＿０４を追加する。さらに、ボリューム情報１２０１のボリュームＩＤ１２０１２のＶｏｌ＿０６の使用可否１２０１３を「可」から「否」へ変更する。

正ボリュームと副ボリュームのコピーペアが構築されると、ホスト計算機１３０のＡＰにより正ボリューム内のデータに書き込み処理などが実行され、正ボリューム内のデータに更新があった時に、正ボリュームの変更されたデータが副ボリュームにコピーされる。

ステップ７０７、バックアッププログラム１５６がコピーペアの情報を取得し、バックアップスケジュール情報１５９に、新規スケジュールを追加する。図８の例では、バックアップスケジュール情報１５９のスケジュールＩＤ１５９０１に、ＳＣ＿０４を新規スケジュールとして追加する。ＯＳＩＤ１５９０３には、バックアップ条件の設定画面において指定されたＡＰの基盤となるＯＳを、ＡＰ構成情報１６１のＯＳＩＤ１６１０３を参照して特定し、ＯＳ＿０２を示す情報を格納する。コピーペアＩＤ１５９０４には、ステップ７０５にて新たに追加されたＰＡＩＲとして特定された、ＰＡＩＲ＿０４を示す情報を格納する。
＜バックアップ処理＞
図９に、本実施形態におけるバックアップ処理フローの一例を示す。ステップ６０１で設定したバックアップ条件にそって、バックアッププログラム１５６がバックアップの処理を行う。各バックアップ処理は、バックアップスケジュール情報１５９のバックアップ開始時刻１５９０１になると、実行される。但し、オンデマンドで実行してもよい。

ステップ９０１では、バックアッププログラム１５６は、バックアップ対象のＡＰが動作するＯＳを確認する。具体的には、図２のバックアップスケジュール情報１５９からＯＳＩＤ１５９０３よりＯＳを特定する。

ステップ９０３では、特定されたＯＳに、ＯＳ静止化プログラム１３６が存在するか否かを確認する。具体的には、バックアッププログラム１５６が、ＡＰ構成情報１６１の静止化プログラム有無１６１０４を参照して確認する。ＯＳ静止化プログラムが存在する場合（ステップ９０３がＹＥＳの場合）はステップ９０５へ進む。ＯＳ静止化プログラムが存在しない場合（ステップ９０３がＮＯの場合）は、ステップ９０７へ進む。

ステップ９０５では、ステップ９０１で特定したＯＳに対してＯＳ静止化プログラム１３６を使用して静止化を行う。

ステップ９０７では、ストレージマイクロプログラム１１９により、バックアップスケジュール情報２００のコピーペアＩＤ２０４が示すコピーペアのスプリットを行う。スプリットとは、コピーペアが構築され正ボリュームのデータ変更を副ボリュームへコピーする処理の実行を停止することを示す。コピー機能は、ＡＰが利用しているストレージの記録領域にデータの書き込みが発生したとき、同じデータを同ストレージ内の他記録領域へ書き込む。そうすることで、常に同じデータが格納されている領域を作成することができる。そのため、スプリットを行うと、スプリットされた時点での正ボリュームのデータをバックアップデータとして副ボリュームに保存することができ、コピー先の記録領域にその時点のバックアップのデータが作成できたことなる。

ここで、コピーペアのスプリット前には、ＡＰの「静止化」は実行されない。ＡＰを「静止化」しないことにより、ＡＰごとの静止化プログラムを保持する必要がない。また、コピーペアスプリット時に、ＡＰの静止化を実行する必要がないため、ＡＰによる業務を継続して実行できる。

ステップ９０９では、バックアップデータが保存されたボリュームである副ボリュームに関する情報などを、図３のバックアップカタログ情報１６０に追加する。具体的には、バックアップカタログ情報１６０に、バックアップＩＤ１６００１と、ＯＳＩＤ１６００２、バックアップ時刻１６００３と、ＡＰＩＤ１６００４、バックアップデータ格納ボリュームＩＤ１６００６を追加する。

例えば、バックアップスケジュール情報１５９より、スケジュールＩＤ１５９０１のＳＣ＿０１が、２００８/１２/０４の１２:００:００に開始されたとする。ステップ９０３にてＯＳ静止化プログラムが存在する場合、ステップ９０５にてＯＳＩＤ１５９０３からＯＳ＿０１を静止化する。ステップ９０７では、コピーペアＩＤ１５９０４からＰＡＩＲ＿０１の正ボリュームと副ボリュームとをスプリットする。スプリット終了後、バックアップカタログ情報１６０に、新規バックアップＩＤ１６００１としてＢＫ＿０１を追加し、ＯＳＩＤ１６００２にＯＳ＿０１、バックアップ時刻１６００３に２００８/１２/０４の１２:００:００、ＡＰＩＤにＡＰ＿０１、バックアップ格納ボリュームＩＤ１６００６にコピーペア情報５２０のＰＡＩＲ＿０１から特定したＶｏｌ＿０３を格納する。

ステップ９１１では、ステップ９０５にて、ＯＳが静止化されているか否かを判断する。ＯＳが静止化されている場合（ステップ９１１がＹＥＳの場合）はステップ９１３へ、静止化されていない場合（ステップ９１１がＮＯの場合）はバックアップ処理を終了する。

ステップ９１３では、ＯＳの静止化の解除を行う。この処理を行うことで、ステップ９０５にて停止していたトランザクションの受付を開始させる。
＜事前リカバリ処理＞
図１０に、本実施形態における事前リカバリ処理フローの一例を示す。ステップ６０３でバックアップした副ボリュームのデータを代替用ホスト計算機１４０のＡＰ１４４を用いて実行して、ＡＰの検証を実行する。事前リカバリ処理は、バックアッププログラム１５６が、バックアップ処理が終了したことを検出した後に、リカバリプログラム１５７に事前リカバリ処理を行うことを指示することによって開始される。

ステップ１００１にて、リカバリプログラム１５７は、バックアップカタログ情報１６０のバックアップ格納ボリュームＩＤ１６００６から特定した副ボリュームを代替用ホスト計算機１４０にマウントする。「副ボリュームを代替用ホスト計算機にマウントする」とは、代替用ホスト計算機から副ボリュームを認識可能な状態とすることを意味する。

ステップ１００３にて、リカバリプログラム１５７により、マウントした副ボリュームのデータを参照してＡＰ１４４を実行し、ＡＰを再開する。

ステップ１００５では、ＡＰの回復処理が発生するか否かを判断する。本実施形態では、ＡＰの使用するボリュームをバックアップする場合に、ＡＰの業務を止めないで行うため、ＡＰを静止化せずにバックアップする。したがって、ＡＰの回復処理が発生する場合がある。ＡＰの回復処理が発生するか否かについては、ＡＰが、ＡＰの回復処理の発生有無をＡＰのログで判断する。ＡＰのログには、ＡＰの履歴とＡＰにより書き出されたデータの情報が記載されている。発生した場合（ステップ１００５ＹＥＳの場合）ステップ１００７の処理を実行する。発生しない場合は（ステップ１００５ＮＯの場合）、ステップ１０２９の処理を実行する。

ステップ１００７では、管理計算機１５０のリカバリプログラム１５７より指示を受けた、代替用ホスト計算機１４０のＡＰ回復処理プログラム１４６が、クラッシュリカバリやロールバックなどのＡＰの回復処理を行う。ＡＰ回復処理とは、アプリケーションが、データの変更履歴を保存している場合に、この履歴を用いて整合性が保たれた状態まで修復する処理である。

ステップ１００９では、ＡＰの回復処理が成功したか否かの判定を行う。例えば、ＡＰの回復処理が成功したか否かの判定するために、ＡＰのログを確認する。ＡＰ回復処理プログラム１４６がＡＰを回復できなかった場合（ステップ１００９：ＮＯの場合）は、ステップ１０１１を実行する。ＡＰ回復処理プログラム１４６によりＡＰを回復できた場合（ステップ１００９：ＹＥＳの場合）は、ステップ１０１７を実行する。

まず、ステップ１００９でＡＰを回復できたと判断した場合（ステップ１００９：ＹＥＳの場合）の処理について説明する。

ステップ１０１７では、バックアッププログラム１５６から代替用ホスト計算機１４０上のＡＰ時刻確認プログラム１４７に指示を出し、クラッシュリカバリやロールバックなどのＡＰの回復処理により回復することのできた時刻（リカバリ可能時刻）を取得する。

ステップ１０１９では、バックアッププログラム１５６により、ステップ１０１７にて取得したリカバリ可能時刻を、バックアップカタログ情報１５９のＡＰリカバリ可能時刻１６００５に更新する。例えば、バックアップＩＤ１６００１のＢＫ＿０１の場合、ＡＰのリカバリ可能時刻１６００５に２００８/１２/０４ １１:５８を記載する。バックアップを開始する時刻とは別にＡＰのリカバリ可能な時刻を管理することで、ＡＰのリカバリ時刻によるリカバリ管理ができる。

ステップ１０２１では、ステップ１０１７で取得したＡＰのリカバリ可能時刻と、リカバリ対象のＡＰが使用するボリュームを前回（過去）バックアップしたときのＡＰのリカバリ可能時刻を比較する。具体的には、バックアップカタログ情報のＢＫ＿０５の事前リカバリ処理をする場合には、同じＡＰが使用する、同じボリュームのバックアップであるＢＫ＿０１を参照し、ＢＫ＿０５のリカバリ可能時刻とＢＫ＿０１のリカバリ可能時刻を比較する。一致する場合（ステップ１０２１：ＹＥＳの場合）はステップ１０２３を実行する。一致しない場合（ステップ１０２１：ＮＯの場合）は１０２５を実行する。

ステップ１０２３では、リカバリプログラム１５７が、ＲＰＯの時間内にチェックポイントが発生するように、チェックポイントの時間間隔の修正を通知する。アプリケーションのデータに変更があった場合、キャッシュ１３８にデータを一時保存して、チェックポイントでボリュームに格納している。そのため、チェックポイントでは、コミットされた全ての処理がボリュームに反映されていることを保証する。ＡＰの回復処理の結果ＡＰのデータが前回のバックアップした時刻と同じ時刻に戻ってしまった原因として、ユーザが指定したＲＰＯの時間内に処理がデータファイルに反映されていないためと考えられる。チャックポイント間隔の修正により、ＲＰＯの時間内で、ＡＰにより使用されるボリュームのバックアップを格納することができる。なお、ステップ１０２１及びステップ１０２３は行わなくてもよい。

チェックポイントの時間間隔の修正を通知する代わりに、バックアプデータが前回と同じためＲＰＯを長めに修正したほうがよいことを通知してもよい。

ステップ１０２５では、ＡＰのＲＰＯを補正するか否かを判断する。具体的には、ＡＰ構成テーブル１６１のＲＰＯ補正有無１６１０８を確認し、「有」を示す情報が格納される場合にはＹＥＳと判断し、「無」を示す情報が格納される場合にはＮＯと判断する。ＡＰのＲＰＯ補正処理を行う場合（ステップ１０２５：ＹＥＳの場合）は、ステップ１０２７を実行する。ＡＰのＲＰＯ補正処理を行わない場合（ステップ１０２５：ＮＯの場合）は、ステップ１０２９を実行する。

ステップ１０２７では、事前リカバリ処理（ステップ６０５）で確認したＡＰのリカバリ可能時刻と、ユーザによって指定されたＡＰのＲＰＯから、次にバックアップを開始する時刻を算出して、バックアップスケジュール情報１５９を修正する。ステップ１０２７については、図１１にて詳細な動作を説明する。

ステップ１０２７では、図１１のＲＰＯ補正処理のステップ１１０１へ進む。ＲＰＯ補正処理は、管理計算機１５０のＲＰＯ補正プログラム１５８によって実行される。

ステップ１１０１では、ＡＰ構成情報１６１を参照して、バックアップしたボリュームを使用するすべてのＡＰを検索する。そして、バックアップカタログ情報１６０を参照して、検索されたＡＰのリカバリ可能時刻を取得する。

ステップ１１０３では、ステップ１１０１で取得した各ＡＰのリカバリ可能時刻に対して、ＡＰ構成情報１６１のＲＰＯ１６１０７から特定されるＲＰＯを加算した時刻を算出する。

ステップ１１０５では、ステップ１１０３に算出した次回のバックアップ開始時刻のうち、もっとも早い時刻を選択する。そして、選択された時刻を次のバックアップ開始時刻として、バックアップスケジュール情報１５９のバックアップ開始時刻２０２に格納する。ＲＰＯ補正処理により、ＡＰに回復処理が発生して、リカバリ可能時刻が古くなった場合にも、バックアップ開始時刻を早めることで、ＲＰＯを守ることができる。

例えば、図４のＡＰ構成情報１６１の使用ＶＯＬＩＤ１６１０６からＶＯＬ＿０２上に、ＡＰＩＤ１６１０１のＡＰ＿０２，ＡＰ＿０３，ＡＰ＿０４の３つのＡＰに使用されるデータが格納されることがわかる。また、ＲＰＯ補正有無１６１０８から、ＡＰ＿０２とＡＰ＿０４の２つのＡＰについてＲＰＯの補正処理が必要であることがわかる。

そして、バックアップカタログ情報１６０のＡＰのリカバリ可能時刻１６００５に、ＡＰ構成情報１６１のＲＰＯ１６１０７を加算する。この場合、ＡＰ＿０２は、２００８:／１２／０４ １２:１９プラス１０分で２００８:／１２／０４ １２:２９、ＡＰ＿０４は２００８:／１２／０４ １２:１６プラス２０分で２００８:／１２／０４ １２:３６になる。両者を比較すると、最も早い時刻は、２００８:／１２／０４ １２:２９となる。そこで、スケジュールＩＤ１５９０２のＳＣ_０５のバックアップ開始時刻１５９０２を１２:３０から１２:２９に修正する。修正後、図１０の事前リカバリ処理のステップ１０２７に戻り、ステップ１０２９へ進む。

ステップ１０２９では、ステップ１００７でＡＰを回復した状態（事前リカバリした状態）を保存するかどうかを判断する。具体的には、ＡＰ構成情報１６１のリカバリデータ保存有無１６１０８を参照し、「有」の場合にはＹＥＳ、「無」の場合にはＮＯと判断する。ＡＰを回復した状態を保存する場合（ステップ１０２９：ＹＥＳの場合）には、ステップ１０３１を実行する。ＡＰを回復した状態を保存しない場合（ステップ１０２９：ＮＯの場合）には、ステップ１０３３を実行する。

ステップ１０３１では、リカバリプログラム１５７は、ＡＰを回復した状態を例えばボリューム情報５１０より使用可否５１３が「可」のボリュームに保存する。ＡＰを回復した状態を保存することにより、実際のリカバリ処理を行うときに回復処理を行う必要がないため、高速に復旧することができる。

次に、ステップ１００９でＡＰが回復できないと判断された場合（ステップ１００９：ＮＯの場合）の処理について説明する。ＡＰが回復できなかいため、バックアップ処理は失敗である。

ステップ１０１１では、ステップ９０９で追加したバックアップカタログ情報１６０のデータを削除する。さらに、バックアップデータが格納される副ボリュームのデータも同時に削除してもよい。バックアップカタログ情報１６０よりデータを削除することにより、ユーザは該バックアップのリカバリを選択できなくすることができる。そして、ＡＰの回復ができないボリュームを誤って選択してしまうことを防止できる。また、リカバリできないボリュームは以後使用することができないため、格納されているデータを削除することで、ボリュームの領域を有効に活用することができる。

ステップ１０１３では、ＡＰのＲＰＯを補正するか否かを判断する。具体的には、ＡＰ構成テーブル１６１のＲＰＯ補正有無１６１０８を確認し、「有」を示す情報が格納される場合にはＹＥＳと判断し、「無」を示す情報が格納される場合にはＮＯと判断する。ＡＰのＲＰＯ補正処理を行う場合（ステップ１０１３：ＹＥＳの場合）は、ステップ１０１５へ進む。既に、この時点でＲＰＯが保証されていないが、少しでもリカバリ可能時刻をＲＰＯに近づけるために、ステップ１０１５では、バックアップ処理を再開させる。よって、バックアップ処理（ステップ９０１）へ戻る。ＡＰのＲＰＯ補正処理を行わない場合（ステップ１０１３：ＮＯの場合）は、ステップ１０３３へ進む。

ステップ１０３３では、バックアップ終了を通知し、バックアップ処理を終了する。

ここで、同時にバックアップ処理が終了したボリュームが複数存在する場合、ＡＰ構成情報１６１の事前リカバリ処理優先度１６１０９を参照し、優先度の高い順に事前リカバリ処理を実行してもよい。ただし、優先度を設定せずに順に処理してもよい。例えば、図４の例では、事前リカバリ処理優先度４０９が、ＡＰ＿０１では１で、ＡＰ＿０２では２である。ＡＰ＿０１とＡＰ＿０２が同時にバックアップ終了した場合、事前リカバリ処理優先度４０９が高いＡＰ＿０１が先に事前リカバリ処理を行う。優先度を用いて処理を行うことにより、ユーザにより設定された重要度が高いボリュームについて優先的に事前リカバリ処理を行うことができる。
＜リカバリ処理＞
図１２に、本実施形態における、リカバリ処理フローの一例を示す。ユーザが、例えば図１３に示すリカバリ設定画面に入力するなどして、副ボリュームを利用したＡＰのリカバリを要求した場合、管理計算機１５０のリカバリプログラム１５７によりリカバリ処理を開始する。

ステップ１２０１では、リカバリ設定画面に、リカバリするＡＰＩＤを入力してもらうことで、リカバリプログラム１５７はＡＰの情報を取得する。

ステップ１２０３では、バックアップカタログ情報１６０のＡＰＩＤ３０４から、指定されたＡＰと一致するバックアップＩＤを検索し、一致したものをバックアップカタログリストとして表示する。

ここで、本実施形態における、リカバリ設定画面の一例を図１３に示す。なお、図１３に記載のリカバリ設定画面のフォーマットは一例であって、図１３に示したフォーマットに限定されるものではない。図１３の画面は、リカバリ対象とするＡＰＩＤを指定する項目１３０１と、バックアップカタログリスト１３０２と、リカバリボタン１３０６と、リカバリ処理を中止するキャンセルボタン１３０７を含む。

リカバリ対象とするＡＰＩＤを指定する項目１３０１には、ユーザがリカバリしたいＡＰを識別する情報を入力する。バックアップカタログリスト１３０２には、リカバリ可能なバックアップＩＤ１３０４と、そのＡＰのリカバリ可能時刻１３０５と、事前リカバリデータ有無１３０６と、リカバリするバックアップカタログを選択するためのチェック項目１３０３とを含む。バックアップカタログリスト１３０２は、リカバリプログラム１５７より、バックアップカタログ情報１６０とＡＰ構成情報１６１を参照して作成される。図１３の例では、リカバリ対象のＡＰＩＤ１３０１としてＡＰ＿０１が指定されるため、バックアップカタログ情報１６０のＡＰＩＤ１６００４を参照し、一致したＡＰ＿０１のバックアップＩＤ３０１のＢＫ＿０１，ＢＫ＿０２，ＢＫ＿０３を表示している。事前リカバリデータ有無１３０６は、ＡＰ構成情報４００のリカバリデータ保存有無４１０より参照している。

ステップ１２０５では、リカバリ設定画面のバックアップカタログリスト１３０２よりユーザが選択したリカバリ対象のバックアップＩＤの情報を取得する。図１３の例では、チェック１３０３により選択されている、ＢＫ＿０３がリカバリ対象のバックアップＩＤとなる。

ステップ１２０７では、図１０のステップ１０２５でＡＰを回復した状態を保存しているか否かを判断する。ＡＰを回復した状態を保存している場合（ステップ１２０７：ＹＥＳの場合）にはステップ１２０９を実行する。ＡＰを回復した状態を保存していない場合（ステップ１２０７：ＮＯの場合）はステップ１２１１を実行する。

ステップ１２０９では、図１０のステップ１０２５にて保存したデータを用いて、ホスト計算機１３０上にリカバリしてデータを復元する。

ステップ１２１１では、事前リカバリ処理でリカバリしたデータを保存していないため再度、ホスト計算機１３０上でリカバリする必要がある。

ステップ１２１３では、指定されたバックアップＩＤのデータをリカバリし、AP回復処理プログラム１４６を使用してＡＰの回復処理を行う。

図１３の例では、２００８／１２／０４ １２：１９のＡＰのデータに戻ることができる。

最後に、ステップ１２１５ではリカバリ終了通知を行い、処理を終了する
＜＜第２実施形態＞＞
次に、本発明の第２の実施形態について説明する。本実施形態は、第１の実施形態の計算機システムに含まれるストレージシステムにおいて、ＮＡＳ(Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ)を含む点が異なる。本実施形態では、図１の構成との差異を中心にＮＡＳ条件におけるＡＰに使用されるボリュームのバックアップ管理に本発明を適用した場合について説明する。

ＮＡＳは、ストレージシステム上のＮＡＳ１４１３のメモリ１４１３にＮＡＳ ＯＳが格納されており、ファイルサーバとして機能する。

図１４に、本実施形態に係るＮＡＳ１４１３を備えた計算機システム１’のシステム構成図の一例を示す。図１４に示すように、本実施形態の計算機システム１’は、図１と同様に、ストレージシステム１４１０と、ホスト計算機１３０と、代替用ホスト計算機１４０と、管理計算機１５０とで構成される。以下、図１と異なるストレージシステム１４１０について説明する。

ストレージシステム１４１０は、ストレージ装置１４１１と、コントローラ１４１２に加えて、ＮＡＳ１４１３とを備える。

ストレージ装置１４１１は図１のストレージ装置１１１と同様である。

コントローラ１４１２は図１のコントローラ１１２と同様である。

ＮＡＳ１４１３は、ネットワークを介してホスト計算機１３０と接続されるＩ／Ｆ１４１４、ＣＰＵ１４１５、メモリ１４１６、及びコントローラ１４１２と接続されるＩ／Ｆ１４１７で構成される。メモリ１４１６には、ＮＡＳのためのＯＳ（ＮＡＳＯＳ）１４１８と、ＮＡＳＯＳのＮＡＳＯＳ静止化プログラム１４１９が格納される。ＮＡＳＯＳ１４１８は、ホスト計算機１３０に、例えばディスクドライブのように記憶領域を提供することができる。ＮＡＳＯＳ静止化プログラム１４１９は、第１の実施形態のＯＳ静止化プログラム１３６と同様にＮＡＳＯＳ１４１８の「静止化」を行う。ＮＡＳＯＳ静止化プログラム１４１９は、ＣＰＵ１４１５によって読み出され実行されることによりその機能が実現される。ＮＡＳ１４１３は、図１４のようにストレージシステム１４１０上にあってもよいし、他の計算機上にあってもよい。

次に、本実施形態において参照される各情報について説明する。本実施形態で用いる各種情報は、第１実施形態に関する図２から図５までに示した各情報に記録されていた情報と同様である。但し、本実施例で指すＯＳは、ＮＡＳ１４１３上にあるＮＡＳＯＳ１４１８のこととし、ＯＳ静止化プログラムはＮＡＳ１４１３上にあるＮＡＳＯＳ静止化プログラム１４２０のこととする。具体的には、バックアップスケジュール情報１５９のＯＳＩＤ１５９０３と、バックアップカタログ１６０のＯＳＩＤ１６００２と、ＡＰ構成情報１６１のＯＳＩＤ１６１０３は、ＮＡＳ１４１３上にあるＮＡＳＯＳ１４１８を示す。また、ＡＰ構成情報１６１のＯＳ静止化プログラム有無１６１０４は、ＮＡＳＯＳ静止化プログラム１４２０の有無を示す。

次に、本実施形態に係るバックアップ管理処理について説明する。

本実施形態におけるバックアップ管理の処理は、図１４に示す計算機システム１’と、上述して各情報を用い、第１実施形態と同様の図６の処理で実現可能である。ステップ６０１からステップ６０７の処理は、本実施形態によるバックアッププログラム１５６によって実現される処理である。但し、本実施例では、ステップ６０３では、ストレージシステム１４１０のＮＡＳ１４１３上のＯＳ静止化プログラム１４１９による処理を含む。

すなわち、第１実施形態に関して図６乃至図８、図１０乃至図１３に示したフローチャート及び画面例は同様のものを用いることができる。

但し、第１実施形態ではホスト計算機１３０上にあるＯＳ１３５とＯＳ静止化プログラム１３６に加えて、本実施例ではストレージシステム１４１０のＮＡＳ１４１３上にＮＡＳＯＳ１４１８とＮＡＳＯＳ静止化プログラム１４１９存在する。そこで、バックアップ処理は図１５に示すように、まずホスト上のＯＳ静止化プログラムを用いてＯＳの静止化を行い、その後、ＮＡＳ上のＮＡＳＯＳ静止化プログラムを用いてＮＡＳＯＳを静止化する。

そのため、管理計算機１５０の操作対象の装置は、ホスト計算機１４３０からストレージ装置１４１０へ変更となる。よって、管理計算機１５０上のバックアッププログラム１５６は、ホスト計算機１４３０上にあるエージェント１４３６からホスト計算機１４３０と、ＮＡＳ１４１６を含むストレージシステム１４１０の構成情報を取得し、ＡＰ構成情報を作成する。

バックアップ管理処理は、第1の実施形態と同様に、ステップ６０１にて管理計算機１５０上のバックアッププログラム１５６は、バックアップの条件設定処理を実行する。

ステップ６０３にて、ステップ６０１にて設定したバックアップ条件を利用してバックアップ処理を行う。図１５に、本実施形態におけるバックアップ処理の一例を示す。第一の実施例との差異を以下に説明する。

ステップ２２０１では、バックアッププログラム１５６は、ＮＡＳＯＳを確認する。

ステップ２２０３では、特定されたＮＡＳＯＳに、ＮＡＳＯＳ静止化プログラム１３６が存在するか否かを確認する。ＮＡＳＯＳ静止化プログラムが存在する場合（ステップ２２０３がＹＥＳの場合）はステップ２２０５へ進む。ＯＳ静止化プログラムが存在しない場合（ステップ２２０３がＮＯの場合）は、ステップ９０７へ進む。

ステップ２２０５では、ステップ２２０１で特定したＮＡＳＯＳに対してＮＡＳＯＳ静止化プログラム１３６を使用して静止化を行う。

さらに、ステップ２２１７では、ステップ２２０５で静止化されたＮＡＳＯＳの静止化を解除する。

ステップ６０５では、代替用ホスト計算機１４０を利用して、バックアップデータを事前にリカバリ処理を行う。代替用ホスト計算機１４０は、第１の実施形態と同様にホスト計算機１４３０上のＡＰ１４３４とＯＳ１４３５と同様のものが搭載されている。そして、ＡＰのリカバリ可能時刻を確認し、バックアップカタログを修正する。

ステップ６０９では、ＡＰのＲＰＯ補正処理を行う場合は、ステップ６０５で確認した時刻と指定されたＡＰのＲＰＯから次にバックアップを開始する時刻を算出して、バックアップスケジュールを修正する。

ステップ６１１では、リカバリ処理は、ユーザがバックアップカタログからＡＰのリカバリ可能時刻を参照し、バックアップデータをリカバリする。
＜＜第３の実施形態＞＞
第３の実施形態は、第１の実施形態における計算機システムと比較し、ホスト計算機に仮想サーバ（ＶＭ）を構築する点が異なる。つまり、第３の実施形態において、仮想サーバ（ＶＭ）にて実行されるＡＰのバックアップ方法を示す。

図１６に、本実施形態における計算機システム１”のシステム構成図の一例を示す。図１６に示すように、本実施形態の計算機システムは、図１と同様に、ストレージシステム１１０と、ホスト計算機１５３０と、代替用ホスト計算機１５４５と、管理計算機１５０で構成されている。以下、図１と異なるホスト計算機１５３０と代替用ホスト計算機１５４５について説明する。

ホスト計算機１５３０は、ＣＰＵ１５３１と、メモリ１５３２と、Ｉ／Ｆ１５３３とで構成される。

ＣＰＵ１５３１は、メモリ１５３２に格納されたプログラムを実行するプロセッサである。

メモリ１５３２には、仮想サーバ（ＶＭ）１５３４、仮想サーバ制御プログラム１５３５と、仮想サーバ静止化プログラム１５３６と、エージェント１５３７が格納される。

仮想サーバ制御プログラム１５３５は、ＶＭ１５３４を制御するプログラムである。メモリ１５３２上に一つ以上のＶＭ１５３４を動作させることができる。実際には、ＶＭのイメージを格納したファイルが、ストレージのボリュームに格納される。ＶＭイメージには、アプリケーションやＯＳの実行プログラムも格納されている。そして、仮想サーバ制御プログラム１５３５が該ファイルを読み出し、ＶＭをホスト計算機のメモリ上に構築する。

仮想サーバ静止化プログラム１５３６は、ＶＭ１５３４を静止化するプログラムである。ＶＭをバックアップするときは、バックアップ対象のＶＭを、ＶＭ単位で静止化することができる。

エージェントは、第１実施形態と同様にホスト計算機１５３０とストレージシステム１１０の情報を取得し、またＡＰの情報も取得し管理計算機１５０に情報を通知する機能を持つ。

ＶＭ１５３４上には、ＡＰ１５３８と、ＯＳ１５３９と、ＯＳ静止化プログラム１５４０と、ＡＰ回復処理プログラム１５４１と、ＡＰ時刻確認プログラム１５４２とが構築される。本実施形態のＶＭ１５３４上のＡＰ１５３８とＯＳ１５３９とＯＳ静止化プログラム１５４０は、それぞれ、第１実施形態のＡＰ１３４とＯＳ１３５とＯＳ静止化プログラム１３６とに対応している。ＡＰ回復処理プログラム１５４１とＡＰ時刻確認プログラム１５４２は、第１の実施形態の代替用ホスト計算機１４０上のＡＰ回復処理プログラム１４６とＡＰ時刻確認プログラム１４７とに対応している。

ＡＰ１５３８は、ホスト計算機１５３０のＶＭ１５３４上で動作し、業務を実行するプログラムである。一つのＶＭ１５３４上にＡＰは一つでもよいし、複数存在してもよい。ＯＳ１５３９は、ＶＭ１５３４上で動作しＶＭ全体を管理する基本ソフトウェアである。ＯＳ静止化プログラム１５４０は、ＯＳの整合性を保つために、ＯＳ１５３９を静止化するプログラムである。ＡＰ回復処理プログラム１５４１は、ＡＰの回復処理を行うプログラムである。ＡＰ時刻確認プログラム１５４２は、ＡＰの最終更新時刻を確認するプログラムである。

代替用ホスト計算機１５４５は、ＣＰＵ１５４６と、メモリ１５４７と、Ｉ／Ｆ１５４８とで構成されている。

ＣＰＵ１５４６は、メモリ１５４７に格納されたプログラムを実行するプロセッサである。

メモリ１５４７には、仮想サーバ制御プログラム１５４９が格納される。仮想サーバ制御プログラム１５４９は、ホスト計算機１５３０上の仮想サーバ制御プログラム１５３５と同様にＶＭを制御するプログラムであり、一つ以上のＶＭ１５３４を動作させることができる。具体的には、仮想サーバ制御プログラム１５４９は、ボリュームに格納されるＶＭのデータファイルを読み出し、代替用ホスト計算機１５４５のメモリ１５４７上にＶＭを構築する。

リカバリの際には、ボリュームにコピーされたファイルを同一のホスト計算機または代替用ホスト計算機の仮想サーバ制御プログラムにより読み出し再現することで、バックアップした条件と同じＯＳやＡＰが構築された状態で再開できる。したがって、第１の実施形態や第２の実施形態のように、代替用ホスト計算機のメモリに仮想サーバ制御プログラムが格納されていればよく、ホスト計算機と同じＯＳやＡＰを格納する必要はない。

また、仮想サーバ条件を使用した本実施形態では、代替用ホスト計算機１５４５とホスト計算機１５３０は、同一の計算機を使用してもよい。

次に、本実施形態において参照される各情報について説明する。

図１７に、本実施形態におけるバックアップスケジュール情報１５９の一例を示す。なお、図１７に記載のバックアップスケジュール情報１５９のフォーマットは一例であって、図１７に示したフォーマットに限定されるものではない。図１７は、第１の実施形態の図２にＶＭＩＤ１５９０５を追加している点で異なる。したがって、スケジュールＩＤ１５９０１、バックアップ開始時刻１５９０２、ＯＳＩＤ１５９０３、コピーペアＩＤ１５９０４、ＶＭＩＤ１５９０５にて構成される。ＶＭＩＤ１５９０５には、バックアップ対象のＶＭを識別する情報（例えば、識別子）が格納される。

図１８に、本実施形態におけるバックアップカタログ情報１６０の一例を示す。なお、図１８に記載のバックアップカタログ情報１６０のフォーマットは一例であって、図１８に示したフォーマットに限定されるものではない。図１８は、第１の実施形態の図３にＶＭＩＤ１６００７を追加している点で異なる。したがって、バックアップＩＤ１６００１、ＯＳＩＤ１６００２、ＶＭＩＤ１６００７、バックアップ時刻１６００３、ＡＰＩＤ１６００４、ＡＰのリカバリ可能時刻１６００５、バックアップデータ格納ボリュームＩＤ１６００６から構成されている。ここで、バックアップＩＤ１６００１と、ＡＰＩＤ１６００４と、ＡＰのリカバリ可能時刻１６００５と、バックアップデータ格納ボリュームＩＤ１６００６は第１の実施形態の図３と同様に取得する。ＶＭＩＤ１６００７は、図１７のバックアップスケジュール情報１５９のＶＭＩＤ１５９０４から情報を取得する。バックアップ時刻１５９０４は、図１７のバックアップスケジュール情報１５９のバックアップ開始時刻１５９０２から情報を取得する。また、バックアップ時に、ＯＳの静止化のみを実行する場合にはＯＳの静止化の時刻とし、ＶＭの静止化のみを実行する場合にはＶＭの静止化の時刻とし、ＯＳとＶＭの静止化を実行する場合にはＶＭの静止化の時刻としてもよい。ＯＳとＶＭの静止化を実行する場合には、ＶＭの静止化の時刻をバックアップ時刻１５９０４としたのは、通常はＯＳの静止化後にＶＭの静止化を実行するためである。

図１９（Ａ）（Ｂ）に、本実施形態におけるＡＰ構成情報１６１の一例を示す。図１９（Ａ）（Ｂ）に記載のＡＰ構成情報１６１のフォーマットは一例であって、図１９（Ａ）（Ｂ）に示したフォーマットに限定されるものではない。図１９（Ａ）（Ｂ）は、第１の実施形態の図４にＶＭＩＤ１６１１１とＶＭ静止化プログラム有無１６１１２を追加している点で異なる。したがって、ＡＰＩＤ１６１０１と、ホストＩＤ１６１０２と、ＯＳＩＤ１６１０３と、ＯＳ静止化プログラム１６１０４と、ＶＭＩＤ１６１１１と、ＶＭ静止化プログラム有無１６１１２と、ストレージＩＤ１６１０５と、使用ＶＯＬＩＤ１６１０６と、ＲＰＯ１６１０７と、ＲＰＯ補正有無１６１０８と、リカバリデータ保存有無１６１０９から構成される。ＶＭＩＤ１６１１１には、バックアップ対象のＶＭを識別する情報（例えば、識別子）を格納する。ＶＭ静止化プログラム有無１６１１２には、バックアップ対象のＶＭを静止化するためのプログラムである仮想サーバ静止化プログラム１５３６を有するか否かを示す情報を格納する。ＶＭＩＤ１６１１１とＶＭ静止化プログラム有無１６１１２の情報は、バックアッププログラムが、ホスト計算機上１５３０上のエージェント１５３７より取得し、格納する。

ストレージシステム１１０のメモリに格納されるストレージ管理情報１２０は、図５と同様であり、管理計算機１５０で実行されるバックアッププログラム１５６によって参照される。
＜バックアップ処理＞
次に、本実施形態に係るバックアップ処理について説明する。

本実施形態におけるバックアップ処理は、図１６に示す計算機システムと、図１７のバックアップスケジュール情報１５９、図１８のバックアップカタログ情報１６０、図１９のＡＰ構成情報１６１、を用いて、第１の実施形態と同様の図６の処理で実現される。図６において、ステップ６０１からステップ６０７の処理は、本実施形態によるバックアッププログラム１５６によって実現される処理である。但し、第１実施形態との差異として、ステップ６０３では、ホスト計算機１３０上のＯＳ静止化プログラム１５４０と、仮想サーバ静止化プログラム１５３６による処理を含む。ステップ６０５では、代替用ホスト計算機１５４１上の仮想サーバプログラム１５４５と、ＡＰ回復処理プログラム１５４６と、ＡＰ時刻確認プログラム１５４７の処理を含む。

図２０に、本実施形態におけるバックアップ条件設定処理の一例を示す。本実施形態においては、バックアップ対象としてＡＰを指定されてもよいし、ＶＭを指定されてもよい。例えば、ユーザがバックアップ対象としてＡＰを指定した場合には、ＡＰが実行されるＶＭを検索し、そのＶＭのイメージファイルが格納されるボリュームのバックアップが実行される。また、ユーザがバックアップ対象としてＶＭを指定した場合には、そのＶＭのイメージファイルが格納されるボリュームのバックアップが実行される。図２０は、第１の実施形態の図７と比較してステップ１９０１とステップ１９０２とが異なる。異なるステップについて以下に説明する。

ステップ１９０１では、バックアッププログラム１５６は、バックアップ条件の設定画面から、ユーザによって入力されたＡＰＩＤ又はＶＭＩＤ、コピー種別、ＲＰＯなどの情報を取得する。そして、取得した情報に基づき、ＡＰ構成情報１６１を修正する。

ステップ１９０３では、ステップ１９０１にてバックアップ対象としてＡＰが指定された場合には、バックアッププログラム１５６が、ＡＰ構成情報１６１を使用して、ステップ１９０３で取得したＡＰＩＤに対応するＡＰＩＤを検索する。そして、ＡＰ構成情報１６１の使用ＶＯＬＩＤ１６１０６を参照し、検索されたＡＰＩＤが実行されるＶＭのイメージファイルの格納されるボリュームを特定する。また、ステップ１９０１にてバックアップ対象としてＶＭが指定された場合には、バックアッププログラム１５６が、ＡＰ構成情報１６１を使用して、ステップ１９０３で取得したＶＭＩＤに対応するＶＭＩＤを検索する。そして、ＡＰ構成情報１６１の使用ＶＯＬＩＤ１６１０６を参照し、検索されたＶＭＩＤのＶＭのイメージファイルが格納されるボリュームを特定する。

図２１に、本実施形態におけるバックアップ処理の一例を示す。バックアッププログラム１５６は、ステップ６０１で設定した条件と、バックアップスケジュール情報１５９に基づき、バックアップ処理を行う。各バックアップ処理は、バックアップスケジュール情報１５９のバックアップ開始時刻１５９０１になると、実行される。但し、オンデマンドで実行してもよい。第1実施形態と比較すると、バックアップ対象のＡＰが実行されるＶＭ又はバックアップ対象のＶＭを特定し、ＶＭの静止化処理を実行する点が異なる。異なるステップについて以下に説明する。

ステップ２１０１では、バックアッププログラム１５６が、バックアップ対象のＡＰが実行されるＶＭまたはバックアップ対象のＶＭを確認する。具体的には、バックアップスケジュール情報１６０のＶＭＩＤ１５９０５より静止化するＶＭを特定する。

ステップ２１０３では、ステップ２００１で特定したＶＭに対してＶＭ静止化プログラム１３６を使用して静止化を行う。ＶＭ静止化処理を行わないと、ファイルが使用中になるため代替用ホスト計算機１５４５で再開できなくなり、リカバリ処理を行うことができない。

ステップ２１０５では、ステップ２００３にてＶＭが静止化されているＶＭの静止化を解除する。

図２２に、本実施形態における事前リカバリ処理の一例を示す。第１の実施形態の図１０と比較すると、ステップ２２０３のみ異なる。異なるステップについて以下に説明する。

ステップ２２０３では、仮想サーバ制御プログラム１５４９が、副ボリュームに格納されたＶＭのイメージファイルを読み出して、ＶＭを構築（再開）する。ＶＭの場合、バックアップされたＶＭイメージに、ＡＰの処理が記載されているログも格納される。ＡＰのトランザクション処理が途中の状態でバックアップされた場合でも、ＶＭを再開したときに途中の状態からトランザクション処理が再開することがある。この場合、ＡＰはトランザクション処理を完了させ、ＡＰのバックアップ時刻より未来の時刻で整合性がとれた状態になる。バックアッププログラムは、この時刻をリカバリ可能時刻としてバックアップカタログ情報のＡＰのリカバリ可能時刻１６００５を更新してもよい。

第３の実施形態では、ＡＰが仮想サーバ上で実行されるホスト計算機を有する計算機システムにおいて、本発明のバックアップ処理を適用した場合を示した。
＜＜第４の実施形態＞＞
第４の実施形態は、第３の実施形態と比較すると、ＶＭのファイルレベルのコピー機能を適用した計算機システム構成を採用している点が異なる。

本実施形態の計算機システムは、第３実施形態のシステム構成を示した図１６と同様である。但し、仮想サーバ制御プログラム１５３５は、ホストベースのコピー機能を有する。

本実施形態でのバックアップ構成構築処理に使用される各種情報について、第３実施形態における図５及び図１７から図１９までの各情報に記録されている情報と異なる部分を説明する。主な差異部分は、ボリューム指定ではなく、ファイル指定となり、ストレージのコピー機能ではなく、ホストベースのコピー機能を用いる点である。

具体的には、図５のストレージ管理情報１２０のうちボリューム情報１２０１のボリュームＩＤ１２０１２にファイルＩＤが格納される。また、コピーペア情報１２０２の、正ＶＯＬＩＤ１２０２３に正ファイルＩＤが格納され、副ＶＯＬＩＤ１２０２５に副ファイルＩＤが格納される。

図１８のバックアップカタログ情報１６０のバックアップデータ格納ボリュームＩＤ１６００７にはバックアップデータ格納ファイルＩＤが格納される。

図１９のＡＰ構成情報１６１の使用ＶＯＬＩＤ１６１０８には、使用ファイルＩＤが格納される。

次に、本実施形態に係るバックアップ処理について説明する。本実施形態におけるバックアップ管理の処理は、第３実施形態と同様である。

図２３に、本実施形態におけるバックアップ条件設定処理フローの一例を示す。バックアッププログラム１５６は、ユーザからのバックアップの要求を受けて、バックアップ条件の設定画面を表示し、処理を開始する。

ステップ２００１では、バックアッププログラム１５６は、バックアップ環境の設定画面から、入力されたＡＰＩＤ、ＲＰＯの情報を取得する。バックアップ先ファイルはユーザによって指定されたファイル先でもよいし、自動でバックアップ先を選択しても良い。取得した情報に基づき、ＡＰ構成テーブル１６１を修正する。

バックアップ条件の設定画面の一例である図８との差異について示す。図８のバックアップ対象とするＡＰＩＤを指定する項目８０１と、バックアップポリシーを入力する情報８０２と、設定ボタン８０８と、バックアップ条件設定を中止するキャンセルボタン８０９を含んだ構成は同じである。バックアップポリシー情報８０２には、コピー種別８０３の項目は削除され、ＲＰＯ８０４と、ＲＰＯ補正処理有無８０５と、事前リカバリデータ保存処理有無８０６の各項目を備えている。ここで、バックアップ先ファイルの項目を追加しても良い。

ステップ２００３では、ＡＰ構成情報１６１を使用して、取得したＡＰＩＤから使用ファイルＩＤ４０５項目を参照し、ＶＭのイメージファイルが格納されるファイルを特定する。本実施形態ではホストベースによるコピー機能を使用するため、コピーペア構築は行わずにバックアップ元とバックアップ先のファイルを指定する。

図２４に、本実施形態におけるバックアップ処理の一例をしめす。第３の実施形態の図１９の処理フローとは、ステップ２３０１のみ異なる。バックアッププログラム１５６が、図２３のバックアップ条件設定処理フローで作成した条件と、バックアップスケジュール情報１５９を参照し、バックアップ処理を行う。具体的には、バックアップスケジュール情報１５９のバックアップ開始時刻１５９０２に、バックアップ処理が実行される。但し、オンデマンドで実行してもよい。以下、図２１の処理フローと異なる点について説明する。

ステップ２３０１にて、コピースプリット処理ではなく、管理計算機１５０のバックアッププログラム１５６を使用して、指定されたファイルを指定されたバックアップ先に対してホストベースのデータコピーを実行する。

事前リカバリ処理は、第３実施形態と同様である。但し、ステップ１００１では副ボリュームではなく、バックアップ先ファイルとなる。
＜＜第５の実施形態＞＞
第５の実施形態は、第３実施形態と比較すると、事前リカバリ処理を行う代替用ホスト計算機１５４５を複数台有する点が異なる。

計算機システム構成は図１６と同様であるが、代替用ホスト計算機が複数台ある点でことなる。この場合、事前リカバリ処理を実行できる代替用ホスト計算機が複数存在するため、利用可能な代替用ホスト計算機を管理する。

本実施形態で使用される各種情報は、図１７、図１８、図１９と同様である。本実施形態では、さらに、管理計算機１５０のメモリ１５２に、代替用ホスト計算機情報が格納される。

図２５に、本実施形態の代替用ホスト計算機情報２３００の一例を示す。代替用ホスト計算機情報２３００は、ホストＩＤ２３０１と、ＶＭ有無２３０２と、使用状況２３０３が格納される。ホストＩＤ２３０１には、代替用ホスト計算機を識別する情報が格納される。ＶＭ有無２３０２には、代替用ホスト計算機が仮想サーバ制御プログラムを有しているか否かを示す情報が格納される。使用状況２３０３には、代替用ホスト計算機が事前リカバリ処理のために使用されているか否かの情報が格納される。

以下、事前リカバリ処理において、第３の実施形態と異なる点を説明する。

図２２に示す、事前リカバリ処理のフローのうち、ステップ１００１が異なる。

ステップ１００１では、代替用ホスト計算機情報２３００を参照し、ＶＭ有無２３０２に仮想サーバ制御プログラムが「有」である情報が格納されており、かつ、使用状況２３０３が「空き」である情報が格納されている代替用ホスト計算機を検索する。そして、検索された代替用ホスト計算機に副ボリュームをマウントする。

このように、代替用ホスト計算機を複数台有し、その使用状況を管理することにより、複数代の代替用ホスト計算機に対して事前リカバリ処理の割り当て、負荷を平準化することが可能となる。

１、１’、１” 計算機システム
１１０、１２５ ストレージシステム
１１１ ストレージ装置
１１２ コントローラ
１１３ ボリューム
１１４ ディスク
１１５ Ｉ／Ｆ
１１６ ＣＰＵ
１１７ メモリ
１１８ ストレージＩ／Ｆ
１１９ ストレージマイクロプログラム
１２０ ストレージ管理情報
１３０ ホスト計算機
１３１ ＣＰＵ
１３２ メモリ
１３３ Ｉ／Ｆ
１３４・１４４ ＡＰ
１３５・１４５ ＯＳ
１３６ ＯＳ静止化プログラム
１３７ エージェント
１４０ 代替用ホスト計算機
１４１ ＣＰＵ
１４２ メモリ
１４３ Ｉ／Ｆ
１４６ ＡＰ回復処理プログラム
１４７ ＡＰ時刻確認プログラム
１５０ 管理計算機
１５１ ＣＰＵ
１５２ メモリ
１５３ 入力装置
１５４ 表示装置
１５５ Ｉ／Ｆ
１５６ バックアッププログラム
１５７ リカバリプログラム
１５８ ＲＰＯ補正プログラム
１５９ バックアップスケジュール情報
１６０ バックアップカタログ情報
１６１ ＡＰ構成情報

Claims (9)

1. 計算機システムであって、
   アプリケーションを実行する第１のホスト計算機と、
   第２のホスト計算機と、
   前記第１のホスト計算機と前記第２のホスト計算機に接続し、前記アプリケーションに割り当てられる第１のボリュームを含む複数のボリュームを形成する複数の記憶装置を有するストレージシステムと、
   前記第１のホスト計算機、前記第２のホスト計算機と前記ストレージシステムに接続し、前記第１のボリュームのバックアップを開始する第１の時間を管理するバックアップスケジュール情報と、バックアップ結果に関する情報を管理するバックアップカタログ情報とを保持する、管理計算機と、を有し
   前記管理計算機は、前記バックアップスケジュール情報を参照し、前記第１の時間に前記ストレージシステムに対し第１の指示を発行し、前記第１の指示発行後に前記第２のホスト計算機に第２の指示を発行し、
   前記ストレージシステムは、前記第１の指示に応じて、前記第１のホスト計算機の前記アプリケーションの処理の継続中に、前記第１の時間に前記第１のボリュームを第２のボリュームにバックアップし、
   前記第２のホスト計算機は、前記第２の指示に応じて、前記第２のボリュームのデータを読み出し、前記アプリケーションがリカバリ可能な時間である第２の時間を取得し、
   前記管理計算機は、前記第１のボリュームのバックアップの識別情報と前記第２の時間を前記バックアップカタログ情報に格納し、
   前記管理計算機は、さらに、前記識別情報と前記第２の時間とを出力する出力装置を含み、
   前記第１のホスト計算機は、さらにアプリケーションを実行するためのオペレーティングシステムを有し、
   前記第２のホスト計算機は、前記第１のホスト計算機が保持する前記アプリケーション及び前記オペレーティングシステムを有し、前記アプリケーションがリカバリ可能な時間である前記第２の時間を取得する際に前記アプリケーション及び前記オペレーティングシステムを使用し、
   前記第１のホスト計算機は、アプリケーションを実行する仮想サーバを制御する仮想サーバ制御プログラムを有し、
   前記第２のホスト計算機は、前記第１のホスト計算機が有する前記仮想サーバ制御プログラムを有し、前記アプリケーションがリカバリ可能な時間である前記第２の時間を取得する際に前記仮想サーバ制御プログラムを使用する、ことを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記管理計算機は、前記第２のホスト計算機が、前記第２の指示に応じて、前記第２のボリュームを読み出して、前記アプリケーションのリカバリができなかった場合、前記バックアップカタログ情報に含まれる前記識別情報に関する情報を削除する、ことを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記管理計算機は、前記第２のホスト計算機が、前記第２の指示に応じて、前記第２のボリュームを読み出して、前記アプリケーションのリカバリができなかった場合、さらに、前記ストレージシステムに対して前記第２のボリュームのバックアップデータの削除の指示を発行する、ことを特徴とする計算機システム。
4. 請求項１乃至請求項３のいずれか１つに記載の計算機システムであって、
   前記第２のホスト計算機は、前記第２の指示に応じて、前記第２のボリュームを読み出して、前記アプリケーションのリカバリを実行する場合、リカバリしたデータを前記ストレージシステムの第３のボリュームに書き込む、ことを特徴とする計算機システム。
5. 請求項１乃至請求項４のいずれか１つに記載の計算機システムであって、
   前記管理計算機は、前記第２の時間にあらかじめ設定されたＲＰＯ値を加算した第３の時間を、前記第１の時間後に前記第１のボリュームを第４のボリュームにバックアップする時間とし、前記バックアップスケジュール情報に格納する、ことを特徴とする計算機システム。
6. 請求項１乃至請求項５のいずれか１つに記載の計算機システムであって、
   前記第１のホスト計算機は、さらに、データを一時的に格納するキャッシュメモリを含み、
   前記管理計算機は、前記第２の時間が、前記第１の時間以前に前記第１のボリュームより他のボリュームにバックアップされたデータを用いて前記アプリケーションがリカバリ可能な時間と一致する場合、前記キャッシュメモリから前記第１のボリュームへデータを移動する時間間隔をあらかじめ設定されたＲＰＯの時間内に収まるよう修正する、ことを特徴とする計算機システム。
7. 請求項１乃至請求項６のいずれか１つに記載の計算機システムであって、
   前記第２のホスト計算機は、複数のホスト計算機を含み、
   前記管理計算機は、前記複数のホスト計算機の使用状況を管理する情報を有し、前記複数のホスト計算機のうち、使用されていないホスト計算機に対して第２の指示を発行し、
   前記使用されていないホスト計算機が、前記第２の指示に応じて、前記第２のボリュームのデータを読み出し、前記アプリケーションがリカバリ可能な時間である前記第２の時間を取得する、ことを特徴とする計算機システム。
8. アプリケーションを実行する第１のホスト計算機と、第２のホスト計算機と、前記アプリケーションに割り当てられる第１のボリュームを含む複数のボリュームを形成する複数の記憶装置を含むストレージシステムと、に接続される管理計算機によるバックアップ方法であって、
   前記第１のボリュームのバックアップを開始する第１の時間を管理するバックアップスケジュール情報と、バックアップ結果に関する情報を管理するバックアップカタログ情報とを保持し、
   前記ストレージシステムに対して、前記第１のホスト計算機の前記アプリケーションの処理の継続中に、前記第１の時間に前記第１のボリュームを第２のボリュームにバックアップする指示を出し、
   前記第２のホスト計算機より、前記第２のホスト計算機が前記第２のボリュームのデータを読み出し、取得された前記アプリケーションがリカバリ可能な時間である第２の時間を取得し、
   前記第１のボリュームのバックアップの識別情報と前記第２の時間とを前記バックアップカタログ情報に格納し、
   前記第２のホスト計算機が、前記第２の指示に応じて、前記第２のボリュームを読み出して、前記アプリケーションのリカバリができなかった場合、前記バックアップカタログ情報に含まれる前記識別情報に関連する情報を削除し、
   前記第２のホスト計算機が、前記第２の指示に応じて、前記第２のボリュームを読み出して、前記アプリケーションのリカバリができなかった場合、さらに、前記ストレージシステムに対して前記第２のボリュームのバックアップデータの削除の指示を発行する、ことを特徴とするバックアップ方法。
9. 請求項８に記載のバックアップ方法であって、
   前記第２のホスト計算機に対して、前記第２の指示に応じて、前記第２のボリュームを読み出して、前記アプリケーションのリカバリを実行する場合、リカバリしたデータを前記ストレージシステムの第３のボリュームに書き込む指示を発行する、ことを特徴とするバックアップ方法。

Images