JP2005538467A - バックアップデータおよび障害回復データのデータ健全性を管理するための方法および装置 - Google Patents

Abstract

本発明は、システムもしくはネットワークの不具合に関連する損失あるいはデータセンタの物理的損失からデータを防護する統合記憶システムを得るため、ファイルバックアップ５６および遠隔複写７６の機能を統合するコンピュータ一次データ記憶システム４６に関する。本発明の１つの実施例はファイルの健全性を管理する方法を提供するものである。この方法は、第１に、第１のチェックサムを得るため第１のレポジトリノード内のファイルのコンテントチェックサムを行い、第１のチェックサムを第１のレポジトリノードに保存するステップを含む。第２に、この方法では第２のチェックサムを得るためファイル上のコンテントチェックサムを再度行い、第２のチェックサムを第１のチェックサムと比較する。

Description

（発明の背景）
本発明は、システム、もしくはネットワークの不具合に関連する損失、あるいはデータセンタの物理的損失からデータを防護する統合記憶システムを得るため、ファイルバックアップおよび遠隔複写の機能を統合するコンピュータ一次データ記憶システムに関する。

従来の一次ディスク記憶システムは、Ｉ／Ｏチャネルまたは独立ディスク冗長アレイ（ＲＡＩＤ）制御装置に装着されたディスクドライブで構成される。これらのシステムではクライアント／サーバからの要求の取り扱いを調整しＲＡＩＤデータ防護を行うためにマイクロプロセッサを用いることが多いが、従来の防護システムや磁気テープベースのバックアップのようなソフトウェアの機能を含むようには設計されていない。ＲＡＩＤデータ防護システムはセクタ／ブロックレベルでデータを管理するのみであり、どの収集やブロックのどのオーダーがファイルを含むかについての情報をもっていないため、データのファイルレベルでの健全性確認は実行できない。

これまでのところ、磁気ディスクデータ防護の最も一般的な形態はデータを磁気テープに定期的にバックアップするものである。磁気テープベースデータ防護スキームに関連しては多くの課題がある：
・磁気ディスクドライブが過去１７年間にわたって行ったのと同様のギガワット当り費用削減を磁気テープは維持できなかった。１９８５年において磁気テープ記憶は磁気ディスクよりも約３５倍安いため、バックアップ記憶媒体として費用効果のよい選択肢になった。２００２年において磁気ディスクドライブは磁気テープに比べて約２倍の費用しかかからなくなった。こういった傾向は将来的にも続くと予測され、磁気ディスクと比較して磁気テープ上でデータを保存する方は費用がかかるようになる可能性がある。

・磁気テープは歴史的に見て信頼性が低く、テープからの読み出しの点で顧客からの信用が低くなっている。データの信頼性が低い点でデータ読み出しがうまくいかない例の報告は多数ある。例えば、２００３年１月２９日発行のコンピューターワールド誌では、ニューヨークにある大手金融サービス会社のネットワーク管理者の以下のような発言を紹介している：「当社のバックアップの８５％には、回復されたデータがまったく利用できない、もしくは不完全になるような大きなエラーが含まれている。」
・テープに保存されたデータの回復性能が悪い理由の１つは、テープドライブヘッドと媒体そのものの間の機構が磨耗することに関係している。テープ媒体がテープドライブヘッドに接触すると、媒体とドライブヘッドの両方が摩擦を受けて磨耗する。単テープを用いた場合でも、記録時のテープドライブヘッドや磁気テープの状態に応じて記録の品質は変わる。

・テープ媒体の品質は時間とともに低下するため、記録管理者はテープを定期的にリフレッシュしなければならない。これには古いテープからのデータを新規テープにコピーすることが含まれる。これは非常に時間のかかるプロセスであって、コピーを完了するのに各テープで数時間かかる。この理由により、このプロセスが行われることはあまりない。

・磁気テープやテープドライブ技術の共存性が成り立たない場合も多い。１つのベンダーからの製品ライン内であっても、ベンダーの最新テープドライブで読み込めないような古いバージョンのテープもある。一旦技術が顧客から選択され長年にわたって用いられると、その顧客が別のテープ技術に変更することは難しい。典型的には、テープの大レポジトリは新たなテープ技術に移行する必要があるか、もしくは顧客の管理者が典型的には複数の非共存性テープドライブ技術を維持しなければならない。

・磁気テープに対するアーカイブ環境要求事項は磁気ディスクよりも拘束性が高い。オフサイトの保存施設への媒体移送中に起こるテープの環境変化が起こる場合、それ以前から媒体上のデータの信頼性および読み出し性は低下する。以下の表は磁気テープおよび磁気ディスク技術に対する相対環境制限値を示す。

・現在の磁気テープおよび光ディスクソリューションを用いて取り出し可能媒体の管理を行うには大きな管理上の努力が必要である。管理者は典型的にはオンラインジュークボックスからオフライン棚まで、さらに場合によってはオフサイトの記憶場所までこういった媒体を手動で動かす必要がある。オフサイト場所までの搬送中テープが受ける大きな環境変動や、関連する衝撃、テープ媒体の取り扱いや搬送に関連する振動があいまってテープベースデータの信頼性や利用可能性を低下させる。

・磁気テープを用いてコンピュータシステムの不具合、あるいは全サイトの喪失からデータを回復させなければならない場合、回復プロセスの完了には数日、あるいは数週間かかる場合もある。記録管理者はバックアップカタログをレビューし、ローカルの、あるいはオフサイトの記憶設備からテープ組を回復し、サーバ、テープライブラリユニット、バックアップソフトウェアを用いてテープベース回復インフラストラクチャを再構築する。次に、記憶管理者は必要なテープ全てをリロードし、必要に応じて、全てのデータをうまく回復させることを拒むテープ媒体やテープドライブに対応する。

・バックアップソフトウェアを利用することで、データの複製が過度になるためテープ媒体費用がかなり大きくなる。毎週、多くの会社ではフルバックアップを行い、これらのフルバックアップデータ組を数年にわたって維持している。典型的には、各フルバックアップテープ組には最終フルバックアップの８０％を超える同内容が含まれる。そのため、１年経つと顧客は複製データが大部分の５０本を越えるテープ組をもつことになる。

・大量のテープアーカイブからテープを消去してリサイクルするのは困難である。保存の必要な重要内容が、もう維持しておく必要のない内容とともに同一のテープ上にあることになる。この理由から、テープアーカイブは合理的な管理制御を超えて拡大する。

・各テープをテープドライブにおくことなく、また最初から最後までそのテープを読み出すことなくアーカイブ内の特定の磁気テープ上のデータ品質を確認することは不可能である。１本のテープの走査を完了するだけで数時間かかる場合もある。これは時間のかかるプロセスであり、データが破損していることがわかった場合でも、破損データを既知の良好データと置き換える典型的な方法はない。

ディスクベースデータ防護システムがある限り、ユーザのニーズが変わるのに応じてバックアップ戦略を効果的に調整でき、バックアップされるデータの健全性を確認するような包括的な費用効果の高いデータバックアップシステムに対する必要性は残る。

（発明の概要）
本発明は、システムもしくはネットワークの不具合に関連する損失あるいはデータセンタの物理的損失からデータを防護する統合記憶システムを得るため、ファイルバックアップおよび遠隔複写の機能を統合するコンピュータ一次データ記憶システムに関する。

本発明の１つの実施例はファイルの健全性を管理する方法を提供するものである。この方法は、第１に、第１のチェックサムを得るため第１のレポジトリノード内のファイルのコンテントチェックサムを行い、第１のチェックサムを第１のレポジトリノードに保存するステップを含む。第２に、この方法では第２のチェックサムを得るためファイル上のコンテントチェックサムを再度行い、第２のチェックサムを第１のチェックサムと比較する。第２のチェックサムが第１のチェックサムと等しくない場合、複製をもつノードにおいて、複製を確認する。複製が確認された場合、この方法では確認された複製を第１のレポジトリノードに送信し、ファイルを確認済み複製と置き換える。複製が確認されない場合、この方法では複製をもつ他の全てのレポジトリノードが確認されたかどうかを判定する。確認されない場合、確認されなかった他の複製をもつノードを選択し、他の複製を確認する。

他の複製が確認された場合、この方法では確認された他の複製を第１のレポジトリノードに送信し、ファイルを確認済みの他の複製と置き換える。複製をもつ他の全てのレポジトリノードが確認され、確認されない複製が見つからない場合、ファイル健全性修正が失敗したと判定する。

（図面の詳細な説明）
図１は統合一次データ記憶・データ防護システムの発明を示す図である。ファイルサーバ４は、ＮＦＳやＣＩＦＳ、ＦＴＰといった標準的なネットワーク付属記憶装置（ＮＡＳ）プロトコルを通してクライアントシステム５に一次データ記憶容量をもたらす。この装置は２つ以上のデータセンタ１間で作動するよう設計される。それらの関連するファイルサーバ一次記憶システムに対する完全なデータ防護を行うため、これらのデータセンタにわたって配置される２個以上のレポジトリ３により記憶容量とデータ管理処理容量がもたらされる。この装置では、レポジトリが複製のためにデータの送受信を行うため、メトロポリタンあるいはワイドエリアインターネットプロトコル（ＩＰ）ネットワーキング２を活用する。発信ファイルサーバからローカルの、さらに少なくとも１つのリモートレポジトリにデータを複製することで、これらのレポジトリは従来のオンサイト・オフサイトテープ記憶システムおよびテープボールトサービスの代替になる。サイト障害の場合、喪失した全ファイルサーバは存続サイトに新規ファイルサーバを配置し存続レポジトリの内容から破損ファイルサーバの内容を再構築することで回復される。

図２は、データセンタ間で配置されたファイルサーバ６と２つのレポジトリ間の関係を示す図である。全ての一次データ記憶作業は、ＮＡＳ共有７を通して１つ以上のクライアントと１つ以上のファイルサーバ間で行われる。ファイルサーバは典型的に数十個の共有をもつよう構成される。こういった共有によりファイルサーバの一次記憶容量が共有され、複数のクライアントシステム間で確実に分割される。

記憶容量のディレクトリもしくはフォルダとしてファイルサーバ上で共有が構築される。この共有されたディレクトリもしくはフォルダの内容に対しては、ローカルエリアネットワークにわたって複数クライアントでアクセス可能である。例えば、マイクロソフトウィンドウズ（登録商標）環境では、ＣＩＦＳ共有は、ウィンドウズ（登録商標）エクスプローラユーザインターフェイスの『マイネットワークプレース』の下でＬＡＮ接続サーバ内の保存フォルダとして現れる。ＵＮＩＸ（登録商標）環境下では、実サーバと、データが保存されるフォルダ、さらにローカルクライアントシステムファイルシステムの一部になる仮想フォルダを規定するマウントポイントを通してアクセスされる。

この装置は一次データ記憶装置であるとともにデータ防護システムであることから、記録管理者は、この共有に対して唯一の防護ポリシー９を作成することを通して２つ以上のレポジトリにわたってどのようにファイルサーバの各共有が防護されるかを規定する。１つの実施例において、この防護ポリシーでは、各共有データを防護するため、どのレポジトリをシステムが用いるかを規定する。１つの実施例において、さらにどの程度の頻度でデータ防護が行われるか、共有データの重要度に応じて各レポジトリ内でどの程度の数の複製が維持されるか、共有データに対するアップデートと改変をどのように維持するかを規定する。周期ベースで、各ファイルサーバは共有に対する防護ポリシーを調べ、必要に応じてファイルサーバが共有ファイルに対する最近の変更全てをつかみ、２つ以上のレポジトリ内でこれらのファイルを保存／防護する。

図３は、メトロポリタンまたはワイドエリアネットワーキング１１経由でお互いに遠隔接続される３つのレポジトリ１０を示す図である。各レポジトリには２つ以上のレポジトリノード１２がある。各レポジトリノードは、ファイル全てに関する健全性確認を行い、ファイルをデルタもしくはファイル圧縮し、各ファイルに対するバージョンチェインを維持し、ファイルを圧密する処理能力をもつ。

圧密によりバージョンの古さに基づくファイルバージョンを除去する手段をもたらす。例えば、ファイル共有に対する圧密オプションは、１年後の月バージョンのファイル、６ヵ月より古い週バージョンのファイル、１ヵ月より古い日バージョンのファイルのみを維持するよう構成される。全ての『余分な』バージョンはレポジトリノードから自動的にパージできるが、次にこれが新規バージョンファイルに対するさらに大きな記憶容量を作製する。

健全性確認で失敗したファイル、あるいはレポジトリノードのディスクドライブ、レポジトリノード、あるいは全レポジトリが失敗したことから現在利用できないたファイルを複製、または再複製するため、各レポジトリノードが他のレポジトリノードと相互作用する。

図４は、本発明の防護ポリシー（ＰＲＯＴＥＣＴＩＯＮ ＰＯＬＩＣＹ）の１つの実施例のスクリーンショットである。各ファイルサーバの各共有に対して規定される単一の防護ポリシーがある。防護ポリシースクリーンに到達する前に記録管理者が共有を作製し、共有に対してＣＩＦＳおよび／またはＮＦＳおよび／またはＦＴＰでアクセス可能にさせる。新たな共有が作製されると、防護ポリシースクリーンが配置される。このスクリーン内では、記録管理者は以下のデータ防護パラメータを特定できる：
・この共有１３を防護する−このチェックボックスは、この共有のデータがレポジトリで防護されることを示すよう通常チェックが入れられる。一次記憶装置に対するファイルサーバを用いるため選定され、さらに第三者のバックアップもしくはアーカイブ生成物を用いてデータ防護を継続するクライアントアプリケーションが複数ある。このチェックボックスがチェックされないまま残されている場合、防護ポリシーユーザインターフェイスの他の全てのオプションは無効にされる。

・防護管理（ＰＲＯＴＥＣＴＩＯＮ ＭＡＮＡＧＥＭＥＮＴ）−バックアップ頻度（ＢＡＣＫＵＰ ＦＲＥＱＵＥＮＣＹ）１４−このオプションではファイルサーバ共有データがローカルおよびリモートレポジトリ内でどの程度の頻度で防護されるかを決める。１つの実施例において、バックアップ頻度間隔は、１５分、３０分、１時間、２時間、３時間、４時間、６時間、８時間、１２時間、２４時間を含む時間間隔リストから選択できる。全バックアップ頻度間隔は、各ファイルサーバの現地時間帯域の深夜１２：００に固定される。バックアップ頻度を２４時間にセットするのは従来の日差分バックアップを行うものと同様である。この間隔を１５分にセットすることで、１日で頻繁に変わるファイルバージョンが１５分間隔で防護できるようになる。最終のバックアップを行った後に変更されたファイルだけがレポジトリにセーブされる。

・防護管理−レポジトリ毎の複製数。この機能により、共有が防護された場合、各レポジトリ１６内で何回データの複製（ＲＥＰＬＩＣＡＳ）１５を作製するかを記録管理者が決定できるようになる。最小限、共有ファイルサーバの位置にあるレポジトリ内に１つの複製が保存されなければならない。１つのレポジトリ内に複数の複製を維持することも可能である。この場合、１つのレポジトリノードの損傷もしくはネットワーク損傷があれば複製に対して継続的にアクセスを確保するため、レポジトリの異なるレポジトリノード上に複製が維持される。複製の位置や数は時間に応じて変更できる。重要度の増すデータに対するデータ利用度を上げるため、各レポジトリや追加レポジトリ毎の複製がさらに特定される。重要度が低下するデータに対して、レポジトリ内で維持される複製が少なくなり、これにより、記憶容量がこれらのレポジトリを同様に利用する他の共有に対してさらに利用可能になる。

・バージョン管理（ＶＥＲＳＩＯＮ ＭＡＮＡＧＥＭＥＮＴ）−バージョン履歴（ＶＥＲＳＩＯＮ ＨＩＳＴＯＲＹ）１７の維持−このチェックボックスは、ファイル内容が定期的にアップデートされる共有に対して確認されなければならない。確認されると、特定のレポジトリは、各バックアップ頻度間隔で特定される全ての変更のバージョンチェインを維持する。ファイル内容が変更されないデータの共有については、このチェックボックスはチェックされない。

・バージョン管理−バージョン圧密（ＶＥＲＳＩＯＮ ＣＯＭＰＲＥＳＳＩＯＮ）１８−３つの圧密オプションは、圧縮しない、デルタ圧縮（ＤＥＬＴＡ ＣＯＭＰＲＥＳＳＩＯＮ）を反転する、あるいは共有ファイルに対して単ファイル圧密を適用するというものである。デルタ圧密では典型的に、ファイルが定期的に改変される共有に対して最大の圧密比をもたらす。

・バージョン管理−バージョン圧縮（ＶＥＲＳＩＯＮ ＣＯＭＰＡＣＴＩＯＮ）１９−圧縮によりバージョンの古さに基づくファイルバージョンを除去する手段をもたらす。例えば、ファイル共有に対するバージョン圧縮オプションは、１年後の月バージョンのファイル、６ヵ月より古い週バージョンのファイル、１ヵ月よりも古い日バージョンのファイルのみを維持するよう構成される。全ての『余分な』バージョンはレポジトリから自動的にパージできるが、次にこれが新規バージョンファイルに対するさらに大きな記憶容量を作製する。

・アドバンスオプション（ＡＤＶＡＮＣＥ ＯＰＴＩＯＮＳ）−消去２０に対するパージ−このオプションがチェックされると、ファイルサーバの共有から消去されるファイルが同様にレポジトリからパージされるようになる。この機能は第三者バックアップのようなアプリケーションで効果があるが、アプリケーションの回復ウィンドウを満足するためレポジトリで保持されている複製やバージョンの一部が必要とされなくなり、全レポジトリからパージされる。

・アドバンスオプション−キャッシュレベル（ＣＡＣＨＩＮＧ ＬＥＶＥＬ）２１−これにより、ファイルサーバ上でキャッシュされるクライアントデータの大まかなパーセンテージを記録管理者がセットできるようになる。通常、このオプションは『読み出しのために最適化』するようセットされ、最も頻繁にアクセスされるファイルの最大数が最高性能レベルでクライアントアプリケーションにおいて利用可能になるようにする。全ての最小限最近利用されたデータは２つ以上のレポジトリで維持される。逆に、キャッシュレベルは『書き込みのために最適化』するようセットでき、これによりクライアントで利用可能なキャッシュデータ量を減らすが、書き込みアプリケーション、すなわちデータ受信に対して常に高レベルの利用可能記憶容量をもたらす。これらのアプリケーションには第三者バックアップアプリケーションを含む。このモードでは、ファイルサーバのデータを積極的にレポジトリに移動させることで、アプリケーションは、ファイルサーバを仮想的に無限の容量をもつ記憶装置とみなす。

各レポジトリノード内で作動する５つの定期データ管理ジョブがある：
１． ファイル健全性確認・修正ジョブ
２． レポジトリノードディスクドライブ回復ジョブ
３． 防護ポリシー適合ジョブ
４． バージョン回復・復元
５． 容量リバランス。

第１のデータ管理ジョブは、ファイルの確認と、破壊された各ファイルを修正することに関する。図５は、周期的なファイル健全性確認を行い、各レポジトリノードのファイルを修正するための手順を示す。１つの実施例において、ファイルがまずレポジトリノード内におかれた場合、そのファイルのＭＤ５コンテントチェックサムを含むメタファイルが作製される。さらにこのメタファイルには、そのファイルの複製をもつ他の全てのレポジトリノードの場所が含まれる。ファイルもしくはそのコンテントチェックサムのいずれかが破損した場合、このレポジトリノード、すなわち一次ノードが、複製を含む他のレポジトリノードの１つに接触する。一次ノードに位置的に近いレポジトリノード複製が優先される。破損ファイルの複製を含むレポジトリノードが最初にデータ健全性に対するそれ自体の複製を確認し、ファイルが破損していない場合、その複製は一次ノードの損傷した複製を取り替える。この取替えプロセスは、単ファイルが破損していることが検出されるたびに行われる。１つの実施例において、各レポジトリノードに対する全ファイルは少なくとも月１回確認される。

さらに詳細に、また図５を参照すると、ファイルもしくはファイルシステムの健全性を管理する方法の１つの実施例は、健全性確認の開始６０と第１のレポジトリノードに対する修正ジョブで始まる。一次ノードは、確認６１されるファイルをファイルシステム内の第１のファイルにセットする。上で述べたとおり、ファイルがまず一次ノードにおかれた場合、内容チェックサム、例えばＭＤ５チェックサムは第１のチェックサムを生成するよう決められ、第１のチェックサムは一次ノード内に保存される。健全性管理プロセス、すなわち健全性確認・修正ジョブの間、一次ノードは第２のチェックサムを実施し、第２のチェックサムを第１のチェックサムと比較６３する。

第２のチェックサムが第１のチェックサムと等しくない場合、ファイルもしくは第１のチェックサムのいずれかが破損していることを示している。これに応じて、一次ノードは、その破損ファイルの複製を維持する他のレポジトリノードを特定６４する。代用ファイルを選定するため２つ以上の他のレポジトリノードがある場合、さらに遠いところにあるレポジトリを選択する前に同一のＬＡＮ上にレポジトリ１つあればこの１つを一次ノードが選択する。複製をもつ回復ノードは複製を確認６５する。１つの実施例において、複製チェックサムを作製し複製チェックサムを第１のチェックサムと比較するため、複製をもつ回復ノードが内容チェックサムを実施する。

複製チェックサムが第１チェックサムと等しくない場合、このプロセスは他の全てのレポジトリノードが確認されたかどうかを判定６７する。確認されている場合、プロセスは健全性修正プロセスが失敗したと判定６８する。しかし、確認すべき他のノードがある場合、プロセスはステップ６４に戻る。

一方、複製チェックサムが第１のチェックサムと等しくない場合、確認済み複製をもつレポジトリノードが確認済み複製を一次ノード、あるいは要求ノードに送信６９する。一次ノードはその後、潜在的に破損したファイルを、ピアノードで供給される確認の済んだばかりの複製と置き換える７０。

潜在的に破損したファイルを確認の済んだばかりの複製と置き換えると、１つの実施例において、このプロセスでは次に、全てのファイルが確認され、必要に応じて修正されたかどうかを判定７１する。同様に、ステップ６３において、第２のチェックサムが第１のチェックサムと等しい場合、このプロセスでは次に、全てのファイルが確認され、必要に応じて修正されたかどうかを判定７１する。確認されている場合、プロセスは健全性管理プロセスが完了したと判定７２する。その他の場合、このプロセスでは、確認される次のファイルに等しい処理に対してファイルをセットし、このプロセスはステップ６２に戻る、すなわちこのプロセスは処理されているファイルに対して第２のチェックサムを実施する。

当業者であれば上述の方法に対して何らかの変更も可能であることを認めるであろう。例えば、どの複製チェックサムも第１のチェックサムと等しくない場合である。第１のチェックサムは破損し、第１のチェックサムは再計算され、第１のチェックサムが破損したことを示すものとして複製チェックサムと比較される。

各レポジトリノードにより実施される第２のデータ管理ジョブは、レポジトリノード内のディスクドライブ故障からの回復に関係する。

・レポジトリノードのディスクドライブが故障した場合、一度維持されたファイル全てについて、そのレポジトリ内の他のディスクドライブ上で再形成されなければならない。故障ディスクドライブをもつレポジトリが他の全てのレポジトリノードに接触し、ディスクドライブが故障したレポジトリの存続レポジトリノードに対する欠けたファイルの全ての回復で参加するよう要求する。全てのレポジトリは、ファイルリストを、故障ディスクドライブをもつレポジトリに送信させる。故障ディスクドライブをもつレポジトリのレポジトリノードの全ては、回復データをもつレポジトリから送信されるデータに対する潜在的目的地として作動する。うまくいく回復では、同一のレポジトリの１つ以上のレポジトリノード間で複製される故障ドライブ上にあったデータ全てをもつ。

・１つ以上のレポジトリノードが故障した場合、同一のプロセスが行われるが、さらに大きな規模になる。存続レポジトリノードは、ハードウェア故障のあるレポジトリの他のレポジトリノードの全ての喪失データを再複製するよう協働する。

各レポジトリノードにより実施される第３のデータ管理ジョブは、記録管理者の共有防護ポリシーに対して記録管理者が行う変更への反応に関連付けられる。記録管理者が防護ポリシーの１つ以上のオプションを変更する場合、各レポジトリノード内で作動する防護ポリシーコンプライアンスジョブは、パージ、複製、ポリシーを圧縮するためのデータの圧密・圧縮に対して行わなければならない。ここでポリシー変更や関連するレポジトリノードおよびレポジトリ間ノード動作の例を示すが、これは以下のものに続く：
・記録管理者が防護ポリシーのレポジトリ当り複製の防護ポリシー数を増やす場合、複製カウントを増加させるため、そのレポジトリのレポジトリノードそれぞれがそれぞれの間の内容を複製するよう協働する。逆に、複製カウントが低下する場合、選択的にファイル複製を消去することで複製数を減らすよう協働する。

・記録管理者が新規レポジトリをポリシーに追加すると、そのデータの複製をすでに保存しているレポジトリノードが、その内容を新たな場所に複製するよう新規レポジトリと関連付けられたレポジトリノードと協働する。破損データを複製しないよう、新規レポジトリに複製する前に全てのデータが確認される。

・レポジトリ内の複製数を減らすため、記録管理者が防護ポリシーを変更する場合、適当な数の複製を削除するよう、そのレポジトリのレポジトリノードが並行して作動する。

・『バージョン履歴を保持』オプションがチェックありからチェックなしに変更されると、そのバージョンチェインを維持するレポジトリノードそれぞれの初期バージョンのファイル全てが、最新バージョンを除く全てのバージョンのファイルを削除することでそのスペースを再利用する。

・データ圧縮オプションが圧縮なしからデルタ圧縮またはファイル圧縮まで変更されると、そのデータに関連する全てのバージョンや複製がそれに応じて圧縮される。逆に、デルタ圧縮オプションが圧縮有効から圧縮無効に変更されると、全ての圧縮バージョンは該当するレポジトリノードそれぞれで圧縮されない。

・圧縮が有効にされる、もしくは防護ポリシーで日、週、月圧縮オプションのいずれかに対して期間が変更されると、削除する必要のあるバージョンをもつ各レポジトリノードが要求されたファイル削除を行う一方、各ファイルのバージョンチェインの健全性を維持する。

・削除機能に対するパージが有効にされると、全ての将来的なファイルサーバの削除操作が行われ、その結果、そのファイルの複製と、レポジトリノード間のバージョンの削除が行われる。

各レポジトリノードで実施される４番目のデータ管理ジョブは、新しい、あるいは初期の１つ以上のファイルのバージョンを回復させるためファイルサーバユーザによる要求に関連付けられる。ファイルがユーザによって時間とともに修正されると、その変更がレポジトリ内で同時にバージョンチェインにリンクされる。共有に対する防護ポリシー内でデルタ圧縮オプションが選択されると、レポジトリノードが、要求されたファイルが到達するまで全てのデルタ圧縮バージョンを通してファイルの最新バージョンから逆方向に逆デルタ圧縮技術を適用する。ファイル圧縮が防護ポリシーで選択されると、レポジトリノードは、要求されているファイルを圧縮する。

各レポジトリノードで実施される第５のデータ管理ジョブは容量の再バランスに関係する。時間の経過に応じて、レポジトリノードの一部の容量は１００％の利用率に達する。これが起こると、同一のレポジトリ内でファイルのバージョンチェインを１つのレポジトリノードから他のレポジトリノードへの移動が開始される。これにより、レポジトリの容量を仮想的記憶容量の総量としてファイルサーバ共有から見ることができるようになる。

図６および図７は、ローカルのレポジトリおよびリモートのレポジトリを用いてクライアントが作製したデータファイルを防護するために用いられるモジュールの１つの実施例を図示したものである。図６は、ローカルレポジトリへのクライアントファイルの防護に関連する本発明の装置およびソフトウェアモジュールの１つの実施例を示す。この装置はファイルサーバ２７および単ローカルレポジトリノード２８を含む。クライアントはクライアントＩＰベース（インターネットプロトコル）ネットワーク２９を通してファイルサーバにアクセスし、ＮＦＳ、ＣＩＦＳ、もしくはＦＴＰプロトコルを用いてファイルサーバと通信する。全てのファイルサーバおよび全てのレポジトリノードは内部ＩＰベース（インターネットプロトコル）ネットワーク３０で相互接続される。現行のクライアントファイルはファイルサーバのファイルシステム３２に常駐する。

１つの実施例において、クライアントファイル要求で開始される入力／出力作業がファイルドライバ３１でインターセプトされる。ファイルサーバソフトウェアは最終のスナップショットが以降の全ての改訂もしくは作製されたファイルのリストを維持する。スナップショットは特定の時点におけるデータ組の複製である。スナップショット間隔は、防護ポリシーのバックアップ頻度１９に基づいて１５分から２４時間まで変わりうる。バックアップ頻度の予定について、ミラーサービス３３の１つの実施例では、共有の防護ポリシーで特定される（図３で示す）レポジトリ２１に置かれる共有で全ての改訂ファイルを作製する。防護ポリシーは複数のレポジトリにわたって保存・複製され、防護ポリシーキャッシュ３４の各ファイルサーバ内でキャッシュされ、定期的にアップデートされる。例えば、共有の防護ポリシーがそのバックアップ頻度を１時間にセットするというものである場合、次の１時間までの移行において、ミラーサービス３３がローカルレポジトリ２８に対して最後の１時間に全ての変更ファイルのバックアップを開始する。全ての新規ファイルに対して、ローカルレポジトリのレポジトリノードを用いてファイルの複製を保持することができる。改訂されたファイルに対して、ミラーサービスは、そのファイルの前のバージョンとして同一のレポジトリノードに既存ファイルの新規バージョンをあてる。ミラーサービスは位置キャッシュ３６に照会を行い、どのレポジトリノードが既存ファイルのアップデートバージョンを受信するかを判定する。ファイルサーバが特定のレポジトリノードにファイルを書き込む場合、この位置キャッシュは位置マネージャ３５で定期的にアップデートされる。位置マネージャがアップデートもしくは作製されたファイルの最新の集合体に対する共有の各ファイルに対して全ての目的レポジトリノードを特定すると、ファイルサーバは、ファイルサーバＡＰＩ３７およびレポジトリノードＡＰＩ３８を通して各ローカルレポジトリと通信する。各レポジトリノードのデータムーバ３９は、ファイルサーバからそのレポジトリノードまでのファイルの複製を管理する。ファイルサーバファイル転送モジュール４０はファイルサーバファイルシステムから各レポジトリノードのファイル転送４１モジュールまでファイルを転送する。ファイルがレポジトリノード内の特定のディスクドライブに複製されると、その位置マネージャ４２がレポジトリノード位置情報を用いて位置キャッシュ４３をアップデートする。既存ファイルの改訂バージョンであるレポジトリノードに到達する全てのファイルに対して、共有の防護ポリシー４４バージョン管理セッティングがレビューされ、新規バージョンを圧縮するかどうか、さらに古いバージョンを維持するかどうかについて判定する。バージョンサービス４５は全てのポリシーベースの圧縮・復元を管理し、共有の防護ポリシーの『１つのバージョンだけ維持』オプションに基づいてバージョンをパージする。

ここの説明では、クライアントデータはローカルレポジトリだけに複製される。図７は、クライアントデータをサイト障害から完全に防護するため、１つ以上リモートレポジトリへのデータを防護するプロセスを実施するモジュールの１つの実施例を図示する。図７はローカルレポジトリノード４６を示すが、これは図６で説明した作業からデータの最初の複製を保持する。図７もリモートレポジトリノード４７を示す。これらはメトロポリタンもしくはワイドエリアネットワーク４８に渡ってそれぞれ接続される。１つの実施例において、ローカルおよびリモートレポジトリ間で転送される全てのデータが仮想的私設ネットワーク（ＶＰＮ）４９暗号で保護される。ローカルレポジトリノードの複製サービス５０は、最新のファイルサーババックアップの一部として作成されたばかりの全てのファイルに対して防護ポリシー５１をレビューする。各レポジトリノードは他のレポジトリノードの一部として作動する。防護ポリシーに基づき、レポジトリノードＡＰＩ５２，５３、データムーバ５４、ファイル転送モジュール５５，５６を用いて各レポジトリノードが全レポジトリノード間のファイルの移動を管理する。データがリモートレポジトリに複製されると、各レポジトリノードの位置マネージャ５７が、そのレポジトリノード内にファイルが維持されるトラックに位置キャッシュ５８をアップデートする。リモートレポジトリノードのバージョンサービス５９が、防護ポリシーに従ってファイルバージョン圧縮および圧密を管理する。

図７において、健全性確認および修正を管理する２つのサービスがある。一次ノードの健全性サービス７９は、その一次レポジトリノードに対する健全性確認ジョブのスケジューリングおよび実行を行う。各レポジトリノードは健全性サービス、例えばリモートノード健全性サービス７７をもち、これら全てはそれぞれのデータを確認するため並行して動作する。健全性サービスでデータ障害問題が検出された場合、ローカル複製サービス７８を用いて、他のレポジトリノードからそれ自体への代用ファイルの移動を管理する。

したがって本発明は、従来型のテープベースデータ防護システムに置き換わる高信頼性の自己回復性の分散型磁気ディスクベースデータ記憶システムを提供することである。この分散型記憶システムの各ノードは、バックアップおよび障害回復データ管理システムを従来のやり方と関連する作業を行う能力がある。さらに、従来のテープベースデータ防護システムを用いて実施することのできないデータ管理機能を実行することも可能である。

本発明の実施例では、２つ以上のデータセンタに渡って物理的に配置される統合データ記憶・データ防護システムを提供する。各データセンタ内の装置配置には１つ以上のファイルサーバおよび１つ以上のレポジトリが含まれる。ファイルサーバは、ＮＦＳ、ＣＩＦＳ、もしくはＦＴＰプロトコルを経由してＩＰネットワーククライアントに一次ディスク記憶容量をもたらす。

各レポジトリは、変化させた、もしくは新規のファイルバージョンを定期的に保存維持することで磁気テープバックアップシステムに対する代用として作動するディスク記憶容量の仮想的プールである。さらに、１つ以上のオフサイトレポジトリへのファイルサーバに近いレポジトリ内に保存された全データを複製することでレポジトリがオフサイト媒体記憶およびオフサイト障害回復システムに対する代用として作動する。

防護ポリシーは、ファイルサーバの一次ディスク記憶システム内のクライアントデータが複数データセンタ内にあるレポジトリの集合間でどのようにして防護されるかを規定する。

各レポジトリは２つ以上のレポジトリノードで構成される。圧密、複製、バージョニング、健全性確認、修正といったさまざまなデータ管理機能をレポジトリノードは個々に実施する。

レポジトリノードは以下のレポジトリ間ノード機能を実行するようまとまって作動する：
・データが以前複製されたピアレポジトリノードから破損されないファイルを用いて、損失、あるいは破損ファイルの配置を自動化する。

・全てのノードがほぼ等価な容量負荷を仮定し、記憶容量の全般的利用率を上げることができるよう、レポジトリノードがまとめて容量再バランスを行う。レポジトリノード容量再バランスなしに、レポジトリノードの中には容量が無くなるものがある一方、他のノードでは過剰な利用可能記憶容量をもつ。

図１は、３つのデータセンタにまたがる本発明の典型的配置の概略図である。 図２は、図１で示したものと同様の、防護ポリシーと、ファイルサーバ共有と関連レポジトリ間の関係を示す概略図である。 図３は、１つの実施例による関連レポジトリノードをもつ図１に示すものと同様の３つのレポジトリの概略図である。 図４は、記憶アドミニストレータが図２の防護ポリシーを定義できるようにする防護ポリシーユーザインターフェイスの１つの実施例を示す。 図５は、図１のシステムに保存されたファイルの健全性を管理する方法の１つの実施例のフロー図である。 図６は、ローカルレポジトリノードへの新クライアントデータを防護するために用いられる装置およびソフトウェアコンポーネントの１つの実施例を示す。 図７は、レポジトリ間のデータを複製する装置の１つの実施例を示す。

Claims (12)

1. ファイルの健全性を管理するための方法であって、この方法が：
   ａ）第１に、第１のチェックサムを得るため第１のレポジトリノード内のファイルのコンテントチェックサムを行い、第１のチェックサムを第１のレポジトリノードに保存するステップと；
   ｂ）第２に、第２のチェックサムを得るためファイル上のコンテントチェックサムを再度行い、第２のチェックサムを第１のチェックサムと比較するステップと；
   ｃ）第２のチェックサムが第１のチェックサムと等しくない場合、複製をもつノードにおいて、複製を確認するステップと；
   複製が確認された場合、確認された複製を第１のレポジトリノードに送信するステップと；
   ファイルを、確認された複製と置き換えるステップと；
   複製が確認されない場合、複製をもつ他の全てのレポジトリノードが確認されたかどうかを判定するステップと；
   確認されない場合、確認されなかった他の複製をもつノードを選択し、他の複製を確認するステップと；
   他の複製が確認された場合、確認された他の複製を第１のレポジトリノードに送信するステップと；
   ファイルを確認された他の複製と置き換えるステップと；
   複製をもつ他の全てのレポジトリノードが確認され、確認されない複製が見つからない場合、ファイル健全性修正が失敗したと判定するステップとを含む方法。
2. 請求項１に記載の方法であって、ファイルが第１のファイルであり、この方法がさらに：
   ファイル、複製、他の複製の少なくとも１つが確認された場合、全ての関連ファイルに対して健全性管理がなされたことを確認するステップと；
   全ての関連ファイルに対して健全性管理がなされた場合、健全性管理が完了したと判定するステップと；
   健全性管理がなされていない場合、ファイルを再帰的に次のファイルと等しくなるよう設定し、全ての関連ファイルに対して健全性管理がなされるまで次のファイルに（ａ）〜（ｃ）を行うステップとを含むことを特徴とする方法。
3. 請求項１に記載の方法であって、複製を確認するステップが、複製チェックサムを得るため複製に対してコンテントチェックサムを行うステップと、複製チェックサムが第１のチェックサムに等しいかどうかを判定するステップとを含むことを特徴とする方法。
4. ファイルの健全性を管理するための方法であって、この方法が：
   ａ）第１に、第１のチェックサムを得るため第１のレポジトリノード内のファイルのコンテントチェックサムを行い、第１のチェックサムを第１のレポジトリノードに保存するステップと；
   ｂ）第２に、第２のチェックサムを得るためファイル上のコンテントチェックサムを再度行い、第２のチェックサムを第１のチェックサムと比較するステップステップと；
   ｃ）第２のチェックサムが第１のチェックサムと等しくない場合、他のノードからファイルを回復するステップとを含む方法。
5. 請求項４に記載の方法であって、他のノードからファイルを回復するステップが：
   ファイルの複製をもつレポジトリノードを判定するステップと；
   レポジトリノードをクエリーするステップとを含むことを特徴とする方法。
6. 請求項５に記載の方法であって、他のノードからファイルを回復するステップが、さらに：
   複製をもつノードにおいて、複製を確認するステップと；
   複製が確認された場合、確認された複製を第１のレポジトリノードに送信するステップと；
   ファイルを、確認された複製と置き換えるステップとを含むことを特徴とする方法。
7. 請求項６に記載の方法であって、複製を確認するステップが、複製チェックサムを得るため複製に対してコンテントチェックサムを行うステップと、複製チェックサムが第１のチェックサムに等しいかどうかを判定するステップとを含むことを特徴とする方法。
8. 請求項６に記載の方法であって、他のノードからファイルを回復するステップが、さらに：
   複製が確認されない場合、複製をもつ他の全てのレポジトリノードが確認されたかどうかを判定するステップと；
   確認されない場合、確認されなかった他の複製をもつノードを選択し、他の複製を確認するステップと；
   他の複製が確認された場合、確認された他の複製を第１のレポジトリノードに送信するステップと；
   ファイルを、確認された他の複製と置き換えるステップとを含むことを特徴とする方法。
9. 請求項８に記載の方法であって、この方法がさらに：
   複製をもつ他の全てのレポジトリノードが確認され、確認されない複製が見つからない場合、ファイル健全性修正が失敗したと判定するステップを含む方法。
10. 請求項８に記載の方法であって、ファイルが第１のファイルであり、この方法がさらに：
    ファイル、複製、他の複製の少なくとも１つが確認された場合、全ての関連ファイルに対して健全性管理がなされたことを確認するステップと；
    全ての関連ファイルに対して健全性管理がなされた場合、健全性管理が完了したと判定するステップと；
    健全性管理がなされていない場合、ファイルを再帰的に次のファイルと等しくなるよう設定し、全ての関連ファイルに対して健全性管理がなされるまで次のファイルに（ａ）〜（ｃ）を行うステップとを含むことを特徴とする方法。
11. 請求項４に記載の方法であって、チェックサムがＭＤ５チェックサムであることを特徴とする方法。
12. データ防護システムであって、：
    一次レポジトリノードであって：
    データ転送を管理するよう作動するデータムーバと；
    データムーバと通信しネットワークと通信するよう作動する一次レポジトリＡＰＩと；
    データムーバと通信しファイルを受信するよう作動する一次レポジトリファイル転送モジュールと；
    健全性サービス作業者と；
    第１に、第１のチェックサムを得るため第１のレポジトリノード内のファイルのコンテントチェックサムを行い、第１のチェックサムを第１のレポジトリノードに保存するステップと；
    第２に、第２のチェックサムを得るためファイル上のコンテントチェックサムを再度行い、第２のチェックサムを第１のチェックサムと比較するステップと；
    第２のチェックサムが第１のチェックサムと等しくない場合、ファイル回復要求を出力するステップと；
    データムーバおよび健全性サービスと通信する複製保持サービスであって、健全性サービスから回復要求を受信し他のノードからファイルを回復するプロセスを管理するよう作動するものとをもつ一次レポジトリノードを備えるシステム。

Images