JP2005050024A - 計算機システムおよびプログラム - Google Patents
計算機システムおよびプログラム Download PDFInfo
- Publication number
- JP2005050024A JP2005050024A JP2003204507A JP2003204507A JP2005050024A JP 2005050024 A JP2005050024 A JP 2005050024A JP 2003204507 A JP2003204507 A JP 2003204507A JP 2003204507 A JP2003204507 A JP 2003204507A JP 2005050024 A JP2005050024 A JP 2005050024A
- Authority
- JP
- Japan
- Prior art keywords
- storage area
- log storage
- file system
- image
- 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.)
- Pending
Links
Images
Abstract
【課題】ファイルシステム上のデータ領域を圧迫することなく、且つファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行わずに、任意の時点のファイルシステムのイメージを効率よく復元する。
【解決手段】ファイルシステムの更新履歴を蓄積するためのログ記憶領域は、ファイルシステムとは独立した２次記憶装置１１６上の記憶領域に作成される。ファイルシステムのブロックが更新される度に、当該ブロックの更新前の内容およびブロック番号がログ記憶記憶領域に格納される。このため、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことなく、過去の所定の時点における前記ファイルシステムのイメージを復元することができる。さらに、ファイルシステムのデータ領域がログ記憶領域によって圧迫されるという事態の発生を防止することができる。
【選択図】 図２
【解決手段】ファイルシステムの更新履歴を蓄積するためのログ記憶領域は、ファイルシステムとは独立した２次記憶装置１１６上の記憶領域に作成される。ファイルシステムのブロックが更新される度に、当該ブロックの更新前の内容およびブロック番号がログ記憶記憶領域に格納される。このため、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことなく、過去の所定の時点における前記ファイルシステムのイメージを復元することができる。さらに、ファイルシステムのデータ領域がログ記憶領域によって圧迫されるという事態の発生を防止することができる。
【選択図】 図２
Description
【０００１】
【発明の属する技術分野】
本発明は過去のある所定の時点におけるファイルシステムのイメージを復元する処理を実行可能な計算機システムおよび同復元処理を実行するためのプログラムに関する。
【０００２】
【従来の技術】
一般に、サーバコンピュータなどとして利用される計算機システムにおいては、その計算機システムに障害が発生した場合でも、ファイルシステムの一貫性を保持することが必要とされる。また、ファイルシステムの容量が大きい場合でも、障害からの復旧に時間がかからないことも要求される。
【０００３】
近年、これらの要求を満たすファイルシステムが幾つか提案されている。例えば、従来では、コピーオンライト（ＣＯＷ）技術とロギング技術を用いることにより、システム障害時におけるファイルシステムの一貫性の保持と高速なリカバリを実現するファイルシステムが知られている（例えば、非特許文献１参照。）。
【０００４】
また、コピーオンライト（ＣＯＷ）技術とロギング技術に加え、ｉノードをファイルとしてディスク上の任意の位置に記録することによって、前述の特徴の他に、指定した時点でのファイルシステムのイメージを記録する技術も知られている（例えば、特許文献１参照。）。
【０００５】
これら従来の方法で使用されているコピーオンライト技術では、ｉノードなどのメタデータブロックやデータブロックを変更する時点でメタデータブロックやデータブロックを新規に作成し、作成したブロックに以前のブロックの内容をコピーし、コピーしたブロックの内容を変更するという方式を採用している。
【０００６】
【非特許文献１】
“Ｔｈｅ Ｅｐｉｓｏｄｅ Ｆｉｌｅ Ｓｙｓｔｅｍ” Ｓａｉｌｅｓｈ Ｃｈｕｔａｎｉ， Ｏｗｅｎ Ｔ． Ａｎｄｅｒｓｏｎ， Ｍｉｃｈａｅｌ Ｌ． Ｋａｚａｒ， Ｂｒｕｃｅ Ｗ． Ｌｅｖｅｒｅｔｔ， Ｗ． Ａｎｔｈｏｎｙ Ｍａｓｏｎ， Ｒｏｂｅｒｔ Ｎ． Ｓｉｄｅｂｏｔｈａｍ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｗｉｎｔｅｒ ＵＳＥＮＩＸ １９９２ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ， Ｊａｎ １９９２， ｐ．４３−５９
【０００７】
【特許文献１】
特表平８−５１１３６７号公報
【０００８】
【発明が解決しようとする課題】
しかし、この方式では、元のブロックの内容は変更されずにそのまま保持されるため、過去の時点のスナップショットを容易に保存することができる反面、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことが必要となる。
【０００９】
また実際には、更新対象のブロックのみならず、そのブロックを含むファイルまたはディレクトリの階層構造上の上位ディレクトリのブロックをも含めてコピーすることが必要となり、ファイル書き込み時のオーバーヘッドは非常に大きなものとなる。
【００１０】
さらに、ディスク上には、現在のファイルシステムのディレクトリ／ファイルに関する情報のみならず、ファイルシステムの更新処理の進行に伴って何世代にも渡るファイルシステムそれぞれに対応したディレクトリ／ファイルに関する情報が存在することとなる。よって、スナップショットを保存するためにファイルシステム上の多くのブロックが消費され、ファイルシステム上のデータ領域が圧迫されるという問題がある。
【００１１】
本発明は上述の事情を考慮してなされたものであり、ファイルシステム上のデータ領域を圧迫することなく、且つファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行わずに、指定された任意の時点のファイルシステムのイメージを効率よく復元することが可能な計算機システムおよびプログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
上述の課題を解決するため、本発明は、２次記憶装置上でファイルを階層構造で管理するファイルシステムを有する計算機システムにおいて、前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に、前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を作成するログ記憶領域作成手段と、前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手段と、前記ログ記憶領域に蓄積されている更新前イメージと前記ファイルシステムの現在のイメージとに基づいて、過去の所定の時点における前記ファイルシステムのイメージを復元する復元手段とを具備することを特徴とする。
【００１３】
この計算機システムにおいては、ファイルシステムで使用される２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号がログ記憶記憶領域に更新前イメージとして格納されるので、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことなく、例えば、ログ記憶領域に蓄積されている各更新ブロックの更新前データをファイルシステム上の対応するブロックの内容に反映させる操作をログ記憶領域の最後尾から行うことなどによって、ログ記憶領域に蓄積されている更新前イメージとファイルシステムの現在のイメージとに基づいて過去の所定の時点における前記ファイルシステムのイメージを復元することができる。さらに、ログ記憶領域はファイルシステムとは独立した２次記憶装置上の記憶領域上に作成されるので、ファイルシステムのデータ領域がログ記憶領域によって圧迫されるという事態の発生を防止することができる。
【００１４】
また、ファイルシステムのイメージを復元すべき隣接する２つの時点間を単位とする世代毎に当該世代の更新履歴に対応する更新前イメージが異なるログ記憶領域に格納されるように、世代別に異なるログ記憶領域を前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域に作成することが好ましい。このように世代別にログ記憶領域を作成して、世代毎に更新前イメージを異なるログ記憶領域に格納することにより、ファイルシステムの復元に使用すべき更新前イメージを容易に特定することが可能になる。さらに、例えば最も古い世代に対応するログ記憶領域を削除することで、復元処理に不要な世代の更新前イメージをログ記憶領域単位でまとめて削除することもできるので、２次記憶装置上の記憶領域の有効利用を図ることが出来る。
【００１５】
また、本発明は、２次記憶装置上でファイルを階層構造で管理するファイルシステムを有する計算機システムにおいて、前記計算機システムに前記２次記憶装置として設けられた全物理ディスクの記憶領域をボリュームグループとして管理し、前記計算機システムの稼働中に記憶領域を当該記憶領域のサイズを拡張可能な論理ボリュームとして動的に生成する論理ボリューム管理手段と、前記ファイルシステムの更新に関する世代別に異なるログ記憶領域が作成されるように、前記ファイルシステムのイメージを復元すべき時点に到達する度に、前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を前記論理ボリューム管理手段を用いて前記論理ボリュームとして動的に作成するログ記憶領域作成手段と、前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶領域作成手段によって作成された最新世代のログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手段と、前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域の残りサイズが所定値以下に低下した場合、前記最新世代のログ記憶領域のサイズを前記論理ボリューム管理手段を用いて拡張する手段と、前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域から、前記ファイルシステムのイメージを復元すべき時点として指定された過去の所定世代に対応するログ記憶領域に渡って蓄積されている更新前イメージと、前記ファイルシステムの現在のイメージとに基づいて、前記指定された世代に対応する前記ファイルシステムのイメージを復元する復元手段とを具備することを特徴とする。
【００１６】
一般に、多くのブロックが更新される世代ほどより大きなログ記憶領域が必要となるが、更新されるブロックの数を的確に予想することは難しい。このため、更新イメージデータ全てを該当する世代のログ記憶領域に格納できるようにするために、通常は、予め大きなサイズの記憶領域を余分に確保してことが必要となる。本発明では、ログ記憶領域を論理ボリュームを利用して作成することにより、ログ記憶領域の動的なサイズ拡張が可能であるので、予め大きなサイズの記憶領域を余分に確保せずとも、更新イメージデータ全てを該当する世代のログ記憶領域に格納することができる。よって、各世代のログ記憶領域のサイズを当該世代の更新ブロック数に応じたサイズに最適化することができ、２次記憶装置上の記憶領域の有効利用を図ることが出来る。
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。
図１には、本発明の一実施形態に係る計算機システムの構成が示されている。この計算機システムは、例えばサーバコンピュータなどのコンピュータシステムとして使用されるものである。このコンピュータシステム１１は、論理ボリューム管理部１１１、ファイル管理システム１１２、スナップショット管理部１１３、ログ記憶領域管理部１１４、ディスクコントローラ１１５、および二次記憶装置１１６を備えている。二次記憶装置１１６は例えばディスクアレイによって実現されている。このディスクアレイは複数の物理ディスクドライブから構成されている。ディスクアレイは、必要に応じて物理ディスクドライブを追加できるように構成されている。
【００１８】
論理ボリューム管理部１１１はコンピュータシステム１１に二次記憶装置１１６として設けられた全物理ディスクドライブの記憶領域をボリュームグループ（ストレージプールとも称する）として管理するプログラムであり、ファイルシステムやログ記憶領域のための記憶領域を論理ボリュームとして生成する。論理ボリュームは、コンピュータシステム１１の稼働中でも動的に生成、削除、サイズ拡張（縮小）することが可能な記憶領域であり、ボリュームグループ内の論理的な区画を用いて実現されている。この論理ボリューム管理部１１１は、例えば、論理ボリュームマネージャ（ＬＶＭ）と称されるプログラムによって実現されている。
【００１９】
ファイル管理システム１１２はファイルシステムを管理するためのプログラムである。ここで、ファイルシステムとは２次記憶装置１１６上でファイルを階層構造で管理するためのデータ構造である。このデータ構造の管理プログラムがファイル管理システム１１２（単にファイルシステムと称される場合もある）であり、ファイルシステムの生成、およびアプリケーションプログラム等からのＩ／Ｏ要求に応じたファイルアクセス操作を実行する。異なる論理ボリューム上にそれぞれファイルシステムを配置することにより、２次記憶装置１１６上には、複数種のファイルシステムを作成することができる。ファイル管理システム１１２は、論理ボリューム管理部１１１およびディスクコントローラ１１５を通じて、２次記憶装置１１６上の該当するファイルシステムをアクセスする。
【００２０】
スナップショット管理部１１３は２次記憶装置１１６上のファイルシステムを過去の任意の時点のイメージ（内容）に復元するためのプログラムであり、更新前情報取得部２０１とスナップショットイメージ生成部２０２を備えている。更新前情報取得部２０１は、ファイルシステムによって利用される２次記憶装置１１６上の記憶領域内のブロック（ｉノードなどのメタデータブロック、およびデータブロック）の更新が行われる度に、そのブロックの更新前の内容をブロック番号等の更新管理情報と一緒に更新前イメージとして、２次記憶装置１１６上に作成されたログ記憶領域にスタック形式で格納する。スナップショットイメージ生成部２０２は、ログ記憶領域に蓄積された更新前イメージと、ファイルシステムの現在のイメージとに基づいて、ファイルシステムの過去の任意の時点のイメージを示すスナップショットを生成する。スナップショットは、例えば、ログ記憶領域に蓄積されている各更新ブロックの更新前データをファイルシステム上の対応するブロックの内容に反映させる操作をログ記憶領域の最後尾から行うことによって生成される。
【００２１】
ログ記憶領域はファイルシステムの更新履歴を蓄積するための記憶領域である。このログ記憶領域はファイルシステムのデータ領域がログ記憶領域によって圧迫されるという事態の発生を防止するために、ファイルシステムとは独立した２次記憶装置１１６上の記憶領域に作成されている。すなわち、ログ記憶領域はファイルシステムが配置される論理ボリュームとは異なる別の論理ボリュームから構成されており、ファイルシステムの稼働中に動的にログ記憶領域の生成、削除、サイズ変更を行うことができる。
【００２２】
ログ記憶領域管理部１１４は論理ボリューム管理部１１１を用いてログ記憶領域を管理するプログラムであり、ログ記憶領域作成部３０１、ログ記憶領域サイズ変更部３０２、およびログ記憶領域削除部３０３を有している。ログ記憶領域作成部３０１は、論理ボリューム管理部１１１を用いてログ記憶領域を任意の時点に論理ボリュームとして動的に作成するプログラムである。このログ記憶領域作成部３０１は、ファイルシステムの更新に関する世代別に異なるログ記憶領域を作成する機能を有している。すなわち、ログ記憶領域作成部３０１は、ファイルシステムのイメージを復元すべき隣接する２つの時点間を単位とする世代毎に、当該世代の更新履歴に対応する更新前イメージが異なるログ記憶領域に格納されるように、世代別に異なるログ記憶領域をファイルシステムとは独立した２次記憶装置１１６上の記憶領域に作成する。
【００２３】
ログ記憶領域サイズ変更部３０２は、ログ記憶領域作成部３０１によって作成されたログ記憶領域のサイズを論理ボリューム管理部１１１を用いて動的に拡張するための処理を実行する。すなわち、ログ記憶領域サイズ変更部３０２は、更新前イメージの格納に現在使用されている最新世代のログ記憶領域の残りサイズが所定値以下に低下した場合、当該最新世代のログ記憶領域のサイズを論理ボリューム管理部１１１を用いて拡張する。
【００２４】
ログ記憶領域削除部３０３はログ記憶領域作成部３０１によって作成されたログ記憶領域を論理ボリューム管理部１１１を用いて動的に削除するための処理を実行する。例えば、ログ記憶領域削除部３０３は、ログ記憶領域作成部３０１によって世代別に作成されたログ記憶領域の数が所定の世代数分に到達した時に、不要となる最も古い世代に対応するログ記憶領域を論理ボリューム管理部１１１を用いて削除する。
【００２５】
次に、図２を参照して、２次記憶装置１１６上に設けられるファイルシステムとログ記憶領域の内容について説明する。
【００２６】
上述したように、２次記憶装置１１６を構成する全物理ディスクドライブの記憶領域は論理ボリューム管理部１１１によってボリュームグループ１００として管理されている。論理ボリューム管理部１１１は、新規作成要求されたサイズの論理的な区画の記憶領域をボリュームグループ１００から切り出して論理ボリュームとして要求元に割り振ることにより、作成要求に応じて論理ボリュームを個々に作成することができる。ボリュームグループ１００のサイズは、２次記憶装置１１６に物理ディスクドライブを追加することによって動的に拡張される。
【００２７】
図２においては、２つのファイルシステムがそれぞれ論理ボリュームとして実現されている場合が示されている。また、ログ記憶領域もそれぞれ世代毎に異なる論理ボリュームによって実現される。図２においては、世代１〜３の３世代分のログ記憶領域Ｓ１〜Ｓ３がそれぞれ異なる論理ボリュームとして実現されている場合が示されている。
【００２８】
ここで、ファイルシステムのデータ構造について説明する。ファイルシステムの記憶領域は複数のブロックに分割されている。各ブロックのデータサイズは例えば５１２バイトである。以下では、ＵＮＩＸ（Ｒ）のファイルシステムを例示してその構成を説明することとする。
ファイルシステムを管理するために、その記憶領域上には、図示のように、ブートブロック、スーパーブロック、ｉノードリスト領域、およびデータ領域が割り当てられている。ブートブロックは、ブートローダプログラムの格納に使用される領域である。スーパーブロックは、空きブロックのリストなどの情報を格納するために利用される。ｉノードリスト領域は、ファイルシステム内の個々のファイル／ディレクトリに関する情報を保持するｉノードの集合を格納するためのブロック群である。ｉノードは、それに対応する個々のファイル／ディレクトリを管理するためのデータ構造である。ｉノードには、それに対応するファイル（ディレクトリもファイルの一種である）に関する管理情報として、１）ファイルの種類（通常ファイル、ディレクトリファイル等）、２）アクセス権、３）ファイルを構成する個々のブロックのブロック番号を示すアドレス情報、等が保持されている。
【００２９】
ｉノードが格納された個々のｉノードブロックは、それに対応するｉノード番号によって参照される。ｉノード番号はファイルシステム内の個々のファイル／ディレクトリを一意に識別するためのファイル識別子であり、対応するファイル／ディレクトリのｉノードを索引するためのインデックスとして使用される。データ領域は、ファイル／ディレクトリの実体が保持されるブロック群である。ディレクトリを保持するブロックには、当該ディレクトリに対応するｉノード番号、およびその上位ディレクトリに対応するｉノード番号に加え、当該ディレクトリ内に属する各ファイルまたはディレクトリに対応するｉノード番号がディレクトリ情報として含まれている。
【００３０】
次に、ログ記憶領域の構造について説明する。各世代のログ記憶領域は、管理情報記憶領域と、更新前データイメージ記憶領域とに分割されている。上述の更新前情報取得部２０１は、ファイルシステム上のｉノードブロックやデータブロックの内容が更新される際に、そのブロックの更新前データを更新前データイメージ記憶領域に書き込むと共に、当該ブロックを含むファイルまたはディレクトリを識別するための識別子（ｉノード番号）、当該ブロックのブロック番号、およびブロックの更新種別（変更、削除、追加等）を示すフラグなどを含む更新管理情報を管理情報記憶領域に書き込む。
【００３１】
なお、ログ記憶領域はスナップショット作成対象のファイルシステム毎に作成される。以下では、スナップショット作成対象のファイルシステムをターゲットファイルシステムと称することとする。
【００３２】
図３には、ターゲットファイルシステムＴ１とそれに対応するログ記憶領域との関係が示されている。
本実施形態においては、ターゲットファイルシステムＴ１のイメージを復元すべきポイント、すなわちターゲットファイルシステムＴ１のスナップショットを作成すべき時点毎に、新たな世代のログ記憶領域が新規作成され、次のポイントが到来するまでの間に行われたファイル更新に対応する更新前イメージ（更新前データ、および更新管理情報）が当該世代のログ記憶領域に蓄積される。この場合、同一ブロックの更新に際してはその更新前イメージをログ記憶領域に逐次採取する必要はなく、スナップショットを作成すべき各時点を基準に、それ以降に最初に更新が行われる際にのみ当該更新に関する更新前イメージが対応するログ記憶領域に採取される。このため、例えばある一定の時間間隔毎にスナップショットを作成すべき時点を設定した場合であっても、ログ記憶領域に採取される更新前イメージのデータ量は世代毎に異なることとなる。そこで、本実施形態では、ログ記憶領域の新規作成時には、予め決められた必要最低限の小さなサイズのログ記憶領域を論理ボリュームとして作成し、必要に応じて当該ログ記憶領域のサイズを動的に拡張するという方式を用いる。これにより、新規作成時の初期設定エリアのサイズはどの世代のログ記憶領域も同じであるが、世代によっては初期設定エリアに拡張エリアが動的に追加設定されることにより、最終的なサイズは世代毎に異なることになる。よって、更新前イメージの格納に使用されない領域が無駄に確保されてしまうことを効率よく防止することが可能となる。
【００３３】
スナップショットは、更新前イメージの格納に現在使用されている最新世代のログ記憶領域から、ターゲットファイルシステムＴ１のイメージを復元すべき時点として指定された過去の所定世代に対応するログ記憶領域に渡って蓄積されている更新前イメージと、ターゲットファイルシステムＴ１の現在のイメージとに基づいて、生成される。つまり、本実施形態においては、世代別にログ記憶領域を作成して、世代毎に更新前イメージを異なるログ記憶領域に格納しているので、ターゲットファイルシステムＴ１のイメージを復元可能な時点とログ記憶領域の世代とは１対１で対応している。よって、更新前イメージ単位で時間管理をせずとも、指定された過去の時点のファイルシステムの復元に使用すべき更新前イメージを容易に特定することが可能になる。さらに、例えば最も古い世代に対応するログ記憶領域を削除することで、復元処理に不要な世代の更新前イメージをログ記憶領域単位でまとめて削除することもできるので、２次記憶装置１１６上の記憶領域の有効利用を図ることが出来る。
【００３４】
次に、図４を参照して、ターゲットファイルシステムとログ記憶領域とを対応づけるためのログ記憶領域管理テーブルについて説明する。
図４に示されているように、ログ記憶領域管理部１１４は、ログ記憶領域管理テーブル５０１を用いてターゲットファイルシステムとログ記憶領域との関係を管理するものであり、ターゲットファイルシステム毎にそれに対応するログ記憶領域の管理情報を保持する。すなわち、ログ記憶領域管理部１１４には、ターゲットファイルシステムを識別するためのファイルシステムＩＤが登録されるエントリが設けられると共に、そのエントリに後続して、当該ターゲットファイルシステムに対応する各世代のログ記憶領域を管理するための管理情報（世代番号、ログ記憶領域名、ログ記憶領域サイズ、ログ記憶領域の使用サイズ）が登録される複数のエントリが設けられる。ターゲットファイルシステムＴ１に対するログ記憶領域として２世代目のログ記憶領域Ｓ２が作成された場合には、図５に示すように、２世代目のログ記憶領域Ｓ２の管理情報が１世代目のログ記憶領域Ｓ１の管理情報に追加される。ログ記憶領域管理テーブル５０１は、例えば、ターゲットファイルシステムＴ１の記憶領域内にファイルなどとして記録することができる。この場合、ログ記憶領域管理テーブル５０１は、システム動作時に必要に応じてメモリ上にロードされる。ターゲットファイルシステムＴ１がシステムに新規に追加された時点では、Ｔ１に対応するログ記憶領域は存在せず、したがってログ記憶領域管理テーブル５０１にもＴ１のエントリは登録されていない。
【００３５】
ターゲットファイルシステムＴ１のスナップショットを取る場合には、まず、１世代目のログ記憶領域Ｓ１を生成し、そしてログ記憶領域管理テーブル５０１にターゲットファイルシステムＴ１のエントリを追加すると共に、それに後続してログ記憶領域Ｓ１の管理情報を登録する（図４）。この時点でのログ記憶領域サイズは予め決められた初期設定エリアのサイズである。スナップショットを作成すべき次の時点が到来すると、２世代目のログ記憶領域Ｓ２が生成され、そしてログ記憶領域管理テーブル５０１にログ記憶領域Ｓ２の管理情報が追加登録される（図５）。
【００３６】
ここでは、新世代のログ記憶領域を新規に生成するときにその分の領域がログ記憶領域管理テーブル５０１に動的に確保される場合を説明したが、ログ記憶領域を生成するタイミングや生成時のサイズ、及び同時に何世代分のログ記憶領域を生成するかは任意である。例えば、ターゲットファイルシステムを作成する時に、これと同時に数世代分のログ記憶領域を生成しておくことも可能である。また、カレントファイルシステムに対して、一番最初のログの保存要求が発生した時点で、動的に生成することも可能である。また世代数に制限を設ける場合等においては、予め世代数の上限分のエントリを静的にログ記憶領域管理テーブル５０１にまとめて確保しておいてもよい。
【００３７】
図６には、３世代分のログ記憶領域Ｓ１，Ｓ２，Ｓ３にそれぞれ更新前イメージ（更新前情報）が蓄積されている様子が示されている。スナップショットを作成可能な時点をＴＩＭＥ１，ＴＩＭＥ２，ＴＩＭＥ３，…とする。例えば、２４時間ノンストップで稼働するコンピュータシステムにおいて、毎日１２：００の時点におけるスナップショットを生成可能にする場合、２４時間間隔でＴＩＭＥ１，ＴＩＭＥ２，ＴＩＭＥ３が設定され、その設定時間に到達する度に新たな世代のログ記憶領域が新規作成される。ＴＩＭＥ１でログ記憶領域Ｓ１が作成されてから、ＴＩＭＥ２でログ記憶領域Ｓ２が作成されるまでの期間中においては、ターゲットファイルシステムＴ１に対するブロック更新が行われる度に、その更新前イメージが現時点で最新のログ記憶領域Ｓ１に格納される。同様にして、ＴＩＭＥ２でログ記憶領域Ｓ２が作成されてから、ＴＩＭＥ３でログ記憶領域Ｓ３が作成されるまでの期間中においては、ターゲットファイルシステムＴ１に対するブロック更新が行われる度に、その更新前イメージが現時点で最新のログ記憶領域Ｓ２に格納される。また、ＴＩＭＥ３（例えば本日の１２：００の時点）で、ログ記憶領域Ｓ３が作成されてから、本日の現在時点（カレントタイム）までの期間中においては、ターゲットファイルシステムＴ１に対するブロック更新が行われる度に、その更新前イメージが現時点で最新のログ記憶領域Ｓ３に格納される。
【００３８】
本日の１２：００の時点におけるスナップショットを生成する場合には、ＴＩＭＥ３以降からカレントタイムまでに最新世代のログ記憶領域Ｓ３に蓄積された更新前イメージ（更新前情報）が最後尾（最も後に蓄積された更新前イメージ）から順に用いられる。また、昨日の１２：００の時点（ＴＩＭＥ２）におけるスナップショットを生成する場合には、最新世代のログ記憶領域Ｓ３と１世代前のログ記憶領域Ｓ２との２世代分のログ記憶領域が用いられる。すなちわ、最新世代のログ記憶領域Ｓ３に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられ、次いで１世代前のログ記憶領域Ｓ２に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられる。一昨日の１２：００の時点（ＴＩＭＥ１）におけるスナップショットを生成する場合には、最新世代のログ記憶領域Ｓ３、１世代前のログ記憶領域Ｓ２、および２世代前のログ記憶領域Ｓ１の３世代分のログ記憶領域が用いられる。すなちわ、最新世代のログ記憶領域Ｓ３に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられ、次いで１世代前のログ記憶領域Ｓ２に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられ、最後に２世代前のログ記憶領域Ｓ２に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられる。
【００３９】
なお、スナップショットを生成すべきタイミングは予め設定された時刻の到来によって指定するのみならず、例えば管理者などによる所定の入力操作によって現時点がファイルシステムのスナップショットを生成すべき時点であることを明示的に指定するようにしてもよい。このように、スナップショットを生成すべきタイミングは、任意のログ作成イベントによって指定することができる。
【００４０】
次に、図７のフローチャートを参照して、ログ記憶領域を世代別に作成し、そこに更新前イメージを格納する処理の手順を説明する。
【００４１】
ログ記憶領域管理部１１４は予め指定された時間の到来や所定の入力操作などのログ作成イベントの発生の有無を監視しており、ログ作成イベントが発生すると（ステップＳ１のＹＥＳ）、ログ記憶領域を作成する（ステップＳ２）。このステップＳ２では、ログ記憶領域管理部１１４のログ記憶領域作成部３０１から論理ボリューム管理部１１１に対して論理ボリュームの作成要求が発行され、これによってログ記憶領域が論理ボリュームとして作成される。ターゲットファイルシステムについての最初のログ作成イベントであれば１世代目のログ記憶領域Ｓ１が最新世代のログ記憶領域として作成され、またターゲットファイルシステムについての２回目のログ作成イベントであれば２世代目のログ記憶領域Ｓ２が最新世代のログ記憶領域として作成されることになる。
【００４２】
ログ記憶領域の作成後、ログ記憶領域管理部１１４は、当該作成したログ記憶領域に対応する管理情報をログ記憶領域管理テーブル５０１に登録する（ステップＳ３）。このステップＳ３では、当該作成したログ記憶領域の所在を、更新前イメージの格納対象となる最新世代のログ記憶領域としてスナップショット管理部１１３に通知する処理も行われる。
【００４３】
ターゲットファイルシステムの記憶領域上のブロック更新要求が発生すると（ステップＳ４のＹＥＳ）、ブロック更新要求が発生したことが、例えば、ログ記憶領域管理部１１４を通じてファイル管理システム１１２からスナップショット管理部１１３に通知される。スナップショット管理部１１３の更新前情報取得部２０１は、論理ボリューム管理部１１１およびディスクコントローラ１１５を介して更新対象のブロックの更新前データを２次記憶装置１１６から取得し、それを当該ブロックのブロック番号、当該ブロックを含むファイル／ディレクトリのｉノード番号等の管理情報と一緒に、最新世代のログ記憶領域に格納するログ書き出し処理を実行する（ステップＳ５）。このログ書き出し処理では、ログ記憶領域管理部１１４によって、ログ記憶領域管理テーブル５０１に登録されている「ログ記憶領域の使用サイズ」の値を更新する処理も併せて実行される。ブロック更新要求が発生したブロックのブロック番、および当該ブロックを含むファイル／ディレクトリのｉノード番号などは、ログ記憶領域管理部１１４を通じて、あるいは直接的にファイル管理システム１１２からスナップショット管理部１１３に通知される。ログ記憶領域へログの書き出し処理終了後に、ファイル管理システム１１２によって更新対象のブロックに対する更新処理が実行される（ステップＳ６）。
【００４４】
次に、図８を参照して、ログ記憶領域のサイズを動的に拡張する処理の手順を説明する。
ブロック更新要求（ログ書き出し要求）が発生すると（ステップＳ１１）、ログ記憶領域管理部１１４は、更新前イメージの格納に現在使用されている最新世代のログ記憶領域に対応するログ記憶領域管理テーブル５０１を参照して、「ログ記憶領域サイズ」の値と「ログ記憶領域の使用サイズ」の値とを比較することにより、当該最新世代のログ記憶領域の残りサイズが一定値以下であるか否かを判断する（ステップＳ１２）。残りサイズが一定値以下であれば（ステップＳ１２のＹＥＳ）、ログ記憶領域管理部１１４のログ記憶領域サイズ変更部３０２は、ログ記憶領域のサイズの拡張を論理ボリューム管理部１１１に要求することにより、論理ボリュームから構成される当該ログ記憶領域のサイズを拡張する（ステップＳ１３）。このステップＳ１３では、ボリュームグループ１００内の未使用の所定サイズの記憶領域が、サイズ拡張が要求されたログ記憶領域を構成する論理ボリュームに追加設定される。これにより、ログ記憶領域のサイズは動的に拡張される。また、ログ記憶領域管理テーブル５０１の「ログ記憶領域サイズ」の値の更新も行われる。この後、ログ記憶領域管理部１１４は、スナップショット管理部１１３に対してログ書き出し処理の実行を指示する（ステップＳ１４）。
【００４５】
次に、図９のフローチャートを参照して、ログ記憶領域を動的に削除する処理について説明する。
ログ記憶領域の削除は、ログ記憶領域作成部３０１によって世代別に作成されたログ記憶領域の数が所定の世代数分に到達した時に実行される。例えば、スナップショットを作成可能な時点を現時点から３世代前までの時点までに制限するシステムにおいては、４世代目のログ記憶領域が作成された時に、１世代目のログ記憶領域の内容は不要となる。このような場合に、１世代目のログ記憶領域の削除処理が自動的に実行される。
【００４６】
図９のフローチャートにおいては、不要なログ記憶領域を削除するために、図７で説明したステップＳ２，Ｓ３の処理の後に、ステップＳ２１，Ｓ２２が追加されている。すなわち、ログ記憶領域管理部１１４は、新たな世代のログ記憶領域の新規作成およびログ記憶領域管理テーブル５０１への登録を行った後（ステップＳ２，Ｓ３）、ログ記憶領域管理テーブル５０１を参照することによって、世代別に作成されたログ記憶領域の数が所定の世代数分に到達したか否か、つまり新たな世代のログ記憶領域の新規作成によって不要となる最古の世代のログ記憶領域（例えば、３世代前のログ記憶領域）が存在するかどうかを判断する（ステップＳ２１）。存在するならば、ログ記憶領域管理部１１４のログ記憶領域削除部３０３は、該当するログ記憶領域の削除を論理ボリューム管理部１１１に要求することによって、該当するログ記憶領域を削除する（ステップＳ２２）。このステップＳ２２では、削除要求されたログ記憶領域を構成する論理ボリュームの削除が論理ボリューム管理部１１１によって実行され、そしてその記憶領域がボリュームグループ１００に未使用領域として戻される。
【００４７】
以上のように、本実施形態においては、ファイルシステムで使用される２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号がログ記憶記憶領域に更新前イメージとして格納されるので、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことなく、例えば、ログ記憶領域に蓄積されている各更新ブロックの更新前データをファイルシステム上の対応するブロックの内容に反映させる操作をログ記憶領域の最後尾から行うことなどによって、ログ記憶領域に蓄積されている更新前イメージとファイルシステムの現在のイメージとに基づいて過去の所定の時点における前記ファイルシステムのイメージを復元することができる。また、ログ記憶領域を、ターゲットファイルシステムとは別に設けることにより、ターゲットファイルシステムのデータ領域を圧迫することなく、更新履歴を保存することが可能となる。またログのデータ量が増大した場合には、ログ記憶領域を動的に拡大することで、ログのデータ量を任意に伸ばすことが可能となるので、１世代当たりの変更ブロック数を制限する必要がなくなる。さらに、ログ記憶領域として、任意の時点での生成、削除、サイズ変更が可能な論理ボリュームを用いることにより、スナップショットの世代の追加・削除・ログ記憶領域サイズの拡大などの管理が容易になるという効果が得られる。
【００４８】
次に、ログ書き出し処理及びスナップショット生成に関する具体例について説明する。
まず、図１０および図１１を参照して、ログ書き出し処理の例について説明する。ここでは、図１０のようなツリー構造のファイルシステムにおいて、ディレクトリａの配下に存在するファイルｂの内容を更新する場合について説明する。
図１１は、２次記憶装置１１２上に構築されたファイルシステムのデータ構造を示している。
ｉノードリスト領域には、ルートディレクトリのｉノード、ディレクトリａのｉノード、ファイルｂのｉノード、等が存在し、またデータ領域には、ルートディレクトリ、ディレクトリａ、ファイルｂそれぞれの実体を記憶したデータブロックが存在する。
【００４９】
通常、ファイルは１以上のデータブロックから構成されており、ファイルｂの管理情報を保持する管理情報ブロックであるｉノードブロックには、ファイルｂのデータの実体を構成しているデータブロックそれぞれのブロック番号（ここでは、ブロック番号９８、１００、１１０）へのリンクを持つポインタがアドレス情報として含まれている。
【００５０】
同様に、ルートディレクトリのｉノードブロックにはルートディレクトリのディレクトリ情報を保持するデータブロックを示すブロック番号が含まれており、そのルートディレクトリのデータブロック内にはそのカレントディレクトリであるルートディレクトリのｉノードブロックを示すｉノード番号（ここでは、３）と、その配下に存在するディレクトリａのｉノードブロックを示すｉノード番号（ここでは、４）がディレクトリ情報として含まれている。
【００５１】
また、ディレクトリａの管理情報を保持するｉノードブロックにはディレクトリａのデータブロックを示すブロック番号が含まれており、そのディレクトリａのデータブロック内には、その上位ディレクトリであるルートディレクトリのｉノードブロックを示すｉノード番号（ここでは、３）と、カレントディレクトリであるディレクトリａのｉノードブロックを示すｉノード番号（ここでは、４）と、ディレクトリａ配下のファイルｂのｉノードブロックを示すｉノード番号（ここでは、５）がディレクトリ情報として含まれている。
【００５２】
いま、ｉノード番号５に対応するファイルｂ内のブロック１００を更新する場合を考える。この場合、ブロック１００の更新に先立ち、ファイルｂのｉノード番号５、更新対象のブロック番号１００、および更新種別が変更であることを示すフラグ情報（Ｍ）からなる更新管理情報と、ブロック１００の更新前データとが最新世代のログ記憶領域、例えばＳ１、に格納される。
【００５３】
図１２のフローチャートには、ファイル／ディレクトリの更新時にコンピュータシステム１１によって実行される一連の処理手順が示されている。
【００５４】
ファイル管理システム１１２は、オペレーティングシステムやアプリケーションプログラムからのファイル操作要求等によってファイル／ディレクトリの内容を更新する必要が生じた場合（ステップＳ１０１のＹＥＳ）、まず、当該更新対象のファイル／ディレクトリのファイル／ディレクトリ名からそれに対応するｉノード番号をサーチし、その更新対象のファイル／ディレクトリのｉノードブロックを取得する（ステップＳ１０２）。
【００５５】
次いで、ファイル管理システム１１２は、取得したｉノードブロックに含まれるアドレス情報から更新対象のファイル／ディレクトリの実体を保持する各データブロックを認識する（ステップＳ１０３）。ｉノード番号５に対応するファイルｂ内のブロック１００を更新する場合を考える。この場合、ファイル管理システム１１２は、ｉノード番号５に対応するファイルｂ内のブロック１００を更新することを、ログ記憶領域管理部１１４を通じて、あるいは直接に、スナップショット管理部１１３に通知する。スナップショット管理部１１３は、更新前情報取得部２０１を用いて、更新管理情報（ｉノード番号＝５、ブロック番号＝１００、フラグ情報＝Ｍ）と、ブロック番号１００のブロックの更新前の内容とを、更新前イメージとしてログ記憶領域に書き込む（ステップＳ１０４，Ｓ１０５）。ログ記憶領域に書き出している途中でブロック１００の内容が変更されるのを防ぐため、ログ記憶領域への書き込みを実行する前にブロック１００をロックする。ログ記憶領域への書き込みが終了すると、ブロック１００のロックを解除する。
【００５６】
この後、ファイル管理システム１１２は、ブロック番号１００のブロックの内容を例えばｂからｂ’に更新する（ステップＳ１０６）。この更新により、ファイルシステムは常に最新の状態に維持される。
【００５７】
次に、図１３を参照して、ファイルシステムの現在のイメージとログ記憶領域Ｓ１の更新前イメージとを利用してスナップショットを作成する処理の例について説明する。
ログ記憶領域Ｓ１に蓄積されている更新前イメージの更新管理情報から、ｉノード番号５に対応するファイルｂのブロック１００が更新されたことが判る。
【００５８】
（１）変更前のファイルｂ用のデータブロックの作成
ここでは、更新されたブロック１００に代わる新たなブロックを作成するために、ファイルシステムのデータ領域上に空きブロック（ここでは、ブロック番号１７０）を確保し、ログ記憶領域Ｓ１に記憶されているブロック１００の更新前データｂをブロック番号１７０にコピーする。
【００５９】
（２）変更前のファイルｂ用のｉノードブロックの作成
次いで、変更前のファイルｂに対応する新たなｉノードブロックを生成するために、ｉノードリスト領域上に空きブロックを確保する。そして、更新されたファイルｂを管理するための管理情報を保持するファイルｂの現在のｉノードブロックの内容をファイルシステムから取得する。取得したファイルｂのｉノードブロックに含まれる管理情報の内、更新されたブロック１００へのリンクを示すアドレス情報は修正され、ブロック番号１７０へのリンクを示すように書き換えられる。修正された管理情報は、ｉノードリスト領域上に確保された空きブロックに書き込まれ、これによってブロック番号９８、１７０、１１０から構成される変更前のファイルｂを管理するためのｉノードブロック、つまり現在のファイルｂのｉノードブロックに代わる、１世代前のファイルｂ（−）に対応するｉノードブロック、が生成される。１世代前のファイルｂ（−）には新たなｉノード番号（ここでは、３０）が割り当てられる。
【００６０】
（３）（４）変更前のファイルｂを含む上位ディレクトリのディレクトリ情報の復元
次に、変更前のファイルｂを含む上位ディレクトリａのディレクトリ情報の復元が行われる。まず、上位ディレクトリａのディレクトリ情報を保持する現在のディレクトリａのデータブロックに代わる新たなデータブロックを作成するために、データ領域上に空きブロックを確保する。そして、ディレクトリａの現在のデータブロックの内容をファイルシステムから取得する。取得したディレクトリａのディレクトリ情報の内、その配下に存在する現在のファイルｂのｉノードブロックへのリンクを示すアドレス情報については修正され、変更前のファイルｂ（−）のｉノードブロックへのリンクを示すように書き換えられる。すなわち、現在のファイルｂのｉノードブロックを示すｉノード番号５から、１世代前のｂ（−）のｉノードブロックを示すｉノード番号３０に変更される。
【００６１】
修正されたディレクトリ情報は、データ領域上の空きブロックに書き込まれ、これによって変更前のファイルｂ（−）を含む上位ディレクトリａ（−）のデータブロックが生成される。
【００６２】
また、ｉノードリスト領域上の空きブロックを用いて、上位ディレクトリａ（−）のｉノードブロックも生成される。この場合、ディレクトリａの現在のｉノードブロックの管理情報をカレントファイルシステムから取得する。取得したディレクトリａの管理情報の内、現在のディレクトリａのブロックへのリンクを示すアドレス情報については修正され、ディレクトリａ（−）のデータブロックへのリンクを示すように書き換えられる。修正された管理情報は、ｉノードリスト領域上に確保された空きブロックに書き込まれ、これによって１世代前のディレクトリａ（−）のｉノードブロックが生成される。この１世代前のディレクトリａ（−）には、新たなｉノード番号（ここでは、２９）が割り当てられる。
【００６３】
ディレクトリａ（−）のデータブロックに保持されているカレントディレクトリのｉノード番号は、現在のディレクトリａのｉノード番号４から、ディレクトリａ（−）のｉノード番号２９に変更される。
【００６４】
（５）（６）次に、最上位のディレクトリである現在のルートディレクトリに代わる新たなルートディレクトリのデータブロックを作成するために、ファイルシステムのデータ領域上に空きブロックを確保する。そして、ルートディレクトリの現在のデータブロックの内容をファイルシステムから取得する。取得したルートディレクトリのディレクトリ情報の内、その配下に存在する現在のディレクトリａのｉノードブロックへのリンクを示すアドレス情報については修正され、１世代前のディレクトリａ（−）のｉノードブロックへのリンクを示すように書き換えられる。すなわち、現在のディレクトリａのｉノードブロックを示すｉノード番号４から、１世代前のａ（−）のｉノードブロックを示すｉノード番号２９に変更される。修正されたディレクトリ情報は、データ領域上の空きブロックに書き込まれ、これによって１世代前のルートディレクトリ（−）のブロックが生成される。
【００６５】
また、ｉノードリスト領域上の空きブロックを用いて、１世代前のルートディレクトリ（−）のｉノードブロックも生成される。この場合、現在のルートディレクトリのｉノードブロックの管理情報をカレントファイルシステムから取得する。取得したルートディレクトリの管理情報の内、現在のルートディレクトリのブロックへのリンクを示すアドレス情報については修正され、１世代前のルートディレクトリ（−）のブロックへのリンクを示すように書き換えられる。修正された管理情報は、ｉノード領域上の空きブロックに書き込まれ、これによって１世代前のルートディレクトリ（−）のｉノードブロックが生成される。この１世代前のルートディレクトリ（−）には、新たなｉノード番号（ここでは、２８）が割り当てられる。ルートディレクトリ（−）のデータブロックに保持されているカレントディレクトリのｉノード番号は、現在のルートディレクトリのｉノード番号３から、ルートディレクトリ（−）のｉノード番号２９に変更される。
【００６６】
このようにして、空きブロックを用いて変更前のファイルに対応するブロックとその上位ディレクトリに関するブロックとを作成することによって、更新されたファイルの更新前の内容と、当該変更前のファイルを含む上位ディレクトリのディレクトリ情報とを復元することにより、現在のファイルシステムのイメージをそのまま維持した状態で、過去の任意の時点のファイルシステムのイメージを示すスナップショットを生成することが可能となる。
【００６７】
図１４のフローチャートには、スナップショット生成時にスナップショット生成部２０２によって実行される一連の処理手順が示されている。
【００６８】
スナップショット生成部２０２は、最新世代のログ記憶領域の最後尾から、復元対象の世代に対応するログ記憶領域の先頭に渡って記憶されている更新前イメージを順に取得し（ステップＳ１１１）、そして指定された時点のスナップショットに関する全ての更新前イメージに対する処理が完了するまで、各更新前イメージ毎に以下の処理を再帰的に実行する（ステップＳ１１２）。
【００６９】
まず、スナップショット生成部２０２は、取得した更新前イメージの内容から、どのファイル／ディレクトリにおけるどのブロックが更新されたのかを認識し、その更新されたファイル／ディレクトリに対応する変更前のファイル／ディレクトリを復元するためのデータブロック（変更前ファイル／ディレクトリ用データブロック）をデータ領域上に新規作成する（ステップＳ１１３）。
【００７０】
例えば、上述の例では、ｉノード番号５に関連するファイルｂのブロック１００の内容が更新されたことがわかるので、更新されたブロック１００に代わる変更前ファイル／ディレクトリ用データブロックを空きブロックを利用して新規に作成し、ログ記憶領域１１３に記録されているブロック１００の更新前データの内容をこの新規作成した変更前ファイル／ディレクトリ用データブロックにコピーする。
【００７１】
次に、スナップショット生成部２０２は、更新されたファイル／ディレクトリに対応する変更前のファイル／ディレクトリを復元するためのｉノードブロック（変更前ファイル／ディレクトリ用ｉノードブロック）をｉノードリスト領域上に新規作成する（ステップＳ１１４）。
【００７２】
すなわち、スナップショット生成部２０２は、ファイルｂの現在のｉノードブロックの内容とステップＳ１１３で新規作成したデータブロックのブロック番号１７０とを使用して、変更されたファイルｂのｉノードの管理情報を修正し、それをｉノードリスト領域上に新規作成した変更前ファイル／ディレクトリ用ｉノードブロックにコピーする。
【００７３】
以上のステップＳ１１３，Ｓ１１４の処理は、上述の（１）（２）の処理に相当しており、これによって変更前のファイル／ディレクトリの内容が復元される。
【００７４】
この後、スナップショット生成部２０２は、変更前ファイル／ディレクトリを含む上位ディレクトリａ（−）用のデータブロックをデータ領域上に新規作成する（ステップＳ１１５）。ここでは、スナップショット生成部２０２は、更新されたファイルｂの上位ディレクトリａの現在のデータブロックの内容とステップＳ１１４で作成した変更前ファイル／ディレクトリ用ｉノードブロックのｉノード番号とに基づいて、上位ディレクトリａの現在のデータブロックの内容を修正し、それを新規作成したディレクトリａ（−）用のデータブロックにコピーする。
【００７５】
そして、スナップショット生成部２０２は、変更前ファイル／ディレクトリを含む上位ディレクトリａ（−）用のｉノードブロックをｉノードリスト領域上に新規作成する（ステップＳ１１６）。ここでは、スナップショット生成部２０２は、更新されたファイルｂの上位ディレクトリａの現在のｉノードブロックの内容とステップＳ１１５で作成した上位ディレクトリａ（−）用のデータブロックのブロック番号とに基づいて、上位ディレクトリａの現在のｉノードブロックの内容を修正し、それを新規作成したディレクトリａ（−）用のｉノードブロックにコピーする。
【００７６】
以上のステップＳ１１５，Ｓ１１６の処理は、上述の（３）（４）の処理に相当しており、これによって変更前のファイル／ディレクトリを含む上位ディレクトリの内容が復元される。そして、ルートディレクトリに遡るまで、ステップＳ１１５，Ｓ１１６の処理が各上位ディレクトリ毎に実行される（ステップＳ１１７）。これにより、更新前のファイル／ディレクトリからルートディレクトリに至るまでの各ディレクトリの情報を含むブロック（データブロック、ｉノードブロック）が新規作成され、変更前のファイルまたはディレクトリをルートディレクトリから参照するためのリンク情報が復元される。
【００７７】
次に、図１５を参照して、スナップショットを作成すべき時点とログ記憶領域に記録すべき更新前イメージとの関係について説明する。
【００７８】
スナップショットを作成すべき時点は１つのファイル更新タイミング毎に設定してもよいが、通常は、上述したように、ある一定の時間間隔をおいて設定される。この場合、同一のファイル／ディレクトリ内の同一ブロックの更新に際してはその更新前イメージをログ記憶領域に逐次採取する必要はなく、スナップショットを作成すべき各時点を基準に、それ以降に最初に更新が行われる際にのみ当該更新に関する更新前イメージをログ記憶領域に採取すればよい。
【００７９】
図１５においては、ファイルｂのブロック１００の更新を○、ファイルｂのブロック９８の更新を△、ファイルＸのブロックＮの更新を□で示している。スナップショットを作成すべき時点ＴＩＭＥ１と次の時点ＴＩＭＥ２との間のファイル更新において、ファイルｂのブロック１００の更新が何度か繰り返された場合を想定する。復元すべきファイルイメージはＴＩＭＥ１であるので、ログ記憶領域に更新前イメージを採取するのは、ＴＩＭＥ１以降における最初の更新時のみでよい。ＴＩＭＥ１の時点におけるファイルｂのブロック１００の内容をログ記憶領域に採取することにより、ファイルｂのブロック１００の内容をＴＩＭＥ１の時点に復元することが出来るからである。他のファイル／ブロックについても同様である。
【００８０】
更新前イメージを採取すべきかどうかは、例えば、当該世代のログ記憶領域に同一のブロック番号の更新前イメージが既に格納されているか否かを調べることによって判断することが出来る。
【００８１】
なお、ここでは、カレントファイルシステムの内容を維持した状態で、ファイルシステムのスナップショットイメージを２次記憶装置１１６上に復元することを前提としたが、読み出し要求されたブロックに関する更新前イメージまたはファイルシステムにおける現在のイメージを選択的に主記憶装置上に読み出すことにより、更新されたブロックを含むファイルまたはディレクトリの更新前の内容を復元することもできる。以下、この場合の例をする。
【００８２】
本例においては、図１６に示されているように、読み出し要求されたブロックに関する更新前イメージをログ記憶領域から高速に読み出せるようにするために、スナップショット用バッファ４０１と、このスナップショット用バッファ４０１を管理するためのスナップショット用バッファ管理テーブル４０２を使用する。スナップショット用バッファ４０１はコンピュータシステム１１の主記憶上に割り当てられたバッファエリアであり、ここにはログ記憶領域に蓄積された更新前イメージが読み出される。
【００８３】
ここで、図１７を参照して、スナップショットイメージ生成部２０２によって実行されるスナップショットイメージ生成処理の原理について説明する。
【００８４】
本例においては、過去の任意の時点のスナップショットイメージを生成する際には、そのスナップショットイメージの作成に必要な更新前イメージが該当する各世代のログ記憶領域から読み出されて、スナップショット用バッファ４０１に格納される。そして、ブロックの読み出し要求を受けるたびに、その読み出し要求で指定されたブロック番号のブロックに対応する更新前イメージが存在するか否かを判別することによって、カレントファイルシステムまたはスナップショット用バッファ４０１から該当するブロックが選択的に読み出される。
【００８５】
例えば、上述したようにファイルｂがブロック番号９８，１００，１１０の３つのデータブロックから構成されており、ブロック番号１００のブロックが更新されている場合を想定する。
【００８６】
ファイルｂの更新前イメージを復元することが利用者によって指定された場合、カレントファイルシステムで管理されているファイルｂのｉノードの内容に基づいて、ブロック番号９８，１００，１１０に対する読み出し要求が順次発行される。ブロック番号９８のブロックは更新されていないので、そのブロック番号９８に対応するブロックのデータが２次記憶装置１１２上のカレントファイルシステムから主記憶上に読み出される。ブロック番号１００のブロックは更新されているので、そのブロック番号１００のブロックの更新前データがスナップショット用バッファ３０１から主記憶上に読み出される。そして、ブロック番号１１０のブロックは更新されていないので、そのブロック番号１１０に対応するブロックのデータは２次記憶装置１１２上のカレントファイルシステムから主記憶上に読み出される。このようにして、ファイルｂの更新前の内容が復元される。
【００８７】
同一ブロックに関する更新前イメージが異なる世代のログ記憶領域にそれぞれ格納されている場合には、スナップショットイメージを復元すべき時点に最も近接した最古の世代のログ記憶領域に格納されている更新前イメージをスナップショット用バッファ４０１に読み出すようにすればよい。
【００８８】
なお、以上説明したログ記憶領域の管理およびスナップショット生成等に関する各機能は全てコンピュータプログラムによって実現されているので、このプログラムをコンピュータ読み取り可能な記憶媒体を通じて通常のコンピュータに導入して実行するだけで、本実施形態と同様の効果を容易に得ることが出来る。
【００８９】
また、本発明はは上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【００９０】
【発明の効果】
以上詳述した如く本発明によれば、ファイルシステム上のデータ領域を圧迫することなく、且つファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行わずに、指定された任意の時点のファイルシステムのイメージを効率よく復元することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る計算機システムの構成を示すブロック図。
【図２】同計算機システムで用いられるファイルシステムとログ記憶領域の内容を説明するための図。
【図３】同計算機システムにおいて世代毎に作成されるログ記憶領域を説明するための図。
【図４】同計算機システムで用いられるログ記憶領域管理テーブルの例を示す図。
【図５】同計算機システムで用いられるログ記憶領域管理テーブルに２世代目のログ記憶領域の管理情報を追加した例を示す図。
【図６】同計算機システムにおいて３世代分のログ記憶領域にそれぞれ更新前イメージが蓄積されている様子を示す図。
【図７】同計算機システムにおいてログ記憶領域を世代別に作成し、そこに更新前イメージを格納する処理の手順を示すフローチャート。
【図８】同計算機システムにおいてログ記憶領域のサイズを動的に拡張する処理の手順を示すフローチャート。
【図９】同計算機システムにおいてログ記憶領域を自動的に削除する処理の手順を示すフローチャート。
【図１０】同計算機システムで管理されているファイルシステムのツリー構造の例を示す図。
【図１１】図１０のファイルシステムが更新される場合における更新前イメージの格納動作を説明するための図。
【図１２】同計算機システムにおいてファイル更新処理時に実行される一連の処理手順の例を示すフローチャート。
【図１３】同計算機システムにおけるスナップショットの作成処理の様子を示す図。
【図１４】同計算機システムにおけるスナップショット作成処理の手順を示すフローチャート。
【図１５】同計算機システムにおける更新前イメージの記録動作とスナップショットを作成すべき時点との関係を示す図。
【図１６】同計算機システムで使用されるスナップショット用バッファとスナップショット用バッファ管理テーブルを説明するための図。
【図１７】同計算機システムにおけるスナップショットイメージ生成処理動作を説明するための図。
【符号の説明】
１１…コンピュータシステム、１１１…論理ボリューム管理部、１１２…ファイル管理システム、１１３…スナップショット管理部、１１４…ログ記憶領域管理部、１１６…２次記憶装置、２０１…更新前情報取得部、２０２…スナップショット生成部、３０１…ログ記憶領域作成部、３０２…ログ記憶領域サイズ変更部、３０３…ログ記憶領域削除部。
【発明の属する技術分野】
本発明は過去のある所定の時点におけるファイルシステムのイメージを復元する処理を実行可能な計算機システムおよび同復元処理を実行するためのプログラムに関する。
【０００２】
【従来の技術】
一般に、サーバコンピュータなどとして利用される計算機システムにおいては、その計算機システムに障害が発生した場合でも、ファイルシステムの一貫性を保持することが必要とされる。また、ファイルシステムの容量が大きい場合でも、障害からの復旧に時間がかからないことも要求される。
【０００３】
近年、これらの要求を満たすファイルシステムが幾つか提案されている。例えば、従来では、コピーオンライト（ＣＯＷ）技術とロギング技術を用いることにより、システム障害時におけるファイルシステムの一貫性の保持と高速なリカバリを実現するファイルシステムが知られている（例えば、非特許文献１参照。）。
【０００４】
また、コピーオンライト（ＣＯＷ）技術とロギング技術に加え、ｉノードをファイルとしてディスク上の任意の位置に記録することによって、前述の特徴の他に、指定した時点でのファイルシステムのイメージを記録する技術も知られている（例えば、特許文献１参照。）。
【０００５】
これら従来の方法で使用されているコピーオンライト技術では、ｉノードなどのメタデータブロックやデータブロックを変更する時点でメタデータブロックやデータブロックを新規に作成し、作成したブロックに以前のブロックの内容をコピーし、コピーしたブロックの内容を変更するという方式を採用している。
【０００６】
【非特許文献１】
“Ｔｈｅ Ｅｐｉｓｏｄｅ Ｆｉｌｅ Ｓｙｓｔｅｍ” Ｓａｉｌｅｓｈ Ｃｈｕｔａｎｉ， Ｏｗｅｎ Ｔ． Ａｎｄｅｒｓｏｎ， Ｍｉｃｈａｅｌ Ｌ． Ｋａｚａｒ， Ｂｒｕｃｅ Ｗ． Ｌｅｖｅｒｅｔｔ， Ｗ． Ａｎｔｈｏｎｙ Ｍａｓｏｎ， Ｒｏｂｅｒｔ Ｎ． Ｓｉｄｅｂｏｔｈａｍ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｗｉｎｔｅｒ ＵＳＥＮＩＸ １９９２ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ， Ｊａｎ １９９２， ｐ．４３−５９
【０００７】
【特許文献１】
特表平８−５１１３６７号公報
【０００８】
【発明が解決しようとする課題】
しかし、この方式では、元のブロックの内容は変更されずにそのまま保持されるため、過去の時点のスナップショットを容易に保存することができる反面、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことが必要となる。
【０００９】
また実際には、更新対象のブロックのみならず、そのブロックを含むファイルまたはディレクトリの階層構造上の上位ディレクトリのブロックをも含めてコピーすることが必要となり、ファイル書き込み時のオーバーヘッドは非常に大きなものとなる。
【００１０】
さらに、ディスク上には、現在のファイルシステムのディレクトリ／ファイルに関する情報のみならず、ファイルシステムの更新処理の進行に伴って何世代にも渡るファイルシステムそれぞれに対応したディレクトリ／ファイルに関する情報が存在することとなる。よって、スナップショットを保存するためにファイルシステム上の多くのブロックが消費され、ファイルシステム上のデータ領域が圧迫されるという問題がある。
【００１１】
本発明は上述の事情を考慮してなされたものであり、ファイルシステム上のデータ領域を圧迫することなく、且つファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行わずに、指定された任意の時点のファイルシステムのイメージを効率よく復元することが可能な計算機システムおよびプログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
上述の課題を解決するため、本発明は、２次記憶装置上でファイルを階層構造で管理するファイルシステムを有する計算機システムにおいて、前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に、前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を作成するログ記憶領域作成手段と、前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手段と、前記ログ記憶領域に蓄積されている更新前イメージと前記ファイルシステムの現在のイメージとに基づいて、過去の所定の時点における前記ファイルシステムのイメージを復元する復元手段とを具備することを特徴とする。
【００１３】
この計算機システムにおいては、ファイルシステムで使用される２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号がログ記憶記憶領域に更新前イメージとして格納されるので、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことなく、例えば、ログ記憶領域に蓄積されている各更新ブロックの更新前データをファイルシステム上の対応するブロックの内容に反映させる操作をログ記憶領域の最後尾から行うことなどによって、ログ記憶領域に蓄積されている更新前イメージとファイルシステムの現在のイメージとに基づいて過去の所定の時点における前記ファイルシステムのイメージを復元することができる。さらに、ログ記憶領域はファイルシステムとは独立した２次記憶装置上の記憶領域上に作成されるので、ファイルシステムのデータ領域がログ記憶領域によって圧迫されるという事態の発生を防止することができる。
【００１４】
また、ファイルシステムのイメージを復元すべき隣接する２つの時点間を単位とする世代毎に当該世代の更新履歴に対応する更新前イメージが異なるログ記憶領域に格納されるように、世代別に異なるログ記憶領域を前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域に作成することが好ましい。このように世代別にログ記憶領域を作成して、世代毎に更新前イメージを異なるログ記憶領域に格納することにより、ファイルシステムの復元に使用すべき更新前イメージを容易に特定することが可能になる。さらに、例えば最も古い世代に対応するログ記憶領域を削除することで、復元処理に不要な世代の更新前イメージをログ記憶領域単位でまとめて削除することもできるので、２次記憶装置上の記憶領域の有効利用を図ることが出来る。
【００１５】
また、本発明は、２次記憶装置上でファイルを階層構造で管理するファイルシステムを有する計算機システムにおいて、前記計算機システムに前記２次記憶装置として設けられた全物理ディスクの記憶領域をボリュームグループとして管理し、前記計算機システムの稼働中に記憶領域を当該記憶領域のサイズを拡張可能な論理ボリュームとして動的に生成する論理ボリューム管理手段と、前記ファイルシステムの更新に関する世代別に異なるログ記憶領域が作成されるように、前記ファイルシステムのイメージを復元すべき時点に到達する度に、前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を前記論理ボリューム管理手段を用いて前記論理ボリュームとして動的に作成するログ記憶領域作成手段と、前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶領域作成手段によって作成された最新世代のログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手段と、前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域の残りサイズが所定値以下に低下した場合、前記最新世代のログ記憶領域のサイズを前記論理ボリューム管理手段を用いて拡張する手段と、前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域から、前記ファイルシステムのイメージを復元すべき時点として指定された過去の所定世代に対応するログ記憶領域に渡って蓄積されている更新前イメージと、前記ファイルシステムの現在のイメージとに基づいて、前記指定された世代に対応する前記ファイルシステムのイメージを復元する復元手段とを具備することを特徴とする。
【００１６】
一般に、多くのブロックが更新される世代ほどより大きなログ記憶領域が必要となるが、更新されるブロックの数を的確に予想することは難しい。このため、更新イメージデータ全てを該当する世代のログ記憶領域に格納できるようにするために、通常は、予め大きなサイズの記憶領域を余分に確保してことが必要となる。本発明では、ログ記憶領域を論理ボリュームを利用して作成することにより、ログ記憶領域の動的なサイズ拡張が可能であるので、予め大きなサイズの記憶領域を余分に確保せずとも、更新イメージデータ全てを該当する世代のログ記憶領域に格納することができる。よって、各世代のログ記憶領域のサイズを当該世代の更新ブロック数に応じたサイズに最適化することができ、２次記憶装置上の記憶領域の有効利用を図ることが出来る。
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。
図１には、本発明の一実施形態に係る計算機システムの構成が示されている。この計算機システムは、例えばサーバコンピュータなどのコンピュータシステムとして使用されるものである。このコンピュータシステム１１は、論理ボリューム管理部１１１、ファイル管理システム１１２、スナップショット管理部１１３、ログ記憶領域管理部１１４、ディスクコントローラ１１５、および二次記憶装置１１６を備えている。二次記憶装置１１６は例えばディスクアレイによって実現されている。このディスクアレイは複数の物理ディスクドライブから構成されている。ディスクアレイは、必要に応じて物理ディスクドライブを追加できるように構成されている。
【００１８】
論理ボリューム管理部１１１はコンピュータシステム１１に二次記憶装置１１６として設けられた全物理ディスクドライブの記憶領域をボリュームグループ（ストレージプールとも称する）として管理するプログラムであり、ファイルシステムやログ記憶領域のための記憶領域を論理ボリュームとして生成する。論理ボリュームは、コンピュータシステム１１の稼働中でも動的に生成、削除、サイズ拡張（縮小）することが可能な記憶領域であり、ボリュームグループ内の論理的な区画を用いて実現されている。この論理ボリューム管理部１１１は、例えば、論理ボリュームマネージャ（ＬＶＭ）と称されるプログラムによって実現されている。
【００１９】
ファイル管理システム１１２はファイルシステムを管理するためのプログラムである。ここで、ファイルシステムとは２次記憶装置１１６上でファイルを階層構造で管理するためのデータ構造である。このデータ構造の管理プログラムがファイル管理システム１１２（単にファイルシステムと称される場合もある）であり、ファイルシステムの生成、およびアプリケーションプログラム等からのＩ／Ｏ要求に応じたファイルアクセス操作を実行する。異なる論理ボリューム上にそれぞれファイルシステムを配置することにより、２次記憶装置１１６上には、複数種のファイルシステムを作成することができる。ファイル管理システム１１２は、論理ボリューム管理部１１１およびディスクコントローラ１１５を通じて、２次記憶装置１１６上の該当するファイルシステムをアクセスする。
【００２０】
スナップショット管理部１１３は２次記憶装置１１６上のファイルシステムを過去の任意の時点のイメージ（内容）に復元するためのプログラムであり、更新前情報取得部２０１とスナップショットイメージ生成部２０２を備えている。更新前情報取得部２０１は、ファイルシステムによって利用される２次記憶装置１１６上の記憶領域内のブロック（ｉノードなどのメタデータブロック、およびデータブロック）の更新が行われる度に、そのブロックの更新前の内容をブロック番号等の更新管理情報と一緒に更新前イメージとして、２次記憶装置１１６上に作成されたログ記憶領域にスタック形式で格納する。スナップショットイメージ生成部２０２は、ログ記憶領域に蓄積された更新前イメージと、ファイルシステムの現在のイメージとに基づいて、ファイルシステムの過去の任意の時点のイメージを示すスナップショットを生成する。スナップショットは、例えば、ログ記憶領域に蓄積されている各更新ブロックの更新前データをファイルシステム上の対応するブロックの内容に反映させる操作をログ記憶領域の最後尾から行うことによって生成される。
【００２１】
ログ記憶領域はファイルシステムの更新履歴を蓄積するための記憶領域である。このログ記憶領域はファイルシステムのデータ領域がログ記憶領域によって圧迫されるという事態の発生を防止するために、ファイルシステムとは独立した２次記憶装置１１６上の記憶領域に作成されている。すなわち、ログ記憶領域はファイルシステムが配置される論理ボリュームとは異なる別の論理ボリュームから構成されており、ファイルシステムの稼働中に動的にログ記憶領域の生成、削除、サイズ変更を行うことができる。
【００２２】
ログ記憶領域管理部１１４は論理ボリューム管理部１１１を用いてログ記憶領域を管理するプログラムであり、ログ記憶領域作成部３０１、ログ記憶領域サイズ変更部３０２、およびログ記憶領域削除部３０３を有している。ログ記憶領域作成部３０１は、論理ボリューム管理部１１１を用いてログ記憶領域を任意の時点に論理ボリュームとして動的に作成するプログラムである。このログ記憶領域作成部３０１は、ファイルシステムの更新に関する世代別に異なるログ記憶領域を作成する機能を有している。すなわち、ログ記憶領域作成部３０１は、ファイルシステムのイメージを復元すべき隣接する２つの時点間を単位とする世代毎に、当該世代の更新履歴に対応する更新前イメージが異なるログ記憶領域に格納されるように、世代別に異なるログ記憶領域をファイルシステムとは独立した２次記憶装置１１６上の記憶領域に作成する。
【００２３】
ログ記憶領域サイズ変更部３０２は、ログ記憶領域作成部３０１によって作成されたログ記憶領域のサイズを論理ボリューム管理部１１１を用いて動的に拡張するための処理を実行する。すなわち、ログ記憶領域サイズ変更部３０２は、更新前イメージの格納に現在使用されている最新世代のログ記憶領域の残りサイズが所定値以下に低下した場合、当該最新世代のログ記憶領域のサイズを論理ボリューム管理部１１１を用いて拡張する。
【００２４】
ログ記憶領域削除部３０３はログ記憶領域作成部３０１によって作成されたログ記憶領域を論理ボリューム管理部１１１を用いて動的に削除するための処理を実行する。例えば、ログ記憶領域削除部３０３は、ログ記憶領域作成部３０１によって世代別に作成されたログ記憶領域の数が所定の世代数分に到達した時に、不要となる最も古い世代に対応するログ記憶領域を論理ボリューム管理部１１１を用いて削除する。
【００２５】
次に、図２を参照して、２次記憶装置１１６上に設けられるファイルシステムとログ記憶領域の内容について説明する。
【００２６】
上述したように、２次記憶装置１１６を構成する全物理ディスクドライブの記憶領域は論理ボリューム管理部１１１によってボリュームグループ１００として管理されている。論理ボリューム管理部１１１は、新規作成要求されたサイズの論理的な区画の記憶領域をボリュームグループ１００から切り出して論理ボリュームとして要求元に割り振ることにより、作成要求に応じて論理ボリュームを個々に作成することができる。ボリュームグループ１００のサイズは、２次記憶装置１１６に物理ディスクドライブを追加することによって動的に拡張される。
【００２７】
図２においては、２つのファイルシステムがそれぞれ論理ボリュームとして実現されている場合が示されている。また、ログ記憶領域もそれぞれ世代毎に異なる論理ボリュームによって実現される。図２においては、世代１〜３の３世代分のログ記憶領域Ｓ１〜Ｓ３がそれぞれ異なる論理ボリュームとして実現されている場合が示されている。
【００２８】
ここで、ファイルシステムのデータ構造について説明する。ファイルシステムの記憶領域は複数のブロックに分割されている。各ブロックのデータサイズは例えば５１２バイトである。以下では、ＵＮＩＸ（Ｒ）のファイルシステムを例示してその構成を説明することとする。
ファイルシステムを管理するために、その記憶領域上には、図示のように、ブートブロック、スーパーブロック、ｉノードリスト領域、およびデータ領域が割り当てられている。ブートブロックは、ブートローダプログラムの格納に使用される領域である。スーパーブロックは、空きブロックのリストなどの情報を格納するために利用される。ｉノードリスト領域は、ファイルシステム内の個々のファイル／ディレクトリに関する情報を保持するｉノードの集合を格納するためのブロック群である。ｉノードは、それに対応する個々のファイル／ディレクトリを管理するためのデータ構造である。ｉノードには、それに対応するファイル（ディレクトリもファイルの一種である）に関する管理情報として、１）ファイルの種類（通常ファイル、ディレクトリファイル等）、２）アクセス権、３）ファイルを構成する個々のブロックのブロック番号を示すアドレス情報、等が保持されている。
【００２９】
ｉノードが格納された個々のｉノードブロックは、それに対応するｉノード番号によって参照される。ｉノード番号はファイルシステム内の個々のファイル／ディレクトリを一意に識別するためのファイル識別子であり、対応するファイル／ディレクトリのｉノードを索引するためのインデックスとして使用される。データ領域は、ファイル／ディレクトリの実体が保持されるブロック群である。ディレクトリを保持するブロックには、当該ディレクトリに対応するｉノード番号、およびその上位ディレクトリに対応するｉノード番号に加え、当該ディレクトリ内に属する各ファイルまたはディレクトリに対応するｉノード番号がディレクトリ情報として含まれている。
【００３０】
次に、ログ記憶領域の構造について説明する。各世代のログ記憶領域は、管理情報記憶領域と、更新前データイメージ記憶領域とに分割されている。上述の更新前情報取得部２０１は、ファイルシステム上のｉノードブロックやデータブロックの内容が更新される際に、そのブロックの更新前データを更新前データイメージ記憶領域に書き込むと共に、当該ブロックを含むファイルまたはディレクトリを識別するための識別子（ｉノード番号）、当該ブロックのブロック番号、およびブロックの更新種別（変更、削除、追加等）を示すフラグなどを含む更新管理情報を管理情報記憶領域に書き込む。
【００３１】
なお、ログ記憶領域はスナップショット作成対象のファイルシステム毎に作成される。以下では、スナップショット作成対象のファイルシステムをターゲットファイルシステムと称することとする。
【００３２】
図３には、ターゲットファイルシステムＴ１とそれに対応するログ記憶領域との関係が示されている。
本実施形態においては、ターゲットファイルシステムＴ１のイメージを復元すべきポイント、すなわちターゲットファイルシステムＴ１のスナップショットを作成すべき時点毎に、新たな世代のログ記憶領域が新規作成され、次のポイントが到来するまでの間に行われたファイル更新に対応する更新前イメージ（更新前データ、および更新管理情報）が当該世代のログ記憶領域に蓄積される。この場合、同一ブロックの更新に際してはその更新前イメージをログ記憶領域に逐次採取する必要はなく、スナップショットを作成すべき各時点を基準に、それ以降に最初に更新が行われる際にのみ当該更新に関する更新前イメージが対応するログ記憶領域に採取される。このため、例えばある一定の時間間隔毎にスナップショットを作成すべき時点を設定した場合であっても、ログ記憶領域に採取される更新前イメージのデータ量は世代毎に異なることとなる。そこで、本実施形態では、ログ記憶領域の新規作成時には、予め決められた必要最低限の小さなサイズのログ記憶領域を論理ボリュームとして作成し、必要に応じて当該ログ記憶領域のサイズを動的に拡張するという方式を用いる。これにより、新規作成時の初期設定エリアのサイズはどの世代のログ記憶領域も同じであるが、世代によっては初期設定エリアに拡張エリアが動的に追加設定されることにより、最終的なサイズは世代毎に異なることになる。よって、更新前イメージの格納に使用されない領域が無駄に確保されてしまうことを効率よく防止することが可能となる。
【００３３】
スナップショットは、更新前イメージの格納に現在使用されている最新世代のログ記憶領域から、ターゲットファイルシステムＴ１のイメージを復元すべき時点として指定された過去の所定世代に対応するログ記憶領域に渡って蓄積されている更新前イメージと、ターゲットファイルシステムＴ１の現在のイメージとに基づいて、生成される。つまり、本実施形態においては、世代別にログ記憶領域を作成して、世代毎に更新前イメージを異なるログ記憶領域に格納しているので、ターゲットファイルシステムＴ１のイメージを復元可能な時点とログ記憶領域の世代とは１対１で対応している。よって、更新前イメージ単位で時間管理をせずとも、指定された過去の時点のファイルシステムの復元に使用すべき更新前イメージを容易に特定することが可能になる。さらに、例えば最も古い世代に対応するログ記憶領域を削除することで、復元処理に不要な世代の更新前イメージをログ記憶領域単位でまとめて削除することもできるので、２次記憶装置１１６上の記憶領域の有効利用を図ることが出来る。
【００３４】
次に、図４を参照して、ターゲットファイルシステムとログ記憶領域とを対応づけるためのログ記憶領域管理テーブルについて説明する。
図４に示されているように、ログ記憶領域管理部１１４は、ログ記憶領域管理テーブル５０１を用いてターゲットファイルシステムとログ記憶領域との関係を管理するものであり、ターゲットファイルシステム毎にそれに対応するログ記憶領域の管理情報を保持する。すなわち、ログ記憶領域管理部１１４には、ターゲットファイルシステムを識別するためのファイルシステムＩＤが登録されるエントリが設けられると共に、そのエントリに後続して、当該ターゲットファイルシステムに対応する各世代のログ記憶領域を管理するための管理情報（世代番号、ログ記憶領域名、ログ記憶領域サイズ、ログ記憶領域の使用サイズ）が登録される複数のエントリが設けられる。ターゲットファイルシステムＴ１に対するログ記憶領域として２世代目のログ記憶領域Ｓ２が作成された場合には、図５に示すように、２世代目のログ記憶領域Ｓ２の管理情報が１世代目のログ記憶領域Ｓ１の管理情報に追加される。ログ記憶領域管理テーブル５０１は、例えば、ターゲットファイルシステムＴ１の記憶領域内にファイルなどとして記録することができる。この場合、ログ記憶領域管理テーブル５０１は、システム動作時に必要に応じてメモリ上にロードされる。ターゲットファイルシステムＴ１がシステムに新規に追加された時点では、Ｔ１に対応するログ記憶領域は存在せず、したがってログ記憶領域管理テーブル５０１にもＴ１のエントリは登録されていない。
【００３５】
ターゲットファイルシステムＴ１のスナップショットを取る場合には、まず、１世代目のログ記憶領域Ｓ１を生成し、そしてログ記憶領域管理テーブル５０１にターゲットファイルシステムＴ１のエントリを追加すると共に、それに後続してログ記憶領域Ｓ１の管理情報を登録する（図４）。この時点でのログ記憶領域サイズは予め決められた初期設定エリアのサイズである。スナップショットを作成すべき次の時点が到来すると、２世代目のログ記憶領域Ｓ２が生成され、そしてログ記憶領域管理テーブル５０１にログ記憶領域Ｓ２の管理情報が追加登録される（図５）。
【００３６】
ここでは、新世代のログ記憶領域を新規に生成するときにその分の領域がログ記憶領域管理テーブル５０１に動的に確保される場合を説明したが、ログ記憶領域を生成するタイミングや生成時のサイズ、及び同時に何世代分のログ記憶領域を生成するかは任意である。例えば、ターゲットファイルシステムを作成する時に、これと同時に数世代分のログ記憶領域を生成しておくことも可能である。また、カレントファイルシステムに対して、一番最初のログの保存要求が発生した時点で、動的に生成することも可能である。また世代数に制限を設ける場合等においては、予め世代数の上限分のエントリを静的にログ記憶領域管理テーブル５０１にまとめて確保しておいてもよい。
【００３７】
図６には、３世代分のログ記憶領域Ｓ１，Ｓ２，Ｓ３にそれぞれ更新前イメージ（更新前情報）が蓄積されている様子が示されている。スナップショットを作成可能な時点をＴＩＭＥ１，ＴＩＭＥ２，ＴＩＭＥ３，…とする。例えば、２４時間ノンストップで稼働するコンピュータシステムにおいて、毎日１２：００の時点におけるスナップショットを生成可能にする場合、２４時間間隔でＴＩＭＥ１，ＴＩＭＥ２，ＴＩＭＥ３が設定され、その設定時間に到達する度に新たな世代のログ記憶領域が新規作成される。ＴＩＭＥ１でログ記憶領域Ｓ１が作成されてから、ＴＩＭＥ２でログ記憶領域Ｓ２が作成されるまでの期間中においては、ターゲットファイルシステムＴ１に対するブロック更新が行われる度に、その更新前イメージが現時点で最新のログ記憶領域Ｓ１に格納される。同様にして、ＴＩＭＥ２でログ記憶領域Ｓ２が作成されてから、ＴＩＭＥ３でログ記憶領域Ｓ３が作成されるまでの期間中においては、ターゲットファイルシステムＴ１に対するブロック更新が行われる度に、その更新前イメージが現時点で最新のログ記憶領域Ｓ２に格納される。また、ＴＩＭＥ３（例えば本日の１２：００の時点）で、ログ記憶領域Ｓ３が作成されてから、本日の現在時点（カレントタイム）までの期間中においては、ターゲットファイルシステムＴ１に対するブロック更新が行われる度に、その更新前イメージが現時点で最新のログ記憶領域Ｓ３に格納される。
【００３８】
本日の１２：００の時点におけるスナップショットを生成する場合には、ＴＩＭＥ３以降からカレントタイムまでに最新世代のログ記憶領域Ｓ３に蓄積された更新前イメージ（更新前情報）が最後尾（最も後に蓄積された更新前イメージ）から順に用いられる。また、昨日の１２：００の時点（ＴＩＭＥ２）におけるスナップショットを生成する場合には、最新世代のログ記憶領域Ｓ３と１世代前のログ記憶領域Ｓ２との２世代分のログ記憶領域が用いられる。すなちわ、最新世代のログ記憶領域Ｓ３に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられ、次いで１世代前のログ記憶領域Ｓ２に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられる。一昨日の１２：００の時点（ＴＩＭＥ１）におけるスナップショットを生成する場合には、最新世代のログ記憶領域Ｓ３、１世代前のログ記憶領域Ｓ２、および２世代前のログ記憶領域Ｓ１の３世代分のログ記憶領域が用いられる。すなちわ、最新世代のログ記憶領域Ｓ３に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられ、次いで１世代前のログ記憶領域Ｓ２に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられ、最後に２世代前のログ記憶領域Ｓ２に蓄積された更新前イメージ（更新前情報）が最後尾から順に用いられる。
【００３９】
なお、スナップショットを生成すべきタイミングは予め設定された時刻の到来によって指定するのみならず、例えば管理者などによる所定の入力操作によって現時点がファイルシステムのスナップショットを生成すべき時点であることを明示的に指定するようにしてもよい。このように、スナップショットを生成すべきタイミングは、任意のログ作成イベントによって指定することができる。
【００４０】
次に、図７のフローチャートを参照して、ログ記憶領域を世代別に作成し、そこに更新前イメージを格納する処理の手順を説明する。
【００４１】
ログ記憶領域管理部１１４は予め指定された時間の到来や所定の入力操作などのログ作成イベントの発生の有無を監視しており、ログ作成イベントが発生すると（ステップＳ１のＹＥＳ）、ログ記憶領域を作成する（ステップＳ２）。このステップＳ２では、ログ記憶領域管理部１１４のログ記憶領域作成部３０１から論理ボリューム管理部１１１に対して論理ボリュームの作成要求が発行され、これによってログ記憶領域が論理ボリュームとして作成される。ターゲットファイルシステムについての最初のログ作成イベントであれば１世代目のログ記憶領域Ｓ１が最新世代のログ記憶領域として作成され、またターゲットファイルシステムについての２回目のログ作成イベントであれば２世代目のログ記憶領域Ｓ２が最新世代のログ記憶領域として作成されることになる。
【００４２】
ログ記憶領域の作成後、ログ記憶領域管理部１１４は、当該作成したログ記憶領域に対応する管理情報をログ記憶領域管理テーブル５０１に登録する（ステップＳ３）。このステップＳ３では、当該作成したログ記憶領域の所在を、更新前イメージの格納対象となる最新世代のログ記憶領域としてスナップショット管理部１１３に通知する処理も行われる。
【００４３】
ターゲットファイルシステムの記憶領域上のブロック更新要求が発生すると（ステップＳ４のＹＥＳ）、ブロック更新要求が発生したことが、例えば、ログ記憶領域管理部１１４を通じてファイル管理システム１１２からスナップショット管理部１１３に通知される。スナップショット管理部１１３の更新前情報取得部２０１は、論理ボリューム管理部１１１およびディスクコントローラ１１５を介して更新対象のブロックの更新前データを２次記憶装置１１６から取得し、それを当該ブロックのブロック番号、当該ブロックを含むファイル／ディレクトリのｉノード番号等の管理情報と一緒に、最新世代のログ記憶領域に格納するログ書き出し処理を実行する（ステップＳ５）。このログ書き出し処理では、ログ記憶領域管理部１１４によって、ログ記憶領域管理テーブル５０１に登録されている「ログ記憶領域の使用サイズ」の値を更新する処理も併せて実行される。ブロック更新要求が発生したブロックのブロック番、および当該ブロックを含むファイル／ディレクトリのｉノード番号などは、ログ記憶領域管理部１１４を通じて、あるいは直接的にファイル管理システム１１２からスナップショット管理部１１３に通知される。ログ記憶領域へログの書き出し処理終了後に、ファイル管理システム１１２によって更新対象のブロックに対する更新処理が実行される（ステップＳ６）。
【００４４】
次に、図８を参照して、ログ記憶領域のサイズを動的に拡張する処理の手順を説明する。
ブロック更新要求（ログ書き出し要求）が発生すると（ステップＳ１１）、ログ記憶領域管理部１１４は、更新前イメージの格納に現在使用されている最新世代のログ記憶領域に対応するログ記憶領域管理テーブル５０１を参照して、「ログ記憶領域サイズ」の値と「ログ記憶領域の使用サイズ」の値とを比較することにより、当該最新世代のログ記憶領域の残りサイズが一定値以下であるか否かを判断する（ステップＳ１２）。残りサイズが一定値以下であれば（ステップＳ１２のＹＥＳ）、ログ記憶領域管理部１１４のログ記憶領域サイズ変更部３０２は、ログ記憶領域のサイズの拡張を論理ボリューム管理部１１１に要求することにより、論理ボリュームから構成される当該ログ記憶領域のサイズを拡張する（ステップＳ１３）。このステップＳ１３では、ボリュームグループ１００内の未使用の所定サイズの記憶領域が、サイズ拡張が要求されたログ記憶領域を構成する論理ボリュームに追加設定される。これにより、ログ記憶領域のサイズは動的に拡張される。また、ログ記憶領域管理テーブル５０１の「ログ記憶領域サイズ」の値の更新も行われる。この後、ログ記憶領域管理部１１４は、スナップショット管理部１１３に対してログ書き出し処理の実行を指示する（ステップＳ１４）。
【００４５】
次に、図９のフローチャートを参照して、ログ記憶領域を動的に削除する処理について説明する。
ログ記憶領域の削除は、ログ記憶領域作成部３０１によって世代別に作成されたログ記憶領域の数が所定の世代数分に到達した時に実行される。例えば、スナップショットを作成可能な時点を現時点から３世代前までの時点までに制限するシステムにおいては、４世代目のログ記憶領域が作成された時に、１世代目のログ記憶領域の内容は不要となる。このような場合に、１世代目のログ記憶領域の削除処理が自動的に実行される。
【００４６】
図９のフローチャートにおいては、不要なログ記憶領域を削除するために、図７で説明したステップＳ２，Ｓ３の処理の後に、ステップＳ２１，Ｓ２２が追加されている。すなわち、ログ記憶領域管理部１１４は、新たな世代のログ記憶領域の新規作成およびログ記憶領域管理テーブル５０１への登録を行った後（ステップＳ２，Ｓ３）、ログ記憶領域管理テーブル５０１を参照することによって、世代別に作成されたログ記憶領域の数が所定の世代数分に到達したか否か、つまり新たな世代のログ記憶領域の新規作成によって不要となる最古の世代のログ記憶領域（例えば、３世代前のログ記憶領域）が存在するかどうかを判断する（ステップＳ２１）。存在するならば、ログ記憶領域管理部１１４のログ記憶領域削除部３０３は、該当するログ記憶領域の削除を論理ボリューム管理部１１１に要求することによって、該当するログ記憶領域を削除する（ステップＳ２２）。このステップＳ２２では、削除要求されたログ記憶領域を構成する論理ボリュームの削除が論理ボリューム管理部１１１によって実行され、そしてその記憶領域がボリュームグループ１００に未使用領域として戻される。
【００４７】
以上のように、本実施形態においては、ファイルシステムで使用される２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号がログ記憶記憶領域に更新前イメージとして格納されるので、ファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行うことなく、例えば、ログ記憶領域に蓄積されている各更新ブロックの更新前データをファイルシステム上の対応するブロックの内容に反映させる操作をログ記憶領域の最後尾から行うことなどによって、ログ記憶領域に蓄積されている更新前イメージとファイルシステムの現在のイメージとに基づいて過去の所定の時点における前記ファイルシステムのイメージを復元することができる。また、ログ記憶領域を、ターゲットファイルシステムとは別に設けることにより、ターゲットファイルシステムのデータ領域を圧迫することなく、更新履歴を保存することが可能となる。またログのデータ量が増大した場合には、ログ記憶領域を動的に拡大することで、ログのデータ量を任意に伸ばすことが可能となるので、１世代当たりの変更ブロック数を制限する必要がなくなる。さらに、ログ記憶領域として、任意の時点での生成、削除、サイズ変更が可能な論理ボリュームを用いることにより、スナップショットの世代の追加・削除・ログ記憶領域サイズの拡大などの管理が容易になるという効果が得られる。
【００４８】
次に、ログ書き出し処理及びスナップショット生成に関する具体例について説明する。
まず、図１０および図１１を参照して、ログ書き出し処理の例について説明する。ここでは、図１０のようなツリー構造のファイルシステムにおいて、ディレクトリａの配下に存在するファイルｂの内容を更新する場合について説明する。
図１１は、２次記憶装置１１２上に構築されたファイルシステムのデータ構造を示している。
ｉノードリスト領域には、ルートディレクトリのｉノード、ディレクトリａのｉノード、ファイルｂのｉノード、等が存在し、またデータ領域には、ルートディレクトリ、ディレクトリａ、ファイルｂそれぞれの実体を記憶したデータブロックが存在する。
【００４９】
通常、ファイルは１以上のデータブロックから構成されており、ファイルｂの管理情報を保持する管理情報ブロックであるｉノードブロックには、ファイルｂのデータの実体を構成しているデータブロックそれぞれのブロック番号（ここでは、ブロック番号９８、１００、１１０）へのリンクを持つポインタがアドレス情報として含まれている。
【００５０】
同様に、ルートディレクトリのｉノードブロックにはルートディレクトリのディレクトリ情報を保持するデータブロックを示すブロック番号が含まれており、そのルートディレクトリのデータブロック内にはそのカレントディレクトリであるルートディレクトリのｉノードブロックを示すｉノード番号（ここでは、３）と、その配下に存在するディレクトリａのｉノードブロックを示すｉノード番号（ここでは、４）がディレクトリ情報として含まれている。
【００５１】
また、ディレクトリａの管理情報を保持するｉノードブロックにはディレクトリａのデータブロックを示すブロック番号が含まれており、そのディレクトリａのデータブロック内には、その上位ディレクトリであるルートディレクトリのｉノードブロックを示すｉノード番号（ここでは、３）と、カレントディレクトリであるディレクトリａのｉノードブロックを示すｉノード番号（ここでは、４）と、ディレクトリａ配下のファイルｂのｉノードブロックを示すｉノード番号（ここでは、５）がディレクトリ情報として含まれている。
【００５２】
いま、ｉノード番号５に対応するファイルｂ内のブロック１００を更新する場合を考える。この場合、ブロック１００の更新に先立ち、ファイルｂのｉノード番号５、更新対象のブロック番号１００、および更新種別が変更であることを示すフラグ情報（Ｍ）からなる更新管理情報と、ブロック１００の更新前データとが最新世代のログ記憶領域、例えばＳ１、に格納される。
【００５３】
図１２のフローチャートには、ファイル／ディレクトリの更新時にコンピュータシステム１１によって実行される一連の処理手順が示されている。
【００５４】
ファイル管理システム１１２は、オペレーティングシステムやアプリケーションプログラムからのファイル操作要求等によってファイル／ディレクトリの内容を更新する必要が生じた場合（ステップＳ１０１のＹＥＳ）、まず、当該更新対象のファイル／ディレクトリのファイル／ディレクトリ名からそれに対応するｉノード番号をサーチし、その更新対象のファイル／ディレクトリのｉノードブロックを取得する（ステップＳ１０２）。
【００５５】
次いで、ファイル管理システム１１２は、取得したｉノードブロックに含まれるアドレス情報から更新対象のファイル／ディレクトリの実体を保持する各データブロックを認識する（ステップＳ１０３）。ｉノード番号５に対応するファイルｂ内のブロック１００を更新する場合を考える。この場合、ファイル管理システム１１２は、ｉノード番号５に対応するファイルｂ内のブロック１００を更新することを、ログ記憶領域管理部１１４を通じて、あるいは直接に、スナップショット管理部１１３に通知する。スナップショット管理部１１３は、更新前情報取得部２０１を用いて、更新管理情報（ｉノード番号＝５、ブロック番号＝１００、フラグ情報＝Ｍ）と、ブロック番号１００のブロックの更新前の内容とを、更新前イメージとしてログ記憶領域に書き込む（ステップＳ１０４，Ｓ１０５）。ログ記憶領域に書き出している途中でブロック１００の内容が変更されるのを防ぐため、ログ記憶領域への書き込みを実行する前にブロック１００をロックする。ログ記憶領域への書き込みが終了すると、ブロック１００のロックを解除する。
【００５６】
この後、ファイル管理システム１１２は、ブロック番号１００のブロックの内容を例えばｂからｂ’に更新する（ステップＳ１０６）。この更新により、ファイルシステムは常に最新の状態に維持される。
【００５７】
次に、図１３を参照して、ファイルシステムの現在のイメージとログ記憶領域Ｓ１の更新前イメージとを利用してスナップショットを作成する処理の例について説明する。
ログ記憶領域Ｓ１に蓄積されている更新前イメージの更新管理情報から、ｉノード番号５に対応するファイルｂのブロック１００が更新されたことが判る。
【００５８】
（１）変更前のファイルｂ用のデータブロックの作成
ここでは、更新されたブロック１００に代わる新たなブロックを作成するために、ファイルシステムのデータ領域上に空きブロック（ここでは、ブロック番号１７０）を確保し、ログ記憶領域Ｓ１に記憶されているブロック１００の更新前データｂをブロック番号１７０にコピーする。
【００５９】
（２）変更前のファイルｂ用のｉノードブロックの作成
次いで、変更前のファイルｂに対応する新たなｉノードブロックを生成するために、ｉノードリスト領域上に空きブロックを確保する。そして、更新されたファイルｂを管理するための管理情報を保持するファイルｂの現在のｉノードブロックの内容をファイルシステムから取得する。取得したファイルｂのｉノードブロックに含まれる管理情報の内、更新されたブロック１００へのリンクを示すアドレス情報は修正され、ブロック番号１７０へのリンクを示すように書き換えられる。修正された管理情報は、ｉノードリスト領域上に確保された空きブロックに書き込まれ、これによってブロック番号９８、１７０、１１０から構成される変更前のファイルｂを管理するためのｉノードブロック、つまり現在のファイルｂのｉノードブロックに代わる、１世代前のファイルｂ（−）に対応するｉノードブロック、が生成される。１世代前のファイルｂ（−）には新たなｉノード番号（ここでは、３０）が割り当てられる。
【００６０】
（３）（４）変更前のファイルｂを含む上位ディレクトリのディレクトリ情報の復元
次に、変更前のファイルｂを含む上位ディレクトリａのディレクトリ情報の復元が行われる。まず、上位ディレクトリａのディレクトリ情報を保持する現在のディレクトリａのデータブロックに代わる新たなデータブロックを作成するために、データ領域上に空きブロックを確保する。そして、ディレクトリａの現在のデータブロックの内容をファイルシステムから取得する。取得したディレクトリａのディレクトリ情報の内、その配下に存在する現在のファイルｂのｉノードブロックへのリンクを示すアドレス情報については修正され、変更前のファイルｂ（−）のｉノードブロックへのリンクを示すように書き換えられる。すなわち、現在のファイルｂのｉノードブロックを示すｉノード番号５から、１世代前のｂ（−）のｉノードブロックを示すｉノード番号３０に変更される。
【００６１】
修正されたディレクトリ情報は、データ領域上の空きブロックに書き込まれ、これによって変更前のファイルｂ（−）を含む上位ディレクトリａ（−）のデータブロックが生成される。
【００６２】
また、ｉノードリスト領域上の空きブロックを用いて、上位ディレクトリａ（−）のｉノードブロックも生成される。この場合、ディレクトリａの現在のｉノードブロックの管理情報をカレントファイルシステムから取得する。取得したディレクトリａの管理情報の内、現在のディレクトリａのブロックへのリンクを示すアドレス情報については修正され、ディレクトリａ（−）のデータブロックへのリンクを示すように書き換えられる。修正された管理情報は、ｉノードリスト領域上に確保された空きブロックに書き込まれ、これによって１世代前のディレクトリａ（−）のｉノードブロックが生成される。この１世代前のディレクトリａ（−）には、新たなｉノード番号（ここでは、２９）が割り当てられる。
【００６３】
ディレクトリａ（−）のデータブロックに保持されているカレントディレクトリのｉノード番号は、現在のディレクトリａのｉノード番号４から、ディレクトリａ（−）のｉノード番号２９に変更される。
【００６４】
（５）（６）次に、最上位のディレクトリである現在のルートディレクトリに代わる新たなルートディレクトリのデータブロックを作成するために、ファイルシステムのデータ領域上に空きブロックを確保する。そして、ルートディレクトリの現在のデータブロックの内容をファイルシステムから取得する。取得したルートディレクトリのディレクトリ情報の内、その配下に存在する現在のディレクトリａのｉノードブロックへのリンクを示すアドレス情報については修正され、１世代前のディレクトリａ（−）のｉノードブロックへのリンクを示すように書き換えられる。すなわち、現在のディレクトリａのｉノードブロックを示すｉノード番号４から、１世代前のａ（−）のｉノードブロックを示すｉノード番号２９に変更される。修正されたディレクトリ情報は、データ領域上の空きブロックに書き込まれ、これによって１世代前のルートディレクトリ（−）のブロックが生成される。
【００６５】
また、ｉノードリスト領域上の空きブロックを用いて、１世代前のルートディレクトリ（−）のｉノードブロックも生成される。この場合、現在のルートディレクトリのｉノードブロックの管理情報をカレントファイルシステムから取得する。取得したルートディレクトリの管理情報の内、現在のルートディレクトリのブロックへのリンクを示すアドレス情報については修正され、１世代前のルートディレクトリ（−）のブロックへのリンクを示すように書き換えられる。修正された管理情報は、ｉノード領域上の空きブロックに書き込まれ、これによって１世代前のルートディレクトリ（−）のｉノードブロックが生成される。この１世代前のルートディレクトリ（−）には、新たなｉノード番号（ここでは、２８）が割り当てられる。ルートディレクトリ（−）のデータブロックに保持されているカレントディレクトリのｉノード番号は、現在のルートディレクトリのｉノード番号３から、ルートディレクトリ（−）のｉノード番号２９に変更される。
【００６６】
このようにして、空きブロックを用いて変更前のファイルに対応するブロックとその上位ディレクトリに関するブロックとを作成することによって、更新されたファイルの更新前の内容と、当該変更前のファイルを含む上位ディレクトリのディレクトリ情報とを復元することにより、現在のファイルシステムのイメージをそのまま維持した状態で、過去の任意の時点のファイルシステムのイメージを示すスナップショットを生成することが可能となる。
【００６７】
図１４のフローチャートには、スナップショット生成時にスナップショット生成部２０２によって実行される一連の処理手順が示されている。
【００６８】
スナップショット生成部２０２は、最新世代のログ記憶領域の最後尾から、復元対象の世代に対応するログ記憶領域の先頭に渡って記憶されている更新前イメージを順に取得し（ステップＳ１１１）、そして指定された時点のスナップショットに関する全ての更新前イメージに対する処理が完了するまで、各更新前イメージ毎に以下の処理を再帰的に実行する（ステップＳ１１２）。
【００６９】
まず、スナップショット生成部２０２は、取得した更新前イメージの内容から、どのファイル／ディレクトリにおけるどのブロックが更新されたのかを認識し、その更新されたファイル／ディレクトリに対応する変更前のファイル／ディレクトリを復元するためのデータブロック（変更前ファイル／ディレクトリ用データブロック）をデータ領域上に新規作成する（ステップＳ１１３）。
【００７０】
例えば、上述の例では、ｉノード番号５に関連するファイルｂのブロック１００の内容が更新されたことがわかるので、更新されたブロック１００に代わる変更前ファイル／ディレクトリ用データブロックを空きブロックを利用して新規に作成し、ログ記憶領域１１３に記録されているブロック１００の更新前データの内容をこの新規作成した変更前ファイル／ディレクトリ用データブロックにコピーする。
【００７１】
次に、スナップショット生成部２０２は、更新されたファイル／ディレクトリに対応する変更前のファイル／ディレクトリを復元するためのｉノードブロック（変更前ファイル／ディレクトリ用ｉノードブロック）をｉノードリスト領域上に新規作成する（ステップＳ１１４）。
【００７２】
すなわち、スナップショット生成部２０２は、ファイルｂの現在のｉノードブロックの内容とステップＳ１１３で新規作成したデータブロックのブロック番号１７０とを使用して、変更されたファイルｂのｉノードの管理情報を修正し、それをｉノードリスト領域上に新規作成した変更前ファイル／ディレクトリ用ｉノードブロックにコピーする。
【００７３】
以上のステップＳ１１３，Ｓ１１４の処理は、上述の（１）（２）の処理に相当しており、これによって変更前のファイル／ディレクトリの内容が復元される。
【００７４】
この後、スナップショット生成部２０２は、変更前ファイル／ディレクトリを含む上位ディレクトリａ（−）用のデータブロックをデータ領域上に新規作成する（ステップＳ１１５）。ここでは、スナップショット生成部２０２は、更新されたファイルｂの上位ディレクトリａの現在のデータブロックの内容とステップＳ１１４で作成した変更前ファイル／ディレクトリ用ｉノードブロックのｉノード番号とに基づいて、上位ディレクトリａの現在のデータブロックの内容を修正し、それを新規作成したディレクトリａ（−）用のデータブロックにコピーする。
【００７５】
そして、スナップショット生成部２０２は、変更前ファイル／ディレクトリを含む上位ディレクトリａ（−）用のｉノードブロックをｉノードリスト領域上に新規作成する（ステップＳ１１６）。ここでは、スナップショット生成部２０２は、更新されたファイルｂの上位ディレクトリａの現在のｉノードブロックの内容とステップＳ１１５で作成した上位ディレクトリａ（−）用のデータブロックのブロック番号とに基づいて、上位ディレクトリａの現在のｉノードブロックの内容を修正し、それを新規作成したディレクトリａ（−）用のｉノードブロックにコピーする。
【００７６】
以上のステップＳ１１５，Ｓ１１６の処理は、上述の（３）（４）の処理に相当しており、これによって変更前のファイル／ディレクトリを含む上位ディレクトリの内容が復元される。そして、ルートディレクトリに遡るまで、ステップＳ１１５，Ｓ１１６の処理が各上位ディレクトリ毎に実行される（ステップＳ１１７）。これにより、更新前のファイル／ディレクトリからルートディレクトリに至るまでの各ディレクトリの情報を含むブロック（データブロック、ｉノードブロック）が新規作成され、変更前のファイルまたはディレクトリをルートディレクトリから参照するためのリンク情報が復元される。
【００７７】
次に、図１５を参照して、スナップショットを作成すべき時点とログ記憶領域に記録すべき更新前イメージとの関係について説明する。
【００７８】
スナップショットを作成すべき時点は１つのファイル更新タイミング毎に設定してもよいが、通常は、上述したように、ある一定の時間間隔をおいて設定される。この場合、同一のファイル／ディレクトリ内の同一ブロックの更新に際してはその更新前イメージをログ記憶領域に逐次採取する必要はなく、スナップショットを作成すべき各時点を基準に、それ以降に最初に更新が行われる際にのみ当該更新に関する更新前イメージをログ記憶領域に採取すればよい。
【００７９】
図１５においては、ファイルｂのブロック１００の更新を○、ファイルｂのブロック９８の更新を△、ファイルＸのブロックＮの更新を□で示している。スナップショットを作成すべき時点ＴＩＭＥ１と次の時点ＴＩＭＥ２との間のファイル更新において、ファイルｂのブロック１００の更新が何度か繰り返された場合を想定する。復元すべきファイルイメージはＴＩＭＥ１であるので、ログ記憶領域に更新前イメージを採取するのは、ＴＩＭＥ１以降における最初の更新時のみでよい。ＴＩＭＥ１の時点におけるファイルｂのブロック１００の内容をログ記憶領域に採取することにより、ファイルｂのブロック１００の内容をＴＩＭＥ１の時点に復元することが出来るからである。他のファイル／ブロックについても同様である。
【００８０】
更新前イメージを採取すべきかどうかは、例えば、当該世代のログ記憶領域に同一のブロック番号の更新前イメージが既に格納されているか否かを調べることによって判断することが出来る。
【００８１】
なお、ここでは、カレントファイルシステムの内容を維持した状態で、ファイルシステムのスナップショットイメージを２次記憶装置１１６上に復元することを前提としたが、読み出し要求されたブロックに関する更新前イメージまたはファイルシステムにおける現在のイメージを選択的に主記憶装置上に読み出すことにより、更新されたブロックを含むファイルまたはディレクトリの更新前の内容を復元することもできる。以下、この場合の例をする。
【００８２】
本例においては、図１６に示されているように、読み出し要求されたブロックに関する更新前イメージをログ記憶領域から高速に読み出せるようにするために、スナップショット用バッファ４０１と、このスナップショット用バッファ４０１を管理するためのスナップショット用バッファ管理テーブル４０２を使用する。スナップショット用バッファ４０１はコンピュータシステム１１の主記憶上に割り当てられたバッファエリアであり、ここにはログ記憶領域に蓄積された更新前イメージが読み出される。
【００８３】
ここで、図１７を参照して、スナップショットイメージ生成部２０２によって実行されるスナップショットイメージ生成処理の原理について説明する。
【００８４】
本例においては、過去の任意の時点のスナップショットイメージを生成する際には、そのスナップショットイメージの作成に必要な更新前イメージが該当する各世代のログ記憶領域から読み出されて、スナップショット用バッファ４０１に格納される。そして、ブロックの読み出し要求を受けるたびに、その読み出し要求で指定されたブロック番号のブロックに対応する更新前イメージが存在するか否かを判別することによって、カレントファイルシステムまたはスナップショット用バッファ４０１から該当するブロックが選択的に読み出される。
【００８５】
例えば、上述したようにファイルｂがブロック番号９８，１００，１１０の３つのデータブロックから構成されており、ブロック番号１００のブロックが更新されている場合を想定する。
【００８６】
ファイルｂの更新前イメージを復元することが利用者によって指定された場合、カレントファイルシステムで管理されているファイルｂのｉノードの内容に基づいて、ブロック番号９８，１００，１１０に対する読み出し要求が順次発行される。ブロック番号９８のブロックは更新されていないので、そのブロック番号９８に対応するブロックのデータが２次記憶装置１１２上のカレントファイルシステムから主記憶上に読み出される。ブロック番号１００のブロックは更新されているので、そのブロック番号１００のブロックの更新前データがスナップショット用バッファ３０１から主記憶上に読み出される。そして、ブロック番号１１０のブロックは更新されていないので、そのブロック番号１１０に対応するブロックのデータは２次記憶装置１１２上のカレントファイルシステムから主記憶上に読み出される。このようにして、ファイルｂの更新前の内容が復元される。
【００８７】
同一ブロックに関する更新前イメージが異なる世代のログ記憶領域にそれぞれ格納されている場合には、スナップショットイメージを復元すべき時点に最も近接した最古の世代のログ記憶領域に格納されている更新前イメージをスナップショット用バッファ４０１に読み出すようにすればよい。
【００８８】
なお、以上説明したログ記憶領域の管理およびスナップショット生成等に関する各機能は全てコンピュータプログラムによって実現されているので、このプログラムをコンピュータ読み取り可能な記憶媒体を通じて通常のコンピュータに導入して実行するだけで、本実施形態と同様の効果を容易に得ることが出来る。
【００８９】
また、本発明はは上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【００９０】
【発明の効果】
以上詳述した如く本発明によれば、ファイルシステム上のデータ領域を圧迫することなく、且つファイルシステムの通常動作中に新たなブロックの生成やデータのコピーといった煩雑な処理を行わずに、指定された任意の時点のファイルシステムのイメージを効率よく復元することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る計算機システムの構成を示すブロック図。
【図２】同計算機システムで用いられるファイルシステムとログ記憶領域の内容を説明するための図。
【図３】同計算機システムにおいて世代毎に作成されるログ記憶領域を説明するための図。
【図４】同計算機システムで用いられるログ記憶領域管理テーブルの例を示す図。
【図５】同計算機システムで用いられるログ記憶領域管理テーブルに２世代目のログ記憶領域の管理情報を追加した例を示す図。
【図６】同計算機システムにおいて３世代分のログ記憶領域にそれぞれ更新前イメージが蓄積されている様子を示す図。
【図７】同計算機システムにおいてログ記憶領域を世代別に作成し、そこに更新前イメージを格納する処理の手順を示すフローチャート。
【図８】同計算機システムにおいてログ記憶領域のサイズを動的に拡張する処理の手順を示すフローチャート。
【図９】同計算機システムにおいてログ記憶領域を自動的に削除する処理の手順を示すフローチャート。
【図１０】同計算機システムで管理されているファイルシステムのツリー構造の例を示す図。
【図１１】図１０のファイルシステムが更新される場合における更新前イメージの格納動作を説明するための図。
【図１２】同計算機システムにおいてファイル更新処理時に実行される一連の処理手順の例を示すフローチャート。
【図１３】同計算機システムにおけるスナップショットの作成処理の様子を示す図。
【図１４】同計算機システムにおけるスナップショット作成処理の手順を示すフローチャート。
【図１５】同計算機システムにおける更新前イメージの記録動作とスナップショットを作成すべき時点との関係を示す図。
【図１６】同計算機システムで使用されるスナップショット用バッファとスナップショット用バッファ管理テーブルを説明するための図。
【図１７】同計算機システムにおけるスナップショットイメージ生成処理動作を説明するための図。
【符号の説明】
１１…コンピュータシステム、１１１…論理ボリューム管理部、１１２…ファイル管理システム、１１３…スナップショット管理部、１１４…ログ記憶領域管理部、１１６…２次記憶装置、２０１…更新前情報取得部、２０２…スナップショット生成部、３０１…ログ記憶領域作成部、３０２…ログ記憶領域サイズ変更部、３０３…ログ記憶領域削除部。
Claims (10)
- ２次記憶装置上でファイルを階層構造で管理するファイルシステムを有する計算機システムにおいて、
前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に、前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を作成するログ記憶領域作成手段と、
前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手段と、
前記ログ記憶領域に蓄積されている更新前イメージと前記ファイルシステムの現在のイメージとに基づいて、過去の所定の時点における前記ファイルシステムのイメージを復元する復元手段とを具備することを特徴とする計算機システム。 - 前記ログ記憶領域作成手段は、前記ファイルシステムのイメージを復元すべき隣接する２つの時点間を単位とする世代毎に当該世代の更新履歴に対応する更新前イメージが異なるログ記憶領域に格納されるように、前記世代別に異なるログ記憶領域を前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域に作成する手段を含むことを特徴とする請求項１記載の計算機システム。
- 前記復元手段は、前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域から、前記ファイルシステムのイメージを復元すべき時点として指定された過去の所定世代に対応するログ記憶領域に渡って蓄積されている更新前イメージと、前記ファイルシステムの現在のイメージとに基づいて、前記指定された世代に対応する前記ファイルシステムのイメージを復元する手段を含むことを特徴とする請求項２記載の計算機システム。
- 前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域の残りサイズが所定値以下に低下した場合、前記最新世代のログ記憶領域のサイズを拡張する手段をさらに具備することを特徴とする請求項２記載の計算機システム。
- 前記ログ記憶領域作成手段によって世代別に作成されたログ記憶領域の数が所定の世代数分に到達した場合、最も古い世代に対応するログ記憶領域を削除する手段をさらに具備することを特徴とする請求項２記載の計算機システム。
- 前記計算機システムに前記２次記憶装置として設けられた全物理ディスクの記憶領域をボリュームグループとして管理し、前記計算機システムの稼働中に記憶領域を当該記憶領域のサイズを拡張可能な論理ボリュームとして動的に生成する論理ボリューム管理手段をさらに具備し、
前記ログ記憶領域作成手段は、前記論理ボリューム管理手段を用いることによって前記ログ記憶記憶領域を前記論理ボリュームとして作成することを特徴とする請求項１記載の計算機システム。 - ２次記憶装置上でファイルを階層構造で管理するファイルシステムを有する計算機システムにおいて、
前記計算機システムに前記２次記憶装置として設けられた全物理ディスクの記憶領域をボリュームグループとして管理し、前記計算機システムの稼働中に記憶領域を当該記憶領域のサイズを拡張可能な論理ボリュームとして動的に生成する論理ボリューム管理手段と、
前記ファイルシステムの更新に関する世代別に異なるログ記憶領域が作成されるように、前記ファイルシステムのイメージを復元すべき時点に到達する度に、前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を前記論理ボリューム管理手段を用いて前記論理ボリュームとして動的に作成するログ記憶領域作成手段と、
前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶領域作成手段によって作成された最新世代のログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手段と、
前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域の残りサイズが所定値以下に低下した場合、前記最新世代のログ記憶領域のサイズを前記論理ボリューム管理手段を用いて拡張する手段と、
前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域から、前記ファイルシステムのイメージを復元すべき時点として指定された過去の所定世代に対応するログ記憶領域に渡って蓄積されている更新前イメージと、前記ファイルシステムの現在のイメージとに基づいて、前記指定された世代に対応する前記ファイルシステムのイメージを復元する復元手段とを具備することを特徴とする計算機システム。 - ２次記憶装置上でファイルを階層構造で管理する計算機システム内のファイルシステムを過去の所定の時点に対応するイメージに復元するためのプログラムであって、
前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に、前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を作成するログ記憶領域作成手順と、
前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手順と、
前記ログ記憶領域に蓄積されている更新前イメージと前記ファイルシステムの現在のイメージとに基づいて、過去の所定の時点における前記ファイルシステムのイメージを復元する復元手順とを前記計算機システムに実行させることを特徴とするプログラム。 - 前記ログ記憶領域作成手順は、前記ファイルシステムのイメージを復元すべき隣接する２つの時点間を単位とする世代毎に当該世代の更新履歴に対応する更新前イメージが異なるログ記憶領域に格納されるように、前記世代別に異なるログ記憶領域を前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域に作成する処理を前記計算機システムに実行させる手順を含むことを特徴とする請求項８記載のプログラム。
- ２次記憶装置上でファイルを階層構造で管理する計算機システム内のファイルシステムを過去の所定の時点に対応するイメージに復元するためのプログラムであって、
前記計算機システムは、前記計算機システムに前記２次記憶装置として設けられた全物理ディスクの記憶領域をボリュームグループとして管理し、前記計算機システムの稼働中に記憶領域を当該記憶領域のサイズを拡張可能な論理ボリュームとして動的に生成する論理ボリューム管理機能を有しており、
前記ファイルシステムの更新に関する世代別に異なるログ記憶領域が作成されるように、前記ファイルシステムのイメージを復元すべき時点に到達する度に、前記ファイルシステムとは独立した前記２次記憶装置上の記憶領域上に前記ファイルシステムの更新履歴を蓄積するためのログ記憶領域を、前記論理ボリューム管理機能を用いて前記論理ボリュームとして動的に作成するログ記憶領域作成手順と、
前記ファイルシステムで使用される前記２次記憶装置上のブロックの内容が更新される度に、当該ブロックの更新前の内容およびブロック番号を前記ログ記憶領域作成手段によって作成された最新世代のログ記憶記憶領域に更新前イメージとして格納する更新前イメージ格納手順と、
前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域の残りサイズが所定値以下に低下した場合、前記最新世代のログ記憶領域のサイズを前記論理ボリューム管理機能を用いて拡張する手順と、
前記更新前イメージの格納に現在使用されている最新世代のログ記憶領域から、前記ファイルシステムのイメージを復元すべき時点として指定された過去の所定世代に対応するログ記憶領域に渡って蓄積されている更新前イメージと、前記ファイルシステムの現在のイメージとに基づいて、前記指定された世代に対応する前記ファイルシステムのイメージを復元する復元手順とを前記計算機システムに実行させることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003204507A JP2005050024A (ja) | 2003-07-31 | 2003-07-31 | 計算機システムおよびプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003204507A JP2005050024A (ja) | 2003-07-31 | 2003-07-31 | 計算機システムおよびプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005050024A true JP2005050024A (ja) | 2005-02-24 |
Family
ID=34263492
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003204507A Pending JP2005050024A (ja) | 2003-07-31 | 2003-07-31 | 計算機システムおよびプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005050024A (ja) |
Cited By (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005301499A (ja) * | 2004-04-08 | 2005-10-27 | Hitachi Ltd | ディスクアレイ装置及びディスクアレイ装置の制御方法 |
| JP2005301628A (ja) * | 2004-04-09 | 2005-10-27 | Hitachi Ltd | ディスクアレイ装置 |
| JP2006279501A (ja) * | 2005-03-29 | 2006-10-12 | Nec Corp | メールボックスシステム及びその装置及びそのジャーナル転送制御方法 |
| JP2006302253A (ja) * | 2005-03-25 | 2006-11-02 | Hitachi Ltd | ストレージシステム |
| JP2007079774A (ja) * | 2005-09-13 | 2007-03-29 | Hitachi Ltd | ファイルシステムの構築方法 |
| JP2007122268A (ja) * | 2005-10-26 | 2007-05-17 | Hitachi Ltd | 計算機システム、記憶領域割当方法及び管理計算機 |
| JP2007257317A (ja) * | 2006-03-23 | 2007-10-04 | Hitachi Ltd | 記憶システム及び記憶領域解放方法並びにストレージシステム |
| JP2008181274A (ja) * | 2007-01-24 | 2008-08-07 | Hitachi Ltd | 管理装置および管理方法 |
| JP2009505310A (ja) * | 2005-12-30 | 2009-02-05 | コパン システムズ インコーポレイテッド | 電力効率の良い大容量のスケーラブルストレージシステムにおける補助データにアクセスするための方法およびシステム |
| JP2009146228A (ja) * | 2007-12-14 | 2009-07-02 | Fujitsu Ltd | バックアップ装置、バックアップ方法およびバックアッププログラム |
| JP2010049488A (ja) * | 2008-08-21 | 2010-03-04 | Hitachi Ltd | ストレージシステム及びデータ管理方法 |
| JP2013502655A (ja) * | 2009-08-21 | 2013-01-24 | シマンテック コーポレーション | Ｎａｓ装置上の仮想ディスクイメージファイルのプロキシバックアップ |
| WO2015093026A1 (ja) | 2013-12-17 | 2015-06-25 | 日本電気株式会社 | 書き込み情報記憶装置、方法、及び、記録媒体 |
| CN105190533A (zh) * | 2013-03-15 | 2015-12-23 | 亚马逊科技公司 | 原位快照 |
| US10534768B2 (en) | 2013-12-02 | 2020-01-14 | Amazon Technologies, Inc. | Optimized log storage for asynchronous log updates |
| US10698881B2 (en) | 2013-03-15 | 2020-06-30 | Amazon Technologies, Inc. | Database system with database engine and separate distributed storage service |
| US10747746B2 (en) | 2013-04-30 | 2020-08-18 | Amazon Technologies, Inc. | Efficient read replicas |
| US10872076B2 (en) | 2013-05-13 | 2020-12-22 | Amazon Technologies, Inc. | Transaction ordering |
| US11030055B2 (en) | 2013-03-15 | 2021-06-08 | Amazon Technologies, Inc. | Fast crash recovery for distributed database systems |
| US11120152B2 (en) | 2013-09-20 | 2021-09-14 | Amazon Technologies, Inc. | Dynamic quorum membership changes |
| JP7378870B2 (ja) | 2018-06-01 | 2023-11-14 | アリババ・グループ・ホールディング・リミテッド | ファイルシステムデータアクセス方法およびファイルシステム |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10232800A (ja) * | 1997-02-19 | 1998-09-02 | Hitachi Ltd | 磁気テープ記憶装置 |
| JPH11194964A (ja) * | 1998-01-05 | 1999-07-21 | Hitachi Ltd | データ記録システム |
| JP2001142750A (ja) * | 1999-11-11 | 2001-05-25 | Nec Corp | データファイル記録管理装置及び方法並びに記録媒体 |
| JP2002278819A (ja) * | 2001-03-21 | 2002-09-27 | Toshiba Corp | スナップショットイメージの世代管理方法、記憶媒体、及び世代管理装置 |
-
2003
- 2003-07-31 JP JP2003204507A patent/JP2005050024A/ja active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10232800A (ja) * | 1997-02-19 | 1998-09-02 | Hitachi Ltd | 磁気テープ記憶装置 |
| JPH11194964A (ja) * | 1998-01-05 | 1999-07-21 | Hitachi Ltd | データ記録システム |
| JP2001142750A (ja) * | 1999-11-11 | 2001-05-25 | Nec Corp | データファイル記録管理装置及び方法並びに記録媒体 |
| JP2002278819A (ja) * | 2001-03-21 | 2002-09-27 | Toshiba Corp | スナップショットイメージの世代管理方法、記憶媒体、及び世代管理装置 |
Non-Patent Citations (6)
| Title |
|---|
| "「ＳｙｓｔｅｍＷａｌｋｅｒ Ｖ１０」統合ストレージ管理製品", 日経コンピュータ, CSND200200782019, 25 March 2002 (2002-03-25), JP, pages 258 - 259, ISSN: 0000892966 * |
| "ＳＡＮｓｙｍｐｈｏｎｙ ４．０", ＳＵＮＷＯＲＬＤ, vol. 第11巻第10号, CSND200301144013, 1 October 2001 (2001-10-01), JP, pages 133, ISSN: 0000892965 * |
| 伊東 達雄、吉田 淳、武田 保真: "専用キットで簡単にできる オールインワン・サーバー自作術", 日経ＬＩＮＵＸ, vol. 第5巻 第6号, CSND200400515025, 8 June 2003 (2003-06-08), JP, pages 58 - 75, ISSN: 0000817034 * |
| 松山 貴之: "解説 新しいストレージ・ソフトでＲＤＢＭＳの可用性を向上", 日経オープンシステム, vol. 第１０７号, CSND200301481001, 15 February 2002 (2002-02-15), JP, pages 92 - 96, ISSN: 0000863585 * |
| 松山 貴之: "解説●ＳＡＮが抱える４つの弱点と，補完製品の実力", 日経オープンシステム, vol. 第108号, CSND200301552004, 15 March 2002 (2002-03-15), JP, pages 108 - 111, ISSN: 0000892964 * |
| 石川 竜也: "導入・検証Ｗｉｎｄｏｗｓソリューションラボ", Ｎ＋Ｉ ＮＥＴＷＯＲＫ, vol. 第3巻第2号, CSND200400151005, 1 February 2003 (2003-02-01), JP, pages 112 - 117, ISSN: 0000863587 * |
Cited By (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005301499A (ja) * | 2004-04-08 | 2005-10-27 | Hitachi Ltd | ディスクアレイ装置及びディスクアレイ装置の制御方法 |
| US7752390B2 (en) | 2004-04-08 | 2010-07-06 | Hitachi, Ltd. | Disk array apparatus and control method for disk array apparatus |
| JP4681247B2 (ja) * | 2004-04-08 | 2011-05-11 | 株式会社日立製作所 | ディスクアレイ装置及びディスクアレイ装置の制御方法 |
| JP2005301628A (ja) * | 2004-04-09 | 2005-10-27 | Hitachi Ltd | ディスクアレイ装置 |
| JP4681249B2 (ja) * | 2004-04-09 | 2011-05-11 | 株式会社日立製作所 | ディスクアレイ装置 |
| US7698518B2 (en) | 2004-04-09 | 2010-04-13 | Hitachi, Ltd. | Disk array with capacity management |
| JP2006302253A (ja) * | 2005-03-25 | 2006-11-02 | Hitachi Ltd | ストレージシステム |
| JP2006279501A (ja) * | 2005-03-29 | 2006-10-12 | Nec Corp | メールボックスシステム及びその装置及びそのジャーナル転送制御方法 |
| US8392685B2 (en) | 2005-09-13 | 2013-03-05 | Hitachi, Ltd. | Arrangements for managing metadata of an integrated logical unit including differing types of storage media |
| JP4704161B2 (ja) * | 2005-09-13 | 2011-06-15 | 株式会社日立製作所 | ファイルシステムの構築方法 |
| US8078819B2 (en) | 2005-09-13 | 2011-12-13 | Hitachi, Ltd. | Arrangements for managing metadata of an integrated logical unit including differing types of storage media |
| JP2007079774A (ja) * | 2005-09-13 | 2007-03-29 | Hitachi Ltd | ファイルシステムの構築方法 |
| JP4693589B2 (ja) * | 2005-10-26 | 2011-06-01 | 株式会社日立製作所 | 計算機システム、記憶領域割当方法及び管理計算機 |
| JP2007122268A (ja) * | 2005-10-26 | 2007-05-17 | Hitachi Ltd | 計算機システム、記憶領域割当方法及び管理計算機 |
| JP2009505310A (ja) * | 2005-12-30 | 2009-02-05 | コパン システムズ インコーポレイテッド | 電力効率の良い大容量のスケーラブルストレージシステムにおける補助データにアクセスするための方法およびシステム |
| US8069331B2 (en) | 2006-03-23 | 2011-11-29 | Hitachi, Ltd. | Storage system, storage extent release method and storage apparatus |
| US8347060B2 (en) | 2006-03-23 | 2013-01-01 | Hitachi, Ltd. | Storage system, storage extent release method and storage apparatus |
| JP2007257317A (ja) * | 2006-03-23 | 2007-10-04 | Hitachi Ltd | 記憶システム及び記憶領域解放方法並びにストレージシステム |
| JP2008181274A (ja) * | 2007-01-24 | 2008-08-07 | Hitachi Ltd | 管理装置および管理方法 |
| JP2009146228A (ja) * | 2007-12-14 | 2009-07-02 | Fujitsu Ltd | バックアップ装置、バックアップ方法およびバックアッププログラム |
| JP2010049488A (ja) * | 2008-08-21 | 2010-03-04 | Hitachi Ltd | ストレージシステム及びデータ管理方法 |
| JP2013502655A (ja) * | 2009-08-21 | 2013-01-24 | シマンテック コーポレーション | Ｎａｓ装置上の仮想ディスクイメージファイルのプロキシバックアップ |
| CN105190533A (zh) * | 2013-03-15 | 2015-12-23 | 亚马逊科技公司 | 原位快照 |
| JP2016511498A (ja) * | 2013-03-15 | 2016-04-14 | アマゾン・テクノロジーズ・インコーポレーテッド | インプレーススナップショット |
| US10180951B2 (en) | 2013-03-15 | 2019-01-15 | Amazon Technologies, Inc. | Place snapshots |
| US10698881B2 (en) | 2013-03-15 | 2020-06-30 | Amazon Technologies, Inc. | Database system with database engine and separate distributed storage service |
| US11030055B2 (en) | 2013-03-15 | 2021-06-08 | Amazon Technologies, Inc. | Fast crash recovery for distributed database systems |
| US11500852B2 (en) | 2013-03-15 | 2022-11-15 | Amazon Technologies, Inc. | Database system with database engine and separate distributed storage service |
| US10747746B2 (en) | 2013-04-30 | 2020-08-18 | Amazon Technologies, Inc. | Efficient read replicas |
| US10872076B2 (en) | 2013-05-13 | 2020-12-22 | Amazon Technologies, Inc. | Transaction ordering |
| US11120152B2 (en) | 2013-09-20 | 2021-09-14 | Amazon Technologies, Inc. | Dynamic quorum membership changes |
| US10534768B2 (en) | 2013-12-02 | 2020-01-14 | Amazon Technologies, Inc. | Optimized log storage for asynchronous log updates |
| WO2015093026A1 (ja) | 2013-12-17 | 2015-06-25 | 日本電気株式会社 | 書き込み情報記憶装置、方法、及び、記録媒体 |
| JP7378870B2 (ja) | 2018-06-01 | 2023-11-14 | アリババ・グループ・ホールディング・リミテッド | ファイルシステムデータアクセス方法およびファイルシステム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4292882B2 (ja) | 複数のスナップショット維持方法及びサーバ装置及びストレージ装置 | |
| KR101137299B1 (ko) | 스냅샷을 제공하는 파일 시스템에 대한 계층적 저장 관리 | |
| JP2005050024A (ja) | 計算機システムおよびプログラム | |
| US7685378B2 (en) | Methods and apparatus for adjusting a journal area for continuous data protection | |
| US10762039B2 (en) | Backup and restoration for storage system | |
| US7257690B1 (en) | Log-structured temporal shadow store | |
| JP4199993B2 (ja) | スナップショット取得方法 | |
| JP5346536B2 (ja) | 情報バックアップ／リストア処理装置、及び情報バックアップ／リストア処理システム | |
| US8271753B2 (en) | Storage controller and storage control method for copying a snapshot using copy difference information | |
| US6880102B1 (en) | Method and system for managing storage systems containing multiple data storage devices | |
| JP4336129B2 (ja) | 複数のスナップショットを管理するシステム及び方法 | |
| EP1918836B1 (en) | Apparatus and method for a hardware-based file system | |
| JP5984151B2 (ja) | データの復旧方法、プログラムおよびデータ処理システム | |
| EP1698977B1 (en) | Storage system and method for acquisition and utilisation of snapshots | |
| US7383465B1 (en) | Undoable volume using write logging | |
| EP1695220A1 (en) | System and method for supporting asynchronous data replication with very short update intervals | |
| JP2005510780A (ja) | コンピュータシステム間でのオブジェクトの共有 | |
| US6629203B1 (en) | Alternating shadow directories in pairs of storage spaces for data storage | |
| CN106528338B (zh) | 一种远程数据复制方法、存储设备及存储系统 | |
| CN115617264A (zh) | 分布式存储方法及装置 | |
| JP2006011811A (ja) | 記憶制御システム及び記憶制御方法 | |
| JP3896077B2 (ja) | 計算機システムおよびファイル管理方法 | |
| JPH11120057A (ja) | ファイルバックアップ方法 | |
| JP4394467B2 (ja) | ストレージシステム、サーバ装置及び先行コピーデータ生成方法 | |
| JP2007305012A (ja) | Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070213 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070416 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070612 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070808 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070911 |