JP2007141043A - ストレージシステムにおける障害管理方法 - Google Patents

Abstract

【課題】ジャーナリングを用いたデータのバックアップ、リカバリと障害時の管理方法に関する。
【解決手段】所定の時刻を示すリカバリポイントを設定する第１のステップと、設定されたリカバリポイント時点のデータを復元するために必要なスナップショットとジャーナルデータとの対応情報を作成する第２のステップと、ディスク装置の障害の発生を検出する第３のステップと、ディスク装置の障害によって、データの復元が不可能となったリカバリポイントを検出する第４のステップと、を備える
【選択図】図１

Description

本発明はストレージシステムに関し、特に、ジャーナリングを用いたデータのバックアップ、リカバリと障害時の管理方法に関する。

従来、一般的に、情報資源を格納するストレージシステムは、バックアップを取得することで、装置の障害、コンピュータウィルスによるデータ破壊、ユーザによる誤操作等によるデータの喪失をリカバリできるようにしている。

データのリカバリの１つの手段として、ジャーナリングによるバックアップ及びリカバリ技術が提案されている。ジャーナリングとは、ストレージシステムで一般に使用されているバックアップ及びリストアの技術である。具体的には、ストレージシステムに格納されているバックアップの対象となるデータからデータイメージを取得する。そして、ホストからの要求によってデータが更新される毎に、更新データをジャーナルとして格納する。ストレージシステムは、このジャーナルから、ある指定時点におけるデータボリュームのデータイメージをリカバリすることが可能となる。

なお、ある指定時点におけるデータボリュームのデータイメージのことをスナップショットと称呼する。また、前述のジャーナリングを実現するために、いくつかのデータボリュームをまとめて運用する事が一般的に行われる。この運用の最小単位をジャーナルグループと呼称する。ストレージシステムは、リカバリが必要になった際には、ジャーナルをスナップショットに適用することで、任意の時点のデータを回復させることが可能である。

このような技術には次のようなものが知られている。あるジャーナルグループの特定時点のスナップショットを取得して、そのジャーナルグループに対するそれ以降の書き込みデータをジャーナルとして保持すること、及び、障害の発生などによりリカバリが必要になった際には、取得したスナップショットに対し、書き込まれた順序どおりにジャーナルを適用することで、特定時点のデータをリカバリできる（特許文献１参照）。

なお、データリカバリする際に、ユーザ等によって指定される特定の時点を、リカバリポイントと呼称する。
米国特許出願公開第２００５／００１５４１６号明細書

前述したようなジャーナリングを用いたバックアップ運用を用いる場合は、例えば、物理ディスクの障害等によってスナップショットが格納されるボリュームや、ジャーナルが格納されたボリュームにデータ損失が発生する場合がある。

このような障害が発生した場合は、ユーザは、バックアップ運用を停止して、障害の要因を取り除いた後、再度運用を開始する必要がある。これは、データ障害によって、リカバリポイントの無効による影響範囲がわからないためである。

ユーザの指定したリカバリポイントでのデータをリカバリするためには、指定されたリカバリポイントの直近の時点で取得されたスナップショットに対して、ユーザが指定したリカバリポイントに対応するジャーナルまでの全てのジャーナルを、書き込まれた順序どおりに適用する必要がある。従って、あるジャーナルを格納しているボリュームに障害が発生すると、そのジャーナルを利用してリカバリされる全てのリカバリポイントが失われる。しかしながら、それ以外のリカバリポイントは有効である。

本発明は、このような課題を鑑みてなされたものであり、スナップショット又はジャーナルを格納しているボリュームにデータ損失が発生した場合にも、バックアップ運用を停止せずに、データ損失によって無効になったリカバリポイント以外のリカバリポイントによってバックアップ運用を継続できる運用方法を提供することを目的とする。

本発明による一実施形態によると、所定の時刻を示すリカバリポイントを設定する第１のステップと、設定されたリカバリポイント時点のデータを復元するために必要なスナップショットとジャーナルデータとの対応情報を作成する第２のステップと、ディスク装置の障害の発生を検出する第３のステップと、ディスク装置の障害によって、データの復元が不可能となったリカバリポイントを検出する第４のステップと、を備えることを特徴とする。

本発明によると、スナップショット又はジャーナルを格納しているボリュームに障害が発生し、データの損失が発生した場合に、データ損失によって無効になったリカバリポイントを知ることができるので、バックアップ運用を停止せずに、無効となったリカバリポイント以外のリカバリポイントを用いてバックアップ運用を継続することが可能となる。

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

（第１実施形態）
図１は、本発明の第１の実施形態の計算機システムの構成ブロック図である。

本実施形態の計算機システムは、ストレージシステム１０００と、ホスト計算機１１００と、管理計算機１２００とを備える。

ストレージシステム１０００とホスト計算機１１００とは、データネットワーク１３００で互いに接続される。データネットワーク１３００はＳＡＮ（ストレージエリアネットワーク）が用いられる。なお、データネットワーク１３００は、これに限らず、ＩＰネットワークであっても、それ以外のデータ通信用ネットワークであってもよい。

ストレージシステム１０００及びホスト計算機１１００は、管理ネットワーク１４００を介して管理計算機１２００と接続される。管理ネットワーク１４００はＩＰネットワークが用いられる。なお、管理ネットワーク１４００は、ストレージエリアネットワークであっても、それ以外のデータ通信用ネットワークであってもよい。また、データネットワーク１３００と管理ネットワーク１４００とが、物理的又は論理的に同一のネットワークであってもよい。また、管理計算機１２００とホスト計算機１１００とが、同一の計算機上で実現されていてもよい。

なお、説明の都合上、図１では、ストレージシステム１０００を１つ、ホスト計算機１１００を１つ、管理計算機１２００を１つ示したが、これらの数は問わない。

ストレージシステム１０００は、データを格納するディスク装置１０１０と、ディスク装置１０１０へのデータの入出力を制御するディスクコントローラ１０２０とを備える。

ディスク装置１０１０は、データの格納領域である複数のデータボリューム１０１１を備える。なお、ＲＡＩＤ構成によってデータボリューム１０１１を構成してもよい。また、データボリューム１０１１が物理ディスクドライブであってもよく、本実施の形態ではデータボリューム１０１１の種類を問わない。

このデータボリューム１０１１によって、ジャーナルグループ１０１４、ＳＳＶＯＬグループ１０１５及びジャーナルボリューム１０１３が構成される。

ジャーナルグループ１０１４は、一つ以上のデータボリューム１０１１を含んだデータを格納する領域である。このジャーナルグループ１０１４のデータボリューム１０１１は、ホスト計算機１１００からの書き込みデータを格納する。

なお、ジャーナルグループ１０４１は、論理的な記憶領域で、ジャーナリングを実現するためにいくつかのデータボリューム１０１１をまとめたものである。また、ジャーナルグループ１０１４は、複数の論理的な記憶領域である運用ボリュームの集合で、運用ボリュームをホスト計算機のアプリケーションのデータを格納するために提供する場合もある。その場合は、運用ボリュームは一以上のデータボリュームで構成される。

ホスト計算機１１００からのアクセスによって生成されるジャーナルを用いたスナップショット及びリカバリを実現するために、いくつかのデータボリューム１０１１をまとめて運用する必要がある。この運用の最小単位をジャーナルグループと呼称する。図１では、ジャーナルグループ１０１４には二つのデータボリュームが示されているがその数は問わない。また、ジャーナルグループ１０１４の数も問わない。

スナップショットボリュームグループ（ＳＳＶＯＬグループ）１０１５は、ジャーナルグループ１０１４の複製イメージを格納する領域である。ＳＳＶＯＬグループ１０１５は、ある時点におけるジャーナルグループ１０１４の複製イメージ（スナップショットと呼ぶ）を格納する領域であるスナップショットボリューム１０１２を含む。このスナップショットボリューム１０１２は、データボリューム１０１１によって構成される。

スナップショットとは、ジャーナルグループ１０１４の、ある指定時点でのデータイメージである。なお、管理者の要求によって、一つのジャーナルグループ１０１４に対して、複数世代のスナップショットボリューム１０１２を設定できる。例えば、あるジャーナルグループ１０１４に対して、特定の時刻、具体的には、１２：００の時点、１８：００の時点及び２４：００の時点、の三つのスナップショットを、それぞれ別個のスナップショットボリューム１０１２として、ＳＳＶＯＬグループ１０１５に格納することができる。なお、図１では、スナップショットボリューム１０１２には二つのデータボリュームが示されているが、その数は問わない。

なお、スナップショットボリューム１０１２に格納される複製イメージは、システムに対する要求や実装等に応じてさまざまな形態を用いることができる。例えば、スナップショットボリューム１０１２に、ジャーナルグループ１０１４の全てのデータボリューム１０１１に対応するバックアップイメージを格納してもよいし、スナップショットボリューム１０１２に、各データボリューム１０１１に対応する差分バックアップのような論理的なデータイメージを格納してもよい。

ジャーナルボリューム１０１３は、ジャーナルグループ１０１４に対するジャーナルを格納する格納領域である。ジャーナルボリューム１０１３は、一つ以上のデータボリューム１０１１を含む。このデータボリューム１０１１にジャーナルが格納される。なお、図１では、二つのジャーナルグループ１０１４それぞれに対応する二つのジャーナルボリューム１０１３が示されているが、その数は問わない。

ディスクコントローラ１０２０は、ホスト計算機１１００からジャーナルグループ１０１４に含まれるデータボリューム１０１１に書き込み要求があった場合は、そのデータボリューム１０１１に書き込みを処理する。このとき、書き込みに要求に対応する適切な順序番号を付与したジャーナルを生成して、ジャーナルグループ１０１４に関連付けられたジャーナルボリューム１０１３に格納する。また、ホスト計算機１１００からの要求に従って、ジャーナルグループ１０１４とジャーナルボリューム１０１３とから、スナップショットボリューム１０１２を生成する。

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

メモリ１０２１は、各種プログラムや管理データ等を格納する記憶装置である、例えばＲＡＭ等によって構成される。

ホストＩ／Ｆ１０２２は、データネットワーク１３００に接続するインターフェースである。ホストＩ／Ｆ１０２２は、ホスト計算機１１００とデータや制御命令を送受信する。

ＣＰＵ１０２３は、ローカルディスク１０２７に格納されているプログラムをメモリ１０２１に読み込んで、そのプログラムを実行することによって、そのプログラムに規定された処理を実行する。

タイマ１０２４は、現在時刻を提供する機能を備える。タイマ１０２４は、ディスクコントローラ１０２０おいて、例えば、ジャーナルの作成やスナップショットの取得のときに、ストレージマイクロプログラム１０２８によってその現在時刻が参照される。

ディスクＩ／Ｆ１０２５は、ディスク装置１０１０に接続するインターフェースである。ディスクＩ／Ｆ１０２５は、ディスク装置１０１０とデータや制御命令を送受信する。

管理Ｉ／Ｆ１０２６は、管理ネットワーク１４００に接続するインターフェースである。管理Ｉ／Ｆ１０２６は、ホスト計算機１１００及び管理計算機１２００とデータや制御命令を送受信する。

ローカルディスク１０２７は、例えばハードディスクなどの記憶装置である。このローカルディスク１０２７は、ストレージマイクロプログラム１０２８、障害管理プログラム１０３５等を格納する。

ストレージマイクロプログラム１０２８は、スナップショットの取得、ジャーナルの生成、ジャーナルを用いたリカバリ、ジャーナルの開放といった、ジャーナリングによる機能を制御する。ストレージマイクロプログラム１０２８は、この制御のときに、管理テーブル１０２９の情報を参照及び更新する。また、ストレージマイクロプログラム１０２８は、管理計算機１２００やホスト計算機１１００からの要求に基づいて、ディスク装置１０１０に対するデータの入出力の制御、ストレージ装置内の制御情報の設定、及び、制御情報の提供、等の各種制御を実行する。

管理テーブル１０２９は、ストレージマイクロプログラム１０２８によって管理される情報である。管理テーブル１０２９には、ジャーナルグループ１０１４、ジャーナルボリューム１０１３及びＳＳＶＯＬグループ１０１５に関する情報、ディスク装置１０１０の障害に関する情報等が格納される。

障害管理プログラム１０３５は、ディスク装置１０１０の障害を監視する。障害管理プログラム１０３５は、ディスク装置１０１０のデータボリューム１０１１の障害を検知すると、ボリューム障害テーブル２０００を作成する。そして、管理計算機１２００に対して、ボリューム障害テーブル２０００を、ボリューム障害イベントとして通知する。

なお、ストレージマイクロプログラム１０２８及び障害管理プログラム１０３５は、ローカルディスク１０２７ではなく、ディスク装置１０１０内の任意のボリューム１０１１に格納してもよい。また、ディスクコントローラ１０２０にフラッシュメモリ等の記憶装置を設け、そこに格納してもよい。

ホスト計算機１１００は、ストレージＩ／Ｆ１１１０、表示装置１１２０、ＣＰＵ１１３０、入力装置１１４０、管理Ｉ／Ｆ１１５０、メモリ１１６０及びローカルディスク１１７０を備える。

ストレージＩ／Ｆ１１１０はデータネットワーク１３００に接続するインターフェースである。ストレージＩ／Ｆ１１１０は、ストレージシステム１０００とデータや制御命令を送受信する。

表示装置１１２０は、ＣＲＴディスプレイ装置等によって構成され、ホスト計算機１１００で実行される処理の内容を表示する。

ＣＰＵ１１３０は、ローカルディスク１１７０に格納されているプログラムをメモリ１１６０に読み込んで、そのプログラムを実行することによって、そのプログラムに規定された処理を実行する。

入力装置１１４０は、キーボードやマウス等の入力デバイスによって構成され、管理者の操作によって、ホスト計算機１１００に指示や情報を入力する。

管理Ｉ／Ｆ１１５０は、管理ネットワーク１４００に接続するインターフェースである。管理Ｉ／Ｆ１１５０は、ストレージシステム１０００及び管理計算機１２００とデータや制御命令を送受信する。

メモリ１１６０は、各種プログラムや管理データ等を格納する記憶装置である、例えばＲＡＭ等によって構成される。

ローカルディスク１１７０は、例えばハードディスクなどの記憶装置である。ローカルディスク１１７０は、システム構成定義ファイル１１７１、アプリケーション１１６３、リカバリマネージャ１１６２、情報収集エージェント１１６１等を格納する。

システム構成定義ファイル１１７１は、アプリケーション１１６３がどのデータボリューム１０１１利用するか、データボリューム１０１１がどのジャーナルグループ１０１４に属するか等のシステムの構成定義を格納する。システム構成定義ファイル１１７１は、システム構築時に管理者によって設定される。例えば、Ｌｉｎｕｘオペレーティングシステムのシステム構築時に用いられる/etc/fstabファイルが、システム構成定義ファイルに該当する。

アプリケーション１１６３、リカバリマネージャ１１６２及び情報収集エージェント１１６１はプログラムであって、ＣＰＵ１１３０によってメモリ１１６０に読み込まれ、それぞれに規定された機能が実行される。

アプリケーション１１６３は、データボリューム１０１１にデータの読み書きを要求する。アプリケーション１１６３は、例えば、ＤＢＭＳやファイルシステムである。なお、ホスト計算機１１００において、複数のアプリケーション１１６３が同時に実行されていてもよい。

リカバリマネージャ１１６２は、ストレージマイクロプログラム１０２８に対するスナップショット取得、ストレージマイクロプログラム１０２８に対する特定時点のデータのリカバリ、及び、アプリケーション１１６３の静止化を要求する。また、リカバリマネージャ１１６２は、データネットワーク１３００を介して、ストレージシステム１０００の管理テーブル１０２９に、ジャーナリングを用いたバックアップに関する設定をする。これらの機能は、管理者や他のプログラムから実行されるように、コマンドラインインターフェース（Command Line Interface：以降、「ＣＬＩ」と呼ぶ）によって提供される。

情報収集エージェント１１６１は、ホスト計算機１１００のシステム構成情報を収集するプログラムである。情報収集エージェント１１６１は、管理計算機１２００の要求に応じて、ローカルディスク１１７０に格納されているシステム構成定義ファイル１１７１から、アプリケーション１１６３が利用しているジャーナルグループ１０１４が属するストレージシステム１０００及びジャーナルグループ１０１４を特定する。そして、特定したストレージシステム１０００の識別子とジャーナルグループの識別子１０１４を、管理計算機１２００に送信する。

管理計算機１２００は、管理Ｉ／Ｆ１２１０、表示装置１２２０、ＣＰＵ１２３０、入力装置１２４０、メモリ１２５０及びローカルディスク１２６０を含む。

管理Ｉ／Ｆ１２１０は、管理ネットワーク１４００に接続するインターフェースである。管理Ｉ／Ｆ１２１０は、ストレージシステム１０００及びホスト計算機１１００とデータや制御命令を送受信する。

表示装置１２２０は、ＣＲＴディスプレイ装置等によって構成され、管理計算機１２００で実行される処理の内容を表示する。

ＣＰＵ１２３０は、ローカルディスク１２６０に格納されているプログラムをメモリ１２５０に読み込んで、そのプログラムを実行することによって、そのプログラムに規定された処理を実行する。

入力装置１２４０は、キーボードやマウス等の入力デバイスによって構成され、管理者の操作によって、管理計算機１２００に指示や情報を入力する。

メモリ１２５０は、各種プログラムや管理データ等を格納する記憶装置である、例えばＲＡＭ等によって構成される。

ローカルディスク１２６０は、例えばハードディスクなどの記憶装置である。ローカルディスク１２６０は、管理プログラム１２６５、バックアッププログラム１２６３を格納する。

バックアップ管理情報１２６４は、バックアップ管理を行うための情報、スナップショット及びリカバリポイントを格納するテーブルである。バックアップ管理情報１２６４は、管理プログラム１２６５によってメモリ１２５０に作成される。

管理プログラム１２６５は、本実施の形態の計算機システム全体の管理情報を設定する。管理プログラム１２６５は、グラフィカルユーザインタフェース（ＧＵＩ）を備え、ユーザから設定の指示を受ける。また、バックアッププログラム１２６３から情報を受け取って、バックアップ管理情報１２６４を設定する。

バックアッププログラム１２６３は、ストレージシステム１０００のディスク装置１０１０にリカバリポイントを作成し、また、スナップショットによるリストアに関する機能を制御する。

次に、ボリューム障害テーブル２０００について説明する。

図２は、ボリューム障害テーブル２０００の一例の説明図である。

ボリューム障害テーブル２０００は、障害管理プログラム１０３５によって生成されて、管理計算機１２００に送信される情報である。ボリューム障害テーブル２０００は、発生時刻フィールド２００１及び障害ボリュームＩＤフィールド２００２を含むエントリ２００３を含む。

発生時刻フィールド２００１は、障害が発生した時刻を格納する。障害ボリュームＩＤフィールド２００２は、障害が発生したデータボリューム１０１１の識別子（ボリュームＩＤ）を格納する。

ストレージシステム１０００において、障害管理プログラム１０３５は、ディスク装置１０１０の障害を監視している。障害管理プログラム１０３５がディスク装置１０１０内のボリュームの障害を検知すると、その時点の時刻をタイマ１０２４からから取得して、エントリ２００３の発生時刻フィールド２００１に設定する。そして、障害が発生したデータボリュームのボリュームＩＤを取得して、障害ボリュームＩＤフィールド２００２に設定する。

なお、ディスク装置内のボリューム障害としては、ディスクドライブの物理的な障害や、論理ボリュームの論理的な障害、例えば、構成情報に異常がありデータの読み書き正常でない場合など、さまざまな障害が考えられる。

そして、障害管理プログラム１０３５は、ボリューム障害テーブル２０００を、管理計算機１２００の管理プログラム１２６５に対して、ボリューム障害イベントとして通知する。なお、通知の方法には、ＳＮＭＰ（Simple Network Management Protocol）トラップを用いるが、これ以外の方法を用いてもよい。

次に、ストレージシステム１０００に格納される管理テーブル１０２９について説明する。

管理テーブル１０２９は、図３のジャーナルグループテーブル３０００、図４のジャーナルボリュームテーブル４０００及び図５のスナップショットテーブル５０００を含んだテーブル群である。

図３は、管理テーブル１０２９に含まれるジャーナルグループテーブル３０００の一例の説明図である。

ジャーナルグループテーブル３０００は、ジャーナルグループの識別子を格納する。ジャーナルグループテーブル３０００は、ＪＮＬグループＩＤフィールド３００１、順序カウンタフィールド３００２及びボリュームＩＤフィールド３００３を含むエントリ３００４を含む。

ＪＮＬグループＩＤフィールド３００１は、ジャーナルグループ１０１４の識別子（ＪＮＬグループＩＤ）を格納する。順序カウンタフィールド３００２は、ジャーナル及びスナップショット作成順序を管理するための番号を格納する。ボリュームＩＤフィールド３００３は、ジャーナルグループ１０１４に含まれるデータボリューム１０１１のボリュームＩＤを格納する。

ＪＮＬグループＩＤフィールド３００１及びボリュームＩＤフィールド３００３は、計算機システム構築時に、管理者が、ホスト計算機１１００のリカバリマネージャ１１６２が提供するＣＬＩを用いて設定する。これによって、ジャーナルグループ１０１４がどのデータボリューム１０１１によって構成されるかを管理する。

順序カウンタフィールド３００２に格納される値は、ストレージマイクロプログラム１０２８がホスト計算機１１００からの書き込みに対してジャーナルを生成するたびに、ストレージマイクロプログラム１０２８によって１が加算される。ストレージマイクロプログラム１０２８は、加算された値を、ジャーナルボリュームテーブル４０００（図４参照）の順序番号フィールド４００２にコピーする。

また、順序カウンタフッィールド３００２に格納される値は、ストレージマイクロプログラム１０２８がスナップショットを取得するたびに、ストレージマイクロプログラム１０２８によってスナップショットテーブル５０００（図５参照）の順序番号５００２にコピーされる。これによって、スナップショットテーブル５０００に、スナップショットと各ジャーナルの順序関係が記録され、リカバリの際にスナップショットに適用すべきジャーナルが特定できる。具体的には、ストレージマイクロプログラム１０２８は、特定のスナップショットにジャーナルを適用してリカバリをする場合は、特定のスナップショットの順序番号より大きい順序番号のジャーナルのうち、指定されたリカバリポイントを持つジャーナルの順序番号以下の順序番号を持つジャーナルを、順序番号に従って適用する。

図４は、管理テーブル１０２９に含まれるジャーナルボリュームテーブル４０００の一例の説明図である。

ジャーナルボリュームテーブル４０００は、ジャーナルグループ１０１４に対して取得したジャーナルデータを管理するためのテーブルである。

ジャーナルボリュームテーブル４０００は、ＪＮＬグループＩＤフィールド４００１、順序番号フィールド４００２、ボリュームＩＤフィールド４００３、ＪＮＬヘッダ格納アドレスフィールド４００４及び生成時刻フィールド４００５を含むエントリ４００６を含む。

ストレージマイクロプログラム１０２８は、ホスト計算機１１００からジャーナルグループ１０１４に対する書き込みがあるたびに、ジャーナルを生成してジャーナルボリューム１０１３のデータボリューム１０１１に格納する。このとき、ストレージマイクロプログラム１０２８は、生成したジャーナルデータに対応するエントリ４００６を生成して、ジャーナルグループテーブル４０００に追加する。

ＪＮＬグループＩＤフィールド４００１は、ホスト計算機１１００からの書き込みがあったジャーナルグループ１０１４の識別子であるＪＮＬグループＩＤを格納する。ストレージマイクロプログラム１０２８は、書き込みがあったデータボリューム１０１１のボリュームＩＤを取得し、ジャーナルグループテーブル３０００を参照して、このボリュームＩＤからＪＮＬグループＩＤを取得する。そして、取得したＪＮＬグループＩＤをＪＮＬグループＩＤフィールド４００１に格納する。

順序番号フィールド４００２は、順序番号を格納する。この順序番号は、リカバリの際に、どのスナップショットにどのジャーナルを適用すべきかを決定するために用いられる。ストレージマイクロプログラム１０２８は、ホスト計算機１１００からの書き込みに対してジャーナルを作成するときに、ジャーナルグループテーブル３０００の順序カウンタ３００３に順序番号を設定する。そして、この順序番号取得して、順序番号フィールド４００２に設定する。

ボリュームＩＤフィールド４００３は、ジャーナルが格納されているジャーナルボリューム１０１３のデータボリューム１０１１の識別子であるボリュームＩＤを格納する。

ＪＮＬヘッダ格納アドレスフィールド４００４は、ジャーナルヘッダが格納されているデータボリューム内のアドレスを格納する。

ストレージマイクロプログラム１０２８は、ジャーナルをジャーナルボリューム１０１３に書き込む際に、ジャーナルの書き込みに領域の識別子であるボリュームＩＤ及びＪＮＬヘッダ格納アドレスを取得して、これらの値をボリュームＩＤフィールド４００３及びＪＮＬヘッダ格納アドレスフィールド４００４に格納する。

生成時刻フィールド４００５は、ホスト計算機１１００からの書き込み要求がストレージシステム１０００に到着した時刻を格納する。ストレージマイクロプログラム１０２８は、ホスト計算機１１００からの書き込み要求がストレージシステム１０００に到着したときに、ディスクコントローラ１０２０のタイマ１０２４から時刻を取得して、生成時刻フィールド４００５に格納する。

この生成時刻は、リカバリの際に、管理者が指定するリカバリポイントとなる。なお、ホスト計算機１１００からの書き込み要求に含まれる書き込み発行時刻を生成時刻に設定してもよい。例えば、メインフレーム環境では、メインフレームホストがタイマを有しており、書き込み要求内に書き込みコマンドを発行する時刻を含める。そのため、この時刻を生成時刻として利用してもよい。

図５は、管理テーブル１０２９に含まれるスナップショットテーブル５０００の一例の説明図である。

スナップショットテーブル５０００は取得したスナップショットを管理するためのテーブルである。

スナップショットテーブル５０００は、ＪＮＬグループＩＤフィールド５００１、順序番号フィールド５００２、ボリュームＩＤフィールド５００３、スナップショットボリュームＩＤフィールド５００４及び生成時刻５００５フィールドを含むエントリ５００６を含む。

ＪＮＬグループＩＤフィールド５００１は、取得対象のジャーナルグループ１０１４の識別子であるＪＮＬグループＩＤを格納する。順序番号フィールド５００２は、スナップショットが取得された順序を示す順序番号を格納する。ボリュームＩＤフィールド５００３は、スナップショットが格納されているスナップショットボリューム１０１２のデータボリューム１０１１の識別子であるボリュームＩＤを格納する。スナップショットボリュームＩＤフィールド５００４、は、スナップショットを格納するスナップショットボリュームの識別子であるスナップショットボリュームＩＤを格納する。生成時刻５００５フィールドは、生成時刻を格納する。

ＪＮＬグループＩＤとスナップショットボリュームＩＤとは、ホスト計算機１１００において、管理者が、リカバリマネージャ１１６２が提供するＣＬＩを用いてこれらを関連付ける。例えば、管理者が次のようなコマンドを発行する。
addSSVOL ?jgid JNLG_01 ?ssvolid SS_01
このコマンドは、ジャーナルグループＩＤが「ＪＮＬＧ＿０１」であるジャーナルグループ１０１４にスナップショットボリュームＩＤが「ＳＳ＿０１」であるスナップショットボリューム１０１２を関連付ける要求である。

このコマンドによって、ＪＮＬグループＩＤフィールド５００１に「ＪＮＬＧ＿０１」が格納され、スナップショットボリュームＩＤフィールド５００４に「ＳＳ＿０１」が格納される。なお、複数世代のスナップショットを設定する場合は、このようなコマンドを複数回実行する。

順序番号フィールド５００２は、ストレージマイクロプログラム１０２８が、スナップショットを取得するたびに、ジャーナルグループテーブル３０００の順序カウンタフィールド３００３に格納された順序番号をコピーすることによって格納される。

生成時刻フィールド５００５は、ストレージマイクロプログラム１０２８が、リカバリマネージャ１１６２からのスナップショット取得要求がストレージシステム１０００に到着した時刻、タイマ１０２４から取得することによって格納される。なお、前述のように、ホスト計算機１１００からのスナップショット取得要求に含まれる要求発行時刻を生成時刻に設定してもよい。

以上が、管理テーブル１０２９に含まれるテーブル群である。

次に、ジャーナルボリューム１０１３の構成を説明する。

図６は、ジャーナルボリューム１０１３の構成の説明図である。

ジャーナルボリューム１０１３は、論理的に、ジャーナルヘッダ領域６０１０とジャーナルデータ領域６０２０とに分割されている。

ストレージシステム１０００において、ジャーナルをジャーナルボリューム１０１３に格納するときに、ストレージマイクロプログラム１０２８は、ジャーナルをジャーナルヘッダ６０１１とジャーナルデータ６０２１とに分割する。ジャーナルヘッダ６０１１はジャーナルヘッダ領域６０１０に格納し、ジャーナルデータ６０２１はジャーナルデータ領域６０２０に格納する。

ジャーナルデータ６０２１は、データボリューム１０１１に書き込まれるデータであり、ジャーナルヘッダ６０１１は、このジャーナルデータ６０２１に関する情報を保持するデータである。

ジャーナルヘッダ６０１１は、データボリュームＩＤ６１０１、書き込み先アドレス６１０２、データ長６１０３、ＪＮＬボリュームＩＤ６１０６及びＪＮＬ格納アドレス６１０７を含むエントリ６００８を含む。

データボリュームＩＤ６１０１は、ジャーナル適用時のジャーナルデータの書き込み先となるデータボリューム１０１１の識別子であるボリュームＩＤを格納する。書き込み先アドレス６１０２は、ジャーナル適用時のジャーナルデータの書き込み先となるアドレスを格納する。データ長６１０３は書き込みデータの長さを格納する。これらの値は、ストレージマイクロプログラム１０２８が、ホスト計算機１１００からの書き込み要求を解析して取得し、ジャーナルヘッダ６０１１に設定する。

ＪＮＬボリュームＩＤ６１０６は、ジャーナルデータを格納しているボリュームの識別子であるボリュームＩＤを格納する。

ＪＮＬ格納アドレス６１０７は、ボリューム内のジャーナルデータが格納されているアドレスを格納する。これらの値は、ジャーナル作成時に、ストレージマイクロプログラム１０２８が設定するものである。また、ジャーナルデータを開放した場合、ストレージマイクロプログラム１０２８がＪＮＬボリュームＩＤ６１０６及びＪＮＬ格納アドレス６１０７に“ＮＵＬＬ”を格納する。

次に、リカバリポイントテーブル７０００について説明する。

図７は、リカバリポイントテーブル７０００の一例の説明図である。

リカバリポイントテーブル７０００は、バックアッププログラム１２６３がリカバリポイントを取得するときに作成される。バックアッププログラム１２６３は、管理プログラム１２６５に対して、作成したリカバリポイントテーブル７０００をリカバリポイント作成イベントとして通知する。

リカバリポイントテーブル７０００は、ＪＮＬグループＩＤフィールド７００１、取得時刻フィールド７００２及びスナップショット取得フラグフィールド７００３を含むエントリ７００４を含む。

ＪＮＬグループＩＤフィールド７００１は、リカバリポイント取得の対象であるジャーナルグループ１０１４の識別子であるＪＮＬグループＩＤを格納する。

取得時刻フィールド７００２は、リカバリポイントを取得した時刻を格納する。この時刻は、ストレージシステム１０００のタイマ１０２４から取得する。なお、管理計算機１２００にタイマを備え、このタイマから時刻を取得してもよい。

スナップショットフラグフィールド７００３には、リカバリポイント取得のタイミングでスナップショットを取得したか否かを示す識別子を格納する。スナップショットを取得した場合は、「Ｏｎ」を格納する。スナップショットを取得しなかった場合は「Ｏｆｆ」を格納する。

次に、管理計算機１２００に格納されるバックアップ管理情報１２６４について説明する。

バックアップ管理情報１２６４は、図８のアプリケーションテーブル８０００及び図９の状態管理テーブル９０００を含んだテーブル群である。

図８は、バックアップ管理情報１２６４に含まれるアプリケーションテーブル８０００の一例の説明図である。

アプリケーションテーブル８０００は、バックアッププログラム１２６３によって管理される、バックアップの管理のための情報を格納するテーブルである。

アプリケーションテーブル８０００は、アプリケーションＩＤフィールド８００１、ホストアドレスフィールド８００２、ストレージＩＤフィールド８００３及びＪＮＬグループＩＤフィールド８００４を含むエントリ８００５を含む。

アプリケーションＩＤフィールド８００１は、バックアップ対象のジャーナルグループのデータを利用するアプリケーション１１６３の識別子を格納する。

ホストアドレスフィールド８００２は、アプリケーション１１６３が実行されているホスト計算機１１００のネットワーク上での識別子を格納する。識別子にはＩＰアドレス等が用いられる。

ストレージＩＤフィールド８００３は、アプリケーションが１１６３利用するジャーナルグループが属しているストレージシステム１０００の識別子を格納する。

ＪＮＬグループＩＤフィールド８００４は、アプリケーション１１６３が利用するジャーナルグループの識別子であるＪＮＬグループＩＤを格納する。

アプリケーションＩＤフィールド８００１及びホストアドレスフィールド８００２は、管理者が、管理計算機１２００の管理プログラム１２６５が提供するＧＵＩを介して設定する。

ストレージＩＤフィールド８００３及びＪＮＬグループＩＤフィールド８００４は、アプリケーションとそのアプリケーションが利用するジャーナルグループとの対応関係を示す。これらは、管理プログラム１２６５が、情報収集エージェント１１６１に問い合わせて取得し、取得した値を設定する。なお、ストレージＩＤフィールド８００３は、シリアル番号等のストレージ装置を一意に識別するためのＩＤを格納する。

図９は、バックアップ管理情報１２６４に含まれる状態管理テーブル９０００の一例の説明図である。

状態管理テーブル９０００は、一つのジャーナルグループに対して一つ生成される。複数のジャーナルグループが存在する場合には複数生成される。

状態管理テーブル９０００は、対象ＪＮＬグループＩＤ９００１、リカバリポイントヘッダフィールド９０１０及びＳｎａｐ／ＪＮＬフィールド９０２０によって構成されるテーブルである。

対象ＪＮＬグループＩＤ９００１は、その状態管理テーブル９０００が、どのジャーナルグループに対するテーブルであるかを示すＪＮＬグループＩＤを格納する。

リカバリポイントヘッダフィールド９０１０は、リカバリポイントＩＤ及びその状態を格納する。

Ｓｎａｐ／ＪＮＬヘッダフィールド９０２０は、各々のリカバリポイントをリカバリするために必要なスナップショット又はジャーナルの、識別子及びその状態を格納する。

リカバリポイントヘッダフィールド９０１０を構成する各リカバリポイントヘッダは、リカバリポイントＩＤ９０１１及びリカバリポイント有効性フラグ９０１２を含む。リカバリポイントＩＤ９０１１は、リカバリポイントを取得した時刻を格納する。リカバリポイント有効性フラグ９０１２は、リカバリポイントＩＤによって示されるリカバリポイントが、有効であるか、障害などによって無効となっているか示すフラグが格納される。リカバリポイント有効フラグ９０１２は、管理プログラム１２６５が、スナップショット又はジャーナルの状態から「有効」又は「無効」を設定する。

Ｓｎａｐ／ＪＮＬヘッダフィールド９０２０を構成する各Ｓｎａｐ／ＪＮＬヘッダは、識別子９０２１及びデータ有効性フラグ９０２２を含む。識別子９０２１は、対象がスナップショットである場合はスナップショットテーブル５０００に格納されているスナップショットボリュームＩＤを格納する。また、対象がジャーナルの場合は、ジャーナルボリュームテーブル４０００に格納されている順序番号４００２を格納する。データ有効性フラグ９０２２は、管理プログラム１２６５が、スナップショット又はジャーナルの状態から「有効」又は「無効」を設定する。

テーブルを構成する各セルは、必要性フラグ９０３１及び有効性フラグ９０３２を含む。

必要性フラグ９０３１は、その行のリカバリポイントヘッダによって示されるリカバリポイントをリカバリするために、どのスナップショット又はジャーナルが必要かを示すフラグである。必要性フラグ９０３１は、管理プログラム１２６５によって、そのリカバリポイントには、Ｓｎａｐ／ＪＮＬヘッダによって示されるスナップショット又はジャーナルが必要である場合には「必要」が格納される。必要でなければ「不必要」が格納される。

有効性フラグ９０３２は、各セルに対応するスナップショット又はジャーナルが有効か、もしくは障害などによって無効になってしまったかを表す。本フラグは、必要性フラグに「必要」という値がセットされているときにのみセットされ、該当するＳｎａｐ／ＪＮＬフィールドのデータ有効性フラグが「有効」であれば有効が、「無効」であれば無効が、管理プログラム１２６５によりセットされる。

図９において、列９０１０Ａを例に説明する。

リカバリポイントヘッダ９０１０Ａを含む列は、リカバリポイント「２００５／９／１ １０：１０」に関する情報が各セルに格納されている。各セル９０３０は、リカバリポイント「２００５／９／１ １０：１０」をリカバリするためには、どのスナップショット又はジャーナルが必要であるかを示す。具体的には、必要性フラグ９０３１が「必要」となっているのは、スナップショット「ＳＳ＿０１」、ジャーナル「１０１」及びジャーナル「１０２」の三つが示されている。さらに、ジャーナル「１０１」の有効性フラグ９０２２は「無効」が設定されているため、これに対応するセルの有効性フラグ９０３２にも「無効」が設定される。この結果、リカバリポイント「２００５／９／１ １０：１０」は無効と設定される。

管理者はこの管理情報テーブルの情報から、有効又は無効であるリカバリポイントを知ることができる。

次に、本発明の第１の実施形態の動作について説明する。

まず、管理計算機１２００の管理プログラム１２６５の動作を説明する。

管理プログラム１２６５は、バックアップ対象アプリケーションの設定、リカバリポイント作成時に状態管理テーブル９０００の更新及びボリューム障害イベント受信時に状態管理テーブル９０００の更新を実行する。

まず、バックアップ対象アプリケーションの設定について説明する。

図１０は、管理プログラム１２６５が提供するＧＵＩであるバックアップ対象アプリケーション情報設定画面１００００の説明図である。

バックアップ対象アプリケーション情報設定画面１００００は、バックアップ対象アプリケーションの情報を設定するときに、管理者が、ＣＬＩ等によって管理プログラム１２６５に要求することによって、表示装置１２２０に表示される。

バックアップ対象アプリケーション情報設定画面１００００は、アプリケーションＩＤ入力フィールド１００１０、ホストアドレス入力フィールド１００２０、実行ボタン１００３０及び取り消しボタンを含む。

アプリケーションＩＤ入力フィールド１００１０は、バックアップ対象として設定するアプリケーションの識別子であるアプリケーションＩＤを入力するためのフィールドである。

ホストアドレス入力フィールド１００２０は、バックアップ対象として設定するアプリケーションが実行されるホスト計算機１１００の識別子を入力するためのフィールドである。この識別子は、ＩＰアドレスを用いる。なお、ホスト名など別の識別子を使用してもよい。

管理者が、アプリケーションＩＤ入力フィールド１００１０及びホストアドレス入力フィールド１００２０に必要な情報を入力した後、実行ボタン１００３０を押下すると、図１１に説明する管理プログラム１２６５の処理が実行される。なお、取り消しボタン１００４０を押下した場合は、管理プログラム１２６５は何もせずに終了する。

図１１は、バックアップ対象アプリケーションの設定のフローチャートである。

このフローチャートは、図１０の画面において、実行１００３０ボタンが押下されたときに、管理プログラム１２６５によって実行される。

まず、管理プログラム１２６５は、アプリケーションＩＤ入力フィールド１００１０に設定された値をアプリケーションテーブル８０００のアプリケーションＩＤフィールド８００１に格納する。そして、ホストアドレス入力フィールド１００２０に設定された値をアプリケーションテーブル８０００のホストアドレスフィールド８００２に格納する（ステップＳ１１０１０）。

次に、管理プログラム１２６５は、ホストアドレスフィールド８００２に格納されている識別子に対応するホスト計算機１１００に接続して、情報収集エージェント１１６１にアプリケーションＩＤを送信して、アプリケーションとジャーナルの対応情報の取得を要求する（ステップＳ１１０２０）。

管理プログラム１２６５からの要求を受け取ると、情報収集エージェント１１６１は、システム構成定義ファイル１１７１を参照して、受け取ったアプリケーションＩＤが利用するデータボリューム１０１１を取得する。そして、取得したデータボリューム１０１１が属するジャーナルグループ１０１４の識別子と、そのジャーナルグループ１０１４が属するストレージシステムの識別子とを取得する。そして、取得したデータボリュームが属するジャーナルグループの識別子と、そのジャーナルグループが属するストレージシステムの識別子とを、管理計算機１２００の管理プログラム１２６５に応答する（ステップＳ１１０３０）。

情報収集エージェント１１６１からの応答を受け取ると、管理プログラム１２６５は、受け取ったジャーナルグループの識別子を、アプリケーションテーブル８０００のＪＮＬグループＩＤ８００４に格納する。また、受け取ったストレージシステムの識別子を、アプリケーションテーブル８０００のストレージＩＤ８００３に格納する（ステップ１１０４０）。

このフローチャートの処理によって、バックアップ対象アプリケーションと、ストレージシステム及びジャーナルグループの情報とが対応付けられて、アプリケーションテーブル８０００に設定される。

次にリカバリポイント作成時の処理を説明する。

図１２は、リカバリポイント作成時の処理のフローチャートである。

バックアッププログラム１２６３は、管理者によって設定されたポリシーに基づいて、リカバリポイントの作成処理を開始する。このポリシーは、一般的には、時間間隔が指定される。すなわち、バックアッププログラム１２６３は、指定された時間間隔となったときに、リカバリポイントの作成処理を実行する
まず、バックアッププログラム１２６３は、リカバリポイント作成処理を実行するときに、管理プログラム１２６５に対してリカバリポイント作成イベントを通知する。具体的には、バックアッププログラム１２６３が、リカバリポイントテーブル７０００を管理プログラム１２６５に送信することによって、リカバリポイント作成イベントが通知される（ステップＳ１２０１０）。

管理プログラム１２６５は、このリカバリポイント作成イベントを受信すると（ステップＳ１２０２０）、以降の処理を実行する。

まず、管理プログラム１２６５は、状態管理テーブル９０００に新規行を追加し、追加した行をカレント行に設定する。

管理プログラム１２６５は、追加した新規行のリカバリポイントヘッダのリカバリポイントＩＤ９０１１には初期値として、リカバリポイントテーブル７０００の取得時刻７００２を格納する。また、有効性フラグ９０１２に、初期値として「有効」を設定する。また、追加した新規行の各セルは、必要性フラグ９０１３に、初期値として「不必要」を設定する。また、有効性フラグ９０３２は空欄（なお、状態管理テーブル９０００では「−」と表記する）とする（ステップＳ１２０３０）。

次に、管理プログラム１２６５は、ジャーナルボリュームテーブル４０００及びスナップショットテーブル５０００を参照して、前回本処理によって生成されたジャーナルよりも後に生成されたジャーナルを、新規列として状態管理テーブル９０００に追加する。管理プログラム１２６５は、追加した各列のＳｎａｐ／ＪＮＬヘッダに、ジャーナルボリュームテーブル４０００に格納されている順序番号フィールド４００２の値を、ジャーナルＩＤとして設定する。また、有効性フラグに、初期値として「有効」を設定する。また、追加された新規列の各セルには、必要性フラグに、初期値として「不必要」を設定する。また、有効性フラグに、初期値として空欄を設定する（ステップＳ１２０４０）。

このステップの処理によって、新たに記録されたジャーナルに対応するエントリが、状態管理テーブル９０００に格納される。

次に、管理プログラム１２６５は、スナップショットテーブル５０００及びリカバリポイントテーブル７０００を参照して、カレント行のリカバリポイントでスナップショットが取得されたか否かを判定する（ステップＳ１２０５０）。

カレント行のリカバリポイントでスナップショットが取得されたと判定した場合は、管理プログラム１２６５は、取得したスナップショットを新規列として状態管理テーブル９０００に追加する。この新規列のＳｎａｐ／ＪＮＬヘッダは、スナップショットテーブル５０００に格納されているスナップショットボリュームＩＤを設定し、データ有効性フラグには、初期値として「有効」を設定する。追加された列の各セルには、必要性フラグに、初期値として「不必要」を設定し、有効性フラグに、初期値として空欄を設定する（ステップＳ１２０６０）。

このとき、本処理の契機となったリカバリポイント作成イベントに係るリカバリポイントは、ステップＳ１２０５０で判定したようにスナップショットが取得されている。従って、本リカバリポイントをリカバリするために必要なデータは、取得されたスナップショットのみで充分となる。そこで、管理プログラム１２６５は、カレント行のうちステップＳ１２０６０で追加された最新のスナップショットに対応するセルに関して、必要性フラグを「必要」に、有効性フラグを「有効」に変更する（ステップＳ１２０７０）。その後、処理を終了する。

一方、ステップ１２０５０において、スナップショットを取得していないと判定した場合は、管理プログラム１２６５は、本リカバリポイントをリカバリするために必要なデータは、最も新しいスナップショットと、そのスナップショットを取得してから本リカバリポイントを取得するまでの間に取得されたまでの全てのジャーナルと、が必要となる。そこで、管理プログラム１２６５は、カレント行において、最も新しいスナップショットから今回作成されたリカバリポイントに対応するジャーナルの範囲にあるセルの、必要性フラグ９０３１を「必要」に変更し、有効性フラグ９０３２を「有効」に設定する（ステップＳ１２０８０）。その後、処理を終了する。

このフローチャートの処理によって、リカバリポイントが作成されたときに、対応するスナップショット及びジャーナルの情報が状態管理テーブル９０００に設定される。特に、リカバリポイントに対して、どのスナップショット又はジャーナルが必要であるかを示す情報（必要性フラグ９０３１）を設定する。

次に、ボリューム障害イベント受信時の処理を説明する。

図１３は、ボリューム障害イベント受信時の処理のフローチャートである。

管理プログラム１２６５は、ストレージシステム１０００の障害管理プログラム１０３５からボリューム障害イベントを受信すると（ステップＳ１３０１０）、状態管理テーブル９０００を更新する処理を開始する。

なお、管理プログラム１２６５は、このボリューム障害イベントを非同期で受信する。なお、イベントの受信方法として、例えば、管理プログラム１２６５からストレージシステム１０００の障害管理プログラム１０３５に対して定期的にポーリングを行って、ボリューム障害イベントを取得してもよい。

次に、管理プログラム１２６５は、ボリューム障害イベントに含まれるボリューム障害テーブル２０００から障害ボリュームＩＤ２００２を取得する。そして、ジャーナルボリュームテーブル４０００を参照して、ボリュームＩＤフィールド４００３に障害ボリュームＩＤ２００２と同じボリュームＩＤが存在するか否かを判定する（ステップ１３０２０）。

障害ボリュームＩＤ２００２と同じボリュームＩＤが存在すると判定した場合は、管理プログラム１２６５は、ジャーナルボリュームテーブル４０００の各エントリ４００６を順次参照する。そして、参照したエントリ４００６のボリュームＩＤフィールド４００３に格納されているボリュームＩＤが、障害ボリュームＩＤと同じ場合は、その行の順序番号フィールド４００２に格納されている順序番号を取得する。次に、管理プログラム１２６５は、状態管理テーブル９０００を参照して、Ｓｎａｐ／ＪＮＬヘッダフィールド９０２０のうち、取得した順序番号と同じ値を持つＳｎａｐ／ＪＮＬヘッダがあれば、そのＳｎａｐ／ＪＮＬヘッダの有効性フラグ９０２２を「無効」に設定する（ステップＳ１３０３０）。

この処理によって、状態管理テーブル９０００において、障害ボリュームＩＤに対応する順序番号のジャーナルが「無効」に設定される。その後、ステップＳ１３０４０に移行する。

なお、ステップＳ１５０２０において、障害ボリュームＩＤと同じボリュームＩＤが存在しないと判定した場合は、管理プログラム１２６５は、ステップＳ１３０３０の処理を実行することなく、ステップＳ１３０４０に移行する。

ステップＳ１３０４０において、管理プログラム１２６５は、障害ボリュームＩＤ２００２と同じボリュームＩＤが、スナップショットテーブル５０００のボリュームＩＤフィールド５００３に格納されているか否かを判定する。

障害ボリュームＩＤと同じボリュームＩＤが、スナップショットテーブル５０００のボリュームＩＤフィールド５００３に格納されている場合は、管理プログラム１２６５は、スナップショットテーブルの各エントリ５００６を順次参照する。そして、参照したエントリ５００６のボリュームＩＤフィールド５００３に格納されているボリュームＩＤが、障害ボリュームＩＤ２００２と同じ場合は、そのエントリ５００６のスナップショットボリュームＩＤフィールド５００４に格納されているスナップショットボリュームＩＤを取得する。次に、状態管理テーブル９０００を参照して、Ｓｎａｐ／ＪＮＬヘッダフィールド９０２０のうち、取得したスナップショットボリュームＩＤと同じ値を持つＳｎａｐ／ＪＮＬヘッダがあれば、そのＳｎａｐ／ＪＮＬヘッダの有効性フラグ９０２２を「無効」に設定する（ステップＳ１３０５０）。

この処理によって、状態管理テーブル９０００において、障害ボリュームＩＤに対応するスナップショットボリュームＩＤのスナップショットが「無効」に設定される。その後、ステップＳ１３０６０に移行する。

なお、ステップＳ１３０４０において、障害ボリュームＩＤと同じボリュームＩＤが存在しないと判定した場合は、管理プログラム１２６５は、ステップ１３０５０の処理を実行することなく、ステップＳ１３０６０に移行する。

ステップＳ１３０６０では、管理プログラム１２６５は、状態管理テーブル９０００のＳｎａｐ／ＪＮＬヘッダフィールド９０２０に含まれるＳｎａｐ／ＪＮＬヘッダを順次参照する。そして、参照したＳｎａｐ／ＪＮＬヘッダの有効性フラグ９０２２が「無効」であれば、その列に含まれる各セルを順次参照する。そして、参照したセルの必要性フラグ９０３１が「必要」である場合は、当該セルの有効性フラグ９０３２を「無効」に変更する。管理プログラム１２６５は、この処理を、Ｓｎａｐ／ＪＮＬヘッダフィールド９０２０の全てのＳｎａｐ／ＪＮＬヘッダについて実行する（ステップＳ１５０６０）。

次に、管理プログラム１２６５は、リカバリポイントヘッダフィールド９０１０の各リカバリポイントヘッダの内容を更新する。具体的には、管理プログラム１２６５は、まず、状態管理テーブル９０００のリカバリポイントヘッダフィールド９０１０に含まれるリカバリポイントヘッダを順次参照する。そして、参照したリカバリポイントヘッダに対応するセルのうち、有効性フラグ９０３２が「無効」に設定されているセルがあるかを判定する。そして、有効性フラグ９０３２が「無効」に設定されているセルがあれば、そのリカバリポイントヘッダのリカバリポイント有効性フラグ９０１２を「無効」に更新する。この処理を、リカバリポイントヘッダフィールド９０１０の全てのリカバリポイントヘッダに実行する（ステップＳ１３０７０）。

この処理によって、状態管理テーブル９０００において、リカバリポイントをリカバリするために必要なスナップショットボリュームＩＤのスナップショットが「無効」に設定されている場合は、そのリカバリポイントが無効に設定される。その後、ステップＳ１３０８０に移行する。

最後に、管理プログラム１２６５は、更新された状態管理テーブル９０００の内容に基づいて、ユーザに通知する（ステップＳ１３０８０）。

次に、このユーザへの通知を説明する。

管理計算機１２００の管理プログラム１２６５は、前述した図１３のフローチャートのステップＳ１３０８０において、管理計算機１２００のユーザに対して、障害ボリュームの発生、障害ボリュームの発生によるアプリケーション又はリカバリポイントへの影響範囲を通知する。管理プログラム１２６５は、図１４乃至図１６に例示するＧＵＩによって通知する。

図１４は、ユーザへの通知のＧＵＩの一例の説明図である。

リカバリポイント表示ＧＵＩ１４０００は、管理プログラム１２６５が、表示装置１２２０に、リカバリポイントの一覧と、そのリカバリポイントが有効であるか無効であるかを表示するためのＧＵＩである。

リカバリポイント表示ＧＵＩ１４０００は、リカバリポイントフィールド１４００１、有効性フィールド１４００２及びアプリケーション名１４００３を含む。

リカバリポイントフィールド１４００１は、リカバリポイントの識別子であるリカバリポイントＩＤを表示する。

有効性フィールド１４００２は、リカバリポイントＩＤによって示されるリカバリポイントが、有効であるか無効であるかを表示する。

アプリケーション名１４００３は、バックアップ対象となるアプリケーションの識別子であるアプリケーションＩＤを表示する。管理プログラム１２６５は、状態管理テーブル９０００のＪＮＬグループＩＤフィールド９００１の値を用いてアプリケーションテーブル８０００を参照することによってアプリケーションＩＤ８００１を取得して、これをアプリケーション名１４００３に表示する。

なお、図１４の例では、文字列によって有効又は無効を表示しているが、アイコン等の図形によって有効又は無効である旨の表示でもよい。

また、有効性フィールド１４００２が「有効」である場合は、管理者が、入力装置１２４０に備えられているマウス等によって該当箇所をクリックすることによって、バックアッププログラム１２６３を起動し、バックアッププログラム１２６３のリストア機能を実行させることもできる。

また、有効性フィールド１４００２が「無効」の場合は、管理者が、入力装置１２４０に備えられているマウス等によって該当箇所をクリックすることによって、ホスト計算機１１７０のリカバリマネージャ１１６２の機能を実行させて、ホスト計算機１１７０のローカルディスク１１７０に格納されているシステム構成定義ファイル１１７１に含まれる情報から、アプリケーションとデータボリュームと障害が発生したボリュームとの関係を、管理プログラム１２６５によって表示させることもできる。

図１４に示したＧＵＩは、一つのアプリケーションに対する表示であった。これに対して、複数のアプリケーションについて同時に表示するようにしてもよい。

図１５は、ユーザへの通知のＧＵＩの他の例の説明図である。

図１５では、計算機システムにおいて、三つのアプリケーションが稼動している場合のアプリケーションステータス表示ＧＵＩ１５０００の表示例である。

このアプリケーションステータス表示ＧＵＩ１５０００は、ホストアイコン１５００１、アプリケーションアイコン１５００２及びステータスアイコン１５００３を含む。

ホストアイコン１５００１は、アプリケーションが実行されえているホスト計算機１１００を、ホストＩＤと共に模式的に表示する。ホストＩＤは、ホスト名やＩＰアドレス等を用いる。

アプリケーションアイコン１５００２は、ホスト計算機１１００で実行されているアプリケーションを模式的に表示する。アプリケーションが実行されているホストアイコンの内に、アプリケーションアイコン１５０２を、アプリケーションＩＤと共に表示する。

このアプリケーションアイコン１５００３を、管理者が、入力装置１２４０に備えられているマウス等によってクリックすることによって、そのアプリケーションが使用するデータボリューム及びジャーナルボリュームの詳細を表示できる。

ステータスアイコン１５００３は、アプリケーションの状態を模式的に表示する。ステータスアイコン１５００３は、アプリケーションアイコン１５００２の近傍に表示され、そのアプリケーションのステータスを示す図を表示する。ステータスは、有効又は無効を示すアイコンを表示する。例えば、アプリケーションの全てのリカバリポイントが有効である場合は、有効であることを示す「○」を模したアイコンを表示する。また、アプリケーションの一部にでも無効なリカバリポイントがあれば、無効であることを示す「×」を模したアイコンを表示する。なお、有効である場合はアイコンを表示せず、無効を示すアイコンのみを表示してもよい。

この図１５のアプリケーションステータス表示ＧＵＩ１５０００を用いることによって、複数のアプリケーションを用いてジャーナリングによるバックアップを運用している場合に、ユーザが、アプリケーションステータス表示ＧＵＩ１５０００を参照することによって、どのアプリケーションに障害が発生したのかを一目で知ることができる。

図１６はアプリケーションステータス表示ＧＵＩ１５０００に表示されているアプリケーションアイコン１５００２を、管理者が、入力装置１２４０に備えられているマウス等によってクリックしたときに表示される物理ビューＧＵＩ１６０００である。

物理ビューＧＵＩ１６０００は、ホストアイコン１６００１、アプリケーションアイコン１６００２、ストレージシステムアイコン１６０１０、ジャーナルボリュームアイコン１６０１１、ジャーナルグループアイコン１６０１２、スナップショットボリュームアイコン１６０１３及びステータスアイコン１６０１４を含む。

ホストアイコン１６００１及びアプリケーションアイコン１６００２は、アプリケーションステータス表示ＧＵＩ１５０００が表示するホストアイコン１５００１及びアプリケーションアイコン１５００２と同様に、アプリケーションを実行しているホスト計算機１１００のホストＩＤ及びホスト計算機で実行されているアプリケーションＩＤを表示する。

ストレージシステムアイコン１６０１０は、アプリケーションがジャーナリングによるバックアップ運用のために使用するストレージシステム１０００を表示する。なお、図１６では、ストレージシステムが一つのみ表示されているが、複数のストレージシステムを表示するようにしてもよい。

ジャーナルボリュームアイコン１６０１１は、ストレージシステム１０００に構成されるジャーナルボリューム１０１３を、ジャーナルボリューム１０１３の識別子であるボリュームＩＤと共に表示する。ジャーナルグループアイコン１６０１２は、ストレージシステム１０００に構成されるジャーナルグループ１０１４を、ジャーナルグループ１０１４の識別子であるＪＮＬグループＩＤと共に表示する。スナップショットボリュームアイコン１６０１３は、ストレージシステム１０００に構成されるスナップショットボリューム１０１２を、スナップショットボリューム１０１２のスナップショットボリュームＩＤと共に表示する。

ステータスアイコン１６０１４は、障害が発生したことを示すアイコンであり、障害が発生した部分に表示される。

なお、管理プログラム１２６５は、物理ビューＧＵＩ１６０００とリカバリポイント表示ＧＵＩ１４０００とを切り替えて表示する機能を提供してもよい。切り替えて表示することにより、ユーザは、どこに障害が発生したのか、どのリカバリポイントが無効になったのかを知ることができる。また、物理ビューＧＵＩ１６０００とリカバリポイント表示ＧＵＩ１４０００とを同一の表示画面上に同時に表示してもよい。

このように、管理プログラム１２６５は、ユーザに障害発生の通知をＧＵＩによって行う。これによって、ユーザは、どのプログラムが使用しているどのボリュームに障害が発生したのかを、一目で知ることができる。

なお、図１４乃至図１６では、ユーザへの通知をＧＵＩによって行ったが、これに限定されるものではない。例えば、管理プログラム１２６５が、ＳＮＭＰトラップ等を用いて、無効となったリカバリポイントをユーザに通知してもよい。また、ＳＮＭＰトラップ等を用いて、ユーザにボリューム障害が発生したことを通知し、ＧＵＩによる表示を参照するように促してもよい。

以上のように、本発明の第１の実施形態によれば、スナップショット又はジャーナルを構成するボリュームに障害が発生した場合に、その障害によって無効となってしまったリカバリポイントを自動的に検出でき、それ以外のリカバリポイントで運用を継続することが可能となる。

（第２実施形態）
前述した第１の実施の形態の計算機システムにおいて、管理計算機１２００の管理プログラム１２６５は、リカバリポイントを作成するたびに、前回リカバリポイントを作成した後に発生したジャーナルの情報を全て状態管理テーブル９０００の列に格納する。一般的に、ジャーナルはホスト計算機１１００から書き込みがあるたびに作成されるので、時間が経過すると、状態管理テーブル９０００のエントリの数が非常に多くなる。そのため、管理計算機１２００は、膨大なデータを管理しなければならない。そこで、管理計算機１２００が管理するデータ量を削減するために、次のような方法を用いる。

なお、第１の実施の形態と同一の作用の構成には同一の符号を付し、その説明は省略する。

図１７は、本発明の第２の実施の形態のバックアップ管理情報１２６４に含まれる状態管理テーブル１７０００の一例の説明図である。

状態管理テーブル１７０００において、Ｓｎａｐ／ＪＮＬヘッダフィールド９０２０を構成する各Ｓｎａｐ／ＪＮＬヘッダの構成が、第１の実施の形態と異なる。すなわち、識別子１７０２１は、スナップショットＩＤ又は複数の連続したジャーナルの識別子を格納する。複数の連続したジャーナルとは、あるリカバリポイントから次のリカバリポイントまでの間に取得されたジャーナルを一つのグループとしたジャーナル群である。

次に、第２の実施の形態の計算機システムの動作を説明する。

管理プログラム１２６５は、図１７の状態管理テーブル１７０００を作成するリカバリポイント作成時の処理を実行する。

この処理は前述した図１２のフローチャートとほぼ同じである。ただし、図１２のステップＳ１２０４０において、管理プログラム１２６５は、スナップショット毎に列を作成するのではなく、前回のリカバリポイントから今回取得したリカバリポイントまでの全てのスナップショットを一つのグループとしてまとめる。具体的には、管理プログラム１２６５は、前回リカバリポイントを取得した直後に取得したジャーナルの順序番号を始点、今回取得したリカバリポイントの順序番号を終点とした識別子１７０２１を格納する。

例えば、図１７の例では、識別子１０１から１５０が一つのグループに、識別子１５１から２２０が一つのグループに、そして、識別子２２１から３００が一つのグループにまとめられて格納されている。

例えば、管理プログラム１２６５は、順序番号１００においてスナップショットＳＳ＿０１が取得された後、順序番号が１５０であるジャーナルでリカバリポイントが取得された場合は、識別子１７０２１を「１０１から１５０」と設定する。なお、管理プログラム１２６５は、追加したＳｎａｐ／ＪＮＬヘッダフィールド９０２０の有効性フラグ９０２２は、初期値を「有効」に設定する。また、追加された各列の各セルは、必要性フラグ９０３１の初期値を「不必要」と設定し、有効性フラグ９０３２の初期値は空欄とする。

その他の処理は、図１２のフローチャートと同様である。

また、管理プログラム１２６５は、ボリューム障害イベント受信時の処理を実行する。この処理は前述した、図１３とほぼ同様であるが、図１３のステップＳ１３０３０において、次のような処理を実行する。

ジャーナルボリュームを構成している何れかのボリュームに障害が発生していることは判明しているので、管理プログラム１２６５は、障害が発生しているボリュームに格納されているジャーナルの順序番号をジャーナルボリュームテーブル４０００から取得する。そして、管理プログラム１２６５は、状態管理テーブル１７０００のＳｎａｐ／ＪＮＬヘッダフィールド９０２０のうち、取得した順序番号が含まれるＳｎａｐ／ＪＮＬヘッダを検索する。そして、そのＳｎａｐ／ＪＮＬヘッダのデータ有効性フラグを「無効」に設定する。

例えば、順序番号「１２５」のジャーナルに障害が発生した場合は、図１７において、この順序番号「１２５」を含む「１０１から１５０」であるセルの有効性フラグ９０２２を無効に設定する。管理プログラム１２６５は、この処理をジャーナルボリュームテーブルの各行に対して実行する。

なお、その他の処理は図１３のフローチャートと同様である。

このように、本発明の第２の実施の形態によれば、前述した第１の実施形態に挙げた効果に加えて、管理計算機が管理しなければならない管理データを削減することが可能である。

（第３実施形態）
次に第３の実施の形態を説明する。

前述した第１及び第２の実施の形態では、あるリカバリポイントをリカバリする方法は１つであった。しかし、実際には、一つのリカバリポイントのリカバリ方法は一つに限られない。

例えば次のような方法がある
まず、Ｂｅｆｏｒｅジャーナルを使用する方法である。

前述した特許文献１に記載の発明のように、ジャーナルを適用することによって上書きされるデータを、異なる領域に退避させておく。そして、ジャーナル適用を取り消す場合、ジャーナル適用後のスナップショットに、前記退避させたデータを元の箇所に書き戻す。これによって、短時間でジャーナル適用以前のデータイメージを復元することができる。この場合のジャーナルを「Ａｆｔｅｒジャーナル」と呼び、退避させたデータを「Ｂｅｆｏｒｅジャーナル」と呼ぶ。なお、前述の第１及び第２の実施の形態は、Ａｆｔｅｒジャーナルを用いた処理である。

ＡｆｔｅｒジャーナルとＢｅｆｏｒｅジャーナルとを同時に管理する場合は、あるリカバリポイントをリカバリするために、二つの方法を用いることができる。一つ目は、リカバリポイントから時間軸を過去の方向に遡ったときの最初のスナップショットを基底として、このスナップショットにＡｆｔｅｒジャーナルを適用してリカバリする方法である。もう一方は、リカバリポイントから時間軸方向を未来の方向に下ったときの最初のスナップショットを基底として、このスナップショットにＢｅｆｏｒｅジャーナルを適用してリカバリする方法である。

このように、ＡｆｔｅｒジャーナルとＢｅｆｏｒｅジャーナルとを用いて二種類のリカバリ方法を用いることで、ＡｆｔｅｒジャーナルとＢｅｆｏｒｅジャーナルとの双方が無効でない限り、そのリカバリポイントは有効である。従って、ディスク装置の障害が発生したとしても、無効となるリカバリポイントが減り、バックアップ運用に対する耐障害性が高くなる。

また、Ｂｅｆｏｒｅジャーナルの利用とは別に、スナップショット時点のリカバリを、そのスナップショットを使用せずに行う方法である。通常、スナップショットを取得した時点にリカバリするには、そのスナップショットのみを使用すればよい。しかし、そのスナップショットを格納しているボリュームに障害が発生した場合には、リカバリができない。そのため、障害の発生したスナップショットの直前のスナップショットに対して、障害の発生したスナップショットまでのジャーナルを適用することによって、障害の発生したスナップショットと同じ時点のデータをリカバリすることが可能である。

このように、あるリカバリポイントにおいてリカバリするための方法が複数存在する場合のリカバリポイントの有効性の管理方法を以降に説明する。

図１８は、第３の実施の形態のジャーナルボリューム１０１３の構成の説明図である。

前述のように、ジャーナルボリューム１０１３は、論理的に、ジャーナルヘッダ領域６０１０とジャーナルデータ領域６０２０とに分割されている。

本実施の形態では、ジャーナルヘッダのエントリ６００８に、さらに、ＢＪＮＬボリュームＩＤ６１０８及びＢＪＮＬ格納アドレス６１０９を含む。

ＢＪＮＬボリュームＩＤ６１０８は、Ｂｅｆｏｒｅジャーナルのジャーナルデータを格納しているボリュームの識別子を格納する。ＢＪＮＬ格納アドレス６１０９はＢｅｆｏｒｅジャーナルのジャーナルデータが格納されているアドレスを格納する。

これらの値は、ストレージマイクロプログラム１０２８が、Ｂｅｆｏｒｅジャーナル作成時に設定する。また、ストレージマイクロプログラム１０２８は、Ｂｅｆｏｒｅジャーナルのジャーナルデータを開放する場合は、ＢＪＮＬボリュームＩＤ６１０８に「ＮＵＬＬ」を、ＢＪＮＬ格納アドレス６１０９に「ＮＵＬＬ」を、それぞれ設定する。

また、ＡＪＮＬボリュームＩＤ６１０６、ＡＪＮＬ格納アドレス６１０７、ＢＪＮＬボリュームＩＤ６１０８、ＢＪＮＬ格納アドレス６１０９の全てがＮＵＬＬの場合は、ストレージマイクロプログラム１０２８は、当該ジャーナルヘッダを開放する。

ストレージマイクロプログラム１０２８は、ホスト計算機１１００から書き込みがあったときに、Ａｆｔｅｒジャーナルを作成したときにのみジャーナルヘッダを作成する。すなわち、Ｂｅｆｏｒｅジャーナルの作成時には、Ｂｅｆｏｒｅジャーナルのジャーナルデータ６０２１が格納されたボリュームの識別子をＢＪＮＬボリュームＩＤ６１０８に、格納されたアドレスをＢＪＮＬ格納アドレス６１０９に設定する。同様に、一度開放したＡｆｔｅｒジャーナルを再作成する場合、Ａｆｔｅｒジャーナルのジャーナルデータ６０２１が格納されたボリュームの識別子をＡＪＮＬボリュームＩＤ６１０６に、格納されたアドレスをＡＪＮＬ格納アドレス６１０７に設定する。

図１９は、管理テーブル１０２９に含まれるジャーナルボリュームテーブル１８０００の一例の説明図ある。

ストレージマイクロプログラム１０２８は、ホスト計算機１１００からジャーナルグループ１０１４に対する書き込みがあるたびに、Ａｆｔｅｒジャーナル又はＢｅｆｏｒｅジャーナルを生成してジャーナルボリューム１０１２に格納する。このとき、ストレージマイクロプログラム１０２８は、生成したジャーナルデータに対応するエントリ４００６を生成して、ジャーナルグループテーブル１８０００に追加する。

ジャーナルボリュームテーブル１８０００は、前述した図４のジャーナルグループテーブル４０００に加え、ジャーナルがＡｆｔｅｒジャーナルであるかＢｅｆｏｒｅジャーナルであるかを示す種別フィールド１８００６、ジャーナルヘッダが格納されているボリュームの識別子を格納するＪＮＬヘッダ格納ＶＯＬフィールド１８００４が追加された構成である。

順序番号フィールド４００２は、順序番号を保持する。順序番号の値は、ストレージマイクロプログラム１０２８は、ホスト計算機１１００からの書き込みに対してＡｆｔｅｒジャーナルを作成するときに、ジャーナルグループテーブル３０００の順序カウンタ３００３に順序番号を設定する。そして、この順序番号取得して、順序番号フィールド４００２に設定する。

又は、バックアッププログラム１２６３は、Ｂｅｆｏｒｅジャーナルの生成を指示するときにＢｅｆｏｒｅジャーナルを元となったＡｆｔｅｒジャーナルを取得し、取得したＡｆｔｅｒジャーナルの順序番号を取得して、順序番号フィールド４００２に設定する。

ボリュームＩＤフィールド４００３、ＪＮＬヘッダ格納ＶＯＬフィールド１８００４及びＪＮＬヘッダ格納アドレスフィールド４００４は、ストレージマイクロプログラム１０２８が、ジャーナルをジャーナルボリューム１０１３に書き込む際に、ジャーナルヘッダ及びジャーナルを書き込む先のボリュームＩＤ及びＪＮＬヘッダ格納アドレスを取得して、取得した値をそれぞれのフィールドに設定する。

図２０は、本実施の形態におけるＢｅｆｏｒｅＪＮＬ作成通知テーブル１９０００の構成である。

Ｂｅｆｏｒｅジャーナル作成通知テーブル１９０００は、ＪＮＬグループＩＤフィールド１９００１、取得時刻フィールド１９００２及びスナップショットボリュームＩＤフィールド１９００３を含む。

バックアッププログラム１２６３は、任意のタイミングで、Ｂｅｆｏｒｅジャーナルを生成する。このとき、あるスナップショットボリュームから時間軸方向に次のスナップショットボリュームまでのＢｅｆｏｒｅジャーナルを生成する。

このときバックアッププログラム１２６３は、生成したＢｅｆｏｒｅジャーナルに対して、Ｂｅｆｏｒｅジャーナル取得の対象であるＪＮＬグループの識別子をＪＮＬグループＩＤフィールド１９００１に設定し、その時点の時刻をタイマ１０２４からから取得して発生時刻フィールド１９００２に設定する。そして、取得したスナップショットボリュームに対する一意の識別子を生成して、スナップショットボリュームＩＤフィールド１９００３に設定する。

バックアッププログラム１２６３は、ＢｅｆｏｒｅＪＮＬ作成通知テーブル１９０００を作成すると、管理プログラム１２６５に対して、作成したＢｅｆｏｒｅＪＮＬ作成通知テーブル１９０００をＢｅｆｏｒｅジャーナル作成イベントとして通知する。なお、この通知は、前述のようにＳＮＭＰトラップを用いるが、その他の通知方法でもよい。

図２１Ａ及び図２１Ｂは、バックアップ管理情報１２６４に含まれる状態管理テーブル２００００の一例の説明図である。

状態管理テーブル２００００は、前述した状態管理テーブル９０００と同様の構成である。ただしＡｆｔｅｒジャーナル及びＢｅｆｏｒｅジャーナルそれぞれについて必要性フラグ及び有効性フラグを設定する。

リカバリポイントヘッダフィールド２００１０はリカバリポイントＩＤ及びその状態を格納する。Ｓｎａｐ／ＪＮＬヘッダフィールド２００２０は各々のリカバリポイントをリカバリするために必要なスナップショットの識別子及びジャーナルの識別子及びその状態を格納する。

リカバリポイントヘッダフィールド２００１０の各リカバリポイントヘッダは、リカバリポイントＩＤ９０１１、リカバリポイント有効性フラグ（Ａｆｔｅｒ）２００１２及びリカバリポイント有効性フラグ（Ｂｅｆｏｒｅ）２００１３を含む。

各リカバリポイントはＡｆｔｅｒジャーナルによってリカバリする方法と、Ｂｅｆｏｒｅジャーナルによってリカバリする方法があるため、有効性フラグをそれぞれの方法について用意する。

Ｓｎａｐ／ＪＮＬヘッダフィールド２００２０を構成する各Ｓｎａｐ／ＪＮＬヘッダは、識別子９０２１、有効性フラグを含む。

有効性フラグは、そのセルがスナップショットを示す場合は、スナップショット有効性フラグ２００２２を格納する。また、そのセルがジャーナルを示す場合はＡｆｔｅｒＪＮＬ有効性フラグ２００２３及びＢｅｆｏｒｅＪＮＬ有効性フラグ２００２４の二つが格納される。

図２１Ｂは、テーブルを構成する各セルの構成の一例の説明図である。

セル２００３０は、必要性フラグ（Ａｆｔｅｒ）２００３１、有効性フラグ（Ａｆｔｅｒ）２００３３、必要性フラグ（Ｂｅｆｏｒｅ）２００３２及び有効性フラグ（Ｂｅｆｏｒｅ）２００３４を含む。

前記したように、各行のリカバリポイントをリカバリするために、Ａｆｔｅｒジャーナルを用いた方法と、Ｂｅｆｏｒｅジャーナルを用いた方法とがある。

そのため、セル２００３０は、Ａｆｔｅｒジャーナルのための必要性フラグ２００３１及び有効性フラグ２００３３と、Ｂｅｆｏｒｅジャーナルのための必要性フラグ２００３２及び２００３４とを含む。

図２１Ａにおいて、リカバリポイント「２００５／９／１ １０：１０」を示す行２００３０Ａでは、リカバリポイント「２００５／９／１ １０：１０」をＡｆｔｅｒジャーナルによってリカバリするために必要なジャーナル及びスナップショットは、必要性フラグが「必要」に設定されている、「ＳＳ＿０１」、「１０１」及び「１０２」の三つであることがわかる。また、ジャーナル「１０１」は無効になっていることがわかる。一方、Ｂｅｆｏｒｅジャーナルによってリカバリするために必要なジャーナル及びスナップショットは、「ＳＳ＿０２」、「１０３」の三つであり、全てが有効であることがわかる。

従って、このリカバリポイント「２００５／９／１ １０：１０」は、Ａｆｔｅｒジャーナルでのリカバリは「無効」であるが、Ｂｅｆｏｒｅジャーナルでのリカバリは「有効」である。

次に第３の実施の形態の計算機システムの動作を説明する。

管理プログラム１２６５は、前述のように、システム設定時の情報の設定、バックアッププログラムからのイベント受信時の状態管理テーブルの更新及びボリューム障害イベント受信時の状態管理テーブルの更新の３つの処理を実行する。

システム設定時の情報の設定は前述の第１の実施形態の図１１のフローチャートと同一である。

図２２は、第３の実施の形態のリカバリポイント作成時の処理のフローチャートである。

バックアッププログラム１２６３は、リカバリポイントを作成するタイミングで、管理プログラム１２６５に対してリカバリポイント作成イベント発行する。また、あるスナップショットまで作成したタイミングで、管理プログラム１２６５に対してＢｅｆｏｒｅＪＮＬ作成通知イベントを発行する。

管理プログラム１２６５は、バックアッププログラム１２６３が発行したリカバリポイント作成イベント、又は、ＢｅｆｏｒｅＪＮＬ作成通知イベントを受信したときに、本フローチャートの処理を開始する。

まず、管理プログラム１２０６は、受信したイベントの種別が、リカバリポイント作成イベントであるか、Ｂｅｆｏｒｅジャーナル作成通知イベントであるかを判定する（ステップ２１０１０）。

まず、リカバリポイント作成イベントである場合の処理を説明する。

ステップＳ２１１００において、管理プログラム１２６５は、状態管理テーブル９０００に新規行を追加し、追加した行をカレント行に設定する（ステップＳ２１１１０）。

このとき、管理プログラム１２６５は、追加した行のリカバリポイントヘッダのリカバリポイントＩＤには初期値として、リカバリポイントテーブル７０００の取得時刻７００２を格納する。また、管理プログラム１２６５は、有効性フラグ２００１２に、初期値として「有効」を設定し、有効性フラグ２００１４に、初期値として空欄とする。また、追加した新規行の各セルは、必要性フラグ（Ａｆｔｅｒ）２００３１に、初期値として「不必要」を設定する。また、有効性フラグ（Ａｆｔｅｒ）２００３３は空欄とする。必要性フラグ（Ｂｅｆｏｒｅ）２００３２は空欄とする。また、有効性フラグ（Ｂｅｆｏｒｅ）２００３４は空欄とする。

次に、管理プログラム１２６５は、ジャーナルボリュームテーブル１８０００及びスナップショットテーブル５０００を参照して、前回本処理によって生成されたジャーナルよりも後に生成されたジャーナルを、新規列として状態管理テーブル１８０００に追加する。管理プログラム１２６５は、追加した各列のＳｎａｐ／ＪＮＬヘッダに、ジャーナルボリュームテーブル１８０００に格納されている順序番号フィールド４００２の値を、ジャーナルＩＤとして設定する。また、有効性フラグに、初期値として「有効」及び「−」を設定する。また、追加した新規行の各セルは、必要性フラグ（Ａｆｔｅｒ）２００３１に、初期値として「不必要」を設定する。また、有効性フラグ（Ａｆｔｅｒ）２００３３は空欄とする。必要性フラグ（Ｂｅｆｏｒｅ）２００３２は空欄とする。また、有効性フラグ（Ｂｅｆｏｒｅ）２００３４は空欄とする（ステップＳ２１１１０）。

続いて、カレント行のフラグの設定を行う。最新のスナップショットから今回作成されたリカバリポイントまでのセルの必要性フラグ（Ａｆｔｅｒ）に「必要」を、有効性フラグ（Ａｆｔｅｒ）に「有効」をセットする。（ステップ２１１２０）
次に、管理プログラム１２６５は、スナップショットテーブル５０００及びリカバリポイントテーブル７０００を参照して、カレント行のリカバリポイントでスナップショットが取得されたか否かを判定する（ステップ２１１３０）。

スナップショットが取得されていなければ処理を終了する。

カレント行のリカバリポイントでスナップショットが取得されたと判定した場合は、管理プログラム１２６５は、取得したスナップショットを新規列として状態管理テーブル２００００に追加する（ステップＳ２１１４０）
続いて、管理プログラム１２６５は、ステップ２１１４０において追加されたスナップショットのセルの必要性フラグ（Ｂｅｆｏｒｅ）２００３２に「必要」を設定し、有効性フラグ（Ｂｅｆｏｒｅ）２００３４に「有効」を設定する。なお、スナップショットは、Ｂｅｆｏｒｅジャーナルを用いなくてもリカバリ可能であるが、スナップショットのみのリカバリの有効性を表すためにＢｅｆｏｒｅのフィールドを設定する（ステップＳ２１１５０）
次に、ＢｅｆｏｒｅＪＮＬ作成通知イベントであった場合処理を説明する。

管理プログラム１２６５は、Ｓｎａｐ／ＪＮＬヘッダフィールドにおいて、受信したイベントに含まれているスナップショットボリュームＩＤと同じ識別子のＳｎａｐ／ＪＮＬヘッダと、そのＳｎａｐ／ＪＮＬヘッダよりも一つ前に取得されたスナップショットボリュームＩＤを識別子としてＳｎａｐ／ＪＮＬヘッダとの間に存在する、ジャーナルを示すＳｎａｐ／ＪＮＬヘッダを取得する。そして、取得したジャーナルを示すＳｎａｐ／ＪＮＬヘッダのＢｅｆｏｒｅＪＮＬ有効性フラグを、全て「有効」にセットする（ステップＳ２１２００）。

次に、管理プログラム１２６５は、各リカバリポイントヘッダフィールド２００１０の必要性フラグ（Ａｆｔｅｒ）２００１２を順次参照する。そして、必要性フラグ（Ａｆｔｅｒ）２００１２が有効であるリカバリポイントヘッダがあり、その次のリカバリポイントヘッダが無効である場合に、その次の列に含まれるセルから、次のスナップショットボリュームに含まれるセルの必要性フラグ（Ｂｅｆｏｒｅ）２００３２を、「必要」に設定し、有効性フラグ（Ｂｅｆｏｒｅ）２００３４を、ＢｅｆｏｒｅＪＮＬの有効性フラグと同じ値を設定する（ステップ２１２１０）。

次にボリューム障害イベント受信処理を説明する。

管理プログラム１２６５は、ストレージシステム１０００内の障害管理プログラム１０３５からボリューム障害イベントを受信すると、状態管理テーブル２００００を更新する。この処理は前述した図１３のフローチャートとほぼ同じであるが、以下の処理が異なる。

ステップＳ１３０３０において、障害ボリュームＩＤ２００２と同じボリュームＩＤが存在すると判定した場合は、管理プログラム１２６５は、ジャーナルボリュームテーブル１８０００の各エントリ４００６を順次参照する。そして、参照したエントリ４００６のボリュームＩＤフィールド４００３に格納されているボリュームＩＤが、障害ボリュームＩＤと同じ場合は、その行の種別フィールド１８００６及び順序番号４００２に格納されている値を取得する。

次に、管理プログラム１２６５は、状態管理テーブル９０００を参照して、Ｓｎａｐ／ＪＮＬヘッダフィールド２００２０のうち、取得した順序番号と同じ値を持つＳｎａｐ／ＪＮＬヘッダがあれば、取得した種別フィールドの値に応じて、そのＳｎａｐ／ＪＮＬヘッダのＡｆｔｅｒＪＮＬ有効性フラグ２００２３又はＢｅｆｏｒｅＪＮＬ有効性フラグ２００２４を、「無効」に設定する。

この処理によって、状態管理テーブル１８０００において、障害ボリュームＩＤに対応するスナップショットボリュームＩＤのスナップショットが「無効」に設定される。

そして、ステップＳ１３０６０において、管理プログラム１２６５は、状態管理テーブル２００００のＳｎａｐ／ＪＮＬヘッダフィールド９０２０に含まれるＳｎａｐ／ＪＮＬヘッダを順次参照する。そして、参照したＳｎａｐ／ＪＮＬヘッダの有効性フラグ２０００２２が「無効」であれば、その列に含まれる各セルを順次参照する。そして、参照したセルの必要性フラグ（Ａｆｔｅｒ）２００３１が「必要」である場合は、当該セルの有効性フラグ（Ａｆｔｅｒ）２００３３を「無効」に変更する。また、参照したセルの必要性フラグ（Ｂｅｆｏｒｅ）２００３２が「必要」である場合は、当該セルの有効性フラグ（Ｂｅｆｏｒｅ）２００３４を「無効」に変更する。管理プログラム１２６５は、この処理を、Ｓｎａｐ／ＪＮＬヘッダフィールド２００２０の全てのＳｎａｐ／ＪＮＬヘッダについて実行する
そして、ステップＳ１３０７０において、管理プログラム１２６５は、まず、状態管理テーブル２００００のリカバリポイントヘッダフィールド２００１０に含まれるリカバリポイントヘッダを順次参照する。そして、参照したリカバリポイントヘッダに対応するセルのうち、有効性フラグ（Ａｆｔｅｒ）２００３２が「無効」に設定されているセルがあるかを判定する。そして、有効性フラグ（Ａｆｔｅｒ）２００３２が「無効」に設定されているセルがあれば、そのリカバリポイントヘッダのリカバリポイント有効性フラグ（Ａｆｔｅｒ）２００１２を「無効」に更新する。

さらに、参照したリカバリポイントヘッダに対応するセルのうち、有効性フラグ（Ｂｅｆｏｒｅ）２００３４が「無効」に設定されているセルがあるかを判定する。そして、有効性フラグ（Ｂｅｆｏｒｅ）２００３４が「無効」に設定されているセルがあれば、そのリカバリポイントヘッダのリカバリポイント有効性フラグ（Ｂｅｆｏｒｅ）２００１３を「無効」に更新する。この処理を、リカバリポイントヘッダフィールド２００１０の全てのリカバリポイントヘッダに実行する
そして、ステップ１３０８０は、更新された状態管理テーブル２００００に基づいて、ユーザに通知する。このとき、管理プログラム１２６５は、リカバリポイントヘッダフィールド２００１０の各セルを参照し、リカバリポイント有効性フラグ（Ａｆｔｅｒ）２００１２、リカバリポイント有効性フラグ（Ｂｅｆｏｒｅ）２００１３の何れかが「有効」であれば、そのリカバリポイントは有効であると判定する。

なお、通知手段として、第１の実施の形態と同様に、図１４乃至図１６のＧＵＩを使用する。

このように本発明の第３の実施の形態では、リカバリポイントをリカバリする手段が複数ある場合に、障害の発生によって、そのうちのいくつかの手段が失われたとしても、一つでも有効な手段が残っていれば、そのリカバリポイントは有効であるものとして、運用を継続することが可能になる。

本発明の第１の実施の形態の計算機システムの構成ブロック図である。 本発明の第１の実施の形態のボリューム障害テーブル２０００の一例の説明図である。 本発明の第１の実施の形態のジャーナルグループテーブル３０００の一例の説明図である。 本発明の第１の実施の形態のジャーナルボリュームテーブル４０００の一例の説明図である。 本発明の第１の実施の形態のスナップショットテーブル５０００の一例の説明図である。 本発明の第１の実施の形態のジャーナルボリューム１０１３の構成の説明図である。 本発明の第１の実施の形態のリカバリポイントテーブル７０００の一例の説明図である。 本発明の第１の実施の形態のアプリケーションテーブル８０００の一例の説明図である。 本発明の第１の実施の形態の状態管理テーブル９０００の一例の説明図である。 本発明の第１の実施の形態のバックアップ対象アプリケーション情報設定画面１００００の説明図である。 本発明の第１の実施の形態のバックアップ対象アプリケーションの設定のフローチャートである。 本発明の第１の実施の形態のリカバリポイント作成時の処理のフローチャートである。 本発明の第１の実施の形態のボリューム障害イベント受信時の処理のフローチャートである。 本発明の第１の実施の形態のユーザへの通知のＧＵＩの一例の説明図である。 本発明の第１の実施の形態のユーザへの通知のＧＵＩの他の例の説明図である。 本発明の第１の実施の形態の物理ビューＧＵＩ１６０００である。 本発明の第２の実施の形態の状態管理テーブル１７０００の一例の説明図である。 本発明の第３の実施の形態のジャーナルボリューム１０１３の構成の説明図である。 本発明の第３の実施の形態のジャーナルボリュームテーブル１８０００の一例の説明図である。 本発明の第３の実施の形態のＢｅｆｏｒｅ ＪＮＬ作成通知テーブル１９０００の一例の説明図である。 本発明の第３の実施の形態の状態管理テーブル２００００の一例の説明図である。 本発明の第３の実施の形態の状態管理テーブル２００００の一例の説明図である。 本発明の第３の実施の形態のリカバリポイント作成時の処理のフローチャートである。

符号の説明

１０００：ストレージ装置
１０１０：ディスク装置
１０２０：ディスクコントローラ
１１００：ホスト計算機
１２００：管理計算機
１３００：データネットワーク
１４００：管理ネットワーク

Claims (15)

1. データを格納するディスク装置と、前記ディスク装置への前記データの読み書きを制御する制御装置とを備えたストレージシステムと、
   前記ストレージシステムにネットワークを介して接続され、前記ディスク装置に格納されたデータの読み書きを要求するホスト計算機と、
   前記ストレージシステム及び前記ホスト計算機の少なくとも一方に接続され、前記ホスト計算機及び前記ストレージシステムを管理する管理計算機と、
   を備える計算機システムで実行されるデータの管理方法であって、
   前記ディスク装置は、前記ホスト計算機によって読み書きされるデータを格納するデータボリュームと、前記ホスト計算機によって書き込まれたデータの差分であるジャーナルデータを書き込み要求毎に格納するジャーナルボリュームと、前記データボリュームの過去の所定の時刻での復元データであるスナップショットを提供するスナップショットボリュームと、を備え、
   前記所定の時刻を示すリカバリポイントを設定する第１のステップと、
   前記設定されたリカバリポイント時点のデータを復元するために必要な前記スナップショットと前記ジャーナルデータとの対応情報を作成する第２のステップと、
   前記ディスク装置の障害の発生を検出する第３のステップと、
   前記ディスク装置の障害によって、データの復元が不可能となったリカバリポイントを検出する第４のステップと、を備えることを特徴とするデータ管理方法
2. 前記第４のステップは、さらに、データの復元が不可能となったリカバリポイントをユーザに通知するステップを備えることを特徴とする請求項１に記載のデータ管理方法。
3. 前記ホスト計算機は、前記ディスク装置に格納されたデータの読み書きを要求する複数のアプリケーションを実行しており、前記アプリケーションはそれぞれ、異なるデータボリューム、ジャーナルボリューム及びスナップショットボリュームを利用しており、
   前記第４のステップは、さらに、データ復元が不可能となったリカバリポイントを利用している前記アプリケーションを特定するステップし、データの復元が不可能となったリカバリポイントと当該リカバリポイントに関係するアプリケーションとを関連付けてユーザに通知するステップを備えることを特徴とする請求項１に記載のデータ管理方法。
4. 前記第４のステップは、前記ディスク装置の障害によってジャーナルボリューム及びスナップショットボリュームの少なくとも一つに障害が発生したときに、前記障害が発生したジャーナルボリュームに格納されているジャーナルデータ又は前記障害が発生したスナップショットボリュームに格納されているスナップショットが、前記作成した対応情報に含まれているときは、前記対応情報に係るリカバリポイントはデータの復元が不可能となったことを検出することを特徴とする請求項１に記載のデータ管理方法。
5. 前記第２のステップは、所定のリカバリポイント時点のデータを復元するために必要となる、前記ジャーナルデータと前記スナップショットとの対応関係を作成するときに、そのリカバリポイントの直前のリカバリポイント時点以降、かつ、そのリカバリポイント時点以前に格納されたジャーナルデータを一つのグループとして、前記対応情報を作成することを特徴とする請求項１に記載のデータ管理方法
6. データを格納するディスク装置を備えたストレージシステムと、前記前記ディスク装置に格納されたデータの読み書きを要求するホスト計算機と、にネットワークを介して接続されるインターフェースと、前記インターフェースに接続されたプロセッサと、プログラム及び情報を格納するメモリと、ユーザに情報を表示する表示装置と、を備える管理計算機であって、
   前記ディスク装置は、前記ホスト計算機によって読み書きされるデータを格納するデータボリュームと、前記ホスト計算機によって書き込まれたデータの差分であるジャーナルデータを書き込み要求毎に格納するジャーナルボリュームと、前記データボリュームの過去の所定の時刻での復元データであるスナップショットを提供するスナップショットボリュームと、を備え、
   前記プロセッサは、
   前記ストレージシステムに、前記所定の時刻を示すリカバリポイントの設定を要求し、
   前記ストレージシステムに、前記設定されたリカバリポイント時点のデータを復元するために必要な、前記スナップショット及び前記ジャーナルデータの情報を要求し、
   前記要求の結果取得した前記スナップショットと前記ジャーナルデータとの対応情報を前記メモリに格納し、
   前記ストレージシステムから前記ディスク装置の障害の発生が通知されたときに、当該ストレージシステムに、前記障害が発生した前記ジャーナルボリューム又は前記スナップショットボリュームを問い合わせ、
   前記問い合わせの結果取得した前記ジャーナルボリューム又は前記スナップショットボリュームが前記対応情報に含まれているときは、前記対応情報に係るリカバリポイントはデータの復元が不可能となったことを検出することを特徴とする管理計算機。
7. 前記プロセッサは、データの復元が不可能となったリカバリポイントを前記表示装置に表示することによって、ユーザに通知することを特徴とする請求項６に記載の管理計算機。
8. 前記ホスト計算機は、前記ディスク装置に格納されたデータの読み書きを要求する複数のアプリケーションを実行しており、前記アプリケーションはそれぞれ、異なるデータボリューム、ジャーナルボリューム及びスナップショットボリュームを利用しており、
   前記プロセッサは、
   前記ホスト計算機に、データの復元が不可能となったリカバリポイントを利用している前記アプリケーションを問い合わせ、
   前記問い合わせの結果、データの復元が不可能となったリカバリポイントと、当該リカバリポイントに関係するアプリケーションとを関連付けて前記表示装置に表示することによって、ユーザに通知することを特徴とする請求項６に記載の管理計算機。
9. 前記プロセッサは、
   前記ストレージシステムから前記ディスク装置の障害が通知されたときに、当該ストレージシステムに、前記障害が発生したジャーナルボリュームを問い合わせ、
   前記問い合わせの結果と前記対応関係とを参照して、前記障害が発生したジャーナルボリュームに格納されたジャーナルデータ又は前記障害が発生した前記スナップショットボリュームに格納されているスナップショットが前記対応関係に含まれているときに、前記対応情報に係るリカバリポイントはデータの復元が不可能となったことを検出することを特徴とする請求項６に記載の管理計算機。
10. 前記プロセッサは、前記要求の結果取得された前記スナップショットと前記ジャーナルデータとの対応関係を前記メモリに格納するときに、そのリカバリポイントの直前のリカバリポイント時点以降、かつ、そのリカバリポイント時点以前に格納されたジャーナルデータを一つのグループとして、前記対応情報を作成することを特徴とする請求項６に記載の管理計算機。
11. データを格納するディスク装置に接続されるディスクインターフェースと、ホスト計算機及び管理計算機に接続される第１のインターフェースと、前記ディスク装置への前記データの読み書きを制御する第１のプロセッサと、プログラム及び情報を格納する第１のメモリと、を含む制御装置と、ディスク装置と、を備えたストレージシステムと、
    前記ストレージシステム及び管理計算機にネットワークを介して接続される第２のインターフェースと、前記ディスク装置に格納されたデータの読み書きを要求する第２のプロセッサと、プログラム及び情報を格納する第２のメモリを備えるホスト計算機と、
    前記ストレージシステム及び前記ホスト計算機の少なくとも一方にネットワークを介して接続される第３のインターフェースと、前記インターフェースに接続される第３のプロセッサと、プログラム及び情報を格納する第３のメモリと、表示装置と、を備える管理計算機と、
    を備える計算機システムであって、
    前記ディスク装置は、前記ホスト計算機によって読み書きされるデータを格納するデータボリュームと、前記ホスト計算機によって書き込まれたデータの差分であるジャーナルデータを書き込み要求毎に格納するジャーナルボリュームと、前記データボリュームの過去の所定の時刻での復元データであるスナップショットを提供するスナップショットボリュームと、を備え、
    前記第３のプロセッサは、
    前記ストレージシステムに、前記所定の時刻を示すリカバリポイントの設定を要求し、
    前記ストレージシステムに、前記設定されたリカバリポイント時点のデータを復元するために必要な、前記スナップショット及び前記ジャーナルデータの情報の取得を要求し、
    前記要求の結果取得された前記スナップショットと前記ジャーナルデータとの対応情報を前記第３のメモリに格納し、
    前記第１のプロセッサは、
    前記ディスク装置の障害の発生を検出し、
    前記検出された障害を前記管理計算機に通知し、
    前記第３のプロセッサは、
    前記ストレージシステムから前記ディスク装置の障害の発生が通知されたときに、当該ストレージシステムに、前記障害が発生している前記ジャーナルボリューム及び前記スナップショットボリュームを問い合わせ、
    前記問い合わせの結果取得した前記ジャーナルボリューム及び前記スナップショットボリュームが前記対応情報に含まれているときは、前記対応関係に係るリカバリポイントはデータの復元が不可能となったことを検出することを特徴とする計算機システム。
12. 前記第３のプロセッサは、データの復元が不可能となったリカバリポイントを前記表示装置に表示することによって、ユーザに通知することを特徴とする請求項１１に記載の計算機システム。
13. 前記第２のプロセッサは、前記ディスク装置に格納されたデータの読み書きを要求する複数のアプリケーションを実行しており、前記アプリケーションはそれぞれ、異なるデータボリューム、ジャーナルボリューム及びスナップショットボリュームを利用しており、
    前記第３のプロセッサは、
    前記ホスト計算機に、データの復元が不可能となったリカバリポイントを利用する前記アプリケーションを問い合わせ、
    前記問い合わせの結果、データの復元が不可能となったリカバリポイントと、当該リカバリポイントに関係するアプリケーションとを関連付けて前記表示装置に表示することによって、ユーザに通知することを特徴とする請求項１１に記載の計算機システム。
14. 前記第３のプロセッサは、
    前記ストレージシステムから前記ディスク装置の障害が通知されたときに、当該ストレージシステムに、前記障害が発生している前記ジャーナルボリューム又はスナップショットボリュームを問い合わせ、
    前記問い合わせの結果と前記対応関係とを参照して、前記障害の発生したジャーナルボリュームに格納されたジャーナルデータ又は前記障害の発生したスナップショットボリュームに格納されているスナップショットが前記対応関係に含まれているときに、前記対応情報に係るリカバリポイントはデータの復元が不可能となったことを検出することを特徴とする請求項１１に記載の計算機システム。
15. 前記第３のプロセッサは、前記要求の結果取得された前記スナップショットと前記ジャーナルデータとの対応関係を前記メモリに格納するときに、そのリカバリポイントの直前のリカバリポイント時点以降、かつ、そのリカバリポイント時点以前に格納されたジャーナルデータを一つのグループとして、前記対応情報を作成することを特徴とする請求項１１に記載の計算機システム。