JP4128641B2 - データ退避方法 - Google Patents
データ退避方法 Download PDFInfo
- Publication number
- JP4128641B2 JP4128641B2 JP27915797A JP27915797A JP4128641B2 JP 4128641 B2 JP4128641 B2 JP 4128641B2 JP 27915797 A JP27915797 A JP 27915797A JP 27915797 A JP27915797 A JP 27915797A JP 4128641 B2 JP4128641 B2 JP 4128641B2
- Authority
- JP
- Japan
- Prior art keywords
- snapshot
- stripe
- information
- time stamp
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/128—Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Description
【０００１】
【発明の属する技術分野】
この発明は、たとえばディスク装置などに格納されたファイルの更新前データを後方回復のために退避するコンピュータシステムのデータ退避方法に係り、特に既存のオペレーティングシステム、ファイルシステムおよびアプリケーションプログラムなどの改造を伴なわずにファイルの内容を所定の時点に復元するためのスナップショットを効率的に採取するコンピュータシステムのデータ退避方法に関する。
【０００２】
【従来の技術】
従来より、ディスク単体の障害に対しては、冗長化ディスク構成を採用することによって対処が可能であるが、この冗長化技術は、ソフトウェアバグ、誤操作およびウイルス感染などによるプログラムまたはデータの喪失・改変、もしくはディスク記憶装置そのものを失なうような大規模な障害には役立たない。これらの問題に対処するためには、スナップショットやバックアップなどの採取が必須となる。
【０００３】
スナップショットとは、ある時点のファイルやディスクなどのコピーイメージのことであり、定期的にファイルやディスク全体を同じディスク記憶装置や別のディスク記憶装置にコピーして、スナップショットを作成する。そして、プログラムまたはデータが喪失・改変された場合には、直前に作成されたスナップショット（コピーイメージ）にプログラムまたはデータ、もしくはディスク全体を戻すことによりこれらの障害に対処する。
【０００４】
また、バックアップとは、このスナップショットを別の大容量記憶媒体（磁気テープなど）に保存して保管したものである。これにより、ディスク記憶装置そのものを失った場合（中のデータも全部喪失）であっても、新しいディスク記憶装置にこのバックアップをロードすることによって、スナップショッ卜採取時のプログラムまたはデータを復元することができる。
【０００５】
通常、スナップショットやバックアップの採取時には、それらのファイルを変更する可能性があるアプリケーションをすべて停止する必要がある。そうしないと、コピー作成中にファイルやデータが変更されてしまい、正しいスナップショットやバックアップが採取できないからである。すなわち、不正なスナップショットやバックアップをディスク記憶装置に戻しても、アプリケーションプログラム側でエラーや誤動作を発生させる危険性があるため、先の障害対策として意味をなさない。
【０００６】
なお、一般に大容量記憶媒体よりもディスク記憶装置への書き込みの方が高速であるので、ファイルやディスクイメージを直接バックアップするよりも、スナップショットを作成し、それを大容量記憶媒体にバックアップする方がアプリケーションの停止期間を短く押さえられる。また、プログラムまたはデータの喪失・改変からの復元もスナップショットの方が短期に行なえる。バックアップが磁気テープなどのシーケンシャルアクセスの媒体の場合、特定のファイルを見つけて読み出すには多くの時間を要してしまい非常に効率が悪い。
【０００７】
また、このスナップショットやバックアップを採取するためにアプリケーションを長時間停止しなければならないといった問題を解決する、スナップショット機能を持ったファイルシステムも開示されている（文献１：「Ｔｈｅ Ｅｐｉｓｏｄｅ Ｆｉｌｅ Ｓｙｓｔｅｍ」，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｗｉｎｔｅｒ １９９２ ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ．４３−６０，Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ、文献２：「Ｆｉｌｅ ＳｙｓｔｅｍＤｅｓｉｇｎ ｆｏｒ ａｎ ＮＦＳ Ｆｉｌｅ Ｓｅｒｖｅｒ Ａｐｐｌｉａｎｃｅ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｗｉｎｔｅｒ １９９４ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ．２３５−２４４，Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ）。
【０００８】
ところで、これらのファイルシステム（たとえば文献２）では、図３２（ａ）に示すように、ファイルがルート・Ｉノードを起点とするブロック木構造であることを前提にしている。そして、スナップショット作成時には、このルート・Ｉノードのコピーを作成する。このコピーしたＩノード（スナップショット・Ｉノード）は、スナップショットとしてのブロック木構造を表現することになる。また、コピー元のルート・Ｉノードは、読み出し／書き込みが行なわれるアクティブなファイルシステムのブロック木構造を表現する。スナップショット・Ｉノードは、生成されたときにはルート・Ｉノードとまったく同じブロックを指しているので（図３２（ｂ））、新しいスナップショットのためにコピーしたＩノード以外はまったくディスクスペースを消費しない。
【０００９】
ここで、ユーザがデータブロックＤを変更したとすると、図３２（ｃ）に示すように、新しいデータブロックＤ’をディスク上に書き込み、ルート・Ｉノードで表現するアクティブなファイルシステムが、この新しいブロックを指すように変更される。ディスク上の元のデータブロックＤは変更されずに残っており、スナップショット・Ｉノードは、元のデータブロックＤをまだ指している。したがって、スナップショット・Ｉノードを指定することにより、スナップショット作成時のデータブロックＡ、Ｂ、Ｃ、Ｄ、Ｅをそのまま参照できる。
【００１０】
このように、スナップショット機能を持ったファイルシステムを使えば、ルート・Ｉノードをコピーするだけで簡単にスナップショットを作成でき、アプリケーションプログラムを停止することなくスナップショットが作成できる。また、スナップショットをアプリケーションプログラムの実行と並行して大容量記億媒体に保存できるので、バックアップの採取もアプリケーションを停止することなく行なえる。したがって、スナップショットやバックアップのデータ退避のためにアプリケーションプログラムを停止する必要が無くなる。
【００１１】
【発明が解決しようとする課題】
しかしながら、前述した手法においては、専用のファイルシステムを新しく開発する必要があり、既存のコンピュータシステムにそのまま適用できるものではなかった。また、ファイルシステム自身もブロック木構造で構成されていることを前提にしており、たとえばマイクロソフト社のＮＴＦＳなどのエクステントベースのファイルシステムには適用できる技術ではなかった。さらに、一般にファイルシステムは大きな木構造をしており、実際に前述のデータブロックＤをＤ’に更新するには、図３３に示すように、その経路に位置する中間ノードすべてをコピーする必要があり、スナップショット作成後の更新性能が大きく低下するといった問題もあった。さらに、ファイルシステムという複雑なソフトウェアモジュールにスナップショット機能を付加したため、スナップショットは読み出しだけで非常に硬直なものになってしまっていた。
【００１２】
この発明はこのような実情に鑑みてなされたものであり、既存のコンピュータシステムやファイルシステムにそのまま適用することができ、かつ更新時のオーバヘッドもなく、スナップショットの更新なども可能な非常に柔軟なデータ退避を可能とするコンピュータシステムのデータ退避方法を提供することを目的とする。
【００１４】
【課題を解決するための手段】
前述した目的を達成するために、この発明は、不揮発性記憶装置に格納されたファイル群に対するアプリケーションプログラムからの更新を含むアクセスを管理するファイルシステムとＫ個の論理ブロックに相当する容量を有する書き込みバッファとを備えたコンピュータシステムに適用されるデータ退避方法において、前記書き込みバッファに更新すべきデータの論理ブロックを蓄積し、その蓄積した論理ブロックがＫ−１個に達したら、前記書き込みバッファに蓄積された各論理ブロックに対する論理アドレスから構成され、タイムスタンプを付加した論理アドレスタグブロックを生成し、Ｋ−１個のブロックに前記論理アドレスタグブロックを加えたＫ個の論理ブロックを一つのストライプとして前記不揮発性記憶装置上の更新されるべきデータを保持する領域とは別の空き領域に連続して書き込みを行う書き込み処理であって、前記書き込み処理中に、前記ファイル群の内容を所定の時点に復元するためのスナップショットを採取するスナップショット採取の指示があった場合に、前記Ｋ−１個の論理ブロックの中で、スナップショット採取時点で更新すべきデータの論理ブロックが埋まっていない論理ブロックに対する論理アドレスをヌルアドレスとしてストライプを作成し、当該ストライプの論理アドレスタグブロックに付加したタイムスタンプをスナップショット情報として前記空き領域内のストライプが書き込まれた領域とは別の領域に記録することを特徴とする。
【００１５】
すなわち、たとえばディスク装置などの不揮発性記憶装置と、この不揮発性記憶装置に格納されたファイル群に対するアプリケーションプログラムからの更新を含むアクセスを管理するファイルシステムとの間に、ファイル群の内容を所定の時点に復元するためのスナップショット情報を不揮発性記憶装置ごとに採取し、この採取したスナップショット情報をそれぞれの不揮発性記憶装置上に格納するスナップショット管理手段を設けるようにしたものである。
【００１６】
この発明によれば、既存のオペレーティングシステムやファイルシステム、あるいはアプリケーションプログラムになんらの改造を伴なうことなく、スナップショットを効率的に採取することが可能となる。
【００１７】
【発明の実施の形態】
以下、図面を参照してこの発明の実施形態について説明する。
【００１８】
（第１実施形態）
まず、この発明の第１実施形態について説明する。図１はこの実施形態に係るコンピュータシステムの構成を示す概念図である。このシステムは、スナップショットやバックアップが必要なアプリケーションプログラム１ａ〜１ｃ、これらのアプリケーションプログラム１ａ〜１ｃが使う既存のファイルシステム２、このファイルシステム２とディスク装置４との間に位置し、ディスクレベルのスナップショットを採取するディスク・スナップショット部３およびファイルシステム２のデータやディスク・スナップショット部３のデータを保持するディスク装置４から構成される。
【００１９】
これらアプリケーションプログラム１ａ〜１ｃ、ファイルシステム２およびディスク装置４は既存のコンピュータシステムと同じ任意の要素であり、従来のようにファイルシステム２がブロック木構造である必要はまったくない。また、ファイルシステム２は既存のものそのままであり、従来のようにスナップショット機能を持ったものである必要もない。すなわち、この発明の特徴となる構成要素はディスクスナップショット部３であるので、以下ではこのディスクスナップショット部３について説明する。
【００２０】
図２はこの実施形態のディスクスナップショット部３の構成を示す概念図である。図２に示すように、このディスクスナップショット部３は、ディスクスナップショット制御部５、揮発性メモリ６から構成される。この揮発性メモリ６内には、書き込みの時間的順序を維持するためのタイムスタンプ７、ディスク装置４に書き込むデータをログ構造化して保持する書き込みバッファ８、および書き込みバッファ８内の空き領域と保持されている書き込みデータの論理アドレスの情報とを保持するバッファ管理テーブル９が格納される。一方、ディスク装置４内には、通常のデータの他に、スナップショット情報（ＳＳ情報）１０が格納される。ディスクスナップショット制御部５は、これらタイムスタンプ７、書き込みバッファ８、バッファ管理テーブル９およびスナップショット情報１０を管理して、ディスク装置４への読み出し／書き込みおよびスナップショット情報の参照を制御する。
【００２１】
図３にこの揮発性メモリ６内の書き込みバッファ８とバッファ管理テーブル９との関係を示す。ディスクスナップショット制御部５は、ファイルシステム２からディスク装置４への書き込みを要求された書き込みデータを、すぐにディスク装置４に書き込むのではなく、ブロック単位に分割して書き込みバッファ８に順番に詰めて（ログ形式に）格納していく。このとき、その書き込みデータのファイルシステム２から見た論理アドレスを、バッファ管理テーブル９が格納したバッファ領域に対応するエントリに保存する。そして、そのエントリにデータが割り当てられたことを示すフラッグ“Ｆ”を立てる。よって、このバッファ管理テーブル９を調べることにより、ファイルシステム２から受け取った書き込みデータを格納すべき次のバッファ領域を決めることができる。図３では、バッファ領域Ｂ９まで書き込みデータが格納されており、Ｂ０、Ｂ１、〜、Ｂ９の論理アドレスが、ＬＡ１３４、ＬＡ９９、〜、ＬＡ６７８であることを表わしている。
【００２２】
また、ディスク装置４は、それぞれブロックサイズの整数倍（Ｋ）であるストライプと呼ぶ予め決められた単位（そのディスク装置の１トラック長に近いサイズが好ましい）で書き込みを行なう。また、実際のディスク装置４を合わせた全記憶容量よりも少ない容量のディスク装置としてファイルシステム２には見せている（ファイルシステムが最初に記憶容量を問い合わせて来たときに、実際よりも少ない容量を返す）。よって、ファイルシステム２から論理的に読み書きできる記憶領域の他に余分な記憶領域が確保されることになる。ここでは、この領域を空領域と呼ぶことにする（図４参照）。また、以下では、ファイルシステム２から見えるディスクスナップショット部３が提供する論理的なディスク領域を論理ディスク装置と呼ぶことにし、一方、ディスク装置４が実際に提供する物理的なディスク領域を物理ディスク装置と呼ぶことにする。
【００２３】
タイムスタンプ７は、ファイルシステム２からの書き込みデータが実際にディスク装置４に書き込まれるときに付加される情報であり、ディスク装置４内でのデータ書き込み順序を判定するのに用いられる。よって、書き込みバッファ８のデータがディスク装置４に書き込まれるごとにタイムスタンプ９がインクリメントされる。また、スナップショット情報１０は、スナップショット採取時点のタイムスタンプの値を保持する。
【００２４】
以下、この実施形態のコンピュータシステムにおける各処理の動作原理を詳細に説明する。
【００２５】
まず、この実施形態のコンピュータシステムにおける書き込み処理について説明する。アプリケーションプログラム１ａ〜１ｃがファイルシステム２上のファイルを書き込むと、ファイルシステム２は、対応する論理ディスク装置に対する書き込み要求に変換してディスクスナップショット部３に引き渡す。ディスクスナップショット制御部５は、ファイルシステム２から書き込むべきデータとその論理アドレスとを受け取り、揮発性メモリ６上の書き込みバッファ８の空領域にブロック単位に分割して詰めて格納する。また、受け取った論理ディスク装置のアドレス（以下論理アドレスと呼ぶ）は、ブロックごとのアドレスに変換してバッファ管理テーブル９の対応するエントリに格納する。なお、すでに書き込みバッファ８に絡納されているデータに対する更新データの場合には、書き込みバッファ８の空領域に詰めて格納するのではなく、直接書き込みバッファ８内の旧データを変更する。
【００２６】
そして、ディスクスナップショット制御部５は、ファイルシステム２から受け取った書き込みデータが１ストライプ分に１ブロック少ない数（Ｋ−１）だけ書き込みバッファ８に溜まった段階で、それらのデータをディスク装置４に書き込みにいく。このとき、ディスクスナップショット制御部５は、最後の書き込みブロックとして、書き込み管理テーブル７に格納された各ブロックの論理アドレスと揮発性メモリ６上のタイムスタンプとから論理アドレスタグブロックを作成する（この論理アドレスタグブロック内のアドレスデータとデータブロックとには１対１の関係が予め設定されており、各データブロックの論理アドレスが分かるようになっている）。その後、ディスクスナップショット制御部５は、この論理アドレスタグブロックを加えた１ストライプ分のデータをまとめてディスク装置４の空領域に同時に書き込む（図５参照）。また、タイムスタンプ５の値は、書き込みが完了した段階でインクリメントされる。
【００２７】
このように書かれたデータブロックの読み出し処理について説明する前に、まず無効ブロックの判定処理について説明する。
【００２８】
ここでは、図６に示す順番でファイルシステム２から１ブロックサイズのデータ書き込みがある場合を例に説明する。なお、図６中のＬｎはファイルシステム２から渡される論理アドレスを表し、Ｓｎは書き込み順番を表わす。また、この実施形態のコンピュータシステムでは、書き込みバッファ８は１５ブロック分のデータを保持できるものとする。この場合、最初のＳ１〜Ｓ１５の書き込みデータが１つのストライプ（ＳＴ１）にまとめられ、タイムスタンプＴＳ１が付加されてディスク装置４の空領域に書き出される。同様に、Ｓ１６〜Ｓ３０の書き込みデータが別のストライプ（ＳＴ２）にまとめられ、タイムスタンプＴＳ２が付加されて別の空領域に書き出される。なお、書き出しごとにタイムスタンプはインクリメントされるので、ＴＳ１とＴＳ２とはＴＳ１＜ＴＳ２の関係をもつ。
【００２９】
この図６から分かるように、論理アドレスＬ９、Ｌ１８のデータは、タイムスタンプＴＳ１のストライプではＳ５、Ｓ２のブロックとして、タイムスタンプＴＳ２のストライプではＳ１９、Ｓ２１のブロックとして重複して存在する。書き込まれた順番を考えると、Ｓ１９、Ｓ２１のデータブロックが有効であり、Ｓ５、Ｓ２のデータは無効と判定されなければならない。しかしながら、ここで便宜上使った書込み順番Ｓｎは、実際のディスク装置４上には記録されていない。
【００３０】
そこで、この実施形態のコンピュータシステムでは、ストライプ内の論理アドレスタグを使ってこの判定を行なう。図６の例における２つのストライプＳＴ１、ＳＴ２の論理アドレスタグＴＧ１、ＴＧ２の内容は図７に示す通りである。図７から分かるように、２つの論理アドレスタグＴＧ１、ＴＧ２に同じ論理アドレスＬ９、Ｌ１８のデータが含まれており、ストライプＳＴ１のブロックＢ５、Ｂ２と、ストライプＳＴ２のブロックＢ４、Ｂ６とのどちらかのデータが無効である。さらに、論理アドレスタグＴＧ１のタイムスタンプＴＳ１と論理アドレスタグＴＧ２のタイムスタンプＴＳ２を比較すると、ＴＳ１＜ＴＳ２であることからストライプＳＴ１のブロックＢ５、Ｂ２が無効であることが判定できる。以上のように、ディスク装置４内の論理アドレスタグを調べることにより、無効なデータブロックを見つけることができる。
【００３１】
次に、この実施形態のコンピュータシステムにおけるデータブロックの読み出し処理について説明する。原理的には、先に述べた無効ブロック判定の処理をディスク装置４内の全ストライプの論理アドレスタグに対して行ない、結果として残る読み出し要求のあった論理アドレスに対する有効ブロックの物理的位置を検出する。
【００３２】
しかしながら、読み出し要求がくる度にこの処理を行なっているのでは、ブロック読み出しに膨大な時間がかかってしまい実用的ではない。そこで、システム起動時にだけ全ストライプの論理アドレスタグの調査を行ない、揮発性メモリ６上に論理アドレスから物理アドレスへの変換マップを作る。ファイルシステム２からの読み出し要求に対しては、この変換マップを使って有効ブロックへのアクセスを行なう。これにより、常にアドレスタグの調査をしなくても良く、読み出し時に性能が大きく低下することはない。この変換マップについて図８を参照して説明する。図８に示すように、変換マップは各論理アドレスに対するブロックが格納されているストライプ番号ＳＴ＃、そのストライプ内のブロック番号ＢＬＫ＃、およびそのタイムスタンプＴＳ＃をテーブル形式で保持している。よって、論理アドレスが与えられれば、このテーブルを引くことにより、ＳＴ＃とＢＬＫ＃とから簡単に実際の物理アドレスが求まる。
【００３３】
また、システム起動時の変換マップの作成は、調査した論理アドレスタグの全論理アドレスについて、テーブルのタイムスタンプより論理アドレスタグのタイムスタンプが大きいときだけ、そのストライプ番号と対応するブロック番号をテーブルに登録する。この調査を全ストライプについて行なえば、有効ブロックだけを指す変換マップができあがる。さらに、ディスク装置４にストライプを書き込むごとに、その論理アドレスタグに対して同様の処理を行なうことにより、この変換マップは常に有効なブロックを指す。このようにして、ディスク装置４上の物理ブロックの有効／無効の判定を行ない変換マップが作られる。
【００３４】
次に、この実施形態のコンピュータシステムにおけるスナップショットの採取処理について説明する。アプリケーションプログラム１ａ〜１ｃやシステム管理者からのスナップショット採取の指示を受けると、ディスクスナップショット制御部５は書き込みバッファ８にその時点で溜まっているデータをディスク装置４に書き込みにいく。ただし、通常の書き込みのように、書き込みバッファ８内に１ストライプ分に１ブロック少ない数（Ｋ−１）のデータブロックが溜まっているとは限らないので、まだ埋まっていない部分に対応する書き込み管理テーブル７には無効であることを示すヌルアドレスを格納する。そして、通常の書き込みと同様に、最後の書き込みブロックとして、書き込み管理テーブル７に格納された各ブロックの論理アドレス（ヌルアドレスを含む）と揮発性メモリ６上のタイムスタンプとから論理アドレスタグブロックを作成する。その後、この論理アドレスタグブロックを加えた１ストライプ分のデータをまとめてディスク装置４の空領域に同時に書込む（図９参照）。さらに、このときに付加したタイムスタンプの値をスナップショット採取時の情報として、ディスク装置４内のスナップショット情報１０に書き込む。そして、タイムスタンプ７の値は、書き込みが完了した段階でインクリメントされる。このように、スナップショット採取には書き込みバッファ８に溜まっていたブロックとスナップショット情報１０とをディスクに書き込むだけの時間しかかからない（その他の処理は非常に短い）ので、従来と同様にアプリケーションプログラム１ａ〜１ｃを停止させることなくスナップショットが作成できる。
【００３５】
次に、図１０を参照してこの実施形態のコンピュータシステムにおけるスナップショットの参照処理について説明する。まず、先にブロック読み出し処理で述べた無効ブロック判定の処理を、ディスク装置４内のタイムスタンプ値がスナップショット情報１０の値よりも小さいストライプの論理アドレスタグに対して行ない、全論理アドレスに対する有効ブロックの物理的位置を検出する。読み出し処理では、全ストライプが対象だったが、このスナップショット参照処理では、スナップショット情報１０のタイムスタンプ値までに書き込まれたストライプだけを対象にする点が異なる。つまり、図１０のディスク状態では、ストライプＳＴ１〜ＳＴ４がブロック読み出しの無効ブロック判定の対象となるが、スナップショット参照処理では、ストライプＳＴ１〜ＳＴ３が無効ブロック判定の対象になる。
【００３６】
また、毎回無効ブロックの判定を行なっていたのでは、スナップショット参照に膨大な時間がかかってしまい実用的ではない。そこで、先の読み出し処理と同様に、最初にスナップショットを参照するときに対象となるストライプの論理アドレスタグの調査を行ない、揮発性メモリ６上に論理アドレスから物理アドレスへのスナップショット用変換マップを作る。図１１に、ディスク状態が図１０である場合のスナップショット用変換マップと読み出し用変換マップとの様子を示す（簡単化のためタイムスタンプのフィールドは省略した）。図１１からわかるように、スナップショット採取後に更新された論理アドレスＬ３、Ｌ７、Ｌ９、〜、Ｌ２５、Ｌ２７のブロックも、スナップショット用変換マップ（図１１（ａ））からは更新前のブロックが参照できるようになっている。また、読み出し用変換マップ（図１１（ｂ））は常に最新のブロックを指している。このように、無効ブロック判定処理の対象とするストライプを変えることにより、スナップショット参照用と読み出し用の変換マップとが作成できる。
【００３７】
なお、スナップショット採取時のディスクイメージは、ディスクスナップショット部３経由で参照することができるが、その中のファイルを直接参照することはできない。そこで、図１２に示すように、ディスクスナップショット部３にスナップショット採取時のディスクイメージを別の擬似ディスクとして見せる擬似ディスク機能をもたせる。一般にオペレーティングシステムは、起動フェーズで検出したディスクに格納されているデータがどのファイルシステムのものか検出し、対応するファイルシステムを構築する機能を持っている。よって、この擬似ディスクを検出したオペレーティングシステムは、その上にスナップショット参照用ファイルシステム１１を構築して、スナップショッ卜参照用ユーティリティプログラム１２がスナップショット採取時のファイルをアクセスできるようにする。このスナップショッ卜参照用ユーティリティプログラム１２としては、たとえば、特定ファイルを磁気テープにバックアップするプログラムなどが考えられる。なお、この擬似ディスク機能は、ＲＡＭディスクなどのハードウェアデバイスをもたないソフトウェアドライバとして実装すれば良いため、その実装は容易である。
【００３８】
（第２実施形態）
次に、この発明の第２実施形態を説明する。
【００３９】
前述の第１実施形態のコンピュータシステムにおけるスナップショット採取処理では、ファイルシステム２が更新データをキャッシュする機能をもたないことを想定していた。つまり、アプリケーションプログラム１ａ〜１ｃによるファイルの変更は、すぐにディスク装置４に書き出されるものと考えていた。よって、スナップショッ卜採取時には、それまでに書き込みバッファ８に溜まっていた書き込みデータをディスク装置４に書き出すだけで、正しいファイルシステム２の状態がディスク装置４に保存できた。しかしながら、たとえばＵＮＩＸのファイルシステムなど、更新データをキャッシュする機能をもったファイルシステムも今日では広く使われている。この場合、先のスナップショット採取処理では、キャッシュされていた更新データが失われてしまうので、正しいスナップショットが採取できない。
【００４０】
そこで、この第２実施形態のコンピュータシステムでは、ファイルシステム２が更新データをキャッシュする機能を有する場合のスナップショット採取を説明する。
【００４１】
一般に、更新データをキャッシュするファイルシステムでは、アプリケーションプログラムにより行なわれたファイル変更が確実にディスク装置に記録され残ることを保証できるように、アプリケーションプログラムからの指示によりキャッシュしている更新データをすべて書き戻す機能をもっている。そこで、この第２実施形態のディスクスナップショット部３では、アプリケーションプログラム１ａ〜１ｃからの書き出し前指示と書き出し後指示とを受け付け、これらの間にファイルシステム２からの書き出しが無い場合にだけ、先に述べたスナップショット採取処理を行なう条件付き採取機能を備える。
【００４２】
そして、このディスクスナップショット部３が備える機能を利用して、更新データがすべて書き戻された状態のスナップショットを、図１３のフローチャートで示される手順を含んだアプリケーションプログラム１ａ〜１ｃの指示に応じて採取する。アプリケーションプログラム１ａ〜１ｃは、まず、ディスクスナップショット部３に書き出し前指示を発行してこれからファイルシステム２の書き戻しを行なうことを指示する（ステップＡ１）。次に、キャッシュされている全更新データをディスク装置４に書き戻すようにファイルシステム２に指示する（ステップＡ２）。この指示を受けたファイルシステム２は、全更新データの書き戻しを実行し、その実行が完了したときに、その旨をアプリケーションプログラム１ａ〜１ｃに通知する。一方、アプリケーションプログラム１ａ〜１ｃでは、この書き戻しが完了した旨の通知をファイルシステム２から受け取ったときに、ディスクスナップショット部３に書き出し後指示を発行する（ステップＡ３）。
【００４３】
そして、この指示を受けたディスクスナップショット部３は、書き出し前指示から書き出し後指示までの間にファイルシステム２からの書き出しが無い場合にだけ、先に述べたスナップショット採取処理を行なう。ディスクスナップショット部３は、スナップショットを採取したか否かを書き出し後指示の応答としてアプリケーションプログラム１ａ〜１ｃに返す。一方、アプリケーションプログラム１ａ〜１ｃは、ディスクスナップショット部３がスナップショットを採取しなかった場合には（ステップＡ４のＮＯ）、最初からこれまでの処理を繰り返し（ステップＡ１〜ステップＡ３）、採取した場合に（ステップＡ４のＹＥＳ）、この処理を終了する。
【００４４】
以上の処理により、ファイルシステム２ヘ書き戻しを指示してもディスク装置４へ書き出すベきデータが無かったこと、すなわち、ディスク装置４上にはすでに正しいファイルシステム２の状態が保存されていることが保証される。したがって、ディスクスナップショット部３で正しいスナップショットが採取できることになる。たとえば、ただ単にファイルシステム２に書き戻し指示をするとともにディスクスナップショット部３にスナップショット採取を指示したのでは、この２つの指示の間にファイル更新が行なわれた場合に、一部の更新データがキャッシュに残ってしまうため、正しいスナップショットが採取できない危険性がある。よって、ここで述べた手順が必要になる。
【００４５】
（第３実施形態）
次に、この発明の第３実施形態を説明する。
【００４６】
前述の第１実施形態のコンピュータシステムでは、スナップショットは１つしか採取できなかったが、この第３実施形態のコンピュータシステムでは、複数のスナップショットを採取する。
【００４７】
まず、先の第１実施形態と異なるのは、図１４に示すように、ディスク装置４上のスナップショット情報１０が、複数のスナップショットそれぞれのタイムスタンプを保持する構造となっていることである。
【００４８】
そして、スナップショット採取処理においては、その時点で溜まっていたデータを書き込みにいく点は同じであるが、書き込んだストライプのタイムスタンプ値を、そのスナップショット（ＳＳ）のスナップショッ卜情報１０としてディスク装置４に保存する。たとえば、図１４のストライプ３（ＳＴ３）をスナップショットの採取処理で書き込む場合には、そのタイムスタンプ値ＴＳ３をスナップショット１（ＳＳ１）のスナップショット情報１０として保存する。同様に、ストライプ５（ＳＴ５）のスナップショット採取処理では、そのタイムスタンプ値ＴＳ５をスナップショット２（ＳＳ２）のスナップショット情報１０として保存し、ストライプ８（ＳＴ８）のスナップショット採取処理では、そのタイムスタンプ値ＴＳ８をスナップショット３（ＳＳ３）のスナップショット情報１０として保存する。
【００４９】
また、スナップショット参照処理においては、図１４に示すように、参照するスナップショットによって対象となるストライプが異なるだけで基本的処理は同じである。たとえば、スナップショット２（ＳＳ２）を参照する場合には、スナップショット情報１０のタイムスタンプ値ＴＳ５から、ＳＴ１〜ＳＴ５が対象となるストライプであることが分かる。そこで、ＳＴ１〜ＳＴ５のストライプだけを調べて、無効ブロックの判定処理とスナップショット参照用変換マップの作成処理とを実行する。そして、ＳＳ２のスナップショッ卜を参照する場合には、この変換マップを参照してスナップショット採取時のデータをアクセスする。同様に、ＳＳ１、ＳＳ３のスナップショットを参照する場合には、そのタイムスタンプ値ＴＳ３、ＴＳ８から対象となるストライプがＳＴ１〜ＳＴ３、ＳＴ１〜ＳＴ８であることが分かり、それらの対象となるストライプに対してだけ無効ブロックの判定処理とスナップショット参照用変換マップの作成処理とを実行し、その変換マップを使ってそれぞれのスナップショットが採取されたときのデータをアクセスする。
【００５０】
このように、スナップショット情報１０として複数のタイムスタンプ値を保存できるようにするだけで、複数のスナップショットを取り扱えるようになる。
【００５１】
次に、ディスクスナップショット部３が採取した複数のスナップショットをスナップショッ卜参照用ユーティリティプログラム１２からアクセスする方法を説明する。
【００５２】
第１の方法としては、図１５に示すように、ディスクスナップショット部３を拡張し、採取したスナップショッ卜ごとに対応する擬似ディスク装置１３ａ〜１３ｃを見せる機能をもたせて、それぞれの擬似ディスク装置１３ａ〜１３ｃの上にスナップショット参照用ファイルシステム１１ａ〜１１ｃを構築する。そして、それぞれのスナップショッ卜をアクセスするスナップショット参照用ユーティリティプログラム１２は、対応するスナップショット参照用ファイルシステム１１ａ〜１１ｃを経由して、スナップショット採取時のアクセスを行なう。しかしながら、この方法では、スナップショット数が増えると擬似ディスクも増えてしまう。たとえばマイクロソフト社のＷｉｎｄｏｗｓなどのように、プログラムから見えるディスク台数に上限があるオペレーティングシステムも多い。したがって、擬似ディスク装置１３ａ〜１３ｃが増えてしまうこの方法では、この制限のために適用できない場合も多くなる。また、プログラムから見えるディスク台数が多いとコンピュータシステムそのものの管理も大変である。
【００５３】
そこで、第２の方法としては、図１６に示すように、ディスクスナップショット部３にスナップショット用として擬似リムーバブルディスク１３を見せる機能をもたせて、各スナップショットはその擬似リムーバブルディスク用の擬似メディアとして取り扱う。この方法では、擬似ディスク装置１３が１台しか要らないので、第１の方法のような問題は発生しない。なお、この方法では、複数のスナップショットを同時にアクセスできないが、同時にスナップショットへのアクセスが必要なケースは少ないので、大きな問題にはならないと思われる。また、それぞれのスナップショットの必要なファイルを最新のディスクイメージにコピーすれば、同時アクセスが可能となるので大きな制限ではない。
【００５４】
また、通常、リムーバブルディスクをサポートするオペレーティングシステムでは、メディアを変更するとそれに合わせてファイルシステムの再構築などが自動的に行なわれる。そこで、スナップショットをＳＳ１からＳＳ２へ切り替えるときには、まず、この擬似リムーバブルディスク１３からメディアが変更された旨の情報をスナップショット参照用ファイルシステム１１やオペレーティングシステムに通知する。すると、オペレーティングシステムは、変更されたメディアをアクセスするために、これまでアクセスしていたスナップショットＳＳ１に対するスナップショット参照用ファイルシステム１１を終了し、変更されたメディアに対するスナップショット参照用ファイルシステム１１を起動する。この新しく起動されたスナップショット参照用ファイルシステム１１からのアクセスに対して、ディスクスナップショット部３の擬似リムーバブルディスクは、スナップショットＳＳ２のディスクイメージを返すことにより、スナップショット参照用ユーティリティプログラム１２は、ススナップショットＳＳ２のファイルをアクセスできるようになる、なお、ディスク（擬似ディスクを含む）がリムーバブルか否かの情報は、システム起動時などにオペレーティングシステムが問い合わせてくるので、このときに、リムーバブルである旨をディスクスナップショット部３がオペレーティングシステムに伝えればよい。
【００５５】
以上をまとめると、スナップショットを格納するディスクを擬似リムーバブルディスクとして扱うためにディスクスナップショット部３が行なうことは、
（１）システム起動時などでのオペレーティングシステムからの問い合わせにリムーバブルである旨の情報を返す。
【００５６】
（２）ユーザやアプリケーションプログラムからのスナップショット切り替え指示を受け付ける。
【００５７】
（３）このスナップショット切り替え指示に対して、メディアが変更された旨の情報をファイルシステムやオペレーティングシステムに通知する。
【００５８】
（４）オペレーティングシステムやファイルシステムからの変更されたメディアへのアクセスに対しては、ユーザやアプリケーションプログラムから指定されたスナップショットのイメージをアクセスできるようにする。
【００５９】
となる。
【００６０】
しかしながら、この第１および第２の方法では、オペレーティングシステムやスナップショッ卜参照用ユーティリティプログラム１２を含む各種プログラムから見える、スナップショットを採取したときのディスク装置とスナップショットを参照する場合のディスク装置とが異なってしまう。たとえば、図１５の場合、Ｗｉｎｄｏｗｓなどのオペレーティングシステムからは、ディスク装置４は“Ｃ：”ドライブ、ＳＳ１の擬似ディスクは“Ｄ：”ドライブなどとして見えてしまう。よって、環境変数などで各種プログラムが使うべきファイル名として、“Ｃ：”ドライブのＡファイルとあったとしても、スナップショット参照時には、“Ｄ：”ドライブのＡファイルとしなければ、各種プログラムは正しく動作しない。同様に、スナップショットのファイルの中にある処理に関連するファイル名として“Ｃ：”ドライブのＢファイルとあったとしても、スナップショットの参照時には、“Ｄ：”ドライブのＢファイルとしなければ、各種プログラムは正しく動作しない。
【００６１】
以上のように、オペレーティングシステムや各種プログラムから見えるディスク装置が異なってしまうと、環境変数やファイル内容をそれに合わせて変更しないとプログラムが正しく動作しない場合も多い。一般に、どのファイルや環境変数を変更すればよいか判っておらず、スナップショットを参照する度に変更するのは大変な作業である。
【００６２】
そこで、第３の方法として、図１７に示すように、ディスクスナップショット部３にディスク装置４がリムーバブル機能をもつようにオペレーティングシステム、ファイルシステムおよび各種プログラムに見せるリムーバブル化機能を設け、最新のディスクイメージと複数のスナップショットとをそれぞれ別の擬似メディアとして取り扱う。この方法では、スナップショット採取時の最新ディスクイメージとスナップショットのイメージとは擬似メディアが異なるだけであるので、オペレーティングシステムや各種プログラムなどから見えるディスク装置は同じであり、第１および第２の方法のような問題は発生しない。なお、この方法では、最新のディスクイメージとスナップショットとを同時にアクセスできなくなるが、ディスクやファイル名を意識するようなプログラムはもともと複数同時には実行できないので問題はないと思われる。
【００６３】
先に述べたように、ディスク装置（擬似ディスクを含む）がリムーバブルか否かの情報は、システム起動時などにオペレーティングシステムが問い合わせてくるので、ディスク装置４をリムーバブル化するには、このオペレーティングシステムからディスク装置４への問い合わせを途中で獲得して、リムーバブルである旨の情報を返せばよい。また、最新ディスクイメージやスナップショットを切替えるときには、第２の方法で述べたメディア変更の手順を行えばよい。
【００６４】
ここで、システムディスクのスナップショット参照について考える。システムディスクのスナップショットイメージでオペレーティングシステムを起動できれば、スナップショットを採取した時点の過去のオペレーティングシステム状態をそのまま再現でき、トラブル対応などで非常に役に立つ。しかし、システムディスクとは、オペレーティングシステムが実行するのに必要なオペレーティングシステムコード、デバイスドライバ、スワップファイルなどを格納するディスクであって、システム実行中は常にアクセスできなければならない。よって、システム実行中にアクセスできなくなるリムーバブルディスクにはできず、第２および第３の方法を適用することはできない。また、システムディスクは“Ｃ：”ドライブなど決まっている場合も多く、オペレーティングシステムから見えるディスクが異なってしまう第１および２の方法も適用できない。
【００６５】
そこで、第４の方法として、図１８に示すように、システム起動時に選択されたスナップショットを最新のディスク装置４のイメージの代わりにオペレーティングシステムやファイルシステムに見せるイメージ選択機能をディスクスナップショット部３に設け、任意のスナップショットをシステム起動時に選択できるようにする。選択したディスクイメージは、システム実行中には替わらないのでアクセスできなくなることはない。また、オペレーティングシステムやアプリケーションプログラムから見えるドライブは、スナップショットを採取したときと同じであるので、システムディスクが“Ｃ：”ドライブなどに予め決まっていても問題がない。
【００６６】
図１９に、この方法におけるコンピュータシステムの運用例を示す。通常のアプリケーションプログラムを実行する場合は、システム起動時にディスクスナップショット部３のイメージ選択機能により最新のディスクイメージをユーザなどが選択して起動処理を行なう。これにより、最新のディスクイメージに対応した最新のファイルシステムが構築され、通常のアプリケーションを実行できるようになる（Ｔ１）。ここで、スナップショットＳＳ１用のアプリケーションを実行するには、一旦、現在実行中のシステムを終了してシステムを再起動する。そして、この再起動時に、ディスクスナップショット部３のイメージ選択機能によりスナップショットＳＳ１をディスクイメージとしてユ−ザなどが選択する。これにより、スナップショットＳＳ１に対応したＳＳ１用のファイルシステムが構築され、スナップショットＳＳ１のファイルをアクセスするアプリケーションプログラムを実行できるようになる（Ｔ２）。さらに、通常のアプリケーションプログラムをを実行するには、システムを再起動して、再起動時に最新のディスクイメージを選択するようにする。
【００６７】
なお、図１９ではユーザなどがイメージを選択するのはシステム起動時だけであったが、ディスクスナップショット部３に次回のシステム起動時に選択すべきイメージを記録する次回記録機能を持たせて、イメージ選択機能はこの次回記録機能に記録されたイメージを選択するようにもできる。これにより、システム起動時以外でも、ユーザなどだけでなくアプリケーション（たとえばＴ１期間に実行されるアプリケーションプログラム）からでもイメージを選択できるようになる。この次回記録機能は、ディスク装置４の予め決めた場所に選択すべきイメージを保存しておき、システム起動時にこの情報を読み出してイメージ選択機能に教えるだけの簡単なプログラムで実現できる。
【００６８】
最後に、アプリケーションプログラムからスナップショットをアクセスするこれら第１乃至第４の方法は、それぞれ排他的に適用されるのではなく、任意に組み合わせて適用することも可能である。
【００６９】
ところで、これまでスナップショットの識別情報としては、ＳＳ１〜ＳＳ３を使っていたが、これだけではいつの時点のスナップショットか分かりにくく、一旦スナップショッ卜を参照してから別のスナップショットを参照すべきことが判明する場合も多い。そこで、図１４に示すように、スナップショット情報１０としてスナップショットを採取した日時を保存するフィールドを用意し、ディスクスナップショット部３がスナップショット採取時のタイムスタンプだけでなく、日時もスナップショット情報に記録するようにする。そして、この日時をスナップショットに対応した擬似ディスクや擬似メディアの識別情報として用いることにより、いつの時点のスナップショットかすぐに分かり、効率のよいスナップショッ卜の運用が可能になる。
【００７０】
（第４実施形態）
次に、この発明の第４実施形態を説明する。
【００７１】
これまでに述べた実施形態では、一度採取したスナップショットは参照だけで変更しないことを前提に説明してきた。よって、図２０（ａ）に示すように、各スナップショットは採取された時間順に一直線に並んでおり一番先頭が最新のディスクイメージとなる順序関係があった。しかしながら、先に述べたシステムディスクのスナップショットの場合、オペレーティングシステム起動途中やオペレーティングシステム実行中にファイルの作成、変更、削除などが行なわれ、また、グループウェアやＤＢＭＳなどのアプリケーションプログラムからスナップショットのファイルをアクセスする場合も、アプリケーションプログラムが実行中である旨の情報などがファイルに書き込まれる。しかも、古いスナップショットの状態から起動したシステムを使って次にスナップショットを採取しても、それは古いスナップショットに戻る前の最新イメージＫとも異なる。このような揚合、戻る前の最新イメージＫも参照したくなる場合があると考えられる。つまり、図２０（ｂ）に示すように、スナップショットＳＳ１、ＳＳ２、ＳＳ３の順番でスナップショットを採取した後で、ＳＳ２のスナップショット時点から再起動したシステムでは、ＳＳ３への変更とは全く異なる変更を行ない、さらにそれに対するスナップショットＳＳ４を採取するなどができなければならない。また、図２０（ｂ）に示すように、複数の最新ディスクイメージを並行してアクセスできる必要もある。
【００７２】
以下ではスナップショットの変更方法について説明する。
【００７３】
まず、スナップショットの変更を可能にするには、図２１に示すように、ディスク装置４上のスナップショット情報として、親となるスナップショット情報（親ＳＳ）と、親ＳＳからそのスナップショットまでに書き出されたストライプのタイムスタンプを保存するようにする。たとえば、図１４のスナップショットＳＳ３は、その基となったスナップショットはＳＳ２であるので、スナップショット情報の親ＳＳとしてＳＳ２を保存する。また、ＳＳ２からＳＳ３への間に書き出されたストライプのタイムスタンプは、ＴＳ６〜ＴＳ８であるので、スナップショッ卜情報のタイムスタンプとしてＴＳ６〜ＴＳ８を保存する。また、複数の最新ディスクイメージを実現するため、スナップショット情報と同様に、親ＳＳとその親ＳＳからその最新イメージまでに書き出されたストライプのタイムスタンプとを最新イメージ（ＮＩ）情報としてディスク装置４上に保存する。
【００７４】
ここで、図２０（ａ）の状態から図２０（ｂ）のように、スナップショットＳＳ２を変更してスナップショットＳＳ４を作成する場合を考える。まず、先に述べた擬似ディスクなどを使ってＳＳ２の参照を行なう。そして、オペレーティングシステムやアプリケーションプログラムがこのスナップショッ卜ＳＳ２を更新し、それに対する書き込みブロックがディスクスナップショット部３に到着した段階で、ディスクスナップショット部３はＳＳ３の先にある最新イメージＮＩ１への追加的更新でないので、最新イメージ情報として最新イメージＮＩ２を作成する。（親ＳＳはＳＳ２であるので、この情報がＮＩ２の親ＳＳとして保存される。）さらに、通常のディスクスナップショット部３の書き込み動作と同じように、メモリ６上の書き込みバッファ８にこの書き込みブロックを順次溜め、書き込みデータが１ストライプ分に１ブロック少ない数（Ｋ−１）だけ書込みバッファ８に溜まった段階で、ディスク装置４に書き込みにいく。最後の書き込みブロックとして、各ブロックの論理アドレスとタイムスタンプとから論理アドレスタグブロックを作成するのも同じである。なお、通常の最新イメージＮＩ１とＳＳ２の更新とを同時に行なう場合には、スナップショット変更用に別の書き込みバッファ８を用意して、それぞれ別々に溜める。そして、ディスク装置４に書き込んだストライプＳＴ１０のタイムスタンプＴＳ１０１を最新イメージＮＩ２のタイムスタンプとして記録する（図２１参照）。
【００７５】
ＳＳ２の変更が進んでスナップショットＳＳ４を採取する処理も前述のスナップショット採取処理と同じである。つまり、まだ埋まっていない部分に対応する書き込み管理テーブル９にヌルアドレスを格納して、書き込みバッファ８にその時点で溜まっているデータをディスク装置４に書き込みにいく。そして、最新イメージＮＩ２の情報（親ＳＳがＳＳ２、タイムスタンプがＴＳ１０１）とこのときに付加したタイムスタンプの値ＴＳ１０２とから、スナップショットＳＳ４のスナップショット情報として、親ＳＳとしてＳＳ２、タイムスタンプとしてＴＳ１０１〜ＴＳ１０２をディスク装置４へ書き込む。そして、タイムスタンプの値は書き込みが完了した段階でインクリメントされる。また、最新イメージＮＩ２の最新イメージ情報は、親ＳＳとして新しく作成したＳＳ４が保存され、タイムスタンプはクリアされる。
【００７６】
さらに、このスナップショットＳＳ４が更新されストライプＳＴ１３がディスク装置に書き出された場合は、最新イメージＮＩ２のタイムスタンプ情報にはＴＳ１０３が保存される。
【００７７】
次に、スナップショットを変更する場合の最新イメージやスナップショットの参照処理について説明する。たとえば、ディスク装置４が図２１の状態であるときに、スナップショットＳＳ４を参照する場合を考える。このＳＳ４は、ＳＳ２を元に変更を加えたスナップショットであるので、参照時の変換マップ作成の対象とすべきストライプはＳＳ２対象のＳＴ１〜ＳＴ５とＳＳ２からＳＳ４への変更分のＳＴ１０〜ＳＴ１１とでなければならない。そこで、これらのストライプを以下の手順で見つける。
【００７８】
まず、スナップショット情報を使って、ＳＳ４の親ＳＳがＳＳ２であることとＳＳ２からＳＳ４への更新データを書き出したストライプのタイムスタンプがＴＳ１０１〜ＴＳ１０２であることを知る。次に、スナップショット情報１０を使って、ＳＳ２の親ＳＳがＳＳ１であることとＳＳ１からＳＳ２への更新データを書き出したストライプのタイムスタンプがＴＳ４〜ＴＳ５であることを知る。この処理を親ＳＳが無くなるまで繰り返すことにより、スナップショットＳＳ４までに書き出されたストライプのタイムスタンプが、ＴＳ１〜ＴＳ３、ＴＳ４〜ＴＳ５、ＴＳ１０１〜ＴＳ１０２であることが分かる。
【００７９】
よって、ディスク上の各ストライプのタイムスタンプを比較することにより、ＳＳ４参照時の対象ストライプであるＳＴ１〜ＳＴ５とＳＴ１０〜ＳＴ１１とを見つけられる。なお、先に説明した実施形態では、最新ディスクイメージを読み出す場合には、ディスク装置上の全ストライプを対象に変換マップを作成すれば良かったが、ストライプの変更が可能な場合には、最新イメージ情報とスナップショット情報とを使い、スナップショット参照と同様の処理を行なって対象とすべきストライプのタイムスタンプを求める。
【００８０】
なお、前述のスナップショット変更処理の説明では、ストライプを書き込む度に最新イメ一ジ（ＮＩ）情報のタイムスタンプ情報を変更していた。また、スナップショット情報や最新イメージ情報のタイムスタンプ情報などは、図２１に示すように、区間情報の方が扱い易い。そこで、最新イメージ（ＮＩ）を作成するときに、書き出す際に用いるタイムスタンプ値を予め予約しておき、ディスク装置にタイムスタンプ（ＴＳ）情報として保存しておく方法が考えられる（図２１参照）。これにより、ストライプを書き出す度に最新イメージ情報のタイムスタンプを更新しなくても、ディスク上の全ストライプのタイムスタンプを調べることによって、この情報を再現できる。たとえば、ストライプＳＴ１３を書き出したときに最新イメージＮＩ２のタイムスタンプを更新しなくても、最新イメージＮＩ２のタイムスタンプはＴＳ１０１〜ＴＳ２００が割り当てられることと、ディスク装置４上のストライプでこの区間に入る最大のタイムスタンプはＴＳ１０３であることから、ＮＩ２のタイムスタンプは最後がＴＳ１０３であることが分かる。また、予めタイムスタンプ値を最新イメージごとに分けているので、スナップショット情報やＮＩ情報のタイムスタンプ値は必ず区間情報になる。
【００８１】
ここで、図２２を参照してスナップショットの削除について考える。スナップショットの変更を許さない場合、図２２（ａ）のようにスナップショットＳＳ２を削除するにはスナップショット情報のスナップショットＳＳ２に関する情報を削除するだけで良く、特別な処理を必要としない。しかしながら、スナップショットの更新が可能な場合には、スナップショットの削除処理はもっと複雑になる。まず、スナップショット情報や最新イメージ情報には親ＳＳを含む。よって、親ＳＳが削除された場合には、削除された親ＳＳの親ＳＳをスナップショット情報や最新イメージ情報の親ＳＳにする必要がある。また、スナップショット情報や最新イメージ情報のタイムスタンプは、削除された親ＳＳのタイムスタンプも含むように修正する必要がある。
【００８２】
さらに、図２１のディスク状態で図２２（ｂ）のようにスナップショットＳＳ３と最新イメージＮＩ１とを削除する場合には、図２３に示すように、スナップショット情報とＮＩ情報とを削除するだけでなく、削除ストライプ情報（ＤＥＬ情報）としてスナップショットＳＳ３と最新イメージＮＩ１のタイムスタンプとをディスク装置４上に保存して、これらのタイムスタンプを使わないようにする必更がある。
【００８３】
（第５実施形態）
次に、この発明の第５実施形態を説明する。
【００８４】
これまで述べた実施形態におけるスナップショット採取処理では、その時点で溜まっていた更新データだけで１つのストライプを構成しディスク装置を書き出していたので、スナップショット採取時のストライプには更新データが無く無駄である領域が出でしまう。したがって、スナップショット採取の頻度が多い場合には、ディスク装置４上に無駄な領域が増えてしまう。
【００８５】
そこで、スナップショット採取処理は先の場合と同じで、まだ埋まっていない部分に対応する書き込み管理テーブル９にヌルアドレスを格納し、書き込みバッファにその時点で溜まっているデータにタイムスタンプを付けてディスク装置４に書き込みに行く。このとき、スナップショット情報としては、図２４に示すように、タイムスタンプ値だけでなく、スナップショット採取時に溜まっていたストライプ内のブロック番号も保存する。
【００８６】
そして、スナップショット採取直後の書き込み処理において、書き込みバッファ８やバッファ管理テーブル９をクリアすることなく、更新データを続けて書き込みバッファ８に格納する。そして、この書き込みバッファ８が１ストライプ分に１ブロック少ない数（Ｋ−１）だけ溜まった段階で、論理アドレスタグブロックを作成し、ディスク装置４に書き出す。このとき、論理アドレスタグブロックのタイムスタンプには、スナップショット採取時の値を、書き出すディスク装置４の位置は、スナップショット採取と同じストライプに上書きする。（図２４のＳＴ３）
このように採取したスナップショットの参照処理では、スナップショット情報のタイムスタンプ値とタイムスタンプが一致するストライプについては、スナップショット情報のブロックまでをそのスナップショットの対象として変換マップ作成時の無効ブロックの判定を行なう。つまり、図２４の場合には、ストライプＳＴ３についてはブロックＢ１〜Ｂ６がスナップショットの対象となるブロックとする。
【００８７】
スナップショット採取直後の書き出し処理とスナップショット参照処理とにおいて、以上のように処理することにより、スナップショットのストライプにも無駄な領域を作らないでスナップショット採取することができる。
【００８８】
（第６実施形態）
次に、この発明の第６実施形態を説明する。
【００８９】
これまで述べた実施形態においてディスクスナップショット部３として採用している、更新前データの領域を書き換えるのではなく、更新データを溜めておいてディスク装置内の予め用意された別の空領域にまとめて書き込む方法では、空領域が常に存在することが必須である。そのため、ファイルシステム２からのディスクアクセスが空いている間に、すでに他の領域にデータが書き込まれて無効になっているデータを寄せ集めて空領域を作る必要がある。ここでは、この処理を詰替え処理と呼ぶものとする。この詰替え処理は、先に述べた無効ブロック判定とストライプ統合との２つのステップからなる。ここで、無効ブロックとは、スナップショット参照としても、通常の読み出しとしてもアクセスされないブロックのことである。つまり、スナップショット参照用変換マップおよび読み出し用変換マップのいずれからも指されていないブロックが無効ブロックである。
【００９０】
ストライプ統合の例として、図２５に示すように２つのストライプＳＴ１、ＳＴ３を１つのストライプＳＴ１０に統合する場合を考える。図２５に示すように、ストライプＳＴ１では、Ｂ２、Ｂ７、Ｂ８、Ｂ１２、Ｂ１３の５ブロックが有効であり、他の１０ブロックは無効であるとする。同様に、ストライプＳＴ３では、ブロックＢ１８、Ｂ１９、Ｂ２０、Ｂ２１、Ｂ２２、Ｂ２４、Ｂ２５、Ｂ２７、Ｂ２９の９ブロックが有効であり、他の６ブロックが無効であるとする。この２つのストライプの有効ブロックは、合わせて１４ブロックしかないので、この２つのブロックを１つに統合することにより、結果として１つの空領域が作れることになる。
【００９１】
ストライプ統合では、２つのストライプをメモリ内に読み出し、有効ブロックだけを詰めて書込みバッファに移す。それに合わせて、論理アドレスタグも、図２６に示すように、ＴＧ１、ＴＧ３から有効ブロックの論理アドレスだけを対応する位置に移して新しい論理アドレスタグＴＧ１０を作り、その時点のタイムスタンプを更新する。この例では、１４個の有効ブロックしかなかったので、最後のデータブロックは空状態のまま書き込む。このときは、論理アドレスタグＴＧ１０の最後のデータブロックに対する論理アドレスにヌルルアドレスを入れることによりデータが入っていないことを表わせるので問題はない。
【００９２】
しかしながら、スナップショットがある場合、ただ詰替えを行なったのでは詰替える前の領域を空き状態にできない。図２７を参照してこれらについて説明する。
【００９３】
たとえば、図２７に示すように、ストライプＳＴ１とＳＴ３を詰替えて新しいストライプＳＴ１０を作ったとしても、スナップショット情報では、スナップショットＳＳ１はタイムスタンプがＴＳ１からＴＳ４であるストライプが対象であり、スナップショットＳＳ１の参照では、空き状態であるはずのストライプＳＴ１およびＳＴ３のブロックをアクセスにいってしまう。
【００９４】
そこで、図２７に示すように、詰替え情報として、詰替えで作成されたストライプのタイムスタンプをディスク上に保存する。また、ストライプの参照処理では、スナップショット情報のタイムスタンプ値から決まるストライプだけでなく、詰替え情報のタイムスタンプのストライプも対象とする。たとえば、スナップショットＳＳ１の参照処理では、タイムスタンプがＴＳ４より小さいストライプ（ＳＴ１〜ＳＴ４）だけでなく、詰替え情報のタイムスタンプのストライプ（ＳＴ１０）も無効ブロック判定の対象とする。これにより、ストライプＳＴ１０はストライプＳＴ１およびＳＴ３の有効ブロックだけを詰替えたものであることから、ストライプＳＴ１およびＳＴ３の全ブロックは必ず無効と判定され、ストライプＳＴ１およびＳＴ３はスナップショットからも参照されることはなくなる。よって、実質的には空き領域となる。
【００９５】
ただし、この方法は、同一のスナップショットのみから対象とされるストライプ同士を詰替えた場合にのみ正しく動作し、図２８に示すような、スナップショットＳＳ１、ＳＳ２、ＳＳ３が対象とするストライプＳＴ２と、スナップショットＳＳ２、ＳＳ３が対象とするストライプＳＴ６とを詰替えて、ストライプＳＴ１０を作るような場合には正しく動作しない。なぜならば、ストライプＳＴ１０にはスナップショットＳＳ１採取後に書き出されたストライプＳＴ６の更新ブロックが含まれているため、スナップショットＳＳ１の参照処理でストライプＳＴ１０も対象にしてしまうと、ＳＳ１採取時のディスク状態が再現できないからである。
【００９６】
そこで、図２８に示すように、詰替えによって作成されたストライプの中に、元になった各ストライプのタイムスタンプと元ブロックが格納されているブロック位置とを元ストライプ情報として保存する。そして、スナップショットの参照処理において、詰替えによって作成されたストライプ（詰替え情報から分かる）に対しては、この元ストライプ情報も活用して不要なブロックを対象にしないようにする。つまり、先のスナップショットＳＳ１の参照処理においては、ストライプＳＴ１０の全ブロックを対象にするのではなく、スナップショットＳＳ１のタイムスタンプＳＴ４より小さい、ブロックＢ１〜Ｂ６（タイムスタンプＴＳ２）だけを対象にする。これにより、スナップショットＳＳ１採取時のディスクイメージを再現できるとともに、ストライプＳＴ２の全ブロックが無効となりＳＴ２を空き領域にできる。
【００９７】
最後に、これまでの詰替え処理の説明では、無効ブロックとはスナップショット参照としても通常の最新イメージの読み出しとしてもアクセスされないブロックと定義し、スナップショット参照用変換マップと読み出し用変換マップとが作成され、それらの変換マップから参照されないブロックを見つける方法を取っていた。しかしながら、この方法では、スナップショット数が多くなると作成すべき変換マップの数も多くなり、非常に効率が悪い。
【００９８】
そこで、無効ブロックの判定に無効ブロックに対応したビットマップを使う方法について説明する。図２９には無効ブロックに対応したビットマップを使った無効ブロック判定のための構成が示されている。
【００９９】
図２９に示すように、メモリ６上には現時点の最新ディスクイメージを構成するディスク装置４上の全ブロックの状態をビットマップとして保持する。
【０１００】
このビットマップは、全ビットを無効状態に初期化した後、読み出し用変換マップから参照されるブロックに対応するビットを有効状態にすることにより容易に作成できる。また、書き出し処理により書き込みバッファ８内の更新データが空き状態のストライプに書き出されると、書き出したストライプのビットマップを有効状態にする（なお、書き込みバッファ管理テーブル９にヌルアドレスをセッ卜されたブロックに対応するビッ卜は無効のままとする）。さらに、この書き出しにより変更された論理アドレスに対する書き出し以前のブロック位置を読み出し用変換マップから求めて、このブロックを無効化されたブロックとして対応するビットマップを無効状態にする。以上のビットマップ変更を更新データの書き出し処理ごとに行なえば、常に最新ディスクイメージを構成するディスク装置４上の全ブロックの状態を維持できるようになる。
【０１０１】
そこで、チェックポイント採取処理では、図２９に示すように、このビットマップもスナップショット情報として保存する。そして、無効ブロックの判定処理では、メモリ６上のビットマップとスナップショット情報の全ビットマップとを調べることにより、無効状態にあるブロックを無効ブロックと判定する。これにより、スナップショットの変換マップを作成しなくても、無効ブロックの判定が可能となり、詰替えるべきストライプを容易に見つけることが可能となる。
【０１０２】
なお、図２９では、メモリ６の全ビットマップをスナップショット情報として保存したが、このビットマップは無効ブロックの判定に用いるだけなので、図３０に示すように、スナップショット採取時に無効ブロックの多いストライプに対するビットマップだけをスナップショット情報として保存することもできる。図３０の例では、ストライプＳＴ３、ＳＴ５、ＳＴ６、ＳＴ１０の無効ブロックが多いので、これらのストライプのビットマップだけがストライプ情報として保存されている。これにより、スナップショット情報のための領域を減らせ、詰替えのための無効ブロック判定も効率よく行なえる。
【０１０３】
（第７実施形態）
次に、この発明の第７実施形態を説明する。
【０１０４】
これまでに述べた実施形態では、更新データやスナップショット情報、最新イメージ情報、削除ストライプ情報、詰替え情報を記憶するディスク装置は１台であるものとして説明してきたが、図３１に示すように、複数のディスク装置から１台の論理的ディスク装置を構成したディスクアレイ装置（ＲＡＩＤ０、１、３、４、５）であっても良い。このとき、これまでの説明で使ってきたストライプのサイズとしては、ＲＡＩＤ０の場合は、“ストライプユニット単位（そのディスク装置の１トラック長に近いサイズが好ましい）＊ディスク台数”を選び、一方、ＲＡＩＤ３、４、５の場合は、“ストライプユニット単位＊（ディスク台数−１）”を選ぶことにより、全ディスクを同じタイミングで書き込めるため非常に効率が良い。特に、冗長情報としてパリティを使うＲＡＩＤ４、５では、通常必要な２回の読み出しと１回の書き込みが不要になり、非常に効率が良い。
【０１０５】
なお、この発明は、不揮発性記憶装置としてディスク装置を用いるコンピュータシステムだけではなく、光磁気ディスク、ＤＶＤ−ＲＡＭおよびＥＥＰＲΟＭなどのあらゆる不揮発性記憶装置を用いるスナップショットやバックアップを必要とするコンピュータシステムに適用可能である。
【０１０６】
【発明の効果】
以上詳述したように、この発明では、たとえばディスク装置などの不揮発性記憶装置とファイルシステムとの間に、ディスクレベルのスナップショットを採取するスナップショット管理手段を介在させる構造を採用するため、既存のコンピュータシステムのファイルシステムをそのまま使え、専用のファイルシステムを新しく開発する必要がない。また、ファイルシステム自身もブロック木構造である必要はまったくなく、ＮＴＦＳなどのエクステントベースのファイルシステムにでも適用できる。さらに、従来発生していた、スナップショッ卜作成後の更新性能が大きく低下するという問題もない。そして、スナップショットはスナップショット情報という簡単なデータ構造で実現されるため、スナップショットに対する操作は読み出しだけでなく更新も可能となり、ファイルをコピーしなくてもファイル更新を伴なうアプリケーションプログラム（ＤＢＭＳ、メールなど）を使って過去のスナップショットをアクセスして必要な情報を取り出せる。また、スナップショットは擬似ディスク、リムーバブルメディア、最新ディスクイメージとして見せることにより、スナップショットをアクセスするために、既存のオペレーティングシステム、ファイルシステムおよびアプリケーションプログラムなどを改造することなく、既存のコンピュータシステムにそのまま適用することが可能である。
【図面の簡単な説明】
【図１】この発明の第１実施形態に係るコンピュータシステムの構成を示す概念図。
【図２】同第１実施形態のディスクスナップショット部の構成を示す概念図。
【図３】同第１実施形態の揮発性メモリ内の書き込みバッファとバッファ管理テーブルとの関係を示す図。
【図４】同第１実施形態のディスク装置上の空領域を示す図。
【図５】同第１実施形態のコンピュータシステムにおける書き込み処理を説明すための図。
【図６】同第１実施形態の無効ブロックの判定処理を説明するための図。
【図７】図６の例における２つのストライプＳＴ１、ＳＴ２の論理アドレスタグＴＧ１、ＴＧ２の内容を示す図。
【図８】同第１実施形態の論理アドレスから物理アドレスへの変換マップを示す図。
【図９】同第１実施形態のコンピュータシステムにおけるスナップショットの採取処理を説明するための図。
【図１０】同第１実施形態のコンピュータシステムにおけるスナップショットの参照処理を説明するための図。
【図１１】ディスク状態が図１０である場合のスナップショット用変換マップと読み出し用変換マップとの様子を示す図。
【図１２】ディスクスナップショット部がもつスナップショット採取時のディスクイメージを別の擬似ディスクとして見せる擬似ディスク機能を説明するための図。
【図１３】この発明の第２実施形態に係るコンピュータシステムのスナップショット採取手順を説明するためのフローチャート。
【図１４】この発明の第３実施形態に係るコンピュータシステムのスナップショット情報を示す図。
【図１５】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第１の方法を説明するための図。
【図１６】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第２の方法を説明するための図。
【図１７】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第３の方法を説明するための図。
【図１８】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第４の方法を説明するための図。
【図１９】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第４の方法におけるコンピュータシステムの運用例を示す図。
【図２０】この発明の第４実施形態に係るコンピュータシステムにおけるスナップショットの変更を説明するための図。
【図２１】同第４実施形態のスナップショット情報、最新イメージ情報およびタイムスタンプ情報を説明するための図。
【図２２】同第４実施形態のコンピュータシステムにおけるスナップショットの削除を説明するための図。
【図２３】同第４実施形態のスナップショット情報、最新イメージ情報およびタイムスタンプ情報のスナップショットの削除に伴なう取り扱いを説明するための図。
【図２４】この発明の第５実施形態に係るコンピュータシステムのスナップショット情報を示す図。
【図２５】この発明の第５実施形態に係るコンピュータシステムにおける詰替え処理を説明するためのストライプを示す図。
【図２６】同第５実施形態のコンピュータシステムにおける詰替え処理を説明するための論理アドレスタグを示す図。
【図２７】同第５実施形態のコンピュータシステムにおける詰替え情報を説明するための図。
【図２８】同第５実施形態のコンピュータシステムにおける元ストライプ情報を説明するための図。
【図２９】同第５実施形態の無効ブロックに対応したビットマップを使った無効ブロック判定のための構成を示す図。
【図３０】同第５実施形態のスナップショット採取時に無効ブロックの多いストライプに対するビットマップだけをスナップショット情報として保存する例を示す図。
【図３１】この発明の第７実施形態に係るコンピュータシステムのディスク装置をディスクアレイ装置で構成した例を示す図。
【図３２】従来のスナップショットの作成を説明するための図。
【図３３】従来のスナップショットの作成の問題点を説明するための図。
【符号の説明】
１ａ〜１ｃ…アプリケーションプログラム、２…ファイルシステム、３…ディスクスナップショット部、４…ディスク装置、５…ディスクスナップショット制御部、６…揮発性メモリ、７…タイムスタンプ、８…書き込みバッファ、９…バッファ管理テーブル、１０…ディスクスナップショット情報、１１…スナップショット参照用ファイルシステム、１２…スナップショット参照用ユーティリティプログラム、１３…スナップショット用ディスク装置。
【発明の属する技術分野】
この発明は、たとえばディスク装置などに格納されたファイルの更新前データを後方回復のために退避するコンピュータシステムのデータ退避方法に係り、特に既存のオペレーティングシステム、ファイルシステムおよびアプリケーションプログラムなどの改造を伴なわずにファイルの内容を所定の時点に復元するためのスナップショットを効率的に採取するコンピュータシステムのデータ退避方法に関する。
【０００２】
【従来の技術】
従来より、ディスク単体の障害に対しては、冗長化ディスク構成を採用することによって対処が可能であるが、この冗長化技術は、ソフトウェアバグ、誤操作およびウイルス感染などによるプログラムまたはデータの喪失・改変、もしくはディスク記憶装置そのものを失なうような大規模な障害には役立たない。これらの問題に対処するためには、スナップショットやバックアップなどの採取が必須となる。
【０００３】
スナップショットとは、ある時点のファイルやディスクなどのコピーイメージのことであり、定期的にファイルやディスク全体を同じディスク記憶装置や別のディスク記憶装置にコピーして、スナップショットを作成する。そして、プログラムまたはデータが喪失・改変された場合には、直前に作成されたスナップショット（コピーイメージ）にプログラムまたはデータ、もしくはディスク全体を戻すことによりこれらの障害に対処する。
【０００４】
また、バックアップとは、このスナップショットを別の大容量記憶媒体（磁気テープなど）に保存して保管したものである。これにより、ディスク記憶装置そのものを失った場合（中のデータも全部喪失）であっても、新しいディスク記憶装置にこのバックアップをロードすることによって、スナップショッ卜採取時のプログラムまたはデータを復元することができる。
【０００５】
通常、スナップショットやバックアップの採取時には、それらのファイルを変更する可能性があるアプリケーションをすべて停止する必要がある。そうしないと、コピー作成中にファイルやデータが変更されてしまい、正しいスナップショットやバックアップが採取できないからである。すなわち、不正なスナップショットやバックアップをディスク記憶装置に戻しても、アプリケーションプログラム側でエラーや誤動作を発生させる危険性があるため、先の障害対策として意味をなさない。
【０００６】
なお、一般に大容量記憶媒体よりもディスク記憶装置への書き込みの方が高速であるので、ファイルやディスクイメージを直接バックアップするよりも、スナップショットを作成し、それを大容量記憶媒体にバックアップする方がアプリケーションの停止期間を短く押さえられる。また、プログラムまたはデータの喪失・改変からの復元もスナップショットの方が短期に行なえる。バックアップが磁気テープなどのシーケンシャルアクセスの媒体の場合、特定のファイルを見つけて読み出すには多くの時間を要してしまい非常に効率が悪い。
【０００７】
また、このスナップショットやバックアップを採取するためにアプリケーションを長時間停止しなければならないといった問題を解決する、スナップショット機能を持ったファイルシステムも開示されている（文献１：「Ｔｈｅ Ｅｐｉｓｏｄｅ Ｆｉｌｅ Ｓｙｓｔｅｍ」，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｗｉｎｔｅｒ １９９２ ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ．４３−６０，Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ、文献２：「Ｆｉｌｅ ＳｙｓｔｅｍＤｅｓｉｇｎ ｆｏｒ ａｎ ＮＦＳ Ｆｉｌｅ Ｓｅｒｖｅｒ Ａｐｐｌｉａｎｃｅ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｗｉｎｔｅｒ １９９４ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ．２３５−２４４，Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ）。
【０００８】
ところで、これらのファイルシステム（たとえば文献２）では、図３２（ａ）に示すように、ファイルがルート・Ｉノードを起点とするブロック木構造であることを前提にしている。そして、スナップショット作成時には、このルート・Ｉノードのコピーを作成する。このコピーしたＩノード（スナップショット・Ｉノード）は、スナップショットとしてのブロック木構造を表現することになる。また、コピー元のルート・Ｉノードは、読み出し／書き込みが行なわれるアクティブなファイルシステムのブロック木構造を表現する。スナップショット・Ｉノードは、生成されたときにはルート・Ｉノードとまったく同じブロックを指しているので（図３２（ｂ））、新しいスナップショットのためにコピーしたＩノード以外はまったくディスクスペースを消費しない。
【０００９】
ここで、ユーザがデータブロックＤを変更したとすると、図３２（ｃ）に示すように、新しいデータブロックＤ’をディスク上に書き込み、ルート・Ｉノードで表現するアクティブなファイルシステムが、この新しいブロックを指すように変更される。ディスク上の元のデータブロックＤは変更されずに残っており、スナップショット・Ｉノードは、元のデータブロックＤをまだ指している。したがって、スナップショット・Ｉノードを指定することにより、スナップショット作成時のデータブロックＡ、Ｂ、Ｃ、Ｄ、Ｅをそのまま参照できる。
【００１０】
このように、スナップショット機能を持ったファイルシステムを使えば、ルート・Ｉノードをコピーするだけで簡単にスナップショットを作成でき、アプリケーションプログラムを停止することなくスナップショットが作成できる。また、スナップショットをアプリケーションプログラムの実行と並行して大容量記億媒体に保存できるので、バックアップの採取もアプリケーションを停止することなく行なえる。したがって、スナップショットやバックアップのデータ退避のためにアプリケーションプログラムを停止する必要が無くなる。
【００１１】
【発明が解決しようとする課題】
しかしながら、前述した手法においては、専用のファイルシステムを新しく開発する必要があり、既存のコンピュータシステムにそのまま適用できるものではなかった。また、ファイルシステム自身もブロック木構造で構成されていることを前提にしており、たとえばマイクロソフト社のＮＴＦＳなどのエクステントベースのファイルシステムには適用できる技術ではなかった。さらに、一般にファイルシステムは大きな木構造をしており、実際に前述のデータブロックＤをＤ’に更新するには、図３３に示すように、その経路に位置する中間ノードすべてをコピーする必要があり、スナップショット作成後の更新性能が大きく低下するといった問題もあった。さらに、ファイルシステムという複雑なソフトウェアモジュールにスナップショット機能を付加したため、スナップショットは読み出しだけで非常に硬直なものになってしまっていた。
【００１２】
この発明はこのような実情に鑑みてなされたものであり、既存のコンピュータシステムやファイルシステムにそのまま適用することができ、かつ更新時のオーバヘッドもなく、スナップショットの更新なども可能な非常に柔軟なデータ退避を可能とするコンピュータシステムのデータ退避方法を提供することを目的とする。
【００１４】
【課題を解決するための手段】
前述した目的を達成するために、この発明は、不揮発性記憶装置に格納されたファイル群に対するアプリケーションプログラムからの更新を含むアクセスを管理するファイルシステムとＫ個の論理ブロックに相当する容量を有する書き込みバッファとを備えたコンピュータシステムに適用されるデータ退避方法において、前記書き込みバッファに更新すべきデータの論理ブロックを蓄積し、その蓄積した論理ブロックがＫ−１個に達したら、前記書き込みバッファに蓄積された各論理ブロックに対する論理アドレスから構成され、タイムスタンプを付加した論理アドレスタグブロックを生成し、Ｋ−１個のブロックに前記論理アドレスタグブロックを加えたＫ個の論理ブロックを一つのストライプとして前記不揮発性記憶装置上の更新されるべきデータを保持する領域とは別の空き領域に連続して書き込みを行う書き込み処理であって、前記書き込み処理中に、前記ファイル群の内容を所定の時点に復元するためのスナップショットを採取するスナップショット採取の指示があった場合に、前記Ｋ−１個の論理ブロックの中で、スナップショット採取時点で更新すべきデータの論理ブロックが埋まっていない論理ブロックに対する論理アドレスをヌルアドレスとしてストライプを作成し、当該ストライプの論理アドレスタグブロックに付加したタイムスタンプをスナップショット情報として前記空き領域内のストライプが書き込まれた領域とは別の領域に記録することを特徴とする。
【００１５】
すなわち、たとえばディスク装置などの不揮発性記憶装置と、この不揮発性記憶装置に格納されたファイル群に対するアプリケーションプログラムからの更新を含むアクセスを管理するファイルシステムとの間に、ファイル群の内容を所定の時点に復元するためのスナップショット情報を不揮発性記憶装置ごとに採取し、この採取したスナップショット情報をそれぞれの不揮発性記憶装置上に格納するスナップショット管理手段を設けるようにしたものである。
【００１６】
この発明によれば、既存のオペレーティングシステムやファイルシステム、あるいはアプリケーションプログラムになんらの改造を伴なうことなく、スナップショットを効率的に採取することが可能となる。
【００１７】
【発明の実施の形態】
以下、図面を参照してこの発明の実施形態について説明する。
【００１８】
（第１実施形態）
まず、この発明の第１実施形態について説明する。図１はこの実施形態に係るコンピュータシステムの構成を示す概念図である。このシステムは、スナップショットやバックアップが必要なアプリケーションプログラム１ａ〜１ｃ、これらのアプリケーションプログラム１ａ〜１ｃが使う既存のファイルシステム２、このファイルシステム２とディスク装置４との間に位置し、ディスクレベルのスナップショットを採取するディスク・スナップショット部３およびファイルシステム２のデータやディスク・スナップショット部３のデータを保持するディスク装置４から構成される。
【００１９】
これらアプリケーションプログラム１ａ〜１ｃ、ファイルシステム２およびディスク装置４は既存のコンピュータシステムと同じ任意の要素であり、従来のようにファイルシステム２がブロック木構造である必要はまったくない。また、ファイルシステム２は既存のものそのままであり、従来のようにスナップショット機能を持ったものである必要もない。すなわち、この発明の特徴となる構成要素はディスクスナップショット部３であるので、以下ではこのディスクスナップショット部３について説明する。
【００２０】
図２はこの実施形態のディスクスナップショット部３の構成を示す概念図である。図２に示すように、このディスクスナップショット部３は、ディスクスナップショット制御部５、揮発性メモリ６から構成される。この揮発性メモリ６内には、書き込みの時間的順序を維持するためのタイムスタンプ７、ディスク装置４に書き込むデータをログ構造化して保持する書き込みバッファ８、および書き込みバッファ８内の空き領域と保持されている書き込みデータの論理アドレスの情報とを保持するバッファ管理テーブル９が格納される。一方、ディスク装置４内には、通常のデータの他に、スナップショット情報（ＳＳ情報）１０が格納される。ディスクスナップショット制御部５は、これらタイムスタンプ７、書き込みバッファ８、バッファ管理テーブル９およびスナップショット情報１０を管理して、ディスク装置４への読み出し／書き込みおよびスナップショット情報の参照を制御する。
【００２１】
図３にこの揮発性メモリ６内の書き込みバッファ８とバッファ管理テーブル９との関係を示す。ディスクスナップショット制御部５は、ファイルシステム２からディスク装置４への書き込みを要求された書き込みデータを、すぐにディスク装置４に書き込むのではなく、ブロック単位に分割して書き込みバッファ８に順番に詰めて（ログ形式に）格納していく。このとき、その書き込みデータのファイルシステム２から見た論理アドレスを、バッファ管理テーブル９が格納したバッファ領域に対応するエントリに保存する。そして、そのエントリにデータが割り当てられたことを示すフラッグ“Ｆ”を立てる。よって、このバッファ管理テーブル９を調べることにより、ファイルシステム２から受け取った書き込みデータを格納すべき次のバッファ領域を決めることができる。図３では、バッファ領域Ｂ９まで書き込みデータが格納されており、Ｂ０、Ｂ１、〜、Ｂ９の論理アドレスが、ＬＡ１３４、ＬＡ９９、〜、ＬＡ６７８であることを表わしている。
【００２２】
また、ディスク装置４は、それぞれブロックサイズの整数倍（Ｋ）であるストライプと呼ぶ予め決められた単位（そのディスク装置の１トラック長に近いサイズが好ましい）で書き込みを行なう。また、実際のディスク装置４を合わせた全記憶容量よりも少ない容量のディスク装置としてファイルシステム２には見せている（ファイルシステムが最初に記憶容量を問い合わせて来たときに、実際よりも少ない容量を返す）。よって、ファイルシステム２から論理的に読み書きできる記憶領域の他に余分な記憶領域が確保されることになる。ここでは、この領域を空領域と呼ぶことにする（図４参照）。また、以下では、ファイルシステム２から見えるディスクスナップショット部３が提供する論理的なディスク領域を論理ディスク装置と呼ぶことにし、一方、ディスク装置４が実際に提供する物理的なディスク領域を物理ディスク装置と呼ぶことにする。
【００２３】
タイムスタンプ７は、ファイルシステム２からの書き込みデータが実際にディスク装置４に書き込まれるときに付加される情報であり、ディスク装置４内でのデータ書き込み順序を判定するのに用いられる。よって、書き込みバッファ８のデータがディスク装置４に書き込まれるごとにタイムスタンプ９がインクリメントされる。また、スナップショット情報１０は、スナップショット採取時点のタイムスタンプの値を保持する。
【００２４】
以下、この実施形態のコンピュータシステムにおける各処理の動作原理を詳細に説明する。
【００２５】
まず、この実施形態のコンピュータシステムにおける書き込み処理について説明する。アプリケーションプログラム１ａ〜１ｃがファイルシステム２上のファイルを書き込むと、ファイルシステム２は、対応する論理ディスク装置に対する書き込み要求に変換してディスクスナップショット部３に引き渡す。ディスクスナップショット制御部５は、ファイルシステム２から書き込むべきデータとその論理アドレスとを受け取り、揮発性メモリ６上の書き込みバッファ８の空領域にブロック単位に分割して詰めて格納する。また、受け取った論理ディスク装置のアドレス（以下論理アドレスと呼ぶ）は、ブロックごとのアドレスに変換してバッファ管理テーブル９の対応するエントリに格納する。なお、すでに書き込みバッファ８に絡納されているデータに対する更新データの場合には、書き込みバッファ８の空領域に詰めて格納するのではなく、直接書き込みバッファ８内の旧データを変更する。
【００２６】
そして、ディスクスナップショット制御部５は、ファイルシステム２から受け取った書き込みデータが１ストライプ分に１ブロック少ない数（Ｋ−１）だけ書き込みバッファ８に溜まった段階で、それらのデータをディスク装置４に書き込みにいく。このとき、ディスクスナップショット制御部５は、最後の書き込みブロックとして、書き込み管理テーブル７に格納された各ブロックの論理アドレスと揮発性メモリ６上のタイムスタンプとから論理アドレスタグブロックを作成する（この論理アドレスタグブロック内のアドレスデータとデータブロックとには１対１の関係が予め設定されており、各データブロックの論理アドレスが分かるようになっている）。その後、ディスクスナップショット制御部５は、この論理アドレスタグブロックを加えた１ストライプ分のデータをまとめてディスク装置４の空領域に同時に書き込む（図５参照）。また、タイムスタンプ５の値は、書き込みが完了した段階でインクリメントされる。
【００２７】
このように書かれたデータブロックの読み出し処理について説明する前に、まず無効ブロックの判定処理について説明する。
【００２８】
ここでは、図６に示す順番でファイルシステム２から１ブロックサイズのデータ書き込みがある場合を例に説明する。なお、図６中のＬｎはファイルシステム２から渡される論理アドレスを表し、Ｓｎは書き込み順番を表わす。また、この実施形態のコンピュータシステムでは、書き込みバッファ８は１５ブロック分のデータを保持できるものとする。この場合、最初のＳ１〜Ｓ１５の書き込みデータが１つのストライプ（ＳＴ１）にまとめられ、タイムスタンプＴＳ１が付加されてディスク装置４の空領域に書き出される。同様に、Ｓ１６〜Ｓ３０の書き込みデータが別のストライプ（ＳＴ２）にまとめられ、タイムスタンプＴＳ２が付加されて別の空領域に書き出される。なお、書き出しごとにタイムスタンプはインクリメントされるので、ＴＳ１とＴＳ２とはＴＳ１＜ＴＳ２の関係をもつ。
【００２９】
この図６から分かるように、論理アドレスＬ９、Ｌ１８のデータは、タイムスタンプＴＳ１のストライプではＳ５、Ｓ２のブロックとして、タイムスタンプＴＳ２のストライプではＳ１９、Ｓ２１のブロックとして重複して存在する。書き込まれた順番を考えると、Ｓ１９、Ｓ２１のデータブロックが有効であり、Ｓ５、Ｓ２のデータは無効と判定されなければならない。しかしながら、ここで便宜上使った書込み順番Ｓｎは、実際のディスク装置４上には記録されていない。
【００３０】
そこで、この実施形態のコンピュータシステムでは、ストライプ内の論理アドレスタグを使ってこの判定を行なう。図６の例における２つのストライプＳＴ１、ＳＴ２の論理アドレスタグＴＧ１、ＴＧ２の内容は図７に示す通りである。図７から分かるように、２つの論理アドレスタグＴＧ１、ＴＧ２に同じ論理アドレスＬ９、Ｌ１８のデータが含まれており、ストライプＳＴ１のブロックＢ５、Ｂ２と、ストライプＳＴ２のブロックＢ４、Ｂ６とのどちらかのデータが無効である。さらに、論理アドレスタグＴＧ１のタイムスタンプＴＳ１と論理アドレスタグＴＧ２のタイムスタンプＴＳ２を比較すると、ＴＳ１＜ＴＳ２であることからストライプＳＴ１のブロックＢ５、Ｂ２が無効であることが判定できる。以上のように、ディスク装置４内の論理アドレスタグを調べることにより、無効なデータブロックを見つけることができる。
【００３１】
次に、この実施形態のコンピュータシステムにおけるデータブロックの読み出し処理について説明する。原理的には、先に述べた無効ブロック判定の処理をディスク装置４内の全ストライプの論理アドレスタグに対して行ない、結果として残る読み出し要求のあった論理アドレスに対する有効ブロックの物理的位置を検出する。
【００３２】
しかしながら、読み出し要求がくる度にこの処理を行なっているのでは、ブロック読み出しに膨大な時間がかかってしまい実用的ではない。そこで、システム起動時にだけ全ストライプの論理アドレスタグの調査を行ない、揮発性メモリ６上に論理アドレスから物理アドレスへの変換マップを作る。ファイルシステム２からの読み出し要求に対しては、この変換マップを使って有効ブロックへのアクセスを行なう。これにより、常にアドレスタグの調査をしなくても良く、読み出し時に性能が大きく低下することはない。この変換マップについて図８を参照して説明する。図８に示すように、変換マップは各論理アドレスに対するブロックが格納されているストライプ番号ＳＴ＃、そのストライプ内のブロック番号ＢＬＫ＃、およびそのタイムスタンプＴＳ＃をテーブル形式で保持している。よって、論理アドレスが与えられれば、このテーブルを引くことにより、ＳＴ＃とＢＬＫ＃とから簡単に実際の物理アドレスが求まる。
【００３３】
また、システム起動時の変換マップの作成は、調査した論理アドレスタグの全論理アドレスについて、テーブルのタイムスタンプより論理アドレスタグのタイムスタンプが大きいときだけ、そのストライプ番号と対応するブロック番号をテーブルに登録する。この調査を全ストライプについて行なえば、有効ブロックだけを指す変換マップができあがる。さらに、ディスク装置４にストライプを書き込むごとに、その論理アドレスタグに対して同様の処理を行なうことにより、この変換マップは常に有効なブロックを指す。このようにして、ディスク装置４上の物理ブロックの有効／無効の判定を行ない変換マップが作られる。
【００３４】
次に、この実施形態のコンピュータシステムにおけるスナップショットの採取処理について説明する。アプリケーションプログラム１ａ〜１ｃやシステム管理者からのスナップショット採取の指示を受けると、ディスクスナップショット制御部５は書き込みバッファ８にその時点で溜まっているデータをディスク装置４に書き込みにいく。ただし、通常の書き込みのように、書き込みバッファ８内に１ストライプ分に１ブロック少ない数（Ｋ−１）のデータブロックが溜まっているとは限らないので、まだ埋まっていない部分に対応する書き込み管理テーブル７には無効であることを示すヌルアドレスを格納する。そして、通常の書き込みと同様に、最後の書き込みブロックとして、書き込み管理テーブル７に格納された各ブロックの論理アドレス（ヌルアドレスを含む）と揮発性メモリ６上のタイムスタンプとから論理アドレスタグブロックを作成する。その後、この論理アドレスタグブロックを加えた１ストライプ分のデータをまとめてディスク装置４の空領域に同時に書込む（図９参照）。さらに、このときに付加したタイムスタンプの値をスナップショット採取時の情報として、ディスク装置４内のスナップショット情報１０に書き込む。そして、タイムスタンプ７の値は、書き込みが完了した段階でインクリメントされる。このように、スナップショット採取には書き込みバッファ８に溜まっていたブロックとスナップショット情報１０とをディスクに書き込むだけの時間しかかからない（その他の処理は非常に短い）ので、従来と同様にアプリケーションプログラム１ａ〜１ｃを停止させることなくスナップショットが作成できる。
【００３５】
次に、図１０を参照してこの実施形態のコンピュータシステムにおけるスナップショットの参照処理について説明する。まず、先にブロック読み出し処理で述べた無効ブロック判定の処理を、ディスク装置４内のタイムスタンプ値がスナップショット情報１０の値よりも小さいストライプの論理アドレスタグに対して行ない、全論理アドレスに対する有効ブロックの物理的位置を検出する。読み出し処理では、全ストライプが対象だったが、このスナップショット参照処理では、スナップショット情報１０のタイムスタンプ値までに書き込まれたストライプだけを対象にする点が異なる。つまり、図１０のディスク状態では、ストライプＳＴ１〜ＳＴ４がブロック読み出しの無効ブロック判定の対象となるが、スナップショット参照処理では、ストライプＳＴ１〜ＳＴ３が無効ブロック判定の対象になる。
【００３６】
また、毎回無効ブロックの判定を行なっていたのでは、スナップショット参照に膨大な時間がかかってしまい実用的ではない。そこで、先の読み出し処理と同様に、最初にスナップショットを参照するときに対象となるストライプの論理アドレスタグの調査を行ない、揮発性メモリ６上に論理アドレスから物理アドレスへのスナップショット用変換マップを作る。図１１に、ディスク状態が図１０である場合のスナップショット用変換マップと読み出し用変換マップとの様子を示す（簡単化のためタイムスタンプのフィールドは省略した）。図１１からわかるように、スナップショット採取後に更新された論理アドレスＬ３、Ｌ７、Ｌ９、〜、Ｌ２５、Ｌ２７のブロックも、スナップショット用変換マップ（図１１（ａ））からは更新前のブロックが参照できるようになっている。また、読み出し用変換マップ（図１１（ｂ））は常に最新のブロックを指している。このように、無効ブロック判定処理の対象とするストライプを変えることにより、スナップショット参照用と読み出し用の変換マップとが作成できる。
【００３７】
なお、スナップショット採取時のディスクイメージは、ディスクスナップショット部３経由で参照することができるが、その中のファイルを直接参照することはできない。そこで、図１２に示すように、ディスクスナップショット部３にスナップショット採取時のディスクイメージを別の擬似ディスクとして見せる擬似ディスク機能をもたせる。一般にオペレーティングシステムは、起動フェーズで検出したディスクに格納されているデータがどのファイルシステムのものか検出し、対応するファイルシステムを構築する機能を持っている。よって、この擬似ディスクを検出したオペレーティングシステムは、その上にスナップショット参照用ファイルシステム１１を構築して、スナップショッ卜参照用ユーティリティプログラム１２がスナップショット採取時のファイルをアクセスできるようにする。このスナップショッ卜参照用ユーティリティプログラム１２としては、たとえば、特定ファイルを磁気テープにバックアップするプログラムなどが考えられる。なお、この擬似ディスク機能は、ＲＡＭディスクなどのハードウェアデバイスをもたないソフトウェアドライバとして実装すれば良いため、その実装は容易である。
【００３８】
（第２実施形態）
次に、この発明の第２実施形態を説明する。
【００３９】
前述の第１実施形態のコンピュータシステムにおけるスナップショット採取処理では、ファイルシステム２が更新データをキャッシュする機能をもたないことを想定していた。つまり、アプリケーションプログラム１ａ〜１ｃによるファイルの変更は、すぐにディスク装置４に書き出されるものと考えていた。よって、スナップショッ卜採取時には、それまでに書き込みバッファ８に溜まっていた書き込みデータをディスク装置４に書き出すだけで、正しいファイルシステム２の状態がディスク装置４に保存できた。しかしながら、たとえばＵＮＩＸのファイルシステムなど、更新データをキャッシュする機能をもったファイルシステムも今日では広く使われている。この場合、先のスナップショット採取処理では、キャッシュされていた更新データが失われてしまうので、正しいスナップショットが採取できない。
【００４０】
そこで、この第２実施形態のコンピュータシステムでは、ファイルシステム２が更新データをキャッシュする機能を有する場合のスナップショット採取を説明する。
【００４１】
一般に、更新データをキャッシュするファイルシステムでは、アプリケーションプログラムにより行なわれたファイル変更が確実にディスク装置に記録され残ることを保証できるように、アプリケーションプログラムからの指示によりキャッシュしている更新データをすべて書き戻す機能をもっている。そこで、この第２実施形態のディスクスナップショット部３では、アプリケーションプログラム１ａ〜１ｃからの書き出し前指示と書き出し後指示とを受け付け、これらの間にファイルシステム２からの書き出しが無い場合にだけ、先に述べたスナップショット採取処理を行なう条件付き採取機能を備える。
【００４２】
そして、このディスクスナップショット部３が備える機能を利用して、更新データがすべて書き戻された状態のスナップショットを、図１３のフローチャートで示される手順を含んだアプリケーションプログラム１ａ〜１ｃの指示に応じて採取する。アプリケーションプログラム１ａ〜１ｃは、まず、ディスクスナップショット部３に書き出し前指示を発行してこれからファイルシステム２の書き戻しを行なうことを指示する（ステップＡ１）。次に、キャッシュされている全更新データをディスク装置４に書き戻すようにファイルシステム２に指示する（ステップＡ２）。この指示を受けたファイルシステム２は、全更新データの書き戻しを実行し、その実行が完了したときに、その旨をアプリケーションプログラム１ａ〜１ｃに通知する。一方、アプリケーションプログラム１ａ〜１ｃでは、この書き戻しが完了した旨の通知をファイルシステム２から受け取ったときに、ディスクスナップショット部３に書き出し後指示を発行する（ステップＡ３）。
【００４３】
そして、この指示を受けたディスクスナップショット部３は、書き出し前指示から書き出し後指示までの間にファイルシステム２からの書き出しが無い場合にだけ、先に述べたスナップショット採取処理を行なう。ディスクスナップショット部３は、スナップショットを採取したか否かを書き出し後指示の応答としてアプリケーションプログラム１ａ〜１ｃに返す。一方、アプリケーションプログラム１ａ〜１ｃは、ディスクスナップショット部３がスナップショットを採取しなかった場合には（ステップＡ４のＮＯ）、最初からこれまでの処理を繰り返し（ステップＡ１〜ステップＡ３）、採取した場合に（ステップＡ４のＹＥＳ）、この処理を終了する。
【００４４】
以上の処理により、ファイルシステム２ヘ書き戻しを指示してもディスク装置４へ書き出すベきデータが無かったこと、すなわち、ディスク装置４上にはすでに正しいファイルシステム２の状態が保存されていることが保証される。したがって、ディスクスナップショット部３で正しいスナップショットが採取できることになる。たとえば、ただ単にファイルシステム２に書き戻し指示をするとともにディスクスナップショット部３にスナップショット採取を指示したのでは、この２つの指示の間にファイル更新が行なわれた場合に、一部の更新データがキャッシュに残ってしまうため、正しいスナップショットが採取できない危険性がある。よって、ここで述べた手順が必要になる。
【００４５】
（第３実施形態）
次に、この発明の第３実施形態を説明する。
【００４６】
前述の第１実施形態のコンピュータシステムでは、スナップショットは１つしか採取できなかったが、この第３実施形態のコンピュータシステムでは、複数のスナップショットを採取する。
【００４７】
まず、先の第１実施形態と異なるのは、図１４に示すように、ディスク装置４上のスナップショット情報１０が、複数のスナップショットそれぞれのタイムスタンプを保持する構造となっていることである。
【００４８】
そして、スナップショット採取処理においては、その時点で溜まっていたデータを書き込みにいく点は同じであるが、書き込んだストライプのタイムスタンプ値を、そのスナップショット（ＳＳ）のスナップショッ卜情報１０としてディスク装置４に保存する。たとえば、図１４のストライプ３（ＳＴ３）をスナップショットの採取処理で書き込む場合には、そのタイムスタンプ値ＴＳ３をスナップショット１（ＳＳ１）のスナップショット情報１０として保存する。同様に、ストライプ５（ＳＴ５）のスナップショット採取処理では、そのタイムスタンプ値ＴＳ５をスナップショット２（ＳＳ２）のスナップショット情報１０として保存し、ストライプ８（ＳＴ８）のスナップショット採取処理では、そのタイムスタンプ値ＴＳ８をスナップショット３（ＳＳ３）のスナップショット情報１０として保存する。
【００４９】
また、スナップショット参照処理においては、図１４に示すように、参照するスナップショットによって対象となるストライプが異なるだけで基本的処理は同じである。たとえば、スナップショット２（ＳＳ２）を参照する場合には、スナップショット情報１０のタイムスタンプ値ＴＳ５から、ＳＴ１〜ＳＴ５が対象となるストライプであることが分かる。そこで、ＳＴ１〜ＳＴ５のストライプだけを調べて、無効ブロックの判定処理とスナップショット参照用変換マップの作成処理とを実行する。そして、ＳＳ２のスナップショッ卜を参照する場合には、この変換マップを参照してスナップショット採取時のデータをアクセスする。同様に、ＳＳ１、ＳＳ３のスナップショットを参照する場合には、そのタイムスタンプ値ＴＳ３、ＴＳ８から対象となるストライプがＳＴ１〜ＳＴ３、ＳＴ１〜ＳＴ８であることが分かり、それらの対象となるストライプに対してだけ無効ブロックの判定処理とスナップショット参照用変換マップの作成処理とを実行し、その変換マップを使ってそれぞれのスナップショットが採取されたときのデータをアクセスする。
【００５０】
このように、スナップショット情報１０として複数のタイムスタンプ値を保存できるようにするだけで、複数のスナップショットを取り扱えるようになる。
【００５１】
次に、ディスクスナップショット部３が採取した複数のスナップショットをスナップショッ卜参照用ユーティリティプログラム１２からアクセスする方法を説明する。
【００５２】
第１の方法としては、図１５に示すように、ディスクスナップショット部３を拡張し、採取したスナップショッ卜ごとに対応する擬似ディスク装置１３ａ〜１３ｃを見せる機能をもたせて、それぞれの擬似ディスク装置１３ａ〜１３ｃの上にスナップショット参照用ファイルシステム１１ａ〜１１ｃを構築する。そして、それぞれのスナップショッ卜をアクセスするスナップショット参照用ユーティリティプログラム１２は、対応するスナップショット参照用ファイルシステム１１ａ〜１１ｃを経由して、スナップショット採取時のアクセスを行なう。しかしながら、この方法では、スナップショット数が増えると擬似ディスクも増えてしまう。たとえばマイクロソフト社のＷｉｎｄｏｗｓなどのように、プログラムから見えるディスク台数に上限があるオペレーティングシステムも多い。したがって、擬似ディスク装置１３ａ〜１３ｃが増えてしまうこの方法では、この制限のために適用できない場合も多くなる。また、プログラムから見えるディスク台数が多いとコンピュータシステムそのものの管理も大変である。
【００５３】
そこで、第２の方法としては、図１６に示すように、ディスクスナップショット部３にスナップショット用として擬似リムーバブルディスク１３を見せる機能をもたせて、各スナップショットはその擬似リムーバブルディスク用の擬似メディアとして取り扱う。この方法では、擬似ディスク装置１３が１台しか要らないので、第１の方法のような問題は発生しない。なお、この方法では、複数のスナップショットを同時にアクセスできないが、同時にスナップショットへのアクセスが必要なケースは少ないので、大きな問題にはならないと思われる。また、それぞれのスナップショットの必要なファイルを最新のディスクイメージにコピーすれば、同時アクセスが可能となるので大きな制限ではない。
【００５４】
また、通常、リムーバブルディスクをサポートするオペレーティングシステムでは、メディアを変更するとそれに合わせてファイルシステムの再構築などが自動的に行なわれる。そこで、スナップショットをＳＳ１からＳＳ２へ切り替えるときには、まず、この擬似リムーバブルディスク１３からメディアが変更された旨の情報をスナップショット参照用ファイルシステム１１やオペレーティングシステムに通知する。すると、オペレーティングシステムは、変更されたメディアをアクセスするために、これまでアクセスしていたスナップショットＳＳ１に対するスナップショット参照用ファイルシステム１１を終了し、変更されたメディアに対するスナップショット参照用ファイルシステム１１を起動する。この新しく起動されたスナップショット参照用ファイルシステム１１からのアクセスに対して、ディスクスナップショット部３の擬似リムーバブルディスクは、スナップショットＳＳ２のディスクイメージを返すことにより、スナップショット参照用ユーティリティプログラム１２は、ススナップショットＳＳ２のファイルをアクセスできるようになる、なお、ディスク（擬似ディスクを含む）がリムーバブルか否かの情報は、システム起動時などにオペレーティングシステムが問い合わせてくるので、このときに、リムーバブルである旨をディスクスナップショット部３がオペレーティングシステムに伝えればよい。
【００５５】
以上をまとめると、スナップショットを格納するディスクを擬似リムーバブルディスクとして扱うためにディスクスナップショット部３が行なうことは、
（１）システム起動時などでのオペレーティングシステムからの問い合わせにリムーバブルである旨の情報を返す。
【００５６】
（２）ユーザやアプリケーションプログラムからのスナップショット切り替え指示を受け付ける。
【００５７】
（３）このスナップショット切り替え指示に対して、メディアが変更された旨の情報をファイルシステムやオペレーティングシステムに通知する。
【００５８】
（４）オペレーティングシステムやファイルシステムからの変更されたメディアへのアクセスに対しては、ユーザやアプリケーションプログラムから指定されたスナップショットのイメージをアクセスできるようにする。
【００５９】
となる。
【００６０】
しかしながら、この第１および第２の方法では、オペレーティングシステムやスナップショッ卜参照用ユーティリティプログラム１２を含む各種プログラムから見える、スナップショットを採取したときのディスク装置とスナップショットを参照する場合のディスク装置とが異なってしまう。たとえば、図１５の場合、Ｗｉｎｄｏｗｓなどのオペレーティングシステムからは、ディスク装置４は“Ｃ：”ドライブ、ＳＳ１の擬似ディスクは“Ｄ：”ドライブなどとして見えてしまう。よって、環境変数などで各種プログラムが使うべきファイル名として、“Ｃ：”ドライブのＡファイルとあったとしても、スナップショット参照時には、“Ｄ：”ドライブのＡファイルとしなければ、各種プログラムは正しく動作しない。同様に、スナップショットのファイルの中にある処理に関連するファイル名として“Ｃ：”ドライブのＢファイルとあったとしても、スナップショットの参照時には、“Ｄ：”ドライブのＢファイルとしなければ、各種プログラムは正しく動作しない。
【００６１】
以上のように、オペレーティングシステムや各種プログラムから見えるディスク装置が異なってしまうと、環境変数やファイル内容をそれに合わせて変更しないとプログラムが正しく動作しない場合も多い。一般に、どのファイルや環境変数を変更すればよいか判っておらず、スナップショットを参照する度に変更するのは大変な作業である。
【００６２】
そこで、第３の方法として、図１７に示すように、ディスクスナップショット部３にディスク装置４がリムーバブル機能をもつようにオペレーティングシステム、ファイルシステムおよび各種プログラムに見せるリムーバブル化機能を設け、最新のディスクイメージと複数のスナップショットとをそれぞれ別の擬似メディアとして取り扱う。この方法では、スナップショット採取時の最新ディスクイメージとスナップショットのイメージとは擬似メディアが異なるだけであるので、オペレーティングシステムや各種プログラムなどから見えるディスク装置は同じであり、第１および第２の方法のような問題は発生しない。なお、この方法では、最新のディスクイメージとスナップショットとを同時にアクセスできなくなるが、ディスクやファイル名を意識するようなプログラムはもともと複数同時には実行できないので問題はないと思われる。
【００６３】
先に述べたように、ディスク装置（擬似ディスクを含む）がリムーバブルか否かの情報は、システム起動時などにオペレーティングシステムが問い合わせてくるので、ディスク装置４をリムーバブル化するには、このオペレーティングシステムからディスク装置４への問い合わせを途中で獲得して、リムーバブルである旨の情報を返せばよい。また、最新ディスクイメージやスナップショットを切替えるときには、第２の方法で述べたメディア変更の手順を行えばよい。
【００６４】
ここで、システムディスクのスナップショット参照について考える。システムディスクのスナップショットイメージでオペレーティングシステムを起動できれば、スナップショットを採取した時点の過去のオペレーティングシステム状態をそのまま再現でき、トラブル対応などで非常に役に立つ。しかし、システムディスクとは、オペレーティングシステムが実行するのに必要なオペレーティングシステムコード、デバイスドライバ、スワップファイルなどを格納するディスクであって、システム実行中は常にアクセスできなければならない。よって、システム実行中にアクセスできなくなるリムーバブルディスクにはできず、第２および第３の方法を適用することはできない。また、システムディスクは“Ｃ：”ドライブなど決まっている場合も多く、オペレーティングシステムから見えるディスクが異なってしまう第１および２の方法も適用できない。
【００６５】
そこで、第４の方法として、図１８に示すように、システム起動時に選択されたスナップショットを最新のディスク装置４のイメージの代わりにオペレーティングシステムやファイルシステムに見せるイメージ選択機能をディスクスナップショット部３に設け、任意のスナップショットをシステム起動時に選択できるようにする。選択したディスクイメージは、システム実行中には替わらないのでアクセスできなくなることはない。また、オペレーティングシステムやアプリケーションプログラムから見えるドライブは、スナップショットを採取したときと同じであるので、システムディスクが“Ｃ：”ドライブなどに予め決まっていても問題がない。
【００６６】
図１９に、この方法におけるコンピュータシステムの運用例を示す。通常のアプリケーションプログラムを実行する場合は、システム起動時にディスクスナップショット部３のイメージ選択機能により最新のディスクイメージをユーザなどが選択して起動処理を行なう。これにより、最新のディスクイメージに対応した最新のファイルシステムが構築され、通常のアプリケーションを実行できるようになる（Ｔ１）。ここで、スナップショットＳＳ１用のアプリケーションを実行するには、一旦、現在実行中のシステムを終了してシステムを再起動する。そして、この再起動時に、ディスクスナップショット部３のイメージ選択機能によりスナップショットＳＳ１をディスクイメージとしてユ−ザなどが選択する。これにより、スナップショットＳＳ１に対応したＳＳ１用のファイルシステムが構築され、スナップショットＳＳ１のファイルをアクセスするアプリケーションプログラムを実行できるようになる（Ｔ２）。さらに、通常のアプリケーションプログラムをを実行するには、システムを再起動して、再起動時に最新のディスクイメージを選択するようにする。
【００６７】
なお、図１９ではユーザなどがイメージを選択するのはシステム起動時だけであったが、ディスクスナップショット部３に次回のシステム起動時に選択すべきイメージを記録する次回記録機能を持たせて、イメージ選択機能はこの次回記録機能に記録されたイメージを選択するようにもできる。これにより、システム起動時以外でも、ユーザなどだけでなくアプリケーション（たとえばＴ１期間に実行されるアプリケーションプログラム）からでもイメージを選択できるようになる。この次回記録機能は、ディスク装置４の予め決めた場所に選択すべきイメージを保存しておき、システム起動時にこの情報を読み出してイメージ選択機能に教えるだけの簡単なプログラムで実現できる。
【００６８】
最後に、アプリケーションプログラムからスナップショットをアクセスするこれら第１乃至第４の方法は、それぞれ排他的に適用されるのではなく、任意に組み合わせて適用することも可能である。
【００６９】
ところで、これまでスナップショットの識別情報としては、ＳＳ１〜ＳＳ３を使っていたが、これだけではいつの時点のスナップショットか分かりにくく、一旦スナップショッ卜を参照してから別のスナップショットを参照すべきことが判明する場合も多い。そこで、図１４に示すように、スナップショット情報１０としてスナップショットを採取した日時を保存するフィールドを用意し、ディスクスナップショット部３がスナップショット採取時のタイムスタンプだけでなく、日時もスナップショット情報に記録するようにする。そして、この日時をスナップショットに対応した擬似ディスクや擬似メディアの識別情報として用いることにより、いつの時点のスナップショットかすぐに分かり、効率のよいスナップショッ卜の運用が可能になる。
【００７０】
（第４実施形態）
次に、この発明の第４実施形態を説明する。
【００７１】
これまでに述べた実施形態では、一度採取したスナップショットは参照だけで変更しないことを前提に説明してきた。よって、図２０（ａ）に示すように、各スナップショットは採取された時間順に一直線に並んでおり一番先頭が最新のディスクイメージとなる順序関係があった。しかしながら、先に述べたシステムディスクのスナップショットの場合、オペレーティングシステム起動途中やオペレーティングシステム実行中にファイルの作成、変更、削除などが行なわれ、また、グループウェアやＤＢＭＳなどのアプリケーションプログラムからスナップショットのファイルをアクセスする場合も、アプリケーションプログラムが実行中である旨の情報などがファイルに書き込まれる。しかも、古いスナップショットの状態から起動したシステムを使って次にスナップショットを採取しても、それは古いスナップショットに戻る前の最新イメージＫとも異なる。このような揚合、戻る前の最新イメージＫも参照したくなる場合があると考えられる。つまり、図２０（ｂ）に示すように、スナップショットＳＳ１、ＳＳ２、ＳＳ３の順番でスナップショットを採取した後で、ＳＳ２のスナップショット時点から再起動したシステムでは、ＳＳ３への変更とは全く異なる変更を行ない、さらにそれに対するスナップショットＳＳ４を採取するなどができなければならない。また、図２０（ｂ）に示すように、複数の最新ディスクイメージを並行してアクセスできる必要もある。
【００７２】
以下ではスナップショットの変更方法について説明する。
【００７３】
まず、スナップショットの変更を可能にするには、図２１に示すように、ディスク装置４上のスナップショット情報として、親となるスナップショット情報（親ＳＳ）と、親ＳＳからそのスナップショットまでに書き出されたストライプのタイムスタンプを保存するようにする。たとえば、図１４のスナップショットＳＳ３は、その基となったスナップショットはＳＳ２であるので、スナップショット情報の親ＳＳとしてＳＳ２を保存する。また、ＳＳ２からＳＳ３への間に書き出されたストライプのタイムスタンプは、ＴＳ６〜ＴＳ８であるので、スナップショッ卜情報のタイムスタンプとしてＴＳ６〜ＴＳ８を保存する。また、複数の最新ディスクイメージを実現するため、スナップショット情報と同様に、親ＳＳとその親ＳＳからその最新イメージまでに書き出されたストライプのタイムスタンプとを最新イメージ（ＮＩ）情報としてディスク装置４上に保存する。
【００７４】
ここで、図２０（ａ）の状態から図２０（ｂ）のように、スナップショットＳＳ２を変更してスナップショットＳＳ４を作成する場合を考える。まず、先に述べた擬似ディスクなどを使ってＳＳ２の参照を行なう。そして、オペレーティングシステムやアプリケーションプログラムがこのスナップショッ卜ＳＳ２を更新し、それに対する書き込みブロックがディスクスナップショット部３に到着した段階で、ディスクスナップショット部３はＳＳ３の先にある最新イメージＮＩ１への追加的更新でないので、最新イメージ情報として最新イメージＮＩ２を作成する。（親ＳＳはＳＳ２であるので、この情報がＮＩ２の親ＳＳとして保存される。）さらに、通常のディスクスナップショット部３の書き込み動作と同じように、メモリ６上の書き込みバッファ８にこの書き込みブロックを順次溜め、書き込みデータが１ストライプ分に１ブロック少ない数（Ｋ−１）だけ書込みバッファ８に溜まった段階で、ディスク装置４に書き込みにいく。最後の書き込みブロックとして、各ブロックの論理アドレスとタイムスタンプとから論理アドレスタグブロックを作成するのも同じである。なお、通常の最新イメージＮＩ１とＳＳ２の更新とを同時に行なう場合には、スナップショット変更用に別の書き込みバッファ８を用意して、それぞれ別々に溜める。そして、ディスク装置４に書き込んだストライプＳＴ１０のタイムスタンプＴＳ１０１を最新イメージＮＩ２のタイムスタンプとして記録する（図２１参照）。
【００７５】
ＳＳ２の変更が進んでスナップショットＳＳ４を採取する処理も前述のスナップショット採取処理と同じである。つまり、まだ埋まっていない部分に対応する書き込み管理テーブル９にヌルアドレスを格納して、書き込みバッファ８にその時点で溜まっているデータをディスク装置４に書き込みにいく。そして、最新イメージＮＩ２の情報（親ＳＳがＳＳ２、タイムスタンプがＴＳ１０１）とこのときに付加したタイムスタンプの値ＴＳ１０２とから、スナップショットＳＳ４のスナップショット情報として、親ＳＳとしてＳＳ２、タイムスタンプとしてＴＳ１０１〜ＴＳ１０２をディスク装置４へ書き込む。そして、タイムスタンプの値は書き込みが完了した段階でインクリメントされる。また、最新イメージＮＩ２の最新イメージ情報は、親ＳＳとして新しく作成したＳＳ４が保存され、タイムスタンプはクリアされる。
【００７６】
さらに、このスナップショットＳＳ４が更新されストライプＳＴ１３がディスク装置に書き出された場合は、最新イメージＮＩ２のタイムスタンプ情報にはＴＳ１０３が保存される。
【００７７】
次に、スナップショットを変更する場合の最新イメージやスナップショットの参照処理について説明する。たとえば、ディスク装置４が図２１の状態であるときに、スナップショットＳＳ４を参照する場合を考える。このＳＳ４は、ＳＳ２を元に変更を加えたスナップショットであるので、参照時の変換マップ作成の対象とすべきストライプはＳＳ２対象のＳＴ１〜ＳＴ５とＳＳ２からＳＳ４への変更分のＳＴ１０〜ＳＴ１１とでなければならない。そこで、これらのストライプを以下の手順で見つける。
【００７８】
まず、スナップショット情報を使って、ＳＳ４の親ＳＳがＳＳ２であることとＳＳ２からＳＳ４への更新データを書き出したストライプのタイムスタンプがＴＳ１０１〜ＴＳ１０２であることを知る。次に、スナップショット情報１０を使って、ＳＳ２の親ＳＳがＳＳ１であることとＳＳ１からＳＳ２への更新データを書き出したストライプのタイムスタンプがＴＳ４〜ＴＳ５であることを知る。この処理を親ＳＳが無くなるまで繰り返すことにより、スナップショットＳＳ４までに書き出されたストライプのタイムスタンプが、ＴＳ１〜ＴＳ３、ＴＳ４〜ＴＳ５、ＴＳ１０１〜ＴＳ１０２であることが分かる。
【００７９】
よって、ディスク上の各ストライプのタイムスタンプを比較することにより、ＳＳ４参照時の対象ストライプであるＳＴ１〜ＳＴ５とＳＴ１０〜ＳＴ１１とを見つけられる。なお、先に説明した実施形態では、最新ディスクイメージを読み出す場合には、ディスク装置上の全ストライプを対象に変換マップを作成すれば良かったが、ストライプの変更が可能な場合には、最新イメージ情報とスナップショット情報とを使い、スナップショット参照と同様の処理を行なって対象とすべきストライプのタイムスタンプを求める。
【００８０】
なお、前述のスナップショット変更処理の説明では、ストライプを書き込む度に最新イメ一ジ（ＮＩ）情報のタイムスタンプ情報を変更していた。また、スナップショット情報や最新イメージ情報のタイムスタンプ情報などは、図２１に示すように、区間情報の方が扱い易い。そこで、最新イメージ（ＮＩ）を作成するときに、書き出す際に用いるタイムスタンプ値を予め予約しておき、ディスク装置にタイムスタンプ（ＴＳ）情報として保存しておく方法が考えられる（図２１参照）。これにより、ストライプを書き出す度に最新イメージ情報のタイムスタンプを更新しなくても、ディスク上の全ストライプのタイムスタンプを調べることによって、この情報を再現できる。たとえば、ストライプＳＴ１３を書き出したときに最新イメージＮＩ２のタイムスタンプを更新しなくても、最新イメージＮＩ２のタイムスタンプはＴＳ１０１〜ＴＳ２００が割り当てられることと、ディスク装置４上のストライプでこの区間に入る最大のタイムスタンプはＴＳ１０３であることから、ＮＩ２のタイムスタンプは最後がＴＳ１０３であることが分かる。また、予めタイムスタンプ値を最新イメージごとに分けているので、スナップショット情報やＮＩ情報のタイムスタンプ値は必ず区間情報になる。
【００８１】
ここで、図２２を参照してスナップショットの削除について考える。スナップショットの変更を許さない場合、図２２（ａ）のようにスナップショットＳＳ２を削除するにはスナップショット情報のスナップショットＳＳ２に関する情報を削除するだけで良く、特別な処理を必要としない。しかしながら、スナップショットの更新が可能な場合には、スナップショットの削除処理はもっと複雑になる。まず、スナップショット情報や最新イメージ情報には親ＳＳを含む。よって、親ＳＳが削除された場合には、削除された親ＳＳの親ＳＳをスナップショット情報や最新イメージ情報の親ＳＳにする必要がある。また、スナップショット情報や最新イメージ情報のタイムスタンプは、削除された親ＳＳのタイムスタンプも含むように修正する必要がある。
【００８２】
さらに、図２１のディスク状態で図２２（ｂ）のようにスナップショットＳＳ３と最新イメージＮＩ１とを削除する場合には、図２３に示すように、スナップショット情報とＮＩ情報とを削除するだけでなく、削除ストライプ情報（ＤＥＬ情報）としてスナップショットＳＳ３と最新イメージＮＩ１のタイムスタンプとをディスク装置４上に保存して、これらのタイムスタンプを使わないようにする必更がある。
【００８３】
（第５実施形態）
次に、この発明の第５実施形態を説明する。
【００８４】
これまで述べた実施形態におけるスナップショット採取処理では、その時点で溜まっていた更新データだけで１つのストライプを構成しディスク装置を書き出していたので、スナップショット採取時のストライプには更新データが無く無駄である領域が出でしまう。したがって、スナップショット採取の頻度が多い場合には、ディスク装置４上に無駄な領域が増えてしまう。
【００８５】
そこで、スナップショット採取処理は先の場合と同じで、まだ埋まっていない部分に対応する書き込み管理テーブル９にヌルアドレスを格納し、書き込みバッファにその時点で溜まっているデータにタイムスタンプを付けてディスク装置４に書き込みに行く。このとき、スナップショット情報としては、図２４に示すように、タイムスタンプ値だけでなく、スナップショット採取時に溜まっていたストライプ内のブロック番号も保存する。
【００８６】
そして、スナップショット採取直後の書き込み処理において、書き込みバッファ８やバッファ管理テーブル９をクリアすることなく、更新データを続けて書き込みバッファ８に格納する。そして、この書き込みバッファ８が１ストライプ分に１ブロック少ない数（Ｋ−１）だけ溜まった段階で、論理アドレスタグブロックを作成し、ディスク装置４に書き出す。このとき、論理アドレスタグブロックのタイムスタンプには、スナップショット採取時の値を、書き出すディスク装置４の位置は、スナップショット採取と同じストライプに上書きする。（図２４のＳＴ３）
このように採取したスナップショットの参照処理では、スナップショット情報のタイムスタンプ値とタイムスタンプが一致するストライプについては、スナップショット情報のブロックまでをそのスナップショットの対象として変換マップ作成時の無効ブロックの判定を行なう。つまり、図２４の場合には、ストライプＳＴ３についてはブロックＢ１〜Ｂ６がスナップショットの対象となるブロックとする。
【００８７】
スナップショット採取直後の書き出し処理とスナップショット参照処理とにおいて、以上のように処理することにより、スナップショットのストライプにも無駄な領域を作らないでスナップショット採取することができる。
【００８８】
（第６実施形態）
次に、この発明の第６実施形態を説明する。
【００８９】
これまで述べた実施形態においてディスクスナップショット部３として採用している、更新前データの領域を書き換えるのではなく、更新データを溜めておいてディスク装置内の予め用意された別の空領域にまとめて書き込む方法では、空領域が常に存在することが必須である。そのため、ファイルシステム２からのディスクアクセスが空いている間に、すでに他の領域にデータが書き込まれて無効になっているデータを寄せ集めて空領域を作る必要がある。ここでは、この処理を詰替え処理と呼ぶものとする。この詰替え処理は、先に述べた無効ブロック判定とストライプ統合との２つのステップからなる。ここで、無効ブロックとは、スナップショット参照としても、通常の読み出しとしてもアクセスされないブロックのことである。つまり、スナップショット参照用変換マップおよび読み出し用変換マップのいずれからも指されていないブロックが無効ブロックである。
【００９０】
ストライプ統合の例として、図２５に示すように２つのストライプＳＴ１、ＳＴ３を１つのストライプＳＴ１０に統合する場合を考える。図２５に示すように、ストライプＳＴ１では、Ｂ２、Ｂ７、Ｂ８、Ｂ１２、Ｂ１３の５ブロックが有効であり、他の１０ブロックは無効であるとする。同様に、ストライプＳＴ３では、ブロックＢ１８、Ｂ１９、Ｂ２０、Ｂ２１、Ｂ２２、Ｂ２４、Ｂ２５、Ｂ２７、Ｂ２９の９ブロックが有効であり、他の６ブロックが無効であるとする。この２つのストライプの有効ブロックは、合わせて１４ブロックしかないので、この２つのブロックを１つに統合することにより、結果として１つの空領域が作れることになる。
【００９１】
ストライプ統合では、２つのストライプをメモリ内に読み出し、有効ブロックだけを詰めて書込みバッファに移す。それに合わせて、論理アドレスタグも、図２６に示すように、ＴＧ１、ＴＧ３から有効ブロックの論理アドレスだけを対応する位置に移して新しい論理アドレスタグＴＧ１０を作り、その時点のタイムスタンプを更新する。この例では、１４個の有効ブロックしかなかったので、最後のデータブロックは空状態のまま書き込む。このときは、論理アドレスタグＴＧ１０の最後のデータブロックに対する論理アドレスにヌルルアドレスを入れることによりデータが入っていないことを表わせるので問題はない。
【００９２】
しかしながら、スナップショットがある場合、ただ詰替えを行なったのでは詰替える前の領域を空き状態にできない。図２７を参照してこれらについて説明する。
【００９３】
たとえば、図２７に示すように、ストライプＳＴ１とＳＴ３を詰替えて新しいストライプＳＴ１０を作ったとしても、スナップショット情報では、スナップショットＳＳ１はタイムスタンプがＴＳ１からＴＳ４であるストライプが対象であり、スナップショットＳＳ１の参照では、空き状態であるはずのストライプＳＴ１およびＳＴ３のブロックをアクセスにいってしまう。
【００９４】
そこで、図２７に示すように、詰替え情報として、詰替えで作成されたストライプのタイムスタンプをディスク上に保存する。また、ストライプの参照処理では、スナップショット情報のタイムスタンプ値から決まるストライプだけでなく、詰替え情報のタイムスタンプのストライプも対象とする。たとえば、スナップショットＳＳ１の参照処理では、タイムスタンプがＴＳ４より小さいストライプ（ＳＴ１〜ＳＴ４）だけでなく、詰替え情報のタイムスタンプのストライプ（ＳＴ１０）も無効ブロック判定の対象とする。これにより、ストライプＳＴ１０はストライプＳＴ１およびＳＴ３の有効ブロックだけを詰替えたものであることから、ストライプＳＴ１およびＳＴ３の全ブロックは必ず無効と判定され、ストライプＳＴ１およびＳＴ３はスナップショットからも参照されることはなくなる。よって、実質的には空き領域となる。
【００９５】
ただし、この方法は、同一のスナップショットのみから対象とされるストライプ同士を詰替えた場合にのみ正しく動作し、図２８に示すような、スナップショットＳＳ１、ＳＳ２、ＳＳ３が対象とするストライプＳＴ２と、スナップショットＳＳ２、ＳＳ３が対象とするストライプＳＴ６とを詰替えて、ストライプＳＴ１０を作るような場合には正しく動作しない。なぜならば、ストライプＳＴ１０にはスナップショットＳＳ１採取後に書き出されたストライプＳＴ６の更新ブロックが含まれているため、スナップショットＳＳ１の参照処理でストライプＳＴ１０も対象にしてしまうと、ＳＳ１採取時のディスク状態が再現できないからである。
【００９６】
そこで、図２８に示すように、詰替えによって作成されたストライプの中に、元になった各ストライプのタイムスタンプと元ブロックが格納されているブロック位置とを元ストライプ情報として保存する。そして、スナップショットの参照処理において、詰替えによって作成されたストライプ（詰替え情報から分かる）に対しては、この元ストライプ情報も活用して不要なブロックを対象にしないようにする。つまり、先のスナップショットＳＳ１の参照処理においては、ストライプＳＴ１０の全ブロックを対象にするのではなく、スナップショットＳＳ１のタイムスタンプＳＴ４より小さい、ブロックＢ１〜Ｂ６（タイムスタンプＴＳ２）だけを対象にする。これにより、スナップショットＳＳ１採取時のディスクイメージを再現できるとともに、ストライプＳＴ２の全ブロックが無効となりＳＴ２を空き領域にできる。
【００９７】
最後に、これまでの詰替え処理の説明では、無効ブロックとはスナップショット参照としても通常の最新イメージの読み出しとしてもアクセスされないブロックと定義し、スナップショット参照用変換マップと読み出し用変換マップとが作成され、それらの変換マップから参照されないブロックを見つける方法を取っていた。しかしながら、この方法では、スナップショット数が多くなると作成すべき変換マップの数も多くなり、非常に効率が悪い。
【００９８】
そこで、無効ブロックの判定に無効ブロックに対応したビットマップを使う方法について説明する。図２９には無効ブロックに対応したビットマップを使った無効ブロック判定のための構成が示されている。
【００９９】
図２９に示すように、メモリ６上には現時点の最新ディスクイメージを構成するディスク装置４上の全ブロックの状態をビットマップとして保持する。
【０１００】
このビットマップは、全ビットを無効状態に初期化した後、読み出し用変換マップから参照されるブロックに対応するビットを有効状態にすることにより容易に作成できる。また、書き出し処理により書き込みバッファ８内の更新データが空き状態のストライプに書き出されると、書き出したストライプのビットマップを有効状態にする（なお、書き込みバッファ管理テーブル９にヌルアドレスをセッ卜されたブロックに対応するビッ卜は無効のままとする）。さらに、この書き出しにより変更された論理アドレスに対する書き出し以前のブロック位置を読み出し用変換マップから求めて、このブロックを無効化されたブロックとして対応するビットマップを無効状態にする。以上のビットマップ変更を更新データの書き出し処理ごとに行なえば、常に最新ディスクイメージを構成するディスク装置４上の全ブロックの状態を維持できるようになる。
【０１０１】
そこで、チェックポイント採取処理では、図２９に示すように、このビットマップもスナップショット情報として保存する。そして、無効ブロックの判定処理では、メモリ６上のビットマップとスナップショット情報の全ビットマップとを調べることにより、無効状態にあるブロックを無効ブロックと判定する。これにより、スナップショットの変換マップを作成しなくても、無効ブロックの判定が可能となり、詰替えるべきストライプを容易に見つけることが可能となる。
【０１０２】
なお、図２９では、メモリ６の全ビットマップをスナップショット情報として保存したが、このビットマップは無効ブロックの判定に用いるだけなので、図３０に示すように、スナップショット採取時に無効ブロックの多いストライプに対するビットマップだけをスナップショット情報として保存することもできる。図３０の例では、ストライプＳＴ３、ＳＴ５、ＳＴ６、ＳＴ１０の無効ブロックが多いので、これらのストライプのビットマップだけがストライプ情報として保存されている。これにより、スナップショット情報のための領域を減らせ、詰替えのための無効ブロック判定も効率よく行なえる。
【０１０３】
（第７実施形態）
次に、この発明の第７実施形態を説明する。
【０１０４】
これまでに述べた実施形態では、更新データやスナップショット情報、最新イメージ情報、削除ストライプ情報、詰替え情報を記憶するディスク装置は１台であるものとして説明してきたが、図３１に示すように、複数のディスク装置から１台の論理的ディスク装置を構成したディスクアレイ装置（ＲＡＩＤ０、１、３、４、５）であっても良い。このとき、これまでの説明で使ってきたストライプのサイズとしては、ＲＡＩＤ０の場合は、“ストライプユニット単位（そのディスク装置の１トラック長に近いサイズが好ましい）＊ディスク台数”を選び、一方、ＲＡＩＤ３、４、５の場合は、“ストライプユニット単位＊（ディスク台数−１）”を選ぶことにより、全ディスクを同じタイミングで書き込めるため非常に効率が良い。特に、冗長情報としてパリティを使うＲＡＩＤ４、５では、通常必要な２回の読み出しと１回の書き込みが不要になり、非常に効率が良い。
【０１０５】
なお、この発明は、不揮発性記憶装置としてディスク装置を用いるコンピュータシステムだけではなく、光磁気ディスク、ＤＶＤ−ＲＡＭおよびＥＥＰＲΟＭなどのあらゆる不揮発性記憶装置を用いるスナップショットやバックアップを必要とするコンピュータシステムに適用可能である。
【０１０６】
【発明の効果】
以上詳述したように、この発明では、たとえばディスク装置などの不揮発性記憶装置とファイルシステムとの間に、ディスクレベルのスナップショットを採取するスナップショット管理手段を介在させる構造を採用するため、既存のコンピュータシステムのファイルシステムをそのまま使え、専用のファイルシステムを新しく開発する必要がない。また、ファイルシステム自身もブロック木構造である必要はまったくなく、ＮＴＦＳなどのエクステントベースのファイルシステムにでも適用できる。さらに、従来発生していた、スナップショッ卜作成後の更新性能が大きく低下するという問題もない。そして、スナップショットはスナップショット情報という簡単なデータ構造で実現されるため、スナップショットに対する操作は読み出しだけでなく更新も可能となり、ファイルをコピーしなくてもファイル更新を伴なうアプリケーションプログラム（ＤＢＭＳ、メールなど）を使って過去のスナップショットをアクセスして必要な情報を取り出せる。また、スナップショットは擬似ディスク、リムーバブルメディア、最新ディスクイメージとして見せることにより、スナップショットをアクセスするために、既存のオペレーティングシステム、ファイルシステムおよびアプリケーションプログラムなどを改造することなく、既存のコンピュータシステムにそのまま適用することが可能である。
【図面の簡単な説明】
【図１】この発明の第１実施形態に係るコンピュータシステムの構成を示す概念図。
【図２】同第１実施形態のディスクスナップショット部の構成を示す概念図。
【図３】同第１実施形態の揮発性メモリ内の書き込みバッファとバッファ管理テーブルとの関係を示す図。
【図４】同第１実施形態のディスク装置上の空領域を示す図。
【図５】同第１実施形態のコンピュータシステムにおける書き込み処理を説明すための図。
【図６】同第１実施形態の無効ブロックの判定処理を説明するための図。
【図７】図６の例における２つのストライプＳＴ１、ＳＴ２の論理アドレスタグＴＧ１、ＴＧ２の内容を示す図。
【図８】同第１実施形態の論理アドレスから物理アドレスへの変換マップを示す図。
【図９】同第１実施形態のコンピュータシステムにおけるスナップショットの採取処理を説明するための図。
【図１０】同第１実施形態のコンピュータシステムにおけるスナップショットの参照処理を説明するための図。
【図１１】ディスク状態が図１０である場合のスナップショット用変換マップと読み出し用変換マップとの様子を示す図。
【図１２】ディスクスナップショット部がもつスナップショット採取時のディスクイメージを別の擬似ディスクとして見せる擬似ディスク機能を説明するための図。
【図１３】この発明の第２実施形態に係るコンピュータシステムのスナップショット採取手順を説明するためのフローチャート。
【図１４】この発明の第３実施形態に係るコンピュータシステムのスナップショット情報を示す図。
【図１５】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第１の方法を説明するための図。
【図１６】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第２の方法を説明するための図。
【図１７】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第３の方法を説明するための図。
【図１８】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第４の方法を説明するための図。
【図１９】同第３実施形態の複数のスナップショットをアプリケーションプログラムからアクセスする第４の方法におけるコンピュータシステムの運用例を示す図。
【図２０】この発明の第４実施形態に係るコンピュータシステムにおけるスナップショットの変更を説明するための図。
【図２１】同第４実施形態のスナップショット情報、最新イメージ情報およびタイムスタンプ情報を説明するための図。
【図２２】同第４実施形態のコンピュータシステムにおけるスナップショットの削除を説明するための図。
【図２３】同第４実施形態のスナップショット情報、最新イメージ情報およびタイムスタンプ情報のスナップショットの削除に伴なう取り扱いを説明するための図。
【図２４】この発明の第５実施形態に係るコンピュータシステムのスナップショット情報を示す図。
【図２５】この発明の第５実施形態に係るコンピュータシステムにおける詰替え処理を説明するためのストライプを示す図。
【図２６】同第５実施形態のコンピュータシステムにおける詰替え処理を説明するための論理アドレスタグを示す図。
【図２７】同第５実施形態のコンピュータシステムにおける詰替え情報を説明するための図。
【図２８】同第５実施形態のコンピュータシステムにおける元ストライプ情報を説明するための図。
【図２９】同第５実施形態の無効ブロックに対応したビットマップを使った無効ブロック判定のための構成を示す図。
【図３０】同第５実施形態のスナップショット採取時に無効ブロックの多いストライプに対するビットマップだけをスナップショット情報として保存する例を示す図。
【図３１】この発明の第７実施形態に係るコンピュータシステムのディスク装置をディスクアレイ装置で構成した例を示す図。
【図３２】従来のスナップショットの作成を説明するための図。
【図３３】従来のスナップショットの作成の問題点を説明するための図。
【符号の説明】
１ａ〜１ｃ…アプリケーションプログラム、２…ファイルシステム、３…ディスクスナップショット部、４…ディスク装置、５…ディスクスナップショット制御部、６…揮発性メモリ、７…タイムスタンプ、８…書き込みバッファ、９…バッファ管理テーブル、１０…ディスクスナップショット情報、１１…スナップショット参照用ファイルシステム、１２…スナップショット参照用ユーティリティプログラム、１３…スナップショット用ディスク装置。
Claims (20)
- 不揮発性記憶装置に格納されたファイル群に対するアプリケーションプログラムからの更新を含むアクセスを管理するファイルシステムとＫ個の論理ブロックに相当する容量を有する書き込みバッファとを備えたコンピュータシステムに適用されるデータ退避方法において、
前記書き込みバッファに更新すべきデータの論理ブロックを蓄積し、
その蓄積した論理ブロックがＫ−１個に達したら、
前記書き込みバッファに蓄積された各論理ブロックに対する論理アドレスから構成され、タイムスタンプを付加した論理アドレスタグブロックを生成し、
Ｋ−１個のブロックに前記論理アドレスタグブロックを加えたＫ個の論理ブロックを一つのストライプとして前記不揮発性記憶装置上の更新されるべきデータを保持する領域とは別の空き領域に連続して書き込みを行う書き込み処理であって、
前記書き込み処理中に、前記ファイル群の内容を所定の時点に復元するためのスナップショットを採取するスナップショット採取の指示があった場合に、
前記Ｋ−１個の論理ブロックの中で、スナップショット採取時点で更新すべきデータの論理ブロックが埋まっていない論理ブロックに対する論理アドレスをヌルアドレスとしてストライプを作成し、
当該ストライプの論理アドレスタグブロックに付加したタイムスタンプをスナップショット情報として前記空き領域内のストライプが書き込まれた領域とは別の領域に記録する
ことを特徴とするデータ退避方法。 - 前記採取したスナップショットに関しては前記不揮発性記憶装置を別の擬似記憶装置に見せ掛け、
この擬似記憶装置に対する読み出し要求に対しては、
前記スナップショット情報として記録されたタイムスタンプで示される時刻またはそれ以前に書き込まれたストライプであって、読み出し要求された論理アドレスのブロックを含む最も後に書き込まれたストライプを検索し、
この検索により検出されたストライプの要求された論理アドレスに対応するブロックを読み出し、その読み出したデータを要求の応答として返す
ことを特徴とする請求項１記載のデータ退避方法。 - 前記採取したスナップショットを格納する前記不揮発性記憶装置を別の擬似記憶装置に見せ掛け、
前記スナップショット情報として記録されたタイムスタンプで示される時刻またはそれ以前に書き込まれたストライプであって、各々の論理アドレスのブロックを含む最も後に書き込まれたストライプに対応する物理ブロックを検索し、
前記論理アドレスと前記検索により検出された物理ブロックとの対応関係を表すスナップショット用変換マップを作成し、前記擬似記憶装置に対する読み出し要求に対しては、前記作成したスナップショット用変換マップに基づいて、要求された論理アドレスに対応する物理ブロックを応答として返す
ことを特徴とする請求項１記載のデータ退避方法。 - オペレーティングシステムからの前記擬似記憶装置に関する問い合わせに対してリムーバブルであると応答を返し、スナップショット切り替え後のアクセスでメディア不確定の応答を返し、かつ切り替え指定されたスナップショットのタイムスタンプを用いて前記擬似記憶装置に対する読み出し処理を実行する
ことを特徴とする請求項２または３記載のデータ退避方法。 - システム起動時に参照すべきスナップショットを問い合わせ、
この問い合わせに応じて選択されたスナップショットのタイムスタンプを用いて前記擬似記憶装置に対する読み出し処理を実行する
ことを特徴とする請求項２または３記載のデータ退避方法。 - 次回のシステム起動時に選択すべきスナップショットを記録し、
この記録されたスナップショットのタイムスタンプを用いて前記擬似記憶装置に対する読み出し処理を実行する
ことを特徴とする請求項２または３記載のデータ退避方法。 - 前記スナップショット情報を親となるスナップショットの識別子とその後に書き出されたストライプのタイムスタンプとから構成し、
スナップショットを参照する際、前記スナップショット情報で示された親となるスナップショットを辿りながら対象とするストライプを決定する
ことを特徴とする請求項２または３記載のデータ退避方法。 - 親となるスナップショットの識別子とその後に書き出されたストライプのタイムスタンプとから最新イメージ情報を構成し、
最新イメージを読み出す際、前記最新イメージ情報で示された親となるスナップショットを辿りながら対象とするストライプを決定する
ことを特徴とする請求項２または３記載のデータ退避方法。 - 最新イメージに対応するタイムスタンプの範囲を予め割り当ててタイムスタンプ情報として保存しておき、
最新イメージ情報のタイムスタンプとして、前記不揮発性記憶装置に書き込まれたストライプのタイムスタンプであって前記タイムスタンプ情報の範囲内にあるものを求める
ことを特徴とする請求項８記載のデータ退避方法。 - 前記スナップショット情報または最新イメージ情報の削除を受け付けることを特徴とする請求項２、３、４、５、６、７、８または９記載のデータ退避方法。
- 削除によりアクセスされなくなったストライプのタイムスタンプを削除スタンプ情報として保存する請求項２、３、４、５、６、７、８、９または１０記載のデータ退避方法。
- 前記スナップショット情報を前記タイムスタンプとストライプ内ブロック位置とにより構成し、
前記スナップショット採取後も前記書き込みバッファをクリアせず、
前記書き込みバッファ内の論理ブロックを前回の書き出し時と同じタイムスタンプで同じストライプ上に書き出すことを特徴とする請求項２、３、４、５、６、７、８、９、１０または１１記載のデータ退避方法。 - 最新イメージおよびスナップショットのいずれからも参照されないブロックを無効ブロックとして複数のストライプを新たな一つのストライプに詰め替えることを特徴とする請求項２、３、４、５、６、７、８、９、１０、１１または１２記載のデータ退避方法。
- 前記詰め替え後の新たなストライプのタイムスタンプを詰め替え情報として記録し、スナップショットを参照する際、前記詰め替え情報のタイムスタンプのストライプも検索対象のストライプに含めることを特徴とする請求項１３記載のデータ退避方法。
- 前記詰め替え対象となったストライプの識別子を前記詰め替え後の新たなストライプの元ストライプ情報として記録し、スナップショットを参照する際、前記元ストライプ情報を用いることを特徴とする請求項１３記載のデータ退避方法。
- ストライプ内の各論理ブロックの状態を示すビットマップをスナップショット情報として保存し、無効ブロックの判定に用いることを特徴とする請求項１３、１４または１５記載のデータ退避方法。
- 無効ブロックが多いストライプのビットマップのみをスナップショット情報として保存する請求項１６記載のデータ退避方法。
- 前記スナップショット情報および最新イメージ情報に採取日時を付加し、
スナップショットまたは最新イメージの識別に前記付加した日時を用いる
ことを特徴とする請求項２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４、１５、１６または１７記載のデータ退避方法。 - 前記不揮発性記憶装置がＲＡＩＤ０の構成であったときには、前記ストライプサイズをストライプユニット単位×ディスク台数とする請求項１、２または３記載のデータ退避方法。
- 前記不揮発性記憶装置がＲＡＩＤ３、ＲＡＩＤ４およびＲＡＩＤ５のいずれかの構成であったときには、前記ストライプサイズをストライプユニット単位×（ディスク台数−１）とする請求項１、２または３記載のデータ退避方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27915797A JP4128641B2 (ja) | 1997-10-13 | 1997-10-13 | データ退避方法 |
| US09/161,508 US6311193B1 (en) | 1997-10-13 | 1998-09-28 | Computer system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27915797A JP4128641B2 (ja) | 1997-10-13 | 1997-10-13 | データ退避方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11120055A JPH11120055A (ja) | 1999-04-30 |
| JP4128641B2 true JP4128641B2 (ja) | 2008-07-30 |
Family
ID=17607253
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP27915797A Expired - Fee Related JP4128641B2 (ja) | 1997-10-13 | 1997-10-13 | データ退避方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6311193B1 (ja) |
| JP (1) | JP4128641B2 (ja) |
Families Citing this family (180)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050015411A1 (en) * | 1996-06-27 | 2005-01-20 | Gerald Altman | Systems, processes, and products for storage and retrieval of electronic files |
| US20040059742A1 (en) * | 1996-06-27 | 2004-03-25 | Gerald Altman | Database systems and processes for storage and retrieval of electronic and related documents |
| US6484235B1 (en) | 1999-05-03 | 2002-11-19 | 3Ware, Inc. | Methods and systems for dynamically distributing disk array data accesses |
| US6487633B1 (en) | 1999-05-03 | 2002-11-26 | 3Ware, Inc. | Methods and systems for accessing disks using forward and reverse seeks |
| TW454120B (en) | 1999-11-11 | 2001-09-11 | Miralink Corp | Flexible remote data mirroring |
| US7203732B2 (en) * | 1999-11-11 | 2007-04-10 | Miralink Corporation | Flexible remote data mirroring |
| EP1178407A3 (en) * | 2000-06-02 | 2007-12-12 | Compaq Computer Corporation | Architecture for parallel distributed table driven I/O mapping |
| US6542980B1 (en) * | 2000-08-11 | 2003-04-01 | Trw Inc. | Time slot data memory storage and access system |
| US6640233B1 (en) * | 2000-08-18 | 2003-10-28 | Network Appliance, Inc. | Reserving file system blocks |
| US6636879B1 (en) * | 2000-08-18 | 2003-10-21 | Network Appliance, Inc. | Space allocation in a write anywhere file system |
| US7072916B1 (en) * | 2000-08-18 | 2006-07-04 | Network Appliance, Inc. | Instant snapshot |
| US6584551B1 (en) * | 2000-11-27 | 2003-06-24 | Lsi Logic Corporation | System and method for automatic dynamic expansion of a snapshot repository |
| US6631456B2 (en) * | 2001-03-06 | 2003-10-07 | Lance Leighnor | Hypercache RAM based disk emulation and method |
| EP1436873B1 (en) | 2001-09-28 | 2009-04-29 | Commvault Systems, Inc. | System and method for generating and managing quick recovery volumes |
| JP3526452B2 (ja) | 2001-12-18 | 2004-05-17 | 株式会社東芝 | ディスクアレイ装置及びデータバックアップ方法 |
| US7043503B2 (en) * | 2002-02-15 | 2006-05-09 | International Business Machines Corporation | Ditto address indicating true disk address for actual data blocks stored in one of an inode of the file system and subsequent snapshot |
| US7373364B1 (en) | 2002-03-05 | 2008-05-13 | Network Appliance, Inc. | System and method for creating a point-in-time restoration of a database file |
| US7340489B2 (en) * | 2002-04-10 | 2008-03-04 | Emc Corporation | Virtual storage devices |
| US7120827B2 (en) * | 2002-05-07 | 2006-10-10 | Hitachi Ltd. | System and method of volume health checking and recovery |
| US8219777B2 (en) | 2002-10-03 | 2012-07-10 | Hewlett-Packard Development Company, L.P. | Virtual storage systems, virtual storage methods and methods of over committing a virtual raid storage system |
| CA2508089A1 (en) | 2002-10-07 | 2004-04-22 | Commvault Systems, Inc. | System and method for managing stored data |
| JP3767818B2 (ja) * | 2002-10-28 | 2006-04-19 | 株式会社サスライト | 着脱式デバイス及びプログラムの起動方法 |
| US20040088301A1 (en) * | 2002-10-31 | 2004-05-06 | Mallik Mahalingam | Snapshot of a file system |
| US7421433B2 (en) * | 2002-10-31 | 2008-09-02 | Hewlett-Packard Development Company, L.P. | Semantic-based system including semantic vectors |
| US20040088274A1 (en) * | 2002-10-31 | 2004-05-06 | Zhichen Xu | Semantic hashing |
| AU2003301696A1 (en) | 2002-11-01 | 2004-05-25 | Shinya Kobayashi | Detachable device, control circuit, control circuit firmware program, information processing method and circuit design pattern in control circuit, and log-in method |
| JP2004178337A (ja) * | 2002-11-28 | 2004-06-24 | Hitachi Ltd | 記憶装置システム、記憶装置、計算機およびプログラム |
| US7284016B2 (en) * | 2002-12-03 | 2007-10-16 | Emc Corporation | Client-server protocol for directory access of snapshot file systems in a storage system |
| US7043470B2 (en) * | 2003-03-05 | 2006-05-09 | Hewlett-Packard Development Company, L.P. | Method and apparatus for improving querying |
| US20040205242A1 (en) * | 2003-03-12 | 2004-10-14 | Zhichen Xu | Querying a peer-to-peer network |
| US7039634B2 (en) * | 2003-03-12 | 2006-05-02 | Hewlett-Packard Development Company, L.P. | Semantic querying a peer-to-peer network |
| JP4311532B2 (ja) * | 2003-03-12 | 2009-08-12 | 株式会社日立製作所 | 記憶システム及び同システムにおけるスナップショット管理方法 |
| US20040181607A1 (en) * | 2003-03-13 | 2004-09-16 | Zhichen Xu | Method and apparatus for providing information in a peer-to-peer network |
| US7231409B1 (en) * | 2003-03-21 | 2007-06-12 | Network Appliance, Inc. | System and method for reallocating blocks in checkpointing bitmap-based file systems |
| US7181476B2 (en) * | 2003-04-30 | 2007-02-20 | Oracle International Corporation | Flashback database |
| US7310681B2 (en) * | 2003-06-23 | 2007-12-18 | Hewlett-Packard Development Company, L.P. | System and method for modeling the memory state of a streaming media server |
| US7165145B2 (en) * | 2003-07-02 | 2007-01-16 | Falconstor Software, Inc. | System and method to protect data stored in a storage system |
| US7756844B2 (en) * | 2003-07-08 | 2010-07-13 | Pillar Data Systems, Inc. | Methods of determining and searching for modified blocks in a file system |
| US20050010592A1 (en) * | 2003-07-08 | 2005-01-13 | John Guthrie | Method and system for taking a data snapshot |
| US7836029B2 (en) * | 2003-07-08 | 2010-11-16 | Pillar Data Systems, Inc. | Systems and methods of searching for and determining modified blocks in a file system |
| US6959313B2 (en) * | 2003-07-08 | 2005-10-25 | Pillar Data Systems, Inc. | Snapshots of file systems in data storage systems |
| US7379954B2 (en) * | 2003-07-08 | 2008-05-27 | Pillar Data Systems, Inc. | Management of file system snapshots |
| JP4559046B2 (ja) * | 2003-08-04 | 2010-10-06 | 株式会社日立製作所 | 仮想テープライブラリ装置 |
| JPWO2005029379A1 (ja) * | 2003-09-19 | 2006-11-30 | 東芝ソリューション株式会社 | 情報処理装置及び情報処理方法 |
| US7730222B2 (en) | 2004-08-24 | 2010-06-01 | Symantec Operating System | Processing storage-related I/O requests using binary tree data structures |
| US7287133B2 (en) | 2004-08-24 | 2007-10-23 | Symantec Operating Corporation | Systems and methods for providing a modification history for a location within a data store |
| US7725760B2 (en) | 2003-09-23 | 2010-05-25 | Symantec Operating Corporation | Data storage system |
| US7991748B2 (en) | 2003-09-23 | 2011-08-02 | Symantec Corporation | Virtual data store creation and use |
| US7827362B2 (en) | 2004-08-24 | 2010-11-02 | Symantec Corporation | Systems, apparatus, and methods for processing I/O requests |
| US7577807B2 (en) * | 2003-09-23 | 2009-08-18 | Symantec Operating Corporation | Methods and devices for restoring a portion of a data store |
| US7577806B2 (en) * | 2003-09-23 | 2009-08-18 | Symantec Operating Corporation | Systems and methods for time dependent data storage and recovery |
| US7904428B2 (en) | 2003-09-23 | 2011-03-08 | Symantec Corporation | Methods and apparatus for recording write requests directed to a data store |
| WO2005048085A2 (en) | 2003-11-13 | 2005-05-26 | Commvault Systems, Inc. | System and method for performing an image level snapshot and for restoring partial volume data |
| CA2544064C (en) | 2003-11-13 | 2012-02-07 | Commvault Systems, Inc. | System and method for performing integrated storage operations |
| US7412583B2 (en) * | 2003-11-14 | 2008-08-12 | International Business Machines Corporation | Virtual incremental storage method |
| US7225210B2 (en) * | 2003-11-20 | 2007-05-29 | Overland Storage, Inc. | Block level data snapshot system and method |
| JP4581518B2 (ja) * | 2003-12-19 | 2010-11-17 | 株式会社日立製作所 | スナップショット取得方法 |
| US7313720B1 (en) * | 2004-02-12 | 2007-12-25 | Network Appliance, Inc. | Technique for increasing the number of persistent consistency point images in a file system |
| JP4489455B2 (ja) * | 2004-02-16 | 2010-06-23 | 株式会社日立製作所 | ディスク制御装置及びディスク制御装置の制御方法 |
| US20050240934A1 (en) * | 2004-04-21 | 2005-10-27 | Hewlett-Packard Development Company, L.P. | Task management based on system utilization |
| US7213103B2 (en) * | 2004-04-22 | 2007-05-01 | Apple Inc. | Accessing data storage systems without waiting for read errors |
| US7409511B2 (en) * | 2004-04-30 | 2008-08-05 | Network Appliance, Inc. | Cloning technique for efficiently creating a copy of a volume in a storage system |
| US7334094B2 (en) * | 2004-04-30 | 2008-02-19 | Network Appliance, Inc. | Online clone volume splitting technique |
| JP2006011811A (ja) * | 2004-06-25 | 2006-01-12 | Hitachi Ltd | 記憶制御システム及び記憶制御方法 |
| US8959299B2 (en) | 2004-11-15 | 2015-02-17 | Commvault Systems, Inc. | Using a snapshot as a data source |
| US20060123210A1 (en) * | 2004-12-06 | 2006-06-08 | St. Bernard Software, Inc. | Method for logically consistent backup of open computer files |
| US7711709B2 (en) * | 2004-12-27 | 2010-05-04 | Siebel Systems, Inc. | Efficient storing and querying of snapshot measures |
| US7577763B1 (en) | 2005-02-28 | 2009-08-18 | Apple Inc. | Managing read requests from multiple requestors |
| US7757056B1 (en) | 2005-03-16 | 2010-07-13 | Netapp, Inc. | System and method for efficiently calculating storage required to split a clone volume |
| US8843591B2 (en) * | 2005-03-17 | 2014-09-23 | International Business Machines Corporation | Selectable repainting of updatable network distributable imagery |
| JP4248510B2 (ja) * | 2005-03-24 | 2009-04-02 | 株式会社東芝 | 計算機システム、ディスク装置およびデータ更新制御方法 |
| US7590668B2 (en) * | 2005-04-15 | 2009-09-15 | Microsoft Corporation | Pausable backups of file system items |
| US7373366B1 (en) | 2005-06-10 | 2008-05-13 | American Megatrends, Inc. | Method, system, apparatus, and computer-readable medium for taking and managing snapshots of a storage volume |
| US7523146B2 (en) | 2005-06-21 | 2009-04-21 | Apple Inc. | Apparatus and method for peer-to-peer N-way synchronization in a decentralized environment |
| US8495015B2 (en) | 2005-06-21 | 2013-07-23 | Apple Inc. | Peer-to-peer syncing in a decentralized environment |
| JP3766429B2 (ja) * | 2005-08-04 | 2006-04-12 | 株式会社サスライト | 着脱式デバイス |
| JP4872328B2 (ja) * | 2005-11-29 | 2012-02-08 | 富士通株式会社 | 動作環境切り替えプログラム及び情報処理装置 |
| US8655850B2 (en) | 2005-12-19 | 2014-02-18 | Commvault Systems, Inc. | Systems and methods for resynchronizing information |
| US7636743B2 (en) | 2005-12-19 | 2009-12-22 | Commvault Systems, Inc. | Pathname translation in a data replication system |
| US7606844B2 (en) | 2005-12-19 | 2009-10-20 | Commvault Systems, Inc. | System and method for performing replication copy storage operations |
| EP1974296B8 (en) | 2005-12-19 | 2016-09-21 | Commvault Systems, Inc. | Systems and methods for performing data replication |
| US7962709B2 (en) | 2005-12-19 | 2011-06-14 | Commvault Systems, Inc. | Network redirector systems and methods for performing data replication |
| US7651593B2 (en) | 2005-12-19 | 2010-01-26 | Commvault Systems, Inc. | Systems and methods for performing data replication |
| US7617262B2 (en) | 2005-12-19 | 2009-11-10 | Commvault Systems, Inc. | Systems and methods for monitoring application data in a data replication system |
| JP4819521B2 (ja) * | 2006-02-17 | 2011-11-24 | 株式会社日立製作所 | 記憶システム及び仮想化方法並びにストレージ装置 |
| US7590660B1 (en) | 2006-03-21 | 2009-09-15 | Network Appliance, Inc. | Method and system for efficient database cloning |
| US7797670B2 (en) * | 2006-04-14 | 2010-09-14 | Apple Inc. | Mirrored file system |
| US8726242B2 (en) | 2006-07-27 | 2014-05-13 | Commvault Systems, Inc. | Systems and methods for continuous data replication |
| US7860826B2 (en) | 2006-08-04 | 2010-12-28 | Apple Inc. | Method and system for using global equivalency sets to identify data during peer-to-peer synchronization |
| US7676510B1 (en) * | 2006-12-22 | 2010-03-09 | Network Appliance, Inc. | Space reservation monitoring in a fractionally reserved data storage system |
| US7657769B2 (en) | 2007-01-08 | 2010-02-02 | Marcy M Scott | N-way synchronization of data |
| US8046547B1 (en) | 2007-01-30 | 2011-10-25 | American Megatrends, Inc. | Storage system snapshots for continuous file protection |
| US8290808B2 (en) | 2007-03-09 | 2012-10-16 | Commvault Systems, Inc. | System and method for automating customer-validated statement of work for a data storage environment |
| US8082407B1 (en) * | 2007-04-17 | 2011-12-20 | American Megatrends, Inc. | Writable snapshots for boot consolidation |
| US7865475B1 (en) | 2007-09-12 | 2011-01-04 | Netapp, Inc. | Mechanism for converting one type of mirror to another type of mirror on a storage system without transferring data |
| US8204859B2 (en) | 2008-12-10 | 2012-06-19 | Commvault Systems, Inc. | Systems and methods for managing replicated database data |
| US9495382B2 (en) | 2008-12-10 | 2016-11-15 | Commvault Systems, Inc. | Systems and methods for performing discrete data replication |
| US8392481B2 (en) * | 2009-04-22 | 2013-03-05 | International Business Machines Corporation | Accessing snapshots of a time based file system |
| US9092500B2 (en) | 2009-09-03 | 2015-07-28 | Commvault Systems, Inc. | Utilizing snapshots for access to databases and other applications |
| US8719767B2 (en) | 2011-03-31 | 2014-05-06 | Commvault Systems, Inc. | Utilizing snapshots to provide builds to developer computing devices |
| US8433682B2 (en) | 2009-12-31 | 2013-04-30 | Commvault Systems, Inc. | Systems and methods for analyzing snapshots |
| JP2013011919A (ja) * | 2009-09-17 | 2013-01-17 | Hitachi Ltd | ストレージ装置及びそのスナップショット制御方法 |
| EP2519872A4 (en) | 2009-12-31 | 2015-08-26 | Commvault Systems Inc | SYSTEMS AND METHOD FOR IMPLEMENTING DATA MANAGEMENT OPERATIONS USING SNAPSHOTS |
| US10564944B2 (en) | 2010-01-07 | 2020-02-18 | Microsoft Technology Licensing, Llc | Efficient immutable syntax representation with incremental change |
| WO2011113504A1 (en) * | 2010-03-16 | 2011-09-22 | Amplidata Nv | Device driver for use in a data storage system |
| US8504517B2 (en) | 2010-03-29 | 2013-08-06 | Commvault Systems, Inc. | Systems and methods for selective data replication |
| US8504515B2 (en) | 2010-03-30 | 2013-08-06 | Commvault Systems, Inc. | Stubbing systems and methods in a data replication environment |
| US8352422B2 (en) | 2010-03-30 | 2013-01-08 | Commvault Systems, Inc. | Data restore systems and methods in a replication environment |
| US8725698B2 (en) | 2010-03-30 | 2014-05-13 | Commvault Systems, Inc. | Stub file prioritization in a data replication system |
| US8423733B1 (en) * | 2010-04-02 | 2013-04-16 | Symantec Corporation | Single-copy implicit sharing among clones |
| US8589347B2 (en) | 2010-05-28 | 2013-11-19 | Commvault Systems, Inc. | Systems and methods for performing data replication |
| US9471578B2 (en) | 2012-03-07 | 2016-10-18 | Commvault Systems, Inc. | Data storage system utilizing proxy device for storage operations |
| US9298715B2 (en) | 2012-03-07 | 2016-03-29 | Commvault Systems, Inc. | Data storage system utilizing proxy device for storage operations |
| US9342537B2 (en) | 2012-04-23 | 2016-05-17 | Commvault Systems, Inc. | Integrated snapshot interface for a data storage system |
| US9104634B2 (en) * | 2012-11-30 | 2015-08-11 | Red Hat Israel, Ltd. | Usage of snapshots prepared by a different host |
| US9262435B2 (en) | 2013-01-11 | 2016-02-16 | Commvault Systems, Inc. | Location-based data synchronization management |
| US9886346B2 (en) | 2013-01-11 | 2018-02-06 | Commvault Systems, Inc. | Single snapshot for multiple agents |
| JP5650826B2 (ja) * | 2013-10-04 | 2015-01-07 | 日本電信電話株式会社 | 検索インデックス生成装置及び検索インデックス構築方法及び検索インデックス構築プログラム |
| US9632874B2 (en) | 2014-01-24 | 2017-04-25 | Commvault Systems, Inc. | Database application backup in single snapshot for multiple applications |
| US9495251B2 (en) | 2014-01-24 | 2016-11-15 | Commvault Systems, Inc. | Snapshot readiness checking and reporting |
| US9753812B2 (en) | 2014-01-24 | 2017-09-05 | Commvault Systems, Inc. | Generating mapping information for single snapshot for multiple applications |
| US9639426B2 (en) | 2014-01-24 | 2017-05-02 | Commvault Systems, Inc. | Single snapshot for multiple applications |
| US9774672B2 (en) | 2014-09-03 | 2017-09-26 | Commvault Systems, Inc. | Consolidated processing of storage-array commands by a snapshot-control media agent |
| US10042716B2 (en) | 2014-09-03 | 2018-08-07 | Commvault Systems, Inc. | Consolidated processing of storage-array commands using a forwarder media agent in conjunction with a snapshot-control media agent |
| US9448731B2 (en) | 2014-11-14 | 2016-09-20 | Commvault Systems, Inc. | Unified snapshot storage management |
| US9648105B2 (en) | 2014-11-14 | 2017-05-09 | Commvault Systems, Inc. | Unified snapshot storage management, using an enhanced storage manager and enhanced media agents |
| US20160217175A1 (en) * | 2015-01-23 | 2016-07-28 | Netapp, Inc. | Techniques for asynchronous snapshot invalidation |
| US10311150B2 (en) | 2015-04-10 | 2019-06-04 | Commvault Systems, Inc. | Using a Unix-based file system to manage and serve clones to windows-based computing clients |
| US10503753B2 (en) | 2016-03-10 | 2019-12-10 | Commvault Systems, Inc. | Snapshot replication operations based on incremental block change tracking |
| US11947489B2 (en) * | 2017-09-05 | 2024-04-02 | Robin Systems, Inc. | Creating snapshots of a storage volume in a distributed storage system |
| US20190073270A1 (en) * | 2017-09-05 | 2019-03-07 | Robin Systems, Inc. | Creating Snapshots Of A Storage Volume In A Distributed Storage System |
| US10430105B2 (en) | 2017-09-13 | 2019-10-01 | Robin Systems, Inc. | Storage scheme for a distributed storage system |
| US10579276B2 (en) | 2017-09-13 | 2020-03-03 | Robin Systems, Inc. | Storage scheme for a distributed storage system |
| US10452267B2 (en) | 2017-09-13 | 2019-10-22 | Robin Systems, Inc. | Storage scheme for a distributed storage system |
| US10534549B2 (en) | 2017-09-19 | 2020-01-14 | Robin Systems, Inc. | Maintaining consistency among copies of a logical storage volume in a distributed storage system |
| US10423344B2 (en) | 2017-09-19 | 2019-09-24 | Robin Systems, Inc. | Storage scheme for a distributed storage system |
| US10782887B2 (en) | 2017-11-08 | 2020-09-22 | Robin Systems, Inc. | Window-based prority tagging of IOPs in a distributed storage system |
| US10846001B2 (en) | 2017-11-08 | 2020-11-24 | Robin Systems, Inc. | Allocating storage requirements in a distributed storage system |
| US10430110B2 (en) | 2017-12-19 | 2019-10-01 | Robin Systems, Inc. | Implementing a hybrid storage node in a distributed storage system |
| US10430292B2 (en) | 2017-12-19 | 2019-10-01 | Robin Systems, Inc. | Snapshot deletion in a distributed storage system |
| US10452308B2 (en) | 2017-12-19 | 2019-10-22 | Robin Systems, Inc. | Encoding tags for metadata entries in a storage system |
| US11392363B2 (en) | 2018-01-11 | 2022-07-19 | Robin Systems, Inc. | Implementing application entrypoints with containers of a bundled application |
| US11582168B2 (en) | 2018-01-11 | 2023-02-14 | Robin Systems, Inc. | Fenced clone applications |
| US11748203B2 (en) | 2018-01-11 | 2023-09-05 | Robin Systems, Inc. | Multi-role application orchestration in a distributed storage system |
| US10628235B2 (en) | 2018-01-11 | 2020-04-21 | Robin Systems, Inc. | Accessing log files of a distributed computing system using a simulated file system |
| US11099937B2 (en) | 2018-01-11 | 2021-08-24 | Robin Systems, Inc. | Implementing clone snapshots in a distributed storage system |
| US10642697B2 (en) | 2018-01-11 | 2020-05-05 | Robin Systems, Inc. | Implementing containers for a stateful application in a distributed computing system |
| US10896102B2 (en) | 2018-01-11 | 2021-01-19 | Robin Systems, Inc. | Implementing secure communication in a distributed computing system |
| US10579364B2 (en) | 2018-01-12 | 2020-03-03 | Robin Systems, Inc. | Upgrading bundled applications in a distributed computing system |
| US10642694B2 (en) | 2018-01-12 | 2020-05-05 | Robin Systems, Inc. | Monitoring containers in a distributed computing system |
| US10846137B2 (en) | 2018-01-12 | 2020-11-24 | Robin Systems, Inc. | Dynamic adjustment of application resources in a distributed computing system |
| US10845997B2 (en) | 2018-01-12 | 2020-11-24 | Robin Systems, Inc. | Job manager for deploying a bundled application |
| US10732885B2 (en) | 2018-02-14 | 2020-08-04 | Commvault Systems, Inc. | Block-level live browsing and private writable snapshots using an ISCSI server |
| US10976938B2 (en) | 2018-07-30 | 2021-04-13 | Robin Systems, Inc. | Block map cache |
| US11023328B2 (en) | 2018-07-30 | 2021-06-01 | Robin Systems, Inc. | Redo log for append only storage scheme |
| US10599622B2 (en) | 2018-07-31 | 2020-03-24 | Robin Systems, Inc. | Implementing storage volumes over multiple tiers |
| US10817380B2 (en) | 2018-07-31 | 2020-10-27 | Robin Systems, Inc. | Implementing affinity and anti-affinity constraints in a bundled application |
| US10908848B2 (en) | 2018-10-22 | 2021-02-02 | Robin Systems, Inc. | Automated management of bundled applications |
| US11036439B2 (en) | 2018-10-22 | 2021-06-15 | Robin Systems, Inc. | Automated management of bundled applications |
| US10620871B1 (en) | 2018-11-15 | 2020-04-14 | Robin Systems, Inc. | Storage scheme for a distributed storage system |
| US11086725B2 (en) | 2019-03-25 | 2021-08-10 | Robin Systems, Inc. | Orchestration of heterogeneous multi-role applications |
| US11256434B2 (en) | 2019-04-17 | 2022-02-22 | Robin Systems, Inc. | Data de-duplication |
| US10831387B1 (en) | 2019-05-02 | 2020-11-10 | Robin Systems, Inc. | Snapshot reservations in a distributed storage system |
| US10877684B2 (en) | 2019-05-15 | 2020-12-29 | Robin Systems, Inc. | Changing a distributed storage volume from non-replicated to replicated |
| US11042318B2 (en) | 2019-07-29 | 2021-06-22 | Commvault Systems, Inc. | Block-level data replication |
| US11226847B2 (en) | 2019-08-29 | 2022-01-18 | Robin Systems, Inc. | Implementing an application manifest in a node-specific manner using an intent-based orchestrator |
| US11520650B2 (en) | 2019-09-05 | 2022-12-06 | Robin Systems, Inc. | Performing root cause analysis in a multi-role application |
| US11249851B2 (en) | 2019-09-05 | 2022-02-15 | Robin Systems, Inc. | Creating snapshots of a storage volume in a distributed storage system |
| US11347684B2 (en) | 2019-10-04 | 2022-05-31 | Robin Systems, Inc. | Rolling back KUBERNETES applications including custom resources |
| US11113158B2 (en) | 2019-10-04 | 2021-09-07 | Robin Systems, Inc. | Rolling back kubernetes applications |
| US11403188B2 (en) | 2019-12-04 | 2022-08-02 | Robin Systems, Inc. | Operation-level consistency points and rollback |
| US11108638B1 (en) | 2020-06-08 | 2021-08-31 | Robin Systems, Inc. | Health monitoring of automatically deployed and managed network pipelines |
| US11528186B2 (en) | 2020-06-16 | 2022-12-13 | Robin Systems, Inc. | Automated initialization of bare metal servers |
| US11740980B2 (en) | 2020-09-22 | 2023-08-29 | Robin Systems, Inc. | Managing snapshot metadata following backup |
| US11743188B2 (en) | 2020-10-01 | 2023-08-29 | Robin Systems, Inc. | Check-in monitoring for workflows |
| US11456914B2 (en) | 2020-10-07 | 2022-09-27 | Robin Systems, Inc. | Implementing affinity and anti-affinity with KUBERNETES |
| US11271895B1 (en) | 2020-10-07 | 2022-03-08 | Robin Systems, Inc. | Implementing advanced networking capabilities using helm charts |
| US11750451B2 (en) | 2020-11-04 | 2023-09-05 | Robin Systems, Inc. | Batch manager for complex workflows |
| US11556361B2 (en) | 2020-12-09 | 2023-01-17 | Robin Systems, Inc. | Monitoring and managing of complex multi-role applications |
| US11809285B2 (en) | 2022-02-09 | 2023-11-07 | Commvault Systems, Inc. | Protecting a management database of a data storage management system to meet a recovery point objective (RPO) |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5151987A (en) * | 1990-10-23 | 1992-09-29 | International Business Machines Corporation | Recovery objects in an object oriented computing environment |
| US5317730A (en) * | 1991-01-11 | 1994-05-31 | International Business Machines Corporation | System for modifying persistent database based upon set of data elements formed after selective insertion or deletion |
| US5379398A (en) * | 1992-04-20 | 1995-01-03 | International Business Machines Corporation | Method and system for concurrent access during backup copying of data |
| US5761739A (en) * | 1993-06-08 | 1998-06-02 | International Business Machines Corporation | Methods and systems for creating a storage dump within a coupling facility of a multisystem enviroment |
| US5495607A (en) * | 1993-11-15 | 1996-02-27 | Conner Peripherals, Inc. | Network management system having virtual catalog overview of files distributively stored across network domain |
| US6202136B1 (en) * | 1994-12-15 | 2001-03-13 | Bmc Software, Inc. | Method of creating an internally consistent copy of an actively updated data set without specialized caching hardware |
| US5678024A (en) * | 1995-05-08 | 1997-10-14 | International Business Machines Corporation | Method and system for dynamic performance resource management within a computer based system |
| US5761626A (en) * | 1995-12-26 | 1998-06-02 | Ford Global Technologies, Inc. | System and method for distinguishing and characterizing motor vehicles for control of automatic drivers |
| US5852818A (en) * | 1996-12-23 | 1998-12-22 | Oracle Corporation | Non-recursive method for parameter evaluation within an information management system |
| US6230200B1 (en) * | 1997-09-08 | 2001-05-08 | Emc Corporation | Dynamic modeling for resource allocation in a file server |
| US6078990A (en) * | 1998-02-06 | 2000-06-20 | Ncr Corporation | Volume set configuration using a single operational view |
| US6052799A (en) * | 1998-05-15 | 2000-04-18 | International Business Machines Corporation | System and method for recovering a directory for a log structured array |
-
1997
- 1997-10-13 JP JP27915797A patent/JP4128641B2/ja not_active Expired - Fee Related
-
1998
- 1998-09-28 US US09/161,508 patent/US6311193B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6311193B1 (en) | 2001-10-30 |
| JPH11120055A (ja) | 1999-04-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4128641B2 (ja) | データ退避方法 | |
| US10289545B2 (en) | Hybrid checkpointed memory | |
| US7822932B2 (en) | Systems and methods for providing nonlinear journaling | |
| US7752402B2 (en) | Systems and methods for allowing incremental journaling | |
| US7899800B2 (en) | Systems and methods for providing nonlinear journaling | |
| US7676691B2 (en) | Systems and methods for providing nonlinear journaling | |
| US8280858B2 (en) | Storage pool scrubbing with concurrent snapshots | |
| US6738863B2 (en) | Method for rebuilding meta-data in a data storage system and a data storage system | |
| JP4292882B2 (ja) | 複数のスナップショット維持方法及びサーバ装置及びストレージ装置 | |
| US7035881B2 (en) | Organization of read-write snapshot copies in a data storage system | |
| KR101824295B1 (ko) | 솔리드 스테이트 장치 가상화를 포함하는 캐시 관리 | |
| US7774565B2 (en) | Methods and apparatus for point in time data access and recovery | |
| EP2176795B1 (en) | Hierarchical storage management for a file system providing snapshots | |
| US7885921B2 (en) | Managing atomic updates on metadata tracks in a storage system | |
| US7720801B2 (en) | System and method for supporting asynchronous data replication with very short update intervals | |
| US7849257B1 (en) | Method and apparatus for storing and retrieving data | |
| US8615641B2 (en) | System and method for differential backup | |
| US6629203B1 (en) | Alternating shadow directories in pairs of storage spaces for data storage | |
| US7472307B2 (en) | Recovery operations in storage networks | |
| Macko et al. | Smore: A cold data object store for smr drives (extended version) | |
| CN110134551B (zh) | 一种持续数据保护方法及装置 | |
| JP4394467B2 (ja) | ストレージシステム、サーバ装置及び先行コピーデータ生成方法 | |
| Kim et al. | Design of a Reliable NAND Flash Software for Mobile Device | |
| Kirk | Secondary Storage and Filesystems | |
| KR20160135608A (ko) | 상변화메모리의 영역별 역할을 고려한 마모도 평준화 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041013 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071218 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080207 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080325 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080415 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080513 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080515 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140523 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |