JP4115060B2 - 情報処理システムのデータ復旧方法及びディスクサブシステム - Google Patents
情報処理システムのデータ復旧方法及びディスクサブシステム Download PDFInfo
- Publication number
- JP4115060B2 JP4115060B2 JP2000030217A JP2000030217A JP4115060B2 JP 4115060 B2 JP4115060 B2 JP 4115060B2 JP 2000030217 A JP2000030217 A JP 2000030217A JP 2000030217 A JP2000030217 A JP 2000030217A JP 4115060 B2 JP4115060 B2 JP 4115060B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- disk device
- data
- pair
- disk
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Description
【０００１】
【発明の属する技術分野】
本発明は、オンライン処理やバッチ処理を実行する情報処理システムに関し、特に、オンライン処理やバッチ処理の障害などによって破壊されたディスク装置などの記憶装置に格納されたデータを復旧するための方法に関する。
【０００２】
【従来の技術】
銀行や証券会社などの情報処理システムで行われるオンライン処理やバッチ処理では、プログラムのバグや記憶装置の障害などによってそれらの処理が異常終了し、データを矛盾した状態にしてしまうことがある。また、情報処理システムに携わる人間の人為的ミスによって大切なデータを破壊したり、消去してしまうことがある。
【０００３】
このような状態になった情報処理システムを回復させ、データの矛盾を解消して途中で止まった処理を再開させたり、あるいは、途中で止まった処理をもう一度やり直したりするための手段がいくつか知られている。そのうちのひとつの手段にバックアップとリストアによる回復処理がある。
【０００４】
バックアップとリストアによる回復処理では、例えば、データベースシステムの場合、磁気テープなどの記憶媒体に定期的にデータのバックアップが取得される。システムに障害が発生した場合は、磁気テープに取得されたバックアップから記憶装置にデータをリストアし、ログファイルを使用して適切なポイントまで記憶装置のデータを再構築する。このような処理により、データベースのデータを適切な状態に回復し、データベース処理を再開させることができる。
【０００５】
バッチ処理の場合には、処理の開始に先立って磁気テープにデータのバックアップが取得される。バッチ処理の開始後、処理が異常終了した場合、磁気テープからデータがリストアされ、記憶装置のデータがバッチ処理を開始する前の状態に戻される。その後、バッチ処理が最初から再実行される。
【０００６】
【発明が解決しようとする課題】
従来のバックアップとリストアによる回復処理では、磁気テープからデータをリストアする際、バックアップを取得した時点から更新されていない部分（記憶装置と磁気テープの内容が一致している部分）のデータも磁気テープから読み出され、記憶装置に書き込まれる。このようなデータの転送は、無駄なデータ転送であり、リストアに要する時間を長びかせる。
【０００７】
また、例えば、記憶装置内の領域Ａ、領域Ｂおよび領域Ｃがバックアップ／リストアの単位であり、回復を必要とするのが領域Ａだけである場合でも、領域Ａ〜Ｃについてリストアが実行され、リストア時間が長くなる。リストア中は、領域Ａ〜Ｃ上のデータを利用する処理を停止する必要があり、その影響は大きい。
【０００８】
本発明の目的は、これら従来技術における問題点を解決し、バックアップからのデータのリストアを高速化し、システム障害からの回復に要する時間を短縮させることのできるデータの復旧方法を提供することにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明によれば、中央処理装置と、ディスク装置を備え、前記中央処理装置からの要求にしたがってデータ転送を実行するディスクサブシステムとを有する情報処理システムにおいて、一連の処理によってディスク装置内のデータを更新する前に、情報処理装置からディスクサブシステムに対して、前記一連の処理で使用されるディスク装置に格納されているデータの写しを保存する保存要求を発行する。ディスクサブシステムは、保存要求に応答して、ディスク装置のデータの写しを保存する。中央処理装置により実行される一連の処理によりディスク装置の内容が更新されたとき、ディスクサブシステムは、更新された場所を差分情報として記憶する。ディスク装置の内容をある時点の状態に復旧する必要が生じた場合、ディスクサブシステムは、中央処理装置からデータの復旧要求に応答して、記憶された前記差分情報に基づいて、保存されたデータを前記ディスク装置にリストアする。
【００１０】
本発明の他の観点によれば、中央処理装置と、ディスク装置を備え、中央処理装置からの要求にしたがってデータ転送を実行するディスクサブシステムとを有する情報処理システムにおいて、ディスクサブシステムは、中央処理装置からのリストア要求に応答して、中央処理装置がアクセスする論理ボリュームのデータを格納した第１のディスク装置に保持されているデータのバックアップデータを第２のディスク装置にリストアする。そして、中央処理装置からのスワップ要求に応答して、論理ボリュームを第２のディスク装置と関連付ける。その後、中央処理装置からの論理ボリュームへのアクセス要求に応答して、ディスクサブシステムは、第２のディスク装置のデータにアクセスする。
【００１１】
【発明の実施の形態】
図１は、本発明の第１の実施形態における情報処理システムのシステム構成を示すブロック図である。本実施形態の情報処理システムは、ホストコンピュータ（ホスト）１０１とディスクサブシステム１０９を含んで構成される。ディスクサブシステム１０９は、スモール・コンピュータ・システム・インタフェース（ＳＣＳＩ）やファイバ・チャネル（Fibre Channel）などのインタフェースバス１０３を介してホスト１０１と接続される。ホスト１０１とディスクサブシステム１０９との間は、ＳＣＳＩプロトコルやＦｉｂｒｅプロトコルなどによって、情報の授受が行われる。
【００１２】
ディスクサブシステム１０９は、ホストインタフェース１１２、制御プロセッサ１０５、制御メモリ１０６、ボリュームアクセス部１０７およびボリューム１０８を有する。ホストインタフェース１０５は、ホスト１０１とのインタフェースである。制御プロセッサ１０５は、ホストインタフェース１１２により受信されたホスト１０１からの要求にしたがって、ディスクサブシステム１０９を制御する。制御メモリ１０６は、制御プロセッサ１０５がディスクサブシステム１０９を制御するために必要な制御情報を格納するメモリである。本発明に関係する情報として、ペア情報１１０および差分情報１１１が制御メモリ１０６に保持される。ボリュームアクセス部１０７は、ボリューム１０８に対してデータのリード／ライトを行う機能を有する。ボリューム１０８は、データを格納する磁気ディスク媒体を備えたディスクユニットなどから構成され、おのおのを識別するための識別子が割り当てられている。
【００１３】
制御メモリ１０６は、１、又は複数のペア情報１１０を保有する。図２は、ペア情報１１０の一例を示すデータ構造図である。
【００１４】
ペア情報１１０は、使用中フラグ２００、正ボリューム番号２０１、副ボリューム番号２０２、差分情報番号２０３、ペア状態２０４、エクステント情報２０５を有して構成される。
【００１５】
使用中フラグ２００は、当該ペア情報１１０が使用されているかどうかを示すフラグで、“使用中”または“未使用”の値をとる。使用中フラグ２００が“使用中”のとき、当該ペア情報１１０は、使用中であることが示される。使用中フラグ２００が“未使用”のとき、当該ペア情報１１０は、未使用であることが示される。
【００１６】
正ボリューム番号２０１、副ボリューム番号２０２は、ボリューム１０８を識別する識別子である。以下では、正ボリューム番号２０１により識別されるボリュームを正ボリューム、副ボリューム番号２０２により特定されるボリュームを副ボリュームと呼ぶ。差分情報番号２０３は、差分情報１１１を識別する識別子である。正ボリュームと副ボリュームの組をここではペアと呼ぶ。ペアには、“ペア形成中”、“ペア形成完了”、“ペア分割”、“データ復旧中”および“ペアなし”という状態がある。ペア状態２０４は、ペアについてのこれらの状態を示す。
【００１７】
エクステント情報２０５は、開始アドレス２０７、終了アドレス２０８から構成される。開始アドレス２０７は、ボリューム１０８内の連続する領域の始端のアドレスを示す。終了アドレス２０８は、ボリューム１０８内の連続する領域の終端のアドレスを示す。例えば、ボリューム１０８が固定長ブロックから構成される固定長ブロック形式のボリュームである場合、開始アドレス２０７および終了アドレス２０８にはブロック番号が格納される。また、ボリューム１０８が可変長レコード形式のボリュームである場合、開始アドレス２０７および終了アドレス２０８にはトラック番号が格納される。以下では、説明を分かりやすくする為に、データを格納する領域として、トラックという言葉を使用する。したがって、トラックという言葉に、可変長レコード形式ボリュームのトラックを当てはめても良いし、固定長ブロック形式ボリュームのブロックを当てはめても良い。また、ボリューム１０８内の先頭からｉ番目のトラックをトラック（ｉ）と表記する。
【００１８】
制御メモリ１０６は、１又は複数の差分情報１１１を保有する。差分情報１１１のデータ構造の一例を図３に示す。
【００１９】
差分情報１１１は、使用中フラグ３０１、コピー対象ビットマップ３０２および差分ビットマップ３０３を保有する。使用中フラグ３０１は、当該差分情報１１１が使用中かどうかを示すフラグで、“使用中”または“未使用”の値をとる。使用中フラグ３０１が“使用中”であるとき、当該差分情報１１１は、使用中であることが示される。使用中フラグ３０１が“未使用”のとき、当該差分情報１１１は、未使用状態であることが示される。
【００２０】
コピー対象ビットマップ３０２は、副ボリュームから正ボリュームへコピーするデータを示す情報で、複数のビットから構成される。１ビットは、ボリューム８上の１つのトラックに対応する。ビットが０のとき、そのビットに対応するトラック（またはブロック）はコピー対象ではないことが示され、ビットが１のとき、そのビットに対応するトラック（またはブロック）がコピー対象であることが示される。以下、コピー対象ビットマップ３０２のｉ番目のビットをコピー対象（ｉ）と表記する。すなわち、トラック（ｉ）に対応するビットは、コピー対象（ｉ）である。
【００２１】
差分ビットマップ３０３は、正ボリュームと副ボリュームの対応するトラック間でデータの内容が異なっているトラックを示す情報で、複数のビットから構成される。コピー対象ビットマップ３０２と同様に、１つのビットは、１つのトラックに対応する。ビットが０のとき、そのビットに対応するトラックのデータは、正ボリュームと副ボリュームとの間で異なっていないことが示される。一方、ビットが１のとき、そのビットに対応するトラックのデータは、正ボリュームと副ボリュームとの間で異なっていることが示される。以下、差分ビットマップ３０３のｉ番目のビットを差分（ｉ）と表記する。すなわち、トラック（ｉ）に対応するビットは、差分（ｉ）である。
【００２２】
図４は、バッチ処理を実行する時のホスト１０１による処理の流れを示すフローチャートである。
【００２３】
ホスト１０１は、実行しようとするバッチ処理で使用されるデータを格納したボリューム１０８の識別子（以下、このボリューム１０８の識別子をＳと表記する）を正ボリューム番号、未使用のボリューム１０８の識別子（以下、このボリューム１０８の識別子をＴと表記する）を副ボリューム番号として、これらをパラメータとして含むペア形成要求を作成し、ディスクサブシステム１０９に発行する（ステップ４００）。
【００２４】
ペア形成要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。ペア状態参照要求に対する応答として、ディスクサブシステム１０９から報告されるペア状態が“ペア形成完了”の場合、ステップ４０２に進む。ディスクサブシステム１０９から報告されるペア状態が“ペア形成完了”以外の場合、報告されるペア状態が“ペア形成完了”となるまで待つ（ステップ４０１）。
【００２５】
ペア状態が“ペア形成完了”になると、ホスト１０１は、例えば、オンライン処理の区切りなどバッチ処理を開始する契機まで待つ（ステップ４０２）。
【００２６】
バッチ処理を開始する契機になると、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア分割要求を作成し、ディスクサブシステム１０９に発行する（ステップ４０３）。
【００２７】
ペア分割要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。ペア状態参照要求に対する応答として、ディスクサブシステム１０９から報告されるペア状態が“ペア分割”の場合、ステップ４０５に進む。ディスクサブシステム１０９から報告されるペア状態が“ペア分割”以外の場合、ホスト１０１は、ペア状態が“ペア分割”になるまで待つ（ステップ４０４）。
【００２８】
ペア状態が“ペア分割”になると、ホスト１０１は、バッチ処理を開始する（ステップ４０５）。
【００２９】
バッチ処理が途中で異常終了すると、バッチ処理のリトライのために、バッチ処理を実行する前のデータが必要とされる。この場合、ステップ４０７に進む。バッチ処理が正常終了した場合は、ステップ４１０に進む。（ステップ４０６）バッチ処理が異常終了し、バッチ処理を実行する前のデータが必要になった場合、ホスト１０１は、データの回復を行うボリューム１０８内の領域を求める。この領域は、ログファイルを解析して、異常終了したバッチ処理の実行中に更新のあった部分を特定することにより行われる。または、ユーザからの指定を受け付けても良い。以降、求められた領域の始端のアドレスをＢ、終端のアドレスをＥと表記する。
【００３０】
続いて、ホスト１０１は、正ボリューム番号の値としてＳ、副ボリューム番号の値としてＴ、開始アドレスの値がＢ、終了アドレスの値がＥをパラメータとして有するデータ復旧要求を作成し、ディスクサブシステム１０９に発行する（ステップ４０７）。
【００３１】
データ復旧要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとするペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答として、ディスクサブシステム１０９から報告されるペア状態が“ペア分割”の場合、ステップ４０９に進む。ディスクサブシステム１０９から報告されるペア状態が“ペア分割”以外の場合、ホスト１０１は、報告されるペア状態が“ペア分割”になるまで待つ（ステップ４０８）。
【００３２】
ペア状態が“データ分割”になると、データの回復が完了しているので、ホスト１０１は、バッチ処理を再実行する（ステップ４０９）。
【００３３】
バッチ処理が正常終了すると、ホスト１０１は、正ボリューム番号の値Ｓ、副ボリューム番号の値Ｔをパラメータとして有するペア解除要求を作成し、ディスクサブシステム１０９に発行する（ステップ４１０）。
【００３４】
ペア解除要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペアなし”の場合、処理を終了する。ディスクサブシステム１０９から報告されるペア状態が“ペアなし”以外の場合、ペア状態が“ペアなし”になるまで待つ（ステップ４１１）。
【００３５】
以上説明したホスト１０１の処理では、バッチ実行前の状態にデータを回復してから、バッチ処理を再実行させたが、ステップ４０９において、ログファイルを使って、適切なところまでデータの更新を行ってからバッチ処理を実行しても良い。
【００３６】
図５は、ホスト１０１からの要求に応答してディスクサブシステム１０９により行われる処理の処理フローを示すフローチャートである。
【００３７】
ディスクサブシステム１０９は、ホスト１０１から要求を受領するとステップ５００〜５０５において、その要求がペア形成要求、ペア分割要求、ペア削除要求、データ復旧要求、及びペア状態参照要求のいずれかに該当するか判別する。
【００３８】
ホスト１０１からの要求がペア形成要求である場合、ディスクサブシステム１０９は、ペア情報及び差分情報を作成する。具体的に、ディスクサブシステム１０９は、使用中フラグ２００が“未使用”であるペア情報１１０を選択し、選択したペア情報１１０の使用中フラグ２００に“使用中”を設定する。次に、使用中フラグ３０１が“未使用”である差分情報１１１を選択し、選択した差分情報１１１の使用中フラグ３０１に“使用中”を設定する。その後、ディスクサブシステム１０９は、選択したペア情報１１０の正ボリューム番号２０１に、ペア形成要求のパラメータとして設定されている正ボリューム番号Ｓを、副ボリューム番号２０２に、副ボリューム番号Ｔを設定する。また、選択したペア情報１１０の差分情報番号２０３に、選択した差分情報１１１の識別子を設定する。そして、選択したペア情報１１０のペア状態２０４に“ペア形成中”を設定する。次に、ディスクサブシステム１０９は、選択した差分情報１１１のコピー対象ビットマップ３０２、及び差分ビットマップ３０３のすべてのビットを０にする。（ステップ５０６）
ペア情報１１０および差分情報１１１に値を設定したら、ディスクサブシステム１０９は、後述する形成コピー処理を実行する（ステップ５０７）。
【００３９】
形成コピーが完了すると、ディスクサブシステム１０９は、ステップ５０６で選択したペア情報１１０のペア状態２０４に“ペア形成完了”を設定し、処理を終了する（ステップ５０８）。
【００４０】
ホスト１０１から受領した要求がペア分割要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、及び副ボリューム番号２０２に、ペア分割要求のパラメータとして与えられる正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。そして、選択したペア情報１１０のペア状態２０４に“ペア分割”を設定して処理を終了する（ステップ５０９）。
【００４１】
ホスト１０１から受領した要求がペア削除要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、副ボリューム番号２０２に、ペア削除要求のパラメータとして設定されている正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。そして、選択したペア情報１１０の差分情報番号２０３によりポイントされる差分情報１１１の使用中フラグ３０１に“未使用”を設定する。また、選択したペア情報１１０の使用中フラグ２００にも“未使用”を設定する。ディスクサブシステム１０９は、使用中フラグ２００および使用中フラグ３０１の更新が完了すると処理を終了する（ステップ５１０）。
【００４２】
次に、ホスト１０１から受領した要求がデータ復旧要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、副ボリューム番号２０２にデータ復旧要求のパラメータとして設定されている正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。次に、ディスクサブシステム１０９は、選択したペア情報１１０のペア状態２０４に“データ復旧中”を設定する。また、エクステント情報２０５の開始アドレス２０７、及び終了アドレス２０８には、データ復旧要求にパラメータとして設定されている開始アドレスＢ、終了アドレスＥを設定する。さらに、ディスクサブシステム１０９は、選択したペア情報２０３の差分情報番号２０３によりポイントされる差分情報１１１のコピー対象ビットマップ３０２を設定する。すなわち、差分（Ｂ）から差分（Ｅ）までのビットに関して、差分（ｉ）が０のときコピー対象（ｉ）に０を設定し、差分（ｉ）が１のときコピー対象（ｉ）に１を設定する（ステップ５１１）。
【００４３】
ペア情報１１０および差分情報１１１を更新した後、ディスクサブシステム１０９は、後述するデータ復旧処理を実行する（ステップ５１２）。
【００４４】
データ復旧処理が完了すると、ディスクサブシステム１０９は、ステップ５１１で選択したペア情報１１０のペア状態２０４に“ペア分割”を設定して処理を終了する（ステップ５１３）。
【００４５】
ホスト１０１から受領した要求がペア状態参照要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、副ボリューム番号２０２にペア状態参照要求のパラメータとして与えられた正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。次に、ディスクサブシステム１０９は、選択したペア情報１１０のペア状態２０４をホスト１０１に報告して処理を終了する。ここで、該当するペア情報１１０がない場合は、ペア状態として“ペアなし”を報告する（ステップ５１４）。
【００４６】
ホスト１０１からの要求が上述したいずれの要求でもない場合、ステップ５１５において、ホスト１０１からの要求がリード要求であるかライト要求であるかが判定される。この判定の結果、要求がリード要求の場合は、後述するリード処理が行われ（ステップ５１６）、ライト要求の場合には、後述するライト処理が行われる（ステップ５１７）。
【００４７】
図６は、ステップ５０７において実施される形成コピー処理のフローチャートである。
【００４８】
まず、初期設定として、ディスクサブシステム１０９は、変数ｉに０を設定する（ステップ６００）。
【００４９】
次に、ボリュームアクセス部１０７により、ステップ５０６で選択したペア情報１１０の正ボリューム番号２０１に設定された識別子で指定されるボリューム１０８のトラック（ｉ）のデータを読み出す。そして、ボリュームアクセス部１０７により、読み出したデータを副ボリューム番号２０２に設定された識別子で指定されるボリュームのトラック（ｉ）に書き込む（ステップ６０１）。
【００５０】
変数ｉの値が、正ボリュームの最終トラックのトラック番号を超えたか判定する（ステップ６０２）。変数ｉが最終トラックのトラック番号を超えていると、ディスクサブシステム１０９は、形成コピーの処理を終了してステップ５０８に進む。そうでなければ、ステップ６０３の処理に進み、変数ｉに１を加算してステップ６０１に戻り、次のトラックのコピー処理を実行する（ステップ６０３）。
【００５１】
図７は、ステップ５１２で実施されるデータ復旧処理のフローチャートである。
【００５２】
ディスクサブシステム１０９は、まず、変数ｉに初期値としてＢを設定する（ステップ７００）。
【００５３】
次に、ステップ５１１で設定したコピー対象ビットマップ３０２を参照して、コピー対象（ｉ）が０か１かを判定する（ステップ７０１）。コピー対象（ｉ）が０の場合は、ステップ７０４に、１の場合は、ステップ７０３に進む。
【００５４】
ステップ７０３では、ボリュームアクセス部１０７により、副ボリュームのトラック（ｉ）のデータを読み出し、読み出したデータを正ボリュームのトラック（ｉ）に書き込む。そして、コピー対象（ｉ）を０にする。
【００５５】
ステップ７０４で、ディスクサブシステム１０９は、Ｅと変数ｉとを比較し、ｉがＥに等しいか大きい場合にはデータ回復処理を終了し、そうでなければ、ステップ７０５に進む。ステップ７０５では、変数ｉに１を加算してステップ７０１に戻り、次のトラックについて同様の処理が行われる。
【００５６】
図８は、ステップ５１６におけるリード処理のフローチャートである。
【００５７】
ホスト１０１により発行されるリード要求には、パラメータとして、データを読み出すべきボリューム１０８の識別子とトラック番号を含んでいる。以降、パラメータで指定されるボリューム１０８の識別子を“ＲＶＯＬ”、トラック番号を“ＲＴＲＫ”とする。
【００５８】
リード処理では、まず、使用中フラグ２００が“使用中”、正ボリューム番号２０１に“ＲＶＯＬ”が設定されているペア情報１１０が選択される。該当するペア情報１１０がある場合、処理は、ステップ８０１に進む。該当するペア情報１１０がない場合、処理は、ステップ８０４に進む。（ステップ８００）
ステップ８０１でディスクサブシステム１０９は、ステップ８００で選択したペア情報１１０のペア状態２０４を参照し、“データ復旧中”になっているか判定する。ペア状態２０４が“データ復旧中”である場合は、ステップ８０２に進み、そうでなければステップ８０６に進む。
【００５９】
ステップ８０２でディスクサブシステム１０９は、エクステント情報２０５の開始アドレス２０７と終了アドレス２０８によって特定される領域に、トラック“ＲＴＲＫ”が含まれるかどうかを判定する。開始アドレス２０７と終了アドレス２０８によって特定される領域にトラック“ＲＴＲＫ”が含まれていれば、当該領域に対するアクセスを拒否することをホスト１０１に報告してリード処理を終了する（ステップ８０３）。開始アドレス２０７と終了アドレス２０８によって特定される領域にトラック“ＲＴＲＫ”が含まれていない場合は、ボリュームアクセス部１０７により、識別子“ＲＶＯＬ”で識別されるボリューム１０８のトラック“ＲＴＲＫ”のデータが読み出され、ホスト１０１に転送されてリード処理が終了する（ステップ８０６）。
【００６０】
リード対象のボリュームが正ボリュームでない場合、使用中フラグ２００が“使用中”となっているペア情報１１０から、副ボリューム番号２０１が“ＲＶＯＬ”であるペア情報が選択される。該当するペア情報１１０がなければ、ステップ８０６の処理に移り、データの転送が行われ処理が終了する。該当するペア情報１１０があれば、ステップ８０５に進む（ステップ８０４）。
【００６１】
ステップ８０５では、ステップ８０４で選択されたペア情報１１０のペア状態２０４が参照され、“ペア分割”であるか判定される。ペア状態２０４が“ペア分割”であればステップ８０６に進み、データの転送が行われる。ペア状態２０４が“ペア分割”でなければステップ８０３に進み、アクセスが拒否される。
【００６２】
図９は、ステップ５１７で行われるライト処理のフローチャートである。
【００６３】
ホスト１０１により発行されるライト要求は、パラメータに、ボリューム１０８の識別子、トラック番号、およびライトデータを含む。以降、パラメータで指定されるボリューム１０８の識別子を“ＷＶＯＬ”、トラック番号を“ＷＴＲＫ”とする。
【００６４】
ライト処理において、ディスクサブシステム１０９は、まず、使用中フラグ２００が“使用中”、正ボリューム番号２０１の値が“ＷＶＯＬ”であるペア情報１１０を選択する。該当するペア情報１１０があればステップ９０１に進み、該当するペア情報１１０がなければステップ９０４に進む（ステップ９００）。
【００６５】
ステップ９０１では、ステップ９００で選択されたペア情報１１０のペア状態２０４が“データ復旧中”かどうか判定される。ペア状態２０４が“データ復旧中”であればステップ９０２に進み、“データ復旧中”でなければステップ９０８に進む。
【００６６】
ステップ９０８では、ステップ９００で選択されたペア情報１１０のペア状態２０４が“分割中”か判定される。ペア状態２０４が“分割中”であればステップ９０６に進み、“分割中”でなければステップ９０９に進む。
【００６７】
ステップ９０９では、ボリュームアクセス部１０７により、ステップ９００で選択されたペア情報１１０の副ボリューム番号２０２により識別されるボリューム１０８内のトラック“ＷＴＲＫ”にライトデータが書き込まれる。その後、処理は、ステップ９０７に進む。
【００６８】
ステップ９０２では、ステップ９００で選択されたペア情報１１０のエクステント情報２０５の開始アドレス２０７と終了アドレス２０８によって特定される領域に、トラック“ＷＴＲＫ”が含まれるかどうか判定される。該当する領域に、トラック“ＷＴＲＫ”が含まれればステップ９０３に進み、含まれなければステップ９０６に進む。
【００６９】
ステップ９０３でディスクサブシステム１０９は、当該領域へのアクセスを拒否することをホスト１０１に報告して処理を終了する。
【００７０】
ステップ９０４では、使用中フラグ２００が“使用中”、副ボリューム番号２０１の値が“ＷＶＯＬ”であるペア情報１１０が選択される。該当するペア情報１１０があればステップ９０５に進み、該当するペア情報１１０がなければステップ９０７に進む。
【００７１】
ステップ９０５では、ステップ９０４で選択されたペア情報１１０のペア状態２０４が“ペア分割”かどうか判定される。ペア状態２０４が“ペア分割”であればステップ９０６に進み、“ペア分割”でなければステップ９０３に進む。
【００７２】
ステップ９０６でディスクサブシステム１０９は、ステップ９０４で選択したペア情報１１０の差分情報番号２０３により示される差分情報１１１の差分（ＷＴＲＫ）に１を設定する。
【００７３】
ステップ９０７では、識別子が“ＷＶＯＬ”であるボリューム１０８のトラック“ＷＴＲＫ”に、受領したライトデータが書き込まれ、ライト処理が終了する。
【００７４】
上述した第１の実施の形態では、ディスクサブシステム１０９は、ホスト１０１から送られる要求に応答して処理を行う。これらの要求のうち、ペア形成要求、ペア分割要求、ペア削除要求、ペア状態参照要求を遠隔端末１００からディスクサブシステム１０９に与えることも可能である。この場合、制御プロセッサ１０５は、遠隔端末インタフェース１０４を介して、遠隔端末１００から要求を受領して、処理を実行する。処理内容は、上述した各処理と同様となる。
【００７５】
また、上述した実施形態では、データを復旧中の領域に対するリード／ライト要求を拒否しているが、リード処理におけるステップ８０３、ライト処理におけるステップ９０３を以下に説明する処理に変更することで、データを復旧中の領域に対するリード／ライト要求に応じてデータ転送を行うようにすることができる。
【００７６】
図１０は、データを復旧中の領域に対するリード要求に対してデータ転送を行うために、ステップ８０３に替えて行われる処理のフローチャートである。
【００７７】
ディスクサブシステム１０９は、データを復旧中の領域に対するリード要求を処理するに当たり、ペア情報１１０を参照して、リード要求の対象ボリュームを含むペアのペア状態２０４が“データ復旧中”か調べる（ステップ１０００）。ペア状態２０４が“データ復旧中”であれば、次に、ディスクサブシステム１０９は、リード要求の対象領域がコピー対象となっているかどうか調べる。これは、ペア情報１１０の差分情報番号２０３が指している差分情報１１１のコピー対象（ＲＴＲＫ）が０か１かを調べることで実現される。コピー対象（ＲＴＲＫ）が０の場合は、ボリュームアクセス部１０７によりボリューム１０８からデータを読み出してホスト１０１に転送し、処理を終了する（ステップ１００５）。
【００７８】
ステップ１００１でコピー対象であると判定された場合、ディスクサブシステム１０９は、ボリュームアクセス部１０７により副ボリュームのトラック“ＲＴＲＫ”からデータを読み出して、それを正ボリュームのトラック“ＲＴＲＫ”に書き込む（ステップ１００２）。
【００７９】
続いて、ディスクサブシステム１０９は、コピー対象（ＲＴＲＫ）に０を設定する（ステップ１００３）。そして、ボリュームアクセス部１０７により、ボリューム１０８からデータを読み出してホスト１０１に転送し、処理を終了する（ステップ１００４）。
【００８０】
ステップ１０００でペア状態２０４が“データ復旧中”でないと判定された場合は、ホスト１０１にアクセスを拒否することが報告されて処理が終了する（ステップ１００６）。
【００８１】
図１１は、データを復旧中の領域に対するライト要求を処理するために、ステップ９０３に替えて行われる処理のフローチャートである。
【００８２】
ディスクサブシステム１０９は、データを復旧中の領域に対するライト要求を処理するに当たり、ライト要求の対象であるボリュームに関するペア情報１１０を参照して、そのペア状態２０４が“データ復旧中”かどうか調べる（ステップ１１００）。
【００８３】
ペア状態２０４が“データ復旧中”であると判定された場合、ライト要求の対象領域がコピー対象となっているかどうか調べられる。これは、ペア情報１１０の差分情報番号２０３が指す差分情報１１１のコピー対象（ＷＴＲＫ）が０であるか１であるかを調べることにより行われる（ステップ１１０１）。
【００８４】
コピー対象（ＷＴＲＫ）が０の場合は、ステップ１１０４に進む。１の場合はステップ１１０２に進む。
【００８５】
ステップ１１０１でコピー対象（ＷＴＲＫ）が１であり、ライト要求の対象領域がコピー対象であると判定しされた場合、ボリュームアクセス部１０７により、副ボリュームのトラック“ＷＴＲＫ”のデータが読み出され、正ボリュームのトラック“ＷＴＲＫ”にそのデータが書き込まれる（ステップ１１０２）。その後、差分情報１１１のコピー対象（ＷＴＲＫ）に０が設定され、ステップ１１０４の処理に移る（ステップ１１０３）。
【００８６】
ステップ１１０４でディスクサブシステム１０９は、差分情報１１１の差分（ＷＴＲＫ）に１を設定する。続いて、ボリュームアクセス部１０７により、識別子“ＷＶＯＬ”で識別されるボリューム１０８のトラック“ＷＴＲＫ”にライトデータが書き込まれる（ステップ１１０５）。
【００８７】
ステップ１１００でペア状態２０４が“データ復旧中”でないと判定された場合、ディスクサブシステム１０９は、ホスト１０１にアクセスを拒否することを報告して処理を終了する（ステップ１１０６）。
【００８８】
以上の処理により、データを復旧中の領域に対するリード／ライト要求に対しても、その要求に応答してデータのリード／ライト処理を実施することが可能となる。
【００８９】
本発明が適用された情報処理システムの他の実施形態について、以下に説明する。以下に説明する実施形態におけるシステムとしての構成は、図１に示したものと同様であるが、制御プロセッサ１０５において実現される機能が上述した実施形態と異なる。本実施形態では、ホスト１０１（あるいは遠隔端末１００）から発行される要求として、上述した実施形態において説明したペア形成要求、ペア分割要求、ペア削除要求、データ復旧要求、ペア状態参照要求、リード要求およびライト要求に加え、コピーなしペア形成要求が含まれる。制御プロセッサ１０５は、これらの要求に応答して各種の処理を行う。
【００９０】
図１２は、データ回復処理時のホスト１０１側の処理を示すフローチャートである。
【００９１】
データ回復処理時、ホスト１０１は、まず、ディスクサブシステム１２０９にコピーなしペア形成要求を発行する。コピーなしペア形成要求には、パラメータとして、正ボリューム番号と副ボリューム番号が含まれる。正ボリューム番号には、回復するデータを格納するボリューム１０８の識別子が、副ボリューム番号には、データを一時的に格納する未使用のボリューム１０８の識別子が設定される。以下では、処理の対象となる正ボリュームのボリューム番号をＳ、副ボリュームのボリューム番号をＴとして説明する（ステップ１３００）。
【００９２】
ホスト１０１は、コピーなしペア形成要求を発行した後、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペア分割”でなければ、ペア状態が“ペア分割”になるまで待ち、ペア状態が“ペア分割”であることを確認して次の処理に進む（ステップ１３０１）。
【００９３】
次に、ホスト１０１は、回復するデータがバックアップされている磁気テープからデータを読み出す。ホスト１０１は、このデータを、ボリューム番号がＴであるボリューム１０８に書き込むよう、ディスクサブシステム１２０９にライト要求を発行する（ステップ１３０２）。
【００９４】
回復するデータを含むバックアップデータをボリューム１０８に書き込むと、ホスト１０１は、ログファイルを解析してデータの回復を行う範囲を求める。続いて、ホスト１０１は、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔ、ここで求めた回復範囲の開始アドレス、及び、終了アドレスの値を有するデータ復旧要求を作成し、ディスクサブシステム１０９に発行する（ステップ１３０３）。
【００９５】
データ復旧要求を発行した後、ホスト１０１は、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペア分割”でなければ、ペア状態が“ペア分割”になるまで待ち、ペア状態が“ペア分割”であることを確認して次の処理に進む（ステップ１３０４）。
【００９６】
ここまでの処理でデータの回復は完了する。ホスト１０１は、データの回復が完了した後、パラメータとして正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア解除要求をディスクサブシステム１０９に発行する（ステップ１３０５）。
【００９７】
ペア解除要求を発行した後、ホスト１０１は、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア状態参照要求をディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペアなし”でなければ、ペア状態が“ペアなし”となるまで待つ。ペア状態が“ペアなし”となり、ペアの解除が完了するとホスト１０１は処理を終える（ステップ１３０６）。
【００９８】
ステップ１３００において、ホスト１０１からコピーなしペア形成要求を受けたときのディスクサブシステム１０９による処理は次の通りである。
【００９９】
ホスト１０１からのコピーなしペア形成要求に応答して、ディスクサブシステム１０９は、使用中フラグ２００が“未使用”であるペア情報１１０を選択し、その使用中フラグ２００を“使用中”にする。続いて、ディスクサブシステム１０９は、使用中フラグ３０１が“未使用”である差分情報１１１を選択し、その使用中フラグ３０１を“使用中”にする。
【０１００】
次に、ディスクサブシステム１０９は、選択されたペア情報１１０の正ボリューム番号２０１に“Ｓ”、副ボリューム番号２０２に“Ｔ”、差分情報番号２０３に、選択した差分情報１１１の識別子、ペア状態２０４に“ペア分割”をそれぞれ設定する。次に、ディスクサブシステム１０９は、選択した差分情報１１１のコピー対象ビットマップ３０２のすべてのビットを０に、差分ビットマップ３０３のすべてのビットを１にする。
【０１０１】
図１３は、本発明のさらに別の実施形態における情報処理システムのシステム構成を示すブロック図である。本実施形態の情報処理システムは、基本的には図１に示した第１の実施形態における情報処理システムと同様に構成されるが、制御プロセッサ１５０５、制御メモリ１５０６、ボリュームアクセス部１０７などの機能がこれまで説明した実施形態とは異なる。以下、特に、第１の実施形態との相違する点を主体として説明を行う。
【０１０２】
制御メモリ１５０６には、制御プロセッサ１５０５が制御に必要とする制御情報である位置情報１５１０が格納される。物理ボリューム１５０８はデータを格納する機能を有し、ボリュームアクセス部１５０７は、物理ボリューム１５０８にアクセスする機能を有する。
【０１０３】
本実施形態では、ホスト１０１は、ディスクサブシステム１５０９により仮想的に定義される論理ボリュームに対してリードやライトなどの要求を発行する。ディスクサブシステム１５０９には、複数の論理ボリュームを定義でき、各論理ボリュームは、個別の識別子を有する。論理ボリュームは、以下のように定義されている。
【０１０４】
(1) 論理ボリュームは、複数の仮想的な論理トラックから構成されている。論理トラックには、各々を識別するための識別子がつけられている。識別子は、０、１、２、…という値を持つ。
【０１０５】
(2) 論理ボリュームは、１以上の仮想的な論理領域から構成されている。論理領域は、１以上の連続する論理トラックから構成されていて、おのおのの論理領域の論理トラック数は等しい。各論理領域には、おのおのを識別するための識別子がついている。識別子は、０、１、２、…という値を持つ。
【０１０６】
論理ボリューム上のデータは、実際には物理ボリューム１０８に格納される。物理ボリューム１０８は以下のような特徴をもつ。
【０１０７】
(1) 物理ボリューム１０８は、データを格納する実体（例えば磁気ディスク）から構成される。
【０１０８】
(2) 物理ボリューム１０８は、複数の物理トラックから構成される。各物理トラックには、おのおのを識別するための識別子がついている。識別子は、０、１、２、…という値を持つ。
【０１０９】
(3) 物理ボリューム１５０８は、１以上の物理領域から構成される。物理領域は、１以上の連続する物理トラックから構成されている。おのおのの物理領域の物理トラック数は等しく、論理領域を構成する論理トラック数と等しい。物理トラックには、おのおのを識別するための識別子がついている。識別子は、０、１、２、…という値を持つ。
【０１１０】
制御メモリ１５０６には、論理ボリュームと物理ボリュームの対応関係を示すマッピング情報である位置情報が格納される。図１４に位置情報のデータ構造を示す。図に示すように、位置情報１５１０は、論理ボリューム番号１８００、デバイスビジー要求１８０１、リード／ライト実行中フラグ１８０２およびマッピング情報１８０３から構成される。
【０１１１】
論理ボリューム番号１８００は、当該位置情報により管理される論理ボリュームの識別子を示す。デバイスビジー要求１８０１は、論理ボリューム番号１８００により識別される論理ボリュームに対するホスト１０１からのアクセスに対して、デバイスビジーを報告することを示す情報である。デバイスビジー要求１８０１は、“オン”あるいは“オフ”の値を取る。リード／ライト実行中フラグ１８０２は、論理ボリューム番号１８００により識別される論理ボリュームに対するホスト１０１からのリード・ライト要求を実行中であることを示すフラグである。リード／ライト実行中フラグ１８０２は、“オン”あるいは“オフ”の値を取る。マッピング情報１８０３は、論理領域番号１８０４、物理ボリューム番号１８０５および物理領域番号１８０６から構成される。論理領域番号１８０４は、論理ボリューム内の論理領域に割り当てられた識別子を示す。物理ボリューム番号１８０５は、物理ボリューム１０８の識別子を示す。物理領域番号１８０６は、物理ボリューム１０８内の物理領域の識別子である。
【０１１２】
図１５は、データ回復時にホスト１０１側で行われる処理のフローチャートである。
【０１１３】
以下、識別子がＳの論理ボリューム１６００に対して、磁気テープに格納されているバックアップデータをリストアする処理ついて説明する。
【０１１４】
データ回復時にホスト１０１は、まず、未使用の論理ボリュームを１つ選択する。以下、この論理ボリュームの識別子を“Ｔ”とする。ホスト１０１は、磁気テープに格納されているバックアップデータを、識別子“Ｔ”で識別される論理ボリュームにリストアする（ステップ１９０１）。
【０１１５】
リストアが完了すると、ホスト１０１は、パラメータに正ボリューム番号“Ｓ”、副ボリューム番号“Ｔ”を有するスワップ要求を作成し、ディスクサブシステム１５０９に発行する（ステップ１９０２）。
【０１１６】
図１６は、ディスクサブシステム１５０９における処理のフローチャートである。
【０１１７】
ディスクサブシステム１５０９は、ホスト１５０１から要求を受領すると（ステップ２０００）、それがスワップ要求であるかリード／ライト要求か判別する（ステップ２００１）。
【０１１８】
受領した要求がスワップ要求である場合、ディスクサブシステム１５０９は、パラメータで指定された正ボリューム番号と同じ値を論理ボリューム番号１８００に持つ位置情報１５１０を選択する。以下、この位置情報１５１０を位置情報（Ｓ）と表記する。ディスクサブシステム１５０９は、位置情報（Ｓ）のデバイスビジー要求１８０１に“オン”を設定する。次に、ディスクサブシステム１５０９は、パラメータで指定された副ボリューム番号と同じ値を論理ボリューム番号１８００に持つ位置情報１５１０を選択する。以下、この位置情報１５１０を位置情報（Ｔ）と表記する。ディスクサブシステム１５０９は、位置情報（Ｔ）のデバイスビジー要求１８０１に“オン”を設定する（ステップ２００７）。
【０１１９】
デバイスビジー要求１８０１を“オン”に設定した後、ディスクサブシステム１５０９は、位置情報（Ｓ）のリード／ライト実行中フラグ１８０２および位置情報（Ｔ）のリード／ライト実行中フラグ１８０２が“オフ”になっているかどうかを判定する（ステップ２００８）。
【０１２０】
リード／ライト実行中フラグ１８０２が“オフ”でなれければ、“オフ”になるまで待つ。リード／ライト実行中フラグ１８０２が“オフ”になると、マッピング情報１８０３が更新される。すなわち、位置情報（Ｓ）のマッピング情報１８０３の値と位置情報（Ｔ）のマッピング情報１８０３の値が入れ替えられる（ステップ２００９）。
【０１２１】
マッピング情報１８０３の入れ替えが終了したら、ディスクサブシステム１５０９は、位置情報（Ｓ）のデバイスビジー要求１８０１および位置情報（Ｔ）のデバイスビジー要求１８０１２に“オフ”を設定し、処理を終了する（ステップ２０１１）。
【０１２２】
ステップ２００１でホスト１０１から受領した要求がリード／ライト要求であると判別された場合、ディスクサブシステム１５０９は、リード／ライトの対象となる論理ボリューム１６００の識別子を論理ボリューム番号１８００に持つ位置情報１５１０を選択し、デバイスビジー要求１８０１の値が“オン”になっているかどうか判定する。デバイスビジー要求１８０１が“オン”であれば、ディスクサブシステム１５０９は、ホスト１５０１にデバイスビジーを報告して処理を終了する（ステップ２０１０）。
【０１２３】
デバイスビジー要求１８０１が“オン”になっていない場合、ディスクサブシステム１５０９は、位置情報（Ｓ）のリード／ライト実行中フラグ１８０２および位置情報（Ｔ）のリード／ライト実行中フラグ１８０２に“オン”を設定する（ステップ２００３）。
【０１２４】
リード／ライト実行中フラグ１８０２の更新が完了したら、まず、リード／ライト対象の論理トラックに対応する物理トラックを求める。物理トラックは、位置情報（Ｓ）のマッピング１８０３の値から次のようにして求められる。
【０１２５】
(1) リード／ライト対象の論理トラックの識別子の値を、論理領域を構成する論理トラック数で割った時の商をＡ、余りをＢとする。
【０１２６】
(2) マッピング情報１８０３の論理領域番号１８０４がＡである行の物理ボリューム番号１８０５にある値Ｃを求める。
【０１２７】
(3) マッピング情報１８０３の論理領域番号１８０４がＡである行の物理領域番号１８０６にある値Ｄを求める。
【０１２８】
(4) 値Ｄと物理領域を構成する物理トラック数の積をＥとする。
【０１２９】
(5) ＥとＢとの和としてＦを得る。
【０１３０】
以上のようにして求めた値から、リード／ライト対象の物理トラックは、識別子がＣである物理ボリューム１０８内の、識別子がＦである物理トラックであることが求まる（ステップ２００４）。
【０１３１】
物理トラックが得られると、ディスクサブシステム１５０９は、ボリュームアクセス部１５０７により、ホスト１０１との間でデータ転送を実行する（ステップ２００５）。
【０１３２】
データ転送の終了に応答して、ディスクサブシステム１５０９は、位置情報（Ｓ）のリード／ライト実行中フラグ１８０２および位置情報（Ｔ）のリード／ライト実行中フラグ１８０２に“オフ”を設定して処理を終了する（ステップ２００６）。
【０１３３】
以上の説明では、論理ボリューム内のデータがすべて交換されるが、第１の論理ボリューム内のある論理領域と、第２の論理ボリューム内のある論理領域のデータとを交換することもできる。以下、識別子がＳである論理ボリュームの論理領域Ｓ１のデータと、識別子がＴである論理ボリュームの論理領域Ｔ１のデータとを交換する場合について説明する。
【０１３４】
この場合、ホスト１０１は、Ｓ、Ｓ１、Ｔ、Ｔ１をパラメータとして有するデータ交換要求をディスクサブシステム１５０９に対して発行する。
【０１３５】
データ交換要求を受領したディスクサブシステム１５０９は、スワップ要求を受領したときの処理と同様に、デバイスビジー要求１８０１に“オン”を設定し、リード／ライト実行中フラグ１８０２が“オフ”なるのを待つ。リード／ライト実行中フラグ１８０２が“オフ”になったら、論理ボリューム番号１８００がＳである位置情報１５１０に含まれるマッピング情報１８０３の論理領域番号１８０４がＳ１であるエントリに対応する物理ボリューム番号１８０５と物理領域番号１８０６の値と、論理ボリューム番号１８００がＴである位置情報１５１０のマッピング１８０３の論理領域番号１８０４がＴ１であるエントリに対応する物理ボリューム番号１８０５と物理領域番号１８０６の値とを入れ替える。入れ替えが終了したら、デバイスビジー要求１８０１に“オフ”を設定して、処理を終了する。
【０１３６】
【発明の効果】
本発明によれば、ホストで実行中の処理に障害が発生し、ディスクサブシステムのデータを復旧する場合に、ホストに負担をかけず、短時間でデータをリストアすることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態における情報処理システムのシステム構成を示すブロック図である。
【図２】ペア情報１１０の一例を示すデータ構造図である。
【図３】差分情報１１１の一例を示すデータ構造図である。
【図４】バッチ処理を実行する時のホスト１０１による処理の流れを示すフローチャートである。
【図５】ホスト１０１からの要求に応答してディスクサブシステム１０９により行われる処理の処理フローを示すフローチャートである。
【図６】ステップ５０７において実施される形成コピー処理のフローチャートである。
【図７】ステップ５１２で実施されるデータ復旧処理のフローチャートである。
【図８】ステップ５１６におけるリード処理のフローチャートである。
【図９】ステップ５１７で行われるライト処理のフローチャートである。
【図１０】データを復旧中の領域に対するリード要求に対してデータ転送を行うために、ステップ８０３に替えて行われる処理のフローチャートである。
【図１１】データを復旧中の領域に対するライト要求を処理するために、ステップ９０３に替えて行われる処理のフローチャートである。
【図１２】データ回復処理時のホスト１０１側の処理を示すフローチャートである。
【図１３】本発明の別の実施形態における情報処理システムのシステム構成を示すブロック図である。
【図１４】位置情報のデータ構造を示すデータ構成図。
【図１５】データ回復時にホスト１０１側で行われる処理のフローチャートである。
【図１６】ディスクサブシステム１５０９における処理のフローチャートである。
【符号の説明】
１００・・・遠隔端末
１０１・・・ホスト
１０２・・・ＬＡＮ
１０３・・・バス
１０４・・・遠隔端末インタフェース
１０５・・・ホストインタフェース
１０６・・・制御メモリ
１０７・・・ボリュームアクセス部
１０８・・・ボリューム
１０９・・・ディスクサブシステム
１１０・・・ペア情報
１１１・・・差分情報
【発明の属する技術分野】
本発明は、オンライン処理やバッチ処理を実行する情報処理システムに関し、特に、オンライン処理やバッチ処理の障害などによって破壊されたディスク装置などの記憶装置に格納されたデータを復旧するための方法に関する。
【０００２】
【従来の技術】
銀行や証券会社などの情報処理システムで行われるオンライン処理やバッチ処理では、プログラムのバグや記憶装置の障害などによってそれらの処理が異常終了し、データを矛盾した状態にしてしまうことがある。また、情報処理システムに携わる人間の人為的ミスによって大切なデータを破壊したり、消去してしまうことがある。
【０００３】
このような状態になった情報処理システムを回復させ、データの矛盾を解消して途中で止まった処理を再開させたり、あるいは、途中で止まった処理をもう一度やり直したりするための手段がいくつか知られている。そのうちのひとつの手段にバックアップとリストアによる回復処理がある。
【０００４】
バックアップとリストアによる回復処理では、例えば、データベースシステムの場合、磁気テープなどの記憶媒体に定期的にデータのバックアップが取得される。システムに障害が発生した場合は、磁気テープに取得されたバックアップから記憶装置にデータをリストアし、ログファイルを使用して適切なポイントまで記憶装置のデータを再構築する。このような処理により、データベースのデータを適切な状態に回復し、データベース処理を再開させることができる。
【０００５】
バッチ処理の場合には、処理の開始に先立って磁気テープにデータのバックアップが取得される。バッチ処理の開始後、処理が異常終了した場合、磁気テープからデータがリストアされ、記憶装置のデータがバッチ処理を開始する前の状態に戻される。その後、バッチ処理が最初から再実行される。
【０００６】
【発明が解決しようとする課題】
従来のバックアップとリストアによる回復処理では、磁気テープからデータをリストアする際、バックアップを取得した時点から更新されていない部分（記憶装置と磁気テープの内容が一致している部分）のデータも磁気テープから読み出され、記憶装置に書き込まれる。このようなデータの転送は、無駄なデータ転送であり、リストアに要する時間を長びかせる。
【０００７】
また、例えば、記憶装置内の領域Ａ、領域Ｂおよび領域Ｃがバックアップ／リストアの単位であり、回復を必要とするのが領域Ａだけである場合でも、領域Ａ〜Ｃについてリストアが実行され、リストア時間が長くなる。リストア中は、領域Ａ〜Ｃ上のデータを利用する処理を停止する必要があり、その影響は大きい。
【０００８】
本発明の目的は、これら従来技術における問題点を解決し、バックアップからのデータのリストアを高速化し、システム障害からの回復に要する時間を短縮させることのできるデータの復旧方法を提供することにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明によれば、中央処理装置と、ディスク装置を備え、前記中央処理装置からの要求にしたがってデータ転送を実行するディスクサブシステムとを有する情報処理システムにおいて、一連の処理によってディスク装置内のデータを更新する前に、情報処理装置からディスクサブシステムに対して、前記一連の処理で使用されるディスク装置に格納されているデータの写しを保存する保存要求を発行する。ディスクサブシステムは、保存要求に応答して、ディスク装置のデータの写しを保存する。中央処理装置により実行される一連の処理によりディスク装置の内容が更新されたとき、ディスクサブシステムは、更新された場所を差分情報として記憶する。ディスク装置の内容をある時点の状態に復旧する必要が生じた場合、ディスクサブシステムは、中央処理装置からデータの復旧要求に応答して、記憶された前記差分情報に基づいて、保存されたデータを前記ディスク装置にリストアする。
【００１０】
本発明の他の観点によれば、中央処理装置と、ディスク装置を備え、中央処理装置からの要求にしたがってデータ転送を実行するディスクサブシステムとを有する情報処理システムにおいて、ディスクサブシステムは、中央処理装置からのリストア要求に応答して、中央処理装置がアクセスする論理ボリュームのデータを格納した第１のディスク装置に保持されているデータのバックアップデータを第２のディスク装置にリストアする。そして、中央処理装置からのスワップ要求に応答して、論理ボリュームを第２のディスク装置と関連付ける。その後、中央処理装置からの論理ボリュームへのアクセス要求に応答して、ディスクサブシステムは、第２のディスク装置のデータにアクセスする。
【００１１】
【発明の実施の形態】
図１は、本発明の第１の実施形態における情報処理システムのシステム構成を示すブロック図である。本実施形態の情報処理システムは、ホストコンピュータ（ホスト）１０１とディスクサブシステム１０９を含んで構成される。ディスクサブシステム１０９は、スモール・コンピュータ・システム・インタフェース（ＳＣＳＩ）やファイバ・チャネル（Fibre Channel）などのインタフェースバス１０３を介してホスト１０１と接続される。ホスト１０１とディスクサブシステム１０９との間は、ＳＣＳＩプロトコルやＦｉｂｒｅプロトコルなどによって、情報の授受が行われる。
【００１２】
ディスクサブシステム１０９は、ホストインタフェース１１２、制御プロセッサ１０５、制御メモリ１０６、ボリュームアクセス部１０７およびボリューム１０８を有する。ホストインタフェース１０５は、ホスト１０１とのインタフェースである。制御プロセッサ１０５は、ホストインタフェース１１２により受信されたホスト１０１からの要求にしたがって、ディスクサブシステム１０９を制御する。制御メモリ１０６は、制御プロセッサ１０５がディスクサブシステム１０９を制御するために必要な制御情報を格納するメモリである。本発明に関係する情報として、ペア情報１１０および差分情報１１１が制御メモリ１０６に保持される。ボリュームアクセス部１０７は、ボリューム１０８に対してデータのリード／ライトを行う機能を有する。ボリューム１０８は、データを格納する磁気ディスク媒体を備えたディスクユニットなどから構成され、おのおのを識別するための識別子が割り当てられている。
【００１３】
制御メモリ１０６は、１、又は複数のペア情報１１０を保有する。図２は、ペア情報１１０の一例を示すデータ構造図である。
【００１４】
ペア情報１１０は、使用中フラグ２００、正ボリューム番号２０１、副ボリューム番号２０２、差分情報番号２０３、ペア状態２０４、エクステント情報２０５を有して構成される。
【００１５】
使用中フラグ２００は、当該ペア情報１１０が使用されているかどうかを示すフラグで、“使用中”または“未使用”の値をとる。使用中フラグ２００が“使用中”のとき、当該ペア情報１１０は、使用中であることが示される。使用中フラグ２００が“未使用”のとき、当該ペア情報１１０は、未使用であることが示される。
【００１６】
正ボリューム番号２０１、副ボリューム番号２０２は、ボリューム１０８を識別する識別子である。以下では、正ボリューム番号２０１により識別されるボリュームを正ボリューム、副ボリューム番号２０２により特定されるボリュームを副ボリュームと呼ぶ。差分情報番号２０３は、差分情報１１１を識別する識別子である。正ボリュームと副ボリュームの組をここではペアと呼ぶ。ペアには、“ペア形成中”、“ペア形成完了”、“ペア分割”、“データ復旧中”および“ペアなし”という状態がある。ペア状態２０４は、ペアについてのこれらの状態を示す。
【００１７】
エクステント情報２０５は、開始アドレス２０７、終了アドレス２０８から構成される。開始アドレス２０７は、ボリューム１０８内の連続する領域の始端のアドレスを示す。終了アドレス２０８は、ボリューム１０８内の連続する領域の終端のアドレスを示す。例えば、ボリューム１０８が固定長ブロックから構成される固定長ブロック形式のボリュームである場合、開始アドレス２０７および終了アドレス２０８にはブロック番号が格納される。また、ボリューム１０８が可変長レコード形式のボリュームである場合、開始アドレス２０７および終了アドレス２０８にはトラック番号が格納される。以下では、説明を分かりやすくする為に、データを格納する領域として、トラックという言葉を使用する。したがって、トラックという言葉に、可変長レコード形式ボリュームのトラックを当てはめても良いし、固定長ブロック形式ボリュームのブロックを当てはめても良い。また、ボリューム１０８内の先頭からｉ番目のトラックをトラック（ｉ）と表記する。
【００１８】
制御メモリ１０６は、１又は複数の差分情報１１１を保有する。差分情報１１１のデータ構造の一例を図３に示す。
【００１９】
差分情報１１１は、使用中フラグ３０１、コピー対象ビットマップ３０２および差分ビットマップ３０３を保有する。使用中フラグ３０１は、当該差分情報１１１が使用中かどうかを示すフラグで、“使用中”または“未使用”の値をとる。使用中フラグ３０１が“使用中”であるとき、当該差分情報１１１は、使用中であることが示される。使用中フラグ３０１が“未使用”のとき、当該差分情報１１１は、未使用状態であることが示される。
【００２０】
コピー対象ビットマップ３０２は、副ボリュームから正ボリュームへコピーするデータを示す情報で、複数のビットから構成される。１ビットは、ボリューム８上の１つのトラックに対応する。ビットが０のとき、そのビットに対応するトラック（またはブロック）はコピー対象ではないことが示され、ビットが１のとき、そのビットに対応するトラック（またはブロック）がコピー対象であることが示される。以下、コピー対象ビットマップ３０２のｉ番目のビットをコピー対象（ｉ）と表記する。すなわち、トラック（ｉ）に対応するビットは、コピー対象（ｉ）である。
【００２１】
差分ビットマップ３０３は、正ボリュームと副ボリュームの対応するトラック間でデータの内容が異なっているトラックを示す情報で、複数のビットから構成される。コピー対象ビットマップ３０２と同様に、１つのビットは、１つのトラックに対応する。ビットが０のとき、そのビットに対応するトラックのデータは、正ボリュームと副ボリュームとの間で異なっていないことが示される。一方、ビットが１のとき、そのビットに対応するトラックのデータは、正ボリュームと副ボリュームとの間で異なっていることが示される。以下、差分ビットマップ３０３のｉ番目のビットを差分（ｉ）と表記する。すなわち、トラック（ｉ）に対応するビットは、差分（ｉ）である。
【００２２】
図４は、バッチ処理を実行する時のホスト１０１による処理の流れを示すフローチャートである。
【００２３】
ホスト１０１は、実行しようとするバッチ処理で使用されるデータを格納したボリューム１０８の識別子（以下、このボリューム１０８の識別子をＳと表記する）を正ボリューム番号、未使用のボリューム１０８の識別子（以下、このボリューム１０８の識別子をＴと表記する）を副ボリューム番号として、これらをパラメータとして含むペア形成要求を作成し、ディスクサブシステム１０９に発行する（ステップ４００）。
【００２４】
ペア形成要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。ペア状態参照要求に対する応答として、ディスクサブシステム１０９から報告されるペア状態が“ペア形成完了”の場合、ステップ４０２に進む。ディスクサブシステム１０９から報告されるペア状態が“ペア形成完了”以外の場合、報告されるペア状態が“ペア形成完了”となるまで待つ（ステップ４０１）。
【００２５】
ペア状態が“ペア形成完了”になると、ホスト１０１は、例えば、オンライン処理の区切りなどバッチ処理を開始する契機まで待つ（ステップ４０２）。
【００２６】
バッチ処理を開始する契機になると、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア分割要求を作成し、ディスクサブシステム１０９に発行する（ステップ４０３）。
【００２７】
ペア分割要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。ペア状態参照要求に対する応答として、ディスクサブシステム１０９から報告されるペア状態が“ペア分割”の場合、ステップ４０５に進む。ディスクサブシステム１０９から報告されるペア状態が“ペア分割”以外の場合、ホスト１０１は、ペア状態が“ペア分割”になるまで待つ（ステップ４０４）。
【００２８】
ペア状態が“ペア分割”になると、ホスト１０１は、バッチ処理を開始する（ステップ４０５）。
【００２９】
バッチ処理が途中で異常終了すると、バッチ処理のリトライのために、バッチ処理を実行する前のデータが必要とされる。この場合、ステップ４０７に進む。バッチ処理が正常終了した場合は、ステップ４１０に進む。（ステップ４０６）バッチ処理が異常終了し、バッチ処理を実行する前のデータが必要になった場合、ホスト１０１は、データの回復を行うボリューム１０８内の領域を求める。この領域は、ログファイルを解析して、異常終了したバッチ処理の実行中に更新のあった部分を特定することにより行われる。または、ユーザからの指定を受け付けても良い。以降、求められた領域の始端のアドレスをＢ、終端のアドレスをＥと表記する。
【００３０】
続いて、ホスト１０１は、正ボリューム番号の値としてＳ、副ボリューム番号の値としてＴ、開始アドレスの値がＢ、終了アドレスの値がＥをパラメータとして有するデータ復旧要求を作成し、ディスクサブシステム１０９に発行する（ステップ４０７）。
【００３１】
データ復旧要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとするペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答として、ディスクサブシステム１０９から報告されるペア状態が“ペア分割”の場合、ステップ４０９に進む。ディスクサブシステム１０９から報告されるペア状態が“ペア分割”以外の場合、ホスト１０１は、報告されるペア状態が“ペア分割”になるまで待つ（ステップ４０８）。
【００３２】
ペア状態が“データ分割”になると、データの回復が完了しているので、ホスト１０１は、バッチ処理を再実行する（ステップ４０９）。
【００３３】
バッチ処理が正常終了すると、ホスト１０１は、正ボリューム番号の値Ｓ、副ボリューム番号の値Ｔをパラメータとして有するペア解除要求を作成し、ディスクサブシステム１０９に発行する（ステップ４１０）。
【００３４】
ペア解除要求を発行した後、ホスト１０１は、正ボリューム番号Ｓ、副ボリューム番号Ｔをパラメータとして有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペアなし”の場合、処理を終了する。ディスクサブシステム１０９から報告されるペア状態が“ペアなし”以外の場合、ペア状態が“ペアなし”になるまで待つ（ステップ４１１）。
【００３５】
以上説明したホスト１０１の処理では、バッチ実行前の状態にデータを回復してから、バッチ処理を再実行させたが、ステップ４０９において、ログファイルを使って、適切なところまでデータの更新を行ってからバッチ処理を実行しても良い。
【００３６】
図５は、ホスト１０１からの要求に応答してディスクサブシステム１０９により行われる処理の処理フローを示すフローチャートである。
【００３７】
ディスクサブシステム１０９は、ホスト１０１から要求を受領するとステップ５００〜５０５において、その要求がペア形成要求、ペア分割要求、ペア削除要求、データ復旧要求、及びペア状態参照要求のいずれかに該当するか判別する。
【００３８】
ホスト１０１からの要求がペア形成要求である場合、ディスクサブシステム１０９は、ペア情報及び差分情報を作成する。具体的に、ディスクサブシステム１０９は、使用中フラグ２００が“未使用”であるペア情報１１０を選択し、選択したペア情報１１０の使用中フラグ２００に“使用中”を設定する。次に、使用中フラグ３０１が“未使用”である差分情報１１１を選択し、選択した差分情報１１１の使用中フラグ３０１に“使用中”を設定する。その後、ディスクサブシステム１０９は、選択したペア情報１１０の正ボリューム番号２０１に、ペア形成要求のパラメータとして設定されている正ボリューム番号Ｓを、副ボリューム番号２０２に、副ボリューム番号Ｔを設定する。また、選択したペア情報１１０の差分情報番号２０３に、選択した差分情報１１１の識別子を設定する。そして、選択したペア情報１１０のペア状態２０４に“ペア形成中”を設定する。次に、ディスクサブシステム１０９は、選択した差分情報１１１のコピー対象ビットマップ３０２、及び差分ビットマップ３０３のすべてのビットを０にする。（ステップ５０６）
ペア情報１１０および差分情報１１１に値を設定したら、ディスクサブシステム１０９は、後述する形成コピー処理を実行する（ステップ５０７）。
【００３９】
形成コピーが完了すると、ディスクサブシステム１０９は、ステップ５０６で選択したペア情報１１０のペア状態２０４に“ペア形成完了”を設定し、処理を終了する（ステップ５０８）。
【００４０】
ホスト１０１から受領した要求がペア分割要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、及び副ボリューム番号２０２に、ペア分割要求のパラメータとして与えられる正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。そして、選択したペア情報１１０のペア状態２０４に“ペア分割”を設定して処理を終了する（ステップ５０９）。
【００４１】
ホスト１０１から受領した要求がペア削除要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、副ボリューム番号２０２に、ペア削除要求のパラメータとして設定されている正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。そして、選択したペア情報１１０の差分情報番号２０３によりポイントされる差分情報１１１の使用中フラグ３０１に“未使用”を設定する。また、選択したペア情報１１０の使用中フラグ２００にも“未使用”を設定する。ディスクサブシステム１０９は、使用中フラグ２００および使用中フラグ３０１の更新が完了すると処理を終了する（ステップ５１０）。
【００４２】
次に、ホスト１０１から受領した要求がデータ復旧要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、副ボリューム番号２０２にデータ復旧要求のパラメータとして設定されている正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。次に、ディスクサブシステム１０９は、選択したペア情報１１０のペア状態２０４に“データ復旧中”を設定する。また、エクステント情報２０５の開始アドレス２０７、及び終了アドレス２０８には、データ復旧要求にパラメータとして設定されている開始アドレスＢ、終了アドレスＥを設定する。さらに、ディスクサブシステム１０９は、選択したペア情報２０３の差分情報番号２０３によりポイントされる差分情報１１１のコピー対象ビットマップ３０２を設定する。すなわち、差分（Ｂ）から差分（Ｅ）までのビットに関して、差分（ｉ）が０のときコピー対象（ｉ）に０を設定し、差分（ｉ）が１のときコピー対象（ｉ）に１を設定する（ステップ５１１）。
【００４３】
ペア情報１１０および差分情報１１１を更新した後、ディスクサブシステム１０９は、後述するデータ復旧処理を実行する（ステップ５１２）。
【００４４】
データ復旧処理が完了すると、ディスクサブシステム１０９は、ステップ５１１で選択したペア情報１１０のペア状態２０４に“ペア分割”を設定して処理を終了する（ステップ５１３）。
【００４５】
ホスト１０１から受領した要求がペア状態参照要求である場合、ディスクサブシステム１０９は、使用中フラグ２００が“使用中”であり、正ボリューム番号２０１、副ボリューム番号２０２にペア状態参照要求のパラメータとして与えられた正ボリューム番号Ｓ、副ボリューム番号Ｔが設定されているペア情報１１０を選択する。次に、ディスクサブシステム１０９は、選択したペア情報１１０のペア状態２０４をホスト１０１に報告して処理を終了する。ここで、該当するペア情報１１０がない場合は、ペア状態として“ペアなし”を報告する（ステップ５１４）。
【００４６】
ホスト１０１からの要求が上述したいずれの要求でもない場合、ステップ５１５において、ホスト１０１からの要求がリード要求であるかライト要求であるかが判定される。この判定の結果、要求がリード要求の場合は、後述するリード処理が行われ（ステップ５１６）、ライト要求の場合には、後述するライト処理が行われる（ステップ５１７）。
【００４７】
図６は、ステップ５０７において実施される形成コピー処理のフローチャートである。
【００４８】
まず、初期設定として、ディスクサブシステム１０９は、変数ｉに０を設定する（ステップ６００）。
【００４９】
次に、ボリュームアクセス部１０７により、ステップ５０６で選択したペア情報１１０の正ボリューム番号２０１に設定された識別子で指定されるボリューム１０８のトラック（ｉ）のデータを読み出す。そして、ボリュームアクセス部１０７により、読み出したデータを副ボリューム番号２０２に設定された識別子で指定されるボリュームのトラック（ｉ）に書き込む（ステップ６０１）。
【００５０】
変数ｉの値が、正ボリュームの最終トラックのトラック番号を超えたか判定する（ステップ６０２）。変数ｉが最終トラックのトラック番号を超えていると、ディスクサブシステム１０９は、形成コピーの処理を終了してステップ５０８に進む。そうでなければ、ステップ６０３の処理に進み、変数ｉに１を加算してステップ６０１に戻り、次のトラックのコピー処理を実行する（ステップ６０３）。
【００５１】
図７は、ステップ５１２で実施されるデータ復旧処理のフローチャートである。
【００５２】
ディスクサブシステム１０９は、まず、変数ｉに初期値としてＢを設定する（ステップ７００）。
【００５３】
次に、ステップ５１１で設定したコピー対象ビットマップ３０２を参照して、コピー対象（ｉ）が０か１かを判定する（ステップ７０１）。コピー対象（ｉ）が０の場合は、ステップ７０４に、１の場合は、ステップ７０３に進む。
【００５４】
ステップ７０３では、ボリュームアクセス部１０７により、副ボリュームのトラック（ｉ）のデータを読み出し、読み出したデータを正ボリュームのトラック（ｉ）に書き込む。そして、コピー対象（ｉ）を０にする。
【００５５】
ステップ７０４で、ディスクサブシステム１０９は、Ｅと変数ｉとを比較し、ｉがＥに等しいか大きい場合にはデータ回復処理を終了し、そうでなければ、ステップ７０５に進む。ステップ７０５では、変数ｉに１を加算してステップ７０１に戻り、次のトラックについて同様の処理が行われる。
【００５６】
図８は、ステップ５１６におけるリード処理のフローチャートである。
【００５７】
ホスト１０１により発行されるリード要求には、パラメータとして、データを読み出すべきボリューム１０８の識別子とトラック番号を含んでいる。以降、パラメータで指定されるボリューム１０８の識別子を“ＲＶＯＬ”、トラック番号を“ＲＴＲＫ”とする。
【００５８】
リード処理では、まず、使用中フラグ２００が“使用中”、正ボリューム番号２０１に“ＲＶＯＬ”が設定されているペア情報１１０が選択される。該当するペア情報１１０がある場合、処理は、ステップ８０１に進む。該当するペア情報１１０がない場合、処理は、ステップ８０４に進む。（ステップ８００）
ステップ８０１でディスクサブシステム１０９は、ステップ８００で選択したペア情報１１０のペア状態２０４を参照し、“データ復旧中”になっているか判定する。ペア状態２０４が“データ復旧中”である場合は、ステップ８０２に進み、そうでなければステップ８０６に進む。
【００５９】
ステップ８０２でディスクサブシステム１０９は、エクステント情報２０５の開始アドレス２０７と終了アドレス２０８によって特定される領域に、トラック“ＲＴＲＫ”が含まれるかどうかを判定する。開始アドレス２０７と終了アドレス２０８によって特定される領域にトラック“ＲＴＲＫ”が含まれていれば、当該領域に対するアクセスを拒否することをホスト１０１に報告してリード処理を終了する（ステップ８０３）。開始アドレス２０７と終了アドレス２０８によって特定される領域にトラック“ＲＴＲＫ”が含まれていない場合は、ボリュームアクセス部１０７により、識別子“ＲＶＯＬ”で識別されるボリューム１０８のトラック“ＲＴＲＫ”のデータが読み出され、ホスト１０１に転送されてリード処理が終了する（ステップ８０６）。
【００６０】
リード対象のボリュームが正ボリュームでない場合、使用中フラグ２００が“使用中”となっているペア情報１１０から、副ボリューム番号２０１が“ＲＶＯＬ”であるペア情報が選択される。該当するペア情報１１０がなければ、ステップ８０６の処理に移り、データの転送が行われ処理が終了する。該当するペア情報１１０があれば、ステップ８０５に進む（ステップ８０４）。
【００６１】
ステップ８０５では、ステップ８０４で選択されたペア情報１１０のペア状態２０４が参照され、“ペア分割”であるか判定される。ペア状態２０４が“ペア分割”であればステップ８０６に進み、データの転送が行われる。ペア状態２０４が“ペア分割”でなければステップ８０３に進み、アクセスが拒否される。
【００６２】
図９は、ステップ５１７で行われるライト処理のフローチャートである。
【００６３】
ホスト１０１により発行されるライト要求は、パラメータに、ボリューム１０８の識別子、トラック番号、およびライトデータを含む。以降、パラメータで指定されるボリューム１０８の識別子を“ＷＶＯＬ”、トラック番号を“ＷＴＲＫ”とする。
【００６４】
ライト処理において、ディスクサブシステム１０９は、まず、使用中フラグ２００が“使用中”、正ボリューム番号２０１の値が“ＷＶＯＬ”であるペア情報１１０を選択する。該当するペア情報１１０があればステップ９０１に進み、該当するペア情報１１０がなければステップ９０４に進む（ステップ９００）。
【００６５】
ステップ９０１では、ステップ９００で選択されたペア情報１１０のペア状態２０４が“データ復旧中”かどうか判定される。ペア状態２０４が“データ復旧中”であればステップ９０２に進み、“データ復旧中”でなければステップ９０８に進む。
【００６６】
ステップ９０８では、ステップ９００で選択されたペア情報１１０のペア状態２０４が“分割中”か判定される。ペア状態２０４が“分割中”であればステップ９０６に進み、“分割中”でなければステップ９０９に進む。
【００６７】
ステップ９０９では、ボリュームアクセス部１０７により、ステップ９００で選択されたペア情報１１０の副ボリューム番号２０２により識別されるボリューム１０８内のトラック“ＷＴＲＫ”にライトデータが書き込まれる。その後、処理は、ステップ９０７に進む。
【００６８】
ステップ９０２では、ステップ９００で選択されたペア情報１１０のエクステント情報２０５の開始アドレス２０７と終了アドレス２０８によって特定される領域に、トラック“ＷＴＲＫ”が含まれるかどうか判定される。該当する領域に、トラック“ＷＴＲＫ”が含まれればステップ９０３に進み、含まれなければステップ９０６に進む。
【００６９】
ステップ９０３でディスクサブシステム１０９は、当該領域へのアクセスを拒否することをホスト１０１に報告して処理を終了する。
【００７０】
ステップ９０４では、使用中フラグ２００が“使用中”、副ボリューム番号２０１の値が“ＷＶＯＬ”であるペア情報１１０が選択される。該当するペア情報１１０があればステップ９０５に進み、該当するペア情報１１０がなければステップ９０７に進む。
【００７１】
ステップ９０５では、ステップ９０４で選択されたペア情報１１０のペア状態２０４が“ペア分割”かどうか判定される。ペア状態２０４が“ペア分割”であればステップ９０６に進み、“ペア分割”でなければステップ９０３に進む。
【００７２】
ステップ９０６でディスクサブシステム１０９は、ステップ９０４で選択したペア情報１１０の差分情報番号２０３により示される差分情報１１１の差分（ＷＴＲＫ）に１を設定する。
【００７３】
ステップ９０７では、識別子が“ＷＶＯＬ”であるボリューム１０８のトラック“ＷＴＲＫ”に、受領したライトデータが書き込まれ、ライト処理が終了する。
【００７４】
上述した第１の実施の形態では、ディスクサブシステム１０９は、ホスト１０１から送られる要求に応答して処理を行う。これらの要求のうち、ペア形成要求、ペア分割要求、ペア削除要求、ペア状態参照要求を遠隔端末１００からディスクサブシステム１０９に与えることも可能である。この場合、制御プロセッサ１０５は、遠隔端末インタフェース１０４を介して、遠隔端末１００から要求を受領して、処理を実行する。処理内容は、上述した各処理と同様となる。
【００７５】
また、上述した実施形態では、データを復旧中の領域に対するリード／ライト要求を拒否しているが、リード処理におけるステップ８０３、ライト処理におけるステップ９０３を以下に説明する処理に変更することで、データを復旧中の領域に対するリード／ライト要求に応じてデータ転送を行うようにすることができる。
【００７６】
図１０は、データを復旧中の領域に対するリード要求に対してデータ転送を行うために、ステップ８０３に替えて行われる処理のフローチャートである。
【００７７】
ディスクサブシステム１０９は、データを復旧中の領域に対するリード要求を処理するに当たり、ペア情報１１０を参照して、リード要求の対象ボリュームを含むペアのペア状態２０４が“データ復旧中”か調べる（ステップ１０００）。ペア状態２０４が“データ復旧中”であれば、次に、ディスクサブシステム１０９は、リード要求の対象領域がコピー対象となっているかどうか調べる。これは、ペア情報１１０の差分情報番号２０３が指している差分情報１１１のコピー対象（ＲＴＲＫ）が０か１かを調べることで実現される。コピー対象（ＲＴＲＫ）が０の場合は、ボリュームアクセス部１０７によりボリューム１０８からデータを読み出してホスト１０１に転送し、処理を終了する（ステップ１００５）。
【００７８】
ステップ１００１でコピー対象であると判定された場合、ディスクサブシステム１０９は、ボリュームアクセス部１０７により副ボリュームのトラック“ＲＴＲＫ”からデータを読み出して、それを正ボリュームのトラック“ＲＴＲＫ”に書き込む（ステップ１００２）。
【００７９】
続いて、ディスクサブシステム１０９は、コピー対象（ＲＴＲＫ）に０を設定する（ステップ１００３）。そして、ボリュームアクセス部１０７により、ボリューム１０８からデータを読み出してホスト１０１に転送し、処理を終了する（ステップ１００４）。
【００８０】
ステップ１０００でペア状態２０４が“データ復旧中”でないと判定された場合は、ホスト１０１にアクセスを拒否することが報告されて処理が終了する（ステップ１００６）。
【００８１】
図１１は、データを復旧中の領域に対するライト要求を処理するために、ステップ９０３に替えて行われる処理のフローチャートである。
【００８２】
ディスクサブシステム１０９は、データを復旧中の領域に対するライト要求を処理するに当たり、ライト要求の対象であるボリュームに関するペア情報１１０を参照して、そのペア状態２０４が“データ復旧中”かどうか調べる（ステップ１１００）。
【００８３】
ペア状態２０４が“データ復旧中”であると判定された場合、ライト要求の対象領域がコピー対象となっているかどうか調べられる。これは、ペア情報１１０の差分情報番号２０３が指す差分情報１１１のコピー対象（ＷＴＲＫ）が０であるか１であるかを調べることにより行われる（ステップ１１０１）。
【００８４】
コピー対象（ＷＴＲＫ）が０の場合は、ステップ１１０４に進む。１の場合はステップ１１０２に進む。
【００８５】
ステップ１１０１でコピー対象（ＷＴＲＫ）が１であり、ライト要求の対象領域がコピー対象であると判定しされた場合、ボリュームアクセス部１０７により、副ボリュームのトラック“ＷＴＲＫ”のデータが読み出され、正ボリュームのトラック“ＷＴＲＫ”にそのデータが書き込まれる（ステップ１１０２）。その後、差分情報１１１のコピー対象（ＷＴＲＫ）に０が設定され、ステップ１１０４の処理に移る（ステップ１１０３）。
【００８６】
ステップ１１０４でディスクサブシステム１０９は、差分情報１１１の差分（ＷＴＲＫ）に１を設定する。続いて、ボリュームアクセス部１０７により、識別子“ＷＶＯＬ”で識別されるボリューム１０８のトラック“ＷＴＲＫ”にライトデータが書き込まれる（ステップ１１０５）。
【００８７】
ステップ１１００でペア状態２０４が“データ復旧中”でないと判定された場合、ディスクサブシステム１０９は、ホスト１０１にアクセスを拒否することを報告して処理を終了する（ステップ１１０６）。
【００８８】
以上の処理により、データを復旧中の領域に対するリード／ライト要求に対しても、その要求に応答してデータのリード／ライト処理を実施することが可能となる。
【００８９】
本発明が適用された情報処理システムの他の実施形態について、以下に説明する。以下に説明する実施形態におけるシステムとしての構成は、図１に示したものと同様であるが、制御プロセッサ１０５において実現される機能が上述した実施形態と異なる。本実施形態では、ホスト１０１（あるいは遠隔端末１００）から発行される要求として、上述した実施形態において説明したペア形成要求、ペア分割要求、ペア削除要求、データ復旧要求、ペア状態参照要求、リード要求およびライト要求に加え、コピーなしペア形成要求が含まれる。制御プロセッサ１０５は、これらの要求に応答して各種の処理を行う。
【００９０】
図１２は、データ回復処理時のホスト１０１側の処理を示すフローチャートである。
【００９１】
データ回復処理時、ホスト１０１は、まず、ディスクサブシステム１２０９にコピーなしペア形成要求を発行する。コピーなしペア形成要求には、パラメータとして、正ボリューム番号と副ボリューム番号が含まれる。正ボリューム番号には、回復するデータを格納するボリューム１０８の識別子が、副ボリューム番号には、データを一時的に格納する未使用のボリューム１０８の識別子が設定される。以下では、処理の対象となる正ボリュームのボリューム番号をＳ、副ボリュームのボリューム番号をＴとして説明する（ステップ１３００）。
【００９２】
ホスト１０１は、コピーなしペア形成要求を発行した後、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペア分割”でなければ、ペア状態が“ペア分割”になるまで待ち、ペア状態が“ペア分割”であることを確認して次の処理に進む（ステップ１３０１）。
【００９３】
次に、ホスト１０１は、回復するデータがバックアップされている磁気テープからデータを読み出す。ホスト１０１は、このデータを、ボリューム番号がＴであるボリューム１０８に書き込むよう、ディスクサブシステム１２０９にライト要求を発行する（ステップ１３０２）。
【００９４】
回復するデータを含むバックアップデータをボリューム１０８に書き込むと、ホスト１０１は、ログファイルを解析してデータの回復を行う範囲を求める。続いて、ホスト１０１は、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔ、ここで求めた回復範囲の開始アドレス、及び、終了アドレスの値を有するデータ復旧要求を作成し、ディスクサブシステム１０９に発行する（ステップ１３０３）。
【００９５】
データ復旧要求を発行した後、ホスト１０１は、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア状態参照要求を作成し、ディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペア分割”でなければ、ペア状態が“ペア分割”になるまで待ち、ペア状態が“ペア分割”であることを確認して次の処理に進む（ステップ１３０４）。
【００９６】
ここまでの処理でデータの回復は完了する。ホスト１０１は、データの回復が完了した後、パラメータとして正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア解除要求をディスクサブシステム１０９に発行する（ステップ１３０５）。
【００９７】
ペア解除要求を発行した後、ホスト１０１は、パラメータに正ボリューム番号Ｓ、副ボリューム番号Ｔを有するペア状態参照要求をディスクサブシステム１０９に発行する。このペア状態参照要求に対する応答としてディスクサブシステム１０９から報告されるペア状態が“ペアなし”でなければ、ペア状態が“ペアなし”となるまで待つ。ペア状態が“ペアなし”となり、ペアの解除が完了するとホスト１０１は処理を終える（ステップ１３０６）。
【００９８】
ステップ１３００において、ホスト１０１からコピーなしペア形成要求を受けたときのディスクサブシステム１０９による処理は次の通りである。
【００９９】
ホスト１０１からのコピーなしペア形成要求に応答して、ディスクサブシステム１０９は、使用中フラグ２００が“未使用”であるペア情報１１０を選択し、その使用中フラグ２００を“使用中”にする。続いて、ディスクサブシステム１０９は、使用中フラグ３０１が“未使用”である差分情報１１１を選択し、その使用中フラグ３０１を“使用中”にする。
【０１００】
次に、ディスクサブシステム１０９は、選択されたペア情報１１０の正ボリューム番号２０１に“Ｓ”、副ボリューム番号２０２に“Ｔ”、差分情報番号２０３に、選択した差分情報１１１の識別子、ペア状態２０４に“ペア分割”をそれぞれ設定する。次に、ディスクサブシステム１０９は、選択した差分情報１１１のコピー対象ビットマップ３０２のすべてのビットを０に、差分ビットマップ３０３のすべてのビットを１にする。
【０１０１】
図１３は、本発明のさらに別の実施形態における情報処理システムのシステム構成を示すブロック図である。本実施形態の情報処理システムは、基本的には図１に示した第１の実施形態における情報処理システムと同様に構成されるが、制御プロセッサ１５０５、制御メモリ１５０６、ボリュームアクセス部１０７などの機能がこれまで説明した実施形態とは異なる。以下、特に、第１の実施形態との相違する点を主体として説明を行う。
【０１０２】
制御メモリ１５０６には、制御プロセッサ１５０５が制御に必要とする制御情報である位置情報１５１０が格納される。物理ボリューム１５０８はデータを格納する機能を有し、ボリュームアクセス部１５０７は、物理ボリューム１５０８にアクセスする機能を有する。
【０１０３】
本実施形態では、ホスト１０１は、ディスクサブシステム１５０９により仮想的に定義される論理ボリュームに対してリードやライトなどの要求を発行する。ディスクサブシステム１５０９には、複数の論理ボリュームを定義でき、各論理ボリュームは、個別の識別子を有する。論理ボリュームは、以下のように定義されている。
【０１０４】
(1) 論理ボリュームは、複数の仮想的な論理トラックから構成されている。論理トラックには、各々を識別するための識別子がつけられている。識別子は、０、１、２、…という値を持つ。
【０１０５】
(2) 論理ボリュームは、１以上の仮想的な論理領域から構成されている。論理領域は、１以上の連続する論理トラックから構成されていて、おのおのの論理領域の論理トラック数は等しい。各論理領域には、おのおのを識別するための識別子がついている。識別子は、０、１、２、…という値を持つ。
【０１０６】
論理ボリューム上のデータは、実際には物理ボリューム１０８に格納される。物理ボリューム１０８は以下のような特徴をもつ。
【０１０７】
(1) 物理ボリューム１０８は、データを格納する実体（例えば磁気ディスク）から構成される。
【０１０８】
(2) 物理ボリューム１０８は、複数の物理トラックから構成される。各物理トラックには、おのおのを識別するための識別子がついている。識別子は、０、１、２、…という値を持つ。
【０１０９】
(3) 物理ボリューム１５０８は、１以上の物理領域から構成される。物理領域は、１以上の連続する物理トラックから構成されている。おのおのの物理領域の物理トラック数は等しく、論理領域を構成する論理トラック数と等しい。物理トラックには、おのおのを識別するための識別子がついている。識別子は、０、１、２、…という値を持つ。
【０１１０】
制御メモリ１５０６には、論理ボリュームと物理ボリュームの対応関係を示すマッピング情報である位置情報が格納される。図１４に位置情報のデータ構造を示す。図に示すように、位置情報１５１０は、論理ボリューム番号１８００、デバイスビジー要求１８０１、リード／ライト実行中フラグ１８０２およびマッピング情報１８０３から構成される。
【０１１１】
論理ボリューム番号１８００は、当該位置情報により管理される論理ボリュームの識別子を示す。デバイスビジー要求１８０１は、論理ボリューム番号１８００により識別される論理ボリュームに対するホスト１０１からのアクセスに対して、デバイスビジーを報告することを示す情報である。デバイスビジー要求１８０１は、“オン”あるいは“オフ”の値を取る。リード／ライト実行中フラグ１８０２は、論理ボリューム番号１８００により識別される論理ボリュームに対するホスト１０１からのリード・ライト要求を実行中であることを示すフラグである。リード／ライト実行中フラグ１８０２は、“オン”あるいは“オフ”の値を取る。マッピング情報１８０３は、論理領域番号１８０４、物理ボリューム番号１８０５および物理領域番号１８０６から構成される。論理領域番号１８０４は、論理ボリューム内の論理領域に割り当てられた識別子を示す。物理ボリューム番号１８０５は、物理ボリューム１０８の識別子を示す。物理領域番号１８０６は、物理ボリューム１０８内の物理領域の識別子である。
【０１１２】
図１５は、データ回復時にホスト１０１側で行われる処理のフローチャートである。
【０１１３】
以下、識別子がＳの論理ボリューム１６００に対して、磁気テープに格納されているバックアップデータをリストアする処理ついて説明する。
【０１１４】
データ回復時にホスト１０１は、まず、未使用の論理ボリュームを１つ選択する。以下、この論理ボリュームの識別子を“Ｔ”とする。ホスト１０１は、磁気テープに格納されているバックアップデータを、識別子“Ｔ”で識別される論理ボリュームにリストアする（ステップ１９０１）。
【０１１５】
リストアが完了すると、ホスト１０１は、パラメータに正ボリューム番号“Ｓ”、副ボリューム番号“Ｔ”を有するスワップ要求を作成し、ディスクサブシステム１５０９に発行する（ステップ１９０２）。
【０１１６】
図１６は、ディスクサブシステム１５０９における処理のフローチャートである。
【０１１７】
ディスクサブシステム１５０９は、ホスト１５０１から要求を受領すると（ステップ２０００）、それがスワップ要求であるかリード／ライト要求か判別する（ステップ２００１）。
【０１１８】
受領した要求がスワップ要求である場合、ディスクサブシステム１５０９は、パラメータで指定された正ボリューム番号と同じ値を論理ボリューム番号１８００に持つ位置情報１５１０を選択する。以下、この位置情報１５１０を位置情報（Ｓ）と表記する。ディスクサブシステム１５０９は、位置情報（Ｓ）のデバイスビジー要求１８０１に“オン”を設定する。次に、ディスクサブシステム１５０９は、パラメータで指定された副ボリューム番号と同じ値を論理ボリューム番号１８００に持つ位置情報１５１０を選択する。以下、この位置情報１５１０を位置情報（Ｔ）と表記する。ディスクサブシステム１５０９は、位置情報（Ｔ）のデバイスビジー要求１８０１に“オン”を設定する（ステップ２００７）。
【０１１９】
デバイスビジー要求１８０１を“オン”に設定した後、ディスクサブシステム１５０９は、位置情報（Ｓ）のリード／ライト実行中フラグ１８０２および位置情報（Ｔ）のリード／ライト実行中フラグ１８０２が“オフ”になっているかどうかを判定する（ステップ２００８）。
【０１２０】
リード／ライト実行中フラグ１８０２が“オフ”でなれければ、“オフ”になるまで待つ。リード／ライト実行中フラグ１８０２が“オフ”になると、マッピング情報１８０３が更新される。すなわち、位置情報（Ｓ）のマッピング情報１８０３の値と位置情報（Ｔ）のマッピング情報１８０３の値が入れ替えられる（ステップ２００９）。
【０１２１】
マッピング情報１８０３の入れ替えが終了したら、ディスクサブシステム１５０９は、位置情報（Ｓ）のデバイスビジー要求１８０１および位置情報（Ｔ）のデバイスビジー要求１８０１２に“オフ”を設定し、処理を終了する（ステップ２０１１）。
【０１２２】
ステップ２００１でホスト１０１から受領した要求がリード／ライト要求であると判別された場合、ディスクサブシステム１５０９は、リード／ライトの対象となる論理ボリューム１６００の識別子を論理ボリューム番号１８００に持つ位置情報１５１０を選択し、デバイスビジー要求１８０１の値が“オン”になっているかどうか判定する。デバイスビジー要求１８０１が“オン”であれば、ディスクサブシステム１５０９は、ホスト１５０１にデバイスビジーを報告して処理を終了する（ステップ２０１０）。
【０１２３】
デバイスビジー要求１８０１が“オン”になっていない場合、ディスクサブシステム１５０９は、位置情報（Ｓ）のリード／ライト実行中フラグ１８０２および位置情報（Ｔ）のリード／ライト実行中フラグ１８０２に“オン”を設定する（ステップ２００３）。
【０１２４】
リード／ライト実行中フラグ１８０２の更新が完了したら、まず、リード／ライト対象の論理トラックに対応する物理トラックを求める。物理トラックは、位置情報（Ｓ）のマッピング１８０３の値から次のようにして求められる。
【０１２５】
(1) リード／ライト対象の論理トラックの識別子の値を、論理領域を構成する論理トラック数で割った時の商をＡ、余りをＢとする。
【０１２６】
(2) マッピング情報１８０３の論理領域番号１８０４がＡである行の物理ボリューム番号１８０５にある値Ｃを求める。
【０１２７】
(3) マッピング情報１８０３の論理領域番号１８０４がＡである行の物理領域番号１８０６にある値Ｄを求める。
【０１２８】
(4) 値Ｄと物理領域を構成する物理トラック数の積をＥとする。
【０１２９】
(5) ＥとＢとの和としてＦを得る。
【０１３０】
以上のようにして求めた値から、リード／ライト対象の物理トラックは、識別子がＣである物理ボリューム１０８内の、識別子がＦである物理トラックであることが求まる（ステップ２００４）。
【０１３１】
物理トラックが得られると、ディスクサブシステム１５０９は、ボリュームアクセス部１５０７により、ホスト１０１との間でデータ転送を実行する（ステップ２００５）。
【０１３２】
データ転送の終了に応答して、ディスクサブシステム１５０９は、位置情報（Ｓ）のリード／ライト実行中フラグ１８０２および位置情報（Ｔ）のリード／ライト実行中フラグ１８０２に“オフ”を設定して処理を終了する（ステップ２００６）。
【０１３３】
以上の説明では、論理ボリューム内のデータがすべて交換されるが、第１の論理ボリューム内のある論理領域と、第２の論理ボリューム内のある論理領域のデータとを交換することもできる。以下、識別子がＳである論理ボリュームの論理領域Ｓ１のデータと、識別子がＴである論理ボリュームの論理領域Ｔ１のデータとを交換する場合について説明する。
【０１３４】
この場合、ホスト１０１は、Ｓ、Ｓ１、Ｔ、Ｔ１をパラメータとして有するデータ交換要求をディスクサブシステム１５０９に対して発行する。
【０１３５】
データ交換要求を受領したディスクサブシステム１５０９は、スワップ要求を受領したときの処理と同様に、デバイスビジー要求１８０１に“オン”を設定し、リード／ライト実行中フラグ１８０２が“オフ”なるのを待つ。リード／ライト実行中フラグ１８０２が“オフ”になったら、論理ボリューム番号１８００がＳである位置情報１５１０に含まれるマッピング情報１８０３の論理領域番号１８０４がＳ１であるエントリに対応する物理ボリューム番号１８０５と物理領域番号１８０６の値と、論理ボリューム番号１８００がＴである位置情報１５１０のマッピング１８０３の論理領域番号１８０４がＴ１であるエントリに対応する物理ボリューム番号１８０５と物理領域番号１８０６の値とを入れ替える。入れ替えが終了したら、デバイスビジー要求１８０１に“オフ”を設定して、処理を終了する。
【０１３６】
【発明の効果】
本発明によれば、ホストで実行中の処理に障害が発生し、ディスクサブシステムのデータを復旧する場合に、ホストに負担をかけず、短時間でデータをリストアすることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態における情報処理システムのシステム構成を示すブロック図である。
【図２】ペア情報１１０の一例を示すデータ構造図である。
【図３】差分情報１１１の一例を示すデータ構造図である。
【図４】バッチ処理を実行する時のホスト１０１による処理の流れを示すフローチャートである。
【図５】ホスト１０１からの要求に応答してディスクサブシステム１０９により行われる処理の処理フローを示すフローチャートである。
【図６】ステップ５０７において実施される形成コピー処理のフローチャートである。
【図７】ステップ５１２で実施されるデータ復旧処理のフローチャートである。
【図８】ステップ５１６におけるリード処理のフローチャートである。
【図９】ステップ５１７で行われるライト処理のフローチャートである。
【図１０】データを復旧中の領域に対するリード要求に対してデータ転送を行うために、ステップ８０３に替えて行われる処理のフローチャートである。
【図１１】データを復旧中の領域に対するライト要求を処理するために、ステップ９０３に替えて行われる処理のフローチャートである。
【図１２】データ回復処理時のホスト１０１側の処理を示すフローチャートである。
【図１３】本発明の別の実施形態における情報処理システムのシステム構成を示すブロック図である。
【図１４】位置情報のデータ構造を示すデータ構成図。
【図１５】データ回復時にホスト１０１側で行われる処理のフローチャートである。
【図１６】ディスクサブシステム１５０９における処理のフローチャートである。
【符号の説明】
１００・・・遠隔端末
１０１・・・ホスト
１０２・・・ＬＡＮ
１０３・・・バス
１０４・・・遠隔端末インタフェース
１０５・・・ホストインタフェース
１０６・・・制御メモリ
１０７・・・ボリュームアクセス部
１０８・・・ボリューム
１０９・・・ディスクサブシステム
１１０・・・ペア情報
１１１・・・差分情報
Claims (2)
- 中央処理装置と、ディスク装置を備え、前記中央処理装置からの要求にしたがってデータ転送を実行するディスクサブシステムとを有する情報処理システムにおいて、前記中央処理装置で行われるバッチ処理に障害が発生した際に、所定の状態までデータを復旧するためのデータ復旧方法であって、
前記中央処理装置でバッチ処理を実行する前に、前記情報処理装置から前記ディスクサブシステムに対して、前記バッチ処理で使用されるディスク装置に格納されているデータの写しを保存する保存要求を発行し、
前記ディスクサブシステムにおいて、前記保存要求に応答して、前記ディスク装置のデータの写しを第２のディスク装置に保存し、
前記ディスクサブシステムが、前記バッチ処理の実行に伴って前記ディスク装置の内容が更新されたとき、更新された場所を差分情報として記憶し、
前記ディスク装置の内容を、バッチ処理を実行する前の状態に復旧する必要が生じた場合、前記中央処理装置から前記ディスクサブシステムにデータの復旧要求を発行し、
前記ディスクサブシステムにおいて、前記復旧要求に応答して、記憶された前記差分情報に基づいて、前記保存されたデータを前記ディスク装置にリストアし、
前記データの写しの保存は、使用されていないディスク装置を前記第２のディスク装置として割り当て、前記ディスク装置と２重化した前記第２のディスク装置に、前記ディスク装置と同一のデータを保存する保存処理を含み、
前記保存要求は、前記ディスク装置を二重化することを要求する第１の要求と、前記ディスク装置と前記二重化された前記第２のディスク装置とをペアを形成した状態から分割する第２の要求とを含み、前記保存処理は、前記第１の要求に応答して、前記ディスク装置と前記第２のディスク装置とのペアを形成し、前記ディスク装置と前記二重化された前記第２のディスク装置とのペアの分割は、第２の要求に応答して、前記ペアを形成した状態から前記ペアを分割することにより行われるものであり、
前記データのリストアは、前記差分情報により、前記バッチ処理により更新された場所を対象として、前記第２のディスク装置の対応する記憶場所に保存されているデータを読み出し、読み出したデータを前記ディスク装置の更新された場所に書き込むことにより行われる
ことを特徴とするデータ復旧方法。 - 中央処理装置からの要求にしたがってデータ転送を実行するディスクサブシステムにおいて、
複数のディスク装置と、
前記中央処理装置からの要求に応答して、第１のディスク装置に格納されたデータの写しを第２のディスク装置に保存する手段と、
前記中央処理装置からのデータの更新要求に応答して、前記第１のディスク装置のデータを更新し、該更新箇所を識別するための差分情報を生成する手段と、
前記中央処理装置からのデータ復旧要求に応答して、前記差分情報に基づいて前記第１のディスク装置の更新が行われた場所のデータを前記第２のディスク装置の対応する記憶場所に保存されているデータと置き換える手段とを有し、
前記データの写しを第２のディスク装置に保存する手段は、
使用されていないディスク装置を前記第２のディスク装置として割り当て、前記ディスク装置と２重化した前記第２のディスク装置に、前記ディスク装置と同一のデータを保存する保存処理を含み、
前記要求は、前記第１のディスク装置を二重化することを要求する第１の要求と、前記第１のディスク装置と前記二重化されたディスク装置とをペアを形成した状態から分割する第２の要求とを含み、前記保存処理は、前記第１の要求に応答して、前記ディスク装置と前記第２のディスク装置とのペアを形成し、前記ディスク装置と前記二重化された前記第２のディスク装置とのペアの分割は、第２の要求に応答して、前記ペアを形成した状態から前記ペアを分割することにより行われる
ことを特徴とするディスクサブシステム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000030217A JP4115060B2 (ja) | 2000-02-02 | 2000-02-02 | 情報処理システムのデータ復旧方法及びディスクサブシステム |
| US09/639,755 US6658434B1 (en) | 2000-02-02 | 2000-08-15 | Method of and a system for recovering data in an information processing system |
| US10/673,609 US7689611B2 (en) | 2000-02-02 | 2003-09-30 | Method of and a system for recovering data in an information processing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000030217A JP4115060B2 (ja) | 2000-02-02 | 2000-02-02 | 情報処理システムのデータ復旧方法及びディスクサブシステム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007323170A Division JP4204060B2 (ja) | 2007-12-14 | 2007-12-14 | 情報処理システムのデータ復旧方法及びディスクサブシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001216185A JP2001216185A (ja) | 2001-08-10 |
| JP4115060B2 true JP4115060B2 (ja) | 2008-07-09 |
Family
ID=18555259
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000030217A Expired - Fee Related JP4115060B2 (ja) | 2000-02-02 | 2000-02-02 | 情報処理システムのデータ復旧方法及びディスクサブシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (2) | US6658434B1 (ja) |
| JP (1) | JP4115060B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7778958B2 (en) | 2002-04-11 | 2010-08-17 | Quantum Corporation | Recovery of data on a primary data volume |
Families Citing this family (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003162378A (ja) | 2001-11-26 | 2003-06-06 | Hitachi Ltd | データ複写方法 |
| JP2003296147A (ja) | 2002-04-08 | 2003-10-17 | Hitachi Ltd | ボリューム管理方法および装置 |
| JP2004178254A (ja) * | 2002-11-27 | 2004-06-24 | Hitachi Ltd | 情報処理システム、ストレージシステム、記憶デバイス制御装置、及びプログラム |
| JP3974538B2 (ja) | 2003-02-20 | 2007-09-12 | 株式会社日立製作所 | 情報処理システム |
| JP4165747B2 (ja) | 2003-03-20 | 2008-10-15 | 株式会社日立製作所 | 記憶システム、制御装置及び制御装置のプログラム |
| JP2004302713A (ja) * | 2003-03-31 | 2004-10-28 | Hitachi Ltd | 記憶システム及びその制御方法 |
| US7398422B2 (en) * | 2003-06-26 | 2008-07-08 | Hitachi, Ltd. | Method and apparatus for data recovery system using storage based journaling |
| US20050015416A1 (en) | 2003-07-16 | 2005-01-20 | Hitachi, Ltd. | Method and apparatus for data recovery using storage based journaling |
| US7111136B2 (en) * | 2003-06-26 | 2006-09-19 | Hitachi, Ltd. | Method and apparatus for backup and recovery system using storage based journaling |
| US20050022213A1 (en) | 2003-07-25 | 2005-01-27 | Hitachi, Ltd. | Method and apparatus for synchronizing applications for data recovery using storage based journaling |
| JP4124348B2 (ja) | 2003-06-27 | 2008-07-23 | 株式会社日立製作所 | 記憶システム |
| US7725760B2 (en) | 2003-09-23 | 2010-05-25 | Symantec Operating Corporation | Data storage system |
| US7827362B2 (en) | 2004-08-24 | 2010-11-02 | Symantec Corporation | Systems, apparatus, and methods for processing I/O requests |
| US7904428B2 (en) | 2003-09-23 | 2011-03-08 | Symantec Corporation | Methods and apparatus for recording write requests directed to a data store |
| US7991748B2 (en) | 2003-09-23 | 2011-08-02 | Symantec Corporation | Virtual data store creation and use |
| US7287133B2 (en) | 2004-08-24 | 2007-10-23 | Symantec Operating Corporation | Systems and methods for providing a modification history for a location within a data store |
| US7730222B2 (en) | 2004-08-24 | 2010-06-01 | Symantec Operating System | Processing storage-related I/O requests using binary tree data structures |
| US7577806B2 (en) | 2003-09-23 | 2009-08-18 | Symantec Operating Corporation | Systems and methods for time dependent data storage and recovery |
| US7409587B2 (en) * | 2004-08-24 | 2008-08-05 | Symantec Operating Corporation | Recovering from storage transaction failures using checkpoints |
| JP4385215B2 (ja) | 2003-10-21 | 2009-12-16 | 日本電気株式会社 | スナップショットシミュレーション機能を有するディスクアレイ装置 |
| JP2005149436A (ja) * | 2003-11-20 | 2005-06-09 | Hitachi Ltd | ストレージ装置、ストレージ装置における制御方法、ジョブスケジューリング処理方法及び障害処理方法並びにそれらのプログラム |
| US7437389B2 (en) * | 2004-03-10 | 2008-10-14 | Hitachi, Ltd. | Remote copy system |
| US7724599B2 (en) | 2003-12-03 | 2010-05-25 | Hitachi, Ltd. | Remote copy system |
| US7085788B2 (en) * | 2003-12-03 | 2006-08-01 | Hitachi, Ltd. | Remote copy system configured to receive both a write request including a write time and a write request not including a write time. |
| JP2005190259A (ja) * | 2003-12-26 | 2005-07-14 | Hitachi Ltd | 複数世代のバックアップデータの管理 |
| JP4551096B2 (ja) * | 2004-02-03 | 2010-09-22 | 株式会社日立製作所 | ストレージサブシステム |
| JP2006011811A (ja) | 2004-06-25 | 2006-01-12 | Hitachi Ltd | 記憶制御システム及び記憶制御方法 |
| JP4477950B2 (ja) * | 2004-07-07 | 2010-06-09 | 株式会社日立製作所 | リモートコピーシステム及び記憶装置システム |
| JP4915775B2 (ja) * | 2006-03-28 | 2012-04-11 | 株式会社日立製作所 | ストレージシステム及びストレージシステムのリモートコピー制御方法 |
| US7330861B2 (en) | 2004-09-10 | 2008-02-12 | Hitachi, Ltd. | Remote copying system and method of controlling remote copying |
| CN101084552A (zh) * | 2004-12-21 | 2007-12-05 | 皇家飞利浦电子股份有限公司 | 一种光盘数据纠错方法及装置 |
| JP4843976B2 (ja) * | 2005-03-25 | 2011-12-21 | 日本電気株式会社 | レプリケーションシステムと方法 |
| JP4648751B2 (ja) * | 2005-05-02 | 2011-03-09 | 株式会社日立製作所 | 記憶制御システム及び記憶制御方法 |
| JP5057366B2 (ja) | 2006-10-30 | 2012-10-24 | 株式会社日立製作所 | 情報システム及び情報システムのデータ転送方法 |
| JP4902403B2 (ja) | 2006-10-30 | 2012-03-21 | 株式会社日立製作所 | 情報システム及びデータ転送方法 |
| JP5244332B2 (ja) | 2006-10-30 | 2013-07-24 | 株式会社日立製作所 | 情報システム、データ転送方法及びデータ保護方法 |
| JP4845724B2 (ja) | 2006-12-28 | 2011-12-28 | 株式会社日立製作所 | バックアップ機能を備えたストレージシステム |
| US8990378B2 (en) * | 2007-07-05 | 2015-03-24 | Interwise Ltd. | System and method for collection and analysis of server log files |
| JP5209293B2 (ja) * | 2007-12-21 | 2013-06-12 | 株式会社野村総合研究所 | 業務継続システム |
| JP4607981B2 (ja) | 2008-03-27 | 2011-01-05 | 富士通株式会社 | コピー制御装置、コピー制御方法およびコピー制御プログラム |
| US8019732B2 (en) | 2008-08-08 | 2011-09-13 | Amazon Technologies, Inc. | Managing access of multiple executing programs to non-local block data storage |
| US8510750B2 (en) * | 2008-09-23 | 2013-08-13 | 1060 Research Limited | Method for caching resource representations in a contextual address space |
| JP4833273B2 (ja) | 2008-12-09 | 2011-12-07 | 富士通株式会社 | ストレージ装置、リストア方法およびリストアプログラム |
| US9141508B2 (en) | 2010-12-21 | 2015-09-22 | Oracle International Corporation | Assigning read requests based on busyness of devices |
| JP5673417B2 (ja) * | 2011-07-29 | 2015-02-18 | 富士通株式会社 | データ復旧方法，データ復旧装置およびデータ復旧プログラム |
| CN103731424B (zh) * | 2013-12-30 | 2017-09-15 | 优视科技有限公司 | 一种网络数据的传输方法、装置及系统 |
| US9612964B2 (en) | 2014-07-08 | 2017-04-04 | International Business Machines Corporation | Multi-tier file storage management using file access and cache profile information |
| JP5991699B2 (ja) | 2014-08-08 | 2016-09-14 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 情報処理装置、情報処理システム、バックアップ方法、およびプログラム |
| US10872008B2 (en) * | 2018-06-22 | 2020-12-22 | Micron Technology, Inc. | Data recovery after storage failure in a memory system |
Family Cites Families (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4625081A (en) * | 1982-11-30 | 1986-11-25 | Lotito Lawrence A | Automated telephone voice service system |
| US4638424A (en) * | 1984-01-12 | 1987-01-20 | International Business Machines Corporation | Managing data storage devices connected to a digital computer |
| US4941089A (en) * | 1986-12-12 | 1990-07-10 | Datapoint Corporation | Input/output network for computer system |
| US5065311A (en) * | 1987-04-20 | 1991-11-12 | Hitachi, Ltd. | Distributed data base system of composite subsystem type, and method fault recovery for the system |
| US5140592A (en) * | 1990-03-02 | 1992-08-18 | Sf2 Corporation | Disk array system |
| US5124987A (en) * | 1990-04-16 | 1992-06-23 | Storage Technology Corporation | Logical track write scheduling system for a parallel disk drive array data storage subsystem |
| US5210866A (en) * | 1990-09-12 | 1993-05-11 | Storage Technology Corporation | Incremental disk backup system for a dynamically mapped data storage subsystem |
| CA2101848A1 (en) * | 1991-02-06 | 1992-08-07 | Robert Walsh | Disk drive array memory system using nonuniform disk drives |
| JPH04309145A (ja) | 1991-04-08 | 1992-10-30 | Hokkaido Nippon Denki Software Kk | データファイル制御方式 |
| US5459857A (en) * | 1992-05-15 | 1995-10-17 | Storage Technology Corporation | Fault tolerant disk array data storage subsystem |
| US5459875A (en) * | 1994-11-14 | 1995-10-24 | Fattorusso; Louis J. | Slide fastener pouch storable garment |
| US5564047A (en) * | 1995-04-11 | 1996-10-08 | International Business Machines Corporation | Trigger generation in an active database management system |
| US5692155A (en) | 1995-04-19 | 1997-11-25 | International Business Machines Corporation | Method and apparatus for suspending multiple duplex pairs during back up processing to insure storage devices remain synchronized in a sequence consistent order |
| US5644696A (en) * | 1995-06-06 | 1997-07-01 | International Business Machines Corporation | Recovering multi-volume data sets during volume recovery |
| US6304980B1 (en) * | 1996-03-13 | 2001-10-16 | International Business Machines Corporation | Peer-to-peer backup system with failure-triggered device switching honoring reservation of primary device |
| US5819310A (en) * | 1996-05-24 | 1998-10-06 | Emc Corporation | Method and apparatus for reading data from mirrored logical volumes on physical disk drives |
| JP4095139B2 (ja) | 1996-09-03 | 2008-06-04 | 株式会社東芝 | コンピュータシステムおよびファイル管理方法 |
| KR19980024086A (ko) | 1996-09-03 | 1998-07-06 | 니시무로 타이조 | 컴퓨터 시스템 및 화일 관리 방법 |
| US5926819A (en) * | 1997-05-30 | 1999-07-20 | Oracle Corporation | In-line triggers |
| US5971778A (en) * | 1997-06-16 | 1999-10-26 | Silicon Gear Corporation | Memory storage device bracket having releasing and extracting handle |
| US6189071B1 (en) * | 1997-10-06 | 2001-02-13 | Emc Corporation | Method for maximizing sequential output in a disk array storage device |
| US6237063B1 (en) * | 1997-10-06 | 2001-05-22 | Emc Corporation | Load balancing method for exchanging data in different physical disk storage devices in a disk array storage device independently of data processing system operation |
| US6631477B1 (en) * | 1998-03-13 | 2003-10-07 | Emc Corporation | Host system for mass storage business continuance volumes |
| US6154852A (en) * | 1998-06-10 | 2000-11-28 | International Business Machines Corporation | Method and apparatus for data backup and recovery |
| US6493825B1 (en) * | 1998-06-29 | 2002-12-10 | Emc Corporation | Authentication of a host processor requesting service in a data processing network |
| US6295575B1 (en) * | 1998-06-29 | 2001-09-25 | Emc Corporation | Configuring vectors of logical storage units for data storage partitioning and sharing |
| US6421711B1 (en) * | 1998-06-29 | 2002-07-16 | Emc Corporation | Virtual ports for data transferring of a data storage system |
| US6353878B1 (en) * | 1998-08-13 | 2002-03-05 | Emc Corporation | Remote control of backup media in a secondary storage subsystem through access to a primary storage subsystem |
| US6269431B1 (en) * | 1998-08-13 | 2001-07-31 | Emc Corporation | Virtual storage and block level direct access of secondary storage for recovery of backup data |
| US6385706B1 (en) * | 1998-12-31 | 2002-05-07 | Emx Corporation | Apparatus and methods for copying a logical object to a primary storage device using a map of storage locations |
| US6349357B1 (en) * | 1999-03-04 | 2002-02-19 | Sun Microsystems, Inc. | Storage architecture providing scalable performance through independent control and data transfer paths |
| US6317334B1 (en) * | 1999-05-25 | 2001-11-13 | Hewlett-Packard Company | Configuration connector for modular data storage system |
| US6252514B1 (en) * | 1999-06-07 | 2001-06-26 | Convergent Technologies, Inc. | Hot-swap assembly for computers |
| US6529995B1 (en) * | 1999-06-18 | 2003-03-04 | Storage Technology Corporation | Method and apparatus for maintaining and restoring mapping table entries and data in a raid system |
| US6490690B1 (en) * | 1999-07-22 | 2002-12-03 | International Business Machines Corporation | Method and apparatus for unix system catastrophic recovery aid |
| US6912629B1 (en) * | 1999-07-28 | 2005-06-28 | Storage Technology Corporation | System and method for restoring data from secondary volume to primary volume in a data storage system |
| US6397292B1 (en) * | 1999-08-19 | 2002-05-28 | Emc Corporation | Asymmetrical striping of mirrored storage device arrays and concurrent access to even tracks in the first array and odd tracks in the second array to improve data access performance |
| US6681310B1 (en) * | 1999-11-29 | 2004-01-20 | Microsoft Corporation | Storage management system having common volume manager |
-
2000
- 2000-02-02 JP JP2000030217A patent/JP4115060B2/ja not_active Expired - Fee Related
- 2000-08-15 US US09/639,755 patent/US6658434B1/en not_active Expired - Fee Related
-
2003
- 2003-09-30 US US10/673,609 patent/US7689611B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7778958B2 (en) | 2002-04-11 | 2010-08-17 | Quantum Corporation | Recovery of data on a primary data volume |
Also Published As
| Publication number | Publication date |
|---|---|
| US6658434B1 (en) | 2003-12-02 |
| US7689611B2 (en) | 2010-03-30 |
| US20050251517A1 (en) | 2005-11-10 |
| JP2001216185A (ja) | 2001-08-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4115060B2 (ja) | 情報処理システムのデータ復旧方法及びディスクサブシステム | |
| US7533298B2 (en) | Write journaling using battery backed cache | |
| US5499367A (en) | System for database integrity with multiple logs assigned to client subsets | |
| JP4800031B2 (ja) | ストレージシステム及びスナップショット管理方法 | |
| US7496718B2 (en) | Data transfer and access control between disk array systems | |
| US6678809B1 (en) | Write-ahead log in directory management for concurrent I/O access for block storage | |
| JP4419884B2 (ja) | データ複製装置、方法及びプログラム並びに記憶システム | |
| US6701455B1 (en) | Remote copy system with data integrity | |
| US7398354B2 (en) | Achieving data consistency with point-in-time copy operations in a parallel I/O environment | |
| JP4152373B2 (ja) | リモートミラーキャッシュ内の論理オブジェクトの完全性を保つシステム | |
| JP4681247B2 (ja) | ディスクアレイ装置及びディスクアレイ装置の制御方法 | |
| JP2003223287A (ja) | 記憶装置、この記憶装置のバックアップ方法及びプログラム | |
| JP2001518210A (ja) | 共通データセットに対する独立及び同時のアクセスに関する方法及び装置 | |
| US20080222214A1 (en) | Storage system and remote copy system restoring data using journal | |
| JP2002259062A (ja) | 記憶装置システム及び記憶装置システムにおけるデータの複写方法 | |
| US8140886B2 (en) | Apparatus, system, and method for virtual storage access method volume data set recovery | |
| JP4104281B2 (ja) | データベースアクセス方法 | |
| JP2023055998A (ja) | ストレージシステム及びストレージシステムの制御方法 | |
| US20100205482A1 (en) | Mirroring controller, storage device, and mirroring control method | |
| JP4204060B2 (ja) | 情報処理システムのデータ復旧方法及びディスクサブシステム | |
| JP3882467B2 (ja) | 記憶装置システムのスナップショット管理方法 | |
| JP3955453B2 (ja) | 外部記憶装置の制御方法 | |
| US20050223180A1 (en) | Accelerating the execution of I/O operations in a storage system | |
| US10656867B2 (en) | Computer system, data management method, and data management program | |
| JPH07319637A (ja) | ディスク装置の制御装置およびディスク装置の制御方 法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060417 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070615 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070626 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070824 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20070824 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20070905 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071015 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071214 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080317 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080408 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080415 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110425 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110425 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120425 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120425 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130425 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130425 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140425 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |