JP2001184246A - オペレーティングシステムとの関連でデータを回復および再生する方法、ソフトウェア、および装置 - Google Patents

Abstract

(57)【要約】 【課題】 コンピュータ環境でデータを回復させるため
の方法を開示すること。 【解決手段】 先ず、ディスク位置Ｘ、ディスク位置
Ｙ、ディスク位置Ｚなどの種々のディスク位置を含んだ
ディスクの履歴状態の記録を作成する。ディスク位置Ｘ
にあるもとのデータを上書きする要求に応じ、ディスク
位置Ｙに新しいデータを格納する。次いで、履歴状態の
記録内に、ディスク位置Ｘおよびディスク位置Ｙの役割
を示す標識を設定する。これらの役割は、履歴データを
含むというディスク位置Ｘの役割、ディスク位置Ｘの新
しいデータを含むというディスク位置Ｙの役割を、規定
することができる。また、この方法は、ディスク位置Ｚ
にあるデータを解放するコマンドをインターセプトし、
履歴状態の記録内に、ディスク位置Ｚが履歴データを格
納することを示す標識を設定することを含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般にデジタルデ
ータの格納に関し、特に、オペレーティングシステム
（ＯＳ）によって同システム管理下のファイルになされ
た変更を、デジタルコンピュータによって格納されたデ
ータのバックアップおよび回復を支援する変更追跡シス
テムとの関連のもとで追跡するための、方法および装置
に関する。

【０００２】

【発明の背景】コンピュータ上で実行されるアプリケー
ションは、特にハードディスクからの情報の保存および
再呼び出しに責任を負う、オペレーティングシステム
（ＯＳ）のもとで動作するのが通常である。情報は、通
常はファイルに編成されている。ＯＳは、ファイルと、
そのファイル情報を保持するハードディスク上の関連位
置との間でマッピングを行う方法を保持している。

【０００３】現在のコンピュータは、一般に、情報（デ
ータ）を読み出して永続記憶用のディスクに書き込む形
で動作する。通常は、ディスクを周期的にバックアップ
（コピー）することによって、次の２種類の問題に対処
している。第１に、ディスク自体が物理的に故障する
と、そこに含まれていた情報がアクセス不能となる。第
２に、ディスク上の情報が変更され、もとの状態が望ま
しかったと判断されると、ユーザは、バックアップを使
用してこのもとの状態を回復する。バックアップは、同
じディスクまたは代替の媒体（ディスクやテープ装置
等）に対して行うことができる。

【０００４】テープバックアップとしては、従来、ファ
イルまたはディスクセクタイメージとして編成されたデ
ィスクの内容を、磁気テープ上に複製する手法がある。
このようなテープは、通常は取り外し可能であるので、
サイトの外に格納して、ディスクドライブの誤動作や、
さらには例えば火災による（ディスクドライブを含む）
サイト全体の破壊に対して回復を提供することができ
る。

【０００５】情報がセクタレベルのディスクイメージの
形態でディスクからテープにコピーされる（すなわち、
情報がディスク上と同じ形でテープ上に編成される）場
合は、同一のディスク駆動装置に対して最も効率的に復
元を行うことができる。このように編成する理由は、速
度である。ディスクを最初から最後まで順次読み出す方
が、ディスク上を跳び回って一度に１ファイルづつ読み
出すより遥かに高速である。これは、ファイルがディス
クの１領域に連続的に保存されていないことが多く、デ
ィスク全体に広がって他のファイルと混ざっている可能
性があるからである。情報を一度に１ファイルづつテー
プにコピーする場合は、１つまたはそれ以上のファイル
を、すでにデータを含んでいる異なるディスクで効率的
に復元することができる。

【０００６】テープバックアップは、ある時点における
ディスク全体または特定のファイルをバックアップする
ことに焦点を合わせている。この処理は、長時間かかる
のが通常であるため、例えば夕方等に低頻度で行われ
る。増分（インクレメンタル）バックアップは、最終の
バックアップ以降に変更されたデータのみを保存するた
め、必要なテープ量およびバックアップ時間が低減され
る。しかしながら、システムを完全に回復させるには、
システム全体の最初のバックアップとその後の増分バッ
クアップ全てを読み出して結合し、最終の増分バックア
ップの時点まで復元しなければならない。テープバック
アップの主要な欠点は、最新のバックアップが実行され
ていない場合に、最後のバックアップ後に生成された情
報や作業が失われる可能性があるということである。

【０００７】ＷＯＲＭドライブによって行われるような
追記型のディスクバックアップは、データバックアップ
と同じ特性を多数有する。しかし、その関連技術のため
データを上書きすることができない。したがってＷＯＲ
Ｍドライブは、変更できないバックアップのある程度の
リーガル「アカウンティング」システム（legal "accou
nting" 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 (20)

【特許請求の範囲】
1. 【請求項１】 データを回復させるための方法であっ
   て、 ディスク位置Ｘと、ディスク位置Ｙと、ディスク位置Ｚ
   とを含んだディスクにつき、ディスクの履歴状態の記録
   を作成する動作と、 前記ディスク位置Ｘにあるもとのデータに上書きする要
   求に応じ、前記ディスク位置Ｙに新しいデータを格納す
   る動作と、 前記履歴状態の記録内に、前記ディスク位置Ｘおよび前
   記ディスク位置Ｙの役割を示す標識を設定する動作と、 前記ディスク位置Ｚにあるデータを解放するコマンドを
   インターセプトする動作と、 前記履歴状態の記録内に、前記ディスク位置Ｚが履歴デ
   ータを格納することを示す標識を設定する動作とを備え
   た方法。
2. 【請求項２】 請求項１記載の方法であって、 前記履歴状態の記録は新しい履歴ヘッダ表である、方
   法。
3. 【請求項３】 請求項１記載の方法であって、前記ディ
   スク位置Ｘおよび前記ディスク位置Ｙの役割を示す前記
   履歴状態の記録内の標識は、転用が発生したことを示
   す、方法。
4. 【請求項４】 請求項１記載の方法であって、前記ディ
   スク位置Ｚが履歴データを格納することを示す前記履歴
   状態の記録内の標識は、ディスク位置Ｚの状態を「ほと
   んど未使用」に設定する、方法。
5. 【請求項５】 請求項１記載の方法であって、さらに、 前記ディスクの過去の状態を再構成するのに必要な履歴
   データを含まないディスク位置Ｔに、新しいデータを書
   き込む要求を受信する動作と、 前記ディスク位置Ｔへの前記書き込み要求に応じ、前記
   新しいデータを前記ディスク位置Ｔに直接格納する動作
   と、 前記ディスク位置Ｔに関する過去の履歴データがもはや
   利用可能ではないことを示す標識を、前記履歴状態の記
   録内に設定する動作とを備えた方法。
6. 【請求項６】 請求項１記載の方法であって、さらに、 オペレーティングシステムが後に使用するために前記デ
   ィスク位置Ｚを再生させる要求を受信する動作と、 前記ディスク位置Ｚが新しいデータの格納に利用可能で
   あることを示す標識を、前記履歴状態の記録内に設定す
   る動作とを備えた方法。
7. 【請求項７】 請求項６記載の方法であって、 前記ディスク位置Ｚが新しいデータの格納に利用可能で
   あることを示す前記履歴状態の記録内の標識は、ディス
   ク位置Ｚの状態が「早期」であることを示す、方法。
8. 【請求項８】 請求項７記載の方法であって、さらに、 前記ディスク位置Ｚにあるもとのデータに上書きする要
   求に応じ、新しいデータをディスク位置Ｙ’に格納する
   動作と、 前記ディスク位置Ｚおよび前記ディスク位置Ｙ’の役割
   を示す標識を、前記履歴状態の記録内に設定する動作と
   を備えた方法。
9. 【請求項９】 請求項１記載の方法であって、さらに、 前記ディスク位置Ｘにある前記もとのデータを前記ディ
   スク位置Ｙに転送する動作と、 前記ディスク位置Ｙの前記新しいデータを前記ディスク
   位置Ｘに転送する動作とを備えた方法。
10. 【請求項１０】 コンピュータ読み取り可能媒体上に組
    み込まれ、コンピュータディスクの過去の状態を復元す
    ることができる、コンピュータプログラムであって、 オペレーティングシステムからのファイル管理コマンド
    をインターセプトすることができるコードセグメント
    と、 ディスク位置の状態を示すマップと、 履歴データをメイン領域にマッピングする履歴表であっ
    て、さらに、前記オペレーティングシステムによって解
    放されたディスク位置を示し、前記履歴内のエントリが
    発生順にアクセスすることができる、履歴表と、 ディスク変更の標識を実質上発生順に前記履歴表内に記
    録するコードセグメントとを備えたコンピュータプログ
    ラム。
11. 【請求項１１】 請求項１０記載のコンピュータプログ
    ラムであって、 前記マップは、前記オペレーティングシステムによって
    「ほどんと未使用」であるとして解放された削除ディス
    ク位置の状態を示す、コンピュータプログラム。
12. 【請求項１２】 請求項１１記載のコンピュータプログ
    ラムであって、さらに、 前記削除ディスク位置が履歴データを含むことを示す標
    識を、前記履歴表内に記録する、コードセグメントを備
    えた、コンピュータプログラム。
13. 【請求項１３】 請求項１２記載のコンピュータプログ
    ラムであって、 前記マップは、前記削除ディスク位置を再生させるとい
    う前記オペレーティングシステムからの要求に応じ、前
    記削除ディスク位置の状態を「早期」であると示す、コ
    ンピュータプログラム。
14. 【請求項１４】 請求項１０記載のコンピュータプログ
    ラムであって、 前記マップは、前記ディスクの過去の状態を再構成する
    のに必要な履歴データを有さない未使用なディスク位置
    の状態を、「真に未使用」であると示す、コンピュータ
    プログラム。
15. 【請求項１５】 請求項１４記載のコンピュータプログ
    ラムであって、さらに、 前記未使用なディスク位置に書き込むという前記オペレ
    ーティングシステムからの要求に応じ、前記未使用なデ
    ィスク位置が直接の書き込みを受信したことを示す標識
    を、前記履歴表内に記録する、コードセグメントを備え
    た、コンピュータプログラム。
16. 【請求項１６】 コンピュータ読み取り可能媒体の過去
    の状態を復元するための方法であって、 （ａ）前記コンピュータ読み取り可能媒体の履歴変更の
    エントリを有したデータ構造であって、第１のデータ位
    置Ｘにあるもとのデータを新しいデータで上書きするこ
    とに関する書き込みエントリを含み、前記データ構造内
    の解放エントリは、オペレーティングシステムによるデ
    ータ位置Ｚの解放に関する、データ構造を設定する動作
    と、 （ｂ）前記コンピュータ読み取り可能媒体を再構成する
    要求に応じ、前記データ構造内の最新のエントリを検討
    する動作と、 （ｃ）前記書き込みエントリの検討に応じ、第１のデー
    タ位置Ｘにある前記新しいデータを前記もとのデータで
    置き換える動作と、 （ｄ）前記解放エントリの検討に応じ、前記オペレーテ
    ィングシステムが前記解放データ位置Ｚにアクセスする
    のを許可する動作と、 （ｅ）前記データ構造内の最新のエントリを廃棄する動
    作と、 （ｆ）前記コンピュータ読み取り可能媒体の前記過去の
    状態が復元されるまで、動作（ｂ）〜（ｆ）を繰り返す
    動作とを備えた方法。
17. 【請求項１７】 請求項１６記載の方法であって、さら
    に、 真の書き込みエントリの検討に応じ、真の書き込みディ
    スク位置からデータを取り除く動作を備え、 前記真の書き込みエントリは、前記真の書き込みディス
    ク位置への書き込みに関し、 前記真の書き込みディスク位置は、前記コンピュータ読
    み取り可能媒体を再構成するのに必要な履歴データを含
    まない、方法。
18. 【請求項１８】 請求項１６記載の方法であって、 前記オペレーティングシステムが前記解放データ位置Ｚ
    にアクセスするのを許可する前記動作は、前記データ位
    置Ｚから「ほとんど未使用」な状態を取り除くことを含
    む、方法。
19. 【請求項１９】 請求項１８記載の方法であって、 前記データ位置Ｚの前記「ほとんど未使用」な状態は、
    複数のデータ位置の状態を記録するマップに記録され
    る、方法。
20. 【請求項２０】 請求項１６記載の方法であって、さら
    に、 前記コンピュータ読み取り可能媒体を再構成するのに必
    要な履歴データを格納するエキストラページメモリを設
    定する動作を備える、方法。