JP2008181274A - 管理装置および管理方法 - Google Patents

Abstract

【課題】過去の或る時点におけるDBデータを回復しそのDBデータにアクセス可能なシステム構成を構築するDB回復処理を容易に行えるようにする。
【解決手段】管理装置が、システム構成の変更履歴を表す構成履歴情報を記憶し、該情報から過去の或る時点である回復時点でのシステム構成を特定し、現時点でのシステム構成を特定し、回復時点でのシステム構成と現時点でのシステム構成とを比較し、該比較の結果を基に、回復時点におけるデータを回復した場合に該回復されたデータにアクセスするために現時点のシステム構成において設定変更が必要となるシステム構成部分があるか否かを特定する。該システム構成部分が特定された場合、該システム構成部分の設定変更を行える要素に対し、必要な設定変更に関する指示を出すことにより、回復されたデータにデータ使用部がアクセスすることを可能にするシステム構成を構築させる。
【選択図】図１

Description

本発明は、計算機システムにおける過去の或る時点のデータを回復するための技術に関する。

企業計算機システム等で利用されるデータベース（以下、DB）のデータは、一般に記憶装置に格納され、データベース管理システム（以下、DBMS）と呼ばれるソフトウェアにより管理される。DBデータ（DBを構成する複数のデータのうちの少なくとも一つ）は、定期的にバックアップが取得され（言い換えれば、バックアップが実行され）、システム障害等が発生した場合には、バックアップデータ（バックアップされたDBデータ）とDBデータの更新履歴であるログとを用いて、所望する時点の状態に回復される。

ログを利用したDB回復処理（DBデータを回復する処理）は、ログに記録された更新履歴通りのデータ更新を再度実行することに他ならない。そのため、バックアップの取得頻度が低い場合、多量のログを用いて古いDBデータから回復を行わなければならなくなる可能性が高く、DB回復処理に要する時間が長時間化すると考えられる。また、ログを用いたDB回復処理のベースとなるDBデータ（バックアップデータ等）でデータ整合性が確保されていない場合、データ整合性を回復するために、より古くからのログを利用してDB回復処理を行う必要がある。

DB回復処理に要する時間の短縮化を目的とした技術が、例えば文献１（特開2004-252686号公報）に開示されている。文献１では、記憶装置でもデータの更新履歴（以下、ストレージジャーナル）を取得する。これにより、記憶装置内のデータを任意の時点の状態に戻れるようにし、高頻度でバックアップを取得していることと等価な効果が得られる。また、DBMSから記憶装置内のDBデータについて整合性が確保された時点にその旨の情報を取得し、ストレージジャーナル内にその情報も同時に記憶する。この情報を利用し、記憶装置内のデータをDBの回復処理に時間がかからない時点に戻すことができるようにする。

また、計算機システムの処理能力増強等の理由により、計算機システムに関わる構成（以下、「システム構成」と略記する）が変更される可能性がある。そのため、過去にバックアップされたデータが現在のシステム構成では利用できない可能性がある。文献２（特開2005-182588号公報）では、データのバックアップ取得時の計算機から記憶装置の間の構成情報を保持し、バックアップされたデータが現在のシステム構成で利用可能か確認する技術が開示されている。

特開2004-252686号公報 特開2005-182588号公報

例えば、文献１で開示された技術では、システム構成まで考慮されていない。そのため、ストレージジャーナルを用いて記憶装置内でデータがある時点の状態に戻されたとしても、システム構成が原因で、計算機がそのデータを利用できないことが生じ得る。

文献２で開示された技術では、バックアップデータ（バックアップされたデータ）を現在のシステム構成で利用可能かどうか判断が行われる。しかし、現在のシステム構成では利用不可と判断された場合に、システム構成を変更するための支援は行われない。現在のシステム構成で利用不可であっても、バックアップデータに応じたシステム構成を構築（例えば回復或いは新規構築）することにより、バックアップデータを利用できるようになる。現状では、このシステム構成の構築は管理者が人手で行う必要がある。

従って、本発明の目的は、過去の或る時点におけるDBデータを回復しそのDBデータにアクセス可能なシステム構成を構築するDB回復処理を容易に行えるようにすることにある。

ホスト計算機が記憶装置にアクセスする計算機システム中で該ホスト計算機及び該記憶装置に接続された管理装置に、構成履歴記憶部と、設定変更要否特定部と、データ回復部と、システム構成構築部とを備える。構成履歴記憶部は、前記ホスト計算機においてデータを使用するデータ使用部が前記記憶装置内のデータにアクセスするまでのアクセス環境に関わる構成であるシステム構成の変更履歴を表す構成履歴情報を記憶する。設定変更要否特定部は、前記構成履歴情報を参照することにより過去の或る時点である回復時点でのシステム構成を特定し、現時点でのシステム構成を特定し、回復時点での前記システム構成と現時点での前記システム構成とを比較し、該比較の結果を基に、回復時点におけるデータを回復した場合に該回復されたデータにアクセスするための設定変更が必要となるシステム構成部分が現時点のシステム構成においてあるか否かを特定する。データ回復部は、前記回復時点におけるデータを前記記憶装置に回復させる。システム構成構築部は、前記システム構成部分が特定された場合、該システム構成部分の設定変更を行える要素（例えば、後述するファイルシステム、ボリュームマネージャ、仮想化スイッチ内の制御プログラム、及び記憶装置内の制御プログラムのうちの少なくとも一つ）に対し、必要な設定変更に関する指示を出すことにより、前記回復されたデータに前記データ使用部がアクセスすることを可能にするシステム構成を構築させる。なお、システム構成としては、例えば、一以上のホスト計算機のうちのどのホスト計算機において、どのコンピュータプログラムが記憶装置内のどこに記憶されているデータにアクセスし、そのコンピュータプログラムからそのデータへのアクセスパスはどのような構成になっているか、を挙げることができる。

上述した各部は、各手段と言い換えてもよい。各部は、ハードウェア（例えば回路）、コンピュータプログラム、或いはそれらの組み合わせ（例えば、コンピュータプログラムを読み込んで実行する一又は複数のＣＰＵ）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。

本発明によれば、過去の或る時点におけるDBデータを回復しそのDBデータにアクセス可能なシステム構成を構築するDB回復処理を容易に行うことができる。

以下、本発明の一実施形態を説明する。以下の説明では、過去の或る時点におけるデータを回復することについて、該時点を「回復時点」と称し、回復の対象を「回復対象」と呼ぶことがある。回復対象がデータであれば、「回復対象データ」と呼び、回復対象がDBMSであれば、「回復対象DBMS」と呼ぶことがある。回復対象は、回復時点と現時点とでは内容が異なることがあるが（例えば、回復対象がデータであれば、回復時点から現時点にかけてデータ更新が行われることにより内容が変わることがあるが）、各時点における回復対象を区別して説明する場合には、例えば、回復時点における回復対象、現時点における回復対象、と言うことがある。

また、本実施形態において、「システム構成」とは、計算機システムに関する構成において、特に、アクセス環境に関わる構成を言う。ここで言う「アクセス環境」とは、例えば、データを使用するプログラム（例えばDBMS）がそのデータにアクセスするまでに至るデータパスを言い、具体的には、例えば、上位（アクセス元側）から下位（アクセス先側）にかけていえば、オブジェクト、ファイル、論理ボリューム、仮想ボリューム、LU、HDDのような階層となる。

また、本実施形態において、「ストレージ構成」とは、ストレージに関する構成である。ここでの「ストレージ」とは、具体的には、例えば、計算機で動作するOSに含まれるファイルシステム及びボリュームマネージャ、仮想化スイッチ、記憶装置を指す。「ストレージ構成」が意味する範囲は、前述した「システム構成」が意味する範囲に含まれるものである。

さて、まず、本実施形態の概要を説明する。本実施形態では、DBMSが稼動するホスト計算機（例えば後述のサーバ）と、DBデータを記憶する記憶装置（例えば多数の記憶媒体を備える大規模なRAID（Redundant Array of Independent (or Inexpensive) Disks）装置）と、計算機と記憶装置の間のデータ転送を制御する仮想化スイッチ、ストレージの構成を管理する管理装置（例えば後述の管理サーバ）、とを含む計算機システムが構築されている。管理装置が、ストレージの構成の変更履歴を保持する。ここで、ストレージの構成とは、例えば、ファイルシステムとボリュームマネージャ、仮想化スイッチ、記憶装置間の対応関係を示す情報である。また、管理装置は、バックアップデータとして記憶装置において取得されたスナップショットイメージ（ある時点でのデータ複製）やストレージジャーナル（例えば更新日時と更新後のデータとを含んだジャーナル）に関する情報を保持する。更に、管理装置は、DBMSの設定に関する変更履歴と、過去にDBMSが作成したログ（アーカイブログ）の保存先に関する情報を保持する。

DB回復処理を行う際、管理装置は、これらの情報を元に、利用可能な機器に応じてストレージ構成の適切な回復手段を決定し、指定された時点のデータをアクセスするためのストレージ構成を構築（例えば回復もしくは新規構築）するための指示をストレージの各要素に発行する。また、管理装置は、どのスナップショットイメージ・ストレージジャーナル・アーカイブログを利用してデータ回復を行うか決定し、それらのデータを利用したDB回復処理の実行を記憶装置やDBMSに対して指示する。

DBデータの回復方法としては、例えば以下の三種類、
(i) 指定された回復時点のストレージ構成まで完全に回復する（完全回復）、
(ii) ストレージ構成は物理的には回復時点と多少異なるが、論理的な整合性を保って回復する、
(iii) 回復時点のDBデータの複製を作成しそのDBデータに対して論理的な整合性を保ってアクセス可能とするストレージ構成を構築（回復）する（複製回復）、
が存在する。必要に応じて、これら三種類の回復方法からいずれかが選択される。

尚、本明細書において、プログラムが主語になる場合は、実際にはそのプログラムを実行するCPU等がプログラムに従って処理を実行する。また、以下の記載は、あくまで実施形態の説明であり、以下の記載と均等の構成も本発明に含まれることは言うまでも無い。

以下、本実施形態について詳細に説明する。

《計算機システム構成》。

図1は、本発明の一実施形態における計算機システムの構成例を示す図である。

計算機システムは、記憶装置40、記憶装置40を使用する計算機（以下「サーバ」）70、計算機システムの管理を行う計算機（以下「管理サーバ」）120、及び、記憶領域の仮想化処理を行う仮想化スイッチ60を有する。各々の装置は、ネットワークI/F 22を有し、それを介して、ネットワーク24に接続され相互に通信可能である。

又、サーバ70及び記憶装置40は、それぞれ、I/OパスI/F 32を有し、そこから通信線（以下I/Oパス）34を介して、仮想化スイッチ60が有するI/OパスI/F 32に接続される。ここで、I/OパスI/F 32のI/Oパス34の接続口をポート36と呼ぶ。サーバ70と記憶装置40間のI/O処理は、このI/Oパス34及び仮想化スイッチ60を介して行われる。尚、I/Oパス34としては、装置間で異なる物理媒体や異なるプロトコルでデータ転送を行う通信線が用いられてもよい。この場合、仮想化スイッチ60が各種のプロトコル変換を行ってよい。また、ネットワーク24とI/Oパス34が同一の通信線でもよい。

記憶装置40は、CPU12、メモリ14、磁気ディスク装置（以下「HDD」）16、ネットワークI/F22、及びI/OパスI/F32を有し、それらは内部バス18で接続される。なお、HDD16は単数でも複数でもよい。メモリ14は、例えば、不揮発性の領域と揮発性の領域とのうちの少なくとも一方を有する。以下の説明では、両方の種類の領域を有するものとする。そして、以下、不揮発性の領域を、ROM領域（ROM（Read Only Memory）で構成される領域）とし、揮発性の領域を、RAM領域（RAM（Random Access Memory）で構成される領域）とする。

記憶装置40を制御するプログラムである制御プログラム44は、メモリ14のROM領域に記憶され、そのプログラム４４の時にRAM領域へ移されCPU12により実行される。メモリ14の一部は、外部装置（記憶装置40の外部に存在する装置、例えばサーバ70）からのアクセス要求（例えば書込み要求或いは読出し要求）に従うデータを一時的に記憶しておくキャッシュメモリ領域（データキャッシュ42）に割り当てられる。記憶装置40は、制御プログラム44を実行することにより、後述する種々の処理を行ったり後述する種々の機能を実現したりすることができる。

記憶装置40は、HDD16が有する物理的な記憶領域を基に作成された1又は複数の論理ディスク装置（以下、Logical Unitを略して「LU」と称する）208を有し、外部装置に提供する。なお、記憶装置40は、HDD16に代えて、フラッシュメモリデバイス等の他種の記憶媒体を備えても良く、故に、LU208は、論理ディスク装置に限らず、他種の論理的な記憶媒体となっても良い。LU208は、HDD16と一対一に対応してもよいし、複数のHDD16から構成される物理的な記憶領域に対応してもよい。また、１つのHDD16が複数のLU208に対応してもよい。記憶装置40は、LU208の制御（例えば、作成、削除、或いはサイズ（記憶容量）変更）、言い換えれば、LU208とHDD16との対応関係の変更を動的に行うことができる。なお、1つのLU208を複数のポート36を経由して外部装置に提供することができ、その設定も動的に変更することができる。また、記憶装置40は、LU208のHDD16上の記憶位置を動的に変更する機能（異なるHDD16上にも移動可能）を有することができる。

記憶装置40は、ある指示された時点のLUセット（１以上のLU208）内のデータの複製を他のLUセット（１以上のLU208）に取得するスナップショット機能を有する（以下、スナップショット機能により取得された複製データ（データの複製）を「スナップショットイメージ」と呼ぶ）。また、記憶装置40は、あるLUセット（1つ以上のLU208）について、そのLUセットに対するデータの更新履歴を他のLUセット（1つ以上のLU208）に取得するストレージジャーナル機能を有する（以下、記憶装置40が取得したデータの更新履歴を「ストレージジャーナル」と呼ぶ）。また、記憶装置40は、データキャッシュ42を複数の領域に分割し、それら複数の領域をそれぞれ一つのキャッシュ領域として管理する分割キャッシュ機能を有する（以下、分割されたデータキャッシュ42のそれぞれの領域を分割キャッシュ212と呼ぶ）。どの分割キャッシュ212にデータを一時的に記憶するかは、LU208を単位として決定することができる。分割キャッシュ212に割り当てられるキャッシュメモリ量（記憶容量）は動的に変更可能である。

記憶装置40は、記憶装置40における設定変更や処理実行（例えば、LU208の制御（作成、削除、或いはサイズ変更）、LU208とポート36の対応関係、LU208のHDD16上の記憶位置、スナップショット機能、ストレージジャーナル機能、分割キャッシュ機能の設定及び／又は実行）を、外部装置からネットワーク24を介して受信した指示に従い行うことができる。

仮想化スイッチ60は、このスイッチ60に接続された記憶装置40から提供されるLU208を認識し、その記憶領域（LU208）を仮想化した仮想ボリューム206を、外部装置に提供する。なお、仮想化スイッチ60が多段で接続された場合には（外部装置と記憶装置40との間でカスケード状に複数の仮想化スイッチ60が接続された場合には）、他の仮想スイッチ60が提供する仮想ボリューム206を、記憶装置40から提供されるLU208と等価に扱い、仮想ボリューム206を外部装置に提供することができる。仮想化スイッチ60は、外部装置からネットワーク24を介して受信した指示に従い、仮想ボリューム206の制御（例えば作成や削除）を動的に行うことができる。さらに、仮想化スイッチ60は、仮想ボリューム206を構成するLU208や他の仮想ボリューム206の記憶領域との対応関係を動的に変更する機能を有してもよい。なお、この対応関係の変更としては、例えば、データのコピーを伴うものと伴わないものの二種類が存在する。また、その変更には、仮想ボリューム206又はそれを構成するLU208のサイズ（記憶容量）の変更が含まれても良い。

サーバ70は、CPU12、メモリ14、HDD16、ネットワークI/F22及びI/OパスI/F32を有し、それらは内部バス18で接続される。メモリ14上には、例えば、オペレーティングシステム（OS）72と管理エージェント160がHDD16から読み込まれる。読み込まれたOS72等は、CPU12により実行される。

OS72は、プログラム実行制御やハードウェア制御等、基本的な処理を行うために計算機が実行するプログラム群であり、例えば、ボリュームマネージャ78及びファイルシステム80を含む。なお、本図１では、サーバ70は、1つのファイルシステム80しか有していないが、複数のファイルシステム80を有してもよい。

ボリュームマネージャ78は、仮想化ボリューム206の記憶領域から論理ボリューム204を作成しその論理ボリューム204をファイルシステム80に提供する機能を有するプログラムである。尚、ボリュームマネージャ78は、論理ボリューム204の制御（例えば、作成或いは削除）を動的に行ってもよい。更に、ボリュームマネージャ78は、論理ボリューム204を構成する仮想ボリューム206の記憶領域との対応関係を動的に変更する機能を有してもよい。この対応関係の変更は、例えば、データのコピーを伴うものと伴わないものの二種類が存在する。その変更には、論理ボリューム204又はそれを構成する仮想ボリューム206のサイズ変更が含まれても良い。ボリュームマネージャ78は、このマネージャ78が有するソフトウェアインタフェースを通じて行われる外部からの指示に従って、上述した処理を実行することができる。

ファイルシステム80は、論理ボリューム204の記憶領域からファイル202を作成しファイル202を他のプログラムに提供する機能を有するプログラムである。尚、以下の説明では、ファイル202へのアクセスと同じソフトウェアインタフェースで、ファイルシステム80により、ローデバイス機能（論理ボリューム204、仮想化ボリューム206及びLU208のうちの少なくとも一つにおける記憶領域へ直接アクセスする機能）が実現されるものとする。また、論理ボリューム204の記憶領域を複数の領域に分割して利用する機能は、ファイルシステム80により実現されるものとする（論理ボリューム204の分割された記憶領域を「パーティション」と呼ぶ）。

管理エージェント160は、管理プログラム140からネットワーク24を介して送られる、ボリュームマネージャ78、ファイルシステム80或いはDBMS90に対する指示を中継する際に実行されるプログラムである。管理エージェント160は、必要に応じて、ボリュームマネージャ78、ファイルシステム80、或いはDBMS90が発信するもしくは内部に管理する各種情報を取得し、取得した各種情報を、ネットワーク24を介して管理プログラム140に送信することができる。また、DB回復処理中に実施するDBMS設定情報修正処理（DBMS90に設定されている情報を修正する処理）、領域確保処理及び初期化処理が実行されるためには、管理エージェント160が指示の中継（必要に応じて、コマンドの実行）を行うことが必要となる。

DBMS90は、サーバ70が、DBに関する処理（管理を含む）を実行する際に実行されるプログラムである。本プログラムは、記憶装置40からメモリ14に読み出されてCPU12により実行される。本実施形態においては、DBMS90の実行プログラムファイルやDBの設定情報を記した設定ファイルは、ファイルシステム80により提供される特定のディレクトリ（以下「DBMSシステムディレクトリ」）下に事前に定められた形式で記憶され、そのディレクトリへのパス名はDBMS90の実行プログラムを実行する際に環境変数により指定される。DBMSシステムディレクトリは複数存在してもよい。また、DBMS90の識別子や必要に応じてネットワーク設定も同時に環境変数により指定されてよい。DBMS90は、1台のサーバ70上で複数同時に実行することもできる。また、複数台のサーバ70で動作する複数のDBMS90が協調し、「クラスタ構成」として論理的に1つのDBMSとして動作してもよい。この場合、クラスタ構成に関する管理情報であるクラスタ構成情報をDBMSシステムディレクトリ下に保持することができる。また、DBMS90間で共有するDBMSシステムディレクトリが存在してもよい。

DBMS90は、各種機能の設定を受け付けるソフトウェアインタフェースを有する。DBMS90は、DBデータの更新履歴をログとしてDBデータとは独立した領域に記憶する。古くなったログはDBMS90が直接利用することはなく、バックアップされたDBデータ（以下、バックアップDBデータ）を基に或る時点のDBデータを復元することに利用される。そのようなログを、本実施形態において「アーカイブログ」と呼ぶ。アーカイブログは、DBMS90の管理対象外として、ログとは異なる領域に記憶される。ログをアーカイブログにする処理は、管理者の指示によりDBMS90を含む任意のプログラムが行ってもよいし、DBMS90が自動的に行ってもよい。

DBMS90は、DBMS90自身が管理し利用するDBデータである表・索引・ログ等（以下、それらを「オブジェクト」と総称することがある）を記憶装置40に記憶する。DBMS90は、ファイルシステム80が提供するファイル202をグループ化した「テーブルスペース」を作成し、自身が使用する記憶領域を管理する。テーブルスペースには、1つ以上のオブジェクト222が割り当てられる。

OS72、DBMS90及び管理エージェント160は、これらのプログラムを格納したCD-ROM（可搬記憶媒体）から管理サーバ120が有するCD-ROMドライブ20を用いて読み出され、ネットワーク24を介してサーバ70内のHDD16もしくは記憶装置40にインストールされる。他の方法（例えば、インターネットを介してダウンロードすること）によりインストールされても良い。これは、管理サーバ120など、他の装置についても同様である。

管理サーバ120は、CPU12、メモリ14、HDD16、CD-ROMドライブ20、ネットワークI/F 22を有し、それらは内部バス18で相互に接続される。メモリ14上には、OS72と管理プログラム140がHDD16から読み込まれ、CPU12により実行される。CD-ROMドライブ20は、各種プログラムのインストールに用いられる。

管理サーバ120には、キーボード・マウス等の入力装置112および表示画面114を有する管理端末110が、ネットワーク24を介して接続される。管理サーバ120と管理端末110は、ネットワーク24とは異なる通信線を用いて接続されていてもよく、管理サーバ120と管理端末110が一体で構成されてもよい。管理者は、原則、情報や制御指示の入出力を、管理端末110を介して行い、必要に応じて、CD-ROMドライブ20等も用いることができる。

管理プログラム140は、管理サーバ120により、DB回復処理の指示等を行う際に実行されるプログラムである。管理プログラム140は、必要に応じて、記憶装置40、仮想化スイッチ60、ボリュームマネージャ78、ファイルシステム80、DBMS90に対して処理の指示を行う。このとき、記憶装置40及び仮想化スイッチ60に対しては、ネットワーク24を介して指示が送信され、ボリュームマネージャ78、ファイルシステム80及びDBMS90に対しては、ネットワーク24と管理エージェント160を介して指示が送信される。

管理プログラム140は、構成履歴情報142（記憶装置40、仮想化スイッチ60、ボリュームマネージャ78、ファイルシステム80及びDBMS90のそれぞれの構成に関する履歴情報）、バックアップデータ情報144（記憶装置40におけるスナップショットイメージやストレージジャーナルの取得状況とDBMS90におけるアーカイブログの取得状況に関する情報）、及び、空きリソース情報146（記憶装置40において新規にデータを記憶可能なHDD16内の記憶領域や新規にDBMS90を実行可能なサーバ70に関する情報）を保持する。管理プログラム140は、必要に応じて、構成履歴情報142、バックアップデータ情報144、空きリソース情報146を管理サーバ120内のHDD16や記憶装置40内に保存することができる。

管理プログラム140の動作の詳細は後述する。管理プログラム140は、CD-ROMから管理サーバ120が有するCD-ROMドライブ20を用いて読み出され、HDD16にインストールされる。

以上が、計算機システムの構成についての説明である。なお、上記構成は一例であり、上記構成に限定される必要は無い。

《データマッピングの階層構成》。

図２は、DBMS90が管理するDBデータのデータマッピング階層構成を例示する図である。

サーバ70と記憶装置40との間に一つの仮想化スイッチ60が存在する場合を例に採り説明する。以下、ある二つの階層について、DBMS90に近い方（アプリケーション側）を「上位」の階層と称し、HDD16に近い方（物理的記憶領域側）を「下位」の階層と称する。ファイル202、論理ボリューム204、仮想ボリューム206及びLU208をまとめて「仮想構造」と称し、仮想構造にHDD16を加えたものをまとめて「管理構造」と称することがある。すなわち、本実施形態の説明で言う「管理構造」には、「仮想構造」が含まれていることになる。

図2で示した例では、DBMS90は、それが管理しているオブジェクト222を記憶しているファイル202（ファイルシステム80が提供するファイル202）に対してアクセスをおこなう。ファイルシステム80は、ファイル202に対するアクセスを、そのファイル202に対応する領域（論理ボリューム204の領域）へのアクセスに変換する。ボリュームマネージャ78は、論理ボリューム204の領域に対するアクセスを、その領域に対応する、仮想ボリューム206の領域へのアクセスに変換する。仮想化スイッチ60は、仮想ボリューム206の領域に対するアクセスを、その領域に対応する、LU208の領域へのアクセスに変換する。記憶装置40は、LU208の領域に対するアクセスを、その領域に対応する、HDD16の領域に対するアクセスに変換する。すなわち、このデータマッピング階層構成によれば、上位階層に提供されるデータ（仮想構造におけるデータ）を下位階層に存在する一つ以上の記憶領域（管理構造における記憶領域）にマッピングされる。また、記憶装置40の中では、LU208毎に、対応する分割キャッシュ212が定まる。

また、図示しないが、ある仮想構造におけるデータの同一部分が、その同一部分よりも下位階層における記憶領域（例えばHDD16における領域）にマッピングされてもよい。また、ある仮想構造のデータがHDD16の領域にマッピングされる経路が複数本存在してもよい。

本実施形態では、論理層214における管理構造間のデータの対応関係が明確化されればよく、サーバ70でボリュームマネージャ78が使用されなくてもよい（仮想ボリューム206に1対1に固定化された論理ボリューム204が存在してもよい）。仮想化スイッチ60は、複数段存在してもよい。仮想化スイッチ60に相当するスイッチが記憶領域の仮想化機能を有さなくともよく、この場合、仮想化スイッチ60が下位階層から提供された記憶領域をそのまま上位層へ提供しているとみなして扱えばよい。仮想化スイッチ60が存在せずにサーバ70と記憶装置40がI/Oパス34により直結されてもよく、この場合、I/Oパス34には、対応するサーバ70と記憶装置40のみに接続された（仮想化機能を有しない）スイッチを有するとみなして扱えばよい。

《データ構造》。

図3は、構成履歴情報142のデータ構造例を示す模式図である。

構成履歴情報142は、管理プログラム140が保持し管理するデータであり、以下のデータを含む。

一つ目のデータは、DBMS90に関する設定変更の履歴情報であり、設定が変更された日時である設定日時302を保持するエントリと、構成が変更されたDBMS90が動作するサーバの識別子であるサーバID304を保持するエントリ、そのDBMS90の識別子であるDBMS ID306を保持するエントリ、構成が変更された後のDBMS90のDBMS設定情報400（後述）を含むエントリ、の組を含む。なお、DBMS90が削除された場合には、DBMS設定情報400を含むエントリには、その旨を示す無効値が記憶される。なお、DBMSがクラスタ構成となっている場合、DBMS ID306が同一の値をもちサーバID304が異なる組が存在する。

二つ目のデータは、サーバ70上で動作するOS72に関する構成設定変更の履歴情報であり、構成が変更された日時である設定日時302を保持するエントリと、構成が変更されたOS72が動作するサーバ70のサーバID304を保持するエントリ、構成が変更された後のOS72に関するOS設定情報440（後述）を含むエントリ、の組を含む。なお、サーバ70が削除された場合には、OS設定情報440を含むエントリには、その旨を示す無効値が記憶される。

三つ目のデータは、仮想化スイッチ60に関する構成設定変更の履歴情報であり、構成が変更された日時である設定日時302を保持するエントリと、構成が変更された仮想化スイッチ60の識別子であるスイッチID308を保持するエントリ、設定が変更された後の仮想化スイッチ60に関するスイッチ設定情報500（後述）を含むエントリ、の組を含む。なお、仮想化スイッチ60が削除された場合には、スイッチ設定情報500を含むエントリには、その旨を示す無効値が記憶される。

四つ目のデータは、記憶装置40に関する構成設定変更の履歴情報であり、構成が変更された日時である設定日時302を保持するエントリと、構成が変更された記憶装置40の識別子である記憶装置ID310を保持するエントリ、構成が変更された後の記憶装置40に関する記憶装置設定情報550（後述）を含むエントリ、の組を含む。なお、記憶装置40が削除された場合には、記憶装置設定情報550を含むエントリには、その旨を示す無効値が記憶される。

図4は、DBMS設定情報400のデータ構造例を示す模式図である。

DBMS設定情報400は、構成履歴情報142に含まれる、DBMS90のある時点での構成設定に関する情報であり、以下のデータを含む。

まず、DBMS90の識別子であるDBMS ID306を保持するエントリ、DBMS90のDBMSシステムディレクトリのパス名であるシステムディレクトリパス404を保持するエントリ、DBMS90を実行する際に設定される環境変数406を保持するエントリを含む。環境変数406の中には、DBMS90の識別子を設定する環境変数等が含まれる。システムディレクトリパス404には、複数のDBMSシステムディレクトリへの情報が含まれてもよい。

また、オブジェクト222の識別子であるオブジェクト名414を保持するエントリ、それが記憶されるテーブルスペースの識別子であるテーブルスペース名412を保持するエントリ、の組が含まれる。更に、デーブルスペース名412を含むエントリ、そのテーブルスペースに対応するファイル202のパス名であるデータファイルパス名422を保持するエントリ、データファイルパス名422で示されるものがシンボリックリンクであった場合に、そのシンボリックリンクを解析することにより得られるファイルパス名である実体ファイルパス名424を保持するエントリ、ファイルタイプ426を保持するエントリ、が含まれる。データファイルパス名422で示されるものがシンボリックリンクでない場合には実体ファイルパス名424を保持するエントリにはデータファイルパス名422と同じ値が保持される。また、ファイルタイプ426はファイルの種別を示すものであり、その値として、通常のファイルの場合は「File」、ローデバイス機能によるものである場合は「Raw」が保持される。

図5は、OS設定情報440のデータ構造例を示す模式図である。

OS設定情報440は、構成履歴情報142に含まれる、OS72のある時点での構成設定に関する情報であり、以下のデータを含む。

まず、論理ボリューム204の識別子である論理ボリュームID452を保持するエントリ、その論理ボリューム204を分割したパーティションの識別子であるパーティションID454を保持するエントリ、そのパーティションに対応する論理ボリューム204内の記憶領域を示すブロック番号456を保持するエントリ、ファイルシステム80が対応するパーティションに構築したファイルシステムのマウントポイント458を保持するエントリ、そのパーティションのローデバイス機構におけるローデバイスパス名460を保持するエントリ、の組が含まれる。パーティションにファイルシステムが構築されていない場合には、マウントポイント458は無効値を取る。また、パーティションにローデバイス機構が利用されない場合には、ローデバイスパス名460は無効値を取る。

また、論理ボリュームID452を保持するエントリ、その論理ボリューム204の記憶領域を示す上位ブロック番号462を保持するエントリ、その記憶領域に対応する仮想ボリューム206を提供する仮想化スイッチ60の識別子であるスイッチID464を保持するエントリとその仮想ボリューム206の識別子である下位ボリュームID466を保持するエントリ、対応する仮想ボリューム206内の記憶領域を示す下位ブロック番号468を保持するエントリ、の組が含まれる。

更に、サーバ70に含まれるI/OパスI/F32が有するポート36のそれぞれについて、ポート36の識別子である受信ポートID472を保持するエントリ、そのポート36がI/Oパス34により接続されている仮想化スイッチ60のスイッチID464を保持するエントリ、そのポート36を介してI/O処理を実施する仮想化ボリューム206が存在する場合には、その仮想ボリューム206を示す下位ボリュームID466を保持するエントリ、の組が保持される。そのポート36を介して仮想化スイッチ60とI/O処理を実施しない場合には、下位ボリュームID466を保持するエントリは無効値を取る。

図6は、スイッチ設定情報500のデータ構造例を示す模式図である。

スイッチ設定情報500は、構成履歴情報142に含まれる、仮想化スイッチ60のある時点での構成設定に関する情報であり、以下のデータを含む。

まず、仮想化スイッチ60が提供する仮想ボリューム206の識別子である仮想ボリュームID502を保持するエントリ、その仮想ボリューム206の記憶領域を示す上位ブロック番号504を保持するエントリ、その記憶領域に対応するLU208（もしくは仮想ボリューム206）を提供する記憶装置40（もしくは仮想化スイッチ60）の識別子である下位装置ID506を保持するエントリとそのLU208（もしくは仮想ボリューム206）の識別子である下位ボリュームID508を保持するエントリ、対応するLU208(もしくは仮想ボリューム206)内の記憶領域を示す下位ブロック番号510を保持するエントリ、の組が含まれる。

また、仮想化スイッチ60が含むI/OパスI/F32が有するポート36について、以下の情報が含まれる。すなわち、仮想ボリューム206の提供先となり得る装置（サーバ70もしくは仮想化スイッチ60）との接続関係として、その装置と接続されたI/Oパス34に対応するポート36の識別子である送信ポートID512を保持するエントリ、そのポート36がI/Oパス34により接続されている装置の識別子である上位装置ID514を保持するエントリ、そのポート36を介して提供される仮想化ボリューム206を示す仮想ボリュームID502を保持するエントリ、の組が含まれる。そのポート36を介して仮想ボリューム206が提供されない場合、仮想ボリュームID502を保持するエントリは無効値を取る。

更に、仮想ボリューム206を構成するのに利用されるLU208もしくは仮想ボリューム206の取得元となり得る装置（記憶装置40もしくは仮想化スイッチ60）との接続関係として、その装置と接続されたI/Oパス34に対応するポート36の識別子である受信ポートID516を保持するエントリ、そのポート36がI/Oパス34により接続されている装置の識別子である下位装置ID506を保持するエントリ、そのポート36を介して取得するLU208もしくは仮想ボリューム206を示す下位ボリュームID508を保持するエントリ、の組が保持される。そのポート36を介してLU208もしくは仮想ボリューム206を取得しない場合、下位ボリュームID508を保持するエントリは無効値を取る。

図7は、記憶装置設定情報550のデータ構造例を示す模式図である。

記憶装置設定情報550は、構成履歴情報142に含まれる、記憶装置40のある時点での構成設定に関する情報であり、以下のデータを含む。

まず、記憶装置40が提供するLU208の識別子であるLU ID552を保持するエントリ、LU208の記憶領域を示す上位ブロック番号554を保持するエントリ、その記憶領域に対応するHDD16の識別子であるHDD ID556を保持するエントリとHDD16内の対応する記憶領域を示す下位ブロック番号558を保持するエントリ、の組が含まれる。

また、記憶装置40が保持するI/OパスI/F32が有するポート36のそれぞれについて、ポート36の識別子である送信ポートID562を保持するエントリ、そのポート36がI/Oパス34により接続されている仮想化スイッチ60の識別子であるスイッチID564を保持するエントリ、そのポート36を介して提供されるLU208を示すLU ID552を保持するエントリ、の組が保持される。そのポート36を介してLU208が提供されない場合、LU ID552を保持するエントリは無効値を取る。

さらに、分割キャッシュ212の設定として、分割キャッシュ212の識別子である分割キャッシュID572を保持するエントリ、その分割キャッシュ212に対応するLU208の識別子を保持するメンバLU ID574を保持するエントリ、分割キャッシュ212に割り当てられたキャッシュメモリ量576を保持するエントリ、の組が含まれる。なお、分割キャッシュID572の値が「Default」の分割キャッシュ212（以下「デフォルト分割キャッシュ」）は、LU208が特定の分割キャッシュ212に割り当てることが指示されていない場合に初期値として割り当てられるものである。

図8は、バックアップデータ情報144のデータ構造例を示す模式図である。

バックアップデータ情報144は、管理プログラム140が保持し管理するデータであり、現時点におけるスナップショットイメージ、ストレージジャーナル、アーカイブログに関する情報を含む。

スナップショットイメージに関する情報として、スナップショットイメージを取得した記憶装置40を示す記憶装置ID612を保持するエントリ、スナップショットイメージの取得対象となるLUセット（１以上のLU208）を示すベースLU ID614を保持するエントリ、スナップショットイメージの取得先となるLUセット（１以上のLU208）を示すスナップショットLU ID616を保持するエントリ、スナップショットイメージの取得時刻618を保持するエントリ、の組が保持される。

ストレージジャーナルに関する情報として、データの更新履歴を取得する記憶装置を示す記録装置ID662を保持するエントリと、更新履歴の取得対象となるLUセット（１以上のLU208）を示す取得対象LU ID624を保持するエントリ、取得した更新履歴を記憶するLUセット（１以上のLU208）を示すジャーナルLU ID626を保持するエントリ、更新履歴の取得期間を示すジャーナル取得期間628を保持するエントリ、の組が保持される。ジャーナル取得期間628については、開始時刻と終了時刻を保持し、現在も更新履歴を取得中の場合には終了時刻に関しては無効値を保持する。

アーカイブログに関する情報として、アーカイブログを生成したDBMS90を示すDBMS ID642を保持するエントリ、そのログが生成された期間（時間や処理順序番号、等）を示すログ期間644を保持するエントリ、アーカイブ先646を保持するエントリ、の組が保持される。アーカイブ先646は、アーカイブログが記憶されている領域に関する情報である。本実施形態では、あるDBMS90においてログ期間644に対応するアーカイブログは１つのLU208内に記憶されるとして説明する。この場合、アーカイブ先646には、アーカイブログが記憶されるLU208とそれを提供する記憶装置40とのそれぞれの識別子、及び、LU208内の記憶先に関する情報が保持される。この記憶先としては、ファイル202として記憶される場合には、例えば、そのファイル202の（LU208上に作成されたファイルシステムにおける）パーティションとファイルパス名、ローデバイス機能を利用して記憶する場合には記憶先のブロック番号が保持される。なお、アーカイブログを複数のLU208に分割して記憶してもよく、その場合には、アーカイブ先646に複数のLU208によるアーカイブログ記憶領域の構成情報が含まれて良い。

図9は、空きリソース情報146のデータ構造例を示す模式図である。

空きリソース情報146は、管理プログラム140が保持し管理するデータであり、現時点における記憶装置40内のHDD16における未割り当て記憶領域（データマッピング階層構造において未だどれにも割り当てられていない記憶領域）に関する情報と、DBMS90を追加して稼動することができるサーバ70に関する情報とを含む。

記憶装置40内のHDD16における未割り当て記憶領域に関する情報として、記憶装置40を示す記憶装置ID662を保持するエントリ、HDD16を示すHDD ID664を保持するエントリ、そのHDD16内で未割り当ての領域を示す空きブロック番号666を保持するエントリ、の組が保持される。

DBMS90を追加して稼動することができるサーバ70に関する情報として、そのようなサーバ70を示す空きサーバID672を含むエントリ、そのサーバにおける新規に利用可能なCPU数やメモリ量（記憶容量）に関する情報を保持する空きリソース674を含むエントリ、の組が含まれる。

《ストレージ構成の変更方法》。

本実施形態においては、ストレージ構成（論理ボリューム204から記憶装置40内のHDD16における記憶領域までの対応関係）が動的に変更される。ここで、ストレージ構成の変更方法について、幾つかの例を用いて説明する。

図10は、ストレージ構成の変更方法の第一の例を示す図である。

この例では、記憶装置40内において、回復時点の記憶位置（HDD16上の記憶位置）に戻したいLU208a（以下、回復対象LU208a）があり、回復時点におけるその記憶位置（HDD16上の記憶位置）に、他のLU208b（以下、競合LU208ｂ）内のデータが記憶されている場合に、回復時点の記憶位置（以下、回復位置）を空き領域としその記憶位置に回復対象LU208aを回復する処理を説明する。

処理開始時点では、回復対象LU208aのデータは、HDD16上の領域812aに記憶されている。回復位置は領域812bであるが、現時点では、競合LU208bのデータが記憶されている（LU208bは、現時点で回復位置に存在し邪魔になっているので、その意味で、「競合LU」と呼んでいる）。また、空き領域として領域812cが存在し、そこに新たにデータを記憶することができる状態にある。

まず、回復領域812bに回復対象LU208aのデータを記憶できるよう回復領域812bを開放するため、記憶装置40に対して、例えば管理プログラム140が、競合LU208bのデータの記憶位置を領域812cに変更するよう指示する。これにより、記憶装置４０の制御プログラム44が、回復領域812b内のデータを領域812cに移し、それ故、回復領域812bが空き領域となる。

その後、例えば管理プログラム140が、回復対象LU208aのデータの記憶位置を回復領域812bに変更するよう記憶装置40に指示する。制御プログラム44が、回復対象LU208aのデータを回復位置812bに移す。なお、本処理により、領域812 aが空き領域となる。

図11は、ストレージ構成の変更方法の第二の例を示す図である。

この例では、処理対象の論理ボリューム204fのデータが記憶されるLU208fに変更は無いが、仮想化スイッチ60ｆを経由していたものを仮想化スイッチ60gを経由して（つまり、異なるI/Oパス34を経由して）I/O処理が行われるようにストレージ構成を変更する処理を説明する。

まず、記憶装置40に対し、例えば管理プログラム140が、LU208fが仮想化スイッチ60gからアクセス可能になるようにLU208ｆとポート36の対応関係を変更するよう指示する。その後、例えば管理プログラム140が、LU208fを用いて仮想化スイッチ60fが提供し、ボリュームマネージャ78ｆが、論理ボリューム（VOL）204fの構成要素としている移動元仮想ボリューム（VVOL）206fと同じ構成の移動先仮想ボリューム206gを作成するよう仮想化スイッチ60gに指示する。続いて、例えば管理プログラム140が、ボリュームマネージャ78fが動作するサーバ70に対して移動先仮想ボリューム206gを提供するように仮想化スイッチ60gに指示する。続いて、例えば管理プログラム140が、論理ボリューム204fを移動元仮想ボリューム206fではなく移動先仮想ボリューム206gから構成するようにボリュームマネージャ78ｆに指示する。この変更指示は、データコピーを伴わない構成変更指示である。最後に、必要に応じて、例えば管理プログラム140が、移動元仮想ボリューム206fの削除を仮想化スイッチ60fに指示し、その後、仮想化スイッチ60fがLU208fをアクセスできなくなるよう、LU208ｆとポート36の対応関係を変更するように記憶装置40に指示する。

本例で示した処理手順は、論理ボリューム204ｆの一部記憶領域が移動元仮想ボリューム206fに対応する、もしくは、全記憶領域が移動元仮想ボリューム206fに対応する、いずれの場合にも適用できる。なお、論理ボリューム204fが複数の仮想ボリューム206から構成される場合、変更対象の全ての仮想ボリューム206に対して本処理をそれぞれ独立に実施する。

図12は、ストレージ構成の変更方法の第三の例を示す図である。

この例では、ボリュームマネージャ78dにおいて、論理ボリューム204dのデータ記憶位置を、記憶装置40dが提供する移動元LU208dから記憶装置40eが提供する移動先LU208eにコピーすることにより変更する処理を説明する。同様に、仮想化スイッチ60おいて移動先LUを用いてコピーを伴う構成変更を実施可能である。

まず、移動先LU208eが存在しない場合、例えば管理プログラム140が、移動元LU208dと同容量で移動先LU208eを作成するよう記憶装置40eに指示する。その後、例えば管理プログラム140が、移動先LU208eが仮想化スイッチ60eからアクセス可能になるよう、LU208eとポート36の対応関係を変更するように記憶装置40eに指示する。続いて、例えば管理プログラム140が、移動元LU208dを用いて仮想化スイッチ60dが提供し、ボリュームマネージャ78dが論理ボリューム204dの構成要素としている移動元仮想ボリューム206dと同じ構成の移動先仮想ボリューム206eを移動先LU208eを用いて作成するよう仮想化スイッチ60eに指示する。その後、例えば管理プログラム140が、移動先仮想ボリューム206eをボリュームマネージャ78dが動作するサーバ70に対して提供するよう仮想化スイッチ60eに指示する。そして、論理ボリューム204dのデータ記憶領域を移動元仮想ボリューム206dから移動先仮想ボリューム206eにデータコピーを伴う方法で変更するよう、例えば管理プログラム140がボリュームマネージャ78dに指示する。最後に、必要に応じて、例えば管理プログラム140が、移動元仮想ボリューム206dの削除を仮想化スイッチ60dに指示し、その後、LU208dを削除するように記憶装置40dに指示する。

上記の手順は、移動元仮想ボリューム206dと移動元LU208dが一対一の関係にあることを前提としている。移動元仮想ボリューム206dが複数のLU208に対応する場合、移動先仮想ボリューム206eに関しては容量が移動元仮想ボリューム206dと同じになればよく、移動先仮想ボリューム206eを構成するLU208の数は移動元仮想ボリューム206dと異なってもよい。

また、論理ボリューム204dの一部記憶領域が移動元仮想ボリューム206dに対応する、もしくは、全記憶領域が移動元仮想ボリューム206dに対応する、いずれの場合にも適用される。なお、論理ボリューム204dが複数の仮想ボリューム206から構成される場合には、変更したい全ての仮想ボリューム206に対して本処理をそれぞれ独立に実施する。

さて、以下、本実施形態で行われる種々の処理について説明する。

《情報収集処理》。

管理プログラム140は、構成履歴情報142、バックアップデータ情報144、空きリソース情報146を保持する。本実施形態では、管理プログラム140は、これらの情報を以下のようにして最新の状態にすることができる。

まず、ストレージ構成の変更、つまり、記憶装置40、仮想化スイッチ60、ボリュームマネージャ78の構成設定や、DBMS90の設定を変更する場合、管理プログラム140が、構成設定の変更要求を管理者等から取得し、構成設定対象に構成設定の変更を指示した後、構成履歴情報142中の関連部分に新しい設定を記憶する。このとき、記憶装置40に対してLU208の作成或いは削除を指示した場合には、空きリソース情報146中の記憶装置40内のHDD16の空き領域に関する情報を同時に更新する。

DBMS90やサーバ70の追加・削除の場合も、管理プログラム140が、それらの処理の実施要求を管理者等から取得し、その処理を実行した後、空きリソース情報146中の空きサーバに関する情報を更新する。

記憶装置40においてLU208のスナップショットイメージを取得・削除する場合や、LU208に更新履歴の取得を設定・解除する、また、取得したストレージジャーナルを削除する場合、管理者等からその指示を管理プログラム140が取得し、記憶装置40に指示した後にバックアップデータ情報144中の関連部分を更新する。

また、DBMS90に対してログをアーカイブログ化する処理を指示する場合、管理プログラム140が、管理者等からその指示を取得し、DBMS90に指示した後にバックアップデータ情報144中の関連部分を更新する。また、DBMS90が自発的にログをアーカイブ化する場合、管理プログラム140が、その旨をDBMS90から取得し、バックアップデータ情報144中の関連部分を更新する。

後述するDB回復処理を実施する場合、ストレージ構成やDBMS90の設定、DBMS90のサーバ構成を変更（追加・削除含む）した場合、その変更も反映する。なお、「サーバ構成」とは、サーバに関する構成であり、具体的には、例えば、計算機システムにおけるサーバの台数、一つのサーバにおける構成（例えばOSやDBMSの種類など）である。

上記の方法では、指示対象に管理プログラム140経由で指示を送る。この方法の代わりに、記憶装置40、仮想化スイッチ60、ボリュームマネージャ78、DBMS90に前記処理の実施を管理プログラム140に報告させる、もしくは、管理プログラム140が定期的にそれらの処理が実施されたかを確認し、実施された場合に対応する情報を更新する方法を利用しても良い。なお、この処理は、ボリュームマネージャ78、DBMS90に関しては管理エージェント160経由で実施してもよい。

《DB回復処理》。

図13に、管理プログラム140により行われるDB回復処理のメイン処理の処理フロー例のフローチャートを示す。

管理プログラム140が、管理者からのDB回復処理の開始指示を受け付けることにより本処理を開始する。ここでは、管理者は、管理端末110から処理の開始を指示するものとして説明する（ステップ1201）。

管理プログラム140は、管理端末110を介して、回復対象となるDBデータを管理するDBMS90の識別子とDBデータの回復時点とを管理者から取得する。なお、回復対象のDBMS90がクラスタ構成の場合、1つの識別子の値に複数のサーバ70で動作する複数のDBMS90が対応することになる（ステップ1202）。

管理プログラム140は、図14により説明する回復方法の設定処理を実行する。この処理に成功した場合はステップ1204に進み、失敗した場合はステップ1241に進み、本処理を異常終了する（ステップ1203）。

管理プログラム140は、管理者からプロテクトリソースの指示を受ける。ここでプロテクトリソースとは、本処理により構成変更をしてはならない部分であり、DBMS90、仮想スイッチ60、記憶装置40、I/Oパス34、論理ボリューム204、仮想ボリューム206、LU208、記憶装置40内のHDD16、分割キャッシュ212、等を指定する（ステップ1204）。

ステップ1203で設定された回復方法が完全回復であるか確認する。「Yes」である場合にはステップ1206に進み、「No」である場合にはステップ1222に進む（ステップ1205）。

管理プログラム140は、ステップ1203の処理で決定した「回復対象データ」に関し、現時点と回復時点のストレージ構成に差が存在するか確認する。この比較は、構成履歴情報142を参照することにより行う。現時点の構成は、各要素の最新の構成として把握できる。回復時点の構成は、設定日時302を保持するエントリを参照し、回復時点以前の条件で最新のものが回復時点の構成情報となる。回復対象データに対応する論理ボリューム204、仮想ボリューム206、LU208、HDD16は、構成履歴情報142内に記憶された対応情報（図２を参照して説明した対応関係（記憶領域の対応関係）を表す情報）を参照することにより把握することができる。

DBMS設定情報400とOS設定情報440について、構成履歴情報142でサーバID304の値が同じもので、上述の方法で同じ日時のデータとされるものが対応する。DBMS設定情報400中でファイルタイプ426の値が「File」の場合には、管理プログラム140は、OS設定情報440中のマウントポイント458からファイルシステム80のマウント状態を把握し、実体ファイルパス名424から対応関係を把握する。ファイルタイプ426の値が「Raw」の場合は、管理プログラム140は、その実体ファイルパス名424とOS設定情報440中のローデバイスパス名460から対応関係を把握する。また、回復対象データがDBMSシステムディレクトリの場合は、管理プログラム140は、ファイルタイプ426が「File」の値を持ち、システムディレクトリパス404の値が実体ファイルパス名424の値と見なして扱う。

現時点と回復時点のストレージ構成に差が存在する場合にはステップ1207に進み、存在しない場合にはステップ1208に進む（ステップ1206）。

管理プログラム140は、図16により説明する完全回復手順を決定する処理を実施する。完全回復手順の決定に成功した場合にはステップ1209に進み、失敗した場合にはステップ1221に進む（ステップ1207）。

管理プログラム140は、図18により説明する、競合が発生するか確認し、発生した場合にはそれを回避する手順を設定する処理を実施する。本処理に成功した場合はステップ1210に進み、失敗した場合にはステップ1221に進む（ステップ1209）。

管理プログラム140は、回復対象として指定されたDBMS90に処理の停止を指示する（ステップ1210）。

管理プログラム140は、ステップ1206と同様な方法で、構成履歴情報142から回復対象データに対応するファイル202のうちファイルタイプ426の値が「File」であるものを管理するファイルシステムを把握し、それらをアンマウントするようファイルシステム80に指示する（ステップ1211）。

管理プログラム140は、ステップ1207、1209で作成した完全回復手順、競合回避手順に従い、対応する記憶装置40、仮想化スイッチ60、ボリュームマネージャ78に対して設定変更を指示する。指示の発行順序は、例えば、完全回復手順、競合回避手順として設定された順序に従う（ステップ1212）。

管理プログラム140は、図15により説明する処理（ステップ1203中に実施される）により決定された方法に従い、対応する記憶装置40にデータのリストアを指示する（ステップ1213）。

管理プログラム140は、ステップ1207で作成した完全回復手順に従い、対応するファイルシステム80に対して設定変更を指示する。その後、ステップ1206と同様な方法で、構成履歴情報142から回復対象データに対応するファイル202のうちファイルタイプ426の値が「File」であるものを管理するファイルシステムを把握し、それらをマウントするようファイルシステム80に指示する。管理プログラム140は、回復対象のDBMS90の回復時点のDBMS設定情報400中のデータファイルパス名422と実体ファイルパス名424のそれぞれの値を確認する。異なる場合には、データファイルパス名422で示されるファイルエントリを実体ファイルパス名424へのシンボリックリンクと設定するようファイルシステム80に指示する（ステップ1214）。

管理プログラム140は、ステップ1207中で回復時点とサーバ構成が異なる回復処理の実施を決定した場合、ステップ1405で決定された、復元されたDBMSシステムディレクトリ下に記憶されるDBMSの設定情報やクラスタ構成情報の修正を、回復対象のDBMS90が動作するサーバ70上で実行中の管理エージェント160に指示する。また、ログの記憶領域の作成・初期化等が必要であれば、その実行を管理エージェント160に指示する。また、回復後のサーバ70の利用状況にあわせて空きリソース情報146中の空きサーバID672、空きリソース674を更新する（ステップ1215）。

管理プログラム140は、図15により説明する処理でアーカイブログを利用したDB回復を実施すると決定された場合、アーカイブログを用いたRedo・Undo処理の実施をDBMS90に指示する。このとき、回復後の処理再開時に利用する環境変数を設定する。DBMS90がクラスタ構成の場合、異なるサーバ70で実行されたDBMS90により作成・アーカイブログ化されたログを用いてRedo・Undo処理を実施してもよい。また、必要であれば、Redo・Undo処理中に、Redo・Undo処理中のDBMS90からの要求を取得し、DBMS90のサーバ構成の変更やストレージ構成の変更を実施してもよい。

アーカイブログの記憶先は、バックアップデータ情報144から把握することができる。この時点で、対象DBMS90が回復処理に利用するアーカイブログに対するアクセスパスが設定されていない場合、管理プログラム140は、そのアクセスパスを設定する。つまり、管理プログラム140は、アーカイブログが記憶されているLU208の仮想化スイッチ60への提供を記憶装置40へ指示する。また、管理プログラム140は、アーカイブログが記憶されているLU208を構成要素とする仮想ボリューム206の作成と対象DBMS90が動作するサーバ70への提供とを仮想化スイッチ60へ指示する。また、管理プログラム140は、作成した仮想ボリューム206を構成要素とした論理ボリューム204の作成をボリュームマネージャ78へ指示する。また、管理プログラム140は、アーカイブログがファイルとして記憶されている場合には作成した論理ボリュームを適当な場所にマウントすることをファイルシステム80へ指示する。DBMS90によるRedo・Undo処理が完了した後、本ステップで指示したものの逆処理を、つまり、ファイルシステム80へはマウントしたもののアンマウントを、ボリュームマネージャ78へは作成した論理ボリューム204の削除を、仮想化スイッチ60へは作成した仮想ボリューム206の削除を、記憶装置40へは提供する設定を未提供に変更するように、それぞれ指示する（ステップ1216）。

管理プログラム140は、対象となるDBMS90に処理の再開を指示する。このとき、回復時点のDBMS設定情報400に記憶される環境変数を設定する。DBMS90がクラスタ構成でそのサーバ構成が変更された場合には、変更後のサーバ構成でDBMS90を再開する。そして、ステップ1240に進む（ステップ1217）。

管理プログラム140は、本処理を正常終了する（ステップ1240）。

管理プログラム140は、回復時点の回復対象データの複製を作成し、それに対してアクセス可能なシステムを構築する方法でDB回復処理を続行するか、管理者に確認する。この確認処理は、管理端末110を介した通知画面等を利用して実施する。管理者が処理を続行すると応答した場合はステップ1222に進み、中断すると応答した場合にはステップ1241に進み本処理を異常終了する（ステップ1221）。

管理プログラム140は、図18により説明する複製回復手順を決定する処理を実施する。回復手順の決定に成功した場合にはステップ1223に進み、失敗した場合にはステップ1241に進み本処理を異常終了する（ステップ1222）。

管理プログラム140は、ステップ1222で作成した複製回復手順に従って、対応する記憶装置40、仮想化スイッチ60、ボリュームマネージャ78に対して設定の変更を指示する。指示の発行順序は、複製回復手順として設定された順序に従う（ステップ1223）。

管理プログラム140は、図15により説明する処理（ステップ1203中に実施される）により決定された方法に従い、対応する記憶装置40にデータのリストアを指示する。なお、データのリストアは、複製回復処理用に新たに割当てられたLU208に対して行う（ステップ1224）。

管理プログラム140は、ステップ1222で作成した複製回復手順に従い、対応するファイルシステム80に対して設定の変更を指示する。その後、ステップ1206と同様な方法で、構成履歴情報142を参照して回復対象データに対応するファイル202のうちファイルタイプ426の値が「File」であるものを管理するファイルシステムを把握し、それらをマウントするようファイルシステム80に指示する。

更に、管理プログラム140は、ステップ1612で決定したデータファイルパス名422・実体ファイルパス名424の変更に従い、それらが不一致の場合に変更後のデータファイルパス名422で示されるファイルエントリを変更後の実体ファイルパス名424へのシンボリックリンクと設定するようファイルシステム80に指示する。なお、一部のオブジェクト222が回復対象データに指定されているときには、回復対象データに対応する部分のみシンボリックリンクの確認・設定処理を行う（ステップ1225）。

管理プログラム140は、複製された回復対象データ（以下、「複製回復データ」）を管理するDBMS90（以下「複製DBMS」）のDBMSシステムディレクトリ下に記憶される設定情報の修正を、それらが動作するサーバ70上で実行中の管理エージェント160に指示する。修正内容はステップ1612で決定される。同時に、複製回復対象のDBMS90の回復時点のDBMS設定情報400のコピーをもとに、複製DBMS用のDBMS設定情報400を作成し、構成履歴情報142に記憶する。なお、DBMSシステムディレクトリ下に記憶される設定情報にあわせてDBMS設定情報400の内容も修正する。また、複製DBMSのサーバ構成にあわせてログの記憶領域（ファイル202等）の作成・初期化等が必要であれば、その実行を管理エージェント160に指示する。

更に、複製DBMSによるサーバ70の利用状況にあわせて空きリソース情報146中の空きサーバID672、空きリソース674を更新する（ステップ1226）。

管理プログラム140は、図15により説明する処理でアーカイブログを利用したDB回復を実施すると決定された場合、アーカイブログを用いたRedo・Undo処理の実施を複製DBMSに対して指示する。このステップの詳細は、Redo・Undo処理を実施するものが回復対象のDBMS90から複製DBMSに変わることを除き、ステップ1216と同様である（ステップ1227）。

管理プログラム140は、複製DBMSに処理の開始を指示する。このとき、複製DBMS向けのDBMS設定情報400により保持される環境変数を設定する。そして、ステップ1240に進む（ステップ1228）。

図14に、管理プログラム140によりステップ1203として実施される、DBデータの回復方法設定処理の処理フロー例のフローチャートを示す。ステップ1301で処理を開始する。

管理プログラム140は、管理端末110を介して管理者に、管理者が回復方法を直接指定するか確認する。直接指定する場合にはステップ1314に進み、指定しない場合にはステップ1303に進む（ステップ1302）。

管理プログラム140は、管理端末110を介して管理者に、回復したDBのデータを業務で直接利用するか確認する。直接利用する場合にはステップ1311に進み、利用しない場合にはステップ1304に進む。なお、具体的には、性能問題による構成回復、影響範囲が広い誤処理やサーバ70のウィルス感染からの処理再実行による回復、等の場合に直接回復データを利用する方法が選択される。このようなガイドを管理端末110を介して管理者に提示してもよい（ステップ1303）。

管理プログラム140は、管理端末110を介して管理者に、一部オブジェクト222のみ回復するか確認する。一部オブジェクト222のみを回復する場合にはステップ1312に進み、全データを回復する場合にはステップ1305に進む。具体的には、表データ誤削除の回復に旧データを引き出す、等の場合に一部表データのみの回復が選択される。このようなガイドを管理端末110を介して管理者に提示してもよい（ステップ1304）。

管理プログラム140は、DBデータの回復方法を複製回復に設定し、ステップ1306に進む（ステップ1305）。

管理プログラム140は、図15により説明する、回復処理で処理対象となるデータを把握する処理を実施する。把握に成功した場合にはステップ1320に進み、本処理を正常終了する。失敗した場合にはステップ1321に進み、本処理を異常終了する（ステップ1306）。

管理プログラム140は、DBデータの回復方法を完全回復に設定し、ステップ1306に進む（ステップ1311）。

管理プログラム140は、管理端末110を介して、回復が必要なオブジェクト222の識別情報（オブジェクト名414）を管理者から取得する。その後、DBデータの回復方法を取得したオブジェクト名414により識別されるオブジェクト222の複製回復に設定し、ステップ1306に進む（ステップ1312）。

管理プログラム140は、管理端末110を介して、回復方法と、回復方法が一部データ（オブジェクト222）の複製回復である場合には、その回復対象とするオブジェクト222の識別情報（オブジェクト名414）を管理者から取得する。取得した情報を回復方法として設定し、ステップ1306に進む（ステップ1314）。

図15に、管理プログラム140によりステップ1306として実施される、回復対象データ把握処理の処理フロー例のフローチャートを示す。ステップ2101で処理を開始する。

管理プログラム140は、回復対象のDBMS90に対応する回復時点における構成情報が存在するか、ステップ1206と同様な方法で構成履歴情報142を参照して確認する。このとき、テーブルスペースのみでなく、DBMSシステムディレクトリ内のデータに関しても、対応する構成情報が存在するか確認する。全て存在する場合にはステップ2103に進み、一部でも未存在であった場合にはステップ2131に進み、本処理を異常終了する（ステップ2102）。

管理プログラム140は、回復対象のDBMS90が管理するデータ全体を回復するか確認する。図14の処理フローにおいて、ステップ1312を実行した場合、もしくは、ステップ1314を実行し、管理者から一部データ（オブジェクト222）の複製回復が指定された場合には、データ全体を回復しないとしてステップ2121に進む。それ以外の場合はステップ2104に進む（ステップ2103）。

管理プログラム140は、回復時点において回復対象のDBMS90が管理するデータ全体（システムディレクトリ内のデータを含む）を回復対象データに設定し、ステップ1206と同様な方法で構成履歴情報142を参照して回復対象データに対応するLU208を把握する（ステップ2104）。

管理プログラム140は、把握したLU208に関して回復時点以前のスナップショットイメージが存在するか、バックアップデータ情報144を参照して把握する。あるLU208に関して、そのようなスナップショットイメージが複数存在する場合には、その中で最新のものを選択する。把握した全てのLU208に関してスナップショットイメージが全部存在する場合にはステップ2106に進み、一部でも未存在の場合にはステップ2131に進み、本処理を異常終了する（ステップ2105）。

管理プログラム140は、ステップ2105で選択したスナップショットイメージからストレージジャーナルにより回復時点まで回復可能か、つまり、そのスナップショットイメージの取得時点から回復時点までの間のストレージジャーナルが選択した全スナップショットイメージに対して存在するかどうか把握する。全部存在する場合には回復可能としてステップ2126に進む。一部での存在しない場合には回復不可能としてステップ2107に進む（ステップ2106）。

管理プログラム140は、ステップ2105で選択したスナップショットイメージからアーカイブログにより回復時点まで回復可能か、つまり、把握した全てのLU208に関して、全て同時に取得されたスナップショットイメージが存在し、かつ、そのスナップショットイメージの取得時点から回復時点までのアーカイブログが存在するか把握する。これは、バックアップデータ情報144を参照することにより実施する。存在する場合には回復可能としてステップ2108に進み、存在しない場合には回復不可能としてステップ2131に進み、本処理を異常終了する。なお、「全て同時に取得されたスナップショットイメージが存在する」とは、回復時点以前で、把握した全てのＬＵ２０８について、全て同時刻に取得したスナップショットイメージが存在するということである（例えば、把握した全てのＬＵ２０８が属するＬＵグループを対象にしたスナップっショットイメージがあるということである）。

なお、回復対象のDBMS90がテーブルスペース毎の回復を行うことができる場合には、以下の処理により条件を緩和できる。構成履歴情報142中の回復対象のDBMS90の回復時点のDBMS設定情報400により、回復時点のテーブルスペース設定を把握する。それを基に構成履歴情報142を参照して、回復時点のテーブルスペース毎のLU208までの対応関係を把握し、同じテーブルスペースに対応するLU208の組（1つのLU208が複数の組の要素となり得る）を作成する。それぞれの組で、構成要素のLU208について同時にスナップショットイメージが取得され、かつ、スナップショットイメージの取得時点から回復時点までのアーカイブログが存在する場合には、回復可能と判断する（ステップ2107）。

管理プログラム140は、アーカイブログを利用した回復処理を行うことに決定し、ステップ2107までに把握したスナップショットイメージとアーカイブログを回復処理に利用するデータに決定する。そして、ステップ2130に進む（ステップ2108）。

管理プログラム140は、本処理を正常終了する（ステップ2130）。

管理プログラム140は、ステップ1206と同様な方法で構成履歴情報142を参照し、回復時点における回復対象データ（オブジェクト222）が記憶されるテーブルスペースを把握する（ステップ2121）。

管理プログラム140は、ステップ2121で把握した回復対象となるテーブルスペース、回復対象のDBMS90のログ、システムディレクトリ内のデータを回復対象データに設定し、ステップ1206と同様な方法で構成履歴情報142を参照し、回復対象データに対応するLU208を把握する。そして、ステップ2105に進む（ステップ2122）。

管理プログラム140は、ストレージジャーナルを利用した回復処理を行うことに決定し、ステップ2106までに把握したスナップショットイメージとストレージジャーナルを回復処理に利用するデータに決定する。そして、ステップ2130に進む（ステップ2126）。

図16、図17に、管理プログラム140によりステップ1207として実施される、完全回復手順を決定する処理の処理フロー例のフローチャートを示す。本処理で設定される手順は、ファイルシステム80に対する指示を除き、先に設定されたものがステップ1212で先に実行される。ステップ1401で処理を開始する。

管理プログラム140は、ステップ1206と同様な方法で構成履歴情報142を参照し、回復時点と現時点における回復対象DBMSのサーバ構成と構成要素の各DBMS90における回復対象データに対応するファイル202（ローデバイス機構を利用した場合を含む）から記憶装置40内のHDD16に至るまでのストレージ構成を把握する。この情報を「構成ワーク情報」と呼ぶ。なお、構成ワーク情報中の現時点の構成に関しては、以下のステップで構成変更指示を発行する手順を設定した場合には、その手順を実施したあとの構成を記憶する。つまり、ステップを実行するたびにその情報が変化する（ステップ1402）。

管理プログラム140は、構成ワーク情報を参照して回復時点と現時点における回復対象DBMSのサーバ構成を比較する。差が存在しない場合にはステップ1406に進み、差が存在する場合にはステップ1404に進む（ステップ1403）。

管理プログラム140は、構成ワーク情報から回復時点と現時点における回復対象DBMSのサーバ構成を把握し、それを同一状態に復元するサーバ割り当てが可能か確認する。現在の構成要素以外のサーバ70上でDBMS90が動作する場合、管理プログラム１４０は、そのサーバ70（現在のＤＢＭＳ９０の構成要素以外のサーバであって待機系として利用するサーバ７０）上でDBMS90を実行可能か空きリソース情報146を参照して確認する（例えば、そのサーバ７０で現在他のプログラムを実行中でも追加的に実行可能か否かを空きリソース情報１４６を参照して確認する）。可能な場合は回復時点のサーバ構成で回復処理を実施するとしてステップ1406に進み、不可能な場合にはステップ1405に進む。なお、現時点のサーバ構成台数が回復時点より多い場合、現時点でのサーバ構成で回復処理を実施するとしてステップ1405に進むと判断してもよい（ステップ1404）。

管理プログラム140は、構成ワーク情報から現時点における回復対象DBMSのサーバ構成を把握し、そのサーバ構成と新規に割り当て可能なサーバ70から回復対象DBMSの回復時のサーバ構成を作成する。管理端末110を介した通知画面等を利用し、そのサーバ構成で回復処理を続行するか管理者に確認する。

回復対象DBMSがクラスタ構成でない場合はサーバが異なっても回復対象データをそのままアクセス可能である。シェアードディスク型クラスタ構成の場合は、回復対象データはそのままアクセス可能（各サーバ70で動作するDBMS90が全回復対象データを参照する）であるが、クラスタ構成情報の修正が必要であり、この修正方法を決定する。

シェアードナッシング型クラスタ構成の場合は、現在利用不可能なサーバ70上で実行されていたDBMS90がアクセスしていたデータ（この段落において「データＡ」と言うことがある）を他のサーバ70上で実行されるDBMS90に割り当てる必要がある。構成ワーク情報からデータＡを把握し、それらをデータ量やアクセスパス設定可・不可等（例えば、アクセスパスの物理構成からアクセスできるかどうか等）の指標を用いて再割り当てする案（具体的には、案を記載した電子データ）を作成し、それも管理者に提示する。具体的には、例えば、構成ワーク情報には、回復時点と現時点の回復対象ＤＢＭＳのサーバ構成と構成要素の各ＤＢＭＳ９０、それからファイル２０２までのストレージ構成を表す情報が含まれている。つまり、現時点と回復時点での構成要素のＤＢＭＳ９０の差を把握し、回復時点と現時点で不一致なＤＢＭＳ９０のうち、回復時点に動作していたＤＢＭＳ９０が把握される。このＤＢＭＳ９０がアクセスしていたデータが、データＡとして把握される。また、前述の割り当て（再割り当て）とは、例えば、待機系として利用するサーバ７０、ＤＭＢＳ９０に対して、データを管理（アクセス）するように割当て（再割り当て）をすることである（直接的なパス変更は後で実施してよい）。また、回復時点で動作していないDBMS90へのデータの再割り当て案の作成も同時に実施する。再割り当て案を作成できない場合には回復処理を中断するものとする。なお、データの再割り当てにはDBMSの設定情報中のデータのマッピングに関する情報や、クラスタ構成情報の修正を必要とする場合があり、この修正方法を決定する。

回復対象DBMSがクラスタ構成の場合で回復時点のサーバ台数より多くの台数で回復処理を行う場合等、回復時点において対応するログのデータが存在しないサーバ70（DBMS90）が存在する。これらについては、ログの記憶領域（ファイル202等）の作成・初期化等を実施するとする。また、回復時点で対応するDBMS90が存在しない場合、DBMSの設定情報や環境変数を、他のクラスタ構成の構成要素の設定情報のコピーから個別情報を修正することにより作成する方法を決定する。

管理者が処理続行と応答した場合には、本ステップで作成した構成を回復時点での構成に置き換えてステップ1406に進む。処理中断と応答した場合にはステップ1431に進み、本処理を異常終了する（ステップ1405）。

管理プログラム140は、構成ワーク情報を参照して回復時点と現時点におけるLU208構成を比較し、対応するLU208が全て存在し、かつ、同じサイズか確認する。全て存在かつ一致する場合にはステップ1408に進み、一部未存在または不一致な場合はステップ1407に進む（ステップ1406）。

管理プログラム140は、構成ワーク情報を参照し、回復時点のLU208に対応するものが現時点で未存在の場合には、対応する記憶装置40にそれと同サイズのLU208を新規に作成する指示を、回復時点と現時点のLU208のサイズが異なる場合には、対応する記憶装置40にそのLU208のサイズを回復時点のものに戻す指示を回復処理手順（例えば、複数の指示をどのような順番でどこに発行するかが記録される電子データ）に設定する。ここで、これらの指示を出すために必要なHDD16の領域を確保可能か空きリソース情報146を参照して確認し、不足する場合には処理失敗とする。また、記憶装置40やHDD16、LU208がプロテクトリソースに指定され、上記の処理を行うことができない場合も処理失敗とする。処理が成功した場合にはステップ1408に進み、処理に失敗した場合にはステップ1431に進み、本処理を異常終了する（ステップ1407）。

管理プログラム140は、構成ワーク情報を参照し、回復対象データに対応するLU208が記憶されるHDD16上の記憶領域に、回復時点と現時点で差が存在するか確認する。異なるものが存在する場合にはステップ1409に進み、存在しない場合にはステップ1411に進む（ステップ1408）。

管理プログラム140は、LU208のHDD16上の記憶領域に差があるものについて、構成ワーク情報を参照し、対応する記憶装置40に対し、図10に例示した、回復時点の構成で利用される領域上に異なるLU208のデータが現存する場合にそれを新規確保した領域へ移動する指示と、その後に回復時点の配置に戻す移動を行う指示を回復処理手順に追加設定する。ここで、これらの指示に必要なHDD16の領域を確保可能か空きリソース情報146を参照して確認し、不足する場合には処理失敗とする。また、記憶装置40やHDD16、LU208がプロテクトリソースに指定され、上記の処理を行えない場合も処理失敗とする。更に、回復時点で利用していたHDD16が現時点で存在しない場合も処理失敗とする。処理が成功した場合にはステップ1411に進み、処理に失敗した場合にはステップ1410に進む（ステップ1409）。

管理プログラム140は、管理端末110を介した通知画面等を利用し、回復時点とは異なるHDD構成で回復処理を続行するか管理者に確認する。管理者が処理続行すると応答した場合はステップ1411に進み、処理中断と応答した場合にはステップ1431に進み、本処理を異常終了する（ステップ1410）。

管理プログラム140は、構成ワーク情報を参照し、回復対象データに対応する仮想ボリューム206の構成が回復時点と現時点で一致するか確認する。全て一致する場合にはステップ1413に進み、一部一致しない場合にはステップ1412に進む（ステップ1411）。

管理プログラム140は、仮想ボリューム206の構成が回復時点と現時点で一致しないものについて、回復時点の仮想ボリューム206を復元する手順を回復処理手順に追加設定する。まず、構成ワーク情報を参照し、復元対象の仮想ボリューム206を提供する仮想化スイッチ60がその構成要素となるLU208に対してアクセス不可能な場合、そのLU208を有する記憶装置40に、そのLU208を復元対象の仮想化スイッチ60に提供するよう、LU208とポート36の対応関係を設定する指示を回復処理手順に追加設定する。仮想ボリューム206が複数のLU208から構成される場合、それぞれについて指示を回復処理手順に追加設定する。また、必要に応じて、仮想化スイッチ60に対してLU208を認識する指示を回復処理手順に追加設定する。その後、復元対象の仮想化スイッチ60に仮想ボリューム206を復元（再作成）する指示を回復処理手順に追加設定する。

記憶装置40やI/Oパス34、仮想化スイッチ60、仮想化ボリューム206がプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1413に進み、処理が失敗した場合にはステップ1431に進み本処理を異常終了する（ステップ1412）。

管理プログラム140は、構成ワーク情報を参照し、回復対象データに対応する論理ボリューム204の構成が回復時点と現時点で一致するか確認する。全て一致する場合にはステップ1415に進み、一部一致しない場合にはステップ1414に進む（ステップ1413）。

管理プログラム140は、論理ボリューム204の構成が回復時点と現時点で一致しないものについて、回復時点の論理ボリューム204を復元する手順を回復処理手順に追加設定する。構成ワーク情報を参照し、復元対象の論理ボリューム204を提供するボリュームマネージャ78がその構成要素となる仮想ボリューム206 に対してアクセス不可能な場合、その仮想ボリューム206を提供する仮想化スイッチ60に、その仮想ボリューム206を復元対象のボリュームマネージャ78が動作するサーバ70に提供するよう、仮想ボリューム206とポート36の対応関係を設定する指示を回復処理手順に追加設定する。論理ボリューム204が複数の仮想ボリューム206から構成される場合、それぞれについて指示を回復処理手順に追加設定する。また、必要に応じて、ボリュームマネージャ78に対して仮想ボリューム206を認識する指示を回復処理手順に追加設定する。その後、復元対象のボリュームマネージャ78に論理ボリューム204を復元（再作成）する指示を回復処理手順に追加設定する。

I/Oパス34、仮想化スイッチ60、ボリュームマネージャ78、論理ボリューム204がプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1415に進み、処理が失敗した場合にはステップ1431に進み本処理を異常終了する（ステップ1414）。

管理プログラム140は、ステップ1206と同様な方法で構成履歴情報142を参照し、回復時点と現時点における回復対象データに対応するLU208が属する分割キャッシュ212を把握する。把握した分割キャッシュ212の回復時点と現時点における構成、つまり、構成要素のLU208とキャッシュメモリ量が一致するか、それぞれ対応する記憶装置設定情報550を参照して確認する。全て一致する場合にはステップ1418に進み、一部でも一致しない場合はステップ1416に進む（ステップ1415）。

管理プログラム140は、分割キャッシュの設定を復元する手順を設定する。ステップ1206と同様な方法で構成履歴情報142を参照し、分割キャッシュ212の構成要素が一致しなかったものについて、対応する記憶装置40に回復時点の構成要素に復元するための分割キャッシュ212に属するLU208を追加・削除する指示を回復処理手順に追加設定する。また、分割キャッシュ212のキャッシュメモリ量が一致しなかったものについて、対応する記憶装置40にキャッシュメモリ量を回復時点に復元するためのキャッシュメモリ量の増加・削減指示を回復処理手順に追加設定する。

キャッシュメモリ量を増加する場合はデフォルト分割キャッシュからキャッシュメモリを確保し、削減する場合にはデフォルト分割キャッシュにキャッシュメモリを返却する。デフォルト分割キャッシュから必要な量のキャッシュメモリを確保できるかどうか、構成履歴情報142中の対応する最新の記憶装置設定情報550中の値を参照し、変更後のデフォルト分割キャッシュのキャッシュメモリ量が事前決定される最低必要量を下回らない場合に確保可能と判断する。確保不可能と判断される場合は処理失敗とする。また、記憶装置40、分割キャッシュ212がプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1418に進み、処理が失敗した場合にはステップ1417に進む（ステップ1416）。

管理プログラム140は、管理端末110を介した通知画面等を利用して回復時点とは異なる分割キャッシュ構成で回復処理を続行するか管理者に確認する。管理者が処理を続行すると応答した場合はステップ1418に進み、中断すると応答した場合にはステップ1431に進み本処理を異常終了する（ステップ1417）。

管理プログラム140は、構成ワーク情報を参照し、以下の確認を行う。まず、回復時点の回復対象データが記憶される論理ボリューム204とそのパーティションを把握する。把握した論理ボリューム204とパーティションについて、回復対象データを記憶するファイル202が通常ファイルの場合にはマウントポイント458の値が、ローデバイス機構を利用する場合はローデバイスパス名460の値が回復時点と現時点で一致するか確認する。全て一致する場合にはステップ1430に進み、一部一致しない場合にはステップ1419に進む（ステップ1418）。

管理プログラム140は、マウントポイントやローデバイス設定を復元する手順を回復処理手順に追加設定する。まず、マウントポイント458の値が回復時点と現時点で一致しないものについて、対応するファイルシステム80に対してマウントポイントを回復時点のものに復元（変更）する指示を回復処理手順に追加設定する。次に、ローデバイスパス名460の値が回復時点と現時点で一致しないものについて、対応するファイルシステム80に対してローデバイス設定を回復時点のものに復元（変更）する指示を回復処理手順に追加設定する。

ここで、ファイルシステムがプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1430に進み、処理が失敗した場合にはステップ1431に進み本処理を異常終了する（ステップ1419）。

管理プログラム140は、本処理を正常終了する（ステップ1430）。

図18に、管理プログラム140によりステップ1209として実施される、競合が発生するか確認し、発生した場合にはそれを回避する手順（競合回避手順）を設定する処理の処理フロー例のフローチャートを示す。本処理で設定される手順は、完全回復手順による手順が終わった後、本処理で先に設定されたものから順にステップ1212で実行される。ステップ1501で処理を開始する。

管理プログラム140は、構成履歴情報142から現時点におけるI/Oパス34の構成を把握する。この情報を「I/Oパス構成ワーク情報」と呼ぶ。現時点のI/Oパス34の構成は、構成履歴情報142中の各要素に対応する最新のOS設定情報440、スイッチ設定情報500、記憶装置設定情報550に含まれる受信ポート・送信ポートの設定を参照することにより求める。なお、I/Oパス構成ワーク情報中の現時点の構成に関しては、構成変更指示を発行する手順を設定後、その手順実施後の構成を記憶する。つまり、ステップを実行するたびにその情報が変化する（ステップ1502）。

管理プログラム140は、完全回復手順適用後の回復対象データに対応する論理ボリューム204からLU208に至るストレージ構成を把握する。具体的には、ステップ1206と同様な方法で構成履歴情報142を参照して現時点における回復対象データに対応するストレージ構成を把握し、その後に完全回復手順による構成の変更分を把握構成に反映する。把握したストレージ構成から、回復対象データのI/O処理に利用されるI/Oパス34を把握し、I/Oパス構成ワーク情報中に「回復時点利用」の印をつける（ステップ1503）。

管理プログラム140は、回復対象データに対応するストレージ構成の完全回復処理後に競合が発生するI/Oパス34を把握する。まず、I/Oパス構成ワーク情報中に「回復時点利用」の印がついたI/Oパス34に注目し、その受信ポート設定が行われている装置（サーバ70、仮想化スイッチ60）とポート36を把握する。構成履歴情報142中で、把握した装置に対応するOS設定情報440またはスイッチ設定情報500で回復時点と現時点（最新）のものを参照し、回復時点と現時点のそれぞれで把握したポート36を経由して参照される仮想構造（ここでは仮想化ボリューム206もしくはLU208）を把握する。回復時点では参照されず現時点では参照される仮想構造が存在するとき、そのI/Oパス34で競合が発生とする。競合が発生するI/Oパス34に対して、I/Oパス構成ワーク情報中に「競合」の印をつけ、競合の発生原因となる仮想構造の識別子を全て保存する。競合が発生するI/Oパス34が存在する場合にはステップ1505に進み、存在しない場合にはステップ1512に進む（ステップ1504）。

管理プログラム140は、発生した競合を回避する、新規ストレージ構成案を作成する。まず、I/Oパス構成ワーク情報を参照し、競合が発生する（「競合」の印がついた）I/Oパス34と発生原因となる仮想構造を把握する。競合が発生したI/Oパス34と同じ装置（サーバ70、仮想化スイッチ60、記憶装置40）間で接続されているI/Oパス34を把握し、I/Oパス構成ワーク情報中でそのI/Oパス34が回復時点利用の印がついておらず、かつ、プロテクトリソースとして指定されていないか確認する。両条件を双方満たす場合に、そのI/Oパス34を経由して競合の発生原因となる仮想構造を提供するストレージ構成を新規構成案として決定する。

両条件のうちいずれかを満たさない場合、図11に例示した方法により、競合の発生原因となる仮想化ボリューム206、もしくは競合の発生原因となるLU208を構成要素とする仮想化ボリューム206と同じデータを参照可能な仮想化ボリューム206を他の仮想化スイッチ60に作成し、I/O処理を異なるI/Oパス34を経由するように構成変更できるかI/Oパス構成ワーク情報を参照して確認する。このとき、変更後のストレージ構成におけるI/Oパス34は回復時点利用の印が付加されず、かつ、プロテクトリソースとして指定されていないものとする。このようなストレージ構成を発見できた場合にはそれを新規構成案として決定する。

そのようなものが見つからなかった場合、図12に例示した方法により、競合の発生原因となる仮想化ボリューム206の構成要素となるLU208、もしくは競合の発生原因となるLU208のデータを他の記憶装置40にコピーすることによる構成変更が可能か確認する（図12では新規に作成するLU208に対応する仮想ボリューム206を作成し、対応する論理ボリューム204においてコピーを伴う構成変更で説明したが、仮想ボリューム206においてコピーを伴う構成変更を実施してもよい。）このとき、新規ストレージ構成が利用するI/Oパス34は回復時点利用の印が付加されず、かつ、プロテクトリソースとして指定されていないものとする。このようなストレージ構成を発見できた場合にはそれを新規構成案として決定する。

競合の発生原因となる仮想構造（例えば、仮想化ボリューム206もしくはLU208）について、全て新規ストレージ構成を決定できた場合に、本ステップの処理が成功したとしてステップ1506に進み、1つでも決定できなかった場合には、本ステップの処理が失敗したとしてステップ1521に進み本処理を異常終了する（ステップ1505）。

管理プログラム140は、新規にLU208を割当てる必要があるか確認する。つまり、新規ストレージ構成を実現するにあたり、コピーを伴うストレージ構成変更を1回でも実施する場合、新規にLU208の割当てが必要としてステップ1507に進む。1回も実施しない場合にはステップ1508に進む（ステップ1506）。

管理プログラム140は、新規ストレージ構成案中のコピーを伴うストレージ構成変更に関して、対応する記憶装置40にデータの移動先として新規に必要とされるLU208を作成する指示を競合回避手順に設定する。このLU208のサイズは移動元のものと同一である。新規LU208ためにHDD16の領域を確保可能か空きリソース情報146を参照して確認し、不足する場合には処理失敗とする。また、記憶装置40がプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1508に進み、処理が失敗した場合にはステップ1521に進み本処理を異常終了する（ステップ1507）。

管理プログラム140は、新規ストレージ構成案において、記憶装置40と仮想化スイッチ60の間で設定変更が必要か確認する。必要な場合にはステップ1509に進み、必要ない場合にはステップ1510に進む（ステップ1508）。

管理プログラム140は、新規ストレージ構成案を実現する、記憶装置40と仮想化スイッチの間の設定手順を競合回避手順に追加設定する。まず、I/Oパス構成ワーク情報を参照し、新規ストレージ構成案と現構成の記憶装置40におけるLU208の提供先（ポート設定）の差異を把握し、新規ストレージ構成案で利用するが現在未設定のLU208の提供先に関して、記憶装置40に対して提供するようにLU208とポート36の対応関係を設定する指示を回復処理手順に追加設定する。次に、必要に応じて、仮想化スイッチ60に対して新規に提供されるLU208を認識する指示を競合回避手順に追加設定する。その後、仮想化スイッチ60に対する、新規提供されたLU208を利用し、新規ストレージ構成案にあわせて仮想ボリューム206の構成変更もしくは新規仮想ボリュームの作成の指示を競合回避手順に追加設定する。

ここで、記憶装置40や仮想化スイッチ60、仮想化ボリューム206がプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1510に進み、処理が失敗した場合にはステップ1521に進み本処理を異常終了する（ステップ1509）。

管理プログラム140は、新規ストレージ構成案において、仮想化スイッチ60とサーバ70の間で設定変更が必要か確認する。必要な場合にはステップ1511に進み、必要ない場合にはステップ1512に進む（ステップ1510）。

管理プログラム140は、新規ストレージ構成案を実現する、仮想化スイッチ60とサーバ70の間の設定手順を競合回避手順に追加設定する。まず、I/Oパス構成ワーク情報を参照し、新規ストレージ構成案と現構成の仮想化スイッチ60における仮想ボリューム206の提供先（ポート設定）の差異を把握し、新規ストレージ構成案で利用するが現在未設定の仮想ボリューム206の提供先に関して、仮想化スイッチ60に対して提供するように仮想ボリューム206とポート36の対応関係を設定する指示を回復処理手順に追加設定する。次に、必要に応じて、ボリュームマネージャ78に対して新規に提供される仮想ボリューム206を認識する指示を競合回避手順に追加設定する。その後、ボリュームマネージャ78に対して、新規に提供された仮想ボリューム206を利用し、新規ストレージ構成案にあわせて論理ボリューム204の構成変更する指示を競合回避手順に追加設定する。

ここで、仮想化スイッチ60、ボリュームマネージャ78、論理ボリューム204がプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1512に進み、処理が失敗した場合にはステップ1521に進み本処理を異常終了する（ステップ1511）。

管理プログラム140は、現時点と完全回復手順・（これまでに設定した）競合回避手順適用後の回復対象データに対応する論理ボリューム204からLU208に至るストレージ構成の差異を把握し、不要となるストレージ構成要素を削除する指示を競合回避手順に追加設定する。

まず、ステップ1206と同様な方法で構成履歴情報142を参照して現時点における回復対象データに対応するストレージ構成を把握する。その後に完全回復手順・競合回避手順適用による構成の変更分を把握構成に反映し、回復処理後のストレージ構成を把握する。双方を比較し、回復処理後に未利用になる論理ボリューム204、仮想スイッチ60におけるポート設定、論理ボリューム206、記憶装置40におけるポート設定、LU208を把握し、対応するボリュームマネージャ78、仮想化スイッチ60、記憶装置40に対するそれらの削除指示を競合回避手順に追加設定する。なお、削除指示の設定順（送付順）は、上記の要素列挙順に従う。なお、記憶装置40や仮想化スイッチ60、ボリュームマネージャ78、LU208、仮想化ボリューム206、論理ボリューム204がプロテクトリソースに指定され、上記の処理を行うことができない場合は処理失敗とする。処理が成功した場合にはステップ1520に進み、処理が失敗した場合にはステップ1521に進み本処理を異常終了する（ステップ1512）。

管理プログラム140は、本処理を正常終了する（ステップ1520）。

図19に、管理プログラム140によりステップ1222として実施される、複製回復手順を決定する処理の処理フロー例のフローチャートを示す。本処理で設定される手順は、ファイルシステム80に対する指示を除き、先に設定されたものがステップ1223で先に実行される。ステップ1601で処理を開始する。なお、本処理の開始時に、利用可能な仮想化スイッチ60やサーバ70に関する制約条件が与えられてもよい。

管理プログラム140は、ステップ1206と同様な方法で構成履歴情報142を参照し、回復時点における回復対象DBMSのサーバ構成と回復対象データの対応するファイル202（ローデバイス機構を利用した場合を含む）から記憶装置40内のLU208に至るまでのストレージ構成を把握する（ステップ1602）。

管理プログラム140は、複製回復データを保持するLU208（以下、複製LU）を作成可能か確認する。ステップ1602で把握した回復時点の回復対象データに対応するLU208の複製を、例えば同一記憶装置40内等の範囲で作成可能か確認する。複製LUの記憶領域として複製元のLU208と同サイズ分を確保可能か空きリソース情報146を参照して確認する。複製先となりうる記憶装置40がプロテクトリソースに指定されている場合には複製不可と判断する。すべての複製LUを作成可能ならステップ1604に進み、1つでも不可能なものが存在する場合にはステップ1631に進み本処理を異常終了する（ステップ1603）。

管理プログラム140は、回復時点の回復対象データに対応する仮想ボリューム206と「等価」（記憶装置40における対応記憶領域が複製LUで、管理構造の記憶領域（I/O先）における複製LUとの対応関係が回復時点の回復対象データにおけるそれと論理的に同一な状態）な仮想ボリュームを作成可能か確認する。構成履歴情報142中の各仮想化スイッチ60、記憶装置40に対応する最新のスイッチ設定情報500、記憶装置設定情報550に含まれる受信ポート・送信ポートの設定を参照し、各複製LUを参照可能な仮想スイッチ60と対応するI/Oパス34を把握する。なお、プロテクトリソースに指定されている、もしくは、処理開始時に与えられた制約条件を満たさない仮想化スイッチ60は除外する。ステップ1602で把握した回復時点の回復対象データに対応する仮想ボリューム206と等価な仮想ボリューム206が作成可能か（対応するデータを保持するLU208をすべて参照可能か）、各仮想化スイッチ60で確認し、作成可能な仮想化スイッチ60と仮想ボリューム206、対応するI/Oパス34の組をすべて記憶する。

すべての等価な仮想ボリューム206がいずれかの仮想化スイッチで作成可能ならステップ1605に進む。1つでも不可能なものが存在する場合にはステップ1631に進み本処理を異常終了する（ステップ1604）。

管理プログラム140は、複製回復データを参照可能なサーバ構成を構築可能か確認する。構成履歴情報142中の各サーバ70、仮想化スイッチ60に対応する最新のOS設定情報440、スイッチ設定情報500に含まれる受信ポート・送信ポートの設定を参照し、各等価な仮想ボリューム206について、それを参照可能なサーバ70と対応するI/Oパス34を把握し、それら組を記憶する。なお、プロテクトリソースに指定されている、もしくは、処理開始時に与えられた制約条件を満たさないサーバ70は除外する。また、空きリソース情報146を参照し、空きサーバID672に含まれない識別子のサーバ70も除外し、空きサーバのみの確認とする。

回復対象DBMSがクラスタ構成でない場合やシェアードディスク型クラスタ構成の場合は、1台以上の空きサーバがすべての等価な仮想ボリューム206を参照可能なら、複製回復データを参照可能なサーバ構成を構築可能である。ここで、クラスタ構成でない場合には、参照可能な空きサーバのうち任意の1台を選択する。シェアードディスク型クラスタ構成の場合、その中から任意の台数（多くの場合、回復対象DBMSの回復時点での構成台数もしくは1台）分の空きサーバを選択する。

回復対象DBMSがシェアードナッシング型クラスタ構成の場合は、ステップ1602で把握した回復対象DBMSの回復時点のサーバ構成と回復対象データのストレージ構成を元に、各構成要素のサーバが参照していた仮想ボリューム206の組に対応する等価な仮想ボリューム206の組を作成する。作成した等価な仮想ボリューム206の組の要素をすべて参照可能な空きサーバがその構成要素の代替サーバとなりうる。すべての構成要素のサーバに対して代替サーバとなりうる空きサーバが存在する場合に、複製回復データを参照可能なサーバ構成が構築可能である（1台の空きサーバが複数台の代替サーバとなっても良い。）ある構成要素のサーバに対して複数台の空きサーバが代替サーバになりうる場合には、任意のものを選択する（サーバ台数を増加させる構成の場合は複数台を選択する。）なお、1台の代替サーバで複数のサーバ上で動作するDBMS90を実施する場合や、回復対象DBMSの回復時点でのサーバ構成より多くの代替サーバを利用して複製DBMSのサーバ構成を利用する場合、ステップ1405と同様な方法で代替サーバが参照可能な等価な仮想ボリュームを用いたデータの再割り当て案作成を同時に実施する。

複製回復データを参照可能なサーバ構成を構築可能ならステップ1606に進み、1つでも不可能なものが存在する場合にはステップ1631に進み本処理を異常終了する（ステップ1605）。

管理プログラム140は、管理端末110を介した通知画面等を利用し、作成したサーバ構成とストレージ構成で回復処理を続行するか管理者に確認する。管理者が処理続行と応答した場合にはステップ1611に進む。処理中断と応答した場合にはステップ1631に進み、本処理を異常終了する。なお、処理の続行・中断以外の管理者の判断として、異なる制約条件によるステップ1601から処理再実行を加えてもよい（ステップ1606）。

管理プログラム140は、作成したサーバ構成とストレージ構成を実現する複製回復処理手順を設定する。その設定内容と設定順序（設定順に従って指示を発行する）は、例えば以下の通り、
i) 記憶装置40に対する複製LUを作成する指示（複製元のLU208と同サイズを指定）、
ii) 記憶装置40に対する複製LUを仮想化スイッチ60が参照可能にするLU208とポート36の対応関係の設定指示、
iii) 必要に応じて、仮想化スイッチ60に対する新規に提供されるLU208の認識指示、
iv) 仮想化スイッチ60に対する新規に提供されたLU208を利用した等価な仮想ボリューム206の作成指示、
v) 仮想化スイッチ60に等価な仮想ボリューム206を代替サーバに提供する仮想ボリューム206とポート36の対応関係の設定指示、
vi) 必要に応じて、代替サーバのボリュームマネージャ78に対する新規に提供される仮想ボリューム206の認識指示、
vii) 代替サーバのボリュームマネージャ78に対する提供された等価な仮想ボリューム206を利用した等価な論理ボリューム204の作成指示、
viii) 代替サーバのファイルシステム80に対する等価な論理ボリューム204中のパーティションのマウントポイントやローデバイスのパス名の設定指示、
である。マウントポイントやローデバイスのパス名は、任意に指定可能である（ステップ1611）。

管理プログラム140は、決定した代替サーバによるサーバ構成・複製LUによるストレージ構成にあわせて変更する、複製DBMSの設定情報の変更内容を決定する。修正する情報は、DBMSの識別子（複製DBMS用に新規作成）、代替サーバの構成に合わせたネットワーク設定（例えば、IPアドレス設定）やクラスタ構成設定やデータマッピングの設定、そして、ステップ1611で決定したマウントポイント・ローデバイスのパス名に従ったシステムディレクトリパス404（環境変数406中の設定を含む）、データファイルパス名422・実体ファイルパス名424の修正、その他更新が必要とされる情報である。

また、複製DBMSがクラスタ構成の場合で回復時点における回復対象DBMSのサーバ台数より多くの台数で回復処理を行う場合、回復時点において対応するログのデータが存在しないサーバ70（DBMS90）が存在する。これらについては、ログの記憶領域（ファイル202等）の作成・初期化等を実施するとする（ステップ1612）。

管理プログラム140は、本処理を正常終了する（ステップ1630）。

以上、上述した実施形態によれば、DB回復処理において、回復したい時点を管理者が指定すれば、DB回復処理と、回復されたDBをアクセスするためのストレージの構成の構築（回復或いは新規構築）が行われる。そのため、DB回復処理を容易に行えるようになる。

また、本実施形態によれば、システム構成を回復時点の構成に完全に戻せない場合にも、ストレージの論理的な構成が復元される。つまり、回復時点のDBにアクセス可能な環境が構築される。そのため、回復時点のDBにアクセス可能な環境をより柔軟に（より少ない制約で）回復することができる。

また、本実施形態によれば、DB回復処理に用いるバックアップデータを、つまり、いずれのスナップショットイメージ・ストレージジャーナル・アーカイブログを利用してデータ回復処理を行うかを、自動的に決定することができる。従って、バックアップデータの選択という観点により、DB回復処理における管理者の負荷が削減される。

以上、本発明の実施形態を説明したが、この実施形態は本発明の説明のための例示にすぎず、本発明の範囲をその実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。例えば、DBMSが稼動する計算機を含む計算機システムの管理に本実施形態が広く利用される可能性がある。

本発明の一実施形態における計算機システムの構成例を示す図である。 DBMS90が管理するDBデータのデータマッピング階層構成を例示する図である。 構成履歴情報142のデータ構造例を示す模式図である。 DBMS設定情報400のデータ構造例を示す模式図である。 OS設定情報440のデータ構造例を示す模式図である。 スイッチ設定情報500のデータ構造例を示す模式図である。 記憶装置設定情報550のデータ構造例を示す模式図である。 バックアップデータ情報144のデータ構造例を示す模式図である。 空きリソース情報146のデータ構造例を示す模式図である。 ストレージ構成の変更方法の第一の例を示す図である。 ストレージ構成の変更方法の第二の例を示す図である。 ストレージ構成の変更方法の第三の例を示す図である。 DBデータの回復処理のメイン処理の処理フロー例を示す図である。 DBデータの回復方法設定処理の処理フロー例を示す図である。 回復対象データ把握処理の処理フロー例を示す図である。 完全回復手順を決定する処理の処理フロー例の一部を示す図である。 完全回復手順を決定する処理の処理フロー例の残りの一部を示す図である。 競合回避手順を設定する処理の処理フロー例を示す図である。 複製回復手順を決定する処理の処理フロー例を示す図である。

符号の説明

１６…ＨＤＤ、２２…ネットワークＩ／Ｆ、２４…ネットワーク、３２…Ｉ／ＯパスＩ／Ｆ、３４…Ｉ／Ｏパス、３６…ポート、４０…記憶装置、６０…仮想化スイッチ、７０…サーバ、９０…ＤＢＭＳ、１２０…管理サーバ、１４０…管理プログラム、１６０…管理エージェント

Claims (18)

1. サーバと、前記サーバに第1のパスを介して接続される仮想化スイッチと、前記仮想化スイッチに第2のパスを介して接続される記憶装置と、前記サーバと仮想化スイッチと記憶装置とにネットワークを介して接続される管理サーバとを有する計算機システムにおける計算機システム管理方法であって、
   前記管理サーバは、当該計算機システムの設定変更があった場合、該計算機システムの設定情報の履歴を取得して記録する構成履歴情報テーブルを有し、
   当該計算機システムの所定時刻への回復命令があった場合、前記構成履歴情報テーブルに記載された履歴情報のうちで指定された回復時刻に対応する第1の構成情報と、現時刻に対応する第2の構成情報とを比較し、両者が一致していない場合、前記第1の構成情報を前記サーバと仮想化スイッチと記憶装置のうちで設定の変更が必要な装置に送信し、
   前記サーバと仮想化スイッチと記憶装置のうちで前記第1の構成情報を受信した装置は、当該第1の構成情報に基づいて、設定を変更する、
   計算機システム管理方法。
2. 請求項１記載の計算機システム管理方法であって、
   前記記憶装置は、前記第1の構成情報に対応するデータを、前記第1の構成情報で指定される記憶装置に復元する、
   計算機システム管理方法。
3. 請求項１記載の計算機システム管理方法であって、
   前記管理サーバは、前記第1の構成情報で特定されるシステム構成を、物理的かつ論理的に復元、あるいは、論理的に復元、あるいは、論理的かつ部分的に復元する回復方法のうちでいずれかの回復方法を選択する、
   計算機システム管理方法。
4. 請求項３記載の計算機システム管理方法であって、
   前記管理サーバは、障害の種類あるいは現在の使用状況に応じて、前記回復方法を選択する、
   計算機システム管理方法。
5. 請求項４記載の計算機システム管理方法であって、
   前記管理サーバは、前記現在の使用状況に基づき、回復時の設定状況よりも現在の設定状況を優先させる場合、前記論理的に復元させる回復方法を選択する、
   計算機システム管理方法。
6. 請求項３記載の計算機システム管理方法であって、
   前記管理サーバは、前記第1の構成情報のうちで、ＬＵ構成、ＨＤＤの領域、仮想ボリューム、論理ボリューム、マウントポイント、キャッシュの設定を回復時の設定状況に復元できる場合に、前記物理的かつ論理的に復元する回復方法を選択する、
   計算機システム管理方法。
7. 請求項３記載の計算機システム管理方法であって、
   前記管理サーバは、前記第1の構成情報と第2の構成情報とを比較し、現時点及び回復時点における前記第1のパス及び前記第2のパスの設定が一致しているでパスの競合が発生している場合、現時点における前記第2のパスの設定を変更した後、現時点における前記第1のパスの設定を変更する、
   計算機システム管理方法。
8. 請求項７記載の計算機システム管理方法であって、
   前記管理サーバは、前記第1のパス、あるいは、前記第2のパスのうちで、設定の変更が必要なパスに接続されている、前記サーバと前記仮想化スイッチと前記記憶装置のいずれかに前記第1の構成情報を送信する、
   計算機システム管理方法。
9. 請求項３記載の計算機システム管理方法であって、
   前記論理的に復元、あるいは、論理的かつ部分的に復元する回復方法を選択した場合、前記記憶装置は、該論理的な復元を実行するのに十分な物理的な空き領域が存在するのを確認した後、当該論理的な復元を実行する、
   計算機システム管理方法。
10. 請求項３記載の計算機システム管理方法であって、
    前記管理サーバは、前記第1の構成情報のうちで、ＬＵ構成、ＨＤＤの領域、仮想ボリューム、論理ボリューム、マウントポイント、キャッシュの設定が回復時の設定状況に復元できる場合に、物理的かつ論理的に復元する回復方法を選択する、
    計算機システム管理方法。
11. ホスト計算機が記憶装置にアクセスする計算機システムにおける管理装置であって、
    前記ホスト計算機においてデータを使用するデータ使用部が前記記憶装置内のデータにアクセスするまでのアクセス環境に関わる構成であるシステム構成の変更履歴を表す構成履歴情報を記憶する構成履歴記憶部と、
    前記構成履歴情報を参照することにより過去の或る時点である回復時点でのシステム構成を特定し、現時点でのシステム構成を特定し、回復時点での前記システム構成と現時点での前記システム構成とを比較し、該比較の結果を基に、回復時点におけるデータを回復した場合に該回復されたデータにアクセスするための設定変更が必要となるシステム構成部分が現時点のシステム構成においてあるか否かを特定する設定変更要否特定部と、
    前記回復時点におけるデータを前記記憶装置に回復させるデータ回復部と、
    前記システム構成部分が特定された場合、該システム構成部分の設定変更を行える要素に対し、必要な設定変更に関する指示を出すことにより、前記回復されたデータに前記データ使用部がアクセスすることを可能にするシステム構成を構築させるシステム構成構築部と
    を備える管理装置。
12. 前記システム構成における或るシステム構成部分の設定変更が行われた場合、該設定変更が行われた日時を表す日時情報と、設定変更後のシステム構成部分を表す変更後情報とを取得し、該取得した日時情報及び変更後情報を前記構成履歴情報に追記する履歴情報更新部、
    を更に備える請求項１１記載の管理装置。
13. 前記回復時点におけるシステム構成と完全に同じシステム構成を回復する回復方法である完全回復と、該所定の業務で使用されない場合には、前記回復されたデータの複製である複製データを作成し該作成された複製データを使用するためのシステム構成を新規に構築する回復方法である複製回復とのいずれかを選択する回復方法選択部、
    を更に備え、
    回復方法として前記完全回復が選択された場合、前記設定変更要否特定部が、現時点のシステム構成における前記回復時点におけるシステム構成との違いを特定し、前記システム構成構築部が、該違いを前記回復時点のシステム構成に戻すための設定変更の指示を、該違いに関わる要素に送信し、
    回復方法として前記複製回復が選択された場合、前記データ回復部が、前記回復されたデータの複製データを作成し、前記システム構成構築部が、該作成された複製データを使用するためのシステム構成を新規に構築するべく、新規のシステム構成の各システム構成部分の設定を行える要素に対し、該新規のシステム構成の構築のための設定の指示を送信する、
    請求項１１記載の管理装置。
14. 前記回復方法選択部は、複数のデータから成るデータ群のうちの全てを回復する場合には、前記複製回復として完全複製回復を選択し、該データ群のうちの一部を回復する場合には、前記複製回復として一部複製回復を選択し、
    前記データ回復部は、前記完全複製回復が選択された場合、前記回復時点におけるデータ群の全てを複製し、前記一部複製回復が選択された場合、前記回復時点におけるデータ群のうちの一部を複製する、
    請求項１３記載の管理装置。
15. 前記データ回復部は、前記回復時点におけるデータの、前記記憶装置における第一の記憶領域に、別のデータが記憶されているならば、該別のデータを、前記記憶装置における第二の記憶領域に移動させ、それにより、前記第一の記憶領域を空き領域とし、空き領域となった前記第一の記憶領域に、前記回復時点におけるデータを回復する、
    請求項１１記載の管理装置。
16. 前記記憶装置が、或る時点におけるデータのイメージであるスナップショットを取得するスナップショット取得部と、データの更新の都度に該更新の履歴であるストレージジャーナルを作成し記憶するストレージジャーナル部とを有し、前記ホスト計算機が、データの更新の都度に該更新のログを作成し前記記憶装置に記憶させるログ作成部を有する場合において、
    前記データ回復部は、或る時点のスナップショットに対して一以上のストレージジャーナルを反映することで前記回復時点におけるデータを回復することを前記記憶装置に実行させ、前記一以上のストレージジャーナルのうちの少なくとも一つが無いが故に該データを回復できない場合には、前記ログを用いてデータを回復することを前記ホスト計算機に実行させる、
    請求項１１記載の管理装置。
17. 前記システム構成構築部は、前記ホスト計算機が前記ログにアクセスするためのシステム構成が構築されていない場合、該システム構成を構築するために必要なシステム構成部分の設定を行える要素に、該システム構成部分の設定を指示し、それにより、該システム構成を構築させ、前記ホスト計算機が前記ログを使用した後、前記システム構成を削除する、
    請求項１１記載の管理装置。
18. ホスト計算機が記憶装置にアクセスする計算機システムの管理方法であって、
    前記ホスト計算機においてデータを使用するデータ使用部が前記記憶装置内のデータにアクセスするまでのアクセス環境に関わる構成であるシステム構成の変更履歴を表す構成履歴情報を記憶し、
    前記構成履歴情報を参照することにより過去の或る時点である回復時点でのシステム構成を特定し、現時点でのシステム構成を特定し、回復時点での前記システム構成と現時点での前記システム構成とを比較し、該比較の結果を基に、回復時点におけるデータを回復した場合に該回復されたデータにアクセスするための設定変更が必要となるシステム構成部分が現時点のシステム構成においてあるか否かを特定し、
    前記回復時点におけるデータを前記記憶装置に回復させ、且つ、前記システム構成部分が特定された場合、該システム構成部分の設定変更を行える要素に対し、必要な設定変更に関する指示を出すことにより、前記回復されたデータに前記データ使用部がアクセスすることを可能にするシステム構成を構築させる、
    管理方法。

Images