特開 2024-121874 ストレージシステム及びストレージシステムの監視方法

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

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

(11)【公開番号】P2024121874

(43)【公開日】2024-09-09

(54)【発明の名称】ストレージシステム及びストレージシステムの監視方法

(51)【国際特許分類】

   G06F 21/56 20130101AFI20240902BHJP

   G06F 3/06 20060101ALI20240902BHJP

   G06F 11/14 20060101ALI20240902BHJP

【ＦＩ】

G06F21/56 360

G06F3/06 304F

G06F3/06 304K

G06F11/14 648

G06F3/06 304N

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023029083

(22)【出願日】2023-02-28

(71)【出願人】

【識別番号】000005108

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

(74)【代理人】

【識別番号】110001689

【氏名又は名称】青稜弁理士法人

(72)【発明者】

【氏名】佐々木 一真

(72)【発明者】

【氏名】荒田 穣毅

(72)【発明者】

【氏名】平岩 友理

(72)【発明者】

【氏名】小山田 健一

(72)【発明者】

【氏名】二階堂 旭

(72)【発明者】

【氏名】坂田 裕辰

(57)【要約】

【要約】
【課題】ランサムウェア攻撃等によるサーバ攻撃の障害を、通常モニタしているメトリクスを用いてシステム負荷を上げることなく検知する
【解決手段】アプリケーションの稼働するサーバに接続された第一のストレージと、第一のストレージのバックアップを取得するデータ保護ストレージと、前記データ保護ストレージを監視する監視サーバとを備え、前記監視サーバは第一のストレージからデータ保護ストレージへデータのバックアップを取得するバックアップ実行部と、バックアップ実行部がバックアップを取得するときのデータ保護ストレージへの書き込みデータ量が予め定められた量を超えたとき異常と判定する書き込みデータ量監視部と、書き込みデータ量監視部が異常と判定したときアラートを出力するアラート出力部を備えるストレージシステム
【選択図】図１

【特許請求の範囲】

【請求項1】

アプリケーションの稼働するサーバに接続された第一のストレージと、
第一のストレージのバックアップを取得するデータ保護ストレージと、
第一のストレージからデータ保護ストレージを監視する監視サーバとを備え、
前記監視サーバは第一のストレージからデータ保護ストレージへデータのバックアップを取得するバックアップ実行部と、
バックアップ実行部がバックアップを取得するときのデータ保護ストレージへの書き込みデータ量が予め定められた量を超えたとき異常と判定する書き込みデータ量監視部と、
書き込みデータ量監視部が異常と判定したときアラートを出力するアラート出力部を備えるストレージシステム。

【請求項2】

前記監視サーバはバックアップ実行部と、
バックアップを行うディスクボリューム、開始時刻を格納したバックアッププランテーブルと、
バックアップ開始時刻、バックアップ終了時刻を格納した閾値テーブルを備え
バックアップ実行部はバックアッププランテーブルを参照し、前記開始時刻に前記ディスクボリュームのバックアップを開始し、
前記書き込みデータ量監視部はデータ保護ストレージへの書き込み完了が閾値テーブルのバックアップ終了時刻を超えているかどうかを基に異常を検知する請求項１に記載のストレージシステム。

【請求項3】

前記監視サーバは接続された監視端末からバックアップ終了時刻の変更を受付け、
前記閾値テーブルのバックアップ終了時刻を更新する請求項２に記載のストレージシステム。

【請求項4】

バックアップの世代管理を行い、世代ごとに削除の可否を示す削除可否フラグを備えるバックアップ管理テーブルを備え
前記書き込みデータ量監視部が異常を検知したとき
前記バックアップ管理テーブルの最も新しい世代の削除可否フラグを削除不可に変更する請求項２に記載のストレージシステム。

【請求項5】

第一のストレージは前記サーバがアクセスする第一の物理ボリュームと第一の物理ボリュームに対応付けられた第一のローカルボリュームを備え、
前記データ保護ストレージは第一の物理ボリュームのバックアップを格納する第二の物理ボリュームを備え、
バックアップ実行部は第一のローカルボリュームの仮想ボリュームから第二の物理ボリュームへバックアップを取得する請求項２に記載のストレージシステム。

【請求項6】

第一のストレージは前記サーバがアクセスする第一の物理ボリュームを備え、
前記データ保護ストレージは前記第一の物理ボリュームに対応付けられた第二のローカルボリュームとバックアップを格納する第二の物理ボリュームを備え、
バックアップ実行部は前記ローカルボリュームの仮想ボリュームから第二の物理ボリュームへバックアップを取得する請求項２に記載のストレージシステム。

【請求項7】

第一のストレージに格納された前記サーバがアクセスする第一の物理ボリュームと、
第一の物理ボリュームに対応する第三の物理ボリュームと第三の物理ボリュームに対応する第三のローカルボリュームを含む第三のストレージと、
前記データ保護ストレージはバックアップを格納する第二の物理ボリュームを備え
を備え、
バックアップ実行部は前記ローカルボリュームの仮想ボリュームから第二の物理ボリュームへバックアップを取得する請求項２に記載のストレージシステム。

【請求項8】

第一のストレージと前記データ保護ストレージはクラウド上に設けられ、前記書き込みデータ量監視部はデータ書き込み開始の遅延を検知したとき、前記閾値テーブルのバックアップ終了時刻より遅い時刻で異常の検出を行う請求項２に記載のストレージシステム。

【請求項9】

前記書き込みデータ量監視部が異常を検出したとき、
アラート出力部は異常を検出した第一の物理ボリュームに対応付けられたホストの識別子を出力する請求項５に記載のストレージシステム。

【請求項10】

アプリケーションの稼働するサーバに接続された第一のストレージと、
第一のストレージのバックアップを取得するデータ保護ストレージとを備えるストレージシステムの監視方法であって、
監視サーバがデータ保護ストレージを監視し、
書き込みデータ量監視部が前記監視サーバはバックアップ取得時のデータ保護ストレージへの書き込みデータ量が予め定められた量を超えたとき異常を検知し、
アラート出力部が書き込みデータ量監視部が異常を検知したときアラートを出力するストレージシステムの監視方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はストレージシステム及びストレージシステムの監視方法に関する。

【背景技術】

【0002】

バックアップデータを遠隔サイトに格納し、障害発生時にバックアップデータを利用してデータをリストアするリモートコピーがある。例えば、特許文献１(特開２００６-１４６８０１号公報)では、リモートコピー技術において、他のホストコンピュータが誤って遠隔ボリュームのデータを破壊することを防止するため、ホストコンピュータ毎にアクセスを制限している。

【0003】

サイバー攻撃された可能性があることをストレージシステムから得られるメトリクスを基に判定するいわゆるＡｎｏｍａｌｙ Ｄｅｔｅｃｔｉｏｎに関する特許文献２がある。特許文献２では、ストレージボリュームの複数のスナップショットを生成し、特定のスナップショットと現在のスナップショットとを監視し、ストレージボリュームの圧縮率が指定された圧縮率を下回ったときなどにランサムウェア攻撃の可能性を示すアラートを出力する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００６-１４６８０１号公報

【特許文献2】ＵＳ１１，０３０，３１４ Ｂ２公報

【発明の概要】

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

【0005】

特許文献１では、障害発生に備えてデータのバックアップをリモートコピー機能を用いて多段のバックアップを取得することが開示されているが、障害をどのようにして検知するかについては開示されていない。

【0006】

特許文献２では、ストレージボリュームから複数のスナップショットを取得し、ストレージボリュームの圧縮率が指定された値を下回るかどうかなどの条件によりランサムウェア攻撃の可能性を検出している。

【0007】

しかしながら、ストレージボリュームの圧縮率等の条件はＰｒｏｄｕｃｔｉｏｎ ｓｅｒｖｅｒで実行されるＡｐｐｌｉｃａｔｉｏｎの稼働状況に大きく影響を受け、稼働状況の変化によりランサムウェア攻撃による障害を示すアラートを正しく出力することは困難である。また、変化の閾値をユーザが設定することが困難なだけでなく、より的確に障害を検知するためには、通常はモニタしていないメトリクスを取得する必要があり、システム負荷増加につながる可能性がある。

【0008】

さらに、Ｐｒｏｄｕｃｔｉｏｎ ｓｅｒｖｅｒがアクセスするＰｒｏｄｕｃｔｉｏｎストレージのメトリクス監視はＰｒｏｄｕｃｔｉｏｎストレージの負荷を上げてしまうため、Ｐｒｏｄｕｃｔｉｏｎ ｓｅｒｖｅｒが提供しているサービスの遅延を招く可能性もある。

【0009】

本発明の目的は、リモートコピーによりデータのバックアップを行っているストレージシステムにおいて、ランサムウェア攻撃等によるサーバ攻撃の障害を、通常モニタしているメトリクスを用いてシステム負荷を上げることなく検知することにある。

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

【0010】

本発明の課題はアプリケーションの稼働するサーバに接続された第一のストレージと、第一のストレージのバックアップを取得するデータ保護ストレージと、第一のストレージからデータ保護ストレージを監視する監視サーバとを備え、前記監視サーバは第一のストレージからデータ保護ストレージへデータのバックアップを取得するバックアップ実行部と、バックアップ実行部がバックアップを取得するときのデータ保護ストレージへの書き込みデータ量が予め定められた量を超えたとき異常と判定する書き込みデータ量監視部と、書き込みデータ量監視部が異常と判定したときアラートを出力するアラート出力部を備えるストレージシステムにより解決される。

【発明の効果】

【0011】

バックアップを取得するストレージシステムが通常モニタしているメトリクスであるデータ書き込み量の変化を基にサーバ攻撃による障害を検知することができる。

【図面の簡単な説明】

【0012】

【図1】本発明の実施例におけるシステム構成の例を示したブロック図の例

【図2(a)】本発明を適用可能なシステムの例

【図2(b)】本発明を適用可能なシステムの例

【図2(c)】本発明を適用可能なシステムの例

【図3】業務ストレージボリュームとデータ保護ストレージボリュームのデータ書き込み量の比較

【図4】データ保護ストレージボリュームでの書き込みデータ量監視のメリット

【図5】本発明の実施例におけるバックアッププランテーブルの例

【図6】本発明の実施例におけるバックアップ管理テーブルの例

【図7】本発明の実施例における閾値テーブルの例

【図8】本発明の実施例における閾値テーブルに設定された閾値と保護ストレージボリュームのメトリクス測定値の例

【図9(a)】本発明の実施例における異常イベントテーブルの例

【図9(b)】本発明の実施例における異常イベントテーブルの例

【図10】本発明の実施例における異常イベントテーブルの値と保護ストレージボリュームのメトリクス測定値の例

【図11】本発明の実施例におけるバックアップ実行部のフローチャートの例

【図12】本発明の実施例における書き込みデータ量監視部のフローチャートの例

【図13】本発明の実施例における異常イベント記録部のフローチャートの例

【図14】本発明の実施例における出力画面の例

【図15】本発明の実施例におけるシステム構成の例を示したブロック図の例

【図16】本発明の実施例における書き込みデータ量監視部のフローチャートの例

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

【0013】

以下図面に従って、本発明の一実施の形態を説明する。

【0014】

ただし、本発明は後述する実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例および同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。

【0015】

なお、本実施例では各情報を「テーブル」形式にて説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、ＤＢ（ＤａｔａＢａｓｅ）等のデータ構造で表現されていても良い。

【0016】

そのため、データ構造に依存しないことを示すために「テーブル」、「ＤＢ」等について単に「情報」と呼ぶことがある。また、各情報の内容を説明する際に、「識別情報」、「識別子」、「ＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

【0017】

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納できる。

【0018】

また、前述した各構成、機能、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

【0019】

また、以後の説明では「ＸＸ部」などのプログラムを主語とした説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ３および外部記憶装置４を用いながら行うため、プロセッサを主語とした説明としてもよい。

【実施例0020】

図１は本発明の実施例におけるシステム構成の例を示したブロック図の例である。業務サーバであるホスト１４はネットワークで接続された業務ストレージ１５のデータを用いて業務を行っている。業務ストレージ１５では物理ボリューム（ＰＶｏｌ）１７にホスト１４が使用するデータが格納されており、ＰＶｏｌ１７のコピーであるローカルコピーがＳＶｏｌ１８へ格納されている。ＳＶｏｌのデータのクローン１９が作成され、データ保護ストレージ１６の物理ボリューム（ＰＶｏｌ）２０と対応付けられて、物理ボリューム１７のコピーがデータ保護ストレージ内に取られる。

【0021】

ＰＶｏｌ２０はスナップショット２１が取られ世代管理が行われる。これらの処理はデータ保護ストレージ１６にネットワーク接続されたデータ保護ストレージ監視サーバ１の指示で実行される。

【0022】

データ保護ストレージ監視サーバ１はバスで接続されたＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２、メモリ３及び外部記憶装置４を含む。メモリ３にはバックアップ実行部７、書き込みデータ量監視部８及び異常イベント記録部９がソフトウェアモジュールとして格納され、外部記憶装置４にはバックアッププランテーブル１０、バックアップ管理テーブル１１、閾値テーブル１２及び異常イベントテーブル１３が格納されている。

【0023】

メモリ３内の各ソフトウェアモジュールは外部記憶装置４に格納されたテーブルを参照し、データ保護ストレージ１６の監視を行う。

【0024】

また、データ保護ストレージ監視サーバ１には監視端末５が接続されており、ユーザは監視端末５からデータ保護ストレージの監視状況を見ることが可能であり、バックアップ時刻の変更や異常を検出する閾値の設定、変更を行うことができる。監視端末５は直接データ保護ストレージ監視サーバ１に接続されている必要はなくネットワーク経由で接続されていれば良い。

【0025】

図２は監視対象のデータ保護ストレージ１６の例を説明する。図２（ａ）はホスト１４が直接使用する第一のストレージ１５とデータ保護ストレージ１６が同じストレージ上に実装され、ローカルコピー（ＳＶｏｌ）を持たないシステムの例である。第一のストレージ１５とデータ保護ストレージ１６が距離的に離れていないためバックアップのために必要な通信の遅延は少なく、安価なバックアップが可能であるがＳＶｏｌを持たないため障害発生時の業務復旧には時間を要する問題や、大規模災害の影響を受けやすいという問題がある。

【0026】

図２（ｂ）はホスト１４が直接使用する第一のストレージ１５とデータ保護ストレージ１６を分けて実装した例である。この例ではローカルコピーを格納するＳｖｏｌ２６をデータ保護ストレージ１６に配置している。データ保護ストレージ１６にＳＶｏｌ２６とＰＶｏｌ２０を配置しているので障害発生時に短期間で業務の復旧が可能となる比較的安価なバックアップが可能であるが、第一のストレージ１５とデータ保護ストレージ１６は距離的に遠い場所に配置することを第一のストレージ１５とデータ保護ストレージ１６の間をリモートレプリケーションで実現しているため、大規模災害の影響を受けにくいシステムを構築することができる。

【0027】

図２（ｃ）は第一のストレージ１５とデータ保護ストレージ１６の間に第二のストレージ２５を設け、第二のストレージにローカルコピーであるＳＶｏｌ２８を格納するようにしたシステムである。第二のストレージ２５とデータ保護ストレージ１６は距離的に近い場所に配置し、第一のストレージと第二のストレージ２５を距離的に離れた場所に配置することにより大規模災害の影響を受けにくいシステムを構築することができる。

【0028】

いずれの例であってもデータ保護ストレージにデータ保護ストレージ監視サーバ１を接続することにより本発明のストレージ監視を行うことができる。

【0029】

図３は業務ストレージボリュームとデータ保護ストレージボリュームのデータ書き込み量の比較を説明する図である。

【0030】

上のグラフが業務ストレージボリュームであるＰＶｏｌ１７の書き込みデータ量を示したグラフである。一点鎖線３０が異常かどうかを判定する閾値を示す書き込みデータ量であり、実線３１が記録された業務ストレージボリュームへの書き込みデータ量である。

【0031】

下のグラフがデータ保護ストレージボリュームであるＰＶｏｌ２０の書き込みデータ量を示したグラフである。点線３３が正常な書き込みが行われる時間帯を示し、実線３４が記録されたデータ保護ストレージボリュームへの書き込み時間を示す。業務ストレージボリュームは業務を実行するサーバの入出力の影響を直接的に受けるため書き込みデータ量が乱高下する。

【0032】

一方、データ保護ストレージボリュームはバックアップを行うスケジュールに基づいたデータの書き込みを行うので、使用可能なネットワークの最大書き込み容量で業務ストレージボリュームに変更があった部分のみをデータ保護ストレージボリュームへ書き込むことになる。このため書き込みデータ量の乱高下は見られず、業務ストレージボリュームの変更量に依存してデータ保護ストレージボリュームへの書き込みの時間だけが変わるグラフとなる。

【0033】

また、業務ストレージボリュームで大量のデータ書き込みがあったとしても、ボリューム内の同じアドレスへのデータの頻繁な変更だけであれば、データ保護ストレージボリュームへの書き込みは当該データを１回書き込むだけとなる。

【0034】

図４はデータ保護ストレージボリュームでの書き込みデータ量監視のメリットを説明するグラフである。

【0035】

業務ストレージボリュームへの書き込みデータ量を示す上のグラフでは、月曜の１０：００ころ通常の業務により一時的に書き込みデータ量が増加しています。このようなデータの書き込みはデータ保護ストレージボリュームでバックアップを取る場合はデータの総量が多くないため異常が検知されることはありません。
一方、１５：００ころから始まる継続的な書き込みデータの増加は業務ストレージボリュームでは一点鎖線で示す書き込みデータ量の上限を超えないため異常と判断されることはない。しかしながら、データ保護ストレージボリュームでは業務ストレージのデータ変更が大量にあったため火曜の９：００に行われたバックアッププランＢＰ１のバックアップでは予定時間を超えたバックアップ時間（斜線部）となり異常と判断することができる。

【0036】

データ保護ストレージボリュームの監視では業務ストレージボリュームの変更領域の累積を見ることができるためランサムウェア攻撃等による業務ストレージボリューム大量のデータに対する暗号化やデータの圧縮、削除等をより正確に認識することができる。

【0037】

図５は本発明の実施例におけるバックアッププランテーブルの例である。バックアップを開始するスケジュールを登録するテーブルである。バックアッププランＩＤ５１，対象ｖｏｌｕｍｅ５２、バックアップの開始時刻５３、バックアップを行う曜日を格納したスケジュール５４の情報を格納する。

【0038】

図６は本発明の実施例におけるバックアップ管理テーブルの例である。バックアップが行われた記録を対象ボリューム毎に格納する。

【0039】

バックアップＩＤ６１、対象ｖｏｌｕｍｅ６２、バックアップが実施されたスケジュールを示すバックアッププランＩＤ６３、バックアップの開始日時６４、バックアップの終了日時６５、バックアップが正常に終わったか、異常に終わったかを示す終了ステータス６６、取得したバックアップを削除して良いかどうかを示すバックアップの削除可否フラグを対応付けて格納する。

【0040】

図７は本発明の実施例における閾値テーブルの例である。閾値ＩＤ７１、対象ボリューム７６，対象バックアッププランＩＤ７２毎にバックアップを始める時刻である開始時刻７３とバックアップが終了する時刻である終了時刻７４、書込みデータ量７７を定義する。この開始時刻７３と終了時刻７４はある程度の余裕をもって定義しておく必要があるが、終了時刻７４が早すぎると通常の業務によるホストの処理によって変更が加えられたＰＶｏｌ１７の更新内容をデータ保護ストレージ１６のＰＶｏｌ２０にバックアップすることができず、誤ったアラートを出力してしまうことがある。

【0041】

書き込みデータ量は書込みを行う時間を設定しているが、データ保護ストレージボリュームへの書き込み量が不安定な場合は記憶容量にしても良い。

【0042】

また、バックアップを行う曜日毎に閾値である終了時刻を変更するためにスケジュール７５にバックアップを実施する曜日を指定することができる。なお、この閾値やバックアッププラン等は、バックアップシステムを導入する際に事前見積もりに基づき設定される。但し、運用開始後に実運用に基づき調整されてもよい。例えば機械学習技術などを導入し、過去の数値に基づき閾値の精度を向上させるなどがある。

【0043】

図８は本発明の実施例における閾値テーブルに設定された閾値と保護ストレージボリュームのメトリクス測定値の例を説明するグラフである。

【0044】

図７で定義された閾値の月曜と火曜の閾値は点線８１で示される。実線８２はメトリクス測定値である。点線８１の山部分がバックアップが実施される可能性がある時間帯を示し、谷部分がバックアップが実施されない時間帯を示す。

【0045】

図９（ａ）と図９（ｂ）は本発明の実施例における異常イベントテーブルの例を示す。

【0046】

図９（ａ）ではバックアップデータの書き込み時間が予定されていた閾値の時刻を過ぎる書き込み量異常と、バックアップデータの書き込みが完了する書き込み量正常というイベント９３が発生したときにイベントＩＤ９１、発生したイベントに対応する閾値ＩＤ９２と対応付けてイベントの発生日時である発生時刻９４、サイバー攻撃の可能性あるかどうかを示すラベル９９とともに記録する。

【0047】

図９（ｂ）では異常が発生したときにイベントＩＤ９５、発生したイベントに対応する閾値ＩＤ９６と異常の発生日時である異常発生時刻９７とバックアップのデータ書き込みが完了し正常に戻った日時である異常終了時刻９８、サイバー攻撃の可能性あるかどうかを示すラベル９９を対応付けて記録する。

【0048】

どちらの形式を用いても良いがストレージシステムでどちらの形式でイベントを管理しているかに基づいて選んでも良い。

【0049】

図１０は本発明の実施例における異常イベントテーブルの値と保護ストレージボリュームのメトリクス測定値の例を示すグラフである。図９（ａ）のイベントＩＤ９１欄のイベント１とイベント２、図９（ｂ）のイベントＩＤ９５欄のイベント１で示す異常イベントが発生した例を説明する。

【0050】

点線１０２がデータ書き込みを予定されている時間帯を示す閾値で、実線１０１がメトリクス測定値である。この例では一点鎖線１０３で示される時刻にホスト側でＰＶｏｌ１７に異常なデータの書き込みが発生し、書き込まれたデータのバックアップを行うため火曜日の９：００から始まったＰＶｏｌ２０へのバックアップデータの書き込みが、バックアップの終了が予定されていた１０：３０になっても終わらず、１０：４９：５８まで行われるという異常が発生している。異常が発生している時間帯が斜線で示されている。

【0051】

図１１は本発明の実施例におけるバックアップ実行部のフローチャートの例を示す。

【0052】

バックアッププランテーブルの情報を取得しＳ１１１、バックアップの開始時刻になったかどうかを判定するＳ１１２。開始時刻でなければ一定時間待つＳ１１３。Ｓ１１２でバックアップ開始時刻になったと判定されたとき、実行するスケジュールのバックアッププランＩＤからバックアップ対象のｖｏｌｕｍｅＩＤを取得するＳ１１４。

【0053】

取得したｖｏｌｕｍｅＩＤでバックアップ管理テーブル１１のバックアップ情報をフィルタリングするＳ１１５。フィルタリングされたバックアップの世代数が最大値より少ないか判定するＳ１１６。

【0054】

最大値を超えていなければ第一のストレージ（業務ストレージ）でＰＶｏｌ１７のローカルコピーＳＶｏｌ１８を取得し、データ保護ストレージでバックアップを取得するＳ１１９。異常イベントテーブル１３から異常情報を取得しＳ１２０、バックアップ管理テーブル１１に取得したバックアップの情報を記入するＳ１２１。取得したバックアップが異常かどうか判定しＳ１２２、異常であれば取得したバックアップと一つ前の正常なバックアップの削除可否フラグを「不可」にするＳ１２３。バックアップが異常でなければ処理を終了する。

【0055】

Ｓ１１６でバックアップの世代数が最大値か、最大値を超えていれば削除可能なバックアップがあるかどうかをバックアップ管理テーブル１１のバックアップ削除可否フラグ６７を基に調べるＳ１１７。削除可能なバックアップがあれば最も古いバックアップを削除し、バックアップ管理テーブル１１からも削除するＳ１１８。このあとはＳ１１９以降のバックアップ処理を行う。

【0056】

Ｓ１１７で削除可能なバックアップが無ければエラーを出力し終了する。

【0057】

図１２は本発明の実施例における書き込みデータ量監視部のフローチャートの例である。

【0058】

閾値テーブル１２を読み込みＳ１３１、閾値監視対象期間かどうかを判定するＳ１３２。閾値監視対象期間でなければ一定時間待つＳ１３３。閾値監視対象期間であれば閾値テーブル１２の対象バックアッププランＩＤ７２から対象のｖｏｌｕｍｅＩＤ５２とバックアップ開始時刻５３を取得するＳ１３４。取得したｖｏｌｕｍｅＩＤ５２への書き込みを監視するＳ１３５。

【0059】

閾値を超過したかどうかを判断するＳ１３６。閾値は閾値テーブルの終了時刻７４までに書き込みが完了したか判定しても良く、書き込まれたデータの容量で判断しても良い。完了していなければ異常イベント記録部を呼び出しＳ１３７、閾値以下に戻ったか再度判定するＳ１３８。書き込みが完了していなければ一定時間待つＳ１３９。書き込みが完了していれば異常イベント記録部を呼び出すＳ１４０。Ｓ１３６で書き込みが完了していれば処理を終了する。

【0060】

図１３は本発明の実施例における異常イベント記録部のフローチャートの例である。異常の発生、終了をユーザの監視端末５に通知しＳ１８１、異常の発生時刻／終了時刻を異常イベントテーブル１３へ記録するＳ１８２。

【0061】

図１４は本発明の実施例における出力画面の例である。異常が発生し、異常イベント記録部がユーザに通知するときに異常が発生したボリュームの識別子を含むボリューム情報１９３と当該ボリュームに対応するホストの識別子を含むホスト情報１９２を異常通知画面１９１に出力することにより、ユーザは影響のあるホストやアプリケーションを特定することが可能となる。

【0062】

ボリュームとホストの対応はボリュームの情報からＬｕｎ（Ｌｏｇｉｃａｌ ｕｎｉｔ ｎｕｍｂｅｒ）、ＨｏｓｔＧｒｏｕｐの対応情報を取得し、ＨｏｓｔＧｒｏｕｐの情報から、ボリュームとＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）の対応情報を取得し、ＷＷＮとホストの対応情報を参照することにより得られる。

【0063】

また、ホストとアプリケーションは対応付けて運用されていることが多いためアプリケーションの特定も可能である。

【実施例0064】

図１５本発明の実施例におけるシステム構成の例を示したブロック図の例である。この例は業務ストレージやデータ保護ストレージがクラウド１００にある場合の例である。複数のシステムがクラウドにある場合、データ保護ストレージからバックアップの指示を出した場合に遅延が発生する可能性がある。

【0065】

また、バックアップの処理自体も他のシステムの影響を受け、予定した時刻に実行できないことも考えられる。

【0066】

図１６は本発明の実施例における書き込みデータ量監視部のフローチャートの例である。

【0067】

図１２のフローチャートで説明した第一の実施例の書き込みデータ量監視部の処理との違いは、閾値監視対象の時間に監視を行うとき、バックアップボリュームへの書き込み量を監視しＳ１６５、書き込み量が増加したかどうかを判定するＳ１６６。書き込み量が増加していない場合は一定時間待つＳ１６７。書き込み量が増加した場合はバックアッププランＩＤ７２の開始時刻７３との差を求め、終了時刻７４に差を加えることにより、異常かどうかを判定する基準である終了時刻７４を補正して異常の判定を行うＳ１６８。

【0068】

この処理を行うことにより他のシステムの影響を受けやすいクラウドで実装されたバックアップシステムであっても異常判定の精度を上げることができる。
以上実施の形態を例示したが、本発明は前述の実施の形態には限定されない。
例えば、図１２において、バックアップボリュームへの書き込み量を監視したが、これをバックアップがバックアップサイクルでデータの書き込みが発生し流量が頭打ちになることを利用しバックアップボリュームへの書き込み速度であるＷｒｉｔｅ Ｔｒａｎｓｆｅｒ Ｒａｔｅを用いて監視してもよい。
また、本発明により記録された異常イベントに基づき、ユーザが調査を行い異常イベントの真偽や対応を判断する間、一時的な対応を自動的に行うなどしてもよい。例えば、ユーザにメールで通知することや、自動的に容量を追加してバックアップを残す期間をあらかじめ定めた期間延ばすといった手段がある。