JP2023050384A - ストレージシステム及びデータ復旧方法 - Google Patents

ストレージシステム及びデータ復旧方法 Download PDF

Info

Publication number
JP2023050384A
JP2023050384A JP2021160452A JP2021160452A JP2023050384A JP 2023050384 A JP2023050384 A JP 2023050384A JP 2021160452 A JP2021160452 A JP 2021160452A JP 2021160452 A JP2021160452 A JP 2021160452A JP 2023050384 A JP2023050384 A JP 2023050384A
Authority
JP
Japan
Prior art keywords
data
volume
host
update
time
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.)
Pending
Application number
JP2021160452A
Other languages
English (en)
Inventor
一樹 松上
Kazuki Matsugami
彰 出口
Akira Deguchi
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 JP2021160452A priority Critical patent/JP2023050384A/ja
Priority to US17/691,253 priority patent/US20230113507A1/en
Publication of JP2023050384A publication Critical patent/JP2023050384A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • 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/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/0292—User address space allocation, e.g. contiguous or non contiguous base addressing using tables or multilevel address translation means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/568—Computer malware detection or handling, e.g. anti-virus arrangements eliminating virus, restoring damaged files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0664—Virtualisation aspects at device level, e.g. emulation of a storage device or system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • 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/815—Virtual
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1024—Latency reduction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/31—Providing disk cache in a specific location of a storage system
    • G06F2212/312—In storage controller
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Quality & Reliability (AREA)
  • Virology (AREA)
  • General Health & Medical Sciences (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】マルウェアに感染したホストによって破壊されたデータをバックアップから復元する際に、正常なホストから書き込まれた有効なデータの消失を防ぐ。【解決手段】ストレージシステム２０において、ストレージコントローラ２１は、ホスト（ホスト計算機３０）によるボリュームのデータ更新の履歴を当該ホストを識別可能な情報を添えて更新履歴情報（更新履歴管理テーブル２４０）に記録し、データ更新を無効にするホスト及び日時の指定を含むボリュームのデータの復旧が要求されたとき、更新履歴情報に基づいて、指定日時より後に指定ホストとは異なるホストによって更新されたデータ更新を有効にしたままで、指定日時より後に指定ホストによって更新されたデータ更新（データＡからデータＸへの更新）を無効にしてボリュームを復元する。【選択図】図１

Description

本発明は、ストレージシステム及びデータ復旧方法に関し、マルウェアに感染したホストによって破壊されたデータをバックアップから復元するストレージシステム及びデータ復旧方法に適用して好適なものである。
近年、ランサムウェアを代表とするマルウェアによる被害の増加により、セキュリティやバックアップへの投資額が増加傾向にある。感染の検出やデータの復元に関する新しい技術が求められており、ブロックストレージのバックアップ機能においてもマルウェアに対する機能の向上が期待されている。
例えば特許文献１には、バックアップシステムが取得したバックアップデータを、ストレージのローカルコピー機能を活用して複製することによりバックアップシステムから分離し、多世代で保持する仕組みが開示されている。
米国特許第１０５９２３５２号明細書
ストレージと複数のホストから構成されるシステムにおいて１つのホストがマルウェアに感染した場合、ファイアウォールでホスト間の感染を防いだとしても、感染したホストからアクセス可能なボリュームはマルウェアによってデータが破壊される可能性がある。しかし、このようにしてデータが破壊された場合、上記の従来技術では、バックアップを行った時点の状態にデータを復元するため、データ復元に用いるバックアップより後に登録されたデータは、感染を防いだはずの正常なホストのデータも含めて全て消失してしまう。すなわち、マルウェアに感染したホストから書き込まれたデータだけでなく、正常なホストから書き込まれたデータも含めて消してしまうため、感染の発覚が遅れると影響が拡大して多くの有効なデータが失われてしまうという問題があった。
本発明は以上の点を考慮してなされたもので、マルウェアに感染したホストによって破壊されたデータをバックアップから復元する際に、正常なホストから書き込まれた有効なデータの消失を防ぐことが可能なストレージシステム及びデータ復旧方法を提案しようとするものである。
かかる課題を解決するため本発明においては、記憶装置とストレージコントローラとを有し、前記ストレージコントローラによって前記記憶装置の記憶領域を仮想化したボリュームを複数のホストに提供するストレージシステムにおいて、前記ストレージコントローラは、前記ホストによる前記ボリュームのデータ更新の履歴を、当該ホストを識別可能な情報を添えて更新履歴情報に記録し、前記データ更新を無効にするホスト及び日時の指定を含む前記ボリュームのデータの復旧が要求されたとき、前記更新履歴情報に基づいて、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストとは異なるホストによって更新されたデータ更新を有効にしたままで、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストによって更新されたデータ更新を無効にして前記ボリュームを復元するストレージシステムが提供される。
また、かかる課題を解決するため本発明においては、記憶装置とストレージコントローラとを有し、前記ストレージコントローラによって前記記憶装置の記憶領域を仮想化したボリュームを複数のホストに提供するストレージシステムによるデータ復旧方法であって、前記ストレージコントローラが、前記ホストによる前記ボリュームのデータ更新の履歴を、当該ホストを識別可能な情報を添えて更新履歴情報に記録する更新履歴記録ステップと、前記データ更新を無効にするホスト及び日時の指定を含む前記ボリュームのデータの復旧が要求されたとき、前記ストレージコントローラが、前記更新履歴情報に基づいて、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストとは異なるホストによって更新されたデータ更新を有効にしたままで、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストによって更新されたデータ更新を無効にして前記ボリュームを復元するデータ復元ステップと、を備えるデータ復旧方法が提供される。
本発明によれば、マルウェアに感染したホストによって破壊されたデータをバックアップから復元する際に、正常なホストから書き込まれた有効なデータの消失を防ぐことができる。
本発明の一実施形態に係るストレージシステム２０によるデータの復元イメージの一例（その１）を説明するための図である。 本実施形態に係るストレージシステム２０の内部構成例を示すブロック図である。 ボリューム情報管理テーブル２１０の一例を示す図である。 論物マッピングテーブル２２０の一例を示す図である。 スナップショット管理テーブル２３０の一例を示す図である。 更新履歴管理テーブル２４０の一例を示す図である。 本実施形態におけるストレージシステム２０によるデータの復元イメージの一例（その２）を説明するための図である。 スナップショット取得処理の処理手順例を示すフローチャートである。 ライト処理の処理手順例を示すフローチャートである。 リビルド処理の処理手順例を示すフローチャートである。 本実施形態におけるストレージシステム２０によるデータの復元イメージの一例（その３）を説明するための図である。
以下、図面を参照して、本発明の実施形態を詳述する。なお、以下の説明では、同種の要素を区別せずに説明する場合には、添字や枝番を含む参照符号のうちの共通部分（添字や枝番を除く部分）を使用し、同種の要素を区別して説明する場合には、添字や枝番を含む参照符号を使用することがある。例えば、ホスト計算機を特に区別せずに説明する場合に「ホスト計算機３０」と記載するとき、個々のホスト計算機を区別して説明する場合には「ホスト計算機３０－１」、「ホスト計算機３０－２」のように記載することがある。
図１は、本発明の一実施形態に係るストレージシステム２０によるデータの復元イメージの一例（その１）を説明するための図である。図１には、ストレージシステム２０が複数のホスト計算機３０に接続する構成例が示されている。
詳細な内部構成は図２を参照しながら後述するが、ストレージシステム２０は、１以上のストレージコントローラ２１と各ストレージコントローラ２１に接続される１以上のドライブ２８とを備えて構成されるストレージシステムであって、複数のホスト計算機３０と、ネットワーク３１を介して接続される。
図１に示すように、ストレージコントローラ２１は、メモリ２４の内部に形成されたキャッシュ領域２０２に、ドライブ２８の物理的な記憶領域を仮想化して１つのＰ－ＶＯＬ（プライマリボリューム）１０００及び１以上のＳ－ＶＯＬ（セカンダリボリューム）１１００の論理ボリュームを構成する。Ｐ－ＶＯＬ１０００は、ストレージシステム２０が通常使用するプライマリボリュームであり、Ｓ－ＶＯＬ１１００は、セカンダリボリュームであって、Ｐ－ＶＯＬ１０００のデータを復元する際に用いられる。なお、Ｐ－ＶＯＬ１０００及びＳ－ＶＯＬ１１００は例えばパーシステントボリューム（永続ボリューム）であるが、これに限らず、通常の論理ボリュームであればよい。各ボリュームに格納されるデータ１０について、図１では、データ１０を区別するために、各データ１０に「Ａ」、「Ｂ」、「Ｃ」、「Ｘ」といった表記を行っている。なお、以降の説明では、これらのデータ１０をデータＡ、データＢ、データＣ、データＸと称することがある。
また、ストレージコントローラ２１は、メモリ２４の内部に形成されたバックアップ領域２０３において、各ボリュームのスナップショットを管理するスナップショット管理テーブル２３０や、ホスト計算機３０からのアクセスに伴う各ボリュームにおけるデータ更新の更新履歴を管理する更新履歴管理テーブル２４０を保持する。スナップショット管理テーブル２３０の詳細は、図５を参照しながら後述し、更新履歴管理テーブル２４０の詳細は、図６を参照しながら後述する。
以下、図１に示すデータの復元イメージについて説明する。Ｐ－ＶＯＬ１０００には、ホスト計算機３０－１（ホストＡ）及びホスト計算機３０－２（ホストＢ）からデータ１０が書き込まれる。データ１０は、Ｐ－ＶＯＬ１０００では論理アドレスが割り当てられるだけであり、実データは記憶装置（ドライブ２８またはメモリ２４）の物理的な記憶領域に格納される。データ１０に割り当てられた論理アドレスは、ホスト計算機３０から認識され、ボリュームの作成や容量拡大等の指示がない限り、基本的には不変である。そして、Ｐ－ＶＯＬ１０００に割当てられた論理アドレスと実データが格納される記憶領域の物理アドレスとの対応関係は、ストレージコントローラ２１において所定の情報（例えば、後述する論物マッピングテーブル２２０）で管理される。なお、図１の場合、各ホスト計算機３０からボリュームへのアクセス先は規定されていない。また、Ｐ－ＶＯＬ１０００は、定期的なスナップショット機能の実施により、ボリューム単位でバックアップ（スナップショット）が取得される。具体的には、図１に例示した更新履歴管理テーブル２４０を参照すると、Ｐ－ＶＯＬ１０００は、当初、データＡ，Ｂを格納しており、スナップショット管理テーブル２０６を参照すると、その時点でスナップショットが取得されていることが分かる。
その後、更新履歴管理テーブル２４０によれば、ホストＡによってデータＡがデータＸに更新され、ホストＢによってデータＢがデータＣに更新されたことにより、Ｐ－ＶＯＬ１０００は、図１に示すようにデータＡ，Ｃを格納するようになる。
このとき、上述したスナップショットが取得された後のタイミングでホストＡがマルウェアに感染され、感染後のホストＡからデータＸの書き込みが行われたとする。一方、ホストＢは、マルウェアに感染することなく、ホストＡがマルウェアに感染した後のタイミングでデータＣを書き込んだとする。このとき、データＸがマルウェアによって作成された不正なデータであった場合、その更新により、元のデータＡが破壊される可能性がある。データＸは暗号化されていることもある。そこで、ストレージシステム２０では、ボリューム内のデータを正常化するために、ホストＡからのアクセスを遮断するとともに、Ｐ－ＶＯＬ１０００のデータを復旧する必要がある。
この場合、従来の一般的なデータ復旧では、ホストＡがマルウェアに感染する前に取得されたスナップショットを利用して、Ｓ－ＶＯＬ１１００にデータを復元し、異常がないことが確認された後、Ｐ－ＶＯＬ１０００にコピーしてＰ－ＶＯＬ１０００のデータを復元することが行われる。但し、スナップショットはボリューム単位でデータ構成を記録しているため、スナップショットを用いた従来のデータ復旧では、ボリューム全体のデータが旧データで復元されてしまう。具体的には、図１に示すＳ－ＶＯＬ１１００－１が、スナップショットを利用した従来のデータ復旧時のＳ－ＶＯＬ１１００のデータ構成を表したものである。Ｓ－ＶＯＬ１１００－１を見ると、スナップショットに記録された「旧データ」の通り、データＡ，Ｂに復元されており、マルウェアに感染したホストＡから更新されたデータＸが削除されていることが分かる。しかし、本発明の課題でも述べたように、このような従来のデータ復旧では、マルウェアに感染していない正常なホストＢから更新されたデータＣも削除されてしまう（データＢに巻き戻されてしまう）ことから、有効なデータが消失し、データ復旧に時間が掛かってしまうという問題があった。
そこで、上記の課題を解決するために、本発明に係るストレージシステム２０は、ホストごとのデータ更新履歴を管理する情報（更新履歴管理テーブル２４０）を有するようにし、当該情報に基づいて、マルウェアに感染したホストによる更新を分離して、データを復元する。本例の場合は、マルウェアに感染したホストＡから更新されたデータＸだけを、スナップショットにおけるデータ構成との変更差分を利用して、更新前のデータＡに復元し、正常なホストＢから更新されたデータＣについては、削除しない（更新前のデータＢに復元しない）ようにする。図１に示すＳ－ＶＯＬ１１００－２は、このような本実施形態に係るストレージシステム２０によるデータ復旧時のＳ－ＶＯＬ１１００のデータ構成を表したものである。Ｓ－ＶＯＬ１１００－２を見ると、データＸが削除されてデータＡで復元されている一方で、データＣはデータＢで復元されることなく、最新状態が維持されていることが分かる。したがって、このようなＳ－ＶＯＬ１１００－２のデータ構成をＰ－ＶＯＬ１０００にコピーすれば、Ｐ－ＶＯＬ１０００において、マルウェアに感染したホストによって破壊されたデータをバックアップから復元するとともに、正常なホストから書き込まれた有効なデータの消失を防ぐことができる。
以上が、本実施形態に係るストレージシステム２０がマルウェアに感染したホストによって破壊されたデータをバックアップから復元する際のデータ復旧の概要である。以下では、このようなデータ復旧を実現するために必要なストレージシステム２０の構成及び処理について詳述する。
図２は、本実施形態に係るストレージシステム２０の内部構成例を示すブロック図である。ストレージシステム２０は、１以上のストレージコントローラ２１及び１以上のドライブ２８を備え、複数のホスト計算機３０とネットワーク３１を介して通信可能に接続される。
図２に示すように、それぞれのストレージコントローラ２１は、ＦＥ Ｉ／Ｆ２２、プロセッサ２３、メモリ２４、バス２５、ＢＥ Ｉ／Ｆ２６、及びストレージＩ／Ｆ２７を備える。
ＦＥ Ｉ／Ｆ２２は、フロントエンドのインタフェースであって、例えばネットワーク３１を介してホスト計算機３０と間でデータの入出力（送受信）を行う。一方、ＢＥ Ｉ／Ｆ２６は、バックエンドのインタフェースであって、例えばドライブ２８とで入出力を行う。ストレージＩ／Ｆ２７は、ストレージシステム２０内の閉じた通信（例えばコントローラ間通信）向けのインタフェースである。また、バス２５は、ストレージコントローラ２１の内部構成を互いに接続する信号線である。
プロセッサ２３は、ＣＰＵ（Central Processing Unit）等のプロセッサであって、メモリ２４等の記憶装置に保持されたプログラムを実行することによって、プログラムによる各種機能を実現する。
メモリ２４は、ＲＡＭ（Random Access Memory）等の記憶装置であって、プログラムやデータを記憶する。メモリ２４は、内部に、プログラムを保持するプログラム領域２０１、キャッシュデータを保持するキャッシュ領域２０２、バックアップデータを保持するバックアップ領域２０３、及び各種のテーブルデータ（ボリューム情報管理テーブル２１０、論物マッピングテーブル２２０、スナップショット管理テーブル２３０、更新履歴管理テーブル２４０）を管理するテーブル管理領域２０４を有する。
図３は、ボリューム情報管理テーブル２１０の一例を示す図である。ボリューム情報管理テーブル２１０は、ストレージコントローラ２１が提供する各ボリュームに関する各種情報を管理するためのテーブルデータであって、テーブル管理領域２０４に格納される。
ボリューム情報管理テーブル２１０は、ボリューム単位でレコードを有し、例えば、ボリュームＩＤ２１１、ボリュームサイズ２１２、スナップショット設定２１３、スナップショット管理テーブルＩＤ２１４、スナップショット取得条件２１５のデータ項目を有する。
ボリュームＩＤ２１１は、当該レコードのボリュームを一意に識別する識別子（ボリュームＩＤ）を示す。ボリュームサイズ２１２は、当該ボリュームに割り当てられた容量を示す。スナップショット設定２１３は、当該ボリュームにおけるスナップショット機能の設定を「有効」または「無効」で示す。スナップショット管理テーブルＩＤ２１４は、当該ボリュームのスナップショットを管理するスナップショット管理テーブル２０６の識別子（スナップショット管理テーブルＩＤ）を示す。スナップショット取得条件２１５は、例えば管理者から設定される、スナップショットを取得する条件を示す。スナップショット設定２１３が「無効」である場合、同レコードにおけるスナップショット管理テーブルＩＤ２１４及びスナップショット取得条件２１５は特段の値を持たなくてもよい。
図４は、論物マッピングテーブル２２０の一例を示す図である。論物マッピングテーブル２２０は、データを記憶する論理アドレスと物理アドレスとの対応関係（論物マッピング）に関する情報を管理するためのテーブルデータであって、テーブル管理領域２０４に格納される。
論物マッピングテーブル２２０は、ボリュームに格納されたデータの最小単位でレコードを有し、例えば、論理アドレス２２１、物理アドレス２２２、データサイズ２２３、及びデータ登録ホスト２２４のデータ項目を有する。
論理アドレス２２１は、当該レコードのデータについて、ボリュームに割り当てられた論理アドレスを示す。物理アドレス２２２は、論理アドレス２２１に対応付けられたドライブ２８等の物理アドレスであり、言い換えれば、当該データが格納される物理アドレスを示す。データサイズ２２３は、当該データのデータサイズを示す。
データ登録ホスト２２４は、当該データを送信したホスト（アクセス元のホスト）の識別情報を示す。すなわち、データ登録ホスト２２４に示されるホストの識別情報は、当該データにアクセスするホストを識別する情報である。なお、図２のシステム構成の場合は、データ登録ホスト２２４には、ホスト計算機３０の何れかの識別情報が指定されるが、本実施形態に係るストレージシステム２０において、ボリュームのデータへのＩＯの接続先は、ホスト計算機３０に限定されるものではなく、ストレージシステム２０の構成に応じて、様々な接続先（ホスト）を登録することができる。具体的には例えば、後述する図７の構成のように、ホスト計算機３０において、複数の仮想マシン（ＶＭ）が構築される場合には、図４に例示したように、仮想マシン単位で識別情報を登録してもよいし、コンテナ等を単位として識別情報を登録してもよい。また、ホストごとに登録されるデータのアクセス先は、ボリュームを単位とすることに限定されず、例えば、ボリューム内に形成される複数の仮想ディスクイメージ（ＶＭＤＫ）のそれぞれを単位とする等してもよい。さらに、上記のホスト等を識別する際には、物理ポートの情報だけでなく仮想ポートの情報を利用してもよい。
なお、以下の説明では、ストレージシステム２０におけるデータの書き込み方式の一例として、追い書き方式（ログストラクチャー方式）を採用する。
追い書き方式の場合、データの更新時に、ストレージコントローラ２１は、論理アドレスを変えずに新しい物理アドレスにデータを格納する。このときストレージコントローラ２１は、論物マッピングテーブル２２０において、更新後のデータの論理アドレス２２１に対応する物理アドレス２２２を古い物理アドレスから新しい物理アドレスに変更し、データサイズ２２３を更新後データのデータサイズに変更し、データ登録ホスト２２４をデータ更新のアクセス元ホストの識別情報に変更する。一方、更新前データは、古い物理アドレスに格納されたままガベージ状態で残され、ガベージコレクションが実行された場合には削除されて未使用記憶領域となる。そしてストレージコントローラ２１は、図６で後述する更新履歴管理テーブル２４０において、データ更新の履歴として、更新前後の論理アドレスと物理アドレスとの対応関係を、データ更新前後のアクセス元ホストの識別情報等（データサイズの他、データ更新時刻等を含んでもよい）とともに記録する。このようにデータ更新に伴って論物マッピングテーブル２２０及び更新履歴管理テーブル２４０が更新されることにより、ストレージコントローラ２１は、データごとの論理アドレスに経時的に複数の物理アドレスを対応付けて管理することができるため、後述するリビルド処理において、所望の更新前データを復元することが可能となる。
また、本実施形態におけるデータの書き込み方式は、上述した追い書き方式に限定されるものではなく、他にも例えば、更新差分を退避する方法であってもよい。更新差分を退避する方法の場合、ストレージコントローラ２１は、データ更新時に、更新前データをコピーして退避させてから更新データを書き込み、論物マッピングテーブル２２０及び更新履歴管理テーブル２４０を更新することにより、コピー先の物理アドレスを復元用の情報として管理することができる。このとき、コピー先の論理アドレスと物理アドレスの対応関係は、通常ではホスト計算機３０からは見えない状態になることが一般的である。あるいは、更新差分を退避する方法の別手法として、ストレージコントローラ２１が、更新前データをメタコピーして退避させることにより、コピー先のメタの論理アドレスを復元情報として管理するようにしてもよい。
以上のように、何れの書き込み方式を採用する場合であっても、本実施形態のストレージシステム２０においては、データを更新しても、更新前の物理データはすぐに消えずに残るため、データ復元に利用することができる。
図５は、スナップショット管理テーブル２３０の一例を示す図である。スナップショット管理テーブル２３０は、スナップショットに関する情報を管理するためのテーブルデータであって、スナップショット管理テーブルＩＤ２１４で管理されるスナップショットを単位として、テーブル管理領域２０４に格納される。
スナップショット管理テーブル２３０は、例えば、スナップショット取得時刻２３１、論理アドレス２３２、物理アドレス２３３、及びデータサイズ２３４のデータ項目を有する。
スナップショット取得時刻２３１は、スナップショットを取得した日時を示す。論理アドレス２３２は、スナップショットを取得したデータのボリューム上の論理アドレスを示し、物理アドレス２３３は、当該スナップショットにおいて当該データが格納されたドライブ２８の物理アドレス（当該データのバックアップ先の物理アドレス）を示す。データサイズ２３４は、当該データのデータサイズを示す。
図６は、更新履歴管理テーブル２４０の一例を示す図である。更新履歴管理テーブル２４０は、データの更新履歴を管理するためのテーブルデータであって、テーブル管理領域２０４に格納される。
更新履歴管理テーブル２４０は、例えば、更新履歴取得期間２４１、データ登録ホスト２４２、論理アドレス２４３、更新前物理アドレス２４４、更新前データ登録ホスト２４５、更新後物理アドレス２４６、及びデータサイズ２４７のデータ項目を有する。
更新履歴取得期間２４１は、更新履歴のレコードを取得した期間を示す。データ登録ホスト２４２は、更新データを登録した登録ホストの識別情報を示し、更新データのアクセス元を識別することができる。更新履歴取得期間２４１は、連続的に記録され、各記録の期間は任意に設定可能である。但し、後述するリビルド処理において、データ復旧の起点とするスナップショットから無効開始時刻までの更新履歴を確認するためには、各記録の期間は、定期的なスナップショットの取得周期を超えない程度に短い期間（より好適には、スナップショットの取得周期よりも短い期間）であることが好ましく、また、期間の途中でスナップショットが取得された場合にはレコードを分けて記録されることが好ましい。また、更新履歴取得期間２４１に代えて、あるいは加えて、個々のデータ更新の更新時刻（更新日時）を記録するようにしてもよい。論理アドレス２４３は、更新データのボリューム上の論理アドレスを示す。更新前物理アドレス２４４は、更新前のデータ（更新されたデータ）が格納されていた物理アドレスを示す。更新前データ登録ホスト２４５は、更新前のデータの登録ホストの識別情報を示す。更新後物理アドレス２４６は、更新データが格納された物理アドレスを示す。データサイズ２４７は、更新データのデータサイズを示す。
なお、更新履歴管理テーブル２４０は、全てのデータ更新の履歴を対象として記録するようにしてもよいし、登録ホストが変わるデータ更新（それまでとは異なるホストによるデータ更新）の履歴のみを対象として記録するようにしてもよい。前者の場合は、更新前物理アドレス２４４及び更新前データ登録ホスト２４５の項目を省略することによってデータ量を削減してもよい。後者の場合は、更新前物理アドレス２４４の項目を省略することはできないが（更新前データ登録ホスト２４５の項目は省略可能）、記録対象の更新履歴が前者よりも少なくなることから、データ量を抑制することができる。
図７は、本実施形態におけるストレージシステム２０によるデータの復元イメージの一例（その２）を説明するための図である。図７には、ストレージシステム２０が複数の仮想マシン４１に接続する構成例が示されており、各ホスト（仮想マシン４１）から各ボリュームへのアクセス先が仮想ディスクイメージ２０５単位で規定された構成となっている。
詳しく説明すると、図７のホスト計算機３０では、ハイパーバイザ４０上に複数の仮想マシン（ＶＭ）４１が構築されている。また、ストレージコントローラ２１において、各ボリューム（Ｐ－ＶＯＬ１０００，Ｓ－ＶＯＬ１１００）のデータ管理領域は、複数の独立した仮想ディスクイメージ２０５に分割されており、仮想ディスクイメージ２０５ごとにアクセス可能な仮想マシン４１が登録されている。図７の場合、ＶＭ４１－１（ＶＭ１）からは仮想ディスクイメージ２０５－１にデータ１０が書き込まれ、ＶＭ４１－２（ＶＭ２）からは仮想ディスクイメージ２０５－２にデータ１０が書き込まれ、ＶＭ４１－３（ＶＭ３）からは仮想ディスクイメージ２０５－３にデータ１０が書き込まれる。
以下、図７に示すストレージシステム２０の接続例におけるデータの復元イメージについて説明する。なお、図１の説明と類似する部分については、詳細な説明を省略する。例えば、データＸは、図１と同様、マルウェアに感染したホスト（本例ではＶＭ４１）から更新された不正なデータであり、暗号化されている場合もある。
図７では、Ｐ－ＶＯＬ１０００は、当初、データＡ，Ｂ，Ｃを格納しており、その後、仮想ディスクイメージ２０５－１のアクセス元として登録されたＶＭ４１－１（ＶＭ１）によってデータＡがデータＸに更新され、仮想ディスクイメージ２０５－２のアクセス元として登録されたＶＭ４１－２によってデータＢがデータＥに更新されている。なお、データＸをストレージシステム２０に送信したとき、ＶＭ１はマルウェアに感染されているとする。
上記の状況になったとき、ストレージシステム２０は、ボリューム内のデータを正常化するために、マルウェアに感染したＶＭ１から仮想ディスクイメージ２０５－１へのアクセスを遮断するとともに、更新履歴管理テーブル２４０に基づいて、感染後のＶＭ１によって更新された仮想ディスクイメージ２０５－１のデータＸを選択的に削除する態様で、Ｐ－ＶＯＬ１０００のデータを復旧する。
図７に示すＳ－ＶＯＬ１１００は、ストレージシステム２０によるデータ復元時のデータ構成を表したものである。Ｓ－ＶＯＬ１１００を見ると、仮想ディスクイメージ２０５－１のみ、ＶＭ１がマルウェアに感染する前に更新されたデータＡが復元されており、その他の仮想ディスクイメージ２０５－２，２０５－３では、最新状態のデータＥ，Ｃで復元されていることが分かる。したがって、このようなＳ－ＶＯＬ１１００のデータ構成をＰ－ＶＯＬ１０００にコピーすれば、Ｐ－ＶＯＬ１０００において、マルウェアに感染したホスト（ＶＭ１）によって破壊されたデータをバックアップから復元するとともに、正常なホスト（ＶＭ２，ＶＭ３）から書き込まれた有効なデータの消失を防ぐことができる。
以下では、本実施形態に係るストレージシステム２０において実行される各種処理を説明する。
図８は、スナップショット取得処理の処理手順例を示すフローチャートである。スナップショット取得処理は、例えば周期的に実行され、ボリューム情報管理テーブル２１０に設定されたスナップショット取得条件２１５に従って、プロセッサ２３がスナップショットを保存する。
図８によればまず、プロセッサ２３が、ボリューム情報管理テーブル２１０のボリューム（ボリュームＩＤ２１１）ごとにスナップショット設定２１３を参照し、スナップショット機能が「無効」に設定されているか否かを判定する（ステップＳ１０１）。スナップショット機能が「無効」である場合は（ステップＳ１０１のＹＥＳ）、ステップＳ１０２に進み、スナップショット機能が「有効」である場合は（ステップＳ１０１のＮＯ）、ステップＳ１０４に進む。
ステップＳ１０２では、プロセッサ２３は、ユーザ（管理者）に対して、スナップショット機能を有効にするかを確認し、有効にするとの回答が得られた場合は、ボリューム情報管理テーブル２１０のスナップショット設定２１３に「有効」を設定し、提示されたスナップショット取得条件をスナップショット取得条件２１５に設定する。スナップショット機能を有効にするとの回答が得られない場合は、プロセッサ２３は対象ボリュームに対するスナップショット取得処理を終了する。なお、ステップＳ１０２，Ｓ１０３の処理は、必ずしも実行されなくてもよい。
次に、プロセッサ２３は、対象ボリュームのスナップショットを管理するスナップショット管理テーブルＩＤの割り当てを行い、割り当てられたＩＤをスナップショット管理テーブルＩＤ２１４に登録する（ステップＳ１０３）。その後、ステップＳ１０４に進む。
ステップＳ１０４では、プロセッサ２３は、現在の日時等を参照して、スナップショットの取得条件を満たすか否かを判定する。スナップショット取得条件を満たす場合は（ステップＳ１０４のＹＥＳ）、ステップＳ１０５に進み、対象ボリュームに対するスナップショットの取得を行う。一方、スナップショット取得条件を満たさない場合は（ステップＳ１０４のＮＯ）、対象ボリュームに対するスナップショット取得処理を終了する。
ステップＳ１０５では、プロセッサ２３は、スナップショット管理テーブル２３０にレコードを新規作成し、現在日時をスナップショット取得時刻２３１に記録し、さらに、論物マッピングテーブル２２０の情報をコピーし、スナップショット管理テーブル２３０の対応するデータ項目（論理アドレス２３２、物理アドレス２３３、データサイズ２３４）にコピーする。
次に、プロセッサ２３は、スナップショット取得時点における情報を更新前情報として更新履歴管理テーブル２４０に登録し（ステップＳ１０６）、スナップショット取得処理を終了する。具体的には、プロセッサ２３は、更新履歴管理テーブル２４０において、更新履歴取得期間２４１に現在時刻が含まれるレコードを探索し（存在しない場合はレコードを新規作成し）、当該レコードの論理アドレス２４３、更新前物理アドレス２４４及び更新前データ登録ホスト２４５を登録する。より詳細には、論理アドレス２４３及び更新前物理アドレス２４４には、ステップＳ１０５でスナップショット管理テーブル２３０に登録した論理アドレス２３２及び物理アドレス２３３が登録され、更新前データ登録ホスト２４５には、ステップＳ１０５でコピーした論物マッピングテーブル２２０のデータ登録ホスト２２４の情報が登録される。なお、更新履歴管理テーブル２４０は、少なくともスナップショットの取得ごとに更新履歴取得期間２４１を閉じ、以降は、別の更新履歴取得期間のレコードを作成することが好ましい。
図９は、ライト処理の処理手順例を示すフローチャートである。ライト処理は、ホストからボリュームにデータを書き込むときに実行される処理であって、ストレージコントローラ２１のＦＥ Ｉ／Ｆ２２がホスト（例えばホスト計算機３０やＶＭ４１）からライト要求を受け取ったときに、プロセッサ２３によって処理が開始される。
図９によればまず、プロセッサ２３は、各ボリュームに対して排他制御を実施し（ステップＳ２０１）、ライト要求に対するＲｅａｄｙ応答を要求元のホストに送信する（ステップＳ２０２）。
次に、プロセッサ２３は、ライトデータをキャッシュ領域２０２に転送し（ステップＳ２０３）、当該ライトデータのドライブ２８への書き込みが必要か否かを判定する（ステップＳ２０４）。ステップＳ２０４におけるドライブ２８への書き込み要否の判定は、ストレージシステム２０におけるキャッシュ制御に依存するものであり、詳細な説明は省略する。
ステップＳ２０４において、ライトデータのドライブ２８への書き込みが必要と判定した場合（ステップＳ２０４のＹＥＳ）、プロセッサ２３は、ライトデータをドライブ２８に書き込み（ステップＳ２０５）、ステップＳ２０７に進む。
一方、ステップＳ２０４において、ライトデータのドライブ２８への書き込みが不要と判定した場合（ステップＳ２０４のＮＯ）、プロセッサ２３は、ステップＳ２０３でライトデータが書き込まれたキャッシュをミラーリングすることにより、キャッシュの二重化を行い（ステップＳ２０６）、ステップＳ２０７に進む。ストレージコントローラ２１におけるキャッシュの二重化は一般的な処理であり、詳細な説明は省略する。
ステップＳ２０７では、プロセッサ２３は、ステップＳ２０３～ステップＳ２０６によるライトデータの書き込みに基づいて、論物マッピングテーブル２２０の情報を更新する。なお、図４の論物マッピングテーブル２２０の説明で述べたように、本実施形態では、データの書き込み方式に追い書き方式または更新差分を退避する方式等を採用することにより、ライトデータの書き込み（データ更新）が行われたときでも、更新前の物理データはすぐには消えずに残るため、後述するデータの復元に利用することができる。
次に、プロセッサ２３は、ボリューム情報管理テーブル２１０を参照し、ライトデータが書き込まれたボリュームにおいてスナップショット設定２１３が「有効」に設定されているか否かを判定する（ステップＳ２０８）。スナップショット設定が有効である場合は（ステップＳ２０８のＹＥＳ）、ステップＳ２０９を経てステップＳ２１０に進み、スナップショット設定が無効である場合は（ステップＳ２０８のＮＯ）、ステップＳ２０９をスキップしてステップＳ２１０に進む。
ステップＳ２０９では、プロセッサ２３は、ライトデータの書き込み結果によって更新履歴管理テーブル２４０を更新する。具体的には、論理アドレス２４３にライトデータの論理アドレスを有するレコードにおいて、ドライブ２８やメモリ２４（キャッシュ）の書き込み先アドレスを更新後物理アドレス２４６に登録する。なお、ステップＳ２０９の処理は、データライト時の更新差分を記録することを目的としているが、ストレージシステム２０における性能低下を考慮して、常時は差分を記録しないといった設定がなされてもよい。
そしてステップＳ２１０では、プロセッサ２３は、ライト要求に対する完了応答を要求元のホストに送信し、次いで、ステップＳ２０１で実施した排他制御を解除し（ステップＳ２１１）、ライト処理を終了する。
図１０は、リビルド処理の処理手順例を示すフローチャートである。リビルド処理は、マルウェアに感染してホストが壊れた場合に、マルウェアに感染したホストからアクセス可能なボリュームのデータがマルウェアによって破壊されるおそれがあることを鑑みて、当該ボリュームのデータをホストがマルウェアに感染する前のデータに復元する処理である。ホストのマルウェアへの感染は、例えばホストユーザが利用しているウィルス検知ソフトによって検知される。なお、リビルド処理の開始時には、各ボリュームへのデータＩＯが停止される。
図１０によればまず、管理者であるユーザが、データ更新を無効にするホスト（ホスト計算機３０や仮想マシン４１等）を指定する（ステップＳ３０１）。ステップＳ３０１で指定するホストは、具体的には、マルウェアに感染したホストであり、以下、指定ホストとも称する。
次に、ユーザは、ステップＳ３０１で指定したホストによるデータ更新の無効開始時刻を指定する（ステップＳ３０２）。「無効開始時刻」は、指定ホストによる更新データを無効にすることによって復旧したいデータのタイミングを示すものであって、任意の時間（日時）を指定可能である。本例の場合、ホストがマルウェアに感染したと推定される時刻よりも少し前のタイミングが無効開始時刻として指定されることが好ましい。
以上ステップＳ３０１，Ｓ３０２の指定を受けて、プロセッサ２３が、リビルドの処理を開始する。ここで、本実施形態に係るストレージシステム２０では、複数の方法によってリビルド処理を実行することができ、図１６に示したステップＳ３０３以降の処理は、そのうちの１つの方法（第１の方法）の処理手順を示している。そこで、以下ではまず、図１６に沿って、第１の方法によるリビルド処理について説明する。
第１の方法は、データ更新を無効にするホストとその無効開始の時刻（日時）とが指定されたときに、指定日時より後に指定ホストから更新されたデータを、指定日時以前のスナップショットをデータ復旧の起点として、更新履歴管理テーブル２４０を用いて更新前の状態に復元する方法である。
第１の方法によればまず、プロセッサ２３は、スナップショット管理テーブル２３０を参照し、ステップＳ３０２で指定された無効開始時刻以前に取得されたスナップショットから「（データ更新を無効にするデータの）データ復旧の起点」とするスナップショットを１つ選択する（ステップＳ３０３）。なお、後述する復元データの特定における処理負荷を考慮すると、ステップＳ３０３では、無効開始時刻以前の比較的近いタイミングで取得されたスナップショットが「データ復旧の起点」として選択されることが好ましい。
次に、プロセッサ２３は、現ボリューム（Ｐ－ＶＯＬ１０００）で論理アドレスが割り当てられたすべてのデータについて、ステップＳ３０１で指定された指定ホストと更新履歴管理テーブル２４０の更新履歴とに基づいて、データ更新の書き込みホスト（データ登録ホスト）ごとに、更新前データによる復元が必要なデータ（以後、「第１種別のデータ」とも称する）であるか、更新前データによる復元が不要なデータ（以後、「第２種別のデータ」とも称する）であるかを判別する。なお、第２種別のデータは、更新前データによる復元が不要というだけであって、リビルド処理において復元されないわけではなく、第１の方法では、後述するように最新状態の現データによって復元される。さらにプロセッサ２３は、判別した第１種別のデータについて、ステップＳ３０２で指定された無効開始時刻に基づいて、その復元データ（すなわち、更新前データ）の物理アドレスを特定する（ステップＳ３０４）。
ステップＳ３０４の処理で判別する第１種別のデータとは、無効開始時刻より後に指定ホストによるデータ更新が行われたデータである。図１の例でいえば、Ｐ－ＶＯＬ１０００のデータＸであり、図７の例で言えば、Ｐ－ＶＯＬ１０００の仮想ディスクイメージ２０５－１のデータＸである。第１の方法では、この第１種別のデータは、具体的には、更新履歴管理テーブル２４０を参照し、無効開始時刻から現在までの期間に含まれる更新履歴のうち、データ登録ホスト２４２が指定ホストである更新履歴を検索することによって、判別することができる。
また、ステップＳ３０４で特定する第１種別のデータに対する復元データは、無効開始時刻の直前の更新前データである。第１の方法では、ステップＳ３０３で選択したスナップショットのデータ構成を起点として、この復元データの物理アドレスを特定する。具体的には、更新履歴管理テーブル２４０を参照し、スナップショットの取得時刻（図５のスナップショット取得時刻２３１参照）から無効開始時刻までの間に、第１種別のデータの更新履歴が存在するかを検索する。該当する１以上の更新履歴が存在する場合には、第１種別のデータに属する各データの論理アドレス（論理アドレス２４３）ごとに、無効開始時刻に最も近い更新履歴における更新後物理アドレス２４６を、当該論理アドレスに対応する物理アドレス（すなわち、復元データの物理アドレス）として特定する。補足すると、ボリュームデータに割り当てられた論理アドレスは、データ更新によって変更されない。また、上記「該当する更新履歴」が存在しない場合は、第１種別のデータに割り当てられたすべての論理アドレスについて、データ復旧の起点とするスナップショットのデータ構成に示される物理アドレス（図５の物理アドレス２３３参照）を、対応する物理アドレス（すなわち、復元データの物理アドレス）として特定する。
ステップＳ３０４では、上記のようにして復元データの論理アドレス及び物理アドレスを特定することにより、第１種別のデータにおけるスナップショット取得時より後の無効開始時刻までの間のデータ更新を、復元データに反映させることが可能となる。また、第１の方法では、スナップショットを起点として復元データを探索することにより、最新状態のデータ構成から遡って復元データを探索する場合よりも、探索に要する時間や負荷を軽減することができる。
次に、プロセッサ２３は、データを復元するセカンダリボリューム（例えばＳ－ＶＯＬ１１００）における論物マッピングを作成する（ステップＳ３０５）。なお、ステップＳ３０５において、プロセッサ２３は、更新前データによる復元が必要な第１種別のデータと、更新前データによる復元が不要な第２種別のデータ（無効開始時刻より後にアクセス元がマルウェアに感染した指定ホストに変更されていないデータであり、図７の例でいえば、Ｐ－ＶＯＬ１０００の仮想ディスクイメージ２０５－２，２０５－３のデータ）とで、以下のように異なる処理を実行する。
第１種別のデータについては、ステップＳ３０５においてプロセッサ２３は、ステップＳ３０１で指定されたホスト及びステップＳ３０４で判別した第１種別のデータの論理アドレスをキーとして、論物マッピングテーブル２２０上の対応する論理アドレスに、ステップＳ３０４で特定した復元データの物理アドレスを記録することにより、セカンダリボリュームに第１種別のデータを復元する。
また、第２種別のデータについては、プロセッサ２３は、更新履歴管理テーブル２４０の最新レコードにおける論理アドレス２４３及び更新後物理アドレス２４６の組み合わせを用いて（あるいは、論物マッピングテーブル２２０で管理されている現データの論物対応を参照して）、セカンダリボリュームにおける論理アドレスと物理アドレスとのマッピングを作成する。このマッピングにより、セカンダリボリュームでは、マルウェアに感染しなかったホストからアクセスされた第２種別のデータ（言い換えると、無効開始時刻より後に、マルウェアに感染したホストからアクセスされていないデータ）は、最新のデータ構成によって復元される。
次に、プロセッサ２３は、ステップＳ３０５でデータを復元したセカンダリボリュームについて、管理者に異常がないかの確認を求める（ステップＳ３０６）。セカンダリボリュームのデータに異常がない（正常である）と確認された場合は（ステップＳ３０６のＹＥＳ）、ステップＳ３０７に進む。一方、セカンダリボリュームのデータに異常があると確認された場合は（ステップＳ３０６のＮＯ）、ステップＳ３０２で指定された無効開始時刻が遅すぎる（指定ホストが既にマルウェアに感染した後である）可能性が考えられることから、ステップＳ３０２に戻る。ステップＳ３０２に戻った場合は、管理者に別の無効開始時刻（好ましくは、現在の指定日時よりも前の日時）を指定させるようにしてもよいし、プロセッサ２３が、現在の指定日時よりも少し前（例えばスナップショット取得の１周期分だけ前）の無効開始時刻を設定して、ステップＳ３０３以降の処理を行うようにしてもよい。
そして、ステップＳ３０７では、プロセッサ２３は、セカンダリボリュームに作成した論物マッピングを、プライマリボリューム（例えばＰ－ＶＯＬ１０００）にコピーし、リビルド処理を終了する。ステップＳ３０７の処理によって、感染したホストによって更新されたデータを復旧したセカンダリボリュームのデータが、プライマリボリュームにコピーされ、正式にデータ復旧が完了する。
以上のように第１の方法でリビルド処理が実行されることにより、ストレージシステム２０は、マルウェアに感染したホストによって破壊されたデータを、感染前に取得したスナップショットとの変更差分を利用して削除する（正常な過去のデータに戻して復元する）とともに、正常なホストから書き込まれた有効なデータについては、最新のデータのままで復元する。言い換えれば、ストレージシステム２０は、マルウェアに感染したホストから更新された可能性があるデータだけを選択的に削除する態様で感染前のデータを復元し、感染時刻より後に正常なホストから更新されたデータは最新状態のままで復元することができる。このようなストレージシステム２０によれば、データの破壊が開始されたタイミングを判断して、有効なデータの消失を防ぐことができ、データ復旧に要する作業時間を短縮することができる。
なお、図１６に示したリビルド処理の変形例として、ステップＳ３０６においてセカンダリボリュームに異常が認められなかった場合に、プロセッサ２３が、ステップＳ３０２で指定された時刻よりも新しい日時に繰り上げた無効開始時刻を再指定してステップＳ３０３～Ｓ３０６の処理を繰り返し、セカンダリボリュームの復元データに異常がないかを改めて管理者に確認させるようにしてもよい。上記のように、指定ホストからのデータ更新を無効にするタイミング（無効開始時刻）を更新しながらマルウェアの感染による異常のないデータ復元を試みることにより、マルウェアの感染の影響が生じる最も直前のデータを復旧することができるため、巻き戻されるデータの差分を可及的に小さくすることができる。なお、上記の処理を行うとき、セカンダリボリュームのデータに異常があった場合には、ステップＳ３０７において、その直前に異常がないと確認されたときのセカンダリボリュームの論物マッピングを用いて、プライマリボリュームへのコピーを行えばよい。
図１１は、本実施形態におけるストレージシステム２０によるデータの復元イメージの一例（その３）を説明するための図である。図１１には、ストレージシステム２０が複数のホストノード（ホスト計算機）３０に接続する構成例が示されており、各ホストノード３０からボリュームへのアクセス先は特に規定されていない構成となっている。
詳しく説明すると、図１１の各ホストノード３０は、ＯＳ（Operation System）４２及びアプリケーション（ＡＰＰ）４３の機能により、ネットワーク３１を介してストレージシステム２０のボリューム（Ｐ－ＶＯＬ１０００）にアクセスすることができる。
以下、図１１に示すストレージシステム２０の接続例におけるデータの復元イメージについて説明する。なお、図１の説明と類似する部分については、詳細な説明を省略する。なお、データＸ，Ｙは、マルウェアに感染したホスト（ホストノード３０－１，３０－２）から更新された不正なデータであり、暗号化されている場合もある。
図１１において、Ｐ－ＶＯＬ１０００は、当初、データＡ，Ｂ，Ｃを格納しており、スナップショットＰが取得される。次に、ホストノード３０－１がマルウェアに感染し、ホストノード３０－１によってＰ－ＶＯＬ１０００のデータＢがデータＸに更新された後、スナップショットＱが取得されたとする。この時点で、Ｐ－ＶＯＬ１０００は、データＡ，Ｘ，Ｃを格納する。次に、ホストノード３０－２もマルウェアに感染し、ホストノード３０－２によってＰ－ＶＯＬ１０００のデータＡがデータＹに更新されたとする。また、ホストノード３０－３はマルウェアに感染することなく、正常な状態で、Ｐ－ＶＯＬ１０００のデータＣをデータＦに更新したとする。したがって、最終的には、Ｐ－ＶＯＬ１０００は、データＹ，Ｘ，Ｆを格納する。
上記の最終的な状況において、ホストノードのマルウェアへの感染が検知されたとすると、ストレージシステム２０は、ボリューム内のデータを正常化するために、マルウェアに感染したホストノード３０－１，３０－２から更新されたデータＹ，Ｘを選択的に削除する態様で、Ｐ－ＶＯＬ１０００のデータを復旧する。
このようなデータ復旧を行う際のリビルド処理について、図１０の流れに沿って確認すると、まず、ステップＳ３０１において、管理者が更新を無効にするホストとしてホストノード３０－１，３０－２を指定する。次のステップＳ３０２において、管理者は、指定ホストによるデータ更新の無効開始時刻を指定する。本例では、例えば、比較的新しいスナップショットＱの取得時刻より少し前の時刻が指定されたとする。なお、第１の方法の変形例として後述するように、ステップＳ３０２では、指定ホストであるホストノード３０－１とホストノード３０－２とで別々の無効開始時刻を指定してもよいが、本例では同一の無効開始時刻を指定したとする。
次のステップＳ３０３では、プロセッサ２３が、データ復旧の起点とするスナップショットを選択する。具体的には、無効開始時刻以前の直近に取得されたスナップショットＱが選択される。
次のステップＳ３０４では、プロセッサ２３が、ステップＳ３０１，Ｓ３０２の指定に基づいて第１種別のデータと第２種別のデータとを判別し、さらにステップＳ３０３で選択したスナップショットを用いて、第１種別のデータに対する復元データの物理アドレスを特定する。詳しくは、プロセッサ２３は、更新履歴管理テーブル２４０を参照し、ホストノード３０－１または３０－２のデータ登録ホスト２４２をキーとして、無効開始時刻から現在までの期間に含まれる更新履歴を検索することにより、ホストノード３０－２から更新されたデータＹを、第１種別のデータと判別する。ホストノード３０－１によるデータＢからデータＸへの更新は、無効開始時刻よりも後に実行されているため、この時点ではデータＸは第１種別のデータとは判別されない。したがって、データＸ，データＦが第２種別のデータと判別される。そして、プロセッサ２３は、第１種別と判別したデータＹについて、更新履歴管理テーブル２４０において、更新履歴取得期間２４１がスナップショットＱの取得時刻から無効開始時刻までの更新履歴を検索し、データＹの無効開始時刻に最も近い更新履歴のレコードにおける更新後物理アドレス２４６を復元データの物理アドレスとして特定する。この場合、具体的には、ホストノード３０－２によって更新されたデータＹについては更新前のデータＡが復元データとされ、その物理アドレスが特定される。
次のステップＳ３０５では、プロセッサ２３は、ステップＳ３０４の特定結果等を踏まえて、セカンダリボリューム（Ｓ－ＶＯＬ１１００）の論物マッピングを生成する。詳細な処理は省略するが、ステップＳ３０５の結果、Ｓ－ＶＯＬ１１００は、データＡ，Ｘ，Ｆの構成でデータが復元される。
次のステップＳ３０６では、ステップＳ３０４でデータ復元されたＳ－ＶＯＬ１１００の異常確認が管理者に求められるが、データＸを含んでいることから、異常があると判断され、ステップＳ３０２に戻る。そして、ステップＳ３０２では、先のステップＳ３０２で指定された日時よりも古い、スナップショットＰの取得時刻よりも少し前に繰り下げた日時が、無効開始時刻に再指定される。
以降は、前述した処理が繰り返される。具体的には、ステップＳ３０３の処理によって、スナップショットＰがデータ復旧の起点として選択される。そしてステップＳ３０４の処理によって、ホストノード３０－１によって更新されたデータＸが第１種別のデータとして新たに判別され、データＸの復元データとして更新前のデータＢが探索され、その物理アドレスが特定される。さらに、ステップＳ３０５の処理によって、Ｓ－ＶＯＬ１１００は、データＡ，Ｂ，Ｆの構成でデータが復元される。
そして、ステップＳ３０６では、改めてステップＳ３０５でデータ復元されたＳ－ＶＯＬ１１００の異常確認が管理者に求められる。このとき、マルウェアに感染したホストノード３０－１，３０－２から更新されたデータＸ，Ｙがともに削除されていることから、Ｓ－ＶＯＬ１１００には異常が認められず、ステップＳ３０７においてＳ－ＶＯＬ１１００の論物マッピングをＰ－ＶＯＬ１０００にコピーすることにより、マルウェアに感染したホストによって破壊されたデータを選択的に削除する態様で、Ｐ－ＶＯＬ１０００のデータ復旧が実現される。
以上に説明したように、本実施形態に係るストレージシステム２０は、図１や図１１のように、ホスト単位でアクセス先が規定されていない場合、及び図７のように、ホスト単位でアクセス先が規定されている場合の何れの構成であっても、更新を無効にするホスト及びその無効開始時刻（日時）を指定してボリュームデータの復旧（リビルド）が指示されたとき、ボリュームの全論理アドレスの特定時刻におけるデータ（現データであるＰ－ＶＯＬ１０００のデータやバックアップ領域２０３に管理されるスナップショット）から、更新履歴管理テーブル２４０等に基づいて、書き込みホストごとに復元データを特定し（特に、指定されたホストによってデータ更新されたことがあるデータは、無効開始時刻以前の直近のデータを復元データとし）、これらの復元データによってボリュームのデータを復旧する。このようなストレージシステム２０によれば、マルウェアに感染したホスト（更新の無効が指示されたホスト）から更新された可能性があるデータを選択的に感染前のデータに復元することができるため、ボリューム全体では、感染時刻より後に正常なホストから更新されたデータを削除することなく復元することができ。その結果、有効なデータの消失を防ぐことができ、データ復旧に要する作業時間を短縮することができる。
なお、図１０及び図１１を参照しながら説明した第１の方法によるリビルド処理の変形例として、ステップＳ３０１において、データ更新を無効にする複数のホストを指定可能としてもよく、さらに、ステップＳ３０２において、それぞれの指定ホストに対して異なる無効開始時刻を指定可能としてもよい。指定ホストごとに異なる無効開始時刻が指定される場合、指定ホストごとに第１種別のデータが判別され、それぞれの第１種別のデータが、指定ホストに対応する無効開始時刻以前の直近のデータを復元データとして復元される。また、指定ホストごとに異なる無効開始時刻が指定される場合、データ復旧の起点とするスナップショットは、指定ホストごとに指定された無効開始時刻に基づいて都度スナップショットを選択してもよいし、複数の無効開始時刻のうちで最も古い無効開始時刻に基づいて共通する１つのスナップショットを選択してもよい。このような変形例によれば、指定されたホストごとに、それぞれ指定された無効開始時刻より後のデータ更新を無効化して、データ更新前のデータを復旧することができる。
また、本実施形態におけるリビルド処理の第２の方法は、データ更新を無効にするホストとその無効開始の時刻（日時）とが指定されたときに、指定日時より後に指定ホストから更新されたデータを、（スナップショットを起点とせずに）更新履歴管理テーブル２４０を用いて更新前の状態に復元する方法である。
第２の方法によるリビルド処理の処理手順を、図１６との相違点を示して説明する。まず、スナップショットをデータ復旧の起点としないことから、ステップＳ３０３の処理は不要となる。次に、ステップＳ３０４で、プロセッサ２３が、現ボリュームのすべてのデータについて、更新前データによる復元が必要な第１種別のデータと、更新前データによる復元が不要な第２種別のデータとを判別し、第１種別のデータに対する復元データ（更新前データ）の物理アドレスを特定する。但し、第２の方法が第１の方法と違う点として、プロセッサ２３は、ステップＳ３０４で第１種別のデータに対する復元データを特定するときに、最新状態である現データをデータ復旧の起点として、更新履歴管理テーブル２４０を遡って検索することにより、無効開始時刻の直前まで巻き戻す形で、復元データの物理アドレスを特定する。より具体的には、第２の方法においてプロセッサ２３は、第１種別のデータに含まれる各データについて、更新履歴管理テーブル２４０を参照しながら、データ復旧の起点（ここでは最新状態）から更新履歴を遡り、無効開始時刻より後の最初のデータ更新における更新前データを復元データとし、その物理アドレスを特定する。そして、ステップＳ３０５以降の処理は、スナップショットを用いる処理以外は第１の方法と同様に実行することにより、第１種別のデータを、無効開始時刻の直前の更新前データで復元することができる。また、第２種別のデータは、第１の方法と同様に、最新状態の現データで復元される。
このような第２の方法によれば、スナップショットを用いることなく、第１の方法と同様にマルウェアに感染したホストから書き込まれたデータを更新前データに復旧することができるため、第１種別の復元データを特定するために要する処理時間は第１の方法よりも長くなるものの、第１の方法よりも簡素なプログラムで実現できるという利点がある。
また、第２の方法によるリビルド処理の変形例として、指定時刻（無効開始時刻）以降のスナップショットを選択し、このスナップショットをデータ復旧の起点として更新履歴管理テーブル２４０を遡ることによって、第１種別のデータの復元データ及びその物理アドレスを特定し、復元するようにしてもよい。第２種別のデータについては、前述した各方法またはその変形例と同様に、最新状態の現データを復元する。このような変形例によれば、スナップショットとの変更差分を利用してデータ復旧を行うため、第１の方法と同様に、探索に要する時間や負荷を軽減することができる。
また、上述した各方法によるリビルド処理では、指定日時（無効開始時刻）以降に指定ホストによるデータ更新が行われていない第２種別のデータを最新状態の現データで復旧するとしたが、第２種別のデータを所定のスナップショットのデータ構成で復元する処理を組み合わせることもできる。この場合、具体的には例えば、リビルド処理の開始時に、データ更新を無効にするホスト（マルウェアに感染したホスト）及びデータ更新の無効開始時刻（マルウェアの感染前と推定されるタイミング）の指定に加えて、データ更新を無効にしないデータ（第２種別のデータ）に対するデータ復旧の目標日時を示すデータ復旧日時が指定される。実際の運用を考慮すると、データ復旧日時として指定される目標日時は、データ更新を無効にする指定日時（無効開始時刻）よりも後の日時であることが好ましい。このときプロセッサ２３は、第２種別のデータに対しては、データ復旧日時で指定された日時以前の直近に取得されたスナップショットを特定し、当該スナップショットのデータ構成に従ってデータを復元する。また、プロセッサ２３は、第１種別のデータに対しては、上述した各方法に従ってデータを復元する。派生例として、第１種別のデータに対するデータ復旧の起点としてスナップショットを利用する方法の場合に、第２種別のデータに対するデータ復旧の起点とするスナップショットを流用するようにしてもよい。なお、上記のデータ復旧日時の指定に代えて、所望のスナップショットの取得日時が直接指定されてもよい。以上のようなリビルド処理によれば、ボリュームデータのうち、マルウェアに感染したホストからの書き込みが行われていない第２種別のデータをユーザ所望のタイミングに近いスナップショット（あるいはユーザ所望のスナップショット）のデータ構成で復旧するとともに、マルウェアに感染したホストからの書き込みが行われた第１種別のデータを感染前のデータで復元することができるため、データ復旧に関するユーザの多様な要求に応えることができる。
また、以上のリビルド処理は、データの書き込み方式に追い書き方式を採用した場合で説明したが、前述した更新差分を退避する方式等を採用した場合でも、更新前の物理データはすぐに消えずに残っていることから、追い書き方式の場合と同様に、リビルド処理においてデータ復元に利用することができる。
本実施形態に係るストレージシステム２０は、ホスト単位（ホスト計算機、仮想マシン、ホストノード、コンテナ等）またはアプリケーションの管理単位（ボリューム、永続ボリューム、仮想ディスクイメージ等）で、登録されるデータが分類される仕組みを有するストレージシステム全般に適用することができる。
なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。具体的には例えば、図１０に示したリビルド処理では、Ｐ－ＶＯＬ１０００のデータを復旧する際に、一旦、Ｓ－ＶＯＬ１１００にデータを復元し、異常がないことをユーザに確認させてからＰ－ＶＯＬ１０００に復元したデータ構成をコピーするようにしたが、変形例として、Ｓ－ＶＯＬ１１００におけるデータ復元を行わずに、Ｐ－ＶＯＬ１０００において直接、データを復元するようにしてもよい。前者の場合は、通常使用しているボリュームとは別のボリュームで復元したデータを確認させることによって、安全なデータ復旧が期待できるのに対し、後者の場合は、安全性は劣るものの、データ復旧に要する時間や手間を削減する効果に期待できる。
また、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、図面において制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
１０ データ
２０ ストレージシステム
２１ ストレージコントローラ
２２ ＦＥ Ｉ／Ｆ
２３ プロセッサ
２４ メモリ
２５ バス
２６ ＢＥ Ｉ／Ｆ
２７ ストレージＩ／Ｆ
２８ ドライブ
３０ ホスト計算機（ホストノード）
３１ ネットワーク
４０ ハイパーバイザ
４１ 仮想マシン（ＶＭ）
４２ ＯＳ
４３ アプリケーション
２０１ プログラム領域
２０２ キャッシュ領域
２０３ バックアップ領域
２０４ テーブル管理領域
２０５ 仮想ディスクイメージ
２１０ ボリューム情報管理テーブル
２２０ 論物マッピングテーブル
２３０ スナップショット管理テーブル
２４０ 更新履歴管理テーブル
１０００ Ｐ－ＶＯＬ
１１００ Ｓ－ＶＯＬ

Claims (13)

  1. 記憶装置とストレージコントローラとを有し、前記ストレージコントローラによって前記記憶装置の記憶領域を仮想化したボリュームを複数のホストに提供するストレージシステムにおいて、
    前記ストレージコントローラは、
    前記ホストによる前記ボリュームのデータ更新の履歴を、当該ホストを識別可能な情報を添えて更新履歴情報に記録し、
    前記データ更新を無効にするホスト及び日時の指定を含む前記ボリュームのデータの復旧が要求されたとき、
    前記更新履歴情報に基づいて、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストとは異なるホストによって更新されたデータ更新を有効にしたままで、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストによって更新されたデータ更新を無効にして前記ボリュームを復元する
    ことを特徴とするストレージシステム。
  2. 前記ストレージコントローラは、
    前記ボリュームの最新状態の各データに割り当てられた論理アドレスと当該各データの前記記憶装置における格納先を示す物理アドレスとの対応関係を、各データを登録した前記ホストを識別可能な情報を添えて論物マッピング情報に記録し、
    前記ボリュームのデータ更新時には、更新前データとは異なる前記記憶領域の物理アドレスに更新後データを格納して前記論物マッピング情報を更新し、少なくともアクセス元ホストが変更となるデータ更新について、アクセス元ホストの変更と、更新前データ及び更新後データそれぞれの論理アドレスと物理アドレスとの組み合わせとを追跡可能な形態で、前記更新履歴情報に履歴を記録し、
    前記ボリュームのデータの復旧が要求されたとき、
    前記ボリュームのデータから、前記更新履歴情報に基づいて、前記指定された日時より後に前記指定されたホストによって更新された第１種別のデータを特定し、
    前記第１種別のデータに含まれる各データの論理アドレスについて、前記更新履歴情報に基づいて、前記指定された日時以前に実行されたデータ更新による更新後データにかかる物理アドレスを特定し、
    前記特定した更新後データにかかる物理アドレスを前記論理アドレスに対応付けて前記第１種別のデータを復元する
    ことを特徴とする請求項１に記載のストレージシステム。
  3. 前記ストレージコントローラは、
    前記ボリュームのデータの復旧が要求されたとき、
    前記ボリュームのデータから、前記更新履歴情報に基づいて、前記第１種別のデータを特定するとともに、前記指定された日時より後に前記指定されたホストによって更新されていない第２種別のデータを特定し、
    前記第２種別のデータを、前記更新履歴情報または前記論物マッピング情報に基づいて最新状態で復元する
    ことを特徴とする請求項２に記載のストレージシステム。
  4. 前記ストレージコントローラは、
    前記ボリュームのスナップショットを所定のタイミングで繰り返し取得し、
    前記ボリュームのデータの復旧が要求されたとき、
    前記指定された日時よりも前に取得されたスナップショットを前記第１種別のデータの復元データの起点として選択し、前記起点から前記指定された日時までの前記第１種別のデータの物理アドレスの更新差分を前記更新履歴情報を用いて特定することにより、前記第１種別のデータの復元データを前記記憶装置に格納されたデータから特定する
    ことを特徴とする請求項２に記載のストレージシステム。
  5. 前記ボリュームのデータの復旧の要求において、前記データ更新を無効にするホストが複数あり、その指定日時が異なって指定されたとき、
    前記ストレージコントローラは、
    前記指定されたホストごとに、対応する前記指定された日時を基準として前記第１種別のデータを特定し、当該日時以前に実行されたデータ更新による更新後データで当該第１種別のデータを復元する
    ことを特徴とする請求項２に記載のストレージシステム。
  6. 前記ボリュームのデータの復旧が要求されたとき、前記ストレージコントローラは、
    前記論物マッピング情報に示される最新状態のデータを前記第１種別のデータの復元データの起点として選択し、前記起点から前記指定された日時までの前記第１種別のデータの物理アドレスの更新差分を前記更新履歴情報を用いて特定することにより、前記第１種別のデータの復元データを前記記憶装置に格納されたデータから特定する
    ことを特徴とする請求項２に記載のストレージシステム。
  7. 前記ストレージコントローラは、
    前記ボリュームのスナップショットを所定のタイミングで繰り返し取得し、
    前記ボリュームのデータの復旧が要求されたとき、
    前記指定された日時よりも後に取得されたスナップショットを前記第１種別のデータの復元データの起点として選択し、前記起点から前記指定された日時までの前記第１種別のデータの物理アドレスの更新差分を前記更新履歴情報を用いて特定することにより、前記第１種別のデータの復元データを前記記憶装置に格納されたデータから特定する
    ことを特徴とする請求項２に記載のストレージシステム。
  8. 前記ストレージコントローラは、
    前記ボリュームのスナップショットを所定のタイミングで繰り返し取得し、
    前記ボリュームのデータの復旧の要求において、前記データ更新を無効にするホスト及び日時の指定とは別に、前記データ更新を無効にしないデータに対するデータ復旧の目標日時が指定された場合、
    前記ボリュームのデータから、前記更新履歴情報に基づいて、前記第１種別のデータを特定するとともに、前記指定された日時より後に前記指定されたホストによって更新されていない第２種別のデータを特定し、
    前記第２種別のデータを、前記目標日時以前に取得されたスナップショットを用いて復元する
    ことを特徴とする請求項２に記載のストレージシステム。
  9. 第１のボリュームに対する前記データの復旧が要求されたとき、前記ストレージコントローラは、
    前記第１のボリュームとは別のバックアップ用の第２のボリュームに、前記データを復元し、復元後の前記第２のボリュームの確認をユーザに要求し、
    前記第２のボリュームに復元されたデータがユーザから確認された場合に、当該第２のボリュームのデータ構成を前記第１のボリュームにコピーすることによって、前記第１のボリュームのデータを復旧する
    ことを特徴とする請求項２に記載のストレージシステム。
  10. 前記ストレージコントローラは、
    前記第２のボリュームに復元されたデータが異常であるとユーザから確認された場合、前記指定された日時を当該日時よりも前の日時に変更して前記第２のボリュームに前記データを復元する処理を、当該第２のボリュームに復元されたデータが正常であるとユーザから確認されるまで繰り返し、当該繰り返しの終了時の前記第２のボリュームのデータ構成を前記第１のボリュームにコピーすることによって、前記第１のボリュームのデータを復旧する
    ことを特徴とする請求項９に記載のストレージシステム。
  11. 前記ストレージコントローラは、
    前記第２のボリュームに復元されたデータが正常であるとユーザから確認された場合、前記指定された日時を当該日時よりも後の日時に変更して前記第２のボリュームに前記データを復元する処理を、当該第２のボリュームに復元されたデータが異常であるとユーザから確認されるまで繰り返し、当該繰り返しの終了時の直前に正常であると確認されたときの前記第２のボリュームのデータ構成を前記第１のボリュームにコピーすることによって、前記第１のボリュームのデータを復旧する
    ことを特徴とする請求項９に記載のストレージシステム。
  12. 前記ボリュームのデータ管理領域が、複数の独立した仮想ディスクイメージに分割され、それぞれの前記仮想ディスクイメージにアクセス可能な前記ホストが予め登録されるとき、
    前記ストレージコントローラは、
    前記ホストによる前記仮想ディスクイメージへのデータ更新の履歴を、当該ホストを識別可能な情報を添えて更新履歴情報に記録し、
    前記データ更新を無効にするホスト及び日時の指定を含む前記ボリュームのデータの復旧が要求されたとき、
    前記更新履歴情報に基づいて、前記指定されたホストとは異なるホストからアクセスされる前記仮想ディスクイメージにおいてデータ更新を有効にしたままで、前記指定されたホストからアクセスされる前記仮想ディスクイメージにおいて前記指定された日時より後に前記指定されたホストによって更新されたデータ更新を無効にして当該仮想ディスクイメージのデータを復元する
    ことを特徴とする請求項１に記載のストレージシステム。
  13. 記憶装置とストレージコントローラとを有し、前記ストレージコントローラによって前記記憶装置の記憶領域を仮想化したボリュームを複数のホストに提供するストレージシステムによるデータ復旧方法であって、
    前記ストレージコントローラが、前記ホストによる前記ボリュームのデータ更新の履歴を、当該ホストを識別可能な情報を添えて更新履歴情報に記録する更新履歴記録ステップと、
    前記データ更新を無効にするホスト及び日時の指定を含む前記ボリュームのデータの復旧が要求されたとき、前記ストレージコントローラが、前記更新履歴情報に基づいて、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストとは異なるホストによって更新されたデータ更新を有効にしたままで、前記ボリュームにおいて前記指定された日時より後に前記指定されたホストによって更新されたデータ更新を無効にして前記ボリュームを復元するデータ復元ステップと、
    を備えることを特徴とするデータ復旧方法。
JP2021160452A 2021-09-30 2021-09-30 ストレージシステム及びデータ復旧方法 Pending JP2023050384A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021160452A JP2023050384A (ja) 2021-09-30 2021-09-30 ストレージシステム及びデータ復旧方法
US17/691,253 US20230113507A1 (en) 2021-09-30 2022-03-10 Storage system and data restoration method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2021160452A JP2023050384A (ja) 2021-09-30 2021-09-30 ストレージシステム及びデータ復旧方法

Publications (1)

Publication Number Publication Date
JP2023050384A true JP2023050384A (ja) 2023-04-11

Family

ID=85798067

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021160452A Pending JP2023050384A (ja) 2021-09-30 2021-09-30 ストレージシステム及びデータ復旧方法

Country Status (2)

Country Link
US (1) US20230113507A1 (ja)
JP (1) JP2023050384A (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11960606B2 (en) * 2022-03-24 2024-04-16 Check Point Software Technologies Ltd. System and method for protecting against data storage attacks

Also Published As

Publication number Publication date
US20230113507A1 (en) 2023-04-13

Similar Documents

Publication Publication Date Title
US20210157523A1 (en) Storage system
JP3878412B2 (ja) データを保存し使用し及び回復する方法
US7895394B2 (en) Storage system
JP2703479B2 (ja) タイム・ゼロ・バックアップ・セッションの安全保護機能を有するデータ処理方法及びシステム
US8386434B2 (en) Optimizing defragmentation operations in a differential snapshotter
US9396198B2 (en) Computer system, file management method and metadata server
US8732121B1 (en) Method and system for backup to a hidden backup storage
KR101085767B1 (ko) 데이터베이스 뷰 제공 방법 및 컴퓨터 판독가능 기록 매체
US6564307B1 (en) Method, system, and program for logically erasing data
US7673096B2 (en) Control apparatus for controlling virtual storage
US20090216973A1 (en) Computer system, storage subsystem, and data management method
JP2007226347A (ja) 計算機システム、計算機システムの管理装置、及びデータのリカバリー管理方法
WO2023206968A1 (zh) 一种数据存储方法、系统及计算机可读存储介质
KR20090091746A (ko) 라이트백 캐시 유닛을 사용하여 데이터를 관리하는 시스템, 방법 및 컴퓨터 프로그램 제품
KR100819022B1 (ko) 하나의 타겟 볼륨과 하나의 소스 볼륨 사이의 관계 관리
US20100005255A1 (en) Method for providing atomicity for host write input/outputs (I/Os) in a continuous data protection (CDP)-enabled volume using intent log
EP3385846B1 (en) Method and device for processing access request, and computer system
US11409451B2 (en) Systems, methods, and storage media for using the otherwise-unutilized storage space on a storage device
US20070143591A1 (en) Method for non-destructive restoration of a corrupted operating system
JP2008204460A (ja) ディスク・パーティションのほぼ瞬時のバックアップおよび復元
US7152147B2 (en) Storage control system and storage control method
JP2023050384A (ja) ストレージシステム及びデータ復旧方法
US11755223B2 (en) Systems for modular hybrid storage devices
US8880820B2 (en) Techniques for using sparse files during snapshots
US20140059291A1 (en) Method for protecting storage device data integrity in an external operating environment