JP3797864B2 - オペレーティングシステムとの関連でデータを回復および再生する方法、ソフトウェア、および装置 - Google Patents
オペレーティングシステムとの関連でデータを回復および再生する方法、ソフトウェア、および装置 Download PDFInfo
- Publication number
- JP3797864B2 JP3797864B2 JP2000308367A JP2000308367A JP3797864B2 JP 3797864 B2 JP3797864 B2 JP 3797864B2 JP 2000308367 A JP2000308367 A JP 2000308367A JP 2000308367 A JP2000308367 A JP 2000308367A JP 3797864 B2 JP3797864 B2 JP 3797864B2
- Authority
- JP
- Japan
- Prior art keywords
- disk
- data
- history
- location
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
Description
【０００１】
【発明の属する技術分野】
本発明は、一般にデジタルデータの格納に関し、特に、オペレーティングシステム（ＯＳ）によって同システム管理下のファイルになされた変更を、デジタルコンピュータによって格納されたデータのバックアップおよび回復を支援する変更追跡システムとの関連のもとで追跡するための、方法および装置に関する。
【０００２】
【発明の背景】
コンピュータ上で実行されるアプリケーションは、特にハードディスクからの情報の保存および再呼び出しに責任を負う、オペレーティングシステム（ＯＳ）のもとで動作するのが通常である。情報は、通常はファイルに編成されている。ＯＳは、ファイルと、そのファイル情報を保持するハードディスク上の関連位置との間でマッピングを行う方法を保持している。
【０００３】
現在のコンピュータは、一般に、情報（データ）を読み出して永続記憶用のディスクに書き込む形で動作する。通常は、ディスクを周期的にバックアップ（コピー）することによって、次の２種類の問題に対処している。第１に、ディスク自体が物理的に故障すると、そこに含まれていた情報がアクセス不能となる。第２に、ディスク上の情報が変更され、もとの状態が望ましかったと判断されると、ユーザは、バックアップを使用してこのもとの状態を回復する。バックアップは、同じディスクまたは代替の媒体（ディスクやテープ装置等）に対して行うことができる。
【０００４】
テープバックアップとしては、従来、ファイルまたはディスクセクタイメージとして編成されたディスクの内容を、磁気テープ上に複製する手法がある。このようなテープは、通常は取り外し可能であるので、サイトの外に格納して、ディスクドライブの誤動作や、さらには例えば火災による（ディスクドライブを含む）サイト全体の破壊に対して回復を提供することができる。
【０００５】
情報がセクタレベルのディスクイメージの形態でディスクからテープにコピーされる（すなわち、情報がディスク上と同じ形でテープ上に編成される）場合は、同一のディスク駆動装置に対して最も効率的に復元を行うことができる。このように編成する理由は、速度である。ディスクを最初から最後まで順次読み出す方が、ディスク上を跳び回って一度に１ファイルづつ読み出すより遥かに高速である。これは、ファイルがディスクの１領域に連続的に保存されていないことが多く、ディスク全体に広がって他のファイルと混ざっている可能性があるからである。情報を一度に１ファイルづつテープにコピーする場合は、１つまたはそれ以上のファイルを、すでにデータを含んでいる異なるディスクで効率的に復元することができる。
【０００６】
テープバックアップは、ある時点におけるディスク全体または特定のファイルをバックアップすることに焦点を合わせている。この処理は、長時間かかるのが通常であるため、例えば夕方等に低頻度で行われる。増分（インクレメンタル）バックアップは、最終のバックアップ以降に変更されたデータのみを保存するため、必要なテープ量およびバックアップ時間が低減される。しかしながら、システムを完全に回復させるには、システム全体の最初のバックアップとその後の増分バックアップ全てを読み出して結合し、最終の増分バックアップの時点まで復元しなければならない。テープバックアップの主要な欠点は、最新のバックアップが実行されていない場合に、最後のバックアップ後に生成された情報や作業が失われる可能性があるということである。
【０００７】
ＷＯＲＭドライブによって行われるような追記型のディスクバックアップは、データバックアップと同じ特性を多数有する。しかし、その関連技術のためデータを上書きすることができない。したがってＷＯＲＭドライブは、変更できないバックアップのある程度のリーガル「アカウンティング」システム（legal "accounting" system）を提供する。ＷＯＲＭドライブは、最終的に一杯になってしまうため、変化するディスク情報に連続的なバックアップを提供することはできない。
【０００８】
ＲＡＩＤシステムは、集合的に１つの記憶システムとして動作するドライブの集まりであり、１つのドライブの故障をデータの損失なしに許容し、且つ互いに独立して動作することができる。ＲＡＩＤに含まれる２つの主要な技術は、ストライピングとミラーリングである。ストライピングは、データをドライブ間で分割して高いデータスループットを得る。ミラーリングは、全てのデータを１つのドライブから他のドライブに複製することによって冗長性を提供する。一般に、１つのドライブが故障しても、他のドライブが別のコピーを有しているため、データが失われることはない。
【０００９】
ＲＡＩＤシステムは、物理的なドライブの故障に対するバックアップという形で、速度およびデータの冗長性に関連する。しかしながら、ＲＡＩＤシステムでは、変更された情報を検索する目的で時間を遡ることはない。
【００１０】
Ｔｉｌｉｏｓオペレーティングシステムは、ディスクの状態を保護し、ユーザによるその継続および修正を可能にするために、数年前に開発されたものである。このオペレーティングシステムでは、保護状態と現行状態の２つの状態が維持される。現行状態が失われるかまたは無効になるクラッシュが生じた場合に、ディスクを容易にその保護状態に復帰させ、ログを再生できるように、キー入力（キーストローク）のロギングが実行された。ここでは、例えばファイルを編集しているユーザをシミュレートすることによって、クラッシュした時点に至るまでのディスク情報を、全て回復することができる。保護されたディスクイメージが、現行のものと共に常に利用可能であるため、情報を後の時点にコピーする、すなわち保護バックアップの時点で保存された情報を現行状態にコピーすることができる。
【００１１】
Ｔｉｌｉｏｓオペレーティングシステムでは、全ての作業がディスク上で行われ（たとえば、テープへの転送がない）、変更の増分を記録するという特質（すなわち、現行状態と保護状態の差が通常は小さい）を利用した技術が使用されているため、バックアップをより高速で行うことができる。それにもかかわらず、ユーザは、やはり保護（バックアップ）を行う特定の時間を選択するという問題に直面しなければならず、キー入力の再生方法は、バックアップ後の状態を再現するのに全面的に信頼できるものではない。例えば、キー入力がフロッピィディスクまたはインターネットからデータをコピーするコマンドだった場合、それらの対話は、いずれもＣＰＵおよびディスクで再現できる範囲の外にある。
【００１２】
これまでは、ファイルの拡張子だけを変更した新しいファイル名でファイルのコピーを作成する（例えば、「abc.doc」を「abc.bak」にコピーする）ことにより、ファイルのバックアップが簡単に作成されてきた。この場合、メインファイル（abc.doc）が破損または紛失した時に、バックアップ（abc.bak）からそのファイルを復元することができる。しかしながら、この処理は、選択的なテープバックアップとほぼ同じであるため、バックアップ管理の問題（いつ行うか、いつ廃棄するか等）を伴う。
【００１３】
要するに、ＲＡＩＤシステムは、物理的ドライブの故障に関係したバックアップのみを取り扱っている。テープ、ＷＯＲＭ、Ｔｉｌｉｏｓ、およびファイルコピーは、変更された（失われた）情報の回復に関係したバックアップにも対処している。
【００１４】
従来のバックアップ処理は、一定の期間停止してディスク情報の複製コピーを作成する作業を含む。これは、ディスク全体が再現されるか、または特定の情報が再呼び出しされるように、ディスク全体を見てコピーを作成する作業を含む。この処理は、テープへの書き込みを含むのが通常である。あるいはユーザは、特定の時点以降の凍結されているコピーを表す複製を作成することで、ファイルの特定の集合をバックアップしても良い。ここでは、オリジナルが継続して変更されることを想定している。この処理は、通常、オリジナルと同じディスクドライブ上にバックアップファイルを作成することを含む。ここで、「ディスク」とは実際には、１つもしくはそれ以上のディスクドライブ、またはディスクドライブと同様に作動する装置を意味することに注意が必要である。
【００１５】
上述したいずれの場合も、ユーザは、バックアップを作成することを意識的に決定しなければならない。後者の場合は、テキストエディタのような特定のアプリケーションが、最後の数バージョンのファイル（情報）を保持している。しかしながら、ファイルがスタビライズされて長期間経た後には最終的に全てが複製されて、ディスク空間が浪費される原因となる。つまり、ユーザが、文書の処理中に前のバージョンに戻りたいケースは多くても、完了して何年も経過した後に、最終状態の直前の状態を再訪したいと思うことは滅多にない。
【００１６】
情報の回復が非常に重要となるもう１つの状況は、どのファイルがディスク上のどの場所に位置しているかを識別するディスク用のディレクトリシステムが破損した場合である。これは、例えば、ディレクトリのアップデート（更新）中に生じるシステムクラッシュや、オペレーティングシステムまたは他のユーティリティ内でのバグが原因で発生する。いずれの場合も、ディスク内容のディレクトリが失われると、たとえ参照ファイルがディスク上に存在していたとしても、それら参照ファイルも失われる結果となる。この場合、ユーザが復元したい情報はディスクのディレクトリである。
【００１７】
ユーザがバックアップに復帰したいと思う最後のケースは、例えば、動作しない新しいソフトウェアまたはデバイスドライバをインストールしたことが原因で、オペレーティングシステムが破損した場合である。
【００１８】
ユーザが、コンピュータディスク上で操作されている情報の内容を、時間的に遡りたいと思う理由は数多くある。従来のバックアップでは、バックアップした時点まで回復することができた。しかしながら、システム全体に渡るこれらのバックアップは、ディスクを走査してその内容を複製するのに長時間必要であるため、行える頻度に限界がある。つまり、このバックアップでは、大きな動作休止と莫大な量の記憶領域とが必要であり、ディスク全体を数分毎にバックアップすることは不可能である。時間の進行に従ってファイルの履歴コピーを保持するには、結局はユーザがアーカイブの管理およびコピーの消去を行って、ディスクのオーバーフローを回避する必要がある。
【００１９】
ファイルの名前を変更し、ファイルのデータを別のファイルと再び関連付ける（re-associate）技術は、データのコピーおよび古いファイルの検出に伴うオーバーヘッドを回避するのに使用される周知の技術である。ＯＳのもとでファイルの名前を変更する動作は、一般に、割り当ての集合をＯＳのファイルシステム内であるファイルから別のファイルへと再び関連付けることを含む。大体の場合は、１ファイルが１集合のディスク割り当てを表し、記憶領域の管理は、同一のファイル内または異なるファイル間でこれらの割り当てを操作することによって行われる。例えば、ＰＣ上の自由記憶領域自体をファイルと見なすことができる。ファイルの作成時には、記憶領域が自由ファイルから引き出されて別のファイルと再び関連付けられる。ファイルを削除する技術は、その定義上、あるファイルデータを保持するのに使用された記憶領域が汎用プールに戻れることを、信号で示すためにＯＳのもとで使用される方法である。汎用プールは、ＯＳが、新しく作成されたファイルに記憶領域を割り当てるもととなる領域である。これらの概念は、ＯＳの設計技術の当業者に周知である。
【００２０】
従来技術によるデータのバックアップアプリケーションに固有な別の問題点は、データがディスクに書き込まれる順番を制御する必要があることである。例えば、ある状態から別の状態に移行する場合は、移行データをディスク上に書き込み（フラッシュし）、次いで、データのバックアップアプリケーションで必要とされる内部バックアップデータを更新する。しかしながら、現在のディスクドライブは、性能向上のために書き込みキャッシュを備えているのが一般的である。書き込みキャッシュは、書き込みをバッファリングし、書き込みとは異なる順序でデータをディスク媒体上に格納（コミット）する。この処理は、例えばディスクコントローラが、ディスクヘッドの動きを低減する順序でデータを書き込むことを可能とすることにより、書き込み処理全体のスピードアップを図るものである。しかしながら、ディスク上にすでに存在すると想定されるデータ（書き込まれるのをまだ待機している）よりも、内部バックアップデータの方が先に更新される。電源障害が発生すると、ある安定状態から別の安定状態への安全な移行が不可能となる。
【００２１】
ディスクドライブに送信されて、このような書き込みキャッシュの最適化を使用不可にできるコマンドが存在する。しかしながら、これらのコマンドは、他の有用な最適化をも使用不可とするため、深刻な性能低下を生じる原因となる。ディスクのなかには、フラッシュコマンドをサポートし書き込みキャッシュを特別にフラッシュするものもあるが、このようなコマンドを使用可能とするのは容易でない。つまり、今日のコンピュータには、ディスクでの読み取りおよび書き込みを行う基本入出力システム（ＢＩＯＳ）の標準手段が含まれているが、書き込みキャッシュをフラッシュする標準手段は含まれていない。したがって、コンピュータのディスクドライブがフラッシュコマンドをサポートするか否かに関わらず、データのバックアップアプリケーションは、標準的なＢＩＯＳインターフェースを使用していることが原因で、容易に初期化フラッシュを行うことができない。データのバックアップアプリケーションは、ディスクと直接通信を行う必要があるため、特別なハードウェア知識を有している。これは、あらゆるコンピュータ上で実行されることを期待される、汎用プログラムの見地からは不可能である。コンピュータメーカがとった一般的な方法は、特定タイプのハードディスクを、そのタイプのディスクの制御方法を知るＢＩＯＳと結合させることであった。その後のソフトウェアは全て、ＢＩＯＳによって提供されたＳＣＳＩやＩＤＥ等のインターフェースに依存してディスクと送話するのが一般的であり、今日のインターフェースにフラッシュコマンドがは含まれていない。
【００２２】
したがって、改良バックアップ方法は、専門のディスク（ハードウェア）知識をエンジン内に構築しなくても、書き込みキャッシュの存在を、それをフラッシュする必要なしに容易にするものである。これは、この方法が、ディスクコントローラに書き込まれるデータが実際には異なる順序でディスク媒体に格納（コミット）され得ることを考慮に入れなければならないこと、そしてそれにもかかわらず、この方法がディスク上のデータ保全性を維持してクラッシュの回復を可能とする必要があること、を意味する。
【００２３】
【発明が解決しようとする課題】
以上から、データを回復させるための改良方法が必要とされていることがわかる。この改良方法は、コンピュータディスクの以前の状態を、安全且つ発生順に制御する方法で再構築することを可能とする必要がある。
【００２４】
【発明の概要】
本発明は、大まかにいえば、コンピュータディスクの現行の状態と履歴データとを共に使用し、そのディスクの以前の状態を再構築する方法を提供することにより、上述したニーズを満たすものである。本発明では、セクタレベルのバックアップをファイルレベルのバックアップと組み合わせることにより、効率および信頼度の向上を図る。
【００２５】
１実施形態では、データを回復させる方法を開示する。先ず、ディスク位置Ｘ、ディスク位置Ｙ、ディスク位置Ｚ等の種々のディスク位置を含むディスクについて、ディスクの履歴状態の記録を作成する。ディスク位置Ｘにあるもとのデータを新しいデータで上書きする要求に応じ、その新しいデータをディスク位置Ｙに格納する。次いで、履歴状態の記録内に、ディスク位置ＸおよびＹの役割を示す標識を設定する。これらの役割は、履歴データを含むというディスク位置Ｘの役割、そして、ディスク位置Ｘの新しいデータを含むというディスク位置Ｙの役割を、規定することができる。また、この方法は、コマンドをインターセプトしてディスク位置Ｚにあるデータを解放し、履歴状態の記録内に、ディスク位置Ｚが履歴データを含むことを示す標識を設定することを含む。
【００２６】
別の１実施形態では、コンピュータディスクの以前の状態を復元するためのコンピュータプログラムを開示する。このコンピュータプログラムは、オペレーティングシステムからのファイル管理コマンドをインターセプトすることができるコードセグメントと、ディスク位置の状態を示すマップとを含む。このコンピュータプログラムはさらに、メイン領域に履歴データをマッピングする履歴表をも含む。履歴表は、オペレーティングシステムによって解放されたディスク位置も示す。履歴表の各エントリは、発生順にアクセスされることができる。このコンピュータプログラムはさらに、ディスク更新の標識を実質上発生順に履歴表に記録するコードセグメントも含む。
【００２７】
さらに別の１実施形態では、コンピュータ読み取り可能媒体の以前の状態を復元する方法を開示する。先ず、コンピュータ読み取り可能媒体への履歴変更のエントリを有したデータ構造を設定する。データ構造は、第１のデータ位置Ｘにあるもとのデータを新しいデータで上書きすることに関する書き込みエントリと、オペレーティングシステムによってデータ位置Ｚを解放することに関する解放エントリとを含む。次いで、コンピュータ読み取り可能媒体を再構築する要求に応じ、データ構造内で最新のエントリを検証する。書き込みエントリの検証に応じ、第１のデータ位置Ｘにある新しいデータをもとのデータで置き換える。さらに、解放エントリの検査に応じ、オペレーティングシステムが解放データ位置Ｚにアクセスできるようにする。すると、データ構造内で最新のエントリが廃棄され、同方法が、コンピュータ読み取り可能媒体の以前の状態が復元されるまで繰り返される。
【００２８】
以下の説明から、本発明が、コンピュータディスクの以前の状態の再構築を安全且つ発生順の制御方法で行えることが、当業者にとって明らかとなる。本発明の他の態様および利点は、本発明の原理を例示した添付の図面と関連させて行う以下の詳細な説明から明らかとなる。
【００２９】
【発明の実施の形態】
本発明は、履歴変更が追跡されるオペレーティングシステムとの関連のもとで、上書きされたディスク記憶領域を再生することを目的として開示されるものである。本発明は、オペレーティングシステムがデータを書き込む実際の格納位置を選択することを可能とする一方で、ディスクの以前の状態を再成するのに必要な古い履歴データをオペレーティングシステムから確実に保護する。本発明はまた、デフラグと、実際のディスク媒体への安全なデータの移行とを支援する。
【００３０】
以下の説明では、本発明の完全な理解を促すために多くの詳細について特定している。しかしながら本発明は、これらの詳細の一部または全てを特定しなくても実施することが可能であることは当業者に明らかである。そのほか、本発明を不必要に不明瞭化するのを避けるため、周知の処理操作の詳細な説明は省略した。
【００３１】
以下の議論をさらに明確にするため、次に、幾つかの用語、すなわちカレントディスクイメージ、シミュレートされたディスクイメージ、メイン領域、およびエキストラページ領域に関して説明する。カレントディスクイメージとは、過去のものではないディスクのビューを指し、ユーザが最後に書き込んだデータからなる。ディスク上に履歴ロギングが存在しない場合は、ディスクに現在含まれるデータがカレントイメージとなる。シミュレートされたディスクとは、ユーザおよびＯＳから完全に独立したディスクを指す。しかしながら、ＯＳより下のレベルのエンジンは、カレントイメージおよび保存された履歴データをもとに、他のことをしているときに、このディスクを作成される。
【００３２】
実際のハードディスクは、メインおよびエキストラのページからなる２つの基本領域に分割されるのが一般的である。メイン領域は、カレントイメージに属するページを保持する。エキストラのページ領域には、履歴データが保持されている。メイン領域のマップは、カレントイメージへのアクセスを転送して、エンジンによって割り当てられた位置の置き換えを可能とする。履歴マップの履歴ページ記述子は、履歴ページを管理する。メインおよびエキストラのページは、自身の領域内でまたは反対領域からのページとの間で、一時的に役割を交換することができる。したがって、通常なら履歴データを保持するエキストラページ領域に属するページに、カレントイメージの一部を一時的にマッピングしても良い。
【００３３】
「上書きデータ」という表現にも注意する必要がある。上書きデータは、物理的に上書きされたデータを意味するのではない。ファイルには、アプリケーションによって上書きされ得るデータが含まれる。しかしながら、本発明は、データのもとの状態を保存することに関するものである。これは、物理的に上書きされる前にデータをコピーする（移動させる）か、または書き込みの宛先を変更して本当に上書きされるのを回避することによって達成される。したがって、「上書きデータ」という表現は、ＯＳによる上書きに先だって存在するファイルのデータであって、履歴データとしてエンジンに保持されているデータを意味する。
【００３４】
ディスク管理の責務は、オペレーティングシステムからファイリングシステム（例えばウィンドウズＮＴのＮＴＦＳ）へと分離され得る。本明細書の目的に沿って、ＯＳに言及する際は、ディスク管理に伴うあらゆる他のサブシステムを含むものとする。
【００３５】
エンジンという用語は、目下議論中の方法を実現するためのロジックを意味する。種々の方法が議論され、それぞれの方法は独自のエンジンを有する。
【００３６】
「エキストラページ領域」の「エキストラ」という用語は、概念的に、ユーザから可視でないものがエキストラであるという思想に基づく。ディスクは、物理的に所定の容量を有する。しかしながら、ディスクのなかには、保留されてユーザから隠されている領域がある。このため、ＯＳによって報告される、ユーザにとって可視のディスクサイズ（メイン領域）は、そのディスクの真のサイズよりも小さい。したがって、ユーザにとって可視でない記憶領域が「エキストラ」であり、エンジンが利用するものである。
【００３７】
ＯＳは、その制御下にある種々の構造（例えばファイル）にディスク位置を割り当てる。しかしながら、エンジンのなかには、ＯＳのディスク位置を他の位置に再マッピングするものもあるため、ＯＳに関連した「ディスク位置」とエンジンに関連した「ディスク位置」とを区別するために、ＯＳのディスク位置を位置キーと呼ぶ。
【００３８】
本発明は、上書きデータのもとの状態を保持するための３つの方法、すなわちＴｅｍｐ、Ａｌｗａｙｓ、Ｆｉｌｅ方法を改良するものである。Ｔｅｍｐ方法およびＡｌｗａｙｓ方法では、所定の時点におけるディスクのもとの状態をオペレーティングシステム（ＯＳ）およびアプリケーション（例えばゲーム）から保護する機構（エンジン）は隔離されている。ここで、保護された「状態」は、エンジンを介してＯＳによってビューされるものであり、エンジンは、ＯＳによる関連ディスク領域へのデータの割り当てを再マッピングまたは管理する。保護機構がＯＳにおけるバグまたは望ましくないディスク書き込み動作に影響されないため、このような隔離によって信頼性を向上させることができる。
【００３９】
また、エンジンの隔離は、保護メカニズムがハードウェアにマイグレーションすることも可能とする。すでに議論したように、ハードウェアへのマイグレーションは、例えばＣＰＵ、ディスクインターフェース、および／またはハードディスクコントローラへの、保護エレメント（ロジック）の組み込みを含むことができる。
【００４０】
一般に、ＯＳによる記憶領域の割り当ておよび解放をエンジンによるそれと密接に協調させて、冗長または余分な工程を低減または排除することが望ましい。このような余分な工程（オーバヘッド）は、エンジンをＯＳから隔離したいという要求が原因で導入されるものである。換言すると、エンジンは、ＯＳとの信頼できない関係を想定していることがある。つまり、ＯＳが、自身がアクセス可能なあらゆるデータを破壊するように作動する可能性があることを想定している。Ｔｅｍｐ方法は、ディスク上のＯＳのデータ編成を維持するように努めているため、データを実際のディスク位置に割り当てるのに際しての、ＯＳとエンジンとの協調はほとんどない。
【００４１】
Ａｌｗａｙｓ方法では、エンジンへの割り当て解除の情報の提供を含む、より密接な関係を使用する。Ａｌｗａｙｓ方法を実装するエンジンは、一般に、この情報およびその他の情報を使用して、データを移動させる必要を回避することにより、所定のディスク位置（ファイル）におけるもとの内容を保存または最適化する。換言すると、ＯＳが新しいデータを書き込む場合、ディスク上に最初に割り当てられた位置は、（Ｔｅｍｐ方法の場合と比べて）かなり永続的である。
【００４２】
本発明は、Ｔｅｍｐ、Ａｌｗａｙｓ、およびＦｉｌｅ方法の変形例を詳細化しており、ＯＳは、データを書き込む実際の格納位置の選択において、より重要な役割を果たす。しかしながら、本発明は同時にまた、ディスクの以前の状態を再現するのに必要な古い履歴データを、ＯＳから確実に保護する。このため、エンジンロジックの一部分は、オペレーティングシステムに対する多少とも標準的な動作か、または増補動作によって処理される。本発明はまた、デフラグ処理と、ディスクの実際の媒体へのデータの安全な推移とを支援する。
【００４３】
本発明の方法は、ＯＳとエンジンの間における、割り当て情報および割り当て解除情報の交換に基づくものである。しかしながら本発明では、特定の方法をディテイルする。そうすることによって、あるファイルから別のファイルへの記憶領域の再関連付け（ファイルの名前変更）と、記憶領域の解放（ファイルの削除）と、を行うためのＯＳ機構は、方法と組み合わされ、これらの動作がエンジンの復元能力に害を及ぼさないようにされる。
【００４４】
本発明は一般に、データに対する少なくとも最終的なディスク上の位置はどこであるかをＯＳが決めることを可能とする。このためファイルシステムは、少なくとも最終的には、エンジンがデータを実際に配置したディスク位置にファイルを直接マッピングして、これ以上の再マッピングを不要とする。
【００４５】
本発明の１実施形態を、ＡＴＦ方法（Ａｌｗａｙｓ、Ｔｅｍｐ、およびＦｉｌｅの３つの方法を組み合わせたもの）と呼ぶことにする。ＡＴＦ方法では、ＯＳが新しいデータの大部分に対して、スワッピングが不要となるように、最終的なディスク位置を選出できるようにして、スワップされなければならないデータの量の低減を図る。この方法はまた、デフラグ処理を分離することによって、ＯＳまたは別のユーティリティが、提供されたエンジンへのインターフェースを使用して、動作を実行できるようにする。
【００４６】
本発明では、ＯＳとエンジン（ＡＴＦ方法）との間にインターフェースを追加することによって、未割り当ての（「真に未使用である」）ＯＳディスク位置に関する通知をはじめにエンジンが受け取るようにする。ここでは、特定の位置が真に未使用であることをエンジンに通知することによって、エンジンがこれらの位置を効果的にゼロ化することができる、というルールが成り立つ。ここで注意する必要があるのは、エンジンはこれらの位置に実際にデータを格納し得るものの、ＯＳがこれらの位置のどれかを読み出そうと試みると、エンジンからはゼロデータが戻されるという点である。この後者の工程は、エンジンによる内部目的のために使用される、履歴データを含む領域にＯＳがアクセスするのを防ぐものである（このため同データに一定レベルのセキュリティを提供する）。
【００４７】
ＯＳが、使用中のディスク位置への書き込みを行うと、エンジンは、Ｔｅｍｐ方法に従って書き込みの宛先を変更して、その後、新しいデータと履歴データとをスワップする。オペレーティングシステムが、記憶領域が真に未使用であることをフラグする（後ほど簡単に説明する）と、フラグされたページは、（セキュリティのために）少なくとも実効的にゼロ化される。ＯＳが、真に未使用であることをフラグされた位置に書き込みを行う場合、データは、エンジンによって直接その場所に書き込まれる。したがって、エンジンは、ＯＳによって真に未使用であるとフラグされた場所を示したマップを保持する。
【００４８】
ＡＴＦ方法は、アクティブ（メイン領域）を含むデータから履歴（エキストラページ）を含むデータへのＯＳディスク位置の移行が、ＯＳまたは拡張ＯＳのいずれに移動したかをＦｉｌｅ方法から取得する。拡張ＯＳは、標準ＯＳに補足コードを組み合わせることによって、エンジンが必要とする動作を実現するものであり、ＯＳに既存のものではない。記憶領域は、基本的に、オペレーティングシステムによって解放されるのに伴って「ほとんど未使用」の状態に移行する。この状態は、以下の点において「真に未使用」な状態とは異なる。すなわち、その記憶領域は、オペレーティングシステムによって正式に解放されているものの、その内容は以前の状態の回復に使用される可能性に備えて維持されて、経年処理を経てほとんど未使用から真に未使用な状態に移行する。換言すると、ほとんど未使用な記憶領域は、単なる古い履歴データである。このような記憶領域は、エンジンとの関連において履歴データ（ＯＳによって上書きされてエンジンによって保存されているディスク位置）と呼ばれる。本発明では、ＯＳがこの記憶領域を認識しているため、この記憶領域は、ＯＳとの関連においてほとんど未使用な記憶領域と呼ばれる。
【００４９】
ディスクおよびファイルは、ＯＳを通常に使用している最中に様々な形で変更される。ファイルは、部分的に（例えば途中の数バイトを）上書きされることができる。新しいファイルを形成したり、ファイルを削除したりすることもできる。既存ファイルの内容を廃棄して新しいデータで置き換えたり（削除と作成の組み合わせ）、ファイルを切りつめたり（ファイルのうち特定の点以降のデータを全て廃棄する）することもできる。ＯＳは、多種類の動作を支援することができる。ユーザに可視のファイルに関連していないディスクデータは、ＯＳのファイル管理に関連しているのが通常である。例として、特定のディスク位置を特定のファイルに関連付ける表が挙げられる。このような情報は、すでに言及したように、少なくとも概念的には特別な内部ＯＳファイルと見なされることができる。本発明の課題の１つは、（ＯＳによってビューされる）早い時間におけるディスクの内容を再現する方法を提供することにある。
【００５０】
ＡＴＦ方法は、ディスクの一般的な変更の保存を、Ｔｅｍｐ方法に類似の方法を使用して処理する。しかしながら、ＡＴＦ方法は、「削除」された記憶領域、すなわちその内容はもう不要であるが回復での使用の可能性に備えてエンジンで追跡する必要があるような記憶領域を、ＯＳに通知する。
【００５１】
一般に、容易にインターセプトされ調整されて、少なくともいくらかの割り当て解除をキャッチすることができる動作は２つある。すなわち、ファイル削除の動作と、ファイル内容の廃棄および置き換えの動作である。いずれの場合も、少なくとも部分的に、動作を、例えばファイル名の変更に変換することにより、解放された記憶領域の保存が行われる。記憶領域は、単に保存されるのではなく記憶領域のブロックとして保存され、ＯＳにおける通常の自由（利用可能）なディスク記憶領域トラッキングによりマッピングされ続けるため、再使用されることはない。
【００５２】
任意ファイルの中間の修正（上書き）など、ファイル名の変更技術（またはそれに同等な技術）で処理されない動作が多く存在する。さらに、ＯＳの内部データの修正も存在する。ＡＴＦ方法は、もとの状態の追跡を目的として、特定の割り当て解除動作上につきＯＳと協調するが、カバーされないその他全ての動作に対しては、Ｔｅｍｐ方法を使用して処理を行う。本発明は、スワッピングを低減する方法の詳細を詳述し、記憶領域の少なくとも最終的なディスク位置を一般的に割り当てる際のＯＳの役割を保存し、隔離（例えばファイアウォール）により全体的な復元能力を保護する。
【００５３】
ＡＴＦ方法では、ＯＳが記憶領域のブロックを解放すると、同ブロックは自由プールに返される代わりに、ほとんど未使用な部類に分類されてラベル付けされ、エンジンが同ブロックの解放に関する通知を受ける。実際のこの処理は、標準ＯＳをファイル名の変更に拡張することによって、ファイルの記憶領域が解放される直前に達成され得る。エンジンは、このほとんど未使用な記憶領域に関連付けられたディスクの割り当てを通知されるため、エンジンは、その記憶領域をどんなさらなる警告（alerting）からも保護することができる。この保護は、ほとんど未使用な記憶領域がＯＳによって修正されうる形態を採るが、エンジンは、ほとんど未使用な記憶領域のもとの状態を追跡する手段を採る。つまり、Ｔｅｍｐ方法が実装されているのに関わらず、エンジンも、ほとんど未使用な記憶領域の位置を（その位置がＯＳによってどのようにラベル付けされているか、ということと共に）通知される。
【００５４】
好都合なことに、ＯＳのビューにおいて、ほとんど未使用な記憶領域は除かれているので、上述の動作によって、ＯＳは、一般にほとんど未使用な記憶領域を再使用しないこととなる。これは、ＯＳがほとんど未使用な記憶領域に上書きしない限り、Ｔｅｍｐ方法が宛先を変更して、その後、新しい状態と以前の状態とをスワップする必要はないことを意味する。
【００５５】
ほとんど未使用な記憶領域は、エンジン内の一般的な履歴データと共に経年処理を経て、真に未使用な記憶領域に移行する。これは、エンジンの制御のもとで行われるのが一般的である。この処理は、Ａｌｗａｙｓ方法の一般的なアウトラインに従う。Ａｌｗａｙｓ方法においては、記憶領域のブロックは、メインＯＳイメージの一部分である状態（ＭＡＩＮブロック）から履歴データである状態（ＥＸＴＲブロック）を経て新しいデータを受信できる状態（ＣＴＭＡブロック）に到達する。ＡＴＦ方法においては、一般的なＴｅｍｐ方法機構に加えて、記憶領域のブロックは、ファイルに関連付けられた状態からほとんど未使用な記憶領域に関連付けられた状態（履歴データを保存している）を経て再び再使用が可能な状態（自由ディスクプール内にある）へと移行する。ＡＴＦ方法における「ブロック」は、一般に、解放されたファイル全体を指す。Ａｌｗａｙｓ方法がある程度の組み込みデフラグを含む一方で、ＡＴＦ方法はデフラグをより外部の処理に格下げする（つまりＡＴＦ方法は、ＯＳまたはユーティリティがディスクの記憶領域の再整理を指示することを可能とする）。
【００５６】
ＡＴＦ方法のもとでの「ブロック」サイズに関して興味深い点は、ほとんど未使用な記憶領域のブロックをファイルと関連付けると、そのブロックのサイズが劇的に変動し得るという点である。つまり、ユーザが削除したのは巨大なファイルかもしれないし小さいファイルかもしれない。したがって、ほとんど未使用な記憶領域が真に未使用な記憶領域に移行するのに伴って、ＯＳの自由プールに戻される記憶領域の量は、かなりの量かもしれない。初めは、履歴データを追跡する記憶領域をもっと徐々に移行させてＯＳの自由プールに戻し、本当に必要なときまで履歴データを解放しない方が良いように思える。
【００５７】
しかしながら、複数のファイルであったものに複数のブロックが対応する場合、履歴ファイルの内容の半分を保持して、一方で、もう半分の再利用を許可することは、データ復元の観点から見て意味をなさない。したがって、古い履歴データのブロック全体が使用のために必要とされている限り、大きな記憶領域のブロックをＯＳの自由プールに返し、そのために古い履歴データを追跡するというこれらブロックの以前の役割を断念しても、何ら問題は生じない。履歴データの追跡に使用される記憶領域が複数の安全点（safe point）に対応する複数のブロック単位で解放され得るＡｌｗａｙｓ方法に関しても、同様な一般的観測がなされる。これは、所定の安全ポイントに対応する履歴データの部分集合が、どの回復目的にも使用できないと考えられるためである。
【００５８】
ＡＴＦ方法の詳細は２つの工程で表される。第１の工程は、Ｎｅｗ Ｔｅｍｐ方法によるもので、同方法からの進行を示すとともに一定事項を強調することを意図するものである。さらに、異なる実装を使用したＡＴＦ方法が、第２の工程として表される。第２の工程は、第１の工程の設計における問題点を解決するものであり、しかし、前述した方法のデータ構造からのさらなるジャンプであると言える。
【００５９】
Ｎｅｗ Ｔｅｍｐ方法では、エンジンは、ＯＳによって一般にアクセス可能なメイン領域ページに加えて、比較的単純なデータ構造を有しエキストラページに対応した履歴ヘッダを保持している。ＡＴＦ方法は、２つの追加のデータ構造を追加する。すなわち、ほとんど未使用なＯＳ位置（ＡＵＯＳ／almost unused OS locations）にあるブロックの発生順の円形表と、どのメイン領域ページが真に未使用またはほとんど未使用である（ＴＵＵＮ／truly unused or almost unused）かを示すマップの２つである。ＡＵＯＳ表の各ブロックに対し、そのブロックをＯＳ内で識別する方法が格納される（例えばファイル名）。また、そのブロックがいつ作成されたかを示す履歴ヘッダへのリンクも格納されており、それによって、そのブロックを履歴ヘッダの全時間追跡機構にリンクさせる。代表的なＡＵＯＳ表エントリを表１に示した。
【００６０】
【表１】
【００６１】
ＯＳが、ファイルに関連付けられた活動状態からほとんど未使用な状態へと記憶領域を移行させるのに伴って、ＡＵＯＳ表の一端にブロックが追加され、ＴＵＵＮマップが、現在はほとんど未使用な状態にある新しいディスク位置を示すように更新される。ＯＳが利用可能な空きスペースを充分な量だけ確保する必要があるため、ブロックは表の他端から取り出される。関連付けられた記憶領域がＯＳによる再使用に提供されて、ＴＵＵＮマップが更新される（ほとんど未使用なディスク位置が真に未使用となる）。名前変更の動作を使用して履歴データを破棄した場合、ＯＳは、削除動作を使用してその記憶領域を自身による再使用に供するのが通常である。ディスク位置が真に未使用であることを示すＴＵＵＮ状態によって、エンジンが通常の転用処理およびスワップ処理を回避することが可能となる。
【００６２】
ＴＵＵＮマップは、ほとんど未使用な状態のディスク位置を追跡することにより、エンジンが、このような記憶領域に対するＯＳ読み出し要求をキャッチして、実際の内容の代わりにゼロデータを返すことを可能とする。こうするには２つの理由がある。先ず第１に、ほとんど未使用な記憶領域は、履歴データを含むため一般的なセキュリティ問題を伴う。ユーザは、自分のディスクの以前の状態に容易にアクセスできることを望まないかもしれない。セキュリティは、前掲したようにこのようなアクセスをエンジンでインターセプトするか、またはＯＳセキュリティ機構を使用する（ファイルをアクセスからロックしたり、ファイルの属性ビットを設定したり等など）ことによって、実現することができる。しかしながら、エンジン全般の目的は、ユーザがそのディスクの以前の状態にアクセスできることを保証することであることに、注意が必要である。
【００６３】
このセキュリティ問題は、それほど重要な関心事ではない。最も重要なのは、ディスクの以前の状態にアクセスできることを保証するという概念である。ユーザ（ＯＳ）が、あたかも通常のディスクイメージの一部であるかのように履歴データにアクセスできるようにすることには、履歴データがメインイメージの一部になるという問題点が伴う。このため、ＯＳ上で実行されるアプリケーションが、履歴データを利用することが可能となって、履歴データにより容易に依存するようになる。このような状態が生じ、データが通常の経年処理の一部として解放されると、ディスク全体を時間的に復帰させることが不可能となる。つまり、ＯＳが履歴データを直接参照できると、時間を遡るというコンセプトが弱体化してしまう。
【００６４】
エンジンが提供する機構は、履歴データをメインイメージから明確に区別するのが一般的である。つまり、ユーザは、メインドライブではなく仮想のドライブを介して以前の状態にアクセスし、特別なアプリケーションを介して上書きバージョンまたは削除バージョンのファイルにアクセスする（を引き出す）。したがって、履歴データとディスクの現行のメインイメージとが合理的に区別される。ここで、ほとんど未使用なデータを保持している名前変更されたファイルの使用によって、特別なアプリケーションを履歴データに直接アクセスできるようにすることが可能であることに、注意が必要である。このためには、エンジン（またはＯＳ）と協調してデータの通常保護（例えばゼロ化）を無効とする必要がある。
【００６５】
重要なのは、アプリケーションが、ＯＳによって管理されユーザが利用可能な「通常」ファイルに単純にアクセスするのではなく、エンジン／ＯＳの履歴追跡からファイル（データ）を「抽出する」ためには、特別なアプリケーションが必要であるということである。
【００６６】
しかしながら、ほとんど未使用だとフラグされたディスク位置をＯＳで読み出す際に、エンジンがリターンデータを一般にゼロ化することには、最も重要な理由が存在する。この理由は、メインイメージと履歴データとを明確に区別することが何故重要なのかに関する前述の議論にある。履歴データとメインイメージとの混合が可能となると、そこに僅かな相互依存を生じるため、履歴データを実際に解放した際には、その相互依存が全て切断されることになる。ここで、履歴データの解放が永続的で不可逆性であることに、留意する必要がある。履歴データを追跡するのは、定義によってある程度の可逆性をユーザに提供するため、つまり、一定期間中に幾らかのデータを取り戻せるようにするためである。ユーザが不可逆性の動作により深く関わるようになると、エンジンの目的が部分的に弱まってしまう。
【００６７】
以下に挙げる実施例は、メインイメージとの関連でＯＳによってなされる一般アクセスからゼロの履歴データを戻し、または履歴データを隠すことの、重要な理由の１つを示している。すなわち、大量のデータを永久に消去するダイアログにおいて、ユーザは意識的または無意識にＯＫをクリックする。まさにこの状況において、エンジンは、ある程度の可逆性を提供することを期待される。履歴追跡システムがＯＳのトップに実装されていると、履歴データを含んだファイルをＯＳが失う結果をもたらす動作またはバグは、致命的なものとなる。
【００６８】
しかしながら、ＡＴＦ方法は、それ自身ＯＳの複雑性から隔離されているのが一般的である。ここで、大量のディスク記憶領域がほとんど未使用であることをエンジンに合図したプログラム（またはウィルス）に対し、ユーザがＯＫをクリックした場合を考える。ただし、この通信はＯＳに対してなされたのではないため、影響を受けた記憶領域は、依然としてＯＳによるアクセスが可能である。ＯＳがデータにアクセスしてエンジンがそれをゼロ化しなかった場合は、ユーザから見ると、そのディスクの内容に問題はないように思える。しかしながら、少なくともエンジンから見ると、ユーザは、メインイメージの一部としての履歴データに知らずにアクセスしていることになる。後になって、エンジンがこの履歴データを解放して再使用すると、ディスクのメインイメージであったものが、突然且つ不可逆的に変化する。さらに、エンジンを使用して時間を遡っても、ユーザやＯＳが表示するメインイメージは再現されない。
【００６９】
一方で、ＯＳによる読み出しの際に履歴データを強制的にゼロ化すると、時間を遡る際に、メインイメージが整合性を保って完全に復元される。履歴データとメインイメージデータの相互依存は、合理的に回避される。このため、上述した筋書きでは、ユーザがＯＫをクリックし、データの多くがほとんど未使用（履歴）であることをフラグされると、そのデータが有効にゼロ化される。したがって、ユーザは、自身のアクションが引き起こす実際の結果を直ちに経験し、そのアクションをエンジンによって取り消すことができる。つまり、エンジンが提供する履歴経年処理によって失われたデータを検索するために、ユーザがメインディスクを介してデータの「損失」を実際に経験する、ということが非常に重要である。
【００７０】
したがって、ほとんど未使用な記憶領域をエンジンに通知するＯＳのアクションが、ＯＳが後に読み出そうとするデータをエンジンによって有効にゼロ化することを、必ず伴うことが推奨される。ここで、ほとんど未使用な記憶領域の履歴内容が、実際にはゼロに設定されないことに注意する必要がある。履歴データにアクセスする方法は、特別なアプリケーションを介して許容可能である。
【００７１】
例えばアプリケーションは、エンジンおよびＯＳによって管理されるデータを利用して、ディスクの以前の状態を再構築したり特定のファイルを検索したりする。この筋書きは、ほとんど未使用なものとして記憶領域を保存するのに使用されているファイルの、ゼロ化されていない実際の内容に、特別なアプリケーションを介してアクセスすることを単純に許可することによって、特定のファイルを復旧することを含む。より厳密に言うと、特定ファイルの以前の状態にアクセスするこの方法は、ＯＳで管理されているように、この状態を保持しているファイルの内容へのアクセスを許可することを含む。この方法は、ディスク全体を、望ましいファイルの検索元の仮想ドライブとして有効に再構築するアプローチと異なり、それを簡略化したものである。ＯＳがほとんど未使用の記憶領域に突然上書きしてしまった、すなわちＯＳが自身の履歴追跡を破壊してしまったことをエンジンが検出した場合は、一般に、この簡略化された方法を採用するべきでない。しかしながら、エンジンは依然として、Ｔｅｍｐ方法を介して以前のディスク状態へのアクセスを提供することができる。
【００７２】
ここで、ＯＳが、ほとんど未使用な記憶領域を直ちにエンジンに通知することを望まなかったりできなかったりする可能性があることに、注意する必要がある。ＯＳは、アプリケーションによって解放されると同時に記憶領域を収集して、関連付けられたディスク位置および他の情報とともに、後ほどエンジンに引き渡すことを選択しても良い。
【００７３】
次に示した表２は、ＯＳおよびエンジンによる関連処理の概略を示したものである。
【００７４】
【表２】
【００７５】
ＡＴＦ方法の的確な特徴の１つは、ほとんどおよび真に未使用な記憶領域の追跡に関連してＯＳとエンジンとが非同期であっても、一般に何の悪影響も及ぼさないということである。次に示した表３および表４は、同期条件からの種々の出力およびその結果を示したものである。ここで、情報を「失う」という表現が、その情報が単にＯＳとエンジンの間で上手く転送されないことを暗示していることに、注意する必要がある。これには、その情報が、全く上手く転送されず、ディスクへの不完全な状態／データフラッシュの一部として失われた場合を含む。
【００７６】
【表３】
【００７７】
【表４】
【００７８】
次に示した表５および表６は、記憶領域を分類することができる３つの状態、およびこれらが各状態から別の状態へとどのように移行するかを示したものである。
【００７９】
【表５】
【００８０】
【表６】
【００８１】
ＴＵＵＮマップは、メイン領域マップの一部として実装されることができる。換言すると、ＯＳがディスクにアクセスするのに伴って指定位置をメイン領域マップに通すのは、保留中の宛先変更があるかを見るためだけでなく、ほとんどまたは真に未使用な記憶領域がアクセスされているかを見るためでもある。しかしながら、メイン領域マップが破損される可能性があり、そうすると再構築が必要となるため、ＴＵＵＮマップの再構築もまた必要となる。ＡＴＦの設計では（第２の工程で）手短に宛名を変更できるため、当座はＴＵＵＮマップの再構築の問題を無視することにする。ただし、真に未使用な場合に真に未使用でないとするような、誤った位置分類の原因となる最新の情報損失は、無害であるのが一般的であり、転用が不要な場合に書き込みを転用させる結果をもたらす。
【００８２】
許されないのは、ユーザ（ＯＳ）が、真に未使用な位置ＬＬに何らかのデータＤＤを書き込めることである。すると、この位置が真に未使用な状態から移行するが、この移行はなんらかの故障が原因で破損される。ＬＬの内容をＤＤに変更することが許可され、ＯＳでこの新しい値を読み出すことができる一方で、エンジンが真に未使用であるとフラグされた位置を依然として有していると、望ましくない状況が生じる。問題は、ユーザがこの新しいデータＤＤ（重要なファイルである）の存在に依存するようになるのに関わらず、後になってＯＳが再び位置ＬＬへの書き込みを行うと、エンジンがその書き込みを直接通すために、データＤＤが上書きされて永久に失われることである。解決策の１つは、すでに議論したように、エンジンによって真に未使用であることをフラグされた位置全てに対してゼロデータを戻すように強制することである。したがって、この場合、真に未使用な状態が破損されるとデータＤＤもまた破損されるため、ユーザが、データが存在していて安全である（もし上書きされたならば追跡されている）と誤解することはない。
【００８３】
エンジンが、真に未使用な状態からメイン領域の状態にランダムに破損されることは考えられないが、クラッシュ時に、一連の書き込みの末端が廃棄される可能性はある。つまり、真に未使用な位置のなかには新しいデータで上書きされるものもあるが、ディスク上のＴＵＵＮマップが更新されるまでは、コンピュータがクラッシュした際にエンジンが復元するのは、安定ではあるがＴＵＵＮマップの更新以前の状態である。したがって、新しいデータがディスクに書き込まれたものの、エンジンにその移行を記録する時間がなかったため、コンピュータは、あたかも新しいデータがディスク上に書き込まれなかったかのように復元される。
【００８４】
ほとんどおよび真に未使用なビットが、幅広い範囲のディスク位置に跨って変動する（変化する）ことから、ＴＵＵＮマップは、ビットマップとして実装されることが好ましい。コンピュータが納品された最初の時点では、ディスクの大部分が真に未使用な状態である。しかしながら、データがロードされて更新されるのに伴って、幅広い範囲に跨る多数のビットが変更される。したがって、マップはまばらであるとは考えにくい。ある状態から別の状態への安全な移行と、ＴＵＵＮマップの耐障害性とを考慮すると、何らかの形の円形表を追加することが推奨される。真に未使用な位置が、上書きされてメイン領域の位置に移行すると、ＴＵＵＮマップが更新されて、対応のエントリが新しい円形表に加えられる。この新しい円形表への追加は、ＡＵＯＳ表とともに、あらゆる更新の後に比較的高速でディスクへとフラッシュされる。一方のＴＵＵＮマップは、クラッシュ時に再構築できると想定されるため、システムのシャットダウン時にのみフラッシュされる。これによって、更新且つキャッシュされたＴＵＵＮマップページを数多く生じる頻繁なフラッシュが回避される。
【００８５】
上述したように、現在のディスクドライブには、性能向上を目的とした書き込みキャッシュが含まれるのが通常である。これらの書き込みキャッシュは、書き込みを一時記憶領域に入れて、書き込みと異なる順序でデータをディスク媒体に引き渡す。この処理は、例えばディスクコントローラを、ディスクヘッドの動きを低減する順序で実際のデータ書き込みを行えるようにすることによって、書き込み処理全体を高速化することができる。しかしながら、ＴＵＵＮマップや履歴ヘッダデータなどの内部のバックアップデータは、ディスク上にすでに存在すると想定されるデータ（依然として書き込みを待機中）より前に、ディスク上で更新され得る。電源異常が発生すると、ある安定な状態から別の状態への安全な移行が不可能となってしまう。
【００８６】
エンジンに書き込みキャッシュのフラッシュ制御能力がないことを想定すると、キャッシュによって、クラッシュ時に難しい問題が提起される。例えば電源異常によって、書き込みキャッシュの一部が永遠にディスク上に書き込まれなくなるかもしれない。エンジンの問題点は、ディスクに書き込まれたデータと書き込まれなかったデータが存在する場合に、書き込みキャッシュ側の要因によって、エンジンがデータを書き込んだ順番とデータがディスクに到達した順番とが対応しないということにある。したがって、エンジンがディスク位置１，２，３への書き込みを行った後にクラッシュしたとすると、位置１，３は更新されたが位置２は更新されなかったという事態が生じ得る。
【００８７】
部分的に失われてもなお完全に有用なデータ構造はほとんどないため、本発明では、ディスクに書き込まれるデータ保全性を確実にする手段として経年処理を使用する。書き込みキャッシュのアルゴリズムは、一般に、ディスクへのデータのコミットが無制限に先送りされる（hold off）ことはないことを想定している。これは、コンスタントな読み出しおよび書き込み活動を行う場合であっても同様であると想定される。そうでないと、書き込みに「最適な」時間を待機するデータが書き込みキャッシュ内に詰まり、朝書き込まれたデータが数時間後になってもディスク媒体に到達しない事態が考えられる。本発明は、ディスクコントローラにページを書き込むに当たり、一定の最小時間（待ち時間）の経過後にはそのページがディスク媒体に実際に書き込まれる（そして、クラッシュ時には不揮発性の記憶領域に保存される）ことを想定して構築されている。
【００８８】
したがって、本発明は、過去の最小待ち時間内にデータがディスクコントローラに書き込まれた場合にのみデータの経年処理を使用し、回復（システム再始動）との関連でデータをトラステッドにする。ディスクコントローラに書き込まれたデータブロックには、何らかの形態の時刻スタンプまたは時刻点が含まれることができる。ここで、１つのブロックは複数のディスクページからなる。最小待ち時間後に書き込まれた続く時刻スタンプまたは時刻点が発見された場合、ブロックは、ディスク媒体に完全に転送されたと想定される。時刻スタンプは、ブロックの読み出しに直接対応する値である。２つの時刻スタンプを比較することにより、表された時間間隔の長さを決定することが可能となる。これに対して時刻点は、前の時刻点から待ち時間分が経過したことを単純に示すものである。
【００８９】
ディスクコントローラにどれだけの量のデータが転送されたかを監視することにより、待ち時間を概算することができる。ディスクコントローラへの転送速度が周知であるため、この転送速度を待ち時間で掛けて、所定ページの書き込み後に転送されるべきデータの量を算出し、このページが確かにディスク媒体に書き込まれたことを保証することができる。これは、転送が連続して行われることを想定している。
【００９０】
事前に書き込まれたデータが、適切な待ち時間の経過後にディスクに実際に到達するという仮定は、特定のディスクコントローラには当てはまらない。このような場合は、代替の方法が使用される。ここで、エンジンは、所定の書き込み以降、ディスクコントローラがその書き込みキャッシュをディスクにフラッシュするのに十分な「自由時間」があったことを保証するものである。エンジンは、ディスクコントローラへの平均転送回数をモニタすることができる。この平均転送回数は、既知または概算の最大転送速度（ディスク媒体で実際にデータの読み出しまたは書き込みを行える速度を反映している）と比較されて、書き込みキャッシュがフラッシュされていることが妥当か否かが決定される。フラッシュが必要である場合は、充分な量の自由時間が引き渡され、エンジンは単純に遅延（または、ディスク活動の突然の休止を回避するための一連の短い遅延）を挿入することができる。最悪の場合は、ドライブの転送速度を、非常に大きい（どんな適度なキャッシュサイズよりも遥かに大きい）データブロックの読み出しおよび書き込みを行うタイミング調整プログラムから推察することができる。ここで、転送の回数、相対的な接近性、およびサイズが全体の転送速度にそれぞれ個別に影響を及ぼすことから、ドライブの転送速度の計算でこれらの各要素を考慮するべきであることに、注意する必要がある。つまり、ディスクヘッドを物理的に動かすまでの各転送の開始に関連付けられた時間と、ディスク媒体に実際にデータを転送するのにかかる一定の時間とが存在する。
【００９１】
ディスクコントローラのキャッシュをフラッシュする自由時間方法への類似点は、キャッシュをコップで水を加えるバケツに譬えられることである。バケツの底には穴が１つ空いており、一定速度での排水を可能としている。穴から流出する水は、ディスク媒体にデータを書き込むディスクコントローラと同等である。コップで水を加える処理は、ディスクコントローラにデータを書き込む動作と同等である。もしバケツが満杯であれば、待機する必要がある。ディスクコントローラからのデータの読み出しは、穴を一時的に塞ぐことと同等であり、何も排出されたり追加されたりしないまま、時間だけが経過する（読み出しキャッシュは書き込みキャッシュから独立していると仮定する）。ここで、書き込みキャッシュをフラッシュする状況は、バケツに加えられた一杯の水が排出されたかを刻々と保証する必要がある状況と非常に似通っているが、実際にバケツの中をのぞいたり、バケツがまだ排水しているかを検知したりすることはできない。さらに、水を１カップ分だけバケツに加えると、この水は、続けて加えられる水とも前に加えられた水とも混合する。
【００９２】
問題の水が本当に排出されたかを知る唯一の方法は、水を加えた後のある時点において、バケツが一時的に完全に排水されるようにすることである。バケツの中身を見たり、まだ排水中かを知ったりすることができないため、これをいつどのように実施するかは難しいところである。つまり、キャッシュがフラッシュされたかをディスクコントローラに尋ねる現行の標準インターフェースは存在しない。解決策の１つとして、水がバケツから排出される最悪の場合の速度を決定することが挙げられる。これは、バケツが満杯になって待機を強制されるまで、可能な限り高速で水を加え続けるという試験を行うことによって達成される。この時点以降は、バケツに余裕ができる（次のカップを受け付る）たびに水を加え続け、その速度を測定すれば良い。この処理によって、バケツの「緩衝」効果を効果的に無効とすることができ、実際の排出速度（またはディスクコントローラがキャッシュを空にする速度）が測定される。
【００９３】
バケツの排水速度がわかれば、水を加える速度をモニタすることができる。加えた水を確実に排出したい場合は、新しい水を加えるよりバケツの排水の方が速くなるように、次に水を加える速度を遅くする必要がある。算出可能なある時点では、ゆっくりであるにもせよ水を加え続けているのにも関わらず、バケツが完全に排水される。もちろん、さらに１カップ分の水を加える前にバケツを直ちに確実に排水させたい場合は、単にバケツの排水に必要な算出時間分だけ待機することができる。事実、バケツに水を加える速度を連続的にモニタすることにより、排出が必要な水を加えた時点でバケツがどのくらい満杯だったかを、ある程度把握することができる。これによって、遅延の低減が可能となる。もちろん、近似を行うこの環境では、遊びをたくさん設ける必要がある（例えば、完全に排水するのに１秒間必要だと考えるならば、２秒間待機して、計算で生じる僅かな誤差を全てカバーする）。
【００９４】
このバケツへの譬えは、書き込みキャッシュをフラッシュする自由時間方法を表している。ここで、バケツが空になる速度は、書き込みキャッシュがフラッシュされる速度に等しくて、シーク時間および転送速度の関数であることに、注意する必要がある。したがって、書き込みキャッシュにおけるデータのディスク接近性（disk proximity）、すなわちディスク上で書き込まれるべき位置は、キャッシュのフラッシュに必要な時間に大きく影響する。つまり、ディスク媒体上の１領域にたくさんのデータを書き込むのに必要な時間は、媒体全体に渡って少しずつ書き込むのに比べて遥かに短くてすむ。しかしながら、最悪の場合のフラッシュ速度として計時および使用できるのは後者の場合であるので、一般的な実際の速度を認める方がずっと良い。ディスクコントローラによって最初にキャッシュから書き込まれるデータがどれかを推測することができないため、ディスクコントローラに書き込まれたページ位置をモニタして、シーク時間対転送時間の比を予測し、現行の予測フラッシュ速度を動的に生成することは不可能である。
【００９５】
再びディスクコントローラの件に戻り、次に問題となるのは、書き込みキャッシュのフラッシュを確実にするにはいつ遅延を挿入するか、ということである。書き込みの転用を行う工程がある。ユーザは一般に、ディスクの活動が一時休止する時点（安全点）を選択してアクセスすることしかできない。こうして、変更処理中の過去の時点からデータにアクセスすることが回避される。したがって、一時休止が充分に長い限り、書き込みキャッシュのフラッシュは安全点の識別に固有である。クラッシュ後にコンピュータを再起動する際に、ユーザは、安全点である過去の時点に復帰したり、単にクラッシュ直前の状態でディスクを使用したりする選択肢を有する。後者の場合、エンジンは、ディスク活動が一時休止をしていない時点までデータ構造を回復させる。つまり、クラッシュが、一連の長いディスク活動の中間で生じた場合である。フラッシュ方法に基づいた待ち時間を使用すると、クラッシュ前の待ち時間までに書き込まれたデータが全て存在することになる。しかしながら、ディスクコントローラがトラステッドされず、待ち時間後実際にディスク媒体にデータを書き込むことができないと、エンジンは、ディスク活動中最後に記録されたフラッシュ時刻点より以前に書き込まれたデータを全て廃棄するしか方法がない。つまりエンジンは、充分な長さの自由時間が経過したことを決定し、データブロックが実際にディスク媒体に転送されたことを保証するとともに、適切な時刻マーカを書き出す。この時刻マーカがディスク媒体上に到達すると、ブロックの妥当性が確立される。クラッシュからの回復時には、媒体に書き込まれたが続く時刻マーカを有さないデータが、データの一部が失われているかもしれないとして廃棄される。ユーザは実際には、クラッシュ時に書き込み中だったまたはクラッシュ時にちょうど書き出されたところだったデータに興味を示さないのが一般的であるため、このデータの廃棄が問題になることはない。
【００９６】
フラッシュが必要な別のエンジン活動は、ディスクの内容が再配置（スワップ）されている場合である。この処理は、特定の時点でディスクにフラッシュされて、耐クラッシュ性となる（クラッシュ発生時にデータを損失することなく再開できる）ことを前提とした、明確な転送工程を含む。データが大量に移動するために、多くの時点でフラッシュを行わなければならない可能性もある。したがって、この活動の最中は、特定の時点で遅延を生じることにより、ディスクへの書き込みがなされたことを確証する必要がある。
【００９７】
適度に有効なスワップ工程の簡単な実施例では、５０メガバイトのスワップ領域を使用する。平均１メガバイト毎秒の転送速度では、このデータを全て書き込むのに５０秒間かかる。ディスクコントローラが１メガバイトの書き込みキャッシュを有する場合は、そのキャッシュをディスクにフラッシュするのに１秒間の自由時間が必要である。したがって、５０メガバイトのスワップ領域を書き込んだ後のある時点で、ディスクコントローラに対するディスク転送の（累積）遅延を１秒間挿入し、１メガバイトのキャッシュが（１メガバイト毎秒で）確実にフラッシュされるようにする。スワップ領域の書き込み５０秒間に対して１秒間の遅延は妥当な比率である（２％の性能ヒット率[performance hit]）。
【００９８】
ここで、この比率を妥当なものとする重要な要素の１つは、ディスクへのフラッシュとして知られる時点と時点の間に書き込まれるデータの量が大きくて良いこと（前の実施例では５０メガバイトを使用した）である点に、注意する必要がある。これに反し、フラッシュが必要とされるまでに１メガバイトしか書き込まれなかった場合は、データ転送にかかった時間と挿入された遅延との比が望ましい値でなくなる（１秒間の書き込み後に１秒間の遅延が続く、すなわち５０％の性能ヒット率）。（有効な）フラッシュ間に書き込まれる領域が大きい必要があることから、上述したようにエンジンは、所定のディスク位置が修正を必要とせず、その後にフラッシュとフラッシュ間で大領域を書き込むより速い速度で行われる修正とが続くように、設計される。
【００９９】
スワッピングは一般に、バックグラウンドで行われ、ユーザが要求したディスク活動による割り込みが可能である。スワッピング処理において、自由時間に基づいたフラッシュが必要とされ且つユーザがディスク活動の切り離し（バースト）を開始する場合は、ユーザ活動の完了後に必要な遅延が単純に挿入される。
【０１００】
書き込みキャッシュのフラッシュは、ほかに、履歴バッファが高速で上書きされている場合と、逸脱処理が中断されている場合と、システムがシャットダウンしている場合とに必要である。これらの事態は、いずれも頻繁に生じるものではないため、ある程度の遅延を加えても一向に構わない。
【０１０１】
データブロックがいつ有効であるかをディスク上で示す方法の１つは、充分な長さの待ち時間またはディスク活動の自由時間が経過した後に、スタンプや時刻点などの結びフラグ（concluding flag）を書き出すことである。
【０１０２】
図１は、システムの代表的な初期状態を示したものである。「メイン領域ページ」と題された第１の列は、メイン領域の内容を示している。位置＃１〜＃５はデータを含み、位置＃６〜＃９はＯＳによる割り当てを受けていない。エンジンは、ＯＳがこれらの非割り当て位置を読み出した際にゼロ化データを戻す。「マップ／ＴＵＵＮ」と題された次の列は、ＴＵＵＮマップと、ＯＳ指定のディスク位置を実際の物理位置に変換するメインマップとの、複合状態を示している。空のボックスは、マッピングが不要であることを示す。「真」という状態は、関連のＯＳ位置が真に未使用であることを示す。「エキストラページ／履歴ヘッダ」と題された第３の列は、エキストラページ領域の内容と、その関連の履歴ヘッダとを示している。列の頂上部に示された矢印は、次の書き込み位置を示す。「ＡＵＯＳ」と題された最後の列は、ほとんど未使用なＯＳ記憶領域の追跡をエンジンに依頼するためにＯＳから発信された、エントリを表している。履歴ヘッダおよびＡＵＯＳ表は、最初は何の情報もトラックしていない。
【０１０３】
図２では、ＯＳが位置＃１への書き込みを行うため、値「ＤＩ１」が値「ＤＩ２」で上書きされる。エンジンは、この書き込みをエキストラページへと転用し、履歴ヘッダ内にメモを作成する。いくらかの自由時間を与えられた後、最終的には、転用後の新しいデータともとの履歴データとが交換（スワップ）される。位置＃１からのＯＳ読み出し要求を指定のエキストラページへと転用するメインマップには、エントリが１つ追加される。
【０１０４】
図３では、ＯＳが、「ＦＡ１」を含んだ位置＃２を解放する。これは例えば、もとの内容が位置＃２にあったファイルの内容を、ユーザが置き換えることによって生じ得る。ＯＳは、ＯＳの汎用割り当てプールに位置＃２を戻す代わりに、その記憶領域を保留し、その旨をエンジンに通知する。するとエンジンは、ＴＵＵＮマップを更新し、ＡＵＯＳ表にエントリを１つ追加する。ファイルの新しい内容が書き込まれると、その新しいデータ「ＦＡ１Ｂ」は、次に利用可能なＯＳ位置＃６に配置される。エンジンとＯＳとが、この位置が真に未使用であることに同意しているため、データは（エキストラページに転用される代わりに）直接その場所に書き込まれる。図２で生じた書き込みと異なり、図３での書き込みは保留スワップを必要としない。
【０１０５】
図４は、４つのアクションの結果を示している。先ず第１に、位置＃３が、ＯＳによって新しいデータ「ＦＢ１Ｂ」で上書きされる。第２に、データ「ＦＣ１」および「ＦＣ２」を含んだ位置＃４および＃５が、ＯＳによってほとんど未使用な状態に移行する。第３に、位置＃１が、ＯＳによって新しいデータ「ＤＩ３」で上書きされる。位置＃３および＃１を上書きした第１および第３のアクションでは、各書き込みがエンジンによって転用される。位置＃４および＃５がほとんど未使用な状態に移行する際には、エンジンによってＴＵＵＮマップおよびＡＵＯＳ表が更新される。これら２つの位置の解放は、例えばユーザがファイルを削除することによって生じ得る。続く第４のアクションでは、ＯＳが、位置＃７および＃８に新しいデータ「ＦＤ１」および「ＦＤ２」を書き込む。この上書きは、ユーザが新しいファイルを作成してそのファイルに「ＦＤ１」および「ＦＤ２」を書き込むことによって生じ得る。ＯＳは、続く２つの真に未使用な位置を選択し、新しいデータ（＃７および＃８）を受信する。ＴＵＵＮマップは更新されて、位置＃７および＃８はもう真に未使用だとは示されず、空のボックスは、マッピングが不要な状態を表している。
【０１０６】
この実施例の次の工程は、ＯＳが、割り当て可能な（真に未使用な）記憶領域において低いことを認識していることを前提とする。ＯＳはエンジンに対し、ほとんど未使用であるとしてＯＳが以前に保留した記憶領域の位置（またはＯＳラベル）を、信号で返すことを要求する。図４において、システム内で最も古い履歴データは、図２で生じた第１の転用である。しかしながら、この履歴データを保持するのに使用される記憶領域（保留スワップが実行されたと想定する）は、アクセス可能なＯＳ領域より外側のエキストラページ領域にある。次に古い履歴データは、図３で作成されたＡＵＯＳメモである。この記憶領域は、ＯＳによって戻されて使用されることができる。しかしながら、ギャップを超える（時間を遡る）データが、ギャップ内にあったデータに依存したかもしれず、一般に使用不能であるため、履歴ログ内にギャップを設ける理由はないのが一般的である。
【０１０７】
したがって、２つの選択肢が可能である。１つ目としては、エンジンは、ＯＳに戻すことができるＡＵＯＳ記憶領域を獲得するまでは、エキストラページ領域内の履歴データを廃棄または「トリム」することができる。２つ目としては、エンジンは、ＡＵＯＳ記憶領域を早めに戻すが、このような記憶領域のＯＳによる再使用を保存が必要な上書きデータとして扱うことによって、転用を行うことができる。
【０１０８】
図５は、第１の選択肢すなわちトリミングを示している。ここでは、データ「ＤＩ１」の履歴追跡が廃棄（トリム）される。この廃棄は、「ＤＩ２」をエキストラページ領域からメイン領域の位置＃１へと強制的にスワップさせることを含み、位置＃２は、エントリがＡＵＯＳ表から取り除かれるのに伴って、真に未使用な状態へと移行する。ＯＳが位置＃２を割り当てて、この位置にデータを書き込む際には、エンジン（およびＯＳ）によって廃棄された古い履歴データを上書きし、直接データを書き込むことができる。
【０１０９】
図６は、第２の選択肢すなわち転用を示している。ここでは、エントリがＡＵＯＳ表から取り除かれ、それに伴ってＯＳが通知を受ける。しかしながら、影響を受ける位置に関しては、ＴＵＵＮマップが「早期」状態に更新される。これは、この位置には、ディスクの過去の状態を再構築する目的で、エンジンが必要とする履歴データが含まれるため、ＯＳがこの位置を上書きしようと試みると、履歴データを保存するために変更が転用されることを意味する。ある位置をフラグで「早期」と示す必要があるということは、ＯＳがこの位置を読み出そうと試みると、ゼロ化されたデータが戻されることを意味する。これによって、ＯＳによる履歴データへのアクセスが回避される。ここで、この「早期」状態が、ほとんど未使用な記憶領域を早めに解放することを含む上記解決策の一部として導入されたことに、注意する必要がある。
【０１１０】
上述した「トリム」および「方向変換」の方法が利用されるのは、履歴が発生順のイベント列であるためである。これに固有なのは、ある履歴ログの異なる部分を記録した２つの「ブック」が、これらのブックの組み合わせによって完全な履歴を知り得る限り、完全な履歴を表すことができるという事実である。しかしながら、この実施例が示しているように、完全な履歴は、必要な全ソースからの全情報が利用可能である時点までしか遡ることができない。ＡＴＦ方法の場合は、履歴ログのうち、一部がエキストラページ／履歴ヘッダシステムで追跡されて、別の部分がＯＳおよびＡＵＯＳシステムで追跡される。これら２つのシステムは、ＯＳがデータの上書きおよび／または解放ならびに割り当てを行う相対頻度に応じ、それぞれ異なる速度でデータの経年処理を行う。相対速度は、動的で任意の使用パターンに依存しており、保証がないのが一般的である。例えば、ＯＳによって生じているのがほとんど上書きである場合、エキストラページ／履歴ヘッダシステムは、大部分の履歴データの追跡を、ＯＳの制御下にある使用され得る記憶領域を一度も利用せずに行う。
【０１１１】
利用可能（真に未使用）なディスクスペースをフル活用するためには、１つの「ログ」を使用することが好ましい。ＴｅｍｐおよびＡｌｗａｙｓ方法におけるエンジンは、履歴の追跡に利用可能なディスクスペースの管理を、比較的完全に制御していた。これに対してＦｉｌｅ方法では、履歴追跡処理をＯＳに組み込むことを想定していた。このため、ＯＳは１つの履歴ログを効果的に維持していた。
【０１１２】
１実施形態において、ＡＴＦ方法は、記憶領域の大部分がＯＳから動的に取り出されてＯＳに動的に戻されるように、変更される。すると、図５に至る場面は、「ＤＩ１」を保持した（スワップが実行されたと仮定する）「エキストラページ領域」内の記憶領域の一部分を、エンジンが解放してＯＳに戻すことを含む。
【０１１３】
好ましい１実施形態において、ＡＴＦ方法は、組み合わされることにより必要な完全ログを形成する、２つの履歴ログを利用する。したがって、ＡＴＦ方法は、ＯＳ制御下の利用可能な「自由」スペースの一部分を利用するとともに、自身のエキストラページ領域を有することにより、ＯＳからの適度な独立性を維持する。ＡＴＦ方法は、自身による制御下に専用の記憶領域のブロック（履歴バッファ）を有することにより、簡潔性（およびＯＳからの相対的独立性）を達成する。ＡＴＦ方法は、記憶領域の割り当ておよび割り当て解除、ならびに履歴データの保守においてＯＳと協調することにより、性能の向上を達成する。
【０１１４】
実際は、履歴追跡のほとんどが、（履歴バッファよりも）エンジンおよびＯＳによる協調ハンドオフ処理を経るようである。しかしながら、何かの手違いが生じ、その変更の大部分が方向変換を必要とする上書きであった場合に、回復可能性を提供できるように、履歴バッファは充分に大きい必要がある。ディスクスペースが比較的高価であることを考慮すると、履歴追跡に割り当てられた記憶領域の半分が履歴バッファに割り振られ、もう半分が動的に取り出されてＯＳの割り当て可能スペースに戻されるように、ＡＴＦ方法を実装することが推奨される。履歴追跡の大部分がエンジン／ＯＳハンドオフ処理を経てなされることが判明すると、履歴バッファの使用が相対的に制限されるため、ＡＴＦ方法による過去への到達がいっそう可能となる。
【０１１５】
トリムまたは転用の選択肢に再び戻り、決定は、どれだけ時間的に遡ることが維持するのに妥当であるかを考慮してなされることが好ましい。履歴バッファの履歴データが非常に古いと予測される場合は、その履歴データを廃棄することができる。しかしながら、その履歴データが適度に新しく、履歴バッファに充分なスペースがある場合は、ＯＳに早めに記憶領域を戻し、書き込みを転用して、ＯＳによる再使用を処理することが最適となる。この際スワップ時間が追加されるが、回復可能性は保持される。ユーザによるＰＣの使用頻度が（履歴追跡に割り当てられた記憶領域の量に比して）低いことが判明した場合は、どんなイベントに対しても、一般に、より多くの履歴データが必要とされる、すなわち時間的により古く遡ることが必要とされる。
【０１１６】
再び図６に戻り、転用を行う決定がなされた。図７において、ＯＳは位置＃２を新しいデータ「ＦＥ１」で上書きする。この上書きは、位置＃２が履歴データを含むため転用される。位置＃７および＃８もまた、ＯＳによって新しいデータ「ＦＤ１Ｂ」および「ＦＤ２Ｂ」で上書きされる。そして最終的には、ＯＳが、真に未使用な記憶領域の位置＃９に新しいデータ「ＦＦ１」を書き込むため、エンジンは、そのデータを場所に直接書き込む。図８では、転用された全データをスワップする時間がエンジンにあったため、履歴バッファは履歴データのみを含み、「生の」データは場所に入る。したがって、これ以上のマッピングは不要である。
【０１１７】
図９は、データが移動し、少なくとも概念的にこの実施例の開始時（図１）に回復した場合の結果を示したものである。ここで、ある所定の位置がＯＳによって２度以上上書きされた場合は、その位置こそが復元された最も古い履歴データであるということに、注意する必要がある。ＡＵＯＳエントリを「復元させた」ことによる効果は、ほとんど未使用な状態を取り除くことであり、これは、影響位置がこれ以上強制的にゼロ化されるべきでないことを意味する。この復帰がＡＵＯＳエントリに跨らなかった場合は、復帰されたイメージにおいて影響位置がゼロ化される。
【０１１８】
図１０は図１の初期状態を示し、図１１は、データを全て場所に入れた場合の結果を示している。ここで、もとから真に未使用な位置であった場所には残留物が残されることに注意する必要がある。この残留物は、ほとんど未使用な記憶領域から真に未使用な記憶領域への移行を表すエントリが、履歴ログに含まれないことが原因で生じる。このため、他の種々の概念的要素が検討された。次に、残留物をアドレッシングするＡＴＦ設計の第２の工程を説明する。
【０１１９】
ＡＴＦの第２の工程
第２のＡＴＦ設計では、履歴ヘッダをＡＵＯＳ表と組み合わせ、真に未使用な移行のロギングを追加する。この組み合わせを達成するために、新しい履歴ヘッダと関連の円形表が作成された。これらの新しい履歴ヘッダは、履歴ヘッダエントリと異なり、エキストラページに直接関連付けられてはいない。したがって、方向変換タイプのエントリが追加されると、割り当てられたエキストラページが好ましく割り当てられて、リンケージが設定される。いずれも利用可能でない場合は、エキストラページが解放されるまで、新しい履歴ヘッダ表の他端からエントリを取り除くことができる。ここで、この処理が、ＡＵＯＳ記憶領域の解放という結果をもたらし得ることに、注意する必要がある。
【０１２０】
次に示す表７は、新しい履歴ヘッダおよびその関連の属性の、３つの形態をまとめたものである。
【０１２１】
【表７】
【０１２２】
第２のＡＴＦ設計が、履歴ヘッダとＡＵＯＳデータとを組み合わせた表を使用していることから、図１２には、第１のＡＴＦ設計の実施例における初期状態を示した。「メイン領域ページ」と題された第１の列は、メイン領域の内容を示している。位置＃１〜＃５はデータを含み、位置＃６〜＃９はＯＳによる割り当てを受けていない。エンジンは、ＯＳがこれらの非割り当て位置を読み出した際にゼロ化データを戻す。「マップ／ＴＵＵＮ」と題された次の列は、ＴＵＵＮマップと、ＯＳ指定のディスク位置を実際の物理位置に変換するメインマップとの、複合状態を示している。空のボックスは、マッピングが不要であることを示す。「真」という状態は、関連のＯＳ位置が真に未使用であることを示す。「新しい履歴ヘッダ」と題された第３の列は、履歴ヘッダの内容を示しており、この履歴ヘッダは、「エキストラページ」と題された最後の列に示されるエキストラページ領域に関連付けられている。新しい履歴ヘッダ表は、エキストラページ領域から独立しており、さらに、ほとんど未使用なＯＳ記憶領域の追跡をエンジンに依頼するためにＯＳから発信された、ＡＵＯＳデータをも含む。図１２に示されるように、新しい履歴ヘッダは、最初は何の情報もトラックしていない。
【０１２３】
図１３では、ＯＳが位置＃１への書き込みを行うため、値「ＤＩ１」が値「ＤＩ２」で上書きされる。エンジンは、この書き込みをエキストラページへと転用し、新しい履歴ヘッダ内にメモを作成する。そして、自由時間が生じたら、転用後の新しいデータともとの履歴データとを交換（スワップ）する。スワップが生じた後、新しい履歴ヘッダ表は、転用が生じて新しいデータ「ＤＩ２」が位置＃１に配置されたことを示す、１つのエントリを含む。また、このエントリは、エキストラページ領域内で古いデータ「ＤＩ１」が含まれる位置も示している。
【０１２４】
図１４では、ＯＳが、「ＦＡ１」を含んだ位置＃２を解放する。これは例えば、もとの内容が位置＃２にあったファイルの内容を、ユーザが置き換えることによって生じ得る。ＯＳは、ＯＳの汎用割り当てプールに位置＃２を戻す代わりに、その記憶領域を保留し、その旨をエンジンに通知する。するとエンジンは、ＴＵＵＮマップを更新し、位置＃２が今では履歴データを含んでいることを示すエントリを、新しい履歴ヘッダに１つ追加する。
【０１２５】
図１５に示されるように、ファイルの新しい内容が書き込まれると、その新しいデータ「ＦＡ１Ｂ」は、次に利用可能なＯＳ位置＃６に配置される。エンジンとＯＳとが、この位置が真に未使用であることに同意しているため、データは（エキストラページへと転用される代わりに）直接その場所に書き込まれる。図２で生じた書き込みと異なり、図３での書き込みはスワッピングを必要としない。また、位置＃６において、履歴データを何ら保存することなく直接の書き込みが生じたことを示すエントリが、新しい履歴ヘッダ表に１つ作成される。
【０１２６】
図１６は、２つのアクションの結果を示している。先ず第１に、位置＃１が、ＯＳによって新しいデータ「ＤＩ３」で上書きされる。第２に、位置＃３が、ＯＳによって新しいデータ「ＦＢ１Ｂ」で上書きされる。位置＃１が上書きされるに際には、エンジンは先ず、次に利用可能なエキストラページ、すなわちこの場合はエキストラページ領域の第２の位置へと新しいデータ「ＤＩ３」を転用させ、次いで、余分な時間がある時に、前の履歴データ「ＤＩ２」を新しいデータ「ＤＩ３」とスワップする。同様に、位置＃３が上書きされるに際には、エンジンは先ず、次に利用可能なエキストラページ、すなわちこの場合はエキストラページ領域の第３の位置へと新しいデータ「ＦＢ１Ｂ」を転用させ、次いで、余分な時間がある時に、前の履歴データ「ＦＢ１」を新しいデータ「ＦＢ１Ｂ」とスワップする。図１６は、データのスワップが生じた結果の構成を示している。
【０１２７】
図１７は、データ「ＦＣ１」および「ＦＣ２」を含んだ位置＃４および＃５が、例えばユーザがファイルを削除したために、ＯＳによってほとんど未使用な状態に移行する状況を示している。位置＃４および＃５がほとんど未使用な状態に移行すると、エンジンは、ＴＵＵＮマップおよび新しい履歴ヘッダ表を更新する。
【０１２８】
図１８は、ＯＳが、位置＃７および＃８に新しいデータ「ＦＤ１」および「ＦＤ２」を書き込む状況を示している。この上書きは、ユーザが新しいファイルを作成し、そのファイルに「ＦＤ１」および「ＦＤ２」を書き込むことによって生じ得る。ＯＳは、続く２つの真に未使用な位置を選択し、新しいデータ（＃７および＃８）を受信する。ＴＵＵＮマップは更新されて、位置＃７および＃８はもう真に未使用だとは示されず、空のボックスは、マッピングが不要な状態を表している。また、位置＃７および＃８において、履歴データを何ら保存することなく直接の書き込みが生じたことを示すエントリが、新しい履歴ヘッダ表に１つ作成される。
【０１２９】
図１９は、位置＃２がＯＳの要求によって戻された状況を示している。ＴＵＵＮマップ内の関連の位置が「早期」状態に更新される。これは、ディスクの前の状態を再構築するためにエンジンが必要とする履歴データが、この位置に含まれることを示している。このため、ＯＳが位置＃２を上書きしようと試みると、履歴データ「ＦＡ１」を保存するために変更が転用される。上述したように、「早期」であるとフラグされた位置をＯＳが読み出そうと試みると、ゼロ化されたデータが戻される。これによって、ＯＳによる履歴データへのアクセスが回避される。
【０１３０】
図２０は、ＯＳが位置＃２を新しいデータ「ＦＥ１」で上書きする状況を示している。位置＃２が履歴データ「ＦＡ１」を含むため、この上書きは、先ずエキストラページ領域へと転用される。次いで、時間がある時に、履歴データ「ＦＡ１」を新しいデータ「ＦＥ１」でスワップする。図２０は、スワップが生じた後の結果構成を示している。上述した転用後の書き込みのように、新しい履歴ヘッダ表は更新されて、転用が生じたことを示す。この新しい表では、位置＃２に新しいデータが配置されて、関連の履歴データを含んだエキストラページへのリンクが含まれる。
【０１３１】
図２１では、位置＃７および＃８が、ＯＳによって新しい値「ＦＤ１Ｂ」および値「ＦＤ２Ｂ」で上書きされる。エンジンは、この書き込みをエキストラページ領域へと転用し、新しい履歴ヘッダ内にメモを作成する。そして、自由時間が生じたら、転用後の新しいデータともとの履歴データとを交換（スワップ）する。
【０１３２】
図２２では、ＯＳが、位置＃９における真に未使用な記憶領域に新しいデータ「ＦＦ１」を書き込むことから、エンジンは、そのデータを場所に直接書き込む。図２２は、前の実施例の全工程が適用された（そしてスワッピングが実行された）後の、最終状態を示している。
【０１３３】
図２３〜３３は、新しい履歴ヘッダを段階的に「ポッピング」すなわち取り消して、カレントイメージを初期状態に復帰させる状況を示している。特に図２３は、図２２との関連で説明した最後の動作に復帰した結果を示したものである。エンジンは、新しい履歴ヘッダ表内の最新のエントリ、すなわり「真に＃９書き込み」を検討する（examine）。よってエンジンは、位置＃９に関連した位置のＴＵＵＮマップを、真に未使用であると記録する。さらに、ＯＳが位置＃９にアクセスすると、ゼロ化情報が戻されるようになる。ここで、エンジンがＯＳによって位置＃９にアクセスされてゼロ化データを戻す限り、位置＃９の実際の内容を消去する必要はないことに、注意する必要がある。
【０１３４】
図２４では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃７／８、古い」を検討する。このエントリは、転用が実行されて、位置＃７および＃８に新しいデータが格納されたことを示している。また、このエントリは、エキストラページ領域内に配置された古いデータへのリンクも含んでいる。したがって、位置＃７および＃８に、古いデータ「ＦＤ１」および「ＦＤ２」が書き込まれる。
【０１３５】
図２５では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃２、古い」を検討する。エンジンは、図２４との関連で説明したのと同様な方法によって、位置＃２に古いデータ「ＦＡ１」を書き込む。
【０１３６】
図２６は、新しい履歴ヘッダ表内の次のエントリ、すなわち「ＡＵＯＳ（早期）＃２」にエンジンが立ち戻った結果を示しており、これは、ＯＳが位置＃２を取り戻す要求をしたことを意味する。よって、ＴＵＵＮマップを変更し、関連の「早期」エントリを「ほとんど」エントリで置き換えることにより、位置＃２を、ＯＳからの要求以以前の状態に復帰させる。
【０１３７】
エンジンは次に、図２７に示された新しい履歴ヘッダ表内の次のエントリ、すなわち「真に＃７、＃８書き込み」を検討する。よって、エンジンは、位置＃７および＃８に関連した位置のＴＵＵＮマップを、真に未使用であると記録する。さらに、ＯＳが位置＃７および＃８にアクセスすると、ゼロ化情報が戻されるようになる。
【０１３８】
図２８では、新しい履歴ヘッダ表の次のエントリが検討される。エントリ「ＡＵＯＳ（追加）＃４、＃５」は、ＯＳが位置＃４および＃５を解放したことを示す。よってエンジンは、ＴＵＵＮマップを変更し、これらの位置に関連した「ほとんど」エントリを取り除くことにより、ＯＳによる位置＃４および＃５の解放以以前の状態に復帰する。
【０１３９】
図２９では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃３、古い」を検討する。このエントリは、転用が実行されて、新しいデータが位置＃３に格納されたことを示している。また、このエントリは、エキストラページ領域内に配置された古いデータへのリンクも含んでいる。したがって、位置＃３に、古いデータ「ＦＢ１」が書き込まれる。
【０１４０】
図３０では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃１、古い」を検討する。エンジンは、図２９との関連で説明したのと同様な方法によって、位置＃１に古いデータ「ＤＩ２」を書き込む。
【０１４１】
図３１は、次に最新の動作に復帰した結果を示している。エンジンは、新しい履歴ヘッダ表内の次のエントリ、すなわち「真に ＃６ 書き込み」を検討する。よってエンジンは、位置＃６に関連した位置のＴＵＵＮマップを、真に未使用であると記録する。さらに、ＯＳが位置＃６にアクセスすると、ゼロ化情報が戻されるようになる。
【０１４２】
図３２では、新しい履歴ヘッダ表の次のエントリが検討される。エントリ「ＡＵＯＳ （追加） ＃２」は、ＯＳが位置＃２を解放したことを示す。よってエンジンは、ＴＵＵＮマップを変更し、位置＃２に関連した「ほとんど」エントリを取り除くことにより、ＯＳによる位置＃２の解放以以前の状態に復帰する。
【０１４３】
図３３では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃１、古い」を検討する。エンジンは、図３０との関連で説明したのと同様な方法によって、位置＃１に古いデータ「ＤＩ１」を書き込む。図１１と異なり、図３３での最終結果は初期状態に一致する。したがって、この設計では、過去の様々な時点におけるＯＳ可視ディスクの再現を支援する必要情報を取り込むことができる。
【０１４４】
１実施形態では、新しいデータを追加するのと同様な方法で履歴エントリを追加することにより、ディスクを前の状態に復帰させることができる。この実施形態におけるエンジンは、上述した方法で履歴データを獲得する。しかしながら、これらのデータのディスクへの書き込みは、まるで新しいデータであるかのようにエンジンを使用して行われる。この方法では、履歴データの書き込みを再びエキストラページ領域へと転用した後、適切な安全点において、前の「現在の」データとスワップされる。この方法では、ディスクが上述した前の状態に復帰した後、ディスクの「現在の」状態が「履歴状態」となる。
【０１４５】
したがって、クラッシュ発生時には、システムの最新スナップショットと組み合わされた新しい履歴ヘッダ表から、現在のＴＵＵＮマップを再構築することができる。スナップショットは、新しい履歴ヘッダ表内のどこかの時点に対応する。スナップショットは、表からのスナップショット基準点におけるエントリまたは同基準点を超えたエントリを使用して実行されて、その現在の状態を再構築する。
【０１４６】
ＡＴＦ方法は、ファイルシステムの知識をある程度有しており、特定の履歴情報が、ＯＳによる高速なデータアクセスが可能な方法で維持される（すなわち、ファイルの古いヴァージョンが単に、名前を変更された一時ファイル内によけられる）。したがって、例えば、ほとんど未使用な記憶領域から非常に高速で特定のファイルを検索することができる。しかしながら、一般には、ほとんど未使用な記憶領域に直接アクセスするか、または部分的に同記憶領域に基づいて仮想ドライブを作成することにより、充分に高速な検索を提供することができる。
【０１４７】
ＡＴＦ方法には、Ｆｉｌｅ方法コンポーネントから取り入れられた大きな利点がある。これは、ファイルの内容を完全に置き換える等の、少なくとも特定タイプの動作に対して有効である。ＯＳは、記憶領域を保留することによって初期状態を保存するため、ユーザが同じファイルを素早く何度も上書きする場合、ＯＳは各ヴァージョンを全て保存する。これは、上書きヴァージョンがＲＡＭ内にのみ存在し、ディスクに実際に書き込まれることはない場合（あまりに素早く置き換えられるため）ですら生じ得る。安全点をファイル（およびその他の）活動に関連付ける汎用システムの活動記録ログは、置き換えられたファイル内容（データ）がどこに保留されたかに関するメモ（例えばＯＳラベル）を記録して、この情報を検索に使用することができる。これは、ＯＳが、単一の安全点内ではＡＵＯＳ記憶領域を再利用しないことを想定している。
【０１４８】
ＡＴＦおよびＡｌｗａｙｓ方法が、ソフトウェアに実装され破壊の可能性に曝されている場合は、ＡＴＦ方法を「放棄（walk off）」し、有用なディスクイメージを何らかの形態で得ることが合理的に可能である。方法を放棄するという概念は、そのアルゴリズムを、最低限のディスク変更によって使用不可とすることである。ＡＴＦ方法は、一般に、ＯＳ可視データを直接ＯＳ内において割り当て位置として保持するため、そのアルゴリズムを突然使用不可とすると、直接ＯＳが利用可能な状態に近い何らかのディスクが生じる。これに対し、Ａｌｗａｙｓ方法の永久的な再マッピングは、同方法がディスクから引き出された場合（すなわち、データにアクセスするためにマッピングを知る必要がある）に、ディスクが使用に適さない（スクランブルされている）ことを、かなりの程度で保証する。どちらかの方法がファイアウォールより後ろで作動している場合は、ディスクからの方法の放棄は適用されない。
【０１４９】
ＡｌｗａｙｓおよびＡＴＦ方法はいずれも、非標準のディスクデフラグソフトウェアと共に使用することができる。ＡＴＦ方法がディスクを自然な編成に維持する傾向にあることから、既存のデフラグプログラムを適用し、単純にエンジンのインターフェースを通して再配置する方が、容易に思える。これに対してユーザは、１つのデフラグユーティリティのみを必要とするのが一般的であり、このようなユーティリティは、ほぼ同様な試みを行ういずれの方法のもとでも提供することができる。
【０１５０】
以上では、理解を明確にする目的で本発明を詳しく説明したが、添付した特許請求の範囲を逸脱しない範囲内ならば、特定の変更および修正を加えられることは明らかである。したがって、本明細書で取り上げた実施形態は、例示を目的としたものであって、本発明の内容を限定するものではない。このため本発明は、本明細書で特定した詳細に限定されることなく、添付した特許請求の範囲の範囲および同等物の範囲内で、種々の変更を加えることが可能である。
【図面の簡単な説明】
【図１】代表的なシステムの初期状態を、本発明の１実施形態に従って示したブロック図である。
【図２】代表的なシステムにおいて、オペレーティングシステム（ＯＳ）が位置＃１に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図３】代表的なシステムにおいて、ＯＳが位置＃２を解放し、位置＃６に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図４】代表的なシステムにおいて、ＯＳが位置＃１および＃３に書き込み、位置＃４および＃５を解放し、位置＃７および＃８に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図５】代表的なシステムにおいて、ディスク位置を再生させるためにトリミングが実行された様子を、本発明の１実施形態に従って示したブロック図である。
【図６】代表的なシステムにおいて、ＯＳが位置＃２を再生した様子を、本発明の１実施形態に従って示したブロック図である。
【図７】代表的なシステムにおいて、ＯＳが位置＃２、＃７、および＃８を上書きし、位置＃９に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図８】代表的なシステムにおいて、転用後の全データをスワップする時間がエンジンにあった場合の様子を、本発明の１実施形態に従って示したブロック図である。
【図９】コンピュータディスクの再構成を、本発明の１実施形態に従って示したブロック図である。
【図１０】図１から得られる初期状態を、本発明の１実施形態に従って示したブロック図である。
【図１１】コンピュータディスクを再構成した結果を、本発明の１実施形態に従って示したブロック図である。
【図１２】代表的なシステムの初期状態を、本発明の１実施形態に従って示したブロック図である。
【図１３】代表的なシステムにおいて、オペレーティングシステム（ＯＳ）が位置＃１に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１４】代表的なシステムにおいて、ＯＳが位置＃２を解放する様子を、本発明の１実施形態に従って示したブロック図である。
【図１５】代表的なシステムにおいて、ＯＳが位置＃６に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１６】代表的なシステムにおいて、ＯＳが位置＃１および＃３に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１７】代表的なシステムにおいて、ＯＳが位置＃４および＃５を解放する様子を、本発明の１実施形態に従って示したブロック図である。
【図１８】代表的なシステムにおいて、ＯＳが位置＃７および＃８に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１９】代表的なシステムにおいて、ＯＳが位置＃２を再生した様子を、本発明の１実施形態に従って示したブロック図である。
【図２０】代表的なシステムにおいて、ＯＳが位置＃２を上書きする様子を、本発明の１実施形態に従って示したブロック図である。
【図２１】代表的なシステムにおいて、ＯＳが位置＃７および＃８に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図２２】代表的なシステムにおいて、ＯＳが位置＃９に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図２３】代表的なシステムにおいて、エンジンが、ＯＳが位置＃９に直接書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２４】代表的なシステムにおいて、エンジンが、ＯＳが位置＃７および＃８に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２５】代表的なシステムにおいて、エンジンが、ＯＳが位置＃２に上書きするより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２６】代表的なシステムにおいて、エンジンが、ＯＳが位置＃２を再生させるより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２７】代表的なシステムにおいて、エンジンが、ＯＳが位置＃７および＃８に直接書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２８】代表的なシステムにおいて、エンジンが、ＯＳが位置＃４および＃５を解放するより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２９】代表的なシステムにおいて、エンジンが、ＯＳが位置＃３に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３０】代表的なシステムにおいて、エンジンが、ＯＳが位置＃１に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３１】代表的なシステムにおいて、エンジンが、ＯＳが位置＃６に直接書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３２】代表的なシステムにおいて、エンジンが、ＯＳが位置＃２を解放するより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３３】代表的なシステムにおいて、エンジンが、ＯＳが位置＃１に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【発明の属する技術分野】
本発明は、一般にデジタルデータの格納に関し、特に、オペレーティングシステム（ＯＳ）によって同システム管理下のファイルになされた変更を、デジタルコンピュータによって格納されたデータのバックアップおよび回復を支援する変更追跡システムとの関連のもとで追跡するための、方法および装置に関する。
【０００２】
【発明の背景】
コンピュータ上で実行されるアプリケーションは、特にハードディスクからの情報の保存および再呼び出しに責任を負う、オペレーティングシステム（ＯＳ）のもとで動作するのが通常である。情報は、通常はファイルに編成されている。ＯＳは、ファイルと、そのファイル情報を保持するハードディスク上の関連位置との間でマッピングを行う方法を保持している。
【０００３】
現在のコンピュータは、一般に、情報（データ）を読み出して永続記憶用のディスクに書き込む形で動作する。通常は、ディスクを周期的にバックアップ（コピー）することによって、次の２種類の問題に対処している。第１に、ディスク自体が物理的に故障すると、そこに含まれていた情報がアクセス不能となる。第２に、ディスク上の情報が変更され、もとの状態が望ましかったと判断されると、ユーザは、バックアップを使用してこのもとの状態を回復する。バックアップは、同じディスクまたは代替の媒体（ディスクやテープ装置等）に対して行うことができる。
【０００４】
テープバックアップとしては、従来、ファイルまたはディスクセクタイメージとして編成されたディスクの内容を、磁気テープ上に複製する手法がある。このようなテープは、通常は取り外し可能であるので、サイトの外に格納して、ディスクドライブの誤動作や、さらには例えば火災による（ディスクドライブを含む）サイト全体の破壊に対して回復を提供することができる。
【０００５】
情報がセクタレベルのディスクイメージの形態でディスクからテープにコピーされる（すなわち、情報がディスク上と同じ形でテープ上に編成される）場合は、同一のディスク駆動装置に対して最も効率的に復元を行うことができる。このように編成する理由は、速度である。ディスクを最初から最後まで順次読み出す方が、ディスク上を跳び回って一度に１ファイルづつ読み出すより遥かに高速である。これは、ファイルがディスクの１領域に連続的に保存されていないことが多く、ディスク全体に広がって他のファイルと混ざっている可能性があるからである。情報を一度に１ファイルづつテープにコピーする場合は、１つまたはそれ以上のファイルを、すでにデータを含んでいる異なるディスクで効率的に復元することができる。
【０００６】
テープバックアップは、ある時点におけるディスク全体または特定のファイルをバックアップすることに焦点を合わせている。この処理は、長時間かかるのが通常であるため、例えば夕方等に低頻度で行われる。増分（インクレメンタル）バックアップは、最終のバックアップ以降に変更されたデータのみを保存するため、必要なテープ量およびバックアップ時間が低減される。しかしながら、システムを完全に回復させるには、システム全体の最初のバックアップとその後の増分バックアップ全てを読み出して結合し、最終の増分バックアップの時点まで復元しなければならない。テープバックアップの主要な欠点は、最新のバックアップが実行されていない場合に、最後のバックアップ後に生成された情報や作業が失われる可能性があるということである。
【０００７】
ＷＯＲＭドライブによって行われるような追記型のディスクバックアップは、データバックアップと同じ特性を多数有する。しかし、その関連技術のためデータを上書きすることができない。したがってＷＯＲＭドライブは、変更できないバックアップのある程度のリーガル「アカウンティング」システム（legal "accounting" system）を提供する。ＷＯＲＭドライブは、最終的に一杯になってしまうため、変化するディスク情報に連続的なバックアップを提供することはできない。
【０００８】
ＲＡＩＤシステムは、集合的に１つの記憶システムとして動作するドライブの集まりであり、１つのドライブの故障をデータの損失なしに許容し、且つ互いに独立して動作することができる。ＲＡＩＤに含まれる２つの主要な技術は、ストライピングとミラーリングである。ストライピングは、データをドライブ間で分割して高いデータスループットを得る。ミラーリングは、全てのデータを１つのドライブから他のドライブに複製することによって冗長性を提供する。一般に、１つのドライブが故障しても、他のドライブが別のコピーを有しているため、データが失われることはない。
【０００９】
ＲＡＩＤシステムは、物理的なドライブの故障に対するバックアップという形で、速度およびデータの冗長性に関連する。しかしながら、ＲＡＩＤシステムでは、変更された情報を検索する目的で時間を遡ることはない。
【００１０】
Ｔｉｌｉｏｓオペレーティングシステムは、ディスクの状態を保護し、ユーザによるその継続および修正を可能にするために、数年前に開発されたものである。このオペレーティングシステムでは、保護状態と現行状態の２つの状態が維持される。現行状態が失われるかまたは無効になるクラッシュが生じた場合に、ディスクを容易にその保護状態に復帰させ、ログを再生できるように、キー入力（キーストローク）のロギングが実行された。ここでは、例えばファイルを編集しているユーザをシミュレートすることによって、クラッシュした時点に至るまでのディスク情報を、全て回復することができる。保護されたディスクイメージが、現行のものと共に常に利用可能であるため、情報を後の時点にコピーする、すなわち保護バックアップの時点で保存された情報を現行状態にコピーすることができる。
【００１１】
Ｔｉｌｉｏｓオペレーティングシステムでは、全ての作業がディスク上で行われ（たとえば、テープへの転送がない）、変更の増分を記録するという特質（すなわち、現行状態と保護状態の差が通常は小さい）を利用した技術が使用されているため、バックアップをより高速で行うことができる。それにもかかわらず、ユーザは、やはり保護（バックアップ）を行う特定の時間を選択するという問題に直面しなければならず、キー入力の再生方法は、バックアップ後の状態を再現するのに全面的に信頼できるものではない。例えば、キー入力がフロッピィディスクまたはインターネットからデータをコピーするコマンドだった場合、それらの対話は、いずれもＣＰＵおよびディスクで再現できる範囲の外にある。
【００１２】
これまでは、ファイルの拡張子だけを変更した新しいファイル名でファイルのコピーを作成する（例えば、「abc.doc」を「abc.bak」にコピーする）ことにより、ファイルのバックアップが簡単に作成されてきた。この場合、メインファイル（abc.doc）が破損または紛失した時に、バックアップ（abc.bak）からそのファイルを復元することができる。しかしながら、この処理は、選択的なテープバックアップとほぼ同じであるため、バックアップ管理の問題（いつ行うか、いつ廃棄するか等）を伴う。
【００１３】
要するに、ＲＡＩＤシステムは、物理的ドライブの故障に関係したバックアップのみを取り扱っている。テープ、ＷＯＲＭ、Ｔｉｌｉｏｓ、およびファイルコピーは、変更された（失われた）情報の回復に関係したバックアップにも対処している。
【００１４】
従来のバックアップ処理は、一定の期間停止してディスク情報の複製コピーを作成する作業を含む。これは、ディスク全体が再現されるか、または特定の情報が再呼び出しされるように、ディスク全体を見てコピーを作成する作業を含む。この処理は、テープへの書き込みを含むのが通常である。あるいはユーザは、特定の時点以降の凍結されているコピーを表す複製を作成することで、ファイルの特定の集合をバックアップしても良い。ここでは、オリジナルが継続して変更されることを想定している。この処理は、通常、オリジナルと同じディスクドライブ上にバックアップファイルを作成することを含む。ここで、「ディスク」とは実際には、１つもしくはそれ以上のディスクドライブ、またはディスクドライブと同様に作動する装置を意味することに注意が必要である。
【００１５】
上述したいずれの場合も、ユーザは、バックアップを作成することを意識的に決定しなければならない。後者の場合は、テキストエディタのような特定のアプリケーションが、最後の数バージョンのファイル（情報）を保持している。しかしながら、ファイルがスタビライズされて長期間経た後には最終的に全てが複製されて、ディスク空間が浪費される原因となる。つまり、ユーザが、文書の処理中に前のバージョンに戻りたいケースは多くても、完了して何年も経過した後に、最終状態の直前の状態を再訪したいと思うことは滅多にない。
【００１６】
情報の回復が非常に重要となるもう１つの状況は、どのファイルがディスク上のどの場所に位置しているかを識別するディスク用のディレクトリシステムが破損した場合である。これは、例えば、ディレクトリのアップデート（更新）中に生じるシステムクラッシュや、オペレーティングシステムまたは他のユーティリティ内でのバグが原因で発生する。いずれの場合も、ディスク内容のディレクトリが失われると、たとえ参照ファイルがディスク上に存在していたとしても、それら参照ファイルも失われる結果となる。この場合、ユーザが復元したい情報はディスクのディレクトリである。
【００１７】
ユーザがバックアップに復帰したいと思う最後のケースは、例えば、動作しない新しいソフトウェアまたはデバイスドライバをインストールしたことが原因で、オペレーティングシステムが破損した場合である。
【００１８】
ユーザが、コンピュータディスク上で操作されている情報の内容を、時間的に遡りたいと思う理由は数多くある。従来のバックアップでは、バックアップした時点まで回復することができた。しかしながら、システム全体に渡るこれらのバックアップは、ディスクを走査してその内容を複製するのに長時間必要であるため、行える頻度に限界がある。つまり、このバックアップでは、大きな動作休止と莫大な量の記憶領域とが必要であり、ディスク全体を数分毎にバックアップすることは不可能である。時間の進行に従ってファイルの履歴コピーを保持するには、結局はユーザがアーカイブの管理およびコピーの消去を行って、ディスクのオーバーフローを回避する必要がある。
【００１９】
ファイルの名前を変更し、ファイルのデータを別のファイルと再び関連付ける（re-associate）技術は、データのコピーおよび古いファイルの検出に伴うオーバーヘッドを回避するのに使用される周知の技術である。ＯＳのもとでファイルの名前を変更する動作は、一般に、割り当ての集合をＯＳのファイルシステム内であるファイルから別のファイルへと再び関連付けることを含む。大体の場合は、１ファイルが１集合のディスク割り当てを表し、記憶領域の管理は、同一のファイル内または異なるファイル間でこれらの割り当てを操作することによって行われる。例えば、ＰＣ上の自由記憶領域自体をファイルと見なすことができる。ファイルの作成時には、記憶領域が自由ファイルから引き出されて別のファイルと再び関連付けられる。ファイルを削除する技術は、その定義上、あるファイルデータを保持するのに使用された記憶領域が汎用プールに戻れることを、信号で示すためにＯＳのもとで使用される方法である。汎用プールは、ＯＳが、新しく作成されたファイルに記憶領域を割り当てるもととなる領域である。これらの概念は、ＯＳの設計技術の当業者に周知である。
【００２０】
従来技術によるデータのバックアップアプリケーションに固有な別の問題点は、データがディスクに書き込まれる順番を制御する必要があることである。例えば、ある状態から別の状態に移行する場合は、移行データをディスク上に書き込み（フラッシュし）、次いで、データのバックアップアプリケーションで必要とされる内部バックアップデータを更新する。しかしながら、現在のディスクドライブは、性能向上のために書き込みキャッシュを備えているのが一般的である。書き込みキャッシュは、書き込みをバッファリングし、書き込みとは異なる順序でデータをディスク媒体上に格納（コミット）する。この処理は、例えばディスクコントローラが、ディスクヘッドの動きを低減する順序でデータを書き込むことを可能とすることにより、書き込み処理全体のスピードアップを図るものである。しかしながら、ディスク上にすでに存在すると想定されるデータ（書き込まれるのをまだ待機している）よりも、内部バックアップデータの方が先に更新される。電源障害が発生すると、ある安定状態から別の安定状態への安全な移行が不可能となる。
【００２１】
ディスクドライブに送信されて、このような書き込みキャッシュの最適化を使用不可にできるコマンドが存在する。しかしながら、これらのコマンドは、他の有用な最適化をも使用不可とするため、深刻な性能低下を生じる原因となる。ディスクのなかには、フラッシュコマンドをサポートし書き込みキャッシュを特別にフラッシュするものもあるが、このようなコマンドを使用可能とするのは容易でない。つまり、今日のコンピュータには、ディスクでの読み取りおよび書き込みを行う基本入出力システム（ＢＩＯＳ）の標準手段が含まれているが、書き込みキャッシュをフラッシュする標準手段は含まれていない。したがって、コンピュータのディスクドライブがフラッシュコマンドをサポートするか否かに関わらず、データのバックアップアプリケーションは、標準的なＢＩＯＳインターフェースを使用していることが原因で、容易に初期化フラッシュを行うことができない。データのバックアップアプリケーションは、ディスクと直接通信を行う必要があるため、特別なハードウェア知識を有している。これは、あらゆるコンピュータ上で実行されることを期待される、汎用プログラムの見地からは不可能である。コンピュータメーカがとった一般的な方法は、特定タイプのハードディスクを、そのタイプのディスクの制御方法を知るＢＩＯＳと結合させることであった。その後のソフトウェアは全て、ＢＩＯＳによって提供されたＳＣＳＩやＩＤＥ等のインターフェースに依存してディスクと送話するのが一般的であり、今日のインターフェースにフラッシュコマンドがは含まれていない。
【００２２】
したがって、改良バックアップ方法は、専門のディスク（ハードウェア）知識をエンジン内に構築しなくても、書き込みキャッシュの存在を、それをフラッシュする必要なしに容易にするものである。これは、この方法が、ディスクコントローラに書き込まれるデータが実際には異なる順序でディスク媒体に格納（コミット）され得ることを考慮に入れなければならないこと、そしてそれにもかかわらず、この方法がディスク上のデータ保全性を維持してクラッシュの回復を可能とする必要があること、を意味する。
【００２３】
【発明が解決しようとする課題】
以上から、データを回復させるための改良方法が必要とされていることがわかる。この改良方法は、コンピュータディスクの以前の状態を、安全且つ発生順に制御する方法で再構築することを可能とする必要がある。
【００２４】
【発明の概要】
本発明は、大まかにいえば、コンピュータディスクの現行の状態と履歴データとを共に使用し、そのディスクの以前の状態を再構築する方法を提供することにより、上述したニーズを満たすものである。本発明では、セクタレベルのバックアップをファイルレベルのバックアップと組み合わせることにより、効率および信頼度の向上を図る。
【００２５】
１実施形態では、データを回復させる方法を開示する。先ず、ディスク位置Ｘ、ディスク位置Ｙ、ディスク位置Ｚ等の種々のディスク位置を含むディスクについて、ディスクの履歴状態の記録を作成する。ディスク位置Ｘにあるもとのデータを新しいデータで上書きする要求に応じ、その新しいデータをディスク位置Ｙに格納する。次いで、履歴状態の記録内に、ディスク位置ＸおよびＹの役割を示す標識を設定する。これらの役割は、履歴データを含むというディスク位置Ｘの役割、そして、ディスク位置Ｘの新しいデータを含むというディスク位置Ｙの役割を、規定することができる。また、この方法は、コマンドをインターセプトしてディスク位置Ｚにあるデータを解放し、履歴状態の記録内に、ディスク位置Ｚが履歴データを含むことを示す標識を設定することを含む。
【００２６】
別の１実施形態では、コンピュータディスクの以前の状態を復元するためのコンピュータプログラムを開示する。このコンピュータプログラムは、オペレーティングシステムからのファイル管理コマンドをインターセプトすることができるコードセグメントと、ディスク位置の状態を示すマップとを含む。このコンピュータプログラムはさらに、メイン領域に履歴データをマッピングする履歴表をも含む。履歴表は、オペレーティングシステムによって解放されたディスク位置も示す。履歴表の各エントリは、発生順にアクセスされることができる。このコンピュータプログラムはさらに、ディスク更新の標識を実質上発生順に履歴表に記録するコードセグメントも含む。
【００２７】
さらに別の１実施形態では、コンピュータ読み取り可能媒体の以前の状態を復元する方法を開示する。先ず、コンピュータ読み取り可能媒体への履歴変更のエントリを有したデータ構造を設定する。データ構造は、第１のデータ位置Ｘにあるもとのデータを新しいデータで上書きすることに関する書き込みエントリと、オペレーティングシステムによってデータ位置Ｚを解放することに関する解放エントリとを含む。次いで、コンピュータ読み取り可能媒体を再構築する要求に応じ、データ構造内で最新のエントリを検証する。書き込みエントリの検証に応じ、第１のデータ位置Ｘにある新しいデータをもとのデータで置き換える。さらに、解放エントリの検査に応じ、オペレーティングシステムが解放データ位置Ｚにアクセスできるようにする。すると、データ構造内で最新のエントリが廃棄され、同方法が、コンピュータ読み取り可能媒体の以前の状態が復元されるまで繰り返される。
【００２８】
以下の説明から、本発明が、コンピュータディスクの以前の状態の再構築を安全且つ発生順の制御方法で行えることが、当業者にとって明らかとなる。本発明の他の態様および利点は、本発明の原理を例示した添付の図面と関連させて行う以下の詳細な説明から明らかとなる。
【００２９】
【発明の実施の形態】
本発明は、履歴変更が追跡されるオペレーティングシステムとの関連のもとで、上書きされたディスク記憶領域を再生することを目的として開示されるものである。本発明は、オペレーティングシステムがデータを書き込む実際の格納位置を選択することを可能とする一方で、ディスクの以前の状態を再成するのに必要な古い履歴データをオペレーティングシステムから確実に保護する。本発明はまた、デフラグと、実際のディスク媒体への安全なデータの移行とを支援する。
【００３０】
以下の説明では、本発明の完全な理解を促すために多くの詳細について特定している。しかしながら本発明は、これらの詳細の一部または全てを特定しなくても実施することが可能であることは当業者に明らかである。そのほか、本発明を不必要に不明瞭化するのを避けるため、周知の処理操作の詳細な説明は省略した。
【００３１】
以下の議論をさらに明確にするため、次に、幾つかの用語、すなわちカレントディスクイメージ、シミュレートされたディスクイメージ、メイン領域、およびエキストラページ領域に関して説明する。カレントディスクイメージとは、過去のものではないディスクのビューを指し、ユーザが最後に書き込んだデータからなる。ディスク上に履歴ロギングが存在しない場合は、ディスクに現在含まれるデータがカレントイメージとなる。シミュレートされたディスクとは、ユーザおよびＯＳから完全に独立したディスクを指す。しかしながら、ＯＳより下のレベルのエンジンは、カレントイメージおよび保存された履歴データをもとに、他のことをしているときに、このディスクを作成される。
【００３２】
実際のハードディスクは、メインおよびエキストラのページからなる２つの基本領域に分割されるのが一般的である。メイン領域は、カレントイメージに属するページを保持する。エキストラのページ領域には、履歴データが保持されている。メイン領域のマップは、カレントイメージへのアクセスを転送して、エンジンによって割り当てられた位置の置き換えを可能とする。履歴マップの履歴ページ記述子は、履歴ページを管理する。メインおよびエキストラのページは、自身の領域内でまたは反対領域からのページとの間で、一時的に役割を交換することができる。したがって、通常なら履歴データを保持するエキストラページ領域に属するページに、カレントイメージの一部を一時的にマッピングしても良い。
【００３３】
「上書きデータ」という表現にも注意する必要がある。上書きデータは、物理的に上書きされたデータを意味するのではない。ファイルには、アプリケーションによって上書きされ得るデータが含まれる。しかしながら、本発明は、データのもとの状態を保存することに関するものである。これは、物理的に上書きされる前にデータをコピーする（移動させる）か、または書き込みの宛先を変更して本当に上書きされるのを回避することによって達成される。したがって、「上書きデータ」という表現は、ＯＳによる上書きに先だって存在するファイルのデータであって、履歴データとしてエンジンに保持されているデータを意味する。
【００３４】
ディスク管理の責務は、オペレーティングシステムからファイリングシステム（例えばウィンドウズＮＴのＮＴＦＳ）へと分離され得る。本明細書の目的に沿って、ＯＳに言及する際は、ディスク管理に伴うあらゆる他のサブシステムを含むものとする。
【００３５】
エンジンという用語は、目下議論中の方法を実現するためのロジックを意味する。種々の方法が議論され、それぞれの方法は独自のエンジンを有する。
【００３６】
「エキストラページ領域」の「エキストラ」という用語は、概念的に、ユーザから可視でないものがエキストラであるという思想に基づく。ディスクは、物理的に所定の容量を有する。しかしながら、ディスクのなかには、保留されてユーザから隠されている領域がある。このため、ＯＳによって報告される、ユーザにとって可視のディスクサイズ（メイン領域）は、そのディスクの真のサイズよりも小さい。したがって、ユーザにとって可視でない記憶領域が「エキストラ」であり、エンジンが利用するものである。
【００３７】
ＯＳは、その制御下にある種々の構造（例えばファイル）にディスク位置を割り当てる。しかしながら、エンジンのなかには、ＯＳのディスク位置を他の位置に再マッピングするものもあるため、ＯＳに関連した「ディスク位置」とエンジンに関連した「ディスク位置」とを区別するために、ＯＳのディスク位置を位置キーと呼ぶ。
【００３８】
本発明は、上書きデータのもとの状態を保持するための３つの方法、すなわちＴｅｍｐ、Ａｌｗａｙｓ、Ｆｉｌｅ方法を改良するものである。Ｔｅｍｐ方法およびＡｌｗａｙｓ方法では、所定の時点におけるディスクのもとの状態をオペレーティングシステム（ＯＳ）およびアプリケーション（例えばゲーム）から保護する機構（エンジン）は隔離されている。ここで、保護された「状態」は、エンジンを介してＯＳによってビューされるものであり、エンジンは、ＯＳによる関連ディスク領域へのデータの割り当てを再マッピングまたは管理する。保護機構がＯＳにおけるバグまたは望ましくないディスク書き込み動作に影響されないため、このような隔離によって信頼性を向上させることができる。
【００３９】
また、エンジンの隔離は、保護メカニズムがハードウェアにマイグレーションすることも可能とする。すでに議論したように、ハードウェアへのマイグレーションは、例えばＣＰＵ、ディスクインターフェース、および／またはハードディスクコントローラへの、保護エレメント（ロジック）の組み込みを含むことができる。
【００４０】
一般に、ＯＳによる記憶領域の割り当ておよび解放をエンジンによるそれと密接に協調させて、冗長または余分な工程を低減または排除することが望ましい。このような余分な工程（オーバヘッド）は、エンジンをＯＳから隔離したいという要求が原因で導入されるものである。換言すると、エンジンは、ＯＳとの信頼できない関係を想定していることがある。つまり、ＯＳが、自身がアクセス可能なあらゆるデータを破壊するように作動する可能性があることを想定している。Ｔｅｍｐ方法は、ディスク上のＯＳのデータ編成を維持するように努めているため、データを実際のディスク位置に割り当てるのに際しての、ＯＳとエンジンとの協調はほとんどない。
【００４１】
Ａｌｗａｙｓ方法では、エンジンへの割り当て解除の情報の提供を含む、より密接な関係を使用する。Ａｌｗａｙｓ方法を実装するエンジンは、一般に、この情報およびその他の情報を使用して、データを移動させる必要を回避することにより、所定のディスク位置（ファイル）におけるもとの内容を保存または最適化する。換言すると、ＯＳが新しいデータを書き込む場合、ディスク上に最初に割り当てられた位置は、（Ｔｅｍｐ方法の場合と比べて）かなり永続的である。
【００４２】
本発明は、Ｔｅｍｐ、Ａｌｗａｙｓ、およびＦｉｌｅ方法の変形例を詳細化しており、ＯＳは、データを書き込む実際の格納位置の選択において、より重要な役割を果たす。しかしながら、本発明は同時にまた、ディスクの以前の状態を再現するのに必要な古い履歴データを、ＯＳから確実に保護する。このため、エンジンロジックの一部分は、オペレーティングシステムに対する多少とも標準的な動作か、または増補動作によって処理される。本発明はまた、デフラグ処理と、ディスクの実際の媒体へのデータの安全な推移とを支援する。
【００４３】
本発明の方法は、ＯＳとエンジンの間における、割り当て情報および割り当て解除情報の交換に基づくものである。しかしながら本発明では、特定の方法をディテイルする。そうすることによって、あるファイルから別のファイルへの記憶領域の再関連付け（ファイルの名前変更）と、記憶領域の解放（ファイルの削除）と、を行うためのＯＳ機構は、方法と組み合わされ、これらの動作がエンジンの復元能力に害を及ぼさないようにされる。
【００４４】
本発明は一般に、データに対する少なくとも最終的なディスク上の位置はどこであるかをＯＳが決めることを可能とする。このためファイルシステムは、少なくとも最終的には、エンジンがデータを実際に配置したディスク位置にファイルを直接マッピングして、これ以上の再マッピングを不要とする。
【００４５】
本発明の１実施形態を、ＡＴＦ方法（Ａｌｗａｙｓ、Ｔｅｍｐ、およびＦｉｌｅの３つの方法を組み合わせたもの）と呼ぶことにする。ＡＴＦ方法では、ＯＳが新しいデータの大部分に対して、スワッピングが不要となるように、最終的なディスク位置を選出できるようにして、スワップされなければならないデータの量の低減を図る。この方法はまた、デフラグ処理を分離することによって、ＯＳまたは別のユーティリティが、提供されたエンジンへのインターフェースを使用して、動作を実行できるようにする。
【００４６】
本発明では、ＯＳとエンジン（ＡＴＦ方法）との間にインターフェースを追加することによって、未割り当ての（「真に未使用である」）ＯＳディスク位置に関する通知をはじめにエンジンが受け取るようにする。ここでは、特定の位置が真に未使用であることをエンジンに通知することによって、エンジンがこれらの位置を効果的にゼロ化することができる、というルールが成り立つ。ここで注意する必要があるのは、エンジンはこれらの位置に実際にデータを格納し得るものの、ＯＳがこれらの位置のどれかを読み出そうと試みると、エンジンからはゼロデータが戻されるという点である。この後者の工程は、エンジンによる内部目的のために使用される、履歴データを含む領域にＯＳがアクセスするのを防ぐものである（このため同データに一定レベルのセキュリティを提供する）。
【００４７】
ＯＳが、使用中のディスク位置への書き込みを行うと、エンジンは、Ｔｅｍｐ方法に従って書き込みの宛先を変更して、その後、新しいデータと履歴データとをスワップする。オペレーティングシステムが、記憶領域が真に未使用であることをフラグする（後ほど簡単に説明する）と、フラグされたページは、（セキュリティのために）少なくとも実効的にゼロ化される。ＯＳが、真に未使用であることをフラグされた位置に書き込みを行う場合、データは、エンジンによって直接その場所に書き込まれる。したがって、エンジンは、ＯＳによって真に未使用であるとフラグされた場所を示したマップを保持する。
【００４８】
ＡＴＦ方法は、アクティブ（メイン領域）を含むデータから履歴（エキストラページ）を含むデータへのＯＳディスク位置の移行が、ＯＳまたは拡張ＯＳのいずれに移動したかをＦｉｌｅ方法から取得する。拡張ＯＳは、標準ＯＳに補足コードを組み合わせることによって、エンジンが必要とする動作を実現するものであり、ＯＳに既存のものではない。記憶領域は、基本的に、オペレーティングシステムによって解放されるのに伴って「ほとんど未使用」の状態に移行する。この状態は、以下の点において「真に未使用」な状態とは異なる。すなわち、その記憶領域は、オペレーティングシステムによって正式に解放されているものの、その内容は以前の状態の回復に使用される可能性に備えて維持されて、経年処理を経てほとんど未使用から真に未使用な状態に移行する。換言すると、ほとんど未使用な記憶領域は、単なる古い履歴データである。このような記憶領域は、エンジンとの関連において履歴データ（ＯＳによって上書きされてエンジンによって保存されているディスク位置）と呼ばれる。本発明では、ＯＳがこの記憶領域を認識しているため、この記憶領域は、ＯＳとの関連においてほとんど未使用な記憶領域と呼ばれる。
【００４９】
ディスクおよびファイルは、ＯＳを通常に使用している最中に様々な形で変更される。ファイルは、部分的に（例えば途中の数バイトを）上書きされることができる。新しいファイルを形成したり、ファイルを削除したりすることもできる。既存ファイルの内容を廃棄して新しいデータで置き換えたり（削除と作成の組み合わせ）、ファイルを切りつめたり（ファイルのうち特定の点以降のデータを全て廃棄する）することもできる。ＯＳは、多種類の動作を支援することができる。ユーザに可視のファイルに関連していないディスクデータは、ＯＳのファイル管理に関連しているのが通常である。例として、特定のディスク位置を特定のファイルに関連付ける表が挙げられる。このような情報は、すでに言及したように、少なくとも概念的には特別な内部ＯＳファイルと見なされることができる。本発明の課題の１つは、（ＯＳによってビューされる）早い時間におけるディスクの内容を再現する方法を提供することにある。
【００５０】
ＡＴＦ方法は、ディスクの一般的な変更の保存を、Ｔｅｍｐ方法に類似の方法を使用して処理する。しかしながら、ＡＴＦ方法は、「削除」された記憶領域、すなわちその内容はもう不要であるが回復での使用の可能性に備えてエンジンで追跡する必要があるような記憶領域を、ＯＳに通知する。
【００５１】
一般に、容易にインターセプトされ調整されて、少なくともいくらかの割り当て解除をキャッチすることができる動作は２つある。すなわち、ファイル削除の動作と、ファイル内容の廃棄および置き換えの動作である。いずれの場合も、少なくとも部分的に、動作を、例えばファイル名の変更に変換することにより、解放された記憶領域の保存が行われる。記憶領域は、単に保存されるのではなく記憶領域のブロックとして保存され、ＯＳにおける通常の自由（利用可能）なディスク記憶領域トラッキングによりマッピングされ続けるため、再使用されることはない。
【００５２】
任意ファイルの中間の修正（上書き）など、ファイル名の変更技術（またはそれに同等な技術）で処理されない動作が多く存在する。さらに、ＯＳの内部データの修正も存在する。ＡＴＦ方法は、もとの状態の追跡を目的として、特定の割り当て解除動作上につきＯＳと協調するが、カバーされないその他全ての動作に対しては、Ｔｅｍｐ方法を使用して処理を行う。本発明は、スワッピングを低減する方法の詳細を詳述し、記憶領域の少なくとも最終的なディスク位置を一般的に割り当てる際のＯＳの役割を保存し、隔離（例えばファイアウォール）により全体的な復元能力を保護する。
【００５３】
ＡＴＦ方法では、ＯＳが記憶領域のブロックを解放すると、同ブロックは自由プールに返される代わりに、ほとんど未使用な部類に分類されてラベル付けされ、エンジンが同ブロックの解放に関する通知を受ける。実際のこの処理は、標準ＯＳをファイル名の変更に拡張することによって、ファイルの記憶領域が解放される直前に達成され得る。エンジンは、このほとんど未使用な記憶領域に関連付けられたディスクの割り当てを通知されるため、エンジンは、その記憶領域をどんなさらなる警告（alerting）からも保護することができる。この保護は、ほとんど未使用な記憶領域がＯＳによって修正されうる形態を採るが、エンジンは、ほとんど未使用な記憶領域のもとの状態を追跡する手段を採る。つまり、Ｔｅｍｐ方法が実装されているのに関わらず、エンジンも、ほとんど未使用な記憶領域の位置を（その位置がＯＳによってどのようにラベル付けされているか、ということと共に）通知される。
【００５４】
好都合なことに、ＯＳのビューにおいて、ほとんど未使用な記憶領域は除かれているので、上述の動作によって、ＯＳは、一般にほとんど未使用な記憶領域を再使用しないこととなる。これは、ＯＳがほとんど未使用な記憶領域に上書きしない限り、Ｔｅｍｐ方法が宛先を変更して、その後、新しい状態と以前の状態とをスワップする必要はないことを意味する。
【００５５】
ほとんど未使用な記憶領域は、エンジン内の一般的な履歴データと共に経年処理を経て、真に未使用な記憶領域に移行する。これは、エンジンの制御のもとで行われるのが一般的である。この処理は、Ａｌｗａｙｓ方法の一般的なアウトラインに従う。Ａｌｗａｙｓ方法においては、記憶領域のブロックは、メインＯＳイメージの一部分である状態（ＭＡＩＮブロック）から履歴データである状態（ＥＸＴＲブロック）を経て新しいデータを受信できる状態（ＣＴＭＡブロック）に到達する。ＡＴＦ方法においては、一般的なＴｅｍｐ方法機構に加えて、記憶領域のブロックは、ファイルに関連付けられた状態からほとんど未使用な記憶領域に関連付けられた状態（履歴データを保存している）を経て再び再使用が可能な状態（自由ディスクプール内にある）へと移行する。ＡＴＦ方法における「ブロック」は、一般に、解放されたファイル全体を指す。Ａｌｗａｙｓ方法がある程度の組み込みデフラグを含む一方で、ＡＴＦ方法はデフラグをより外部の処理に格下げする（つまりＡＴＦ方法は、ＯＳまたはユーティリティがディスクの記憶領域の再整理を指示することを可能とする）。
【００５６】
ＡＴＦ方法のもとでの「ブロック」サイズに関して興味深い点は、ほとんど未使用な記憶領域のブロックをファイルと関連付けると、そのブロックのサイズが劇的に変動し得るという点である。つまり、ユーザが削除したのは巨大なファイルかもしれないし小さいファイルかもしれない。したがって、ほとんど未使用な記憶領域が真に未使用な記憶領域に移行するのに伴って、ＯＳの自由プールに戻される記憶領域の量は、かなりの量かもしれない。初めは、履歴データを追跡する記憶領域をもっと徐々に移行させてＯＳの自由プールに戻し、本当に必要なときまで履歴データを解放しない方が良いように思える。
【００５７】
しかしながら、複数のファイルであったものに複数のブロックが対応する場合、履歴ファイルの内容の半分を保持して、一方で、もう半分の再利用を許可することは、データ復元の観点から見て意味をなさない。したがって、古い履歴データのブロック全体が使用のために必要とされている限り、大きな記憶領域のブロックをＯＳの自由プールに返し、そのために古い履歴データを追跡するというこれらブロックの以前の役割を断念しても、何ら問題は生じない。履歴データの追跡に使用される記憶領域が複数の安全点（safe point）に対応する複数のブロック単位で解放され得るＡｌｗａｙｓ方法に関しても、同様な一般的観測がなされる。これは、所定の安全ポイントに対応する履歴データの部分集合が、どの回復目的にも使用できないと考えられるためである。
【００５８】
ＡＴＦ方法の詳細は２つの工程で表される。第１の工程は、Ｎｅｗ Ｔｅｍｐ方法によるもので、同方法からの進行を示すとともに一定事項を強調することを意図するものである。さらに、異なる実装を使用したＡＴＦ方法が、第２の工程として表される。第２の工程は、第１の工程の設計における問題点を解決するものであり、しかし、前述した方法のデータ構造からのさらなるジャンプであると言える。
【００５９】
Ｎｅｗ Ｔｅｍｐ方法では、エンジンは、ＯＳによって一般にアクセス可能なメイン領域ページに加えて、比較的単純なデータ構造を有しエキストラページに対応した履歴ヘッダを保持している。ＡＴＦ方法は、２つの追加のデータ構造を追加する。すなわち、ほとんど未使用なＯＳ位置（ＡＵＯＳ／almost unused OS locations）にあるブロックの発生順の円形表と、どのメイン領域ページが真に未使用またはほとんど未使用である（ＴＵＵＮ／truly unused or almost unused）かを示すマップの２つである。ＡＵＯＳ表の各ブロックに対し、そのブロックをＯＳ内で識別する方法が格納される（例えばファイル名）。また、そのブロックがいつ作成されたかを示す履歴ヘッダへのリンクも格納されており、それによって、そのブロックを履歴ヘッダの全時間追跡機構にリンクさせる。代表的なＡＵＯＳ表エントリを表１に示した。
【００６０】
【表１】
ＯＳが、ファイルに関連付けられた活動状態からほとんど未使用な状態へと記憶領域を移行させるのに伴って、ＡＵＯＳ表の一端にブロックが追加され、ＴＵＵＮマップが、現在はほとんど未使用な状態にある新しいディスク位置を示すように更新される。ＯＳが利用可能な空きスペースを充分な量だけ確保する必要があるため、ブロックは表の他端から取り出される。関連付けられた記憶領域がＯＳによる再使用に提供されて、ＴＵＵＮマップが更新される（ほとんど未使用なディスク位置が真に未使用となる）。名前変更の動作を使用して履歴データを破棄した場合、ＯＳは、削除動作を使用してその記憶領域を自身による再使用に供するのが通常である。ディスク位置が真に未使用であることを示すＴＵＵＮ状態によって、エンジンが通常の転用処理およびスワップ処理を回避することが可能となる。
【００６２】
ＴＵＵＮマップは、ほとんど未使用な状態のディスク位置を追跡することにより、エンジンが、このような記憶領域に対するＯＳ読み出し要求をキャッチして、実際の内容の代わりにゼロデータを返すことを可能とする。こうするには２つの理由がある。先ず第１に、ほとんど未使用な記憶領域は、履歴データを含むため一般的なセキュリティ問題を伴う。ユーザは、自分のディスクの以前の状態に容易にアクセスできることを望まないかもしれない。セキュリティは、前掲したようにこのようなアクセスをエンジンでインターセプトするか、またはＯＳセキュリティ機構を使用する（ファイルをアクセスからロックしたり、ファイルの属性ビットを設定したり等など）ことによって、実現することができる。しかしながら、エンジン全般の目的は、ユーザがそのディスクの以前の状態にアクセスできることを保証することであることに、注意が必要である。
【００６３】
このセキュリティ問題は、それほど重要な関心事ではない。最も重要なのは、ディスクの以前の状態にアクセスできることを保証するという概念である。ユーザ（ＯＳ）が、あたかも通常のディスクイメージの一部であるかのように履歴データにアクセスできるようにすることには、履歴データがメインイメージの一部になるという問題点が伴う。このため、ＯＳ上で実行されるアプリケーションが、履歴データを利用することが可能となって、履歴データにより容易に依存するようになる。このような状態が生じ、データが通常の経年処理の一部として解放されると、ディスク全体を時間的に復帰させることが不可能となる。つまり、ＯＳが履歴データを直接参照できると、時間を遡るというコンセプトが弱体化してしまう。
【００６４】
エンジンが提供する機構は、履歴データをメインイメージから明確に区別するのが一般的である。つまり、ユーザは、メインドライブではなく仮想のドライブを介して以前の状態にアクセスし、特別なアプリケーションを介して上書きバージョンまたは削除バージョンのファイルにアクセスする（を引き出す）。したがって、履歴データとディスクの現行のメインイメージとが合理的に区別される。ここで、ほとんど未使用なデータを保持している名前変更されたファイルの使用によって、特別なアプリケーションを履歴データに直接アクセスできるようにすることが可能であることに、注意が必要である。このためには、エンジン（またはＯＳ）と協調してデータの通常保護（例えばゼロ化）を無効とする必要がある。
【００６５】
重要なのは、アプリケーションが、ＯＳによって管理されユーザが利用可能な「通常」ファイルに単純にアクセスするのではなく、エンジン／ＯＳの履歴追跡からファイル（データ）を「抽出する」ためには、特別なアプリケーションが必要であるということである。
【００６６】
しかしながら、ほとんど未使用だとフラグされたディスク位置をＯＳで読み出す際に、エンジンがリターンデータを一般にゼロ化することには、最も重要な理由が存在する。この理由は、メインイメージと履歴データとを明確に区別することが何故重要なのかに関する前述の議論にある。履歴データとメインイメージとの混合が可能となると、そこに僅かな相互依存を生じるため、履歴データを実際に解放した際には、その相互依存が全て切断されることになる。ここで、履歴データの解放が永続的で不可逆性であることに、留意する必要がある。履歴データを追跡するのは、定義によってある程度の可逆性をユーザに提供するため、つまり、一定期間中に幾らかのデータを取り戻せるようにするためである。ユーザが不可逆性の動作により深く関わるようになると、エンジンの目的が部分的に弱まってしまう。
【００６７】
以下に挙げる実施例は、メインイメージとの関連でＯＳによってなされる一般アクセスからゼロの履歴データを戻し、または履歴データを隠すことの、重要な理由の１つを示している。すなわち、大量のデータを永久に消去するダイアログにおいて、ユーザは意識的または無意識にＯＫをクリックする。まさにこの状況において、エンジンは、ある程度の可逆性を提供することを期待される。履歴追跡システムがＯＳのトップに実装されていると、履歴データを含んだファイルをＯＳが失う結果をもたらす動作またはバグは、致命的なものとなる。
【００６８】
しかしながら、ＡＴＦ方法は、それ自身ＯＳの複雑性から隔離されているのが一般的である。ここで、大量のディスク記憶領域がほとんど未使用であることをエンジンに合図したプログラム（またはウィルス）に対し、ユーザがＯＫをクリックした場合を考える。ただし、この通信はＯＳに対してなされたのではないため、影響を受けた記憶領域は、依然としてＯＳによるアクセスが可能である。ＯＳがデータにアクセスしてエンジンがそれをゼロ化しなかった場合は、ユーザから見ると、そのディスクの内容に問題はないように思える。しかしながら、少なくともエンジンから見ると、ユーザは、メインイメージの一部としての履歴データに知らずにアクセスしていることになる。後になって、エンジンがこの履歴データを解放して再使用すると、ディスクのメインイメージであったものが、突然且つ不可逆的に変化する。さらに、エンジンを使用して時間を遡っても、ユーザやＯＳが表示するメインイメージは再現されない。
【００６９】
一方で、ＯＳによる読み出しの際に履歴データを強制的にゼロ化すると、時間を遡る際に、メインイメージが整合性を保って完全に復元される。履歴データとメインイメージデータの相互依存は、合理的に回避される。このため、上述した筋書きでは、ユーザがＯＫをクリックし、データの多くがほとんど未使用（履歴）であることをフラグされると、そのデータが有効にゼロ化される。したがって、ユーザは、自身のアクションが引き起こす実際の結果を直ちに経験し、そのアクションをエンジンによって取り消すことができる。つまり、エンジンが提供する履歴経年処理によって失われたデータを検索するために、ユーザがメインディスクを介してデータの「損失」を実際に経験する、ということが非常に重要である。
【００７０】
したがって、ほとんど未使用な記憶領域をエンジンに通知するＯＳのアクションが、ＯＳが後に読み出そうとするデータをエンジンによって有効にゼロ化することを、必ず伴うことが推奨される。ここで、ほとんど未使用な記憶領域の履歴内容が、実際にはゼロに設定されないことに注意する必要がある。履歴データにアクセスする方法は、特別なアプリケーションを介して許容可能である。
【００７１】
例えばアプリケーションは、エンジンおよびＯＳによって管理されるデータを利用して、ディスクの以前の状態を再構築したり特定のファイルを検索したりする。この筋書きは、ほとんど未使用なものとして記憶領域を保存するのに使用されているファイルの、ゼロ化されていない実際の内容に、特別なアプリケーションを介してアクセスすることを単純に許可することによって、特定のファイルを復旧することを含む。より厳密に言うと、特定ファイルの以前の状態にアクセスするこの方法は、ＯＳで管理されているように、この状態を保持しているファイルの内容へのアクセスを許可することを含む。この方法は、ディスク全体を、望ましいファイルの検索元の仮想ドライブとして有効に再構築するアプローチと異なり、それを簡略化したものである。ＯＳがほとんど未使用の記憶領域に突然上書きしてしまった、すなわちＯＳが自身の履歴追跡を破壊してしまったことをエンジンが検出した場合は、一般に、この簡略化された方法を採用するべきでない。しかしながら、エンジンは依然として、Ｔｅｍｐ方法を介して以前のディスク状態へのアクセスを提供することができる。
【００７２】
ここで、ＯＳが、ほとんど未使用な記憶領域を直ちにエンジンに通知することを望まなかったりできなかったりする可能性があることに、注意する必要がある。ＯＳは、アプリケーションによって解放されると同時に記憶領域を収集して、関連付けられたディスク位置および他の情報とともに、後ほどエンジンに引き渡すことを選択しても良い。
【００７３】
次に示した表２は、ＯＳおよびエンジンによる関連処理の概略を示したものである。
【００７４】
【表２】
ＡＴＦ方法の的確な特徴の１つは、ほとんどおよび真に未使用な記憶領域の追跡に関連してＯＳとエンジンとが非同期であっても、一般に何の悪影響も及ぼさないということである。次に示した表３および表４は、同期条件からの種々の出力およびその結果を示したものである。ここで、情報を「失う」という表現が、その情報が単にＯＳとエンジンの間で上手く転送されないことを暗示していることに、注意する必要がある。これには、その情報が、全く上手く転送されず、ディスクへの不完全な状態／データフラッシュの一部として失われた場合を含む。
【００７６】
【表３】
【表４】
次に示した表５および表６は、記憶領域を分類することができる３つの状態、およびこれらが各状態から別の状態へとどのように移行するかを示したものである。
【００７９】
【表５】
【表６】
ＴＵＵＮマップは、メイン領域マップの一部として実装されることができる。換言すると、ＯＳがディスクにアクセスするのに伴って指定位置をメイン領域マップに通すのは、保留中の宛先変更があるかを見るためだけでなく、ほとんどまたは真に未使用な記憶領域がアクセスされているかを見るためでもある。しかしながら、メイン領域マップが破損される可能性があり、そうすると再構築が必要となるため、ＴＵＵＮマップの再構築もまた必要となる。ＡＴＦの設計では（第２の工程で）手短に宛名を変更できるため、当座はＴＵＵＮマップの再構築の問題を無視することにする。ただし、真に未使用な場合に真に未使用でないとするような、誤った位置分類の原因となる最新の情報損失は、無害であるのが一般的であり、転用が不要な場合に書き込みを転用させる結果をもたらす。
【００８２】
許されないのは、ユーザ（ＯＳ）が、真に未使用な位置ＬＬに何らかのデータＤＤを書き込めることである。すると、この位置が真に未使用な状態から移行するが、この移行はなんらかの故障が原因で破損される。ＬＬの内容をＤＤに変更することが許可され、ＯＳでこの新しい値を読み出すことができる一方で、エンジンが真に未使用であるとフラグされた位置を依然として有していると、望ましくない状況が生じる。問題は、ユーザがこの新しいデータＤＤ（重要なファイルである）の存在に依存するようになるのに関わらず、後になってＯＳが再び位置ＬＬへの書き込みを行うと、エンジンがその書き込みを直接通すために、データＤＤが上書きされて永久に失われることである。解決策の１つは、すでに議論したように、エンジンによって真に未使用であることをフラグされた位置全てに対してゼロデータを戻すように強制することである。したがって、この場合、真に未使用な状態が破損されるとデータＤＤもまた破損されるため、ユーザが、データが存在していて安全である（もし上書きされたならば追跡されている）と誤解することはない。
【００８３】
エンジンが、真に未使用な状態からメイン領域の状態にランダムに破損されることは考えられないが、クラッシュ時に、一連の書き込みの末端が廃棄される可能性はある。つまり、真に未使用な位置のなかには新しいデータで上書きされるものもあるが、ディスク上のＴＵＵＮマップが更新されるまでは、コンピュータがクラッシュした際にエンジンが復元するのは、安定ではあるがＴＵＵＮマップの更新以前の状態である。したがって、新しいデータがディスクに書き込まれたものの、エンジンにその移行を記録する時間がなかったため、コンピュータは、あたかも新しいデータがディスク上に書き込まれなかったかのように復元される。
【００８４】
ほとんどおよび真に未使用なビットが、幅広い範囲のディスク位置に跨って変動する（変化する）ことから、ＴＵＵＮマップは、ビットマップとして実装されることが好ましい。コンピュータが納品された最初の時点では、ディスクの大部分が真に未使用な状態である。しかしながら、データがロードされて更新されるのに伴って、幅広い範囲に跨る多数のビットが変更される。したがって、マップはまばらであるとは考えにくい。ある状態から別の状態への安全な移行と、ＴＵＵＮマップの耐障害性とを考慮すると、何らかの形の円形表を追加することが推奨される。真に未使用な位置が、上書きされてメイン領域の位置に移行すると、ＴＵＵＮマップが更新されて、対応のエントリが新しい円形表に加えられる。この新しい円形表への追加は、ＡＵＯＳ表とともに、あらゆる更新の後に比較的高速でディスクへとフラッシュされる。一方のＴＵＵＮマップは、クラッシュ時に再構築できると想定されるため、システムのシャットダウン時にのみフラッシュされる。これによって、更新且つキャッシュされたＴＵＵＮマップページを数多く生じる頻繁なフラッシュが回避される。
【００８５】
上述したように、現在のディスクドライブには、性能向上を目的とした書き込みキャッシュが含まれるのが通常である。これらの書き込みキャッシュは、書き込みを一時記憶領域に入れて、書き込みと異なる順序でデータをディスク媒体に引き渡す。この処理は、例えばディスクコントローラを、ディスクヘッドの動きを低減する順序で実際のデータ書き込みを行えるようにすることによって、書き込み処理全体を高速化することができる。しかしながら、ＴＵＵＮマップや履歴ヘッダデータなどの内部のバックアップデータは、ディスク上にすでに存在すると想定されるデータ（依然として書き込みを待機中）より前に、ディスク上で更新され得る。電源異常が発生すると、ある安定な状態から別の状態への安全な移行が不可能となってしまう。
【００８６】
エンジンに書き込みキャッシュのフラッシュ制御能力がないことを想定すると、キャッシュによって、クラッシュ時に難しい問題が提起される。例えば電源異常によって、書き込みキャッシュの一部が永遠にディスク上に書き込まれなくなるかもしれない。エンジンの問題点は、ディスクに書き込まれたデータと書き込まれなかったデータが存在する場合に、書き込みキャッシュ側の要因によって、エンジンがデータを書き込んだ順番とデータがディスクに到達した順番とが対応しないということにある。したがって、エンジンがディスク位置１，２，３への書き込みを行った後にクラッシュしたとすると、位置１，３は更新されたが位置２は更新されなかったという事態が生じ得る。
【００８７】
部分的に失われてもなお完全に有用なデータ構造はほとんどないため、本発明では、ディスクに書き込まれるデータ保全性を確実にする手段として経年処理を使用する。書き込みキャッシュのアルゴリズムは、一般に、ディスクへのデータのコミットが無制限に先送りされる（hold off）ことはないことを想定している。これは、コンスタントな読み出しおよび書き込み活動を行う場合であっても同様であると想定される。そうでないと、書き込みに「最適な」時間を待機するデータが書き込みキャッシュ内に詰まり、朝書き込まれたデータが数時間後になってもディスク媒体に到達しない事態が考えられる。本発明は、ディスクコントローラにページを書き込むに当たり、一定の最小時間（待ち時間）の経過後にはそのページがディスク媒体に実際に書き込まれる（そして、クラッシュ時には不揮発性の記憶領域に保存される）ことを想定して構築されている。
【００８８】
したがって、本発明は、過去の最小待ち時間内にデータがディスクコントローラに書き込まれた場合にのみデータの経年処理を使用し、回復（システム再始動）との関連でデータをトラステッドにする。ディスクコントローラに書き込まれたデータブロックには、何らかの形態の時刻スタンプまたは時刻点が含まれることができる。ここで、１つのブロックは複数のディスクページからなる。最小待ち時間後に書き込まれた続く時刻スタンプまたは時刻点が発見された場合、ブロックは、ディスク媒体に完全に転送されたと想定される。時刻スタンプは、ブロックの読み出しに直接対応する値である。２つの時刻スタンプを比較することにより、表された時間間隔の長さを決定することが可能となる。これに対して時刻点は、前の時刻点から待ち時間分が経過したことを単純に示すものである。
【００８９】
ディスクコントローラにどれだけの量のデータが転送されたかを監視することにより、待ち時間を概算することができる。ディスクコントローラへの転送速度が周知であるため、この転送速度を待ち時間で掛けて、所定ページの書き込み後に転送されるべきデータの量を算出し、このページが確かにディスク媒体に書き込まれたことを保証することができる。これは、転送が連続して行われることを想定している。
【００９０】
事前に書き込まれたデータが、適切な待ち時間の経過後にディスクに実際に到達するという仮定は、特定のディスクコントローラには当てはまらない。このような場合は、代替の方法が使用される。ここで、エンジンは、所定の書き込み以降、ディスクコントローラがその書き込みキャッシュをディスクにフラッシュするのに十分な「自由時間」があったことを保証するものである。エンジンは、ディスクコントローラへの平均転送回数をモニタすることができる。この平均転送回数は、既知または概算の最大転送速度（ディスク媒体で実際にデータの読み出しまたは書き込みを行える速度を反映している）と比較されて、書き込みキャッシュがフラッシュされていることが妥当か否かが決定される。フラッシュが必要である場合は、充分な量の自由時間が引き渡され、エンジンは単純に遅延（または、ディスク活動の突然の休止を回避するための一連の短い遅延）を挿入することができる。最悪の場合は、ドライブの転送速度を、非常に大きい（どんな適度なキャッシュサイズよりも遥かに大きい）データブロックの読み出しおよび書き込みを行うタイミング調整プログラムから推察することができる。ここで、転送の回数、相対的な接近性、およびサイズが全体の転送速度にそれぞれ個別に影響を及ぼすことから、ドライブの転送速度の計算でこれらの各要素を考慮するべきであることに、注意する必要がある。つまり、ディスクヘッドを物理的に動かすまでの各転送の開始に関連付けられた時間と、ディスク媒体に実際にデータを転送するのにかかる一定の時間とが存在する。
【００９１】
ディスクコントローラのキャッシュをフラッシュする自由時間方法への類似点は、キャッシュをコップで水を加えるバケツに譬えられることである。バケツの底には穴が１つ空いており、一定速度での排水を可能としている。穴から流出する水は、ディスク媒体にデータを書き込むディスクコントローラと同等である。コップで水を加える処理は、ディスクコントローラにデータを書き込む動作と同等である。もしバケツが満杯であれば、待機する必要がある。ディスクコントローラからのデータの読み出しは、穴を一時的に塞ぐことと同等であり、何も排出されたり追加されたりしないまま、時間だけが経過する（読み出しキャッシュは書き込みキャッシュから独立していると仮定する）。ここで、書き込みキャッシュをフラッシュする状況は、バケツに加えられた一杯の水が排出されたかを刻々と保証する必要がある状況と非常に似通っているが、実際にバケツの中をのぞいたり、バケツがまだ排水しているかを検知したりすることはできない。さらに、水を１カップ分だけバケツに加えると、この水は、続けて加えられる水とも前に加えられた水とも混合する。
【００９２】
問題の水が本当に排出されたかを知る唯一の方法は、水を加えた後のある時点において、バケツが一時的に完全に排水されるようにすることである。バケツの中身を見たり、まだ排水中かを知ったりすることができないため、これをいつどのように実施するかは難しいところである。つまり、キャッシュがフラッシュされたかをディスクコントローラに尋ねる現行の標準インターフェースは存在しない。解決策の１つとして、水がバケツから排出される最悪の場合の速度を決定することが挙げられる。これは、バケツが満杯になって待機を強制されるまで、可能な限り高速で水を加え続けるという試験を行うことによって達成される。この時点以降は、バケツに余裕ができる（次のカップを受け付る）たびに水を加え続け、その速度を測定すれば良い。この処理によって、バケツの「緩衝」効果を効果的に無効とすることができ、実際の排出速度（またはディスクコントローラがキャッシュを空にする速度）が測定される。
【００９３】
バケツの排水速度がわかれば、水を加える速度をモニタすることができる。加えた水を確実に排出したい場合は、新しい水を加えるよりバケツの排水の方が速くなるように、次に水を加える速度を遅くする必要がある。算出可能なある時点では、ゆっくりであるにもせよ水を加え続けているのにも関わらず、バケツが完全に排水される。もちろん、さらに１カップ分の水を加える前にバケツを直ちに確実に排水させたい場合は、単にバケツの排水に必要な算出時間分だけ待機することができる。事実、バケツに水を加える速度を連続的にモニタすることにより、排出が必要な水を加えた時点でバケツがどのくらい満杯だったかを、ある程度把握することができる。これによって、遅延の低減が可能となる。もちろん、近似を行うこの環境では、遊びをたくさん設ける必要がある（例えば、完全に排水するのに１秒間必要だと考えるならば、２秒間待機して、計算で生じる僅かな誤差を全てカバーする）。
【００９４】
このバケツへの譬えは、書き込みキャッシュをフラッシュする自由時間方法を表している。ここで、バケツが空になる速度は、書き込みキャッシュがフラッシュされる速度に等しくて、シーク時間および転送速度の関数であることに、注意する必要がある。したがって、書き込みキャッシュにおけるデータのディスク接近性（disk proximity）、すなわちディスク上で書き込まれるべき位置は、キャッシュのフラッシュに必要な時間に大きく影響する。つまり、ディスク媒体上の１領域にたくさんのデータを書き込むのに必要な時間は、媒体全体に渡って少しずつ書き込むのに比べて遥かに短くてすむ。しかしながら、最悪の場合のフラッシュ速度として計時および使用できるのは後者の場合であるので、一般的な実際の速度を認める方がずっと良い。ディスクコントローラによって最初にキャッシュから書き込まれるデータがどれかを推測することができないため、ディスクコントローラに書き込まれたページ位置をモニタして、シーク時間対転送時間の比を予測し、現行の予測フラッシュ速度を動的に生成することは不可能である。
【００９５】
再びディスクコントローラの件に戻り、次に問題となるのは、書き込みキャッシュのフラッシュを確実にするにはいつ遅延を挿入するか、ということである。書き込みの転用を行う工程がある。ユーザは一般に、ディスクの活動が一時休止する時点（安全点）を選択してアクセスすることしかできない。こうして、変更処理中の過去の時点からデータにアクセスすることが回避される。したがって、一時休止が充分に長い限り、書き込みキャッシュのフラッシュは安全点の識別に固有である。クラッシュ後にコンピュータを再起動する際に、ユーザは、安全点である過去の時点に復帰したり、単にクラッシュ直前の状態でディスクを使用したりする選択肢を有する。後者の場合、エンジンは、ディスク活動が一時休止をしていない時点までデータ構造を回復させる。つまり、クラッシュが、一連の長いディスク活動の中間で生じた場合である。フラッシュ方法に基づいた待ち時間を使用すると、クラッシュ前の待ち時間までに書き込まれたデータが全て存在することになる。しかしながら、ディスクコントローラがトラステッドされず、待ち時間後実際にディスク媒体にデータを書き込むことができないと、エンジンは、ディスク活動中最後に記録されたフラッシュ時刻点より以前に書き込まれたデータを全て廃棄するしか方法がない。つまりエンジンは、充分な長さの自由時間が経過したことを決定し、データブロックが実際にディスク媒体に転送されたことを保証するとともに、適切な時刻マーカを書き出す。この時刻マーカがディスク媒体上に到達すると、ブロックの妥当性が確立される。クラッシュからの回復時には、媒体に書き込まれたが続く時刻マーカを有さないデータが、データの一部が失われているかもしれないとして廃棄される。ユーザは実際には、クラッシュ時に書き込み中だったまたはクラッシュ時にちょうど書き出されたところだったデータに興味を示さないのが一般的であるため、このデータの廃棄が問題になることはない。
【００９６】
フラッシュが必要な別のエンジン活動は、ディスクの内容が再配置（スワップ）されている場合である。この処理は、特定の時点でディスクにフラッシュされて、耐クラッシュ性となる（クラッシュ発生時にデータを損失することなく再開できる）ことを前提とした、明確な転送工程を含む。データが大量に移動するために、多くの時点でフラッシュを行わなければならない可能性もある。したがって、この活動の最中は、特定の時点で遅延を生じることにより、ディスクへの書き込みがなされたことを確証する必要がある。
【００９７】
適度に有効なスワップ工程の簡単な実施例では、５０メガバイトのスワップ領域を使用する。平均１メガバイト毎秒の転送速度では、このデータを全て書き込むのに５０秒間かかる。ディスクコントローラが１メガバイトの書き込みキャッシュを有する場合は、そのキャッシュをディスクにフラッシュするのに１秒間の自由時間が必要である。したがって、５０メガバイトのスワップ領域を書き込んだ後のある時点で、ディスクコントローラに対するディスク転送の（累積）遅延を１秒間挿入し、１メガバイトのキャッシュが（１メガバイト毎秒で）確実にフラッシュされるようにする。スワップ領域の書き込み５０秒間に対して１秒間の遅延は妥当な比率である（２％の性能ヒット率[performance hit]）。
【００９８】
ここで、この比率を妥当なものとする重要な要素の１つは、ディスクへのフラッシュとして知られる時点と時点の間に書き込まれるデータの量が大きくて良いこと（前の実施例では５０メガバイトを使用した）である点に、注意する必要がある。これに反し、フラッシュが必要とされるまでに１メガバイトしか書き込まれなかった場合は、データ転送にかかった時間と挿入された遅延との比が望ましい値でなくなる（１秒間の書き込み後に１秒間の遅延が続く、すなわち５０％の性能ヒット率）。（有効な）フラッシュ間に書き込まれる領域が大きい必要があることから、上述したようにエンジンは、所定のディスク位置が修正を必要とせず、その後にフラッシュとフラッシュ間で大領域を書き込むより速い速度で行われる修正とが続くように、設計される。
【００９９】
スワッピングは一般に、バックグラウンドで行われ、ユーザが要求したディスク活動による割り込みが可能である。スワッピング処理において、自由時間に基づいたフラッシュが必要とされ且つユーザがディスク活動の切り離し（バースト）を開始する場合は、ユーザ活動の完了後に必要な遅延が単純に挿入される。
【０１００】
書き込みキャッシュのフラッシュは、ほかに、履歴バッファが高速で上書きされている場合と、逸脱処理が中断されている場合と、システムがシャットダウンしている場合とに必要である。これらの事態は、いずれも頻繁に生じるものではないため、ある程度の遅延を加えても一向に構わない。
【０１０１】
データブロックがいつ有効であるかをディスク上で示す方法の１つは、充分な長さの待ち時間またはディスク活動の自由時間が経過した後に、スタンプや時刻点などの結びフラグ（concluding flag）を書き出すことである。
【０１０２】
図１は、システムの代表的な初期状態を示したものである。「メイン領域ページ」と題された第１の列は、メイン領域の内容を示している。位置＃１〜＃５はデータを含み、位置＃６〜＃９はＯＳによる割り当てを受けていない。エンジンは、ＯＳがこれらの非割り当て位置を読み出した際にゼロ化データを戻す。「マップ／ＴＵＵＮ」と題された次の列は、ＴＵＵＮマップと、ＯＳ指定のディスク位置を実際の物理位置に変換するメインマップとの、複合状態を示している。空のボックスは、マッピングが不要であることを示す。「真」という状態は、関連のＯＳ位置が真に未使用であることを示す。「エキストラページ／履歴ヘッダ」と題された第３の列は、エキストラページ領域の内容と、その関連の履歴ヘッダとを示している。列の頂上部に示された矢印は、次の書き込み位置を示す。「ＡＵＯＳ」と題された最後の列は、ほとんど未使用なＯＳ記憶領域の追跡をエンジンに依頼するためにＯＳから発信された、エントリを表している。履歴ヘッダおよびＡＵＯＳ表は、最初は何の情報もトラックしていない。
【０１０３】
図２では、ＯＳが位置＃１への書き込みを行うため、値「ＤＩ１」が値「ＤＩ２」で上書きされる。エンジンは、この書き込みをエキストラページへと転用し、履歴ヘッダ内にメモを作成する。いくらかの自由時間を与えられた後、最終的には、転用後の新しいデータともとの履歴データとが交換（スワップ）される。位置＃１からのＯＳ読み出し要求を指定のエキストラページへと転用するメインマップには、エントリが１つ追加される。
【０１０４】
図３では、ＯＳが、「ＦＡ１」を含んだ位置＃２を解放する。これは例えば、もとの内容が位置＃２にあったファイルの内容を、ユーザが置き換えることによって生じ得る。ＯＳは、ＯＳの汎用割り当てプールに位置＃２を戻す代わりに、その記憶領域を保留し、その旨をエンジンに通知する。するとエンジンは、ＴＵＵＮマップを更新し、ＡＵＯＳ表にエントリを１つ追加する。ファイルの新しい内容が書き込まれると、その新しいデータ「ＦＡ１Ｂ」は、次に利用可能なＯＳ位置＃６に配置される。エンジンとＯＳとが、この位置が真に未使用であることに同意しているため、データは（エキストラページに転用される代わりに）直接その場所に書き込まれる。図２で生じた書き込みと異なり、図３での書き込みは保留スワップを必要としない。
【０１０５】
図４は、４つのアクションの結果を示している。先ず第１に、位置＃３が、ＯＳによって新しいデータ「ＦＢ１Ｂ」で上書きされる。第２に、データ「ＦＣ１」および「ＦＣ２」を含んだ位置＃４および＃５が、ＯＳによってほとんど未使用な状態に移行する。第３に、位置＃１が、ＯＳによって新しいデータ「ＤＩ３」で上書きされる。位置＃３および＃１を上書きした第１および第３のアクションでは、各書き込みがエンジンによって転用される。位置＃４および＃５がほとんど未使用な状態に移行する際には、エンジンによってＴＵＵＮマップおよびＡＵＯＳ表が更新される。これら２つの位置の解放は、例えばユーザがファイルを削除することによって生じ得る。続く第４のアクションでは、ＯＳが、位置＃７および＃８に新しいデータ「ＦＤ１」および「ＦＤ２」を書き込む。この上書きは、ユーザが新しいファイルを作成してそのファイルに「ＦＤ１」および「ＦＤ２」を書き込むことによって生じ得る。ＯＳは、続く２つの真に未使用な位置を選択し、新しいデータ（＃７および＃８）を受信する。ＴＵＵＮマップは更新されて、位置＃７および＃８はもう真に未使用だとは示されず、空のボックスは、マッピングが不要な状態を表している。
【０１０６】
この実施例の次の工程は、ＯＳが、割り当て可能な（真に未使用な）記憶領域において低いことを認識していることを前提とする。ＯＳはエンジンに対し、ほとんど未使用であるとしてＯＳが以前に保留した記憶領域の位置（またはＯＳラベル）を、信号で返すことを要求する。図４において、システム内で最も古い履歴データは、図２で生じた第１の転用である。しかしながら、この履歴データを保持するのに使用される記憶領域（保留スワップが実行されたと想定する）は、アクセス可能なＯＳ領域より外側のエキストラページ領域にある。次に古い履歴データは、図３で作成されたＡＵＯＳメモである。この記憶領域は、ＯＳによって戻されて使用されることができる。しかしながら、ギャップを超える（時間を遡る）データが、ギャップ内にあったデータに依存したかもしれず、一般に使用不能であるため、履歴ログ内にギャップを設ける理由はないのが一般的である。
【０１０７】
したがって、２つの選択肢が可能である。１つ目としては、エンジンは、ＯＳに戻すことができるＡＵＯＳ記憶領域を獲得するまでは、エキストラページ領域内の履歴データを廃棄または「トリム」することができる。２つ目としては、エンジンは、ＡＵＯＳ記憶領域を早めに戻すが、このような記憶領域のＯＳによる再使用を保存が必要な上書きデータとして扱うことによって、転用を行うことができる。
【０１０８】
図５は、第１の選択肢すなわちトリミングを示している。ここでは、データ「ＤＩ１」の履歴追跡が廃棄（トリム）される。この廃棄は、「ＤＩ２」をエキストラページ領域からメイン領域の位置＃１へと強制的にスワップさせることを含み、位置＃２は、エントリがＡＵＯＳ表から取り除かれるのに伴って、真に未使用な状態へと移行する。ＯＳが位置＃２を割り当てて、この位置にデータを書き込む際には、エンジン（およびＯＳ）によって廃棄された古い履歴データを上書きし、直接データを書き込むことができる。
【０１０９】
図６は、第２の選択肢すなわち転用を示している。ここでは、エントリがＡＵＯＳ表から取り除かれ、それに伴ってＯＳが通知を受ける。しかしながら、影響を受ける位置に関しては、ＴＵＵＮマップが「早期」状態に更新される。これは、この位置には、ディスクの過去の状態を再構築する目的で、エンジンが必要とする履歴データが含まれるため、ＯＳがこの位置を上書きしようと試みると、履歴データを保存するために変更が転用されることを意味する。ある位置をフラグで「早期」と示す必要があるということは、ＯＳがこの位置を読み出そうと試みると、ゼロ化されたデータが戻されることを意味する。これによって、ＯＳによる履歴データへのアクセスが回避される。ここで、この「早期」状態が、ほとんど未使用な記憶領域を早めに解放することを含む上記解決策の一部として導入されたことに、注意する必要がある。
【０１１０】
上述した「トリム」および「方向変換」の方法が利用されるのは、履歴が発生順のイベント列であるためである。これに固有なのは、ある履歴ログの異なる部分を記録した２つの「ブック」が、これらのブックの組み合わせによって完全な履歴を知り得る限り、完全な履歴を表すことができるという事実である。しかしながら、この実施例が示しているように、完全な履歴は、必要な全ソースからの全情報が利用可能である時点までしか遡ることができない。ＡＴＦ方法の場合は、履歴ログのうち、一部がエキストラページ／履歴ヘッダシステムで追跡されて、別の部分がＯＳおよびＡＵＯＳシステムで追跡される。これら２つのシステムは、ＯＳがデータの上書きおよび／または解放ならびに割り当てを行う相対頻度に応じ、それぞれ異なる速度でデータの経年処理を行う。相対速度は、動的で任意の使用パターンに依存しており、保証がないのが一般的である。例えば、ＯＳによって生じているのがほとんど上書きである場合、エキストラページ／履歴ヘッダシステムは、大部分の履歴データの追跡を、ＯＳの制御下にある使用され得る記憶領域を一度も利用せずに行う。
【０１１１】
利用可能（真に未使用）なディスクスペースをフル活用するためには、１つの「ログ」を使用することが好ましい。ＴｅｍｐおよびＡｌｗａｙｓ方法におけるエンジンは、履歴の追跡に利用可能なディスクスペースの管理を、比較的完全に制御していた。これに対してＦｉｌｅ方法では、履歴追跡処理をＯＳに組み込むことを想定していた。このため、ＯＳは１つの履歴ログを効果的に維持していた。
【０１１２】
１実施形態において、ＡＴＦ方法は、記憶領域の大部分がＯＳから動的に取り出されてＯＳに動的に戻されるように、変更される。すると、図５に至る場面は、「ＤＩ１」を保持した（スワップが実行されたと仮定する）「エキストラページ領域」内の記憶領域の一部分を、エンジンが解放してＯＳに戻すことを含む。
【０１１３】
好ましい１実施形態において、ＡＴＦ方法は、組み合わされることにより必要な完全ログを形成する、２つの履歴ログを利用する。したがって、ＡＴＦ方法は、ＯＳ制御下の利用可能な「自由」スペースの一部分を利用するとともに、自身のエキストラページ領域を有することにより、ＯＳからの適度な独立性を維持する。ＡＴＦ方法は、自身による制御下に専用の記憶領域のブロック（履歴バッファ）を有することにより、簡潔性（およびＯＳからの相対的独立性）を達成する。ＡＴＦ方法は、記憶領域の割り当ておよび割り当て解除、ならびに履歴データの保守においてＯＳと協調することにより、性能の向上を達成する。
【０１１４】
実際は、履歴追跡のほとんどが、（履歴バッファよりも）エンジンおよびＯＳによる協調ハンドオフ処理を経るようである。しかしながら、何かの手違いが生じ、その変更の大部分が方向変換を必要とする上書きであった場合に、回復可能性を提供できるように、履歴バッファは充分に大きい必要がある。ディスクスペースが比較的高価であることを考慮すると、履歴追跡に割り当てられた記憶領域の半分が履歴バッファに割り振られ、もう半分が動的に取り出されてＯＳの割り当て可能スペースに戻されるように、ＡＴＦ方法を実装することが推奨される。履歴追跡の大部分がエンジン／ＯＳハンドオフ処理を経てなされることが判明すると、履歴バッファの使用が相対的に制限されるため、ＡＴＦ方法による過去への到達がいっそう可能となる。
【０１１５】
トリムまたは転用の選択肢に再び戻り、決定は、どれだけ時間的に遡ることが維持するのに妥当であるかを考慮してなされることが好ましい。履歴バッファの履歴データが非常に古いと予測される場合は、その履歴データを廃棄することができる。しかしながら、その履歴データが適度に新しく、履歴バッファに充分なスペースがある場合は、ＯＳに早めに記憶領域を戻し、書き込みを転用して、ＯＳによる再使用を処理することが最適となる。この際スワップ時間が追加されるが、回復可能性は保持される。ユーザによるＰＣの使用頻度が（履歴追跡に割り当てられた記憶領域の量に比して）低いことが判明した場合は、どんなイベントに対しても、一般に、より多くの履歴データが必要とされる、すなわち時間的により古く遡ることが必要とされる。
【０１１６】
再び図６に戻り、転用を行う決定がなされた。図７において、ＯＳは位置＃２を新しいデータ「ＦＥ１」で上書きする。この上書きは、位置＃２が履歴データを含むため転用される。位置＃７および＃８もまた、ＯＳによって新しいデータ「ＦＤ１Ｂ」および「ＦＤ２Ｂ」で上書きされる。そして最終的には、ＯＳが、真に未使用な記憶領域の位置＃９に新しいデータ「ＦＦ１」を書き込むため、エンジンは、そのデータを場所に直接書き込む。図８では、転用された全データをスワップする時間がエンジンにあったため、履歴バッファは履歴データのみを含み、「生の」データは場所に入る。したがって、これ以上のマッピングは不要である。
【０１１７】
図９は、データが移動し、少なくとも概念的にこの実施例の開始時（図１）に回復した場合の結果を示したものである。ここで、ある所定の位置がＯＳによって２度以上上書きされた場合は、その位置こそが復元された最も古い履歴データであるということに、注意する必要がある。ＡＵＯＳエントリを「復元させた」ことによる効果は、ほとんど未使用な状態を取り除くことであり、これは、影響位置がこれ以上強制的にゼロ化されるべきでないことを意味する。この復帰がＡＵＯＳエントリに跨らなかった場合は、復帰されたイメージにおいて影響位置がゼロ化される。
【０１１８】
図１０は図１の初期状態を示し、図１１は、データを全て場所に入れた場合の結果を示している。ここで、もとから真に未使用な位置であった場所には残留物が残されることに注意する必要がある。この残留物は、ほとんど未使用な記憶領域から真に未使用な記憶領域への移行を表すエントリが、履歴ログに含まれないことが原因で生じる。このため、他の種々の概念的要素が検討された。次に、残留物をアドレッシングするＡＴＦ設計の第２の工程を説明する。
【０１１９】
ＡＴＦの第２の工程
第２のＡＴＦ設計では、履歴ヘッダをＡＵＯＳ表と組み合わせ、真に未使用な移行のロギングを追加する。この組み合わせを達成するために、新しい履歴ヘッダと関連の円形表が作成された。これらの新しい履歴ヘッダは、履歴ヘッダエントリと異なり、エキストラページに直接関連付けられてはいない。したがって、方向変換タイプのエントリが追加されると、割り当てられたエキストラページが好ましく割り当てられて、リンケージが設定される。いずれも利用可能でない場合は、エキストラページが解放されるまで、新しい履歴ヘッダ表の他端からエントリを取り除くことができる。ここで、この処理が、ＡＵＯＳ記憶領域の解放という結果をもたらし得ることに、注意する必要がある。
【０１２０】
次に示す表７は、新しい履歴ヘッダおよびその関連の属性の、３つの形態をまとめたものである。
【０１２１】
【表７】
第２のＡＴＦ設計が、履歴ヘッダとＡＵＯＳデータとを組み合わせた表を使用していることから、図１２には、第１のＡＴＦ設計の実施例における初期状態を示した。「メイン領域ページ」と題された第１の列は、メイン領域の内容を示している。位置＃１〜＃５はデータを含み、位置＃６〜＃９はＯＳによる割り当てを受けていない。エンジンは、ＯＳがこれらの非割り当て位置を読み出した際にゼロ化データを戻す。「マップ／ＴＵＵＮ」と題された次の列は、ＴＵＵＮマップと、ＯＳ指定のディスク位置を実際の物理位置に変換するメインマップとの、複合状態を示している。空のボックスは、マッピングが不要であることを示す。「真」という状態は、関連のＯＳ位置が真に未使用であることを示す。「新しい履歴ヘッダ」と題された第３の列は、履歴ヘッダの内容を示しており、この履歴ヘッダは、「エキストラページ」と題された最後の列に示されるエキストラページ領域に関連付けられている。新しい履歴ヘッダ表は、エキストラページ領域から独立しており、さらに、ほとんど未使用なＯＳ記憶領域の追跡をエンジンに依頼するためにＯＳから発信された、ＡＵＯＳデータをも含む。図１２に示されるように、新しい履歴ヘッダは、最初は何の情報もトラックしていない。
【０１２３】
図１３では、ＯＳが位置＃１への書き込みを行うため、値「ＤＩ１」が値「ＤＩ２」で上書きされる。エンジンは、この書き込みをエキストラページへと転用し、新しい履歴ヘッダ内にメモを作成する。そして、自由時間が生じたら、転用後の新しいデータともとの履歴データとを交換（スワップ）する。スワップが生じた後、新しい履歴ヘッダ表は、転用が生じて新しいデータ「ＤＩ２」が位置＃１に配置されたことを示す、１つのエントリを含む。また、このエントリは、エキストラページ領域内で古いデータ「ＤＩ１」が含まれる位置も示している。
【０１２４】
図１４では、ＯＳが、「ＦＡ１」を含んだ位置＃２を解放する。これは例えば、もとの内容が位置＃２にあったファイルの内容を、ユーザが置き換えることによって生じ得る。ＯＳは、ＯＳの汎用割り当てプールに位置＃２を戻す代わりに、その記憶領域を保留し、その旨をエンジンに通知する。するとエンジンは、ＴＵＵＮマップを更新し、位置＃２が今では履歴データを含んでいることを示すエントリを、新しい履歴ヘッダに１つ追加する。
【０１２５】
図１５に示されるように、ファイルの新しい内容が書き込まれると、その新しいデータ「ＦＡ１Ｂ」は、次に利用可能なＯＳ位置＃６に配置される。エンジンとＯＳとが、この位置が真に未使用であることに同意しているため、データは（エキストラページへと転用される代わりに）直接その場所に書き込まれる。図２で生じた書き込みと異なり、図３での書き込みはスワッピングを必要としない。また、位置＃６において、履歴データを何ら保存することなく直接の書き込みが生じたことを示すエントリが、新しい履歴ヘッダ表に１つ作成される。
【０１２６】
図１６は、２つのアクションの結果を示している。先ず第１に、位置＃１が、ＯＳによって新しいデータ「ＤＩ３」で上書きされる。第２に、位置＃３が、ＯＳによって新しいデータ「ＦＢ１Ｂ」で上書きされる。位置＃１が上書きされるに際には、エンジンは先ず、次に利用可能なエキストラページ、すなわちこの場合はエキストラページ領域の第２の位置へと新しいデータ「ＤＩ３」を転用させ、次いで、余分な時間がある時に、前の履歴データ「ＤＩ２」を新しいデータ「ＤＩ３」とスワップする。同様に、位置＃３が上書きされるに際には、エンジンは先ず、次に利用可能なエキストラページ、すなわちこの場合はエキストラページ領域の第３の位置へと新しいデータ「ＦＢ１Ｂ」を転用させ、次いで、余分な時間がある時に、前の履歴データ「ＦＢ１」を新しいデータ「ＦＢ１Ｂ」とスワップする。図１６は、データのスワップが生じた結果の構成を示している。
【０１２７】
図１７は、データ「ＦＣ１」および「ＦＣ２」を含んだ位置＃４および＃５が、例えばユーザがファイルを削除したために、ＯＳによってほとんど未使用な状態に移行する状況を示している。位置＃４および＃５がほとんど未使用な状態に移行すると、エンジンは、ＴＵＵＮマップおよび新しい履歴ヘッダ表を更新する。
【０１２８】
図１８は、ＯＳが、位置＃７および＃８に新しいデータ「ＦＤ１」および「ＦＤ２」を書き込む状況を示している。この上書きは、ユーザが新しいファイルを作成し、そのファイルに「ＦＤ１」および「ＦＤ２」を書き込むことによって生じ得る。ＯＳは、続く２つの真に未使用な位置を選択し、新しいデータ（＃７および＃８）を受信する。ＴＵＵＮマップは更新されて、位置＃７および＃８はもう真に未使用だとは示されず、空のボックスは、マッピングが不要な状態を表している。また、位置＃７および＃８において、履歴データを何ら保存することなく直接の書き込みが生じたことを示すエントリが、新しい履歴ヘッダ表に１つ作成される。
【０１２９】
図１９は、位置＃２がＯＳの要求によって戻された状況を示している。ＴＵＵＮマップ内の関連の位置が「早期」状態に更新される。これは、ディスクの前の状態を再構築するためにエンジンが必要とする履歴データが、この位置に含まれることを示している。このため、ＯＳが位置＃２を上書きしようと試みると、履歴データ「ＦＡ１」を保存するために変更が転用される。上述したように、「早期」であるとフラグされた位置をＯＳが読み出そうと試みると、ゼロ化されたデータが戻される。これによって、ＯＳによる履歴データへのアクセスが回避される。
【０１３０】
図２０は、ＯＳが位置＃２を新しいデータ「ＦＥ１」で上書きする状況を示している。位置＃２が履歴データ「ＦＡ１」を含むため、この上書きは、先ずエキストラページ領域へと転用される。次いで、時間がある時に、履歴データ「ＦＡ１」を新しいデータ「ＦＥ１」でスワップする。図２０は、スワップが生じた後の結果構成を示している。上述した転用後の書き込みのように、新しい履歴ヘッダ表は更新されて、転用が生じたことを示す。この新しい表では、位置＃２に新しいデータが配置されて、関連の履歴データを含んだエキストラページへのリンクが含まれる。
【０１３１】
図２１では、位置＃７および＃８が、ＯＳによって新しい値「ＦＤ１Ｂ」および値「ＦＤ２Ｂ」で上書きされる。エンジンは、この書き込みをエキストラページ領域へと転用し、新しい履歴ヘッダ内にメモを作成する。そして、自由時間が生じたら、転用後の新しいデータともとの履歴データとを交換（スワップ）する。
【０１３２】
図２２では、ＯＳが、位置＃９における真に未使用な記憶領域に新しいデータ「ＦＦ１」を書き込むことから、エンジンは、そのデータを場所に直接書き込む。図２２は、前の実施例の全工程が適用された（そしてスワッピングが実行された）後の、最終状態を示している。
【０１３３】
図２３〜３３は、新しい履歴ヘッダを段階的に「ポッピング」すなわち取り消して、カレントイメージを初期状態に復帰させる状況を示している。特に図２３は、図２２との関連で説明した最後の動作に復帰した結果を示したものである。エンジンは、新しい履歴ヘッダ表内の最新のエントリ、すなわり「真に＃９書き込み」を検討する（examine）。よってエンジンは、位置＃９に関連した位置のＴＵＵＮマップを、真に未使用であると記録する。さらに、ＯＳが位置＃９にアクセスすると、ゼロ化情報が戻されるようになる。ここで、エンジンがＯＳによって位置＃９にアクセスされてゼロ化データを戻す限り、位置＃９の実際の内容を消去する必要はないことに、注意する必要がある。
【０１３４】
図２４では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃７／８、古い」を検討する。このエントリは、転用が実行されて、位置＃７および＃８に新しいデータが格納されたことを示している。また、このエントリは、エキストラページ領域内に配置された古いデータへのリンクも含んでいる。したがって、位置＃７および＃８に、古いデータ「ＦＤ１」および「ＦＤ２」が書き込まれる。
【０１３５】
図２５では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃２、古い」を検討する。エンジンは、図２４との関連で説明したのと同様な方法によって、位置＃２に古いデータ「ＦＡ１」を書き込む。
【０１３６】
図２６は、新しい履歴ヘッダ表内の次のエントリ、すなわち「ＡＵＯＳ（早期）＃２」にエンジンが立ち戻った結果を示しており、これは、ＯＳが位置＃２を取り戻す要求をしたことを意味する。よって、ＴＵＵＮマップを変更し、関連の「早期」エントリを「ほとんど」エントリで置き換えることにより、位置＃２を、ＯＳからの要求以以前の状態に復帰させる。
【０１３７】
エンジンは次に、図２７に示された新しい履歴ヘッダ表内の次のエントリ、すなわち「真に＃７、＃８書き込み」を検討する。よって、エンジンは、位置＃７および＃８に関連した位置のＴＵＵＮマップを、真に未使用であると記録する。さらに、ＯＳが位置＃７および＃８にアクセスすると、ゼロ化情報が戻されるようになる。
【０１３８】
図２８では、新しい履歴ヘッダ表の次のエントリが検討される。エントリ「ＡＵＯＳ（追加）＃４、＃５」は、ＯＳが位置＃４および＃５を解放したことを示す。よってエンジンは、ＴＵＵＮマップを変更し、これらの位置に関連した「ほとんど」エントリを取り除くことにより、ＯＳによる位置＃４および＃５の解放以以前の状態に復帰する。
【０１３９】
図２９では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃３、古い」を検討する。このエントリは、転用が実行されて、新しいデータが位置＃３に格納されたことを示している。また、このエントリは、エキストラページ領域内に配置された古いデータへのリンクも含んでいる。したがって、位置＃３に、古いデータ「ＦＢ１」が書き込まれる。
【０１４０】
図３０では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃１、古い」を検討する。エンジンは、図２９との関連で説明したのと同様な方法によって、位置＃１に古いデータ「ＤＩ２」を書き込む。
【０１４１】
図３１は、次に最新の動作に復帰した結果を示している。エンジンは、新しい履歴ヘッダ表内の次のエントリ、すなわち「真に ＃６ 書き込み」を検討する。よってエンジンは、位置＃６に関連した位置のＴＵＵＮマップを、真に未使用であると記録する。さらに、ＯＳが位置＃６にアクセスすると、ゼロ化情報が戻されるようになる。
【０１４２】
図３２では、新しい履歴ヘッダ表の次のエントリが検討される。エントリ「ＡＵＯＳ （追加） ＃２」は、ＯＳが位置＃２を解放したことを示す。よってエンジンは、ＴＵＵＮマップを変更し、位置＃２に関連した「ほとんど」エントリを取り除くことにより、ＯＳによる位置＃２の解放以以前の状態に復帰する。
【０１４３】
図３３では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい＃１、古い」を検討する。エンジンは、図３０との関連で説明したのと同様な方法によって、位置＃１に古いデータ「ＤＩ１」を書き込む。図１１と異なり、図３３での最終結果は初期状態に一致する。したがって、この設計では、過去の様々な時点におけるＯＳ可視ディスクの再現を支援する必要情報を取り込むことができる。
【０１４４】
１実施形態では、新しいデータを追加するのと同様な方法で履歴エントリを追加することにより、ディスクを前の状態に復帰させることができる。この実施形態におけるエンジンは、上述した方法で履歴データを獲得する。しかしながら、これらのデータのディスクへの書き込みは、まるで新しいデータであるかのようにエンジンを使用して行われる。この方法では、履歴データの書き込みを再びエキストラページ領域へと転用した後、適切な安全点において、前の「現在の」データとスワップされる。この方法では、ディスクが上述した前の状態に復帰した後、ディスクの「現在の」状態が「履歴状態」となる。
【０１４５】
したがって、クラッシュ発生時には、システムの最新スナップショットと組み合わされた新しい履歴ヘッダ表から、現在のＴＵＵＮマップを再構築することができる。スナップショットは、新しい履歴ヘッダ表内のどこかの時点に対応する。スナップショットは、表からのスナップショット基準点におけるエントリまたは同基準点を超えたエントリを使用して実行されて、その現在の状態を再構築する。
【０１４６】
ＡＴＦ方法は、ファイルシステムの知識をある程度有しており、特定の履歴情報が、ＯＳによる高速なデータアクセスが可能な方法で維持される（すなわち、ファイルの古いヴァージョンが単に、名前を変更された一時ファイル内によけられる）。したがって、例えば、ほとんど未使用な記憶領域から非常に高速で特定のファイルを検索することができる。しかしながら、一般には、ほとんど未使用な記憶領域に直接アクセスするか、または部分的に同記憶領域に基づいて仮想ドライブを作成することにより、充分に高速な検索を提供することができる。
【０１４７】
ＡＴＦ方法には、Ｆｉｌｅ方法コンポーネントから取り入れられた大きな利点がある。これは、ファイルの内容を完全に置き換える等の、少なくとも特定タイプの動作に対して有効である。ＯＳは、記憶領域を保留することによって初期状態を保存するため、ユーザが同じファイルを素早く何度も上書きする場合、ＯＳは各ヴァージョンを全て保存する。これは、上書きヴァージョンがＲＡＭ内にのみ存在し、ディスクに実際に書き込まれることはない場合（あまりに素早く置き換えられるため）ですら生じ得る。安全点をファイル（およびその他の）活動に関連付ける汎用システムの活動記録ログは、置き換えられたファイル内容（データ）がどこに保留されたかに関するメモ（例えばＯＳラベル）を記録して、この情報を検索に使用することができる。これは、ＯＳが、単一の安全点内ではＡＵＯＳ記憶領域を再利用しないことを想定している。
【０１４８】
ＡＴＦおよびＡｌｗａｙｓ方法が、ソフトウェアに実装され破壊の可能性に曝されている場合は、ＡＴＦ方法を「放棄（walk off）」し、有用なディスクイメージを何らかの形態で得ることが合理的に可能である。方法を放棄するという概念は、そのアルゴリズムを、最低限のディスク変更によって使用不可とすることである。ＡＴＦ方法は、一般に、ＯＳ可視データを直接ＯＳ内において割り当て位置として保持するため、そのアルゴリズムを突然使用不可とすると、直接ＯＳが利用可能な状態に近い何らかのディスクが生じる。これに対し、Ａｌｗａｙｓ方法の永久的な再マッピングは、同方法がディスクから引き出された場合（すなわち、データにアクセスするためにマッピングを知る必要がある）に、ディスクが使用に適さない（スクランブルされている）ことを、かなりの程度で保証する。どちらかの方法がファイアウォールより後ろで作動している場合は、ディスクからの方法の放棄は適用されない。
【０１４９】
ＡｌｗａｙｓおよびＡＴＦ方法はいずれも、非標準のディスクデフラグソフトウェアと共に使用することができる。ＡＴＦ方法がディスクを自然な編成に維持する傾向にあることから、既存のデフラグプログラムを適用し、単純にエンジンのインターフェースを通して再配置する方が、容易に思える。これに対してユーザは、１つのデフラグユーティリティのみを必要とするのが一般的であり、このようなユーティリティは、ほぼ同様な試みを行ういずれの方法のもとでも提供することができる。
【０１５０】
以上では、理解を明確にする目的で本発明を詳しく説明したが、添付した特許請求の範囲を逸脱しない範囲内ならば、特定の変更および修正を加えられることは明らかである。したがって、本明細書で取り上げた実施形態は、例示を目的としたものであって、本発明の内容を限定するものではない。このため本発明は、本明細書で特定した詳細に限定されることなく、添付した特許請求の範囲の範囲および同等物の範囲内で、種々の変更を加えることが可能である。
【図面の簡単な説明】
【図１】代表的なシステムの初期状態を、本発明の１実施形態に従って示したブロック図である。
【図２】代表的なシステムにおいて、オペレーティングシステム（ＯＳ）が位置＃１に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図３】代表的なシステムにおいて、ＯＳが位置＃２を解放し、位置＃６に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図４】代表的なシステムにおいて、ＯＳが位置＃１および＃３に書き込み、位置＃４および＃５を解放し、位置＃７および＃８に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図５】代表的なシステムにおいて、ディスク位置を再生させるためにトリミングが実行された様子を、本発明の１実施形態に従って示したブロック図である。
【図６】代表的なシステムにおいて、ＯＳが位置＃２を再生した様子を、本発明の１実施形態に従って示したブロック図である。
【図７】代表的なシステムにおいて、ＯＳが位置＃２、＃７、および＃８を上書きし、位置＃９に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図８】代表的なシステムにおいて、転用後の全データをスワップする時間がエンジンにあった場合の様子を、本発明の１実施形態に従って示したブロック図である。
【図９】コンピュータディスクの再構成を、本発明の１実施形態に従って示したブロック図である。
【図１０】図１から得られる初期状態を、本発明の１実施形態に従って示したブロック図である。
【図１１】コンピュータディスクを再構成した結果を、本発明の１実施形態に従って示したブロック図である。
【図１２】代表的なシステムの初期状態を、本発明の１実施形態に従って示したブロック図である。
【図１３】代表的なシステムにおいて、オペレーティングシステム（ＯＳ）が位置＃１に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１４】代表的なシステムにおいて、ＯＳが位置＃２を解放する様子を、本発明の１実施形態に従って示したブロック図である。
【図１５】代表的なシステムにおいて、ＯＳが位置＃６に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１６】代表的なシステムにおいて、ＯＳが位置＃１および＃３に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１７】代表的なシステムにおいて、ＯＳが位置＃４および＃５を解放する様子を、本発明の１実施形態に従って示したブロック図である。
【図１８】代表的なシステムにおいて、ＯＳが位置＃７および＃８に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図１９】代表的なシステムにおいて、ＯＳが位置＃２を再生した様子を、本発明の１実施形態に従って示したブロック図である。
【図２０】代表的なシステムにおいて、ＯＳが位置＃２を上書きする様子を、本発明の１実施形態に従って示したブロック図である。
【図２１】代表的なシステムにおいて、ＯＳが位置＃７および＃８に書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図２２】代表的なシステムにおいて、ＯＳが位置＃９に直接書き込む様子を、本発明の１実施形態に従って示したブロック図である。
【図２３】代表的なシステムにおいて、エンジンが、ＯＳが位置＃９に直接書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２４】代表的なシステムにおいて、エンジンが、ＯＳが位置＃７および＃８に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２５】代表的なシステムにおいて、エンジンが、ＯＳが位置＃２に上書きするより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２６】代表的なシステムにおいて、エンジンが、ＯＳが位置＃２を再生させるより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２７】代表的なシステムにおいて、エンジンが、ＯＳが位置＃７および＃８に直接書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２８】代表的なシステムにおいて、エンジンが、ＯＳが位置＃４および＃５を解放するより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図２９】代表的なシステムにおいて、エンジンが、ＯＳが位置＃３に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３０】代表的なシステムにおいて、エンジンが、ＯＳが位置＃１に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３１】代表的なシステムにおいて、エンジンが、ＯＳが位置＃６に直接書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３２】代表的なシステムにおいて、エンジンが、ＯＳが位置＃２を解放するより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
【図３３】代表的なシステムにおいて、エンジンが、ＯＳが位置＃１に書き込むより以前の状態に復帰する様子を、本発明の１実施形態に従って示したブロック図である。
Claims (19)
- データを回復させるための方法であって、
ディスク位置Ｘと、前記ディスク位置Ｘとは異なるディスク位置Ｙと、ディスク位置Ｚとを含んだディスクにつき、ディスクの履歴状態の記録を作成する動作と、
前記ディスク位置Ｘにあるもとのデータに上書きする要求に応じ、
前記ディスク位置Ｙに新しいデータを格納し、
前記履歴状態の記録内に、上書きを指示されたデータであって前記上書きがなされずに保存されている履歴データを含むという前記ディスク位置Ｘの役割と、前記ディスク位置Ｘの前記新しいデータを含むという前記ディスク位置Ｙの役割と、を示す標識を設定する動作と、
前記ディスク位置Ｚにあるデータを解放するコマンドに応じ、
前記データを解放するコマンドをインターセプトし、
前記履歴状態の記録内に、前記ディスク位置Ｚが履歴データを格納し、前記ディスク位置Ｚの読み出し要求があった場合にはゼロが返されるべきことを示す標識を設定する動作と、
オペレーティングシステムが後に使用するために前記ディスク位置Ｚを再生させる要求を受信する動作と、
前記ディスク位置Ｚが新しいデータの格納に利用可能であることを示す標識を、前記履歴状態の記録内に設定する動作と、を備えた方法。 - 請求項１記載の方法であって、
前記履歴状態の記録は新しい履歴ヘッダ表である、方法。 - 請求項１記載の方法であって、前記ディスク位置Ｘおよび前記ディスク位置Ｙの役割を示す前記履歴状態の記録内の標識は、転用が発生したことを示す、方法。
- 請求項１記載の方法であって、前記ディスク位置Ｚが履歴データを格納することを示す前記履歴状態の記録内の標識は、ディスク位置Ｚの状態を「ほとんど未使用」に設定する、方法。
- 請求項１記載の方法であって、さらに、
前記ディスクの過去の状態を再構成するのに必要な履歴データを含まないディスク位置Ｔに、新しいデータを書き込む要求を受信する動作と、
前記ディスク位置Ｔへの前記書き込み要求に応じ、前記新しいデータを前記ディスク位置Ｔに直接格納する動作と、
前記ディスク位置Ｔに関する過去の履歴データがもはや利用可能ではないことを示す標識を、前記履歴状態の記録内に設定する動作と
を備えた方法。 - 請求項１記載の方法であって、
前記ディスク位置Ｚが新しいデータの格納に利用可能であることを示す前記履歴状態の記録内の標識は、ディスク位置Ｚの状態が「早期」であることを示す、方法。 - 請求項６記載の方法であって、さらに、
前記ディスク位置Ｚにあるもとのデータに上書きする要求に応じ、新しいデータをディスク位置Ｙ’に格納する動作と、
前記ディスク位置Ｚおよび前記ディスク位置Ｙ’の役割を示す標識を、前記履歴状態の記録内に設定する動作と
を備えた方法。 - 請求項１記載の方法であって、さらに、
前記ディスク位置Ｘにある前記もとのデータを前記ディスク位置Ｙに転送する動作と、
前記ディスク位置Ｙの前記新しいデータを前記ディスク位置Ｘに転送する動作と
を備えた方法。 - 請求項１記載の方法であって、
前記履歴状態の記録は、
ディスク位置の状態を示すマップと、
前記履歴データをメイン領域にマッピングする履歴表であって、さらに、前記オペレーティングシステムによって解放されたディスク位置を示し、前記履歴表内のエントリに発生順にアクセスすることができる、履歴表と、を含み、
前記方法は、さらに、
オペレーティングシステムからのファイル管理コマンドをインターセプトする動作と、
前記標識を前記エントリとして実質上発生順に前記履歴表内に記録する動作と
を備えた方法。 - 請求項９記載の方法であって、
前記マップは、前記オペレーティングシステムによって「ほどんと未使用」であるとして解放された削除ディスク位置の状態を示す、方法。 - 請求項１０記載の方法であって、さらに、
前記削除ディスク位置が履歴データを含むことを示す標識を、前記履歴表内に記録する動作を備えた、方法。 - 請求項１１記載の方法であって、
前記マップは、前記削除ディスク位置を再生させるという前記オペレーティングシステムからの要求に応じ、前記削除ディスク位置の状態を「早期」であると示す、方法。 - 請求項９記載の方法であって、
前記マップは、前記ディスクの過去の状態を再構成するのに必要な履歴データを有さない未使用なディスク位置の状態を、「真に未使用」であると示す、方法。 - 請求項１３記載の方法であって、さらに、
前記未使用なディスク位置に書き込むという前記オペレーティングシステムからの要求に応じ、前記未使用なディスク位置が直接の書き込みを受信したことを示す標識を、前記履歴表内に記録する動作を備えた、方法。 - 請求項９記載の方法で処理した前記ディスクの過去の状態を復元するための方法であって、
（ａ）前記ディスクを再構成する要求に応じ、前記履歴表内の最新のエントリを検討する動作と、
（ｂ）前記ディスクのディスク位置Ｐにあるもとのデータを新しいデータで上書きすることに関する書き込みエントリが、前記最新のエントリ内において検知された場合に、前記ディスク位置Ｐにある前記新しいデータを前記もとのデータで置き換える動作と、
（ｃ）前記ディスクのディスク位置Ｑの解放に関する解放エントリが、前記最新のエントリ内において検知された場合に、前記解放されていたディスク位置Ｑに前記オペレーティングシステムがアクセスするのを許可する動作と、
（ｄ）前記履歴表内の前記最新のエントリを廃棄する動作と、
（ｅ）前記ディスクの前記過去の状態が復元されるまで、動作（ａ）〜（ｄ）を繰り返す動作と
を備えた方法。 - 請求項１５記載の方法であって、
前記工程（ｅ）は
真の書き込みディスク位置への書き込みに関する真の書き込みエントリが、前記最新のエントリ内において検知された場合に、真の書き込みディスク位置からデータを取り除く動作を備え、
前記真の書き込みディスク位置は、前記コンピュータ読み取り可能媒体を再構成するのに必要な履歴データを含まないディスク位置である、方法。 - 請求項１５記載の方法であって、
前記動作（ｃ）における、前記オペレーティングシステムが前記ディスク位置Ｑにアクセスするのを許可する前記動作は、前記ディスク位置Ｑの「ほとんど未使用」の状態を解除することを含む、方法。 - 請求項１７記載の方法であって、
前記ディスク位置Ｑについての前記「ほとんど未使用」の状態は、複数のディスク位置の状態を記録するマップに記録される、方法。 - 請求項１５記載の方法であって、さらに、
前記コンピュータ読み取り可能媒体を再構成するのに必要な履歴データを格納するエキストラページメモリを設定する動作を備える、方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15833699P | 1999-10-07 | 1999-10-07 | |
| US60/158336 | 1999-10-07 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001184246A JP2001184246A (ja) | 2001-07-06 |
| JP3797864B2 true JP3797864B2 (ja) | 2006-07-19 |
Family
ID=22567658
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000308367A Expired - Fee Related JP3797864B2 (ja) | 1999-10-07 | 2000-10-06 | オペレーティングシステムとの関連でデータを回復および再生する方法、ソフトウェア、および装置 |
Country Status (2)
| Country | Link |
|---|---|
| EP (1) | EP1091299A2 (ja) |
| JP (1) | JP3797864B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6732293B1 (en) | 1998-03-16 | 2004-05-04 | Symantec Corporation | Method, software and apparatus for recovering and recycling data in conjunction with an operating system |
| US7055055B1 (en) | 1999-04-23 | 2006-05-30 | Symantec Corporation | Write cache flushing method for reducing data corruption |
| WO2001004801A1 (en) | 1999-07-09 | 2001-01-18 | Wild File, Inc. | Optimized disk storage defragmentation with swapping capabilities |
| US7051055B1 (en) | 1999-07-09 | 2006-05-23 | Symantec Corporation | Optimized disk storage defragmentation with swapping capabilities |
| US7296008B2 (en) * | 2004-08-24 | 2007-11-13 | Symantec Operating Corporation | Generation and use of a time map for accessing a prior image of a storage device |
| US7949665B1 (en) | 2004-11-19 | 2011-05-24 | Symantec Corporation | Rapidly traversing disc volumes during file content examination |
| EP1713008B1 (en) | 2005-04-14 | 2013-03-13 | Rajesh Kapur | Method and system for preserving access to deleted and overwritten documents by means of a system recycle bin |
| JP2009258825A (ja) * | 2008-04-14 | 2009-11-05 | Hitachi Ltd | ストレージシステム、仮想化装置、及び計算機システム |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04165543A (ja) * | 1990-10-30 | 1992-06-11 | Matsushita Electric Ind Co Ltd | 電子フアイリング装置 |
-
2000
- 2000-10-06 EP EP20000308805 patent/EP1091299A2/en not_active Withdrawn
- 2000-10-06 JP JP2000308367A patent/JP3797864B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001184246A (ja) | 2001-07-06 |
| EP1091299A2 (en) | 2001-04-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6732293B1 (en) | Method, software and apparatus for recovering and recycling data in conjunction with an operating system | |
| JP3878412B2 (ja) | データを保存し使用し及び回復する方法 | |
| US8296264B1 (en) | Method and system for file-level continuous data protection | |
| US10762039B2 (en) | Backup and restoration for storage system | |
| US8005797B1 (en) | File-level continuous data protection with access to previous versions | |
| US5086502A (en) | Method of operating a data processing system | |
| US9699255B2 (en) | Device driver | |
| US7246211B1 (en) | System and method for using file system snapshots for online data backup | |
| US7849257B1 (en) | Method and apparatus for storing and retrieving data | |
| US6738863B2 (en) | Method for rebuilding meta-data in a data storage system and a data storage system | |
| US6816941B1 (en) | Method and system for efficiently importing/exporting removable storage volumes between virtual storage systems | |
| US7325159B2 (en) | Method and system for data recovery in a continuous data protection system | |
| US7406488B2 (en) | Method and system for maintaining data in a continuous data protection system | |
| EP0733235B1 (en) | Incremental backup system | |
| US7363540B2 (en) | Transaction-safe FAT file system improvements | |
| US7318135B1 (en) | System and method for using file system snapshots for online data backup | |
| KR100510808B1 (ko) | 데이터 저장 장치 및 시스템을 위한 로그 구조 기록 캐시 | |
| KR100437199B1 (ko) | 컴퓨터시스템및그에저장된데이터를액세싱하기위한방법 | |
| US6718427B1 (en) | Method and system utilizing data fragments for efficiently importing/exporting removable storage volumes | |
| US7979654B2 (en) | Method and system for restoring a volume in a continuous data protection system | |
| US20020049883A1 (en) | System and method for restoring a computer system after a failure | |
| EP2333653A1 (en) | Information backup/restoring apparatus and information backup/restoring system | |
| US7383465B1 (en) | Undoable volume using write logging | |
| JPH1055298A (ja) | コンピュータのディスクボリュームをバックアップするシステム | |
| US20070061540A1 (en) | Data storage system using segmentable virtual volumes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20040514 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20040528 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040514 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040528 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050201 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050427 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050506 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050728 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060328 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060418 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090428 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140428 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |