(57)【特許請求の範囲】
【請求項１】
第１の記憶媒体に記憶されているバックアップ対象データを第２の記憶媒体へバックアップするためのバックアップ処理装置であって、
前記バックアップ対象データをルートディレクトリにある第１階層のサブディレクトリごとにセッション分割する、分割パターンＢの場合に必要なバックアップ容量を算出する算出手段と、
前記バックアップ対象データを分割しない、分割パターンＡの場合に必要なバックアップ容量が前記第２の記憶媒体の空き容量以下であって、かつ、前記分割パターンＢの場合に必要なバックアップ容量が前記第２記憶媒体の空き容量よりも大きいときには、分割パターンＡを採用する分割パターン決定手段と、
前記分割パターン決定手段において前記分割パターンＡが採用された場合には、前記分割パターンＡに従って第１の記憶媒体から第２の記憶媒体へコピーするコピー手段と、を備えるバックアップ処理装置。
【請求項２】
前記算出手段は、前記バックアップ対象データを、前記第１階層のサブディレクトリ配下の第２階層以下のサブディレクトリごとにさらにセッション分割をする、分割パターンＣの場合に必要なバックアップ容量を算出し、
前記分割パターン決定手段は、前記分割パターンＢの場合に必要なバックアップ容量が前記第２記憶媒体の空き容量以下であって、かつ、前記分割パターンＣの場合に必要なバックアップ容量が前記第２記憶媒体の空き容量よりも大きいときには、分割パターンＢを採用し、
前記分割パターン決定手段において前記分割パターンＢが採用された場合には、前記コピー手段は、前記分割パターンＢに従って前記バックアップ対象データを分割して、第１の記憶媒体から第２の記憶媒体へコピーすることを特徴とする請求項１記載のバックアップ処理装置。
【請求項３】
前記第２階層以下の同一のサブディレクトリに複数のファイルが含まれているときは、
前記算出手段は、前記各ファイルの作成日付に従ってさらにセッション分割をする、分割パターンＤの場合に必要なバックアップ容量を算出し、
前記分割パターン決定手段は、分割パターンＣの場合に必要なバックアップ容量が前記第２記憶媒体の空き容量以下であって、かつ、分割パターンＤの場合に必要なバックアップ容量が前記第２記憶媒体の空き容量よりも大きいときには、分割パターンＣを採用し、
前記分割パターン決定手段において前記分割パターンＣが採用された場合には、前記コピー手段は、前記分割パターンＣに従って前記バックアップ対象データを分割して、第１の記憶媒体から第２の記憶媒体へコピーすることを特徴とする請求項２に記載のバックアップ処理装置。
【請求項４】
前記算出手段は、前記バックアップ対象データの容量に加えて、管理領域、ルートディレクトリ領域及びパステーブルを考慮して、各分割パターンのときに必要なバックアップ容量を算出する、請求項１〜３のいずれかに記載のバックアップ処理装置。
【請求項５】
前記第２の記憶媒体は、ＣＤ−ＲＯＭファイルシステムに従うことを特徴とする請求項１〜４のいずれかに記載のバックアップ処理装置。
【請求項６】
バックアップ処理装置が行うバックアップ処理方法であって、
算出手段が、第１の記憶媒体に記憶されているバックアップ対象データをルートディレクトリにある第１階層のサブディレクトリごとにセッション分割する、分割パターンＢの場合に必要なバックアップ容量を算出するステップと、
分割パターン決定手段が、前記バックアップ対象データを分割しない、分割パターンＡの場合に必要なバックアップ容量が前記第２の記憶媒体の空き容量以下であって、かつ、前記分割パターンＢの場合に必要なバックアップ容量が前記第２記憶媒体の空き容量よりも大きいときには、分割パターンＡを採用するステップと、
前記採用ステップにおいて前記分割パターンＡが採用された場合には、コピー手段が、前記分割パターンＡに従って第１の記憶媒体から第２の記憶媒体へコピーするステップと、を有するバックアップ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ある記録媒体に格納されているデータを他の記録媒体にバックアップするための技術に関し、特にバックアップに失敗したときのデータ損失リスクを低減するための技術に関する。
【背景技術】
【０００２】
電子式スチルカメラ（いわゆるデジタルカメラ）やデジタルビデオカメラなどで撮影した画像データは、まずカメラ内に格納されている半導体メモリなどに格納される。そして、ユーザは、この半導体メモリに格納されている画像データをＣＤあるいはＤＶＤなどの他の記録媒体にバックアップした後、画像データを消去して、この半導体メモリを繰り返し利用する。
【０００３】
つまり、電子式スチルカメラやデジタルビデオカメラの普及により、一般ユーザが大容量データをバックアップする機会が急速に増加している。
【０００４】
例えば、ＣＤなどにバックアップをするとともに、元データが格納されている記憶媒体から元データを消去する場合、バックアップの途中でエラーが発生し、バックアップ処理が完了しないときは、ＣＤに書き込んだデータはすべて失われてしまう。
【０００５】
そこで、特許文献１には、このような場合にデータの論理的な整合を保つように、自動的にバックアップ処理を継続するためシステムが開示されている。
【特許文献１】特開平９−３０５９７４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
近年、バッテリ駆動可能な携帯型端末でバックアップ処理が可能なものが実用されている。この端末を用いた場合、バックアップ処理途中でのバッテリ切れ、あるいは外部からの衝撃等によるエラーが発生する確率が高くなる。このような場合は、特許文献１のようにバックアップ処理を継続することができない。
【０００７】
そこで、本発明の目的は、バックアップ処理に失敗し、処理を継続できないようなときであっても、既にバックアップしたデータを確保できるようにすることである。
【０００８】
本発明の別の目的は、バックアップが正常終了した場合でも、その後傷または汚れなどにより記録媒体が物理的に損傷したときでも、一部のデータの読み出しを可能とすることである。
【課題を解決するための手段】
【０００９】
本発明の一実施態様に従うバックアップ処理装置は、第１の記憶媒体に記憶されているバックアップ対象データを第２の記憶媒体へバックアップするためのバックアップ処理装置であって、前記バックアップ対象データを複数のセッションに分割してバックアップする場合に必要な第２の記憶媒体の容量を算出し、当該算出された必要な容量と前記第２の記憶媒体の空き容量とに基づいてセッション分割数を決定する分割手段と、前記バックアップ対象データを、前記セッション分割数に分けて、第１の記憶媒体から第２の記憶媒体へコピーするコピー手段と、を備える。
【００１０】
これにより、バックアップ対象データを複数セッションに分けてバックアップすることができ、バックアップ中にトラブルが発生してもデータを失うリスクが低減される。
【００１１】
好適な実施形態では、前記分割手段は、前記バックアップ対象データをルートディレクトリにある第１階層のサブディレクトリごとにセッション分割して分割数を決定することようにしてもよい。
【００１２】
好適な実施形態では、前記分割手段は、前記第１階層のサブディレクトリ配下の第２階層以下のサブディレクトリごとにさらにセッション分割をして分割数を決定するようにしてもよい。
【００１３】
好適な実施形態では、同一ディレクトリに複数のファイルが含まれているときは、各ファイルの作成日付に従ってさらにセッション分割をして前記セッション分割数を決定するようにしてもよい。
【００１４】
好適な実施形態では、同一ディレクトリにデジタルカメラで撮影された複数の画像ファイルが含まれているときは、各画像ファイルに含まれている撮影条件に関する付帯情報に従ってさらにセッション分割をして前記セッション分割数を決定するようにしてもよい。
【００１５】
好適な実施形態では、前記第２の記憶媒体は、ＣＤ−ＲＯＭファイルシステムに従うようにしてもよい。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の一実施形態に係るバックアップ処理装置について、図面を参照して説明する。
【００１７】
図１は、本実施形態に係るバックアップ処理装置１の機能構成図である。
【００１８】
すなわち、バックアップ処理装置１は、第１の記憶媒体に格納されているバックアップ対象データを、第２の記憶媒体へコピーしてデータバックアップを行う。本実施形態では、メモリカード２に格納されているデータをＣＤにバックアップする場合を例にあげて説明するが、第１及び第２の記憶媒体はこれら以外であってもよい。
【００１９】
また、バックアップ処理装置１は、例えば汎用的なコンピュータシステムにより構成され、以下に説明するバックアップ処理装置１内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００２０】
さらに、バックアップ処理装置１は、この装置単体で実現することもできるし、プリンタ、デジタル複合機、ビューワなど他の装置に組み込み、その装置の一部の機能として実現することもできるし、電子式スチルカメラ、デジタルビデオカメラなどの一部機能を利用して、電子式スチルカメラ、デジタルビデオカメラと組み合わせて実現することもできる。
【００２１】
図１に示すバックアップ処理装置１は、バックアップ管理部１１と、メモリカードリーダ／ライタ１２と、ＣＤリーダ／ライタ１３とを備える。
【００２２】
メモリカードリーダ／ライタ１２は、メモリカード２に格納されているデータを読み出し、メモリカード２にデータを書き込む。
【００２３】
ＣＤリーダ／ライタ１３は、ＣＤ３に格納されているデータを読み出し、ＣＤ３にデータを書き込む。
【００２４】
バックアップ管理部１１は、メモリカード２に格納されているバックアップ対象データを、ＣＤ３にバックアップするための処理を行う。例えば、バックアップ対象データの容量が大きく、バックアップ処理に時間がかかる場合には、バックアップ管理部１１は、所定のルールに基づいてデータを分割する。そして、分割されたデータをそれぞれ一つの単位として、複数のセッションに分けてバックアップを行う。バックアップ対象データの分割については後述する。
【００２５】
図２は、メモリカード２に格納されているディレクトリ構造の一例を示す。
【００２６】
同図に示すように、メモリカード２には、ルートディレクトリ２００直下の第１階層２１にサブディレクトリである「ＤＣＩＭ」ディレクトリ２１１と「ＭＩＳＣ」ディレクトリ２１２とが存在する。「ＤＣＩＭ」ディレクトリ２１１の配下の第２階層２２には、さらにサブディレクトリである「１００ＡＢＣＤＥ」ディレクトリ２２１と「１０１ＡＢＣＤＥ」ディレクトリ２２２とが存在する。そして、「１００ＡＢＣＤＥ」ディレクトリ２２１には、５つの画像ファイル２５１が存在し、「１０１ＡＢＣＤＥ」ディレクトリ２２２には、２つの画像ファイル２５２が存在する。さらに、「ＭＩＳＣ」ディレクトリ２１２には、一つのテキストファイル（「ＡＵＴＰＲＩＮＴ．ＭＲＫ」）２５３が存在する。
【００２７】
図２に示すディレクトリ構造に含まれるデータをバックアップ対象データとしてＣＤ３にバックアップしたときの、ＣＤ３のデータ構造を説明する。
【００２８】
図３は、図２に示すバックアップ対象データを一つのセッションでＣＤ３にバックアップしたときのバックアップデータ３０のデータ構造を示す。
【００２９】
ＣＤ３は、ＣＤ−ＲＯＭファイルシステムに従った構造になっている。従って、バックアップデータ３０の先頭及び末尾に、ＣＤ−ＲＯＭファイルシステムに従う管理領域３０１，３０２が設けられている。
【００３０】
なお、本実施形態ではＩＳＯ９６６０レベル１の規格に従うＣＤを例にして説明するが、本発明はこれを拡張した他の規格（例えば、ＩＳＯ９６６０レベル２，Ｊｏｌｉｅｔなど）にも適用することが可能である。
【００３１】
バックアップデータ３０は、先頭の管理領域３０１に引き続き、ルートディレクトリエントリ３１０と、サブディレクトリである「ＤＣＩＭ」ディレクトリ２１１、及び「ＭＩＳＣ」ディレクトリ２１２のディレクトリエントリ３１１、３１２とが設けられている。
【００３２】
「ＭＩＳＣ」ディレクトリ２１２にはサブディレクトリが存在しないので、ディレクトリエントリ３１２に引き続いてテキストファイル２５３のデータ本体３５３が格納される。
【００３３】
これに引き続いて第２階層２２の「１００ＡＢＣＤＥ」ディレクトリ２２１のディレクトリエントリ３２１及び「１００ＡＢＣＤＥ」ディレクトリ２２１内の画像ファイル２５１のデータ本体３５１、並びに「１０１ＡＢＣＤＥ」ディレクトリ２２２のディレクトリエントリ３２２及び「１０１ＡＢＣＤＥ」ディレクトリ２２２内の画像ファイル２５２のデータ本体３５２が格納される。
【００３４】
以上説明した範囲で、バックアップ対象データのディレクトリ及びデータ本体のすべてが含まれている。ＣＤ−ＲＯＭファイルシステムの場合、さらに、ＣＤ３に格納されている全データのディレクトリ構造を示すパステーブル３３０が設けられる。
【００３５】
パステーブル３３０には、バックアップデータ３０をＣＤ３に格納する時点で、ＣＤ３に含まれる全データを図２に示すようなツリー構造で表現するためのものである。従って、例えば、新品のＣＤ３にバックアップデータ３０を書き込む場合は、パステーブル３３０は、図２に示すツリー構造を表現するものになっている。
【００３６】
図５から図９には、ルートディレクトリ，「ＤＣＩＭ」ディレクトリ，「ＭＩＳＣ」ディレクトリ，「１００ＡＢＣＤＥ」ディレクトリ、「１０１ＡＢＣＤＥ」ディレクトリのディレクトリエントリ３１０，３１１，３１２，３２１，３２２のデータ構造を示す。
【００３７】
それぞれのディレクトリエントリ３１０，３１１，３１２，３２１，３２２には、自分自身のセクタを指すポインタレコード３１０１、３１１１，３１２１，３２１１，３２２１と、親ディレクトリのセクタを指すポインタレコード３１０２、３１１２，３１２２，３２１２，３２２２とが含まれていて、これのデータ長はいずれも３４バイト固定である。
【００３８】
さらに、それぞれのディレクトリエントリ３１０，３１１，３１２，３２１，３２２には、それぞれのディレクトリの直下にサブディレクトリがあるときは、サブディレクトリレコード３１０３，３１１３が含まれていて、それぞれのディレクトリの直下にファイルがあるときは、ファイルレコード３１２４，３２１４，３２２４が含まれている。
【００３９】
サブディレクトリレコード３１０３，３１１３には、そのサブディレクトリのディレクトリエントリが格納されているセクタを指すポインタとサブディレクトリ名が含まれていて、レコード長は可変長であり、最大４６バイトである。
【００４０】
ファイルレコード３１２４，３２１４，３２２４には、ファイル本体が格納されているセクタを指すポインタとファイル名が含まれていて、レコード長は可変長であり、最大４６バイトである。
【００４１】
例えば図５に示すルートディレクトリエントリ３１０では、「ＤＣＩＭ」ディレクトリ２１１のディレクトリレコード３１０３及び「ＭＩＳＣ」ディレクトリ２２１のディレクトリレコード３１０３とが含まれている。図７に示す「ＭＩＳＣ」ディレクトリのディレクトリエントリ３１２では、テキストファイル２５３のファイルレコード３１２４が含まれている。
【００４２】
図１０は、パステーブル３３０のデータ構造を示す。
【００４３】
パステーブル３３０は、ルートディレクトリレコード３３０１と、サブディレクトリレコードごとにそれぞれの親ディレクトリを示すポインタ及びディレクトリ名を含むサブディレクトリレコード３３０３とを含む。
【００４４】
ルートディレクトリレコード３３０１は、１０バイト固定であり、サブディレクトリレコード３３０３は可変長であり、最大１８バイトである。
【００４５】
ここで、ＣＤ３の１セクタは２０４８バイトである。従って、各ディレクトリエントリ３１０，３１１，３１２，３２１，３２２及びパステーブル３３０に格納すべきデータ量が２０４８バイトに満たないときでも、一つのディレクトリエントリないしはパステーブルを格納するときは２０４８バイトの倍数で記憶領域が消費される。また、これはデータ本体を格納する場合も同様である。つまり、データ本体がＣＤ３に格納されるときは、データ本体のサイズに応じて２０４８バイト単位で記憶領域が消費される。
【００４６】
次に、図４は、図２に示すバックアップ対象データを二つのセッションに分けてＣＤ３にバックアップしたときのバックアップデータ３１，３２のデータ構造を示す。
【００４７】
すなわち、ここでは、第１階層２１の「ＤＣＩＭ」ディレクトリ２１１及びその配下のサブディレクトリ及びファイルを含む第１セッションと、「ＭＩＳＣ」ディレクトリ２１２及びその配下のファイルを含む第２セッションとに分割し、２回に分けてバックアップを行った場合のバックアップデータ３１，３２のデータ構造を示す。
【００４８】
図４（ａ）は、第１セッションのバックアップを行った後のバックアップデータ３１を示す。
【００４９】
バックアップデータ３１は、図３に示すバックアップデータ３０から「ＭＩＳＣ」ディレクトリエントリ３１２及びテキストファイル本体３５３を除いた構成となっている。ただし、パステーブル３３０ａは、その内容がバックアップデータ３０のパステーブル３３０と異なる。すなわち、「ＭＩＳＣ」ディレクトリ２１２がコピーされていないので、パステーブル３３０ａには、図２に示すディレクトリ構造において、「ＭＩＳＣ」ディレクトリ２１２及びその配下のテキストファイル２５３を除いたディレクトリ構造を示す情報が含まれている。
【００５０】
図４（ｂ）は、第１セッションに引き続き、第２セッションのバックアップを実行した場合のバックアップデータ３２を示す。
【００５１】
バックアップデータ３２には、このセッションのバックアップ対象である「ＭＩＳＣ」ディレクトリ２１２のディレクトリエントリ３１２ｂ及びテキストファイル本体３５３ｂが含まれている。これに加え、管理領域３０１ｂ、３０２ｂとルートディレクトリエントリ３１０ｂと、パステーブル３３０ｂとが含まれている。
【００５２】
ここで、パステーブル３３０ｂには、図２に示すディレクトリ構造を示す情報が含まれている。なぜならば、第１セッションで「ＤＣＩＭ」ディレクトリ２１１がバックアップされ、第２セッションで「ＭＩＳＣ」ディレクトリ２１２がコピーされたので、ＣＤ３には図２に示すすべてのデータがコピーされた状態になっているからである。
【００５３】
これより、同じデータをバックアップする場合でも、セッションを分けることにより全体で必要な容量が異なることがわかる。つまり、図４のようにセッションを複数に分けると、図３のようにセッションを分けずにバックアップした場合と比較して、管理領域３０１ｂ、３０２ｂ、ルートディレクトリエントリ３１０ｂ、及びパステーブル３３０ｂの容量だけ多く必要になる。
【００５４】
図１１は、バックアップ管理部１１が行う分割バックアップ処理の手順を示すフローチャートである。
【００５５】
図１２は、ディレクトリ構造及び分割パターンの関係を示す図である。
【００５６】
ここでは、図１２に示すディレクトリ構造を有するバックアップ対象データを、図１１に示すフローチャートに従ってバックアップする場合を例にして説明する。
【００５７】
まず、バックアップ管理部１１は、分割パターンＡとして分割数０とする（Ｓ１１）。すなわち、バックアップ対象データを分割せずに、１セッションでバックアップする場合について検討する。
【００５８】
ここで、バックアップ管理部１１は、バックアップ対象データの全容量がバックアップ先メディアであるＣＤ３の空き容量よりも大きいか否かを判定する（Ｓ１２）。バックアップ対象データの全容量がＣＤ３の空き容量よりも大きいときは（Ｓ１２：Ｙｅｓ）、ＣＤ３の容量が不足しているのでバックアップできないので、この時点で処理を終了する。
【００５９】
バックアップ対象データの全容量がＣＤ３の空き容量よりも大きくないときは（Ｓ１２：Ｎｏ）、バックアップ管理部１１は、分割パターンＢとして、第１階層のサブディレクトリ単位にセッション分割をする場合に必要なＣＤ３の容量を計算する（Ｓ１３）。
【００６０】
図１２の例では、「ＤＣＩＭ」ディレクトリ２１１を第１セッション、「ＭＩＳＣ」ディレクトリ２１２を第２セッションとする分割である。
【００６１】
上述したように、セッションを分割すると、管理領域等が増えるので、バックアップをするために全体として必要となる容量が増える。さらに、ディレクトリまたはファイルの数、ファイルのサイズなどに応じて、必要となるセクタ数も異なる場合がある。
【００６２】
例えば、サブディレクトリごとにディレクトリエントリとして１セクタが必要である。また、各ディレクトリエントリ内では、ディレクトリレコードの最大長が４６バイトであるから、１セクタには最大４４ディレクトリレコードを格納可能である。つまり、あるディレクトリ直下のサブディレクトリ数に応じて、ディレクトリエントリとして必要なセクタ数が異なることがある。あるいは、パステーブル内では、ディレクトリレコードの最大長が１８バイトであるから、１セクタには最大１１３ディレクトリレコードを格納可能である。つまり、１セッションに含まれる全ディレクトリ数に応じて、パステーブルに必要なセクタ数が異なることがある。
【００６３】
そこで、バックアップ管理部１１は、各セッションに含まれるディレクトリ構造及びディレクトリ数に従って、バックアップに必要な全容量を算出する。
【００６４】
次に、バックアップ管理部１１は、分割パターンＢで必要な全容量がバックアップ先メディアであるＣＤ３の空き容量よりも大きいか否かを判定する（Ｓ１４）。分割パターンＢで必要な全容量がＣＤ３の空き容量よりも大きいときは（Ｓ１４：Ｙｅｓ）、分割パターンＡが選択される（Ｓ１５）。
【００６５】
分割パターンＢで必要な全容量がＣＤ３の空き容量よりも大きくないときは（Ｓ１４：Ｎｏ）、バックアップ管理部１１は、分割パターンＣとして第２階層のサブディレクトリ単位にセッション分割する場合に必要なＣＤ３の容量を計算する（Ｓ１６）。
【００６６】
図１２の例では、「１００ＡＢＣＤＥ」ディレクトリ２２１と「１０１ＡＢＣＤＥ」ディレクトリ２２２とをさらに別セッションに分割する。
【００６７】
バックアップ管理部１１は、分割パターンＣで必要な全容量がバックアップ先メディアであるＣＤ３の空き容量よりも大きいか否かを判定する（Ｓ１７）。分割パターンＣで必要な全容量がＣＤ３の空き容量よりも大きいときは（Ｓ１７：Ｙｅｓ）、分割パターンＢが選択される（Ｓ１８）。
【００６８】
分割パターンＣで必要な全容量がＣＤ３の空き容量よりも大きくないときは（Ｓ１７：Ｎｏ）、バックアップ管理部１１は、分割パターンＤとして、第２階層のサブディレクトリ内の複数のファイルを２つのグループに分割し、このときに必要なＣＤ３の容量を計算する（Ｓ１９）。
【００６９】
ここで、第３階層以下のサブディレクトリが存在する場合には、さらにサブディレクトリ単位に分割するようにしてもよい。ここでは、第３階層以下のサブディレクトリが存在しないので、最下位層である第２階層のサブディレクトリに多数存在するファイルを複数のグループに分割する。
【００７０】
ここで、同一ディレクトリに存在する複数のファイルは、以下のようにして分割してもよい。例えば、ファイルの作成日付が同一のものを１グループとしたり、ファイル名が連番になっているときは、その連番が途切れたところで分割したり、画像ファイルに含まれる付帯情報（例えばＥｘｉｆ形式のファイルに含まれる撮影情報など）に基づいて分割したりしてもよい。
【００７１】
そして、バックアップ管理部１１は、分割パターンＤで必要な全容量がＣＤ３の空き容量よりも大きいか否かを判定する（Ｓ２０）。分割パターンＤで必要な全容量がＣＤ３の空き容量よりも大きいときは（Ｓ２０：Ｙｅｓ）、分割パターンＣが選択される（Ｓ２１）。
【００７２】
分割パターンＤで必要な全容量がＣＤ３の空き容量よりも大きくないときは（Ｓ２０：Ｎｏ）、分割パターンＤが選択される（Ｓ２２）。
【００７３】
そして、バックアップ管理部１１は、上記の処理により選択された分割パターンに従って、バックアップ対象データをセッションごとにバックアップする（Ｓ２３）。
【００７４】
これにより、バックアップの途中でトラブルが生じた場合でも、全データを失うようなことはなく、より多くのデータをバックアップすることができる。
【００７５】
なお、上述の処理手順において、バックアップ対象データが単一のディレクトリ及びその配下のファイルであるときは、分割パターンＢ，Ｃはあり得ないので、これに関連する処理はスキップする。
【００７６】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【図面の簡単な説明】
【００７７】
【図１】本発明の一実施形態に係るバックアップ処理装置１の機能構成図である。
【図２】メモリカード２に格納されているディレクトリ構造の一例を示す。
【図３】１セッションでＣＤ３にバックアップしたときのデータ構造を示す。
【図４】２セッションに分けてＣＤ３にバックアップしたときのデータ構造を示す。
【図５】ルートディレクトリエントリのデータ構造を示す。
【図６】「ＤＣＩＭ」ディレクトリエントリのデータ構造を示す。
【図７】「ＭＩＳＣ」ディレクトリエントリのデータ構造を示す。
【図８】「１００ＡＢＣＤＥ」ディレクトリエントリのデータ構造を示す。
【図９】「１０１ＡＢＣＤＥ」ディレクトリエントリのデータ構造を示す。
【図１０】パステーブルのデータ構造を示す。
【図１１】分割バックアップ処理の手順を示すフローチャートである。
【図１２】ディレクトリ構造及び分割パターンの関係を示す図である。
【符号の説明】
【００７８】
１…バックアップ処理装置、２…メモリカード、３…ＣＤ、１１…バックアップ管理部、３０、３１，３２…バックアップデータ、３０１，３０２…管理領域、３１０…ルートディレクトリエントリ、３１１…「ＤＣＩＭ」ディレクトリエントリ、３１２…「ＭＩＳＣ」ディレクトリエントリ、３２１…「１００ＡＢＣＤＥ」ディレクトリエントリ、３２２…「１０１ＡＢＣＤＥ」ディレクトリエントリ、３３０…パステーブル。
【図１】
0004508137.tif 000002
【図２】
0004508137.tif 000003
【図３】
0004508137.tif 000004
【図４】
0004508137.tif 000005
【図５】
0004508137.tif 000006
【図６】
0004508137.tif 000007
【図７】
0004508137.tif 000008
【図８】
0004508137.tif 000009
【図９】
0004508137.tif 000010
【図１０】
0004508137.tif 000011
【図１１】
0004508137.tif 000012
【図１２】
0004508137.tif 000013