特開 2023-179097 ストレージシステムおよびストレージシステムのリストア方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023179097

(43)【公開日】2023-12-19

(54)【発明の名称】ストレージシステムおよびストレージシステムのリストア方法

(51)【国際特許分類】

   G06F 11/14 20060101AFI20231212BHJP

   G06F 3/06 20060101ALI20231212BHJP

【ＦＩ】

G06F11/14 648

G06F3/06 301X

G06F3/06 304F

G06F3/06 304B

G06F11/14 656

G06F11/14 664

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2022092162

(22)【出願日】2022-06-07

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】藤井 裕大

(72)【発明者】

【氏名】新井 政弘

(72)【発明者】

【氏名】出口 彰

(57)【要約】

【課題】クラウドからリストアを行う場合のデータ転送量を削減する。
【解決手段】論理ボリュームのスナップショットの取得は、スナップショットの実データの格納場所と当該スナップショットと親子関係を有する他のスナップショットを特定する参照先とを少なくとも含む各々のスナップショットのカタログ情報を生成することと、スナップショットの実データを物理記憶デバイス及び／又はクラウドサービスに格納することとを含み、複数のスナップショットのいずれかを指定してリストアを行う場合に、カタログ情報を参照して実データの格納場所を特定して物理記憶デバイスに保存された実データを取得し、実データが物理記憶デバイスに保存されていない実データをクラウドサービスから取得する。
【選択図】図１７

【特許請求の範囲】

【請求項1】

物理記憶デバイスと、
前記物理記憶デバイスの記憶領域を用いて構成した論理ボリュームを提供するプロセッサと、
ストレージを提供するクラウドサービスに接続するネットワークインターフェースと、を備え、
前記プロセッサは、
前記論理ボリュームのスナップショットを取得する機能を有し、
前記スナップショットの取得は、前記スナップショットの実データの格納場所と当該スナップショットと親子関係を有する他のスナップショットを特定する参照先とを少なくとも含む各々のスナップショットのカタログ情報を生成することと、前記スナップショットの実データを前記物理記憶デバイス及び／又は前記クラウドサービスに格納することとを含み、
複数の前記スナップショットのいずれかを指定してリストアを行う場合に、前記カタログ情報を参照して実データの格納場所を特定して前記物理記憶デバイスに保存された実データを取得し、前記実データが物理記憶デバイスに保存されていない実データを前記クラウドサービスから取得することを特徴とするストレージシステム。

【請求項2】

請求項１に記載のストレージシステムであって、
前記カタログ情報の参照先は、カタログ情報にかかるスナップショットより先に作成されたスナップショットを参照しており、
前記プロセッサは、複数の前記スナップショットのいずれかを指定してリストアを行う場合に、
前記リストア対象のスナップショットを含む複数のカタログ情報を参照してリストア対象のスナップショットより前の時刻で作成されたスナップショットを参照するとともに、
前記リストア対象のスナップショットより後の時刻で作成したスナップショットのカタログ情報であり前記リストア対象スナップショットを参照するスナップショットを用いることを特徴とするストレージシステム。

【請求項3】

請求項１に記載のストレージシステムであって、
前記リストア対象のスナップショットと親子関係によりつながっており前記物理記憶デバイスに実データが記憶されているスナップショットを特定して、その実データを前記リストア対象のスナップショットの復元に用いるために取得し、
前記記憶デバイスに格納されていない実データについて、前記リストア対象のスナップショットと親子関係によりつながっており前記クラウドサービスに実データが記憶されているスナップショットを特定して、その実データを前記リストア対象のスナップショットの復元に用いるために取得する
ことを特徴とするストレージシステム。

【請求項4】

請求項１に記載のストレージシステムであって、
前記プロセッサは、
前記スナップショットを取得する場合に、当該スナップショットにおいて前回のスナップショットから更新されているデータの位置である更新データ位置を示すメタ情報を格納し、
前記リストアを行う場合に、前記メタ情報及び前記カタログ情報を参照し、前記リストアに用いる１又は複数のスナップショットの各々について、リストア先のボリュームにおいて有効なデータの位置を抽出し、前記有効なデータを選択的に前記クラウドサービスからの転送の対象とすることを特徴とするストレージシステム。

【請求項5】

請求項４に記載のストレージシステムであって、
前記プロセッサは、
リストア対象のスナップショットよりも古く且つ前記物理記憶デバイスに保存されたオンプレミスのスナップショットが存在するならば、当該オンプレミスのスナップショットに含まれるデータであってリストア先のボリュームにおいて有効なデータについては、前記クラウドサービス上のスナップショットからの転送の対象から除外することを特徴とするストレージシステム。

【請求項6】

請求項４に記載のストレージシステムであって、
前記プロセッサは、
更新データ位置が同一の複数のスナップショットが前記クラウドサービス上に存在するならば、最新のスナップショットについて当該更新データ位置のデータを有効なデータとし、他のスナップショットについて当該更新データ位置のデータを無効なデータとすることを特徴とするストレージシステム。

【請求項7】

請求項６に記載のストレージシステムであって、
前記プロセッサは、前記リストア先のボリュームの各ブロックについて有効データ決定済か有効データ未決定かを示す前方累積ビットマップを生成し、
新しいスナップショットから順に、当該スナップショットの更新データ位置であって前記前方累積ビットマップにおいて有効データ未決定のブロックを抽出し、抽出したブロックを当該スナップショットの有効なデータ位置とするとともに、抽出したブロックを有効データ決定済に更新する処理を行うことで、各スナップショットについて有効なデータ位置を決定することを特徴とするストレージシステム。

【請求項8】

請求項１に記載のストレージシステムであって、
前記プロセッサは、
前記カタログ情報を参照して、前記リストア対象のスナップショットから子世代側に辿って前記オンプレミスのスナップショットを探索し、
子世代側で見出した前記オンプレミスのスナップショットのうち、最も新しいスナップショットから親世代側に戻りつつ、リストアすべきデータと同一のデータが格納されているスナップショットを特定し、前記リストアすべきデータと同一のデータを前記有効なデータとして前記リストア先のボリュームに復元することを特徴とするストレージシステム。

【請求項9】

物理記憶デバイスの記憶領域を用いて構成した論理ボリュームを提供するプロセッサを備えるストレージシステムのリストア方法であって、
前記プロセッサが、
前記論理ボリュームのスナップショットを取得する場合に、前記スナップショットの実データの格納場所と当該スナップショットと親子関係を有する他のスナップショットを特定する参照先とを少なくとも含む各々のスナップショットのカタログ情報を生成するステップと、前記スナップショットの実データを前記物理記憶デバイス及び／又はクラウドサービスに格納するステップとを含み、
複数の前記スナップショットのいずれかを指定してリストアを行う場合に、前記カタログ情報を参照して実データの格納場所を特定して前記物理記憶デバイスに保存された実データを取得し、前記実データが物理記憶デバイスに保存されていない実データを前記クラウドサービスから取得するステップと、
を含むことを特徴とするストレージシステムのリストア方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストレージシステムおよびストレージシステムのリストア方法に関する。

【背景技術】

【0002】

近年、オンプレミスのIT資産とパブリッククラウドのサービスとを、コストや用途に応じて組み合わせて利用するハイブリッドクラウドと呼ばれる運用形態が登場している。ストレージにおいては、オンプレミスの装置は、I/Oアクセスは高速だが、ビットコストが高く事前の容量設計も必要である。これに対し、クラウドサービスは、性能は距離や通信帯域に制限されるものの、ビットコストが安く容量設計が不要であるという特徴がある。代表的なサービスにデータをオブジェクト形式にて格納し、REST APIにてアクセスするオブジェクトストアサービスがある。オブジェクトストアはほぼ無制限の容量を利用することができるため事前の容量設計が不要であり、また他のクラウドストレージサービスに比べビットコストが安価であることが特徴である。

【0003】

オブジェクトストアの利用方法として、オンプレミスのストレージ装置のバックアップとして利用する方法が考えられる。オブジェクトストアの利用に関し、特許文献１には、「オンプレミスのストレージ装置の容量の節約と、オンプレミスのストレージ装置の高アクセス性能と、オンプレミスのリソースに障害があったとき、クラウド上のデータを用いて、高速かつ正確に業務を再開することとを実現する。」、「プロセッサは、仮想ボリュームである第一ボリュームを提供し、第一ボリュームと、他のストレージシステムにより提供される第二ボリュームとのコピーペアを設定する。第一ボリュームへのライトデータは、コピーペアに基づいて、ネットワークを介して第二ボリュームへ転送される。プロセッサは、第二ボリュームへ書き込まれるデータの一部をメモリへ書き込み、メモリへ書き込まれたデータを記憶デバイスへ書き込む。」との記載がある。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１８－１２９０７４号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、従来の技術をクラウドバックアップに用いようとした場合には、リストア時のデータ転送量が多いという課題がある。増分でバックアップされたデータをリストアするには古い世代から順に１つずつ戻す必要がある。なぜならば一度バックアップされたデータは他の世代に含まれないからである。従い、この方法でバックアップを続けた場合、100回目には100世代分のデータが蓄積され、リストア時にはこれを順に戻さなければならなくなる。

【0006】

そこで、本発明では、クラウドからリストアを行う場合のデータ転送量を削減することを目的とする。

【課題を解決するための手段】

【0007】

上記目的を達成するために、代表的な本発明のストレージシステムの一つは、物理記憶デバイスと、前記物理記憶デバイスの記憶領域を用いて構成した論理ボリュームを提供するプロセッサと、ストレージを提供するクラウドサービスに接続するネットワークインターフェースと、を備え、前記プロセッサは、前記論理ボリュームのスナップショットを取得する機能を有し、前記スナップショットの取得は、前記スナップショットの実データの格納場所と当該スナップショットと親子関係を有する他のスナップショットを特定する参照先とを少なくとも含む各々のスナップショットのカタログ情報を生成することと、前記スナップショットの実データを前記物理記憶デバイス及び／又は前記クラウドサービスに格納することとを含み、複数の前記スナップショットのいずれかを指定してリストアを行う場合に、前記カタログ情報を参照して実データの格納場所を特定して前記物理記憶デバイスに保存された実データを取得し、前記実データが物理記憶デバイスに保存されていない実データを前記クラウドサービスから取得することを特徴とする。
また、代表的な本発明のストレージシステムのリストア方法の一つは、物理記憶デバイスの記憶領域を用いて構成した論理ボリュームを提供するプロセッサを備えるストレージシステムのリストア方法であって、前記プロセッサが、前記論理ボリュームのスナップショットを取得する場合に、前記スナップショットの実データの格納場所と当該スナップショットと親子関係を有する他のスナップショットを特定する参照先とを少なくとも含む各々のスナップショットのカタログ情報を生成するステップと、前記スナップショットの実データを前記物理記憶デバイス及び／又はクラウドサービスに格納するステップとを含み、複数の前記スナップショットのいずれかを指定してリストアを行う場合に、前記カタログ情報を参照して実データの格納場所を特定して前記物理記憶デバイスに保存された実データを取得し、前記実データが物理記憶デバイスに保存されていない実データを前記クラウドサービスから取得するステップと、を含むことを特徴とする。

【発明の効果】

【0008】

本発明によれば、クラウドからリストアを行う場合のデータ転送量を削減できる。上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。

【図面の簡単な説明】

【0009】

【図1】本発明の実施例におけるストレージシステムとオブジェクトストアを提供するクラウドサービスとの接続関係、およびその構成全体像を示したものである。

【図2】本発明の実施例におけるクラウドサービスが提供するサービス群を具体的に示したものである。

【図3】本発明の実施例におけるストレージシステムで動作するI/Oコントロールプログラムの機能構成を示した図である。

【図4】本発明の実施例におけるストレージシステムで動作するストレージ管理プログラムの機能構成を示した図である。

【図5A】本発明の実施例のストレージシステムにおいて、ドライブ群、ストレージプール、および論理ボリュームの関係を模式的に表したものである。

【図5B】本発明の実施例のストレージシステムにおいて、ドライブ群、ストレージプール、および論理ボリュームの関係を模式的に表したものである。

【図6】本発明の実施例におけるストレージシステムが、図５で述べた管理機構を用いてスナップショットを取得した際の状況を示した図である。

【図7】本発明の実施例において、図６のスナップショットを取得した際のマッピングテーブルの状態を示した図である。

【図8A】本発明の実施例のストレージシステムにおける、オブジェクトストアの登録画面を示した図である。

【図8B】本発明の実施例のストレージシステムにおける、オブジェクトストアの登録画面を示した図である。

【図9】本発明の実施例のストレージシステム10における、バックアップ処理を表すフローチャートである。

【図10A】本実施例のバックアップ処理において、バックアップ対象データが特定される様子を模式的に表したものである。

【図10B】本実施例のバックアップ処理において、バックアップ対象データが特定される様子を模式的に表したものである。

【図11】本実施例において、図９で示したオブジェクト変換とオブジェクト送信処理を表すフローチャートである。

【図12】本実施例のバックアップ処理において、メタデータの構造を示す図である。

【図13A】本実施例のバックアップ処理において、オブジェクトストアに格納されるカタログデータを示した図である。

【図13B】本実施例のバックアップ処理において、オブジェクトストアに格納されるカタログデータを示した図である。

【図14】本実施例におけるカタログデータ、メタデータ、バックアップデータ群がクラウドサービスのオブジェクトストアサービスに格納されている様子を模式的に表した図である。

【図15】本発明の実施例におけるバックアップのリストア選択画面である。

【図16】本実施例において、ストレージ管理プログラムがバックアップデータの一覧を取得する際のフローチャートである。

【図17】本発明の実施例におけるリストア手順を示すフローチャートである。

【図18】本実施例において、図１７に示した転送位置情報作成処理の動作に関するフローチャートである。

【図19】本実施例において、図１７に示した子世代バックアップデータ復元処理の動作に関するフローチャートである。

【図20】本実施例において、図１７に示したバックアップデータの取得復元処理の動作に関するフローチャートである。

【図21】本実施例において、オブジェクトストアからオブジェクトを取得し、同オブジェクトを変換して格納されていたバイナリデータを得るまでの処理を示すワークフローである。

【図22A】本実施例におけるリストア手順の事例である。

【図22B】本実施例におけるリストア手順の事例である。

【図22C】本実施例におけるリストア手順の事例である。

【図22D】本実施例におけるリストア手順の事例である。

【図23】本実施例におけるカタログデータを、データベースサービスが提供するNoSQLデータベースを用いて記録した様子を示した図である。

【発明を実施するための形態】

【0010】

以下、実施例を図面を用いて説明する。

【0011】

以下の説明では、「×××テーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「×××テーブル」を「×××情報」と呼ぶことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

【0012】

また、以下の説明では、要素の識別情報として、ＩＤが使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。

【0013】

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたＩＤを使用することがある。

【0014】

また、以下の説明では、Ｉ／Ｏ（Input/Output）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。

【0015】

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理又はシステムとしてもよい。また、プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

【実施例0016】

本実施例について、図１～図２３を用いて説明する。はじめに全体の構成を図１～４を用いて示し、次に図５～７にて、本発明のクラウドバックアップの前提となるデータ管理方法とスナップショットの仕組みについて述べる。図８以降を用いて、クラウドバックアップおよびリストアの動作について説明する。

【0017】

図１は本発明の実施例におけるストレージシステムと、オブジェクトストアを提供するクラウドサービスとの接続関係、およびその構成の全体像を示したものである。
ストレージシステム10は、RAIDによるデータ保護や、ストレージシステム内外でのデータコピー機能などを提供するディスクアレイ装置である。ストレージシステム10は、入出力制御サブシステムとして冗長化された複数のI/O制御サブシステム150a,150b（以下150）を備える。I/O制御サブシステム150は複数のドライブ140-0,140-1,・・・140-n（以下140）を接続し、所定の論理-物理ブロック変換処理を経て、論理ボリューム群を構成する。入出力制御サブシステム150は、プロセッサを備えており、プロセッサが後述するI/OコントロールプログラムP150を実行することで各種機能を実現する。

【0018】

ドライブ140はSSDやHDDなどの物理記憶デバイスであり、論理ボリュームは、I/O制御サブシステム150が提供する論理記憶デバイスである。
論理ボリューム群は、複数のホストインターフェース110a,110bと、ストレージネットワーク12を介して、サーバ群11に提供される。I/O制御サブシステム150は、サーバ群11からの読み書きI/Oに基づいて、ドライブ群140への読み書きI/Oを発行する。
またI/O制御サブシステム150は、クラウドサービス20へ接続するための複数のネットワークインターフェース120a,120b（以下120）を備える。ネットワークインターフェース120は、専用線13aまたはインターネット回線13bを通じクラウドサービスプロバイダによって提供されるクラウドサービス20へ接続する。

【0019】

ストレージシステム10は、装置の各種設定や監視を行うためのストレージ管理サブシステム160を備える。ストレージ管理サブシステム160はLAN 14を介して、端末17aから利用される。また、同システム160は、専用線15aやインターネット回線15bを介して、クラウドサービス20上で動作する運用管理システム18に接続される。運用管理システム18は別ネットワーク上の端末17bから利用される。なお、本実施例では、ストレージ管理サブシステム160はストレージシステム10の内部に図示したが、外部に構成されていても構わない。例えば、ストレージ管理サブシステムの一部は、クラウドサービス20上で動作することもある。ストレージ管理サブシステム160は、プロセッサを備えており、プロセッサが後述するストレージ管理プログラムP160を実行することで各種機能を実現する。

【0020】

その他に、ストレージシステム10は、他のストレージ装置と接続することもある。例えば、ストレージシステム10は接続インターフェース131を介して、ストレージシステム170が備える論理ボリューム171,172を接続し、自身のボリュームであるかのように制御することができる。例えば、ストレージシステム10は接続インターフェース132を介して別のストレージシステム180と接続し、ストレージ装置間ボリュームコピー機能を構成することができる。

【0021】

図２は本発明の実施例におけるクラウドサービスが提供するサービス群を具体的に示したものである。クラウドサービス20は、データストアサービスや、コンピューティングサービス、アプリケーションサービスなど、様々なマイクロサービスを提供する。このうち本発明に関するもののみを以下に説明する。

【0022】

ユーザ認証およびアクセス権限管理サービス210は、本クラウドサービス20の契約者が、各種サービスを利用するユーザごとにアクセスIDおよびシークレットキーを発行するときに利用する。また本サービス210は、アクセスIDに対する権限や、サービスリソースごとのアクセス許可ポリシーを定義するときに利用される。ユーザや各種サービスのアクセスは本サービス210を通じて制御される。

【0023】

データベースサービス220は、マネージドのSQLデータベースやNoSQLデータベースを提供するサービスである。
オブジェクトストアサービス230は、REST APIを用いてオブジェクト群を読み書きする容量無制限のストレージを提供するサービスである。
このほかに、各種サービスの利用開始/停止や、および利用状況を表示するコンソールサービス290がある。例えば契約者はこのコンソールサービス200からユーザ認証およびアクセス権限管理サービス210にアクセスしてユーザのアクセスIDを作成したり、オブジェクトストアサービス230の使用容量を確認したりすることができる。

【0024】

図３は、本発明の実施例におけるストレージシステム10で動作するI/OコントロールプログラムP150の機能構成を示した図である。
物理ボリュームコントロール機能群P1510は、ドライブ群140を制御する基本機能セットであり、ドライブパスやドライブ自身の障害処理を含むドライブI/O制御を行う。
論理ボリュームコントロール機能群P1520は、後述する容量仮想化機構を通じて論理ボリュームを構成し、ホストI/O制御やデータのコピーを行う基本機能セットである。
Point-in-Timeコピー機能P1530は、論理ボリュームの静止イメージ（以下スナップショット）を、論理ボリュームコントロール機能群P1520と連携してコピーとして保存する機能である。また、保存したスナップショットを元のボリュームにコピーバックする機能も備える。

【0025】

マッピング差分抽出機能P1531は、本発明のクラウドバックアップにおいて、スナップショットのマッピングテーブル間の差分を取得する機能である。
データ転送機能P1532は、本発明のクラウドバックアップにおいて、データをメモリやバッファ間でコピーする機能である。
オブジェクトメタデータ生成機能P1533は、本発明のクラウドバックアップにおいて、オブジェクト内の位置情報と論理ボリューム上のブロックのアドレス情報との対応を記録したメタデータを生成する機能である。

【0026】

カタログ生成機能P1534は、本発明のクラウドバックアップにおいて、バックアップの世代ごとの各種情報を保持するカタログデータを作成する機能である。
オブジェクト変換機能P1535は、ストレージシステム10内で保持するバイナリ形式のデータと、REST APIを用いて送信するオブジェクト形式のデータとを相互に変換する機能である。

【0027】

API通信管理機能P1536は、ネットワークインターフェース120を通じて、クラウドサービス間とREST APIにて通信処理する機能であり、エラー発生時の各種リカバリ処理を含む。
リストアプランナーP1537は、複数のカタログやストレージシステム10が保持するスナップショットを参照して、クラウドサービスからデータをリストアする際の手順を計画する機能である。
カタログ取得機能P1538は、リストアの際、オブジェクトストアから取得したカタログの内容を解釈する機能であり、オブジェクトメタデータ取得機能P1539は、リストアの際、オブジェクトストアから取得したメタデータの内容を解釈する機能である。

【0028】

図４は、本発明の実施例におけるストレージシステム10で動作するストレージ管理プログラムP160の機能構成を示した図である。
GUIおよびCLIコンポーネントP1610は、本管理機能を端末17a,17b、および運用管理システム18から利用できるようユーザインターフェースを提供する機能である。本実施例においては、例えばオブジェクトストアの登録画面やバックアップの設定画面等が本機能によって提供される。

【0029】

ネットワーク通信管理機能P1620は、クラウドサービス20と接続するためのネットワークインターフェース120の設定、およびLAN 14に接続するためのネットワーク設定を管理するための機能である。本実施例においては、例えばネットワークインターフェース120のIPアドレス、ネットマスク、ゲートウェイなどの設定に用いられる。

【0030】

ステータスモニタP1630は、ストレージシステム10が備えるハードウェアの健康状態や、各論理ボリュームやオブジェクトストアの使用容量および健康状態、ならびに実行中の処理の進捗やI/O速度などを表示する機能群である。本実施例においては、例えばオブジェクトストアの使用容量等が確認できる。

【0031】

ロギング機能P1640は各種処理のログを記録する機能である。本実施例においては、例えばバックアップ処理の開始/終了やエラー等が記録される。
ストレージボリューム管理機能P1650は、ドライブ群140、それらを用いて構成されるストレージプール、および、ストレージプールより作成される論理ボリューム、を構成および管理する機能である。ストレージプールについては図５を用いて後述する。

【0032】

オブジェクトストア登録管理機能P1660は、ストレージシステム10が利用するクラウドサービス20のオブジェクトストアサービスの情報を登録および管理する機能である。
バックアップ管理機能P1670は本実施例におけるクラウドバックアップのバックアップ設定を行う機能である。同様に、リストア管理機能P1680はクラウドバックアップのリストア指示を行う機能である。

【0033】

図５Ａ,図５Ｂは本発明の実施例のストレージシステム10における、ドライブ群140、ストレージプール600、および論理ボリューム500の関係を模式的に表したものである。はじめに図５Ａを用いてその関係を示し、次に図５Ｂを用いてデータが更新された際の状態を示す。

【0034】

ストレージシステム10は、複数のドライブ140を用いて、RAIDにてデータ保護を行うRAIDグループ300を構成する。RAIDグループ300に書き込まれるデータは、例えばRAID5などの所定の計算を経て複数のドライブ140に分散格納される。
RAIDグループ300は複数のドライブ140で構成されるため、一般には大きな容量を持つ。そのため、近年ではストレージプール600と呼ばれる論理的な管理機構を定義し、RAIDグループの容量を管理する。ストレージプール600では、容量を、より小さな所定のブロックサイズに分割し、これにプール上の論理アドレス（プールアドレス）を割り振って管理する。

【0035】

ストレージプール600は複数のRAIDグループで構成されることがある。またストレージシステム10は、複数のストレージプールを持つことが可能である。
論理ボリューム500は、Thin Provisioning技術で管理されるストレージプール600の容量を関連付けて構成された仮想デバイスである。論理ボリューム500には実体がないため、ホストが論理ボリューム500にデータを書き込むと、ストレージシステム10は、データをI/O制御サブシステム150上のメモリに一時的に格納し、その後、ストレージプール600のブロックの一部を論理ボリューム500の仮想ブロックとして割り当て、データを格納する。論理ボリューム500の仮想ブロックとストレージプール600上のブロックとの対応は、マッピングテーブル400によって管理される。

【0036】

図５Ａは、論理ボリューム500に、３つのデータが仮想ブロック50,51,52へ順に書き込まれ、それらがプールアドレスA00,A01,A02で示されるブロック60,61,62に格納されている様子を示している。両者のアドレスの関係情報はマッピングテーブル400に記録される（図ではその関係が点線にて示される）。

【0037】

図５Ｂは、本実施例のストレージシステムにおいて、論理ボリューム500のデータが更新されたときの様子を示している。ホストから仮想ブロック50に新たなデータ40が上書きされた場合、ストレージシステム10は、ストレージプール600の新たなブロック63を確保してデータを書き込む。そして、ストレージシステム10はマッピングテーブル400の情報を更新することで、仮想ブロック50を新たなブロック63に関連づけて管理する。なお、どこからも参照されないブロック60は、未使用ブロックと見なされ、ストレージシステムの処理プログラムが適切なタイミングにて回収し再利用する。

【0038】

図６は、本実施例におけるストレージシステム10が、図５Ａ、Ｂで述べた管理方式を用いてスナップショットを取得した様子を示した図である。
プライマリボリューム（P-VOL）510は、ホストからアクセスされる論理ボリュームである。スナップショット（SS01,SS02）511,512は、P-VOL 510のある過去の時点で取得された仮想的なコピーである。

【0039】

P-VOL 510のデータが「Ａ」「Ｂ」「Ｃ」であったときに取得された第1のスナップショット（SS01）が511である。ストレージシステム10は、その時点でのP-VOL 510のマッピング情報をコピーすることでSS01を作成する。その後、P-VOLの先頭データが「Ａ」から「Ａ’」に書き換わった後、取得された第2のスナップショット（SS02）が512である。ストレージシステム10は、同様にしてその時点でのP-VOL 510のマッピング情報をコピーすることでSS02を作成する。図６では、さらにその後、P-VOL 510の2つめのデータが「Ｂ」から「Ｂ’」に上書きされた様子を示している。

【0040】

図７はこのときのマッピングテーブル410を示したものである。P-VOL 510では書き込まれたデータが「Ａ’」「Ｂ’」「Ｃ」となっているので、マッピングテーブル410では、参照先ブロックのプールアドレスがB03, B04, B02となっている。SS01 511では、「Ａ」「Ｂ」「Ｃ」だったときの状態を保持しているため、参照先ブロックのプールアドレスはB00, B01, B02となっている。同様にSS02では、「Ａ’」「Ｂ」「Ｃ」に対応して、B03, B01, B02が対応づけられている。

【0041】

このようにマッピングテーブル410によって、スナップショットが管理される。なおブロックB00～B04は、P-VOLもしくはSS01,SS02から参照されているので、未使用ブロックと見なされることはない。
以降では、前述のスナップショットを用いて動作するクラウドバックアップについて述べる。

【0042】

図８Ａ，Ｂは、本実施例のストレージシステム10における、オブジェクトストアの登録画面を示したものである。本機能は図４に示したオブジェクトストア登録管理機能P1660およびGUIおよびCLIコンポーネントP1610によって提供される。

【0043】

図８Ａはオブジェクトストア登録時の最初の画面である。既に登録されているオブジェクトストアがある場合には、D101,D102のように一覧として表示される。新規にオブジェクトストアを追加する場合には、追加ボタンD111を押す。一方、既存のオブジェクトストアを削除する場合は、削除したいオブジェクトストアを選択し、削除ボタンD112を押すことで削除することができる。編集する場合には、編集したいオブジェクトストアを選択し、追加ボタンD111を押す。

【0044】

図８Ｂは、新規にオブジェクトストアを登録する画面であり、図８Ａにおいて追加ボタンD111を押すことで表示される。
はじめに本発明のストレージシステム10で利用可能なクラウドサービスをドロップダウンボックスD201より選択する。選択されたクラウドサービスに応じてD202～D206が表示される。
項目D207はオブジェクトストア一覧に表示する際の登録名を指定する。
項目D202は利用するクラウドサービスの利用地域を選択するドロップダウンボックスである。
項目D203およびD204は本オブジェクトストアにアクセスするために必要な認証情報であるIDとシークレットキーを登録する項目である。
項目D205は本オブジェクトストア上で、バックアップデータを格納するBucketを指定する項目である。Bucketはリージョンにおいて固有名である必要がある。このため、特に指定がなければ、ストレージシステムの製造番号やカスタマIDなど、他のユーザと重複しない固有情報から自動的に生成する。
項目D206はデータの暗号化方法を選択する。
さらにオプションとして、D211を押すことでタグを登録することができる。タグはName、Valueの一対で構成され、任意の個数を登録できる。
以上の内容で、オブジェクトストアを登録して良い場合にはボタンD212を、キャンセルする場合にはD213を押す。

【0045】

図９は、本実施例のストレージシステム10における、バックアップ処理を表すフローチャートである。本機能は、図４に示すバックアップ管理機能P1670が、設定されたバックアップスケジュールに基づき、図３に示すI/OコントロールプログラムP150に指示を出すことで実施される。動作に必要な情報は両者で適宜共有される。

【0046】

バックアップの最初の処理は、新旧２つのスナップショットからバックアップ対象データを抽出することである。具体的にはマッピングテーブル410を用いてスナップショットの差異を抽出することでデータを特定する。以下では、差異を抽出しオブジェクトストアに格納するまでの詳細な流れについて述べる。

【0047】

I/OコントロールプログラムP150は、動作指示を受けると、Point-in-Timeコピー機能P1530によって、バックアップする論理ボリュームのスナップショットを取得する（S2100）。具体的には図６、７で説明したように、対象ボリュームのマッピングテーブルをコピーすることにより実現される。
次に、I/OコントロールプログラムP150はバックアップ回数を確認する（S2110）。初回のバックアップの場合（S2110:初回）、同コントロールプログラムP150は、バックアップの比較元となる旧スナップショットにNULLを設定する（S2121）。これは、プールアドレスが無効値を意味する0で埋められたマッピングテーブルを持つ、ダミーのスナップショットである。

【0048】

2回目以降のバックアップだった場合（S2110:2回目以降）、同コントロールプログラムP150は、前回バックアップ時に取得したスナップショットを比較元に選択する（S2122）。
次に、I/OコントロールプログラムP150は、マッピング差分抽出機能P1531により、バックアップすべきデータを特定する（S2130）。具体的には、比較元スナップショットとバックアップ対象スナップショットとマッピングテーブルにおいて、同一ブロック番号同士でプールアドレスの排他的論理和を取る。結果が0であれば（即ちアドレスが同一であれば）バックアップ対象でないブロックであることを示し、結果が非0であれば（即ちアドレスが異なれば）バックアップ対象であることを示す（なお、非0は1として扱う）。

【0049】

次に、I/OコントロールプログラムP150は、バックアップする複数のブロックを集めてオブジェクトにするため、先の抽出結果に基づいてストレージプール600から対象ブロックを読み出し転送用メモリに格納する（S2140）。I/O制御サブシステムのリソース制約から一度にすべてを読み出すことはできないので、一定のサイズ（例えば16MB等）ごとに処理を行う。

【0050】

そして、同コントロールプログラムP150は、今回送信するオブジェクトの名称（OBJ Key）を決定し、そのオブジェクトに含まれるブロックの情報（例えば圧縮の有無、サイズ等）を蓄積する（S2150）。同プログラムP150は、オブジェクト変換機能P1534およびAPI通信機能P1536を通じて、バックアップデータをオブジェクトに変換し、オブジェクトストアに送信する（S2160）。また送信とは非同期にオブジェクトストアから受信結果を受け取り、正常に転送できたかをチェックする（S2161）。

【0051】

I/OコントロールプログラムP150は、差分抽出されたデータをすべて送信できるまで上述した処理S2140～S2161を繰り返す（S2170:No）。すべての転送が終わると（S2170:Yes）、同コントロールプログラムP150は、続いてメタデータを生成して転送用メモリに格納する（S2180）。そして、オブジェクト変換機能P1534およびAPI通信機能P1536を通じてオブジェクトとしてオブジェクトストアに格納し（S2190）、正常に転送できたかを確認する（S2200）。なおメタデータの詳細については図１２を用いて後述する。

【0052】

以上により、今回のバックアップデータとそのメタデータの対をオブジェクトストアに格納したことが確認できたので、I/OコントロールプログラムP150は、リストア時に参照する当該バックアップの諸情報を記したカタログデータを生成し（S2210）、オブジェクトストアに転送（S2220）し、正常終了を確認する（S2230）。

【0053】

最後に、I/OコントロールプログラムP150は、バックアップに用いたスナップショットの後始末を行う。これはバックアップごとにスナップショットを取っているとスナップショット数が膨大になってしまうためである。具体的には、利用者によってストレージシステム10にあらかじめ設定された世代数（例えば3）に応じ、これを超える古い世代のスナップショットを削除する（S2240）（ただし、差分バックアップが指定されている場合、前回フルバックアップに用いたスナップショットは除く）。削除は該当スナップショットのマッピングテーブル410を削除することで行われる。なお、スナップショットを削除した結果、どこからも参照されなくなったストレージプールのブロックは、I/OコントロールプログラムP150により回収され、適切なタイミングで再利用される。

【0054】

図１０Ａ、Ｂは、図９に示したフローチャートS2110～S2130において、バックアップ対象データが特定される様子を模式的に表したものである。
図１０Ａは、フローチャートS2110でバックアップが初回の場合である。比較元スナップショット2121はマッピングテーブル410AがNULLとなるダミーのスナップショットであり、スナップショット2100はバックアップ対象スナップショットである。マッピングテーブル410Aに示すように、比較元のアドレスは0なので、両者の排他的論理和の結果4130Aから、すべてのデータがバックアップ対象、すなわちフルバックアップとなることが分かる（2130A）。

【0055】

図１０Ｂは、フローチャートS2110で増分バックアップが指定され、かつ当該バックアップが2回目以降の場合である。
比較元スナップショット2122は、前回バックアップ対象のスナップショットであり、スナップショット2100は今回バックアップ対象のスナップショットである。このときの両者のマッピングテーブルは410Bのようになり、その排他的論理和4130Bから、ブロック番号#1に格納されていたデータ「Ａ’」のみがバックアップデータとして特定される（2130B）。このようにして更新されたデータのみがバックアップされることがわかる。

【0056】

図１１は、図９におけるオブジェクト変換とオブジェクト送信（S2160, S2190, S2220）に係る処理手順を示すフローチャートである。この処理では、ストレージシステム10は、ディスクにバイナリ形式で格納されていたデータをテキスト形式に変換し、HTTPプロトコルを用いてREST APIで送信する。

【0057】

I/OコントロールプログラムP150は、オブジェクト変換機能P1534によって、転送用メモリに格納されたデータを、BASE64形式にてテキストデータにエンコードする（S3100）。そしてエンコードされたデータから、データ保護用にMD5ハッシュ値を計算する（S3110）。次にI/OコントロールプログラムP150は、オブジェクトストア登録情報からAccess IDとSecret Keyを用いて、所定の計算を行い、認証情報を作成する（S3120）。そして、同プログラムP150のAPI通信機能P1536は、先に作成したMD5値、認証情報の他、送信日時、サイズ情報等をHTTPヘッダ、先にBASE64エンコードしたテキストデータをHTTPボディとしたオブジェクトデータを構成し（S3130）、PUTまたはPOSTコマンドを使ってREST API通信にてオブジェクトストアへ格納する（S3140）。

【0058】

図１２は、本実施例のバックアップにおけるメタデータの構造を示す図である。オブジェクトはその名称にあたる固有のOBJ Keyを持つ（T150）。固有のOBJ Keyは例えば製品番号、ボリューム番号、バックアップ世代番号などを組み合わせて構成できる。
メタデータT150はOBJ Key:VSP56342-v7f-s02.metaでオブジェクトストアに格納されており、ビットマップサイズ（T1510）、ビットマップ（T1511）および、１つめのバックアップデータのOBJ Key（T1520）、当該バックアップデータに含まれる各ブロックのサイズ（T1521）、２つめのバックアップデータのOBJ Key（T1530）および当該バックアップデータに含まれる各ブロックのサイズ（T1531）・・・が記録されている。ビットマップ（T1511）は、バックアップ対象データを抽出する際に作成したマッピングテーブル間の排他的論理和であり、ブロック番号順にデータが含まれている（1）か、否か（0）を表している。例えば、図１２では、ビットマップT1511の先頭が「110011」となっているので、バックアップデータには、ビットが「1」であるブロック番号#1,#2および#5,#6のデータは含まれているが、#3,#4のブロックは含まれていないことが分かる。

【0059】

バックアップデータは、データをオブジェクトにして転送する際、一定のサイズで区切って処理している。このため、T1520,T1530のように複数のOBJ Keyが存在する。また、ブロック長T1521,T1531は、バックアップに含まれる各データブロックのサイズを示しており、どこまでが１つのブロックとなっているかを判別するのに利用する。図１２ではデータが無圧縮で格納されている例を示しているので、同一値が並んでいるが、ブロックが圧縮されている場合には、異なる値が並ぶ。

【0060】

図１３Ａ、Ｂは、本実施例のバックアップにおいてオブジェクトストアに格納されるカタログデータを示した図である。カタログデータは、リストアの際に参照する諸情報が格納される。諸情報は、例えば、バックアップ元、復元に必要な容量、バックアップデータにアクセスするためのOBJ Key、バックアップの親子関係情報などである。
図１３Ａは、2回目のバックアップのカタログデータであり、図１３Ｂは初回のカタログデータである。

【0061】

カタログデータT160はVSP56342-v7f-s02.catalogというOBJ Keyでオブジェクトストアに格納されている。カタログデータT160には、装置製品番号（T1610）、バックアップされた論理ボリューム番号（T1611）、当該ボリュームのプロビジョニングサイズ（割当容量）と使用サイズ（T1612）、バックアップに用いたスナップショットの世代番号（T1613）、当該スナップショットの取得日時（T1614）、メタデータのOBJ Key（T1615）、前世代のカタログデータのOBJ Key（T1616）が記録されている。これらの情報から、これは、装置製品番号がVSP56342の装置においてボリューム番号が0x7fのバックアップであり、リストアすると16TBのボリュームになることが分かる。また、これはスナップショット番号2を用いて2021年4月28日21時に取得されたものであり、バックアップデータにアクセスするにはメタデータVSP56342-v7f-s02.metaを参照すれば良いことが分かる。さらに、親カタログデータのOBJ Keyが存在することから、本バックアップをリストアする前にVSP56342-v7f-s01.catalogをリストアする必要があることが分かる。

【0062】

カタログデータT170は、カタログデータT160で親カタログとしてポイントされていたものである。記録情報から、これは同じ装置の同じボリュームのバックアップであり（T1710,T1711,T1712）、スナップショット世代番号1を用いて2021年4月28日18時に取得されたものであり、バックアップデータにアクセスするにはメタデータVSP56342-v7f-s01.metaを参照すれば良いことが分かる。また、親カタログの記載がないことから、本バックアップを最初にリストアすれば良いことが分かる。

【0063】

図１４は、これまで説明してきたカタログデータ、メタデータ、バックアップデータ群がクラウドサービス20のオブジェクトストアサービス230に格納されている様子を模式的に表した図である。

【0064】

オブジェクトストアサービスには、図８Ｂで登録した認証情報でアクセス可能な領域231があり、ストレージシステム10のバックアップデータを格納するバケット2310が構成されている。バケット2310には、論理ボリューム番号0x7fの1世代目のバックアップカタログC23、2世代目のバックアップカタログC24と、それぞれのカタログに参照されるメタデータM23,M24、バックアップデータ群m231,m232,・・・m241,m242,・・・が格納されている。バケット2310には、この他に論理ボリューム番号0x90のバックアップがあり、カタログC25、メタデータM25、バックアップデータ251,・・・がそれぞれ格納されている。
なお、領域231は複数のバケットを持つことがある。例えばバケット2320は同じ認証情報を登録した別のストレージシステムのバックアップが格納される様子を示している。

【0065】

図１５以降では本発明の実施例におけるリストア動作について説明する。
図１５は、本発明の実施例におけるバックアップのリストア選択画面である。この画面はストレージ管理プログラムP160に含まれる、GUIおよびCLIコンポーネントP1610とリストア管理機能P1680によって提供される。

【0066】

項目D401はリストアに用いるオブジェクトストアを選択するドロップダウンボックスであり、図８において登録されたオブジェクトストア（およびバケット）が選択肢として表示される。例えば、図１５では「ams: std Backup」が選択されている。
項目D402は、リストアするボリュームを選択する項目である。項目D401における選択に基づき、ストレージ管理プログラムP160がストレージ管理オブジェクトストアのバケットをサーチして得られたボリュームの情報が表示される。サーチ動作については図１６を用いて後述する。

【0067】

項目D403は、リストアするボリュームのバックアップデータを選択する項目である。項目D402の選択に基づいてフィルタされたバックアップデータが表示される。例えば図１５では、項目D402において論理ボリューム番号#7Fのボリュームが選択されているので、項目D403にはボリューム番号#7Fのバックアップデータのみが表示される。

【0068】

項目D404は、ボリュームのリストア先を選択する項目である。例えば、図１５は新規の論理ボリュームにリストアすることが選択されており（D4042）、同ボリュームの作成先にストレージプールBを用いることが選択されている。なお、ストレージ管理プログラムP160の判断により、ストレージプールCはリストアに必要な容量（項目D402を参照）が不足するので選択不可となっている。

【0069】

図１６は、本発明の実施例におけるストレージ管理プログラムP160が、図１５の画面に表示するバックアップデータの一覧を取得する際のフローチャートである。
ストレージ管理プログラムP160は、リストア選択画面の表示に先立ち、前回バックアップデータ一覧を作成した日時を取得する（S5100）、次に同プログラムは、I/OコントロールプログラムP150と連携し、当該オブジェクトストアのカタログファイル一覧を取得するLISTコマンドを生成する（S5110）。具体的には、OBJ Keyの末尾が「.catalog」となっているものOBJ key群を取得するコマンドを生成する。次に、同プログラムはAPI通信管理機能P1536を通じてLISTコマンドを発行し、結果を得る（S5120）。前回一覧に含まれなかった新たなカタログデータが存在しない場合（S5130:No）、ストレージ管理プログラムP160は、バックアップデータ一覧は最新であると判断し、処理を終える。一方、前回一覧に含まれなかった新たなカタログデータが存在した場合（S5130:Yes）、ストレージ管理プログラムP160は、新たなカタログデータに含まれる諸情報を取得するため、カタログデータを取得するGETコマンドを作成する（S5140）。そして、同プログラムP160はAPI通信管理機能P1536を通じてコマンドを発行し、結果を取得する（S5150）。これを、全ての新たなカタログデータの取得が完了するまで繰り返す（S5160）。全て取得できたら（S5160:Yes）、ストレージ管理プログラムP160はバックアップデータの一覧を更新し（S5170）、処理を終了する。

【0070】

なお、本発明の実施例は、リストア先のストレージシステムが、バックアップしたストレージシステムとは異なる場合でも動作することができる。より詳細には、ユーザがリストア先のストレージシステムに、図８に示すオブジェクトストアの登録を行うと、図１５、図１６に示したバックアップデータ一覧の取得動作および画面表示によって、バックアップデータを選択することが可能となる。なお、このケースでは、リストア先のストレージシステムに、元の論理ボリュームは存在しないので、図１５の項目D404において、元のボリュームへの復元（D4041）は選択不可となる。

【0071】

図１７は、本発明の実施例におけるリストア手順を示すフローチャートである。ストレージ管理機能P160は図１５においてリストアボタンが押下されると（D411）、I/OコントロールプログラムP150にリストア処理を開始させる。リストアはバックアップデータに利用されたスナップショットがストレージシステムに残っていれば、それを利用し、残っていない場合は、オブジェクトストアからバックアップデータを取得して復元するよう、動作する。

【0072】

はじめに、I/OコントロールプログラムP150は、リストア対象として選択されたバックアップのカタログデータを取得する（S6100）。
次にI/OコントロールプログラムP150は、カタログデータに含まれる論理ボリューム番号とスナップショット番号を参照し、該当するボリュームのスナップショットがストレージシステムに存在し、利用可能か確認する。同スナップショットが存在、利用可能な場合（S6110:Yes）、当該バックアップデータは、スナップショットとしてストレージシステム内に残っていることを意味する。そこで、同プログラムP150は、同スナップショットをリストア先ボリュームに復元する（S6121）。具体的には、スナップショットのマッピングテーブルの内容をリスト先ボリュームのマッピングにコピーする。ボリューム上のデータを読み書きしないため、高速に処理を終えることができる。

【0073】

一方、同スナップショットが存在しない場合（S6110:No）、クラウドのオブジェクトストアからバックアップデータを取得する必要がある。そこで、I/OコントロールプログラムP150はリストアプランナーP1537が管理する処理リストに当該カタログデータを追加する。次に同プログラムP150はカタログデータに含まれる親カタログのOBJ Keyを参照し、親世代のバックアップが存在するかどうか確認する（S6130）。親世代のバックアップが存在する場合（S6130:Yes）、同プログラムは親世代のカタログデータを取得し（S6141）、S6110～S6130に示す処理を繰り返す。これにより、処理リストは、最後尾から、親→子→孫のように、世代順に復元すべきバックアップのカタログデータが登録された状態になる。
以降の処理ではこの処理リストに登録されたカタログ群に基づきデータの復元処理が行われる。

【0074】

I/OコントロールプログラムP150は、処理リストにカタログデータが存在するか確認する。処理リストにカタログデータが存在しない場合（S6140:No）、リストアに必要な処理が全て終わっているので終了する。処理リストにカタログデータが存在する場合（S6140:Yes）、同プログラムは親世代のバックアップから復元するデータを抽出する処理である、親世代データ転送リスト作成処理を行う（S6143）。本処理の結果、処理リスト内のカタログごとに、当該カタログデータから転送するデータ格納位置を示す転送位置情報ビットマップが作成される。詳細は図１８を用いて後に説明する。

【0075】

次にI/OコントロールプログラムP150は、子世代のバックアップからのデータ復元処理を行う（S6144）。本処理を実行した結果、復元先装置内にリストア対象バックアップの子世代のバックアップデータが存在する場合に、そのなかでリストア対象と同じ、すなわちリストア対象から更新の無い箇所のデータ格納位置が抽出され、当該格納位置のデータが、リストア対象ボリューム上に復元される。また、子世代のバックアップデータからデータ復元済みの箇所を示すビットマップ“子世代復元ビットマップ”が作成される。なお、子世代のバックアップデータが復元先装置内に存在しない場合、復元可能なデータがなく１つのデータも復元されないので、子世代復元ビットマップはAll0となる。詳細は図１９を用いて後に説明する。

【0076】

次に、I/OコントロールプログラムP150は、処理リストとそれに紐付いたビットマップと、子世代復元ビットマップとを用いて、バックアップデータをオブジェクトストアから取得し、バックアップデータを復元していく。処理リスト最後尾のカタログデータ（即ち、最も親となる世代のカタログデータ）を参照し、メタデータのOBJ Keyを取得する（S6150）。そして、同OBJ Keyが指し示すオブジェクトをオブジェクトストアから取得して、バックアップデータの取得復元処理を実施する（S6160）。バックアップデータの取得復元処理の詳細な動作については図２０を用いて後述する。

【0077】

その後、I/OコントロールプログラムP150は、取得復元処理した世代のカタログデータを処理リストから取り除く（S6170）。そして処理リストにカタログデータがなくなるまで、S6145～S6170の動作を繰り返すことで、処理を完遂する。

【0078】

図１８は、図１７の手順S6143に示した転送位置情報作成処理の動作に関するフローチャートである。本動作では、I/OコントロールプログラムP150が、メタデータに基づき取得したビットマップを解釈して、各世代のバックアップデータのうち、クラウドから転送するデータの格納位置を示すビットマップを作成する。このビットマップを、転送位置情報と呼ぶ。転送位置情報は、世代ごとに生成する。また、転送位置情報の生成には、前方累積ビットマップを使用する。前方累積ビットマップは、各世代で共通して使用される。前方累積ビットマップは、リストア先のボリュームの各ブロックについて有効データ決定済（値1）か有効データ未決定（値0）かを示す。

【0079】

I/OコントロールプログラムP150は、まず、前方累積ビットマップを初期化（0化）する（S10100）。次に、処理リスト最前列のカタログデータ（即ち、最も孫となる世代のカタログデータ）を参照し（S10110）、メタデータのOBJ Keyを取得する（S10120）。そして、同OBJ Keyが指し示すオブジェクトをオブジェクトストアから取得する（S10130）。オブジェクトストアからの取得処理の詳細については図２１で説明する。次に、取得したメタデータから、ビットマップ部を切り出す（S10140）。

【0080】

次に、I/OコントロールプログラムP150は、このビットマップを用いて、転送位置情報を作成する。転送位置情報は、初期値0であり、ビットマップ部と同じ長さを持ち、カタログデータからの転送が必要な格納位置情報を管理する。I/OコントロールプログラムP150は、前方累積ビットマップを反転したビットマップを一時的に作成し、反転した前方累積ビットマップとビットマップ部とのAND演算を行い、転送位置情報を得る（S10150）。転送位置情報において非0の部分は、本世代でデータ更新があったデータ格納位置であり、当該カタログデータに関連するデータOBJから転送を行うことを示している。次に、転送位置情報を、処理対象のカタログデータと関連づけて管理する（S10160）。すなわちこの後、処理対象カタログデータをキーとして、当該転送位置情報を取得できる。

【0081】

最後に、転送位置情報と、前方累積ビットマップとのOR演算を行い、前方累積ビットマップを上書き更新する（S10170）。この操作により、前方累積ビットマップ上で、処理対象カタログデータからデータを復元する位置のビットが新たに非0となる。非0は、以降の処理で、新規にクラウドから復元不要なデータ格納位置であることを示す。
次に、同カタログデータの1つ親世代のカタログデータが処理リスト内にある場合（S10180：No）、親世代のカタログデータを処理リストから取得し（S10190）、同様にして転送位置情報を作成する（S10120～S10170）。

【0082】

なお、処理の途中で前方累積ビットマップ上のビットがすべて非0になった場合、それより親世代のカタログデータから取得すべきデータブロックが存在しないことを表す。この場合には、メタOBJの受信量を減らすべく、処理を途中で打ち切っても良い。仮に処理を続けた場合、以降のカタログデータに紐づく転送位置情報はすべてAll0が格納される。そのため、処理を途中で打ち切る場合には、All0の転送位置情報を作成し、以降のカタログデータに関連付けを行う。

【0083】

図１９は、図１７の手順S6144に示した子世代バックアップデータ復元処理の動作に関するフローチャートである。本動作では、I/OコントロールプログラムP150が、リストア対象より子世代スナップショットが復元先装置内にある場合に、子世代カタログデータのメタデータに基づき取得したビットマップを解釈して、復元先装置内のバックアップから復元するデータの位置を示すビットマップ（“子世代復元ビットマップ”） を作成し、このビットマップと復元先装置内のスナップショットデータを用いて、リストアボリューム上にデータを復元する。

【0084】

まずI/OコントロールプログラムP150は、子世代復元ビットマップの初期化を行う （S11100）。次に、リストア対象スナップショットより子世代のスナップショット有無を判定する。具体的には、まずリストアボリュームに関連するカタログリストを取得する（S11110）。リストアボリュームより子世代のカタログがない場合（S11120:No）、処理を終了する。子世代のカタログがある場合（S11120：Yes）、子世代のカタログに対応するバックアップが復元先装置内にあるかどうかを判定する（S11130,S11140）。復元先装置内にスナップショットが無い場合（S11140：No）、更に子世代のカタログを検索し、上述の手順でカタログデータを順に参照し、利用可能スナップショットを発見するか（S11140:Yes）、子世代のカタログがなくなる（S11120:No）かまで続ける。

【0085】

次に、処理対象として、復元先装置内にバックアップの存在するカタログを選択し（S11150）、対象カタログに含まれるOBJKeyを取得、メタ情報内のビットマップを取得する（S11160～S11180）。メタ情報内のビットマップと子世代復元ビットマップとでOR演算を行い、子世代復元ビットマップを演算結果で上書き更新する（S11190）。次に対象カタログデータに格納された親カタログのOBJKeyを参照し、親世代カタログを特定する。

【0086】

親世代カタログがリストア対象カタログと一致しない場合（S11200:No）、親カタログのOBJ Keyを参照して親世代のカタログを選択し（S11230）、手順S11160からの処理を反復する。
親世代カタログがリストア対象カタログと一致した場合（S11200:Yes）、子世代復元ビットマップを反転して、上書き更新する（S11210）。この時点で子世代復元ビットマップ上非0の格納位置にあるデータは、対象のバックアップデータから更新されていないデータであり、後方のスナップショットに、復元対象と等しいデータが格納されていることを示している。

【0087】

次に、手順S11130で選択したカタログのボリューム、すなわち復元先装置内に利用可能スナップショットが存在するボリュームのうち、子世代復元ビットマップに対応する格納位置のデータを、リストア対象のボリューム上へ復元する。具体的には、スナップショットのマッピングテーブルのうち、子世代復元ビットマップ上非0の格納位置にあるテーブルのみをリストア先ボリュームのマッピングにコピーする。

【0088】

図２０は、図１７の手順S6160に示したバックアップデータの取得復元処理の動作に関するフローチャートである。本動作では、I/OコントロールプログラムP150が、メタデータに基づき取得したバックアップデータを解釈して、リストア先ボリュームに書き込む。
はじめに、I/OコントロールプログラムP150は、カタログに格納されていたメタのOBJ Key（例えば図１３A T1615）に基づいて、オブジェクトストアからメタデータのオブジェクトを取得する（S7100）。次に同プログラムP150は、取得したメタデータから、ビットマップ部を切り出す （S7110）。
なお、本処理よりも以前に、転送位置情報作成処理内の手順S10130で対象カタログからメタのOBJを受信し、手順S10140でビットマップを取得しているため、データが復元先装置のバッファ内に残存している場合は、これらのいずれかまたは両方の処理を省略できる。

【0089】

その後、同プログラムP140は、対象カタログに紐付いた転送位置情報と、子世代復元ビットマップとを用いて、対象カタログから復元するデータ格納位置を特定するための“復元位置ビットマップ”を取得する（S7111）。具体的には、子世代復元ビットマップを反転したものと、転送位置情報をAND演算する。復元位置ビットマップが非0の部分は、当該転送リストから復元すべきデータの格納位置を表している。すなわち、転送位置情報は、ローカルに存在するデータを転送の対象から除外し、クラウドからの転送が必要なデータを示している。

【0090】

次に同プログラムP150は、データ長の情報を得る（S7112）。データ長情報の個数を数え、ビットマップと比較して同OBJ Keyを持つバックアップデータ内に、復元対象のデータが格納されているか否かを判定する。具体的には、復元位置ビットマップにおいて、現在のビット参照位置からデータ長個数分だけ先の範囲に、非0のビットが立っているかどうかを検索し、1つ以上あれば、復元対象のデータが格納されているデータOBJであると判断する。

【0091】

復元対象のデータが格納されている場合（S7113:Yes）、メタデータから1つめのデータOBJ Keyを得（S7120）、同OBJ Keyを持つバックアップデータのオブジェクトを、オブジェクトストアから取得する（S7130）。

【0092】

そして、同I/OコントロールプログラムP150は、復元位置ビットマップと、ビットマップ部の各ビットを参照しながらデータを復元していく。
まず、転送位置ビットマップの参照ビットが1の時（S7150:Yes）、バックアップデータに当該ブロック番号のデータが存在し、かつ復元が必要であることを意味する。このためI/OコントロールプログラムP150はバックアップデータに含まれるデータブロックを、リストア先ボリュームの当該ブロック番号に書き込む（S7160）。一方、ビットが0の時（S7150:No）はバックアップデータにからの復元は不要であることを意味するので、何もせずに処理を先にすすめる。

【0093】

次に、ビットマップ部の参照箇所が１の場合（S7165：Yes）、データOBJ内に当該ブロック番号に対応するバックアップデータが含まれていたことを示しており、次の処理に備えて、バックアップデータの参照ブロックを１つ進める（S7170）。一方、ビットマップ部の参照箇所が０の場合（S7165：No）、何もせずに処理を先にすすめる。

【0094】

次に、リストア先ボリュームの書き込み先のブロック番号を１つ進める（S7180）。
もしバックアップデータにまだ参照ブロックが存在する場合、すなわち終端でない場合は（S7190:No）、ビットマップを参照しながらブロック書込み処理を繰り返す（S7140～S7170）。一方、終端に達した場合（S7190:Yes）は、まだビットマップに未参照ビット群があるか、すなわちボリュームへの書き込みが未完了か確認し（S7200）、未完了の場合（S7200:No）、データ長を取得（S7112）し、ビットマップと照合しながら書き込み処理を繰り返す（S7112～S7190）。

【0095】

復元対象のデータが対象OBJに格納されていない場合（S7113:No）、復元位置ビットマップの参照ビットを、データ長分先に進め（S7145）、ボリュームの更新アドレスも、データ長分先に進める（S7155）。

【0096】

その後、まだビットマップに未参照ビット群があるか、すなわちボリュームへの書き込みが未完了か確認し（S7200）、未完了の場合（S7200:No）、データ長を取得（S7112）し、ビットマップと照合しながら書き込み処理を繰り返す（S7112～S7190）。
ビットマップが終端に達した場合（S7200:Yes）、当該バックアップの全てのデータの書き込みが終わったことを意味するので、処理を終了する。

【0097】

図２１は、I/OコントロールプログラムP150がオブジェクトストアからオブジェクトを取得し、同オブジェクトを変換して格納されていたバイナリデータを得るまでの処理を示すワークフローである。
I/OコントロールプログラムP150は、オブジェクトの名称にあたるOBJ Keyを取得すると（S8100）、オブジェクトストア登録情報からAccess IDとSecret Keyを用いて、所定の計算を行い、認証情報を作成する（S8110）。そして、同プログラムP150のAPI通信機能P1536によって、認証情報の他、送信日時、HTTPヘッダとしたGET コマンドを構成し（S8120）、REST API通信にてオブジェクトストアへオブジェクトを要求する（S8130）。

【0098】

同I/OコントロールプログラムP150は、オブジェクトストアからオブジェクトを含む応答を受信すると（S8200）、受信データのMD5をチェックしてデータに誤りがないか確認する（S8210）。そして、データに誤りがなければ、受信したデータをBASE64でデコードしてバイナリデータに変換し（S8220）、データ格納用のメモリ領域にコピーする（S8230）。

【0099】

図２２Ａ～Ｄでは、図１７で示したリストア手順の動作について理解を深めるためにいくつか事例を示した。説明の簡略化のため、１つのデータOBJに格納するデータブロック数は１として示す。
図２２Ａは、ストレージシステム10にスナップショットSS02,SS03が残っており、オブジェクトストア（のバケット）2310には各スナップショットに対応した増分バックアップB01,02,03があり、このときB03にあたる３世代目のバックアップをボリュームR00へリストアする様子を示している。図１７の手順によれば、I/OコントロールプログラムP150はまずB03のカタログデータを取得し、これに対応するスナップショットの存在を確認する。その結果、SS03が利用可能であるので、同プログラムP150はスナップショットを復元する（P1）。次に処理リストには他のカタログが登録されていないため、リストア処理を完了する。結果、R00には3世代目のバックアップがリストアされたことが確認できる。

【0100】

図２２Ｂは、何らかの理由によりスナップショットSS03およびSS02が利用できない状態で、B03で示される第3世代目のバックアップをリストアする様子を示している。図１７の手順によれば、B03に対応するスナップショットSS03は存在するが利用できないため、I/OコントロールプログラムP150は処理リストにB03のカタログデータを追加する。
次にB03には、親世代となるバックアップB02が存在するので、同I/OコントロールプログラムはB02のカタログを取得する。B02には対応するスナップショットSS02が存在せず、親世代となるバックアップB01が存在するので、同I/OコントロールプログラムはB01のカタログを取得する。B01には対応するスナップショットSS01が存在し利用可能なため、同I/OコントロールプログラムはSS01をボリュームR00へ復元する（P1）。次に同I/OコントロールプログラムP150は処理リストの処理に移る。

【0101】

処理リストにはB02とB03のカタログデータが登録されているので、同I/OコントロールプログラムP150は、転送位置情報作成処理を行う。この結果、B02とB03のカタログに対して、転送位置情報ビットマップ（T2330Ｂ）が紐付けされる。

【0102】

次に同I/OコントロールプログラムP150は、子世代バックアップデータ復元処理を行う。B03以降のバックアップが存在しないので、子世代からのデータ復元は行わず、子世代復元ビットマップは全て0を格納する。

【0103】

次に同I/OコントロールプログラムP150は、B02,B03の復元処理を行う。B02からの復元処理P2では、B02に紐付いた転送位置情報上に非0のビットがないため、データ転送を行わない。一方でB03からの復元処理P3では、B03に紐付いた転送位置情報上に非0のビットが存在するため、当該格納位置のデータに対してリストア処理を行う。結果、R00には3世代目のバックアップがリストアされることが確認できる。

【0104】

図２２Ｃは、別のストレージシステム10’のボリュームR01に、B03にあたる3世代目のバックアップをリストアする様子を示している。図１７の手順によれば、別のストレージシステム10’にもはいずれのスナップショットも存在しないため、処理リストには、B03、B02、B01の順にカタログデータが追加される。そして図２２Ｂと同様に、最後尾から順に、それぞれに対応する復元処理P1,P2,P3が実施され、結果、R01には3世代目のバックアップがリストアされることが確認できる。なおP2処理については、図２２Ｂと同様、データ転送はおこなわない。本例におけるデータ転送量は、復元ボリューム容量と同じサイズであり、これがデータ転送量の上限値となる。なお、管理情報削減のために、１つのデータOBJに複数個（Ｎ個）のデータブロックを格納する場合、データ転送量の上限値はボリューム容量のＮ倍となる。

【0105】

図２２Ｄは、ストレージシステム10にはスナップショットSS03のみが残っており、B02にあたる2世代目のバックアップをボリュームR00へリストアする様子を示している。図１７の手順によれば、I/OコントロールプログラムP150はまずB02のカタログデータを取得し、これに対応するスナップショットを確認する。その結果、対応するスナップショットSS02は存在しないため、同コントロールプログラムP150は、処理リストにB02のカタログデータを追加する。次にB02には親世代となるバックアップB01が存在するので、B01のカタログを取得する。B01に対応するスナップショットSS01も同様に存在しないため、処理リストにB01のカタログを追加する。処理リストには、B02、B01の順にカタログが存在するため、同コントロールプログラムP150は、最後尾のB01のカタログとメタデータを用いて転送位置情報作成処理を行い、それぞれの転送位置情報を得る。次に同I/OコントロールプログラムP150は、子世代バックアップデータ復元処理を行う。B02には子世代となるB03のバックアップが存在し、かつB03には利用可能なスナップショットが存在する。そこでB03に対して子世代復元ビットマップを作成し、それに基づいてSS03からR00に復元処理P1を行う。このとき、ビットが１になっているビットマップ位置#3のデータが復元される。次に同コントロールプログラムP150は、処理リストの最後尾から順に復元処理を行う。このとき、子世代復元ビットマップと、転送位置情報を参照し、P2ではビットマップ位置#2のデータのみ、P3ではビットマップ位置#1のデータのみをクラウドから転送する。結果、R00には2世代目のバックアップがリストアされることが確認できる。

【0106】

以上の実施例によれば、カタログデータに含まれるバックアップ元装置とスナップショット番号情報を用いて、復元先ストレージ装置にスナップショットがあればリストアに利用するよう動作し、かつリストア先ボリューム上有効なデータのみをクラウドから転送するので、リストア時間の短縮およびオブジェクトストアからの取得料金を削減することができる。また、バックアップの世代数が増加した場合でも、データ転送量の上限が規定される。

【実施例0107】

実施例１ではバックアップデータのオブジェクト、メタ情報、カタログデータを全てオブジェクトストアに格納した。実施例１の変形例として、カタログデータの格納にクラウドのデータベースサービスを利用する形態が考えられる。
この場合、カタログデータは図２のデータベースサービス220に設けられるデータベースのレコードとして記録される。

【0108】

図２３は本実施例におけるカタログデータを、データベースサービス220が提供するNoSQLデータベースを用いて記録した様子を示した図である。図１３Ａ、Ｂで示したカタログデータがレコードと記録されていることが分かる。
本実施例の場合、複数のカタログデータの情報をNoSQLコマンド１回で取得できるので、図１６に示すような複雑な取得フローが不要となり、バックアップ一覧の表示処理を高速に行うことができる。また、バックアップ/リストアにおいてカタログデータのOBJ変換処理が不要となる。

【0109】

上述してきたように、実施例に開示のストレージシステムは、バックアップ毎に当該ボリュームのスナップショットを取得し、比較元となる過去のスナップショットを選定し、前記過去のスナップショットとの変更差異を取得し、バックアップ対象データブロックを抽出する。
また、ストレージシステムは、抽出された対象データブロックを複数個ずつまとめてオブジェクト群とし、前記オブジェクト群に含まれる各データブロックの元の格納位置を判別するためのメタ情報と、過去のバックアップとの親子関係およびバックアップ元の装置およびスナップショット情報を保持するカタログデータを生成し、前記オブジェクト群と前記メタ情報と前記カタログデータをオブジェクトストアに格納する。
ストレージシステムは、リストアする際、前記カタログデータの親子関係に基づいて、リストア処理に必要な一連のバックアップデータ群を特定する。
ストレージシステムは、前記カタログデータのバックアップ元の装置およびスナップショット情報を用いて、復元先装置に前記スナップショットが利用可能に存在するか否か判別し、利用可能である場合はスナップショットを優先利用する。
加えて、前記メタ情報の格納位置情報に基づいて、子以降の世代でデータ上書きされずリストア対象ボリューム上有効なデータブロックを特定し、当該データブロックを含むオブジェクト群のみを転送することで、クラウドからのデータ受信量を削減する。

【0110】

このため、ストレージシステムは、リストア時間およびクラウドサービスの利用コストを削減することが可能である。リストア時に上書きされるデータブロックと、バックアップ先装置に存在しているデータはオブジェクトストアから受信しないために、データ転送量が削減されるからである。
また本ストレージシステムによれば、バックアップの世代が増加した場合でも、リストア時に転送が必要なデータ量上限が規定できる。

【0111】

なお、本発明は上記の実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、かかる構成の削除に限らず、構成の置き換えや追加も可能である。