JP4157858B2 - ストレージ・エリア・ネットワーク（ｓａｎ）ファイル・システムの並列高速バックアップ - Google Patents

Description

本発明は、全般的には、ファイル・システムをバックアップする方法およびシステムを対象とする。具体的には、本発明は、分散データ処理システムまたは並列データ処理システムで特に有用と思われる。というのは、本発明の構造によって、バックアップ処理の複数の独立の単位への区分化が可能になるからである。更に具体的には、本発明は、特に、分散データ処理ステムまたは並列データ処理システムのストレージ・エリア・ネットワークと共に使用可能である。

ディスク・ストレージにおける進歩によって、単一のファイル・システム内で大量のデータおよび多数のファイルを管理する能力が生み出された。これによって、大量のデータの移動に関連する問題と、どのファイルがバックアップされなければならないかの識別に関連する問題に起因して、ネットワーク内のファイルの普通のバックアップ・コピーを作る際の問題が生じる。

ファイルをバックアップする従来の技法では、フル・モードまたは増分モードのいずれかで動作することができるバックアップ・アプリケーションを実行することを必要とする。フル・バックアップ（即ち、フル・モードで実行されるバックアップ。ベース・バックアップとも称する）では、名前ツリー（用語「名前ツリー」または「名前空間」の詳細な議論については下を参照されたい）全体を読み取り、各ファイルのコピーを転送することによって、ファイル・システム全体が単一のデータシンクにバックアップされる。増分バックアップでは、作成または変更されたファイルについてファイルの新しいコピーが転送され、増分バックアップはまた削除されたファイルの注記も作成する。削除されたファイルのバックアップ・コピーは、最終的に、あるポリシー機構（たとえば、バックアップ・コピーを１カ月間保存する）に従って削除される。

上で説明した状況において存在する、本発明によって対処される２つの問題がある：（１）第１の問題は、その性質がなければそうならなかったのだが、データ・レートを不当に制限するというデータおよびファイル転送の持つシリアル（連続的）な性質、から生じるバックアップ・アプリケーションのシリアルな性質であり、（２）第２の問題は、どのファイルが実際にバックアップを必要とするかをすばやく判定する能力の欠如である。ファイル・バックアップ操作の既存の技法では、通常は、ファイル・システム階層内の名前空間全体が読み取られ、各ファイルに関するあるファイル情報が抽出される。これは、ファイル・システム内のすべてのファイルに対してファイル・システム呼出しを実行することを必要とする（Ｐｏｓｉｘファイル・システム標準規格に従うデータ処理システムでは、この呼出しが、「ｓｔａｔ（）」コマンドによってもたらされる）。この呼出しは、ディスクに保管された情報を必要とし、ファイル名の順番で実行されるので、通常は、それぞれ数ミリ秒（ｍｓ）の時間的「コスト」を有するディスク操作がもたらされる。たとえば、１億個のファイルを有し、５ｍｓでファイル情報を読み取ることができるディスクを有するファイル・システムは、各ファイルを検査するのに１３３時間を必要とする。ＵＮＩＸ（Ｒ）オペレーティング・システム（Ｕｎｉｘ（登録商標）は、The Open Groupの登録商標である）の開発の初期から、「ｉノード」（あるファイル・システム構造の記述に幅広く使用されているこの用語の説明については、下を参照されたい）によるバックアップの技法が存在したが、これらの技法は、ファイルの識別が、一般に人間のファイル・システム・ユーザによって認識可能なファイル名自体ではなく、人間が使用可能な識別子ではないｉノード番号である、という問題を被っている。

このファイル・バックアップ問題に対する唯一の他の既知の解決策は、変更されたファイルの連続的ジャーナル化に基づくファイル・システムに存在する。しかし、この解決策では、ファイルの修正、削除、または名前変更のたびにプログラム終了が呼び出され、その結果、バックアップされる必要があるファイルを表したある形のログの作成がもたらされる。この解決策は、必要なすべての情報が、バックアップの時に即座に使用可能であるという長所を有するが、継続的にログに情報を付加するというコスト的短所を有する。更に、非常に頻繁に発生する状況であるが、複数回修正されるファイルについては、当該付加されるレコードが冗長となることがある。

本発明が使用される環境のよりよい理解のために、当技術分野で、下記の用語が一般に明確に理解された概念を指すのに使用される。下に示す定義は、便宜のために、ならびにかかわる問題および提案される解決策のよりよい理解のために提供され、ファイル・システム技術の技量を有する者によって理解されるように、一般的に理解される意味からの変形の暗示を意図するものではない。本発明は、ファイルおよびファイル・システムを取り巻く概念に密接にかかわるので、読者に、少なくともいくつかのより関連する用語について、簡潔な記述を与えることが有用である。より完全なリストは、本発明と同一の譲受人に譲渡された米国特許第６０３２２１６号明細書にある。この特許明細書は、参考文献として本明細書に組み込まれている。この特許からの用語からなる下記の用語集が提供されるのは、これらの用語が、本発明をより容易に理解するのに最も関連するのであるからである。

データ／ファイル・システム・データ： これは、特定のアプリケーションとの関連でのみ意味がある任意のビット列である。

ファイル： コンピュータ・アプリケーションによってアクセスできる名前付きビット列。ファイルは、長さ、修正時刻、および最終アクセス時刻などの標準属性を有する。

メタデータ： これは、ファイルの構造とファイル・システムを含むディスクの使用とを記述するために、ファイル・システム・ソフトウェアによって作成される制御構造である。このタイプのファイル・システムに適用される特定のタイプのメタデータの特徴を下で特に示すが、これには、ディレクトリ、ｉノード、割振りマップ、およびログが含まれる。

ディレクトリ： これは、ｉノードによって表される一組のデータに名前を関連付ける制御構造である。

ｉノード： ファイルの属性と、ファイルを構成するデータを含むディスク（または他の記憶媒体）の区域への一連のポインタとを含むデータ構造。間接ブロックによってｉノードを補完することができ、即ちこれら間接ブロックは、たとえばファイルが大きい場合には、追加ポインタによって当該ｉノードを補完する。

割振りマップ： これは、ディスクの特定の区域（またはｉノードなどの他の制御構造）が、使用中かまたは使用可能であるかどうかを示す制御構造である。これによって、ソフトウェアが、使用可能なブロックおよびｉノードを新しいファイルに効率的に割り当てられるようになる。この用語は、ファイル・システム操作の全般的な理解に有用であるが、本発明の動作に関しては周辺でのみ使用される。

ログ： 障害状況での消失に対する保護のために、他のタイプのメタデータを同期状態に（即ち、矛盾がない状態に）保つために使用されるレコードの組である。ログには、複数の構造に対する関連する更新を記述する単一のレコードが含まれる。この用語は、周辺でのみ有用であるが、上で説明した代替解決策との関連で提供される。

ファイル・システム： ディスク（または他の媒体）の定義された組を管理し、また、データおよびデータ・ファイルの一貫性のある追加、修正、および削除を実現する形でデータへのアクセスを提供する、ソフトウェア・コンポーネント。この用語は、ディスク（または他の媒体）の特定の組に含まれるデータおよびメタデータの組を記述するのにも使用される。本発明は、通常は、最も頻繁に、回転式磁気ディスク記憶システムと共に使用されるが、また、隣接するブロックに配置されたデータと共に名前によってアクセスできるいかなるデータ記憶媒体と共にでも使用可能であり、したがって、用語「ディスク」または「ディスク・ストレージ」等が本明細書で使用される場合に、記憶媒体のこのより一般的な特性が意図されている。

スナップショット： ある所定の時点でのファイル・システムの状態を取り込んだファイルまたはファイルの組。

メタデータ・コントローラ： あるファイルへのすべてのアクセス要求がそれを介して処理される、ネットワーク化されたコンピュータ・システム内のノードまたはプロセッサ（本発明の譲受人が提供するスケーラブル並列システムのｐＳｅｒｉｅｓなど）。この用語は、完全を期して提供されるが、本発明の動作の理解には関連しない。
米国特許第６０３２２１６号 米国特許出願第ＵＳ２００２／０１２４０１３号 米国特許出願第ＵＳ２００２／０１４３７３４号 米国仮特許出願第６０／２１４１２７号 米国特許出願第ＵＳ２００２／０１２３９９７号 米国特許出願（弁理士整理番号ＰＯＵ９２００３０００６ＵＳ１）

本発明の１つの目的は、大ファイル・システムをバックアップする方法を提供することである。

本発明のもう１つの目的は、ストレージ・エリア・ネットワーク（ＳＡＮ）内のデータのバックアップの性能を強化することである。

本発明の更なる目的は、バックアップ処理を、複数のデータ処理ノードで並列に実行されるように区分化することができる機構を提供することである。

本発明のもう１つの目的は、ｉノード番号による参照ではなく、より人間に可読なファイル名によってファイル指定をすることに、より従ったファイル・バックアップ・システムを提供することである。

本発明の更にもう１つの目的は、フル・モードおよび増分モードの両方のファイル・バックアップ手順の操作を機能拡張することである。

本発明の更なる目的は、単一のデータ・シンクまたは複数のデータ・シンクにファイルをバックアップする機構を提供することである。

本発明のまた更なる目的は、ファイル削除ポリシー、特に長期削除ポリシーとの一貫性があるファイル・バックアップ手順を提供することである。

本発明の１つの目的はまた、ファイル・バックアップ手順の通常のシリアルな性質を回避することである。

本発明のまたもう１つの目的は、どのファイルをバックアップすべきかをすばやく判定し、ファイル名によってバックアップを実行し、したがって、ファイル名によって個々のファイルを選択的に復元する能力を保つことである。

本発明の更にもう１つの目的は、ジャーナリングに基づくファイル・バックアップ手順を回避することである。

本発明の１つの目的はまた、特に大規模分散データ処理システムでのファイル・システム・バックアップに必要な時間を大幅に減らすことである。

最後に、これに制限はされないが、本発明の目的は、多数のファイルを有するファイル・システムで、たとえば、ファイルの数が数億である時に、バックアップ目的で、変更されたファイルをすばやく識別できるようにすることである。

本発明のさまざまな実施形態によって満足される望ましい目的のリストの本明細書での詳述は、これらの目的のいずれかまたはすべてが、個々にせよまたは集合的にせよ、本発明の最も一般的な実施形態またはそのより詳細な実施形態のいずれかにおいて本質的特徴として存在していることを暗示または提案するよう意図されたものではない。

本発明の好ましい実施形態によれば、ファイル・システムをバックアップする方法には、指定された時刻以降に変更されたｉノードの、ｉノード番号順のリストを生成するステップが含まれる。このリストには、ｉノード番号と、ファイルのサイズや最後のファイル修正の時刻（日付も含む）などの、ある種のファイル属性が含まれる。現在ファイル・システム内にあるすべてのファイルの名前とｉノード番号／世代番号とを有するテーブルも、生成される。このリストは、ｉノード番号によってソートされる。リストおよびテーブルが、ｉノード番号によってマージ（結合）される。その後、マージされたリストおよびテーブルの内容をどのファイルがバックアップされなければならないかを判定するために利用することによって、ファイルがバックアップされる。マージされた構成要素に現れる順序でファイルをバックアップすることができるが、この特定の順序によって決定されるものではない。本明細書で使用される用語「リスト」および「テーブル」は、本質的に同一の線形構造を含むことが意図され、「第１リスト」および「第２リスト」などのわかりにくい表記の参照を避けるために別々の用語が使用される。

本発明の好ましい実施形態では、ｉノード番号には世代番号も含まれる。世代番号を使用することによって、ファイルの削除の後に同一のｉノードを使用できるようになる。古いファイルは「ｉノードＸ、世代Ｎ」であり、新しいファイルは、「ｉノードＸ、世代Ｎ＋１」である。もう１つの態様では、マージされたリストおよびテーブルが、シャドウ名前空間ファイルと称するそれ自体のファイルに保管される。本発明では、比較的大きいブロックでのアクセスに、シャドウ名前空間ファイルの存在および構造も利用される。この形で、ブロックを区分し、システム内のさまざまな処理ノードに供給することができ、したがって、これにより、少なくとも２つの独立のプロセッサによって並列に実行される複数のバックアップ操作がもたらされる。この形でのバックアップ操作の区分は、バックアップされるシャドウ名前空間ファイルからのファイルの単純な線形分割に制限されない。区分は、区分内で示されるファイルのファイル・バックアップの完了の推定時間といった、だがこれに制限はされない、さまざまなファイル・パラメータに基づくものと容易にすることができる。

図１に、ファイル・システムの原理的要素を示す。図示されたような通常のファイル・システムには、ディレクトリ・ツリー１００、ｉノード・ファイル２００、およびデータ３００が含まれる。この３つの要素は、通常は、ファイル・システム内でファイル自体として存在する。たとえば、図１からわかるように、ｉノード・ファイル２００には個々のレコードまたはエントリー２２０の集合が含まれる。ファイル・システムごとに１つだけｉノード・ファイルがある。具体的に言うと、ｉノード・ファイルは、図１の最下部に示されたものであり、参照符号２００によって示される。ディレクトリ・ツリー１００内のエントリーにはフィールド１１２などのポインタが含まれ、このフィールドにはｉノード・ファイル２００への単純なインデックスとして動作する整数の量が含まれることが望ましい。たとえば、フィールド１１２にたとえば「１０８７６」を表す２進整数が含まれる場合に、これによってｉノード・ファイル２００の１０８７６番目のエントリーが参照される。特殊なエントリーを使用して（下で説明する参照符号２１６を参照されたい）、ファイルをディレクトリであるとして示すことができる。このように、ディレクトリとは、通常は、保管されたファイルの名前が任意の深さのディレクトリ・ツリー内に維持されているファイルである。ディレクトリ１００に関して、本発明のよりよい理解のために意味が理解されなければならない３つの用語がある。「ディレクトリ・ツリー」とは、ファイル・システムのすべてのディレクトリを含むディレクトリの集合である。「ディレクトリ」とは、ディレクトリ・ツリーの要素である特定のタイプのファイルである。ディレクトリは、ディレクトリ・ツリー内の下位の位置を占めるファイルまたはディレクトリのいずれか、であるｉノードへのポインタの集合である。「ディレクトリ・エントリー」とは、ファイルまたはディレクトリを指すディレクトリ内の単一のレコードである。図１では、模範的なディレクトリ・ツリーが機能ブロック１００内に示されている。模範的なディレクトリ・エントリーには、図示のように、書式１２０の要素が含まれるが、本発明の目的のためのディレクトリ・エントリー内容の例示については図３も参照されたい。図１には（便宜的目的のため）２レベルだけの階層が示されているが、ディレクトリの階層ツリー構造の深さは２レベルに制限されないことを理解されたい。実際、どのディレクトリ・ツリーにも数十個のレベルが存在する可能性がある。にもかかわらず、このディレクトリ・ツリーの深さは、１つのファイルだけが識別されるかアクセスされる必要がある場合における複数ディレクトリ参照の必要性に寄与している。しかし、どの場合でも、ディレクトリ・ツリーの「葉」が、ファイル名（参照符号１１１）をｉノード・ファイル２００内のエントリー２２０に関連付けるのに使用される。参照は、ｉノード・ファイル２００へのポインタを提供する「ｉノード番号」（参照符号１１２）による。本明細書で考慮されるタイプのファイル・システムには１つのｉノード配列がある。本発明の好ましい実施形態では、このｉノード配列はｉノード・ファイル２００であり、インデックスによって、配列要素がポイントされる。したがって、ｉノード＃１０８７６は、ｉノード・ファイル２００の１０８７６番目の配列要素である。通常、このポインタは、ｉノード・ファイル２００への単純なインデックスであり、したがって、本質的に線形の形でアクセスされ、そうであることが好ましい。したがって、インデックスが１０８７６である場合に、これは、ｉノード・ファイル２００の１０８７６番目のレコードまたは配列要素をポイントする。名前エントリー１１１を用いると、ツリーの１つ深いレベルに移動することができる。通常のファイル・システムでは、名前エントリー１１１によって、たとえばディレクトリまたはデータ・ファイルであるｉノード＃１０８７６がポイントされる。これがディレクトリである場合には、名前の次のレベルに関して、そのディレクトリ・ファイル内を再帰的に検索する。たとえば、エントリー１１１が、図１に示されているように「ａ」であると仮定する。この場合に、「ａ２」のｉノードに関する名前エントリーが、ｉノード＃１０８７６のデータから検索される。名前エントリー１１１によってデータがポイントされる場合には、名前検索の終りに達している。本発明では、名前エントリー１１１に追加フィールド１１３（図３参照）が含まれ、これによって、ディレクトリであるか否かが示される。ディレクトリ・ツリー構造は、別々に含まれる。というのは、ＰＯＳＩＸによって、本発明の理解または動作のいずれにも関連しない形で同一のファイルの複数の名前が可能になるからである。

ｉノード番号による参照ではなく、ファイル名による個々のファイル・エントリーへの参照が可能になるという点で、ディレクトリ・ツリー１００は、当該ファイル・システムのために階層的名前空間を提供する。ディレクトリの各エントリーはｉノードを指す。そのｉノードは、ディレクトリの場合もあり、ファイルの場合もある。ｉノード２２０は、ｉノード・ファイル２００内の位置のインジケータ（指標）であることが望ましいフィールド１１２内のエントリーによって決定される。ｉノード・ファイル２００内のｉノード・ファイル・エントリー２２０は、通常は線形リストとして実施され、そうであることが望ましい。このリストの各エントリーに複数のフィールド、即ちｉノード番号２１２、世代番号２１３、個々のファイル属性２１４、データ・ポインタ２１５、最終修正日付２１６、およびファイルがディレクトリであるか否かを示すインジケータ・フィールド２１７が含まれる。本発明と関係または関連性のない他のフィールドも、通常はｉノード・エントリー２２０内に存在する。しかし、本出願と共に使用するのに最も関連するフィールドは、最終修正日付を示すフィールド２１６である。ｉノード番号は、ファイル・システム内で固有である。ファイル・システムには、もはや存在しないが存在した時に同一のｉノード番号を有していたあるファイルからあるファイルを区別するのに普通使用される、世代番号２１３が含まれることもまた望ましい。ｉノード・フィールド２１４によって、あるファイルに関連するある種の属性が識別される。これらの属性には、最終修正日付、作成日付、ファイル・サイズ、ファイル・タイプ、読取アクセスまたは書込アクセスを示すパラメータ、さまざまなアクセス許可およびアクセス・レベル、圧縮状況、暗号化状況、隠し状況、およびネットワーク内での状況が含まれるが、これらに限定はされない。ｉノード・エントリー２２０には、それがポイントするファイルが実際にディレクトリであるかどうかを示すエントリー２１７も含まれる。これによって、ファイル・システム自身のための名前空間として最もよく記述されるものをこのファイルが含んでいるという事実に従って、ファイル・システム自体がこのファイルを異なる形で扱うことが可能になる。しかし、最も重要なことは、普通のｉノード・エントリー２２０に、ファイル・システムのデータ部分３００に常駐する実際のデータ３１０の物理的な位置を識別するのに十分な情報を含むデータ・ポインタ２１５が含まれるということである。

本発明では、複数の機能の組合せを使用して、上で説明したものなどの現在使用されている技術よりかなり高速なバックアップ機能性を提供する。具体的には、本発明によって、下記の機能が提供される。

（１）個々のｉノードではなくブロックによってｉノード・ファイルをすばやく読み取る機能。これによって、ディスク・ストレージをより効率的に使用でき、複数のディスクにまたがるｉノード・エントリーの読取りのオーバーラップも可能になる。たとえば、４０ミリ秒で５１２個のｉノード・エントリーのブロックを読み取ることが可能であり、これを１００台のディスクにまたがって並列に行って、１億個のｉノード・エントリーがある場合に、１３３時間ではなく、約８０秒の要件がもたらされる。公開された特許出願である２００２年９月５日公開の米国特許出願第ＵＳ２００２／０１２４０１３号（２００１年６月２５日出願の出願番号第０９／８８７５３３号、弁理士整理番号ＩＬ９２０００００６７ＵＳ２）および２００２年１０月３日公開の米国特許出願第ＵＳ ２００２／０１４３７３４号（２００１年６月２５日出願の米国特許出願第０９／８８７５２０号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ３であり、０９／８８７５３３の分割出願である；この両方が、米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ１、２０００年６月２６日出願に基づいて出願された）、および２００２年９月５日公開の米国特許出願第ＵＳ ２００２／０１２３９９７号（出願番号第０９／８８７５５０号、弁理士整理番号ＩＬ９２０００００６８ＵＳ２、２００１年６月２５日出願であり、米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６８ＵＳ１、２０００年６月２６日出願のものに基づく）に、並列システムから階層ストレージ・マネージャにイベントを提示する能力を提供するツールが記載されている。そのようなツールは、ストレージ・マネージャに供給される複数の返されたイベントを処理するのに有用である。上で参照した特許出願は、本発明と同時に出願された関連特許、米国特許出願（弁理士整理番号ＰＯＵ９２００３０００７ＵＳ１）により関連するが、完全を期してここに掲載した。

（２）ファイル・システムの名前空間をすばやく読み取り、効果的に前空間のシャドウ・コピーであるものをすばやく作成する能力。本発明には、タイプを判定するためにｉノードを読み取ることを必要とせずに、各ディレクトリ・エントリー内で名前付けされるオブジェクトのタイプを指定する能力も含まれる。これによって、ディレクトリ・エントリーを読み取ることだけによって名前空間を生成できるようになる。

（３）ディレクトリ・エントリーをｉノード番号によって順序付けることでｉノード番号からファイル名へのすばやい変換が可能になるようにするための、ディレクトリ・エントリーをソートする能力。これによって、ファイル・システム名前空間の前のコピー（シャドウ名前空間ファイル）を現在のコピーと比較して、好都合な形で、名前を変更されたファイルおよび削除されたファイルを検出できるようにもなる。

（４）作業負荷を分割してバックアップ対象に関するほぼ等しいストレスをもたらす能力。これによって、ファイルのサイズに従って作業負荷を分割できるようになり、ファイルの数に従って分割することも可能になり、更に、１つまたは複数のバックアップ対象への実際のデータ移動を行う「ワーカー（作業者）」スレッドのスケジューリングが可能になる。

（５）ファイル名空間の同一の部分から同一のバックアップ対象への毎回のデータのバックアップをする能力、またはバックアップ作業負荷をよりよく平衡化するために他のバックアップ対象へそれを移植する能力。

本明細書では、データのバックアップ・コピーを受け入れ、保管するバックアップ機構があると仮定する。そのような機構のテープ管理機能およびカタログ作成機能は、明らかに、本発明の動作に重要であるが、そのような製品の多数の例が現在の市場に存在する。ＩＢＭ社のTivoli Storage Managerが、そのような製品の例である。ＩＢＭは、本発明の譲受人でもある。

多くの点でファイル・システムのＸ−ｏｐｅｎ標準規格に従うファイル・システムに似たＩＢＭ社のGeneral Parallel File System（ＧＰＦＳ）の構造の関連する諸部分を、本発明の正しい理解のための背景を提供するために、短く検討する。

ファイル・システムの開始点は、スーパーブロック（superblock）と称するファイル・システム記述子データ構造であり、これは、ファイル・システムを含むディスクの既知の固定された点に常駐する。この構造は、ファイル・システムに関するすべての働きを実行するために必要である。この構造は、本発明の理解の鍵となる２つのデータ構造の、ディスク位置へのポインタを有する。これらのデータ構造の第１のデータ構造がｉノード・ファイル２００である。ｉノード・ファイルは、ファイルの主要なプロパティを記述するデータ構造、を構成する個々のｉノードの集合である。本発明に関連して具体的に言うと、ｉノード・ファイル内のエントリーは、ファイルまたはそのプロパティが最後に変更された時を反映するタイム・スタンプを含んでおり、そのエントリーはまたファイルのサイズをも示している。ファイルのｉノードには、ファイルの名前が含まれないことに留意されたい。ファイル名は、ファイル・システムのディレクトリ構造１００に保管される。ファイル・システムのルート・ディレクトリ１００は、ファイル・システムのスーパーブロックによって対処される第２の鍵となるデータ構造である。当該ルート・ディレクトリは、名前によってファイルを発見する開始点である。当該ルート・ディレクトリは、構造的には他のディレクトリと同一であり、即ちファイルまたは別のディレクトリの名前と、当該ファイルのプロパティを含むｉノードを指すｉノード番号と、ディレクトリ・エントリーの対象がファイルまたは別のディレクトリのどちらであるかを記述する（ＧＰＦＳにおける）対象タイプ・フィールドとからなる一連のレコードが含まれる。ｒｏｏｔｄｉｒ／ｕｓｅｒｎａｍｅ／ｆｉｌｅという名前のファイルが、ｒｏｏｔｄｉｒという名前のディレクトリｕｓｅｒｎａｍｅと呼ぶディレクトリを表すｉノード、を指すｒｏｏｔｄｉｒと呼ぶディレクトリ、を検索することによって突き止められる。ｕｓｅｒｎａｍｅという名前のディレクトリに、ファイルのｉノード番号が含まれる。通常のアクセス操作では、パス内の各ディレクトリおよびそれに対応するｉノードが、データを見つけるためにアクセスされる。

本発明の長所の正しい理解のために、これらの操作の性能特性を完全に理解することが有用である。ほとんどのＵＮＩＸ（登録商用）システムまたはＵＮＩＸ（登録商用）的システムでは、ディレクトリはファイルである。したがって、ディレクトリに対する読取操作には、ディレクトリのｉノードの読取りと、適切なディレクトリ・ブロックの読取りとが含まれる。これらの操作のそれぞれは、アクセス・パターンおよび／または使用可能キャッシュ量、による必要データのキャッシュが可能でない場合には、ディスク操作を含んでいる。本発明は、ファイル・システムのサイズと、メタデータが複数のシステムに対して使用可能であるという要件とによって、必要なデータが既にキャッシュされている可能性が低いものとなる場合に関するものである。更に、ディレクトリ・スキャンは、ｉノード・ファイルへのランダム・アクセスによく似ている。これによって、将来のアクセスを予測し、プリフェッチすることが困難になる。ディレクトリをスキャンしたりｉノードを読み取ったりするのに必要なディスク操作が、性能を左右する。

バックアップに使用される２つの標準的な技法がある。この技法の一方が、「ｉノードによるバックアップ」である。この技法では、ｉノード・ファイルからｉノードをまとめて読み取り、各ｉノード・ファイル・エントリーに関連するデータをバックアップする。ファイルはｉノード番号によって識別される。これは、名前によって個々のファイルを復元する試みには、普通には行われないかなりのカスタム・プログラミングが伴うことを意味している。代替のより一般的な技法は、バックアップ判断基準（たとえば、指定された日付の後で修正されたもの）に合致するファイルを探して、ファイル・システム名前空間をスキャンすることである。名前空間を使用することによって、プログラムは名前空間全体における各ファイルを照会する。これを行う標準インターフェースは、ファイルに関するディレクトリ・エントリーとｉノードとの読取りを必要とし、この処理は別々のディスク操作を必要とする。この名前空間全体の通過は、より大きいファイル・システムについて極端に時間がかかる。

上で注記したように、本発明では、複数の処理修正を利用することにより上で説明したバックアップ方法の制限を克服する。具体的に言うと、本発明では下記の方法が使用される。

（１）本発明では、ｉノード・ファイル２００がｉノードによるバックアップとほとんど同様の方法で読み取られ、変更されたｉノードのリスト４００（図２参照）が生成される。これによって、バックアップ判断基準を満たすｉノードのリストがもたらされる。しかし、ｉノードによるバックアップとは異なり、本発明では、ｉノード番号を手掛かりとして使用するバックアップは行われない。

（２）本発明では追加ステップが使用され、この追加ステップでは、ディレクトリ名前空間１００が読み取られて、ファイル・システム内の各ファイルの名前が、それに対応するｉノード番号と共に含まれた、ファイル名のテーブル５００（図２参照）を生成する。ディレクトリを読み取る時に、本発明では、図３に示すように、ディレクトリ・エントリーにより新たに供給される対象タイプ・フィールド１１３が使用される。従来のファイル・システムでは、対象がディレクトリまたはファイルであるか否かを示すディレクトリ・エントリー内のインジケータが保持されない。その情報は、一般にｉノード・ファイル内だけに保持され、したがってｉノードの読取りが必要である。それ故、本発明の動作では、すべてのアクティブｉノードを読み取る必要なしにサブディレクトリを識別できるようにするためにフィールド１１３が提供され、このようにして本方法の主要な長所の１つがもたらされる。ディレクトリ・スキャンの結果は、ファイル・システムに現在存在するすべてのファイルについての名前とｉノード番号とを有するテーブル５００である。このスキャンは、現在のアクティブなファイル・システムかまたはファイル・システムのスナップショットかのいずれかに対して行われる。

（３）本発明では、結果として得られるシャドウ名前空間テーブル５００を、ｉノード番号によってソートする。これによって名前空間テーブル５００をｉノード・リスト４００と簡単にマージできるようになり、これによるテーブルによって、バックアップされるファイルを指すファイル名のリストが作成される。

（４）結果として得られるマージされたテーブルの構造および内容は、ファイルの数と各ファイルのサイズとに基づいてマージされたテーブルを等しい部分に分割するための、そしてその後、ファイル・システム（たとえばＧＰＦＳ）の複数のノードにまたがって並列にバックアップを実行する複数の並列バックアップ・ジョブ「ワーカー・スレッド」を呼び出すための、付加的な能力を本発明に提供する。テーブルの「等しい」部分への分割は、各ファイルに必要な時間を推定することによって行われる。時間推定は、下記の計算に基づくことが望ましい（しかし、この計算の正確な式によって決定されるものではないことに留意されたい）。
時間＝基礎時間＋（時間／バイト）＊（バイト数）
ここで、基礎時間とは、１バイトのファイルをバックアップするのに必要な推定時間であり、時間／バイトとは、追加のバイトをバックアップするのに必要な増分時間の推定値である。本発明のこの態様は、そうあることが望ましいが、任意選択的なものである。

（５）バックアップが、複数のバックアップ・リポジトリ（集積場所）にまたがって分散される場合には、各ファイルを、毎回同一のリポジトリに送ることが望ましい。ベース・バックアップで、ファイル名前空間がリポジトリごとのほぼ等しい部分に分割され、ファイルは次のベース・バックアップまでそのリポジトリに関連付けられたままになる。このマッピングが元々の名前空間テーブルに追加されることが望ましい。本発明のこの態様は、そうあることが望ましいが、また任意選択的なものでもある。区分化は、指定された基礎バックアップで任意に実行される。ｎ個のリポジトリがある場合に、シャドウ・ファイルは、上のエントリー（４）で指定されたものとほぼ同一の負荷のｎ個の部分に分割される。その後、ｍ個のワーカー・スレッドを使用してｎ個のリポジトリにデータが移動されるが、ここでｍはｎの倍数であるため、理想的には、各リポジトリが所望の時間のうちにバックアップを完了できるようになる。

（６）ファイル名からバックアップ・リポジトリへのマッピングは、バックアップ作業負荷を再平衡化できるように変更されることが望ましい。マッピングが変更される時に、ファイルの既存のバックアップ版は新しいリポジトリに移動されることが望ましいが、これは必要という訳ではない。本発明のこの態様は、そうあることが望ましいが、任意選択的なものでもある。

（７）名前空間テーブルが、次のバックアップでの使用のために保存される。現在のバックアップの名前空間を前のバックアップと比較することによって、削除されたファイルと名前を変更されたファイルとが簡単に検出され、標準バックアップ・ポリシーに従って正しいバックアップ対策が行われる。本発明のこの態様は、そうあることが望ましいが、任意選択的なものでもあり、特に本発明をその最も広い範囲で検討する時にはそうである。

上で説明した処理修正の結果は、名前によるバックアップの柔軟性を依然可能としながらも、大ファイル・システムのバックアップが高速になるということである。本発明のシステムおよび方法の長所を完全に諒解するために、具体的な例を下で検討する。これらの例のそれぞれで、５ミリ秒のディスク・シーク時間を仮定する。これは、現在のディスク・ドライブの通常のシーク時間である。

たとえば、サイズ１００，０００バイトの１千万個のファイルおよび１０，０００個のディレクトリを含む１０台のディスクを有し、前のバックアップ以降にファイルの５％だけが変更されたファイル・システムにおいて、下記の性能差が認められた。

［名前によるバックアップを使用する従来技術のバックアップ技法］
それぞれ５ミリ秒での１千万個のｉノード「読取」によって、変更されたファイルの判定に１３時間以上の時間がもたらされ、名前を得るために１００００個のディレクトリを読み取る必要がある。

［本発明を使用するバックアップ技法］
ｉノード・ファイルが、より大きい単位で読み取られる。更に、ｉノード・ファイルへのアクセスは連続的であり、前もって並列にｉノードを読み取ることができる。この例では、ｉノードが、１０台のディスクのすべてから５１２個単位で並列に読み取られる。５１２個のｉノードの読取のそれぞれが、１０元並列で、約５０ミリ秒を要する。これは、１００，０００ｉノード／秒の読取レートであり、２分以内に１千万個のｉノードを読み取ることができる。ディレクトリ読取性能は前の場合と同一である。この性能利得は、バックアップ・データを複数のリポジトリに送る複数ワーカー・スレッドを使用して並列にバックアップする能力によって、更に改善される。

ある好ましい実施形態に従って本発明を詳細に説明したが、多数の修正および変更を当業者が行うことができる。したがって、特許請求の範囲の意図するところは、本発明の真の趣旨および範囲に適合するようにそのような修正および変更のすべてをカバーすることである。

本発明によって活用されるファイル・システム構造を示すブロック図である。 データ構造記述の大きいブロックの検索を可能にするような、またバックアップ・タスクを複数の独立の動作に区分化することを可能にするような、形態にて現在使用可能なすばやく効率的なバックアップ操作、と共に用いることができる２つの追加構造体の構造を示すブロック図である。 ファイルとディレクトリ・エントリーまたはサブディレクトリ・エントリーとを区別するためにファイル・システム・ディレクトリ内で使用可能な構造を示すブロック図である。

符号の説明

１００ ディレクトリ・ツリー
１１１ ファイル名
２００ ｉノード・ファイル
２１２ ｉノード番号
２１３ 世代番号
２１４ 個々のファイル属性
２１５ データ・ポインタ
２１６ 最終修正日付
２１７ インジケータ・フィールド
２２０ レコードまたはエントリー
３００ データ
３１０ データ
４００ リスト

Claims (9)

1. データ処理システムによりファイル・システムを並列的にバックアップする方法であって、
   変更されたｉノードのリストを、ｉノード番号順で生成するステップであって、前記リストがｉノード番号を含む、ステップと、
   対象がディレクトリであるかファイルであるかを示すインジケータを保持するディレクトリ・エントリーをスキャンすることによって、現在前記ファイル・システム内にあるすべてのファイルの名前およびｉノード番号を有するテーブルを生成するステップと、
   前記テーブルをｉノード番号によってソートするステップと、
   前記リストおよび前記テーブルをｉノード番号によってマージするステップであって、これによって、関連するｉノードおよびファイル名が単一の構成要素にて提供される、ステップと、
   前記マージされたリストおよびテーブルに基づいてｉノード番号からバックアップするべきファイル名への変換を行い、該ファイル名からバックアップ・リポジトリへのマッピングを行なってファイルをバックアップするステップと
   を有する方法。
2. 前記ｉノード番号が世代番号をも含む、請求項１に記載の方法。
3. 前記マージされたリストおよびテーブルを、シャドウ名前空間ファイルに保管するステップを更に有する、請求項１に記載の方法。
4. 前記シャドウ名前空間ファイルにブロック単位でアクセスするステップを更に有する、請求項３に記載の方法。
5. 前記ブロックが区分化され、また、前記バックアップするステップが、少なくとも２つの独立のプロセッサによって、その各々のプロセッサが前記区分内で示されるファイルをバックアップすることで実行される、請求項４に記載の方法。
6. 前記区分化が、前記区分内で示されるファイルについてのファイル・バックアップの完了に関する推定時間に基づくものである、請求項５に記載の方法。
7. 前記バックアップが、前記マージされたリストおよびテーブル内で示されるのと同一の順序で実行される、請求項１に記載の方法。
8. ファイル・システムの並列的なバックアップのための機械実行可能なコンピュータ・プログラムであって、前記コンピュータ・プログラムが、
   （１）変更されたｉノードのリストをｉノード番号を含み、かつｉノード番号順で生成する手段と、
   （２）対象がディレクトリであるかファイルであるかを示すインジケータを保持するディレクトリ・エントリーをスキャンすることによって、現在前記ファイル・システム内にあるすべてのファイルについての名前およびｉノード番号を有するテーブルを生成する手段と、
   （３）前記テーブルをｉノード番号によってソートする手段と、
   （４）前記リストおよび前記テーブルをｉノード番号によってマージして、関連するｉノードおよびファイル名を単一の構成要素にて提供する手段と、
   （５）前記マージされたリストおよびテーブルに基づいてｉノード番号からバックアップするべきファイル名への変換を行い、該ファイル名からバックアップ・リポジトリへのマッピングを行なってファイルをバックアップする手段と
   をコンピュータに実現する、コンピュータ・プログラム。
9. ファイル・システムを並列的にバックアップするデータ処理システムであって、
   中央処理装置と、
   前記中央処理装置による実行のためにデータおよびプログラムを保管するランダム・アクセス・メモリと、
   不揮発性ストレージ・デバイスと、
   前記メモリに保管された、ファイル・システムのバックアップのためのプログラム手段を実行させることによりコンピュータ上に実現される、
   （１）変更されたｉノードのリストをｉノード番号を含み、かつｉノード番号順で生成する手段と、
   （２）対象がディレクトリであるかファイルであるかを示すインジケータを保持するディレクトリ・エントリーをスキャンすることによって、現在前記ファイル・システム内にあるすべてのファイルについての名前およびｉノード番号を有するテーブルを生成する手段と、
   （３）前記テーブルをｉノード番号によってソートする手段と、
   （４）前記リストおよび前記テーブルをｉノード番号によってマージして、関連するｉノードおよびファイル名を単一の構成要素にて提供する手段と、
   （５）前記マージされたリストおよびテーブルに基づいてｉノード番号からバックアップするべきファイル名への変換を行い、該ファイル名からバックアップ・リポジトリへのマッピングを行なってファイルをバックアップするプログラム手段と
   を含む、データ処理システム。

Images