JP2008181287A - データのリカバリを制御する装置及び方法 - Google Patents

Abstract

【課題】複数のアプリケーションが動作する計算機システムの業務再開までの時間を短くする。
【解決手段】制御装置は、ボリュームグループを構成する異なる論理ボリューム内のデータをそれぞれ利用する複数のアプリケーションの各々の優先度を決定する優先度決定部と、前記ボリュームグループを構成する複数の論理ボリュームのうち、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、ストレージシステムにリストア指示を出すリストア指示部とを備える。
【選択図】図１０

Description

本発明は、データのリカバリに関する。

一般に計算機システムでは、ストレージシステムの障害、コンピュータウィルスによるデータ破壊、ユーザによる誤操作などによってデータが喪失した場合に備え、定期的にデータのバックアップを行い、リカバリできるようにする。

また、現在、多くの企業では、企業の経営資源を有効に活用し経営を効率化するために、ERPパッケージ(Enterprise Resource Planning package)等を用いて、基幹業務の部門ごとに独立して運用されていたアプリケーション(データベースマネジメントシステム（ＤＢＭＳ）やファイルシステム等)を統合し、各アプリケーションが連携して動作可能な計算機システムを構築している。具体的には、例えば、各部門において運用されるそれぞれのアプリケーションが、同一のストレージシステムを利用することで、情報の共有化が図られている。これに加えて、アプリケーション同士が、お互いの機能を利用したり、お互いの処理結果を利用したりすることで、計算機システム全体として効率的な処理を行うことも図られている。このように、アプリケーション同士が、お互いの機能を利用したり、お互いの処理結果を利用したりして動作している場合に、それらのアプリケーションは、連携して動作していることになる。

このような連携して動作する複数のアプリケーションが存在する計算機システムに障害が発生した場合、アプリケーション間の整合性(各アプリケーションが利用しているデータ間の整合性)が保たれた状態にリカバリする必要がある。

このリカバリを実現するためのバックアップ技術の一つとして、各アプリケーションが利用する記憶領域(データボリューム)を一括してバックアップ操作する技術が提案されている（たとえば、特許文献１を参照）。この特許文献１では、一括してバックアップ操作を行いたいデータボリューム群(「コピーグループ」と呼ぶ)をストレージシステムが記憶することと、コピーグループ単位のバックアップ操作に対して、当該コピーグループに属する全データボリュームの同一時点のデータについて、ストレージシステムがバックアップを行うことと、が開示されている。

これにより当該バックアップ技術を用いてリカバリした場合、コピーグループに属するデータボリュームが同一時点の状態にリカバリされるためアプリケーション間の整合性が保証される。

また、他の技術として、ジャーナリングを用いたバックアップ技術が提案されている（たとえば、特許文献２を参照）。この特許文献２には、一つ以上のデータボリュームで構成される論理的なグループ(以降、「ジャーナルグループ」と呼ぶ)の特定時点のスナップショット（フルバックアップあるいは、差分バックアップなどの論理的なイメージ）を取得し、それ以降の前記データボリュームへの書き込みデータをジャーナル(「Afterジャーナル」と呼ばれる)として前記ジャーナルグループに関連付けられたジャーナルボリュームに格納することと、取得したスナップショットに対して書き込まれた順序どおりに一連のAfterジャーナルを適用することで、ジャーナルグループに属する全データボリュームのデータを特定の時点の状態にリストアすることと、が開示されている。これは一般に「Continuous Data Protection」又はそれを略して「CDP」と呼ばれる技術の一例である。

これによりリストアされたデータは完全に同一時点のデータとなるため、これを利用してリカバリすることでアプリケーション間の整合性を保証することができる。

なお、リカバリ時にジャーナルの適用対象となるスナップショットを「基底スナップショット」と呼ぶ。

特開２００５−１９６６１８号公報 特開２００４−２５２６８６号公報

課題を説明するために、まず、「リカバリ」という用語の定義を行う。

「リカバリ」とは、次の二つの処理を順番に実行することである。

一つ目は、ストレージシステム或いはバックアップソフトウェアが、バックアップ時点のデータをデータボリュームへリストアする処理である。以降では、これを単に「リストア」と呼ぶ。リストアは、具体的には、例えば、特許文献１の技術であれば、ストレージシステム内でバックアップボリュームに基づいてデータボリュームのデータを復元することを指す。また、例えば、特許文献２の技術であれば、基底スナップショットに基づいてデータボリュームのデータを基底スナップショットが取得された時点のデータに復元し、その後、このデータボリュームへジャーナルを適用し、特定時点のデータを復元することを指す。

二つ目は、アプリケーションが、運用再開する前に、リストアされたデータがアプリケーションにとって整合性のとれたものとなるように、その内容を確認、変更する処理である。以降では、これを「整合性確認」と呼ぶ。整合性確認は、具体的には、アプリケーションがファイルシステムであれば、ボリュームをマウントして、データの整合性確認を行う処理(FSCK（File System Consistency Check）等)を指す。また、アプリケーションがＤＢＭＳであれば、リストアされたデータにログを適用し、その後直近のコミット時点まで更新を取り消す処理(クラッシュリカバリ、あるいは、インスタントリカバリ等と呼ばれる処理)を指す。

ここで、課題の説明に戻るが、一般的に、計算機システムのリカバリでは、リカバリにかかる時間(リカバリ時間)を可能な限り短くし、迅速に業務を再開したいという要求がある。

また、リストアの処理には、その処理能力の限界が存在する。この限界は、リストア処理を制御するCPU性能がネックであったり、データ転送におけるネットワークやバスの帯域がネックであったり、データボリュームなどの論理ボリュームのアクセス性能がネックであったり、さまざまな原因で発生する。このため、複数のボリュームをグループ単位でリストアすると処理能力が分散されてしまい、各ボリュームのリストア処理時間が長くなってしまう。

複数のアプリケーションが連携して動作する計算機システムをリカバリする場合、このような各ボリュームのリストア処理時間の増大が起こると、各アプリケーションの整合性確認開始タイミングが遅れる。この結果、各アプリケーションのリカバリ時間が長くなってしまい、複数のアプリケーションが連携して動作する計算機システムの業務再開までの時間が長くなってしまうという課題がある。

なお、ここでいう「複数のアプリケーションが連携して動作する計算機システムの業務再開までの時間」は、アプリケーションの連携の仕方で異なる。複数のアプリケーションがお互いの処理(関数等)を呼び出しあうような密な連携を行う計算機システムの場合は、全アプリケーションのリカバリが完了するまでの時間を指す。また、ワークフローのように、一つのアプリケーションが独立に行う処理の結果を他のアプリケーションが利用するといった、複数のアプリケーションが疎に連携する計算機システムでは、業務再開直後に行われる処理を実行するアプリケーションのリカバリが完了するまでの時間を指す。また、リカバリを行うときに、データをどの時点の状態にリストアしたいかをユーザが指定することがある。「リカバリポイント」とは、この指定する時点のことである。リカバリポイントは、ユーザが指定することに代えて、他の方法により指定されてもよい。

前述した問題は、複数のアプリケーションが連携して動作する計算機システムに限らず、複数のアプリケーションが連携せずに動作する計算機システムについても起こりうる。

従って、本発明の目的は、複数のアプリケーションが動作する計算機システムの業務再開までの時間を短くすることである。

本発明の他の目的は、後述の説明から明らかになるであろう。

本発明に従う制御装置は、ボリュームグループを構成する複数の論理ボリュームを有するストレージシステムにある前記論理ボリュームに格納されるデータのリカバリを制御する制御装置において、前記ボリュームグループを構成する異なる論理ボリューム内のデータをそれぞれ利用する複数のアプリケーションの各々の優先度を決定する優先度決定部と、前記ボリュームグループを構成する複数の論理ボリュームのうち、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、ストレージシステムにリストア指示を出すリストア指示部とを備える。

上述した各部は、ハードウェア、コンピュータプログラム又はそれらの組み合わせ（例えば一部をコンピュータプログラムにより実現し残りをハードウェアで実現すること）により構築することができる。コンピュータプログラムは、所定のプロセッサに読み込まれて実行される。また、コンピュータプログラムがプロセッサに読み込まれて行われる情報処理の際、適宜に、メモリ等のハードウェア資源上に存在する記憶域が使用されてもよい。また、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体から計算機にインストールされてもよいし、通信ネットワークを介して計算機にダウンロードされてもよい。

また、制御装置は、ストレージシステム内部に組み込まれる形で構成されてもよいし、制御装置とストレージシステムとは、通信ネットワークを介して接続されてもよい。

また、制御装置は、複数のアプリケーションが実行されるホスト計算機と、ホスト計算機に指示を出す管理計算機とによって構成されてもよいし、複数のアプリケーションが実行されるホスト計算機又はホスト計算機に指示を出す管理計算機であってもよい。例えば、制御装置がホスト計算機と管理計算機とによって構成される場合は、ホスト計算機と管理計算機とストレージシステムとが、通信ネットワークを介して接続されるようにすることができる。

以下、本発明のいくつかの実施形態について、図面を参照しながら説明する。なお、これにより本発明が限定されるものではない。

＜第一の実施形態＞。

まず、第一の実施形態について説明する。

本実施形態に係る計算機システムは、ジャーナリングを用いたバックアップ技術を用いてバックアップ及びリストアを行うストレージシステムを備える。当該ストレージシステムは、密に連携する複数のアプリケーションのデータを格納するボリュームを備え、ジャーナリングを用いたバックアップ技術でこれをバックアップ(及びリストア)する。

当該計算機システムでは、複数のアプリケーションがお互いに処理を呼び出しあう。このため、データ破壊などの障害発生時には、全てのアプリケーションをリカバリしてから業務を再開する必要がある。

また、ジャーナリングを用いたバックアップ技術を用いて任意時点の状態にデータをリストアすると、一般的なアプリケーションにとってデータは不整合な状態である。このため、整合性確認処理（例えば、FSCKやクラッシュリカバリ）が必要となるが、当該処理にかかる時間は、アプリケーションのタイプやリカバリポイントにおけるアプリケーションの稼働状況や状態によって大きく異なる。

ところで、全ボリュームを一括してリストアすると、全ボリュームにとって、リストア完了までの時間が長くなる。この結果、全てのアプリケーションにとって、整合性確認開始時間が遅くなり、業務再開までの時間が長くなってしまうという問題が発生する。

本実施形態では、この問題を解決するために、リストアされたデータの整合性確認の時間が長いアプリケーションのデータを優先的にリストアし、他より早く完了させる。これにより、長い処理時間を必要とする整合性確認処理ほど前倒しして実行できるようになる。また、当該整合性確認処理はホスト計算機上で行われ、ストレージシステムのリストア処理性能に影響を与えないため、他のアプリケーションのデータのリストアを当該処理と並行して実行できる。この結果、業務再開までの時間を短くすることが可能になる。

以下、本実施形態のシステム構成と動作を説明する。

（１）第一の実施形態のシステム構成。

図１は、本実施形態の計算機システムの構成を示すブロック図である。本システムでは、ストレージシステム１０００とホスト計算機１１００は、データネットワーク１３００を介して互いに接続される。本実施形態では、データネットワーク１３００は、ストレージエリアネットワークとするが、IPネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。

ストレージシステム１０００とホスト計算機１１００と管理計算機１２００は、管理ネットワーク１４００を介して互いに接続される。本実施形態では、管理ネットワーク１４００は、IPネットワークとするが、ストレージエリアネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。また、データネットワーク１３００と管理ネットワーク１４００が、同一ネットワークであってもよいし、ホスト計算機１１００と管理計算機１２００が、同一計算機であってもかまわない。

なお、説明の都合上、図１では、ストレージシステム１０００を１台、ホスト計算機１１００を１台、管理計算機１２００を１台としたが、これら以上の台数を設置しても良い。

ストレージシステム１０００は、データを格納するディスク装置１０１０、ストレージシステム１０００内の制御を行うディスクコントローラ１０２０で構成されている。

ディスク装置１０１０は、ディスク型の記憶装置、例えば、ハードディスクドライブである。ディスク装置１０１０に代えて、フラッシュメモリデバイス等、多種の記憶装置が採用されてもよい。ディスク装置１０１０の記憶空間を基に、複数の論理ボリューム、例えば、データボリューム１０１１、スナップショットボリューム１０１２、ジャーナルボリューム１０１３等が形成される。そして、複数の論理ボリュームのうちの一以上の論理ボリュームより、それぞれ、ジャーナルグループ１０１４、SSVOLグループ１０１５が構成される。尚、ストレージシステム１０００は、実際には、複数のディスク装置１０１０を備え、複数のディスク装置１０１０の記憶空間を基に、論理ボリュームが形成される。ディスク装置１０１０は、複数に限らず一つでもよい。

ジャーナルグループ１０１４は、一つ以上のデータボリューム１０１１により構成される。データボリューム１０１１は、ホスト計算機１１００が利用するデータを格納する論理ボリュームである。また、ジャーナルグループ１０１４には、一つ以上のジャーナルボリューム１０１３及び一つ以上のSSVOLグループ１０１５が、関連付けられる。

ジャーナルボリューム１０１３は、ジャーナルを格納する論理ボリュームである。

SSVOLグループ１０１５は、一つ以上のスナップショットボリューム１０１２で構成される。スナップショットボリューム１０１２は、ある時点におけるデータボリューム１０１１の複製イメージ(スナップショット)を格納する論理ボリュームである。なお、スナップショットボリューム１０１２に格納されるスナップショットは、データボリューム１０１１のフルバックアップであっても、差分バックアップのような論理的なイメージであっても良い。

なお、これらの論理ボリュームに関する情報（構成情報）は、後述する制御プログラム１０２８を実行するCPU１０２３によって、管理情報群１０２９内で管理される。

ディスクコントローラ１０２０は、管理Ｉ／Ｆ１０２１、データＩ／Ｆ１０２２、ディスクＩ／Ｆ１０２５、メインメモリ１０２６、ＣＰＵ１０２３、タイマ１０２４を備えている。

メインメモリ１０２６には、管理情報群１０２９と、制御プログラム１０２８と、マーカー管理テーブル１０３０と、ジャーナル管理テーブル１０３１とが記憶される。ＣＰＵ１０２３は、メインメモリ１０２６に記憶されたプログラムを実行する。

制御プログラム１０２８がＣＰＵ１０２３に実行されることにより、スナップショットの取得、ジャーナルの生成、ジャーナリングを用いたリストア、ジャーナルの開放などのジャーナリングを用いたバックアップ技術を実現するために必要な処理が行われる。以下、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するＣＰＵによって処理が行われるものとする。

また、制御プログラム１０２８は、ジャーナリングを用いたバックアップ技術を用いてリカバリを支援するためにマーカーを生成、管理する。マーカーとは、テキストデータを含むデータである。また、マーカーは、ジャーナルの作成順序と関連付けられて管理される。このため、マーカーは、リカバリを行う際にリカバリポイント選択のための指標として用いることができる。

さらに、制御プログラム１０２８は、管理計算機１２００やホスト計算機１１００からの要求に応じディスク装置１０１０に対するデータの入出力を処理することや、ストレージシステム１０００内の構成情報(論理ボリュームの構成等)や制御情報の設定を行うことができる。ストレージシステム１０００の構成の設定としては、例えば、どの論理ボリュームがデータボリューム１０１１なのか等の論理ボリュームの種別を示す情報や、データボリューム１０１１がどのジャーナルグループに所属しているのか等のボリューム間の関係性を示す情報の設定がある。この構成の設定を表した情報は、構成情報の全部叉は一部として、管理情報群１０２９に含まれる。制御プログラム１０２８は、管理情報群１０２９の情報を参照または更新しながら上述した種々の処理を実行することができる。

ここで、ジャーナリングを用いたバックアップ技術に関連する制御プログラム１０２８の動作のうち、本実施形態の説明に必要な動作について述べておく。

制御プログラム１０２８は、スナップショット、ジャーナル、マーカーの作成順序を管理する。これにより、データのリストアを行う際に、どのスナップショットにどのジャーナルをどのような順番で適用していけばよいのかが特定できるようになる。

具体的な作成順序の管理方法と利用方法は、例えば、次の通りである。

まず、この作成順序を管理するために、制御プログラム１０２８が、ジャーナルグループ１０１４毎に順序番号を管理している。

そして、制御プログラム１０２８は、ホスト計算機１１００からデータボリューム１０１１への書き込みを受け付けると、当該データボリューム１０１１に対して書込みを行う。このとき、制御プログラム１０２８は、書き込みデータをジャーナルとし、当該データボリューム１０１１が属するジャーナルグループ１０１４の順序番号を、当該ジャーナルに割り振る。そして、制御プログラム１０２８は、当該ジャーナルを、当該データボリューム１０１１が属するジャーナルグループ１０１４に関連付けられたジャーナルボリューム１０１３に、格納する。その後、制御プログラム１０２８は、当該ジャーナルグループ１０１４の順序番号に１を加算する。

また、制御プログラム１０２８は、後述するリカバリマネージャ１１６２やバックアップ指示プログラム１２５２からマーカー作成要求を受け付けると、マーカーを作成し、当該データボリューム１０１１が属するジャーナルグループ１０１４の順序番号を、当該マーカーに割り振る。そして、制御プログラム１０２８は、当該マーカーを、当該データボリューム１０１１が属するジャーナルグループ１０１４に関連付けられたマーカー管理テーブル１０３０（後述する）に、格納する。その後、制御プログラム１０２８は、当該ジャーナルグループ１０１４の順序番号に１を加算する。

さらに、制御プログラム１０２８は、後述するリカバリマネージャ１１６２やバックアップ指示プログラム１２５２からスナップショット取得要求を受け付けると、指定されたジャーナルグループ１０１４に属するデータボリューム１０１１のスナップショットを、当該ジャーナルグループ１０１４に関連付けられたＳＳＶＯＬグループ１０１５に属するスナップショットボリューム１０１２に、格納する。次に、制御プログラム１０２８は、当該ジャーナルグループ１０１４の順序番号を、スナップショットに割り振る。その後、制御プログラム１０２８は、当該ジャーナルグループ１０１４の順序番号に１を加算する。

以上の処理を、制御プログラム１０２８が行うことで、スナップショット、ジャーナル、マーカーの作成順序が、管理される。

この作成順序は、リストアの際に、制御プログラム１０２８によって利用される。制御プログラム１０２８は、この作成順序を用いて基底スナップショットに適用すべきジャーナルとその適用順序とを特定する。具体的には、特定のスナップショット(基底スナップショットとなる)にジャーナルを適用してリストアを行う場合、制御プログラム１０２８は、当該スナップショットより大きく且つ指定されたリカバリポイントのジャーナル以下の順序番号を持つジャーナルを、順序番号に従って適用する。また、リカバリポイントとしてマーカーを指定した場合は、制御プログラム１０２８は、基底スナップショットより大きく且つ指定されたリカバリポイントのマーカーより小さい順序番号を持つジャーナルを、順序番号に従って適用する。以上の処理を、制御プログラム１０２８が行うことでリストアが行われる。

管理情報群１０２９は、ジャーナリングを用いたバックアップの各種機能を実行するための情報であり、上述したように、例えば、どの論理ボリュームがデータボリューム１０１１なのか、どの論理ボリュームがスナップショットボリューム１０１２なのか等の論理ボリュームの種別を示す情報や、データボリューム１０１１がどのジャーナルグループ１０１４に所属しているのか等のボリューム間の関係性を示す情報が含まれる。

マーカー管理テーブル１０３０及びジャーナル管理テーブル１０３１については、後述する。

タイマ１０２４は、現在時刻を提供する機能を持つ一般的なタイマである。ジャーナル作成時やスナップショット取得時に、制御プログラム１０２８によって参照される。

データＩ／Ｆ１０２２は、データネットワーク１３００に対するインタフェースであって、一つ以上の通信用ポートを持つ。ディスクコントローラ１０２０は、このポートを介してホスト計算機１１００、他のストレージシステム１０００と、データや制御命令の送受信を行う。管理Ｉ／Ｆ１０２１は、管理ネットワーク１４００とのインタフェースであって、ホスト計算機１１００、管理計算機１２００と、データや制御命令の送受信を行う。ディスクＩ／Ｆ１０２５は、ディスク装置１０１０に対するインタフェースであって、データや制御命令の送受信を行う。

ホスト計算機１１００は、キーボードやマウスなどの入力装置１１４０、ＣＰＵ１１３０、ＣＲＴなどの表示装置１１２０、メモリ１１６０、データＩ／Ｆ１１１０、管理Ｉ／Ｆ１１５０を備える。

データＩ／Ｆ１１１０は、データネットワーク１３００に対するインタフェースであって、一つ以上の通信ポートを持つ。このポートを介して、ホスト計算機１１００は、ストレージシステム１０００と、データや制御命令の送受信を行う。管理Ｉ／Ｆ１１５０は、管理ネットワーク１４００に対するインタフェースであって、システム管理のために管理計算機１２００及びストレージシステム１０００と、データや制御命令の送受信を行う。

メモリ１１６０には、アプリケーション１１６１、リカバリマネージャ１１６２、整合性確認時間取得エージェント１１６３が記憶される。ＣＰＵ１１３０は、メモリ１１６０に記憶された各種プログラムを実行することで、各機能を実現する。

アプリケーション１１６１は、データボリューム１０１１を利用するアプリケーションプログラムであり、例えば、ＤＢＭＳやファイルシステムである。

リカバリマネージャ１１６２は、例えば、アプリケーション１１６１の静止化、ストレージシステム１０００に対するスナップショット取得の要求や特定時点のデータのリストア要求等を行うプログラムである。また、リカバリマネージャ１１６２は、アプリケーションの静止化などのイベントやユーザの指示に応じて、ストレージシステム１０００にマーカーの挿入を要求する。リカバリマネージャ１１６２は、ユーザや他のプログラムがこれらの機能を実行できるように、ユーザや他のプログラムに対するインタフェースとして、コマンドラインインタフェース(以降、「ＣＬＩ」と呼ぶ)などを提供する。

整合性確認時間取得エージェント１１６３は、後述する整合性確認時間モニタ１２５６の要求に従い、当該要求を受け付けた時点におけるデータボリューム１０１１内のデータの整合性を確認するために、アプリケーション１１６１が必要とする時間（以下、「整合性確認時間」）を取得するプログラムである。例えば、アプリケーション１１６１がOracle DBというＤＢＭＳであれば、整合性確認時間取得エージェント１１６３は、MTTR（Mean Time To Repair）アドバイザというツールから、クラッシュリカバリに必要な時間を、整合性確認時間として取得することができる。また、例えば、アプリケーション１１６１が一般的なファイルシステムであれば、他の作業にリソースが利用されていなければ、FSCKに必要な時間は主にファイル数(有効なi-nodeの数)に依存するため、整合性確認時間取得エージェント１１６３は、ファイル数ごとに過去のFSCKにかかった時間の実績値を保持しておくことで、現在のファイル数から整合性確認時間を推定することが可能である。また、ジャーナリングファイルシステムでは、ほぼ数秒単位でFSCKが完了することが知られているため、整合性確認時間は、数秒単位の時間となる。

また、整合性確認時間取得エージェント１１６３は、アプリケーションがＤＢＭＳである場合は、ＤＢＭＳがチェックポイントを発行するタイミング(データボリューム１０１１に反映されていないデータを全て反映させるタイミング)を、監視する。ＤＢＭＳがチェックポイントを発行すると、整合性確認時間取得エージェント１１６３は、整合性確認時間モニタ１２５６に整合性確認時間取得を指示する。

なお、説明の都合上、図１では、アプリケーション１１６３を一つとしたが、本実施形態ではこれ以上設置してもよい。

管理計算機１２００は、キーボードやマウスなどの入力装置１２４０、ＣＰＵ１２３０、ＣＲＴなどの表示装置１２２０、メモリ１２５０、管理Ｉ／Ｆ１２１０を備える。

管理Ｉ／Ｆ１２１０は、システム管理のために、ホスト計算機１１００及びストレージシステム１０００と、データや制御命令を送受信する。

メモリ１２５０には、設定プログラム１２５1、バックアップ指示プログラム１２５２、リカバリ指示プログラム１２５３、ＪＮＬＧ管理テーブル１２５４、ボリューム管理テーブル１２５５、整合性確認時間モニタ１２５６、モニタ管理テーブル１２５７が記憶される。ＣＰＵ１２３０は、メモリ１２５０に記憶された各種プログラムを実行することで、各機能を実現する。

設定プログラム１２５１は、JNLG管理テーブル１２５４、ボリューム管理テーブル１２５５、モニタ管理テーブル１２５７に値を設定するためのプログラムである。設定プログラム１２５１は、ユーザにこれらの値を設定させるためのインタフェースとして、ＣＬＩなどを提供する。

バックアップ指示プログラム１２５２は、一以上のジャーナルグループ１０１４の中から選択されたジャーナルグループ１０１４に属するアプリケーション１１６１群の静止化ポイントを、記録するためのプログラムである。ここで、ジャーナルグループ１０１４に属するアプリケーション１１６１群とは、当該ジャーナルグループ１０１４を構成する一以上のデータボリューム１０１１のうち、いずれか一つ又はそれ以上を利用するアプリケーションの集合体のことである。以降、ジャーナルグループに属するボリュームを利用するアプリケーションのことを、単に、「ジャーナルグループに属するアプリケーション」と呼ぶ。当該プログラムの動作の詳細は、後述する。

リカバリ指示プログラム１２５３は、ユーザの指示に従い、指示されたジャーナルグループ１０１４に属するアプリケーション１１６１を、指定された時点（リカバリポイント）におけるデータを用いてリカバリするためのプログラムである。当該プログラムの動作の詳細は、後述する。

整合性確認時間モニタ１２５６は、特定のジャーナルグループ１０１４に属するアプリケーション１１６１が、特定の時点におけるデータボリューム１０１１内のデータを用いてリカバリを行う際に、当該データの整合性確認を行うために必要な時間を取得するためのプログラムである。当該プログラムの動作の詳細は、後述する。

JNLG管理テーブル１２５４、ボリューム管理テーブル１２５５、モニタ管理テーブル１２５７の詳細は後述する。

以下、図２から図６まで、本実施形態に係る計算機システムが備える種々のテーブルの構成例を示す。なお、各図のテーブルにおいて、参照番号が付されているのは、カラム或いはフィールドを指し、カラム或いはフィールドに格納される値それ自体を指してはいない。従って、以下の説明では、カラム或いはフィールドを指す場合には、参照番号を付して説明し、カラム或いはフィールドを指しているわけではない場合には、参照番号を付さずに説明することにする。第二、第三の実施形態の説明においても同様とする。

図２は、JNLG管理テーブル１２５４の一例である。

当該テーブル１２５４は、アプリケーション１１６１がどのジャーナルグループ１０１４に属するかという対応関係を管理する。ＡＰ＿ＩＤ２００１は、当該計算機システムにおけるアプリケーション１１６１の識別子を格納するカラムである。JNLG_ID２００２は、前記アプリケーション１１６１が属するジャーナルグループ１０１４の識別子を格納するカラムである。ＡＰ管理用ネットワークアドレス２００３は、前記アプリケーション１１６１が稼動しているホスト計算機１１００のネットワークアドレスが格納されるカラムである。ＡＰ管理用ネットワークアドレス２００３に格納される値として、たとえばＩＰアドレスが用いられる。

JNLG管理テーブル１２５４における各情報要素の対応関係は、設定プログラム１２５１が提供するCLIを用いて、ユーザによって設定される。

図３は、ボリューム管理テーブル１２５５の一例である。

当該テーブル１２５５は、アプリケーション１１６１と当該アプリケーション１１６１が利用するデータボリューム１０１１との対応関係を管理する。ＡＰ＿ＩＤ３００１は、当該計算機システムにおけるアプリケーション１１６１の識別子を格納するカラムである。データボリュームＩＤ３００２は、前記アプリケーション１１６１が利用するデータボリューム１０１１のＩＤを格納するカラムである。ストレージ管理用ネットワークアドレス３００３は、前記データボリューム１０１１を格納するストレージシステム１０００のネットワークアドレスを格納するカラムである。ストレージ管理用ネットワークアドレス３００３に格納される値として、たとえばＩＰアドレスが用いられる。

ボリューム管理テーブル１２５５における各情報要素の対応関係は、設定プログラム１２５１が提供するCLIを用いて、ユーザによって設定される。

図４は、モニタ管理テーブル１２５７の一例である。

当該テーブル１２５７は、ジャーナルグループ１０１４に属するアプリケーション１１６１の整合性確認時間を取得する間隔を管理する。ＪＮＬＧ＿ＩＤ４００１は、取得の対象となるアプリケーション１１６１群が属するジャーナルグループ１０１４のＩＤを格納するカラムである。モニタ間隔４００２は、当該ジャーナルグループ１０１４に属するアプリケーション１１６１の整合性確認時間を取得する間隔を格納するカラムである。たとえば、モニタ間隔４００２に格納された値が、「60Sec」であれば、６０秒周期で整合性確認時間の取得が行われる。

モニタ管理テーブル１２５７における各情報要素の対応関係は、設定プログラム１２５１が提供するCLIを用いて、ユーザによって設定される。

図５は、マーカー管理テーブル１０３０の一例である。

当該テーブル１０３０は、マーカーを管理するテーブルである。また、当該テーブル１０３０はジャーナルグループ１０１４毎に管理されている。時刻５００１は、マーカーが作成された時刻を格納するカラムである。順序番号５００２は、当該マーカーに割り振られた順序番号を格納するカラムである。当該順序番号は、前述の通り、マーカーやジャーナルやスナップショットが作成された順序の関係を示す。データ５００３は、マーカーに付与されたテキストデータが格納されるカラムである。

マーカー管理テーブル１０３０にて管理されるマーカーは、例えば、以下のようにして作成される。すなわち、後述するリカバリマネージャ１１６１やバックアップ指示プログラム１２５２が、マーカーに付与すべきテキストデータをパラメータとして、制御プログラム１０２８にマーカー作成を要求する。作成要求を受けた制御プログラム１０２８は、タイマ１０２４から、例えば、マーカー作成の要求を受けた時の時刻を取得して時刻５００１に設定する。また、制御プログラム１０２８は、現在の順序番号を当該マーカーに割り振って、その順序番号を順序番号５００２に設定する。このとき、上述したように、制御プログラム１０２８がジャーナルグループ毎に管理している順序番号には、１が加算される。さらに、パラメータとして指定されたテキストデータを制御プログラム１０２８がデータ５００３に設定する。具体的には、「静止化ポイント」や「整合性確認時間(DB1:100Sec, DB2:150Sec, FS3:0Sec)」といったテキストデータ（テキストに限らず他の形式でもよい）である。

図６は、ジャーナル管理テーブル１０３１の一例である。

当該テーブル１０３１は、ジャーナルのメタデータを管理する。また、当該テーブルはジャーナルグループ毎に管理されている。時刻６００１は、ジャーナルが作成された時刻を格納するカラムである。順序番号６００２は、当該ジャーナルに割り振られた順序番号を格納するカラムである。当該順序番号は、前述の通り、マーカーやジャーナルやスナップショットが作成された順序の関係を示す。適用先ボリューム６００３は、ジャーナルを適用するデータボリューム１０１１の識別子を格納するカラムである。適用先アドレス６００４は、ジャーナルを適用するアドレスを格納するカラムである。格納ボリューム６００５は、当該ジャーナルが格納されているボリュームの識別子が格納されるカラムである。格納アドレス６００６は、当該ジャーナルが格納されているアドレスを格納するカラムである。データ長６００７は、当該ジャーナルの長さが格納されるカラムである。

これらのカラムには、ホスト計算機１１００からの書込みに対してジャーナルを作成するたびに、制御プログラム１０２８が、値を設定する。まず、制御プログラム１０２８は、タイマ１０２４から、例えば、ジャーナル作成の要求を受けた時の時刻を取得して時刻５００１に設定する。また、制御プログラム１０２８は、現在の順序番号を当該ジャーナルに割り振って、その順序番号を順序番号５００２に設定する。このとき、上述したように、制御プログラム１０２８がジャーナルグループ毎に管理している順序番号には、１が加算される。さらに、制御プログラム１０２８は、書き込み要求を参照し、書き込み先のデータボリューム１０１１の識別子を適用先ボリューム６００３に、書き込み先のアドレスを適用先アドレス６００４に、ジャーナルを格納するボリュームのＩＤを格納ボリューム６００５に、ジャーナルを格納するアドレスを格納アドレス６００６に、書き込みデータの長さをデータ長６００７に、それぞれ設定する。

尚、図１に示されてはいないが、メインメモリ１０２６には、スナップショットボリューム管理テーブル２４０００と、ＳＳＶＯＬグループ管理テーブル２５０００とが記憶される。

図２４は、スナップショットボリューム管理テーブル２４０００の構成例を示す。

スナップショットボリューム管理テーブル２４０００には、SSVOLグループ１０１５を構成するスナップショットに関する情報が記録される。例えば、各ＳＳＶＯＬグループ（スナップショットボリュームグループ）１０１５毎に、該SSVOLグループのＩＤ、該SSVOLグループに属するスナップショットボリュームのＩＤ、及び該SSVOLグループに対応付けられたデータボリュームのＩＤが格納される。具体的には、例えば、本テーブルには、SSVOLグループＩＤ２４００１、スナップショットボリュームＩＤ２４００２及び対応データボリュームＩＤ２４００３がある。

SSVOLグループＩＤ２４００１は、管理対象となるSSVOLグループの識別子が格納されるカラムである。

スナップショットボリュームＩＤ２４００２は、論理ボリューム(スナップショットボリューム)の識別子が格納されるカラムである。該カラムの各エントリ（セル）には、該エントリが対応するSSVOLグループIDが割り当てられたSSVOLグループに属するスナップショットボリュームのＩＤが格納される。

対応データボリュームＩＤ２４００３は、スナップショット取得対象のデータボリュームの識別子を格納する。該カラムの各エントリ（セル）には、該エントリが対応するSSVOLグループIDが割り当てられたSSVOLグループに対応付けられたデータボリュームのＩＤが格納される。

これらの値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いて、SSVOLグループにスナップショットボリュームとなる論理ボリュームを追加することで設定することが可能である。

図２５は、SSVOLグループ管理テーブル２５０００の構成例を示す。

SSVOLグループ管理テーブル２５０００には、ジャーナルグループ１０１４とSSVOLグループ１０１５の関連付けに関する情報が記録される。例えば、各ジャーナルグループ１０１４毎に、該ジャーナルグループのIDと、該ジャーナルグループに対応するSSVOLグループのIDと、該SSVOLグループに対応したスナップショットの順序番号と、該スナップショットの取得時刻とが記録される。具体的には、例えば、本テーブル２５０００には、JNLG_ID２５００１、SSVOLグループID２５００２、順序番号２５００３及び取得時刻２５００４がある。

JNLG_ID２５００１は、管理対象となるジャーナルグループの識別子が格納されるカラムである。

SVOLグループID２５００２は、JNLG_ID２５００１で示されるジャーナルグループのスナップショットを格納するSSVOLグループの識別子が格納される。

これらの値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いて、ジャーナルグループにSSVOLグループを関連付けることにより設定することが可能である。

順序番号２５００３は、当該スナップショットに割り振られた順序番号を格納するカラムである。当該順序番号は、前述の通り、マーカーやジャーナルやスナップショットが作成された順序の関係を示す。

取得時刻２５００４は、スナップショットが作成された時刻を格納するカラムである。

（２）第一の実施形態の動作。

次に、本実施形態の動作を説明する。

図７は、バックアップ指示プログラム１２５２の処理の流れを示したものである。

本処理では、連携する全アプリケーション１１６１にとって、データの整合性が保たれている時点が記録される。本処理は、ユーザがバックアップ指示プログラム１２５２を起動することで開始される。

本処理が起動されると、まずバックアップ指示プログラム１２５２は、静止化指示が発生するまで待機する（ステップ７０１０）。この静止化指示は、例えば、バックアップ指示プログラム１２５２が提供するＣＬＩを介して、ユーザやジョブスケジューラが静止化の要求を出したときに発生する。ユーザやジョブスケジューラは、当該ＣＬＩのパラメータとして、特定のジャーナルグループ１０１４を指定する。

静止化指示を受け付けると、バックアップ指示プログラム１２５２は、パラメータに指定されたジャーナルグループ１０１４に属する全てのアプリケーション１１６１を静止化する(ステップ７０２０)。静止化対象のアプリケーション１１６１は、ＪＮＬＧ管理テーブル１２５４を参照することで特定可能である。本ステップでは、バックアップ指示プログラム１２５２はリカバリマネージャ１１６２と通信を行い、リカバリマネージャ１１６２にアプリケーション１１６１の静止化指示を発行する。当該通信は、ＡＰ管理用ネットワークアドレスとリカバリマネージャ１１６２固有のポート番号とを利用することで確立される。

次に、バックアップ指示プログラム１２５２は、ステップ７０２０で指示した全てのアプリケーション１１６１の静止化が完了するまで待機する（ステップ７０３０）。

全てのアプリケーション１１６１の静止化の完了を確認した後に、バックアップ指示プログラム１２５２は、パラメータで指定されたジャーナルグループ１０１４の静止化ポイントとして、マーカーを挿入するように、制御プログラム１０２８に指示する（ステップ７０４０）。本ステップでは、バックアップ指示プログラム１２５２は、制御プログラム１０２８と通信を行い、マーカーの挿入指示を発行する。当該通信は、パラメータで指定されたジャーナルグループ１０１４に属するデータボリューム１０１１に対応するストレージ管理用ネットワークアドレス３００３のうちの一つと制御プログラム１０２８固有のポート番号とを利用することで確立される。当該指示を受け付けた制御プログラム１０２８は、前述したように、マーカーを作成し、マーカー管理テーブル１０３０へ格納する。

次に、バックアップ指示プログラム１２５２は、パラメータに指定されたジャーナルグループ１０１４に属する全てのアプリケーション１１６１の静止化を解除する(ステップ７０５０)。本ステップでは、前記ステップ７０２０と同様に、バックアップ指示プログラム１２５２はリカバリマネージャ１１６２と通信を行い、リカバリマネージャ１１６２に静止化解除指示を発行する。

次に、バックアップ指示プログラム１２５２は、ステップ７０５０で指示した全てのアプリケーション１１６１の静止化解除が完了するまで待機する（ステップ７０６０）。

そして、全アプリケーション１１６１の静止化解除が完了すると、バックアップ指示プログラム１２５２の処理は、ステップ７０１０に戻る。

以上が、バックアップ指示プログラム１２５２の処理の流れである。

図８は、整合性確認時間モニタ１２５６と整合性確認時間取得エージェント１１６３の処理の流れの一つを示したものである。

本処理では、アプリケーション１１６１毎の特定時点におけるデータボリューム１０１１内のデータの整合性を確認するために必要となる時間、すなわち、整合性確認時間が記録される。本処理は、ユーザが、パラメータとして特定のジャーナルグループ１０１４を指定して、整合性確認時間モニタ１２５６を起動することで開始される。

本処理が起動されると、まず整合性確認時間モニタ１２５６は、整合性確認時間の取得タイミングまで待機する（ステップ８０１０）。待機する時間は、パラメータに指定されたジャーナルグループ１０１４に対応するモニタ間隔４００２に基づいて決定される。たとえば、モニタ管理テーブル１２５７の当該ジャーナルグループ１０１４に対応するモニタ間隔４００２に格納されている値が、「６０Ｓｅｃ」となっている場合は、整合性確認時間モニタ１２５６は、６０秒間待機することとなる。

次に、整合性確認時間モニタ１２５６は、本ステップを処理する時点におけるデータボリューム１０１１内のデータの整合性確認時間の取得を、整合性確認時間取得エージェント１１６３に要求する(ステップ８０２０)。この要求は、パラメータに指定されたジャーナルグループ１０１４に属するアプリケーション１１６１が動作する全ホスト計算機１１００上の整合性確認時間取得エージェント１１６３に通知される。本ステップでは、整合性確認時間モニタ１２５６は整合性確認時間取得エージェント１１６３と通信を行う。当該通信は、ＡＰ管理用ネットワークアドレスと整合性確認時間取得エージェント１１６３固有のポート番号とを利用することで確立される。

整合性確認時間の取得指示を受け付けた整合性確認時間取得エージェント１１６３は、アプリケーションの整合性確認時間を取得し、取得した整合性確認時間を整合性確認時間モニタ１２５６へ通知する(ステップ８０３０)。当該整合性確認時間は、前述のとおりMTTRアドバイザなどを用いて取得される。

整合性確認時間モニタ１２５６は、アプリケーションの整合性確認時間の取得を指示した全整合性確認時間取得エージェント１１６３からの完了応答が返ってくるまで待機する(ステップ８０４０)。

全整合性確認時間取得エージェント１１６３からの完了応答が返ると、整合性確認時間モニタ１２５６は、パラメータで指定されたジャーナルグループ１０１４のマーカー管理テーブル１０３０に、取得した整合性確認時間情報をマーカーとして挿入するように、制御プログラム１０２８に指示する（ステップ８０５０）。ここで、マーカーに付与するテキストデータは、たとえば「整合性確認時間(DB1:100Sec, DB2:150Sec, FS3:0Sec)」といったものである。これは、識別子がＤＢ１であるアプリケーション１１６１の整合性確認時間が100秒、識別子がＤＢ２であるアプリケーション１１６１の整合性確認時間が150秒、識別子がＦＳであるアプリケーション１１６１の整合性確認時間が0秒である、ということを示す。その後、整合性確認時間モニタ１２５６の処理は、ステップ８０１０へ移行する。

以上が、性確認時間モニタ１２５６と整合性確認時間取得エージェント１１６３の処理の流れの一つである。

なお、ステップ８０５０において、整合性確認時間情報をマーカーとしてマーカー管理テーブル１０３０に格納したが、変形例として、整合性確認時間モニタ１２５６は適当な識別子をマーカーとして挿入するように指示し、当該識別子と整合性確認時間の対応関係をメモリ１２５０において管理しておくようにしても良い。

図９は、整合性確認時間取得エージェント１１６３と整合性確認時間モニタ１２５６の処理の流れの一つを示したものである。

本処理では、単一のＤＢＭＳがチェックポイントを発行するなどのタイミングに応じて、アプリケーション１１６１毎の当該時点におけるデータボリューム１０１１内のデータの整合性確認時間を記録する。本処理は、ユーザが、パラメータとして管理計算機１２００のネットワークアドレスを指定して、整合性確認時間取得エージェント１２５６を起動することで開始される。なお、本処理は、図８で示した処理と同一部分が含まれるため、同一部分の説明は省略する。

本処理が起動されると、まず整合性確認時間取得エージェント１１６３は、ＤＢＭＳのチェックポイント発行タイミングを監視する（ステップ９０１０）。

ＤＢＭＳがチェックポイントを発行すると、整合性確認時間取得エージェント１１６３は、整合性確認時間モニタ１２５６に、当該ＤＢＭＳが属するジャーナルグループ（静止化対象のジャーナルグループ）１０１４に属する全アプリケーション１１６１の整合性確認時間取得を要求する。この際、整合性確認時間取得エージェント１１６３は、パラメータで指定されたネットワークアドレスと整合性確認時間モニタ１２５６固有のポート番号とを用いて、整合性確認時間モニタ１２５６との通信を確立する（ステップ９０２０）。

整合性確認時間モニタ１２５６が当該要求を受け付けた以降のステップ８０２０から８０５０までは、前述した通りの処理を行う。

そして、整合性確認時間取得エージェント１１６３は、静止化対象のジャーナルグループ１０１４に属する全アプリケーション１１６１の整合性確認時間取得要求に対する整合性確認時間モニタ１２５６からの応答を待つ（ステップ９０３０）。そして、応答があり次第、整合性確認時間取得エージェント１１６３の処理は、ステップ９０１０へ進む。

以上が、性確認時間モニタ１２５６と整合性確認時間取得エージェント１１６３の処理の流れの一つである。これにより、ＤＢＭＳ等のアプリケーション１１６１による整合性確認時間が０となる時点を記録することができる。

図１０は、リカバリ指示プログラム１２５３の処理の流れを示したものである。

本処理は、ユーザが、パラメータとして特定のジャーナルグループ１０１４を指定して、リカバリ指示プログラム１２５３を起動することで開始される。

本処理が起動されると、まずリカバリ指示プログラム１２５３は、指定されたジャーナルグループ１０１４のリストア可能な時点の範囲を、制御プログラム１０２８から取得する（ステップ１００１０）。制御プログラム１０２８は、ＳＳＶＯＬグループ管理テーブル２５０００を参照することにより、リストア可能な時点の範囲を算出することができる。当該範囲は、例えば、「2006/11/10 0:00〜2006/11/15 11:00」といった形で表現される。

次にリカバリ指示プログラム１２５３は、指定されたジャーナルグループ１０１４のマーカー管理テーブル１０３０の情報を、制御プログラム１０２８から取得する（ステップ１００２０）。

次にリカバリ指示プログラム１２５３は、ステップ１００１０において取得したリストア可能な時点の範囲と、ステップ１００２０において取得したマーカーの情報を用いて、リカバリポイント選択画面をユーザにＧＵＩ(グラフィカルユーザインタフェース)で提示する(ステップ１００３０)。この表示形式の一例については、後述する。なお、変形例として、ＣＵＩ（キャラクタユーザインタフェース）で提示しても良い。

提示されたリカバリポイント選択画面から、ユーザがリカバリポイントを選択する（ステップ１００４０）。

次に、リカバリ指示プログラム１２５３は、選択されたリカバリポイントが静止化ポイントであるか否かを判定する(ステップ１００５０)。例えば、リカバリ指示プログラム１２５３は、ステップ１００２０において取得したマーカー管理テーブル１０３０の情報から、選択されたリカバリポイントが静止化ポイントであるか否かを判定する。

静止化ポイントである場合（ステップ１００５０：ＹＥＳ）、リカバリ指示プログラム１２５３は、パラメータとして指定されたジャーナルグループ１０１４のリストアを、制御プログラム１０２８へ指示する（ステップ１００６０）。当該指示は、ストレージ管理用ネットワークアドレス３００３と制御プログラム１０２８固有のポート番号とを用いて通信を確立することで実行される。制御プログラム１０２８は、当該指示を受け付けるとリストアを実行する。

次に、リカバリ指示プログラム１２５３は、ステップ１００６０において指示したリストアが完了するまで待機する（ステップ１００７０）。リストアが完了すると、リカバリ指示プログラム１２５３は、指定されたジャーナルグループ１０１４に属する全てのアプリケーション１１６１に対して整合性確認を行うように指示する（ステップ１００８０）。リカバリポイントが静止化ポイントである場合は、整合性確認の指示を受けたアプリケーション１１６１は、ＦＳＣＫ等のデータの整合性確認を行うことなく、ボリュームのマウントを行う。尚、リカバリポイントが静止化ポイントである場合は、リカバリ指示プログラム１２５３は、アプリケーション１１６１に対して整合性確認の指示をするのではなく、ボリュームのマウントを指示してもよい。

次にリカバリ指示プログラム１２５３は、ステップ１００８０において指示した整合性の確認が完了するまで待機し（ステップ１００９０）、当該整合性の確認が完了したら処理を終了する。

一方、ステップ１００５０において、リカバリポイントが静止化ポイントでないと判定された場合（ステップ１００５０：ＮＯ）、リカバリ指示プログラム１２５３は、アプリケーション１１６１毎の整合性確認時間を推定する(ステップ１０１００)。このときリカバリ指示プログラム１２５３は、ステップ１００２０において取得したマーカー管理テーブル１０３０の情報から、リカバリポイントから最も近い過去とリカバリポイントから最も近い未来との整合性確認時間が付与されマーカーを取得する(以降、過去のものを直前のマーカー、未来のものを直後のマーカーと呼ぶ)。そして、リカバリ指示プログラム１２５３は、この二つのマーカーからアプリケーション毎の整合性確認時間を推定する。例えば、アプリケーション１１６１がＤＢＭＳである場合は、一般に、クラッシュリカバリに必要となる時間は、特定の契機(通常はチェックポイント作成のタイミング)で０秒になり、その後、単調に増加する。このため、リカバリ指示プログラム１２５３は、直前のマーカーと直後のマーカーとが示す整合性確認時間から、整合性確認時間のおおよその変化量を計算して、それらの値からリカバリポイントにおける整合性確認時間を推定することができる。本実施形態では、リカバリ指示プログラム１２５３は、直前のマーカーにおける整合性確認時間と直後のマーカーにおける整合性確認時間の平均をリカバリポイントにおける整合性確認時間の推定値としている。変形例としては、リカバリポイントの時刻が、直前と直後のマーカーが挿入された時刻からどの程度はなれているかによって、重みをつけて、推定値が求められても良い。あるいは、直前のマーカーにおける整合性確認時間や直後のマーカーにおける整合性確認時間が、推定値として扱われても良い。また、直後のマーカーがない場合は、直前のマーカーに付与された整合性確認時間が、推定値とされても良い。また、アプリケーション１１６１が一般的なファイルシステムである場合は、直前のマーカーが示す整合性確認時間と直後のマーカーが示す整合性確認時間との平均値が、推定値となる。アプリケーション１１６１がジャーナリングファイルシステムである場合は、整合性確認時間がほぼ数秒である。

次にリカバリ指示プログラム１２５３は、整合性確認時間の推定値が最も長いアプリケーション１１６１が利用するボリュームを、リストアするように制御プログラム１０２８へ指示する(ステップ１０１１０)。制御プログラム１０２８は、当該指示を受け付けると、ジャーナリングを用いたリストアを実行する。

次にリカバリ指示プログラム１２５３は、ステップ１０１１０において指示したリストアが完了するまで待機する（ステップ１０１２０）。

リストアが完了すると、リカバリ指示プログラム１２５３は、ステップ１０１１０においてリストアを指示したボリュームを利用するアプリケーション１１６１に対して、整合性の確認を指示する（ステップ１０１３０）。

次にリカバリ指示プログラム１２５３は、まだリストアしていないボリュームがあるかを判断する（ステップ１０１４０）。全てリストア済みである場合（ステップ１０１４０：ＮＯ）、リカバリ指示プログラム１２５３の処理は、ステップ１００９０に進み、リカバリ指示プログラム１２５３は、ステップ１０１３０で指示した整合性確認が全て終了するまで待機する。整合性確認が全て終了すると、リカバリ指示プログラム１２５３は、処理を終了する。

一方、まだリストアが完了していないボリュームがある場合は（ステップ１０１４０：ＹＥＳ）、リカバリ指示プログラム１２５３は、先ほどリストアしたボリューム以外のボリュームの中で、そのボリュームを利用するアプリケーション１１６１の整合性確認時間の推定値が最も長いものをリストアするように、制御プログラム１０２８へ指示する(ステップ１０１５０)。その後、リカバリ指示プログラム１２５３の処理は、ステップ１０１２０へ進む。

以上が、リカバリ指示プログラム１２５３の処理の流れである。

なお、本実施形態では、ステップ１０１１０及びステップ１０１５０において、ボリュームのリストア指示は、単一アプリケーション１１６１毎に行われているが、変形例において、複数のアプリケーション１１６１が利用する複数のボリュームに対して、一括して行われてもよい。つまり、ＣＰＵ１０２３が複数存在するストレージシステム１０００など、特定のボリューム数まで並行にリストアしても個々のリストアの性能が劣化しないストレージシステム１０００が存在する。このストレージシステム１０００を利用する場合、性能が劣化しない上限まで、複数のボリュームを並行してリストアが行われても問題ない。このため、単一のアプリケーション１１６１が利用するボリューム数が当該上限数よりも小さい場合は、リカバリ指示プログラム１２５３は、リストアが行われるボリューム数が当該上限数を超えない範囲で、他のアプリケーション１１６１のボリュームをリストアするように指示することができる。なお、このときリストア対象のボリュームは、整合性確認時間の長いアプリケーション１１６１の順番に従って選択される。

また、本実施形態では、ステップ１０１００において、アプリケーション１１６１の整合性確認時間が推定され、その長さに応じて利用するボリュームのリストア順序が決定されたが、変形例として、アプリケーション１１６１のタイプで、当該アプリケーション１１６１が利用するリストア順序が決定されても良い。つまり、一般的なファイルシステムの整合性確認時間は一般的に長いため、一般的なファイルシステムが利用するボリュームが、優先的にリストアされるようにしてもよい。また、ジャーナリングファイルシステムの整合性確認時間は一般的に数秒であるため、ジャーナリングファイルシステムが利用するボリュームのリストアを後回しにするといった方法で、ボリュームのリストア順序が決定されても良い。

図１１Ａは、ステップ１００３０において、リカバリ指示プログラム１２５３がユーザに提示するＧＵＩの例である。

符号１１０１０は、リストア可能な時点の範囲を数直線で示した図である。符号１１０１２は、マーカーが挿入された時刻を示すアイコンである。本アイコン１１０１２は、マーカーに付与されたテキストデータの内容に応じて形や色を変更しても良い。符号１１０１３は、マウス等の入力装置によって移動するポインタである。ステップ１００４０において、ユーザがリカバリポイントの選択を行う際に移動させる。

符号１００２１は、マーカーに付与されているテキストデータを表示するテキストフィールドである。ユーザが、符号１１０１０の数直線上のアイコン１１０１２にポインタ１１０１３を移動させ、クリックすると、当該アイコン１１０１２に対応するマーカーに含まれているテキストデータが、このテキストフィールド１００２１に表示される。なお、アイコン１１０１２が存在しない数直線上の点をクリックされても、テキストフィールド１１０２１には何も表示されない。符号１１０２２は、リカバリポイントの時刻を表示するテキストフィールドである。ユーザが、符号１１０１０の数直線上の一点にポインタ１１０１３を移動させ、クリックすると、当該点に対応する時刻が、このテキストフィールド１１０２２に表示される。

符号１１０３１は、リカバリポイントの選択を確定するためのボタンである。ユーザが、本ボタン１１０３１を押下すると、テキストフィールド１１０２２に表示された時点のデータをリカバリすることが、リカバリ指示プログラム１２５３へ要求されたことになる。符号１１０３２は、図１０を用いて説明した処理を終了するためのボタンである。ユーザが、本ボタン１１０３２を押下すると、図１０を用いて説明した処理を終了することが、リカバリ指示プログラム１２５２へ要求されたことになる。本要求を受け取ったリカバリ指示プログラム１２５３は、処理を強制終了する。

以上が、ステップ１００３０において表示されるインタフェースの例である。

図１１Ｂは、ステップ１００３０において、リカバリ指示プログラム１２５３がユーザに提示するＧＵＩの別の例である。

符号１１０４０は、リストア可能な時点の範囲と複合アプリケーションの業務再開までの時間との関係を示した２次元グラフである。ここで、複合アプリケーションとは、連携して動作している複数のアプリケーション全体のことをいう。従って、複合アプリケーションの業務再開までの時間とは、連携して動作している複数のアプリケーションのそれぞれが利用する全てのボリュームについて、リカバリが完了するまでに要する時間となる。尚、リカバリにかかる時間は、リストアにかかる時間と整合性確認時間とを足し合わせたものである。当該グラフ１１０４０の横軸は、リストア可能な時刻を示す。当該グラフ１１０４０の縦軸は、複合アプリケーションの業務再開までの時間を示す。

符号１１０１２、１１０１３、１１０２１、１１０２２、１１０３１，１１０３２は、図１１Ａのものと同様なので、説明を省略する。

符号１１０２３は、複合アプリケーションの業務再開までの時間を表示するテキストフィールドである。ユーザが、横軸上の一点にポインタ１１０１３を移動させ、クリックすると、当該点に対応する複合アプリケーションの業務再開までの時間が、このテキストフィールド１１０２３に表示される。

なお、当該ＧＵＩでリカバリ時間を表示するためには、予め複合アプリケーションの業務再開までの時間を、算出しておく必要がある。このため、ステップ１００２０において、リカバリ指示プログラム１２５３が、ジャーナル管理テーブル１０３１の情報とジャーナル適用速度とを取得する。そして、リカバリ指示プログラム１２５３は、ジャーナル管理テーブル１０３１における適用先ボリューム６００３に格納された値と適用先アドレス６００４に格納された値とデータ長６００７に格納された値とを用いて、各時点の各ボリュームへのジャーナル適用量を算出する。また、リカバリ指示プログラム１２５３は、リストア可能な範囲にある各時点のボリュームのリストア順序を決定する。そして、リカバリ指示プログラム１２５３は、これらの情報を元に、実際にリカバリを行った場合の時間をシミュレートする。具体的には、まず、ボリューム毎のジャーナル適用量をジャーナル適用速度で割り、各ボリュームごとにリストアにかかる時間が算出される。この各ボリュームごとに算出されたリストアにかかる時間を、リストア順序どおり足し合わせることで、各ボリュームについて、実際にリストアが完了するまでにかかる時間（以下、「リストア完了時間」）が算出される。その後、各アプリケーション１１６１が利用するボリュームのリストア完了時間（各アプリケーション１１６１が複数のボリュームを利用している場合は、最長のリストア完了時間）に、そのアプリケーション１１６１の整合性確認時間の推定値が足し合わされて、各アプリケーション１１６１についてのリカバリにかかる時間が算出される。そして、複数のアプリケーション１１６１のリカバリにかかる時間の中で、最も長くなったものが、複数のアプリケーションが連携して動作する計算機システムの業務再開までの時間となる。

このように、リストアされたデータの整合性確認の時間が長いアプリケーション１１６１のデータを優先的にリストアし、他より早く完了させることにより、長い時間必要とする整合性確認処理ほど前倒しして実行できるようになる。また、当該整合性確認処理は、ホスト計算機１１００上で行われ、ストレージシステム１０００のリストア処理性能に影響を与えないため、他のアプリケーション１１６１のデータのリストアを、当該処理と並行して実行することもできる。この結果、複数のアプリケーション１１６１が連携して動作する計算機システムの業務再開までの時間を、短くすることが可能になる。

＜第二の実施形態＞。

次に第二の実施形態について説明する。

本実施形態は、ワークフローで疎に連携する複数のアプリケーションをリストアする例である。本実施形態におけるストレージシステムは、これらのアプリケーションのデータを格納するボリュームを備え、ジャーナリングを用いたバックアップ技術で、これをバックアップ(及びリストア)する。

当該計算機システムでは、複数のアプリケーションは、お互いに処理を呼び出すことはせず、独立して処理を行う。各アプリケーションは、処理が完了すると、ＦＴＰ（File Transfer Protocol）等で、次に処理を開始するアプリケーションが稼動しているホスト計算機へ、処理結果を転送する。そして、当該処理結果をインプットとして、次に処理を行うアプリケーションは、処理を開始する。このように、各処理が独立して順番に実行されるため、データ破壊などの障害発生時には、リカバリポイント直後に開始する処理を行うアプリケーションをリカバリすれば、業務を再開できる。なお、上記各処理のことをジョブと呼ぶ。また、ジョブの実行順序の定義をワークフローと呼ぶ。

ところで、前述したとおり、全ボリュームを一括してリストアすると、全ボリュームにとって、リストア完了までの時間が長くなる。この結果、全てのアプリケーションにとって、ジョブの開始時刻が遅くなり、業務再開までの時間が長くなってしまうという問題が発生する。

本実施形態では、この問題を解決するために、リカバリポイントを基点に、先にジョブが開始されるアプリケーションほど、リストアの優先度を高くする。これにより、リカバリ後すぐに処理を開始する必要があるアプリケーションほど、前倒ししてリカバリされるため、業務再開までの時間を短くすることが可能になる。

以下、本実施形態のシステム構成と動作を説明する。その際、第一の実施形態との相違点を主に説明し、第一の実施形態との共通点については、説明を省略或いは簡略する。

（１）第二の実施形態のシステム構成。

図１２は、本実施形態の計算機システムの構成を示すブロック図である。

本システムでは、第一の実施形態のシステム構成に、ジョブ管理計算機１２５００が追加されている。そして、ジョブ管理計算機１２５００は、管理ネットワーク１４００を介して、ストレージシステム１０００、ホスト計算機１１００、管理計算機１２００と接続される。

ストレージシステム１０００の構成は、第一の実施形態と同等であるため、説明を省略する。

ホスト計算機１１００のメモリ１１６０には、新たにジョブ管理エージェント１２１６３が記憶されている。また、メモリ１１６０に、整合性確認時間取得エージェント１１６３を記憶しておく必要はない。

ジョブ管理エージェント１２１６３は、後述するジョブ管理サーバ１２５６１の要求に応じて、アプリケーション１１６１のコマンドを実行するプログラムである。この動作の詳細は、後述する。

管理計算機１２００のメモリ１２５０には、バックアップ指示プログラム１２５２、整合性確認時間モニタ１２５６、モニタ管理テーブル１２５７を記憶しておく必要はない。

また、ＪＮＬＧ管理テーブル１２５４’に、新たにアプリケーション１１６１の稼働状況を管理できるようにする必要がある。本テーブル１２５４’の詳細は、後述する。

さらに、リカバリ指示プログラム１２５３’は、第一の実施形態とは異なり、制御プログラム１０２８からワークフローの進捗情報を、後述するジョブ管理サーバ１２５６１からワークフローファイル１２５６３の情報を、それぞれ取得し、指定されたリカバリポイントの直後に処理を行うアプリケーション１１６１のボリュームから、リカバリを開始していく。この動作の流れは、後述する。また、リカバリ指示プログラム１２５３’は、整合性確認開始指示プロセス１２５８を備える。整合性確認開始指示プロセス１２５８は、アプリケーション１１６１の状況、すなわち、そのアプリケーション１１６１が利用するボリュームのリカバリ状況を監視する。そして、整合性確認開始指示プロセス１２５８は、リカバリが完了したアプリケーション１１６１へ、整合性確認処理の開始を指示する。

ジョブ管理計算機１２５００は、キーボードやマウスなどの入力装置１２５４０、ＣＰＵ１２５３０、ＣＲＴなどの表示装置１２５２０、メモリ１２５６０、管理Ｉ／Ｆ１２５５０を備える。

管理Ｉ／Ｆ１２５５０は、システム管理のためにホスト計算機１１００、管理計算機１２００、ストレージ装置１０００とデータや制御命令を送受信する。

メモリ１２５６０には、ジョブ管理サーバ１２５６１、ワークフローファイル１２５６２、ワークフロー管理テーブル１２５６３が、記憶されている。ＣＰＵ１２５３０は、メモリ１２５６０に記憶された各種プログラムを実行することで、各機能を実現する。

ジョブ管理サーバ１２５６１は、ワークフローファイル１２５６２に定義されたジョブの実行順序に従い、ジョブを実行するアプリケーション１１６１が稼動するホスト計算機１１００のジョブ管理エージェントに、ジョブの開始を要求するプログラムである。また、ジョブ管理サーバ１２５６１は、ジョブ完了毎に、ワークフローの進捗を示すマーカーを挿入するように制御プログラム１０２８へ要求する。なお、本動作の詳細は、後述する。

ワークフロー管理テーブル１２５６３の詳細は、後述する。

図１３は、ワークフローファイル１２５６２の一例である。

ワークフローファイル１２５６２は、ワークフローの管理、すなわち、ジョブの実行順序の管理を行う。各ワークフローには、ジョブ管理計算機１２５００において、一意の識別子が割り振られている。実行順序１３００１には、本ワークフローで実行されるジョブの順序番号が、格納される。ＡＰ＿ＩＤ１３００２には、そのジョブを実行するアプリケーションのＩＤが、格納される。コマンド１３００３には、そのジョブのコマンドのＣＬＩが、格納される。ＡＰ管理用ネットワークアドレス１３００４には、ジョブを実行するホスト計算機のネットワークアドレスが、格納される。ＡＰ管理用ネットワークアドレス１３００４に格納される値として、たとえばＩＰアドレスが用いられる。これらの値は、ジョブ管理サーバ１２５６１が提供するＧＵＩを用いて、ユーザがワークフローの定義を行う際に設定される。

稼働状況１３００５には、ジョブを実行するアプリケーション１１６１の稼働状況が、格納される。稼働状況１３００５に格納される値としては、例えば、「稼働中」、「リカバリ中」のいずれか一方とすることができる。本実施形態では、ユーザがワークフロー定義を行った際に、ジョブ管理サーバ１２５６１によって、稼働状況１３００５に「稼働中」が、設定される。

図１４は、ワークフロー管理テーブル１２５６３の一例である。

本テーブル１２５６３は、ワークフローの進捗を管理する。ワークフローＩＤ１４００１は、管理対象となるワークフローの識別子を格納するカラムである。開始時刻１４００２は、ワークフローを開始するタイミングが格納されるカラムである。これらのカラムに格納される値は、ジョブ管理サーバ１２５６１が提供するＧＵＩを用いて、ユーザによって、ワークフロー定義を行う際に設定される。

進捗状況１４００３は、ワークフローの進捗状況を格納するカラムである。本カラム１４００３には、ワークフロー開始前であれば、例えば、「ＷＡＩＴ」が格納される。また、本カラム１４００３には、ワークフロー終了後であれば、例えば、「ＤＯＮＥ」が格納される。ワークフロー実行中であれば、例えば、開始直後には「０」が本カラム１４００３に格納され、その後、ジョブ完了するたびに、完了したジョブの実行順序が本カラム１４００３に格納される。

図１５は、ＪＮＬＧ管理テーブル１２５４’の一例である。

本テーブル１２５４’は、第一の実施形態とほぼ同等であるため、相違点を主に説明する。

ステータス１５００４は、アプリケーション１１６１の稼働状況を格納するカラムである。本カラム１２５４’には、例えば、「稼働中」、「リカバリ前」、「リストア完」のいずれかが格納される。

設定プログラム１２５１が提供するCLIを用いて、アプリケーション１１６１とジャーナルグループ１０１４の対応関係を設定する際に、本カラム１２５４’には「稼働中」が設定される。
（２）第二の実施形態の動作
次に、本実施形態の動作の説明を行う。

まず、ジョブ管理サーバ１２５６１とジョブ管理エージェント１２１６３のワークフロー実行時の処理の流れを、図１６を用いて説明する。本処理は、ジョブ管理サーバ１２５６１が提供するＣＬＩを用いて、ユーザが起動する。

ユーザによって起動されると、ジョブ管理サーバ１２５６１は、ワークフローの開始時間まで待機する（ステップ１６０１０）。本開始時間は、ワークフロー管理テーブル１２５６３に記憶されているものである。

開始時間になると、ジョブ管理サーバ１２５６１は、ワークフロー管理テーブル１２５６３における実行対象のワークフロー（以下、「実行対象ワークフロー」）の進捗状況１４００３に「０」を設定する(ステップ１６０１５)。

次に、ジョブ管理サーバ１２５６１は、実行対象ワークフローのワークフローファイル１２５６２を参照して、開始するジョブを実行するアプリケーション１１６１の稼働状況を確認し、「稼働中」で無ければ、稼働中になるまで待機する(ステップ１６０２０)。なお、開始するジョブは、実行中のワークフローにおいて、進捗状況１４００３に格納されている値に、「１」を加算した実行順序を持つジョブとなる。

稼働状況が「稼働中」になると、ジョブ管理サーバ１２５６１は、ジョブを開始するようにジョブ管理エージェント１２１６３へ指示する（ステップ１６０３０）。このとき、ジョブ管理サーバ１２５６１は、ＡＰ管理用ネットワークアドレスとジョブ管理エージェント１２１６３固有のポート番号とを用いて、ジョブ管理エージェント１２１６３と通信を確立し、ジョブ開始指示を伝える。また、ジョブ管理サーバ１２５６１は、ジョブ開始指示と併せて、実行するアプリケーション１１６１とそのＣＬＩ名を引き渡す。さらに、一つ前に完了したジョブの出力が存在する場合は、ジョブ管理サーバ１２５６１は、当該出力をジョブ管理エージェント１２１６３へ引き渡す。

ジョブ開始指示を受け取ったジョブ管理エージェント１２１６３は、ジョブを起動し（ステップ１６０４０）、その完了を待つ（ステップ１６０５０）。ジョブが完了すると、ジョブ管理エージェント１２１６３は、その出力と共にジョブ完了通知を、ジョブ管理サーバ１２５６１へ通知する。

完了通知を受け取ったジョブ管理サーバ１２５６１は、完了したジョブの実行順序を、実行対象ワークフローの進捗状況１４００３へ設定する(ステップ１６０６０)。

そして、ジョブ管理サーバ１２５６１は、ワークフローの進捗情報をマーカーとして挿入するように、制御プログラム１０２８へ要求する（ステップ１６０７０）。本要求に基づいて、例えば、「ワークフローＩＤ：２, 進捗状況：３」といったテキストデータが付与されたマーカーが作成される。これは、ワークフローＩＤが２のワークフロー内で実行順序が３までのジョブが完了しているという情報になる。

次に、ジョブ管理サーバ１２５６１は、ワークフロー内の全ジョブが終了したかを判定する(ステップ１６０８０)。ここでは、進捗状況１４００３に格納されている値と実行中ワークフローのワークフローファイル１２５６２に定義されているジョブの数とが同値であれば、ワークフロー内の全ジョブが完了したことが判明する。

ワークフロー内で未完了のジョブがある場合は（ステップ１６０８０：ＮＯ）、ジョブ管理サーバ１２５６１の処理は、ステップ１６０２０へ戻る。

一方、全ジョブが完了していた場合は（ステップ１６０８０：ＹＥＳ）、ジョブ管理サーバ１２５６１は、実行対象ワークフローの進捗状況１４００３へ「ＤＯＮＥ」を設定する（ステップ１６０９０）。

そして、ジョブ管理サーバ１２５６１は、ワークフローの完了情報をマーカーとして挿入するように、制御プログラム１０２８へ要求する（ステップ１６１００）。本要求に基づいて、例えば、「ワークフローＩＤ：２, 進捗状況：ＤＯＮＥ」といったテキストデータが付与されたマーカーが作成される。これは、ワークフローＩＤが２のワークフローが完了したことを示す。

以上が、ジョブ管理サーバ１２５６１とジョブ管理エージェント１２１６３のワークフロー実行時の処理の流れである。

次に、リカバリ指示プログラム１２５３’が、リカバリ指示を受け付けたときの処理の流れを、図１７を用いて説明する。

本処理は、ユーザが、パラメータとして特定のジャーナルグループ１０１４を指定して、リカバリ指示プログラム１２５３’を起動することで開始される。

ユーザにより本処理が起動されると、リカバリ指示プログラム１２５３’は、制御プログラム１０２８から、リストア可能範囲とマーカー管理テーブル１０３０の情報とを取得する。また、ユーザからリカバリポイントを受け付ける（ステップ１００１０〜１００４０）。本処理は、第一の実施形態と同様であるため、説明を省略する。

次に、リカバリ指示プログラム１２５３’は、ジョブ管理サーバ１２５６１から、ワークフローファイル１２５６２の情報とワークフロー管理テーブル１２５６３の情報とを取得する(ステップ１７００５)。なお、本ステップでは、リカバリ指示プログラム１２５３’は、予めリカバリ指示プログラム’に、ジョブ管理用計算機１２５００のＩＰアドレスとジョブ管理用サーバ固有のポート番号とを設定しておき、それらを用い、ジョブ管理サーバ１２５６１との通信を確立した後に、情報を取得する。

次に、リカバリ指示プログラム’は、リカバリ対象の全アプリケーション１１６１に対応する稼働状況とステータスを変更する（ステップ１７０１０）。本ステップでは、リカバリ指示プログラム１２５３’は、ＪＮＬＧ管理テーブル１２５４と指定されたジャーナルグループの識別子とから、リカバリ対象のアプリケーション１１６１を特定する。そして、リカバリ指示プログラム１２５３’は、特定されたアプリケーション１１６１に対応するステータス１５００４に、「リカバリ前」を設定する。次に、リカバリ指示プログラム１２５３’は、ジョブ管理サーバ１２５６１に、特定されたアプリケーション１１６１に対応する稼働状況１３００５に、「リカバリ中」を設定するように要求する。

次に、リカバリ指示プログラム１２５３’は、整合性確認開始指示プロセス１２５８を起動する（ステップ１７０２０）。本プロセスは、ＣＰＵ１２３０によって実行される。本プロセスの処理の流れは、後述する。

次に、リカバリ指示プログラム１２５３’は、リカバリポイントにおいて実行中のワークフローが存在するか否かを判定する（ステップ１７０３０）。本ステップの判定は、ステップ１００１０〜１００４０において取得したマーカー管理テーブル１０３０の情報から、リカバリポイント以前に挿入された進捗状況が記録されているマーカーのうち、最新の進捗状況が「ＤＯＮＥ」となっていないワークフローがあるか否かを検索することにより、行われる。

ステップ１７０３０において、実行中のワークフローが存在しないと判定された場合（ステップ１７０３０：ＮＯ）、リカバリ指示プログラム１２５３’は、指定されたジャーナルグループ１０１４に属する全ボリュームのリストアを、制御プログラム１０２８へ要求する(ステップ１７０４０)。

次に、リカバリ指示プログラム１２５３’は、ステップ１７０４０において要求したリストアが完了するまで待機する（ステップ１７０４５）。

リストアが完了したら、リカバリ指示プログラム１２５３’は、ステップ１７０４５においてリストアが完了したボリュームを利用する全アプリケーション１１６１に対応するステータス１５００４に、「リストア完」を設定し（ステップ１７０５０）、処理を終了する。

一方、ステップ１７０３０において、実行中のワークフローがあると判定された場合（ステップ１７０３０：ＹＥＳ）、リカバリ指示プログラム１２５３’は、リカバリポイント直後に実行するアプリケーション１１６１が利用するボリュームのリストアを、制御プログラム１０２８へ要求する（ステップ１７０６０）。リカバリポイント直後に実行するアプリケーション１１６１は、以下のようにして特定される。すなわち、まず、ステップ１７０３０で検索されたマーカーに付与されているテキストデータを参照して、リカバリポイント直後に実行するワークフローのワークフローＩＤと進捗状況とが取得される。次に、そのワークフローＩＤに対応するワークフローファイル１２５６２を参照して、進捗状況の値に１を加算した実行順序を持つジョブが、次に実行するジョブとして特定される。そのジョブを実行するアプリケーション１１６１が、リカバリポイント直後に実行されるアプリケーション１１６１である。また、リカバリポイント直後に実行するアプリケーション１１６１が利用するボリュームはボリューム管理テーブル１２５５から特定することができる。

次に、リカバリ指示プログラム１２５３’は、ステップ１７０６０において要求したリストアが完了するまで待機する（ステップ１７０７０）。

リストアが完了すると、リカバリ指示プログラム１２５３’は、ステップ１７０７０においてリストアしたボリュームを利用するアプリケーション１１６１に対応するステータス１５００４に、「リストア完」を設定する（ステップ１７０８０）。

次に、リカバリ指示プログラム１２５３’は、ジョブ管理サーバ１２５６１へ、ワークフローの再開を要求する（ステップ１７０９０）。このとき、リカバリ指示プログラム１２５３’は、ジョブ管理サーバ１２５６１へ、ステップ１７０６０で利用した進捗状況の値を、リカバリポイントにおける進捗状況として引き渡す。

次に、リカバリ指示プログラム１２５３’は、ワークフロー内に次に実行するジョブが存在するかを判定する(ステップ１７１００)。

ステップ１７１００において、存在しないと判定した場合（ステップ１７１００：ＮＯ）、リカバリ指示プログラム１２５３’は、指定されたジャーナルグループ１０１４に属するボリュームのうち、まだリストアしていないボリュームのリストアを、制御プログラム１０２８へ要求する(ステップ１７０４０)。

一方、ステップ１７１００において存在すると判定した場合（ステップ１７１００：ＹＥＳ）、次のジョブを行うアプリケーション１１６１のボリュームが、リストア済みであるか否かを判定する(ステップ１７１１０)。本判定では、ジョブを実行するアプリケーション１１６１に対応するステータス１５００４、「リカバリ前」が格納されている場合は、リストアされておらず、「リストア完」が格納されている場合は、リストア済みであると判定される。

ステップ１７１１０において、リストア済みと判定された場合は（ステップ１７１１０：ＮＯ）、リカバリ指示プログラム１２５３’の処理は、ステップ１７１００へ進む。一方、リストアされていないと判定された場合は（ステップ１７１１０：ＹＥＳ）、リカバリ指示プログラム１２５３’は、次にジョブを実行するアプリケーション１１６１が利用するボリュームのリストアを、制御プログラム１０２８へ要求する（ステップ１７１２０）。

次に、リカバリ指示プログラム１２５３’は、ステップ１７１２０において要求したリストアが完了するまで待機する（ステップ１７１３０）。

リストアが完了すると、リカバリ指示プログラム１２５３’は、ステップ１７１３０においてリストアしたボリュームを利用するアプリケーション１１６１に対応するステータス１５００４に、「リストア完」を設定する（ステップ１７１４０）。そして、リカバリ指示プログラム１２５３’の処理は、ステップ１７１００へ戻る。

以上が、リカバリ指示プログラム１２５３が、リカバリ指示を受け付けたときの処理の流れである。

なお、ステップ１７０４０〜１７０５０では、未リストアボリュームを纏めてリストアしたが、変形例として、ワークフローの実行順序が若いジョブのアプリケーション１１６１が利用するボリュームから順番にリストアし、利用するボリュームがリストア完了したアプリケーション１１６１から、そのアプリケーション１１６１に対応するステータス１６００４に、「リストア完」を設定していってもよい。

次に、ステップ１７０２０において起動された整合性確認開始指示プロセス１２５８の処理の流れを、図１８を用いて説明する。

本プロセスが起動されると、整合性確認開始指示プロセス１２５８は、ＪＮＬＧ管理テーブル１２５４のステータス１５００４に「リストア完」が格納されているアプリケーション１１６１が存在するか否かを判定する(ステップ１８０１０)。

ステップ１８０１０において、存在しない場合は（ステップ１８０１０：ＮＯ）、再びステップ１８０１０の判定が繰り返される。一方、存在すると判定された場合は（ステップ１８０１０：ＹＥＳ）、整合性確認開始指示プロセス１２５８は、その中の一つのアプリケーション１１６１に対して、整合性確認を行うように指示する（ステップ１８０２０）。なお、このとき、整合性確認開始指示プロセス１２５８は、ＡＰ管理用ネットワークアドレスと、ジョブ管理用サーバ固有のポート番号とを用い、アプリケーション１１６１との通信を確立した後に、整合性確認開始の指示を行う。

次に整合性確認開始指示プロセス１２５８は、ステップ１８０２０において指示した整合性確認が完了するまで待機する（ステップ１８０３０）。

整合性確認が完了したら、整合性確認開始指示プロセス１２５８は、整合性確認が完了したアプリケーション１１６１に対応する稼働状況１３００５へ「稼働中」を設定するように、ジョブ管理サーバ１２５６１へ指示する（ステップ１８０４０）。なお、この処理は、ＣＰＵ１２３０が、予めリカバリ指示プログラムに設定してあったジョブ管理用計算機のＩＰアドレスと、ジョブ管理用サーバ固有のポート番号とを用い、ジョブ管理サーバ１２５６１との通信を確立した後に行われる。

次に、整合性確認開始指示プロセス１２５８は、整合性確認が完了したアプリケーション１１６１に対応するステータス１５００４に、「稼働中」を設定する（ステップ１８０５０）。

次に、整合性確認開始指示プロセス１２５８は、リカバリ対象として指定されたジャーナルグループ１０１４に属するボリュームを利用する全てのアプリケーション１１６１が、稼働中となったか否かを判定する（ステップ１８０６０）。当該判定は、ＪＮＬＧ管理テーブル１２５４におけるステータス１５００４が参照されることにより行われる。

ステップ１８０６０において、全てのアプリケーションが稼働中であると判定された場合は（ステップ１８０６０：ＹＥＳ）、処理を終了する。一方、稼働中でないアプリケーション１１６１が存在する場合は、整合性確認開始指示プロセス１２５８の処理は、ステップ１８０１０へ戻る。

以上が、ステップ１７０２０において起動された整合性確認開始指示プロセス１２５８の処理の流れとなる。

以上が第二の実施形態の説明である。本実施形態によれば、リカバリ後すぐに処理を開始する必要があるアプリケーション１１６１ほど前倒ししてリカバリされるため、業務再開までの時間を短くすることが可能になる。

＜第三の実施形態＞。

次に第三の実施形態について説明する。

本実施形態に係る計算機システムは、コピーグループを一括バックアップする技術を用いてバックアップ及びリストアを行うストレージシステムを備える。当該ストレージシステムは、疎に連携する複数のアプリケーションのデータを格納するボリュームを備え、これらのボリュームを一括バックアップする。

当該計算機システムにおいても、第二の実施形態と同様の問題が発生する。

そこで、本実施形態では、この問題を解決するために、リカバリポイントを基点に、先にジョブが開始されるアプリケーションほど、リストアの優先度を高くし、リカバリ後すぐに処理を開始する必要があるアプリケーションほど前倒ししてリカバリさせる。これにより、業務再開までの時間を短くすることが可能になる。

以下、本実施形態のシステム構成と動作を説明する。

（１）第三の実施形態のシステム構成。

本実施形態のシステム構成の大部分は第二の実施形態のものと同じであるため、以降は相違点を主に説明する。

図１９は、本実施形態の計算機システムの構成を示すブロック図である。

当該構成のストレージシステム１０００のディスク装置には、一つ以上のコピーグループ１９０１３が格納されている。当該コピーグループ１９０１３は、一つ以上のデータボリューム１０１１と一つ以上のバックアップボリューム１９０１２とにより構成されている。データボリューム１０１１は、ホスト計算機１１００上で動作するアプリケーション１１６１により利用されるデータを格納する。バックアップボリューム１９０１２には、特定時点におけるデータボリューム内のデータのバックアップデータが格納される。

本実施形態における制御プログラム１０２８は、バックアップ指示プログラム１２５２から、コピーグループ１９０１３の一括バックアップを要求されると、コピーグループに１９０１３属する全てのデータボリューム１０１１の同一時点のデータをバックアップボリューム１９０１２へコピーする
なお、本実施形態では、ディスク装置１０１０内に、ジャーナルグループ１０１４、ＳＳＶＯＬグループ１０１５、スナップショットボリューム１０１２、ジャーナルボリューム１０１３は必要ない。

また、メインメモリ１０２６にマーカー管理テーブル１０３０、ジャーナル管理テーブル１０３１を記憶させる必要もない。

ホスト計算機１１００、ジョブ管理計算機１２５００に関しては、第二の実施形態と同等であるため、説明を省略する。

管理計算機上１２００のメモリ１２５０には、バックアップ指示プログラム１２５２’、リカバリ指示プログラム１２５３’’、コピーグループ管理テーブル１９２５４、バックアップ管理テーブル１９２５６、設定プログラム１２５１、ボリューム管理テーブル１２５５が、記憶される。

設定プログラム１２５１及びボリューム管理テーブル１２５５は、第一の実施形態で示したものと同様であるので、説明を省略する。

バックアップ指示プログラム１２５２’、リカバリ指示プログラム１２５３’’は、第一の実施形態のものとほぼ同等であるため、相違点を主に後ほど説明する。コピーグループ管理テーブル１９２５４、バックアップ管理テーブル１９２５６についても、後述する。

図２０は、コピーグループ管理テーブル１９２５４の一例である。

本テーブル１９２５４は、アプリケーション１１６１がどのコピーグループ１９０１３に属するかを管理する。ＡＰ＿ＩＤ２０００１は、本システムにおけるアプリケーション１１６１の識別子を格納するカラムである。ＣＧ＿ＩＤ２０００２は、アプリケーション１１６１が属するコピーグループ１９０１３の識別子を格納するカラムである。ＡＰ管理用ネットワークアドレス２０００３は、アプリケーション１１６１が稼動しているホスト計算機１１００のネットワークアドレスを格納するカラムである。ステータス２０００４はアプリケーション１１６１の稼働状況を格納するカラムである。本カラム２０００４には、例えば、「稼働中」、「リカバリ前」、「リストア完」のいずれかが格納される。

これらの値は、設定プログラム１２５１が提供するCLIを用いて、ユーザによって設定される。なお、ステータス２０００４には、設定プログラム１２５１によって、「稼働中」と設定される。

図２１は、バックアップ管理テーブル１９２５６の一例である。

本テーブル１９２５６は、バックアップに関する情報（以下、「バックアップ情報」）の管理を行う。ＣＧ＿ＩＤ２１００１は、バックアップデータ取得対象のコピーグループ１９０１３の識別子を格納するカラムである。取得時刻２１００２は、バックアップデータを取得した時刻を格納するカラムである。進捗状況２１００３は、コピーグループ１９０１３に属するアプリケーション１１６１を用いて実行されるワークフローの、バックアップデータ取得時点における進捗状況を格納するカラムである。このカラム２１００３には、例えば、「ワークフローＩＤ：２, 進捗状況：2」などが格納される。これは、このバックアップデータ取得時点において、ワークフローＩＤが２であるワークフローの二つ目のジョブまで終了していることを示す。

これらの値は、ユーザ等からバックアップ取得の要求を受け付けたバックアップ指示プログラム１２５２’によって、バックアップを取得した際に設定される。この動作の詳細は後述する。

（２）第三の実施形態の動作。

次に、本実施形態の動作の説明を行う。

本実施形態の動作の大部分は、第二の実施形態の動作と同じであるため、以降は相違点を主に説明する。

まず、バックアップ指示プログラム１２５２’の処理の流れを、図２２を用いて説明する。

本処理は、ユーザがバックアップ指示プログラム１２５２’を起動することで開始される。

本処理が起動されると、まずバックアップ指示プログラム１２５２’は、バックアップデータの取得指示が発生するまで待機する（ステップ２２０１０）。このバックアップデータの取得指示は、バックアップ指示プログラム１２５２’が提供するＣＬＩを用いることで発生させることができる。ユーザやジョブスケジューラは、当該ＣＬＩのパラメータとして、特定のコピーグループ１９０１３を指定する。

バックアップデータの取得指示を受け付けると、バックアップ指示プログラム１２５２’は、パラメータに指定されたコピーグループ１９０１３に属する全てのアプリケーション１１６１を静止化する(ステップ２２０２０)。静止化対象のアプリケーション１１６１は、コピーグループ管理テーブル１９２５４を参照することで特定可能である。本ステップでは、バックアップ指示プログラム１２５２’は、リカバリマネージャ１１６２と通信を行い、リカバリマネージャ１１６２にアプリケーション１１６１の静止化指示を発行する。当該通信は、ＡＰ管理用ネットワークアドレスとリカバリマネージャ１１６２固有のポート番号とを利用することで確立される。

次に、バックアップ指示プログラム１２５２’は、ステップ２２０２０で指示した全てのアプリケーション１１６１の静止化が完了するまで待機する（ステップ２２０３０）。

全てのアプリケーション１１６１の静止化の完了を確認した後に、バックアップ指示プログラム１２５２’は、ワークフローの進捗状況をジョブ管理サーバ１２５６１から取得する（ステップ２２０４０）。進捗状況の取得は、例えば、以下のようにして行われる。すなわち、バックアップ指示プログラム１２５２’は、ワークフロー（ワークフローＩＤ）を指定して、その進捗状況の取得要求を、ジョブ管理サーバ１２５６１へ通知する。取得要求を受けたジョブ管理サーバは、ワークフロー管理テーブル１２５６３を参照して、指定されたワークフローに対応する進捗状況の値を取得し、それをバックアップ指示プログラム１２５２’へ通知する。

次に、バックアップ指示プログラム１２５２’は、制御プログラム１０２８へ、パラメータに指定されたコピーグループ１９０１３に属するデータボリューム１０１１のデータを、バックアップするように要求する。（ステップ２２０５０）。

次に、バックアップ指示プログラム１２５２’は、バックアップ管理テーブル１９２５６を更新する（ステップ２２０６０）。ここでは、バックアップ指示プログラム１２５２’は、バックアップ対象となるコピーグループ１９０１３の識別子を、ＣＧ＿ＩＤ２１００１へ設定する。また、バックアップ指示プログラム１２５２’は、構成図には図示されていないタイマから現在時刻を取得し、この時刻を取得時刻２１００２へ設定する。さらに、バックアップ指示プログラム１２５２’は、ステップ２２０４０において取得したワークフローの進捗状況の値を、進捗状況２１００１へ設定する。

次に、バックアップ指示プログラム１２５２’は、パラメータに指定されたコピーグループ１９０１３に属する全てのアプリケーション１１６１の静止化を解除する(ステップ２２０７０)。本ステップでは、前記ステップ２２０２０と同様に、バックアップ指示プログラム１２５２’は、リカバリマネージャ１１６２と通信を行い、リカバリマネージャ１１６２に静止化解除指示を発行する。

次に、バックアップ指示プログラム１２５２’は、ステップ２２０７０で指示した全てのアプリケーション１１６１の静止化解除が完了するまで待機する（ステップ２２０８０）。そして、全アプリケーション１１６１の静止化解除完了を確認した後に、バックアップ指示プログラム１２５２’の処理は、ステップ７０１０に戻る。

以上が、バックアップ指示プログラム１２５２の処理の流れである。

次に、リカバリ指示プログラム１２５３’’が、リカバリ指示を受け付けたときの処理の流れを、図２３を用いて説明する。本処理は、ユーザが、パラメータとして特定のコピーグループ１９０１３を指定して、リカバリ指示プログラム１２５３’’を起動することで開始される。なお、本処理は、第二の実施形態で図１７を用いて説明した処理とほぼ同等であるため、以下、相違点を主に説明する。

ユーザにより本処理が起動されると、リカバリ指示プログラム１２５３’’は、バックアップ管理テーブル１９２５６から、パラメータとして指定されたコピーグループ１９０１３のバックアップ情報を検索し、その情報をリカバリ候補として、ユーザに提示する(ステップ２３０１０)。

次に、提示された候補から、ユーザは、リカバリポイントを選択する（ステップ２３０２０）。

リカバリポイントを受け付けたリカバリ指示プログラム１２５３’’は、ジョブ管理サーバ１２５６１から、ワークフローファイルの情報を取得する（ステップ２３０３０）。

以降、ステップ１７０１０からステップ１７０５０まで、第二の実施形態で図１７を用いて説明した処理と以下の点を除き実質的に同等である。すなわち、ステップ１７０１０やステップ１７０５０等において稼働状況情報を設定し、また、参照する箇所に関しては、ＪＮＬＧ管理テーブル１２５４のステータス１５００４ではなく、コピーグループ管理テーブル１９２５４のステータス２０００４に対して行われる。

以上が、リカバリ指示プログラム１２５３’’が、リカバリ指示を受け付けたときの処理の流れである。

以上が第三の実施形態の説明である。本実施形態によれば、複数アプリケーション１１６１のデータボリューム１０１１を一括バックアップする技術を用いてバックアップしたデータをリカバリする場合でも、リカバリ後すぐに処理を開始する必要があるアプリケーション１１６１ほど前倒ししてリカバリすることで、業務再開までの時間を短くなる。

以上、本発明の幾つかの実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

第一の実施形態におけるシステム構成を示す図である。 第一の実施形態におけるＪＮＬＧ管理テーブルの一例を示す図である。 第一の実施形態におけるボリューム管理テーブルの一例を示す図である。 第一の実施形態におけるモニタ管理テーブルの一例を示す図である。 第一の実施形態におけるマーカー管理テーブルの一例を示す図である。 第一の実施形態におけるジャーナル管理テーブルの一例を示す図である。 第一の実施形態におけるバックアップ指示プログラムの処理の流れを示す図である。 第一の実施形態における整合性確認時間モニタと整合性確認時間取得エージェントの処理の流れの一つを示す図である。 第一の実施形態における整合性確認時間取得エージェント１１６３と整合性確認時間モニタの処理の流れの別の一つを示す図である。 第一の実施形態におけるリカバリ指示プログラムの処理の流れを示す図である。 図１１Ａは、第一の実施形態にリカバリ指示プログラムがユーザに提示するＧＵＩの一例である。図１１Ｂは、第一の実施形態にリカバリ指示プログラムがユーザに提示するＧＵＩの別の一例である。 第二の実施形態におけるシステム構成を示す図である。 第二の実施形態におけるワークフローの一例を示す図である。 第二の実施形態におけるワークフロー管理テーブルの一例を示す図である。 第二の実施形態におけるＪＮＬＧ管理テーブルの一例を示す図である。 第二の実施形態におけるジョブ管理サーバとジョブ管理エージェントのワークフロー実行時の処理の流れを示す図である。 第二の実施形態におけるリカバリ指示プログラムが、リカバリ指示を受け付けたときの処理の流れを示す図である。 第二の実施形態における整合性確認開始指示プロセスの処理の流れを示す図である。 第三の実施形態におけるシステム構成を示す図である。 第三の実施形態におけるコピーグループ管理の一例を示す図である。 第三の実施形態におけるバックアップ管理テーブルの一例を示す図である。 第三の実施形態におけるバックアップ指示プログラムの処理の流れを示す図である。 第三の実施形態におけるリカバリ指示プログラムの処理の流れを示す図である。 スナップショットボリューム管理テーブルの一例を示す図である。 ＳＳＶＯＬグループ管理テーブルの一例を示す図である。

符号の説明

１０００…ストレージシステム、１１００…ホスト計算機、１２００…管理計算機、１２５００…ジョブ管理計算機

Claims (20)

1. ボリュームグループを構成する複数の論理ボリュームを有するストレージシステムにある前記論理ボリュームに格納されるデータのリカバリを制御する制御装置において、
   前記ボリュームグループを構成する異なる論理ボリューム内のデータをそれぞれ利用する複数のアプリケーションの各々の優先度を決定する優先度決定部と、
   前記ボリュームグループを構成する複数の論理ボリュームのうち、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、ストレージシステムにリストア指示を出すリストア指示部と、
   を備える制御装置。
2. 前記リストア指示部は、前記ボリュームグループに記録されたデータのリストアの場合、論理ボリューム単位でリストア指示を出すように構成されており、優先度の高いアプリケーションが利用する論理ボリュームを指定したリストア指示を、そのアプリケーションよりも優先度の低いアプリケーションが利用する論理ボリュームを指定したリストア指示よりも先に前記ストレージシステムに出す、
   請求項１記載の制御装置。
3. 指定した論理ボリュームにデータをリストアすることが完了した場合に、その論理ボリュームを利用するアプリケーションに整合性確認の指示を出す整合性確認指示部、
   を更に備える、
   請求項２記載の制御装置。
4. 前記複数のアプリケーションの各々について、アプリケーションが利用する論理ボリュームに格納されたデータの整合性確認に要する時間を取得する整合性確認時間取得部、
   を更に備え、
   前記優先度決定部は、前記整合性確認時間取得部が取得した前記複数のアプリケーションの各々の整合性確認に要する時間を参照して、前記整合性確認に要する時間の長いアプリケーションから順に高い優先度となるように、前記複数のアプリケーションの各々の優先度を決定し、
   前記リストア指示部は、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、リストア指示を出し、
   前記整合性確認指示部は、リストアが完了した論理ボリュームから順番に、その論理ボリュームを利用するアプリケーションに整合性確認の指示を出す、
   請求項３記載の制御装置。
5. 前記優先度決定部は、前記複数のアプリケーションの各々によって処理される複数のジョブが順番に実行される場合に、早く実行されるジョブを処理するアプリケーションほど高い優先度となるように、前記複数のアプリケーションの各々の優先度を決定し、
   前記リストア指示部は、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、リストア指示を出す、
   請求項１記載の制御装置。
6. 前記複数のアプリケーションの各々について、各々のアプリケーションが利用する論理ボリュームに格納されたデータの整合性確認に要する時間を取得する整合性確認時間取得部、
   を更に備え、
   前記優先度決定部は、
   前記複数のアプリケーションのうち、少なくとも二以上のアプリケーション同士がお互いの機能を利用して動作している場合は、前記整合性確認時間取得部が取得した前記複数のアプリケーションの各々の整合性確認に要する時間を参照して、前記整合性確認に要する時間の長いアプリケーションから順に高い優先度となるように、前記複数のアプリケーションの各々の優先度を決定し、
   前記複数のアプリケーションの各々によって処理される複数のジョブが順番に実行される場合は、早く実行されるジョブを処理するアプリケーションほど高い優先度となるように、前記複数のアプリケーションの各々の優先度を決定し、
   前記リストア指示部は、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、リストア指示を出し、
   前記整合性確認指示部は、リストアが完了した論理ボリュームから順番に、その論理ボリュームを利用するアプリケーションに整合性確認の指示を出す、
   請求項１記載の制御装置。
7. 前記複数のアプリケーションの各々によって処理される複数のジョブと前記複数のジョブの各々の実行順序とを記した実行順序情報を記憶するジョブ順序記憶領域と、
   前記複数のジョブごとに、どのジョブまで実行が完了したかを示す進捗情報を記憶するジョブ進捗記憶領域と、
   を更に備え、
   前記優先度決定部は、前記実行順序情報と前記進捗情報とを参照して、次に実行するジョブ及びその後のジョブの実行順序を特定し、早く実行されるジョブを処理するアプリケーションほど高い優先度となるように、前記複数のアプリケーションの各々の優先度を決定し、
   前記リストア指示部は、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、リストア指示を出し、
   前記整合性確認指示部は、リストアが完了した論理ボリュームから順番に、その論理ボリュームを利用するアプリケーションに整合性確認の指示を出す、
   請求項３記載の制御装置。
8. 前記ボリュームグループに、複数の論理ボリュームのそれぞれのバックアップ先の論理ボリュームである複数のバックアップボリュームを含み、前記複数のバックアップボリュームの各々に、バックアップを取得した時点において必ず整合性の保たれているデータが格納されている場合には、
   前記優先度決定部は、前記複数のアプリケーションの各々によって処理される複数のジョブの実行順序に基づいて、早く実行されるジョブを処理するアプリケーションほど高い優先度となるように、前記複数のアプリケーションの各々の優先度を決定し、
   前記リストア指示部は、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、リストア指示を出す、
   請求項１記載の制御装置。
9. 前記ボリュームグループは、ＣＤＰ（Continuous Data Protection）に関するグループである、
   請求項１記載の制御装置。
10. 前記整合性確認時間取得部は、前記整合性確認に要する時間を、前記複数のアプリケーションの各々の種別に基づいて推定する、
    請求項４記載の制御装置。
11. 前記整合性確認時間取得部は、前記複数のアプリケーションとして、ＤＢＭＳ、ジャーナリングファイルシステム及びジャーナリングファイルシステム以外のファイルシステムのうち、少なくとも二以上のアプリケーションが含まれていた場合には、前記推定された前記整合性確認に要する時間は、ジャーナリングファイルシステム以外のファイルシステムが最も長く、ＤＢＭＳがその次に長く、ジャーナリングファイルシステムが最も短い、
    請求項１０記載の制御装置。
12. 前記整合性確認時間取得部は、前記複数のアプリケーションがある種のＤＢＭＳを含む場合には、前記ある種のＤＢＭＳについての前記整合性確認に要する時間を、ＭＴＴＲアドバイザというツールから取得する、
    請求項１０記載の制御装置。
13. 前記整合性確認時間取得部は、前記アプリケーションがジャーナリングファイルシステム以外のファイルシステムを含む場合には、前記ジャーナリングファイルシステム以外のファイルシステムについての前記整合性確認に要する時間を、過去の実績値と現在のファイル数とから推定する、
    請求項１０記載の制御装置。
14. 前記整合性確認時間取得部は、前記複数のアプリケーションの各々についての整合性確認に要する時間を、リカバリが開始される前から、定期的又は不定期的に取得し、
    前記ストレージシステムは、
    前記複数の論理ボリュームの各々について、任意の時刻において取得されたスナップショットを格納する論理ボリュームであるスナップショットボリュームと、
    前記複数の論理ボリュームに対するデータの更新が行われるごとに、その更新内容を記すものとして取得されたジャーナルを格納する論理ボリュームであるジャーナルボリュームと、
    前記整合性確認に要する時間、前記スナップショット及び前記ジャーナルの各々について、それらが取得された時点の相互の順序関係を示す情報を管理する順序関係管理部と、
    前記整合性確認時間取得部が定期的又は不定期的に取得した、前記複数のアプリケーションの各々についての整合性確認に要する時間を含む整合性確認時間情報と、前記順序関係を示す情報とを対応付けて記憶する第一の記憶領域と、
    前記スナップショットボリュームへ格納されたスナップショットに関する情報と、前記順序関係を示す情報とを対応付けて記憶する第二の記憶領域と、
    前記ジャーナルボリュームへ格納されたジャーナルに関する情報と、前記順序関係を示す情報とを対応付けて記憶する第三の記憶領域と、
    を更に備える、
    請求項４記載の制御装置。
15. 前記整合性確認時間取得部は、
    指定された時刻に対応する前記整合性確認時間情報が、前記第一の記憶領域に記憶されている場合には、指定された時刻に対応する前記整合性確認時間情報から、指定された時刻における前記整合性確認に要する時間を取得し、
    指定された時刻に対応する前記整合性確認時間情報が、前記第一の記憶領域に記憶されていない場合には、前記第一の記憶領域に記憶されている一又は複数の整合性確認時間情報に基づいて、指定された時刻における前記整合性確認に要する時間を推定する、
    請求項１４記載の制御装置。
16. 前記整合性確認時間取得部は、
    指定された時刻に対応する前記整合性確認時間情報が、前記第一の記憶領域に記憶されていない場合には、前記第一の記憶領域から、指定された時刻の直前の前記整合性確認時間情報と指定された時刻の直後の前記整合性確認時間情報とを取得し、それぞれの情報に含まれる前記整合性確認に要する時間の平均値を、指定された時刻における前記整合性確認に要する時間と推定する、
    請求項１５記載の制御装置。
17. リストア可能な時刻の範囲を、ユーザに対して提示し、前記リストア可能な範囲内であってユーザから指定された時刻におけるリカバリに要する時間を、前記指定された時刻における整合性確認時間の推定値とリストアに要する時間とから計算し、ユーザに対して提示するユーザインタフェース部、
    を更に備える、
    請求項１５記載の制御装置。
18. ストレージシステムとデータのリカバリを制御する計算機とを備えた計算機システムにおいて、
    前記計算機が、
    ボリュームグループを構成する異なる論理ボリューム内のデータをそれぞれ利用する複数のアプリケーションの各々の優先度を決定する優先度決定部と、
    前記ボリュームグループを構成する複数の論理ボリュームのうち、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、ストレージシステムにリストア指示を出すリストア指示部と、
    を備え、
    前記論理ボリュームは、アプリケーションが利用するデータを格納した論理ボリュームであり、
    前記ストレージシステムが、
    前記ボリュームグループを構成する複数の論理ボリュームと、
    前記ボリュームグループに記録されたデータのリストアを実行するリストア実行部と、
    を備え、
    前記リストア実行部は、前記リストア指示部からのリストア指示に応答して前記ボリュームグループのうちの論理ボリュームにデータをリストアする、
    計算機システム。
19. ボリュームグループを構成する異なる論理ボリューム内のデータをそれぞれ利用する複数のアプリケーションの各々の優先度を決定し、
    前記ボリュームグループを構成する複数の論理ボリュームのうち、優先度の高いアプリケーションが利用する論理ボリュームから順番にリストアが実行されるように、ストレージシステムにリストア指示を出し、
    前記リストア指示部からのリストア指示に応答して前記ボリュームグループのうちの論理ボリュームにデータをリストアする、
    リカバリ制御方法。
20. 指定した論理ボリュームにデータをリストアすることが完了した場合に、その論理ボリュームを利用するアプリケーションに整合性確認の指示を出す、
    請求項１９記載のリカバリ制御方法。

Images