JP2008065392A - ストレージ装置及びこれを用いたデータのバックアップ方法 - Google Patents

Abstract

【課題】本発明は、バックアップウィンドウが比較的小さく設定されたシステムやユーザの例外的な使用状況においても、バックアップの取りこぼしを防止し、効率的なバックアップを行うことができるストレージ装置を提供することを課題とする。
【解決手段】本発明は、バックアップウィンドウ内のある時点におけるログオフやログイン要求をトリガとして、データを格納したボリュームに対してスナップショットを行い、さらに、当該取得したスナップショットに基づいてボリュームのレプリカを作成するストレージ装置である。ストレージ装置は、データの整合性の観点から、ログイン要求があった場合、スナップショットが作成されるまで、セッション確立のための処理は一時的に保留され、スナップショットが作成された後に、ログイン要求に基づくセッション確立のための処理が再開される。この場合、ボリュームのレプリカは、バックグラウンドで作成される。
【選択図】図１

Description

本発明は、ストレージ装置及びこれを用いたデータのバックアップ方法に関し、特に、ネットワークを介して接続されたホスト装置からアクセスされるストレージ装置におけるデータのバックアップ技術に関する。

コンピュータシステムにおけるデータの破損・消失を防止するため、ストレージ装置に記憶されたデータのバックアップを定期的に行うことは重要である。データのバックアップは、典型的には、保全されるべきデータボリューム（以下、単に「ボリューム」という。）の全部又は一部を定期的に別の格納場所にコピーして、そのレプリカ（バックアップデータ）を作成することで成される。データが破損・消失した場合には、バックアップされたデータを元の場所に戻すことにより、消失する前のデータボリュームを復元することができる。

スナップショットもまた、データのバックアップに用いられる技術として知られている。スナップショットは、ある時点におけるボリュームについてのデータイメージを保存する技術である。例えば障害によりデータが消失した場合であっても、保存されたスナップショットイメージを参照することによって、消失する前のボリュームを復元することができる。スナップショットは、データの実体を単にコピーしてレプリカを作成する手法よりも高速に、その時点におけるボリュームを保全することができる。

スナップショット技術を用いた一つの例として、下記特許文献１には、独立の二重化された記憶領域のうち一方を通常のアクセス用としてコンピュータに提供し、他方をスナップショットイメージの取得のために用いる技術が開示されている。

保全すべきデータのバックアップ作業中にデータの書き換えが発生するとデータの整合性が失われてしまうため、バックアップ作業中にデータの書き換えが行われないことを保証する必要がある。したがって、データの整合性の観点から、一般に、ボリュームに対するアクセスが行われない時間帯、例えば深夜や休日に、ボリュームの使用状態を検査した後、未使用の状態にあるボリュームに対してコピーを行う。

バックアップのスケジューリングの観点から、データのバックアップが可能な時間範囲をバックアップウィンドウと呼ぶことがある。データのバックアップは、その開始から終了までのすべての処理をバックアップウィンドウの中で行われる必要がある。

データのバックアップ処理にはある程度の時間を要するために、バックアップウィンドウが小さい場合や、バックアップの対象となるボリューム数（またはデータ量）が多い場合、バックアップウィンドウ内でバックアップ処理を終了させることができないおそれがある。このため、下記特許文献２に示されるように、保全すべきデータの重要度やストレージ装置の信頼度に基づいてバックアップのスケジューリングを行う技術が開示されている。
特開２００１-３０６４０７号公報 特開２００２-２９７４２７号公報

バックアップ処理は、バックアップを行った時点までのボリュームを復元できるのみであるため、バックアップが完了してから次のバックアップの開始までの期間が長いと、その間に書き換えられたデータを復元できない。一方、頻繁にバックアップを行うと、システムのパフォーマンスが低下するばかりでなく、バックアップに関わるコストの上昇を招く要因となる。リカバリポイント目標（ＲＰＯ：Recovery Point Objective）は、バックアップ処理の頻度を示す指標であり、ＲＰＯをどのように設定するかは、ストレージ装置の運用コストに関わってくる。

ストレージ装置を導入・運用するに際して、バックアップの低コスト化が要求される。複数のパーソナルコンピュータのそれぞれに一又は複数のボリュームを提供するようなストレージ装置を用いたあるシステムにおいては、バックアップの低コスト化の観点から、例えば、ＲＰＯを１日１回程度に設定し、また、できる限り多くのボリュームに対して１つのバックアップモジュールがバックアップ処理を担うことでコストを低く抑えることができる。

しかしながら、このようなＲＰＯのバックアップポリシーに従うシステムでは、例えば、ユーザが夜遅くまでコンピュータを操作し、翌朝早くにそれを立ち上げるような例外的な使用状況等、バックアップウィンドウを浸食するような行動があった場合には、予め定められたバックアップのスケジュールに適合せず、いわゆるバックアップの「取りこぼし」が発生するという事態が生じるおそれがある。また、１つのバックアップモジュールが多くのデータボリュームに対するバックアップを行うと、バックアップすべきデータ量の多さからバックアップウィンドウ内で処理しきれないおそれもある。

上記課題を解決するために、本発明は、バックアップスケジュールに従い、ある時点におけるログインやログオフ要求のようなセッションに関わる要求に基づいて、データを格納したボリュームに対してスナップショットを行ってスナップショットイメージを取得し、さらに、当該取得したスナップショットイメージに基づいてボリュームのレプリカを作成する。

ログイン要求があった場合、スナップショットイメージが取得されるまで、セッション確立のための処理は一時的に保留され、スナップショットイメージが取得された後に、ログイン要求に基づくセッション確立のための処理が再開される。

一方、ログオフ要求があった場合、セッション切断のための処理を行った後、スナップショットを行ってスナップショットイメージを取得する。

スナップショットイメージを取得したボリュームについては、適宜に、当該スナップショットイメージに基づいてレプリカの作成が行われる。

すなわち、本発明のある観点によれば、ホスト装置に接続されるストレージ装置は、１又は複数のボリュームが形成されたディスクデバイスと、当該ディスクデバイスに対する制御を行うコントローラユニットと、を備える。当該コントローラユニットは、当該ホスト装置から送られる所定のボリュームに対するセッションに関わる要求に基づいて、当該所定のボリュームに対してスナップショットを行ってスナップショットイメージを取得し、当該取得したスナップショットイメージに基づいてレプリカを作成する。

また、本発明のある観点によれば、ホスト装置に接続されるストレージ装置におけるデータのバックアップ方法は、ストレージ装置のディスクデバイス上に形成された所定のボリュームに対するセッションに関わる要求を当該ホスト装置から受け付けるステップと、当該セッションに関わる要求に基づいて、当該所定のボリュームに対するスナップショットを行ってスナップショットイメージを取得するステップと、当該取得したスナップショットイメージに基づいて前記所定のボリュームに対するレプリカを作成するステップと、を含む。

本発明によれば、バックアップウィンドウが比較的小さく設定されたシステムやユーザの例外的な使用状況においても、バックアップの取りこぼしを防止することができる。また、多数のデータボリュームに対しても、バックアップウィンドウ内で効率的にバックアップを行うことができるようになる。

次に、本発明の実施の形態について、図面を参照しつつ説明する。

図１は、本発明の一実施形態に係るストレージシステム１におけるデータのバックアップ処理を説明する概念図である。

本発明は、バックアップウィンドウ内（正確にはバックアップウィンドウ内のみに限られない。）のある時点におけるログインやログオフ要求のようなセッションに関わる要求に基づいて、データを格納したボリュームに対してスナップショットを行ってスナップショットイメージを取得し、さらに、当該取得したスナップショットイメージに基づいてボリュームのレプリカを作成するシステム又は方法である。

本実施形態では、データの整合性の観点から、ログイン要求があった場合、スナップショットイメージが取得されるまで、セッション確立のための処理は一時的に保留され、スナップショットイメージが取得された後に、ログイン要求に基づくセッション確立のための処理が再開される。この場合、ボリュームのレプリカは、バックグラウンドで作成される。

同図には、複数のホスト装置３にネットワーク２を介して接続されたストレージ装置４を含むストレージシステム１が示されている。ホスト装置３は、ネットワーク２を介してストレージ装置４にログインすることにより、ストレージ装置４のディスクデバイス４１上に形成された、対応するボリューム４１１との間でセッションが確立され、そこにアクセスすることができるようになる。管理装置５は、予め定められたバックアップスケジュールに従って、個々のボリューム４１１に対するバックアップの指示をストレージ装置４のコントローラユニット４２に与える。ここでいうバックアップとは、ボリューム４１１のレプリカを作成することを最終的な目標としているという意味で用いている。管理装置５は、コントローラユニット４２のセッション管理機能を通じて、各ホスト装置３とストレージ装置４の各ボリューム４１１との間のセッションの確立状態を取得する。

具体的には、同図は、バックアップウィンドウ内のある時点について、（１）ホスト装置３ａはログアウトしている状態、（２）ホスト装置３ｂは、一旦、ログオフした後、再度、ログイン要求を送出している状態、また、（３）ホスト装置３ｃは、対応するボリューム４１１を継続的に使用している状態を示している。

ホスト装置３ａに対応するボリューム４１１ａは、ホスト装置３ａによってログインされておらず、使用されていない状態であるため、管理装置５の指示の下、コントローラユニット４２は、ボリューム４１１ａのレプリカを作成する。ボリューム４１１ｂは、ホスト装置３ｂがログイン要求を送出しているボリュームである。したがって、コントローラユニット４２は、管理装置５の指示の下、スナップショットを行ってスナップショットイメージを取得した後、スナップショットイメージに基づいてレプリカを作成する。コント

ローラユニット４２は、レプリカの作成後、ログイン要求に基づいてホスト装置３ｂとのセッションを確立する。ボリューム４１１ｃは、ホスト装置３ｃにより使用されているボリュームであるため、管理装置５は、コントローラ４２に対してバックアップに関する指示を行わない。

図２は、本発明の一実施形態に係るストレージシステム１の構成を示している。同図に示すように、ストレージシステム１は、ネットワーク２を介してホスト装置３に接続されたストレージ装置４を含む。同図においては、ホスト装置３は１台のみ示されているが、実際の使用環境においては、複数のホスト装置３がネットワーク２に接続され、ストレージ装置４は、これら複数のホスト装置３からアクセスを受け付けることになる。ストレージシステム１はまた、ストレージ装置２に接続された管理装置５を含む。管理装置５は、システム管理者がストレージ装置４全体を管理するために用いる端末装置である。

ネットワーク２は、例えばＬＡＮ、インターネット、ＳＡＮ（Storage Area Network）、公衆回線又は専用回線などから構成される。ネットワーク２を介したホスト装置３とストレージ装置４との間の通信は、所定のプロトコルをベースにして行われる。ネットワーク２が、例えば、ＬＡＮやインターネットであれば、ＴＣＰ／ＩＰをベースにした通信が行われる。また、ネットワーク２がＳＡＮであれば、ファイバーチャネルプロトコルが採用される。本実施形態では、ネットワーク２がＬＡＮであり、したがって、ＴＣＰ／ＩＰベースの通信が行われるものとする。また、ホスト装置３とストレージ装置４に代表される周辺装置とを接続する技術としてＳＣＳＩが知られており、また、ＳＣＳＩをＩＰネットワークに適合させた技術としてｉＳＣＳＩがある。そこで、本実施形態においても、ホスト装置３とストレージ装置４との通信は、ＴＣＰ／ＩＰ上でｉＳＣＳＩにより行われるものとする。

ホスト装置３は、典型的には、汎用のパーソナルコンピュータ等が該当する。ホスト装置３は、ＣＰＵ３１、メインメモリ３２、ネットワークインターフェース３３およびローカル入出力装置３４等のハードウェア資源を備え、これらは内部バス３５により相互に接続されている。ホスト装置３はまた、デバイスドライバ（例えばＳＣＳＩドライバ等）やオペレーティングシステム（ＯＳ）、アプリケーションプログラム等のソフトウェア資源を備えている。

これによって、ホスト装置３は、ＣＰＵ３１の制御の下、各種のプログラムを実行して、ハードウェア資源との協働作用により、所望の処理を実現する。典型的には、ホスト装置３は、ＣＰＵ３１の制御の下、ＯＳ上でアプリケーションプログラムを実行する。アプリケーションプログラムは、ユーザがホスト装置３によって遂行させようとする処理を実現するためのプログラムである。アプリケーションプログラムは、その実行に際して、ストレージ装置４に対してデータの読み込みや書き込み等のアクセスを要求する。ホスト装置３に実装されたイニシエータは、アプリケーションプログラムからのアクセス要求をコマンドとして、ネットワーク２を介して接続されたストレージ装置４に引き渡すことができるように、ネットワークプロトコルに従った処理を行い、また、ストレージ装置４から読み出され、ネットワーク２を介して送られてきたデータをアプリケーションプログラムに引き渡すことができるように、ネットワークプロトコルに従った処理を行う。上述したように、本実施形態では、ｉＳＣＳＩを採用しているので、イニシエータはＳＣＳＩコマンドをＰＤＵ（Protocol Data Unit）としてカプセル化してネットワークプロトコルモデルいうところの下位のレベルに引き渡し、また、下位のレベルから引き渡されたＰＤＵをＳＣＳＩコマンドに変換する。イニシエータは、ＯＳとは独立に設計されてもよいし、またはその一部として組み込まれていてもよい。各種のプログラムは、１つのモジュールとして構成されてもよいし、複数のモジュールとして構成されてもよい。

ストレージ装置４は、１又は複数のディスクデバイス４１と、ディスクデバイス４１に対する書き込み又は読み込みといったアクセスを制御するコントローラユニット４２と、を備えている。ディスクデバイス４１によって提供される記憶領域上には、１又は複数の論理的なボリューム（ＬＵ）４１１が定義される。ボリューム４１１を定義した内容は、システム構成情報としてコントローラユニット４２に保持される。本実施形態では、複数のホスト装置３のそれぞれに対して１又は複数のボリューム４１１が提供されるように定義されている。すなわち、各ホスト装置３のイニシエータは、１又は複数のボリューム４１１をターゲットとしてアクセスできるように構成されている。

ボリューム４１１には、固有の識別子（ＬＵＮ：Logical Unit Number）が割り当てられ、個々のボリューム４１１は当該識別子によって管理される。ボリュームＬＵに対するアクセスは、所定サイズのブロックを単位として行われる。各ブロックには、さらに、論理ブロックアドレス（ＬＢＡ：Logical Block Address）が割り当てられている。したがって、ホスト装置３は、識別子および論理ブロックアドレスからなる論理アドレスをストレージ装置４のコントローラユニット４２に指定することにより、所望のボリューム上のブロックに対してアクセスを行うことができる。

コントローラユニット４２は、主として、ＣＰＵ４２１と、メモリ４２２と、キャッシュ機構４２３とを備えたシステム回路であり、ホスト装置３とディスクデバイス４１との間の入出力処理を統括的に制御する。また、コントローラユニット４２は、１又は複数のネットワークコントローラ４２４と１又は複数のディスクインターフェース４２５とを備える。さらに、コントローラユニット４２は、管理装置５との接続を可能にするための外部インターフェース４２６を備える。これらのシステムモジュールは、データコントローラ４２７に機能的に接続されている。

メモリ４２２は、ＣＰＵ４２１のメインメモリとして機能する。メモリ４２２は、ＣＰＵ４２１の利用に供されるべく、図３に示すように、例えば、各種の制御プログラム及びシステム構成情報や各種の管理テーブル等のプロファイルを記憶する。本実施形態では、制御プログラムとして、Ｉ／Ｏ制御プログラム、バックアップ制御プログラム及び障害監視制御プログラム等が実装されている。これら制御プログラム及び各種のプロファイル等は、例えば、ストレージ装置４に電源が投入された時点で、ＣＰＵ４２１の制御の下、ディスクデバイス４１上の特定のボリュームから読み出され、メモリ４２２上に展開される。または、メモリ４２２が再書き込み可能な不揮発性メモリを含んで構成されている場合には、当該不揮発性メモリに恒常的に保持され、そこから読み出されるようにしてもよい。

図２に戻り、キャッシュ機構４２３はキャッシュメモリを備え、ホスト装置３とディスクデバイス４１との間の入出力データを一時的に記憶するために利用される。すなわち、ホスト装置３から送られたコマンドは、キャッシュメモリに一旦保持され、また、ディスクデバイス４１から読み出されたデータは、ホスト装置３に送り出す際に、キャッシュメモリに一旦保持される。

ネットワークコントローラ４２４は、ネットワーク２を介してホスト装置３と通信できるように構成されたシステム回路である。図４は、本発明の一実施形態に係るストレージ装置４におけるネットワークコントローラ４２４の構成を示す図である。同図に示すように、ネットワークコントローラ４２４は、プロセッサ４２４１と、メモリ４２４２と、ポート４２４３と、ブリッジ４２４５とを備えている。プロセッサ４２４１は、メモリ４２４２に記憶された制御プログラムを実行する。メモリ４２４２は、図５に示すように、制御プログラムの実行に必要な各種の管理テーブルを保持している。ｉＳＣＳＩ制御プログラムは、ホスト装置３のイニシエータと対をなすプログラムである。ｉＳＣＳＩ制御プログラムは、ボリューム割当てテーブルを参照して、どのイニシエータがどのボリュームに割り当てられているかを認識する。また、ｉＳＣＳＩセッション管理テーブルは、ｉＳＣＳＩ上の各セッションの確立状態を保持している。ネットワークコントローラ４２４は、ｉＳＣＳＩセッション管理テーブルにより、図１に示したようなセッション管理機能を提供している。ボリューム割当てテーブル及びｉＳＣＳＩセッション管理テーブルの詳細については、後述する。

ポート４２４３には、ネットワークアドレスが割り当てられており、したがって、個々のネットワークコントローラ４２４は、ネットワーク２上で一意に識別される。ネットワークコントローラ４２４は、ホスト装置３からネットワーク２を介して送られるパケットデータを受け取り、ネットワークプロトコルに従ってコマンドを抽出した後、ブリッジ４２４５を介して、コントローラユニット４２のＣＰＵ４２１の制御に引き渡す。

図２に戻り、ディスクインターフェース４２５は、ディスクデバイス４１に対する入出力インターフェースを提供している。典型的には、一つのディスクインターフェース４２５には、一つのディスクデバイスが接続される。

外部インターフェース４２６は、ストレージ装置４全体を管理する管理装置５を接続するためのインターフェースである。本実施形態では、管理装置５は、外部インターフェース４２６によりネットワーク２を介してストレージ装置４と接続されているが、専用線を介してストレージ装置４と直接的に接続されてもよい。また、本実施形態では、管理装置５はストレージ装置４に外的に接続されているが、ストレージ装置４に設けられたサービスプロセッサ（ＳＶＰ）及びユーザインターフェースによって同等の機能を実現するように構成されてもよい。

既述したように、管理装置５は、ストレージ装置４全体を管理する端末装置であり、典型的には、汎用のコンピュータが適用されるが、制御端末であってもよい。管理装置５は、ホスト装置３と同様、プロセッサの制御の下、ハードウェア資源とソフトウェア資源との協働作用により、ストレージ装置４に対するさまざまな管理を行うための処理を実現する。管理装置５は、例えば、バックアップ管理プログラム及びバックアップ管理テーブルが実装され、ストレージ装置４に対するバックアップに関する処理を行っている。管理装置５は、バックアップスケジュールを設定するために、システム管理者に対するユーザインターフェースを提供し、また、設定されたバックアップスケジュールに従って、バックアップ管理テーブルを参照して、バックアップの対象となったボリュームに対してバックアップ処理が行われるよう、コントローラユニット４２に指示を出す。バックアップ管理テーブルは、個々のボリュームに対してバックアップ処理が行われたか否かを管理するテーブルである。また、本実施形態では、管理装置５は、バックアップスケジュールに従って、ネットワークコントローラ４２４を監視し、あるボリュームに対するｉＳＣＳＩプロトコルに従うログインまたはログアウト要求といった所定のイベントを検出すると、バックアップの指示を出す。

図６は、本発明の一実施形態に係るボリューム割当てテーブルを示す図である。ボリューム割当てテーブルは、上述したように、ネットワークコントローラ４２４のメモリ４２４２に保持され、各ホスト装置３に実装されたイニシエータとストレージ装置４内の各ボリュームとの対応関係を定義する。ホスト装置３上ではイニシエータは複数の実行インスタンスとして存在しうるため、ホスト装置３とボリュームとは、一対多の関係となりうる。

同図に示すように、ボリューム割当てテーブルは、「ボリューム名」、「割当てサイズ」、「ターゲット名」、及び「イニシエータ名」のフィールドから構成される。「ターゲット名」は、イニシエータがターゲットにしているボリュームに割り当てられたｉＳＣＳＩ上の名前である。イニシエータは、ターゲット名を指定することにより、ディスクデバイス４１上のボリュームにアクセスすることができる。

図７は、本発明の一実施形態に係るセッション管理テーブルを示す図である。セッション管理テーブルもまた、ネットワークコントローラ４２４のメモリ４２４２に保持され、ｉＳＣＳＩセッションごとの確立状態を管理する。同図に示すように、例えば、イニシエータ“initiator#1001”とボリューム“Volume#1001”とのｉＳＣＳＩセッションは、“OFF”、つまり、ボリューム“Volume#1001”を利用するホスト装置３のユーザはログインしていないことを示す。また、イニシエータ“initiator#1002”とボリューム“Volume#1002”とのｉＳＣＳＩセッションは、“ON”であるので、ボリューム“Volume#1002”を利用するホスト装置３のユーザはログインしていることを示す。管理装置５は、バックアップスケジュールに従って、当該セッション管理テーブルを参照し、ｉＳＣＳＩセッションが“OFF”であるボリュームに対してバックアップが行われるよう、コントローラユニット４２に指示を出す。

図８（ａ）乃至（ｃ）は、本発明の一実施形態に係るバックアップ管理テーブルを示す図である。バックアップ管理テーブルは、ボリューム４１１についてのバックアップ処理の状態を管理するテーブルであって、管理装置５内のメモリ上に保持される。同図は、バックアップウィンドウ内のある時点におけるボリューム４１１についてのバックアップ処理の状態を示している。バックアップ処理の状態は、“Online”、“Ready”、“Done”、“Done(ss)”、及び“Error”が定義されている。

状態“Online”は、ボリュームが使用されており、したがって、ボリュームのレプリカが作成されていないことを意味する。また、状態“Ready”は、ボリュームは使用されていないが、ボリュームのレプリカは作成されていないことを意味する。さらに、状態“Done”は、レプリカがすでに作成されたことを意味し、また、状態“Done(ss)”は、スナップショットイメージがすでに取得されているが、まだ、レプリカは作成されていないことを意味する。上述したように、本実施形態においては、バックアップは、レプリカを作成することを最終的な目標としているので、バックアップ処理の過程を２つの状態（すなわち“Done”及び“Done(ss)”）で定義している。

バックアップスケジュールとして、例えば、午前０：００にバックアップ処理が開始されると設定されているものとすると、状態は、“Online”または“Ready”のいずれかを示す。

図９は、本発明の一実施形態に係る管理装置５におけるバックアップ処理の管理を示すフローチャートである。管理装置５は、バックアップ管理プログラムを実行することにより、同図に示すようなバックアップ処理の管理を行う。

すなわち、管理装置５は、ネットワークコントローラ４２４内のボリューム割当てテーブルを参照し、ボリューム４１１の割当情報を取得する（ＳＴＥＰ９０１）。本実施形態では、管理装置５は、外部Ｉ／Ｆに接続されているので、データコントローラ４２７を介して、ネットワークコントローラ４２４から割当情報を取得する。当該割当情報を取得することにより、管理装置５は、各ボリューム４１１とｉＳＣＳＩセッションの関係を認識することができる。次に、管理装置５は、自身のメモリに格納されているｉＳＣＳＩセッション管理テーブルを参照し、セッションの確立状態を取得する（ＳＴＥＰ９０２）。管理装置５は、取得したボリュームの割当情報及びセッションの確立状態に基づいて、バックアップ管理テーブルを更新する（ＳＴＥＰ９０３）。具体的には、セッションの確立状態が“ON”であれば、バックアップ管理テーブルの対応するボリュームは、“Online”に変更され、“OFF”であれば、“Ready”に変更される。なお、ストレージ装置４のコントローラユニット４２が初期化された直後のように、バックアップ管理テーブルがまだ作成されていない場合には、管理装置５は、バックアップ管理テーブルを新たに作成する。また、上述したように、バックアップ処理を開始する直前にあっては、バックアップ管理テーブルの状態は、“Online”または“Ready”のいずれかである。

次に、管理装置５は、現時点の処理がバックアップウィンドウ外であるか否かを判断する（ＳＴＥＰ９０４）。これは、例えば、管理装置５に内蔵されたタイマーの時間とバックアップスケジュールとを比較することにより行われる。このことから明らかなように、バックアップ管理プログラムは、バックアップウィンドウ内でのみ実行されるわけではなく、システム常駐プログラム等によって適宜実行されてもよい。

管理装置５は、バックアップウィンドウ外であると判断すると（ＳＴＥＰ９０４の“Ｙｅｓ”）、バックアップ管理テーブルを参照して、状態が“Ready”にあるボリューム４１１（X）があるか否かを検索する（ＳＴＥＰ９０５）。管理装置５は、状態が“Ready”にあるボリューム４１１（X）を抽出すると（ＳＴＥＰ９０５の“Ｙｅｓ”）、当該ボリューム４１１（X）に対してスナップショットを行ってスナップショットイメージを取得するように、コントローラユニット４２に指示を出す（ＳＴＥＰ９０６）。なお、この場合、管理装置５は、レプリカを作成するように指示を出してもよいが、バックアップウィンドウ外であって当該ボリューム４１１（X）が使用される可能性があるため、本実施形態では、スナップショットを行うように指示している。コントローラユニット４２は、管理装置５からの指示に従って、スナップショットを行い、スナップショットイメージを作成する。なお、スナップショットイメージは、典型的には、ボリューム４１１内の実データに対するハードリンク情報等からなるメタデータのボリュームである。コントローラユニット４２は、スナップショットを行ったボリューム４１１に対して、さらにデータの更新等があった場合、例えば、図１０に示すように、ビットマップテーブルを用いてこのような更新情報を管理する。

管理装置５は、スナップショットの作成指示後、コントローラユニット４２から送られてくる処理結果レポートに基づいて、バックアップ管理テーブルを更新する（ＳＴＥＰ９０７）。すなわち、スナップショットの指示がなされたボリューム４１１（X）の状態は、“Done(ss)”又は“Error”となる。“Error”は、例えば、スナップショットイメージの取得中にログインがあった等の原因で、正常にスナップショットイメージが取得されなかったことを示している。

一方、ＳＴＥＰ９０４においてバックアップウィンドウ内であると判断される場合（ＳＴＥＰ９０４の“Ｎｏ”）、管理装置５は、バックアップ管理テーブルを参照して、状態が“Ready”にあるボリューム４１１（X）を検索する（ＳＴＥＰ９０８）。管理装置５は、状態が“Ready”にあるボリューム４１１（X）を抽出すると（ＳＴＥＰ９０８の“Ｙｅｓ”）、当該ボリューム４１１（X）に対するレプリカを作成するように、コントローラユニット４２に指示を出す（ＳＴＥＰ９０９）。後述するように、コントローラユニット４２は、当該指示に基づき、まず、当該ボリューム４１１（X）に対してスナップショットを行った後、そのスナップショットイメージに基づいて、レプリカを作成する。管理装置５は、その後、コントローラユニット４２から送られてくる処理結果レポートに基づいて、バックアップ管理テーブルを更新する（ＳＴＥＰ９１０）。すなわち、スナップショットの指示がなされたボリューム４１１（X）の状態は、“Done”、“Done(ss)”、又は“Error”のいずれかになる。

状態が“Ready”にあるボリューム４１１（X）がない場合（ＳＴＥＰ９０８の“Ｎｏ”）、管理装置５はさらに、状態が“Online”にあるボリューム４１１（X）があるか否かをチェックする（ＳＴＥＰ９１１）。状態が“Online”にあるボリューム４１１（X）がある（ＳＴＥＰ９１１の“Ｙｅｓ”）、管理装置５は、バックアップ処理を継続するため、ＳＴＥＰ９０２に戻る。

上記のバックアップ処理の管理が行われることによって、ある時点において、例えば、図８（ａ）に示したバックアップ管理テーブルが得られる。また、時間の経過とともに、バックアップ管理テーブルは、図８（ｂ）や図８（ｃ）に示すように、次々と更新されていく。

図１１は、本発明の一実施形態に係るストレージ装置４におけるバックアップ処理を示すフローチャートである。同図は、ストレージ装置４上のあるボリューム４１１に対するホスト装置３からのログイン要求がなされた時のバックアップ処理を示している。

同図に示すように、ストレージ装置４は、ホスト装置３のイニシエータからボリューム４１１（X）に対するログイン要求を受け付けると（ＳＴＥＰ１１０１）、管理装置５内のバックアップ管理テーブルを参照して、ボリューム４１１（X）におけるバックアップ処理の状態を取得して（ＳＴＥＰ１１０２）、ボリューム４１１（X）の状態が“Ready”であるか否かをチェックする（ＳＴＥＰ１１０３）。上述したように、状態“Ready”は、ボリュームが未使用中で、そのレプリカが未作成であることを示している。

ストレージ装置４は、ボリューム４１１（X）の状態が“Ready”であると判断すると（ＳＴＥＰ１１０３の“Ｙｅｓ”）、続いて、当該ボリューム４１１（X）が、現在、レプリカの作成が行われているか否かをチェックする（ＳＴＥＰ１１０４）。これは、レプリカの作成には、ある程度の時間を要するため、状態が“Ready”であっても、作成が完了するまでの時間的なずれにより、バックアップ管理テーブルの内容が反映されていないことがあるためである。ボリューム４１１（X）のレプリカが作成中である場合（ＳＴＥＰ１１０４の“Ｙｅｓ”）、ストレージ装置４は、データ整合性の観点から、当該ボリューム４１１（X）のレプリカを中断し、レプリカを破棄乃至は削除する（ＳＴＥＰ１１０５）。ここでいう破棄乃至は削除とは、当該ボリューム４１１（X）についての作成中のレプリカを利用しないようにするという広い意味で用いられる。

ストレージ装置４は、ボリューム４１１（X）に対してレプリカの作成をまだ始めていなかった場合には（ＳＴＥＰ１１０４の“Ｎｏ”）、ボリューム４１１（X）に対してスナップショットを行ってスナップショットイメージを取得し（ＳＴＥＰ１１０６）、管理装置５に対して、当該バックアップ処理の結果を通知する（ＳＴＥＰ１１０７）。管理装置５は、この通知を受けて、バックアップ管理テーブルの内容を更新する。すなわち、バックアップ管理テーブル内のボリューム４１１（X）の状態は、“Done(ss)”に更新される。その後、ストレージ装置４は、ログイン要求に関わる一連の処理を行って、ホスト装置３との間のセッションを確立する（ＳＴＥＰ１１０８）。

このように、ストレージ装置４は、ホスト装置３からのログイン要求をバックアップ処理のためのトリガとしているが、ログイン要求のあったボリューム４１１に対しては、直接的にレプリカを作成するのではなくスナップショットを行っているので、ユーザに必要以上のログイン処理待ちといった不都合を与えない範囲で、ログイン要求に応答することができるようになる。

図１２は、本発明の一実施形態に係る管理装置５によるバックアップ管理を示すフローチャートである。管理装置５は、バックアップ処理が完了していない、すなわち、レプリカの作成が完了していないボリューム４１１がある場合、レプリカが作成されるように、ストレージ装置４に指示を行う。同図は、このようなスナップショットが行われた段階のボリューム４１１に対するバックアップ管理を示している。

同図に示すように、管理装置５は、ボリューム管理テーブルを参照して、バックアップ処理の状態が“Done(ss)”であるボリューム４１１（X）があるか否かを判断する（ＳＴＥＰ１２０１）。状態が“Done(ss)”であるボリューム４１１（X）がある場合、管理装置５は、ボリューム４１１（X）に対するレプリカを作成するように、ストレージ装置４に指示を出す（ＳＴＥＰ１２０２）。これによって、ストレージ装置４は、ボリューム４１１（X）のすでに取得されたスナップショットイメージに基づいて、レプリカの作成を開始する。管理装置５は、ストレージ装置４から通知される処理の結果に基づいて、バックアップ管理テーブルの内容を更新する（ＳＴＥＰ１２０３）。すなわち、バックアップ管理テーブル内のボリューム４１１（X）の状態は、“Done”に更新される。そして、ボリューム４１１（X）のスナップショットイメージは不要であることから、管理装置５は、スナップショットイメージを削除するように、ストレージ装置４に対して指示を出す（ＳＴＥＰ１２０４）。

次に、本発明の他の実施形態について説明する。図１３は、本発明の一実施形態に係るストレージシステムにおけるデータのバックアップ処理を説明する概念図である。

本実施形態では、データの整合性の観点から、ログオフ要求があった場合、直ちに、スナップショットイメージを取得し、その後、バックグラウンド処理で、スナップショットイメージに基づいてレプリカを作成する。

同図は、バックアップウィンドウ内のある時点について、（１）ホスト装置３ａはすでにログアウトしている状態、（２）ホスト装置３ｂは、ログオフ要求を送出している状態、また、（３）ホスト装置３ｃは、対応するボリューム４１１を継続的に使用している状態を示している。

ホスト装置３ａに対応するボリューム４１１ａは、ホスト装置３ａによってログインされておらず、使用されていない状態であるため、管理装置５の指示の下、コントローラユニット４２は、ボリューム４１１ａのレプリカを作成する。ボリューム４１１ｂは、ホスト装置３ｂがログオフ要求を送出しているボリュームである。したがって、コントローラユニット４２は、管理装置５の指示の下、直ちにスナップショットを行ってスナップショットイメージを取得した後、スナップショットイメージに基づいてレプリカを作成する。ボリューム４１１ｃは、ホスト装置３ｃにより使用されているボリュームであるため、管理装置５は、コントローラ４２に対してバックアップに関する指示を行わない。

図１４は、本発明の一実施形態に係るストレージ装置４におけるバックアップ処理を示すフローチャートである。同図は、ストレージ装置４上のあるボリューム４１１に対するホスト装置３からのログオフ要求がなされた時のバックアップ処理を示している。

同図に示すように、ストレージ装置４は、ホスト装置３のイニシエータからボリューム４１１（X）に対するログオフ要求を受け付けると（ＳＴＥＰ１４０１）、ログオフ要求に関わる一連の処理を行って、ホスト装置３との間のセッションを切断する（ＳＴＥＰ１４０２）。

ストレージ装置４は、セッションを切断した後、直ちに、ボリューム４１１（X）に対してスナップショットを行ってスナップショットイメージを取得し（ＳＴＥＰ１４０３）、管理装置５に対して、当該バックアップ処理の結果を通知する（ＳＴＥＰ１４０４）。管理装置５は、この通知を受けて、バックアップ管理テーブルの内容を更新する。すなわち、バックアップ管理テーブル内のボリューム４１１（X）の状態は、“Done(ss)”に更新される。

このように、ストレージ装置４は、ホスト装置３からのログオフ要求をバックアップ処理のためのトリガとしているが、ログオフ要求のあったボリューム４１１に対しては、直接的にスナップショットを行うことで、後のバックグラウンド処理においてスナップショットが行われたボリューム４１１について、レプリカを作成すればよいことになる。

図１５は、本発明の一実施形態に係る管理装置５におけるバックアップ管理を示すフローチャートである。同図は、上述した実施形態における図９に対応するが、バックアップウィンドウ内での状態が“Ready”のボリューム４１１（X）に対して、レプリカを作成するのではなく、スナップショットを行う点で異なっている（同図ＳＴＥＰ１５０９）。

すなわち、同図に示すように、管理装置５は、ネットワークコントローラ４２４内のボリューム割当てテーブルを参照し、ボリューム４１１の割当情報を取得する（ＳＴＥＰ１５０１）。次に、管理装置５は、自身のメモリに格納されているｉＳＣＳＩセッション管理テーブルを参照し、セッションの確立状態を取得する（ＳＴＥＰ１５０２）。管理装置５は、取得したボリュームの割当情報及びセッションの確立状態に基づいて、バックアップ管理テーブルを更新する（ＳＴＥＰ１５０３）。

次に、管理装置５は、現時点の処理がバックアップウィンドウ外であるか否かを判断する（ＳＴＥＰ１５０４）。これは、例えば、管理装置５に内蔵されたタイマーの時間とバックアップスケジュールとを比較することにより行われる。

管理装置５は、バックアップウィンドウ外であると判断すると（ＳＴＥＰ１５０４の“Ｙｅｓ”）、バックアップ管理テーブルを参照して、状態が“Ready”にあるボリューム４１１（X）があるか否かを検索する（ＳＴＥＰ１５０５）。管理装置５は、状態が“Ready”にあるボリューム４１１（X）を抽出すると（ＳＴＥＰ１５０５の“Ｙｅｓ”）、当該ボリューム４１１（X）に対してスナップショットを行ってスナップショットイメージを取得するように、コントローラユニット４２に指示を出す（ＳＴＥＰ１５０６）。管理装置５は、スナップショットの作成指示後、コントローラユニット４２から送られてくる処理結果レポートに基づいて、バックアップ管理テーブルを更新する（ＳＴＥＰ１５０７）。すなわち、スナップショットの指示がなされたボリューム４１１（X）の状態は、“Done(ss)”又は“Error”となる。

一方、ＳＴＥＰ１５０４においてバックアップウィンドウ内であると判断される場合（ＳＴＥＰ１５０４の“Ｎｏ”）、管理装置５は、バックアップ管理テーブルを参照して、状態が“Ready”にあるボリューム４１１（X）を検索する（ＳＴＥＰ１５０８）。管理装置５は、状態が“Ready”にあるボリューム４１１（X）を抽出すると（ＳＴＥＰ１５０８の“Ｙｅｓ”）、当該ボリューム４１１（X）に対するスナップショットを行ってスナップショットイメージを取得するように、コントローラユニット４２に指示を出す（ＳＴＥＰ１５０９）。後述するように、コントローラユニット４２は、当該指示に基づき、まず、当該ボリューム４１１（X）に対してスナップショットを行った後、そのスナップショットイメージに基づいて、レプリカを作成する。管理装置５は、その後、コントローラユニット４２から送られてくる処理結果レポートに基づいて、バックアップ管理テーブルを更新する（ＳＴＥＰ１５１０）。すなわち、スナップショットの指示がなされたボリューム４１１（X）の状態は、“Done(ss)”又は“Error”のいずれかになる。

状態が“Ready”にあるボリューム４１１（X）がない場合（ＳＴＥＰ１５０８の“Ｎｏ”）、管理装置５はさらに、状態が“Online”にあるボリューム４１１（X）があるか否かをチェックする（ＳＴＥＰ９１１）。状態が“Online”にあるボリューム４１１（X）がある（ＳＴＥＰ１５１１の“Ｙｅｓ”）、管理装置５は、バックアップ処理を継続するため、ＳＴＥＰ１５０２に戻る。

これら上記の実施形態は、本発明を説明するための例示であり、本発明をこれらの実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱しない限り、さまざまな形態で実施することができる。例えば、各種の処理乃至は動作をシーケンシャルに説明したが、特にこれにこだわるものではない。したがって、動作に矛盾が生じない限り、処理の順序を入れ替えまたは並行動作するように構成しても良い。

また、上記実施形態に係るストレージ装置４は、デュアルコントローラユニットを含んで構成されてもよい。図１６は、本発明の一実施形態に係るストレージ装置４の構成を示す図である。同図に示すように、ストレージ装置４は、障害等によるシステムダウンを防止するために、２系統のパスを備えたコントローラユニット４２’を含んでいる。すなわち、コントローラユニット４２’は、図２に示したコントローラユニット４２のシステム回路を２重化することで構成され、これら２重化されたシステム回路は内部的に連携動作可能なように接続されている。

さらに、上記実施形態は、リカバリポイント目標（ＲＰＯ）が固定値の１日であることを前提に説明されたが、ＲＰＯは、ディスクデバイス４１の記憶容量（ボリューム容量）や処理パフォーマンス、書き込み要求の頻度等といった各種のパラメータに基づいて、動的に算出され、決定されてもよい。また、システム管理者が、管理装置５を用いて、ＲＰＯを自由に設定できるようにしてもよい。図１７及び図１８は、本発明の一実施形態に係る管理装置５により提供されるユーザインターフェースの一例を示す図である。管理装置５は、このようなユーザインターフェースを介して、システム管理者にＲＰＯの設定を促す。

管理装置５は、例えば、すべてのボリューム４１１に対してバックアップ処理を開始してから終了するまでのバックアップ所要時間に基づいてバックアップ見積時間Ｔｂ１を算出する。また、当該バックアップ見積時間Ｔｂ１に基づいてある期間の統計値に基づくバックアップ見積時間Ｔｂ２を算出してもよい。さらに、管理装置５は、入力された設定値に基づいて処理パフォーマンス（例えば、５１２ｋｂで１０００ＩＯＰＳといった仕様）及びボリュームの総容量から、実際に要するであろうバックアップ見積時間Ｔｂ３を算出してもよい。管理装置５は、このようなバックアップ見積時間Ｔｂ１乃至Ｔｂ３のいずれかをシステム管理者に提示して、１日当たりのバックアップ回数の入力を促す。管理装置５は、システム管理者から入力された設定値が矛盾する値であるか否かをチェックし、矛盾する場合にはエラーダイアログを表示して、再入力を促す（図１８（ｂ））
さらにまた、上記実施形態では、ＴＣＰ／ＩＰ上のｉＳＣＳＩを採用しているが、特にこれに限定されるものではない。本発明は、ログインやログオフ要求といった所定のイベントの発生をトリガできるものであればよい。例えば、ＦＣ（Fibre Channel）技術における再認証処理に基づいてバックアップ処理を行うように構成してもよい。

さらに、上記実施形態では、管理装置５がバックアップ処理の管理を行っていたが、ストレージ装置４のコントローラユニット４２に、管理装置５と同等の機能を実装し、コントローラユニット４２がバックアップ処理の一元管理を行うようにしてもよい。

上記実施形態に係るストレージシステムまたはストレージ装置によれば、すでに述べたようなまたは以下に述べるような効果ないしは利点を奏する。

ストレージ装置は、ホスト装置からのログイン要求をバックアップ処理のためのトリガとしているが、ログイン要求のあったボリュームに対しては、直接的にレプリカを作成するのではなくスナップショットを行っているので、ユーザに必要以上のログイン処理待ちといった不都合を与えない範囲で、ログイン要求に応答することができるようになる。

また、ストレージ装置は、ホスト装置からのログオフ要求をバックアップ処理のためのトリガとして、ログオフ要求のあったボリュームに対してスナップショットを行っているので、後のバックグラウンド処理においてスナップショットが行われたボリュームについて、効率的にレプリカを作成することができるようになる。

したがって、バックアップウィンドウが比較的小さく設定されたシステムやユーザの例外的な使用状況においても、バックアップの取りこぼしを防止することができる。また、多数のデータボリュームに対しても、バックアップウィンドウ内で効率的にバックアップを行うことができるようになる。

本発明は、コンピュータシステム上で処理されるデータを記憶するストレージ装置に幅広く適用することができる。特に、本発明は、データの消失を防止するため、データのバックアップおよび復元・復旧のために用いられるストレージ装置に適用することができる。

本発明の一実施形態に係るストレージシステムにおけるデータのバックアップ処理を説明する概念図である。 本発明の一実施形態に係るストレージシステムの構成を示している。 本発明の一実施形態に係るストレージ装置におけるコントローラユニットのメモリ内容を説明するための図である。 本発明の一実施形態に係るストレージ装置におけるネットワークコントローラの構成を示す図である。 本発明の一実施形態に係るストレージ装置におけるネットワークコントローラのメモリ内容を説明するための図である。 本発明の一実施形態に係るボリューム割当てテーブルを示す図である。 本発明の一実施形態に係るセッション管理テーブルを示す図である。 本発明の一実施形態に係るバックアップ管理テーブルを示す図である。 本発明の一実施形態に係る管理装置におけるバックアップ処理の管理を示すフローチャートである。 本発明の一実施形態に係るスナップショット処理を説明するための図である。 本発明の一実施形態に係るストレージ装置におけるバックアップ処理を示すフローチャートである。 本発明の一実施形態に係る管理装置によるバックアップ管理を示すフローチャートである。 本発明の一実施形態に係るストレージシステムにおけるデータのバックアップ処理を説明する概念図である。 本発明の一実施形態に係るストレージ装置におけるバックアップ処理を示すフローチャートである。 本発明の一実施形態に係る管理装置におけるバックアップ管理を示すフローチャートである。 本発明の一実施形態に係るストレージ装置の構成を示す図である。 本発明の一実施形態に係る管理装置５により提供されるユーザインターフェースの一例を示す図である。 本発明の一実施形態に係る管理装置５により提供されるユーザインターフェースの一例を示す図である。

符号の説明

１…記憶システム
２…ネットワークシステム
３…ホスト装置
３１…ＣＰＵ
３２…ローカルメモリ
３３…インターフェース部
３４…ローカル入出力装置
３５…内部バス
４…ストレージ装置
４１…ディスクデバイス
４１１…ボリューム
４２…コントローラユニット
４２１…ＣＰＵ
４２２…メモリ
４２３…キャッシュ機構
４２４…ネットワークコントローラ
４２５…ディスクインターフェース
４２６…外部インターフェース
４２７…データコントローラ
５…管理装置

Claims (20)

1. ホスト装置に接続されるストレージ装置であって、
   １又は複数のボリュームが形成されたディスクデバイスと、
   前記ディスクデバイスに対する制御を行うコントローラユニットと、を備え、
   前記コントローラユニットは、
   前記ホスト装置から送られる所定のボリュームに対するセッションに関わる要求に基づいて、前記所定のボリュームに対してスナップショットを行ってスナップショットイメージを取得し、前記取得したスナップショットイメージに基づいてレプリカを作成することを特徴とするストレージ装置。
2. 前記コントローラユニットは、前記セッションに関わる要求を受け付けた場合に、前記スナップショットイメージを取得した後に、前記セッションに関わる要求に応じた処理を行うことを特徴とする請求項１記載のストレージ装置。
3. 前記セッションに関わる要求は、ｉＳＣＳＩ規格のログイン要求であることを特徴とする請求項２記載のストレージ装置。
4. 前記コントローラユニットは、前記セッションに関わる要求を受け付けた場合に、前記セッションに関わる要求に応じた処理を行った後に、前記スナップショットイメージを取得することを特徴とする請求項１記載のストレージ装置。
5. 前記セッションに関わる要求は、ｉＳＣＳＩ規格のログオフ要求であることを特徴とする請求項３記載のストレージ装置。
6. 前記ストレージ装置には、前記１又は複数のボリュームに対するバックアップ処理の状態を管理するバックアップ管理テーブルを有する管理装置が接続され、
   前記コントローラユニットは、前記ホスト装置と前記１又は複数のボリュームとの間のセッションの状態を管理するセッション管理テーブルを備え、
   前記管理装置は、前記バックアップ管理テーブルに示されるバックアップ処理の状態及び前記セッション管理テーブルに示されるセッションの状態に基づいて、前記１又は複数のボリュームに対する所定のバックアップ処理が行われるように、前記コントローラユニットに対して指示を行うことを特徴とする請求項１記載のストレージ装置。
7. 前記管理装置は、前記バックアップ管理テーブルが示すバックアップ処理の状態に応じて、スナップショット又はレプリカの作成のいずれかが行われるように、前記コントローラユニットに対して指示を行うことを特徴とする請求項６記載のストレージ装置。
8. 前記管理装置は、
   前記セッション管理テーブルに示されるセッションの状態に基づいて、前記ホスト装置との間でセッションが確立されていないボリュームを特定し、
   前記バックアップ管理テーブルが示すバックアップ処理の状態に基づいて、前記特定されたボリュームのうち、前記スナップショットの作成がまだ行われていないボリュームについて、前記スナップショットが行われるように、前記コントローラユニットに対して指示することを特徴とする請求項７記載のストレージ装置。
9. 前記管理装置は、
   前記セッション管理テーブルに示されるセッションの状態に基づいて、前記ホスト装置との間でセッションが確立されていないボリュームを特定し、
   前記バックアップ管理テーブルが示すバックアップ処理の状態に基づいて、前記特定されたボリュームのうち、前記スナップショットが行われているが、前記レプリカの作成がまだ行われていないボリュームについて、前記レプリカの作成が行われるように、前記コントローラユニットに対して指示を行うことを特徴とする請求項７記載のストレージ装置。
10. 前記コントローラユニットは、前記レプリカを作成した後に、前記取得したスナップショットイメージを削除することを特徴とする請求項１記載のストレージ装置。
11. ホスト装置に接続されるストレージ装置におけるデータのバックアップ方法であって、
    前記ストレージ装置のディスクデバイス上に形成された所定のボリュームに対するセッションに関わる要求を前記ホスト装置から受け付けるステップと、
    前記セッションに関わる要求に基づいて、前記所定のボリュームに対するスナップショットを行ってスナップショットイメージを取得するステップと、
    前記取得したスナップショットイメージに基づいて前記所定のボリュームに対するレプリカを作成するステップと、を含むことを特徴とするデータのバックアップ方法。
12. 前記データのバックアップ方法は、前記スナップショットイメージを取得した後、前記セッションに関わる要求に応じた処理を行うことを特徴とする請求項１１記載のデータのバックアップ方法。
13. 前記セッションに関わる要求は、ｉＳＣＳＩ規格のログイン要求であることを特徴とする請求項１２記載のデータのバックアップ方法。
14. 前記データのバックアップ方法は、前記セッションに関わる要求に応じた処理を行った後に、前記スナップショットイメージを取得することを特徴とする請求項１１記載のストレージ装置。
15. 前記セッションに関わる要求は、ｉＳＣＳＩ規格のログオフ要求であることを特徴とする請求項１４記載のデータのバックアップ方法。
16. 前記データのバックアップ方法は、
    前記１又は複数のボリュームに対するバックアップの状態を監視するステップと、
    前記１又は複数のボリュームに対するセッションの状態を監視するステップと、を含み、
    前記バックアップの状態及び前記セッションの状態に基づいて、前記１又は複数のボリュームに対するバックアップ処理を行うことを特徴とする請求項１１記載のデータのバックアップ方法。
17. 前記データのバックアップ方法は、
    前記バックアップ処理の状態に応じて、スナップショット又はレプリカの作成のいずれかを行うことを特徴とする請求項１６記載のデータのバックアップ方法。
18. 前記データのバックアップ方法は、
    前記セッションの状態に基づいて、前記ホスト装置との間でセッションが確立されていないボリュームを特定するステップをさらに含み、
    前記バックアップ処理の状態に基づいて、前記特定されたボリュームのうち、前記スナップショットの作成がまだ行われていないボリュームについて、前記スナップショットを行うことを特徴とする請求項１７記載のデータのバックアップ方法。
19. 前記データのバックアップ方法は、
    前記セッションの状態に基づいて、前記ホスト装置との間でセッションが確立されていないボリュームを特定するステップをさらに含み、
    前記バックアップ処理の状態に基づいて、前記特定されたボリュームのうち、前記スナップショットが行われているが、前記レプリカの作成がまだ行われていないボリュームについて、レプリカの作成を行うことを特徴とする請求項１７記載のデータのバックアップ方法。
20. 前記データのバックアップ方法は、
    前記所定のデータボリュームに対するレプリカを作成中に、前記セッションに関わる要求を受け付けた場合に、前記作成中のレプリカを破棄することを特徴とする請求項１７記載のデータのバックアップ方法。

Images