(57)【要約】本発明は、WORMストレージ実施形態内の削除や変更が禁止されたデータセットの中に、指定された保有日を提供する。この保有日スキームは、工業所有権を有するアプリケーションプログラムインタフェースやプロトコルを一切利用せず、一般に使用されているオペレーティングシステムにおいて使用可能なファイル（又は、他のデータコンテナ、データセット、又は、ブロックベースの論理ユニット番号）プロパティ内の本来の機能を使用する。一実施形態において、この保有日／時刻は、収容前にファイルの最終更新時刻を問い合せ、その値に保有期間を加算して保有日を導出することによって算出される。その保有日を過ぎると、WORMからそのファイルを解放することができる。収容前に、算出された保有日は、そのファイルの「最終アクセス時刻」プロパティ／属性フィールド、又は、保有日に使用してもWORM状態におけるファイル管理に影響を与えないそのファイルに永久的に関連付けられた他のメタデータフィールドに格納される。このフィールドはWORMコンテキストにおいて使用されるため、このフィールドは、その日付を記憶するように構成することができる。いったん保有日がそのフィールドに記憶されると、その保有日の変更は禁止される。保有日の延長（又は短縮）が必要な場合、最終アクセス時刻フィールドを更新し、既存の最終アクセス時刻値に新たな保有期間を加算し、そのファイルの新たな保有日を導出する。保有日を過ぎると、システムは、期限を過ぎたファイル／データセットの削除を許可する。
2007524954.tif 000002
【特許請求の範囲】
【請求項１】
追記型(WORM)ストレージシステムにおいてデータセットに保有期間を与える方法であって、
WORMデータセットを作成し、該WORMデータセットをWORMデータ構造に保存するステップと、
前記データセットに永久的に関連付けられた前記データセットのデータに保有期間を設定するステップと、
前記WORMデータセットを前記WORMデータ構造に収容し、その後、前記ストレージシステムは前記保有期間の短縮を禁止し、前記ストレージシステムは前記保有期間の満了後の時点まで前記WORMデータセットに対する変更を全て禁止するステップと
からなる方法。
【請求項２】
前記保有期間の満了後、前記ストレージシステムは、前記WORMデータ構造からの前記WORMデータセットの削除だけを許可し、前記WORMデータセットに対する他の変更を全て禁止する、請求項１に記載の方法。
【請求項３】
前記保有期間が設定される前記データは、前記データセットに関連する時刻値に関連するファイル属性、又は、ファイルプロパティである、請求項２に記載の方法。
【請求項４】
前記ファイル属性、又は、前記ファイルプロパティは、最終アクセス時刻属性、又は、最終アクセス時刻プロパティである、請求項３に記載の方法。
【請求項５】
前記収容するステップは、前記データセットに関連するリードオンリーファイル属性を非リードオンリー値からリードオンリー値に変更することを含む、請求項３に記載の方法。
【請求項６】
前記保有期間に延長期間を加算し、延長された保有期間を導出し、該延長された保有期間を、前記保有期間が設定される前記データに記憶することにより、前記保有日を延長するステップを更に含む、請求項１に記載の方法。
【請求項７】
前記延長するステップは、前記延長期間が前記保有期間よりも時間的に後であるか否かを確認し、前記保有期間よりも時間的に前の延長期間を拒否することを含む、請求項６に記載の方法。
【請求項８】
前記保有期間を前記ストレージシステムに関連するコンプライアンス・クロックの時刻値と比較し、該時刻値が前記保有期間以後の値になった後、前記WORMデータセットの削除だけを許可することを更に含む、請求項１に記載の方法。
【請求項９】
前記ストレージシステムの規則的な反復動作をカウントし、該反復動作のカウントに基づいて、前記時刻値を生成することを更に含む、請求項８に記載の方法。
【請求項１０】
前記時刻値を前記WORMデータ構造における時間記憶WORMデータセットに記憶し、前記カウントの中断後に、前記時間記憶WORMデータセットにアクセスして、前記時刻値のカウントを再開することを更に含む、請求項９に記載の方法。
【請求項１１】
前記ストレージシステムは、前記WORMデータ構造における前記WORMデータセットを含むディレクトリパスのリネームを禁止するように構成される、請求項１に記載の方法。
【請求項１２】
前記収容するステップは、前記ストレージシステムに相互接続されたクライアント上のアプリケーションによって実施される、請求項１に記載の方法。
【請求項１３】
前記WORMデータ構造をミラー宛先に作成し、作成されたWORMデータセットを前記宛先WORMデータ構造に送信し、収容することを更に含む、請求項１に記載の方法。
【請求項１４】
ファイルシステムを有する追記型(WORM)ストレージシステムであって、
ファイルシステムに常駐し、ファイルが指定されたボリュームに記憶された後、該ファイルに与えられたオープンプロトコルファイル属性に基づいて、該ファイルを前記指定されたボリュームに収容し、収容された後、該ファイルを変更することが出来ない選択された保有期間を提供するWORMユーティリティを含む、WORMストレージシステム。
【請求項１５】
前記オープンプロトコルファイル属性は、リードオンリーファイル属性からなる、請求項１４に記載のWORMストレージシステム。
【請求項１６】
前記ファイルシステムは、前記ファイルを有するディレクトリの削除を禁止するように構成される、請求項１４に記載のWORMストレージシステム。
【請求項１７】
前記保有期間は、オープンプロトコルファイル属性に記憶される、請求項１４に記載のWORMストレージシステム。
【請求項１８】
前記保有期間が記憶される前記ファイル属性は、最終アクセス時刻属性からなる、請求項１７に記載のWORMストレージシステム。
【請求項１９】
前記WORMユーティリティは、前記保有期間をコンプライアンス・クロックの時刻値と比較し、前記保有期間が前記時刻値よりも以前になった後、所定の変更を許可するように構成される、請求項１４に記載のWORMストレージシステム。
【請求項２０】
前記所定の変更は、前記ファイルの削除だけからなる、請求項１９に記載のWORMストレージシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、William P. McGovern他による「WRITE-ONCE-READ-MANY STORAGE SYSTEM AND METHOD FOR IMPLEMENTING THE SAME」と題する米国特許出願第１０／３９１，２４５号に関連し、この米国特許出願は参照により本明細書に援用される。
発明の分野
本発明は、データ完全性向上のための追記機能を有するデータ記憶装置に関する。
【背景技術】
【０００２】
発明の背景
ファイルサーバは、ディスクのような記憶装置における情報の編成に関連するファイルサービスを提供するコンピュータである。ファイルサーバ又は「ファイラ」は、情報をディレクトリやファイルの階層構造としてディスク上に論理編成するためのファイルシステムを実施するストレージオペレーティングシステムを有する。「ディスク上」の各ファイルは、例えば、情報を記憶するように構成された１セットのディスクブロックのようなデータ構造として実施される場合がある。一方、ディレクトリは、他のファイルやディレクトリに関する情報を記憶するための特殊形式のファイルとして実施される場合がある。
【０００３】
ファイラは、情報配送のクライアント／サーバモデルに従って動作するように更に構成され、それによって、多数のクライアントが、例えばファイラのようなサーバ上に記憶されたファイルにアクセスすることができる。このモデルにおいて、クライアントは、コンピュータ上で実施されるデータベースアプリケーションのようなアプリケーションを有する場合があり、直接接続、あるいは、ポイント・ツー・ポイント接続、共有ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）又はインターネットのような公共ネットワークを介して実施される仮想私設ネットワーク（ＶＰＮ）を介してファイラに「接続」される場合がある。各クライアントは、ネットワークを介してファイルシステムプロトコルメッセージを（パケットの形で）ファイラに発行することによって、ファイラに対し、ファイルシステムのサービスを要求することができる。
【０００４】
ファイルシステムの一般的タイプは「定位置書き込み型」ファイルシステムであり、その一例は、従来のバークレイ・ファーストファイルシステムである。「ファイルシステム」とは、ディスクのような記憶装置上のデータやメタデータの構造を一般に言い、ファイルシステムによって、そうしたディスク上のデータの読み書きが可能になる。定位置書き込み型ファイルシステムでは、ディスク上のinodeやデータブロックのようなデータ構造の位置が、一般に固定されている。inodeはファイルに関するメタデータのような情報の記憶に使用されるデータ構造であるのに対し、データブロックは、そのファイルの実際のデータの記憶に使用される構造である。inodeに記憶される情報には、例えば、ファイルの所有者、ファイルのアクセス権、ファイルのサイズ、ファイルタイプ、及び、ファイルのデータブロックのディスク上の位置の参照などがある。ファイルデータの位置の参照は、ポインタとしてinodeに与えられ、ファイル内のデータ量によっては、間接ブロックを更に参照する場合もあり、従ってデータブロックを参照する場合がある。定位置書き込み型ファイルシステムによれば、inodeやデータブロックに対する変更は「定位置」で行われる。ファイルの更新によってファイルのデータの品質が拡張される場合、更に別のデータブロックが割り当てられ、適当なinodeがそのデータブロックを参照するように更新される。
【０００５】
ファイルシステムの他のタイプとして、ディスク上のデータを上書きしないWrite Anywhereファイルシステムがある。ディスク上のデータブロックをディスクからメモリに取り出し（読み出し）、そのデータブロックを新たなデータで「汚す」と、そのデータブロックはディスク上の新たな位置に記憶（書き込み）され、それによって書き込み性能が最適化される。Write Anywhereファイルシステムは、データがディスク上に実質的に連続的に配置されるような最適ディスクレイアウトを最初に想定している。この最適ディスクレイアウトによって、効率的なアクセス動作が得られ、特に、ディスクに対するシーケンシャルリード動作の場合に効率的なアクセス動作が得られる。ファイラ上で動作するように構成されたWrite Anywhereファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから入手できるWrite Anywhere File Layout(WAFL)である。WAFLファイルシステムは、マイクロカーネルの内部で、ファイラ及び関連ディスクストレージの全体的プロトコルスタックの一部として実施される。このマイクロカーネルは、ネットワーク接続されたクライアントからのファイルサービス要求の処理を行うためにファイラに常駐するネットワーク・アプライアンスのData ONTAPソフトウェアの一部として提供される。
【０００６】
本明細書で使用される「ストレージオペレーティングシステム」という用語は通常、データアクセスを管理するための、コンピュータ上で動作するコンピュータ実行可能コードを意味し、ファイラの場合、コンピュータ実行可能コードは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから入手できるマイクロカーネルとして実施されるData ONTAPストレージオペレーティングシステムのようなファイルシステムセマンティックを実施する場合がある。Data ONTAPストレージオペレーティングシステムは、Write Anywhere File Layout (WAFL)ファイルシステムを実施する。ストレージオペレーティングシステムは、UNIXやWindows NTのような汎用オペレーティングシステム、あるいは、本明細書に記載するような記憶目的のために構成された、設定可能機能を備えた汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施することも可能である。
【０００７】
ディスクストレージは一般に、複数のストレージディスクからなる１以上のストレージ「ボリューム」として実施され、ボリュームによって記憶空間の全体的論理配置が画定される。現在市販されているファイラ実施形態は、多数（例えば、１５０以上）の個別のボリュームを提供することができる。本明細書の目的のために、各ボリュームは独自のファイルシステムに関係し、ボリュームとファイルシステムは一般に同義語として使用されるものとする。ボリューム内のディスクは通常、１以上のＲＡＩＤグループとして編成される。ＲＡＩＤ実施形態は、データをＲＡＩＤグループ内の所与の数の物理ディスクにわたって「ストライプ」状に書き込み、そのストライプ化されたデータに関するパリティ情報を適切にキャッシュすることによって、データ記憶の信頼性／完全性を向上させる。WAFLファイルシステムの例の場合、ＲＡＩＤ４実施形態を使用すると有利である。この実施形態は具体的には、１グループのディスクにわたるデータのストライピングを課し、そのＲＡＩＤグループ内の特定のディスクに別個にパリティをキャッシュする。本明細書に記載する「ボリューム」は通常、ＲＡＩＤ４又は等価な高信頼性実施形態に従って構成された、少なくとも１つのデータディスク及び１つの関連パリティディスクから構成される（あるいは、データパーティションとパリティパーティションを一台のディスク上に設けることも可能である）。
【０００８】
データ記憶は、近年重要性が益々増大し、金融取引、並びに、銀行、政府施設／請負業者、防衛、医療施設、製薬会社、及び、セキュリティ仲介業務のような他の細心の注意を要する業務における多くの産業取引の中心部分になっている。それらの環境の多くでは、特定のデータを不変的且つ変更不能な形で記憶しなければならない。現在の関心事に照らして、この要求は、制度上の不正や誤った管理を超えて成長を続け、一部の犯罪者に対し、罪になるようなデータの消去や変更の誘惑を与えている。不変的な扱いが必要とされるデータの典型的な形態には、電子メール、金融文書、取引記録、及び、重要な行動や決定の証明としての役割をする任意の他の記録などがある。あまり重要でない／無秩序な環境であっても、安全で変更不能なデータキャッシュを記憶する機能は、強く望まれている。例えば、工学技術、医療、法律、及び、他の専門の企業は、重要データ（発明レポート、設計ファイル、クライアントとのやりとり、医学画像など）のキャッシュを作成し、それを長期間にわたって変更不可能な状態でオンラインに維持することを望むことがある。こうしたキャッシュによれば、信頼性の高い参考文献や証明書をクライアント及び関係者に提供することができる。
【０００９】
非常に規則正しい環境の一例として、米国証券取引委員会（ＳＥＣ）（その本体は、公共団体に関連する機密取引及びレポートを統制する）は、仲介機関や投資機関の文書保持を管理する規則１７条ａ−４を発布している。この規則は、クライアントによる種々の売買及び取引に関係する電子メールその他の文書を記憶する設備は、数年にわたって不変状態且つ変更不可能な状態に維持しなければならず、それらの記録は、ＳＥＣその他の監督機関に即座に提供できるように維持しなければならないというものである。この規則に違反した場合、重大な制裁措置を受ける可能性がある。
【００１０】
WORMストレージシステムを実施するために、数年にわたって、テープドライブ、電気光学媒体などを使用する種々の従来技術のアプローチが採用されている。それらのシステムは、記憶サイズ、速度管理要件、あるいは、それらの（及び他の）ファクタの組み合わせの点で、幾つかの欠点を有している。
【００１１】
上で参照により援用した「WRITE-ONCE-READ-MANY STORAGE SYSTEM AND METHOD FOR IMPLEMENTING THE SAME」と題する米国特許出願第１０／３９１，２４５号には、従来のフォールトトレラントな（ＲＡＩＤを利用した）ディスクストレージ（又は、同様の書替可能媒体）をWORMストレージのプラットフォームとして使用する、WORMストレージにとって特に有用なアプローチが記載されている。記載されたシステムは、ディスクの記憶容量が大きく、ディスクが比較的安価で、既に実施されているストレージに対してディスクを簡単に追加することができるという利点がある。しかしながら、既存のオペレーティングシステムやプロトコルが一般に、取り付けられたディスクの自由な書き替えや消去を具体的に可能にするセマンティックで一般に設計されていることを考えれば、それらのディスクは、もともと書替可能、及び／又は、消去可能でもある。従って、記載されたWORMストレージアプローチは、WORM指定されたデータの改変を完全に防止するように特別に構成される。また、ソリューションの寿命を維持し、出来る限り多数のクライアントから利用可能にするために、記載されたWORM実施形態は、CIFSやNFSのようなオープンプロトコルを使用していて、それらのプロトコルや、それらのプロトコルを使用するアプリケーションに対する改変は最小限で済み、クライアントアプリケーションに対する足跡も最小限で済む。従って、システムは、ファイルを格納するWORMストレージのように編成され、いったんファイルがWORMストレージに収容されると、そのファイルを消去したり修正したりすることはできない。WROMボリューム内でファイルの識別に使用される何らかのファイルパス又はディレクトリツリー構造は、その削除が禁止される。
【００１２】
記載されたWROMシステムでは、指定されたWORMファイル（又は、他の「データセット」）を記憶可能なWORMボリューム（又は、他のWORM指定されたデータ組織構造）を管理者が作成する。そしてクライアントは、適当なプロトコルセマンティックを使用して適当なWORMファイルを作成する。ファイルはそのボリュームに書き込まれ、ファイルの属性を非リードオンリー状態からリードオンリー状態へ変更することにより、WROM状態にされる。ファイルシステムは、WROM状態のファイルをそのファイルの属性及びメタデータとともに永久的に記憶し、その永久的WORM状態を使用して、WORMボリューム上のWORMファイルを認識する。以後、クライアント、管理者、又は、その他の者によるファイル属性の変更、ファイルへの書き込み、及び、ファイルの削除の試みは全て拒否され、要求拒否メッセージがそれを試みた者に返される。ファイルを削除することができないため、従来のファイルシステムセマンティックは、ディレクトリパスの削除を禁止している。同様に、一実施形態においてファイルシステムはディレクトリのリネームも許可せず、それによって、ディレクトリ構造内のWORMファイルの信頼性のある不変的な識別を可能にしている。
【００１３】
クライアントは、WORMストレージボリュームへのWORMファイルの収容を、コマンドラインインタフェースを介して対話的態様で実施することができる。あるいは、WORMセマンティックに精通したアプリケーションプログラムが、適当なアプリケーションプログラム又は他のプログラマチックコマンド構造を使用してファイルを収容するように構成されることがある。同様に、クライアントがファイルサーバ／ファイルシステムとの通信に使用するNFSやCIFSのようなオープンプロトコルに変更を加え、ファイルをクローズする動作のようなキーイベントが発生したときに、作成されたファイルを自動的に収容できるようにする場合もある。プロトコルやファイルシステムに変更を加え、ボリューム内に特殊なWORMディレクトリを作成できるようにする場合もある。ボリューム内のWORMファイルをクライアントが容易に識別できるような適当なWORMファイル拡張を行う場合もある。また、特定のミラーリング機能やバックアップ機能は許可されていても、ボリュームを前の時点まで復元又は復帰させる他のバックアップ機能は無効にされる場合がある。
【００１４】
WORMデータ記憶装置を管理する多くの規制スキームは、保有期間に関する規定を有し、その保有期間の満了後でなければ、WORMデータを破棄することはできない。作成中のレコードに対して適用される指定保有期間が存在しない場合、それらの規則によれば、一般に、永久的な保有期間が指定される。テープや電気光学媒体のようなリムーバブル媒体の場合、媒体は慎重に索引付けされ、その保有期間の間、（大抵は安全な場所に）記憶される。適用された保有日を過ぎると、媒体は記憶装置から取り出され、物理的に破壊される。ディスクストレージは、何らかの特定レコードがもはや不要になった場合、書き替えて再使用することがもともと可能であるから、ディスク上の種々のレコードに対するWORM保護は保有日を有し、その保有日を過ぎると、期間を満了したWORMレコード及び関連データは削除される。従って、物理的媒体の破壊により材料を浪費することなく、ストレージリソースが確保され、保有期間を過ぎたWORMデータの規則正しく予測可能な削除が確保される。
【００１５】
マサチューセッツ州ホプキントンにあるＥＭＣコーポレーションから「Ｃｅｎｔｒａ」という商標名で販売されているWROMストレージシステムは、レコード記憶の保有日の基本形態が可能である。このシステムは、カスタマイズされた種々のLinuxオペレーティングシステムを使用する、ネットワーク接続された一群の汎用コンピュータシステムを使用する。これらのコンピュータは、ストレージシステムとの間のインタフェースに、オープンプロトコルやオープンスタンダードＡＰＩアプローチとは対照的な、工業所有権を有するアプリケーションプログラムインタフェース（ＡＰＩ）や工業所有権を有するプロトコルを使用している。そのため、アプリケーションは、ユーザとストレージシステムとの間に配置された工業所有権を有するメカニズム、すなわち「ゲートウェイ」を通じてしか、ストレージにアクセスしてレコードを操作することができない。ゲートウェイは、オープンプロトコルをストレージシステムで利用可能な工業所有権を有するプロトコルに変換するものである。
【００１６】
この形態のWORMストレージシステムは、いわゆる「コンテント・アドレッサブル・ストレージ」（ＣＡＳ）を使用して、記憶されたレコードを管理する。ＣＡＳは、ＭＤ５ハッシュのようなアルゴリズムを使用して、何らかのWORM記憶されたレコードの内容のデジタル署名を計算し、全てのレコードのそれぞれについて（「内容アドレス」の）一意の（重複しない）キーを生成することによってレコードを管理する。レコードのデジタル署名表現は「キー」又は「内容アドレス」として使用され、記憶されたオブジェクトへの以後の参照は全て、そのキーを使用して行わなければならない。これは、記憶されたあらゆるオブジェクトについて、ストレージシステムが一意のキーを生成し、それをアプリケーションに返すことによる、「手荷物預かり証」システムに似たものとして説明されることが多い。アプリケーションは、それらの内容アドレスを管理及び保存する働きを持ち、ストレージシステムの外部で実施されなければならない。
【００１７】
記憶レコードに保有情報を関連付けるために、工業所有権を有するＡＰＩは、工業所有権を有するフォーマットのメタデータを、記憶オブジェクトに関連付けることを許可する。このメタデータ情報には、レコードの保有情報を含めることができる。ＡＰＩは、保有日を更に先に延ばす機能を有し、構成によっては、保有情報を付けずに提出されたレコードに対し、無期限の保有日を割り当てる場合がある。ＣＡＳアーキテクチャであることから、システムに書き込まれたあらゆるオブジェクトは、それが一意の内容を有するものである限り、一意の内容アドレスを有する一意のオブジェクトとして記憶される。WORM機能を有効化するために、ＡＰＩは、期限満了前のオブジェクトの削除を禁止する。既存のオブジェクトの変更は不可能である。なぜなら、オブジェクトの内容に何らかの変化があると、新たな内容アドレスが発生し、その結果、ストレージシステム内に新たなオブジェクトが生成されるからである。
【００１８】
このシステムは、保有時間及び他の時間依存機能をトラッキングするために、一群のノード（コンピュータ）内にあるシステムハードウェアクロックから時刻値を基準時刻として単純に引き込み、システムの物理的セキュリティによって不正を防止するものと考えられる。
【発明の開示】
【課題を解決するための手段】
【００１９】
発明の概要
本発明は、WROMストレージ実施形態における削除や変更が禁止されたデータセットの中に、指定された保有日を入れることによって、従来技術の欠点を克服するものである。この保有日スキームは、工業所有権を有するアプリケーションプログラムインタフェース（ＡＰＩ）やプロトコルを何も使用せず、代わりに、一般的に使用されているオペレーティングシステムにおいて使用可能なファイル（あるいは、他のデータコンテナ、データセット、又は、ブロックに基づく論理装置番号）の属性内の本来の機能を使用する。代替実施形態において、この保有日／保有時間の算出は、収容前にファイルの最終更新時刻を問合せ、その値に保有期間を加算して保有日を算出することによって行われる。保有日を過ぎればファイルをWORMから解放することが可能になる。算出された保有日は、ファイル収容前にそのファイルの「最終アクセス時刻」プロパティ／属性フィールドに記憶され、あるいは、保有日の記憶に使用するためにそのファイルに永久的に関連付けられた他のメタデータフィールド（通常はオープンプロトコルに基づく）に記憶され、WORM状態におけるファイル管理の妨害にはならない。このフィールドは必須ではなく、WORMコンテキストにおいて稀にしか使用されないものであるから、このフィールドは保有日の記憶に使用してもよい。いったん保有日がこのフィールドに記憶されると、その保有日の変更は禁止される。保有日の延長（短縮はできない）が必要な場合、最終アクセス時刻フィールドを更新し、既存の最終アクセス時刻値に保有期間延長分を加算し、そのファイルの新たな保有日を導出する。保有日を過ぎると、システムは期限を満了したWORMファイル／データセットの削除を許可する。
【００２０】
本手順は、管理者、ユーザ、又は、ユーザインタフェースによって与えられた保有日が、ボリュームを管理するWORM規則の特定のセットによって認められるか否かを判定する。この目的を達成するためにに、ストレージシステムに適用可能な２以上のセットのWORMルールが存在する場合がある。（例えば、政府の規制に）厳格に準拠することが必要とされるストレージの場合、厳格なWORMボリューム、すなわち、規制WORMボリュームが使用される場合がある。このボリュームへの記憶は、厳格な最小デフォルト保有期間、すなわち、指定期間が無い場合、無期限とされる。適用された保有日を過ぎるまで、ファイルの変更や削除は一切認められない。逆に言えば、信頼のおける管理者モデルに従って定義された「エンタープライズ」ボリュームでは、保有日の自由な設定や、デフォルトとして何も日付を指定ないことが許される場合がある。同様に、エンタープライズボリュームは、ファイル／ボリュームの古いイメージからの復元や、適当であればボリュームの破壊が可能である場合がある。
【００２１】
一実施形態では、セキュア・コンプライアンス・クロックを使用して、保有期間に関連する時間を計測する。一実施形態において、このクロックは、反復ファイルサーバプロセスのような信頼のおける時間基準を使用して、その時間値を導出する。このクロックには不正防止措置が施されていて、クロックの時間値は実際の時間にほぼ等しいが、保有期間全体を確実に観測できるようにするために、実際の時間よりも僅かに長い場合がある。他の実施形態では、このクロックは、信頼のおける第三者機関のクロック（例えば、政府機関系クロック）や、更に別の安全なハードウェアベースのクロックである場合がある。
【００２２】
記憶される保有日／保有時間は、今日とほぼ同じ時期の日時基準（時代）を与えることにより、古いオープンプロトコルの場合の小さな範囲の特定の制限を克服する。そのような小さな範囲制限の下で使用可能な日付範囲は、時間値に関連する時代（日時基準）を再定義することにより、一般に拡大することができる。全く同じフォーマットがその時代内の日付にも使用される一方、拡大された日付範囲内に現れる値の日付はラップアラウンド・エンコードされる。
【００２３】
本発明の上記の利点及び他の利点は、添付の図面と合わせて下記の説明を参照すると分かりやすいであろう。図面において、同じ参照符号は、それが機能的に同一又は類似の要素であることを意味している。
例示的実施形態の詳細な説明
Ａ．ネットワーク及びファイルサーバ環境
更に別の背景として、図１は、本発明と共に使用するのに都合がよいファイルサーバ１１２を含むストレージシステム環境１００を示す概略図である。説明のために、ソースシステムは、１以上のストレージディスク１６０の記憶を管理するネットワークコンピュータ（図１には描かれていない１６１）であるものとする。
【００２４】
ファイルサーバ又は「ファイラ」１１２は、ディスク１６０のアレイからなる１以上のボリューム１１５及び１１６を管理する。ファイラ１１２は、ローカルエリアネットワークや、周知のインターネットのようなワイドエリアネットワークからなるネットワーク１１８に接続される。適当なネットワークアダプタ１３０によって、ネットワーク１１８を介した通信が可能になる。ファイラ１１２は一般に、システムバス１４５によって相互接続されたプロセッサ１２０、メモリ１２５、ネットワークアダプタ１３０、及び、ストレージアダプタ１４０を含む。ファイラ１１２はストレージオペレーティングシステム２００（図２）を更に含み、ストレージオペレーティングシステム２００は、情報をディレクトリやファイルの階層構造としてディスク上に論理編成するためのファイルシステムを実施する。
【００２５】
当業者には明らかなように、本明細書に記載する本発明の技術は、任意のタイプの特殊用途のコンピュータ（例えば、ファイルサービスを提供する装置）に適用することができ、また、ストレージシステムとして実施されるスタンドアロンコンピュータのような汎用コンピュータにも適用することができる。そのため、ファイラ１１２は、広い意味で、代わりにストレージシステムと呼んでもよい。また、本発明の教示は、限定はしないが、ネットワーク取り付けストレージ環境、ストレージエリアネットワーク、及び、クライアント／ホストコンピュータに直接取り付けられたディスクアセンブリのような、種々のストレージシステムアーキテクチャに適合するように構成することができる。従って、「ストレージシステム」という用語は、それらの構成も含むものとして広い意味で解釈しなければならない。
【００２６】
図示の実施形態において、メモリ１２５は、ソフトウェアプログラムコードを記憶するためにプロセッサ及びアダプタによってアドレス指定される幾つかの記憶場所を含む。メモリは、ランダムアクセスメモリ（ＲＡＭ）の形を有し、電源の入れ直しや、他のリブート動作によって一般にクリアされるメモリ（すなわち、「揮発性」メモリ）である。また、プロセッサ及びアダプタは、そのソフトウェアコードを実行し、データ構造を操作するように構成された処理要素、及び／又は、論理回路からなる。ストレージシステム２００は、その一部が通常、メモリに記憶され、処理要素によって実行され、特にファイラによって実施されるファイルサービスを支える記憶処理を実施することによって、ファイラの機能を構成する。当業者には明らかなように、本明細書に記載する本発明の技術に関連するプログラム命令の記憶及び実行は、他の処理手段、及び、種々のコンピュータ読取可能媒体のような他の記憶手段を使用して実施してもよい。
【００２７】
ネットワークアダプタ１３０は、ファイラ１１２をネットワーク１１８に接続するために必要な機械的、電気的、及び、信号的回路を含み、その回路は、ポイント・ツー・ポイントプロトコルや、ローカルエリアネットワークのような共有媒体を備える場合がある。クライアント（１７０，１７２）は、情報配送のクライアント／サーバモデルに従って、宛先ファイラ１１２と情報をやりとりする。すなわち、クライアントはファイラのサービスを要求する場合があり、ファイラは、クライアント１７０及び１７２によって要求されたサービスの結果をネットワーク１１８を介して、例えばＴＣＰ／ＩＰプロトコルフォーマット又は別のネットワークプロトコル（CIFS１７４，NFS１７６）フォーマットにカプセル化されたパケット１５５を交換することによって返送する場合がある。
【００２８】
ストレージアダプタ１４０は、ファイラ１１２上で動作するオペレーティングシステム２００（図２）と協働し、クライアントから要求された情報を取得する。この情報は、ストレージアダプタ１４０を介してファイラ１１２に取り付けられたディスク１６０上に記憶される場合もあれば、本明細書に記載するようなストレージシステムの他のノードに記憶されている場合もある。ストレージアダプタ１４０は、従来の高性能ファイバーチャネル・シリアルリンク・トポロジのようなＩ／Ｏ相互接続構成を介してそれらのディスクに接続された入出力（Ｉ／Ｏ）インタフェース回路を有する。情報はストレージアダプタによって取得され、後で説明するスナップショット手順の一部に従ってプロセッサ１２０によって処理され、その後、システムバス１４５を介してネットワークアダプタ１３０へ転送される。そして、後で詳細を説明するように、そこで情報はパケットとしてフォーマットされ、宛先サーバへ送信される。
【００２９】
ファイラは、ネットワークアダプタ１３０を介して１以上のクライアント１７０に更に相互接続される場合がある。クライアントはそれぞれ、ファイルサービスの要求をファイラ１１２に送信し、その要求に対する応答をＬＡＮ又は他のネットワーク（１１８）を介して受信する。クライアント１７０又は１７２とファイラ１１２との間において、データはそれぞれ、コモンインターネットファイルシステム（CIFS）プロトコル（１７４）又はNFSのような他の適当なプロトコル（１７６）のカプセル化として定義されるデータパケットを使用して転送される。
【００３０】
ファイラ実施形態の一例として、ファイラ１１２は、データのフォールトトレラントなバックアップ機能を備えた不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）１３５を有し、電源故障やその他の故障によるサービス中断を切り抜けるためのファイラトランザクションの完全性を確保する場合がある。ＮＶＲＡＭのサイズは、例えば、ファイルサーバ内におけるＮＶＲＡＭの実施形態や機能によって異なる場合がある。このＮＶＲＡＭは通常、時間にして或る特定のかなりの量のトランザクション（例えば、数秒相当）の記録を取るのに十分なだけのサイズを有する。各クライアント要求が完了した後、その要求の結果を要求元クライアントへ返送する前に、ＮＶＲＡＭはバッファキャッシュと並行して満たされる。
【００３１】
一実施形態では、種々のファイルサーバの機能及び動作を制御するための管理者コンソール１９０が、更に設けられる。コンソール１９０は、専用ポートを介してファイルサーバに接続されたクライアントや端末であってもよく、ネットワーク１１８を介してネットワーク接続されたものであってもよく、また、遠くの場所にあってもよい。この遠くの場所はファイルサーバから長距離離れていてもよい。一実施形態では、コンソールを通じて、後で説明する特定のコマンドが入力される。
【００３２】
図示の実施形態において、ディスク１６０は、例えばボリューム０（１１５）及びボリューム１（１１６）と名付けられた複数のボリュームに編成され、各ボリュームはそのボリュームに関連するファイルシステムを有する。ボリューム１１５及び１１６はそれぞれ、１以上のディスク１６０を有する。一実施形態において、物理ディスク１６０は、複数のＲＡＩＤグループとして構成される。一実施形態では、この編成は、好ましいＲＡＩＤ４構成に従って、幾つかのディスクがストライプ状データを記憶し、幾つかのディスクがそのデータの個別パリティを記憶するように構成される。ただし、他の構成（例えば、複数のストライプにわたる分散パリティを有するＲＡＩＤ５）も可能である。しかしながら、典型的な実施形態は、１ＲＡＩＤグループあたり３つのデータディスクと１つのパリティディスクを有し、１ボリュームあたり複数のＲＡＩＤグループを有する場合がある。後で説明するように、ボリューム０（１１５）は、読み出しや書き込みを自由に行うことが可能な普通のストレージボリュームであり、ボリューム１（１１６）は、特定のファイルを記憶装置にいったん収容した後はそれらを変更したり消去（又は削除）したりすることができない追記型(WORM)ボリュームである。
【００３３】
Ｂ．ストレージオペレーティングシステム
ディスク１６０全体にわたる全般的アクセスを可能にするために、ストレージオペレーティングシステム２００（図２）は、情報をディレクトリとファイルの階層構造としてディスク上に論理編成する。「ディスク上」の各ファイルは、データのような情報を記憶するように構成された１セットのデータブロックとして実施され、一方、ディレクトリは、他のファイルやディレクトリへの参照が記憶される特殊形式のファイルとして実施される。上に記載及び定義したように、本明細書に記載する例示的実施形態において、ストレージオペレーティングシステムは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから販売されているNetApp Data ONTAPストレージオペレーティングシステムであり、このストレージオペレーティングシステムは、Write Anywhere File Layout (WAFL)ファイルシステムを実施する。なお、当然ながら、任意の適当なファイルシステムを使用することが可能であるため、「WAFL」という用語を使用した場合でも、その用語は、本発明の教示を適用可能な任意のファイルシステムを意味するものとして広い意味で解釈しなければならない。
【００３４】
次に、例示的ファイラのそれぞれについて、好ましいストレージオペレーティングシステムの構成を簡単に説明する。ただし、当然ながら、本発明の原理は、種々の代替ストレージオペレーティングシステムを使用して実施することも可能である。図２に示すように、例示的ストレージオペレーティングシステム２００は、ネットワークドライバ（例えば、イーサネット（登録商標）ドライバ）のメディアアクセス層２０５を含む一連のソフトウェア層からなる。このオペレーティングシステムは、インターネットプロトコル（ＩＰ）層２１０のようなネットワークプロトコル層、並びに、それを支える搬送機構であるトランスポート・コントロール・プロトコル（ＴＣＰ）層２１５、及び、ユーザ・ダイアグラム・プロトコル（ＵＤＰ）層２２０を更に含む。ファイルシステムプロトコル層はマルチプロトコル・データアクセスを可能にするために、CIFSプロトコル２２５、ｉＳＣＳＩプロトコル２２４、NFSプロトコル２３０、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）プロトコル２３５、及び、他のプロトコル（図示せず）を含み、それらはオープンフォーマットであってもよいし、NFSバージョン４等のように工業所有権を有するフォーマットであってもよい。更に、ストレージオペレーティングシステム２００は、ＲＡＩＤプロトコルのようなディスクストレージプロトコルを実施するディスクストレージ層２４０、及び、スモール・コンピュータ・システム・インタフェース（ＳＣＳＩ）のようなディスク制御プロトコルを実施するディスクドライバ層２４５を有する。
【００３５】
ディスクソフトウェア層をネットワークプロトコル層やファイルシステム層に橋渡しするのは、ストレージオペレーティングシステム２００のファイルシステム層２５０である。一般に、ファイルシステム層２５０は、例えば４キロバイト（ＫＢ）データブロックを使用したブロック単位のディスク上フォーマット表現を有するファイルシステムを実施し、ファイルシステムはinodeその他のデータ構造を使用してファイルを表現する。なお、図示の実施形態ではファイルが実施されているが、「ファイル（単数）」又は「ファイル（複数）」という用語は、ＳＣＳＩのようなブロックレベルのプロトコルに使用されるものを含めて、任意のタイプのデータ編成又は「データコンテナ」を含むものとして広い意味で解釈しなければならない。従って、本明細書では、「データコンテナ」という用語も、同じ意味で使用される場合がある。
【００３６】
トランザクション要求に応答して、要求データが「コア内」に、すなわち、ファイラのメモリ２２５内にない場合、ファイルシステムは、要求データをボリュームからロードする（読み出す）ための処理を発生する。情報がメモリ上にない場合、ファイルシステム層２５０は、inode番号を使用してinodeファイル内を検索し、適当なエントリにアクセスし、ボリュームブロック番号を取得する。次にファイルシステム層２５０は、そのボリュームブロック番号をディスクストレージ（ＲＡＩＤ）層２４０に渡し、ディスクストレージ層２４０は、そのボリュームブロック番号をディスクブロック番号にマッピングし、後者をディスクドライバ層２４５の適当なドライバ（例えば、ファイバーチャネル・ディスク相互接続上で実施されるＳＣＳＩのカプセル化）に送信する。ディスクドライバは、ボリュームからそのディスクブロック番号をアクセスし、要求データをファイラ１１２（図１を参照）によって処理するためにメモリ１２５にロードする。要求が完了すると、ファイラは、対応するネットワーク接続１７２を介してクライアント１７０に返答を返す。この返答は、例えば、CIFS仕様に規定される従来の受領確認パケットである。
【００３７】
なお、ファイラで受信されたクライアントの要求に対し、データストレージアクセスを実施しなければならない上記のストレージオペレーティングシステムの種々の層を貫通するソフトウェア「パス」２７０は、代わりにハードウェアとして実施してもよいし、ハードウェアとソフトウェアの組み合わせとして実施してもよい。つまり、本発明の代替実施形態では、ストレージアクセス要求データパス２７０は、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）の中に実装される論理回路として実施される場合がある。この種のハードウェア実施形態によれば、クライアント１７０によって発行されたファイルシステム要求パケットに応答してファイラ１１２が提供するファイルサービスの性能を向上させることができる。
【００３８】
図面の詳細な説明を続ける前に、バックアップについて簡単に説明した方がよいであろう。信頼性を向上させ、ファイラ、関連ディスク、又は、ストレージ・インフラストラクチャの何らかの部分の故障時における災害復旧を容易にするために、基礎データ、及び／又は、データを編成するファイルシステムの一部又は全部を「ミラーリング」、すなわち複製することが一般的である。一例として、ミラーは、メインの記憶場所やそのインフラストラクチャに物理的損害を与える真の災害（例えば、洪水、停電、戦争活動など）の際に比較的高い復元可能性を持つ遠くの場所に作成され、そこに記憶される。ミラーは最新の変更をそのファイルシステムに取り込むために一定時間間隔で更新され、その時間間隔は通常、管理者によって設定される。
【００３９】
更新の１つの一般的形は、「スナップショット」プロセスを使用するものである。スナップショットプロセスは、ストレージサイトにある動作中のファイルシステム（inodeとブロックから構成される）をキャプチャし、そのスナップショット全体をネットワーク（例えば、周知のインターネット）を介して離れた所にあるストレージサイトへ転送する。一般に、スナップショットは、ある時点におけるファイルシステムのイメージ（通常は、読み出し専用）であり、アクティブファイルシステムと同じ一次記憶装置に記憶され、アクティブファイルシステムのユーザによってアクセスされる。「アクティブファイルシステム」とは、現在の入出力処理の対象となっているファイルシステムを言う。１セットのディスクのような一次記憶装置はアクティブファイルシステムを記憶する一方、テープドライブのような二次記憶装置はそのアクティブファイルシステムのバックアップに使用される場合がある。スナップショットを取った後（すなわち、イメージをキャプチャした後）、起こり得る災害に備えて、そのスナップショットを適所に残したまま、アクティブファイルシステムは再構築される。スナップショットをとるたびに、古いアクティブファイルシステムが新たなスナップショットになり、新たなアクティブファイルシステムは、新たな変化の記録を実行する。種々の時間基準及び他の基準に従って、所定数のスナップショットが保持される場合がある。
【００４０】
「スナップショット」はネットワーク・アプライアンス・インコーポレイテッドの商標である。本発明の目的では、スナップショットは、永久的なコンシステンシー・ポイント（ＣＰ）イメージの指定に使用される。永久的なコンシステンシー・ポイント・イメージ（ＰＣＰＩ）は、ストレージシステムの或る時点での表現であり、具体的には、ストレージデバイス（例えば、ディスク）や他の永久的メモリに記憶されたアクティブファイルシステムの或る時点での表現であり、別の時点で取得された他のＰＣＰＩから自分を区別するために、一意（重複のない）の名前、又は、識別子を有する。ＰＣＰＩは、そのイメージをキャプチャした或る特定時点におけるアクティブファイルシステムに関する他の情報（メタデータ）を更に含む場合がある。本明細書全体を通して「ＰＣＰＩ」という用語と「スナップショット」という用語は、ネットワーク・アプライアンスの商標権を傷付けることなく、同じ意味で使用されるものとする。
【００４１】
ＰＣＰＩ／スナップショットプロセスの詳細は、Blake Lewis他による「INSTANT SNAPSHOT」と題する米国特許出願第０９／９３２，５７８号に記載されており、この文献は参照により本明細書の中で完全に説明したものとして援用される。また、WAFLファイルシステムの本来のスナップショット機能については、ネットワーク・アプライアンスにより発行されたＴＲ３００２、David Hitz他による「File System Design for an NFS File Server Appliance」、及び、「METHOD FOR MAINTAINING CONSISTENT STATES OF A FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM」と題するDavid Hitz他による本願と同じ譲受人の米国特許第５，８１９，２９２号に記載されており、これらの文献も参照により本明細書に援用される。
【００４２】
図２を再度参照すると、ファイルシステム層２５０の上には、管理者のためのユーザインタフェース２８５がある。ユーザインタフェース２８５は、上で述べた種々のプロトコル（CIFS、NFSなど）を利用してアクセスすることができる。
【００４３】
更に、ファイルシステム層２５０の上には、特殊な非同期ボリューム及びサブボリューム（又は「qtree」）スナップショットミラーリング（又は複製）アプリケーション２９０がある。このアプリケーションは、ソースにおけるスナップショット間の変化に基づいて、遠くの場所にある宛先ストレージボリュームにミラーを生成する働きをする。ＴＣＰ／ＩＰ層２１５及び２１０への直接接続２９２、及び、ファイルシステムスナップショットメカニズム（２８０）への直接接続２９４に示すように、スナップショットミラーリングアプリケーション２９０は、ストレージアクセス要求パス２７０の外側で動作する。このアプリケーションによれば、各サブボリュームにおける変化の「非同期」ミラーリングが可能になる。つまり、ミラーリングは、ネットワーク接続によってリンクされた遠くの場所にある宛先記憶装置に増分として書き込まれる（ソースサブボリュームに発生する変化に対してリアルタイムではなく）。ボリュームレベル又はサブボリュームレベルの非同期ミラーリングについては、Michael L. Federwisch他による「SYSTEM AND METHOD FOR DETERMINING CHANGES IN TWO SNAPSHOTS AND FOR TRANSMITTING CHANGES TO A DESTINATION SNAPSHOT」と題する米国特許出願第１０／１００，９６７号に記載されており、この文献は参照により本明細書に援用される。
【００４４】
同様に、ＲＡＩＤ層で動作する同期ボリュームスナップショットミラーリングアプリケーション２９８も設けられている。このアプリケーションは、管理者によって開始されたミラーコマンドに応答して、ミラー記憶装置への同期（リアルタイム）ミラーリングを行う。このミラーリングは、ミラーコマンドが実行された時点で存在するソースを複製したものである、或る時点におけるソースのイメージを作成するものである。スナップショットのボリュームベースの遠隔ミラーリングの詳細は、Steven Kleiman他による「FILE SYSTEM IMAGE TRANSFER」と題する本願と同じ譲受人の米国特許出願第０９／１２７，４９７号、及び、Steven Kleiman他による「FILE SYSTEM IMAGE TRANSFER BETWEEN DISSIMILAR FILE SYSTEMS」と題する米国特許出願第０９／４２６，４０９号に記載されおり、これらの文献は両方とも参照により本明細書に援用される。
【００４５】
とりわけ、ストレージオペレーティングシステムはWORMユーティリティ２９９を含み、WORMユーティリティ２９９は通常、ファイルシステム層に存在する。後で詳しく説明するように、このWORMユーティリティは、従来のファイルシステムボリューム２７６とは異なる特殊なWORMボリューム２７５をファイルシステム上に作成する働きをする。これらのボリュームは、分化WORMボリューム２７７及び非WORM RAIDボリューム２７８としてそれぞれＲＡＩＤ層に運ばれる。また、このユーティリティは、書き替え不能且つ消去／削除も不可能なWORMボリュームの中に、WROMファイル又は同様の「WORMデータコンテナ」（例えば、クロックなど）を作成する機能を更に有する。WORMファイルがディレクトリパス／ツリー上にある限り、ユーティリティ２９９の働きによって、そのWORMファイル／データコンテナの各ディレクトリパス（又は、他の識別論理編成）はいずれも、削除が禁止される。
【００４６】
図示の実施形態によれば、ストレージオペレーティングシステム２００はセキュア・コンプライアンス・クロック２７９を更に含む。図示の実施形態において、セキュア・コンプライアンス・クロック２７９は、後で説明するようなWORMファイルに関する保有期間の設定、トラッキング、及び、強制に関係して使用されるソフトウェア・クロックである。あるいは、セキュア・コンプライアンス・クロックは、ハードウェア・クロックとして実施することもでき、また、信頼のおける第三者機関（例えば、政府系）のクロックから供給されるものであってもよい。後で詳しく説明するように、コンプライアンス・クロックの実施形態は全て、不正を防止するメカニズム、及び、出力時刻値の信頼性を確保するメカニズムを備える。
【００４７】
図示の実施形態に関する更に詳細な説明に移る前に、次のような定義をしておく。上に記載した「データセット」又は「データコンテナ」という用語は、ファイル、ＬＵＮ（論理ユニット番号）、又は、任意の個別に又は個々にアドレス指定可能なデータ構造を意味するものとする。「ボリューム」という用語は、データコンテナの論理グループを意味するものとする。「ディレクトリ」という用語は、ツリー又は他の論理的索引付け構造をたどることにより所与のデータコンテナのアクセスを容易にする組織的構造を意味するものとする。同様に、「パスウェイ」又は「パス」という用語は、データコンテナをアドレス指定する際にディレクトリ構造の中を通ってストレージオペレーティングシステムがたどる経路を意味するものとする。更に、当然ながら、本発明の教示は、種々のストレージ環境に適用することができ、また、限定はしないが、ファイルデータ、データベースデータ、ブロックレベルデータ等を含む種々のデータタイプに適用することが可能である。
【００４８】
Ｃ．WORMボリュームの作成
図３のフロー図を参照すると、この図は、WORMボリュームを作成するための汎用手順３００と、その作成結果を記載している。この手順は通常、管理者が管理用コンソール及びインタフェースを使用して適当なボリューム作成コマンドを入力することによって実施される。ファイルシステムは、WORMボリュームを指定する従来の（事前WORM）ボリューム作成コマンドに関連する新たなセマンティックを解釈するように変更が加えられている。ステップ３０２において、管理者はまず、ディスク数のようなサイズ等に関する幾つかの一般的パラメータを有するWORMボリュームを作成する。一実施形態において、これはボリューム名「volume」及び「-L ディスク数」を含む次のようなコマンドをタイプすることによって行われる。
【００４９】
vol create <volume> -L <ディスク数>
次に、ステップ３０４において、ボリュームに、ファイルサーバ上で必要とされる名前（ボリューム）を割り当てる。その結果、ボリュームは/vol/volumeのように識別される。ボリュームに関連するディスクは、永久記憶装置上のディスクのＲＡＩＤラベルに基づくWORM属性を使用してマークされ、その結果、それらのディスクはWORMボリュームとして識別される。そのためには、従来のＲＡＩＤ層構造に変更を加え、追加ラベルが考慮されるようにしければならない場合もある。WORMは、ファイルシステム層において一次的なものでなければならないが、このタグは、割り当てられたディスクをWORM記憶装置としても識別する働きをする。ここで、WORM指定は、WORMディスクの永久的ラベルとして不揮発性メモリに記憶される。このラベルは、ストレージオペレーティングシステムがディスクをボリュームにマッピングするためのディスクに関する識別情報を含み、ディスク上の標準的位置（例えば、始め）に記憶される。このようにして、WORMファイルを含むディスク自体に対するWORM指定が維持される。また、このWORM指定は、ＮＶＲＡＭ及び他の永久的メモリ構造やバッテリバックアップメモリ構造に記憶することもでき、それによって、後で説明するような不注意による、又は故意のボリューム破壊を防止することができる。なお、ボリューム名はWORMボリュームの作成プロセスの一部において割り当てられるため、ステップ３０４はユーザ対話を必要としない。これは、システムの内部で処理してもよい。
【００５０】
次にステップ３０６において、そのボリュームをエキスポート（NFSクライアントの場合）するか、シェア（CIFSクライアントの場合）するか、又は、その他の方法により、外部クライアントから利用できるようにする。エキスポート／シェアステップは、クライアントに対する適当な使用許可を与える従来のプロセスである。NFSクライアントの例の場合、適当なコマンドの簡略化された文法は次のようなものである。
【００５１】
exports [-o オプション] /vol/volname
同様にCIFSクライアントの例の場合、文法は次のようなものである。
【００５２】
cifs shares -add <共有名> /vol/volume
エキスポート及びシェアは適当なアクセス制御を含み、クライアントに対し、特定ユーザだけがそのボリュームにアクセスできるような権限を与える。更に、パーミッションも入力される。ボリューム（WORMは別として）機能に対して成すことが可能な行動は、これらによってほぼ制御される。例えば、リードオンリーボリュームを作成することは可能であるが、その結果、そのボリュームに対する以後の書き込みは制限される場合がある。ユーザがリードオンリー状態を破棄することが出来るマイクロソフトオフィス環境とは対照的に、WORMデータの完全性を維持したままWORM状態をユーザ、管理者、又は、その他の者が破棄することは、どのような環境であっても出来ない。
【００５３】
最後に、ステップ３０８において、次にそのWORMボリュームをオンラインにし、クライアントからアクセスできるようにする。WORM機能が有効化されているため、WORM機能によって課せられる制限が存在する。一実施形態において、そうした制限には次のようなものがある。
【００５４】
１．WORMはボリューム破壊コマンドを無効にする。すなわち、一実施形態において、WORMボリュームに変化を与えないWORMボリューム破壊は許可される。ただし、以下で説明するように保有日が存在する場合、ボリューム上に存在する保有期間を全て超過した後は、そのボリュームを破壊することができるものと考えられる。
【００５５】
２．WORMは、スナップショットからのWORMボリュームの「従来」の復元、又はその一部の復元を無効にする。すなわち、或る時点よりも後に収容されたファイルやWORMファイルに対する比較的最近の変更を消し去る比較的古い時点のイメージからの不適切な復元を禁止する。
【００５６】
なお、本明細書に記載するWORM原理は、少なくとも２つのシナリオに適用することができる。すなわち、管理者が信用できない比較的厳格なシナリオ（政府規制シナリオ）と、信頼のおける管理者、又は、「エンタープライズ」モデルに基づいて確立されたシナリオである。エンタープライズモデルのケースでは、比較的厳格なモデルに従って禁止された特定の動作を実施するための柔軟性が存在する場合、特定のエンタープライズWORMボリュームが提供される場合がある（比較的厳格に規制されるボリュームにおいて）。例えば、ファイル・エンタープライズ・ボリュームは、ＰＣＰＩからの復元、ボリュームの破壊、及び、最小保有期間の設定における柔軟性の影響を受ける場合がある
３．パーミッションを最初の非リードオンリー状態から「リードオンリー」状態に設定する場合（NFSの場合、属性セットコマンド「SETATTR」）（CIFSの場合、ファイル情報設定コマンド「TRANS2_SET_FILE_INFORMATION」）、ボリューム内のファイル（又はデータコンテナ）は全て、WORMファイルでなければならない。すなわち、ファイルシステム層は、各プロトコルから全てのパーミッションを抜き出し、当該ファイルに割り当てられたWORM状態を非リードオンリー状態からリードオンリーに変化させる。
【００５７】
４．日付スタンプやリードオンリー状態の変更の試みを含む、ファイルの状態を変化させるボリューム内のWORMファイルの変更（例えば、書き込み、リネーム、削除（以下の保有日の影響を受ける）、ファイル属性の変更など）はいずれも、制限を受ける。ファイルのアクセス／変更が要求された場合、ファイルシステムはまず、そのボリュームのWORM状態をチェックし、目的ファイルの個々のWORM状態（以下に記載する）をチェックしてから、変更を許可する。ファイルがWORMであった場合、変更を制限し、ファイルサーバは、その変更要求を拒否する「リードオンリー」や「アクセス拒否」といった適当なファイルエラーメッセージを返す。保有日を有するWORMファイルの作成及び扱いに関連して後で説明するように、保有日の設定には、最終アクセス時刻プロパティフィールドが使用される。このフィールドは収容前に設定される。この設定値は、特定ファイルの保有期間をトラッキングするのに使用される。期間が過ぎると、期限を満了した特定ファイルの削除のような他のプロパティのロックは解除され、この目的のために限られたアクセスが許可される。
【００５８】
具体的には、例示的なCIFS環境の場合、従来のファイル属性には次のようなものがある。すなわち、隠しファイルフラグ、リードオンリーフラグ、アーカイブフラグ（バックアップ実施前且つファイル書き込み後に設定される）、作成タイムスタンプ、変更タイムスタンプ、アクセスタイムスタンプ、アクセスコントロールリスト（ＡＣＬ）、及び、ＮＴストリームである。これらの変更によってファイルに対する不適切な変化が生じる可能性がある場合、これらの属性の変更は通常、禁止される。
【００５９】
NFSの例の場合、ロックされる従来のファイル属性には、アクセスコントロールリスト、並びに、ファイル所有者やグループなどに関連する他のパーミッションがある。NFSバージョン４は、上に記載したCIFSのものと同様の、ロックしなければならない多数の属性を有する。
【００６０】
５．一実施形態において、WORMボリュームにおけるディレクトリのリネームは許可されない。これによって、ディレクトリが変更され、WORMファイルが誤った場所に置かれることが防止される。代替実施形態では、ディレクトリのリネームによってWORMファイルが誤った場所に置かれることが絶対にない場合に限り、ディレクトリのリネームが許可される場合がある。ただし、WORMボリューム内におけるディレクトリのリネームを禁止するこの基本ルールによれば、ディレクトリリネームコマンドが発行されたとき常にディレクトリツリー内のWORMファイルの移動をチェックする必要はなくなるので、多くの場合、オーバヘッドは軽減され、性能は向上する。
【００６１】
６．WORMファイルが存在する場合、ディレクトリの削除は許可されない。図４に概略的に示すように、WORMボリュームのディレクトリツリー４００にWORMファイル４０２を収容すると、WORMファイル４０２は不変になり、削除や変更を受けなくなる。従って、従来のファイルシステムセマンティックによれば、ディレクトリ４０４及びルートを（並びに、パス４１０上のサブディレクトリは全て）削除することはできない。言い換えれば、事実上全ファイルシステムにおいて一般に認められるルールによれば、少なくとも１つ未消去のファイルが残っていれば、その上に重なるディレクトリを削除することはできない。そのようなファイルシステムがこのルールを明示的に必要としない場合、そのファイルシステムを明示的に変更し、WORMファイルパスの削除を制限しなければならない。この実施形態によれば、他の非WORMディレクトリ４１２及び４１４、並びにそれらに対応するファイル４１６及び４１８は、普通に削除することができる。なお、以下で説明するように、所与のツリー内の全てのファイルの保有期間が満了すると、それらのファイルの削除は許可される。あるツリー内の全てのWORMファイルを削除すると、それによってディレクトリ全体の削除が許可される。あるいは、オペレーティングシステムは、あるディレクトリ内の全ての保有期間の満了を認識し、それによってそのディレクトリ全体の削除の禁止を解除するように構成される場合がある。
【００６２】
Ｄ．WORMファイルの生成
上記のように管理者によってWORMファイルが作成されると、そのWORMファイルは許可されたクライアントによって使用することが可能になる。WORMボリュームは、上記のような一般的制限を受ける非WORMのファイルやディレクトリに対する従来のボリューム操作（例えば、ディレクトリやファイルの作成、ファイルへの書き込み、及び、ディレクトリやファイルの削除）を全て許可する。更に、WORMボリュームは、WORMファイルの一回限りの書き込み、及び、WORMファイルの読み出しや複製も許可する。WORMファイルはWORMボリューム全体中の特殊なファイル(又は、データセット／データコンテナ）である。換言すれば、ボリューム内の全ファイルがWORMファイルである必要はない。WORMファイルは、クライアントと、不変に維持しなければならない情報を記憶又は保管するために必要とされるファイルサーバアプリケーションとによって作成される。そのようなアプリケーションの１つとして、所望の電子メールレコードを継続的又は定期的に収集し、それらのレコードを１つのアーカイブファイルとして記憶する電子メールアーカイブプログラムがある。
【００６３】
周知のWindows(登録商標）オペレーティングシステム（ワシントン州レドモンドにあるマイクロソフト・コーポレーションから販売されている）で動作するクライアントの一例における、ファイルを作成し、それをWORMに収容する手順５００を図５に示す。まず、ステップ５０２において、クライアントは、WORMファイルを記憶すべきWORMボリュームに、ネットワークシェアを追加する。例えば、このボリュームは「ドライブW」という名前である可能性がある。そして、このドライブは、クライアントに見せる共有ドライブのリスト上にあると思われる。ステップ５０４において、次に、標準ウィンドウズコマンドを使用して、そのファイルをWORMドライブWに保存する。WORMファイルが適当なWORMボリュームに保存又は複製されると、ユーザは、関連保有期間を入力することが出来る（ステップ５０５）。保有期間を入力し、操作するプロセスについては、後で詳しく説明する。一般に、ファイルの適当な属性への保有日の記入は、ファイルの記憶を扱うクライアントアプリケーションにより、標準ウィンドウズアプリケーションプログラムインタフェース（ＡＰＩ）を使用してプログラム的に実施されるか、又は、ファイルに属性を設定する機能を有する非標準ウィンドウズコマンドラインユーティリティを使用して実施される。最後に、クライアントは「ファイルプロパティ」ダイアログを呼び出し、ドライブW上のそのWORMファイルにリードオンリー属性を設定する。ファイルサーバのファイルシステムは、非リードオンリー状態からリードオンリー状態へのそのファイルの状態の変化を認識し、そのファイルをWORMファイルとして指定し、属性の修正や変更等に関する上記の制限を全て課す。具体的には、そのファイルのリードオンリー状態を変更しようとするクライアントの以後の試みは全て拒否され、Permission deniedメッセージがファイルサーバからクライアントへ返される。この態様において、最後のステップ５０６は、WORM状態へのファイルの「収容」と呼ばれる。どのようなプロトコルの場合であっても、ファイルにWORM特性を与えるためには、この収容ステップが必要とされる。
【００６４】
なお、例示的実施形態において、収容ステップは、WORMボリュームへのリードオンリーファイルの記憶に単純に依存するのではなく、非リードオンリー状態からリードオンリー状態への「WORMボリューム内」のファイルの変化に依存する。非リードオンリー状態からリードオンリー状態へファイルを変化させることがない複製ユーティリティや他のファイル作成アプリケーションは、ファイルをWORMとして解釈しない場合がある。
【００６５】
一実施形態による収容プロセスは、ファイル属性を非リードオンリー状態からリードオンリー状態へ変化させる必要があるが、他の従来の属性の他の変化（例えば、WORMファイルタイプへのファイルのリネーム）や、他の特殊属性又はメタデータの設定を、収容のトリガとして使用する場合がある。あるいは、記憶装置のWORM指定部分又は構造へのデータ又はファイルの記憶を収容のトリガとしてもよい。
【００６６】
図６の手順６００は、NFSによってファイルサーバに接続された周知のUNIXオペレーティングシステムで動作するクライアントの例における、WORMファイル作成ステップ及び収容ステップの概要を示している。まず、ステップ６０２において、従来のボリュームマウント手順を使用して、WORMボリュームをマウントする。例えば、"mount filer:/vol/volname /worm"というコマンドが使用される。例えば一例としてリードオンリーでないファイルfile.txtをWORM記憶したい場合、次にそのファイルを複製する（ステップ６０４）。典型的なコマンドラインシェルコマンドは次のようなものであろう。
【００６７】
cp file.txt /worm
このコマンドにより、そのファイルは指定されたWORMファイルとしてそのボリュームに複製される。WORMファイルが適当なWORMボリューム上に保存又は複製された後、ユーザは、保有期間を入力することができる（ステップ６０５）。保有期間を入力し、扱うためのプロセスについては、後で詳しく説明する。WORMファイルが複製され、何らかの保有期間が設定された後、ステップ６０６によれば、それをWORMに収容しなければならない。なお、UNIXシステム環境では、適当なオプションを有する「touch」コマンドを使用してファイル属性を設定することにより、保有期間を対話的に設定することが出来る。この属性は、Windowsその他のプラットフォーム上で動作する種々の市販の「touch」ユーティリティを使用して設定してもよい。最終アクセス時刻設定の例におけるコマンドの例は次のようなものである。
【００６８】
touch -a -t <日付> <ファイル>
次に、所有者、グループ、及び、ユーザの全てから書き込みパーミッションを取り除き、非リードオンリー状態からリードオンリー状態、すなわちWORMへファイルを変更することによって、収容を達成する。パーミッションを取り除くためのシェルコマンドの例は次のようなものである。
【００６９】
chmod -w /worm/file.txt
従来のDOSシェルの場合、収容は単に次のように表わされる。
【００７０】
ATTRIB +R <ファイル名>
上記の各コマンドライン表現は、具体的には、クライアント側の対話セッションで使用される。換言すれば、クライアントユーザは、コマンドを物理的に入力し、ファイルサーバからの適当な応答を待つ。これらの作成手順や収容手順は、アプリケーションプログラム中で内部的に実行してもよい。周知の各オペレーティングシステム（Windows（登録商標）やUnixなど）は、アプリケーションベースの収容機能や属性変更機能をサポートしている。WORMを実施するためには、次のファンクションコールをアプリケーションプログラムに組み込むことが望ましい。なお、WORM機能を完全に実施するためには、WORMの存在を認識するために、アプリケーションに対して他にも変更（アプリケーションプログラムのグラフィカルユーザインタフェースに対する変更など）を施さなければならない場合がある。また、WORMボリュームは、WORMボリュームの特殊なプロパティや変更の加えられたセマンティックを認識し、それらを使用することが可能なアプリケーションでしか使用されないものと考えられる。例えば、WORMに収容する（例えば、「リードオンリー」に設定する）ためのWindows系Ｃ＋＋（Ｗｉｎ３２）アプリケーション・プログラム・インタフェース・ファンクションコールは次のようなものである。
【００７１】
SetFileAttributes(<ファイル>, FILE_ATTRIBUTE_READONLY)
同様に、UNIX系システムの場合、アプリケーション・ファンクションコールは次のようなものになるであろう。
【００７２】
fchmod (<ファイル>, 0444)
上の記載から明らかなように、この実施形態によるWORMボリュームの作成、並びに、WORMファイル（データコンテナ）の記憶は、オープンプロトコル(CIFS, NFSなど)に対する変更が最小限で済み、WORM機能を使用する特定アプリケーションの変更も最小限で済む。その理由は、新たな機能の大半がファイルシステム層に収容され、ファイルシステム層が、ボリューム作成コマンドに対する簡単な変更や、ファイルシステム層内でWORMを実施するための既存のファイル属性の変化（すなわち、非リードオンリーからリードオンリーへの変化）を認識するように構成されるからである。また、ファイルシステム層の大部分は、種々のオープンプロトコルに依存せず、情報を均一なWORM特性でストレージ層へ渡すため、ストレージオペレーティングシステム内のストレージ層や他の層に施さなければならない変更も、最小限で済む。
【００７３】
代替実施形態によれば、自動収容機能をオープンプロトコルに組み込むことも可能であるものと考えられる。CIFSは処理状態を把握する機能を本来持っているので、作成されたWORMファイルがクローズされたときに、そのファイルをWORMに収容する手順を実施することができる。つまり、CIFSプロトコルは、WORM作成ダイアログを認識し、ファイルがクローズされたときに、収容（例えば、非リードオンリー属性からリードオンリー属性への変化）に移る。これは、NFSのような処理状態を把握する機能を有するプロトコルにおいて興味深い取り組みである。ただし、NFSバージョン４は、処理状態を把握する命令を多数備えているため、CIFSのような自動収容のための出来合いのプラットフォームとしても機能する。ファイルクローズ時の自動収容を提供するプロトコルは他にもあるであろう。
【００７４】
更に別の代替実施形態では、WORMディレクトリを実現するために、オープンプロトコルに更に変更を加える場合があると考えられる。一実施形態では、WORMファイルだけに、WORMディレクトリに対するアクセス権を与える場合がある。その目的を達成するために、WORM収容された全ファイルをユーザが閲覧できるようにする「WORM」ファイル拡張が施される。一回のトランザクションでディレクトリ全体を自動的に収容する利点は、クラッシュその他の中断を引き起こす可能性があるファイルの部分的収容による、残りのファイルが収容されるまでに生じる問題を制限できることにある。比較的新しいファイルが最後に収容されると、部分的収容によって矛盾が生じることがある。更に別の代替実施形態では、ファイルの任意の部分を一回だけ書き込むことができる。そのため、自動収容メカニズムを使用する場合があり、このメカニズムは、既存のファイルに対するデータの追記や、ファイルにおける何らかの「穴」の充填を許可することが望ましく、且つ、ファイル内の既存の書き込みデータに対する変更の試みは許可しないことが望ましい。そのようないわゆる「増分WORM収容」は、WORMログファイルのような用途に適している。WORMログファイルにおけるファイル内の既存のレコードはWORMであり、新たなレコードはファイルの終わりの未書き込み空間に追記される。
【００７５】
管理者は、簡易ネットワーク管理プロトコル（ＳＮＭＰ）により、ボリューム作成、ボリューム破壊（もし許可されていれば）、WORMファイル書き込み等のようなWORMボリューム活動をログに記録することが可能であるものと考えられる。ファイラは、ログ、すなわち、管理ファイルを有する場合があり、ＳＮＭＰは、そのような活動を検出するためのトラップとして使用される場合がある。このようにすると、全てのWORM活動のログを管理することができ、例えば、法律の施行や内部セキュリティ目的のためのデータ管理、並びに、データアクセスの管理及び監査報告が更に容易になる。
【００７６】
Ｅ．ミラーリング及び複製の検討
上で簡単に述べたように、幾つかの特定のスナップショット復元機能は、無効化する必要はない。背景として、図７は、WORMボリュームデータ７０２が作成され、ソースWORMボリューム７０４に記憶されるときに、それをリアルタイムに宛先ボリューム７０６へ転送する同期ミラーリング手順７００の詳細を示している。この転送は、ソースから宛先への高速リアルタイム転送が可能な転送プロトコル（ファイバチャネル、iSCSIなど）を使用して、高速リンク７１０を介して行われる。要するに、ミラーとは、ソースと同じ時点で満たされ悦るのディスクアレイである。つまり、ソースボリュームに入れたものは全て、ミラー宛先ボリュームにも入れられる。ストレージ(RAID)層において大量のミラー機能を処理するために、ソース上の上位ファイルシステムから少しだけ介入が必要となる。
【００７７】
宛先ボリュームを使用する前に、まず、宛先ボリュームを宛先ストレージシステム上に作成する。一実施形態では、ミラーボリューム、又は他の構造が、ソースと同じファイラ又はファイルサーバのRAIDレベルを使用して自動的に生成される。その場合、全てのWORM機能が、ソースから宛先へ転送される。宛先ボリュームの作成は通常、適当なボリューム作成コマンドを使用して管理者によって行われる。通常、宛先ボリュームの作成には、WORM機能を有するファイルシステムを備えたバックアップ記憶装置が必要とされ、宛先ボリュームはWORMボリュームとしてそのバックアップ記憶装置上に置かれる。WORMミラーボリュームを使用することによって記憶データの完全性は更に保護され、WORMミラーボリュームはセキュアなバックアップ記憶装置の一般的要件に準拠する。非WORMの宛先ボリュームを作成することも可能であり、また、場合によってはそれを作成することが望ましい場合がある。ただし、そのようなボリュームは、セキュアなバックアップ記憶装置に関するルールに違反する。
【００７８】
宛先ボリュームがWORMボリュームであることから、ミラーリングプロセスにおける何らかの中断は、取り返しがつかない場合がある。中断が起きた場合、システムは、全記憶ブロックの転送、すなわち、新たに作成された宛先ボリュームへのレベル０転送のような、ミラーの再初期化が必要になる場合がある。
【００７９】
本明細書に記載された他のミラーリングプロセスと同様に、ソースのWORM特性は、災害時における宛先からのソースの復元（例えば、復元プロセス）に制限を課す場合がある。ソースWORMボリュームにあるWORMファイルは、当然ながら書き替え不可であるから、ソースボリュームを修復する好ましい手順は、ソースボリュームをミラーリングされた宛先ボリュームで置き換えることである。宛先を利用したソースの部分的復元は禁止される。ただし、一般にこれは、同期ミラーリングアプローチにおける小さな欠点に過ぎない。なぜなら、宛先は当然ながらソースの最新バージョンを記憶していて、必要であればそれ全体をソースと容易に入れ替えることができるからである。
【００８０】
図８は、非同期ミラーリング手順８００を示す略図である。このアプローチの詳細は、Michael L. Federwisch他による「SYSTEM AND METHOD FOR DETERMINING CHANGES IN TWO SNAPSHOTS AND FOR TRANSMITTING CHANGES TO A DESTINATION SNAPSHOT」と題する上記の米国特許出願第１０／１００，９６７号に記載されている。下記の説明に関しては、この文献を参照しなければならない。
【００８１】
ソースボリューム８０２のファイルシステムは、ソースボリュームデータ構造、又は、時間的に隔てられた種々の時点における特定のサブボリューム（例えば、qtree）のデータ構造のイメージ、すなわち、「スナップショット」（図２の２８０）を生成するように構成される。なお、そのようなサブボリュームの１つは、上で述べたWORM（例えば、「WORM」拡張」）ディレクトリ構造である場合がある。上で援用した参考文献によれば、スナップショットミラーリングアプリケーションは、スナップショットをスキャンし、異なる時点において取得されたスナップショット間の顕著な違いに基づいて、ファイル間の変化を検出する。宛先８０４に適当なWORMボリュームが作成された後、それらの変化は、フォーマット（整形）されたデータストリーム８０６として、従来の（通常は低速の）ネットワーク接続８１０を介して送信される。従来のネットワーク接続８１０には、例えば周知のインターネットがある。接続が低速であることから、それらの変化は一般に、リアルタイムに発生する変化ではなく、周期的時間間隔で「非同期的」に、すなわち、遅延書き込み態様で宛先に書き込まれる。
【００８２】
非同期転送におけるソースWORMボリューム８０２から宛先WORMボリュームへのデータ転送を容易にするために、データは、一連のメタデータ（一実施形態ではinodeの形を持つ）及び関連ファイルデータの形にフォーマットされる。データを宛先ファイルシステムにとって意味のあるものにするために、このデータは、データ転送の種々の部分を分離（例えば、メタデータとファイルデータに）するための認識可能なヘッダや、どのタイプのデータ転送が行われているかを伝えるための認識可能なヘッダを使用してフォーマットされる。更に、削除ファイルリストのような情報を含む幾つかの独立した特定のヘッダが設けられる。図９は、Federwisch他による上記の特許出願に詳細が記載されているヘッダを簡略化したものの詳細を示している。このヘッダは、１ＫＢの汎用部９０２、２ＫＢの非汎用部９０４、及び、１ＫＢの拡張部９０６を有する。汎用部９０２に追加されているのは、次にWORMボリューム情報がデータストリームとして伝送されることを宛先ファイルシステムに伝えるためのWORMボリューム転送フラグ９０８である。このフラグは、オープンプロトコルによって認識できるように、ヘッダの「公共」部に配置される。
【００８３】
同様に、図１０に示すように、ストリーム中の各データファイル１００は、WORMフラグビット１００２を有する。このビットはヘッダ情報とともに使用され、inode/メタデータが指し示す先のファイル（又は、他のデータセット／データコンテナ）に関する適当なWORM状態情報を使用して、新たなinode（メタデータ）を宛先WORMボリュームに再構築するのに使用される。宛先ファイルシステムのミラーリングアプリケーションは、符号化されたフラグを適切に解釈するように構成される。inodeを宛先ボリュームに構築する手順に関する更なる詳細については、上で参照した特許出願に記載されている。
【００８４】
更に別の実施形態として、ソースと宛先の間に信頼関係を成立させるために、従来の暗号化技術、及び／又は、認証技術、あるいは、他のセキュリティ向上手段を使用することにより、ソースと宛先ファイルサーバとの間のセキュリティを向上させることも可能であるものと考えられる。そのような実施形態では、普通なら望ましくない特定の幾つかの復元機能を安全に使用できる場合がある。
【００８５】
Ｆ．保有日の設定と使用
図５及び図６におけるWORMファイル作成を参照して上で説明したように、WOMファイル（又は、他のデータセット／データコンテナ）に関して、保有期間を設定する場合がある。この保有期間は基本的にファイルをWORMに収容する前にファイル属性に設定され、適用された保有期間の間、システムがWORMファイルに関する上記のWORMプロパティ（削除、変更の禁止など）を全て監視できるようにするためのものであり、期間満了後に、ユーザは、期間を満了したWORMファイルに対して、非WORM操作の限られたセットを実施することが許可される。すなわち、期間を満了したWORMファイルをWORMボリュームから削除することができ、それによって新たな記憶のための空間を空けることができる。
【００８６】
図１１は、WORMファイルに関係する保有期間（「保有日」と呼ばれる期間が満了した後の有効な日付／時刻）を設定するための一般的手順１１００を示している。ステップ５０４（Windowsシステムの場合）、及び／又は、ステップ６０４（UNIXシステムの場合）に概略的に記載されているように、まず、WORMとして記憶したいファイルを作成し、それをWORMボリューム上に複製する（ステップ１１０２）。管理者又はユーザが、上記のようなクライアントベースのインタフェース又は他のユーティリティを使用して、保有日を対話的に設定するか、又は、適当なアプリケーションが、所定の規則に基づいて保有日を設定する（ステップ１１０４）。ユーティリティは、保有期間が許容範囲内であるか否かを判定する。後で説明するように、保有期間は、所与の属性において使用可能なビット数に基づいて制限される場合がある。また、最小保有日を指定する場合もある。保有期間が許容範囲内であれば、その保有期間を受け入れる（判断ステップ１１０５）。許容範囲内でなければ、保有期間は拒否され、システムは、無効値エラーコードを返す。ユーザ又は管理者が期間を何も選択しなかった場合、あるいは、保有期間が有効なものでなかった場合、ユーティリティは、保有期間をデフォルト値として解釈する（ステップ１１１０）。このデフォルト値の性質は、種々のファクタによって決まる。例えば、WORMボリュームが、比較的信用のおける管理者を有する「エンタープライズ」モデルに基づくものである場合、デフォルト値は、自由に決定された値に設定されるか、あるいは、適宜、初期値、すなわちゼロ（保有期間なし）に設定される。同様に、デフォルト値が厳格な規制制度に基づくものである場合、適用可能な規則及び慣行によって定義される最小保有期間又は無期限の保有期間が存在する場合があり、それが、デフォルトとしてファイルに割り当てられる。なお、無期限の値が定義された場合、ゼロのような不確定な保有期間を意味する特定のビットコードが、プロパティ又は属性に書き込まれる。
【００８７】
なお、特定のWORM規制制度では、最小保有日が指定される場合がある。つまり、ユーザが保有日を何も指定しなかった場合、無期限の日付を設定するのではなく、有限の最小デフォルト保有日を指定する場合がある。最小デフォルト保有日も、ファイルを記憶する先のWORMボリュームの性質に応じて決まる場合がある。有効な保有日が存在せず、システムがデフォルトとして最小保有期間をボリュームに設定する場合、幾つかのボリュームは、規制又は「政府規制」デフォルト設定に設定される場合がある。管理者が信用のおける者であり、規則が保有日の割り当てに比較的寛大なものである場合、幾つかのボリュームは「エンタープライズ」デフォルト環境に設定される場合がある。この場合、保有日の不在は、特定のエンタープライズWORMボリュームを管理する規則に基づいて、無期限の日付又は特定の有限の日付が割りあてられたものと推定する場合がある。
【００８８】
有効保有期間値（又は、期間なし）を受信した後、手順１１００は、メタデータファイル属性又はプロパティを問合せ、そのファイルに対する最終変更時刻を判定する（ステップ１１０６）。一実施形態において、この最終変更日は、保有日を算出するもとになる基礎データとして使用される。ファイルがWORMに収容されると、最終変更日は固定される。すなわち、収容後は、ファイルを変更することが出来ず、ファイルはリードオンリーのWORMボリュームにおいてWORMとして認識される。ステップ１１０６において、収容前に問い合わせる最終変更時刻は、そのファイルの作成時刻又は複製時刻である。最終変更データは、保有日算出のための基礎の一例に過ぎない。代替実施形態では、コンプライアンス・クロック２７９や他の信用のおけるクロック（例えば、クライアントクロック）のような信頼できると考えられる種々の他の時間基準値を使用する場合がある。
【００８９】
有効な無期限でない保有期間を受信した後、次に、この手順は、コンプライアンス・クロック２７９（図２）による時間の報告に影響を与える可能性があるクロックスキューや他の要因を考慮して、その期間が確実に十分に遠い将来であることを確認する。判断ステップ１１０８によれば、保有期間は、最終変更時刻に従って、最小将来時刻値に設定しなければならない（例えば、１日後、又は２日後）。あるいはシステムは、デフォルト保有期間を使用すべきとみなす場合がある（ステップ１１１０）。
【００９０】
保有期間（有限又は無限）が選択された後、手順１１００は、データ判定の際に監視される、WORMからファイルが解放される時刻を示す時刻値を計算する。そのため、最終変更時刻に保有期間（例えば、「ファイルを１０年間保有」）を加算することにより、そのファイルの将来の解放日を導出しなければならない。
【００９１】
そして、計算された保有日／時刻は、次に、そのファイルの最終アクセス時刻プロパティ又は属性に適用される（ステップ１１１４）。この属性がWORMコンテキストで使用されることは、あるとしてもめったになく、非WORMコンテキストであっても、特に重要ではない。例えば、Windows環境では、システムを起動するたびに大量のファイルがアクセスされるため、この属性は、所与のファイルの実際の「アクセス」に関する情報をあまり持たない。従って、最終アクセス時刻プロパティ／属性は、重要な保有日ビットコード（もしあれば）を記憶するための媒体として、WORMユーティリティにより使用することができる。
【００９２】
最終アクセス時刻フィールドに保有日が適用された後、次に、そのファイルを不変状態にする。つまり、上記のようにリードオンリー属性を設定し、WORMユーティリティに、そのファイルに対する以後の変更を全て拒否させる。同様に、最終アクセス時刻を含むファイルの属性／プロパティを固定する。このように、最終アクセス時刻フィールドにおいて、将来の保有日は固定され、不変状態にされる。
【００９３】
保有期間を最初に設定した後、その保有期間を延長しなければならない状況がある。例えば、いずれ保有期間を過ぎる運命のファイル又はレコードが、取り調べの対象になった場合、それを通常の期限日を超えて無期限に保有しなければならない場合がある。従って、WORMユーティリティは、保有期間の満了を考慮して、収容されたWORMファイルのプロパティの変更を制限する条項を有する。図１２は、保有日／時刻延長手順１２００の詳細を示している。通常は、ユーザ又は管理者が、特定ファイルの保有期間を延長するための要求を開始する（ステップ１２０２）。保有日の初期設定と同様に、延長期間日は、最終アクセス時刻フィールドに基づく値内でなければならない。値内である場合、次に、手順は、最終アクセス時刻を問合せ、既存のフィールド値を読み出す（ステップ１２０４）。
【００９４】
判断ステップ１２０６は、要求された日付又は期間が、既存の日付よりも先であるか否かを確認する。先でなかった場合、延長の要求は拒否される。逆に、要求が、十分に遠い先への延長を求めるものであれば、新たな延長された保有日／時刻が算出される（ステップ１２１２）。この計算は、種々の方法で実施することができる。例えば、延長後のデータは、基準時刻や最終変更時刻に基づいて決定することができ、延長後の新たな期間は、それらの値に加算される。あるいは、延長後の保有日は、最終アクセス時刻値（現在の保有日／保有時刻）と延長後の新たな保有期間を加算することにより、延長後の新たな保有日／保有時刻を算出することができる。上記の例のいずれにおいても、延長後の期間が無限であれば、無限の保有期間に対する適当な表現が算出される。なお、いったん期間を無限又は永久に設定すると、その期間を後から減らすことはできない（ステップ１２０６、１２０８及び１２１０）。最後に、ステップ１２１４において、WORMユーティリティは、当該WORMファイルに対する変更の通常の禁止に優先して、最終アクセス時刻プロパティの制限付き上書きを許可し、新たに計算された延長後の保有日値（又は無限保有の指示）を記憶できるようにする。
【００９５】
本明細書に記載されるように、一般に使用されているNFSバージョン２及びバージョン３は、１９７０年１月１日（「時刻０」）からの秒数として解釈される３２ビットの時刻フォーマットを使用している。しかしながら、多くのオペレーティングシステムは、この値を符号付き３２ビット整数として解釈し、その日付範囲を事実上３１ビットの値に制限し、２０３８年１月１８日の時刻値を上限値として課している。従って、将来の実施形態（CIFSやNFSバージョン４）は間違いなく、事実上無制限の日付範囲を全てサポートするであろうが、現在の実施形態は、日付範囲の限られた上限値を多少考慮しなければならず、その上限値は、特定ファイルの長期記憶において許容できない場合もある。
【００９６】
従って、保有日を記録するための範囲の拡大を可能にするために、現在の認識が３１ビットの符号付きの値であることを想定し、WORMユーティリティは、特定の日付値を何らかの時間をずらした形に書き替えなければない。このようにして、WORMユーティリティは、例えば２００３年１月１日のような新たな比較的同時代の基準時刻、又は、時代（時刻０）を得る。ただし、WORMユーティリティは、時間範囲全体をこの新たな基準時刻までずらすのではなく、２００３年１月１日（新たな時刻０）よりも前の最終アクセス時刻を２００３年１月１日よりも後の最終アクセス時刻とは異なる解釈で解釈する（図１３の時間ライン１３００を参照）。このようにして、新たな時刻ゼロと２０３８年１月１８日（古い上限）との間にある全ての保有日が、標準値（３１ビット日付範囲１）として保持される。ただし、新たな時刻ゼロよりも前の時刻にある最終アクセス時刻はすべてWORMシステムの有効日よりも前にあるため、これらの日付は、２０３８年１月１８日と２０７１年１月１日の間にある上限範囲の日付（３１ビット日付範囲２）として解釈され、すなわち丸められる（矢印１３０１）。２つの３１ビット日付範囲（新たな時刻０の前と、新たな時刻０の後０）をあわせると、図示のような新たな上限範囲である２０７１年１月１日までの３２ビット保有日範囲１３０２全体が得られる。
【００９７】
当然ながら、時刻値のビット範囲の制限に対して、種々の解決方法を使用することができる。また、十分に長い時刻値を最終アクセス属性に使用することが可能な場合、時間書き替え法は必要ない。
【００９８】
時刻値をトラッキングし、適切な期限日／時刻にWORMファイルが解放されるようにするために、セキュア・コンプライアンス・クロック２７９（図２）が、ストレージオペレーティングシステムに供給される。コンプライアンス・クロックは、種々の態様のストレージオペレーティングシステム、並びに、WORMユーティリティと交流し、通常の保有期間を過ぎた所望の保有日を提供することを確実に目標とする時刻値を生成する。
【００９９】
一実施形態によるセキュア・コンプライアンス・クロック２７９の例を図１４に示す。このクロックは通常、ハードウェア・メカニズムではなく、ソフトウェアとして実施される。このクロックは、コンシステンシー・ポイント・オペレーション（ＣＰ）のような規則正しくスケジューリングされた連続的ファイライベント１４０４から一貫性のあるパルスを受信する時刻値発生器１４０２を含む。時刻値発生器１４０２は、ＣＰ又は他のイベントを時間基準の値に変換するスケーリング機能を有する。例えば、１１秒毎にＣＰが発生する場合、このクロックは、各ＣＰを、時間基準を１１秒進めるものとして解釈する。時刻値発生器１４０２内のカウンタは、イベントの進行全体を維持し、それらのイベントから現在進行中の日付／時刻値１４１０を生成し、それをWORMユーティリティ及びシステムの他の興味のある構成要素に出力する。時刻値発生器は、その時間基準値（例えば、時刻０）を受信し、その合計動作時間を適当な記憶素子に記憶することができる。実際には、例えば、関連WORMボリューム上にある削除不能なWORMファイル１４１４におけるディスク上のレコードを例えば使用して、時間メモリを定期的に永久記憶装置に収容することができる。一般にこれは、コンプライアンス・クロックが、基礎となるファイラに同調するのではなく、WORMボリュームに同調することも意味する。このファイルは、システムクラッシュ、故障、又は、ファイラの取り替え／アップグレードの際にアクセスされる。従って、ファイラの起動時には、各WORMボリュームのクロックファイルが、追加された安全性の尺度として読み出され、一番古いクロックタイムが、WORM動作におけるファイラの総合的なコンプライアス・クロックの値として選択される。特定WORMボリュームに使用されている以前のモデルよりも速いサイクルタイムを有する新しいファイラを配備する場合、コンプライアンス・クロック発生器１４０２は、時間基準のこの変化を考慮するためにアップグレードされ、ファイル１４１４から経過時間カウントを読み込んでカウントを再開し、その新たなスケールを使用して所望の正確な時間カウントの出力を継続する。
【０１００】
システムダウンタイムその他の要因によって、コンプライアンス・クロックが報告する時刻と実際の時刻（例えば、グリニッジ標準時）の間にずれ、すなわちスキューが発生することもあるが、コンプライアンス・クロックをファイラのシステムクロックのような他のクロックに接続することにより、このずれ／スキューは、考慮に入れることができる。図１４に示すように、コンプライアンス・クロック２７９は、従来のシステム・ハードウェア／ソフトウェア・クロック（又は、他の一般的に信用のおけるクロック）１４１６からの入力を備え、申告により、そのクロックから報告された時刻を実際の時刻と比較することができる。この比較は、絶対的な比較（例えば、報告された日付／時刻とシステムが報告する日付／時刻の比較）と、経過時間に基づく相対的比較（例えば、システムクロックの経過秒数とコンプライアンス・クロックの経過秒数の比較）の両方により実施してもよい。ハードウェアシステムクロックに対するコンプライアンス・クロックのスキューを低減するために、コンプライアンス・クロックは、記載した周期的イベント（例えば、ＣＰ）の増分カウントを実施するが、コンプライアンス・クロックは更に、厳格に束縛された速度のハードウェアシステムクロックタイムに向けて「推移」する。この「推移の束縛」により、コンプライアンス・クロックをシステムハードウェアクロックタイムに追従、すなわちロックさせることができ、長い時間にわたるクロックスキューの合成を防止することができる。この推移速度の束縛１４１８によれば、時期を早めてWORMレコードを削除しようとして、たとえ管理者がクロックを例えば１０年進めたとしても、コンプライアンス・クロックはその新たな時刻に向けてゆっくりと推移するため、その破壊的試みは無効化される。例えば、一年あたり±１０００秒の許容推移速度しか許容されない場合（すなわち、１年あたり、１０００秒を超えてコンプライアンス・クロックを進めたり戻したりすることができない場合）、たとえシステムクロックを（誤って）１年先に設定したとしても、コンプライアンス・クロックを１年間ずらすためには、数千年を要することになる。
【０１０１】
更に別の安全性尺度として、システムクロックとコンプライアンス・クロックの比較した値が同期から大きく外れている場合、管理者、又は、スーパーバイザー／取締人に対し、警報を発する場合がある。更に、全ての警報をボリューム又はクロックファイルに関連する永久的／WORM記憶装置にログとして記録してもよい。そのような警報が発せられた場合、権限により、適当な動作を行うことができる。また、警報期間中は、ファイルの削除や変更が、全て無効化される。一実施形態によれば、上記の機能拡張によって、コンプライアンス・クロックの比較的不正操作に強い性質が向上する。同様に、セキュア・ハードウェアクロックや、信頼のおける第三者機関（例えば政府）のクロックも、高レベルの不正防止機能を提供することができる。
【０１０２】
コンプライアンス・クロックの例について上に記載したが、当然ながら、内部的時刻維持手順と外部的時刻維持手順の外部的、内部的、又は組み合わせを使用した種々のメカニズム及び技術も考えられる。例えば、ネットワークにより相互接続された政府系の原子時計のような外部マスタークロックを使用してもよい。
【０１０３】
クライアントが或るファイルを手動で削除しようとする場合、あるいは、適当なアプリケーションデーモンプロセスが、ボリュームをスウィープしてファイルを見つけ、削除する場合、システムは、そのファイルの保有日を超過しているか否か、及び、そのファイルの削除が許可されているか否かを判断しなければならない。図１５は、WORM保有日をチェックし、期限を満了したファイルから適宜、WORM状態を一部解除することが可能な汎用手順を示している。
【０１０４】
ステップ１５０２によれば、ユーザ又は管理者は、当該WORMファイルに対するアクション（例えば削除）を要求し、又は、アプリケーションデーモンは、そのファイルを削除可能であるかを調べる。この時点でWORMユーティリティは、当該ファイルの最終アクセス時刻を問い合わせる。これを記憶した後、信用のおける日付／時刻をコンプライアンス・クロックに問い合せる（ステップ１５０４）。
【０１０５】
ステップ１５０６によれば、保有日が、クロック日（又は、更なるスキュー防止のために、クロック日よりも後の何らかの最小将来期日）以後である場合、要求者は、そのファイルに対して何もアクションを行うことができない（ステップ１５０８）。通常、無期限の保有日が設定されている場合、保有日が、クロック日よりも前であることは絶対になく、アクションがユーティリティによって許可されることは絶対にない。
【０１０６】
逆に、保有日が、コンプライアンス・クロック日（又は、クロック日＋「安全」マージン）以前である場合、判断ステップ１５０６はステップ１５１０へ分岐し、ユーザ又は管理者は、そのファイルに対して限られたアクションを行うことが許可される。一実施形態において、このアクションは通常、ボリュームからのそのファイルの削除に限定される。ただし、エンタープライズモデルWORM実施形態の場合、他のファイル操作が許可される場合もある。このように、ファイルを無傷に維持したままファイルの完全性を改ざんする可能性がある他のアクションは、そのまま禁止される。通常、ファイルをWORMに収容するためのリードオンリー属性は、期限日と共に維持され、それによって、「削除」の限られたファイルパーミッションを返すことが可能になる。従って、ユーティリティは、期限を過ぎたWORMファイルに対して削除許可だけを与える。
【０１０７】
上記のように、クライアントは、アプリケーションデーモン又は類似のユーティリティの動作により、保有日を過ぎたファイルの自動削除を実施することができる。一般に、コンプライアンス・クロック又は信用のおけるクロックを使用すれば、保有日の超過に対する信用のおける基準が得られ、自動削除処理が容易になる。つまり、この削除は、期限を過ぎたファイル、すなわち、信用のおけるクロック時刻以後の保有日を有するファイルを見付けるためのボリュームの定期的スキャンに基づいて、「自動的」態様で行うことができる。その目的のために、最近の信用のおけるクロックタイムをシステムメモリに記憶し、それを各ファイルの時刻と比較することにより、期限を過ぎたファイルを見つけることができる。あるいは、各ファイルの保有日を読み取り、現在時刻を取得して、それらを比較してもよい。期限超過を確認した後、各ファイルに対する削除を実施してもよいし、あるいは、スキャンによって期限を過ぎたファイルを全て特定した後、バッチ処理によりそれらを削除してもよい。次に、それらのファイルは、アプリケーションにより、適当なファイル管理スクリプトを使用して削除される。本明細書に記載するデーモンは通常、クライアント側で動作するが、当然ながら、信用のおけるクロックを利用した自動削除プロセスは、クライアント側で実施してもよいし、ファイルサーバ側で実施してもよく、あるいは、両方で実施してもよい。
【０１０８】
なお、代替実施形態において、本明細書に記載するWORMファイラ又はファイルサーバは、マルチプロトコル・ストレージ・アプライアンスとして実施することもでき、また、常駐ストレージオペレーティングシステムは、仮想ディスク（「vdisk」）モジュールとして実施される仮想化モジュールと、ＳＣＳＩターゲットモジュール（図示せず）とを備えた仮想システムとして実施してもよい。vdiskモジュールはファイルシステム２５０上にレイアウトされ、システム管理者がマルチプロトコル・ストレージ・アプライアンスに対して発行したコマンドに応答して、精錬されたユーザインタフェース（ＵＩ）のような管理用インタフェースによりアクセスすることができる。実際には、vdiskモジュールは、とりわけ、システム管理者によってＵＩを使用して発行されたvdisk論理ユニット番号（ＬＵＮ）コマンドの複雑なセットを実行することにより、ＳＡＮデプロイメントを管理する。これらのvdiskコマンドは、ファイルシステム２５０及びＳＣＳＩターゲットモジュールと交信してvdiskを実現するための原始的なファイルシステムオペレーション（「プリミティブ」）に変換される。このマルチプロトコル・ストレージ・アプライアンスの詳細については、「STORAGE VIRTUALIZATION BY LAYERING VIRTUAL DISK OBJECTS ON FILE SYSTEM」と題する、本願と同じ譲受人による米国特許出願第１０／２１６，４５３号に記載されており、その教示は参照によって本明細書に援用される。ＬＵＮはストレージシステムにおいてファイルとして表現されるため、当然ながら、ファイルをWORM状態にし、そのファイルに決められた保有日を与えることが可能な種々のパーミッション及び属性は、ＬＵＮ構造にも適用可能であるものと考えられる。
【０１０９】
なお、例示した実施形態のWORM機能や保有日機能の実施には、オープンプロトコルが一般に使用されるが、当然ながら、工業所有権を有するプロトコルや、オープンプロトコルを大幅に改造したプロトコル、例えば工業所有権を有するＡＰＩを使用して、本発明の種々のWORM機能を実施することも可能であるものと考えられる。例えば、代替実施形態では、工業所有権を有するＡＰＩを使用して保有日を実施することがある。これらを信用のおけるクロック又は、コンプライアンス・クロックと組み合わせることにより、信頼性の高い保有日、及び、不正防止動作を確保することが可能である。また、「ストレージシステム」という用語は、本明細書に様々に記載された信用のおけるクロックに関して使用される場合、上で概略を説明したようなコンテント・アドレッサブル・ストレージシステム（ＣＡＳ）を含む。そのような信用のおけるクロックによれば、それらのタイプのストレージシステムの信頼性や不正防止動作を向上させることができる。
【０１１０】
本発明の幾つかの例示的実施形態に関する詳細な説明が、上に記載されている。本発明の思想及び範囲から外れることなく、種々の改変及び追加を施すことが可能である。例えば、一実施形態において、各データコンテナ、データセット、又は、ファイルに関連する保有日／時刻値は、最終アクセスプロパティフィールドに設けられているが、当然ながら、この値は、データコンテナ、データセット又はファイルに関連するものであって、データコンテナ、データセット、又は、ファイルをWORMに格納する際に不変状態にすることができ、それらの管理及び取り扱いに干渉することがないものであれば、任意のプロパティ、属性、又は、他のデータに適用することが可能である。また、一実施形態によれば、ファイルの保有日／時刻は、最終変更時刻を問い合せ、そこに保有期間を加算することによって設定又は延長されているが、例えば、コンプライアンス・クロックや他の信用のおける時刻ソースから時間基準を得ることを含めて、保有日／時刻の算出には種々の時間基準値を使用することが可能である。同様に、サーバ、又は、それに対応するストレージアレイ、クライアント、並びに、そのネットワーク接続、及び、プロトコルの内部アーキテクチャは、大きく異なるものであってよい。種々のソースサーバ及び宛先サーバで使用されるオペレーティングシステムも異なるものであってよい。更に、当然ながら、本明細書に記載する動作及び手順はいずれも、ハードウェア、コンピュータ上で実行されるプログラム命令を有するコンピュータ読取可能媒体を含むソフトウェア、及び、ハードウェアとソフトウェアの組み合わせ、のうちのいずれを使用して実施してもよいと考えられる。従って、本明細書の説明は、例として解釈すべきものであり、本発明の範囲を制限するためのものではない。
【図面の簡単な説明】
【０１１１】
【図１】本発明の原理が内部で実施されるファイルサーバ及び関連クライアントを含む例示的なネットワーク及びファイルサーバ環境を定義する略ブロック図である。
【図２】本発明の一実施形態による例示的なストレージオペレーティングシステムを示す略ブロック図である。
【図３】本発明の一実施形態によるWORMボリューム作成手順を示すフロー図である。
【図４】WORMファイルパスウェイの一例を示すディレクトリツリーの概略図である。
【図５】本発明の一実施形態による、Windowsクライアントの場合のWORMファイル作成及び収容手順を示すフロー図である。
【図６】本発明の一実施形態による、Unixクライアントの場合のWORMファイル作成及び収容手順を示すフロー図である。
【図７】本発明の一実施形態による同期ミラーリング手順を示す概略図である。
【図８】本発明の一実施形態による非同期ミラーリング手順を示す概略図である。
【図９】図８の非同期ミラーリング手順に使用されるデータフォーマットの汎用ヘッダの概略図である。
【図１０】図９の非同期ミラーリング手順により送信されるデータファイルのWORMフラグの概略図である。
【図１１】本発明の一実施形態による、WORMファイルの保有日／時刻設定手順を示すフロー図である。
【図１２】本発明の一実施形態による、WORMファイルに収容された保有日／時刻を延長するための手順を示すフロー図である。
【図１３】本発明の一実施形態による、日付用に限られたビット範囲しか持たない特定のオープンプロトコルの場合に、使用可能な保有日範囲を拡大するための例示的技術を示す時間線である。
【図１４】本発明の一実施形態による、保有日／時刻のトラッキングに使用されるセキュア・コンプライアンス・クロックの一例を示す概略図である。
【図１５】本発明の一実施形態による、対象ファイルの保有日／時刻の超過を判定し、対象ファイルに対する特定のWORM制限を外すための手順を示すフロー図である。
【図１】
2007524954.tif 000003
【図２】
2007524954.tif 000004
【図３】
2007524954.tif 000005
【図４】
2007524954.tif 000006
【図５】
2007524954.tif 000007
【図６】
2007524954.tif 000008
【図７】
2007524954.tif 000009
【図８】
2007524954.tif 000010
【図９】
2007524954.tif 000011
【図１０】
2007524954.tif 000012
【図１１】
2007524954.tif 000013
【図１２】
2007524954.tif 000014
【図１３】
2007524954.tif 000015
【図１４】
2007524954.tif 000016
【図１５】
2007524954.tif 000017
【手続補正書】
【提出日】平成18年7月5日(2006.7.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
追記型(WORM)ストレージシステムにおいてデータセットに保有期間を与える方法であって、
WORMデータセットを作成し、該WORMデータセットをWORMデータ構造に保存するステップと、
前記データセットに永久的に関連付けられた前記データセットのデータに保有期間を設定するステップと、
前記WORMデータセットを前記WORMデータ構造に収容し、その後、前記ストレージシステムは前記保有期間の短縮を禁止し、前記ストレージシステムは前記保有期間の満了後の時点まで前記WORMデータセットに対する変更を全て禁止するステップと
からなる方法。
【請求項２】
前記保有期間の満了後、前記ストレージシステムは、前記WORMデータ構造からの前記WORMデータセットの削除だけを許可し、前記WORMデータセットに対する他の変更を全て禁止する、請求項１に記載の方法。
【請求項３】
前記保有期間に延長期間を加算し、延長された保有期間を導出し、該延長された保有期間を、前記保有期間が設定される前記データに記憶することにより、前記保有日を延長するステップを更に含む、請求項１に記載の方法。
【請求項４】
前記保有期間を前記ストレージシステムに関連するコンプライアンス・クロックの時刻値と比較し、該時刻値が前記保有期間以後の値になった後、前記WORMデータセットの削除だけを許可することを更に含む、請求項１に記載の方法。
【請求項５】
前記ストレージシステムは、前記WORMデータ構造における前記WORMデータセットを含むディレクトリパスのリネームを禁止するように構成される、請求項１に記載の方法。
【請求項６】
前記WORMデータ構造をミラー宛先に作成し、作成されたWORMデータセットを前記宛先WORMデータ構造に送信し、収容することを更に含む、請求項１に記載の方法。
【請求項７】
ファイルシステムを有する追記型(WORM)ストレージシステムであって、
ファイルシステムに常駐し、ファイルが指定されたボリュームに記憶された後、該ファイルに与えられたオープンプロトコルファイル属性に基づいて、該ファイルを前記指定されたボリュームに収容し、収容された後、該ファイルを変更することが出来ない選択された保有期間を提供するWORMユーティリティを含む、WORMストレージシステム。
【請求項８】
前記オープンプロトコルファイル属性は、リードオンリーファイル属性からなる、請求項７に記載のWORMストレージシステム。
【請求項９】
前記WORMユーティリティは、前記保有期間をコンプライアンス・クロックの時刻値と比較し、前記保有期間が前記時刻値よりも以前になった後、所定の変更を許可するように構成される、請求項７に記載のWORMストレージシステム。
【請求項１０】
前記所定の変更は、前記ファイルの削除だけからなる、請求項９に記載のWORMストレージシステム。