JP2000227868A

JP2000227868A - バックアップ取得方法および計算機システム

Info

Publication number: JP2000227868A
Application number: JP11344259A
Authority: JP
Inventors: Kenji Yamakami; 憲司山神; Takashi Arakawa; 敬史荒川; Shigeo Honma; 繁雄本間; Manabu Kitamura; 学北村
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1998-12-04
Filing date: 1999-12-03
Publication date: 2000-08-15

Abstract

(57)【要約】【課題】メインフレームなどＣＫＤ形式を用いるコンピ
ュータが使用するデータを、パソコンやワークステーシ
ョンなどの固定長ブロック形式を用いる小型コンピュー
タで、高速にバックアップする。【解決手段】互いに異なる第１と第２のインターフェー
ス３２０，３３０を備えた記憶装置３００が、第１のイ
ンタフェース１１０を有するホスト１００と第２のイン
タフェース２１０を有するホスト２００とに接続され
る。ホスト１００は、第１のインターフェース１１０を
介して記憶装置３００にデータを格納する。ホスト２０
０は、第１のインタフェースにおけるデータの格納形式
を第２のインタフェースにおける格納形式におけるデー
タの格納形式に変換し、バックアップするデータの格納
位置情報を獲得し、その格納位置情報に基づいて記憶装
置３００からデータを読み出してバックアップ装置２９
０に保存する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、計算機システムに
おけるバックアップの取得方法、および該バックアップ
取得方法を用いた計算機システムに関する。

【０００２】

【従来の技術】従来メインフレームで行われてきた業務
をパソコンやワークステーションなどの小型コンピュー
タで行う「ダウンサイジング」などにより、近年、メイ
ンフレーム、パソコン、及びワークステーションなど、
異種のコンピュータやオペレーティングシステムが混在
したコンピュータシステムが構築されるようになってき
た。異種のコンピュータ、あるいは、異種のオペレーテ
ィングシステムの間でデータを交換する技術として、デ
ータをネットワーク経由で転送する、ＦＴＰ（File Tra
nsfer Protocol）や、分散データベースなどの技術が知
られている。このような技術については、例えば、日経
オープンシステム１９９８年２月（ｎｏ．５９）ｐ．２
３０−ｐ．２４１に開示がある。

【０００３】特開平９−２５８９０８号公報には、メイ
ンフレームのＩ／Ｏインターフェース形式であるカウン
トキーデータ形式（ＣＫＤ形式）と、パソコンやワーク
ステーションなど小型コンピュータのＩ／Ｏインターフ
ェース形式である固定長ブロック形式の両形式のインタ
ーフェースを有するディスクサブシステムを使用して、
異種コンピュータ、異種オペレーティングシステム間で
データを共用する方法が示されている。

【０００４】

【発明が解決しようとする課題】上記従来技術によれ
ば、ネットワーク経由のデータ転送によりメインフレー
ムのデータをパソコンやワークステーションなど小型コ
ンピュータに転送し、データを小型コンピュータに接続
したテープ装置などに保存してバックアップを取得する
ことができる。しかし、この場合、ネットワーク経由の
データ転送速度はＩ／Ｏデバイスの転送速度と比較して
低速であるため、バックアップ処理時間が大きくなると
いう課題がある。

【０００５】また、ネットワークを経由したバックアッ
プの取得方法においては、メインフレームと小型コンピ
ュータの双方に処理負荷が発生する。特に、データの保
存を行う小型コンピュータ側のみでなくメインフレーム
においても処理負荷が発生するのは問題である。一般に
メインフレームはトランザクション処理など高速処理、
高速応答を要する処理を行うため、バックアップ処理に
よりメインフレームに処理負荷が発生することは好まし
くない。また、この方法では、ネットワークに対し転送
帯域負荷が発生するという課題もある。

【０００６】上記特開平９−２５８９０８号公報には、
ＣＫＤ形式および固定長ブロック形式の両形式のインタ
フェースを有するディスクサブシステムに対し、ＣＫＤ
形式のインターフェースに接続するメインフレームが格
納したデータを、固定長ブロック形式のインターフェー
スに接続するパソコンやワークステーションなどの小型
コンピュータが読み上げ、小型コンピュータ上のアプリ
ケーションプログラムで該データを使用する方法が示さ
れている。しかし、この方法により、メインフレームが
ディスクサブシステムに格納したデータを、小型コンピ
ュータに接続したテープ装置などに保存してバックアッ
プを取得する場合、小型コンピュータ上のアプリケーシ
ョンプログラムには格納したデータのみが得られ、バッ
クアップに係る各種の管理情報は得られない。ここで、
管理情報とは、バックアップの取得処理や管理、および
バックアップデータによるデータの回復処理（リストア
処理）に有用な情報であり、例えばリストアするときに
データを戻す位置情報などを含むものである。管理情報
がなければ、バックアップしたデータをリストアすると
き、元の位置に戻すことができない。従って、特開平９
−２５８９０８号公報に開示された技術を用いて、小型
コンピュータによりメインフレームが作成したデータの
バックアップを取得するには無理がある。

【０００７】本発明の第一の目的は、メインフレームな
どＣＫＤ形式を用いるコンピュータが使用するデータの
バックアップを、固定長ブロック形式を用いるコンピュ
ータに接続したテープ装置などに保存して取得する際
に、高速なバックアップ処理を実現してバックアップ処
理時間を削減できるバックアップ取得方法を提供するこ
とである。また、この際に、本発明の第二の目的は、メ
インフレームなどＣＫＤ形式を用いるコンピュータが使
用するデータのバックアップを、固定長ブロック形式を
用いるコンピュータに接続したテープ装置などに保存し
て取得する際に、メインフレーム側、あるいは両コンピ
ュータ間を接続するネットワークに発生する処理負荷を
削減できるバックアップ取得方法を提供することであ
る。

【０００８】

【課題を解決するための手段】上記課題を解決するため
に、本発明は、互いに異なる第一のインターフェースお
よび第二のインターフェースを有する記憶装置と、第一
のインターフェースによって記憶装置に接続する第一の
計算機および第二のインターフェースによって記憶装置
に接続する第二の計算機を備えた計算機システムにおけ
るバックアップ取得方法であって、第一の計算機が第一
のインターフェースにより記憶装置に格納したデータ
を、第二の計算機が第二のインターフェースにより記憶
装置から読み出して保存することを特徴とする。

【０００９】また、他の観点から、本発明による計算機
システムは、互いに異なる第一のインターフェースおよ
び第二のインターフェースを有する記憶装置と、第一の
インターフェースによって記憶装置に接続する第一の計
算機および第二のインターフェースによって記憶装置に
接続する第二の計算機を備えた計算機システムであっ
て、第二の計算機が、第一の計算機により第一のインタ
ーフェースに係る格納形式で記憶装置に格納されたデー
タを、第二のインターフェースによって検出して読み出
す手段と、第二のインターフェースによる読み出しを行
うため、データの格納形式を第一のインターフェースに
係る格納形式に変換する手段と、読み出したデータを保
存することによって、第一の計算機が使用するデータの
バックアップを取得する手段とを備えたことを特徴とす
る。

【００１０】本発明の好ましい一つの態様によれば、第
一のインターフェースとして、カウントキーデータ形式
に従うインターフェースが用いられ、第二のインターフ
ェースとして、固定長ブロック形式に従うインターフェ
ースが用いられる。第一の計算機が記憶装置に格納した
データに関して第一の計算機が記憶装置内に作成した管
理情報は、第二の計算機が記憶装置から検出し読み出し
て保存するようにするとよい。また、第二の計算機は、
第一の計算機が記憶装置に格納したデータに関して、第
一の計算機が記憶装置内に作成した管理情報を記憶装置
から検出して読み出し、バックアップ取得の処理の制御
に用いるようにしてもよい。

【００１１】さらに、本発明の他の態様によれば、互い
に異なる第一のインターフェースおよび第二のインター
フェースを有する記憶装置と、第一のインターフェース
によって記憶装置に接続する第一の計算機と、記憶装置
と前記第二のインタフェースによって接続されたスイッ
チ装置と、スイッチ装置と接続する第二の計算機と、ス
イッチ装置に接続されたバックアップ装置を有する計算
機システムが提供される。

【００１２】第一の計算機は、前記第二の計算機よりバ
ックアップ要求を受領すると、バックアップ対象データ
を格納するボリュームのボリュームＩＤと該ボリューム
上の物理アドレスを含む格納位置情報を前記第二の計算
機へ通知する。第二の計算機は、格納位置情報を受信
し、格納位置情報に基づいて、スイッチ装置にバックア
ップ対象データをボリュームＩＤにより識別されるボリ
ュームからバックアップ装置へコピーすることを指示す
るためのコマンドを作成して、発行する。スイッチ装置
は、コマンドの内容にしたがって、ボリュームからバッ
クアップ装置へバックアップ対象データをコピーする。

【００１３】

【発明の実施の形態】図１は、本発明を用いた計算機シ
ステムの第１の実施形態における構成図である。

【００１４】本実施形態における計算機システムは、２
台のホストコンピュータ（以降、単にホストと呼ぶ）１
００、２００、ホスト１００とホスト２００の両者に接
続するディスクサブシステム３００、及びホスト２００
に接続されたテープデバイス２９０を有している。ホス
ト１００とホスト２００は、ネットワーク４００を介し
て相互に接続されている。

【００１５】ホスト１００は、ディスクサブシステム３
００が接続するＣＫＤインタフェース１１０と、ネット
ワーク４００に接続するためのネットワークインタフェ
ース１２０を有する。ＣＫＤインタフェース１１０は、
カウントキーデータ形式（ＣＫＤ形式）に従うインター
フェースである。

【００１６】ホスト１００は、その上で動作するプログ
ラムとして、オペレーティングシステム１３０と、オペ
レーティングシステム１３０の制御下で動作するアプリ
ケーションプログラム１４０及びバックアップエージェ
ントプログラム１５０を有する。これらのプログラム
は、ホスト１００が有するメモリ（図示せず）に格納さ
れる。ホスト１００による各種の処理は、これらのプロ
グラムがＣＰＵ（図示せず）により実行されることで実
現される。

【００１７】ホスト２００は、ディスクサブシステム３
００が接続する固定長インタフェース２１０、テープデ
バイス２１１が接続する固定長インタフェース２１１、
及びネットワーク４００に接続するネットワークインタ
フェース２２０を有する。固定長インタフェース２１
０、及び２１１は、固定長ブロック形式に従うインター
フェースである。

【００１８】ホスト２００は、ホスト１００は、プログ
ラムとして、オペレーティングシステム２３０と、オペ
レーティングシステム２３０の制御下で動作するファイ
ルアクセスプログラム２４０、形式変換プログラム２５
０、及びバックアッププログラム２６０を有する。これ
らのプログラムは、図示しないメモリに格納され、図示
しないＣＰＵによって実行されることで、所定の機能を
達成する。

【００１９】ディスクサブシステム３００は、ディスク
３１０、ホスト１００と接続するＣＫＤインタフェース
３２０、ホスト２００と接続する固定長インターフェー
ス３３０、及びＣＫＤインタフェース変換手段３４０を
有する。

【００２０】固定長ブロック形式では、データは、ブロ
ックと呼ばれる、例えば、５１２バイトの固定長の記憶
領域に格納される形で扱われる。各ブックロの指定は、
各々のブロックに割り当てられたブロック番号（ＬＢ
Ａ）を用いて行われる。

【００２１】ＣＫＤ形式では、データは、可変長の記憶
領域であるレコードに格納する形で扱われる。ＣＫＤ形
式では、シリンダ番号（ＣＣ）、ヘッド番号（ＨＨ）、
およびレコード番号（Ｒ）を指定して、レコードが指定
される。以下、シリンダ番号、ヘッド番号、およびレコ
ード番号で表される、レコードを指定するためのアドレ
スをＣＣＨＨＲと呼ぶ。シリンダ番号とヘッド番号のみ
で表されるレコードの集合がトラックであり、トラック
を指定するためのアドレスをＣＣＨＨと呼ぶ。ＣＫＤ形
式におけるレコードは、カウント部（Ｃ部）、キー部
（Ｋ部）、およびデータ部（Ｄ部）の３部分からなる。
Ｃ部は固定長であり、ＣＣＨＨＲと、Ｋ部およびＤ部の
それぞれの長さが格納される。Ｋ部およびＤ部は可変長
である。

【００２２】図２は、ＣＫＤ形式でのデータ構造と、デ
ィスク上でのディスクは一の関係を示す説明図である。
図において、ＡはＣＫＤ形式のトラック上のデータ配置
を、ＢはＡに示すＣＫＤ形式のデータのディスク３１０
へ格納した状態のデータ配置を示す。本実施形態におい
ては、ディスク３１０は、物理的には固定長ブロック形
式に従う。ホスト１００が用いるＣＫＤ形式のデータ
は、ＣＫＤインタフェース変換手段３４０により固定長
ブロック形式に変換された上でディスク３１０に格納さ
れる。

【００２３】図中Ａに示すＣＫＤ形式において、ＨＡ５
１０は、ホームアドレスであり、トラックの状態等を示
す。Ｒ０Ｃ５２０はレコード番号０のレコード“（Ｒ
０”のＣ部であり、Ｒ０Ｄ５３０は、）レコード“Ｒ
０”のＤ部である。Ｒ０Ｄ５３０は、管理情報の格納に
用いられ、ユーザのデータを格納することはできない。
Ｒ１Ｃ５４０、Ｒ１Ｋ５５０、Ｒ１Ｄ５６０は、それぞ
れレコード番号１のレコード“Ｒ１”のＣ部、Ｄ部、Ｋ
部、Ｒ２Ｃ５７０、Ｒ２Ｋ５８０、Ｒ２Ｄ５９０は、そ
れぞれレコード番号２のレコード“Ｒ２”のＣ部、Ｄ
部、Ｋ部である。ユーザデータは、通常、“Ｒ１”以降
のレコードのＤ部に格納される。

【００２４】本実施形態のディスクサブシステム３００
では、全トラックのＨＡ５１０、Ｒ０Ｃ５２０、Ｒ０Ｄ
５３０は、Ｒ１以降のレコードとは別の領域にまとめて
格納される。“Ｒ１”以降のレコードは、例えば、図中
Ｂに示すように、ディスク３１０内のＬＢＡ０以降のブ
ロックに格納される。ホスト２００が固定長インターフ
ェース３３０を介してＬＢＡ０のブロック６１０を指定
する場合は、ＣＣＨＨＲ＝（０，０，１）のＲ１の先頭
を指定する。

【００２５】ＣＫＤ形式における１つのレコードの大き
さがディスク３１０内の１ブロックの大きさを越える場
合、そのレコードは、連続する複数のブロックに分けて
格納される。例えば、図において、レコード“Ｒ１”
は、２つのブロックＬＢＡ１とＬＢＡ２（ブロック６１
０、６２０）に格納されており、続くレコード“Ｒ２”
は、後続のブロックであるＬＢＡ２（ブロック６３０）
に格納されている。レコードの長さは固定長ブロックの
長さと必ずしも一致しない。このため、レコードの終端
からブロックの終端までの領域は空白とし値０で埋めら
れる。

【００２６】本実施形態では、トラックの大きさはブロ
ックの整数倍とする。トラック内レコードの終端がトラ
ックの終端に一致しない場合には、レコードの終端から
トラックの終端まで０で埋められ、全トラックが同じ数
のブロックを持つ。このとき、ＣＣＨＨＲ＝（ｃ，ｈ，
１）で指定されるレコードの先頭を示すＬＢＡは、ＬＢＡ＝（ｃ×ｎｈ＋ｈ）×（ｎｂ） … （数１）で算出できる。ここで、ｎｈは、１シリンダ内のヘッド
数、ｎｂは、１トラック内のブロック数である。

【００２７】図３に、ホスト１００がディスクサブシス
テム３００に対してＣＫＤインタフェース１１０とＣＫ
Ｄインタフェース３２０を介して作成したＣＫＤ形式で
のファイル（データセット）とデータセット管理情報を
示す。

【００２８】ディスクサブシステム３００上の特定位置
にはボリュームラベル７１０が格納される。ボリューム
ラベル７１０には、ＶＴＯＣ（Volume Table Of Conten
ts）７２０の位置が保持されている。ＶＴＯＣ７２０に
は、ディスク３１０に格納されているデータセットの管
理情報が記録されている。ＶＴＯＣ７２０は、例えば、
Ｋ部４４バイト、Ｄ部９６バイトのレコードの集まりに
なっている。Ｋ部にはデータセット名が格納され、Ｄ部
にはデータセットの位置情報が格納される。データセッ
トは、エクステントと呼ばれる、複数のトラックからな
る連続領域に格納される。１つのデータセットが、不連
続である複数のエクステントに格納される場合もありう
る。

【００２９】ホスト１００上のアプリケーションプログ
ラム１４０が、ＣＫＤインタフェース１１０とＣＫＤイ
ンタフェース３２０を介してディスクサブシステム３０
０上のデータセットにリードライトする際には、以下の
手順で処理が行われる。

【００３０】アプリケーションプログラム１４０は、対
象となるデータセットを指定してデータセットのオープ
ンをオペレーティングシステム１３０に要求する。オペ
レーティングシステム１３０は、ＶＴＯＣ７２０内のレ
コードを検索して、データセットの格納位置を得る。取
得したデータセットの格納位置から、オペレーションシ
ステム１３０は、対象となるレコードの相対トラックと
レコード番号を求め、対象レコードへのシーク処理を行
う。相対トラックとは、データセットのエクステントの
先頭を０とした相対的なトラック番号である。

【００３１】次にリードを行う場合、アプリケーション
プログラム１４０は、オペレーティングシステム１３０
のリード処理を呼び出す。リード処理においてオペレー
ティングシステム１３０は、レコードのＤ部をホスト１
００上に読み出す。またライトを行う場合、アプリケー
ションプログラム１４０は、オペレーティングシステム
１３０のライト処理を呼び出す。ライト処理においてオ
ペレーティングシステム１３０は、アプリケーションプ
ログラム１４０が用意したデータをレコードのＤ部とし
て書き出す。

【００３２】ホスト２００上のバックアッププログラム
２６０が固定長インタフェース２１０と固定長インタフ
ェース３３０を介してディスクサブシステム３００上の
データセットにリードライトする際の手順は、以下の通
りである。

【００３３】バックアッププログラム２６０は、ファイ
ルアクセスプログラム２４０にデータセットのオープ
ン、リード、ライト、クローズ、ＶＴＯＣリード、およ
びＶＴＯＣライトの各処理を要求する。ファイルアクセ
スプログラム２４０は、バックアッププログラム２６０
からの要求をレコードとレコードの集合であるトラック
およびデータセットといった単位に従って処理する。ホ
スト２００上のオペレーティングシステム２３０は、Ｃ
ＫＤ形式のデータセットをリードライトする機能を持っ
ていない。このため、本実施形態では、形式変換プログ
ラム２５０がファイルアクセスプログラム２４０とオペ
レーティングシステム２３０の間に介在して、ＣＫＤ形
式と固定長ブロック形式の変換を行い、ファイルアクセ
スプログラム２５０に以下に示すオープン、シーク（位
置付け）、リード、ライト、クローズ、ＶＴＯＣリー
ド、およびＶＴＯＣライトの各処理を提供する。ファイ
ルアクセスプログラム２４０は、バックアッププログラ
ム２６０からの要求に従って形式変換プログラム２５０
にオープン、リード、ライト、クローズ、ＶＴＯＣリー
ド、およびＶＴＯＣライトの各処理を要求する。形式変
換プログラム２５０によるシーク処理は、リードおよび
ライトの処理に付随して必要に応じて行われる。

【００３４】まず、オープン処理について説明する。図
４は、ファイルアクセスプログラム２４０によるディス
クサブシステム３００上のデータセットのオープン要求
に応答して、形式変換プログラム２５０により実施され
る処理のフローチャートである。

【００３５】形式変換プログラム２５０は、１トラック
分の内部バッファを持つ。形式変換プログラム２５０
は、ディスクサブシステム３００に格納されているボリ
ュームラベル７１０を、以下に示すように１トラックご
と内部バッファに読み込み、ボリュームラベル７１０を
得る。ここで、形式変換プログラム２５０には、ディス
クサブシステム３００上でのボリュームラベル７１０の
格納位置（ＣＣＨＨＲ）があらかじめ与えられているも
のとする。

【００３６】例えば、ボリュームラベル７１０の格納位
置がＣＣＨＨＲ＝（０，０，３）である場合、形式変換
プログラム２５０は、その位置を探すため具体的に以下
の処理を行う。まず形式変換プログラム２５０は、ＣＣ
ＨＨ＝（０，０）に相当するＬＢＡすなわちＬＢＡ０を
数１から算出し（ステップ１０１０）、ＬＢＡ０から１
トラック分のブロックを内部バッファに読み込む（ステ
ップ１０２０）。図２で説明したように、形式変換プロ
グラム２５０は、読み込んだブロックの先頭にある“レ
コード１”のＣ部を参照して“レコード１”のＫ部およ
びＤ部の大きさを求め、“レコード２”の格納されてい
るＬＢＡを求める（ステップ１０３０）。さらに“レコ
ード２”のＣ部を参照して“レコード３”の格納されて
いるＬＢＡを求め、ボリュームラベル７１０の存在する
レコード３のＤ部を得る（ステップ１０４０）。

【００３７】形式変換プログラム２５０は、“レコード
３”のＤ部に格納されたボリュームラベル７１０からＶ
ＴＯＣ７２０の格納位置を獲得し（ステップ１０５
０）、この格納位置に相当するＬＢＡを数１から算出す
る（ステップ１０６０）。形式変換プログラム２５０
は、得られたＬＢＡから１トラック分のブロックを読み
込み、ＶＴＯＣ７２０を取得する（ステップ１０７
０）。

【００３８】次に、形式変換プログラム２５０は、カウ
ンタｒを用意し、ＶＴＯＣ７２０内にあるデータセット
名を検索する。具体的には、形式変換プログラム２５０
は、カウンタｒの初期値を１とし（ステップ１０８
０）、読み込んだトラック内のレコードｒのＫ部を調
べ、処理の対象となるデータセットの名前と一致するか
判定する（ステップ１０９０）。処理の対象となるデー
タセットの名前を保持するＫ部を持つレコードが見つか
った場合、形式変換プログラム２５０は、このレコード
のＤ部からデータセットの格納位置を得て内部変数に記
憶しておく（ステップ１１４０）。形式変換プログラム
２５０は、次にリードライトする相対トラックとレコー
ド番号を記憶するための内部ポインタを持つ。形式変換
プログラム２５０は、この内部ポインタに相対トラック
０の“レコード１”を指す値を設定してオープン処理を
終了する（ステップ１１５０）。

【００３９】ステップ１０９０の判定において該当する
レコードが見つからない場合、形式変換プログラム２５
０は、読み出したトラックの終端まで調べたか否かを判
定する（ステップ１１００）。終端まで調べていないと
きは、カウンタｒを１増加し（ステップ１１３０）、ス
テップ１０９０に戻って次のレコードにある次のＶＴＯ
Ｃが検索される。読み出したトラックの終端まで調べて
も該当するレコードが見つからない場合、形式変換プロ
グラム２５０は、後続のトラックをディスク３１０から
読み出し（ステップ１１１０）、カウンタｒを１に初期
化してステップ１０９０に戻り、後続のトラック内の
“レコード１”から検索を続ける（ステップ１１２
０）。

【００４０】次に、形式変換プログラム２５０によるシ
ーク処理について説明する。形式変換プログラム２５０
の内部ポインタは、前述のようにデータセットのオープ
ン直後は相対トラック０の“レコード１”を示してい
る。ファイルアクセスプログラム２４０は、形式変換プ
ログラム２５０に対して、対象の相対トラックを指定し
て処理を要求する。形式変換プログラム２５０は、相対
トラックからＣＣＨＨを算出し、さらにＬＢＡを求め
て、データセット内のレコード位置に内部ポインタを移
動する。相対トラックは、データセットにおける先頭ト
ラックからの相対的な位置を示す。データセットに関す
るエクステントが全て連続領域ならば、先頭トラックの
ＣＣＨＨを（ｃ１，ｈ１）とすると、ＣＣＨＨ＝（ｃ，
ｈ）の相対トラックＴＴはＴＴ＝（ｃ−ｃ１）×（ｎｔ）＋ｈ−ｈ１ … （数２）となる。ここで、ｎｔは、１シリンダ内のトラックの数
を示す。逆にＴＴからＣＣＨＨを求めることもできる。
本実施形態では、簡単のためエクステントは全て連続領
域であるとするが、エクステントが全て連続領域ではな
くても、ＴＴとＣＣＨＨの対応関係を求めて相互に算出
することは可能である。

【００４１】図５は、リード処理のフローチャートであ
る。形式変換プログラム２５０の内部ポインタ（バッフ
ァポインタ）には、前述のシーク処理によって処理対象
となるデータセットの相対トラック、レコード番号、及
び内部バッファにおけるリードライト位置が保持され
る。ファイルアクセスプログラム２４０からのリード処
理要求を受けた形式変換プログラム２５０は、内部ポイ
ンタにより指定されるトラックが既に内部バッファに読
み込まれているか調べる（ステップ２０１０）。指定さ
れるトラックが読み込まれていない場合には、内部ポイ
ンタにより示される相対トラックからＣＣＨＨが計算さ
れ、この値からＬＢＡが算出される（ステップ２０２
０）。形式変換プログラム２５０は、算出したＬＢＡか
ら１トラック分のブロックを内部バッファに読み込む
（ステップ２０３０）。ステップ２０１０において既に
トラックが読み込まれている場合、ステップ２０２０、
２０３０の処理は行われない。

【００４２】次に形式変換プログラム２５０は、内部バ
ッファに読み込んだレコードからＤ部のみをファイルア
クセスプログラム２４０に渡し（ステップ２０４０）、
トラック内の最終レコードまでリード処理を行ったか否
か判定する（ステップ２０５０）。トラック内の最終レ
コードまで読んでいなかったら、内部ポインタを次のレ
コードに移して処理を終了する（ステップ２０７０）。
次レコードの先頭は、現在のレコードのＣ部を参照して
求められる。トラック内の最終レコードまでリード処理
が行われている場合は、内部ポインタを次のトラックの
レコード番号１のレコードに移動して処理を終了する
（ステップ２０６０）。

【００４３】図６は、ライト処理のフローチャートであ
る。ライト処理において、形式変換プログラム２５０
は、内部バッファに１トラック分のＣＫＤ形式の内容を
作成し、ディスクサブシステム３００に１トラック単位
で書き出す。

【００４４】ライト処理要求に伴いファイルアクセスプ
ログラム２４０は、形式変換プログラム２５０にライト
データおよびライトデータ長を渡す。形式変換プログラ
ム２５０は、ライトデータおよびライトデータ長、前述
のシーク処理によって保持している処理対象相対トラッ
クおよびレコード番号、及びＶＴＯＣから得ているレコ
ード長から、レコードのＣ部を作成できる。

【００４５】ライト処理において形式変換プログラム２
５０は、Ｃ部の情報としてＣＣＨＨＲを算出する（ステ
ップ３０１０）。このＣＣＨＨＲとレコード長からＣ部
を作成して内部バッファに書き込み（ステップ３０２
０）、ライトデータをレコードのＤ部として続いて書き
込む（ステップ３０３０）。次のレコードは次のブロッ
クの先頭から始まるため、書き込んだデータがブロック
の終端まで達していない場合には次のブロックの先頭ま
で０を書き込む（ステップ３０４０）。

【００４６】ステップ３０５０では、現在のトラックに
次のレコードが書けるか判定する。

【００４７】本実施形態では、使用するデータセットは
固定長レコードであるため、レコード長などの情報から
ステップ３０５０の判定が可能である。ステップ３０５
０において次レコードが書けると判断した場合、内部ポ
インタを次レコードの先頭位置に移し、ライト処理を終
了する（ステップ３０６０）。書けない場合には、内部
バッファの現在の書き込み位置から現在のトラックの終
端まで０を書きこみ（ステップ３０７０）、内部バッフ
ァの内容を１トラック分の内容としてディスクサブシス
テム３００に書き出す（ステップ３０８０）。そして、
内部ポインタを次トラックのレコード番号１のレコード
に移して、ライト処理を終了する（ステップ３０９
０）。

【００４８】次に、形式変換プログラム２５０により行
われるＶＴＯＣリードおよびＶＴＯＣライトの処理につ
いて説明する。

【００４９】図７に、ＶＴＯＣリードおよびＶＴＯＣラ
イト処理のフローチャートを示す。

【００５０】ファイルアクセスプログラム２４０からＶ
ＴＯＣリード、またはＶＴＯＣライトの要求を受けた形
式変換プログラム２５０は、データセットのオープン処
理におけるステップ１０１０からステップ１１３０と同
様の処理を行い、与えられた処理対象データセット名か
ら、ＶＴＯＣのデータセットに関するレコードの内部バ
ッファでの位置およびディスクサブシステム３００での
格納位置（ＬＢＡ）を取得し検索して、レコードを内部
バッファに得る（ステップ４０１０から４１３０）。こ
こではオープン処理と同様に、格納位置がＣＣＨＨＲ＝
（０，０，３）で与えられているとする。

【００５１】上記の処理の後、行う処理がＶＴＯＣリー
ドかＶＴＯＣライトかを判定する（ステップ４１４
０）。ファイルアクセスプログラム２４０からのＶＴＯ
Ｃリードの要求に対して、形式変換プログラム２５０
は、内部バッファ内のレコードの内容をファイルアクセ
スプログラム２４０に渡して、ＶＴＯＣリード処理を終
了する（ステップ４１５０）。

【００５２】ファイルアクセスプログラム２４０からの
ＶＴＯＣライトの要求に対して、形式変換プログラム２
５０は、ＶＴＯＣを示す形式のレコード内容をファイル
アクセスプログラム２４０から受け取り、内部バッファ
上にレコードを含むトラックの内容を作成する（ステッ
プ４１６０）。そして、内部バッファの内容を１トラッ
ク分の内容としてディスクサブシステム３００に書き戻
し、ＶＴＯＣライト処理を終了する（ステップ４１７
０）。なお、ＶＴＯＣについて、書き戻しの前と後で構
成に変化はなく、ＶＴＯＣの大きさも変わらないとす
る。

【００５３】以上説明した形式変換プログラム２５０お
よびファイルアクセスプログラム２４０のＶＴＯＣリー
ドおよびＶＴＯＣライトの処理により、バックアッププ
ログラム２６０は、ＶＴＯＣリードをファイルアクセス
プログラム２４０に要求してＶＴＯＣ内容を得ることが
できる。また、ＶＴＯＣを格納している形式のレコード
内容をファイルアクセスプログラム２４０に渡してＶＴ
ＯＣライトを要求することにより、ＶＴＯＣを書き換え
ることができる。

【００５４】クローズ処理では、ファイルアクセスプロ
グラム２４０からのクローズ処理要求に応じて、形式変
換プログラム２５０が、シーク処理で設定した処理対象
データセットについての内部変数などを解放する。

【００５５】図８は、ホスト２００上のバックアッププ
ログラム２６０が行うバックアップ処理のフローチャー
トである。バックアップ処理の対象は、ホスト１００が
ＣＫＤインターフェース３２０を介して使用するディス
クサブシステム３００上のデータセットである。

【００５６】バックアッププログラム２６０はまず、ユ
ーザから設定されたデータセット名など対象データセッ
トを特定できる情報を、ネットワーク４００を介してホ
スト１００上のバックアップエージェントプログラム１
５０に渡す（ステップ５０１０）。バックアップエージ
ェントプログラム１５０は、この情報に基づき当該デー
タセットの状態をホスト１００上のオペレーティングシ
ステム１３０に確認する（ステップ５０２０）。例え
ば、確認によりデータセットが使用中である（オープン
されている）などの状態を取得できる。バックアップエ
ージェントプログラム１５０は、取得した状態をネット
ワーク４００を介してバックアッププログラム２６０に
渡す（ステップ５０３０）。バックアッププログラム２
６０は、受け取った状態に基づいて、データセットに対
するバックアップを行う／行わない／延期する等の制
御、判定、スケジューリングを行うことができる。ここ
では、が、本実施形態では、バックアッププログラム２
６０は、バックアップ処理を続行するものとする。

【００５７】バックアッププログラム２６０は、ファイ
ルアクセスプログラム２４０に対しデータセットのオー
プンを要求する（ステップ５０４０）。ファイルアクセ
スプログラム２４０および形式変換プログラム２５０
は、この要求に応答してオープン処理を行う（ステップ
５０５０）。バックアッププログラム２６０は、ファイ
ルアクセスプログラム２４０に対しデータセットに関す
るＶＴＯＣリードを要求し（ステップ５０６０）、ファ
イルアクセスプログラム２４０および形式変換プログラ
ム２５０によるＶＴＯＣリード処理の結果としてＶＴＯ
Ｃのレコードを得る（ステップ５０７０）。バックアッ
ププログラム２６０は、このＶＴＯＣのレコードをホス
ト２００に接続するテープデバイス２９０に保存する
（ステップ５０８０）。保存の際にバックアッププログ
ラム２６０は、バックアップ取得日時などの情報を付加
することもありうる。

【００５８】さらにバックアッププログラム２６０は、
ファイルアクセスプログラム２４０に対しデータセット
のリードを要求し（ステップ５０９０）、ファイルアク
セスプログラム２４０および形式変換プログラム２５０
によるシーク処理およびリード処理の結果としてデータ
セットの内容を得る（ステップ５１００）。バックアッ
ププログラム２６０は、データセットの内容をテープデ
バイス２９０に保存する（ステップ５１１０）。保存の
際にバックアッププログラム２６０は、バックアップ取
得日時などの情報を付加することもありうる。

【００５９】なおＶＴＯＣを後述のように管理情報とし
て利用することなく単にデータセットの内容を取得して
保存することのみを処理の目的とするときは、ステップ
５０６０、５０７０、５０８０は行わなくてもよい。

【００６０】次に、ホスト２００上のバックアッププロ
グラム２６０が行うリストア処理（バックアップデータ
によるデータ回復処理）について説明する。

【００６１】リストア処理の対象は、ホスト１００がＣ
ＫＤインターフェース３２０を介して使用するディスク
サブシステム３００上のデータセットであって、バック
アップ処理によりテープデバイス２９０に既にバックア
ップが取得されているデータセットである。リストア処
理による回復先の１つの例として、ディスクサブシステ
ム３００でのバックアップを取得したデータセットにそ
のまま回復することが考えられる。

【００６２】図９に、ディスクサブシステム３００のデ
ータセットにそのまま回復する場合のリストア処理のフ
ローチャートを示す。

【００６３】バックアッププログラム２６０は、ユーザ
から設定されたデータセット名などの対象データセット
を特定できる情報を、ネットワーク４００を介してホス
ト１００上のバックアップエージェントプログラム１５
０に渡す（ステップ６０１０）。バックアップエージェ
ントプログラム１５０は、受け取った情報に基づき、ホ
スト１００上の他のプロセスがデータセットをアクセス
しないようにオペレーティングシステム１３０を使用し
てロックする（ステップ６０２０）。バックアップエー
ジェントプログラム１５０は、ネットワーク４００を介
してロックの完了をバックアッププログラム２６０に通
知する（ステップ６０３０）。

【００６４】次に、バックアッププログラム２６０は、
ファイルアクセスプログラム２４０に対しデータセット
のオープンを要求する（ステップ６０４０）。ファイル
アクセスプログラム２４０および形式変換プログラム２
５０は、この要求を受けてオープン処理を行う（ステッ
プ６０５０）。バックアッププログラム２６０は、バッ
クアップしてあったデータセットのＶＴＯＣのレコード
をテープデバイス２９０から読み出す（ステップ６０６
０）。バックアッププログラム２６０は、ファイルアク
セスプログラム２４０に対し読み出したＶＴＯＣ、すな
わちデータセットに関するＶＴＯＣのライト処理を要求
し（ステップ６０７０）、ファイルアクセスプログラム
２４０および形式変換プログラム２５０によるＶＴＯＣ
ライト処理の結果としてデータセットに関するディスク
サブシステム３００上のＶＴＯＣをテープデバイスから
読み出したＶＴＯＣのレコードで変更する（ステップ６
０８０）。

【００６５】さらにバックアッププログラム２６０は、
バックアップしてあったデータセットの内容をテープデ
バイス２９０から読み出す（ステップ６０９０）。バッ
クアッププログラム２６０は、ファイルアクセスプログ
ラム２４０に対し、データセットへの読み出した内容の
ライトを要求し（ステップ６１００）、ファイルアクセ
スプログラム２４０および形式変換プログラム２５０に
よるシーク処理およびライト処理の結果として、ディス
ク上のデータセットの格納位置に内容を書き戻す（ステ
ップ６１１０）。

【００６６】その後、バックアッププログラム２６０
は、ネットワーク４００を介してバックアップエージェ
ントプログラム１５０にロックの解除を許可する（ステ
ップ６１２０）。バックアップエージェントプログラム
１５０は、これを受けてロックの解除を行う（ステップ
６１３０）。上記の処理によりデータセットのリストア
処理が行える。

【００６７】リストア処理による回復先の他の例とし
て、バックアップ時とリストア時でディスクサブシステ
ム３００内でのデータセットの配置や構成が変化してい
る場合などに、バックアップを取得したデータセットと
は別のデータセットを用意してそのデータセットに内容
を回復するようにしてもよい。この場合のリストア処理
のフローチャートを図１０に示す。

【００６８】まずバックアッププログラム２６０は、ユ
ーザから設定された対象データセットについて、バック
アップしてあったデータセットのＶＴＯＣのレコードを
テープデバイス２９０から読み出して、レコード長など
のデータセットの構成情報を取得する（ステップ７０１
０）。バックアッププログラム２６０は、ネットワーク
４００を介して取得した構成情報をホスト１００上のバ
ックアップエージェントプログラム１５０に渡す（ステ
ップ７０２０）。バックアップエージェントプログラム
１５０は、構成情報に基づき、ホスト１００上のオペレ
ーティングシステム１３０を使用してディスクサブシス
テム３００上に適当な他のデータセットを用意する（ス
テップ７０３０）。バックアップエージェントプログラ
ム１５０は、ネットワーク４００を介してデータセット
名など他のデータセットを特定できる情報をバックアッ
ププログラム２６０に渡す（ステップ７０４０）。

【００６９】次に、バックアッププログラム２６０は、
ファイルアクセスプログラム２４０に対し他のデータセ
ットのオープンを要求する（ステップ７０５０）。ファ
イルアクセスプログラム２４０および形式変換プログラ
ム２５０は、この要求に応じてオープン処理を行う（ス
テップ７０６０）。バックアッププログラム２６０は、
バックアップしてあったデータセットの内容をテープデ
バイス２９０から読み出す（ステップ７０７０）。バッ
クアッププログラム２６０は、ファイルアクセスプログ
ラム２４０に対し他のデータセットへの読み出した内容
のライト処理を要求し（ステップ７０８０）、ファイル
アクセスプログラム２４０および形式変換プログラム２
５０によるシーク処理およびライト処理の結果として他
のデータセットの格納位置に内容を書き戻す（ステップ
７０９０）。

【００７０】上記の処理により、他のデータセットへの
リストア処理が行える。ユーザは、バックアッププログ
ラム２６０やバックアップエージェントプログラム１５
０から、他のデータセットのデータセット名などを知る
ことができる。

【００７１】上述した実施形態では、バックアッププロ
グラム２６０とファイルアクセスプログラム２４０を別
個のプログラムとして説明したが、バックアッププログ
ラム２６０とファイルアクセスプログラム２４０を合わ
せて、両者の処理を形式変換プログラム２５０を使用し
て行う１つのプログラムとして実現してもよい。

【００７２】上記のように処理することによって、ホス
ト１００がＣＫＤインターフェース３２０を介して使用
するディスクサブシステム３００上のデータセットのバ
ックアップ処理およびリストア処理を、ホスト２００が
テープデバイス２９０を用いて行う際に、高速に行うこ
とができ、バックアップ処理およびリストア処理に要す
る時間を削減することができる。また、ホスト１００が
バックアップ処理、あるいは、リスト処理におけるデー
タの転送処理を行わないで済むため、ホスト１００の処
理負荷を削減することができる。さらに、ホスト１００
とホスト２００との間でネットワークを介したデータ転
送が発生しないので、ネットワークの転送帯域負荷の増
大を抑止することができる。さらにまた、ホスト１００
がディスクサブシステム３００上に作成した管理情報
を、バックアップ処理における管理情報として利用し
て、バックアップ処理およびリストア処理を簡易に効率
的に行うことができる。

【００７３】図１１は、本発明の第２の実施形態に係る
計算機システムの構成図である。本実施形態が上述した
第１の実施形態と異なる点は、ディスクサブシステム３
００に、ＣＫＤインターフェース変換手段３４０がな
く、固定長インタフェース変換手段３５０がある点であ
る。本実施形態において、ディスク３１０は物理的にＣ
ＫＤ形式に従い、ホスト２００が固定長インタフェース
２１０および固定長インタフェース３３０を介してディ
スク３１０のデータをリードライトする場合には、固定
長インタフェース変換手段３５０が、ＣＫＤ形式と固定
長ブロック形式との間の変換を行う。

【００７４】固定長インタフェース変換手段３５０によ
り変換されるＣＫＤ形式と固定長ブロック形式の対応
は、第一の実施形態において図２で説明したものと等し
い。本実施形態では、図２に示すＡがディスク３１０に
おけるＣＫＤ形式の実際のデータ配置であり、図２のＢ
は、固定長インタフェース変換手段３５０により変換さ
れ、固定長インターフェース２１０と固定長インタフェ
ース３３０の間の転送に使われる固定長ブロック形式で
のデータ配置となる。固定長インタフェース変換手段３
５０は、第１の実施形態における場合と同様にして、Ｃ
ＫＤ形式と固定長ブロック形式との間の変換を行う。

【００７５】ホスト１００およびホスト２００は、本実
施形態においても、ディスクサブシステム３００に格納
されたデータセットに対し、第一の実施形態において説
明した処理と同じ処理を行うことができる。ホスト１０
０上のオペレーティングシステム１３０とバックアップ
エージェントプログラム１５０、及び、ホスト２００上
のオペレーティングシステム２３０、ファイルアクセス
プログラム２４０、形式変換プログラム２５０、並びに
バックアッププログラム２６０は、第一の実施形態で説
明した各処理と同じ処理を行い、データセットに対する
バックアップ処理とリストア処理を実現する。これらの
プログラムによる具体的な処理の内容については、第１
の実施形態と変わるところはなく説明を省略する。

【００７６】以上説明した第２の実施形態によっても第
１の実施形態と同様の効果を得ることができる。

【００７７】次に、本発明の第３の実施形態について説
明する。本実施形態における計算機システムの構成は、
図１で示した第１の実施形態での構成と同様である。本
実施形態では、第１の実施形態において図８により説明
したバックアップ処理が、第１の実施形態とは異なる。

【００７８】図１２は、本実施形態においてホスト２０
０上のバックアッププログラム２６０が行うバックアッ
プ処理のフローチャートである。バックアップ処理の対
象は、ホスト１００がＣＫＤインターフェース３２０を
介して使用するディスクサブシステム３００上のデータ
セットである。

【００７９】ホスト２００上のバックアッププログラム
２６０は、ユーザから設定されたデータセット名などの
対象データセットを特定できる情報を、ネットワーク４
００を介してホスト１００上のバックアップエージェン
トプログラム１５０に渡す（ステップ８０１０）。バッ
クアップエージェントプログラム１５０は、この情報に
基づき当該データセットの状態をホスト１００上のオペ
レーティングシステム１３０に確認する（ステップ８０
２０）。この確認によりデータセットが使用中である
（オープンされている）かどうかといった状態を取得で
きる。

【００８０】バックアップエージェントプログラム１５
０は、取得した状態をネットワークインタフェース１２
０を介してバックアッププログラム２６０に渡す（ステ
ップ８０３０）。バックアッププログラム２６０は、受
け取った状態に基づいて、データセットに対するバック
アップを行う／行わない／延期する、等の制御や判定、
あるいは、スケジューリングを行うことができる。ここ
ではバックアップ処理を続行するものとする。

【００８１】バックアッププログラム２６０は、ファイ
ルアクセスプログラム２４０に対しデータセットのオー
プンを要求する（ステップ８０４０）。ファイルアクセ
スプログラム２４０および形式変換プログラム２５０
は、この要求に応答してオープン処理を行う（ステップ
８０５０）。バックアッププログラム２６０は、ファイ
ルアクセスプログラム２４０に対しデータセットに関す
るＶＴＯＣリードを要求し（ステップ８０６０）、ファ
イルアクセスプログラム２４０および形式変換プログラ
ム２５０によるＶＴＯＣリード処理の結果としてＶＴＯ
Ｃのレコードを得る（ステップ８０７０）。

【００８２】バックアッププログラム２６０は、ＶＴＯ
Ｃのレコードに記録されているデータセットの最終参照
日付を、あらかじめユーザから設定された日付と比較し
（ステップ８０８０）、その前後関係を判別する（ステ
ップ８０９０）。最終参照日付が設定日付より前の日付
であれば、バックアッププログラム２６０は、データセ
ットに対するバックアップ処理を中止する（ステップ８
１００）。ステップ８０９０において最終参照日付が前
記設定日付より後かまたは等しい場合、バックアッププ
ログラム２６０は、データセットに対するバックアップ
処理を続行する。

【００８３】バックアップ処理を続行する場合、バック
アッププログラム２６０は、ＶＴＯＣのレコードをホス
ト２００に接続するテープデバイス２９０に保存する
（ステップ８１１０）。保存の際にバックアップ取得日
時などの情報が付加されてもよい。さらにバックアップ
プログラム２６０は、ファイルアクセスプログラム２４
０に対しデータセットのリードを要求し（ステップ８１
２０）、ファイルアクセスプログラム２４０および形式
変換プログラム２５０によるシーク処理およびリード処
理の結果としてデータセットの内容を得る（ステップ８
１３０）。バックアッププログラム２６０は、データセ
ットの内容をテープデバイス２９０に保存する（ステッ
プ８１４０）。保存の際にバックアップ取得日時などの
情報が付加されてもよい。

【００８４】本実施形態におけるバックアップ処理以外
の処理は、上述した第１の実施形態と同様に行われる。

【００８５】本実施形態で説明したバックアップ処理に
おいて、最終参照日付の他に、作成日付などのＶＴＯＣ
に格納されている情報を用いて、バックアップ処理の制
御を行うようにしてもよい。設定日付は、ユーザが指定
する代わりに、前回のバックアップ処理時にバックアッ
ププログラム２６０が記録しておいた前回のバックアッ
プ処理の日付を使用しても良い。また、ここで説明した
バックアップ処理は、上述した第２の実施形態の構成に
対しても、同様にして適用することができる。

【００８６】本実施形態においても、第１及び第２の実
施形態と同様の効果を得ることができる。

【００８７】図１３は、本発明の第４の実施形態おける
計算機システムの構成及びその概略動作を示す概要図で
ある。図において、１は、ワークステーション、あるい
はパーソナルコンピュータなどの、オープン系のコンピ
ュータにより構成されるオープンサーバである。

【００８８】オープンサーバ１は、上述した第１乃至第
３の実施形態におけるホスト２００に相当し、ＦＢＡ形
式のインタフェースに従ったディスク装置のアクセスを
行う。オープンサーバ１は、ファイバチャネル７により
スイッチ３に接続されている。スイッチ３は、送信パケ
ットのルーティングを行う装置である。オープンサーバ
１からディスクシステム４へのアクセスは、スイッチ３
を経由して行われる。また，スイッチ３を経由しない接
続方法も存在する。スイッチ３は、ファイバチャネル７
によりディスクシステム４に接続される。オープンサー
バ１は、従来のＳＣＳＩ上でのプロトコルをファイバチ
ャネル上で実装したＦＣＰと呼ばれるプロトコルによっ
てディスクシステム４にアクセスする。

【００８９】一方、２は、いわゆるメインフレームコン
ピュータ（以下、メインフレームと略す）である。メイ
ンフレーム２は、上述した第１乃至第３の実施形態にお
けるホスト１００に相当し、ＣＫＤ形式のインタフェー
スに従ったディスク装置のアクセスを行う。メインフレ
ーム２は、チャネルインタフェース６によってディスク
システム４に接続される。メインフレーム２とディスク
システム４の間には、例えば、ディレクタと呼ばれるル
ーティング装置を介在させてもよい。

【００９０】ディスク装置４は、ユーザのデータが格納
されるボリューム８を有する。ディスク装置４は、ＣＫ
Ｄインタフェース９とＦＢＡインタフェース１０を有
し、これらインタフェースを介して同一のボリューム８
へアクセスすることが可能である。

【００９１】オープンサーバ１は、ユーザからバックア
ップ指示に従い、あるいは、あらかじめ定められた時刻
に到達すると、メインフレーム１へネットワーク１４経
由で目的のデータセットをバックアップするよう指示す
る。このとき、オープンサーバ１は、バックアップ対象
となるデータセットの名称をメインフレーム１へ通知す
る（）。

【００９２】データセット位置検出プログラム１２は、
目的のデータセットがどのボリューム８のどのアドレス
に存在するかを検出し、この情報をデータセット位置情
報として、オープンシステム１へ通知する（）。な
お、本実施形態及び以降説明する実施形態では、データ
セット位置情報はメインフレーム２で取得し、オープン
サーバ１へ送信されものとするが、オープンサーバ１が
ボリューム８からカタログ情報やＶＴＯＣ情報を参照す
ることによりデータセット位置を把握するようにしても
よい。この場合、データセットや関連するカタログを格
納しているボリューム８については、あらかじめユーザ
が与えておいても良いし、メインフレーム２から教えて
もらってもよい。あるいは第１乃至第３の実施形態のよ
うに、オープンサーバ１で全ての共用ボリュームのＶＴ
ＯＣ情報を読出してデータセット位置情報を取得するこ
ともできる。

【００９３】オープンシステム１は、コピーコマンド作
成・発行プログラム１１により、メインフレーム２から
与えられたデータセット位置情報に基づいてコマンド
（ＣＣＯＰＹコマンドと呼ぶ）を作成し、スイッチ３に
対して発行する（、）。ＣＣＯＰＹコマンドには、
コピー元のボリューム番号とコピーアドレス、コピー先
のテープ番号などが格納されている。スイッチ３は、こ
れらの情報を元にボリューム８からデータを読出し、テ
ープ装置５へデータをバックアップする（）。以下に
このようなバックアップ処理について詳細について説明
する。

【００９４】図１４は、データセット位置情報の詳細を
示す説明図である。

【００９５】サブシステム数１６は、当該データセット
を格納する論理的なディスクシステムの個数を表す。近
年のディスクシステム４では、物理的に１台のディスク
システムを、論理的に複数個のディスクシステムとして
メインフレーム２あるいはオープンサーバ１に見せるこ
とがある。この論理的なディスクシステムをここではサ
ブシステムと呼ぶ。ディスクシステム製造番号１７は、
ディスクシステム４を一意に識別するための番号であ
る。サブシステムＩＤ１８は、当該ディスクシステム４
に付与されたＩＤである。ボリュームＩＤ１９は、バッ
クアップ対象のデータセットを格納したボリューム８の
ＩＤで、サブシステム毎に一意の番号である。

【００９６】エクステント数２０は、当該データセット
を格納している連続領域の個数を示す。エクステント数
２０で示された分だけ、エクステント開始ＣＣＨＨ２１
とエクステント終了ＣＣＨＨ２２のエントリが出現す
る。図では、3個のエクステント開始および終了ＣＣＨ
Ｈが示されている。データセットが複数のボリューム
８、サブシステム、およびディスクシステムに渡って格
納されていた場合、サブシステム数１６には２以上の値
が格納され、ディスクシステム製造番号１７からエクス
テント終了ＣＣＨＨ２２までのエントリが繰り返され
る。メインフレーム２は、データセット位置情報をこの
形式によってオープンサーバ１へ送信する。

【００９７】オープンサーバ１は、データセット位置情
報のボリュームＩＤ１９で示されたボリューム８がどの
デバイスファイルとして登録されているか調べる必要が
ある。オープンサーバ１では、プログラムはデバイスフ
ァイルを介してボリューム８にアクセスする。このため
に、オープンサーバ１は、各デバイスファイルに対して
Inquiryコマンドを発行する。

【００９８】Inquiryコマンドのリターン値を図１５に
示す。Inquiryコマンドのリターン値の一部は、ベンダ
が独自に定義することができ、図１５は本実施形態の実
現のために定義した部分のみを表している。ディスクシ
ステム製造番号２５およびサブシステムＩＤ２６は、In
quiryコマンドを処理したディスクシステム４の製造番
号およびサブシステムのＩＤを示す。ボリュームＩＤ２
７は、Inquiryコマンドを発行したデバイスファイル名
に対応するボリュームのＩＤである。エミュレーション
タイプ２８は、メインフレーム専用、共用、オープン専
用の３種類と、メインフレーム専用および共用の場合に
は、特定のディスクシステムのタイプが設定される。そ
れぞれのタイプによって、トラックフォーマットや容量
が異なる。ボリューム容量２９は、当該ボリューム８の
容量をＭＢ単位に表す。

【００９９】Inquiryコマンドはオープンサーバ１の全
てのデバイスファイルに対して発行されるために時間が
かかる。このため、Inquiryコマンドの発行は、システ
ムブート時に一度だけ行い、そのリターン値を保持して
おくのが良い。最近のＯＳでは、システムをブートせず
にボリュームを組込むことができるものがある。このよ
うなＯＳでは、ボリューム８を組込んだ際に、当該ボリ
ューム８に対してのみInquiryコマンドを実行し、その
リターン値を取得するのが良い。Inquiryコマンドのリ
ターン値とデータセット位置情報を比較することによっ
て、デバイスファイル名に対応したボリュームＩＤを見
つけ出すことができる。すなわち、それぞれのディスク
システム製造番号、サブシステムＩＤ、及びボリューム
ＩＤを比較する。これらがもし一致していたらInquiry
コマンドを発行したデバイスファイルが、データセット
位置情報で与えられたボリュームＩＤを有することが分
かる。

【０１００】このようにしてデバイスファイルを割り出
すと、オープンサーバ１は、次にデータセット位置が、
当該デバイスファイル上のどのアドレスになるかを求め
る。

【０１０１】デバイスファイル上のアドレスは、ＣＫＤ
形式におけるボリューム８の論理的な構成、すなわち、
ＣＫＤ形式におけるボリューム８のトラック長、シリン
ダあたりのトラック数、及び、ＦＢＡ形式でのブロック
サイズに基づいて（数１）により求めることができる。
ＣＫＤ形式におけるボリュームの論理的な構成は、エミ
ュレーションタイプによって異なり、Inquiryコマンド
で獲得したエミュレーションタイプ２８に基づいて認識
される。

【０１０２】これらの情報を元に、オープンシステム１
はコピーコマンドを作成する。図１６にコピーコマンド
のフォーマットの一例を示す。図に示すコピーコマンド
は、ボリューム８のアドレス０から０ｘ１０ブロック、
およびアドレス１００から０ｘ１０ブロックを一つのＣ
ＣＯＰＹコマンドによりテープ装置５へコピーする場合
を想定している。

【０１０３】オープンサーバ１は、CDB(Command Descri
ptor Block)に続いて、パラメータリストをスイッチ３
に対して送信する。パラメータリストは可変であり、そ
の長さはCDBのParameter List Length３２に格納され
る。

【０１０４】パラメータリストは、コピー元および先の
装置アドレスが格納されているTarget Descriptor List
３５およびコピーするデータが格納されている装置上の
アドレスに関する情報が格納されているSegment Descri
ptor List３６から構成される。これらのリストの長さ
は可変であり、その長さは、それぞれTarget Descripto
r Length３３およびSegment Descriptor Length３４に
格納される。

【０１０５】Target Descriptor List３５は、複数のTa
rget Descriptorから構成される。図では、コピー元で
あるディスク装置と、コピー先であるテープ装置のTarg
et Descriptorが示されている。一方、Segment Descrip
tor Listは、アドレス０から０ｘ１０ブロックをコピー
するパラメータと、アドレス１００から０ｘ１０ブロッ
クをコピーするパラメータの２つのSegment Descriptor
を有する。

【０１０６】オープンサーバ１が、上述したようなＣＣ
ＯＰＹコマンドをスイッチ３に対して発行すると、スイ
ッチ３は、このコマンドに従ってボリューム８からテー
プ５にデータをコピーする。

【０１０７】バックアップが完了すると、データセット
情報記録プログラム２３により、図１７に示すデータセ
ット情報がバックアップディレクトリ、すなわちバック
アップの管理ファイルに登録される（）。登録される
内容は、データセットを所有するメインフレーム２のホ
スト名称４０、データセットを格納するディスクシステ
ム製造番号４１、サブシステムＩＤ４２、ボリュームＩ
Ｄ４３であり、これらはデータセット位置情報に含まれ
る。さらにバックアップ日時４４、データセット名称４
５、データセットサイズ４６、データセットのエクステ
ント範囲（エクステント開始ＣＣＨＨ５５およびエクス
テント終了ＣＣＨＨ５６）などが登録される。図のよう
にデータセットを構成するエクステントが複数個あれ
ば、複数のエクステント範囲が記録される。

【０１０８】これらの情報は、一つのテーブルとして登
録しても構わないが、図１８に示すように、ホスト名４
０とデータセット名称４５をキーとしてディレクトリを
構成した方が管理は容易になる。この例では、バックア
ップディレクトリ“backDir”から、バックアップファ
イルを所有するホスト名をたどる。図では、“MFDB2MAI
N”が目的のデータセット“DB2SYS”を所有していて、
子ディレクトリとして登録されている。さらに“DB2SY
S”から当該データセットをバックアップした時刻をそ
の子ディレクトリ“1999.8,7.00:12”として登録されて
いる。例えば、同一のデータセットを周期的にバックア
ップしている場合、複数の子ディレクトリが存在するこ
とになる。そして、その子ディレクトリにバックアップ
の詳細情報を格納したファイルが格納される。

【０１０９】通常、ユーザはメインフレーム２の名称と
ファイル名を元にリカバリを行うケースが多い。さら
に、いつバックアップしたか、いつの時点へ回復可能か
を検討する。このような場合に、図１８に示したディレ
クトリ構造は有効である。さらに同様のしくみによりオ
ープンシステムのバックアップ情報も管理されるため、
管理が統合でき好都合である。

【０１１０】図１９は、本発明の第５の実施形態おける
計算機システムの構成及びその概略動作を示す概要図で
ある。本実施形態では、ディスクシステム４が有する公
知のボリューム二重化機能を使用してバックアップが実
行される。

【０１１１】オープンサーバ１からバックアップ要求が
発行されると、メインフレーム２は、バックアップを要
求されたデータセットの物理位置、すなわちデータセッ
ト格納ボリューム８やエクステントを得る。次に、ボリ
ューム二重化制御プログラム４９により、ボリューム８
が二重化状態となっているかどうかを調べる。二重化状
態であれば、ボリューム二重化制御プログラム４９は、
ディスクシステム４に対してペア分割要求を発行する
（′）。

【０１１２】ペア分割が成功すると、メインフレーム１
は、オープンサーバ２が副ボリューム８ｂからバックア
ップを行うよう、データセット位置情報を報告する。し
たがって、図１４に示したデータセット位置情報のう
ち、サブシステムＩＤ１８とボリュームＩＤ１９は副ボ
リューム８ｂのものが格納される。以降の処理は第四の
実施形態と同様であり、説明を省略する。

【０１１３】本実施例によれば、データベース（ＤＢ）
などのアプリケーションを静止化(quiesche)した後、副
ボリューム８ｂを凍結することによって、アプリケーシ
ョンから見て無矛盾な状態のバックアップが取得でき
る。また、ペアを分割するコマンドが完了するまでの間
静止化状態を保持すれば良いので、静止化状態が非常に
短時間である。さらに、バックアップを行うボリューム
８ｂとメインフレーム２がアクセスするボリューム８ａ
が異なるので、メインフレーム２での通常業務に対する
性能的な影響を少なくできる。

【０１１４】図２０は、本発明の第６の実施形態おける
計算機システムの構成及びその概略動作を示す概要図で
ある。本実施形態では、ボリューム二重化機能が異なる
ディスクシステム４ａおよび４ｂの間で実現され、ディ
スクシステム４ｂからバックアップが行われる。

【０１１５】ディスクシステム４ａと４ｂ間は、ファイ
バチャネル７で接続される。データは、ファイバチャネ
ル７を介してディスクシステム４ａのボリューム８ａか
らディスクシステム４ｂのボリューム８ｂへ転送され、
二重化状態が保持される。

【０１１６】本実施形態における基本的な処理は、第５
の実施形態と同様である。バックアップを行うとき、メ
インフレームホスト２のボリューム二重化制御４９は、
ディスクシステム４ａに対してペア分割指示を行い、こ
れにより二重化状態がサスペンドされる。その後、デー
タセット位置情報がオープンサーバ１へ送信される。図
１４に示したデータセット位置情報のうち、ディスクシ
ステム製造番号１７にはディスクシステム４ｂのものが
格納され、サブシステムＩＤ１８およびボリュームＩＤ
１９には、副ボリューム８ｂのものが格納される。以降
の処理は第４あるいは第５の実施形態と同様なので説明
を省略する。

【０１１７】本実施形態によれば、ディスクシステム４
ａとバックアップ４ｂを互いに遠隔地に設置することで
よりデータ保護性の高いバックアップシステムを提供す
ることができる。例えば地震などの広範囲にわたる災害
では、ディスクシステム４とバックアップ５の距離が近
いと、両方が損害を受けデータが消失する可能性があ
る。しかし本実施形態のように、遠隔地にバックアップ
装置５を設置することで、そのような危険を免れること
ができる。

【０１１８】図２１は、本発明の第７の実施形態であ
る、バックアップされたデータのリストア処理の概要図
である。リストア処理では、データセットが元の格納位
置にリストアされるとは限らない。データセットを構成
するレコードには、レコードの物理位置などを格納した
フィールドであるカウント部が存在するため、リストア
位置がバックアップした時の位置と異なる場合には、こ
れを書きかえる必要がある。本実施形態では、この処理
をオープンサーバ１が実行する。

【０１１９】オープンシステム１は、メインフレーム２
に対してリストア要求をネットワーク１４経由で発行す
る。リストア要求に付属するパラメータとして、データ
セット名、データセットサイズ、リストア先のディスク
システム製造番号、サブシステムＩＤ、ボリュームＩ
Ｄ、などが含まれる。データセット名、リストア先のデ
ィスクシステム製造番号、サブシステムＩＤ、ボリュー
ムＩＤは、ユーザから指定されるものとする。データセ
ットサイズは、バックアップ時に作成されたバックアッ
プディレクトリのファイルより取得する。

【０１２０】場合によってはリストアを行うメインフレ
ーム２がバックアップ時とは異なる場合がある。例え
ば、データセットを所有していたメインフレーム２がダ
ウンして復旧不可能な場合などである。したがって、リ
ストア要求がファイルを所有していたメインフレーム２
に発行されるとは限らない。

【０１２１】メインフレーム２は、続いて、データセッ
ト領域確保処理５０により、指定されたディスクシステ
ム２、サブシステムＩＤ、ボリュームＩＤで特定される
ボリューム８上に、データセット領域を確保する。そし
て、その物理位置情報、すなわちエクステント位置を得
る。メインフレーム２は、この物理位置情報をオープン
サーバ１へ報告する。エクステント位置は、図１４によ
り説明したように、エクステント開始ＣＣＨＨと終了Ｃ
ＣＨＨの組から構成される。

【０１２２】オープンサーバ１は、バックアップ装置製
造番号４７とバックアップメディア名称４８で特定され
るバックアップメディアからリストアするデータを読み
出す。そして、カウント部変更処理５１によりメインフ
レーム２から報告されたエクステント情報を元にカウン
ト部を更新する。その後、エクステント情報からブロッ
クアドレスを算出して、該当するブロックへリストアデ
ータを書きこむ。

【０１２３】図２２は、本発明の第８の実施形態による
他のリストア処理の概要図である。本実施形態は、図に
示すように、オープンサーバ１がバックアップ装置５か
らリストアデータを読出し、必要なデータ整形処理を施
した後、ネットワーク１４経由でリストアデータをメイ
ンフレーム２へ転送する。メインフレーム２では、指定
されたサイズのデータセット領域を確保した後、データ
を当該データセット領域へ格納する。

【０１２４】これまで説明した実施形態では、本来不要
なギャップやパディングデータも含めてデータセットが
バックアップされる。リストア処理では、これらのデー
タを含んだままリストアデータをメインフレーム２へ送
っても良いが、ネットワーク負荷が増大し、リストア時
間も増大する。

【０１２５】データ整形処理５３は、これら、不要なデ
ータを取り除く処理を実行する。オープンサーバ１は、
トラックフォーマットを知っているので、どこに何バイ
トのギャップが存在するか、レコード終端を検出してト
ラックの残り何バイトがパディングされているかといっ
たことが分かり、データ整形処理を行うことが可能であ
る。

【０１２６】本実施形態は、第７の実施例に比べると、
データをネットワーク経由でメインフレーム２へ転送し
ているため、ネットワーク負荷が増大し、リストア時間
がより大きくなるというデメリットがある。

【０１２７】図２３は、本発明の第９の実施形態におけ
る、さらに他のリストア処理の概要図である。第７、ま
たは第８の実施形態は、リストア対象ボリュームがバッ
クアップボリュームと異なる場合、オープンサーバ１が
テープ装置５からリストアデータを読出し、カウント部
を更新してリストアする。リストアボリュームがバック
アップボリュームと同一であれば、カウント部の更新は
必要ない。本実施形態では、この条件が成立する場合
に、オープンサーバ１を経由せずにバックアップする。

【０１２８】本実施形態において、オープンサーバ１
は、ダイレクトリストア可否判定処理５４を有する。こ
の処理は、メインフレーム１からリストア先のデータセ
ット位置を受領すると、バックアップディレクトリの内
容に基づいて、リストア先のボリュームおよびデータセ
ット位置が、バックアップを行ったボリュームおよびデ
ータセット位置と一致しているかどうかを判定する。も
し一致していたら、カウント部の変更は不要であると判
断し、制御をコピー処理１１へ渡して、ＣＣＯＰＹコマ
ンドによりテープ装置５からリストア先のボリューム８
へ直接リストアを行う。

【０１２９】リストアボリュームのエミュレーションタ
イプが、バックアップ時のものと異なっていた場合、リ
ストアはできない。そこで、第７乃至第９の実施形態に
おけるリストア処理では、オープンサーバ１がメインフ
レーム２からデータセット位置情報を受け取ると、リス
トアボリュームのエミュレーションタイプがバックアッ
プ時のものと一致しているかどうかをチェックする。こ
のために、オープンサーバ１は、Inquiryコマンドを使
用してデータセット位置情報に格納されたボリュームの
エミュレーションタイプを読出す。そして、バックアッ
プディレクトリに格納されたバックアップボリュームの
エミュレーションタイプ５７と比較し、一致しているか
どうか調べる。もし一致していなければ、オープンサー
バ１は、ユーザへエラーを報告してリストア処理を中止
する。

【０１３０】図２４は、本発明の第１０の実施形態であ
るデータベースのリカバリ処理の概要図である。データ
ベースシステムにおいて、データベースをリカバリする
場合は，必要に応じてデータベース本体とそのログがリ
ストアされる。ユーザは、リストアするバックアップデ
ータを選択することができ、選択した時点のデータが復
元される。ここからさらに最近の状態にデータベースを
回復するために、リストアデータにログを適用すること
ができる。

【０１３１】本実施形態では、まず第７乃至第９の実施
形態のいずれかにおけるリストア処理によりデータベー
ス本体およびログを回復する。その後、メインフレーム
２によって回復したデータベースにログを適用する。以
下の説明では、ボリューム８へのリストア処理が完了し
た状態から説明を行う。

【０１３２】オープンサーバ１は、ＤＢリカバリマネー
ジャ６１を有する。ＤＢリカバリマネージャ６１は、主
にユーザインタフェースを司る。すなわち、リカバリ候
補のデータセットの表示、リカバリ結果の表示、リカバ
リ対象ファイルおよびリカバリ時刻の入力などを実行す
る。

【０１３３】データベース管理システムは、データセッ
トをリカバリするためのＤＢリカバリプログラム６３を
提供する。ＤＢリカバリプログラム６３は、ログボリュ
ーム８ｅの中からリカバリ対象のデータセットを更新し
たトランザクションを探し出し、このログを使ってデー
タセットへの更新を反映し（ロールフォワード）、ある
いは元に戻す（ロールバック）処理を行う。ＤＢリカバ
リプログラム６３は、一般的にリカバリ対象データセッ
ト名と時刻を受け取り、リカバリを実行するためのＡＰ
Ｉを提供する。ＤＢリカバリエージェント６０は、この
ＡＰＩを使ってリカバリ処理を実行する。

【０１３４】これらの機構を利用して、ユーザからデー
タセット名、時刻とともにリカバリ要求が発行される
と、これら３つの処理プログラムが連携してリカバリ処
理が実行される。

【０１３５】以上の処理によって、メインフレーム２が
所有するデータベースのリカバリをオープンサーバ１側
から実行することができる。

【０１３６】以上説明した実施形態によれば、メインフ
レームおよびオープンシステムの区別なくバックアップ
ファイルの管理を一元化でき、バックアップ・リストア
に関するユーザのコストを低減することができる。

【０１３７】さらに、メインフレームのデータをオープ
ンサーバを介さずにテープ装置へコピーするでき、メイ
ンフレームならびにオープンサーバのＣＰＵ負荷を低減
するとともに、バックアップ・リストアにかかる時間を
短縮することができる。

【０１３８】

【発明の効果】本発明によれば、例えばＣＫＤ形式を用
いるメインフレームなどのコンピュータが使用するデー
タのバックアップを、固定長ブロック形式を用いるコン
ピュータに接続したテープ装置などに保存して取得する
際に、高速なバックアップ処理を実現してバックアップ
処理時間を削減できる。

【０１３９】また、ＣＫＤ形式を用いるメインフレーム
などのコンピュータが使用するデータのバックアップ
を、固定長ブロック形式を用いるコンピュータに接続し
たテープ装置などに保存して取得する際に、メインフレ
ームなどのコンピュータに発生する処理負荷を削減でき
る。

【０１４０】さらに、ＣＫＤ形式を用いるメインフレー
ムなどのコンピュータが使用するデータのバックアップ
を、固定長ブロック形式を用いるコンピュータに接続し
たテープ装置などに保存して取得する際に、メインフレ
ームなどのコンピュータがデータに対して作成した管理
情報を、固定長ブロック形式を用いるコンピュータが取
得し利用できるバックアップ処理およびリストア処理を
実現できる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態における計算機システ
ムの構成図である。

【図２】ＣＫＤ形式でのデータ構造と、ディスク上での
ディスクは一の関係を示す説明図である

【図３】ホストが作成したＣＫＤ形式でのデータセット
とデータセット管理情報を示す説明図である。

【図４】データセットのオープン要求に応答して、形式
変換プログラム２５０により実施される処理のフローチ
ャートである。

【図５】形式変換プログラム２５０によるデータセット
リード処理のフローチャートである。

【図６】形式変換プログラム２５０によるデータセット
ライト処理のフローチャートである。

【図７】形式変換プログラム２５０によるＶＴＯＣリー
ド処理およびＶＴＯＣライト処理のフローチャートであ
る。

【図８】バックアップ処理のフローチャートである。

【図９】本発明の第１の実施形態によるリストア処理の
一例のフローチャートである。

【図１０】本発明の第１の実施形態によるリストア処理
の他の例のフローチャートである。

【図１１】本発明の第２の実施形態における計算機シス
テムの構成図である。

【図１２】本発明の第３の実施形態によるバックアップ
処理のフローチャートである。

【図１３】本発明の第４の実施形態おける計算機システ
ムの構成及びその概略動作を示す概要図である。

【図１４】データセット位置情報の詳細を示す説明図で
ある。

【図１５】Inquiryコマンドのリターン値を示すフォー
マット図である。

【図１６】コピーコマンドのフォーマットの一例を示す
説明図である。

【図１７】データセット情報の構成を示すデータフォー
マット図である。

【図１８】データセット情報を格納する際のディレクト
リ構造の説明図である。

【図１９】第５の実施形態おける計算機システムの構成
及びその概略動作を示す概要図である。

【図２０】第６の実施形態おける計算機システムの構成
及びその概略動作を示す概要図である。

【図２１】第７の実施形態である、バックアップされた
データのリストア処理の概要図である。

【図２２】第８の実施形態におけるリストア処理の概要
図である。

【図２３】第９の実施形態におけるリストア処理の概要
図である。

【図２４】第１０の実施形態であるデータベースのリカ
バリ処理の概要図である。

【符号の説明】

１００…ホスト、１１０…ＣＫＤインタフェース、１２
０、２２０…ネットワークインタフェース、１３０、２
３０…オペレーティングシステム、１４０…アプリケー
ションプログラム、１５０…バックアップエージェント
プログラム、２００…ホスト、２１０、２１１…固定長
インタフェース、２４０…ファイルアクセスプログラ
ム、２５０…形式変換プログラム、２６０…バックアッ
ププログラム、２９０…テープデバイス、３００…ディ
スクサブシステム、３１０…ディスク、３２０…ＣＫＤ
インタフェース、３３０…固定長インタフェース、３４
０…ＣＫＤインタフェース変換手段、３５０…固定長イ
ンタフェース変換手段、４００…ネットワーク、７１０
…ボリュームラベル、７２０…ＶＴＯＣ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者本間繁雄神奈川県小田原市国府津2880番地株式会社日立製作所ストレージシステム事業部内 (72)発明者北村学神奈川県川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内

Claims

【特許請求の範囲】

【請求項１】互いに異なる第一のインターフェースおよ
び第二のインターフェースを有する記憶装置と、前記第
一のインターフェースによって前記記憶装置に接続する
第一の計算機および前記第二のインターフェースによっ
て前記記憶装置に接続する第二の計算機を備えた計算機
システムにおけるバックアップ取得方法であって、前記
第一の計算機が前記第一のインターフェースにより前記
記憶装置に格納したデータを、前記第二の計算機が前記
第二のインターフェースにより前記記憶装置から検出し
読み出して保存することによって、前記第一の計算機が
使用するデータのバックアップを取得することを特徴と
するバックアップ取得方法。
【請求項２】前記第一のインターフェースがカウントキ
ーデータ形式に従うインターフェースであり、前記第二
のインターフェースが固定長ブロック形式に従うインタ
ーフェースであることを特徴とする請求項１記載のバッ
クアップ取得方法。
【請求項３】前記第一の計算機が前記記憶装置に格納し
た前記データに関して前記第一の計算機が前記記憶装置
内に作成した管理情報を、前記第二の計算機が前記記憶
装置から検出し読み出して保存することを特徴とする請
求項１または２に記載のバックアップ取得方法。
【請求項４】前記第一の計算機が前記記憶装置に格納し
た前記データに関して前記第一の計算機が前記記憶装置
内に作成した管理情報を、前記第二の計算機が前記記憶
装置から検出して読み出し、前記バックアップ取得の処
理の制御に用いることを特徴とする請求項１から３の何
れかに記載のバックアップ取得方法。
【請求項５】前記第一の計算機が前記記憶装置に格納し
た前記データに関して前記第一の計算機が前記記憶装置
内に作成した管理情報を、前記第二の計算機が前記記憶
装置から検出して読み出し、前記管理情報に記録されて
いる前記データに関する日付情報に基づき、前記データ
のバックアップ取得の可否を決定することを特徴とする
請求項４記載のバックアップ取得方法。
【請求項６】互いに異なる第一のインターフェースおよ
び第二のインターフェースを有する記憶装置と、前記第
一のインターフェースによって前記記憶装置に接続する
第一の計算機および前記第二のインターフェースによっ
て前記記憶装置に接続する第二の計算機の少なくとも２
台の計算機を備えた計算機システムであって、前記第
二の計算機が、前記第一の計算機が前記第一のインター
フェースに係る格納形式で前記記憶装置に格納したデー
タを、前記第二のインターフェースによって検出して読
み出す手段と、前記第二のインターフェースによる読み
出しを行うため、前記データの格納形式を前記第一のイ
ンターフェースに係る格納形式に変換する手段と、該読
み出したデータを保存することによって、前記第一の計
算機が使用するデータのバックアップを取得する手段と
を備えたことを特徴とする計算機システム。
【請求項７】前記第一のインターフェースがカウントキ
ーデータ形式に従うインターフェースであり、前記第二
のインターフェースが固定長ブロック形式に従うインタ
ーフェースであることを特徴とする請求項６記載の計算
機システム。
【請求項８】前記第二の計算機は、前記第一の計算機が
前記記憶装置に格納した前記データに関して前記第一の
計算機が前記記憶装置内に作成した管理情報を、前記記
憶装置から検出して読み出す手段と、読み出した管理情
報を保存する手段とをさらに備えたことを特徴とする請
求項６または７に記載の計算機システム。
【請求項９】前記第二の計算機は、前記第一の計算機が
前記記憶装置に格納した前記データに関して前記第一の
計算機が前記記憶装置内に作成した管理情報を、前記記
憶装置から検出して読み出す手段と、読み出した管理情
報によって前記データの読み出しおよび保存の可否を決
定する手段とをさらに備えたことを特徴とする請求項６
から８の何れかに記載の計算機システム。
【請求項１０】前記記憶装置がディスクサブシステムで
あることを特徴とする請求項６から９の何れかに記載の
計算機システム。
【請求項１１】互いに異なる第一のインターフェースお
よび第二のインターフェースを有する記憶装置と、前記
第一のインターフェースによって前記記憶装置に接続す
る第一の計算機および前記第二のインターフェースによ
って前記記憶装置に接続する第二の計算機と、前記第二
の計算機に接続されたバックアップ装置を有する計算機
システムにおけるバックアップの取得方法において、前記第一の計算機が前記第二の計算機よりバックアップ
要求を受領すると、前記第一の計算機は、バックアップ
対象データを格納するボリュームＩＤ、ならびに該ボリ
ュームＩＤにより識別されるボリューム上の物理アドレ
スを前記第二の計算機へ通知し、前記第二の計算機は、前記物理位置に基づいて前記第二
のアクセスインタフェースによってアクセス可能なアド
レスを算出し、算出されたアドレスに基づいて前記ボリ
ュームからデータを読出し、読出したデータを前記バックアップ装置へ格納すること
を特徴とするバックアップ取得方法。
【請求項１２】前記第一のインターフェースがカウント
キーデータ形式に従うインターフェースであり、前記第
二のインターフェースが固定長ブロック形式に従うイン
ターフェースであることを特徴とする請求項１１記載の
バックアップ取得方法。
【請求項１３】請求項１２記載のバックアップ取得方法
において、前記第二の計算機により前記バックアップ装
置からデータを読出し、読み出したデータ内のカウント
部を変更した後に前記記憶装置へ書込むことを特徴とす
るバックアップ取得方法。
【請求項１４】互いに異なる第一のインターフェースお
よび第二のインターフェースを有する記憶装置と、前記
第一のインターフェースによって前記記憶装置に接続す
る第一の計算機と、前記記憶装置と前記第二のインタフ
ェースによって接続されたスイッチ装置と、前記スイッ
チ装置と接続する第二の計算機と、前記スイッチ装置に
接続されたバックアップ装置を有する計算機システムに
おいて、前記第一の計算機が前記第二の計算機よりバックアップ
要求を受領すると、前記第一の計算機は、バックアップ
対象データを格納するボリュームのボリュームＩＤと該
ボリューム上の物理アドレスを含む格納位置情報を前記
第二の計算機へ通知し、前記第二の計算機は、前記格納位置情報を受信し、前記
格納位置情報に基づいて、前記スイッチ装置に前記バッ
クアップ対象データを前記ボリュームＩＤにより識別さ
れるボリュームから前記バックアップ装置へコピーする
ことを指示するためのコマンドを作成して前記スイッチ
装置に発行し、前記スイッチ装置は、前記コマンドの内容にしたがっ
て、前記ボリュームから前記バックアップ装置へデータ
をコピーすることを特徴とするバックアップ取得方法。
【請求項１５】請求項１４記載のバックアップ取得方法
において、前記第二の計算機によりリストア先の記憶装
置がバックアップ取得時における前記記憶装置と同じか
どうかを調べ、同じであることが確認できた場合に、前
記バックアップ装置から前記記憶装置へデータをコピー
するコマンドを作成して前記スイッチ装置に発行し、前
記スイッチ装置は、前記コマンドに従って、前記バック
アップ装置から前記記憶装置へデータをリストアするこ
とを特徴とするバックアップ取得方法。