JP4800046B2 - ストレージシステム - Google Patents

ストレージシステム Download PDF

Info

Publication number
JP4800046B2
JP4800046B2 JP2006021650A JP2006021650A JP4800046B2 JP 4800046 B2 JP4800046 B2 JP 4800046B2 JP 2006021650 A JP2006021650 A JP 2006021650A JP 2006021650 A JP2006021650 A JP 2006021650A JP 4800046 B2 JP4800046 B2 JP 4800046B2
Authority
JP
Japan
Prior art keywords
recovery point
recovery
storage system
journal
point
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006021650A
Other languages
English (en)
Other versions
JP2007206759A (ja
Inventor
彰 出口
賢哲 江口
健太 二瀬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2006021650A priority Critical patent/JP4800046B2/ja
Priority to US11/385,860 priority patent/US7571348B2/en
Priority to EP06253263A priority patent/EP1814032A3/en
Publication of JP2007206759A publication Critical patent/JP2007206759A/ja
Priority to US12/500,986 priority patent/US8327183B2/en
Application granted granted Critical
Publication of JP4800046B2 publication Critical patent/JP4800046B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Description

本発明は、データのバックアップおよびリカバリを行なうストレージシステムに関する。
企業情報システムのデータを格納するストレージシステムは、従来からデータ保護という役割を担っている。データ保護へのニーズなどから、ストレージシステムの分野では、企業情報システムを停止することなく、データのコピーであるレプリケーションを取得し、災害やオペレーションミスが発生した場合に瞬時にレプリケーションからデータを修復し、ある過去の運用状態に再形成（以下、この処理を「リカバリ」と呼ぶ）するためのスナップショット機能やジャーナル機能などが提案されている。
スナップショット機能は、ストレージシステムが、計算機からスナップショット指示を受領すると、その時刻の記憶領域のデータを別の記憶領域へコピーすることによって、レプリケーションを作成する機能である。定期的にスナップショット機能を実行することにより、データのレプリケーションを間欠的に取得しておくことが可能となる。スナップショット機能を用いた場合、ユーザは、スナップショットを取得したポイントにおいてリカバリを行なうことが可能となる。
ジャーナル機能は、ストレージシステムが計算機からライト要求を受領すると、ライトに関する制御情報やライトデータからなるジャーナルを作成し、保存する機能である。特許文献１には、スナップショット機能によって取得したスナップショットに、ジャーナル中のライトデータを書き込むことによって、スナップショットを作成したポイント以外のポイントにおいて実行されるリカバリ処理について開示されている。このように、ジャーナル機能とスナップショット機能を併用することで、少数のスナップショットから多数のポイントにおけるリカバリが可能となる。
特開2005-18738
特許文献１に開示された技術では、ストレージシステム内の記憶領域を使用する計算機からは検出できないような、当該ストレージシステムに関する制御情報や記憶領域内のデータについての状態変化等の現象（以下、「イベント」と呼ぶ）を契機として、リカバリの実行を可能とするポイントを作成することができない。そのため、ストレージシステムが検出するあるイベントの直前、または、直後のデータがユーザにとって有効な場合に、このポイントにおけるリカバリが実行できない。
ストレージシステムは、計算機（以下、「ホスト」と呼ぶ）が使用するデータを格納する第１の記憶領域と、第１の記憶領域に対する計算機からの更新がある場合に、更新されたデータとその更新履歴情報を格納する第２の記憶領域を有する。ストレージシステムは、自ストレージシステムを監視してイベントを検出し、イベントに基づいた時点を、後にリカバリを実行するための目標点（以下、「リカバリポイント」と呼ぶ）として決定し、その更新履歴情報を作成する。
ストレージシステムは、ホストから、あるリカバリポイントにおけるリカバリの指示を受けると、第１の記憶領域をある時点において複製した記憶領域に対して、第２の記憶領域に格納された更新データのうち、リカバリポイントまでの更新データを書き込む。作成された記憶領域が、このリカバリポイントにおける第１の記憶領域のデータを修復した記憶領域となる。
また、ストレージシステムは、リカバリポイントの中から任意のリカバリポイントを抽出して削除する。
ストレージシステムが検出するイベントを契機として、リカバリポイントを作成することができる。
以下、本発明の実施形態を実施例１から実施例５を例に挙げて説明する。なお、以下に説明する実施形態は一例であって、本発明はこれに限定されるものではない。
図１から図20を用いて、実施例１を説明する。
まず図１および図２を用いてシステム構成について説明し、図3を用いて本実施例の全体概要を説明する。続いて、図4および図5を用いて本実施例に用いるソフトウェア機能であるスナップショット機能およびジャーナル機能について説明する。次に、図6を用いてホストからのライト要求に応じたジャーナルの作成処理について説明する。次に、図7から図9を用いて、ホストからの要求に応じたリカバリポイント作成処理について説明し、図10を用いて、ユーザの要求によるリカバリ処理について説明する。さらに、図11から図20を用いて、ストレージが検出するイベントに応じたリカバリポイント作成処理やリカバリポイントの削除について説明する。
図1および図2に、本実施形態に係るシステムの全体構成の一例を示す。システムは、ネットワーク160によって接続されるホスト100とストレージシステム200から成る。特に、図1がホスト100の構成の詳細を示す図であり、図2がストレージシステム200の構成の詳細を示す図である。
まず、図1を参照し、ホスト100の構成の詳細を説明する。ホスト100は、アプリケーション150やデータベース管理システム（以後、「DBMS」と呼ぶ）などのソフトウェアを実行することで、業務処理を行なう装置である。そして、ホスト100で実行する業務処理に用いられるデータの一部、または全てを、ネットワーク160を介して接続されるストレージシステム200に格納している。
ホスト100は、インタフェース(以下、「I/F」と略す)130、メモリ110、プロセッサ120を有している。I/F130は、ホスト100がストレージシステム200に格納しているデータに対するリードやライトを要求するためのインタフェースである。I/F130はネットワーク140によってプロセッサ120と接続されている。ホスト100はI/F130を複数個有してもよい。また、I/F130として、例えばFC（Fibre Channel）やiSCSIなどが考えられるが、上記用途を満たすインタフェースであればこれ以外でもよい。
メモリ110には、OS(Operating System)170、ミドルウェア160、アプリケーション150、管理ソフト180などのソフトウェアが記憶されている。これらのソフトウェアは、ネットワーク140を介してメモリ110と接続されているプロセッサ120が、メモリ110から読み出し実行する。本実施形態に係るデータのバックアップやリカバリを行なうためのプログラム、及び、管理情報は、管理ソフト180に格納される。管理ソフト180に含まれるプログラムの動作内容などの詳細については、後述する。
次に、図2を参照し、ストレージシステム200の構成の詳細を説明する。ストレージシステム200は、上述したようにホスト100が実行する業務処理に用いられるデータを格納するための装置である。ストレージシステム200は、大きく分けてI/F210、キャッシュ260、メモリ220、プロセッサ250、ディスクコントローラ270、ボリューム280から成る。
I/F210は、ホスト100からのライトやリードを受けるためのインタフェースである。I/F210は、ネットワーク290によって、メモリ220、プロセッサ250、キャッシュ260と接続されている。ストレージシステム200は、このI/F210を複数個有してもよい。また、I/F210として、例えばFCやiSCSIなどが考えられるが、上記用途を満たすインタフェースであればこれ以外であってもよい。
ボリューム280には、ホスト100が使用するデータが格納される。ボリューム280は磁気ディスク装置、磁気メモリ、光ディスクなどの物理的な記憶装置であってもよいし、RAID(Redundant Arrays of Inexpensive Disks)のような方法によって一つ以上の物理的な記憶装置から成る論理的な記憶領域であってもよい。ボリューム280は、ネットワーク290によってディスクコントローラ270に接続されている。
ボリューム280へのライトやリードといった処理は、プロセッサ250がネットワーク290を介して接続されているディスクコントローラ270に対してリードやライトを指示することによって行なう。
キャッシュ260は、ボリューム280に比べて高速な記憶媒体である。ボリューム280に格納される使用頻度の高いデータなどを、キャッシュ260に格納することにより、常に全てのデータをボリューム280に格納する場合に比べて、ホスト100からのリードやライトなどの処理の高速化を図ることができる。また、キャッシュ260は、I/F210、プロセッサ250、ディスクコントローラ270とネットワーク290によって接続されている。
メモリ220には、制御部230、制御情報部240などのプログラムが格納されている。制御部230には、ストレージシステム200が提供する機能を実現するためのプログラムが記録されている。そして、制御情報部240には、これらプログラムが利用する管理情報が記録されている。これらメモリに格納されたプログラム及びプログラムが利用する管理情報は、プロセッサ250がメモリ220から読み出し処理する。制御部230、制御情報部240のプログラムおよび管理情報の詳細は後述する。また、メモリ220はネットワーク290によってI/F210、プロセッサ250と接続されている。なお、プロセッサ250やキャッシュ260は、障害発生時におけるデータ消失などを避けるため、二重化してもよい。
なお、ストレージシステム200は、メモリ220、プロセッサ250、キャッシュ260、I/F210、ディスクコントローラ270などに電力を供給する電源部（図示しない）を有するものとする。また、上述した電源部、メモリ220、キャッシュ260、I/F210、ディスクコントローラ270などは、それぞれ内部に制御情報を送受信するプロセッサや、制御情報を記憶するメモリを有しても良い。
なお、ホスト100、ストレージシステム200が有するメモリ110、220などのメモリは、RAM（Random Access Memory）などにより構成されてもよい。また、ホスト100、ストレージシステム200が有するプロセッサ120、250などのプロセッサは、CPU（Central Processing Unit）によって構成される演算処理装置であってもよい。
なお、上述した制御部230、制御情報部240などの機能モジュールは、上述したようにソフトウェアにより実現されてもよいし、任意のCPUや他のＬＳＩ(Large Scale Integration)などによりハードウェアとして、さらにそれらの組み合わせとして実現されてもよい。また、上記のように構成可能であることは、ホスト100に含まれる管理ソフト180などの、他の構成部内における機能モジュールにおいても同様である。
続いて、図3を用いて本実施例におけるスナップショット機能、ジャーナル機能、およびリカバリポイントを用いたバックアップ方法について模式的に述べ、本実施例の基本概要を説明する。
図3中の矢印310は、ジャーナルが格納されるボリューム（以下、「ジャーナルボリューム」と呼ぶ）の内容を時系列で示しており、矢印320はスナップショット取得状況を時系列に示している。
矢印310に重ねて示しているブロック330、340、および350は、ジャーナルを示しており、一つのブロックが一つのジャーナルに対応する。ブロック330の中に示している「JNL」は、あるボリュームに対して、その時点でホスト100からのライト要求に対して作成したジャーナルであることを意味する。ブロック340の中に示している「SS」は、その時点で、あるボリュームに対するスナップショットを取得した場合に、スナップショットに関する情報として、当該ボリュームの識別情報などを格納する特殊なジャーナル（以下、「スナップショットジャーナル」と呼ぶ）であることを意味する。ブロック350の中に示している「RP」は、その時点で、あるボリュームに対するリカバリポイントを取得した場合に、リカバリポイントの情報として、当該ボリュームの識別情報などを格納する特殊なジャーナル（以下、「リカバリポイントジャーナル」と呼ぶ）であることを意味する。
ジャーナル、スナップショットジャーナル、リカバリポイントジャーナルに格納される情報の詳細については、図５を用いて後述する。
また、図3中の各ブロックにおいて、「SS」、「JNL」、「RP」の前に示す数字は、それぞれのジャーナルに付与された連続番号であるシーケンス番号（以下、「SEQ#」と略す）の値を示す。ホスト100およびストレージシステム200は、SEQ#によって、各ジャーナルを一意に識別することが可能となる。
次に、図3中の矢印320に重ねて示しているボリューム360、370および380について説明する。ボリューム360および380は、それぞれ、そのポイントにおいて、あるボリュームに対するスナップショットを取得済みであり、このボリュームのデータイメージを再形成できることを意味している。つまり、ボリューム360は、SEQ#が1のスナップショットジャーナルに対応してスナップショットが取得され、作成されるボリュームであり、ボリューム380はSEQ#が6のスナップショットジャーナルに対応してスナップショットが取得され、作成されるボリュームであることを意味する。
そして、矢印320に重ねて示しているボリューム370は、そのポイントでのリカバリ処理に備えてリカバリポイントを取得済みであり、リカバリ処理においてこのボリュームのデータイメージを再形成できることを意味している。つまり、ボリューム370は、SEQ#が4のリカバリポイントジャーナルに対応して、そのポイントでデータを復元する場合に作成されるボリュームである。ユーザなどからリカバリ処理の要求を受けた場合、当該リカバリポイントのデータは、ボリューム360が示すスナップショットボリュームに対してSEQ#が2および3のジャーナル中のライトデータを順次書き込むことによって、生成される。
ここで、図4を用いてスナップショット機能の詳細について説明する。スナップショット機能は前述のように、ストレージシステム200が、ストレージシステム200内のあるボリューム280(以下、「ソースボリューム」と呼ぶ)に含まれるデータを別のボリューム280(以下、「スナップショットボリューム」と呼ぶ)へコピーすることによって、ソースボリュームのある時刻のレプリケーションを作成する機能である。このレプリケーションのことを単にスナップショットと呼ぶこともある。
図4に示すスナップショット作成に関する概念図を用いて、スナップショット作成の動作を簡単に説明する。ホスト100は、ストレージシステム200にスナップショット作成要求を行なうためのスナップショット指示プログラム181と、取得したスナップショットの情報を管理するためのスナップショット管理表185を有する。そして、ストレージシステム200は、スナップショットを作成するためのスナップショット作成プログラム232と、作成したスナップショット情報を管理するためのスナップショット管理表241を有する。
スナップショットを取得する動作について説明する。ホスト100のスナップショット指示プログラム181がストレージシステム200のスナップショット作成プログラム232に、スナップショット作成要求を発行する。このとき、ホスト100は、ボリューム280の中からソースボリューム400と、コピー対象となるスナップショットボリューム410を指定する。スナップショット作成要求を受領したスナップショット作成プログラム232は、ソースボリューム400の先頭アドレスからソースボリューム400の末尾に向かって順次データを読み出し、スナップショットボリューム410に書き込む。ボリュームの末尾までのコピーが完了するとスナップショット作成完了となる。
ただし、上記の動作によって、ある時刻のボリューム280のスナップショットを作成するためには、ホスト100からのソースボリューム400へのライトを一旦停止してスナップショットを取得する必要がある。これを回避して、ホスト100からのライト要求を受領しながらスナップショットを作成する方法を述べる。これを実現するために、ストレージシステム200はコピー済みビットマップ（図示しない）を有する。このコピー済みビットマップとは、ソースボリューム400内のアドレスごとに、当該アドレスに格納されているデータがスナップショットボリューム410にコピー済みか否かを示す情報である。ここでは、あるアドレスのコピー済みビットマップの値が「OFF」の場合はコピー済み、「ON」の場合は未コピーを表すものとする。
スナップショット作成プログラム232がスナップショット作成要求を受領するとコピー済みビットマップの内容を全て「ON」とする。次に、スナップショット作成プログラム232は、ソースボリューム400からスナップショットボリューム410へデータをコピーするとき、コピーが完了したアドレスに対するコピー済みビットマップの値を「OFF」へと変更する。さらに、ホスト100からライト要求を受領したときにも、コピー済みビットマップを参照し、ライトアドレスに対するコピー済みビットマップの値が「ON」であれば、その時点でソースボリューム400からスナップショットボリューム410へとライトアドレスのデータをコピーし、コピー済みビットマップを「OFF」へ変更する。そのコピー完了後、ホスト100からのライトデータをソースボリューム400に書き込む。
これによって、ホスト100からのライトを受領しつつ、ストレージシステム200のスナップショット作成プログラム232がスナップショット作成要求を受領した時刻におけるボリューム280のスナップショットを作成することができる。
また、上記の説明では、ホスト100からのスナップショット作成要求に基づきスナップショット作成するとしたが、ストレージシステム200内の別のプログラムからのスナップショット作成要求に基づきスナップショットを作成することも可能である。
また、コピー済みビットマップは、スナップショットボリューム410の情報として有してもよい。一つのソースボリューム400から複数のスナップショットボリューム410を作成する場合、コピー済みビットマップをそれぞれのスナップショットが保持することで、コピー済みビットマップの管理を単純化できる。
なお、図示しないが、ホスト100およびストレージシステム200が有するスナップショット管理表185および241は、属性としてスナップショットを一意に識別するための識別番号であるスナップショット番号、前述したジャーナルのSEQ#(シーケンス番号)、ソースボリューム400を一意に識別するためのソースボリューム番号、スナップショットボリューム410を識別するためのスナップショットボリューム番号などを有する。
次に、ジャーナル機能の詳細について説明する。スナップショット機能を用いると、スナップショットを作成したポイントのデータのみをリカバリできるが、ジャーナル機能をスナップショット機能と併用することで、少数のスナップショットから多数のポイントのデータをリカバリすることができる。以下に、実現方法の概要を述べる。ストレージシステム200は、ホスト100からライト要求を受領すると、ジャーナル機能によって、ライトに関する制御情報(時刻やライトアドレスなど)とライトデータからなるジャーナルを作成し、記憶しておく。そして、データをリカバリする際には、スナップショットに対してジャーナル中のライトデータを書き込むことで(以後、スナップショットにジャーナルを適用すると表現する)、スナップショットを作成したポイント以外のデータのリカバリも行なう。
さらに、例えばホスト100が有する管理ソフト180によって、ホスト100が有するアプリケーションにエラーが検出された場合や、ユーザがホスト100に対して、特定のリカバリポイントを作成するように指示する場合がある。このように、ホスト100からのストレージシステム200に対するライト要求以外のポイントにおいて、ホスト100がストレージシステム200に対してリカバリポイントの取得を要求する場合について、説明する。（詳細については、図７を用いて後述する。）
まず、ホスト100はストレージシステム200に対して、リカバリポイント作成要求を発行する。そして、ストレージシステム200が当該指示に基づき、リカバリポイントを管理し、当該リカバリポイントへのリカバリを制御する。
ストレージシステム200は、図3において説明したように、ライト要求に対応するジャーナル、スナップショット作成要求を受領したポイントにおいて作成したスナップショットジャーナル、リカバリポイント作成要求を受領したポイントにおいて作成したリカバリポイントジャーナルに対してシーケンシャルな番号（SEQ#）を付与する。 以上の処理によって、例えば、スナップショットは、10時、11時のように1時間おきにしか取得しないが、10時30分にリカバリポイントを作成しておけば、10時に取得しておいたスナップショットボリュームに対して、10時のスナップショットジャーナルの直後のジャーナル(SEQ#が次のジャーナル）から10時30分のリカバリポイントジャーナルの直前のジャーナルまでを適用することで10時30分のボリューム280のデータをリカバリすることが可能となる。
ジャーナル機能によるリカバリのため、ホスト100およびストレージシステム200は次のプログラムおよび管理情報を有する。ホスト100は、ストレージシステム200に対してリカバリポイントの作成要求を発行するためのリカバリポイント指示プログラム182、作成したリカバリポイントを管理するためのリカバリポイント管理表186、そして、あるリカバリポイントのデータリカバリを要求するためのリカバリ指示プログラム187を有する。ストレージシステム200は、ライトに対してジャーナル、リカバリポイント作成要求に対してリカバリポイントジャーナル、スナップショット作成要求に対してスナップショットジャーナルを作成するためのジャーナル作成プログラム233、ジャーナルが持つシーケンシャルな番号を管理しているSEQ#情報243、ストレージシステム200が作成したリカバリポイントを管理するためのリカバリポイント管理表242、ホスト100からのリカバリ要求に基づきリカバリ処理を実行するリカバリプログラム237、ボリューム280のうち、上述したジャーナルを格納するための領域としてジャーナルボリュームを有する。ジャーナルボリュームは、ホスト100が利用するデータを格納する通常のボリューム280と同等のものである。
次に、図5を用いて、ジャーナルのフォーマットに関して説明する。上述のようにジャーナルにはライト要求に対するジャーナル、スナップショット作成要求に対するスナップショットジャーナル、リカバリポイント作成要求に対するリカバリポイントジャーナルの3種類があるが、フォーマットは同様である。図5にジャーナルフォーマットの一例を示す。図5（a）に示すように、ジャーナル500の属性として、SEQ#501、時刻502、種別503、データ504、ボリューム番号505、アドレス506、データ長507が格納される。
SEQ#501には、ライトに対応するジャーナル、スナップショットジャーナル、リカバリポイントジャーナルに対して一意に付与される連続番号であるシーケンス番号が格納される。
時刻502には、それぞれのジャーナルに対して、ストレージシステム200がライト要求に対応するライトデータを更新した時刻情報、ストレージシステム200がスナップショットを取得した時刻情報、ストレージシステム200がリカバリポイントを作成した時刻情報が格納される。
種別503には、ジャーナル、スナップショットジャーナル、リカバリポイントジャーナルのいずれであるかを識別するための情報が格納される。
ボリューム番号505には、それぞれのジャーナルに対して、ライト要求の対象となるデータボリュームであるボリュームの識別情報、スナップショットを作成する対象のソースボリュームであるボリュームの識別情報、リカバリポイントを作成する対象のボリュームの識別情報が格納される。
データ504、アドレス506、データ長507には、ライト要求に対応するジャーナルを作成する場合、それぞれ、ライト要求によって更新されたライトデータ、データボリュームにおけるライトデータのアドレス情報、ライトデータのデータ長が格納される。なお、種別503がスナップショットジャーナル、リカバリポイントジャーナルの場合には、データ504、アドレス506、およびデータ長507には何も格納しない。
ジャーナルフォーマットには、上記の属性以外にも、例えば、スナップショットジャーナルに対してコピー先のスナップショットボリュームの識別情報を付与しても良い。
図5（ｂ）（ｃ）（ｄ）に、ライト要求に対するジャーナル510、スナップショットジャーナル520、リカバリポイントジャーナル530の具体例を示す。例えば、図5（ｃ）のジャーナル520は、SEQ#501が100のスナップショットジャーナルであり、2005/10/21 14:50:46の時刻において、ボリューム番号505が2であるボリューム2に対して、スナップショットを取得したことを示している。
これらのジャーナルは、ジャーナル作成プログラム233が作成し、ジャーナルボリュームに格納される。
図6に、ストレージシステム200がホスト100からライトを受領し、ジャーナルを作成する処理の一例を示す。この処理は、ホスト100のプロセッサ120が、ホスト100上でライトを発行するOS170などのプログラムを実行し、ストレージシステム200のプロセッサ250が、ストレージシステム200のライトデータ受領プログラム231とジャーナル作成プログラム233を実行することで行なわれる。
ホスト100上のOS170がストレージシステム200に対してライトを発行する(S100)。ストレージシステム200のライトデータ受領プログラム231がこのライトを受領すると、ライト対象のボリューム280に対してライトデータを書き込む(S101)。続いて、ジャーナル作成プログラム233を呼び出す（S102）。呼び出されたジャーナル作成プログラム233は、SEQ#情報243からSEQ#を取得する。後続のジャーナル作成のためにSEQ#を用意しておくため、ジャーナル作成プログラム233は、取得したSEQ#に1を加えてSEQ#情報243を更新する(S103)。
続いて、ジャーナル作成プログラム233は、取得したSEQ#やライトデータからジャーナルを作成しジャーナルボリュームに格納する(S104）。最後に、呼び出し元のライトデータ受領プログラム231へ完了報告する(S105）。完了報告を受領したライトデータ受領プログラム231はホスト100に対してライトの完了を報告する(S106)。
ここで、本実施例は、ストレージシステム200がホスト100からの指示に基づいてリカバリポイントジャーナルを作成する第１の場合と、ストレージシステム200がホスト100からの指示を伴わずにリカバリポイントを作成する第２の場合とに大きく分かれる。
まず、図7から図9を用いて、本実施例において、ホスト100からの指示に基づいて、リカバリポイントジャーナルを作成する処理について説明する。
図7に、ストレージシステム200が、ホスト100からリカバリポイント作成要求を受領し、リカバリポイントジャーナルを作成する処理の一例を示す。この処理は、ホスト100のプロセッサ120がリカバリポイント指示プログラム182を実行し、ストレージシステム200のプロセッサ250がジャーナル作成プログラム233を実行することで行なわれる。
リカバリポイント指示プログラム182が、ジャーナル作成プログラム233に対してリカバリポイント作成の要求を発行する(S200)。このとき、パラメータとしてリカバリポイント作成の対象とするボリューム番号と、リカバリポイントを一意に識別するための識別番号としてリカバリポイントＩＤ（以下、「RPID」と略す）をジャーナル作成プログラム233へ渡す。
リカバリポイント作成要求を受領したジャーナル作成プログラム233は、ステップS103と同様にSEQ#情報243からSEQ#を取得し、後続のライトのためにSEQ#情報243を更新する(S201)。続いて、取得したSEQ#を含むリカバリポイントジャーナルを作成し、ジャーナルボリュームに格納する(S202)。最後に、リカバリポイント管理表242にステップS202で作成したリカバリポイント情報を追加するとともに(S203)、リカバリポイント指示プログラム182に完了を報告する(S204)。S203において、ストレージシステム200のリカバリポイント管理表242に登録する値は、ステップS202で割当てたSEQ#と、ホストからパラメータとして受領したRPIDである。
完了報告を受領したリカバリポイント指示プログラム182は、ホスト100上のリカバリポイント管理表186にリカバリポイント情報を追加(S205)して処理を終了する(S206)。
図8に、ストレージシステム200が管理するリカバリポイント管理表242の一例を示す。リカバリポイント管理表242には、リカバリポイントの属性として、RPID801とSEQ#802が格納される。RPID801には、図7のS203において前述したように、ホスト100から受領したリカバリポイントの識別番号が格納される。そして、SEQ#802には、当該リカバリポイントに対するリカバリポイントジャーナルが有するSEQ#が格納される。このSEQ#802によって当該リカバリポイントジャーナルを一意に識別することが可能となる。
図9に、ホスト100が管理するリカバリポイント管理表186の一例を示す。リカバリポイント管理表186には、リカバリポイントの属性としてRPID901、取得時刻902、ボリューム番号903、種別904、イベント905が格納される。RPID901は、リカバリポイント指示プログラム182が図7のS200においてリカバリポイント作成要求時にパラメータとして渡す値である。取得時刻902は、ホスト100がリカバリポイント作成要求を発行した時刻情報を示す値である。ボリューム番号903は、リカバリポイント作成対象のボリューム280がどのボリューム280であるかを示す情報である。そして、種別904には、このリカバリポイントが、管理ソフト180によって自動取得されたものか、ユーザが指示して取得されたものかを示す情報が格納される。イベント905には、管理ソフト180がリカバリポイントを自動取得した場合に、ホストに生じたどのイベントを契機としてリカバリポイント作成要求を発行したかを示す情報が格納される。
続いて、図10を用いて、リカバリポイントを用いたリカバリ処理について説明する。
図10に、ユーザが指定したリカバリポイントのデータをリカバリする処理の一例を示す。この処理は、ホスト100のプロセッサ120がリカバリ指示プログラム187をメモリ110に読み出して実行し、ストレージシステム200のプロセッサ250がリカバリプログラム237をメモリ220に読み出して実行することで行なわれる。
リカバリ指示プログラム187が、ストレージシステム200におけるリカバリ処理の指示を、リカバリプログラム237に対して発行する。このとき、リカバリ指示プログラム187は、RPID901、およびリカバリ先ボリューム番号を指定する。リカバリ先ボリュームとは、リカバリするデータを格納するためのボリューム280である(S300)。リカバリ要求を受領したリカバリプログラム237は、指定されたRPIDが示すリカバリポイントに対応するリカバリポイントジャーナルのSEQ#802を探す。この処理は、ホスト100が指定したRPID901を元にリカバリポイント管理表242を参照し、RPID801、およびRPID801に該当するリカバリポイントのリカバリポイントジャーナルのSEQ#802の値を得ることで実現する(S301)。
続いて、リカバリプログラム237は、ストレージシステム200のスナップショット管理表241を参照し、前ステップで得たSEQ#の値よりも古いSEQ#を持つスナップショットを探す(S302)。そして、当該スナップショットに対応するスナップショットボリュームに格納されているデータを、リカバリ先ボリュームへコピーする(S303)。最後に、ステップS302で検出したスナップショットジャーナルのSEQ#からステップS301で検出したリカバリポイントジャーナルのSEQ#までの間に存在するジャーナルを、SEQ#順にリカバリ先ボリュームへ適用し(S304)、リカバリ指示プログラム187に完了を報告する(S305)。
以上の処理によって、ユーザが指定したリカバリポイントのデータをリカバリ先ボリュームへリカバリする。
次に、図11から図16を用いて、本実施例において、ストレージシステム200がホスト100からの指示を伴わずにリカバリポイントを作成する第２の場合について説明する。まず、リカバリポイントの割当て方について、図11および図12を用いて説明する。
ストレージシステム200は、ホスト100からの指示に伴わずに作成するリカバリポイントに割当てるためのリカバリポイントの識別番号（RPID）を決定する。これを実現するために、ストレージシステム200は、制御情報部240にRPID情報244を有する。RPID情報244は、ストレージシステム200において未使用のRPIDを格納している。また、単にRPID情報244として一つの数字を管理しており、リカバリポイントにRPIDを割当てる際に、管理する値に1インクリメントすることによっても、RPIDを管理することが可能である。
ホスト100とストレージシステム200でRPIDを一元的に割当てる方法として、図11に示すように、ホスト100からの指示を契機とするリカバリポイント、及び、ホスト100の指示を伴わずストレージシステム200が自動的に作成するリカバリポイントの両方に、ストレージシステム200がRPID情報244からRPIDを割当てる方法がある。
ホスト100からストレージシステム200にリカバリポイント作成要求を発行する場合、リカバリポイント指示プログラム182は、図7のS200においてパラメータとしてRPID901を渡す必要はない。ジャーナル作成プログラム233は、S201の直前でRPID情報244からRPID801を取得し、割当てる。最後に、図7のS204でリカバリポイント作成完了を報告するときに、ジャーナル作成プログラム233が割当てたRPID801をリカバリポイント指示プログラム182へ通知するものとする。
図11に、ストレージシステム200が管理するリカバリポイント管理表242の一例を示す。
図11に示すリカバリポイント管理表242は、図8に示すリカバリポイント管理表242の属性であるRPID801およびSEQ#802に加え、属性として、取得時刻1101、ボリューム番号1102、イベント1103を有する。
取得時刻1101には、ストレージシステム200が検出したイベント、またはホストからの指示に基づいてリカバリポイントジャーナルを作成した時刻を格納する。
ボリューム番号1102は、リカバリポイント作成対象のボリューム280がどのボリューム280であるかを示す情報である。
イベント1103には、ストレージシステム200において生じたどのイベントを契機としてリカバリポイントを作成したかを示す情報が格納される。また、ホスト100からの指示に基づいてリカバリポイントを作成する場合は、ホスト指示による作成であることを示す識別情報が格納される。
これらの情報を持つことによって、ストレージシステム200は、ホスト100に対して、ストレージシステム200において、いつ、どのイベントを契機として、どのボリューム280のリカバリポイントを作成したかという情報を提供できるようになる。
また、上述した方法以外にも、ホスト100とストレージシステム200はそれぞれ別のRPIDを割り当て、区別して管理した後、リカバリ処理の際に双方のSEQ#から判断する方式でもよい。
図12を用いて、ストレージシステム200が、RPIDにプレフィックスを付与して管理する方法について説明する。
ホスト100は、ホスト100によって管理するRPID901を指定し、ストレージシステム200にリカバリポイント作成要求を発行する。このとき、ストレージシステム200がホスト指示を伴わずに作成するリカバリポイントのRPIDと衝突が起こらないように、ホスト指示を伴わずに作成するリカバリポイントのRPID1202にはプレフィックスを付与するものとする。
ストレージシステム200は、例えば、図12（a）に示す表1200及び図12（ｂ）に示す表1210の二つの表によってリカバリポイントを管理する。図12（a）に示す表1200は、図8に示したストレージシステム200が管理するリカバリポイント管理表242同等のものであり、ホスト100からの指示によって作成したリカバリポイントを管理している。そして、図12（ｂ）に示す表1210によって、ストレージシステム200がホスト100からの指示を伴わずに作成したリカバリポイントを管理する。表1210におけるRPID1202は、番号の前に「S」と付与することによって表1200におけるRPID801と区別する。この区別は、「S」を付けるのではなく、割当てる数字を表1200と表1210の間で予め分けておくことによっても実現できる。
図12（ｂ）に示す表1210は、図11と同様に、属性として、取得時刻1101、ボリューム番号1102、イベント1103を有する。
さらに、図12（ｃ）に示す表1220によって、リカバリポイントを管理する方法もある。図12（ｃ）に示す表1220は、RPID1202により、前述した図12（a）に示す表1200と図12（ｂ）に示す表1210をマージしたものになっている。図12（a）に示す表1200には、取得時刻1101、ボリューム番号1102、イベントの属性1103はないが、ストレージシステム200がホスト100からリカバリポイント作成要求を受領した際に、当該情報を作成してもよい。
なお、ホスト100がストレージシステム200から、ストレージシステム200がホスト100の指示を伴わずに作成したリカバリポイントを、ストレージシステム200から収集したときに、当該リカバリポイントに対してホスト100が新たにRPID901を付け直してもよい。この場合には、ホスト100は、RPID901を付け直したことをストレージシステム200へ通知し、ストレージシステム200のリカバリポイント管理表242でもRPID801を修正するものとする。
以降に説明する実施内容では、図11に示すように、ストレージシステム200が全てのRPID801を管理する方式に基づいて説明する。
続いて、図13から図16を用いて、ストレージシステム200がホスト100からの指示を伴わずにリカバリポイントを作成する第２の場合において、ストレージシステム200がイベントを検出する方法について説明する。イベントの検出は、イベントの種類によって異なるため、以下にはボリューム障害によるライト失敗、ホストから受領したコマンドの実行前後、ストレージシステム200の構成変更、状態監視プログラムによるポーリングの四つパターンの契機によるイベント検出方法を示す。ただし、本発明は以下に示すイベント検出方法およびイベントに限定されない。
第1のパターンとして、図13に、ライトデータ受領プログラム231がホスト100から受領したライトデータをボリューム280に書き込む際に、ボリューム280の障害というイベントを検出し、リカバリポイントを作成する処理の一例を示す。この処理は、ホスト100上でライトを発行するOS170などのプログラムから信号を受信したストレージシステム200のプロセッサ250が、ライトデータ受領プログラム231およびジャーナル作成プログラム233をメモリ220に読み出して実行する。
ホスト100上のOS170がストレージシステム200に対してライトを発行する(S400)。ストレージシステム200のライトデータ受領プログラム231がライトデータをボリューム280に書き込む際に、書き込み失敗などを要因としてボリューム280の障害を検出する(S401)。ライトデータ受領プログラム231は、リカバリポイントジャーナルを作成するために、ジャーナル作成プログラム233を呼び出す(S402)。
呼び出されたジャーナル作成プログラム233は、作成するリカバリポイントに割当てるためのRPID801をRPID情報244から取得する。次に、ステップS103同様に、SEQ#802を取得し、後続のジャーナル作成のためにSEQ#情報243を更新する(S404)。続いて、取得したSEQ#802を含むリカバリポイントジャーナルを作成し、ジャーナルボリュームに格納する(S405)。最後に、リカバリポイント管理表242にリカバリポイント情報を追加するとともに(S406)、ライトデータ受領プログラム231に完了報告をする(S407)。完了報告を受領したライトデータ受領プログラム231はホスト100に対してライト失敗を報告する(S408)。
第2のパターンとして、図14に、ライトデータ受領プログラム231がホスト100からコマンドを受領したことを契機として、当該コマンドを実行する前に、リカバリポイントを作成する処理の一例を示す。この例は、先に示したパターン1とほぼ同様の動作を行なうため、異なる部分のみを説明する。
ホスト100上のOS170がストレージシステム200に対してコマンドを発行する(S500)。ストレージシステム200のライトデータ受領プログラム231がコマンドを受領すると(S501)、ジャーナル作成プログラム233を呼び出し(S502)、リカバリポイントを作成する。ジャーナル作成プログラム233によるリカバリポイント作成の処理内容（S403〜S407）は、上述した第１のパターンと同様である。ジャーナル作成プログラム233からリカバリポイント作成の完了報告を受信後、ライトデータ受領プログラム231は、リカバリポイント作成後に関数を呼び出すなどによりコマンドを実行する(S503)。最後に、ホスト100に完了を報告する(S504)。
この第２のパターンでは、特定のコマンドに対してのみリカバリポイントを作成するなど、S501においてコマンドを選出する処理を行ってもよい。たとえば、ボリューム280の中身を完全に消去するようなコマンドを受領した場合にはリカバリポイントを作成してから実行する。このようにコマンド受領を契機とすることで、コマンドがユーザのオペレーションミスであった場合にも、コマンドを実行する直前のボリューム280のデータをリカバリすることが可能となる。
第3のパターンとして、図15に、ボリューム管理プログラム238が、あるボリュームに対するオフライン化の指示を操作パネルや保守用管理端末などから受領したことを契機に、オフライン処理中において、リカバリポイントを作成する処理の一例を示す。この処理は、ストレージシステム200のプロセッサ250が、ボリューム管理プログラム238およびジャーナル作成プログラム233をメモリ220に読み出して実行する。
ボリューム管理プログラム238が、ストレージシステム200の操作パネルや保守用管理端末を介してボリューム280のオフライン化指示を受領する(S600)。次に、ボリューム管理プログラム238は、オフライン化対象のボリューム280をオフラインにする(S601)。この時点で、ホスト100からオフライン化対象のボリューム280にはライトが発行されなくなる。そして、ボリューム管理プログラム238は、リカバリポイントの作成が完了するまで、対象ボリューム280が再びオンラインにならないように、オンライン化の拒否を開始する(S602)。次に、ボリューム管理プログラム238は、ジャーナル作成プログラム233を呼び出す(S603)。ジャーナル作成プログラム233によるリカバリポイント作成の処理内容（S403〜S407）は、第１のパターン1と同様である。リカバリポイント作成完了後、ボリューム管理プログラム238は、S602で開始した対象ボリューム280のオンライン化の拒否を解除し(S604)、処理を終了する(S605)。
この第３のパターンでは、ストレージシステム200に付随する操作パネルや保守用管理端末などから、オフライン処理において、ストレージシステム200自体の構成を変更する場合などに、ホスト100からの指示を契機とせずにリカバリポイントを作成できる。このように、オフライン化を契機とすることによって、次にホスト100がオンライン接続してシステム構成の変更を認識する前に障害が発生するような場合にも、リカバリポイントを作成しておくことができる。
第4のパターンとして、図16に、ポーリングによりストレージシステム200のイベントを検出したことを契機に、リカバリポイントを作成する処理の一例を示す。この処理は、ストレージシステム200のプロセッサ250が、状態監視プログラム234とジャーナル作成プログラム233をメモリ220に読み出して実行することで行なわれる。
状態監視プログラム234は、ポーリングによって任意の契機で、監視対象部位を管理するプログラムの呼び出しや、管理対象部位の管理情報の参照を実行する(S700)。その結果、何らかのイベント（イベントは部位によって異なる。イベントの例については後述する。）が発生しているか否かをチェックする(S701)。状態監視プログラム234は、イベントが発生していると判断した場合には、ジャーナル作成プログラム233を呼び出して、イベントが発生しているボリューム280の識別情報を渡す(S702)。ジャーナル作成プログラム233によるリカバリポイント作成の処理内容（S403〜S406）は、第１のパターンと同様である。また、イベントが発生していない場合、または、ジャーナル作成プログラム233を呼び出した後は、状態監視プログラム234は、再びS700へ戻りストレージシステム200の監視を行なう。
以上の方法によって、ストレージシステム200が検出するイベントに基づくリカバリポイントの作成が実現できる。なお、イベントの例として、以下のようなものが挙げられる。なお、本発明は以下に示すイベントに限定されない。
S701で検出されるイベントの例には、監視対象部位が電源部である場合、ストレージシステム200の電源停止、電源投入、電源障害、電源障害によるバッテリー動作開始などが挙げられる。
また、監視対象が記憶領域である場合、S701で検出されるイベントの例には、状態監視プログラム234で検出されるような、ボリューム280の属性変更（ボリュームオフライン化、レプリケーション機能のペア状態遷移を含む）、障害検出（2重化されているシステムの片側障害も含む）などが挙げられる。
また、監視対象部位が、インタフェース部である場合、S701で検出されるイベントの例には、ライトデータ受領プログラム231で検出されるような、ホスト100からのコマンド、ホスト100からのライト要求やリード要求が一定時間発行されない場合、ホスト100からのリカバリポイント作成指示が一定時間発行されない場合などが挙げられる。
また、監視対象部位がプロセッサ250自身である場合、例えば、iSCSIのログイン／ログアウトなどのイベントが検出される。
なお、第４のパターンの変形例として、上述のようなポーリングではなく、プロセッサ250が、各監視対象部位においてあらゆるイベントが発生する度にイベントの履歴を収集して管理し、特定のイベントであるか否かを判定し、特定のイベントであることを検知したことを契機として、リカバリポイントを作成する態様であってもよい。
この場合、ストレージシステム200は、制御情報部240にイベント情報244を有する。
イベント情報244には、各監視対象部位の管理情報から収集されるすべてのイベントのうち、リカバリポイントを作成するイベントとして特定のイベントの識別情報が登録される。プロセッサ250は、各監視対象部位の管理情報から収集されるすべてのイベントに対し、イベント情報244を参照して登録されているか否かを判定し、イベント情報244に登録されている場合、特定のイベントの発生であることを検知して、ジャーナル作成プログラム233を呼び出す。ジャーナル作成プログラム233は、リカバリポイントを作成する。ジャーナル作成プログラム233によるリカバリポイント作成の処理内容は、第１のパターンと同様である。
また、各監視対象部位がそれぞれプロセッサを有し、当該監視対象部位においてイベントが発生する度にイベントの履歴をメモリなどに記録し、プロセッサ250がそのメモリを読み出し、イベント情報244を参照して、特定のイベントであるか否かを判定する形態でもよい。
また、各監視対象部位がプロセッサを有し、当該監視対象部位においてイベントが発生する度に、イベント情報244を参照して特定のイベントであるか否かを判定し、特定のイベントであることを検知した場合、プロセッサ250に通知する形態であってもよい。
なお、管理者は、管理ソフト180や保守用管理端末、ストレージシステム200付随の操作パネルなどを介して、イベント情報244に登録されるイベントを追加・削除することができる。
また、上述のように、ストレージシステム200の稼働中、常にイベント検出を行なう形態ではなく、管理者が管理ソフト180や保守用管理端末、ストレージシステム200付随の操作パネルなどからイベント検出機能の停止、起動などを行なえるようにしてもよい。
次に、図17を用いて、ストレージシステム200がホスト100からの指示を伴わずにリカバリポイントを作成する第２の場合において、上述したイベント検出方法に基づいてストレージシステム200が作成したリカバリポイントを、ホスト100へ提供するための処理を説明する。
図17に、ホスト100が、ストレージシステム200が検出したイベントに基づくリカバリポイントを収集する処理の一例を示す。この処理は、ホスト100のプロセッサ120がリカバリポイント収集プログラム183を実行し、ストレージシステム200のプロセッサ250がリカバリポイント提示プログラム235を実行することで行なわれる。
リカバリポイント収集プログラム183が、リカバリポイント提示プログラム235に対してリカバリポイント収集要求を発行する(S800)。リカバリポイント収集要求を受領したリカバリポイント提示プログラム235は、ストレージシステム200のリカバリポイント管理表242から、リカバリポイント情報をリードし、リカバリポイント収集プログラム183へ報告する。リカバリポイント情報の内容としては、図11に示すように、RPID801、取得時刻1101、ボリューム番号1102、イベント1103などがある(S801)。リカバリポイント収集プログラム183が、リカバリポイント情報を受領すると(S802)、ホスト100のリカバリポイント管理表186にリカバリポイント情報を追加する。このとき、リカバリポイント情報のRPID901、取得時刻902、ボリューム番号903、イベント905はストレージシステム200が報告した値とし、種別904を「ストレージシステム」としてホスト100のリカバリポイント管理表186に追加する(S803)。
また、ホスト100からの指示によって作成したリカバリポイントと、ホスト100の指示を伴わずに作成したリカバリポイントを同一のリカバリポイント管理表242で管理している場合には、ホストの指示を伴わずに作成したリカバリポイントのみを報告してもよい。また、リカバリポイント管理表242に格納されている全てのリカバリポイントをホスト100へ報告し、ホスト100がホスト指示を伴わないリカバリポイントのみをホスト100のリカバリポイント管理表186へ追加してもよい。
なお、ホスト100からの1回のリカバリポイント収集に対して、ストレージシステム200は、複数個のリカバリポイントを同時に報告することができる。さらに、ホスト100は、イベントを指定したリカバリポイントの収集指示を行い、ストレージシステム200は、指定されたイベントをイベント1103から検出し、当該イベントによるリカバリポイントのみを報告する形態であってもよい。また、ホスト100から時刻を指定してリカバリポイントの収集指示を行い、ストレージシステム200は指定された時刻より取得時刻1101が新しいリカバリポイントのみを報告する形態であってもよい。
ここで、特に、ストレージシステム200がホスト100からの指示を伴わずにリカバリポイントを作成する第２の場合において、ストレージシステム200が作成するリカバリポイントの総数が膨大になることが考えられる。そこで、図18および図19を用いて、リカバリポイントを適宜削除する方法について述べる。
リカバリポイントの削除の処理方式には複数のポリシーが考えられる。たとえば、指定したリカバリポイントのみを削除、イベントを指定して指定されたイベントに関するリカバリポイントを全て削除、時刻を指定して指定された時刻以前のリカバリポイントを全て削除、ストレージシステム200による自動削除などといった例が挙げられる。以下に、それぞれを説明する。
第１に、指定したリカバリポイントのみを削除する場合について説明する。
ホスト100のリカバリポイント削除指示プログラム184は、RPID901を指定して、ストレージシステム200のリカバリポイント削除プログラム236にリカバリポイント削除要求を発行する。リカバリポイント削除要求を受領したリカバリポイント削除プログラム236は、ストレージシステム200のリカバリポイント管理表242から該当するRPID801のリカバリポイント情報を削除し、リカバリポイント削除指示プログラム184へ報告する。最後に、リカバリポイント削除指示プログラム184がホスト100のリカバリポイント管理表186から指定したRPID901のリカバリポイント情報を削除する。
第２に、ホスト100がイベントを指定し、指定されたイベントに関するリカバリポイントを削除する場合について説明する。
ホスト100は、イベントを指定してリカバリポイント削除指示を発行し、ストレージシステム200は、該当する全てのリカバリポイントを削除する。なお、この処理方式の変形例として、ホスト100からリカバリポイントの削除を指定されたイベントに関しては、以後リカバリポイントを作成しない方式が考えられる。これにより、ホスト100上で動作するソフトウェアなどが、あるイベントに基づいてリカバリポイントを作成する必要がないと判断した場合、そのイベントに基づくリカバリポイントを以後作成しなくなる。
図18に、ホスト100から指定されたイベントに関しては、以後リカバリポイントを作成しない場合のリカバリポイント削除処理の一例を示す。この処理は、ホスト100のプロセッサ120がリカバリポイント削除指示プログラム184を実行し、ストレージシステム200のプロセッサ250のリカバリポイント削除プログラム236を実行することで行なわれる。
まず、リカバリポイント削除指示プログラム184が、あるイベント905を指定して、ストレージシステム200のリカバリポイント削除プログラム236にリカバリポイント削除要求を発行する(S900)。リカバリポイント削除要求を受領したリカバリポイント削除プログラム236は、ストレージシステム200のリカバリポイント管理表242から、指定されたイベント905に対応するイベント1103に基づくリカバリポイントを全て見つけ、削除する(S901)。この時、リカバリポイント削除プログラム236は、指定されたイベント1103を記憶しておく。記憶領域としては、図示していないがストレージシステム200の制御情報部240や、ボリューム280などに記憶するものとする(S902)。この後、リカバリポイント削除プログラム236は、リカバリポイント削除指示プログラム184に完了を報告して処理を終了する(S903)。最後に、リカバリポイント削除指示プログラム184がホスト100のリカバリポイント管理表186から指定したイベント905に基づくリカバリポイントを検出して、削除する(S904)。
ステップS902で記憶したイベントに基づくリカバリポイント作成の抑止に関して述べる。これまで、図13、図14、図15、図16に大きく四つのパターンのイベント検出方式およびリカバリポイント作成の処理方式を示した。これらの処理では、リカバリポイントジャーナル作成のためにジャーナル作成プログラム233を呼び出す処理ステップがある(S402、S502、S603、S702である)。このジャーナル作成プログラム233を呼び出す直前に、今作成しようとしているリカバリポイントジャーナルが、S902で記憶したイベント1103に該当するものであるかをチェックするステップを追加する。このステップにおいて、当該リカバリポイントジャーナルがS902で記憶したイベント1103に該当するものであるならばジャーナル作成プログラム233を呼び出さないようにすることで、リカバリポイントの作成を抑止することが可能となる。
第３に、ホスト100が時刻を指定し、指定された時刻以前のリカバリポイントを全て削除する場合について説明する。
ホスト100は、時刻を指定してリカバリポイント削除指示を発行し、指定時刻以前にストレージシステム200が作成した全てのリカバリポイントを削除する。なお、この処理方式の変形例として、指定時刻以前に作成したスナップショットに、指定時刻以降のリカバリポイントまでのジャーナルを適用し、指定時刻以前のスナップショットおよびジャーナルを削除することも考えられる。この変形例の概念図を図19に示す。
図19の例では、ホスト100の指定時刻がジャーナルのSEQ#6とSEQ#7の間の時刻の場合である。この比較は、ホスト100の指定時刻と、図5に示すようなジャーナルの属性情報である時刻503との比較によって実現する。
指定時刻以前のスナップショットが、ボリューム1920に示すスナップショットである。そして、指定時刻以降のリカバリポイントが、SEQ#8のリカバリポイントジャーナルに対応するボリューム1940に示すリカバリポイントである。このとき、ボリューム1920のスナップショットに、SEQ#6およびSEQ7のジャーナルを適用することで、ボリューム1940時点のスナップショットを生成する。作成したスナップショットを、図19におけるボリューム1930で示している。この結果、指定時刻以降のリカバリポイント（ボリューム1940）へのリカバリは、スナップショット1930により実現できる。また、ストレージシステム200は、ホスト100からの、指定時刻以前のリカバリポイントを削除するよう要求を受けて、ボリューム1900、1910で示されるスナップショットデータ、およびSEQ#1〜SEQ#7までのジャーナルは不要となり、削除することができる。
以下に、上記のリカバリポイント削除の処理内容を示す。リカバリポイント削除指示プログラム184が、ある時刻を指定して、ストレージシステム200のリカバリポイント削除プログラム236にリカバリポイントの削除要求を発行する。リカバリポイント削除要求を受領したリカバリポイント削除プログラム236は、指定時刻以前のスナップショットをスナップショット管理表241から探す。指定時刻以前のスナップショットが存在しない場合には、ホスト100に完了を報告して処理を終了する。
指定時刻以前のスナップショットが存在する場合には、続いて、指定時刻以降のリカバリポイントをリカバリポイント管理表242から探す。指定時刻以降のリカバリポイントが存在しない場合には、ホスト100に完了を報告して処理を終了する。
指定時刻以前のスナップショットが存在し、指定時刻以降のリカバリポイントが存在する場合には、指定時刻以前のスナップショットに対して指定時刻以降のリカバリポイントまでのジャーナルを適用する。これにより、指定時刻以降のリカバリポイントに対応するスナップショットを生成する（このとき、スナップショット管理表241も更新する）。最後に、リカバリポイント削除プログラム236は、前ステップで生成したリカバリポイントに対応するスナップショット以前のスナップショットおよびジャーナルのデータを削除して、ホスト100に完了を報告する。完了報告を受領したホスト100では、リカバリポイント管理表186を更新し、処理を終了する。
第４に、ストレージシステム200による自動削除の場合について説明する。
たとえば、ストレージシステム200は、一定時間経過後にリカバリポイントを自動的に削除することができる。以下に処理の内容を示す。ストレージシステム200のリカバリポイント削除プログラム236は、一定時間以上古い（たとえば、1年など）リカバリポイントをリカバリポイント管理表242から探す。続いて、当該リカバリポイントを削除する。その後、ホスト100のリカバリポイント収集プログラム183からリカバリポイント収集要求を受領した際に、自動削除したリカバリポイントを通知することで、ホスト100のリカバリポイント管理表186からも削除する。また、ストレージシステム200の自動削除では、イベント指定や、時刻指定のリカバリポイント削除で述べた変形例を適用することも可能である。
次に、図20を用いて、本実施例のユーザインタフェースの一例について説明する。管理ソフト180は、ユーザに対してリカバリポイントをGUI（Graphical User Interface）画面によって提示する。また、ユーザがGUI画面からリカバリポイントを選択し、ストレージシステム200にリカバリ要求や、リカバリポイント削除要求を発行することができる。このGUI画面は、管理ソフト180のGUIプログラム188が実行する。
図20に管理ソフト180がユーザに提供するGUI画面の一例を示す。このGUI画面2000は大きく分けて、リカバリポイント表示部2010、リカバリ指示部2020、リカバリポイント削除部2030から成る。
リカバリポイント表示部2010は、リカバリポイント一覧表2011によってリカバリポイントを表示する。リカバリポイント一覧表2011は、属性として、RPID2012、取得時刻2013、ボリューム番号2014、種別2015、イベント内容2016を持つ。各属性の表示はプルダウンメニューとなっている。例えば、種別2015では、メニューをクリックすると、画面2018に示すように、「すべて」、「ユーザ指示」、「ホスト自動取得」、「ストレージシステム自動取得」が表示さる。このとき、「ストレージシステム自動取得」を選択するとリカバリポイント一覧表2011には、ストレージシステム200によるイベント検出を契機とするリカバリポイントが表示される。
ユーザは、リカバリポイント一覧表2011から一つのリカバリポイントを選択することができる。図20の例では、RPIDが4のリカバリポイント情報2017が選択されていることを示している。
リカバリ指示部2020は、リカバリ先ボリューム一覧表2021とリカバリ要求ボタン2023から成る。ユーザは、リカバリポイント一覧表2011から一つのリカバリポイントを選択し、さらに、リカバリ先ボリューム一覧表2021から一つのリカバリ先ボリュームを選択すると、リカバリ要求ボタン2023の実行によって、リカバリ要求をストレージシステム200へ発行することができる。図20の例では、リカバリ先ボリュームがボリューム4であるエントリ2022が選択されていることを示している。
リカバリポイント削除部2030は、リカバリポイント削除ボタン2031から成る。ユーザは、リカバリポイント一覧表2011から、削除したい一つ以上のリカバリポイントを選択し、リカバリポイント削除ボタン2031を実行することによって、選択したリカバリポイントの削除要求をストレージシステム200へ発行することができる。
また、リカバリポイント一覧表2011のプルダウンメニューの項目を選択し、リカバリポイント削除ボタン2031を実行することで、イベント指定のリカバリポイント要求、取得時刻指定のリカバリポイント要求を行なえるものとする。具体的には、例えば、イベント内容2016から「通信障害」を選択し、リカバリポイント削除ボタン2031を実行する。このとき、リカバリポイント削除要求を受領したストレージシステム200は、「通信障害」というイベントを契機に取得したリカバリポイントを全て削除する。
なお、本実施形態では、図4を用いて説明したように、ストレージシステム200がスナップショット作成要求を受領するとソースボリューム400の全データをスナップショットボリュームへコピーするとした。以下に述べるような変形例１および２によるスナップショット作成でも本実施形態は実現できる。
（変形例1）
変形例1では、ストレージシステム200がスナップショット作成要求を受領しても、ソースボリューム400にライトが行われるまでは、ソースボリューム400からスナップショットボリューム410へのデータコピーを行なわない。
ストレージシステム200がスナップショット作成要求を受領すると、スナップショットボリューム410の属性として、スナップショットボリューム410のアドレスごとにソースボリューム400への同一アドレスへのポインタを作成する。スナップショットボリューム410からデータをリードする場合には、ストレージシステム200が、当該ポインタを用いて、ソースボリューム400のデータからリードするように制御する。ホスト100からソースボリューム400へライトが発行されると、ライトアドレスに格納されているデータをスナップショットボリューム410へコピーし、コピー完了後ソースボリューム400にホスト100からのライトデータを書き込む。さらに、当該アドレスに関してはスナップショットボリューム410からソースボリューム400へのポインタを削除する。
以上の処理によって、ソースボリューム400においてライトが発行されたアドレスに対応するスナップショットボリューム410中のデータに対するリード要求は、ソースボリューム400ではなくスナップショットボリューム410に対して行なわれる。
（変形例2）
変形例2では、変形例1に加えて、スナップショットボリューム410に対して実際にデータを書き込む場合のみ記憶領域を割当てるものである。たとえば、次のようにして実現する。
ストレージシステム200に、複数のスナップショットに必要に応じて割当てるための記憶領域を作成しておく。この記憶領域をプールボリューム（図示しない）と呼ぶ。
ホスト100からソースボリューム400へライト要求が発行されると、ストレージシステム200は、プールボリュームからスナップショットボリューム410に必要な容量の領域を割当てる。続いて、ソースボリューム400のライトアドレスに格納されているデータを、スナップショットボリューム410において割当てられた領域にコピーし、コピー完了後ソースボリューム400にホスト100からのライトデータを書き込む。この場合、スナップショットボリューム410は、ソースボリューム400またはプールボリュームへのポインタとなる。
以上のように論理的に取得するスナップショットでも本発明を実施することができる。変形例１および変形例２のようにスナップショットボリューム410を作成することで、スナップショットボリューム410として確保する記憶領域を削減することができる。
なお、本実施例で述べていないスナップショット作成技術によっても本発明を実施することは可能である。
実施例１によると、ホストとストレージシステムが接続されたシステムにおいて、ストレージシステムが検出し、ホストが検出しないようなイベントにおいても、ストレージシステムがリカバリポイントを作成することで、後にリカバリを実行することが可能となる。また、作成したリカバリポイントを任意に削除することで、記憶領域に格納されるリカバリポイントに要する容量を低減することができる。
実施例１では、図1、図2に示すシステム構成で本発明を説明した。しかし、図1、図2に示したシステム構成以外でも本発明は実施可能である。図21に、実施例２として、その他のシステム構成の一例を示す。この構成では、ストレージシステム200にホスト100と管理サーバ2100がネットワークによって接続されている形態である。ホスト100とストレージシステム200の接続は図1、図2に示したとおりネットワーク160によって接続する。管理サーバ400とストレージシステム200は、管理ネットワーク2110によって接続されている。
管理サーバ2100は管理ソフト180を有する。管理ソフト180は、図1、図2に示した管理ソフト180と同様である。管理サーバ2100は、この管理ソフト180を用いて、バックアップ/リカバリの設定などを実施することができる。また、図21のシステム構成に加えてホスト100と管理サーバ2100をネットワークで接続するような構成であってもよい。
実施例２のようなシステム構成によって、ホスト100とストレージシステム200との間の通信によるネットワーク負荷を低減することができる。また、ホスト100のプロセッサ120によるI/O処理速度の低減を防止することができる。
図22に示すようなシステム構成においても、本発明を適用することができる。図22に、実施例3として、その他のシステム構成の一例を示す。この構成では、ストレージシステム200とホスト100はスイッチ2200を経由してネットワーク160で接続されている。このスイッチ2200が、イベント検出プログラム2210を有している。そして、イベント検出プログラム2210がスイッチ2200で検出可能なイベントの検出を契機としてリカバリポイント作成指示をストレージシステム200へ発行する。当該指示を受領したストレージシステム200がリカバリポイント作成を実施する。また、スイッチ2200がリカバリポイント作成処理を実施してもよい。また、スイッチ2200に接続される別の装置が、プロセッサやメモリを有しており、当該装置がイベント検出プログラム2210を有してもよい。さらには、当該装置がジャーナルを作成、格納してもよい。
本実施例におけるシステム構成のように複数台のストレージシステム200やホスト100に接続されているスイッチ2200によってイベント検出を行なうことで、複数のストレージシステム200が連携して動作する場合にも、当該連係動作をイベントとして検出することができる。
例えば、スイッチ2200に接続されているストレージシステムAからストレージシステムBへデータを移行する場合に、移行完了をイベントとして検出することなどが考えられる。また、ストレージシステムAとストレージシステムBが運用系と待機系である場合に、スイッチ2200は、ストレージシステムAからストレージシステムBへの切り替えをイベントとして検出することが可能である。
図23を用いて、実施例４を説明する。
本実施例では、実施例１におけるあるボリューム280、またはボリューム280の集合に対するリカバリポイントを、ボリューム280が属するストレージシステムとは別のストレージシステムで発生し、検出したイベントに基づき作成する方法について述べる。
ストレージシステムの分野においては、災害によりデータセンタが倒壊した場合にも、ホスト100がストレージシステムに格納していたデータを失うことなく、ストレージシステムとしてのサービスを提供し続けるための機能としてリモートコピー機能がある。
リモートコピー機能とは、ストレージシステム（以下、本実施例において、「正ストレージシステム」と呼ぶ）のボリューム280に格納されているデータを、別のストレージシステム(以下、本実施例において、「副ストレージシステム」と呼ぶ)のボリューム280にコピーし2重化する機能である。このような環境においては、二つのボリューム280やストレージシステムが関連性を持つことになる。そのため、たとえば、副ストレージシステムの障害により、正ストレージシステムはデータが2重化されていないという状態となってしまう。
本実施形態では、副ストレージシステムで検出したイベントに基づき、正ストレージシステムでリカバリポイントを作成する方法を述べる。
図23に本実施形態に係るシステムの全体構成図の一例を示す。実施例1で図1、図2に示したシステム構成に加えて、ストレージシステム200にネットワーク2310によって副ストレージシステム2300が接続されている。なお、ストレージシステム200を本実施例では、正ストレージシステム200とする。
正ストレージシステム200は、リモートコピーのコピー元ボリューム280であるプライマリボリューム2320を有する。プライマリボリューム2320に対するジャーナルは、実施例1と同様に、ジャーナルボリューム2340に格納される。さらに、正ストレージシステム200は、制御部230に副ストレージシステム2300からイベント発生の通知を受領するための通知受領プログラム2350を有する。それ以外の構成は、実施例1で述べたストレージシステム200と同様である。
副ストレージシステム2300は、リモートコピーのコピー先ボリューム280であるセカンダリボリューム2330を有する。副ストレージシステム2300は、リモートコピーによって、正ストレージシステム200からプライマリボリューム2320に格納されるデータを同期もしくは非同期に受信して、セカンダリボリューム2330に格納する。さらに、副ストレージシステム2300は、制御部230に副ストレージシステム2300が検出したイベントを正ストレージシステム200に通知するためのイベント通知プログラム2360を有する。それ以外の構成は、実施例1で述べたストレージシステム200と同様である。以下に、副ストレージシステム2300で検出するイベントに基づいて正ストレージシステム200がリカバリポイントを作成するための方法を述べる。
まず、副ストレージシステム2300は、実施例1述べた方式によって、副ストレージシステムで検出可能なイベントを検出する。イベントを検出した副ストレージシステム2300は、イベント通知プログラム2360を起動し、正ストレージシステム200に対してイベント発生を通知する。イベント通知プログラム2360からイベント発生の通知を受領した通知受領プログラム2350は、ジャーナル作成プログラム233を呼び出し、リカバリポイントを作成する（ジャーナル作成プログラム233によるリカバリポイント作成の処理内容は、実施例1と同様である）。以上の処理によって、副ストレージシステム2300で発生するイベントに基づくリカバリポイントを、正ストレージシステム200において作成することが可能となる。
たとえば、副ストレージシステム2300が有するリモートコピー機能のセカンダリボリューム2330の状態遷移（ペア状態の解除など）を契機として、正ストレージシステム200が有するプライマリボリューム2320に対するリカバリポイント作成が可能となる。
なお、上述のシステム構成において、副ストレージシステム2300がジャーナルボリュームと通知受領プログラム2350を有し、正ストレージシステム200がイベント通知プログラム2360を有してもよい。この場合には、正ストレージシステム200で発生するイベントに基づくリカバリポイントを副ストレージシステム2300で作成することも上記の方式によって実現できる。
図24を用いて、実施例５を説明する。
本実施例では、ストレージシステム200が障害というイベントを検出した場合に、ストレージシステム200に格納しているデータが破壊されている可能性があるか否かという情報をホスト100へ提供する方法を述べる。
多くのストレージシステム200では、全てのハードウェアが冗長化されており、1重障害では、ストレージシステム200が格納しているデータが破壊されるという状態は起こらない。しかし、全てのストレージシステム200が冗長化されているわけではなく、さらに、2重障害時にはデータ破壊やデータ消失なども発生することがある。本実施例のようにホスト100にあるリカバリポイント以降のデータは破壊されている可能性があるという情報を提供すると、データが破壊されている可能性がない時点でデータをリカバリすることができる。
上記方法を実現するために、実施例1に示したストレージシステム200のリカバリポイント管理表242及びホスト100のリカバリポイント管理表186に、実施例1で述べた情報に加えて、データ破壊の可能性有無を示す情報を格納する。図24に、データ破壊の可能性有無の情報を有するストレージシステム200のリカバリポイント管理表2400を示す。リカバリポイント管理表2400のその他の属性である、RPID801、取得時刻1101、ボリューム番号1102、SEQ#802、イベント1103は、実施例1と同様である。データ破壊可能性有無情報2401には、データ破壊の可能性の有無を示す識別情報が格納される。また、図示しないがホスト100のリカバリポイント管理表186も、同様にデータ破壊の可能性という属性を持つ情報が格納されるものとする。
まず、ユーザへのリカバリポイント提供方法に関して述べる。
実施例１において、ストレージシステム200があるボリュームに対して、イベントとして障害を検出して、このイベント発生後にリカバリポイントを作成したとする。次に、ストレージシステム200は、ホスト100からあるボリュームに対してリカバリポイント作成要求を受領し、リカバリポイントを作成するとする。このとき、障害発生部位にも依存するが、上記二つのリカバリポイントが同一のボリュームに対するリカバリポイントの作成である場合には、ホスト100からのリカバリポイント作成要求に応じてストレージシステム200が作成したリカバリポイントのデータは、破壊されている可能性を含むが、ホスト100およびユーザには提供されない。
本実施例では、このような場合にも正しく利用者にデータ破壊の可能性の情報を提供するために、ストレージシステム200が、障害を検出しリカバリポイントを作成するとき、当該障害の範囲を決定し、記憶する。そして、以降に、ストレージシステム200がリカバリポイントを作成するとき、リカバリポイント作成対象のボリュームが、記憶している障害の範囲に含まれる場合には、データ破壊の可能性ありとしてデータ破壊可能性有無情報2401に「あり」を付与し、リカバリポイントを作成する。
具体的には、例えば、図24に示すように、キャッシュ障害を検出し、ボリューム1に対するRPIDが13のリカバリポイントを、データ破壊の可能性ありとして、データ破壊可能性有無情報2401に「あり」を格納して作成する。キャッシュ障害は、ボリューム1以外のボリュームにも影響するため、障害の範囲として、以降に作成するRPID14からRPID18のリカバリポイントを、データ破壊の可能性があるとして、これらのリカバリポイントにはデータ破壊可能性有無情報2401に「あり」を格納してリカバリポイントを作成する。
このようにしてリカバリポイントをユーザに提供することで、ユーザは、データ破壊が発生していないデータをリカバリするためには、RPID12以前のリカバリポイントへのリカバリで十分であると判断することができる。
また、上記説明ではストレージシステム200が、障害を検出した場合に、作成するリカバリポイントに対してデータ破壊の可能性有無を決定するとしたが、データ破壊可能性有無情報2401を付与するか否かの判定は、ホスト100で行ってもよい。つまり、ストレージシステム200は実施例1と同じようにホスト100へリカバリポイント情報を提供する。そして、ホスト100がストレージシステム200から収集したリカバリポイントのイベント内容からデータ破壊の可能性有無を決定する。
次に、リカバリポイント削除方法に関して述べる。これは、データ破壊の可能性があるリカバリポイントを優先的に削除するものである。実施例1のリカバリポイント削除の方法では、ストレージシステム200が自動的にリカバリポイントの削除を行なう方法を述べた。
本実施例では、削除対象とするリカバリポイントとして、データ破壊可能性有無情報2401に基づいて、データ破壊の可能性があるリカバリポイントを優先的に選択することができる。また、ホスト100から自動的にデータ破壊の可能性があるリカバリポイントを選択し、ストレージシステム200へ当該リカバリポイントの削除を要求することも考えられる。
また、管理者などが管理ソフト180、保守用管理端末、または、操作パネルなどから、障害をリカバリしたことを、ホスト100やストレージシステム200へ知らせるためのインタフェースを有していてもよい。この場合には、障害をイベントとするリカバリポイントから障害リカバリが通知されるまでの間に作成したリカバリポイントを一括して削除することも考えられる。
本実施例のように、ストレージシステム200がイベント発生ごとにデータ破壊可能性有無情報2401を付与し、ホスト100に対して通知することで、ユーザは、データが正常に記憶されているという信頼性が高いリカバリポイントを選択して、リカバリを実行することができる。また、ユーザは、データが破壊されている可能性のある時点以降のリカバリポイントを選択して、削除するように指示することが可能となる。
以上、本発明の実施の形態について説明したが、本発明はこうした実施の形態に何ら限定されるものではなく、本発明の趣旨を逸脱しない範囲内において様々な形態で実施し得ることは勿論である。
実施例1における情報処理システムの一例、および、ホストの構成の一例を示す図である。 ストレージシステムの構成の一例を示す図である。 スナップショットとジャーナルを用いたリカバリ処理の概念を示す図である。 スナップショット機能の概念を示す図である。 ジャーナルのフォーマットの一例を示す図である。 ライト要求時におけるジャーナル作成処理の一例を示す図である。 リカバリポイント作成の処理の一例を示す図である。 ストレージシステムが管理するリカバリポイント管理表の一例を示す図である。 ホストが管理するリカバリポイント管理表の一例を示す図である。 リカバリポイントにおけるリカバリ処理の一例を示す図である。 ストレージシステムが管理するリカバリポイント管理表の他の一例を示す図である。 ストレージシステムが管理するリカバリポイント管理表の他の一例を示す図である。 ストレージシステムによるイベント検出に基づくリカバリポイント作成処理の一例を示す図である。 ストレージシステムによるイベント検出に基づくリカバリポイント作成処理の他の一例を示す図である。 ストレージシステムによるイベント検出に基づくリカバリポイント作成処理の他の一例を示す図である。 ストレージシステムによるイベント検出に基づくリカバリポイント作成処理の他の一例を示す図である。 ホストがストレージシステムからリカバリポイントを収集する処理の一例を示す図である。 ストレージシステムが取得したリカバリポイントを削除する処理の一例を示す図である。 リカバリポイント削除に伴い不要なスナップショットおよびジャーナルの削除の概念を示す図である。 ホストのリカバリポイント表示部、リカバリ指示部、および、リカバリポイント削除指示部の画面の一例を示す図である。 実施例２における情報処理システムの一例を示す図である。 実施例３における情報処理システムの一例を示す図である。 実施例４における情報処理システムの一例を示す図である。 実施例５においてストレージシステムが管理するリカバリポイント管理表の一例を示す図である。
符号の説明
１００・・・ホスト
１１０、２２０・・・メモリ
１２０、２５０・・・プロセッサ
１３０、２１０・・・インタフェース
１６０・・・ネットワーク
１８０・・・管理ソフト
１８５、２４１・・・スナップショット管理表
１８６、２４２・・・リカバリポイント管理表
２００・・・ストレージシステム
２３０・・・制御部
２４０・・・制御情報部
２３２・・・スナップショット作成プログラム
２３３・・・ジャーナル作成プログラム
２３４・・・状態監視プログラム
２３５・・・リカバリポイント提示プログラム
２３６・・・リカバリポイント削除プログラム
２３７・・・リカバリプログラム
２３８・・・ボリューム管理プログラム
２４１・・・スナップショット管理表
２４２・・・リカバリポイント管理表
２４３・・・SEQ#情報
２４４・・・RPID情報
２４５・・・イベント情報
２８０・・・ボリューム
３３０・・・ジャーナル
３４０・・・スナップショットジャーナル
３５０・・・リカバリポイントジャーナル
４００・・・ソースボリューム
４１０・・・スナップショットボリューム
２１００・・・管理サーバ
２２００・・・スイッチ
２２１０・・・イベント検出プログラム
２３００・・・副ストレージシステム
２３２０・・・プライマリボリューム
２３３０・・・セカンダリボリューム
２３４０・・・ジャーナルボリューム
２３５０・・・通知受領プログラム
２３６０・・・イベント通知プログラム

Claims (23)

  1. 計算機に接続されるストレージシステムであって、
    前記計算機が使用するデータを格納する第１の記憶領域と、
    前記第１の記憶領域内のデータに対する前記計算機からの書き込み要求があった場合に形成されるジャーナルであって、書き込みデータ及び前記書き込みデータに関する制御情報に対応したジャーナルと、データリカバリを実行するための目標点となるリカバリポイントが設定された場合に形成されるリカバリポイントジャーナルとを格納する第２の記憶領域と、
    前記ジャーナル及び前記リカバリポイントジャーナルを作成するジャーナル作成手段と、
    前記リカバリポイントに関する情報及び前記リカバリポイントに関する情報に対応付けられた識別番号を格納する管理テーブルと、
    前記ストレージシステムに関する状態変化を検出する検出手段と
    を有し、
    前記ジャーナル作成手段は、
    前記計算機からリカバリポイントの設定要求を受け付けると、第１のリカバリポイントジャーナルを作成し、該作成した第１のリカバリポイントジャーナルに含まれる情報と、前記計算機から指定される第１のリカバリポイントに対応する第１の識別番号とを対応付けて前記管理テーブルに記録し、
    前記検出手段により前記ストレージシステムに関する状態変化が検出されると、第２のリカバリポイントジャーナルを作成し、該作成した第２のリカバリポイントジャーナルに含まれる情報と、前記第１の識別番号とは異なる第２のリカバリポイントに対応する第２の識別番号とを対応付けて前記管理テーブルに記録する
    ことを特徴とするストレージシステム。
  2. 請求項１に記載のストレージシステムであって、
    前記検出手段は、
    前記計算機から前記書き込みデータを受信した場合であって、かつ、前記計算機から受信した前記書き込みデータを前記第１の記憶領域に書き込むことができない場合、前記書き込みデータを前記第１の記憶領域に書き込むことができないことを、前記第１の記憶領域における状態変化として検出し、
    前記ジャーナル作成手段は、
    前記検出手段が前記状態変化として検出した時点を前記第２のリカバリポイントとして決定し、該決定した第２のリカバリポイントに対応する前記第２のリカバリポイントジャーナルを作成する
    ことを特徴とするストレージシステム。
  3. 請求項２に記載のストレージシステムであって、
    前記検出手段は、
    前記計算機から、ある制御要求を受信した場合、前記ストレージシステムに関する状態変化として検出し、
    前記ジャーナル作成手段は、
    前記検出手段が前記ある制御要求を受信した後で前記ある制御要求を実行する前の時点を、前記第２のリカバリポイントとして決定する
    ことを特徴とするストレージシステム。
  4. 請求項３に記載のストレージシステムであって、
    前記検出手段は、
    前記計算機から、前記第１の記憶領域内のあるデータを削除する制御要求を受信した場合、前記ストレージシステムに関する状態変化として検出する
    ことを特徴とするストレージシステム。
  5. 請求項２に記載のストレージシステムであって、
    リカバリポイント提供手段を有し、
    前記リカバリポイント提供手段は、
    前記計算機から前記第２のリカバリポイントの情報の送信要求を受信した場合、前記管理テーブルを参照して、前記第２のリカバリポイントに対応する前記第２の識別番号が付与された前記第２のリカバリポイントジャーナルを送信する
    ことを特徴とするストレージシステム。
  6. 請求項５に記載のストレージシステムであって、
    リカバリ手段を有し、
    前記リカバリ手段は、
    前記計算機が、前記リカバリポイント提供手段から受信した前記第１の識別番号又は前記第２の識別番号に基づいて前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域のリカバリ要求を送信する場合、まず、前記リカバリ要求を受信し、該受信したリカバリ要求に含まれる前記第１の識別番号又は前記第２の識別番号と、前記管理テーブルとに基づいて、前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号を取得し、次いで該取得したシーケンス番号よりも小さいシーケンス番号を持つスナップショットを、スナップショットを管理するスナップショット管理表から検索し、次いで該検索したスナップショットに対応するスナップショットボリュームに格納されているデータを前記リカバリ要求に含まれるリカバリ先ボリューム番号に対応付けられたリカバリ先ボリュームにコピーし、最後に前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号よりも小さいシーケンス番号から前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号までの間に存在するジャーナルをシーケンス順に前記リカバリ先ボリュームに適用することにより、前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域をリカバリする
    ことを特徴とするストレージシステム。
  7. 請求項１に記載のストレージシステムであって、
    前記検出手段は、
    前記第１の記録領域の使用状態を管理し、前記計算機から前記第１の記憶領域に対するアクセス要求が停止された場合、前記第１の記憶領域に対するアクセス要求が停止されたことを、前記第１の記憶領域における状態変化として検出し、
    前記ジャーナル作成手段は、
    前記検出手段が前記状態変化として検出した時点を前記第２のリカバリポイントとして決定し、前記第２のリカバリポイントに対応する前記第２のリカバリポイントジャーナルを作成する
    ことを特徴とするストレージシステム。
  8. 請求項７に記載のストレージシステムであって、
    リカバリポイント提供手段を有し、
    前記リカバリポイント提供手段は、
    前記計算機から前記第２のリカバリポイントの情報の送信要求を受信した場合、前記管理テーブルを参照して、前記第２のリカバリポイントに対応する前記第２の識別番号が付与された前記第２のリカバリポイントジャーナルを送信する
    ことを特徴とするストレージシステム。
  9. 請求項８に記載のストレージシステムであって、
    リカバリ手段を有し、
    前記リカバリ手段は、
    前記計算機が、前記リカバリポイント提供手段から受信した前記第１の識別番号又は前記第２の識別番号に基づいて前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域のリカバリ要求を送信する場合、まず、前記リカバリ要求を受信し、該受信したリカバリ要求に含まれる前記第１の識別番号又は前記第２の識別番号と、前記管理テーブルとに基づいて、前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号を取得し、次いで該取得したシーケンス番号よりも小さいシーケンス番号を持つスナップショットを、スナップショットを管理するスナップショット管理表から検索し、次いで該検索したスナップショットに対応するスナップショットボリュームに格納されているデータを前記リカバリ要求に含まれるリカバリ先ボリューム番号に対応付けられたリカバリ先ボリュームにコピーし、最後に前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号よりも小さいシーケンス番号から前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号までの間に存在するジャーナルをシーケンス順に前記リカバリ先ボリュームに適用することにより、前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域をリカバリする
    ことを特徴とするストレージシステム。
  10. 請求項１に記載のストレージシステムであって、
    前記検出手段は、
    前記ストレージシステムに関する状態変化を検出し、
    前記ジャーナル作成手段は、
    前記検出手段が前記状態変化として検出した時点を第２のリカバリポイントとして決定し、前記第２のリカバリポイントに対応する前記第２のリカバリポイントジャーナルを作成する
    ことを特徴とするストレージシステム。
  11. 請求項１０に記載のストレージシステムであって、
    前記計算機との間で制御情報を送受信する通信手段を有し、
    前記検出手段は、
    前記通信手段をポーリングして、前記通信手段から異常を示す制御情報を受信した場合、前記ストレージシステムに関する状態変化として検出する
    ことを特徴とするストレージシステム。
  12. 請求項１０に記載のストレージシステムであって、
    リカバリポイント提供手段を有し、
    前記リカバリポイント提供手段は、
    前記計算機から前記第２のリカバリポイントの情報の送信要求を受信した場合、前記管理テーブルを参照して、前記第２のリカバリポイントに対応する前記第２の識別番号が付与された前記第２のリカバリポイントジャーナルを送信する
    ことを特徴とするストレージシステム。
  13. 請求項１２に記載のストレージシステムであって、
    リカバリ手段を有し、
    前記リカバリ手段は、
    前記計算機が、前記リカバリポイント提供手段から受信した前記第１の識別番号又は前記第２の識別番号に基づいて前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域のリカバリ要求を送信する場合、まず、前記リカバリ要求を受信し、該受信したリカバリ要求に含まれる前記第１の識別番号又は前記第２の識別番号と、前記管理テーブルとに基づいて、前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号を取得し、次いで該取得したシーケンス番号よりも小さいシーケンス番号を持つスナップショットを、スナップショットを管理するスナップショット管理表から検索し、次いで該検索したスナップショットに対応するスナップショットボリュームに格納されているデータを前記リカバリ要求に含まれるリカバリ先ボリューム番号に対応付けられたリカバリ先ボリュームにコピーし、最後に前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号よりも小さいシーケンス番号から前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号までの間に存在するジャーナルをシーケンス順に前記リカバリ先ボリュームに適用することにより、前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域をリカバリする
    ことを特徴とするストレージシステム。
  14. 請求項１０に記載のストレージシステムであって、
    前記管理テーブルは、
    前記検出手段が検出する複数の前記ストレージシステムに関する状態変化のそれぞれに対して、前記状態変化の種別を示す識別情報を格納し、
    前記検出手段は、
    前記管理テーブルを参照して、前記ストレージシステム内で送受信される制御情報と、前記管理テーブルに格納される前記識別情報とが一致する場合、前記ストレージシステムに関する状態変化として検出する
    ことを特徴とするストレージシステム。
  15. 請求項１に記載のストレージシステムであって、
    前記ジャーナル作成手段は、
    前記第２の識別番号にはプレフィックスを付与することにより、前記第１の識別番号と前記第２の識別番号とを区別して前記管理テーブルに記録する
    ことを特徴とするストレージシステム。
  16. 請求項１に記載のストレージシステムであって、
    前記第１の識別番号及び前記第２の識別番号は、互いに区別される番号が予め設定されており、
    前記ジャーナル作成手段は、
    前記第２の識別番号を前記互いに区別される番号のうちの何れかの番号にすることにより、前記第１の識別番号と前記第２の識別番号とを区別して前記管理テーブルに記録する
    ことを特徴とするストレージシステム。
  17. 請求項１に記載のストレージシステムであって、
    前記管理テーブルは、
    前記リカバリポイントに関する情報及び前記識別番号に対応付けてデータ破壊可能性有無情報を格納し、
    前記検出手段は、
    前記ストレージシステムにおけるデータの破壊可能性の有無を検出し、
    前記ジャーナル作成手段は、
    前記検出手段により検出されたデータの破壊可能性の有無に基づいて、データ破壊可能性有無情報を作成し、該作成したデータ破壊可能性有無情報を、前記リカバリポイントに関する情報及び前記識別番号に対応付けて前記管理テーブルに記録する
    ことを特徴とするストレージシステム。
  18. 計算機と、他のストレージシステムとに接続されるストレージシステムであって、
    前記計算機が使用するデータを格納する第１の記憶領域と、
    前記第１の記憶領域内のデータに対する前記計算機からの書き込み要求があった場合に形成されるジャーナルであって、書き込みデータ及び前記書き込みデータに関する制御情報に対応したジャーナルと、データリカバリを実行するための目標点となるリカバリポイントが設定された場合に形成されるリカバリポイントジャーナルとを格納する第２の記憶領域と、
    前記第１の記憶領域内の任意の時点におけるデータを複製して格納する第３の記憶領域と、
    前記ジャーナル及び前記リカバリポイントジャーナルを作成するジャーナル作成手段と、
    前記リカバリポイントに関する情報及び前記リカバリポイントに関する情報に対応付けられた識別番号を格納する管理テーブルと、
    前記他のストレージシステムに関する状態変化を検出する検出手段と
    を有し、
    前記計算機からリカバリポイントの設定要求を受け付けると、第１のリカバリポイントジャーナルを作成し、該作成した第１のリカバリポイントジャーナルに含まれる情報と、前記計算機から指定され、前記第１のリカバリポイントに対応する第１の識別番号とを対応付けて前記管理テーブルに記録し、
    前記検出手段により前記他のストレージシステムに関する状態変化が検出されると、第２のリカバリポイントジャーナルを作成し、該作成した第２のリカバリポイントジャーナルに含まれる情報と、前記第１の識別番号とは異なり、前記第２のリカバリポイントに対応する第２の識別番号とを対応付けて前記管理テーブルに記録する
    ことを特徴とするストレージシステム。
  19. 請求項１８に記載のストレージシステムであって、
    前記他のストレージシステムは、
    当該ストレージシステムから転送される前記第１の記憶領域内のデータを格納する第４の記憶領域を有し、
    前記検出手段は、
    前記第４の記憶領域に対するデータの格納が停止されたことを前記他のストレージシステムに関する状態変化として検出し、
    前記ジャーナル作成手段は、
    前記検出手段が前記状態変化として検出した時点を前記第２のリカバリポイントとして決定する
    ことを特徴とするストレージシステム。
  20. 請求項１８に記載のストレージシステムであって、
    リカバリポイント提供手段を有し、
    前記リカバリポイント提供手段は、
    前記計算機から前記第２のリカバリポイントの情報の送信要求を受信した場合、前記管理テーブルを参照して、前記第２のリカバリポイントに対応する前記第２の識別番号が付与された前記第２のリカバリポイントジャーナルを送信する
    ことを特徴とするストレージシステム。
  21. 請求項２０に記載のストレージシステムであって、
    リカバリ手段を有し、
    前記リカバリ手段は、
    前記計算機が、前記リカバリポイント提供手段から受信した前記第１の識別番号又は前記第２の識別番号に基づいて前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域のリカバリ要求を送信する場合、まず、前記リカバリ要求を受信し、該受信したリカバリ要求に含まれる前記第１の識別番号又は前記第２の識別番号と、前記管理テーブルとに基づいて、前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号を取得し、次いで該取得したシーケンス番号よりも小さいシーケンス番号を持つスナップショットを、スナップショットを管理するスナップショット管理表から検索し、次いで該検索したスナップショットに対応するスナップショットボリュームに格納されているデータを前記リカバリ要求に含まれるリカバリ先ボリューム番号に対応付けられたリカバリ先ボリュームにコピーし、最後に前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号よりも小さいシーケンス番号から前記第１のリカバリポイント又は前記第２のリカバリポイントに対応する前記第１のリカバリポイントジャーナル又は前記第２のリカバリポイントジャーナルのシーケンス番号までの間に存在するジャーナルをシーケンス順に前記リカバリ先ボリュームに適用することにより、前記第１のリカバリポイント又は前記第２のリカバリポイントにおける前記第１の記憶領域をリカバリする
    ことを特徴とするストレージシステム。
  22. 請求項１８に記載のストレージであって、
    前記検出手段は、
    二重化されているストレージシステムの片側障害を、前記ストレージシステムに関する状態変化として検出し、
    前記ジャーナル作成手段は、
    前記検出手段が前記状態変化として検出した時点を前記第２のリカバリポイントとして決定し、該決定した第２のリカバリポイントに対応する前記第２のリカバリポイントジャーナルを作成する
    ことを特徴とするストレージシステム。
  23. 計算機に接続されるストレージシステムにおけるデータ制御方法であって、
    第１の記憶領域が、前記計算機が使用するデータを格納する第１のステップと、
    第２の記憶領域が、前記第１の記憶領域内のデータに対する前記計算機からの書き込み要求があった場合に形成されるジャーナルであって、書き込みデータ及び前記書き込みデータに関する制御情報に対応したジャーナルと、データリカバリを実行するための目標点となるリカバリポイントが設定された場合に形成されるリカバリポイントジャーナルとを格納する第２のステップと、
    ジャーナル作成手段が、前記ジャーナル及び前記リカバリポイントジャーナルを作成する第３のステップと、
    管理テーブルが、前記リカバリポイントに関する情報及び前記リカバリポイントに関する情報に対応付けられた識別番号を格納する第４のステップと、
    検出手段が、前記ストレージシステムに関する状態変化を検出する第５のステップと
    を備え、
    前記第３のステップにおいて、前記ジャーナル作成手段は、
    前記計算機からリカバリポイントの設定要求を受け付けると、第１のリカバリポイントジャーナルを作成し、該作成した第１のリカバリポイントジャーナルに含まれる情報と、前記計算機から指定され、前記第１のリカバリポイントに対応する第１の識別番号とを対応付けて前記管理テーブルに記録し、
    前記検出手段により前記ストレージシステムに関する状態変化が検出されると、第２のリカバリポイントジャーナルを作成し、該作成した第２のリカバリポイントジャーナルに含まれる情報と、前記第１の識別番号とは異なり、前記第２のリカバリポイントに対応する第２の識別番号とを対応付けて前記管理テーブルに記録する
    ことを特徴とするデータ制御方法。
JP2006021650A 2006-01-31 2006-01-31 ストレージシステム Expired - Fee Related JP4800046B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2006021650A JP4800046B2 (ja) 2006-01-31 2006-01-31 ストレージシステム
US11/385,860 US7571348B2 (en) 2006-01-31 2006-03-22 Storage system creating a recovery request point enabling execution of a recovery
EP06253263A EP1814032A3 (en) 2006-01-31 2006-06-23 Recovery for storage system
US12/500,986 US8327183B2 (en) 2006-01-31 2009-07-10 Storage system creating a recovery request enabling execution of a recovery and comprising a switch that detects recovery request point events

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006021650A JP4800046B2 (ja) 2006-01-31 2006-01-31 ストレージシステム

Publications (2)

Publication Number Publication Date
JP2007206759A JP2007206759A (ja) 2007-08-16
JP4800046B2 true JP4800046B2 (ja) 2011-10-26

Family

ID=37965282

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006021650A Expired - Fee Related JP4800046B2 (ja) 2006-01-31 2006-01-31 ストレージシステム

Country Status (3)

Country Link
US (2) US7571348B2 (ja)
EP (1) EP1814032A3 (ja)
JP (1) JP4800046B2 (ja)

Families Citing this family (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7146524B2 (en) 2001-08-03 2006-12-05 Isilon Systems, Inc. Systems and methods for providing a distributed file system incorporating a virtual hot spare
US7685126B2 (en) 2001-08-03 2010-03-23 Isilon Systems, Inc. System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system
CN1692356B (zh) * 2002-11-14 2014-06-04 易斯龙系统公司 用于对现存文件重新条带化的方法
US8238350B2 (en) 2004-10-29 2012-08-07 Emc Corporation Message batching with checkpoints systems and methods
US8055711B2 (en) 2004-10-29 2011-11-08 Emc Corporation Non-blocking commit protocol systems and methods
US8051425B2 (en) 2004-10-29 2011-11-01 Emc Corporation Distributed system with asynchronous execution systems and methods
US8825837B2 (en) * 2010-04-21 2014-09-02 International Business Machines Corporation Notice of restored malfunctioning links
US7917474B2 (en) 2005-10-21 2011-03-29 Isilon Systems, Inc. Systems and methods for accessing and updating distributed data
US7788303B2 (en) 2005-10-21 2010-08-31 Isilon Systems, Inc. Systems and methods for distributed system scanning
US7551572B2 (en) 2005-10-21 2009-06-23 Isilon Systems, Inc. Systems and methods for providing variable protection
US7797283B2 (en) 2005-10-21 2010-09-14 Isilon Systems, Inc. Systems and methods for maintaining distributed data
KR100762689B1 (ko) * 2005-12-08 2007-10-01 삼성에스디아이 주식회사 휴대용 표시장치
US7848261B2 (en) 2006-02-17 2010-12-07 Isilon Systems, Inc. Systems and methods for providing a quiescing protocol
US7756898B2 (en) 2006-03-31 2010-07-13 Isilon Systems, Inc. Systems and methods for notifying listeners of events
JP5124989B2 (ja) * 2006-05-26 2013-01-23 日本電気株式会社 ストレージシステム及びデータ保護方法とプログラム
US8539056B2 (en) 2006-08-02 2013-09-17 Emc Corporation Systems and methods for configuring multiple network interfaces
US7899800B2 (en) 2006-08-18 2011-03-01 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US7590652B2 (en) 2006-08-18 2009-09-15 Isilon Systems, Inc. Systems and methods of reverse lookup
US7882071B2 (en) * 2006-08-18 2011-02-01 Isilon Systems, Inc. Systems and methods for a snapshot of data
JP2008046986A (ja) * 2006-08-18 2008-02-28 Hitachi Ltd ストレージシステム
US7822932B2 (en) 2006-08-18 2010-10-26 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US7680842B2 (en) 2006-08-18 2010-03-16 Isilon Systems, Inc. Systems and methods for a snapshot of data
US7680836B2 (en) 2006-08-18 2010-03-16 Isilon Systems, Inc. Systems and methods for a snapshot of data
US7953704B2 (en) 2006-08-18 2011-05-31 Emc Corporation Systems and methods for a snapshot of data
US7676691B2 (en) 2006-08-18 2010-03-09 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US8620970B2 (en) * 2006-10-03 2013-12-31 Network Appliance, Inc. Methods and apparatus for changing versions of a filesystem
US8286029B2 (en) * 2006-12-21 2012-10-09 Emc Corporation Systems and methods for managing unavailable storage devices
US20080155191A1 (en) * 2006-12-21 2008-06-26 Anderson Robert J Systems and methods for providing heterogeneous storage systems
US7593938B2 (en) 2006-12-22 2009-09-22 Isilon Systems, Inc. Systems and methods of directory entry encodings
US7509448B2 (en) 2007-01-05 2009-03-24 Isilon Systems, Inc. Systems and methods for managing semantic locks
US7779048B2 (en) 2007-04-13 2010-08-17 Isilon Systems, Inc. Systems and methods of providing possible value ranges
US8966080B2 (en) 2007-04-13 2015-02-24 Emc Corporation Systems and methods of managing resource utilization on a threaded computer system
US7900015B2 (en) 2007-04-13 2011-03-01 Isilon Systems, Inc. Systems and methods of quota accounting
US7966289B2 (en) 2007-08-21 2011-06-21 Emc Corporation Systems and methods for reading objects in a file system
US7882068B2 (en) 2007-08-21 2011-02-01 Isilon Systems, Inc. Systems and methods for adaptive copy on write
US7949692B2 (en) 2007-08-21 2011-05-24 Emc Corporation Systems and methods for portals into snapshot data
US8738575B2 (en) * 2007-09-17 2014-05-27 International Business Machines Corporation Data recovery in a hierarchical data storage system
JP5180578B2 (ja) * 2007-12-21 2013-04-10 株式会社野村総合研究所 業務継続システム
US7877360B2 (en) * 2008-01-15 2011-01-25 International Business Machines Corporation Recovery point identification in CDP environments
JP5159356B2 (ja) * 2008-02-13 2013-03-06 株式会社日立製作所 リモートコピーシステム及び計算機システム
US7949636B2 (en) 2008-03-27 2011-05-24 Emc Corporation Systems and methods for a read only mode for a portion of a storage system
US7870345B2 (en) 2008-03-27 2011-01-11 Isilon Systems, Inc. Systems and methods for managing stalled storage devices
US7953709B2 (en) 2008-03-27 2011-05-31 Emc Corporation Systems and methods for a read only mode for a portion of a storage system
US7984324B2 (en) * 2008-03-27 2011-07-19 Emc Corporation Systems and methods for managing stalled storage devices
US8250031B2 (en) 2008-08-26 2012-08-21 Hitachi, Ltd. Low traffic failback remote copy
EP2804350B1 (en) 2009-04-01 2019-07-24 Nicira, Inc. Method and apparatus for implementing and managing virtual switches
US20100275219A1 (en) * 2009-04-23 2010-10-28 International Business Machines Corporation Scsi persistent reserve management
US8719885B2 (en) * 2009-11-30 2014-05-06 Echostar Technologies L.L.C. Systems and methods for accessing recoverable program content
US8315991B2 (en) 2010-04-20 2012-11-20 International Business Machines Corporation Detecting inadvertent or malicious data corruption in storage subsystems and recovering data
US8717895B2 (en) 2010-07-06 2014-05-06 Nicira, Inc. Network virtualization apparatus and method with a table mapping engine
US8964528B2 (en) 2010-07-06 2015-02-24 Nicira, Inc. Method and apparatus for robust packet distribution among hierarchical managed switching elements
US9525647B2 (en) 2010-07-06 2016-12-20 Nicira, Inc. Network control apparatus and method for creating and modifying logical switching elements
US10103939B2 (en) 2010-07-06 2018-10-16 Nicira, Inc. Network control apparatus and method for populating logical datapath sets
US9680750B2 (en) 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
US20120254118A1 (en) * 2011-03-31 2012-10-04 Microsoft Corporation Recovery of tenant data across tenant moves
US9043452B2 (en) 2011-05-04 2015-05-26 Nicira, Inc. Network control apparatus and method for port isolation
AU2013249152B2 (en) 2012-04-18 2016-04-28 Nicira, Inc. Using transactions to minimize churn in a distributed network control system
US9678863B2 (en) * 2012-06-12 2017-06-13 Sandisk Technologies, Llc Hybrid checkpointed memory
US9141495B2 (en) * 2013-03-12 2015-09-22 Dell Products, Lp Automatic failure recovery using snapshots and replicas
US9098444B2 (en) 2013-03-12 2015-08-04 Dell Products, Lp Cooperative data recovery in a storage stack
US9514007B2 (en) 2013-03-15 2016-12-06 Amazon Technologies, Inc. Database system with database engine and separate distributed storage service
US11030055B2 (en) 2013-03-15 2021-06-08 Amazon Technologies, Inc. Fast crash recovery for distributed database systems
US10180951B2 (en) 2013-03-15 2019-01-15 Amazon Technologies, Inc. Place snapshots
US10747746B2 (en) 2013-04-30 2020-08-18 Amazon Technologies, Inc. Efficient read replicas
US9760596B2 (en) 2013-05-13 2017-09-12 Amazon Technologies, Inc. Transaction ordering
US9559870B2 (en) 2013-07-08 2017-01-31 Nicira, Inc. Managing forwarding of logical network traffic between physical domains
US10218564B2 (en) 2013-07-08 2019-02-26 Nicira, Inc. Unified replication mechanism for fault-tolerance of state
US9973382B2 (en) 2013-08-15 2018-05-15 Nicira, Inc. Hitless upgrade for network control applications
US10216949B1 (en) 2013-09-20 2019-02-26 Amazon Technologies, Inc. Dynamic quorum membership changes
US9952937B2 (en) * 2013-10-28 2018-04-24 Openet Telecom Ltd. Method and system for reducing journaling log activity in databases
WO2015066698A1 (en) * 2013-11-04 2015-05-07 Falconstor, Inc. Snapshots using copy on predicted write
US9223843B1 (en) 2013-12-02 2015-12-29 Amazon Technologies, Inc. Optimized log storage for asynchronous log updates
US9367260B1 (en) * 2013-12-13 2016-06-14 Emc Corporation Dynamic replication system
US10164894B2 (en) 2014-05-05 2018-12-25 Nicira, Inc. Buffered subscriber tables for maintaining a consistent network state
JP6218668B2 (ja) * 2014-05-12 2017-10-25 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ メディアへのファイル書き込みに伴うメタ情報の効率的な利用
US10210171B2 (en) 2014-06-18 2019-02-19 Microsoft Technology Licensing, Llc Scalable eventual consistency system using logical document journaling
US10318618B2 (en) * 2014-06-18 2019-06-11 Microsoft Technology Licensing, Llc Consistent views of partitioned data in eventually consistent systems
US9967134B2 (en) 2015-04-06 2018-05-08 Nicira, Inc. Reduction of network churn based on differences in input state
WO2016167762A1 (en) * 2015-04-15 2016-10-20 Hitachi, Ltd. Method and apparatus for volume type change
US10204122B2 (en) 2015-09-30 2019-02-12 Nicira, Inc. Implementing an interface between tuple and message-driven control entities
US11019167B2 (en) 2016-04-29 2021-05-25 Nicira, Inc. Management of update queues for network controller
US10459632B1 (en) * 2016-09-16 2019-10-29 EMC IP Holding Company LLC Method and system for automatic replication data verification and recovery
JP2018160156A (ja) * 2017-03-23 2018-10-11 東芝メモリ株式会社 メモリシステム
US10437691B1 (en) * 2017-03-29 2019-10-08 Veritas Technologies Llc Systems and methods for caching in an erasure-coded system
CN107643882A (zh) * 2017-09-29 2018-01-30 昂纳信息技术（深圳）有限公司 一种数据可靠性的存储及恢复方法、系统及存储装置
US10671494B1 (en) * 2017-11-01 2020-06-02 Pure Storage, Inc. Consistent selection of replicated datasets during storage system recovery
US10909073B2 (en) * 2019-04-18 2021-02-02 EMC IP Holding Company LLC Automatic snapshot and journal retention systems with large data flushes using machine learning
US11238063B2 (en) * 2019-07-25 2022-02-01 EMC IP Holding Company LLC Provenance-based replication in a storage system
US11762807B2 (en) * 2021-01-21 2023-09-19 Dell Products, L.P. Method and apparatus for deterministically identifying sets of snapshots on a storage system

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5799141A (en) * 1995-06-09 1998-08-25 Qualix Group, Inc. Real-time data protection system and method
US6766470B1 (en) * 2000-03-29 2004-07-20 Intel Corporation Enhancing reliability and robustness of a cluster
JP3974538B2 (ja) * 2003-02-20 2007-09-12 株式会社日立製作所 情報処理システム
JP4165747B2 (ja) 2003-03-20 2008-10-15 株式会社日立製作所 記憶システム、制御装置及び制御装置のプログラム
US7139845B2 (en) * 2003-04-29 2006-11-21 Brocade Communications Systems, Inc. Fibre channel fabric snapshot service
US20050015416A1 (en) * 2003-07-16 2005-01-20 Hitachi, Ltd. Method and apparatus for data recovery using storage based journaling
US20050022213A1 (en) * 2003-07-25 2005-01-27 Hitachi, Ltd. Method and apparatus for synchronizing applications for data recovery using storage based journaling
US7111136B2 (en) 2003-06-26 2006-09-19 Hitachi, Ltd. Method and apparatus for backup and recovery system using storage based journaling
JP4267420B2 (ja) * 2003-10-20 2009-05-27 株式会社日立製作所 ストレージ装置及びバックアップ取得方法
US7254683B2 (en) * 2003-11-03 2007-08-07 International Business Machines Corporation Speculative data mirroring apparatus method and system
JP4551096B2 (ja) * 2004-02-03 2010-09-22 株式会社日立製作所 ストレージサブシステム
US7490103B2 (en) * 2004-02-04 2009-02-10 Netapp, Inc. Method and system for backing up data
US7162602B2 (en) * 2004-03-16 2007-01-09 Hitachi, Ltd. More granular and more efficient write protection for disk volumes
US7167880B2 (en) * 2004-04-14 2007-01-23 Hitachi, Ltd. Method and apparatus for avoiding journal overflow on backup and recovery system using storage based journaling
JP4641443B2 (ja) * 2005-03-28 2011-03-02 富士通株式会社 ログ情報管理装置、ログ情報管理方法およびログ情報管理プログラム
JP2006318012A (ja) * 2005-05-10 2006-11-24 Hitachi Ltd ディスク制御システム
US7519858B2 (en) * 2006-08-18 2009-04-14 Computer Associates Think, Inc. Selective file restoration from incremental backups

Also Published As

Publication number Publication date
JP2007206759A (ja) 2007-08-16
EP1814032A2 (en) 2007-08-01
US20090276661A1 (en) 2009-11-05
US7571348B2 (en) 2009-08-04
US8327183B2 (en) 2012-12-04
US20070179994A1 (en) 2007-08-02
EP1814032A3 (en) 2008-07-02

Similar Documents

Publication Publication Date Title
JP4800046B2 (ja) ストレージシステム
US7725776B2 (en) Method for displaying pair state of copy pairs
JP4800031B2 (ja) ストレージシステム及びスナップショット管理方法
JP4405509B2 (ja) データ管理方法、システム、およびプログラム（リモート記憶位置にフェイルオーバを行うための方法、システム、およびプログラム）
JP4321705B2 (ja) スナップショットの取得を制御するための装置及び記憶システム
US8255647B2 (en) Journal volume backup to a storage device
US7827367B2 (en) Backup control method for acquiring plurality of backups in one or more secondary storage systems
US8001344B2 (en) Storage control apparatus, storage control program, and storage control method
US9442809B2 (en) Management computer used to construct backup configuration of application data
US20070115738A1 (en) Failure management method for a storage system
JP2005196683A (ja) 情報処理システム、情報処理装置、及び情報処理システムの制御方法
JP2006023889A (ja) リモートコピーシステム及び記憶装置システム
JP2004252686A (ja) 情報処理システム
US20200192693A1 (en) Container provision support system and container provision support method
US7200725B2 (en) Storage remote copy system
US8533411B2 (en) Multiple backup processes
JP2006011811A (ja) 記憶制御システム及び記憶制御方法
US20090249010A1 (en) Apparatus and method for controlling copying
JP4790283B2 (ja) ストレージサブシステム及びストレージシステム
JP6668733B2 (ja) 制御装置、管理装置、ストレージシステム、制御プログラム、管理プログラム、制御方法、および管理方法
JP2024049934A (ja) 計算機システム及びデータ制御方法
JP2021086331A (ja) 情報処理装置、情報処理システム及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20081021

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20090206

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20090216

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110303

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110316

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110516

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110712

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110803

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140812

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees