JP4236677B2

JP4236677B2 - Ｃｄｐを用いたリカバリ方法

Info

Publication number: JP4236677B2
Application number: JP2006253787A
Authority: JP
Inventors: 渡岡田; 山本　　政行; 雅英佐藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-09-20
Filing date: 2006-09-20
Publication date: 2009-03-11
Anticipated expiration: 2026-09-20
Also published as: JP2008077264A; US20080071841A1; US20090070390A1; US8082232B2; US7467165B2

Description

本発明は、データのリカバリのための技術に関する。

一般に、情報システムでは、定期的にバックアップを取得することで、ストレージシステムの障害、コンピュータウィルスによるデータ破壊、ユーザによる誤操作などによってデータが喪失した場合に、喪失したデータをリカバリできるようにする。

このバックアップ及びリカバリ技術の一つとして、ジャーナリングを用いたバックアップ及びリカバリ技術が提案されている（たとえば、文献１（米国特許公開明細書２００５／００１５４１６号）を参照）。この文献１には、一つ以上のデータボリュームで構成される論理的なグループ（以降、「ジャーナルグループ」と呼ぶ）の特定時点のスナップショット（フルバックアップあるいは、差分バックアップなどの論理的なイメージ）を取得し、それ以降の前記データボリュームへの書き込みデータをジャーナル(「Afterジャーナル」と呼ばれる)として前記ジャーナルグループに関連付けられたジャーナルボリュームに格納することと、取得したスナップショットに対して書き込まれた順序どおりに一連のAfterジャーナルを適用することで、特定の時点のデータをリカバリすることと、が開示されている。これは一般に「Continuous Data Protection」又はそれを略して「CDP」と呼ばれる技術の一例である。

また、特許文献１には、上記Afterジャーナル適用によってリカバリしたデータが既に破壊されている場合に、Afterジャーナル適用を取り消す方法も提案されている。この文献１には、Afterジャーナル適用によって上書きされる箇所のデータを前記ジャーナルボリュームへ退避させておき、Afterジャーナル適用を取り消す場合、Afterジャーナル適用後のスナップショットに前記退避させたデータを元の箇所へ適用する(退避したデータを書き戻す)ことで、短時間でAfterジャーナル適用以前のスナップショットへリカバリすることが開示されている。なお、この退避させたデータを「Beforeジャーナル」と呼ぶ。

文献２（特開２００４−２５２６８６号公報）では、ホスト計算機からの書き込み時にAfterジャーナルとBeforeジャーナルを同時に取得する技術も開示されている。これにより、運用中のデータボリュームにBeforeジャーナルを適用することで、過去のデータをリカバリすることができる。なお、Afterジャーナル、Beforeジャーナル及び当該ジャーナルの管理用のメタデータを纏めて、単に「ジャーナル」と呼ぶ。また、リカバリ時にジャーナルの適用対象となるスナップショットを「基底スナップショット」と呼ぶ。
米国特許公開明細書２００５／００１５４１６号特開２００４−２５２６８６号公報

一般的に、計算機システムのリカバリでは、リカバリにかかる時間(リカバリ時間)を可能な限り短くしたいという要求がある。

また、計算機システムのリカバリでは、二つ以上の時点のいずれかの時点のデータをリカバリすればよい場合がある。たとえば、ユーザの誤操作により削除してしまったファイルを復元したい場合は、当該ファイルの作成時点から当該ファイルの削除直前までであれば、いずれの時点のデータを復旧してもよい。また、復元対象のファイルの存在期間がわからない場合など、どの時点のデータをリカバリすれば良いかが不明な場合、おおよその見当をつけて特定の時点のデータをリカバリし、そのデータの妥当性を検証することがある。この場合も、厳密に決定された時点のデータをリカバリするわけではなく、ある程度の時間範囲（たとえば、10:00付近など）のいずれかの時点のデータをリカバリすることになる。あるいは、データベース(DB)の全データの中で、日次のバッチ処理によってのみ更新されるデータを復元する場合も、前記バッチ処理間のいずれかの時点のデータをリカバリすればよい。つまり、アプリケーションや業務のイベント間のいずれかの時点のデータをリカバリすればよい場合がある。さらには、データ障害等により停止したシステムを再稼動させる場合も、データ障害以前のいずれかの時点のデータを復旧すればよい。ただし、この場合は、最新のデータが再稼動に必要が無い場合に限られる。たとえば、メールサーバであれば、再稼動に最新のメールデータは必要ないのでこの例に当てはまる(別途、最新のメールデータを復元する必要があってもよい)。

ところで、上述した文献１および２で開示されている技術では、特定時点（リカバリポイント）のデータをリカバリするのに要する時間長（以下、リカバリ時間）は、リカバリ時に基底スナップショットへ適用するジャーナルの数とそのサイズに依存する。つまり、各時点のデータのリカバリ時間はそれぞれ異なっている。しかし、文献１及び２では、どの時点のデータをリカバリするかをユーザが選択するときに、リカバリ時間に関する情報を提示していない。このため、二つ以上の時点のいずれかの時点のデータをリカバリすればよい場合、必要以上に長いリカバリ時間を必要とするデータをリカバリしてしまう場合があるという課題がある。

本発明の目的は、リカバリ時間を短く抑えられるリカバリポイントをユーザが正確に選択できるようにすることにある。

本発明の他の目的は、後述の説明から明らかになるであろう。

本発明に従う制御装置は、ＣＤＰを用いたリカバリを実行することができるストレージシステムの制御装置である。

ストレージシステムが、第一の記憶域と、第二の記憶域と、第三の記憶域と、リカバリ実行部とを備えている。前記第一の記憶域は、上位装置（例えばホスト計算機或いは他のストレージシステム）から送信されたデータが格納されるデータ記憶装置の複数のスナップショット取得時点を表す第一の情報を記憶する。前記第二の記憶域は、前記データ記憶装置に対するデータの書込み時点と該データの書込みについてのジャーナルのサイズとを含んだ第二の情報であるジャーナル管理データを各ジャーナルについて記憶する。第三の記憶域は、前記データ記憶装置のリカバリ可能な複数の時点である複数のリカバリポイントを表す第三の情報を記憶する。前記リカバリ実行部は、前記複数のリカバリポイントのうちリカバリ実行要求で指定されたリカバリポイントにおける前記データ記憶装置内のデータ群をリカバリする。具体的には、前記リカバリ実行部は、前記複数のスナップショット取得時点のうち前記指定されたリカバリポイントに対応したスナップショット取得時点における前記データ記憶装置のデータ群に、該対応したスナップショット取得時点と前記指定されたリカバリポイントとの間が書込み時点となっているジャーナル管理データに対応したジャーナルを適用することで、前記複数のリカバリポイントのうちの前記指定されたリカバリポイントにおける前記データ記憶装置内のデータ群をリカバリするように構成されている。

ここで、「前記指定されたリカバリポイントに対応したスナップショット取得時点」とは、例えば、該リカバリポイントにおけるデータ群をリカバリするための基底となるデータ群（以下、基底データ群）が一つだけのケースでは、該基底データ群に対応したスナップショット取得時点である。このケースは、例えば、リカバリの際に適用されるジャーナルが、AfterジャーナルとBeforeジャーナルとのうちいずれか一方のみの場合に該当し得る。一方、別のケースとして、指定されたリカバリポイントにおけるデータ群をリカバリするための基底データ群が複数個あるケースでは、「前記指定されたリカバリポイントに対応したスナップショット取得時点」とは、それら複数の基底データ群のうちリカバリ負荷が最も少なくて済む基底データ群に対応したスナップショット取得時点である。この別のケースは、例えば、ストレージシステムが、AfterジャーナルとBeforeジャーナルとのいずれか一方を選択してリストア可能な構成となっている場合に該当し得る。

また、前述したデータ記憶装置は、前記ストレージシステムに存在しても良いし、該ストレージシステムに他のストレージシステムが接続されておりストレージシステム間でリモートコピーが行われるようになっている場合には、該他のストレージシステムに存在しても良い。

このようなストレージシステムに対し、制御装置が、取得部と、算出部と、リカバリポイント選択受付部と、リカバリ要求部とを備えている。前記取得部は、前記複数のスナップショット取得時点を表す第一の情報と、各ジャーナルについての前記各ジャーナル管理データと、前記複数のリカバリポイントを表す第三の情報とを取得する。前記算出部は、前記取得した第一の情報が表す複数のスナップショット取得時点と、前記各ジャーナル管理データにおける各書込み時点及び各ジャーナルサイズと、前記取得した第三の情報が表す複数のリカバリポイントとに基づいて、各リカバリポイント毎に、そのリカバリポイントにおける前記データ記憶装置のデータ群をリカバリするために転送すべき一以上のデータのトータル転送データサイズを算出する。前記表示部は、前記各リカバリポイントと、該各リカバリポイントについて算出されたトータル転送データサイズを基に表したリカバリ負荷を表す各リカバリ負荷情報との対応関係を可視化した表示画面を表示する表示部と、ユーザ所望のリカバリポイントの選択をユーザから受け付けるリカバリポイント選択受付部と、前記ユーザにより選択されたリカバリポイントを指定したリカバリ実行要求を前記リカバリ実行部に送信するリカバリ要求部とを備える。なお、前記トータル転送データサイズには、例えば、前記対応したスナップショット取得時点における前記データ記憶装置のデータ群に適用すべき一以上のジャーナルのトータルジャーナルサイズが含まれる。また、例えば、リカバリ負荷とは、リカバリ時間の長短に関わるものであり、リカバリ負荷が大きければ、リカバリ時間が長く、リカバリ負荷が小さければ、リカバリ時間は短い。

この制御装置は、ストレージシステムの中に組み込まれたコントローラであっても良いし、ストレージシステムと通信可能な計算機であっても良い。また、制御装置が備える複数の構成要素の一部が、ストレージシステムのコントローラが備え、他の一部が、計算機にあっても良い。

上述した各記憶域は、例えば、記憶資源（例えばメモリ或いはハードディスクなど）に設けることができる。また、各部は、ハードウェア、コンピュータプログラム又はそれらの組み合わせ（例えば一部をコンピュータプログラムにより実現し残りをハードウェアで実現すること）により構築することができる。コンピュータプログラムは、所定のプロセッサに読み込まれて実行される。また、コンピュータプログラムがプロセッサに読み込まれて行われる情報処理の際、適宜に、メモリ等のハードウェア資源上に存在する記憶域が使用されてもよい。また、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体から計算機にインストールされてもよいし、通信ネットワークを介して計算機にダウンロードされてもよい。

本発明によれば、リカバリ時間を短く抑えられるリカバリポイントをユーザが正確に選択できる。

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

（１）実施例１のシステム構成。

図１は、本発明の実施例１に係る計算機システムの構成例を示すブロック図である。

本システムでは、ストレージシステム１０００とホスト計算機１１００は、データネットワーク１３００を介して互いに接続される。本実施例では、データネットワーク１３００はストレージエリアネットワークとするが、IPネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。

ストレージシステム１０００とホスト計算機１１００と管理計算機１２００は、管理ネットワーク１４００を介して互いに接続される。本実施例では、管理ネットワーク１４００はIPネットワークとするが、ストレージエリアネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。また、データネットワーク１３００と管理ネットワーク１４００が同一ネットワークであってもよいし、ホスト計算機１１００と管理計算機１２００が同一計算機であってもかまわない。

なお、説明の都合上、図１では、ストレージシステム１０００を１台、ホスト計算機１１００を１台、管理計算機１２００を１台としたが、本発明ではこれら以上の台数を設置しても良い。

ストレージシステム１０００は、データを格納する複数の記憶装置１０１０と、ストレージシステム１０００内の制御を行うコントローラ１０２０とで構成されている。

記憶装置１０１０として、ハードディスクドライブ、フラッシュメモリデバイスなど、種々の記憶装置を採用することができる。異なる種類の記憶装置１０１０がストレージシステム１０００に混在してもよい。二以上の記憶装置１０１０により、ＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）の規則に従うグループ（ＲＡＩＤグループ）を構成することができる。ＲＡＩＤグループの記憶空間により、一以上の論理ボリュームを用意することができる。複数の記憶装置１０１０には、この論理ボリュームを一又は複数個備えたものとして、例えば、ジャーナルグループ１０１４、SSVOLグループ１０１５、ジャーナルボリューム１０１３を備えることができる。なお、記憶装置１０１０は一つでもよい。

ジャーナルグループ１０１４は、一つ以上のデータボリューム１０１１により構成される。データボリューム１０１１は、ホスト計算機１１００が利用するデータを格納する論理ボリュームである。また、ジャーナルグループ１０１４には、一つ以上のジャーナルボリューム１０１３及び一つ以上のSSVOLグループ１０１５が関連付けられる。ジャーナルボリューム１０１３は、ジャーナル及びマーカーを格納する論理ボリュームである。マーカーとは、各種イベントの発生時点を記録するためのデータであり、リカバリ時にリカバリポイント選択の指標として利用される。SSVOLグループ１０１５については後述する。

データボリューム１０１１へのホスト計算機１１００からの書き込み要求は、後述する制御プログラム１０２８を実行するＣＰＵ１０２３により処理され、該書込み要求に従うデータが、データボリューム１０１１に書込まれる。このとき、ＣＰＵ１０２３は、書き込むデータをAfterジャーナル、上書きされる箇所のデータをBeforeジャーナルとし、送信されてきた順序に従って順序番号を割り振るなど、適切な管理用メタデータを付与してジャーナルを作成する。そして、ＣＰＵ１０２３は、当該ジャーナルを、データボリューム１０１１が属するジャーナルグループ１０１４に関連付けられたジャーナルボリューム１０１３に格納する。前記メタデータや順序番号については、後にジャーナルの構成と併せて説明する。なお、新規ジャーナルの格納領域が不足した場合、前記ＣＰＵ１０２３は、最古のジャーナルをジャーナルボリューム１０１３から削除して空き領域を作成した後に、ジャーナルを格納することができる。また、一変形例として、ホスト計算機１１００からの書き込み要求の処理の際は、ＣＰＵ１０２３はAfterジャーナルとBeforeジャーナルのどちらか一方のみを持つジャーナルを作成する構成にしてもよい。

SSVOLグループ１０１５は、一つ以上のスナップショットボリューム１０１２で構成される。スナップショットボリューム１０１２は、ある時点におけるデータボリューム１０１１の複製イメージ(スナップショット)を格納する論理ボリュームである。なお、本実施例において、スナップショットボリューム１０１２に格納されるスナップショットは、データボリューム１０１１のフルバックアップであっても、差分バックアップのような論理的なイメージであっても良い。

なお、これらの構成情報は、後述するコントローラ１０２０の制御プログラム１０２８を実行するCPU１０２３によって、管理情報群１０２９で管理される。

コントローラ１０２０は、管理Ｉ／Ｆ１０２１、データＩ／Ｆ１０２２、ストレージＩ／Ｆ１０２５、メインメモリ１０２６、ＣＰＵ１０２３及びタイマ１０２４を備えている。

メインメモリ１０２６には、管理情報群１０２９及び制御プログラム１０２８が記憶されている。ＣＰＵ１０２３は、メインメモリ１０２６に記憶されたコンピュータプログラムである制御プログラム１０２８を実行する。

制御プログラム１０２８がＣＰＵ１０２３に実行されることにより、種々の処理、例えば、スナップショットの取得、ジャーナルの生成、ジャーナルを用いたリカバリ、ジャーナルの開放などが行われる。以下、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するＣＰＵによって処理が行われるものとする。制御プログラム１０２８は、管理計算機１２００やホスト計算機１１００からの要求に応じて記憶装置１０１０に対するデータの入出力を処理することや、ストレージシステム１０００の構成の設定を行うことができる。ストレージシステム１０００の構成の設定としては、例えば、どの論理ボリュームがどの記憶装置１０１０から提供されるかなどを表す情報を設定することがある。該構成の設定を表した情報は、管理情報群１０２９に含まれる。制御プログラム１０２８は、管理情報群１０２９を参照し、該管理情報群１０２９中の情報を基に、上述した種々の処理を実行することができる。情報群１０２９の構成については後述する。

タイマ１０２４は、現在時刻を提供する機能を持つ一般的なタイマとすることができる。ジャーナル作成時やスナップショット取得時に、制御プログラム１０２８によって参照される。

データＩ／Ｆ１０２２は、データネットワーク１３００に対するインタフェース装置であって、一つ以上の通信用ポートを持つ。コントローラ１０２０は、このポートを介して、ホスト計算機１１００（及び／又は他のストレージシステム）とデータや制御命令の送受信を行う。管理Ｉ／Ｆ１０２１は、管理ネットワーク１４００とのインタフェース装置であって、ホスト計算機１１００や管理計算機１２００とデータや制御命令の送受信を行う。ストレージＩ／Ｆ１０２５は、記憶装置１０１０に対するインタフェース装置であって、データや制御命令の送受信を行う。

ホスト計算機１１００は、入力装置（例えばキーボードやマウス）１１４０や、ＣＰＵ１１３０や、表示装置（例えばＣＲＴ（Cathode Ray Tube）或いは液晶ディスプレイ）１１２０や、メモリ１１６０や、データＩ／Ｆ１１１０や、管理Ｉ／Ｆ１１５０を備える。

データＩ／Ｆ１１１０は、データネットワーク１３００に対するインタフェース装置であって、一つ以上の通信ポートを持つ。このポートを介して、ホスト計算機１１００は、ストレージシステム１０００とデータや制御命令の送受信を行う。管理Ｉ／Ｆ１１５０は、管理ネットワーク１４００に対するインタフェース装置であって、システム管理のために（システム管理のために限らなくて良い）管理計算機１２００及びストレージシステム１０００とデータや制御命令の送受信を行う。

メモリ１１６０には、複数のコンピュータプログラム、例えば、アプリケーション１１６１やリカバリマネージャ１１６２が記憶されている。ＣＰＵ１１３０は、メモリ１１６０に記憶された各種プログラムを実行することで各機能を実現することができる。

アプリケーション１１６１は、データボリューム１０１１を利用するアプリケーションプログラムであり、例えば、ＤＢＭＳ（データベースマネジメントシステム）やファイルシステムである。

リカバリマネージャ１１６２は、例えば、アプリケーション１１６１の静止化、ストレージシステム１０００に対するスナップショット取得の要求や特定時点のデータのリカバリ要求等を行う。また、リカバリマネージャ１１６２は、アプリケーションの静止化やその他のイベントや管理者の指示に応じて、ストレージシステム１０００にマーカーの挿入を要求する。当該マーカーは、リカバリを行う際にリカバリポイント選択のための指標として用いられる。リカバリポイントとは、過去の或る時点におけるデータをリカバリする際の該過去の或る時点を意味する。つまり、リカバリポイントを選択することは、どの時点におけるデータをリカバリするかを選択することである。マーカーは、制御プログラム１０２８により、データ長０のジャーナルとしてジャーナルと同等のデータ構成でジャーナルボリューム１０１３内に保存される。この構成についてはジャーナルの構成と共に後述する。リカバリマネージャ１１６２は、管理者や他のプログラムがこれらの機能を実行できるように、インタフェースとしてコマンドラインインタフェース(以降、「ＣＬＩ」と呼ぶ)などを提供する。

なお、説明の都合上、図１では、アプリケーション１１６３を一つとしたが、本実施例ではこれ以上存在してもよい。

管理計算機１２００は、入力装置（例えばキーボードやマウス）１２４０、ＣＰＵ１２３０、表示装置（例えばＣＲＴ或いは液晶ディスプレイ）１２２０、メモリ１２５０及び管理Ｉ／Ｆ１２１０を備える。

管理Ｉ／Ｆ１２１０は、システム管理のために（システム管理に限らなくて良い）ホスト計算機１１００及びストレージシステム１０００とデータや制御命令を送受信する。

メモリ１２５０には、複数のコンピュータプログラム、例えば、設定プログラム１２５１やリカバリ指示プログラム１２５２が記憶されている。ＣＰＵ１２３０はメモリ１２５０に記憶された各種プログラムを実行することで各機能を実現することができる。

設定プログラム１２５１は、管理情報群１０２９の値を設定させるためのプログラムである。なお、管理情報群１０２９の値を設定する場合、該設定プログラム１２５１を実行するＣＰＵ１２３０が、制御プログラム１０２８を実行するＣＰＵ１０２３と通信を行うことができる。

リカバリ指示プログラム１２５２は、リカバリ時に管理者の指示に従い、ジャーナルやマーカーの蓄積情報と基底スナップショットの取得時刻とをストレージシステム１０００から収集し、各種イベント発生時点を含む各時点と当該時点のデータのリカバリに必要なジャーナル適用量の関係性を可視化したインタフェースを提供し、当該可視化したインタフェースを用いてユーザが選択したリカバリポイントのデータを復元するようにストレージシステム１０００に指示を出す。本処理の詳細は後述する。

なお、上記２つのプログラム１２５１及び１２５２は、管理者や他のプログラムがこのプログラムを実行できるように、インタフェースとしてＣＬＩなどを提供することができる。

図２から図７は管理情報群１０２９に含まれる種々のテーブル或いはデータの構成例を示す。なお、各図のテーブルにおいて、参照番号が付されているのは、カラム或いはフィールドを指し、カラム或いはフィールドに格納される値それ自体を指してはいない。従って、以下の説明では、カラム或いはフィールドを指す場合には、参照番号を付して説明し、カラム或いはフィールドを指しているわけではない場合には、参照番号を付さずに説明することにする。

図２は、ジャーナルグループテーブル２０００の構成例を示す。

ジャーナルグループテーブル２０００には、ジャーナルグループ１０１４に関する情報が記録される。本テーブル２０００には、例えば、各ジャーナルグループ１０１４毎に、該ジャーナルグループのID（JNLG_ID）と、順序カウンタとが記録される。具体的には、例えば、本テーブル２０００には、JNLG_ID２００１及び順序カウンタ２００２がある。

JNLG_ID２００１は、ジャーナルグループの識別子（ＩＤ）が格納されるカラムである。この識別子は、設定プログラム１２５１が提供するCLIを管理者が用いてジャーナルグループ１０１４を作成することで、設定される。たとえば、管理者は、「CreateJG -jgid JNLG_1」のようなコマンドを発行できる。これは、ストレージシステム１０００に対する「ジャーナルグループJNLG_1を作成せよ」という命令になる。このJNLG_1という値が、JNLG_ID２００１に格納される。

なお、この設定を行うために、設定プログラム１２５１に従い動作するＣＰＵ１２３０は、制御プログラム１０２８に従い動作するＣＰＵ１０２３と通信を行うことができる。この通信は、例えば、設定プログラム１２５１の設定情報（図示せず）に接続先として登録されているIPアドレスを用いて確立される。以下、前記ＣＰＵ１２３０が各種プログラムを実行する上で、制御プログラム１０２８に従い動作するＣＰＵ１０２３と通信を行う場合は、上記と同様に通信を確立してから行うものとし、説明を省略する。また、リカバリ指示プログラム１２５２に従って動作する場合も同様である。

順序カウンタ２００２は、ジャーナル作成の順序を管理するための番号（順序カウント値）が格納されるカラムである。順序カウンタ２００２に格納される各順序カウント値の初期値は０だが、ホスト計算機１１００からの書込み要求に対してジャーナルを生成するたびに、制御プログラム１０２８によって、順序カウント値は、所定値分更新、例えば１加算される。そして、この加算後の順序カウント値が後述するジャーナルの順序番号７００５にコピーされる。なお、ジャーナルの順序番号は、スナップショットを取得するたびに、制御プログラム１０２８によって、後述するSSVOLグループ管理テーブルの順序番号５００５にコピーされる。この処理により、各ジャーナル作成タイミングとスナップショット取得タイミングの順序関係が記録される。リカバリの際は、制御プログラム１０２８は、この順序関係を用いて、基底スナップショットに適用すべきジャーナルとその適用順序を特定することができる。具体的には、例えば、特定のスナップショットにAfterジャーナルを適用してリカバリを行う場合、制御プログラム１０２８は、当該スナップショットの取得時のジャーナル順序番号より大きく且つ指定されたリカバリポイントのジャーナル順序番号以下のジャーナル順序番号を持つジャーナルを、該ジャーナルのジャーナル順序番号に従って適用する。逆に、特定のスナップショットにBeforeジャーナルを適用する場合、制御プログラム１０２８は、当該スナップショットの取得時のジャーナル順序番号より小さく且つ指定されたリカバリポイントのジャーナル順序番号以上のジャーナル順序番号を持つ各ジャーナルを、該ジャーナルのジャーナル順序番号の大きい順に適用する。

図３は、データボリュームテーブル３０００の構成例を示す。

データボリュームテーブル３０００には、ジャーナルグループ１０１４を構成するデータボリュームに関する情報が記録される。例えば、データボリュームテーブル３０００には、各ジャーナルグループ１０１４毎に、JNLG_ID、該ジャーナルグループに属するデータボリュームのＩＤ、及び該データボリュームのボリュームサイズが記録される。具体的には、例えば、本テーブル３０００には、JNLG_ID３００１、データボリュームＩＤ３００２及びサイズ３００３がある。

JNLG_ID３００１は、ジャーナルグループの識別子が格納されるカラムである。

データボリュームＩＤ３００２は、論理ボリューム（データボリューム）の識別子が格納されるカラムである。該カラムの各エントリ（セル）には、該エントリが対応するJNLG_IDが割り当てられたジャーナルグループに属する論理ボリュームのＩＤが格納される。

サイズ３００３は、論理ボリュームのサイズが格納されるカラムである。該カラムの各エントリ（セル）には、該エントリが対応するデータボリュームＩＤが割り当てられた論理ボリュームのボリュームサイズが格納される。

これらの値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いて、ジャーナルグループにデータボリュームを追加することで、設定することが可能である。たとえば、管理者は、「addDataVOL -jgid JNLG_1 -datavolid LU_11」というコマンドを発行できる。これは、ストレージシステム１０００に対する「ジャーナルグループJNLG_1にデータボリュームLU_11を追加せよ」という命令になる。このJNLG_1がJNLG_ID６００１に格納され、LU_11がデータボリュームＩＤ６００２に格納される。また、このとき、制御プログラム１０２８に従い動作するCPU１０２３が管理しているLU_11のサイズが、サイズ３００３に設定される。なお、単一のジャーナルグループに複数のデータボリュームを設定する場合は、上記のコマンドを複数回実行することができる。

図４は、スナップショットボリューム管理テーブル４０００の構成例を示す。

スナップショットボリューム管理テーブル４０００には、SSVOLグループ１０１５を構成するスナップショットに関する情報が記録される。例えば、各ＳＳＶＯＬグループ（スナップショットボリュームグループ）１０１５毎に、該SSVOLグループのＩＤ、該SSVOLグループに属するスナップショットボリュームのＩＤ、及び該SSVOLグループに対応付けられたデータボリュームのＩＤが格納される。具体的には、例えば、本テーブルには、SSVOLグループＩＤ４００１、スナップショットボリュームＩＤ４００２及び対応データボリュームＩＤ４００３がある。

SSVOLグループＩＤ４００１は、管理対象となるSSVOLグループの識別子が格納されるカラムである。

スナップショットボリュームＩＤ４００２は、論理ボリューム(スナップショットボリューム)の識別子が格納されるカラムである。該カラムの各エントリ（セル）には、該エントリが対応するSSVOLグループIDが割り当てられたSSVOLグループに属するスナップショットボリュームのＩＤが格納される。

対応データボリュームＩＤ４００３は、スナップショット取得対象のデータボリュームの識別子を格納する。該カラムの各エントリ（セル）には、該エントリが対応するSSVOLグループIDが割り当てられたSSVOLグループに対応付けられたデータボリュームのＩＤが格納される。

これらの値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いて、SSVOLグループにスナップショットボリュームとなる論理ボリュームを追加することで設定することが可能である。たとえば、管理者は、「addSSVOL -ssvolgid SSG_1 -ssvolid LU_21 -source LU_11」というコマンドを発行する。これは、ストレージシステム１０００に対する「SSVOLグループSSG_1に、データボリュームLU_11のスナップショットを格納するためのスナップショットボリュームLU_21を追加せよ」という命令になる。このSSG_1がSVOLグループＩＤ４００１に格納され、LU_21がスナップショットボリュームＩＤ４００２に格納され、LU_11が対応データボリュームＩＤ４００３に格納される。

図５は、SSVOLグループ管理テーブル５０００の構成例を示す。

SSVOLグループ管理テーブル５０００には、ジャーナルグループ１０１４とSSVOLグループ１０１５の関連付けに関する情報が記録される。例えば、各ジャーナルグループ１０１４毎に、該ジャーナルグループのIDと、該ジャーナルグループに対応するSSVOLグループのIDと、該SSVOLグループに対応したスナップショットの順序番号と、該スナップショットの取得時刻とが記録される。具体的には、例えば、本テーブル５０００には、JNLG_ID５００１、SSVOLグループID５００２、順序番号５００３及び取得時刻５００４がある。

JNLG_ID５００１は、管理対象となるジャーナルグループの識別子が格納されるカラムである。

SVOLグループID５００２は、JNLG_ID５００１で示されるジャーナルグループのスナップショットを格納するSSVOLグループの識別子が格納される。

これらの値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いて、ジャーナルグループにSSVOLグループを関連付けることにより設定することが可能である。たとえば、管理者は、「addSSVOLG -jgid JNLG_1 -ssvolgid SSG_1」のようなコマンドを発行する。これは、ストレージシステム１０００に対する「ジャーナルグループJNLG_1にSSVOLグループSSG_1を関連付けよ」という命令になる。このJNLG_1がＪＮＬグループＩＤ５００１に格納され、SSG_1の値がＳＳＶＯＬグループＩＤ５００２に格納される。なお、上記コマンドのSSVOLグループの識別子を変更させて複数回実行することで、複数のSSVOLグループをジャーナルグループに関連付けることができる。

順序番号５００３は、SSVOLグループID５００２で示されるSSVOLグループに格納したスナップショットの取得タイミングと、ジャーナル作成タイミングとの順序関係を示す番号（スナップショット順序番号）が格納されるカラムである。制御プログラム１０２８が、スナップショットを格納する場合に、順序カウンタ２００２の順序カウント値を順序番号５００３に設定する。すなわち、順序番号５００３に格納されるスナップショット取得番号は、どのジャーナル順序番号を有するジャーナルまで格納された場合のスナップショットであるかを表す番号となる。

取得時刻５００４は、スナップショット取得要求がストレージシステム１０００に到着した時刻（スナップショット取得時刻）が格納されるカラムである。制御プログラム１０２８が、タイマ１０２４から現在時刻を取得し、取得した現在時刻を、取得時刻５００４に設定する。なお、変形例として、取得時刻５００４には、スナップショット取得要求内に含まれる要求発行時刻としても良い。たとえば、メインフレーム環境では、複数のメインフレームホストがタイマを共有しており、スナップショット取得要求を発行する時刻を提供することができるため、これを利用してもよい。

図６は、ジャーナルボリュームテーブル６０００の構成例を示す。

ジャーナルボリュームテーブル６０００には、ジャーナルグループに対応付けられたジャーナルボリュームに関する情報が記録される。例えば、各ジャーナルグループ１０１４毎に、該ジャーナルグループのIDと、該ジャーナルグループに対応付けられたJNLボリュームのIDと、該JNLボリュームの使用順序とが記録される。具体的には、例えば、本テーブル６０００には、JNLG_ID６００１、JNLボリュームID６００２及び使用順序６００３がある。

JNLG_ID６００１は、ジャーナルグループの識別子が格納されるカラムである。

ＪＮＬボリュームＩＤ６００２は、JNLG_ID６００１で示されるジャーナルグループで利用されるジャーナルボリュームの識別子が格納されるカラムである。

使用順序６００３は、JNLボリュームID６００２で示されるジャーナルボリュームがジャーナルを格納するために使用される順番が格納されるカラムである。

これらの値は、例えば、設定プログラム１２５４が提供するＣＬＩを管理者が用いて、ジャーナルグループにジャーナルボリュームを追加することにより設定することが可能である。たとえば、管理者は、「addJVOL -jgid JNLG_1 -jvolid LU_31」のようなコマンドを発行する。これは、ストレージシステム１０００に対する「ジャーナルグループJNLG_1にジャーナルボリュームLU_31を追加せよ」という命令になる。このJNLG_1がJNLG_ID６００１に格納され、LU_31がJNLボリュームID６００２に格納される。また、使用順序６００３には、この命令により設定されたJNLG_ID６００１の値と同一の値を持つレコードの使用順序６００３の最大値に１を加えたものが格納される。このとき、同一の値を持つレコードが無い場合は、１が格納される。なお、上記コマンドのジャーナルボリュームとなる論理ボリュームの識別子を変更させて複数回実行することで、複数のジャーナルボリュームをジャーナルグループに追加することができる。

図７は、ジャーナル管理データ７０００の構成例を示した図である。

ジャーナル管理データ７０００は、ジャーナルを管理するためのデータである。ジャーナル管理データ７０００は、一つのジャーナルにつき一つ存在し、新たにジャーナルが作成される都度に新たに作成される。本実施例では、マーカーがジャーナルの一種のため、マーカーが作成される場合にも、該マーカーに対応したジャーナル管理データ７０００が作成される。ジャーナル管理データ７０００には、例えば、データボリュームID７００１、適用先アドレス７００２、データ長７００３、生成時刻７００４、順序番号７００５、Afterジャーナル格納ボリュームID７００６、Afterジャーナル格納アドレス７００７、Beforeジャーナル格納ボリュームID７００８、Beforeジャーナル格納アドレス７００９及びコメント７０１０がある。

データボリュームＩＤ７００１は、ジャーナルの適用先となるデータボリュームの識別子が格納されるフィールドである。

適用先アドレス７００２は、データボリュームＩＤ７００１で示されるデータボリューム内での適用先アドレスが格納されるフィールドである。

データ長７００３は適用するデータの長さ、すなわちAfterジャーナル及び／又はBeforeジャーナルの長さが格納されるフィールドである。

これらの値は、制御プログラム１０２８に従って動作するＣＰＵ１０２３がジャーナルを作成する際に、ホスト計算機１１００の書込み要求に応じて設定する値である。なお、ジャーナルがマーカーを意味する場合は、データボリュームＩＤ７００１と適用先アドレス７００２には、NULLが設定される。また、データ長７００３には０が設定される。

生成時刻７００４は、ホスト計算機１１００の書き込み要求がストレージシステム１０００に到着した時刻を保持する。生成時刻７００４の値は、制御プログラム１０２８に従って動作するＣＰＵ１０２３が、コントローラ１０２０のタイマ１０２４から取得し、設定するものである。なお、変形例として、生成時刻７００４には、書込み要求内に含まれる書込み発行時刻（タイムスタンプ）が格納されても良い。

順序番号７００５は、スナップショットの取得タイミングとジャーナル作成タイミングとの順序関係を示す番号が格納されるフィールドである。制御プログラム１０２８が、ジャーナルを作成する時に、順序カウンタ５００２の順序カウント値に１だけ加算した値を順序番号として設定する。

Afterジャーナル格納ボリュームID７００６は、Afterジャーナルを格納している論理ボリューム(ジャーナルボリューム)の識別子が格納されるフィールドである。

Afterジャーナル格納アドレス７００７は、Afterジャーナル格納ボリュームID７００６で示される論理ボリュームにおけるアドレス（Afterジャーナルを格納しているアドレス）が格納されるフィールドである。制御プログラム１０２８が、ジャーナルを作成する時に、Afterジャーナルを格納した場所に応じて、これらの値を設定する。なお、ジャーナルがマーカーを意味する場合は、Afterジャーナル格納ボリュームID７００６とAfterジャーナル格納アドレス７００７には、NULLが設定される。

Beforeジャーナル格納ボリュームID７００８は、Beforeジャーナルを格納している論理ボリューム(ジャーナルボリューム)の識別子が格納されるフィールドである。

Beforeジャーナル格納アドレス７００９は、Beforeジャーナル格納ボリュームID７００８で示される論理ボリュームにおけるアドレス（Beforeジャーナルを格納しているアドレス）が格納されるフィールドである。制御プログラム１０２８が、ジャーナルを作成する時に、Beforeジャーナルを格納した場所に応じて、これらの値を設定する。なお、ジャーナルがマーカーを意味する場合は、Beforeジャーナル格納ボリュームID７００８とBeforeジャーナル格納アドレス７００９には、NULLが設定される。

コメント７０１０は、特定のイベントを示す文字列が格納されるフィールドである。本値は、例えば、ジャーナルがマーカーである場合のみに設定され、リカバリマネージャ１１６２の要求に応じて設定される。ジャーナルがマーカーで無い場合は、コメント７０１０には、NULLが設定される。勿論、これに限定することなく、例えば、ジャーナルがマーカーではない場合に、コメントとして、特定のイベントを示す文字列が格納されても良い。

（２）実施例１の動作。

次に、本実施例の動作の説明を行う。

図８は、リカバリ指示プログラム１２５２が管理者の指示に従いストレージシステム１０００へリカバリの指示を行う際の処理の流れである。

管理者は、リカバリ指示プログラム１２５２が提供するCLIを用いて、本処理を起動する。たとえば、管理者は「showRecoveryConsole -jnlgid JNLG_1」のようなコマンドを発行する。これは、「ジャーナルグループJNLG_1のデータをリカバリするためのコンソールを開け」という命令になる。

本処理が起動された場合、リカバリ指示プログラム１２５２が、制御プログラム１０２８から、管理者から指定されたジャーナルグループ(上記コマンド例ではJNLG_1)に関するジャーナル及びマーカーの蓄積情報と、スナップショットの取得タイミングとを取得する(ステップ８０１０)。ここで取得する情報は、具体的には、SSVOLグループ管理テーブル５０００の情報と、ジャーナル管理データ７０００の情報となる。なお、本ステップでは、通信を行うために、前述した設定プログラム１２５１の設定情報に接続先として登録されていたIPアドレスを用いて予めストレージシステム１０００との通信を確立する。

次に、リカバリ指示プログラム１２５２は、各種イベント発生時点を含む各時点（リカバリポイント）のデータのリカバリに必要なジャーナル適用量を算出する（ステップ８０２０）。本実施例では、BeforeジャーナルもAfterジャーナルの適用可能なので、この処理では、各リカバリポイントの直前のスナップショットを基底スナップショットとしてリカバリを行った場合に適用するジャーナルのデータ長の総計と、直後のスナップショット(存在しなければデータボリューム)を基底スナップショットとしてリカバリを行った場合に適用するジャーナルのデータ長の総計を比較する（データ長は、データ長７００３に格納されている値）。そして、データ値の総計の小さい方を、データのリカバリに必要なジャーナル適用量とする。なお、変形例として、ジャーナルとしてAfterジャーナルのみを保持する計算機システムである場合は、各リカバリポイントの直前のスナップショットを基底スナップショットとしてリカバリを行った場合に適用するジャーナルのデータ長の総計が、データのリカバリに必要なジャーナル適用量となる。同様に、別の変形例において、ジャーナルとしてBeforeジャーナルのみを保持する計算機システムである場合は、各時点の直後のスナップショット(存在しなければデータボリューム)を基底スナップショットとしてリカバリを行った場合に適用するジャーナルのデータ長の総計が、データのリカバリに必要なジャーナル適用量となる。さらに、また別の変形例として、制御プログラム１０２８が、リカバリ時に基底スナップショットの同一のアドレスに複数のジャーナルを適用する必要がある場合に、最後に適用するジャーナル以外のジャーナルの適用をスキップすることができる。この場合は、本ステップのデータのリカバリに必要なジャーナル適用量の算出時も同様に、最後に適用するジャーナル以外のジャーナルのデータ長の加算をスキップすることができる。

次に、リカバリ指示プログラム１２５２は、ステップ８０２０で各時点間のデータのリカバリに必要なジャーナル適用量の関係を可視化したインタフェースを表示装置１２２０に表示する（ステップ８０３０）。このインタフェースは、例えばＧＵＩ（グラフィカルユーザインタフェース）である。詳細は、後述する。

次に、管理者は、表示されたインタフェース上でリカバリポイントを選択する（ステップ８０４０）。リカバリ指示プログラム１２５２は、この選択を受け付ける(ステップ８０５０)。

次に、リカバリ指示プログラム１２５２は、受け付けたリカバリポイントのデータをリカバリすることの要求（リカバリ実行要求）を、制御プログラム１０２８に送信する（ステップ８０６０）。リカバリ実行要求を受け付けた制御プログラム１０２８は、リカバリを実施する。具体的には、制御プログラム１０２８は、リカバリ実行要求で指定されたリカバリポイントに対応したスナップショット取得時刻におけるスナップショットに、該対応したスナップショット取得時刻と上記指定されたリカバリポイントとの間が生成時刻となっているジャーナル管理データに対応したジャーナルを適用することで、上記指定されたリカバリポイントにおけるデータ群をリカバリする。リカバリ実行要求では、スナップショット取得時刻を指定しても良い。

以上が、リカバリ指示プログラム１２５２が、ストレージシステム１０００へリカバリの指示を行う際の処理の流れである。なお、本実施例では、ジャーナル適用量をリカバリ指示プログラム１２５２が算出しているが、変形例として、制御プログラム１０２８が算出し、それをリカバリ指示プログラム１２５２がステップ８０１０において収集しても良い。この場合は、ステップ８０２０の処理は省略可能である。

図９Ａは、ステップ８０３０において表示される第一種のＧＵＩの第一の例である。

このＧＵＩは、リカバリ指示プログラム１２５２によって生成され表示される前述のインタフェースの一例である。以下、各リカバリポイントを含む各時点とジャーナル適用量との関係を二次元グラフで表現したＧＵＩを、「第一種のＧＵＩ」と呼ぶことにする。それに対し、各時点とジャーナル適用量との関係をバーで表現したＧＵＩを、「第二種のＧＵＩ」と呼ぶことにする。これは、リカバリ負荷情報が、ジャーナル適用量以外の場合にも同様とする。

９０１０は、各リカバリポイントを含む各時点でのデータのリカバリに必要なジャーナル適用量の関係を示した２次元グラフである。当該グラフ９０１０の縦軸は、ジャーナル適用量を示し、横軸は、時刻を示している。９０１１は、ステップ８０２０で算出した各リカバリポイントにおけるデータのリカバリに必要なジャーナル適用量をプロットした点を線で結んだものである。９０１２は、マーカーが挿入された時刻、つまりリカバリポイントを示すアイコンである。本アイコンは、マーカーに含まれているコメント７０００に応じて形や色を変更しても良い。マーカーは、ユーザからの指示や、エラーが発生した場合などの所定のイベント発生時に挿入される。９０１３は、マウス等の入力装置によって移動するポインタである。ステップ８０４０において、ユーザがリカバリポイントの選択を行う際に移動させる。

９０２１は、マーカーに含まれているコメントがテキストで表示されるテキストフィールドである。管理者が、９０１０の横軸上の９０１２に９０１３を移動させ、クリックすると、リカバリ指示プログラム１２５２が、当該９０１２に対応するマーカーに含まれているコメントを９０２１に表示する。なお、９０１２が存在しない横軸上の点をクリックすると、９０２１には何も表示されなくてよい。

９０２２は、リカバリポイントがテキストで表示されるテキストフィールドである。管理者が９０１０の横軸上の一点に９０１３を移動させ、クリックすると、リカバリ指示プログラム１２５２が、当該点に対応する時刻をテキストで９０２２に表示する。

９０２３はリカバリに必要なジャーナル適用量がテキストで表示されるテキストフィールドである。管理者が、９０１０の横軸上の一点に９０１３を移動させ、クリックすると、リカバリ指示プログラム１２５２が、当該点に対応するリカバリに必要なジャーナル適用量をテキストで９０２３に表示する。

９０３１は、リカバリポイントの選択を確定するためのボタンである。管理者が、本ボタンを押下すると、９０２２に表示された時点のデータをリカバリすることを、リカバリ指示プログラム１２５２に要求したことになる。９０３２は、図８を用いて説明した処理を終了するためのボタンである。管理者が本ボタンを押下すると、図８を用いて説明した処理を終了することを、リカバリ指示プログラム１２５２に要求したことになる。本要求を受け取ったCPU１２３０は処理を強制終了する。

以上が、ステップ８０３０において表示する第一種のＧＵＩの第一の例である。なお、第一種のＧＵＩの第二の例として、ジャーナルとしてAfterジャーナルのみを保持している場合は、９０１０は、図９Ｂのような形となる。つまり、第一のスナップショット取得時刻と次の第二のスナップショット取得時刻との中間付近には、リカバリ時間のピークは存在せず、第二のスナップショット取得時刻に最も近い時点が、リカバリ時間のピークとなる。逆に、例えば、ジャーナルとしてBeforeジャーナルのみを保持している場合は、９０１０は、例えば、図２２Ａに例示するようになる。つまり、第一のスナップショット取得時刻と次の第二のスナップショット取得時刻との中間付近には、リカバリ時間のピークは存在せず、第一のスナップショット取得時刻に最も近い時点が、リカバリ時間のピークとなる。

なお、線９０１１において、各時点間での傾きは、その時点間で書き込まれたジャーナルのデータ長の総計によって異なる。つまり、同一の長さの時点間において、該総計が大きい場合には、傾きは大きくなり、該総計が小さい場合には、傾きは小さくなる。

図１０Ａは、ステップ８０３０において表示する第二種のＧＵＩの第一の例である。なお、本ＧＵＩにおいて、各リカバリポイントとジャーナル適用量との関係性の表示態様以外は、第一種のＧＵＩと同じであるため、以下では、該関係性の表示態様のみを説明する。

本ＧＵＩでは、２次元グラフ９０１０の代わりに、表示エリア１００１０が表示される。当該表示エリア１００１０では、各時点のデータのリカバリに必要なジャーナル適用量を示すバー１００１１が含まれる。当該バーの横軸は時刻を示し、内部の色がジャーナルの適用量を示している。当該バーの着色方法は、例えば次の通りである。リカバリ指示プログラム１２５２が、ステップ８０２０において算出した各時点のデータリカバリに必要なジャーナル適用量の最大値を検索する。この最大値を２５６として、各時点のデータリカバリに必要なジャーナル適用量の比率K1を求める。そして各時点の色を、（Ｒ，Ｇ，Ｂ）＝(２５６，２５６−K1，２５６−K1)として着色する（RGBは、光の三原色である赤、緑、青の略）。これにより、ジャーナル適用量が多いものほど赤くなるバーが作成できる。なお、着色方法は、この方法に限らず、他種の方法を採用することができる。また、色に限らず、テクスチャやパターンなど他種の態様での表示が行われても良い。表示エリア１００１０において、９０１２、９０１３に関しては図９Ａと同等である。

以上が、ステップ８０３０において表示する第二種のＧＵＩの第一の例である。なお、第二種のＧＵＩの第二の例として、ジャーナルとしてAfterジャーナルのみを保持している場合は、１００１０は図１０Ｂのようになる。すなわち、第一のスナップショット取得時刻と次の第二のスナップショット取得時刻との間では、第二のスナップショット取得時刻により近くなれば、第一のスナップショット取得時刻で取得された第一のスナップショットに適用すべきジャーナルの適用量はより多くなるので、より赤色になる。

以上、図９Ａ、図９Ｂ、図１０Ａ、図１０Ｂ及び図２２Ａに、第一種及び第二種のＧＵＩの例を示したが、各リカバリポイントとジャーナル適用量との関係を示す方法はこれに限定されるものではない。

以上が、実施例１の説明である。当該実施例１によれば、各リカバリポイントとジャーナル適用量との関係性を可視化したインタフェースを管理者に提供することができる。このため、管理者は、どのリカバリポイントを選択すればより短いリカバリ時間でリカバリが可能であるかを把握することができるので、正確に、リカバリ時間を短く抑えられるリカバリポイントを選択できる。

次に第２の実施例について説明する。なお、以下の説明では、実施例１との相違点を主に説明し、実施例１との共通点については、説明を省略或いは簡略する（これは、後の実施例３以降についても同様である）。

実施例１では、各リカバリポイントを含む各時点と当該時点のデータのリカバリに必要なジャーナル適用量との関係性を可視化する例を示した。本実施例では、ジャーナル適用の性能が取得できる場合に、各時点とリカバリ時間との関係性を可視化する例を示す。

（１）実施例２のシステム構成。

本実施例のシステム構成の大部分は実施例１のものと同じであるため、以降は差分を主に説明する。

図１１は、実施例２でのデータボリュームテーブル３０００の一例である。

本実施例では、新たにWrite性能１１００４が追加されている。Write性能１１００４は、データボリュームＩＤ３００２で示される論理ボリュームの書き込み性能が格納されるカラムである。管理者は、例えば、予め書き込み性能テストを行い、その平均値をWrite性能として入力することができる。変形例としては、当該論理ボリュームの性能をモニタリングし、本値をリアルタイムに変更しても良い。

本値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いることにより、設定することが可能である。たとえば、管理者は、「setDataVOLPerformance -datavolid LU_11 -performance 200Mbps」というコマンドを発行できる。これは、ストレージシステム１０００に対する「データボリュームLU_11のWrite性能を200Mbpsとして設定せよ」という命令になる。この200MbpsがWrite性能１１００４に格納される。

図１２は、実施例２でのスナップショットボリューム管理テーブル４０００の一例である。

本実施例では、新たにWrite性能１２００４が追加されている。Write性能１２００４は、スナップショットボリュームＩＤ４００２で示される論理ボリュームの書き込み性能が格納されるカラムである。管理者は、例えば、予め書き込み性能テストを行い、その平均値をWrite性能として入力することができる。変形例としては、当該論理ボリュームの性能をモニタリングし、本値をリアルタイムに変更しても良い。

本値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いることにより、設定することが可能である。たとえば、管理者は、「setSSVOLPerformance -ssvolid LU_21 -performance 200Mbps」というコマンドを発行できる。これは、ストレージシステム１０００に対する「スナップショットボリュームLU_21のWrite性能を200Mbpsとして設定せよ」という命令になる。この200MbpsがWrite性能１２００４に格納される。

図１３は、実施例２でのジャーナルボリューム管理テーブル６０００の一例である。

本実施例では、新たにRead性能１３００４が追加されている。Read性能１３００４は、JNLボリュームIDＩＤ６００２で示される論理ボリュームの読み込み性能が格納されるカラムである。管理者は、例えば、予め読み込み性能テストを行い、その平均値をRead性能として入力することができる。変形例としては、当該論理ボリュームの性能をモニタリングし、本値をリアルタイムに変更しても良い。

本値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いることにより、設定することが可能である。たとえば、管理者は、「setJNLVOLPerformance -ssvolid LU_31 -performance 400Mbps」というコマンドを発行できる。これは、ストレージシステム１０００に対する「ジャーナルボリュームボリュームLU_31のRead性能を400Mbpsとして設定せよ」という命令になる。この400MbpsがRead性能１３００４に格納される。

（２）実施例２の動作。

次に、本実施例の動作の説明を行う。本実施例の動作の大部分は、実施例１の動作と同じであるため、以降は差分を主に説明する。具体的には、例えば、リカバリ指示プログラム１２５２の処理の流れは実施例１とほぼ同じであるため、図８を用いて処理の流れを説明する。

ステップ８０１０では、SSVOLグループ管理テーブル５０００の情報とジャーナル管理データ７０００の情報に加え、リカバリ指示プログラム１２５２は、データボリュームテーブル３０００、スナップショットボリューム管理テーブル４０００、ＳＳＶＯＬグループ管理テーブル５０００、ジャーナルボリュームテーブル６０００を、制御プログラム１０２８から取得する。

次に、ステップ８０２０では、リカバリ指示プログラム１２５２は、ジャーナル適用量ではなく、各リカバリポイントを含む各時点のデータのリカバリにかかる時間（リカバリ時間）を算出する。

この処理では、まず、リカバリ指示プログラム１２５２は、各時点の直前のスナップショットを基底スナップショットとしてリカバリを行った場合に適用するジャーナル管理データを列挙する。そして、リカバリ指示プログラム１２５２は、各ジャーナル管理データに関して、適用先論理ボリュームの書き込み性能でデータ長を割り、ジャーナル書き込み時間を算出する。また、リカバリ指示プログラム１２５２は、ジャーナルを格納しているボリュームの読み込み性能でデータ長を割り、ジャーナル読み込み時間を算出する。そして、この二つの値の大きい方が、当該ジャーナルの適用時間とする。二つの値のうち大きい方としているのは、ジャーナルボリュームからのジャーナルの読み出しと、読み出したジャーナルを適用先論理ボリュームに適用することとを、並行して行うことができるためである。この各ジャーナルの適用時間の総計が、Afterジャーナルによるリカバリ時間となる。

次に、リカバリ指示プログラム１２５２は、直後のスナップショット(存在しなければデータボリューム)を基底スナップショットとしてリカバリを行った場合に適用するジャーナル管理データを列挙する。そして、リカバリ指示プログラム１２５２は、各ジャーナル管理データに関して、適用先論理ボリュームの書き込み性能でデータ長を割り、ジャーナル書き込み時間を算出する。また、リカバリ指示プログラム１２５２は、ジャーナルを格納しているボリュームの読み込み性能でデータ長を割り、ジャーナル読み込み時間を算出する。そして、この二つの値の大きいものを当該ジャーナルの適用時間とする。この各ジャーナルの適用速度の総計がBeforeジャーナルによるリカバリ時間となる。

最後に、上記Afterジャーナルによるリカバリ時間とBeforeジャーナルによるリカバリ時間を比較し、値の小さいものを、リカバリポイントに対応したリカバリ時間とする。

なお、変形例として、ジャーナルとしてAfterジャーナルのみを保持する計算機システムである場合は、Afterジャーナルによるリカバリ時間が、リカバリポイントに対応したリカバリ時間となる。同様に、別の変形例において、ジャーナルとしてBeforeジャーナルのみを保持する計算機システムである場合は、Beforeジャーナルによるリカバリ時間が、リカバリポイントに対応したリカバリ時間となる。さらに、また別の変形例として、制御プログラム１０２８が、リカバリ時に基底スナップショットの同一のアドレスに複数のジャーナルを適用する必要がある場合には、最後に適用するジャーナル以外のジャーナル適用をスキップすることができる。この場合は、本ステップのデータのリカバリにかかる時間の算出時も同様に、最後に適用するジャーナル以外のジャーナル適用時間の加算をスキップする。

次に、リカバリ指示プログラム１２５２は、ステップ８０２０で各時点間のリカバリ時間の関係を可視化したインタフェースを表示する（ステップ８０３０）。このインタフェース例は後述する。

以降の処理は実施例１と同じであるため、説明を省略する。

以上が、リカバリ指示プログラム１２５２が、ストレージシステム１０００へリカバリの指示を行う際の処理の流れである。

なお、本実施例では、ジャーナルボリュームからジャーナルの読み込み処理と、基底スナップショットへの書き込み処理とが並行して行われることを前提としてジャーナル適用速度を算出したが、変形例として、この二つの処理が逐次的に行われる場合は、ステップ８０２０のジャーナルの適用時間は、ジャーナル書き込み時間とジャーナル読み込み時間の和として算出することができる。

さらに、別の変形例では、ジャーナル適用速度自体をモニタリングしておき、その平均値で適用するジャーナルのデータ長の総和を割ることでデータのリカバリにかかる時間を算出しても良い。

図１４Ａは、実施例２における第一種のＧＵＩの第一の例である。

本ＧＵＩは、実施例１の図９Ａとほぼ同等であるため、以下では、差分を主に説明する。

本実施例では、２次元グラフ９０１０の代わりに、各リカバリポイントを含む各時点とリカバリ時間との関係を示した２次元グラフ１４０１０が表示される。当該グラフの縦軸は、リカバリ時間を示し、横軸は、時刻を示している。９０１１は、ステップ８０２０で算出した各時点におけるリカバリ時間をプロットした点を線で結んだものである。９０１２と９０１３は実施例１の図９Ａと同じである。

また、本ＧＵＩでは、リカバリに必要なジャーナル適用量を表示するテキストフィールド９０２３の代わりに、リカバリ時間がテキストで表示されるテキストフィールド１４０２３が表示される。管理者が、９０１０の横軸上の一点に９０１３を移動させ、クリックすると、リカバリ指示プログラム１２５２が、当該点に対応するリカバリ時間をテキストで１４０２３に表示する。

以上が、ステップ８０３０において表示するＧＵＩの例である。なお、変形例として、ジャーナルとしてAfterジャーナルのみを保持している場合は、１４０１０は、例えば、図１４Ｂに例示するようになる。別の変形例として、ジャーナルとしてBeforeジャーナルのみを保持している場合は、格別図示しないが、１４０１０では、９０１１が、例えば、図１４Ｂに例示した９０１１を左右反転したような形となる。

図１５Ａは、実施例２における第二種のＧＵＩの第一の例ある。なお、本ＧＵＩの大部分は図１４Ａと同等であるため、以下では差分を主に説明する。

本ＧＵＩでは２次元グラフ１４０１０の代わりに、各リカバリポイントを含む各時点とリカバ時間との関係を示す表示エリア１５０１０が表示される。当該表示エアリア１５０１０では、各時点でのリカバリ時間を示すバー１５０１１が含まれる。当該バーの横軸は、時刻を示し、内部の色が、リカバリ時間を示している。当該バーの着色方法は、例えば次の通りである。ステップ８０２０において算出した各時点のリカバリ時間の最大値を検索する。この最大値を２５６として、各時点のリカバリ時間の比率K2を求める。そして各時点の色を、（Ｒ，Ｇ，Ｂ）＝(２５６、２５６−K2、２５６−K2)として着色する。これにより、リカバリ時間が長いものほど赤くなるバーが作成できる。なお、９０１２、９０１３に関しては図１４Ａと同等である。

以上が、ステップ８０３０において表示する第二種のＧＵＩの第一の例である。

なお、変形例において、ジャーナルとしてAfterジャーナルのみを保持している場合は、１５０１０は、例えば図１５Ｂに例示するようになる。

以上、図１４Ａ、図１４Ｂ、図１５Ａ、図１５Ｂで本実施例におけるインタフェースの例を示したが、各リカバリポイントを含む各時点とリカバリ時間との関係を示す方法はこれに限定されるものではない。

以上が実施例２の説明である。当該実施例２によれば、ジャーナル適用の性能が取得できる場合に、各時点とリカバリ時間との関係性を可視化したインタフェースを管理者に提供することができる。このため、管理者は、所望のデータをリカバリするためのリカバリポイントが複数個ある場合には、それら複数個のリカバリポイントの中から、リカバリ時間が最も短くて済むリカバリポイントを正確に選択することができる。そのため、リカバリ時間を短く抑えることができる。

次に第３の実施例について説明する。実施例１では、リカバリの際に基底スナップショットへ直接ジャーナル適用をしていた。本実施例では、リカバリの際に基底スナップショットの複製を他のボリュームに作成し、その複製にジャーナルを適用する場合の適用例を示す。

（１）実施例３のシステム構成。

本実施例のシステム構成の大部分は実施例１のものと同じであるため、以下では差分を主に説明する。

本実施例の計算機システムの構成は、実施例１とほぼ同じなので、図１を用いて構成を説明する。

本実施例では、制御プログラム１０２８は、特定時点（リカバリポイント）のデータをリカバリする際に、スナップショット取得元のデータボリュームへ、基底スナップショットの複製を作成する。このとき、制御プログラム１０２８は、基底スナップショットが通常のフルバックアップである場合は、全データをデータボリュームへコピーする。ただし、制御プログラム１０２８が、基底スナップショットとデータボリュームとの差分を管理している場合は、差分のみをコピーして基底スナップショットの複製を作成する。基底スナップショットが、スナップショット取得以降のデータボリュームへの書き込みにより上書きされた箇所のスナップショット取得時点のデータ（上書き時に退避させておいたもの）の集合と、データボリュームのデータを組み合わせて作成した仮想的なイメージである場合は、退避させたデータをデータボリュームへ書き戻すことで基底スナップショットの複製を作成する。この場合、該データボリューム内のデータを別の論理ボリュームにコピーし、該別の論理ボリュームに、退避させたデータを書き戻しても良い。

上記のように、複製を作成した後に、制御プログラム１０２８は、その複製に対してジャーナルを適用することでリカバリを行う。

図１６は、実施例３でのSSVOLグループ管理テーブル５０００の一例である。

本実施例では、スナップショット１６００５が追加されている。スナップショット１６００５は、スナップショットのタイプを示す文字列が格納されるカラムである。具体的には、例えば、「フルバックアップ」という文字列が格納されている場合は、ＳＳＶＯＬグループＩＤ５００２で示されるＳＳＶＯＬグループには、フルバックアップが格納されていることを意味する。「差分管理フルバックアップ」が格納されている場合は、ＳＳＶＯＬグループＩＤ５００２で示されるＳＳＶＯＬグループには、基底スナップショットとデータボリュームとの差分の管理を行うフルバックアップが格納されていることを意味する。「スナップショット」が格納されている場合は、ＳＳＶＯＬグループＩＤ５００２で示されるＳＳＶＯＬグループには、スナップショット取得以降のデータボリュームへの書き込みにより上書きされた箇所のスナップショット取得時点のデータの集合と、データボリュームのデータを組み合わせて作成した仮想的なイメージが格納されていることを意味する。

この値は、例えば、設定プログラム１２５１が提供するＣＬＩを管理者が用いて、ジャーナルグループにSSVOLグループを関連付けることにより、設定することが可能である。たとえば、管理者は、「addSSVOLG -jgid JNLG_1 -ssvolgid SSG_1 -type フルバックアップ」のようなコマンドを発行する。これは、ストレージシステム１０００に対する「ジャーナルグループJNLG_1にフルバックアップを格納するSSVOLグループSSG_1を関連付けよ」という命令になる。このJNLG_1がＪＮＬグループＩＤ８００１に格納され、SSG_1の値がＳＳＶＯＬグループＩＤ８００２に格納され、フルバックアップがスナップショットタイプ１６００５に格納される。なお、上記コマンドのSSVOLグループの識別子を変更させて複数回実行することで、複数のSSVOLグループをジャーナルグループに関連付けることができる。

また、本実施例では、リカバリ時コピー量１６００６が追加されている。リカバリ時コピー量１６００６は、リカバリの際に基底スナップショットの複製をデータボリュームに作成する際に発生するデータコピー量が格納されるカラムである。本値は、スナップショット取得時点に設定され、スナップショットタイプに応じて、適宜更新される。スナップショットタイプが、「フルバックアップ」である場合、制御プログラム１０２８は、スナップショット取得時にＳＳＶＯＬグループＩＤで示されるＳＳＶＯＬグループに属するスナップショットボリュームのサイズの総計を本値に設定する。その後のこの値の更新は、行わない。スナップショットタイプが、「差分管理フルバックアップ」あるいは「スナップショット」である場合、制御プログラム１０２８は、スナップショット取得時には０を設定する。その後、データボリュームへの書き込みにより、スナップショット取得時点のデータが上書きされる毎に上書きされたサイズの総計が設定される。

いずれのスナップショットタイプであっても、本実施例では、ジャーナルの適用によるデータ転送のみならず、複製作成のためのデータ転送が発生する。本実施例では、複製作成のために転送されるデータの総量が、ジャーナル適用容量に加味される。以下、詳述する。

（２）実施例３の動作。

次に、本実施例の動作の説明を行う。

本実施例の動作の大部分は実施例１の動作と同じであるため、以降は差分を主に説明する。

リカバリ指示プログラム１２５２が、管理者の指示に従いストレージシステム１０００へリカバリの指示を行う際の本実施例における処理の流れは実施例１とほぼ同じであるため、図８を用いて処理の流れを説明する。

ステップ８０１０は実施例１と同じであるため、説明を省略する。

次に、ステップ８０２０では、リカバリ指示プログラム１２５２が、各時点のデータをリカバリする際に基底スナップショットの複製をデータボリュームへ作成する際のデータコピー量と、ジャーナル適用量との総和（以下、トータル転送データ量）を求める（ステップ８０２０）。つまり、実施例１で算出方法を示したジャーナル適用量とリカバリ時コピー量の総和となる。従って、例えば、実施例３において、第一種のＧＵＩの第一の例は、図２２Ｂに例示するように、９０１１は、図９Ａに例示した９０１１よりも全体的に上がる。各ジャーナル適用量にデータコピー量が加算されたためである。

ステップ８０３０以降は、実施例１と同じであるため、説明を省略する。

以上が実施例３の説明である。当該実施例３によれば、リカバリの際に基底スナップショットの複製を他のボリュームに作成し、その複製にジャーナルを適用する場合において、各時点とトータル転送データ量とを可視化したインタフェースを管理者に提供することができる。このため、管理者は、所望のデータをリカバリするためのリカバリポイントが複数個ある場合には、それら複数個のリカバリポイントの中から、リカバリ時間が最も短くて済むリカバリポイントを正確に選択することができる。そのため、リカバリ時間を短く抑えることができる。

次に第４の実施例について説明する。実施例１から実施例３では、各リカバリポイントを含む連続した各時点とリカバリ負荷（具体的には、ジャーナル適用量、リカバリ時間、トータル転送データ量）との関係を示すＧＵＩが表示された。本実施例では、複数のリカバリポイントの中から、管理者の指示従って絞り込まれたリカバリポイント候補をリストアップし、該リストアップされたリカバリポイント候補から、最終的にリカバリポイントを選択する。以下、詳細に説明する。

（１）実施例４のシステム構成。

本実施例では、管理計算機１２００のメモリ１２５０は、リカバリポリシー１２５３を記憶している。リカバリポリシー１２５３は、リカバリ指示プログラム１２５２が管理者の指示に従いリカバリポイントをリストアップする際に、リカバリ指示プログラム１２５２に利用される情報である。本実施例では、リカバリポリシー１２５３は、テキストファイル形式で記憶されているものとする。ただし、変形例として別の形式で記憶されていても良い。

リカバリ指示プログラム１２５２は、リカバリポリシー１２５３及び管理者が指定するリカバリポイント候補を基に、リカバリポイント候補をリストアップして管理者に提示する。以下、管理者が指定するリカバリポイント候補を「第一のリカバリポイント候補」と呼び、該第一のリカバリポイント候補とリカバリポリシー１２５３とに基づいてリストアップされるリカバリポイント候補を、単に「リカバリポイント候補」と呼ぶ。

図１８は、リカバリポリシー１２５３としてのテキストファイルの一例である。

リカバリポリシー１２５３には、一以上の条件が記述される。各条件において、行頭が「#」で始まっている条件は、コメントとして無視される。つまり、条件を表す文字列の頭に「#」を付けるか否かで、その条件を有効とするか無効とするかが選択可能である。

行頭から「JNLG ID」で始まっている行は、ポリシーを設定するジャーナルグループを示している。そして次の「JNLG ID」で始まる行が現れるまでが、当該ジャーナルグループのポリシー（条件の集合）となる。

「データ未更新による最大データ損失量（時間）」で始まる行は、リカバリポイントとして許容可能な時点の範囲を示す。特に、当該行では、管理者が指定した第一のリカバリポイント候補に対して相対的な過去の時間の範囲を示す。具体的には、例えば、「データ未更新による最大データ損失量（時間） = 30min」と登録してある場合は、管理者が指定した第一のリカバリポイント候補から過去３０分前の時点までが許容範囲となる。

「データ更新による最大データ損失量（時間）」で始まる行は、リカバリポイントとして許容可能な時点の範囲を示す。特に当該行では、管理者が指定した第一のリカバリポイント候補に対して相対的な未来の時間の範囲を示す。具体的には、例えば、「データ更新による最大データ損失量（時間） = 30min」と登録してある場合は、管理者が指定した第一のリカバリポイント候補から３０分後の時点までが許容範囲となる。

「データ未更新による最大データ損失量（データ量）」で始まる行は、リカバリポイントとして許容可能なデータそれ自体の損失量を示す。特に当該行では、管理者が指定した第一のリカバリポイント候補に対して相対的に未更新なデータの損失量の範囲を示す。具体的には、例えば、「データ未更新による最大データ損失量（データ量） = 30Gb」と登録してある場合は、管理者が指定した第一のリカバリポイント候補のデータから30Gbのデータ更新分遡るまでの各データの存在時点がリカバリポイントの許容範囲となる。

「データ更新による最大データ損失量（データ量）」で始まる行は、リカバリポイントとして許容可能なデータそれ自体の損失量を示す。特に当該行では、管理者が指定した第一のリカバリポイント候補に対して相対的に更新済みのデータ量の範囲を示す。具体的には、例えば、「データ更新による最大データ損失量（データ量） = 30Gb」と登録してある場合は、管理者が指定した第一のリカバリポイント候補のデータから30Gbのデータ更新を行うまでの各データの存在時点がリカバリポイントの許容範囲となる。

「最大ジャーナル適用量」で始まる行は、リカバリ処理において許容可能なジャーナルの適用量を示す。具体的には、例えば、「最大ジャーナル適用量= 30Gb」と登録してある場合は、リカバリ処理において許容可能なジャーナルの適用量が30Gbとなる。

なお、以上のポリシーを示す行（つまり、ポリシーに含まれる条件）は、管理者が選択的に指定することが可能である。また、変形例として、それぞれのポリシーの優先順位を決定しても良い。なお、本ポリシーは一例であり、システムの実装に応じてこれら以外のポリシーも設定可能である。

（２）実施例４の動作。

次に、本実施例の動作の説明を行う。

図１９は、実施例４において、リカバリ指示プログラム１２５２が管理者の指示に従いストレージシステム１０００へリカバリの指示を行う際の処理の流れである。本処理の流れは実施例１とほぼ同じであるため、差分を主に説明する。

ステップ８０２０までは、実施例１と同じであるため、説明を省略する。

ステップ１９０３０では、リカバリ指示プログラム１２５２が、取得したジャーナル及びマーカーの蓄積情報から、リカバリ可能な時点の範囲（つまり、選択可能な複数のリカバリポイント）を表示する。本インタフェースについては後述する。

次に、管理者は、表示されたインタフェース上で、第一のリカバリポイント候補を選択する（ステップ１９０３３）。

次に、リカバリ指示プログラム１２５２は、この選択された第一のリカバリポイント候補とリカバリポリシー１２５３とに基づき、リカバリポリシー１２５３に記述された条件にマッチする各リカバリポイントをリカバリポイント候補として表示する(ステップ１９０３６)。本インタフェースについては後述する。

次に、管理者は、ステップ１９０３６において表示されたインタフェースから、所望のリカバリポイントを選択する（ステップ８０４０）。以降は実施例１と同じであるため説明を省略する。

図２０は、ステップ１９０３０において表示されるインタフェースの例である。

本インタフェースの大部分は、図９Ａと同じであるため、以降、差分を主に説明する。

本インタフェース（ＧＵＩ）では、２次元グラフ９０１０の代わりに、リカバリ可能な時点の範囲を示す数直線２００１０が表示される。当該数直線２００１０の横軸は、時刻を示す。９０１２及び９０１３に関しては、図９Ａと同じであるため説明を省略する。また、本ＧＵＩでは、テキストフィールド９０２３は必要ないため、表示されなくてよい。

９０３１は、第一のリカバリポイント候補の選択を確定するためのボタンである。管理者が、本ボタン９０３１を押下すると、９０２２に表示された時点を第一のリカバリポイント候補とすることを、リカバリ指示プログラム１２５２へ指示したことになる。

図２１は、ステップ１９０３６において表示されるインタフェースの例である。

２１０１９は、マウス等の入力装置によって移動するポインタである。ステップ８０４０において、管理者が、リカバリポイントの選択を行う際等に移動させる。

２１０１０は、管理者が指定した第一のリカバリポイント候補とリカバリポリシー１２５３とに基づきリストアップされたリカバリポイント候補の一覧である。２１０１１は、どの候補をリカバリポイントとするかを示す列である。本列は、管理者がリカバリポイントとして指定したいリカバリポイント候補の行を、ポインタ２１０１９を用いて選択すると、チェックマークが記される。本列のチェックマークは、リカバリポイント候補間で排他的に表示される。

２１０１２は、リカバリポイント候補の時刻がテキストで表示される列である。２１０１３は、リカバリポイント候補に対応したマーカー中のコメントがテキストで表示される列である。マーカーが挿入されていない場合は、何も表示されない。つまり、本発明において、リカバリポイントは、マーカーが挿入された時点に代えて又は加えて、マーカーが挿入されていない時点でも良い。つまり、マーカーが無くても、ＣＤＰが作動することができる。言い換えれば、ジャーナルを保持している期間のうちいずれの時点もリカバリポイントとなり得る。２１０１４は、リカバリポイント候補に対応したジャーナル適用量がテキストで表示される列である。２１０１５は、リカバリポイント候補のデータが、管理者が選択した第一のリカバリポイント候補のデータから相対的に失っているデータ量を示す列である。２１０１６は、管理者が選択した第一のリカバリポイント候補を示す列である。管理者が選択した第一のリカバリポイント候補である場合は「○」が表示される。それ以外は何も表示されない。

２１０２１は、リカバリポイントの選択を確定するためのボタンである。管理者が本ボタンを押下すると、２１０１１にチェックマークが表示されているリカバリポイント候補のデータをリカバリすることを、リカバリ指示プログラム１２５２に要求したことになる。２１０２２は、図１９を用いて説明した処理を終了するためのボタンである。管理者が本ボタンを押下すると、図１９を用いて説明した処理を終了することを、リカバリ指示プログラム１２５２に従って動作するCPU１２３０へ要求したことになる。本要求を受け取ったCPU１２３０は処理を強制終了する。

以上が実施例４の説明である。当該実施例４によれば、まず、複数のリカバリポイントが選択可能に表示され、管理者は、それら複数のリカバリポイントの中から、基準としてのリカバリポイント（第一のリカバリポイント候補）を選択する。その後、第一のリカバリポイント候補を基準とした条件に合致するリカバリポイント候補であって、リカバリポリシー１２５３に記述されている有効の条件に合致するリカバリポイント候補が、複数のリカバリポイントの中から絞り込まれ、リストアップされる。リストアップされたリカバリポイント候補が表示されたＧＵＩでは、各リカバリポイント候補とジャーナル適用量との関係が可視化されている。このため、管理者は、第一のリカバリポイント候補を基準とした所望の条件に合致するリカバリポイント候補が複数個ある場合には、それら複数個のリカバリポイント候補の中から、リカバリ時間が短くて済むリカバリポイント候補を正確に選択することができる。そのため、リカバリ時間を短く抑えることができる。

以上、本発明の幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

実施例１に係る計算機システムの構成例を示す図である。実施例１におけるジャーナルグループテーブルの一例を示す図である。実施例１におけるデータボリュームテーブルの一例を示す図である。実施例１におけるスナップショットボリューム管理テーブルの一例を示す図である。実施例１におけるＳＳＶＯＬグループ管理テーブルの一例を示す図である。実施例１におけるジャーナルボリュームテーブルの一例を示す図である。実施例１におけるジャーナル管理データの一例を示す図である。実施例１においてリカバリ指示プログラムが実行する処理の流れの一例を示す図である。図９Ａは、実施例１で表示される第一種のＧＵＩの第一の例を示す図である。図９Ｂは、該第一種のＧＵＩの第二の例を示す図である。図１０Ａは、実施例１で表示される第二種のＧＵＩの第一の例を示す図である。図１０Ｂは、該第二種のＧＵＩの第二の例を示す図である。実施例２におけるデータボリュームテーブルの一例を示す図である。実施例２におけるスナップショットボリューム管理テーブルの一例を示す図である。実施例２におけるジャーナルボリュームテーブルの一例を示す図である。図１４Ａは、実施例２で表示される第一種のＧＵＩの第一の例を示す図である。図１４Ｂは、該第一種のＧＵＩの第二の例を示す図である。図１５Ａは、実施例２で表示される第二種のＧＵＩの第一の例を示す図である。図１５Ｂは、該第二種のＧＵＩの第二の例を示す図である。実施例３におけるＳＳＶＯＬグループ管理テーブルの一例を示す図である。実施例４における計算機システムの構成例を示す図である。実施例４におけるリカバリポリシーの一例を示す図である。実施例４におけるリカバリ指示プログラムの処理の流れの一例を示す図である。実施例４で表示される、選択可能な複数のリカバリポイントを表したＧＵＩの例を示す図である。実施例４で表示される、複数のリカバリポイントが絞り込まれた選択可能な一以上のリカバリポイント候補とジャーナル適用量との関係を表したＧＵＩの例を示す図である。図２２Ａは、実施例１で表示される第一種のＧＵＩの第三の例を示す図である。図２２Ｂは、実施例３で表示される第一種のＧＵＩの第一の例を示す図である。

符号の説明

１０００…ストレージシステム、１１００…ホスト計算機、１２００…管理計算機

Claims

ストレージシステムの制御装置において、
前記ストレージシステムが、
データが格納されるデータ記憶装置の複数のリカバリポイントを記憶する記憶域と、
前記複数のリカバリポイントのうち、リカバリ実行要求で指定されたリカバリポイントにおいてデータをリカバリするリカバリ実行部と、
を備え、
前記制御装置が、
リカバリの指示が入力される入力装置と、
前記リカバリの指示を受けた際、前記ストレージ装置から、前記複数のリカバリポイントを取得する取得部と、
前記複数のリカバリポイントを取得した後に、各リカバリポイントにおいて、リカバリする際の負荷を算出する算出部と、
前記各リカバリポイントと、前記各リカバリポイントについて算出されたリカバリ負荷との対応関係を可視化した表示画面を表示する表示部と、
ユーザ所望のリカバリポイントの選択を受け付ける前記入力装置と、
前記リカバリ実行要求と、前記選択されたリカバリポイントと、を前記リカバリ実行部に送信するリカバリ要求部と
を備える制御装置。
前記リカバリ実行部は、前記制御装置から前記リカバリ要求を受信すると、複数のスナップショットのうち、前記選択されたリカバリポイントに対応するスナップショットに、ジャーナルを適用することで、データのリカバリを実行する、
請求項１記載の制御装置。
前記各リカバリポイントにおける前記リカバリ負荷は、当該リカバリポイントでのデータをリカバリするために転送するデータの合計サイズであるトータル転送データサイズであり、該トータル転送データサイズには、前記選択されたリカバリポイントに対応するスナップショットに適用する一以上のジャーナルのデータ量が含まれる、
請求項２記載の制御装置。
前記リカバリ実行部が、前記選択されたリカバリポイントに対応するスナップショットの一部又は全部を、該一部又は全部が記憶されている記憶装置とは別の記憶装置にコピーするように構成されており、
前記各リカバリポイントに対応した前記トータル転送データサイズが、前記選択されたリカバリポイントに対応するスナップショットに適用するジャーナルのデータ量と、前記コピーされるスナップショットの一部又は全部のデータ量との和である、
請求項３記載の制御装置。
前記リカバリ負荷情報は、リカバリに要する時間長であるリカバリ時間である、
請求項１記載の制御装置。
前記リカバリ実行部が、リカバリの際、ジャーナルが記憶されているジャーナル記憶装置から、ジャーナルを読出し、前記リカバリポイントにおけるデータ群のリカバリ先となるリカバリ先記憶装置に、該読み出したジャーナルを書込み、
前記算出部が、前記ジャーナル記憶装置の読出し性能と、前記リカバリ先記憶装置の書込み性能と、前記トータル転送データサイズとに基づいて前記リカバリ時間を算出し、
前記表示部が、前記各リカバリポイントについて前記算出されたリカバリ時間と、前記各リカバリポイントとの対応関係を可視化した前記表示画面を表示する、
請求項５記載の制御装置。
前記表示画面では、前記複数のリカバリポイントが時系列に並べられ、前記複数のリカバリポイントの各々に、該リカバリポイントに対応したリカバリ負荷を表す値が対応付けられている、
請求項１記載の制御装置。
前記ジャーナルには、前記データ記憶装置に書込まれるデータであるAfterジャーナルと、該データによって上書きされるデータであるBeforeジャーナルとの少なくとも一種類があり、
前記リカバリ実行部が、Afterジャーナル及びBeforeジャーナルの少なくとも一方を適用することによりリカバリを実行するように構成されており、
前記算出部が、第一のスナップショット取得時点と該第一のスナップショット取得時点の次のスナップショット取得時点である第二のスナップショット取得時点との間が書込み時点である各ジャーナルのジャーナルサイズと、前記リカバリ実行部が適用するジャーナル種類とに基づいて、前記第一のスナップショット取得時点と前記第二のスナップショット取得時点との間にあるリカバリポイントでの前記トータル転送データサイズを算出する、
請求項２記載の制御装置。
前記ジャーナルの種類として、前記Afterジャーナルと前記Beforeジャーナルとの両方があり、
前記表示部が、前記第一のスナップショット取得時点と前記第二のスナップショット取得時点との間に属するリカバリポイントについて、前記Afterジャーナルと前記Beforeジャーナルの両方を適用した場合にリカバリ負荷の小さくなる方を、該リカバリポイントに対応したリカバリ負荷として前記表示画面を表示する、
請求項８記載の制御装置。
リカバリポイントの絞込みのための一以上の条件が記述されたポリシーを記憶する記憶域を備え、
前記表示部が、前記複数のリカバリポイントのうち前記ポリシーに記述された一以上の条件の全部又は一部に合致する一以上のリカバリポイントを前記表示画面に表示する、
請求項１記載の制御装置。
前記入力装置が、複数のリカバリポイントからリカバリポイント候補の選択を前記ユーザから受け付け、該選択されたリカバリポイントを含む、前記ポリシーに記述された前記一以上の条件に合致する一以上のリカバリポイントを絞り込み、
前記表示部が、前記絞り込まれた一以上のリカバリポイントと該一以上のリカバリポイントにそれぞれ対応した一以上のリカバリ負荷情報との対応関係を可視化した前記表示画面を表示し、
前記入力装置が、前記絞り込まれた一以上のリカバリポイントの中から前記ユーザ所望のリカバリポイントの選択を受け付ける、
請求項１０記載の制御装置。
前記ポリシーに記述される前記一以上の条件には、前記ユーザに選択されるリカバリポイント候補を基準とした他の各リカバリポイントでの各差分許容値が含まれ、
前記差分許容値は、前記リカバリポイント候補と他の各リカバリポイントとの時間及び／又はデータサイズの差分である、
請求項１０記載の制御装置。
前記各リカバリポイントにおける前記リカバリ負荷は、前記データ記憶装置のデータ群をリカバリするために転送する際のデータの合計サイズであるトータル転送データサイズであり、前記トータル転送データサイズには、前記選択されたリカバリポイントに対応するスナップショットに適用する一以上のジャーナルのデータ量が含まれ、
前記表示画面では、前記複数のリカバリポイントが時系列に並べられ、前記複数のリカバリポイントの各々に、該リカバリポイントに対応したリカバリ負荷を表す値が対応付けられ、
前記ジャーナルには、前記データ記憶装置に書込まれるデータであるAfterジャーナルと、該データによって上書きされるデータであるBeforeジャーナルとの少なくとも一種類があり、
前記リカバリ実行部が、Afterジャーナル及びBeforeジャーナルの少なくとも一方を適用することによりリカバリを実行するように構成されており、
前記算出部が、第一のスナップショット取得時点と該第一のスナップショット取得時点の次のスナップショット取得時点である第二のスナップショット取得時点との間が書込み時点である各ジャーナルのジャーナルサイズと、前記リカバリ実行部が適用するジャーナル種類とに基づいて、前記第一のスナップショット取得時点と前記第二のスナップショット取得時点との間にあるリカバリポイントでの前記トータル転送データサイズを算出する、
請求項１記載の制御装置。
ストレージシステムと計算機とを備えた計算機システムにおいて、
前記ストレージシステムが、
データが格納されるデータ記憶装置の複数のリカバリポイントを記憶する記憶域と、
前記複数のリカバリポイントのうち、リカバリ実行要求で指定されたリカバリポイントにおいてデータをリカバリするリカバリ実行部と
を備え、
前記計算機が、
リカバリの指示が入力される入力装置と、
前記リカバリの指示を受けた際、前記ストレージ装置から、前記複数のリカバリポイントを取得する取得部と、
前記複数のリカバリポイントを取得した後に、各リカバリポイントにおいて、リカバリする際の負荷を算出する算出部と、
前記各リカバリポイントと、前記各リカバリポイントについて算出されたリカバリ負荷との対応関係を可視化した画面を表示する表示部と、
ユーザ所望のリカバリポイントの選択を受け付ける前記入力装置と、
前記リカバリ実行要求と、前記選択されたリカバリポイントと、を前記リカバリ実行部に送信するリカバリ要求部と
を備える、
計算機システム。
データが格納されるデータ記憶装置の複数のリカバリポイントを取得し、
各リカバリポイントにおいて、リカバリする際の負荷を算出し、
前記各リカバリポイントと、前記各リカバリポイントについて算出されたリカバリ負荷との対応関係を可視化した表示画面を表示し、
ユーザから所望のリカバリポイントの選択を受け、
複数のスナップショット取得時点のうち前記選択されたリカバリポイントに対応するスナップショットにジャーナルを適用することで、データをリカバリする、
リカバリ方法。