(57)【特許請求の範囲】
【請求項１】
記憶装置に格納されたファイルをバックアップする情報処理装置であって、
前記記憶装置に格納されたファイルのメタデータを管理するメタデータ管理部と、
記憶装置上のファイルに対応する識別値に対応付けられた前記メタデータが存在するか、存在しないかを示すマップを生成するマップ生成部と、
前記メタデータをスキャンして、前回のバックアップで作成されたマップとの比較により、現在までに作成、修正、削除されたファイルを検出し、ファイルの作成または削除に対応して前記マップを更新し、少なくとも検出された前記ファイル、前記メタデータ、および更新後の前記マップを、バックアップ情報としてバックアップ記憶装置に格納する、バックアップ管理部と
を含む、情報処理装置。
【請求項２】
前記マップは、前記メタデータの存在または不存在をバイナリ値で置換したビットマップである、請求項１に記載の情報処理装置。
【請求項３】
前記バックアップ記憶装置は、リモート・ストレージ装置またはローカル・ストレージ装置である、請求項１に記載の情報処理装置。
【請求項４】
記憶装置に格納されたファイルをバックアップする情報処理システムであって、
プログラムの実行によりアプリケーションを動作させて、ファイルを作成、修正、または削除すると共にファイルをバックアップするプロセッサと、
記憶装置へのアクセスを可能とする外部記憶制御部と、
前記記憶装置に格納されたファイルのメタデータを管理するメタデータ管理部と、
記憶装置上のファイルを一意に識別する識別値に対応付けられた前記メタデータが存在するか、存在しないかを示すマップを生成するマップ生成部と、
前記メタデータをスキャンして、前回のバックアップで作成されたマップとの比較により、現在までに作成、修正、削除されたファイルを検出し、ファイルの作成または削除に対応して前記マップを更新し、少なくとも検出された前記ファイル、前記メタデータ、および更新後の前記マップを、バックアップ情報としてバックアップ記憶装置に格納する、バックアップ管理部と
を含む、情報処理システム。
【請求項５】
前記マップは、前記メタデータの存在または不存在をバイナリ値で置換したビットマップである、請求項４に記載の情報処理システム。
【請求項６】
前記外部記憶制御部は、ネットワーク・アダプタであり、前記バックアップ記憶装置は、ネットワークを介して接続されるリモート・ストレージ装置である、請求項４に記載の情報処理システム。
【請求項７】
情報処理装置がプログラムをメモリに読み込んで当該プログラムを実行することによって情報処理装置が記憶装置に格納されたファイルをバックアップする方法であって、
前記記憶装置に格納されたファイルのメタデータを生成または削除するステップと、
記憶装置上のファイルに対応する識別値に対応付けられた前記メタデータが存在するか、存在しないかを示すマップを生成するステップと、
バックアップ処理毎に前記メタデータをスキャンして、前回のバックアップで作成されたマップとの比較により、現在までに作成、修正、削除されたファイルを検出し、ファイルの作成または削除に対応して前記マップを更新し、少なくとも検出された前記ファイル、前記メタデータ、および更新後の前記マップを、バックアップ情報としてバックアップ記憶装置に格納するステップと
を含む、方法。
【請求項８】
前記マップは、前記メタデータの存在または不存在をバイナリ値で置換したビットマップである、請求項７に記載の方法。
【請求項９】
前記バックアップ記憶装置に格納するステップは、ネットワークを介してリモート・ストレージ装置またはストレージ・アダプタを介してローカル・ストレージ装置に格納するステップを含む、請求項７に記載の方法。
【請求項１０】
情報処理装置がプログラムをメモリに読み込んで当該プログラムを実行することによって情報処理装置が記憶装置に格納されたファイルをバックアップする方法を実行するための装置実行可能なプログラムであって、情報処理装置が、
前記記憶装置に格納されたファイルのメタデータを生成または削除するステップと、
記憶装置上のファイルに対応する識別値に対応付けられた前記メタデータが存在するか、存在しないかを示すマップを生成するステップと、
バックアップ処理毎に前記メタデータをスキャンして、前回のバックアップで作成されたマップとの比較により、現在までに作成、修正、削除されたファイルを検出し、ファイルの作成または削除に対応して前記マップを更新し、少なくとも検出された前記ファイル、前記メタデータ、および更新後の前記マップを、バックアップ情報としてバックアップ記憶装置に格納するステップと
を実行するためのプログラム。
【請求項１１】
前記マップは、前記メタデータの存在または不存在をバイナリ値で置換したビットマップである、請求項１０に記載のプログラム。
【請求項１２】
情報処理装置がプログラムをメモリに読み込んで当該プログラムを実行することによって情報処理装置が記憶装置に格納されたファイルをバックアップする方法であって、
前記記憶装置に格納されたファイルのメタデータを生成または削除するステップと、
記憶装置上のファイルに対応する識別値に対応付けられた前記メタデータが存在するか、存在しないかを示すマップを、前記メタデータの存在または不存在をバイナリ値で置換したビットマップとして生成するステップと、
バックアップ処理毎に前記メタデータをスキャンして、前回のバックアップで作成したマップとの比較により、現在までに作成、修正、削除されたファイルを検出してファイルの作成または削除に対応して前記マップを更新し、少なくとも検出された前記ファイル、前記メタデータ、および更新後の前記マップを、バックアップ情報としてバックアップ記憶装置に格納するステップと
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報バックアップ技術に関し、より詳細には、記憶媒体に記録された情報をバックアップする技術に関する。
【背景技術】
【０００２】
近年、コンピュータなどによる情報処理に伴い、ますますデジタル情報が増加し、またその付加価値も高まってきている。このような高付加価値の情報を災害などによる消失から防ぐため、定期的にファイル・システムのバックアップを磁気テープ、ハードディスク・ドライブといった他の記憶媒体に複製し、冗長記録することが推奨されている。バックアップ処理は、元の記憶媒体に記録された情報を他の記憶媒体に書き込むという読み出し・書き込み処理を伴うので、一定の時間を必要とする。
【０００３】
バックアップの処理負荷は、データ量が小さい場合にはそれほど負担にならない。しかしながら、数テラバイトを超える可能性の有る業務情報を定期的にバックアップすることは、定期的に発生することもあり、ファイルサイズの増大に伴い、情報処理装置に大きな処理負担をかけると共に、処理時間を浪費させるようになってきている。
【０００４】
バックアップ処理に要する時間を短くすることは、Recovery Point Objective（RPO、目標復旧地点）を短い時間間隔で設定することを可能とする。このため、より高精度にデータを復元することができ、バックアップ処理の効率化は、ますます重要な課題となってきている。バックアップを定期的に実行する場合に、バックアップを効率化し、重複無くバックアップを取得するために、多くの場合、現在の記憶装置内のファイルと、前回実行したバックアップに記録されたファイルとの間の差分データを検出し、検出された差分データだけをバックアップとして取得する。以下、この手法を差分バックアップとして参照する。
【０００５】
従来から、差分バックアップを行うための差分データ検出は、例えばinodeスキャンおよび現在と前回の２つのファイル・リストの比較を併用する方法が知られている。ここで、inodeとは、ファイルのメタデータ（サイズ、mtime、UID、データ・ブロックのアドレスなど）を格納するオブジェクトのことであり、ファイルごとに存在する。inodeスキャンとは，ファイル・システムに存在する各ファイルのメタデータを読み、最終更新時刻（mtime／ctime）が前回のバックアップ時刻よりも新しいファイルをリストする処理を意味する。
【０００６】
しかしながら、inodeスキャンでは、最終更新時刻が新しく、現実に存在するファイルしか検出できない。このため、inodeスキャンでは、削除されたファイルを検出するためにファイル・リストの比較も併用する必要がある。このため、inodeスキャンをファイルの数が数十億個にもなるような巨大なファイル・システムに適用すると、ファイル・リストのサイズが大きくなるため、ファイル・リストの生成自体の他、その比較処理に膨大な時間を要する、という課題があった。
【０００７】
従来から、バックアップ処理の効率化が検討されており、特開２００５−２９２８６５号公報（特許文献１）では、ファイルの最終更新時刻が前回のバックアップ時刻よりも新しいファイルを検出するために、スナップ・ショットを作成し、inodeスキャンを実行することが記載されている。さらに、特開２００７−１０２６９２号公報（特許文献２）では、バックアップ処理の中で、削除されたファイルの検出は行わない。代わりに、bitmapを使用してスナップ・ショットの管理を行う点が記載されている。さらに、特開２００１−２１６１８５号公報（特許文献３）では、リストア時には、まず復旧したい時点のスナップ・ショットを選択する。選択したスナップ・ショットとの差分ビットマップを使用してリストア処理を行う点を記載する。
【０００８】
この他、従来技術として認識されるIBM Scale Out Network Attached Storage (SONAS)（登録商標）などにおいて実装されるバックアップ方式について、図１０を参照しながら説明する。図１０に示す従来方式では、前回のコピー時から新規作成されたファイルや更新された差分データを検出するために、inodeスキャンを用いて、最終更新時刻が前回のバックアップ時よりも新しいファイルのファイル・リストを作成する。この際、前回のバックアップ時以降に削除されたファイルを検出するための中間ファイルとして、前回の全ファイル・リスト１００２および今回の全ファイル・リスト１００３を作成し、保存する。
【０００９】
inodeスキャンの完了後、今回の全ファイル・リストを、前回のバックアップ時に作成された全ファイル・リストと比較を行い、削除されたファイルを検出して削除ファイル・リスト１００１を作成する。具体的には、削除ファイル・リスト１００１を作成するために、図１０のように，inode番号順にソートされた２つのファイル・リスト１００２、１００３を比較する。この比較は、各ファイル１００２、１００３に登録された全ファイルについて行う必要がある。
【００１０】
図１１は、図１０の差分バックアップ方法の概略的な処理および生成される中間ファイルを対応付けて説明した図である。従来のinodeスキャンによる差分バックアップは、ステップＳ１１００から開始し、ステップＳ１１０１で、inodeスキャンによって最終更新時刻が前回のバックアップ時よりも新しいファイルの全ファイル・リストを作成する、この段階で全ファイル・リスト１１１０が生成される。
【００１１】
次いでステップＳ１１０２で、前回バックアップに関連づけられた前回の全ファイル・リストを読み出し、ステップＳ１１０３で２つの中間ファイルを比較して削除ファイル・リスト１１１１を作成する。その後、ステップＳ１１０４で作成した削除ファイル１１１１および全ファイル・リスト１１１０を、現在のバックアップに関連づけて適切な記憶領域に格納する。
【００１２】
以上説明したように、従来のinodeスキャンによる差分バックアップは、inodeスキャンにより生成される全ファイル・リスト１１１０の他、削除ファイル・リスト１１１１を生成するためのファイル比較という処理負担を要求する。さらに従来の差分バックアップ法では、全ファイル・リスト１１１０および削除ファイル・リスト１１１１という差分ファイル以外の余分な中間ファイルを格納しなければならないので、中間ファイルを格納するための記憶容量も割かなければならない。上述した中間ファイルは、バックアップ対象のデータが数テラバイト程度となり、またネットワーク・アクセスが頻繁で修正を伴うファイルが多くなるにつれ、中間ファイル自体の容量も無視できないものとなっていた。
【００１３】
これとは別に、Tivoli Storage Manager (TSM)（登録商標）において実装されるバックアップ法（General Parallel File System (GPFS)のバックアップ機能(mmbackup) （http:／／www-01.ibm.com／support／knowledgecenter／SSFKCN_4.1.0／com.ibm.cluster.gpfs.v4r1.gpfs100.doc／bl1adm_backuptuning.htm?lang=en：非特許文献１、２０１４年７月３１日付けダウンロード）では、過去にバックアップ済みの全ファイルのメタデータをデータベースに保存しておく。
【００１４】
バックアップが起動されると、データベースに保存された全ファイルのメタデータとinodeスキャンにより得られた全ファイルのメタデータと比較し、前回のバックアップ以降に更新・作成されたファイルや削除されたファイルを検出するという手法を採用する。すなわち、mmbackupは、SONASの機能と同様に、inodeスキャンに加え、前回のバックアップ時の全ファイルのメタデータとinodeスキャンにより得られた全ファイルのメタデータを比較する必要があった。このようなバックアップ方式においても差分バックアップを効率化することが要求されていた。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００５−２９２８６５号公報
【特許文献２】特開２００７−１０２６９２号公報
【特許文献３】特開２００１−２１６１８５号公報
【非特許文献】
【００１６】
【非特許文献１】http:／／www-01.ibm.com／support／knowledgecenter／SSFKCN_4.1.0／com.ibm.cluster.gpfs.v4r1.gpfs100.doc／bl1adm_backuptuning.htm?lang=en：非特許文献１、２０１４年７月３１日付けダウンロード
【発明の概要】
【発明が解決しようとする課題】
【００１７】
本発明は、上記従来技術の問題点に鑑みてなされたものであり、本発明は、より効率的な差分バックアップ技術を提供することを課題とする。
【課題を解決するための手段】
【００１８】
本発明では、バックアップを行う際に、前回のバックアップ以降に作成、修正、削除に伴うファイル構造を取得するために識別値に対応付けられたメタデータをスキャンする。当該スキャンにより、前回のバックアップ以後のファイル構造の実変化を取得する。当該スキャンにより、現在のファイル構造を、ファイルを一意に識別する識別値に関連するメタデータの存在・不存在を示すマップとして取得することができる。その後、実変化に関連して現実に存在するファイルのメタデータを抽出し、対応するファイルのデータ・ブロックと共に、識別値に対応付けてバックアップ記憶装置にバックアップ情報として格納する。さらに本発明では、バックアップ情報に現在のファイル構造を示すマップを追加して格納する。
【００１９】
バックアップ情報は、該当するバックアップの際のファイル構造のマップ、作成、修正されたファイルのデータ・ブロックおよびメタデータが識別値に対応付けて登録されたデータ構造としてバックアップ毎に時系列的に生成される。
【００２０】
データのリストア時には、目的とするリストアの時刻などで指定されるリストア・ポイントが決定される。そして、当該リストア・ポイントに対応するバップアップ情報に格納されたマップをバックアップ記憶装置から主記憶装置に読み出す。その後、当該マップを参照して、マップが存在を指示する識別値に対応するメタデータおよびデータ・ブロックを、履歴的に保存されたバックアップ情報から主記憶装置に読み込む。削除されたファイルは、マップのビット構造により直接指定される。
【００２１】
読み出したメタデータおよびデータ・ブロックは、リストア・ポイントにおけるマップに対応付けて構成され、マップで指定されるデータ構造が再構築される。
【００２２】
以上の通り、本発明では、inodeスキャンにより全ファイル・リスト、削除リストなどの中間ファイルを作成する情報処理を行うことがなく、また中間ファイルのための記憶容量を確保する必要が無くなるので、効率的なバックアップおよびリストア処理が可能となる。
【図面の簡単な説明】
【００２３】
【図１】本発明の情報処理装置１００の概略的な構成を示したブロック図である。
【図２】本実施形態の情報処理装置２０６が実装される情報処理システム２００の実施形態を示す。
【図３】本実施形態のサーバ装置２０６のバックアップ制御部３００の機能ブロック図
【図４】本実施形態でバックアップ対象となるファイルのデータ構造４００を示す。
【図５】メタデータおよびディレクトリ構造をデータ・ブロックと分離してバックアップする実施形態におけるデータ構造５００を説明した図
【図６】本実施形態のバックアップ方法のフローチャート
【図７】図６の処理で生成されるバックアップ情報７００の実施形態を示す。
【図８】本実施形態で、バックアップ情報をリストアする場合の処理のフローチャートを示す。
【図９】本実施形態のリストア処理でバックアップ記憶装置３１０から主記憶装置３０９に複製されるデータおよび情報を示す概略図
【図１０】図１０は、従来技術として認識されるIBM Scale Out Network Attached Storage (SONAS)などにおいて実装されるバックアップ方式を説明した図。
【図１１】図１１は、図１０の差分バックアップ方法の概略的な処理および生成される中間ファイルを対応付けて説明した図。
【符号の説明】
【００２４】
１００    ：情報処理装置
１０１    ：プロセッサ
１０２    ：メモリ
１０３    ：バス
１２０    ：ドライバ
１２１    ：ディスプレイ装置
１２２    ：ネットワーク・アダプタ
１２３    ：Ｉ／Ｏバス・ブリッジ
１２４    ：Ｉ／Ｏバス
１３０    ：記憶装置
１３１    ：入力装置
２００    ：情報処理システム
２０１    ：ネットワーク
２０２〜２０５    ：情報処理装置
２０６    ：サーバ装置
２０７ａ  ：持続性記憶媒体
２０７ｂ  ：持続性記憶媒体
２０８    ：携帯端末
３００    ：バックアップ装置
３０１    ：ネットワーク
３０２    ：アダプタ
３０３    ：メタデータ管理部
３０４    ：マップ生成部
３０５    ：バックアップ管理部
３０６    ：アダプタ
３０７    ：アプリケーション
３０９    ：主記憶装置
３１０    ：バックアップ記憶装置
４００    ：データ構造
４０３、５１０    ：データ・ブロック
５００    ：データ構造
５１０    ：ブロック
７００    ：バックアップ情報
７０１    ：ファイル
【発明を実施するための形態】
【００２５】
図１は、本発明の情報処理装置１００の概略的な構成を示したブロック図である。本発明の情報処理装置１００は、概ねパーソナル・コンピュータ、ワークステーション、サーバなどを用いることができる。情報処理装置１００は、プロセッサ１０１と、プロセッサ１０１の処理を可能とするＲＡＭ、ＤＲＡＭなどの固体メモリ素子から形成されるシステム・メモリ１０２とを備える。なお、本実施形態では、Ｌ１〜Ｌ３といった階層構造を有するキャッシュ・メモリを介してシステム・メモリ１０２へのアクセスを行うことができる。
【００２６】
プロセッサ１０１、システム・メモリ１０２は、システム・バス１０３を介して、情報処理装置１００の他のデバイスまたはドライバ、例えば、グラフィックス・ドライバ１２０およびネットワーク・アダプタ１２２へと接続されている。グラフィックス・ドライバ１２０は、バスを介してディスプレイ装置１２１に接続されて、プロセッサ１０１による処理結果をディスプレイ画面上に表示させている。また、ネットワーク・アダプタ１２２は、トランスポート層レベルおよび物理層レベルで情報処理装置１００をネットワークへと接続して、クライアント（図示せず）とのセッションを確立させている。
【００２７】
システム・バス１０３には、さらにＩ／Ｏバス・ブリッジ１２３が接続されている。Ｉ／Ｏバス・ブリッジ１２３の下流側には、ＰＣＩ、ＰＣＩ−ＥｘｐｒｅｓｓなどのＩ／Ｏバス１２４を介して、ＩＤＥ、ＡＴＡ、ＡＴＡＰＩ、シリアルＡＴＡ、ＳＣＳＩ、ＵＳＢなどにより、ハードディスク、ＤＡＴなどの記憶装置１３０が接続されている。また、Ｉ／Ｏバス１２４には、ＵＳＢなどのバスを介して、キーボードおよびマウスなどのポインティング・デバイスなどの入力装置１３１が接続され、システム管理者などのオペレータによる入力および指令を受付けている。
【００２８】
情報処理装置１００が使用するプロセッサとしては、より具体的には、例えば、ＰＥＮＴＩＵＭ（登録商標）シリーズ、Ｃｏｒｅ２Ｄｕｏ（登録商標）、Ｃｏｒｅ２Ｑｕａｄ（登録商標）、Ｃｏｒｅ（登録商標）ｉ３、ｉ５、ｉ７などのいわゆる８６系のシングルコアまたはマルチコアプロセッサの他、Ｘｅｏｎ（登録商標）、ＰＥＮＴＩＵＭ（登録商標）互換プロセッサ、ＰＯＷＥＲ  ＰＣ（登録商標）、ＭＩＰＳ、Ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅのプロセッサを挙げることができる。
【００２９】
使用するオペレーティング・システム（ＯＳ）としては、ＭａｃＯＳ（商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）２００Ｘ  Ｓｅｒｖｅｒ、ＵＮＩＸ（登録商標）、ＡＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）またはそれ以外の適切なＯＳを挙げることができる。さらに、情報処理装置１００は、上述したＯＳ上で動作する、Ｃ＋＋、Ｖｉｓｕａｌ  Ｃ＋＋、ＶｉｓｕａｌＢａｓｉｃ、Ｊａｖａ（登録商標）、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎなどのオブジェクト指向のプログラミング言語により記述されたアプリケーション・プログラムを格納し、実行する。
【００３０】
図２は、本実施形態のバックアップ方法が実装される情報処理システム２００の実施形態を示す。情報処理システム２００は、ネットワーク２０１を介して複数の情報処理装置２０２、２０３、２０４、２０５、２０６、２０８が接続されて、データなどの相互通信を可能としている。情報処理装置２０２、２０４は、ノートブック型パーソナル・コンピュータとされ、情報処理装置２０３、２０５は、デスクトップ・コンピュータ、ワークステーションまたはローカル・サーバとされている。この他、タブレット型コンピュータやスマートホンといった携帯端末２０８などもネットワーク２０１に接続されていて、各種の情報伝送を行う。ネットワーク２０１は、ローカルエリア・ネットワーク（ＬＡＮ）、インターネットまたはこれらのネットワークが混在して存在する複合的なネットワークとすることができる。
【００３１】
ネットワーク２０１には、サーバ装置２０６が接続されていて、ネットワーク２０１を介して接続する各種の情報処理装置からの情報を蓄積し、またデータベースなどに格納した情報を各情報処理装置へと提供する。サーバ装置２０６は、本実施形態では、クライアント−サーバ型のサービスを提供するサーバ、ウェブ・サーバ、ＦＴＰサーバ、ストレージ・サーバなどとして構成することができ、１態様としては、データ・サービスおよびアプリケーション・サービスを提供するクラウド・サーバとして実装することができる。
【００３２】
以下、本実施形態におけるバックアップ装置を、例示的な１実施形態としてサーバ装置２０６に実装するものとして説明する。サーバ装置２０６がバックアップ装置として機能する場合、サーバ装置２０６は、サーバ装置２０６が管理する各種情報、データなどを、ハードディスク装置、磁気テープドライブなどの持続性記憶媒体２０７ａ、２０７ｂに記憶し、またバックアップする。なお、サーバ装置２０６は、冗長記録の目的で、ＲＡＩＤシステムなどを搭載することもできる。本実施形態の情報処理装置は、ＲＡＩＤシステムとは独立したバックアップ方式とすることもできるし、ＲＡＩＤシステムの１プロトコルとして実装することもできる。
【００３３】
図３は、本実施形態のバックアップ装置３００の機能ブロック図である。図３の機能ブロックは、サーバ装置２０６が、プロセッサ可読なメモリにプログラムを読み込んで、プロセッサが当該プログラムをメモリ上で実行することにより、情報処理装置上に実現される。なお、本実施形態のプログラムは、オペレーティング・システム（ＯＳ）に直接管理されるモジュールとして構成することができる。図３に示すように、バックアップ装置３００は、メタデータ管理部３０３と、マップ生成部３０４とを含んでいる。
【００３４】
メタデータ管理部３０３は、特定のファイルに関し、ファイルのサイズ、最終更新時刻、ＵＩＤ、データ・ブロックのアドレスなどのメタデータを生成し、主記憶装置３０９に格納する機能部である、メタデータは、ファイル毎に一意の識別値が割り当てられた情報として作成され、ファイルが削除されると、該当するメタデータの内容は削除される、識別値は、保存される。この結果、ファイルが一旦生成されると、仮にファイルが削除されたとしても、当該識別値に割り当てられたメタデータの記憶領域はvoidとして残される。特に特定の形式に限定するものではないが、上述したメタデータは、inodeとして参照されるデータ形式とすることもできる。この他、Ｗｉｎｏｄｗｓ（登録商標）系のNTFSとして参照されるデータ形式とすることもできる。その他、ＭａｃＯＳ（登録商標）で使用されるメタデータも使用することができる。
【００３５】
マップ生成部３０４は、サーバ装置２０６が作成したファイルのメタデータに関する識別値について、対応するメタデータが存在するか、存在しないかを識別して現在主記憶装置３０９に存在するファイル構造のマップを作成する。当該マップは、所定の識別値に対応するメタデータが存在するか、存在しないかの判断を与える機能を有し、メタデータが存在する場合、バイナリ１、存在しない場合バイナリ０を割り当てたマップとして生成することができ、この実施態様の場合、ビットマップ(Bitmap)として参照することができる。
【００３６】
なお、当該マップは、アプリケーションによるファイルの作成、修正、削除に同期して主記憶装置３０９に永続的データとして登録されても良い。また、当該マップは、バックアップの処理中にオンザフライに生成され、専らリストアのための情報としてバックアップ記憶装置３１０のバックアップ情報に追加的に格納することができる。
【００３７】
さらにバックアップ装置３００は、バックアップ管理部３０５を備えている。バックアップ管理部３０５は、メタデータをスキャンして、例えばタイムスタンプを参照して前回のバックアップ処理後にアプリケーション３０７が作成、修正または削除したファイルを識別する。バックアップ管理部３０５は、検出されたファイルのメタデータおよびデータ・ブロックを、ファイルをハードウェア上で一意に識別させる識別値に対応付けてバックアップ記憶装置３１０に格納する。
【００３８】
さらに本発明の実施形態では、バックアップ記憶装置３１０は、マップがすでに作成されている場合には、バックアップ記憶装置３１０に複製する処理を行う。さらに他の実施形態では、バックアップ管理部３０５は、バックアップ処理中にマップ生成部３０４を呼び出し、マップをオンザフライで生成させ、バックアップ記憶装置３１０に格納することもできる。
【００３９】
さらに、本実施形態のバックアップ装置３００の機能を説明する。バックアップ装置３００は、バックアップを設定されたシーケンスで実行し、バックアップ情報を履歴的に生成する。バックアップ情報は、全部の情報を１つのバックアップ情報として同一の記憶領域に格納することができる、また、他の実施形態では、データ・ブロックと、メタデータおよびマップをそれぞれ別の記憶領域に、関連づけて格納する形式を採用することもできる。また、バックアップ記憶装置３１０は、例示的に１つとして記載するが、ＲＡＩＤ方式に従い、複数のバックアップ記憶装置３１０を使用して冗長バックアップを行うこともできる。
【００４０】
バックアップ装置３００は、ネットワーク・アダプタ３０２およびストレージ・アダプタ３０６を、外部記憶制御部として備えている。ネットワーク・アダプタ３０２は、ネットワーク３０１を介して外部からアクセスするリモート・コンピュータからの要求を受領し、サーバ装置２０６に各種処理を行なわせている。また、本実施形態の１態様では、サーバ装置２０６は、主記憶装置３０９に格納したデータを遠隔地にあるデータ・センターに送付して、バックアップやリカバリを行うことを可能とする機能も提供する。
【００４１】
ストレージ・アダプタ３０６は、アプリケーション３０７によるファイルの作成、削除、修正に伴って、主記憶装置３０９の該当するファイルを、データ・ブロックおよびメタデータなどと共に格納または削除する。また、ストレージ・アダプタ３０６は、本実施形態のバックアップ処理が、ローカルに行われる場合には、主記憶装置３０９に格納されたファイルを、バックアップ記憶装置３１０に他の情報と共に複製する機能も提供する。なお、ストレージ・アダプタ３０６は、ＲＡＩＤ機能を備えていても良い。
【００４２】
以下、説明の便宜上、より具体的にメタデータが、ＵＮＩＸ／ＬＩＮＵＸ（いずれも登録商標である。）系ＯＳにおけるinodeであるものとして説明を行う。図４は、本実施形態でバックアップ対象となるファイルのデータ構造４００を示す。なお図４に示す実施形態は、データ・ブロック４０３と、inode番号と、inode bitmapとを、同じバックアップ記憶装置３１０にバックアップする実施形態について説明したものである。ファイルは、データの実体的内容であるデータ・ブロック４０３として作成され、これらのデータ・ブロック４０３が、ハードディスクまたは磁気テープなどの記憶メディアに応じたフォーマットで、物理媒体内に記録される。
【００４３】
また、ディレクトリ構造の情報も独立したデータ・ブロックとして記録され、図４に示した実施形態では、データ・ブロック４０４が、ディレクトリ構造を記述したものとして説明されている。ディレクトリ構造は、ディレクトリに含まれるファイル名および当該ファイルのinode番号を対応付けた形式４０５とされる。図４で示したデータ・ブロックのうち、破線で示したデータ・ブロックは、過去に生成され、現在は、削除されたデータ・ブロックであることを示す。
【００４４】
各データ・ブロックには、固有の識別値であるinode番号４０２が関連づけられており、各inode番号で指定された記憶領域には、関連するデータ・ブロックのメタデータが格納される。なお、削除されたデータ・ブロックのinodeデータは、データ・ブロックが現在存在せず、メタデータも存在しないので、void（空）とされている。
【００４５】
inode番号で指定されるメタデータの有無を、バイナリ値に置換した形式としたものが、inode bitmap４０１である。inode bitmap４０１は、メタデータが存在している、すなわち有意なデータを含むデータ・ブロックがその時点で存在する場合、該当するinode番号についてビットを設定（バイナリ１を割り当てる）し、該当するinode番号に対応するデータ・ブロックが存在しない場合にはビットを設定（バイナリ０を割り当てる）し、既存のinode番号全部について生成される。図４では、削除されたデータ・ブロックに対応するinode番号についてのビットが０とされているのが示されている。
【００４６】
図５は、メタデータおよびディレクトリ構造をデータ・ブロックと分離してバックアップする実施形態における、データ構造５００を説明した図である。図５に示した実施形態では、inode bitmap５０２およびinode５０３は、本実施形態のハックアップ方式によりバックアップされる。一方、データ・ブロック５１０は、バックアップとは分離した、例えばＴＳＭ（Tivoli Storage Manager：登録商標）プロセスを使用し、ストレージ間の階層的バックアッププロセスによって独立してバックアップが行われる、いわゆるスケーラブルバックアップ方式に従う実施形態である。このバックアップ方式では、データ・ブロック５１０は、メタデータなどと別に格納される。
【００４７】
図６は、本実施形態のバックアップ方法のフローチャートを示す。本実施形態のバックアップ方法は、ステップＳ６００から開始し、ステップＳ６０１で最初のバックアップかを判断する。最初のバックアップの場合（ｙｅｓ）、ステップＳ６０２で全inodeおよび関連するデータ・ブロックをバックアップして、ステップＳ６０７で処理を終了する。
【００４８】
一方、ステップＳ６０１で、最初のバックアップではないと判断した場合（ｎｏ）、ステップＳ６０３で、前回のバックアップ時刻Ｔｎを読み込み、ステップＳ６０４で最終更新時刻がＴｎよりも新しいinode情報を有するデータ・ブロックを新規作成または変更されたデータ・ブロックとして検出する。ステップS６０５では、検出されたデータ・ブロックのinode情報およびデータ・ブロック自体をinode番号に対応付けてバックアップ記憶装置３１０に複製する。ステップＳ６０６で、inode
bitmapが生成されていない場合には、inode bitmapを生成し、inode bitmapをバックアップ記憶装置３１０に複製することによってバックアップし、ステップＳ６０７で処理を終了する。
【００４９】
ステップＳ６０７が終了した時点で、バックアップ時刻が異なる毎に、差分データ・ブロック、inode、inode bitmap（最初のバックアップを除く）を含むバックアップ情報が生成される。図７は、図６の処理で生成されるバックアップ情報７００の実施形態を示す。
【００５０】
現在、主記憶装置３０９には、バックアップ時刻Ｔｎのファイル７０１が存在するものとする。一方、バックアップ記憶装置３１０には、最初（Ｔ１）のバックアップ情報７１１、２回目（Ｔ２）のバックアップ情報７１２、時刻Ｔｎのバックアップ情報７１３が、バックアップ履歴７１０として生成される。Ｔ２〜Ｔｎは、最初のバックアップではないので、Ｔｎ−１以後Ｔｎまでに追加・修正された差分データ・ブロック、当該差分データ・ブロックに関連するinode、およびinode bitmapがバックアップ情報７１２、７１３として生成される。
【００５１】
バックアップ履歴７１０を構成するバックアップ情報７１１、７１２〜７１３は、バックアップ記憶装置３１０の適切な記憶領域に記憶させることができ、例えばバックアップ記憶装置３１０がハードディスク・ドライブの場合、ディレクトリなどとして記憶することができる。またバックアップ記憶装置３１０が、磁気テープドライブの場合には、磁気テープの異なる領域に記憶させることもできる。
【００５２】
図８は、本実施形態で、バックアップ情報をリストアする場合の処理のフローチャートを示す。本実施形態のバックアップ方法でバックアップされた情報をリストアする処理は、ステップＳ８００から開始し、ステップＳ８０１でリストア・ポイントがＴ１か否かを判断する。なお、リストア・ポイントは、ユーザが指定するようにしても良いし、システムが設定するようにしても良い。ステップＳ８０１で、リストア・ポイントがＴ１であると判断した場合（ｙｅｓ）、ステップＳ８０２で全inodeおよび関連するデータ・ブロックをバックアップ記憶装置３１０から主記憶装置３０９にリストアし、ステップＳ８０５で処理を終了する。
【００５３】
一方、ステップＳ８０１でリストア・ポイントがＴ１ではないと判断した場合、ステップＳ８０３でリストア・ポイントの識別値、例えばタイムスタンプがＴｒのバックアップ情報に含まれるinode bitmapを主記憶装置３０９に読み込む。その後ステップＳ８０４では、バックアップ情報Ｔ１〜Ｔｒまでの各バックアップ情報を検索し、ステップＳ８０３で読み込んだinode bitmapのビット情報を参照し、ビットが設定されているinode番号のメタデータおよび対応するデータ・ブロックをバックアップ記憶装置３１０から主記憶装置３０９に読み込み、該当するinode番号の記憶領域にメタデータおよびデータ・ブロックを格納しリストアを行う。リストア・ポイントＴｒのinode bitmapで規定されるファイル構造が得られると、ステップＳ８０５でリストアを終了させる。
【００５４】
図９は、本実施形態のリストア処理でバックアップ記憶装置３１０から主記憶装置３０９に複製されるデータおよび情報を示す概略図である。リストア開始時、バックアップ履歴９１０から、まず、リストア・ポイントＴｒのバックアップ情報９１３を検索し、登録されているinode bitmap９００を主記憶装置３０９に読み込む。次いで、inode bitmap９００のビット・イメージに従って、バックアップ情報９１１〜９１３を新しいバックアップ情報から古いバックアップ情報へと検索し、inode bitmapのビットが設定されているinode番号が存在するバックアップ情報から対応する最新のデータ・ブロックおよびメタデータを読み出す。その後、対応するinode番号で指定される記憶領域にメタデータおよびデータ・ブロックを格納して、inode情報およびデータ・ブロックをリストアする。
【００５５】
同一のinode番号で識別されるメタデータおよびデータ・ブロックが異なるバックアップ情報で見出される場合には、バックアップ時刻が新しいバックアップ情報のメタデータおよびデータ・ブロックを読み込んでリストアする。この際、すでにリストアしたinode番号については検索処理から除外することで、リストアの進行に応じて検索効率を改善することができる。なお、リストアを行うinode番号のシーケンスは、inode bitmapの最下位ビットに対応するバックアップ情報から開始しても良いし、inode bitmapの最上位ビットに対応するバックアップ情報から開始しても良い。
【００５６】
なお、inode番号、inode情報およびディレクトリのデータ・ブロックがファイルのデータ・ブロックと分離して格納されるスケーラブルバックアップ方式の場合には、検索するべきバックアップ記憶装置または記憶領域を適合的に拡張することにより、リストアを行うことができる。
【００５７】
以上のリストア処理が終了すると、リストア・ポイントＴｒで指定されるinode bitmapに対応するinodeおよびデータ・ブロックが、リストア済みデータ９２０として再現される。以上、本実施形態のバックアップ処理およびリストア処理は、削除されたファイルを識別する目的で生成する中間ファイルを使用すること無く、削除されたファイルを含むリストア処理を可能とする。このため、図9に示したバックアップ情報９１１〜９１３は、リストアに不要なファイルを含むこと無く、大容量のデータ・ファイルの時系列的なバックアップにより生成されるファイルの容量を最小とすることができる。なお、リストア後には、主記憶装置３０９のinode bitmapは、削除することもできるし、そのまま残しておくこともできる。
【００５８】
さらに、本実施形態のバックアップ方法は、削除されたファイルを識別するために中間ファイルを生成する処理を要しないため、バックアップ処理は、差分データ、inode bitmap、inode情報というバックアップに本質的に必要な情報を複製する最小の処理を要求するので、バックアップ処理自体も高速化できる。この結果としてリストア・ポイント間の時間間隔も短くできるので、より高精度のリストアが可能となる。
【００５９】
なお、バックアップ履歴９１０は、ローカル・ストレージに局在化して生成することもできるが、遠隔サイトのデータ・センターのリモート・ストレージ装置を使用して、ＨＴＴＰ、ＦＴＰといった適切なデータ転送プロトコルで、データ・センターにバックアップ履歴９１０を生成することもできる。この実施形態の場合、中間ファイルのファイル転送を排除することができ、より効率的なストレージ・サービスまたはクラウド・サービスを提供することが可能となる。異なるハードウェアにまたがってバックアップおよびリストアする場合、バックアップ先のハードウェアを固有に識別する例えばIPアドレス、ＭＡＣアドレスなどをinode番号にconcatenationして、ハードウェア毎にinode情報を指定する識別値を生成させてファイル・アクセスを可能とすることができる。
【００６０】
また、例えばストレージ・エリアネットワーク（ＳＡＮ）のリモート・ストレージ装置を使用する場合、特定のノードでのリストアを行うために、他のノードのバックアップ情報９１１、９１２を使用して特定の情報処理装置のデータ・リストア処理を行うこともできる。この実施態様では、データ冗長性を保証しながら、より効率的なリストア処理が可能となり、データ保全性を改善することが可能となる。
【００６１】
以上説明したように、本発明によれば、効率的な差分バックアップを可能とする情報処理装置、情報処理システム、バックアップ方法、およびプログラムを提供することができる。
【００６２】
これまで本発明について実施形態をもって説明してきたが、本発明は、図面に示した実施形態に限定されず、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【図１】
0005991699.tif 000002
【図２】
0005991699.tif 000003
【図３】
0005991699.tif 000004
【図４】
0005991699.tif 000005
【図５】
0005991699.tif 000006
【図６】
0005991699.tif 000007
【図７】
0005991699.tif 000008
【図８】
0005991699.tif 000009
【図９】
0005991699.tif 000010
【図１０】
0005991699.tif 000011
【図１１】
0005991699.tif 000012