JP3726559B2 - ダイレクトバックアップ方法および記憶装置システム - Google Patents
ダイレクトバックアップ方法および記憶装置システム Download PDFInfo
- Publication number
- JP3726559B2 JP3726559B2 JP15338699A JP15338699A JP3726559B2 JP 3726559 B2 JP3726559 B2 JP 3726559B2 JP 15338699 A JP15338699 A JP 15338699A JP 15338699 A JP15338699 A JP 15338699A JP 3726559 B2 JP3726559 B2 JP 3726559B2
- Authority
- JP
- Japan
- Prior art keywords
- volume
- command
- copy
- computer
- data stored
- 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
Description
【０００１】
【発明の属する技術分野】
本発明はデータバックアップ方法に関するものであり、特にホストコンピュータ上で動作するアプリケーションプログラムのＩ／Ｏ処理を中断することなしに、ディスクシステムからバックアップ媒体へホストコンピュータを介することなくバックアップする方法に関する。
【０００２】
【従来の技術】
バックアップはシステム障害、人為的ミス、災害などからデータを保護するために必要である。一般的なユーザでは、日に一度、あるいは週に一度、夜間にオンライン業務を停止してバックアップを行っている。ところが近年では、企業のグローバル化や顧客に対するサービス向上のために、オンライン業務の無停止化に対する要求が高まっていて、バックアップに割くことのできる時間はますます短くなっている。この要求にこたえるために、Legato社ホワイトペーパー"Legato NetWorkerfor EMC Symmetrix Installation and Administration Guide"(www.legato.comより入手)に開示されている従来技術が知られている。本従来技術では、図１２に示すように、ユーザデータを格納しており、オンライン業務に使用しているユーザボリューム６ａのコピーをセカンダリボリューム６ｂに格納する。バックアップを行わないときは、データはユーザボリューム６ａとセカンダリボリューム６ｂに二重化して格納されている。バックアップを行う際には、ホストコンピュータ２ａはそのキャッシュメモリに格納されたダーティデータ（ボリューム６ａへ未反映のデータ）をフラッシュした後、ディスクシステム１に対してペア分割要求を発行する。この要求をディスクシステム１が受領すると、ユーザボリューム６ａに対するホストコンピュータ２ａからの更新を、セカンダリボリューム６ｂへ反映するのを中断することによって、セカンダリボリューム６ｂのデータを凍結する。その後ホストコンピュータ２ｂはセカンダリボリューム６ｂからデータを読出し、テープ装置等へデータをバックアップする。このバックアップ方法の利点は、ダーティデータが全てセカンダリボリューム６ｂに反映された時点で凍結されるので、無矛盾なデータのバックアップが取得できること、およびペア分割処理は非常に短時間で完了するので、オンライン処理を中断する必要がないことである。なお、バックアップ処理が完了すると、ホストコンピュータ２ａは再同期コマンドを発行して、ユーザボリューム６ａとセカンダリボリューム６ｂを再び二重化状態にもどす。
【０００３】
このように、ある一点時点の凍結データをスナップショットと呼ぶ。スナップショットを取得する他の方法として、Legato社ホワイトペーパー"Celestra Architecture for Serverless Backups" および"Celestra Block Copy Interface Specification" (ともにwww.iguard.comより取得可能)に開示された従来技術が知られている。この様子を図２を使って説明する。本従来技術では、通称ＣＣＯＰＹコマンドと呼ばれるボリュームから他のボリュームへ、あるいはボリュームからテープ装置へデータをコピーするコマンドを使用する。ホストコンピュータ２ａはバックアップ取得処理に先立って、ダーティデータをフラッシュして、ユーザボリューム６ａへデータを書出す。その後ＣＣＯＰＹコマンドを使用して、ユーザボリューム６ａからワークボリューム６ｃへデータをコピーする。ホストコンピュータ２ａ上で走行するアプリケーションプログラムが未コピーのデータへライトしようとすると、コピープログラムはそれを検出し、ＣＣＯＰＹコマンドを使用して、ライト対象のブロックをワークボリューム６ｃへコピーする。以上の処理により、バックアップ取得処理開始時点のデータがワークボリューム６ｃ上に得られることになる。その後ＣＣＯＰＹコマンドを使用して、データをワークボリューム６ｃからテープ装置３へバックアップする。
【０００４】
【発明が解決しようとする課題】
タイムアウトによってアプリケーションプログラムがハングするのを防止したり、オンライン処理の待ち時間を小さくためには、アプリケーションプログラムが待たされる時間を最小にする必要がある。Legato社ホワイトペーパー"Celestra Architecture for Serverless Backups" および"Celestra Block Copy Interface Specification" (ともにwww.iguard.comより取得可能)に開示された従来技術だと、アプリケーションプログラムが未コピーの領域へライトしようとすると、コピーが完了するまでライト処理が待たされる。ユーザボリューム６ａの全データをワークボリューム６ｃに一度にコピーしようとすると、全データのコピーが完了するまでアプリケーションプログラムが待たされることになってしまう。これを避けるためには、コピー対象のデータを少しずつワークボリューム６ｃにコピーしていく必要がある。このように少しずつコピーしていった場合、一つのＣＣＯＰＹコマンドでバックアップ対象データの部分領域のコピーを行うので、コピーコマンドの発行回数が多くなる。
この様子を図２の例を用いてさらに説明する。バックアップ対象のデータが領域１から領域５より構成されるとする。ここで領域１から領域５をユーザボリューム６ａからワークボリューム６ｃへコピーするよう、一つのＣＣＯＰＹコマンドにより要求したとする。その後、アプリケーションから領域３に対するライト要求が発生すると、領域１から領域５までのコピーが完了するまでこのライト要求は待たされる。
【０００５】
一方で、今度は各領域毎に一個のＣＣＯＰＹコマンドを発行する場合を考える。例えば領域１のコピーを要求した後、アプリケーションプログラムから領域３のライト要求が発生したとする。この場合、やはり領域１のコピーが完了するまでライト要求は待たされるが、前述のケースと比べると待ち時間は大幅に短縮できる。反面、ＣＣＯＰＹコマンドの発行回数が多くなり、ホストコンピュータのＩ／Ｏ発行負荷が大きくなる欠点がある。
【０００６】
以上から本発明における第一の目的は、ＣＣＯＰＹ処理における上記の背反する事象を解決する、すなわちアプリケーションプログラムのライト処理待ち時間を最小にするとともに、ＣＣＯＰＹコマンドの発行回数を最小にして、ホストコンピュータのＩ／Ｏ発行負荷を低減することにある。
【０００７】
さらにこの従来技術では、バックアップを行うために、データをユーザボリューム６ａからワークボリューム６ｃへコピーした後、テープ装置３へバックアップを行うため、バックアップを完了するまでに時間がかかる。
【０００８】
以上から本発明における第二の目的は、バックアップ時のワークボリューム６ｃへのデータコピーを無くして、バックアップ時間を短縮することにある。
【０００９】
【課題を解決するための手段】
本発明では上記課題を解決するために、ホストコンピュータはペア分割コマンドに続いて、分割したボリューム上に格納されたバックアップ対象の全データをバックアップするＣＣＯＰＹコマンドを、セカンダリボリューム６ｂに対して発行する手段を有する。一方、ディスクシステムはペア分割コマンドを受領すると、指定されたボリュームペアを分割する手段、およびＣＣＯＰＹコマンドを受領すると、、指定されたブロック１７をセカンダリボリューム６ｂからテープ装置３へ直接バックアップする手段を有する。ペア分割時点でセカンダリボリューム６ｂ上のデータは凍結される。このため、ホストコンピュータは一つのＣＣＯＰＹコマンドで、セカンダリボリューム６ｂ上に凍結されたバックアップ対象の全データをバックアップするよう指示できる。つまり、ＣＣＯＰＹコマンドは一度だけ発行すれば良く、コマンド発行回数が削減できる。さらに従来技術で説明したように、ペア分割後はユーザボリューム６ａに対するアクセスと、セカンダリボリュームからのバックアップ処理は平行して行えるので、アプリケーションプログラムがＣＣＯＰＹの完了を待つ必要はなく、アプリケーションのライトＩ／Ｏ待ち時間を最小にすることができる。さらにペア分割処理は非常に短い時間で終了し、セカンダリボリューム６ｂからテープ装置３へバックアップを行えるので、従来のワークボリューム６ｃを使ったやり方に比べて、バックアップ時間を短縮することができる。
【００１０】
一方、ディスクシステム１は、上記手段に加えて、ＣＣＯＰＹコマンドを受領した時に、指定されたセカンダリボリューム６ｂが分割済みかどうかを判定する手段、および分割済みならばセカンダリボリューム６ｂからテープ装置３へバックアップを行い、分割済みでなければホストコンピュータ２へエラーを報告する手段を設ける。これらの手段により、ホストコンピュータ２が分割コマンドを発行せず、誤ってＣＣＯＰＹコマンドのみを発行した場合でも、矛盾のあるデータのバックアップが取得されることはない。
【００１１】
本発明では、コマンド発行回数をさらに削減するために、ディスクシステム１がＣＣＯＰＹコマンドを受領すると、ペア分割、バックアップ、ペア統合の一連の処理を行う手段を有する。ここでペア統合とは、ペア分割中に発生した書き込みを差分管理しておき、この情報に基づいて差分データをユーザボリューム６ａからセカンダリボリューム６ｂへ反映して、再び二重化状態へ復帰させることである。この手段により、ホストコンピュータ２のコマンド発行回数をさらに削減することができるとともに、ホストコンピュータがペアの状態を意識する必要がなくなるので、管理が単純化できる。
【００１２】
【発明の実施の形態】
図１を用いて本発明の概要について説明する。ディスクシステム１には、ユーザボリューム６ａとセカンダリボリューム６ｂが存在し、これらはあらかじめ二重化されている。これをペアボリューム２０と呼ぶ。ホストコンピュータ２からユーザボリューム６ａに対して更新が行われると、更新データをセカンダリボリューム６ｂに反映することにより、二重化状態が保たれる。ボリューム６は複数の固定長のブロック１７より構成されていて、ブロック１７はボリューム６内で一意に番号付けされている。ボリューム６には一個以上のファイル１８が格納されていて、ファイル１８は一個以上のブロック１７により構成されている。ファイル１８とは、ホスト２上で走行するプログラムが認識している論理的なアクセス単位である。図の例のように、ファイル１８にはボリューム６上で連続したブロック１７が割当てられるとは限らない。バックアップはファイル１８単位に実行される。ホストコンピュータ２がペア分割コマンドをディスクシステム１に対して発行すると、二重化状態は解除される。つまり、ユーザボリューム６ａに対する以降の更新はセカンダリボリューム６ｂに反映されなくなり、セカンダリボリューム６ｂ上のデータはその時点で凍結される。
【００１３】
その後、ホストコンピュータ２はバックアップを行うセカンダリボリューム６ｂからテープ装置３へのコピーコマンドを発行する。この際、コピーコマンドのパラメータとして、バックアップ対象のファイル１８を構成する全てのブロック１７をコピーするよう指示する。すると、ディスクシステム１は指示されたブロック１７ｂをテープ装置３にコピーする。
【００１４】
セカンダリボリューム６ｂからテープ装置３へのコピー実行中でも、ホストコンピュータ２からユーザボリューム６ａへのアクセスは継続できる。もし更新があったら、当該ブロック１７がセカンダリボリューム６ｂに未反映であることを記録しておく。バックアップが完了すると、ホストコンピュータ２は再同期コマンドを発行して、ユーザボリューム６ａとセカンダリボリューム６ｂを再び二重化状態にもどす。この際にはユーザボリューム６ａの更新データでセカンダリボリューム６ｂに未反映のものをコピーする。
【００１５】
以上、本発明の概要について説明した。以下にこれを実現するための方法について具体的に説明する。
【００１６】
図３は本発明におけるシステム構成例である。一台以上のホストコンピュータ２では、アプリケーションプログラムや、ペアボリューム２０の制御、バックアップおよびリストアの実行、磁気テープライブラリ３の管理等をおこなうプログラムが走行する。ホストコンピュータ２は、他のホストコンピュータ２、ディスクシステム１、磁気テープライブラリ３と、ネットワーク１７により接続されていて、互いに通信が可能である。ここでネットワークとは、10BaseTや100BaseT等の一般的にＬＡＮ等で使用されるケーブルで接続されていて、通信にはTCP/IPやUDPなどのネットワークプロトコルにしたがって行われるものとする。ホストコンピュータ２はさらに、チャネルパス１２によりディスクシステム１に接続されている。チャネルパス１２の実例としては、ＳＣＳＩケーブルあるいはＦｉｂｒｅチャネルを想定する。なお以降の説明では、チャネルパス１２はファイバチャネルを前提とする。チャネルパス１２がファイバチャネルの場合は、ホストコンピュータ２とディスクシステム１がポイントツーポイントで接続されるケースや、ＦＣ−ＡＬと呼ばれるループ状に各装置（ノードと呼ぶ）が接続されるケースや、図３のようにスイッチ４を介在して接続されるケースなどがある。本発明はこの接続形態のいずれにも対応可能である。
【００１７】
テープ装置３はバックアップデータを格納するための装置である。テープ装置３の実現例としては、例えば磁気テープライブラリ、カートリッジテープ、ＤＶＤ（ライブラリ）装置、ＤＶＤ−ＲＡＩＤ装置、ＣＤ−ＲＷ、あるいはディスク装置等、あらゆる記憶媒体を適用できる。
【００１８】
ディスクシステム１は、データを格納する一台以上のディスク装置１５と、ディスク装置１５とホストコンピュータ２間のデータ転送を制御する制御装置５から構成される。ディスク装置１５とディスク制御装置５はチャネルパス１４により接続されている。本発明では、チャネルパス１４はＳＣＳＩケーブル、ファイバチャネルＩＢＭ社のＳＳＡを想定し、これらのインタフェースに迎合したディスク装置１５が使用される。また、近年では複数のディスク装置１５を一つのグループとして、このグループ上にボリューム６を分散配置するＲＡＩＤと呼ばれる手法が一般的になっている。本発明はディスクシステム１がＲＡＩＤを採用した場合でも適用可能である。
【００１９】
さて次に、ディスク制御装置５内の制御情報のうち、第一の実施例に関連するものを説明する。コピーパラメータ８は、ホストコンピュータ２から受領したコピーパラメータを格納するための領域である。差分ビットマップ９は、ボリューム６対応に存在し、ユーザボリューム６ａとセカンダリボリューム６ｂが分割された後、ボリューム６にホストコンピュータ２から更新があった場合に該当するビットがオンされる。本発明では、ブロック１７単位にビットを持ち、ブロック番号１がビット１に、ブロック番号２がビット２に、．．．と対応させる。もちろんブロック１７対応に１ビットを対応させる必要はなく、例えばｎブロック（ｎ＞１）単位に１ビットを対応させても構わない。このようにすることによって、差分ビットマップの容量を削減することも可能である。
【００２０】
コピーコマンドは、ＳＣＳＩ−２で標準化されているＣＯＰＹコマンドと、Legato社ホワイトペーパー"Celestra Architecture for Serverless Backups" および"Celestra Block Copy Interface Specification" (ともにwww.iguard.comより取得可能)に開示された従来技術で開示されたＣＣＯＰＹコマンドが一般的に知られている。本発明ではこれら両方に適用可能だが、以降の説明では、ＣＣＯＰＹコマンドを前提に説明する。なお、これらのコマンドの詳細については、「ＳＣＳＩ−２詳細解説」、菅谷誠一著、CQ出版社、ならびに"Celestra Block Copy Interface Specification"を参照されたい。
【００２１】
次に図４を使用して、バックアップ処理について説明する。
【００２２】
まずステップ４０で、ユーザまたは管理者は、ペアボリューム２０を形成する。このステップでは、ユーザボリューム６ａとセカンダリボリューム６ｂがユーザにより指定される。この要求を受領すると、ディスク制御装置５は、ユーザボリューム６ａからセカンダリボリューム６ｂへデータをコピーする。これ以降、ホストコンピュータ２からユーザボリューム６ａへ更新があると、更新データはセカンダリボリューム６ｂへコピーされ、二重化状態が保持される。
【００２３】
ステップ４１で、ユーザまたは管理者からのバックアップ指示があると、あるいはあらかじめスケジュールされていた時刻が到来すると、ホストコンピュータ２上ではバックアッププログラムが動作して、バックアップ処理モードに入る。バックアップ処理モードに入ってからステップ４６までの間、ホストコンピュータ２上で走行するコピープログラムは、アプリケーションプログラムからのユーザボリューム６ａへのアクセスを禁止する。
【００２４】
続いてホストコンピュータ２は、ステップ４２で、バックアップ対象のファイル１８を構成するブロック１７と、そのブロック１７を格納しているユーザボリュームを特定する。その後、ステップ４３で、Inqueryコマンド等を用いて当該ユーザボリューム６ａがペアを形成しているかどうかを調べる。ペアを形成している場合は、ステップ４４で分割コマンドを発行して、二重化状態を中断する。このコマンドをディスク制御装置５が受領すると、ユーザボリューム６ａに対する更新はセカンダリボリューム６ｂに反映されなくなり、その時点でセカンダリボリューム６ｂのデータは凍結される。
【００２５】
ペアの分割が完了すると、ホストコンピュータ２はステップ４５で、ファイル１８全体をバックアップするＣＣＯＰＹコマンドをセカンダリボリューム６ｂに対して発行する。このとき、アクセスするセカンダリボリューム６ｂは、ステップ４３でＩｎｑｕｅｒｙコマンドを発行したときに特定される。
【００２６】
ディスク制御装置５は、ステップ４５でＣＣＯＰＹコマンドを受領すると、ステップ４６で、まず指定されたボリューム６がセカンダリボリューム６ｂであり（つまりペアボリューム２０を構成しており）、かつペアが分割された状態かどうかを調べる。この条件に合致していない場合は、エラーをホストコンピュータ２へ報告し、バックアップ処理は行わない。合致している場合は、そのパラメータをコピーパラメータ８に格納してコマンド完了を返す。その後、コピーパラメータ８に格納された情報にしたがって、セカンダリボリューム６ｂからテープライブラリ装置３へのバックアップを実行する。ＣＣＯＰＹコマンドのパラメータには、コピー元（すなわちセカンダリボリューム６ｂ上）のブロックアドレスとブロック数と、これらのブロック１７を格納するテープ装置のポートアドレスとの組が含まれる。したがって、このパラメータにしたがって、セカンダリボリューム６ｂからブロック１７を読出し、指定されたポートアドレスに送信してやれば良い。ここで、ＣＣＯＰＹコマンドの完了報告は、バックアップ処理の開始を示すものであるため、注意すること（バックアップ完了を報告するものではない）。この段階では、バックアップの実行可能条件をチェックして、可能であれば、完了報告する。
【００２７】
ホストコンピュータ２は、ディスク制御装置５からＣＣＯＰＹコマンド完了を受領すると、ステップ４７で、ユーザボリューム６ａへのアクセスを再開させる。その後、ステップ４８で、バックアップが完了したかどうかをチェックし、もし完了していれば、ペア再同期コマンドを発行して、ペアボリューム２０を再び二重化状態へもどす。ディスク制御装置５は、再同期コマンドを受領すると、差分ビットマップ８にしたがって、差分データをユーザボリューム６ａからセカンダリボリューム６ｂへコピーする。
【００２８】
ステップ４３でユーザボリューム６ａがペアを形成していないことが分かると、ホストコンピュータ２はステップ４９で、通常のＣＣＯＰＹ処理を実行する。この処理については公知技術であるので、説明を省略する。
【００２９】
ディスク制御装置５は、ステップ４７で、ＣＣＯＰＹコマンドの実行可否をチェックした。もしホストコンピュータ２がペアボリューム２０を分割せずにＣＣＯＰＹコマンドを発行し、かつステップ４７のチェックを行わずにバックアップをおこなってしまったら、凍結データのバックアップを取得することはできない。すなわち本発明の本来の目的である、無矛盾なデータのバックアップが取得できないことになる。したがってこの処理は、ペアの分割および統合の機能に、ＣＣＯＰＹを使用したバックアップ処理を組み合わせる際の重要なステップである。
【００３０】
以上の処理によれば、ペアを分割することによってセカンダリボリューム６ｂのデータを凍結でき、このためホストコンピュータ２はファイル１８全体のバックアップを行うＣＣＯＰＹコマンドをセカンダリボリューム６ｂに対して発行できるようになる。このため、ＣＣＯＰＹコマンドは最初の一回だけ発行すればよく、ホストのＣＣＯＰＹコマンド発行負荷を低減できる。
【００３１】
以上で第一実施例の説明を終わるが、最後にこの効果についてまとめておく。第一実施例では、ペア分割を使用してＣＣＯＰＹによるダイレクトバックアップ方法について説明した。従来技術では、ファイル１８をいったんワークディスク６ｃへ格納した後、テープ装置３へバックアップしていた。また、ワークディスク６ｃへファイル１８をコピーする際には、複数のＣＣＯＰＹコマンドを発行していた。第一実施例では、ＣＣＯＰＹコマンドとペア分割・再同期を行う処理と組み合わせることにより、ホストコンピュータ２はファイル１８全体をバックアップするＣＣＯＰＹコマンドを一度だけ発行すれば済み、ホストのＩ／Ｏ発行負荷を低減できる。さらにセカンダリボリューム６ｂからテープ装置３へバックアップを行うので、ワークディスク６ｃへコピー処理が不要となり、バックアップ時間を短縮することができる。
【００３２】
第二実施例
次に第二の実施例について説明する。
【００３３】
第一の実施例では、ホストコンピュータ２はペア分割、バックアップ指示に続いて、バックアップ処理が完了した後、ペア再同期を指示していた。バックアップ処理の完了はInqueryコマンドをたびたび発行することにより、調べていた。本実施例は、これらの処理を無くし、ホストコンピュータ２のコマンド発行回数をさらに削減するためのものである。
【００３４】
図９に本実施例におけるホストコンピュータ２およびディスク制御装置５の処理フローを示す。なお、図９のステップ９０からステップ９５以外は図４の説明と同様なので、省略する。
【００３５】
ホストコンピュータ２は、ステップ９０で、ファイル全体をバックアップするＣＣＯＰＹコマンドをＡＵＴＯ指定で発行する。ここでＡＵＴＯ指定とは、ペアの分割、セカンダリボリューム６ｂからテープ装置３へのバックアップ、ペアの再同期までの一連の処理を、ディスクシステム１で自動的に実行するモードである。このモード指定には、ＣＣＯＰＹコマンドCDB(Command Descriptor Block)のリザーブ領域に１ビットを設ければ良い。
【００３６】
ディスク制御装置５が、ＡＵＴＯモード指定のＣＣＯＰＹコマンドを受領すると、ステップ９１でバックアップ対象のユーザボリューム６ａが、ペアを形成しているかどうか、すなわちセカンダリボリューム６ｂを有するかどうかをチェックする。もし、ペアを形成していなければ、ステップ９４で、ホストコンピュータ２に対してエラーを報告して処理を完了する。もしペアを形成していれば、ステップ９３で、ペアを分割した後、ステップ９４で、ＣＣＯＰＹコマンドの完了を報告し、セカンダリボリューム６ｂからテープ装置３へのバックアップ処理を実行する。
【００３７】
ステップ９４のＣＣＯＰＹ完了報告を契機に、ホストコンピュータ２はステップ４７で、アプリケーションプログラムのボリュームアクセスを再開させるが、この間もディスク制御装置５はバックアップを継続する。そしてＣＣＯＰＹコマンドで指定されたバックアップ処理が全て完了すると、ディスク制御装置５はステップ９５で、ペアを再同期させる。
【００３８】
以上の処理により、ＣＣＯＰＹコマンド発行契機で、ディスク制御装置５が、ペア分割、バックアップ、ペア再同期までの一連の処理を実行する。これら全ての処理はホストコンピュータ２に対して透過的なので、ペア状態の監視、制御などによるホストプログラムの複雑さから開放される。さらに本実施例から分かるように、ホストコンピュータ２はディスク制御装置５に対してＣＣＯＰＹコマンドを一度発行すればよく、コマンド発行回数を削減できる。
【００３９】
第三実施例
次に第三の実施例について説明する。
【００４０】
第一および第二の実施例では、ペアの分割および統合の単位はボリューム６であった。ところが実際にバックアップを実行するのはボリューム６上のごく一部の領域である。ボリューム全体を分割してしまうと、ホストコンピュータ２からの更新があれば差分ビットがオンされ、再同期時にコピー対象となってしまうので、再同期処理に時間がかかる。第二の実施例ではこれを解決するために、バックアップ対象の領域のみを分割する方法を開示する。さらにこの方法を用いると、あるユーザボリューム６ａに格納された各ファイル１８を任意の時点でバックアップすることが可能になる。すなわち、第一の実施例ではボリューム６を分割した時点でセカンダリボリューム６ｂが凍結される。そしてバックアップが完了し、ペアの再同期が行われるまでは、同一のユーザボリューム６ａに格納された別のファイル１８をバックアップすることができなかった。ところが本実施例の技術を適用すると、ペアボリューム２０はバックアップ対象のブロック１７毎に分割・再同期が行われるので、各ファイル１８毎に任意のタイミングでバックアップすることができる。以下、第二実施例の詳細について説明する。
【００４１】
この方法では、図３に示すように、ディスク制御装置５はペア分割ビットマップ１０をボリューム６対応に保持する。これはブロック１７対応のビットマップであり、分割コマンドにより指示されたブロック１７に対応するビットがオンされる。ホストコンピュータ２から更新があった場合には、ペア分割ビットマップ１０を見て、ライト対象のブロック１７のビットがオンなら、セカンダリボリューム６ｂへのコピーを行わない。そしてＣＣＯＰＹコマンドにより指示されたブロック１７を、セカンダリボリューム６ｂからテープ装置３へバックアップする。なお、ペア分割ビットマップ１０は連続したｎブロック対応に１ビットを割当てても構わない。
【００４２】
次に処理ステップの詳細を図４を用いて説明する。ステップ４０から４３まではこれまでの説明と同じである。ディスク制御装置５はステップ４４において、ステップ４２で特定されたブロック１７を分割するよう、ペア分割コマンドを発行する。
【００４３】
図５はペア分割・再同期コマンドのフォーマットを示す。ペア分割・再同期コマンドコード５０は、本コマンドに割当てられたコードを示す。分割要求ビット５１は本コマンドがペア分割か、それとも再同期かを示すビットである。パラメータリスト数５２は、ブロックアドレス・ブロック数５３がいくつ後続するかを示す。分割するブロック１７の個数と、それらのブロック１７が連続的にボリューム６上に割当てられているかどうかによって、可変である。ブロックアドレス・ブロック数５３は、分割するブロック１７がボリューム６上で連続だった場合に、そのブロック集合内の先頭ブロックアドレスと、ブロック数を格納する。
【００４４】
図６は、ペア分割コマンドを受領した時のディスク制御装置の処理を示す。ディスク制御装置５がペア分割コマンドを受領すると、ステップ６０で、ブロックアドレス・ブロック数５３から、分割対象のブロックアドレスを求め、ペア分割ビットマップ１０の対応するビットをオンする。この処理以降、当該ボリューム６はステップ６１で示したペア分割モードに入る。ボリューム６がペア分割モードにあるとき、ステップ６２においてホストコンピュータ２からライトコマンドを受領すると、 ステップ６３で、ライト対象ブロック１７が分割対象かどうかを、ペア分割ビットマップ１０を参照して調べる。ライトコマンドには、ライト対象の先頭ブロック１７と、ライトするブロック１７数がパラメータに含まれるので、これよりライト対象ブロック１７を求めて、対応するビットがオンかどうかを調べれば良い。もし分割対象ならば、ステップ６４で、差分ビットマップ９の対象ビットをオンした後、ユーザボリューム６ａに書込みを行う。ステップ６３で分割対象でなければ、ステップ６５で、ユーザボリューム６ａとセカンダリボリューム６ｂの両方へ書込みを行う。
【００４５】
以上、ペア分割コマンドを受領した時のディスク制御装置５の処理について説明した。再び図４に戻る。ステップ４５および４６は以前の説明と同様である。これらのステップにより、ファイル１８がセカンダリボリューム６ｂからテープ装置３へバックアップされる。バックアップが完了し、ステップ４７でペアの再同期を行う。ペアの再同期の際には、図５で説明したペア分割・再同期コマンドを使用するが、分割要求ビット５１は０とする（これによりペア再同期を示す）。
【００４６】
図７はペア再同期コマンドを受領した時のディスク制御装置５の処理フローを示す。ペア再同期コマンドを受領すると、ディスク制御装置５は本コマンドで受領した全てのブロック１７に対してステップ７０以降の処理を実行する。まずステップ７０で、当該ブロック１７に対応するペア分割ビットマップ１０のビットがオンかどうかを調べ、もしオンなら、ステップ７１で、差分ビットマップ９の対応するビットがオンかどうかを調べる。これもオンなら、差分データが存在することになるので、ステップ７２で、当該ブロック１７をユーザボリューム６ａからセカンダリボリューム６ｂへコピーする。そしてステップ７３および７４で、差分ビットおよびペア分割ビットをオフする。その後ステップ７５で、全てのペア分割ビットがオフになっていたら、当該ボリューム６のペア分割モードを解除する。これによって、以降のホストコンピュータ２からの全てのライトデータは、ユーザボリューム６ａおよびセカンダリボリューム６ｂの両方に書込まれる。以上によりペア再同期処理が完了する。
【００４７】
以上、第三実施例でも、ホストコンピュータ２は、ペア分割コマンド、ＣＣＯＰＹコマンド、ペア再同期コマンドの３つのコマンドを送信していた。このコマンドに伴う一連の処理は定型的なものなので、第二の実施例と同様に、一つのＣＣＯＰＹコマンドによりこれらの処理を行わせることができる。つまり、ホストコンピュータ２がＣＣＯＰＹコマンドを発行すると、ディスク制御装置５は、本コマンドで指定されたブロック１７に関してペア分割、バックアップ、ペア統合を実行するわけである。この方法により、ホストコンピュータ２のコマンド発行回数を一回に削減することが可能となる。
【００４８】
これで第三実施例の説明を終わるが、最後にこの効果についてまとめておく。第三実施例では、ペアボリューム２０をブロック１７単位にペア分割する方法について説明した。この方法によると、ペア分割中は分割対象のブロック１７のみが差分管理されるため、再同期にかかる時間が短くて済む。また、ペア分割モード中でも、新たなペア分割コマンドを受領すると、図６に示した処理を実行することによって、他のブロック１７に関してペア分割できる。このため、同一ユーザボリューム６ａに格納された任意のファイル１８を任意の時点でバックアップすることができる。
【００４９】
次に第四の実施例として、本発明における他の構成例を図８を用いて説明する。図８では、２台のディスクシステム１ａおよび１ｂと、これらを接続するチャネルパス８０から構成される。さらにスイッチ４ａおよびスイッチ４ｂはチャネルパス８１により接続され、スイッチ間でデータの送受信が可能である。ディスクシステム１ａはユーザボリューム６ａを有し、ディスクシステム１ａに接続したホストコンピュータ２ａでは、オンライン処理等のアプリケーションプログラムを実行する。他方、ディスクシステム２ｂはセカンダリボリューム６ｂを有し、ディスクシステム２ｂに接続したホストコンピュータ２ｂでは、テープ装置３の制御を行う。すなわち本構成では、遠隔地に設置された2台のディスクシステム１ａおよび１ｂ間でペアボリューム２０を構成している。ホストコンピュータ２ａからユーザボリューム６ａに対して更新があると、ディスクシステム１ａと１ｂを接続するチャネルパス８０を介してライトデータが転送され、セカンダリボリューム６ｂに更新データが反映される。あるいはディスクシステム１ａからスイッチ４ａへ、さらにスイッチ４ａからチャネルパス８１経由でスイッチ４ｂへ、そしてスイッチ４ｂからディスクシステム１ｂへライトデータが送信され、最終的にはセカンダリボリューム６ｂへ書込まれる。このようにして二重化状態が保持される。
【００５０】
以上のような構成においても、第一、第二、第三の実施例で説明した方式を適用できる。すなわち、バックアップの際にはペアを分割した後、ディスクシステム１ｂが、セカンダリボリューム６ｂからテープ装置３へバックアップを行う。また、ブロック１７毎にペア分割を行う場合でも、ディスクシステム１ａはペア分割ビットマップ１０を利用して、分割が指示されたブロック１７については、ディスクシステム１ｂへライトデータを転送しない。
【００５１】
他の実現例として、図８において、ディスクシステム１ｂのボリューム６ｂと６ｃをさらに二重化する場合を考える。したがって、ボリューム６ａ、６ｂ、６ｃは、同一データを保持する三重化状態である。バックアップの際に、ボリューム６ｂとボリューム６ｃ間のペアを分割した後、ボリューム６ｃからテープ装置３へバックアップを行っても良い。
【００５２】
続いて第五の実施例として、スイッチ４がＣＣＯＰＹコマンドを解釈し、バックアップ処理を実行する方法について説明する。本実施例の概要を図１０に示す。この場合、ホストコンピュータ２は、まずペア分割コマンドをディスク制御装置５に対して発行し、その後、スイッチ４に対してＣＣＯＰＹコマンドを発行する。この際に、ＣＣＯＰＹコマンドのパラメータとして、コピー元となるディスクシステム１に接続されたチャネルパス１２のポートアドレスと、ボリューム６ｂのアドレス、バックアップするテープ装置３のアドレスを指定する。スイッチ４はＣＣＯＰＹコマンドを解釈し、コピー処理を実行する機能を有する。本機能により、スイッチ４はボリューム６ｂからバックアップ対象のデータを読出し、それをテープ装置３へ格納していく。ＣＣＯＰＹコマンドにより指定された全てのブロックをテープ装置３へ格納すると、処理を完了する。
【００５３】
ボリューム６ａと６ｂはスプリットされているので、ボリューム６ｂからテープ装置３へデータをバックアップしている間も、ホストコンピュータ２からボリューム６ａへのアクセスは継続できる。
【００５４】
図１１は第六の実施例を示す。本実施例では、テープ装置３がＣＣＯＰＹコマンドを解釈し、バックアップ処理を実行する方法に関するものである。この場合、この場合、ホストコンピュータ２は、まずペア分割コマンドをディスク制御装置５に対して発行し、その後、テープ装置３に対してＣＣＯＰＹコマンドを発行する。この際に、ＣＣＯＰＹコマンドのパラメータとして、コピー元となるディスクシステム１に接続されたチャネルパス１２のポートアドレスと、ボリューム６ｂのアドレス、バックアップするテープ装置３のアドレスを指定する。テープ装置３はＣＣＯＰＹコマンドを解釈し、コピー処理を実行する機能を有する。本機能により、テープ装置３はボリューム６ｂからバックアップ対象のデータを読出し、それをテープ装置３へ格納していく。ＣＣＯＰＹコマンドにより指定された全てのブロックをテープ装置３へ格納すると、処理を完了する。
【００５５】
ボリューム６ａと６ｂはスプリットされているので、ボリューム６ｂからテープ装置３へデータをバックアップしている間も、ホストコンピュータ２からボリューム６ａへのアクセスは継続できる。
【００５６】
【発明の効果】
以上、説明したように、本発明によれば、アプリケーションプログラムのライト処理待ち時間を最小にするとともに、ＣＣＯＰＹコマンドの発行回数を最小にして、ホストコンピュータのＩ／Ｏ発行負荷を低減できる。また、バックアップ時のワークボリューム６ｃへのデータコピーを無くして、バックアップ時間を短縮できる。
【図面の簡単な説明】
【図１】本発明の概要図である。
【図２】第一従来技術の概要図である。
【図３】本発明におけるシステム構成である。
【図４】バックアップ処理フローである。
【図５】ペア分割・再同期コマンド形式である。
【図６】ペア分割コマンド受領時のディスク制御装置の処理フローである。
【図７】ペア再同期コマンド受領時のディスク制御装置の処理フローである。
【図８】本発明における他のシステム構成例である。
【図９】ＣＣＯＰＹコマンド・ＡＵＴＯモード指定時のバックアップ処理フローである。
【図１０】第五実施例の概要図である。
【図１１】第六実施例の概要図である。
【図１２】第二従来技術の概要図である。
【符号の説明】
１…ディスクシステム、２…ホストコンピュータ、３…テープ装置、４…スイッチ、５…ディスク制御装置、６…ボリューム、６ａ…ユーザボリューム、６ｂ…セカンダリボリューム、８…コピーパラメータ、９…差分ビットマップ、１０…ペア分割ビットマップ、１２…チャネルパス、１３…ネットワーク、１４…ディスク接続パス、１５…ディスク装置、１７…ブロック、１８…ファイル、２０…ペアボリューム。
【発明の属する技術分野】
本発明はデータバックアップ方法に関するものであり、特にホストコンピュータ上で動作するアプリケーションプログラムのＩ／Ｏ処理を中断することなしに、ディスクシステムからバックアップ媒体へホストコンピュータを介することなくバックアップする方法に関する。
【０００２】
【従来の技術】
バックアップはシステム障害、人為的ミス、災害などからデータを保護するために必要である。一般的なユーザでは、日に一度、あるいは週に一度、夜間にオンライン業務を停止してバックアップを行っている。ところが近年では、企業のグローバル化や顧客に対するサービス向上のために、オンライン業務の無停止化に対する要求が高まっていて、バックアップに割くことのできる時間はますます短くなっている。この要求にこたえるために、Legato社ホワイトペーパー"Legato NetWorkerfor EMC Symmetrix Installation and Administration Guide"(www.legato.comより入手)に開示されている従来技術が知られている。本従来技術では、図１２に示すように、ユーザデータを格納しており、オンライン業務に使用しているユーザボリューム６ａのコピーをセカンダリボリューム６ｂに格納する。バックアップを行わないときは、データはユーザボリューム６ａとセカンダリボリューム６ｂに二重化して格納されている。バックアップを行う際には、ホストコンピュータ２ａはそのキャッシュメモリに格納されたダーティデータ（ボリューム６ａへ未反映のデータ）をフラッシュした後、ディスクシステム１に対してペア分割要求を発行する。この要求をディスクシステム１が受領すると、ユーザボリューム６ａに対するホストコンピュータ２ａからの更新を、セカンダリボリューム６ｂへ反映するのを中断することによって、セカンダリボリューム６ｂのデータを凍結する。その後ホストコンピュータ２ｂはセカンダリボリューム６ｂからデータを読出し、テープ装置等へデータをバックアップする。このバックアップ方法の利点は、ダーティデータが全てセカンダリボリューム６ｂに反映された時点で凍結されるので、無矛盾なデータのバックアップが取得できること、およびペア分割処理は非常に短時間で完了するので、オンライン処理を中断する必要がないことである。なお、バックアップ処理が完了すると、ホストコンピュータ２ａは再同期コマンドを発行して、ユーザボリューム６ａとセカンダリボリューム６ｂを再び二重化状態にもどす。
【０００３】
このように、ある一点時点の凍結データをスナップショットと呼ぶ。スナップショットを取得する他の方法として、Legato社ホワイトペーパー"Celestra Architecture for Serverless Backups" および"Celestra Block Copy Interface Specification" (ともにwww.iguard.comより取得可能)に開示された従来技術が知られている。この様子を図２を使って説明する。本従来技術では、通称ＣＣＯＰＹコマンドと呼ばれるボリュームから他のボリュームへ、あるいはボリュームからテープ装置へデータをコピーするコマンドを使用する。ホストコンピュータ２ａはバックアップ取得処理に先立って、ダーティデータをフラッシュして、ユーザボリューム６ａへデータを書出す。その後ＣＣＯＰＹコマンドを使用して、ユーザボリューム６ａからワークボリューム６ｃへデータをコピーする。ホストコンピュータ２ａ上で走行するアプリケーションプログラムが未コピーのデータへライトしようとすると、コピープログラムはそれを検出し、ＣＣＯＰＹコマンドを使用して、ライト対象のブロックをワークボリューム６ｃへコピーする。以上の処理により、バックアップ取得処理開始時点のデータがワークボリューム６ｃ上に得られることになる。その後ＣＣＯＰＹコマンドを使用して、データをワークボリューム６ｃからテープ装置３へバックアップする。
【０００４】
【発明が解決しようとする課題】
タイムアウトによってアプリケーションプログラムがハングするのを防止したり、オンライン処理の待ち時間を小さくためには、アプリケーションプログラムが待たされる時間を最小にする必要がある。Legato社ホワイトペーパー"Celestra Architecture for Serverless Backups" および"Celestra Block Copy Interface Specification" (ともにwww.iguard.comより取得可能)に開示された従来技術だと、アプリケーションプログラムが未コピーの領域へライトしようとすると、コピーが完了するまでライト処理が待たされる。ユーザボリューム６ａの全データをワークボリューム６ｃに一度にコピーしようとすると、全データのコピーが完了するまでアプリケーションプログラムが待たされることになってしまう。これを避けるためには、コピー対象のデータを少しずつワークボリューム６ｃにコピーしていく必要がある。このように少しずつコピーしていった場合、一つのＣＣＯＰＹコマンドでバックアップ対象データの部分領域のコピーを行うので、コピーコマンドの発行回数が多くなる。
この様子を図２の例を用いてさらに説明する。バックアップ対象のデータが領域１から領域５より構成されるとする。ここで領域１から領域５をユーザボリューム６ａからワークボリューム６ｃへコピーするよう、一つのＣＣＯＰＹコマンドにより要求したとする。その後、アプリケーションから領域３に対するライト要求が発生すると、領域１から領域５までのコピーが完了するまでこのライト要求は待たされる。
【０００５】
一方で、今度は各領域毎に一個のＣＣＯＰＹコマンドを発行する場合を考える。例えば領域１のコピーを要求した後、アプリケーションプログラムから領域３のライト要求が発生したとする。この場合、やはり領域１のコピーが完了するまでライト要求は待たされるが、前述のケースと比べると待ち時間は大幅に短縮できる。反面、ＣＣＯＰＹコマンドの発行回数が多くなり、ホストコンピュータのＩ／Ｏ発行負荷が大きくなる欠点がある。
【０００６】
以上から本発明における第一の目的は、ＣＣＯＰＹ処理における上記の背反する事象を解決する、すなわちアプリケーションプログラムのライト処理待ち時間を最小にするとともに、ＣＣＯＰＹコマンドの発行回数を最小にして、ホストコンピュータのＩ／Ｏ発行負荷を低減することにある。
【０００７】
さらにこの従来技術では、バックアップを行うために、データをユーザボリューム６ａからワークボリューム６ｃへコピーした後、テープ装置３へバックアップを行うため、バックアップを完了するまでに時間がかかる。
【０００８】
以上から本発明における第二の目的は、バックアップ時のワークボリューム６ｃへのデータコピーを無くして、バックアップ時間を短縮することにある。
【０００９】
【課題を解決するための手段】
本発明では上記課題を解決するために、ホストコンピュータはペア分割コマンドに続いて、分割したボリューム上に格納されたバックアップ対象の全データをバックアップするＣＣＯＰＹコマンドを、セカンダリボリューム６ｂに対して発行する手段を有する。一方、ディスクシステムはペア分割コマンドを受領すると、指定されたボリュームペアを分割する手段、およびＣＣＯＰＹコマンドを受領すると、、指定されたブロック１７をセカンダリボリューム６ｂからテープ装置３へ直接バックアップする手段を有する。ペア分割時点でセカンダリボリューム６ｂ上のデータは凍結される。このため、ホストコンピュータは一つのＣＣＯＰＹコマンドで、セカンダリボリューム６ｂ上に凍結されたバックアップ対象の全データをバックアップするよう指示できる。つまり、ＣＣＯＰＹコマンドは一度だけ発行すれば良く、コマンド発行回数が削減できる。さらに従来技術で説明したように、ペア分割後はユーザボリューム６ａに対するアクセスと、セカンダリボリュームからのバックアップ処理は平行して行えるので、アプリケーションプログラムがＣＣＯＰＹの完了を待つ必要はなく、アプリケーションのライトＩ／Ｏ待ち時間を最小にすることができる。さらにペア分割処理は非常に短い時間で終了し、セカンダリボリューム６ｂからテープ装置３へバックアップを行えるので、従来のワークボリューム６ｃを使ったやり方に比べて、バックアップ時間を短縮することができる。
【００１０】
一方、ディスクシステム１は、上記手段に加えて、ＣＣＯＰＹコマンドを受領した時に、指定されたセカンダリボリューム６ｂが分割済みかどうかを判定する手段、および分割済みならばセカンダリボリューム６ｂからテープ装置３へバックアップを行い、分割済みでなければホストコンピュータ２へエラーを報告する手段を設ける。これらの手段により、ホストコンピュータ２が分割コマンドを発行せず、誤ってＣＣＯＰＹコマンドのみを発行した場合でも、矛盾のあるデータのバックアップが取得されることはない。
【００１１】
本発明では、コマンド発行回数をさらに削減するために、ディスクシステム１がＣＣＯＰＹコマンドを受領すると、ペア分割、バックアップ、ペア統合の一連の処理を行う手段を有する。ここでペア統合とは、ペア分割中に発生した書き込みを差分管理しておき、この情報に基づいて差分データをユーザボリューム６ａからセカンダリボリューム６ｂへ反映して、再び二重化状態へ復帰させることである。この手段により、ホストコンピュータ２のコマンド発行回数をさらに削減することができるとともに、ホストコンピュータがペアの状態を意識する必要がなくなるので、管理が単純化できる。
【００１２】
【発明の実施の形態】
図１を用いて本発明の概要について説明する。ディスクシステム１には、ユーザボリューム６ａとセカンダリボリューム６ｂが存在し、これらはあらかじめ二重化されている。これをペアボリューム２０と呼ぶ。ホストコンピュータ２からユーザボリューム６ａに対して更新が行われると、更新データをセカンダリボリューム６ｂに反映することにより、二重化状態が保たれる。ボリューム６は複数の固定長のブロック１７より構成されていて、ブロック１７はボリューム６内で一意に番号付けされている。ボリューム６には一個以上のファイル１８が格納されていて、ファイル１８は一個以上のブロック１７により構成されている。ファイル１８とは、ホスト２上で走行するプログラムが認識している論理的なアクセス単位である。図の例のように、ファイル１８にはボリューム６上で連続したブロック１７が割当てられるとは限らない。バックアップはファイル１８単位に実行される。ホストコンピュータ２がペア分割コマンドをディスクシステム１に対して発行すると、二重化状態は解除される。つまり、ユーザボリューム６ａに対する以降の更新はセカンダリボリューム６ｂに反映されなくなり、セカンダリボリューム６ｂ上のデータはその時点で凍結される。
【００１３】
その後、ホストコンピュータ２はバックアップを行うセカンダリボリューム６ｂからテープ装置３へのコピーコマンドを発行する。この際、コピーコマンドのパラメータとして、バックアップ対象のファイル１８を構成する全てのブロック１７をコピーするよう指示する。すると、ディスクシステム１は指示されたブロック１７ｂをテープ装置３にコピーする。
【００１４】
セカンダリボリューム６ｂからテープ装置３へのコピー実行中でも、ホストコンピュータ２からユーザボリューム６ａへのアクセスは継続できる。もし更新があったら、当該ブロック１７がセカンダリボリューム６ｂに未反映であることを記録しておく。バックアップが完了すると、ホストコンピュータ２は再同期コマンドを発行して、ユーザボリューム６ａとセカンダリボリューム６ｂを再び二重化状態にもどす。この際にはユーザボリューム６ａの更新データでセカンダリボリューム６ｂに未反映のものをコピーする。
【００１５】
以上、本発明の概要について説明した。以下にこれを実現するための方法について具体的に説明する。
【００１６】
図３は本発明におけるシステム構成例である。一台以上のホストコンピュータ２では、アプリケーションプログラムや、ペアボリューム２０の制御、バックアップおよびリストアの実行、磁気テープライブラリ３の管理等をおこなうプログラムが走行する。ホストコンピュータ２は、他のホストコンピュータ２、ディスクシステム１、磁気テープライブラリ３と、ネットワーク１７により接続されていて、互いに通信が可能である。ここでネットワークとは、10BaseTや100BaseT等の一般的にＬＡＮ等で使用されるケーブルで接続されていて、通信にはTCP/IPやUDPなどのネットワークプロトコルにしたがって行われるものとする。ホストコンピュータ２はさらに、チャネルパス１２によりディスクシステム１に接続されている。チャネルパス１２の実例としては、ＳＣＳＩケーブルあるいはＦｉｂｒｅチャネルを想定する。なお以降の説明では、チャネルパス１２はファイバチャネルを前提とする。チャネルパス１２がファイバチャネルの場合は、ホストコンピュータ２とディスクシステム１がポイントツーポイントで接続されるケースや、ＦＣ−ＡＬと呼ばれるループ状に各装置（ノードと呼ぶ）が接続されるケースや、図３のようにスイッチ４を介在して接続されるケースなどがある。本発明はこの接続形態のいずれにも対応可能である。
【００１７】
テープ装置３はバックアップデータを格納するための装置である。テープ装置３の実現例としては、例えば磁気テープライブラリ、カートリッジテープ、ＤＶＤ（ライブラリ）装置、ＤＶＤ−ＲＡＩＤ装置、ＣＤ−ＲＷ、あるいはディスク装置等、あらゆる記憶媒体を適用できる。
【００１８】
ディスクシステム１は、データを格納する一台以上のディスク装置１５と、ディスク装置１５とホストコンピュータ２間のデータ転送を制御する制御装置５から構成される。ディスク装置１５とディスク制御装置５はチャネルパス１４により接続されている。本発明では、チャネルパス１４はＳＣＳＩケーブル、ファイバチャネルＩＢＭ社のＳＳＡを想定し、これらのインタフェースに迎合したディスク装置１５が使用される。また、近年では複数のディスク装置１５を一つのグループとして、このグループ上にボリューム６を分散配置するＲＡＩＤと呼ばれる手法が一般的になっている。本発明はディスクシステム１がＲＡＩＤを採用した場合でも適用可能である。
【００１９】
さて次に、ディスク制御装置５内の制御情報のうち、第一の実施例に関連するものを説明する。コピーパラメータ８は、ホストコンピュータ２から受領したコピーパラメータを格納するための領域である。差分ビットマップ９は、ボリューム６対応に存在し、ユーザボリューム６ａとセカンダリボリューム６ｂが分割された後、ボリューム６にホストコンピュータ２から更新があった場合に該当するビットがオンされる。本発明では、ブロック１７単位にビットを持ち、ブロック番号１がビット１に、ブロック番号２がビット２に、．．．と対応させる。もちろんブロック１７対応に１ビットを対応させる必要はなく、例えばｎブロック（ｎ＞１）単位に１ビットを対応させても構わない。このようにすることによって、差分ビットマップの容量を削減することも可能である。
【００２０】
コピーコマンドは、ＳＣＳＩ−２で標準化されているＣＯＰＹコマンドと、Legato社ホワイトペーパー"Celestra Architecture for Serverless Backups" および"Celestra Block Copy Interface Specification" (ともにwww.iguard.comより取得可能)に開示された従来技術で開示されたＣＣＯＰＹコマンドが一般的に知られている。本発明ではこれら両方に適用可能だが、以降の説明では、ＣＣＯＰＹコマンドを前提に説明する。なお、これらのコマンドの詳細については、「ＳＣＳＩ−２詳細解説」、菅谷誠一著、CQ出版社、ならびに"Celestra Block Copy Interface Specification"を参照されたい。
【００２１】
次に図４を使用して、バックアップ処理について説明する。
【００２２】
まずステップ４０で、ユーザまたは管理者は、ペアボリューム２０を形成する。このステップでは、ユーザボリューム６ａとセカンダリボリューム６ｂがユーザにより指定される。この要求を受領すると、ディスク制御装置５は、ユーザボリューム６ａからセカンダリボリューム６ｂへデータをコピーする。これ以降、ホストコンピュータ２からユーザボリューム６ａへ更新があると、更新データはセカンダリボリューム６ｂへコピーされ、二重化状態が保持される。
【００２３】
ステップ４１で、ユーザまたは管理者からのバックアップ指示があると、あるいはあらかじめスケジュールされていた時刻が到来すると、ホストコンピュータ２上ではバックアッププログラムが動作して、バックアップ処理モードに入る。バックアップ処理モードに入ってからステップ４６までの間、ホストコンピュータ２上で走行するコピープログラムは、アプリケーションプログラムからのユーザボリューム６ａへのアクセスを禁止する。
【００２４】
続いてホストコンピュータ２は、ステップ４２で、バックアップ対象のファイル１８を構成するブロック１７と、そのブロック１７を格納しているユーザボリュームを特定する。その後、ステップ４３で、Inqueryコマンド等を用いて当該ユーザボリューム６ａがペアを形成しているかどうかを調べる。ペアを形成している場合は、ステップ４４で分割コマンドを発行して、二重化状態を中断する。このコマンドをディスク制御装置５が受領すると、ユーザボリューム６ａに対する更新はセカンダリボリューム６ｂに反映されなくなり、その時点でセカンダリボリューム６ｂのデータは凍結される。
【００２５】
ペアの分割が完了すると、ホストコンピュータ２はステップ４５で、ファイル１８全体をバックアップするＣＣＯＰＹコマンドをセカンダリボリューム６ｂに対して発行する。このとき、アクセスするセカンダリボリューム６ｂは、ステップ４３でＩｎｑｕｅｒｙコマンドを発行したときに特定される。
【００２６】
ディスク制御装置５は、ステップ４５でＣＣＯＰＹコマンドを受領すると、ステップ４６で、まず指定されたボリューム６がセカンダリボリューム６ｂであり（つまりペアボリューム２０を構成しており）、かつペアが分割された状態かどうかを調べる。この条件に合致していない場合は、エラーをホストコンピュータ２へ報告し、バックアップ処理は行わない。合致している場合は、そのパラメータをコピーパラメータ８に格納してコマンド完了を返す。その後、コピーパラメータ８に格納された情報にしたがって、セカンダリボリューム６ｂからテープライブラリ装置３へのバックアップを実行する。ＣＣＯＰＹコマンドのパラメータには、コピー元（すなわちセカンダリボリューム６ｂ上）のブロックアドレスとブロック数と、これらのブロック１７を格納するテープ装置のポートアドレスとの組が含まれる。したがって、このパラメータにしたがって、セカンダリボリューム６ｂからブロック１７を読出し、指定されたポートアドレスに送信してやれば良い。ここで、ＣＣＯＰＹコマンドの完了報告は、バックアップ処理の開始を示すものであるため、注意すること（バックアップ完了を報告するものではない）。この段階では、バックアップの実行可能条件をチェックして、可能であれば、完了報告する。
【００２７】
ホストコンピュータ２は、ディスク制御装置５からＣＣＯＰＹコマンド完了を受領すると、ステップ４７で、ユーザボリューム６ａへのアクセスを再開させる。その後、ステップ４８で、バックアップが完了したかどうかをチェックし、もし完了していれば、ペア再同期コマンドを発行して、ペアボリューム２０を再び二重化状態へもどす。ディスク制御装置５は、再同期コマンドを受領すると、差分ビットマップ８にしたがって、差分データをユーザボリューム６ａからセカンダリボリューム６ｂへコピーする。
【００２８】
ステップ４３でユーザボリューム６ａがペアを形成していないことが分かると、ホストコンピュータ２はステップ４９で、通常のＣＣＯＰＹ処理を実行する。この処理については公知技術であるので、説明を省略する。
【００２９】
ディスク制御装置５は、ステップ４７で、ＣＣＯＰＹコマンドの実行可否をチェックした。もしホストコンピュータ２がペアボリューム２０を分割せずにＣＣＯＰＹコマンドを発行し、かつステップ４７のチェックを行わずにバックアップをおこなってしまったら、凍結データのバックアップを取得することはできない。すなわち本発明の本来の目的である、無矛盾なデータのバックアップが取得できないことになる。したがってこの処理は、ペアの分割および統合の機能に、ＣＣＯＰＹを使用したバックアップ処理を組み合わせる際の重要なステップである。
【００３０】
以上の処理によれば、ペアを分割することによってセカンダリボリューム６ｂのデータを凍結でき、このためホストコンピュータ２はファイル１８全体のバックアップを行うＣＣＯＰＹコマンドをセカンダリボリューム６ｂに対して発行できるようになる。このため、ＣＣＯＰＹコマンドは最初の一回だけ発行すればよく、ホストのＣＣＯＰＹコマンド発行負荷を低減できる。
【００３１】
以上で第一実施例の説明を終わるが、最後にこの効果についてまとめておく。第一実施例では、ペア分割を使用してＣＣＯＰＹによるダイレクトバックアップ方法について説明した。従来技術では、ファイル１８をいったんワークディスク６ｃへ格納した後、テープ装置３へバックアップしていた。また、ワークディスク６ｃへファイル１８をコピーする際には、複数のＣＣＯＰＹコマンドを発行していた。第一実施例では、ＣＣＯＰＹコマンドとペア分割・再同期を行う処理と組み合わせることにより、ホストコンピュータ２はファイル１８全体をバックアップするＣＣＯＰＹコマンドを一度だけ発行すれば済み、ホストのＩ／Ｏ発行負荷を低減できる。さらにセカンダリボリューム６ｂからテープ装置３へバックアップを行うので、ワークディスク６ｃへコピー処理が不要となり、バックアップ時間を短縮することができる。
【００３２】
第二実施例
次に第二の実施例について説明する。
【００３３】
第一の実施例では、ホストコンピュータ２はペア分割、バックアップ指示に続いて、バックアップ処理が完了した後、ペア再同期を指示していた。バックアップ処理の完了はInqueryコマンドをたびたび発行することにより、調べていた。本実施例は、これらの処理を無くし、ホストコンピュータ２のコマンド発行回数をさらに削減するためのものである。
【００３４】
図９に本実施例におけるホストコンピュータ２およびディスク制御装置５の処理フローを示す。なお、図９のステップ９０からステップ９５以外は図４の説明と同様なので、省略する。
【００３５】
ホストコンピュータ２は、ステップ９０で、ファイル全体をバックアップするＣＣＯＰＹコマンドをＡＵＴＯ指定で発行する。ここでＡＵＴＯ指定とは、ペアの分割、セカンダリボリューム６ｂからテープ装置３へのバックアップ、ペアの再同期までの一連の処理を、ディスクシステム１で自動的に実行するモードである。このモード指定には、ＣＣＯＰＹコマンドCDB(Command Descriptor Block)のリザーブ領域に１ビットを設ければ良い。
【００３６】
ディスク制御装置５が、ＡＵＴＯモード指定のＣＣＯＰＹコマンドを受領すると、ステップ９１でバックアップ対象のユーザボリューム６ａが、ペアを形成しているかどうか、すなわちセカンダリボリューム６ｂを有するかどうかをチェックする。もし、ペアを形成していなければ、ステップ９４で、ホストコンピュータ２に対してエラーを報告して処理を完了する。もしペアを形成していれば、ステップ９３で、ペアを分割した後、ステップ９４で、ＣＣＯＰＹコマンドの完了を報告し、セカンダリボリューム６ｂからテープ装置３へのバックアップ処理を実行する。
【００３７】
ステップ９４のＣＣＯＰＹ完了報告を契機に、ホストコンピュータ２はステップ４７で、アプリケーションプログラムのボリュームアクセスを再開させるが、この間もディスク制御装置５はバックアップを継続する。そしてＣＣＯＰＹコマンドで指定されたバックアップ処理が全て完了すると、ディスク制御装置５はステップ９５で、ペアを再同期させる。
【００３８】
以上の処理により、ＣＣＯＰＹコマンド発行契機で、ディスク制御装置５が、ペア分割、バックアップ、ペア再同期までの一連の処理を実行する。これら全ての処理はホストコンピュータ２に対して透過的なので、ペア状態の監視、制御などによるホストプログラムの複雑さから開放される。さらに本実施例から分かるように、ホストコンピュータ２はディスク制御装置５に対してＣＣＯＰＹコマンドを一度発行すればよく、コマンド発行回数を削減できる。
【００３９】
第三実施例
次に第三の実施例について説明する。
【００４０】
第一および第二の実施例では、ペアの分割および統合の単位はボリューム６であった。ところが実際にバックアップを実行するのはボリューム６上のごく一部の領域である。ボリューム全体を分割してしまうと、ホストコンピュータ２からの更新があれば差分ビットがオンされ、再同期時にコピー対象となってしまうので、再同期処理に時間がかかる。第二の実施例ではこれを解決するために、バックアップ対象の領域のみを分割する方法を開示する。さらにこの方法を用いると、あるユーザボリューム６ａに格納された各ファイル１８を任意の時点でバックアップすることが可能になる。すなわち、第一の実施例ではボリューム６を分割した時点でセカンダリボリューム６ｂが凍結される。そしてバックアップが完了し、ペアの再同期が行われるまでは、同一のユーザボリューム６ａに格納された別のファイル１８をバックアップすることができなかった。ところが本実施例の技術を適用すると、ペアボリューム２０はバックアップ対象のブロック１７毎に分割・再同期が行われるので、各ファイル１８毎に任意のタイミングでバックアップすることができる。以下、第二実施例の詳細について説明する。
【００４１】
この方法では、図３に示すように、ディスク制御装置５はペア分割ビットマップ１０をボリューム６対応に保持する。これはブロック１７対応のビットマップであり、分割コマンドにより指示されたブロック１７に対応するビットがオンされる。ホストコンピュータ２から更新があった場合には、ペア分割ビットマップ１０を見て、ライト対象のブロック１７のビットがオンなら、セカンダリボリューム６ｂへのコピーを行わない。そしてＣＣＯＰＹコマンドにより指示されたブロック１７を、セカンダリボリューム６ｂからテープ装置３へバックアップする。なお、ペア分割ビットマップ１０は連続したｎブロック対応に１ビットを割当てても構わない。
【００４２】
次に処理ステップの詳細を図４を用いて説明する。ステップ４０から４３まではこれまでの説明と同じである。ディスク制御装置５はステップ４４において、ステップ４２で特定されたブロック１７を分割するよう、ペア分割コマンドを発行する。
【００４３】
図５はペア分割・再同期コマンドのフォーマットを示す。ペア分割・再同期コマンドコード５０は、本コマンドに割当てられたコードを示す。分割要求ビット５１は本コマンドがペア分割か、それとも再同期かを示すビットである。パラメータリスト数５２は、ブロックアドレス・ブロック数５３がいくつ後続するかを示す。分割するブロック１７の個数と、それらのブロック１７が連続的にボリューム６上に割当てられているかどうかによって、可変である。ブロックアドレス・ブロック数５３は、分割するブロック１７がボリューム６上で連続だった場合に、そのブロック集合内の先頭ブロックアドレスと、ブロック数を格納する。
【００４４】
図６は、ペア分割コマンドを受領した時のディスク制御装置の処理を示す。ディスク制御装置５がペア分割コマンドを受領すると、ステップ６０で、ブロックアドレス・ブロック数５３から、分割対象のブロックアドレスを求め、ペア分割ビットマップ１０の対応するビットをオンする。この処理以降、当該ボリューム６はステップ６１で示したペア分割モードに入る。ボリューム６がペア分割モードにあるとき、ステップ６２においてホストコンピュータ２からライトコマンドを受領すると、 ステップ６３で、ライト対象ブロック１７が分割対象かどうかを、ペア分割ビットマップ１０を参照して調べる。ライトコマンドには、ライト対象の先頭ブロック１７と、ライトするブロック１７数がパラメータに含まれるので、これよりライト対象ブロック１７を求めて、対応するビットがオンかどうかを調べれば良い。もし分割対象ならば、ステップ６４で、差分ビットマップ９の対象ビットをオンした後、ユーザボリューム６ａに書込みを行う。ステップ６３で分割対象でなければ、ステップ６５で、ユーザボリューム６ａとセカンダリボリューム６ｂの両方へ書込みを行う。
【００４５】
以上、ペア分割コマンドを受領した時のディスク制御装置５の処理について説明した。再び図４に戻る。ステップ４５および４６は以前の説明と同様である。これらのステップにより、ファイル１８がセカンダリボリューム６ｂからテープ装置３へバックアップされる。バックアップが完了し、ステップ４７でペアの再同期を行う。ペアの再同期の際には、図５で説明したペア分割・再同期コマンドを使用するが、分割要求ビット５１は０とする（これによりペア再同期を示す）。
【００４６】
図７はペア再同期コマンドを受領した時のディスク制御装置５の処理フローを示す。ペア再同期コマンドを受領すると、ディスク制御装置５は本コマンドで受領した全てのブロック１７に対してステップ７０以降の処理を実行する。まずステップ７０で、当該ブロック１７に対応するペア分割ビットマップ１０のビットがオンかどうかを調べ、もしオンなら、ステップ７１で、差分ビットマップ９の対応するビットがオンかどうかを調べる。これもオンなら、差分データが存在することになるので、ステップ７２で、当該ブロック１７をユーザボリューム６ａからセカンダリボリューム６ｂへコピーする。そしてステップ７３および７４で、差分ビットおよびペア分割ビットをオフする。その後ステップ７５で、全てのペア分割ビットがオフになっていたら、当該ボリューム６のペア分割モードを解除する。これによって、以降のホストコンピュータ２からの全てのライトデータは、ユーザボリューム６ａおよびセカンダリボリューム６ｂの両方に書込まれる。以上によりペア再同期処理が完了する。
【００４７】
以上、第三実施例でも、ホストコンピュータ２は、ペア分割コマンド、ＣＣＯＰＹコマンド、ペア再同期コマンドの３つのコマンドを送信していた。このコマンドに伴う一連の処理は定型的なものなので、第二の実施例と同様に、一つのＣＣＯＰＹコマンドによりこれらの処理を行わせることができる。つまり、ホストコンピュータ２がＣＣＯＰＹコマンドを発行すると、ディスク制御装置５は、本コマンドで指定されたブロック１７に関してペア分割、バックアップ、ペア統合を実行するわけである。この方法により、ホストコンピュータ２のコマンド発行回数を一回に削減することが可能となる。
【００４８】
これで第三実施例の説明を終わるが、最後にこの効果についてまとめておく。第三実施例では、ペアボリューム２０をブロック１７単位にペア分割する方法について説明した。この方法によると、ペア分割中は分割対象のブロック１７のみが差分管理されるため、再同期にかかる時間が短くて済む。また、ペア分割モード中でも、新たなペア分割コマンドを受領すると、図６に示した処理を実行することによって、他のブロック１７に関してペア分割できる。このため、同一ユーザボリューム６ａに格納された任意のファイル１８を任意の時点でバックアップすることができる。
【００４９】
次に第四の実施例として、本発明における他の構成例を図８を用いて説明する。図８では、２台のディスクシステム１ａおよび１ｂと、これらを接続するチャネルパス８０から構成される。さらにスイッチ４ａおよびスイッチ４ｂはチャネルパス８１により接続され、スイッチ間でデータの送受信が可能である。ディスクシステム１ａはユーザボリューム６ａを有し、ディスクシステム１ａに接続したホストコンピュータ２ａでは、オンライン処理等のアプリケーションプログラムを実行する。他方、ディスクシステム２ｂはセカンダリボリューム６ｂを有し、ディスクシステム２ｂに接続したホストコンピュータ２ｂでは、テープ装置３の制御を行う。すなわち本構成では、遠隔地に設置された2台のディスクシステム１ａおよび１ｂ間でペアボリューム２０を構成している。ホストコンピュータ２ａからユーザボリューム６ａに対して更新があると、ディスクシステム１ａと１ｂを接続するチャネルパス８０を介してライトデータが転送され、セカンダリボリューム６ｂに更新データが反映される。あるいはディスクシステム１ａからスイッチ４ａへ、さらにスイッチ４ａからチャネルパス８１経由でスイッチ４ｂへ、そしてスイッチ４ｂからディスクシステム１ｂへライトデータが送信され、最終的にはセカンダリボリューム６ｂへ書込まれる。このようにして二重化状態が保持される。
【００５０】
以上のような構成においても、第一、第二、第三の実施例で説明した方式を適用できる。すなわち、バックアップの際にはペアを分割した後、ディスクシステム１ｂが、セカンダリボリューム６ｂからテープ装置３へバックアップを行う。また、ブロック１７毎にペア分割を行う場合でも、ディスクシステム１ａはペア分割ビットマップ１０を利用して、分割が指示されたブロック１７については、ディスクシステム１ｂへライトデータを転送しない。
【００５１】
他の実現例として、図８において、ディスクシステム１ｂのボリューム６ｂと６ｃをさらに二重化する場合を考える。したがって、ボリューム６ａ、６ｂ、６ｃは、同一データを保持する三重化状態である。バックアップの際に、ボリューム６ｂとボリューム６ｃ間のペアを分割した後、ボリューム６ｃからテープ装置３へバックアップを行っても良い。
【００５２】
続いて第五の実施例として、スイッチ４がＣＣＯＰＹコマンドを解釈し、バックアップ処理を実行する方法について説明する。本実施例の概要を図１０に示す。この場合、ホストコンピュータ２は、まずペア分割コマンドをディスク制御装置５に対して発行し、その後、スイッチ４に対してＣＣＯＰＹコマンドを発行する。この際に、ＣＣＯＰＹコマンドのパラメータとして、コピー元となるディスクシステム１に接続されたチャネルパス１２のポートアドレスと、ボリューム６ｂのアドレス、バックアップするテープ装置３のアドレスを指定する。スイッチ４はＣＣＯＰＹコマンドを解釈し、コピー処理を実行する機能を有する。本機能により、スイッチ４はボリューム６ｂからバックアップ対象のデータを読出し、それをテープ装置３へ格納していく。ＣＣＯＰＹコマンドにより指定された全てのブロックをテープ装置３へ格納すると、処理を完了する。
【００５３】
ボリューム６ａと６ｂはスプリットされているので、ボリューム６ｂからテープ装置３へデータをバックアップしている間も、ホストコンピュータ２からボリューム６ａへのアクセスは継続できる。
【００５４】
図１１は第六の実施例を示す。本実施例では、テープ装置３がＣＣＯＰＹコマンドを解釈し、バックアップ処理を実行する方法に関するものである。この場合、この場合、ホストコンピュータ２は、まずペア分割コマンドをディスク制御装置５に対して発行し、その後、テープ装置３に対してＣＣＯＰＹコマンドを発行する。この際に、ＣＣＯＰＹコマンドのパラメータとして、コピー元となるディスクシステム１に接続されたチャネルパス１２のポートアドレスと、ボリューム６ｂのアドレス、バックアップするテープ装置３のアドレスを指定する。テープ装置３はＣＣＯＰＹコマンドを解釈し、コピー処理を実行する機能を有する。本機能により、テープ装置３はボリューム６ｂからバックアップ対象のデータを読出し、それをテープ装置３へ格納していく。ＣＣＯＰＹコマンドにより指定された全てのブロックをテープ装置３へ格納すると、処理を完了する。
【００５５】
ボリューム６ａと６ｂはスプリットされているので、ボリューム６ｂからテープ装置３へデータをバックアップしている間も、ホストコンピュータ２からボリューム６ａへのアクセスは継続できる。
【００５６】
【発明の効果】
以上、説明したように、本発明によれば、アプリケーションプログラムのライト処理待ち時間を最小にするとともに、ＣＣＯＰＹコマンドの発行回数を最小にして、ホストコンピュータのＩ／Ｏ発行負荷を低減できる。また、バックアップ時のワークボリューム６ｃへのデータコピーを無くして、バックアップ時間を短縮できる。
【図面の簡単な説明】
【図１】本発明の概要図である。
【図２】第一従来技術の概要図である。
【図３】本発明におけるシステム構成である。
【図４】バックアップ処理フローである。
【図５】ペア分割・再同期コマンド形式である。
【図６】ペア分割コマンド受領時のディスク制御装置の処理フローである。
【図７】ペア再同期コマンド受領時のディスク制御装置の処理フローである。
【図８】本発明における他のシステム構成例である。
【図９】ＣＣＯＰＹコマンド・ＡＵＴＯモード指定時のバックアップ処理フローである。
【図１０】第五実施例の概要図である。
【図１１】第六実施例の概要図である。
【図１２】第二従来技術の概要図である。
【符号の説明】
１…ディスクシステム、２…ホストコンピュータ、３…テープ装置、４…スイッチ、５…ディスク制御装置、６…ボリューム、６ａ…ユーザボリューム、６ｂ…セカンダリボリューム、８…コピーパラメータ、９…差分ビットマップ、１０…ペア分割ビットマップ、１２…チャネルパス、１３…ネットワーク、１４…ディスク接続パス、１５…ディスク装置、１７…ブロック、１８…ファイル、２０…ペアボリューム。
Claims (9)
- バックアップ装置と、コンピュータとに接続される記憶装置システムであって、
第 1 のボリュームと、
前記第1のボリュームに記憶されるデータのコピーを格納する第2のボリュームと、前記第 1 のボリュームと前記第 2 のボリュームへのアクセスを制御する、前記コンピュータと接続される制御装置とを有し、
前記制御装置は、
前記コンピュータから更新命令を受信すると、前記第 1 のボリュームに格納されているデータを更新し、前記第 1 のボリュームに格納された更新データのコピーを前記第２のボリュームに格納し、
前記コンピュータから分割命令を受信すると、前記分割命令を受信した後、前記第1のボリュームに格納される更新データのコピーを、前記第2のボリュームに格納することを中断し、
前記コンピュータからボリュームの指定を含むコピー命令を受信すると、コンピュータから指定されたボリュームが、前記第 2 のボリュームであり、かつ前記第 2 のボリュームへの前記第 1 のボリュームに格納される更新データのコピーが中断されているかを確認し、
前記コンピュータから指定されたボリュームが、前記第 2 のボリュームであり、かつ、前記第 2 のボリュームに対し前記第 1 のボリュームに格納される更新データのコピーが中断されている場合は、前記コンピュータを介さずに、前記コンピュータから指定されたボリュームに格納されているデータを前記バックアップ装置に転送し、
前記コンピュータから指定されたボリュームが、前記第2のボリュームでない、または、前記第 2 のボリュームに対し前記第 1 のボリュームに格納される更新データのコピーが中断されていない場合は、前記コンピュータに対し、エラーを報告することを特徴とする記憶装置システム。 - 請求項１記載の記憶装置システムであって、
前記制御装置は、更新命令に基づく前記第1のボリュームに格納されているデータの更新と、
前記コンピュータから指定されたボリュームに格納されているデータの前記バックアップ装置への転送を並行して実行することを特徴とする記憶装置システム。 - 請求項1記載の記憶装置システムであって、
前記制御装置は、前記分割命令を受信した後に、更新命令に基づいてデータが更新された前記第1の記憶装置内の記憶領域を示すビットマップを有することを特徴とする記憶装置システム。 - 請求項３記載の記憶装置システムであって、
前記制御装置は、前記第2のボリュームに格納されているデータの前記バックアップ装置への転送が完了した後、前記コンピュータから再同期命令を受信し、
前記ビットマップを用いて、前記分割命令を受信した後に更新された前記第1のボリューム内に格納されている更新データのコピーを前記第2の記憶装置に格納することを特徴とする記憶装置システム。 - 請求項1記載の記憶装置システムであって、
前記分割命令は、前記第１のボリュームの一部記憶領域を特定する情報を含み、
前記制御装置は、分割命令受信後、更新命令に基づき、分割命令によって特定された一部記憶領域に格納された更新データを前記第2のボリュームに格納することを中断することを特徴とする記憶装置システム。 - 請求項１記載の記憶装置システムであって、
前記コピー命令は、第2のボリュームの一部記憶領域を特定する情報を含み、
前記制御装置は、前記第2のボリューム内のコピー命令により特定された一部記憶領域に格納されているデータを前記バックアップ装置に転送することを特徴とする記憶装置システム。 - 請求項５記載の記憶装置システムであって、
前記制御装置は、分割命令を受信した後に、更新命令に基づいてデータが更新された、分割命令により特定された一部記憶領域内の記憶領域を示すビットマップを有することを特徴とする記憶装置システム。 - 請求項１記載の記憶装置システムであって、
前記制御装置は、分割命令を受信した後、前記第2のボリュームに格納されているデータの前記バックアップ装置への転送の完了前に、
前記コンピュータにバックップの完了を報告することを特徴とする記憶装置システム。 - バックアップ装置とコンピュータに接続される記憶装置システムであって、
第１のボリュームと、
前記第1のボリュームに格納されるデータのコピーを格納する第2のボリュームと、
前記第1のボリュームと前記第2のボリュームを制御する、前記コンピュータと接続される制御装置とを有し、
前記制御装置は、前記コンピュータからの更新命令を受信すると、前記第1のボリュームに格納されているデータを更新し、前記第1のボリュームに格納される更新データのコピーを第2のボリュームに格納して、前記コンピュータから書き込まれるデータが格納される前記第1のボリュームと前記コンピュータから書き込まれるデータのコピーが格納される前記第2のボリュームとでペアを形成し、
前記コンピュータからボリュームの指定を含むコピー命令を受信すると、
前記コピー命令により指定されるボリュームとペアであるボリュームが存在するかどうかを確認し、
前記コピー命令により指定されるボリュームとペアであるボリュームが存在する場合は、前記第1のボリュームに格納される更新データのコピーを、前記第2のボリュームに格納することを中断し、
前記コンピュータを介さずに、前記第2のボリュームに格納されているデータを前記バックアップ装置に転送し、
バックアップが完了したら、前記第1のボリュームに格納される更新データのコピーを、前記第2のボリュームに格納することを中断した後に、前記第1のボリュームに格納されたデータのコピーを前記第2のボリュームに格納し、
前記コピー命令により指定されるボリュームとペアであるボリュームが存在しない場合は、前記コンピュータに対し、エラーを報告することを特徴とする記憶装置システム。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP15338699A JP3726559B2 (ja) | 1999-06-01 | 1999-06-01 | ダイレクトバックアップ方法および記憶装置システム |
| DE60043873T DE60043873D1 (de) | 1999-06-01 | 2000-05-29 | Verfahren zur Datensicherung |
| EP00111511A EP1058190B1 (en) | 1999-06-01 | 2000-05-29 | Data backup method |
| US09/584,319 US6836830B1 (en) | 1999-06-01 | 2000-05-31 | Method of data backup in a computer system and a storage system therefor |
| US10/893,884 US6981115B2 (en) | 1999-06-01 | 2004-07-20 | Method of data backup in a computer system and a storage system therefor |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP15338699A JP3726559B2 (ja) | 1999-06-01 | 1999-06-01 | ダイレクトバックアップ方法および記憶装置システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000347811A JP2000347811A (ja) | 2000-12-15 |
| JP3726559B2 true JP3726559B2 (ja) | 2005-12-14 |
Family
ID=15561356
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP15338699A Expired - Fee Related JP3726559B2 (ja) | 1999-06-01 | 1999-06-01 | ダイレクトバックアップ方法および記憶装置システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3726559B2 (ja) |
Families Citing this family (62)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6938122B2 (en) | 2001-01-23 | 2005-08-30 | Emc Corporation | Remote mirroring in a switched environment |
| JP4078039B2 (ja) * | 2001-03-21 | 2008-04-23 | 株式会社東芝 | スナップショットイメージの世代管理方法及び世代管理装置 |
| JP2003006020A (ja) | 2001-06-26 | 2003-01-10 | Hitachi Ltd | 複製データベースアクセス装置とそのアクセス方法 |
| US7346623B2 (en) | 2001-09-28 | 2008-03-18 | Commvault Systems, Inc. | System and method for generating and managing quick recovery volumes |
| JP2004046435A (ja) * | 2002-07-10 | 2004-02-12 | Hitachi Ltd | バックアップ方法、その方法に用いた記憶制御装置 |
| JP4186537B2 (ja) | 2002-07-23 | 2008-11-26 | 株式会社日立製作所 | ディスクアレイシステムのバックアップ方法 |
| EP1579331A4 (en) | 2002-10-07 | 2007-05-23 | Commvault Systems Inc | SYSTEM AND METHOD FOR MANAGING SAVED DATA |
| ATE557349T1 (de) * | 2002-10-31 | 2012-05-15 | Parallel Iron Llc | Speichersystem und verfahren für ein speichersystem |
| JP4199993B2 (ja) | 2002-11-27 | 2008-12-24 | 株式会社日立製作所 | スナップショット取得方法 |
| JP4704660B2 (ja) | 2002-12-18 | 2011-06-15 | 株式会社日立製作所 | 記憶デバイス制御装置の制御方法、記憶デバイス制御装置、及びプログラム |
| JP4433372B2 (ja) | 2003-06-18 | 2010-03-17 | 株式会社日立製作所 | データアクセスシステム及び方法 |
| JP4559046B2 (ja) * | 2003-08-04 | 2010-10-06 | 株式会社日立製作所 | 仮想テープライブラリ装置 |
| JP4863605B2 (ja) | 2004-04-09 | 2012-01-25 | 株式会社日立製作所 | 記憶制御システム及び方法 |
| CA2548542C (en) | 2003-11-13 | 2011-08-09 | Commvault Systems, Inc. | System and method for performing a snapshot and for restoring data |
| GB2423850B (en) | 2003-11-13 | 2009-05-20 | Commvault Systems Inc | System and method for performing integrated storage operations |
| JP4581518B2 (ja) * | 2003-12-19 | 2010-11-17 | 株式会社日立製作所 | スナップショット取得方法 |
| JP4790283B2 (ja) * | 2005-02-22 | 2011-10-12 | 株式会社日立製作所 | ストレージサブシステム及びストレージシステム |
| US7194486B2 (en) | 2004-06-03 | 2007-03-20 | Hitachi, Ltd. | Method and system for data processing with data replication for the same |
| JP4575762B2 (ja) * | 2004-06-03 | 2010-11-04 | 株式会社日立製作所 | データ処理方法および装置並びにストレージ装置およびその処理プログラム |
| JP4508798B2 (ja) * | 2004-08-09 | 2010-07-21 | 株式会社日立製作所 | ストレージリモートコピー方式 |
| US8959299B2 (en) | 2004-11-15 | 2015-02-17 | Commvault Systems, Inc. | Using a snapshot as a data source |
| JP4575119B2 (ja) * | 2004-11-25 | 2010-11-04 | 株式会社日立製作所 | ストレージシステム |
| US7487386B2 (en) * | 2005-03-30 | 2009-02-03 | International Business Machines Corporation | Method for increasing file system availability via block replication |
| JP2006293850A (ja) * | 2005-04-13 | 2006-10-26 | Hitachi Ltd | リモートコピーシステムおよびリモートコピー方法 |
| JP4733431B2 (ja) * | 2005-06-01 | 2011-07-27 | 株式会社日立製作所 | リモートコピーの初期コピーシステムおよび初期コピー方法ならびに記憶装置 |
| US7651593B2 (en) | 2005-12-19 | 2010-01-26 | Commvault Systems, Inc. | Systems and methods for performing data replication |
| CA2632935C (en) | 2005-12-19 | 2014-02-04 | Commvault Systems, Inc. | Systems and methods for performing data replication |
| US7606844B2 (en) | 2005-12-19 | 2009-10-20 | Commvault Systems, Inc. | System and method for performing replication copy storage operations |
| JP4833734B2 (ja) * | 2006-05-19 | 2011-12-07 | 株式会社日立製作所 | データベースシステム、ストレージ装置、初期コピー方法及びログ適用方法 |
| JP5222469B2 (ja) | 2006-10-11 | 2013-06-26 | 株式会社日立製作所 | 記憶システム及びデータ管理方法 |
| JP4771916B2 (ja) * | 2006-11-15 | 2011-09-14 | 富士通株式会社 | データ格納制御装置、データ格納制御方法、データ格納制御プログラムおよびデータ記憶システム |
| JP5207637B2 (ja) * | 2007-02-23 | 2013-06-12 | 株式会社日立製作所 | 一以上のセカンダリストレージシステムで複数のバックアップを取得するバックアップ制御方法 |
| WO2009013833A1 (ja) * | 2007-07-26 | 2009-01-29 | Fujitsu Limited | 記録制御装置、記録装置、記録システム及び記録制御プログラム |
| JP4620134B2 (ja) * | 2008-01-30 | 2011-01-26 | 株式会社日立製作所 | 記憶デバイス制御装置の制御方法及び記憶デバイス制御装置 |
| US8204859B2 (en) | 2008-12-10 | 2012-06-19 | Commvault Systems, Inc. | Systems and methods for managing replicated database data |
| US9092500B2 (en) | 2009-09-03 | 2015-07-28 | Commvault Systems, Inc. | Utilizing snapshots for access to databases and other applications |
| US8719767B2 (en) | 2011-03-31 | 2014-05-06 | Commvault Systems, Inc. | Utilizing snapshots to provide builds to developer computing devices |
| US8595191B2 (en) | 2009-12-31 | 2013-11-26 | Commvault Systems, Inc. | Systems and methods for performing data management operations using snapshots |
| WO2011082132A1 (en) | 2009-12-31 | 2011-07-07 | Commvault Systems, Inc. | Systems and methods for analyzing snapshots |
| US8504515B2 (en) | 2010-03-30 | 2013-08-06 | Commvault Systems, Inc. | Stubbing systems and methods in a data replication environment |
| US9471578B2 (en) | 2012-03-07 | 2016-10-18 | Commvault Systems, Inc. | Data storage system utilizing proxy device for storage operations |
| US9298715B2 (en) | 2012-03-07 | 2016-03-29 | Commvault Systems, Inc. | Data storage system utilizing proxy device for storage operations |
| US9342537B2 (en) | 2012-04-23 | 2016-05-17 | Commvault Systems, Inc. | Integrated snapshot interface for a data storage system |
| JP5333639B2 (ja) * | 2012-10-19 | 2013-11-06 | 富士通株式会社 | ストレージ装置、ストレージ装置制御方法およびストレージ装置制御プログラム |
| JP6070146B2 (ja) * | 2012-12-14 | 2017-02-01 | 富士通株式会社 | 情報処理装置及びバックアップ方法 |
| US9336226B2 (en) | 2013-01-11 | 2016-05-10 | Commvault Systems, Inc. | Criteria-based data synchronization management |
| US9886346B2 (en) | 2013-01-11 | 2018-02-06 | Commvault Systems, Inc. | Single snapshot for multiple agents |
| JP5839727B2 (ja) * | 2013-08-06 | 2016-01-06 | 株式会社日立製作所 | 記憶制御システム及び方法 |
| WO2015037078A1 (ja) * | 2013-09-11 | 2015-03-19 | 富士通株式会社 | 情報処理装置、バックアッププログラム、バックアップ方法 |
| US9495251B2 (en) | 2014-01-24 | 2016-11-15 | Commvault Systems, Inc. | Snapshot readiness checking and reporting |
| US9639426B2 (en) | 2014-01-24 | 2017-05-02 | Commvault Systems, Inc. | Single snapshot for multiple applications |
| US9753812B2 (en) | 2014-01-24 | 2017-09-05 | Commvault Systems, Inc. | Generating mapping information for single snapshot for multiple applications |
| US9632874B2 (en) | 2014-01-24 | 2017-04-25 | Commvault Systems, Inc. | Database application backup in single snapshot for multiple applications |
| US10042716B2 (en) | 2014-09-03 | 2018-08-07 | Commvault Systems, Inc. | Consolidated processing of storage-array commands using a forwarder media agent in conjunction with a snapshot-control media agent |
| US9774672B2 (en) | 2014-09-03 | 2017-09-26 | Commvault Systems, Inc. | Consolidated processing of storage-array commands by a snapshot-control media agent |
| US9648105B2 (en) | 2014-11-14 | 2017-05-09 | Commvault Systems, Inc. | Unified snapshot storage management, using an enhanced storage manager and enhanced media agents |
| US9448731B2 (en) | 2014-11-14 | 2016-09-20 | Commvault Systems, Inc. | Unified snapshot storage management |
| US10311150B2 (en) | 2015-04-10 | 2019-06-04 | Commvault Systems, Inc. | Using a Unix-based file system to manage and serve clones to windows-based computing clients |
| US10503753B2 (en) | 2016-03-10 | 2019-12-10 | Commvault Systems, Inc. | Snapshot replication operations based on incremental block change tracking |
| US10732885B2 (en) | 2018-02-14 | 2020-08-04 | Commvault Systems, Inc. | Block-level live browsing and private writable snapshots using an ISCSI server |
| US11042318B2 (en) | 2019-07-29 | 2021-06-22 | Commvault Systems, Inc. | Block-level data replication |
| US11809285B2 (en) | 2022-02-09 | 2023-11-07 | Commvault Systems, Inc. | Protecting a management database of a data storage management system to meet a recovery point objective (RPO) |
-
1999
- 1999-06-01 JP JP15338699A patent/JP3726559B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000347811A (ja) | 2000-12-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3726559B2 (ja) | ダイレクトバックアップ方法および記憶装置システム | |
| US6981115B2 (en) | Method of data backup in a computer system and a storage system therefor | |
| US7971097B2 (en) | Data restoring method and an apparatus using journal data and an identification information | |
| US6304980B1 (en) | Peer-to-peer backup system with failure-triggered device switching honoring reservation of primary device | |
| JP3868708B2 (ja) | スナップショット管理方法及び計算機システム | |
| EP1734450B1 (en) | Storage system and replication creation method thereof | |
| US7464236B2 (en) | Storage system and storage management method | |
| US7103713B2 (en) | Storage system, device and method using copy-on-write for synchronous remote copy | |
| US20030177306A1 (en) | Track level snapshot | |
| US20070050574A1 (en) | Storage system and storage system management method | |
| JPH07248988A (ja) | 記憶制御装置及び関連する方法 | |
| JP2002297456A (ja) | バックアップ処理方法及びその実施システム並びにその処理プログラム | |
| US7069400B2 (en) | Data processing system | |
| US20050108470A1 (en) | Tape mirror interface | |
| JP2001125815A (ja) | バックアップデータ管理システム | |
| JP2006285336A (ja) | 記憶装置及びストレージシステム並びにその制御方法 | |
| JP3937878B2 (ja) | 磁気テープ装置及びその制御方法並びに磁気テープ装置制御用プログラム | |
| JP3882467B2 (ja) | 記憶装置システムのスナップショット管理方法 | |
| JP2003173240A (ja) | 記憶装置システム及びそのデータバックアップ方法 | |
| JP4122724B2 (ja) | データの複製方法及び情報処理システム | |
| JP2000305719A (ja) | 情報処理システムにおけるデータのバックアップ方法 | |
| JP2000227868A (ja) | バックアップ取得方法および計算機システム | |
| JP2021174392A (ja) | リモートコピーシステム及びリモートコピー管理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040210 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040309 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040420 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050412 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050603 |
|
| 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: 20050906 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050919 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091007 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091007 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101007 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111007 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121007 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121007 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131007 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |