(57)【要約】【課題】  別途のプログラムを予め設置しなくてもＥＸＴ２ファイルシステムにおいて損傷または削除されたデータを事後に復旧し得るＥＸＴ２ファイルシステムのデータ復旧方法及びそのプログラムを記録した記録媒体を提供する。【解決手段】  パーティションテーブルを抽出する段階と、該当パーティションからディレクトリ及びファイルのエントリーを抽出する段階と、抽出されたエントリーを利用して該当データを抽出する段階と、抽出されたデータを結合して新しいファイルとして貯蔵する段階と、を含む。【選択図】    図５ 
2005166042.tif 000002
【特許請求の範囲】
【請求項１】
(ａ)データ復旧対象の貯蔵媒体からパーティションテーブルを抽出する段階と、
(ｂ)該抽出されたパーティションテーブルを利用して該当パーティションからディレクトリ及びファイルのエントリーを抽出する段階と、
(ｃ)該エントリーを利用して該当データを抽出する段階と、
(ｄ)該抽出されたデータを結合して新しいファイルとして貯蔵する段階と、
を含むことを特徴とするＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項２】
前記(ｂ)段階は、
(ｂ１)前記パーティションからスーパーブロック情報を抽出する段階と、
(ｂ２)該スーパーブロック情報を利用してグループディスクリプタ情報を抽出する段階と、
(ｂ３)該グループディスクリプタ情報が示すアイノードテーブルを参考してルートディレクトリ以下の全てのレベルに対するディレクトリ及びファイルのエントリーを抽出する段階と、を含むことを特徴とする請求項１に記載のＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項３】
前記(ｂ１)段階は、
スーパーブロックの損傷有無を予め確認し、損傷されていないスーパーブロックを抽出することを特徴とする請求項２に記載のＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項４】
前記(ｂ)段階は、
前記パーティションがＥＸＴ２ファイルシステムを使用するか否かを確認する段階をさらに含むことを特徴とする請求項２に記載のＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項５】
前記(ａ)段階は、
前記パーティションテーブルが損傷された場合、セクター単位で読み込んだ後、予め指定されたファイルシステム形式にマッチングされる情報が存在するか否かを確認することを特徴とする請求項１〜４のいずれか１項に記載のＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項６】
前記(ｄ)段階は、
外部貯蔵装置または復旧対象のデータが貯蔵されたパーティション以外のパーティションに新しいファイルとして貯蔵することを特徴とする請求項１〜４のいずれか１項に記載のＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項７】
前記(ｂ)段階は、
(ｂ１)前記パーティションからスーパーブロック情報を抽出する段階と、
(ｂ２)該スーパーブロック情報を利用してグループディスクリプタ情報を抽出する段階と、
(ｂ３)該グループディスクリプタ情報が示すアイノードテーブルを参考してアイノード番号フィールドがクリアされたディレクトリ及びファイルのエントリーを抽出する段階と、を含むことを特徴とする請求項１に記載のＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項８】
前記(ｂ３)段階は、
削除時間が設定されているアイノードテーブルのディレクトリ及びファイルのエントリーを抽出することを特徴とする請求項７に記載のＥＸＴ２ファイルシステムのデータ復旧方法。
【請求項９】
(ａ)データ復旧対象の貯蔵媒体からパーティションテーブルを抽出するプロセスと、
(ｂ)該抽出されたパーティションテーブルを利用して該当パーティションからディレクトリ及びファイルのエントリーを抽出するプロセスと、
(ｃ)該エントリーを利用して該当データを抽出するプロセスと、
(ｄ)該抽出されたデータを結合して新しいファイルとして貯蔵するプロセスと、
を含むことを特徴とするＥＸＴ２ファイルシステムのデータ復旧プログラムを記録したコンピュータ読み込み可能な記録媒体。
【請求項１０】
前記(ｂ)プロセスは、
(ｂ１)前記パーティションからスーパーブロック情報を抽出するプロセスと、
(ｂ２)該スーパーブロック情報を利用してグループディスクリプタ情報を抽出するプロセスと、
(ｂ３)該グループディスクリプタ情報が示すアイノードテーブルを参考してルートディレクトリ以下の全てのレベルに対するディレクトリ及びファイルのエントリーを抽出するプロセスと、を含むことを特徴とする請求項９に記載の記録媒体。
【請求項１１】
前記(ｂ１)プロセスは、
スーパーブロックの損傷有無を予め確認し、損傷されていないスーパーブロックを抽出することを特徴とする請求項１０に記載の記録媒体。
【請求項１２】
前記(ｂ)プロセスは、
前記パーティションがＥＸＴ２ファイルシステムを使用するか否かを確認するプロセスをさらに含むことを特徴とする請求項１０に記載の記録媒体。
【請求項１３】
前記(ａ)プロセスは、
前記パーティションテーブルが損傷された場合、セクター単位で読み込んだ後、予め指定されたファイルシステム形式にマッチングされる情報が存在するか否かを確認することを特徴とする請求項９〜１２のいずれか１項に記載の記録媒体。
【請求項１４】
前記(ｄ)プロセスは、
外部貯蔵装置または復旧対象のデータが貯蔵されたパーティション以外のパーティションに新しいファイルとして貯蔵することを特徴とする請求項９〜１２のいずれか１項に記載の記録媒体。
【請求項１５】
前記(ｂ)プロセスは、
(ｂ１)前記パーティションからスーパーブロック情報を抽出するプロセスと、
(ｂ２)該スーパーブロック情報を利用してグループディスクリプタ情報を抽出するプロセスと、
(ｂ３)該グループディスクリプタ情報が示すアイノードテーブルを参考してアイノード番号フィールドがクリアされたディレクトリ及びファイルのエントリーを抽出するプロセスと、を含むことを特徴とする請求項９に記載の記録媒体。
【請求項１６】
前記(ｂ３)プロセスは、
削除時間が設定されているアイノードテーブルのディレクトリ及びファイルのエントリーを抽出することを特徴とする請求項１５に記載の記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＸＴ２ファイルシステム(the Second Extend File System)のデータ復旧方法及びそのプログラムを記録した記録媒体に関し、特に、別途のプログラムを予め設置しなくても事後に復旧できるＥＸＴ２ファイルシステムのデータ復旧方法及びそのプログラムを記録した記録媒体に関する。
【背景技術】
【０００２】
最近、コンピュータの処理速度が増加するにつれて、コンピュータによって算出されるデータの量も何年前とは比較できない程度、爆発的に増加している。また、このように算出されたデータを貯蔵するための貯蔵媒体の容量も急速に増加している。
【０００３】
しかしながら、膨大な量のデータが貯蔵された貯蔵媒体が外部の衝撃、ユーザの過ち、プログラム間の衝突、または、ウイルスなどによって、一瞬に損失される場合がしばしば発生している。
【０００４】
勿論、普段は不意の事故に対応して別途にバックアップをしておくが、予めバックアップできなかったデータ場合は、全く手が付けられない状況になってしまう。
【０００５】
このような問題点を解決するために、従来にも多様な復旧方法が開示された。しかしながら、従来の技術は、バックアップのためにディスクをモニターリングするためのプログラムを予め設置しなければならないという問題点がある。
【０００６】
さらに、代表的なコンピュータ運営体系としては、Ｗｉｎｄｏｗｓ（登録商標）及びＬiｎｕｘがあるが、従来の技術では、Ｗｉｎｄｏｗｓ（登録商標）基盤の特定ファイルシステムにおけるデータ復旧方法のみを開示している。つまり、Ｗｉｎｄｏｗｓ（登録商標）を基盤のデータ復旧プログラムを使用してはＬiｎｕｘ基盤のデータを復旧し得ないという問題点がある。  
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、このような問題点を解決するために提案されたもので、本発明の目的は、別途のプログラムを予め設置しなくてもＥＸＴ２ファイルシステムにおいて損傷または削除されたデータを事後に復旧し得るＥＸＴ２ファイルシステムのデータ復旧方法及びそのプログラムを記録した記録媒体を提供することにある。
【０００８】
本発明の他の目的は、マスターブートレコード(Master Boot Record: ＭＢＲ)領域のパーティションテーブルが損傷されてディスクが認識できない場合も、データを復旧し得るＥＸＴ２ファイルシステムのデータ復旧方法及びそのプログラムを記録した記録媒体を提供することにある。
【０００９】
本発明のまた他の目的は、スーパーブロックの異常などによって正常なブーティングができない場合も、データを復旧し得るＥＸＴ２ファイルシステムのデータ復旧方法及びそのプログラムを記録した記録媒体を提供することにある。
【課題を解決するための手段】
【００１０】
このような目的を達成するために本発明の一実施形態では、(ａ)データ復旧対象の貯蔵媒体からパーティションテーブルを抽出する段階と、(ｂ)該抽出されたパーティションテーブルを利用して該当パーティションからディレクトリ及びファイルのエントリーを抽出する段階と、(ｃ)該エントリーを利用して該当データを抽出する段階と、(ｄ)該抽出されたデータを結合して新しいファイルとして貯蔵する段階と、を含むＥＸＴ２ファイルシステムのデータ復旧方法を提供する。
【００１１】
また、前記(ｂ)段階は、(ｂ１)前記パーティションからスーパーブロック情報を抽出する段階と、(ｂ２)該スーパーブロック情報を利用してグループディスクリプタ情報を抽出する段階と、(ｂ３)該グループディスクリプタ情報が示すアイノードテーブルを参考してルートディレクトリ以下の全てのレベルに対するディレクトリ及びファイルのエントリーを抽出する段階と、を含むことを特徴とする。
【００１２】
さらに、前記(ｂ１)段階は、スーパーブロックの損傷有無を予め確認し、損傷されていないスーパーブロックを抽出することを特徴とする。
【００１３】
さらに、前記(ｂ)段階は、前記パーティションがＥＸＴ２ファイルシステムを使用するか否かを確認する段階をさらに含むことを特徴とする。
【００１４】
さらに、前記(ａ)段階は、前記パーティションテーブルが損傷された場合、セクター単位で読み込んだ後、予め指定されたファイルシステム形式にマッチングされる情報が存在するか否かを確認することを特徴とする。
【００１５】
さらに、前記(ｄ)段階は、外部貯蔵装置または復旧対象のデータが貯蔵されたパーティション以外のパーティションに新しいファイルとして貯蔵することを特徴とする。
【００１６】
本発明の他の実施形態では、(ａ)データ復旧対象の貯蔵媒体からパーティションテーブルを抽出するプロセスと、(ｂ)該抽出されたパーティションテーブルを利用して該当パーティションからディレクトリ及びファイルのエントリーを抽出するプロセスと、(ｃ)該エントリーを利用して該当データを抽出するプロセスと、(ｄ)該抽出されたデータを結合して新しいファイルとして貯蔵するプロセスと、を含むＥＸＴ２ファイルシステムのデータ復旧プログラムを記録したコンピュータ読み込み可能な記録媒体を提供する。
【００１７】
さらに、前記(ｂ)プロセスは、(ｂ１)前記パーティションからスーパーブロック情報を抽出するプロセスと、(ｂ２)該スーパーブロック情報を利用してグループディスクリプタ情報を抽出するプロセスと、(ｂ３)該グループディスクリプタ情報が示すアイノードテーブルを参考してルートディレクトリ以下の全てのレベルに対するディレクトリ及びファイルのエントリーを抽出するプロセスと、を含むことを特徴とする。
【００１８】
さらに、前記(ｂ１)プロセスは、スーパーブロックの損傷有無を予め確認し、損傷されていないスーパーブロックを抽出することを特徴とする。
【００１９】
さらに、前記(ｂ)プロセスは、前記パーティションがＥＸＴ２ファイルシステムを使用するか否かを確認するプロセスをさらに含むことを特徴とする。
【００２０】
さらに、前記(ａ)プロセスは、前記パーティションテーブルが損傷された場合、セクター単位で読み込んだ後、予め指定されたファイルシステム形式にマッチングされる情報が存在するか否かを確認することを特徴とする。
【００２１】
さらに、前記(ｄ)プロセスは、外部貯蔵装置または復旧対象のデータが貯蔵されたパーティション以外のパーティションに新しいファイルとして貯蔵することを特徴とする。
【００２２】
さらに、前記(ｂ)プロセスは、(ｂ１)前記パーティションからスーパーブロック情報を抽出するプロセスと、(ｂ２)該スーパーブロック情報を利用してグループディスクリプタ情報を抽出するプロセスと、(ｂ３)該グループディスクリプタ情報が示すアイノードテーブルを参考してアイノード番号フィールドがクリアされたディレクトリ及びファイルのエントリーを抽出するプロセスと、を含むことを特徴とする。
【００２３】
さらに、削除時間が設定されているアイノードテーブルのディレクトリ及びファイルのエントリーを抽出することを特徴とする。
【発明の効果】
【００２４】
本発明は、別途のプログラムを予め設置しなくてもＥＸＴ２ファイルシステムにおいて損傷または削除されたファイルを事後に復旧することができる。また、実際データに他の内容が上書きさえされていないと該当データの復旧が可能である。また、ＭＢＲ領域のパーティションテーブルが損傷されてディスクが認識できない場合も、データを復旧することができる。また、スーパーブロックの異常などによって正常的なブーティングができない場合も、データを復旧することができる。  
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００２６】
本発明は、ＥＸＴ２ファイルシステムのデータが削除または損傷された時、該削除または損傷されたデータを復旧する方法及びその方法を支援可能に具現されるシステムの望ましい実施形態を提案する。
【００２７】
本発明の望ましい実施形態は、本発明による方法をコンピュータシステムにおいて実行可能に具現されたプログラムを記録したコンピュータ読み込み可能な記録媒体を含む。このような記録媒体には、磁気貯蔵媒体(例えば、フロッピー（登録商標）ディスク、ハードディスクなど)及び光学貯蔵媒体(例えば、ＣＤ、ＤＶＤなど)などが含まれる。
【００２８】
まず、本発明の理解を容易にするためにＥＸＴ２ファイルシステムの構造を簡単に説明する。
【００２９】
図１は、ＥＸＴ２ファイルシステムの構造を説明する図である。
【００３０】
一般的なハードディスクは、図１に示すようにマスタブートレコード(Master Boot Record: 以下、ＭＢＲと称する)及び一つまたはそれ以上のパーティション(Partition)が存在する論理構造を有する。ＭＢＲには、ブート及びパーティションの割り当てに対する情報が貯蔵されている。
【００３１】
ＥＸＴ２ファイルシステムにおいてパーティションは、一つまたはそれ以上のブロックグループ(Block Group)から構成され、前記ブロックグループは、スーパーブロック(Super Block)、グループディスクリプタ(Group Descriptors)、ブロックビットマップ(Block Bitmap)、アイノードビットマップ(Inode Bitmap)、アイノードテーブル(Inode Table)、及びデータブロック(Data Blocks)から構成される。
【００３２】
前記スーパーブロックは、下記のように、ファイルシステムのサイズ及び形態に対する情報を有し、大きさが１０２４バイトである。ブロックグループ０のスーパーブロックは、ブロックグループの開始点から１０２４バイトオフセット部分に位置し、各ブロックグループのスーパーブロックは、全て同一の内容を維持する。
【００３３】
struct ext2_super_block {
__u32   s_inodes_count;           /* アイノード個数 */
__u32   s_blocks_count;           /* ブロック個数 */
__u32   s_r_blocks_count;         /* 予約されたブロック個数 */
__u32   s_free_blocks_count;      /* フリーブロック個数 */
__u32   s_free_inodes_count;      /* フリーアイノード個数 */
__u32   s_first_data_block;       /* １番目のデータブロック*/
__u32   s_log_block_size;         /* ブロックサイズ */
__s32   s_log_frag_size;          /* フラグメントサイズ */ 
__u32   s_blocks_per_group;       /* グループ当たりブロック個数 */
__u32   s_frags_per_group;     /* グループ当たりフラグメント個数 */
__u32   s_inodes_per_group;      /* グループ当たりアイノード個数 */
__u32   s_mtime;                  /* マウント時刻 */
__u32   s_wtime;                  /* ライト時刻 */
__u16   s_mnt_count;              /* マウント個数 */
__s16   s_max_mnt_count;          /* 最大マウント個数 */
__u16   s_magic;                  /* マジックシグニチャー */
__u16   s_state;                  /* ファイルシステム状態 */
__u16   s_errors;                 /* エラー検出時行動 */
__u16   s_minor_rev_level;        /* 最小リビジョンレベル */
__u32   s_lastcheck;              /* 最後チェック時刻 */
__u32   s_checkinterval;          /* チェック間最大時間 */
__u32   s_creator_os;             /* OS(0:linux、1:Hurd、2:masix) */
__u32   s_rev_level;              /* Revision level */
__u16   s_def_resuid;            /* Default uid for reserved blocks */
__u16   s_def_resgid;            /* Default gid for reserved blocks */
__u32   s_first_ino;              /* First non-reserved inode */
__u16   s_inode_size;             /* アイノード構造体のサイズ */
__u16   s_block_group_nr;       /* block group # of this superblock */
__u32   s_feature_compat;         /* compatible feature set */
__u32   s_feature_incompat;       /* incompatible feature set */
__u32   s_feature_ro_compat;    /* readonly-compatible feature set */
__u8    s_uuid[16];               /* ボリューム用128-bit uuid */
char    s_volume_name[16];        /* ボリューム名 */
char    s_last_mounted[64];   /* 最後のマウントされたディレクトリ*/
__u32   s_algorithm_usage_bitmap; /* 圧縮用 */
__u8   s_prealloc_blocks;      /* Nr of blocks to try to preallocate*/
__u8    s_prealloc_dir_blocks;    /* Nr to preallocate for dirs */
__u16   s_padding1;
__u32   s_reserved[204];         /* ブロックの最後までパディング */
}; 
【００３４】
グループディスクリプタは、下記のように各ブロックグループに対するブロックビットップ、アイノードビットマップ、アイノードテーブルの開始位置及びサイズに対する情報を全て有している。グループディスクリプタもスーパーブロックのように全てのブロックグループにおいて同一の内容が維持される。
【００３５】
struct ext2_group_desc{
__u32   bg_block_bitmap;       /* ブロックビットマップブロック*/
__u32   bg_inode_bitmap;       /*アイノードビットマップブロック*/
__u32   bg_inode_table;        /*アイノードテーブルブロック*/
__u16   bg_free_blocks_count;  /* フリーブロック個数 */
__u16   bg_free_inodes_count;  /* フリーアイノード個数 */
__u16   bg_used_dirs_count;    /* ディレクトリ個数 */
__u16   bg_pad;
__u32   bg_reserved[3];
}; 
【００３６】
ブロックビットマップは、ブロックの使用可否を示し、アイノードビットマップは、アイノードの使用可否を示す。
【００３７】
アイノードは、一つのファイル(ディレクトリ、リンクなど)を表現する基本単位で、アイノードテーブルには、それぞれのアイノードに対するファイルの経路、位置、サイズ、タイプ(ファイル／ディレクトリ／シンボリングリンク／ＦＩＦＯなど)、許容権限などに対する情報が以下のように貯蔵されている。
【００３８】
struct ext2_inode {
__u16    i_mode;         /* ファイルモード */
__u16    i_uid;          /* Low 16 bits of Owner Uid */
__u32    i_size;         /* Size in bytes */
__u32    i_atime;        /* アクセス時刻 */
__u32    i_ctime;        /* 生成時刻 */
__u32    i_mtime;        /* 修正時刻 */
__u32    i_dtime;        /* 削除時刻 */
__u16    i_gid;          /* Group Idの下位16ビット */
__u16    i_links_count;  /* リンク個数 */
__u32    i_blocks;       /* ブロック個数 */
__u32    i_flags;        /* ファイルフラッグ */
union {
struct {
__u32  l_i_reserved1;
} linux1;
struct {
__u32  h_i_translator;
} hurd1;
struct {
__u32  m_i_reserved1;
} masix1;
} osd1;/* OS dependent 1 */
__u32    i_block[EXT2_N_BLOCKS];     /* ブロックに対するポインタ */
__u32    i_generation;               /* ファイルバージョン(ＮＦＳ用) */
__u32    i_file_acl;                 /* ファイルＡＣＬ */
__u32    i_dir_acl;                  /* ディレクトリＡＣＬ */
__u32    i_faddr;                    /* フラグメントアドレス */
union {
struct {
__u8     l_i_frag;        /* フラグメント番号*/
__u8     l_i_fsize;       /* フラグメントサイズ */
__u16    i_pad1;
__u16    l_i_uid_high;    /* these 2 fields    */
__u16    l_i_gid_high;    /* were reserved2[0] */
__u32    l_i_reserved2;
} linux2;
struct {
__u8     h_i_frag;        /* フラグメント番号*/
__u8     h_i_fsize;       /* フラグメントサイズ */
__u16    h_i_mode_high;
__u16    h_i_uid_high;
__u16    h_i_gid_high;
__u32    h_i_author;
} hurd2;
struct {
__u8     m_i_frag;        /* フラグメント番号*/
__u8     m_i_fsize;       /* フラグメントサイズ */
__u16    m_pad1;
__u32    m_i_reserved2[2];
} masix2;
} osd2;                         /* OS dependent 2 */
}; 
【００３９】
図２は、アイノードの構造を簡略に説明する図である。
【００４０】
データブロックには、アイノードテーブルのアイノードが示す全てのデータが実際位置する。
【００４１】
図３は、データブロックに存在するディレクトリエントリーの概略的な構造を示す図で、下記のように構成される。
【００４２】
struct ext2_dir_entry_2 {
__u32    inode;                /*アイノード番号*/
__u16    rec_len;              /* ディレクトリエントリー長さ */
__u8     name_len;             /* 名長さ */
__u8     file_type;
char     name[EXT2_NAME_LEN];  /* ファイル名 */
}; 
【００４３】
図４は、ディレクトリツリーの全体構造を示すアイノードテーブル及びデータブロックである。ここでは、ルートディレクトリ下にディレクトリ(Ａ、Ｂ、Ｃ、…)及びファイル(ア、イ、ウ、…)があり、ディレクトリＢ下にファイル(ａ、ｂ、ｃ、…、ｈ、…)がある場合のディレクトリツリーを例として表示した。
【００４４】
図５は、本発明の一実施形態による ＥＸＴ２ ファイルシステムのデータ復旧方法を示すフローチャートである。
【００４５】
図５を参照すると、本発明による方法は、データ復旧対象の貯蔵媒体からパーティションテーブルを抽出する(ａ)段階(Ｓ１００)と、該抽出されたパーティションテーブルを利用して該当パーティションからディレクトリ及びファイルのエントリーを抽出する(ｂ)段階(Ｓ１２０、Ｓ１４０〜Ｓ１６０)と、該エントリーを利用して該当データを抽出する(ｃ)段階(Ｓ１７０)と、該抽出されたデータを結合して新しいファイルとして貯蔵する(ｄ)段階(Ｓ１８０)と、を含む。
【００４６】
(ａ)段階は、パーティションテーブルが損傷された場合、セクター単位で読み込んだ後、予め指定されたファイルシステム形式にマッチングされたる情報が存在するか否かを確認する段階である。
【００４７】
(ｂ)段階は、パーティションからスーパーブロック情報を抽出する段階(Ｓ１２０)と、スーパーブロック情報を利用してグループディスクリプタ情報を抽出する段階(Ｓ１４０)と、グループディスクリプタ情報が示すアイノードテーブルを参考してルートディレクトリ以下の全てのレベルに対するディレクトリ及びファイルのエントリーを抽出する(ｂ３)段階(Ｓ１５０〜Ｓ１６０)と、を含む。
【００４８】
ここで、Ｓ１２０段階は、パーティションからスーパーブロック情報を抽出するとき、スーパーブロックの損傷有無を予め確認し、損傷されていないスーパーブロックのみを抽出する。また、(ｂ)段階は、パーティションがＥＸＴ２ファイルシステムを使用するか否かを予め確認する段階(Ｓ１３０)をさらに含む。
【００４９】
(ｄ)段階は、外部貯蔵装置または復旧対象のデータが貯蔵されたパーティション以外のパーティションに新しいファイルとして貯蔵する。
【００５０】
以下、図１ないし図５を参照して、このように構成された本発明によるＥＸＴ２ファイルシステムのデータ復旧過程を詳細に説明する。
【００５１】
まず、パーティションテーブルを抽出してディスクに対する情報を求める(Ｓ１００)。パーティションテーブルはＭＢＲから抽出し、ディスクの一番目のセクターの最後にＭＢＲを認識するための識別記号(０ｘＡＡ５５)が存在する。ＭＢＲの最後から０ｘＡＡ５５を除いて逆に６４バイトがパーティションテーブルである。
【００５２】
０ｘＡＡ５５が存在しないか、それとも、パーティションテーブルの一部が損傷された場合、ハードディスクの論理ドライブ情報を把握することが不可能になる可能性がある。
【００５３】
この場合、ハードディスクをセクター単位で読み込んだ後、予め指定されたファイルシステム形式にマッチングされる情報(本発明の場合は、スーパーブロック)が存在するか否かを確認することにより、論理ドライブ情報を把握することができる。このとき、セクター区間は、ユーザから入力されることもできる。従って、ユーザが過ちによってフォーマットをした場合も、データを上書きさえしなければ、このような方法によって論理ドライブ情報を把握することができる。
【００５４】
その次、復旧しようとする論理ドライブがユーザによって選択されると、該当パーティションからスーパーブロック情報を抽出するが(Ｓ１２０)、このとき、選択された論理ドライブは、本発明において具現しようとするＥＸＴ２ファイルシステムであることが最も望ましい。しかしながら、ファイルシステムに応じて復旧方法が異なるため、ユーザが選択した論理ドライブのファイルシステム種類を確認する必要がある。
【００５５】
このために、抽出されたパーティションテーブルの運営体系設定値がＬiｎｕｘであるか否かを確認する(Ｓ１１０)。パーティションテーブルには、４つのパーティションに対する情報が貯蔵されることができ、一つのパーティションに対する情報は、１６バイトで表示される。
【００５６】
１６バイト中、前から５番目のバイトが該当パーティションの運営体系を示すが、この値がＯｘ８３であると、Ｌiｎｕｘを示し、Ｏｘ０７であると、ＮＴＦＳファイルシステムを示す。
【００５７】
Ｓ１００段階で確認した結果、運営体系がＬiｎｕｘでない場合は終了し、運営体系がＬiｎｕｘである場合は、該当パーティションからスーパーブロック情報を抽出する(Ｓ１２０)。また、該抽出されたスーパーブロックの互換特徴値(compatible feature set)がＥＸＴ２であるか否かを確認する(Ｓ１３０)。互換特徴値が０である場合は、ＥＸＴ２ファイルシステムを示し、互換特徴値が４である場合は、ＥＸＴ３ファイルシステムを示す。
【００５８】
Ｓ１２０段階で、スーパーブロック情報は、ブロックグループ０から抽出することが最も望ましい。しかしながら、ブロックグループ０にあるスーパーブロックはウイルスなどによって最も損傷されやすいので、本発明では、ブロックグループ０にあるスーパーブロックの損傷有無をまず確認してから抽出する。
【００５９】
スーパーブロックの損傷を確認するためには、Ｍａｇｉｃ ｓｉｇｎａｔｕｒｅ、ＯＳ、及びＲｅｖｉｓｉｏｎ ｌｅｖｅｌ値をチェックすれば良い。Ｍａｇｉｃ ｓｉｇｎａｔｕｒｅ(s_magic)の値は、ＯｘＥＦ５３を有するべきであり、ＯＳ(s_creator_os)は、０の値を有するべきであり、Ｒｅｖｉｓｉｏｎ ｌｅｖｅｌ(s_rev_level)は、０または１の値を有するべきである。
【００６０】
スーパーブロックが損傷された場合は、Ｒｅｖｉｓｉｏｎ ｌｅｖｅｌによってその次のブロックグループのスーパーブロック情報を抽出する。つまり、スーパーブロックの仕様を満足するデータをセクター単位で検索することにより、その次のブロックグループのスーパーブロック情報を抽出することができる。
【００６１】
Ｒｅｖｉｓｉｏｎ ｌｅｖｅｌが０であると、スーパーブロックがそれぞれのブロックグループごとに一つずつ位置するが、１以上の値を有すると、０及び１の以後には３、５、７の累乗{つまり、３, ５, ７, ９(＝３２), ２５(＝５２), ４９(＝７２), ２７(＝３３), １２５(＝５３), ３４３(＝７３),…}にスーパーブロックが位置する。
【００６２】
このようにスーパーブロック情報を抽出し、ファイルシステムがＥＸＴ２であると確認されると、パーティションの全体構造を把握するために、スーパーブロック情報を利用してグループディスクリプタ情報を抽出する(Ｓ１４０)。
【００６３】
スーパーブロック情報のs_blocks_count値をs_blocks_per_group値によって割ると、全体ブロックグループの個数を求めることができる。このように求めた全体ブロックグループの個数の分だけグループディスクリプタを読み込めば良い。
【００６４】
このようにスーパーブロック情報及びグループディスクリプタ情報を抽出すると、パーティションに含まれたそれぞれのブロックグループを区分することが可能になる。
【００６５】
その次、抽出されたグループディスクリプタ情報が示すアイノードテーブルを参考してルートディレクトリのエントリーを抽出する(Ｓ１５０)。アイノードテーブルの２番目のアイノードにルートディレクトリに対する情報が貯蔵されており、２番目のアイノードが示すデータブロックにルートディレクトリのエントリーが貯蔵されている。
【００６６】
また、このような方式によってルートディレクトリ以下の全てのレベルに対するディレクトリ及びファイルのエントリーを抽出する(Ｓ１５０)。
【００６７】
Ｓ１５０段階で抽出されたディレクトリ及びファイルの目録を全てユーザに見せることが望ましいが、処理容量上の問題のため、ルートディレクトリ、該ルートディレクトリに属するその次のレベルのディレクトリ、ルートディレクトリに属するファイルまでのみ見せるように構成することもできる。
【００６８】
後者のように構成する場合は、ユーザが見たいと思うディレクトリを選択するとき、それに該当するディレクトリ及びその次のレベルのディレクトリ、該当ディレクトリに属するファイルを見せるように構成すれば良い。
【００６９】
その次、ユーザが復旧しようとするディレクトリやファイルを選択すると、抽出されたエントリーを利用してデータブロックから該当データを抽出する(Ｓ１７０)。
【００７０】
その次、抽出されたデータを結合して新しいファイルとして貯蔵する(Ｓ１８０)。このとき、結合したデータは、元来データのサイズと同一か、または大きくなるので、元来のサイズと同一になるようにデータの最後の部分を切ることが望ましい。
【００７１】
例えば、一つのサイズが４Ｋバイトであるデータブロック１０個を結合したと仮定する。ここで、元来データのサイズが３８Ｋバイトであると、４０Ｋバイトのデータの後部分の２Ｋバイトを切って３８Ｋバイトを新しいファイルとして貯蔵する。
【００７２】
Ｓ１００段階から抽出された情報及びデータはメモリーに貯蔵し、新しいファイルは、外部貯蔵装置(例えば、ハードディスク、フロッピー（登録商標）ディスクなど)または復旧対象のデータが貯蔵されたパーティション以外のパーティションに貯蔵することが望ましい。ファイルやディレクトリの単純削除、または、ウイルスなどによる損傷の場合も、前述したような方法によって復旧することができる。
【００７３】
一方、一般的に、削除されたファイルを復旧する他の方法として、削除されたファイルのアイノードをＳ１４０〜Ｓ１７０段階の間で検索する方法があるが、該検索段階は、Ｓ１６０段階の次に遂行することが最も望ましい。
【００７４】
ファイル削除時、該当ファイルが属しているディレクトリエントリーのアイノード番号フィールドが０にクリアされ、ファイルに対する情報を有するアイノードに削除時間が設定される。また、スーパーブロック及びグループディスクリプタなどの情報が変更される。
【００７５】
本実施形態では、アイノード番号フィールドが０にクリアされたディレクトリエントリーを検索し、検索されたディレクトリ及びそれに属するファイルをユーザに見せるが、削除時間が設定されたアイノードを検索して見せることもできる。
【００７６】
その次、ユーザが復旧しようとするファイルを選択すると、Ｓ１７０及びＳ１７０段階を順次に実行する。
【００７７】
以上、ＥＸＴ２ファイルシステムに限定して説明したが、ＥＸＴ３ファイルシステムはＥＸＴ２ファイルシステムと物理的に同一の構造を有するので、ＥＸＴ３ ファイルシステムでも同一の方法によってデータを復旧することができる。ただし、ＥＸＴ３ファイルシステムで削除されたファイルは除外される  
【図面の簡単な説明】
【００７８】
【図１】ＥＸＴ２ファイルシステムの構造を説明した図である。
【図２】アイノードの構造を簡略に説明した図である。
【図３】データブロックに存在するディレクトリエントリーの概略的な構造を示す図である。
【図４】ディレクトリツリーの全体構造を示すアイノードテーブル及びデータブロックである。
【図５】本発明の一実施形態による ＥＸＴ２ファイルシステムのデータ復旧方法を示すフローチャートである。
【図１】
2005166042.tif 000003
【図２】
2005166042.tif 000004
【図３】
2005166042.tif 000005
【図４】
2005166042.tif 000006
【図５】
2005166042.tif 000007