(57)【要約】【課題】データベースとファイルサーバの両方を併用する文書管理システムにおいて、バックアップをそれぞれ別々に行うと、バックアップデータをリストアした際にデータベースとファイルサーバのデータの整合が取れなくなってしまう。【解決手段】文書の第１のデータを保管するデータベースサーバ、文書の第２のデータを保管するファイルサーバ及び前記ファイルサーバに保管される前記第２のデータのバックアップデータを保管するバックアップファイルサーバを含む文書管理システムにおいて、前記データベースサーバで前記第１のデータのリストアが発生した場合に、前記ファイルサーバで保管される前記第２のデータに対し、前記バックアップファイルサーバでバックアップされたデータを用いて、前記第１のデータに対するリストアの内容に応じたリストアを行なう手段を備えることを特徴とする。【選択図】図１２
2015108966.tif 000002
【特許請求の範囲】
【請求項１】
文書管理システムであって、文書の第１のデータを保管するデータベースサーバ、文書の第２のデータを保管するファイルサーバ及び前記ファイルサーバに保管される前記第２のデータのバックアップデータを保管するバックアップファイルサーバを含み、
前記データベースサーバで前記第１のデータのリストアが発生した場合に、前記ファイルサーバで保管される前記第２のデータに対し、前記バックアップファイルサーバでバックアップされたデータを用いて、前記第１のデータに対するリストアの内容に応じたリストアを行なう手段を備える
ことを特徴とする文書管理システム。
【請求項２】
前記データベースサーバにおける前記第１のデータに対してなされたリストアによるリカバリの内容に基づいて、前記ファイルサーバで管理される前記第２のデータに対して行なうリストアの内容を決定する手段をさらに備える、
ことを特徴とする請求項１に記載の文書管理システム。
【請求項３】
前記バックアップファイルサーバを介さない独立したバックアップ機能を前記ファイルサーバが有している場合に、当該バックアップ機能によってバックアップされたデータに対する独立したリストアを行なうかどうかを判定する判定手段をさらに備え、
前記リストアの内容を決定する手段において決定される、前記ファイルサーバで管理される前記第２のデータに対して行なうリストアの内容は、前記判定手段での判定の結果に応じて異なる、
ことを特徴とする請求項２に記載の文書管理システム。
【請求項４】
前記判定手段は、
前記独立したバックアップ機能によってバックアップされたデータに対する前記独立したリストアを行った場合の処理コストを推定する第１の推定手段と、
前記独立したバックアップ機能によってバックアップされたデータに対する前記独立したリストアを行なわなかった場合の処理コストを推定する第２の推定手段と、
前記第１の推定手段の結果と前記第２の推定手段の結果とを比較して、処理コストが小さい方を選択する手段と
を含むことを特徴とする請求項３に記載の文書管理システム。
【請求項５】
前記ファイルサーバは、前記第２のデータの更新の履歴を示す更新情報を有し、
前記バックアップファイルサーバは、前記更新に伴ってバックアップされるバックアップデータの更新の履歴を示す第２の更新情報を有し、
前記リストアを行なう手段は、不要な処理が間引かれた前記第２の更新情報に従って、前記ファイルサーバにおける前記第２のデータに対し、前記第１のデータに対するリストアの内容に応じたリストアを行なう
ことを特徴とする請求項１乃至４のいずれか１項に記載の文書管理システム。
【請求項６】
前記バックアップファイルサーバは、時系列に保管されたバックアップデータのうち特定の時点より古いバックアップデータを削除する手段をさらに有することを特徴とする請求項１乃至５のいずれか１項に記載の文書管理システム。
【請求項７】
前記第１のデータは文書の書誌情報であり、前記第２のデータは文書の実体ファイルであることを特徴とする請求項１乃至６のいずれか１項に記載の文書管理システム。
【請求項８】
前記更新に伴ってバックアップされるバックアップデータのファイル名には、前記文書の実体ファイルに対する前記更新のリクエストの時間を示す情報を含むことを特徴とする請求項７に記載の文書管理システム。
【請求項９】
文書の第１のデータを保管するデータベースサーバ、文書の第２のデータを保管するファイルサーバ及び前記ファイルサーバに保管される前記第２のデータのバックアップデータを保管するバックアップファイルサーバを含む文書管理システムにおける文書管理方法であって、
前記データベースサーバで前記第１のデータのリストアが発生した場合に、前記ファイルサーバで保管される前記第２のデータに対し、前記バックアップファイルサーバでバックアップされたデータを用いて、前記第１のデータに対するリストアの内容に応じたリストアを行なうステップを含む
ことを特徴とする文書管理方法。
【請求項１０】
コンピュータを、請求項１乃至８のいずれか１項に記載の文書管理システムとして機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書管理システムにおけるデータのバックアップ及びリストアの技術に関する。
【背景技術】
【０００２】
文書管理システムには、大量のデータを低コストで管理するために、高速ではあるが高コストで容量が比較的小さいデータベースと、低速ではあるが低コストで容量が比較的大きいファイルサーバの両方を併用するシステムがある。このような文書管理システムでは、データベース上のデータとファイルサーバ上のデータとの整合性を保つことが求められ、そのために種々の方法が検討されてきた（例えば、特許文献１参照）。また、ファイルサーバのバックアップに関しても定期的に差分バックアップを行うなど、より細やかなタイミングでのリストアができるように検討されてきた（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２８２５９３号公報
【特許文献２】特開２００７−１７９５５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のような、データの格納先がデータベースとファイルサーバに分かれた文書管理システムの場合、データのバックアップはデータベースとファイルサーバのそれぞれにおいて別個に行われることになる。そして、別々にバックアップを行う結果、バックアップの実行や障害発生のタイミングによっては、リストア後のデータの整合が取れなくなってしまう。
【課題を解決するための手段】
【０００５】
本発明に係る文書管理システムは、文書の第１のデータを保管するデータベースサーバ、文書の第２のデータを保管するファイルサーバ及び前記ファイルサーバに保管される前記第２のデータのバックアップデータを保管するバックアップファイルサーバを含み、前記データベースサーバで前記第１のデータのリストアが発生した場合に、前記ファイルサーバで保管される前記第２のデータに対し、前記バックアップファイルサーバでバックアップされたデータを用いて、前記第１のデータに対するリストアの内容に応じたリストアを行なう手段を備えることを特徴とする。
【発明の効果】
【０００６】
データベースとファイルサーバの両方を用いる文書管理システムにおいて、リストア時にデータベースとファイルサーバのデータの整合性を保つことができる。
【図面の簡単な説明】
【０００７】
【図１】実施例１に係る、文書管理システムを構成する各サーバやクライアント端末としての情報処理装置の構成の一例を示す図である。
【図２】実施例１に係る、文書管理システムの構成の一例を示す図である。
【図３】実施例１に係る、文書管理システムにおける処理の流れを示した図である。
【図４】データベースとファイルサーバを併用した文書管理システムにおいて、データベースに障害が発生した場合におけるデータベースとファイルサーバの復旧手順を比較して示した図である。
【図５】実施例１に係る、文書管理システムの機能ブロック図である。
【図６】ファイルサーバにおけるファイル更新処理の流れを示すフローチャートである。
【図７】ジャーナルファイルの一例を示す図である。
【図８】バックアップ実行部によるバックアップの概要を説明する図である。
【図９】バックアップエージェントによるバックアップ処理の詳細を示すフローチャートである。
【図１０】バックアップエージェントによってバックアップファイルがどのように保存されるのかを示す図である。
【図１１】更新後のジャーナルファイルの状態を説明する図である。
【図１２】リストア処理の流れを示すフローチャートである。
【図１３】処理コスト判定処理の詳細を示すフローチャートである。
【図１４】ＦＳリストアした場合及びＦＳリストアしなかった場合のそれぞれの場合におけるバックアップ処理との関係を示した図である。
【図１５】ファイルのリストア処理の詳細を示すフローチャートである。
【図１６】ファイルのリストアを行った後の、履歴データの保管構造を示す図である。
【図１７】ファイルのリストアを行った後のジャーナルファイルの状態を説明する図である。
【図１８】実施例２に係る、直近のＦＳバックアップ以前の履歴データを削除する様子を説明する図である。
【図１９】実施例３に係る、文書管理システムの構成の一例を示す図である。
【発明を実施するための形態】
【０００８】
以下、本発明を実施するための形態について図面を用いて説明する。
【実施例１】
【０００９】
図１は、本実施例に係る、文書管理システムを構成する各サーバやクライアント端末としての情報処理装置の構成の一例を示す図である。図１において、情報処理装置１００は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下、Ｉ／Ｏ）インタフェース１０６、通信インタフェース１０７を備えている。また、情報処理装置１００内の各構成要素はシステムバス１０１を介して互いに接続されている。
【００１０】
ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。
【００１１】
メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）から構成される。
【００１２】
記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４としては、ハードディスクドライブ（ＨＤＤ）、磁気テープドライブ、ＤＶＤ−ＲＯＭ、ＵＳＢメモリなどがある。上述のプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納した上で、ＣＰＵ１０２によって実行される。なお、プログラムをＲＯＭから読み込んだり、通信インタフェース１０７を介して外部から読み込んだりする構成としてもよい。
【００１３】
ビデオインタフェース１０５は、ディスプレイ１１４への表示出力を制御する。
【００１４】
ディスプレイ１１４には、ＣＲＴや液晶等の方式を用いたものがある。
【００１５】
Ｉ／Ｏインタフェース１０６には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することにより情報処理装置１００に対する動作指令等を行う。
【００１６】
ポインティングデバイス１１６は、ディスプレイ１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、ディスプレイ１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ１１４は出力装置と入力装置を兼ねることになる。
【００１７】
通信インタフェース１０７は、ネットワーク１１７を通して外部機器との通信を行う。ネットワーク１１７には、ＬＡＮやＷＡＮ、インターネットのような公衆回線等が含まれる。また、通信インタフェース１０７は、ローカルプリンタ１１８などの他デバイスとの通信も行う。
【００１８】
図２は、本実施例に係る、文書管理システムの構成の一例を示す図である。文書管理システム２００は、ネットワーク１１７を介して相互に接続される、サーバコンピュータ（以下、サーバ）２０１〜２０５と、クライアント端末２１１で構成されている。上述のとおりネットワーク１１７には、ＬＡＮ、ＷＡＮ、インターネット等があり、特にサーバ間接続においてはインターコネクトなどの接続形態も含む。
【００１９】
サーバ２０１はＷｅｂサーバで、クライアント端末２１１との通信を行うためのサーバである。
【００２０】
サーバ２０２はアプリケーションサーバ（以下、ＡＰＰサーバ）で、文書管理システムシステムを制御するプログラムが格納されている。
【００２１】
サーバ２０３はデータベースサーバ（以下、ＤＢ）で、ＡＰＰサーバ２０２が利用する種々のデータのうち、例えば管理対象となる文書の書誌情報などが格納される。
【００２２】
サーバ２０４はファイルサーバ（以下、ＦＳ）で、アプリケーションが利用する種々のデータのうち、例えば管理対象となる文書の実体ファイルなどが格納され、時系列に管理される。
【００２３】
サーバ２０５はバックアップファイルサーバ（以下、ＢＦＳ）で、ＦＳ２０４で保管される文書ファイルのバックアップデータが格納され、時系列に管理される。
【００２４】
なお、本実施例において、サーバ２０１〜２０５、クライアント端末２１１はいずれも、図１で示した情報処理装置の構成を有するものとする。ただし、図１の構成に限定するものではなく、他の機能を備えていても構わない。
【００２５】
本実施例に係る文書管理システム２００は、上述したサーバ群２０１〜２０５が協働することにより実現される。ここで、文書管理システムとは、電子文書や電子化された紙文書を保管、管理するコンピュータ上のシステムのことを意味する。電子文書（以下、文書）とは、コンピュータ上のファイル形式で表現できるデータのことを指し、そのコンテンツは文字に限定されない。文書には、画像や動画など様々なコンテンツを含むものとし、ファイル形式で保管されるデータは全て、ここでの「文書」に含まれる。
【００２６】
本実施例に係る文書管理システム２００においては、各サーバにはサーバアプリケーションがそれぞれインストールされる。そして、サーバ群２０１〜２０５の機能を併せて文書管理サービスが提供される。図２ではサーバ群２０１〜２０５をそれぞれ別のサーバ筐体として記載しているが、同一のサーバ内に複数のサーバアプリケーションがインストールされ、機能が集約されていても構わない。また、ラックマウント型のシステムであっても構わない。
【００２７】
図３は、本実施例に係る文書管理システム２００における処理の流れを示した図である。クライアント端末２１１上には、Ｗｅｂブラウザあるいは専用のクライアントアプリケーションがインストールされる。クライアント端末２１１からＷｅｂサーバ２０１へリクエストが発信されると、Ｗｅｂサーバ２０１は受信したリクエストをＡＰＰサーバ２０２へ送信する。ＡＰＰサーバ２０２は、リクエスト内容を解釈して必要な情報をＤＢ２０３およびＦＳ２０４に問い合わせる。そして、ＡＰＰサーバ２０２は、Ｗｅｂサーバ２０１を通して、リクエストに応じた情報をクライアント端末２１１へ送信する。クライアント端末２１１は情報を受信すると、取得した情報をディスプレイに表示する。
【００２８】
ここで、ＡＰＰサーバ２０２は、ＤＢ２０３及びＦＳ２０４を情報の保管場所として用いている。ＤＢ２０３上にインストールされているデータベースアプリケーションは検索性に優れており、ＦＳ２０４はサイズの大きいデータを保管することに適している。すなわち、運用コストの低いＦＳ２０４にデータサイズの大きい実体ファイルを置くことで低コストを実現するとともに、ＤＢ２０３内のデータ量を削減してＤＢ２０３における検索時のパフォーマンス向上を図ることができる。
【００２９】
このように、文書管理システムではデータベースとファイルサーバを併用することがあり、本発明においてもこのような併用を前提としている。本実施例では、ＡＰＰサーバ２０２がＤＢ２０３及びＦＳ２０４へのデータ保管の処理（リクエスト）を同期して行うことで、文書管理システム２００としてのデータの整合性を保っている。
【００３０】
図４は、データベースとファイルサーバを併用した文書管理システムにおいて、データベースに障害が発生した場合におけるデータベースとファイルサーバの復旧手順を比較して示した図である。図４において、右方向の矢印線４００はデータベースにおける時間経過を、同じく右方向の矢印線４１０はファイルサーバにおける時間経過を表しており、矢印線４００及び４１０は同じ時間軸上にある。データベースは、定期的にバックアップを行なってバックアップデータを生成している。また、ファイルサーバも独立したバックアップ機能を使って定期的にバックアップ（以下、ＦＳバックアップ）を行ない、バックアップデータを生成している。なお、バックアップには、全てのデータをバックアップする方法、毎回ある特定の時点から現時点までの差分をバックアップする方法、前回のバックアップ時点からの差分をバックアップする方法などがある。なお、ＦＳバックアップは、後述のバックアップエージェントによって実行されるバックアップとは区別される。また、ファイルサーバにはＦＳバックアップの機能が備わっていないタイプのものもある。
【００３１】
障害が発生すると、データベースは、まず、障害が発生する前の時点（正常な状態であったとき）のバックアップされたデータをリストアする。そして、リストアによって得られたデータに対してＲＥＤＯログを適用する。ここで、ＲＥＤＯログとは、データベースアプリケーション自身がデータベースに対して行なわれた操作（処理）を再実行することができるように記録しているログである。リストアによって、データベースの内容はバックアップが実行された時点に戻ってしまうので、リストアを行なうだけでは、バックアップの実行時から障害発生時までの間になされた処理の内容が失われてしまう。そこで、障害発生時のできるだけ直前の正常な状態まで戻すために、リストアによって得られたデータに対しＲＥＤＯログを適用することになる。ＲＥＤＯログはメモリ１０３に存在するデータベースアプリケーションのインスタンスや、記憶装置１０４に存在するデータベース上に保存されている。そのため、障害の内容によってはＲＥＤＯログが直前の処理まで全て記録されているとは限らない。例えば、データベースアプリケーションのインスタンスに問題が発生した場合には、記憶装置１０４のデータベースに保存されているＲＥＤＯログしか残らない場合もある。従って、記録されて残っているＲＥＤＯログの範囲内で、システム全体における処理の整合性を考慮し、ＲＥＤＯログの適用が行われる。
【００３２】
一方、ファイルサーバ側でも、データベースと同様、ＦＳバックアップによるバックアップデータをリストアしてデータを復元することができる。しかし、データベースとファイルサーバとは別々の機構であり、データベースにおけるバックアップとファイルサーバにおけるＦＳバックアップの間でデータの整合が取れているとは限らない。また、ファイルサーバにはＲＥＤＯログのようなリカバリ手段が無い。そのため、データベース側で、リストアしたデータにＲＥＤＯログが適用された場合、ファイルサーバとデータベースとの間でデータの整合を取ることができない。
【００３３】
従って、データベースとファイルサーバを併用した文書管理システムでは、障害の発生等を機にデータのリストアがなされた場合に、データの不整合が起きるという問題が発生することになる。なお、上述の例では障害発生時の場合を例に説明したが、特定時点の状態に戻したい場合は同様の問題が発生することになる。
【００３４】
次に、上記の問題に対する解決方法について説明する。
【００３５】
図５は、本実施例に係る、文書管理システム２００の機能ブロック図である。以下で述べる各機能は、ＦＳ２０４及びＢＦＳ２０５上で実現される。ＦＳ２０４とＢＦＳ２０５は役割が異なるため、両サーバのそれぞれにおいて図５で示される機能の全てが動作するわけではないが、両サーバが同等の機能を有することで役割を入れ替えることもできる。
【００３６】
リクエスト受信部５０１は、他サーバからのリクエストを受信する。
【００３７】
更新情報管理部５０２は、受信したリクエストに基づいて後述するジャーナルファイルを作成し、管理する。
【００３８】
ファイル管理部５０３は、ＦＳ２０４内にあるファイルの操作、管理を行う。
【００３９】
一時ファイル管理部５０４は、ファイルの変更や削除を行う際に元のファイルを一時的に保存すると共に、保存したファイル（一時ファイル）の管理を行う。
【００４０】
バックアップ実行部５０５は、ＤＢ２０３とのデータ整合性を担保するためのバックアップを行なう。詳細は後述するが、このバックアップ実行部５０５によるバックアップは、前述のＦＳバックアップとは異なる処理であり、専用のバックアップエージェントによってなされる。
【００４１】
ＦＳバックアップ照会部５０６は、前述のＦＳバックアップの内容を照会する。
【００４２】
リストア実行部５０７は、バックアップ実行部５０５によって生成されたバックアップデータに基づいて、後述のリストア処理を実行する。
【００４３】
ＤＢ２０３とのデータ整合性を担保するためのバックアップ処理の説明に入る前に、ＦＳ２０４でのファイルの更新処理について説明する。
【００４４】
図６は、ＦＳ２０４におけるファイル更新処理の流れを示すフローチャートである。なお、本フローチャートに係る一連の処理を実行するためのプログラムは、ＦＳ２０４の記憶装置１０４に記憶されており、メモリ１０３に読み出されＣＰＵ１０２によって実行される。
【００４５】
ステップ６０１において、ＦＳ２０４のリクエスト受信部５０１は、ＡＰＰサーバ２０２からファイル更新のリクエストを受信する。
【００４６】
ステップ６０２において、ＦＳ２０４のファイル管理部５０３は、受信したリクエストのコマンド種別を判定する。コマンド種別には様々なものがあるが、以下では代表的な、ファイルの追加（ＡＤＤ）、変更（ＭＯＤ）、削除（ＤＥＬ）を用いて説明することとする。受信したリクエストのコマンド種別が、ファイルの追加（ＡＤＤ）であると判定されればステップ６０３に進む。一方、受信したリクエストのコマンド種別が、ファイルの変更（ＭＯＤ）或いは削除（ＤＥＬ）であると判定されればステップ６０４に進む。
【００４７】
ステップ６０３において、ＦＳ２０４のファイル管理部５０３は、受信したリクエストに係る処理対象のファイルを所定の位置に保存する。
【００４８】
ステップ６０４において、ＦＳ２０４のファイル管理部５０３は、一時ファイル管理部５０４と連携して、所定の位置に保存中の処理対象ファイルを一時領域に退避させる。
【００４９】
ステップ６０５において、ＦＳ２０４のファイル管理部５０３は、再度、受信したリクエストのコマンドの種別を判定する。受信したリクエストのコマンド種別が削除（ＤＥＬ）であると判定されればステップ６０６に進む。ステップ６０４で一時領域に退避した処理対象のファイルは、これにより削除されることになる。一方、受信したリクエストのコマンド種別が変更（ＭＯＤ）であると判定されればステップ６０３に進み、処理対象のファイルは所定の位置に保存される。
【００５０】
ステップ６０６において、ＦＳ２０４の更新情報管理部５０２は、ジャーナルファイルを更新する。図７は、ＦＳ２０４において管理されるジャーナルファイルの一例を示す図である。図７において、列７０１には、リクエストがあったときのタイムスタンプの情報が入る。このタイムスタンプは、ＤＢ２０３におけるデータの更新処理と同期をとるために必要な情報になる。列７０２には、後述のバックアップを行なったときのタイムスタンプの情報が入る。図７は未バックアップの状態なので値は入っておらず、空文字が格納されている。列７０３には、受信したリクエストのコマンド種別の情報（本実施例では、上述の追加（ＡＤＤ）、変更（ＭＯＤ）、削除（ＤＥＬ）のいずれか）が入る。列７０４には、ファイルが格納されたロケーションの情報が入る。
【００５１】
次に、バックアップ実行部５０５による、上述のようにして更新されたファイルのバックアップについて説明する。図８は、バックアップ実行部５０５によるバックアップの概要を説明する図である。
【００５２】
図８の（ａ）に示されるように、上述のバックアップエージェント８０１によって、ネットワーク１１７を介してＦＳ２０４からＢＦＳ２０５へ、ファイル８０２がコピーされる。バックアップエージェント８０１は、ジャーナルファイルに記録されたデータ順にファイルのバックアップを行う。図８の（ｂ）は、このバックアップ処理の大まかな流れを示すシーケンス図である。矢印線８２１はＡＰＰサーバ２０２からＦＳ２０４へのリクエスト、矢印線８２２は前述したファイル更新処理、矢印線８２３はリクエスト（矢印線８２１）に対するレスポンスをそれぞれ示している。また、矢印線８２４はＦＳ２０４からＢＦＳ２０５へのバックアップリクエスト、矢印線８２６はバックアップリクエスト（矢印線８２４）に対するレスポンスを示している。そして、矢印線８２５は後述するバックアップ処理のうちＢＦＳ２０５にて実行される部分を示し、矢印線８２７はＦＳ２０４にて実行される部分を示している。
【００５３】
このようにバックアップエージェント８０１によるバックアップ処理は、矢印線８２２のファイル更新処理とは非同期で実施され、ＦＳ２０４及びＢＦＳ２０５のバックアップ実行部５０５で連携して実行される。なお、図８の例では、バックアップエージェント８０１は、ＦＳ２０４上で動作する構成としているが、別のサーバ上で動作する構成としてもよい。
【００５４】
図９は、ＢＦＳ２０５及びＦＳ２０４において実行される、バックアップエージェント８０１によるバックアップ処理の詳細を示すフローチャートである。ステップ９０１〜ステップ９１２の処理がＢＦＳ２０５で実行される前述の矢印線８２５に相当し、ステップ９１３及び９１４の処理がＦＳ２０４で実行される前述の矢印線８２７に相当する。なお、本フローチャートに係る一連の処理を実行するためのプログラムは、ＦＳ２０４又はＢＦＳ２０５の記憶装置１０４に記憶されており、メモリ１０３に読み出されＣＰＵ１０２によって実行される。
【００５５】
ステップ９０１において、ＢＦＳ２０５のリクエスト受信部５０１は、バックアップリクエストをＦＳ２０４から受信する。
【００５６】
ステップ９０２において、ＢＦＳ２０５のファイル管理部５０３は、受信したバックアップリクエストのコマンド種別を判定する。ＦＳ２０４からのバックアップリクエストは、前述のジャーナルファイルの列７０３に格納される各コマンドの情報を含んでおり、当該コマンドに応じたバックアップが実行される。すなわち、以下に述べるとおり、各コマンドに対応するバックアップリクエストに応じてファイルが保存（コピー）されていき、バックアップファイルが履歴として蓄積されていくことになる。
【００５７】
ステップ９０３において、ＢＦＳ２０５のバックアップ実行部５０５は、履歴データ保管フォルダを作成する。図１０は、バックアップエージェント８０１によるバックアップ処理によってバックアップファイルがどのように保存されるのかを示す図である。図１０の例では、「ａａａ．ｐｐｔｘ」及び「ｂｂｂ．ｘｌｓｘ」という２種類のファイルに関してバックアップを行った場合の様子が示されている。そして、本ステップで作成される履歴データ保管フォルダとは、図１０におけるフォルダ１００２及び１０１２を指している。この履歴データ保管フォルダの中に、リクエスト毎に更新されたファイルのコピーを、バックアップファイルとして保存して行くことになる。
【００５８】
ステップ９０４において、ＢＦＳ２０５のバックアップ実行部５０５は、バックアップファイルのファイル名を決定する。バックアップファイルに付されるファイル名は、元のファイル名にタイムスタンプとコマンド種別を付与したものとなる。そして、この際のタイムスタンプは、バックアップタイムではなくリクエストタイム（図７の列７０１を参照）が用いられる。上述のとおり、ここでのバックアップはファイルの更新処理とは非同期で行われるが、バックアップファイルのファイル名に用いるタイムスタンプをリクエストタイムにすることでＤＢ２０３との間でデータの整合性を図ることができる。
【００５９】
ステップ９０５において、ＢＦＳ２０５のバックアップ実行部５０５は、ステップ９０４で決定されたファイル名を付したバックアップファイルを所定の位置に保存する。図１０におけるファイル１００３、１００４、１０１４、１０１５が、本ステップで保存されるバックアップファイルに相当する。なお、ファイル１００３、１０１４及び１０１５は変更（ＭＯＤ）コマンドであった場合のバックアップファイルであり、ファイル１００４は追加（ＡＤＤ）コマンドであった場合のバックアップファイルである。
【００６０】
ステップ９０６において、ＢＦＳ２０５のバックアップ実行部５０５は、ＦＳ２０４のスタンバイ環境としてＢＦＳ２０５を利用する設定となっているかどうかを確認する。スタンバイ環境として利用する設定になっていれば、ステップ９０７に進む。一方、スタンバイ環境として利用する設定になっていなければステップ９１２に進む。なお、ＢＦＳ２０５をＦＳ２０４のスタンバイ環境として利用するかどうかは予め設定されている。
【００６１】
ステップ９０７において、ＢＦＳ２０５のバックアップ実行部５０５は、カレントファイルを更新する。ＢＦＳ２０５がスタンバイ環境として動作するためには、ＢＦＳ２０５はＦＳ２０４と同様のデータを保持している必要があり、その同様のデータ（ファイル）に該当するのがカレントファイルである。図１０におけるファイル１００１が、「ａａａ．ｐｐｔｘ」のカレントファイルに相当する。履歴データ保管フォルダ１００２及び当該フォルダ１００２内のファイル群は、ＦＳ２０４には存在しないデータである。そこで、最新のファイルをＦＳ２０４上のファイルと同じ構成で配置する。すなわち、ファイル１００１とファイル１００３とは内容が同じファイルとなる。なお、ＢＦＳ２０５がＦＳ２０４のスタンバイ環境として動作する設定になっていない場合は、ＢＦＳ２０５は単なるバックアップファイルの保管庫として機能するため、カレントファイルは不要である。
【００６２】
ステップ９０８において、ＢＦＳ２０５のバックアップ実行部５０５は、削除状態識別ファイル（ダミーファイル）を生成する。この削除状態識別ファイルは、コンテンツが無いダミーのファイルであるが、削除されたことを示すために生成され保持される。
【００６３】
ステップ９０９において、ＢＦＳ２０５のバックアップ実行部５０５は、生成された削除状態識別ファイルを所定の位置に保存する。図１０におけるファイル１０１３がこの削除状態識別ファイルに相当する。
【００６４】
ステップ９１０において、ＢＦＳ２０５のバックアップ実行部５０５は、追加や更新の場合と同様、ＦＳ２０４のスタンバイ環境としてＢＦＳ２０５を利用する設定となっているかどうかを確認する。スタンバイ環境として利用する設定になっていれば、ステップ９１１に進む。一方、スタンバイ環境として利用する設定になっていなければステップ９１２に進む。
【００６５】
ステップ９１１において、ＢＦＳ２０５のバックアップ実行部５０５は、カレントファイルを削除する。例えば、図１０において、ファイル「ｂｂｂ．ｘｌｓｘ」については、カレントファイルが存在していない。これは、ファイル「ｂｂｂ．ｘｌｓｘ」についてのカレントファイルが削除された状態を示しており、こうしてＢＦＳ２０５は、ＦＳ２０４の環境と同じ状態になる。
【００６６】
ステップ９１２において、ＢＦＳ２０５の更新情報管理部５０２は、ジャーナルファイルの更新を行う。本ステップで更新されるジャーナルファイルは、前述の図７で示したＦＳ２０４のジャーナルファイルと同様のものであるが、ＢＦＳ２０５に存在している。図１１の（ａ）は、ＢＦＳ２０５のジャーナルファイルであって、本ステップで更新された後の状態を示しており、バックアップを行ったときのタイムスタンプの情報が列７０２に格納されている。
【００６７】
前述のとおり、ステップ９１３以降の処理は、ＦＳ２０４において実行される。
【００６８】
ステップ９１３において、ＦＳ２０４のバックアップ実行部５０５は、一時領域に退避していたファイルを削除する。これは、前述した図６のファイル更新処理のフローチャートにおけるファイルの一時領域への退避（ステップ６０４）に伴う処理である。バックアップエージェント８０１によるバックアップ処理がファイル更新処理とは非同期でなされるため、バックアップ処理が完了した後に一時領域に退避していたファイルを削除している。
【００６９】
ステップ９１４において、ＦＳ２０４の更新情報管理部５０２は、ジャーナルファイルの更新を行う。本ステップで更新されるジャーナルファイルはＦＳ２０４に存在する、前述した図７で示したジャーナルファイルである。図１１の（ｂ）は、本ステップで更新された後のジャーナルファイルの状態を示している。図７と対比すると、図１１の（ｂ）では、バックアップがなされたことを表すタイムスタンプの情報が列７０２に格納されているのが分かる。ただし、この時点において未バックアップのリクエストに係るレコード１１０１については、列７０２の値は空文字の状態となっている。
【００７０】
以上が、ＤＢ２０３とのデータ整合性を担保するために行なう、バックアップエージェント８０１によるバックアップ処理の内容である。
【００７１】
（リストア処理）
次に、バックアップエージェントによるバックアップ処理に伴ってなされるリストア処理について、図１２〜図１７を参照しつつ説明する。
【００７２】
図１２は、リストア処理の流れを示すフローチャートである。なお、本フローチャートに係る一連の処理を実行するためのプログラムは、ＢＦＳ２０５の記憶装置１０４に記憶されており、メモリ１０３に読み出されＣＰＵ１０２によって実行される。このリストア処理は、ＢＦＳ２０５からＦＳ２０４に対してなされるものであるが、ＦＳ２０４上のファイルの更新処理は、当然のことながらＦＳ２０４において実行される。
【００７３】
ステップ１２０１において、ＢＦＳ２０５のリストア実行部５０７は、最初にＤＢ２０３のリカバリポイントを取得する。ＤＢ２０３のリカバリポイントとは、ＤＢ２０３においてデータのリストアを行なって、さらにＲＥＤＯログを適用した結果（前述の図４を参照）、どこまでリカバリがなされたのかを示す情報である。
【００７４】
ステップ１２０２において、ＢＦＳ２０５のリストア実行部５０７は、取得したＤＢ２０３のリカバリポイントを元に、バックアップファイルのリカバリポイントを決定する。具体的には、ＦＳ２０４で管理されるジャーナルファイルを参照し、ＤＢ２０３での更新処理と同期して実施されたＦＳ２０４での更新処理の内容を特定する。これにより、ＤＢ２０３との間でデータの整合性を保つため、どこまでＦＳ２０４内のデータをリカバリするのかが特定される。以下、詳しく説明する。
【００７５】
まず、ＤＢ２０３におけるリカバリの最終時刻（現在からみて直近の時刻）の情報をＲＥＤＯログから取得する。その際は、ＲＥＤＯログから直接的に最終時刻の情報を取得してもよいし、間接的に取得（例えばリカバリの最終処理の情報を取得してその情報に基づいて取得）してもよい。そして、取得したリカバリの最終時刻と、ＦＳ２０４のジャーナルファイル（前述の図１１の（ｂ）を参照。）のリクエストタイム列７０１の時刻と比較する。そして、リカバリの最終時刻の直前になされた処理をバックアップファイルのリカバリポイントとして特定する。なお、特定の方法はＷｅｂサーバ２０１におけるデータ保存の同期処理に応じて異なる場合もある。例えば、データベースコミット後に、ＦＳ２０４へのリクエストを送信する場合には、ＤＢ２０３のリカバリ最終時刻の直後になされた処理をバックアップファイルのリカバリポイントとして特定することになる。また、Ｗｅｂサーバ２０１におけるデータ保存の同期処理が複数のリクエストで行われる場合には、セッションIDもしくはスレッドIDなど、処理を識別する情報もジャーナルファイルに保管しておく。
【００７６】
ステップ１２０３において、ＢＦＳ２０５のリストア実行部５０７は、未だバックアップがなされていないデータが存在するかどうかを判定する。未バックアップのデータが存在した場合は、ステップ１２０４に進む。一方、未バックアップのデータが存在しない場合は、ステップ１２０５に進む。
【００７７】
ステップ１２０４において、ＢＦＳ２０５のリストア実行部５０７は、未バックアップのデータのバックアップを行ない、ＢＦＳ２０５にバックアップファイルを保存する。例えば、図１１（ｂ）のレコード１１０１で示す一時保管中のデータが、ここでの未バックアップのデータを意味している。図１１の（ｂ）において、レコード１１０１で示すデータはコマンド（ＡＤＤ）に係る処理でＦＳ２０４には保存されているが、列７０２が空文字の状態であり、バックアップが行われていないことを示している。なお、リストアの方法としては、未バックアップのデータのバックアップを行なうことなく、一時保管先から直接リストアする方法も考えられるが、その場合はＢＦＳ２０５に履歴が残らないことになる。
【００７８】
ステップ１２０５において、ＢＦＳ２０５のＦＳバックアップ照会部５０６は、後述する処理コスト判定処理を行なって、ＦＳリストアを行うかどうかを決定する。なお、ＦＳ２０４がＦＳバックアップの機能を有していない場合には、本ステップ〜ステップ１２０７までの処理は省略されることになる。本ステップでＦＳリストアした方が良いと判定されればステップ１２０７に進む。一方、ＦＳリストアしない方が良いと判定されればステップ１２０８に進む。図１３は、処理コスト判定処理の詳細を示すフローチャートである。図１３のフローチャートの説明の前に、どのような場合にＦＳリストアをした方が良いのかについて説明する。図１４は、ＦＳリストアした場合及びＦＳリストアしなかった場合のそれぞれの場合におけるバックアップ処理との関係を、ＦＳ２０４のジャーナルファイルに基づいて示した図である。太線１４０１は前述のステップ１２０２で特定されたバックアップファイルのリカバリポイントを表し、太線１４０２はＦＳリストアポイント（ＦＳリストアした場合にどこまで復元されるのかを示す情報）を表している。まず、ＦＳリストアした場合は、ＦＳ２０４のデータはＦＳバックアップを行なった時点の内容に戻ってしまうため、ＤＢ２０３との整合をとるためにはＦＳリストアポイント１４０２からリカバリポイント１４０１までの間の更新処理を再実行する必要がある。一方、ＦＳリストアしなかった場合は、現在の状態からリカバリポイント１４０１の状態までデータの内容を戻すことによってＤＢ２０３との整合をとることができる。どちらの場合も結果は同じであるが、処理方法が異なる。そこで、より処理コストの掛からない方の処理方法を、図１３のフローチャートに示す処理コスト判定処理よって判別することになる。
【００７９】
ステップ１３０１において、ＢＦＳ２０５のＦＳバックアップ照会部５０６は、ＦＳリストア自体の処理コストを推定する。例えば、ＦＳ２０４がリストア処理に要する推定時間を返してくれるようなI/Fを持っている場合は、ＦＳ２０４に問合せを行って、当該推定時間の情報を取得する。或いは、ファイル数やファイルサイズ毎に予測される所要時間を予めテーブル等で保持しておき、当該テーブルを参照して取得するようにしてもよい。また、ファイルサイズやファイル数にリストア時間がさほど影響を受けないタイプのファイルサーバであれば一律でn分掛かるといった情報を保持しておいてもよい。さらには、ファイル数に応じてリストア時間が変動するタイプのファイルサーバであれば、「ファイルの登録利用率」×「単位処理時間」の演算を行なって求めるようにしてもよい。
【００８０】
ステップ１３０２において、ＦＳバックアップ照会部５０６は、ジャーナルファイルを参照して、バックアップファイルのリカバリポイントからＦＳリストアポイントまでの更新処理の情報（以下、更新情報）を取得する。例えば、図１４に示すジャーナルファイルの場合、リカバリポイント１４０１からＦＳリストアポイント１４０２までの範囲にある９個のレコードが更新情報として取得される。
【００８１】
ステップ１３０３において、ＦＳバックアップ照会部５０６は、ステップ１３０２で取得した更新情報に対し、過去から現在に向けて不要な中間処理を間引く処理を行なう。例えば、上述した９個のレコードの内容が更新情報として取得された場合、ファイル「ｄｄｄ．ｐｐｔｘ」に対する更新処理としては、３つのレコード（レコード１４１１、１４１２、１４１３）が存在する。これら３つのレコードはすべて変更（ＭＯＤ）処理であり、これらを過去から順に更新すると最終的にはレコード１４１３で更新した処理のファイルになる。つまり、レコード１４１１と１４１２の処理は適用する必要がないので、これら２つのレコードに係る処理が不要な中間処理として間引かれることになる。
【００８２】
ステップ１３０４において、ＦＳバックアップ照会部５０６は、ＦＳリストアした場合に掛かる総処理コストを推定する。具体的には、１ファイルのリストアに掛かる処理コストに、不要な中間処理を間引いた後の更新処理数を乗じ、そうして得られた処理コストに、ステップ１３０１で推定したＦＳリストア自体の処理コストを加算して、総処理コストを推定する。これを式で表すと以下のようになる。
総処理コスト＝（１ファイルのリストア処理時間×Ｓ１３０３で求めた更新処理数）
＋ＦＳリストア自体の処理時間
ここで、１ファイルのリストア処理時間 は、ファイルサイズ×係数で求められる。この係数は、ファイルサイズの大小に応じて予め設定される係数であり、ファイルサイズ毎にどのくらい処理時間が掛かるかをネットワーク環境なども考慮して予め設定しておく。
【００８３】
ステップ１３０５において、ＦＳバックアップ照会部５０６は、現在からバックアップファイルのリカバリポイントまでの更新情報を取得する。更新情報についてはステップ１３０２で説明したとおりであり、図１４の例では、現在からリカバリポイント１４０１までの範囲にある３つのレコードが更新情報として取得されることになる。
【００８４】
ステップ１３０６において、ＦＳバックアップ照会部５０６は、ステップ１３０５で取得した更新情報に対し、現在から過去に向けて不要な中間処理を間引く処理を行なう。間引くことの意味は上述のステップ１３０３と同じであるが、ステップ１３０３では過去から現在に向けて不要な中間処理を間引いていたのに対し、本ステップでは現在から過去に向けて不要な中間処理が間引かれることになる。
【００８５】
ステップ１３０７において、ＦＳバックアップ照会部５０６は、ＦＳリストアしない場合の総処理コストを推定する。ここでは、上述した１ファイルのリストアに掛かる処理コストに、不要な中間処理を間引いた後の更新処理数を乗じることにより、総処理コストを推定する。ＦＳリストアを行わないため、ＦＳリストア自体の処理コストが加算されない点で、ステップ１３０４とは異なっている。
【００８６】
ステップ１３０８において、ＦＳバックアップ照会部５０６は、ステップ１３０４で求めたＦＳリストアする場合の総処理コストと、ステップ１３０７で求めたＦＳリストアしない場合の総処理コストとを比較して、より処理コストの低い方を選択する。
【００８７】
以上が、ＦＳリストアを行うかどうかを判定する処理の内容である。
【００８８】
図１２のフローチャートの説明に戻る。
【００８９】
ステップ１２０７において、ＦＳ２０４のリストア実行部５０７は、ＦＳリストアを実行する。ＦＳリストアの内容については、前述のとおりである。
【００９０】
ステップ１２０８において、ＢＦＳ２０５のリストア実行部５０７は、ＦＳ２０４に対してファイルをリストアする。図１５は、本ステップにおけるファイルのリストア処理の詳細を示すフローチャートである。
【００９１】
ステップ１５０１において、リストア実行部５０７は、ＦＳリストアの実行の有無を確認する。ＦＳリストアが実行されていた場合（ステップ１２０６でＹｅｓ）には、ステップ１５０２に進み、ステップ１５０３〜ステップ１５０６の処理をファイル単位で実行する。一方、ＦＳリストアが実行されなかった場合（ステップ１２０６でＮｏ）には、ステップ１５０７に進み、ステップ１５０８〜ステップ１５１４の処理をファイル単位で実行する。
【００９２】
まず、ＦＳリストアが実行されていた場合の、ファイルのリストア処理について説明する。
【００９３】
ステップ１５０２において、リストア実行部５０７は、前述のステップ１３０３で間引き処理された後の更新情報を取得する。
【００９４】
ステップ１５０３において、リストア実行部５０７は、対象ファイルについて、ジャーナルファイルを参照し、取得した更新情報で特定されるリクエストタイムを持つバックアップファイルの内容で、ＦＳ２０４内の対応するファイルを再更新（上書き）する。
【００９５】
ステップ１５０４において、リストア実行部５０７は、上記再更新処理によって、ＢＦＳ２０５の履歴データ（前述の図１０を参照）に変更が生じるかどうかを判定する。履歴データに変更が生じる場合は、ステップ１５０５に進む。例えば、ファイル「ａａａ．ｐｐｔｘ」は、ＦＳリストア後の再処理によって2013/03/20 14:58:01の状態になるが、ＢＦＳ２０５では2013/03/21 15:52:06の状態である。このような場合は、ステップ１５０５に進む。一方、履歴データに変更が生じない場合には、ＢＦＳ２０５内のバックアップファイルの内容を変更する必要がない。例えば、ファイル「ｄｄｄ．ｐｐｔｘ」については、ＦＳリストア後の再処理された状態（2013/03/20 14:35:25）は、ＢＦＳ２０５でも同じ状態である。このような場合は、未処理のファイルがあれば次のファイルの処理に移行し、未処理のファイルがなければ本処理を終える。
【００９６】
ステップ１５０５において、リストア実行部５０７は、バックアップファイルを更新する。図１６は、ファイルのリストアを行った後の、履歴データの保管構造を示しており、前述の図１０に対応している。リストアを行なう前は、ファイル「ａａａ．ｐｐｔｘ」の最新のバックアップファイルはファイル１００３であり、ファイル「ｂｂｂ．ｘｌｓｘ」の最新のバックアップファイルは削除状態識別ファイル１０１３であった。ここで、ＦＳ２０４におけるファイル「ａａａ．ｐｐｔｘ」がリストアによってファイル１００４の状態に戻った場合、ファイル１００４をコピーして最新のバックアップファイル１６０２が生成される。さらに、カレントファイル１６０１もファイル１００４の内容に更新される。これにより、ファイル１６０１、１６０２、１００４は同じコンテンツのファイルとなる。同様に、ＦＳ２０４におけるファイル「ｂｂｂ．ｘｌｓｘ」がリストアによってファイル１０１５の状態に戻った場合、ファイル１０１５をコピーして最新のバックアップファイル１６１２が生成される。さらに、ファイル１０１５と同じ内容を持つカレントファイル１６１１が生成される。これにより、ファイル１６１１、１６１２、１０１５は同じコンテンツのファイルとなる。そして、最新のバックアップファイル１６０２及び１６１２のファイル名には、リストアされたことを示す識別子が付与される。ここでは、バックアップファイル１６０２にはリストアによって更新が行われたので識別子「ＲＳＴＭＯＤ」が、バックアップファイル１６１２には、リストアによって削除された状態から追加されたので識別子「ＲＳＴＡＤＤ」が付与されている。
【００９７】
ステップ１５０６において、リストア実行部５０７は、ジャーナルファイルを更新する。ジャーナルファイルも、図１６で説明したバックアップファイルの内容に合わせて変更が行われる。図１７は、ファイルのリストアを行った後のＢＦＳ２０５のジャーナルファイルを示している。図１７において、レコード１７０１〜１７０３は、ファイルのリストアによって追加されたレコードである。レコード１７０１〜１７０３のコマンド列７０３には、リストアによって更新されたことを示す情報が格納されている。また、これら３つのレコード１７０１〜１７０３におけるリクエストタイム列７０１とバックアップタイム列７０２には同じタイムスタンプが格納される。そして、この際には、ＦＳ２０４のジャーナルファイルも更新される。
【００９８】
続いて、ＦＳリストアがなされなかった場合のファイルのリストア処理について説明する。
【００９９】
ステップ１５０７において、リストア実行部５０７は、前述のステップ１３０６で間引き処理された後の更新情報を取得する。
【０１００】
ステップ１５０８において、リストア実行部５０７は、対象ファイルについて、取得した更新情報におけるレコードのコマンド種別を判定する。コマンド種別が、ファイルの変更（ＭＯＤ）或いは削除（ＤＥＬ）であると判定されればステップ１５０９に進み、ファイルの追加（ＡＤＤ）であると判定されればステップ１５１２に進む。
【０１０１】
ステップ１５０９において、リストア実行部５０７は、対象ファイルについての、リカバリポイント（１４０１）より前の更新処理の内容を取得する。例えば、図１７において、ファイル「ｂｂｂ．ｘｌｓｘ」が対象ファイルの場合、レコード１７０４で示す内容が取得されることになる。
【０１０２】
ステップ１５１０において、リストア実行部５０７は、取得した前の更新処理の内容に対応するバックアップファイルをＢＦＳ２０５から取得する。例えば、対象ファイルが「ｂｂｂ．ｘｌｓｘ」で、前の更新処理の内容として上述のレコード１７０４の内容が取得されていた場合は、図１６におけるファイル１０１４が取得されることになる。
【０１０３】
ステップ１５１１において、リストア実行部５０７は、ステップ１５１０で取得したバックアップファイルの内容で、ＦＳ２０４内の対応するファイルの内容を更新する。これにより、当該ファイルの内容は前のバージョンに戻ることになる。
【０１０４】
ステップ１５１２において、リストア実行部５０７は、ステップ１５０７で取得した更新情報のレコードにおいてコマンドが追加（ＡＤＤ）となっている対象ファイルを、ＦＳ２０４から削除する。
【０１０５】
以後のステップ１５１３及び１５１４の内容は、前述のステップ１５０５及び１５０６と同じである。すなわち、リストア実行部５０７は、最新のバックアップファイルを生成して（ステップ１５１３）、ジャーナルファイルを更新する（ステップ１５１４）。
【０１０６】
以上が、ファイルのリストア処理の内容である。
【０１０７】
なお、データベースの管理形態に応じて複数のジャーナルファイルが存在する場合は、上述したファイルのバックアップやリストアをジャーナルファイル単位に実行すればよい。
【０１０８】
また、本実施例では、ジャーナルファイルがＦＳ２０４とＦＳ２０５の両方に存在していたがどちらか一方（或いは、データベース上など別の場所）で一元的に管理されていてもよい。
【０１０９】
本実施例によれば、データベースとファイルサーバを併用するシステムにおいて、リストアした場合のデータの整合性を保つことができる。
【実施例２】
【０１１０】
実施例１では、データベースとファイルサーバとの間でデータの整合性を保つために、ファイルサーバで更新された全ての履歴データをバックアップファイルサーバ内に保存していた。しかし、時間の経過と共に保存されるデータ量は増大していくため、不要な履歴データを削除する必要が出てくる。例えば、定期的にファイルサーバで前述のＦＳバックアップを行っている場合、データを直近のＦＳバックアップ以前の状態に戻す可能性は極めて低いと考えられる。そこで、直近のＦＳバックアップ以前など特定の時点よりも古い履歴ファイルを削除することで、バックアップファイルサーバに保存するデータ容量を減らす態様について、実施例２として説明する。なお、実施例１と共通する部分については説明を省略ないしは簡略化し、以下では差異点を中心に説明するものとする。
【０１１１】
図１８は、本実施例に係る、直近のＦＳバックアップ以前の履歴データ（バックアップファイル）を削除する様子を説明する図であり、前述の図１０のバックアップファイルの保管構造に対応している。図１８において、ファイル１８０１はカレントファイルであり、フォルダ１８０２はバックアップファイルを格納する履歴データ保管フォルダである。この履歴データ保管フォルダ１８０２の中に、バックアップファイル１８０３〜１８０９が格納されている。点線１８１０は、直近のＦＳバックアップを行った時点を示している。したがって、図１８の例では、直近のＦＳバックアップの時点１８１０以前に格納されたバックアップファイル１８０６〜１８０９が削除されることになる。
【０１１２】
このバックアップファイルの削除処理は、ＢＦＳ２０５内のファイル管理部５０３によって実行される。具体的には、ＦＳバックアップが行われた日時の情報をＦＳサーバ２０４から受信し、ＢＦＳ２０５内で管理されているバックアップファイルのうち、受信した日時以前のバックアップファイルが削除フォルダ等に移動されて、削除される。
【０１１３】
なお、特定の時点より古いバックアップファイルを削除するだけではなく、例えば、現在あるいは過去の一時点におけるデータを２次的なメディア（例えば、テープメディア）にバックアップするといったことを行なってもよい。
【０１１４】
本実施例によれば、ＦＳバックアップの実行された日時の情報に基づいて、履歴データを定期的に削除することで、バックアップファイルサーバのデータ容量を削減することが出来る。
【実施例３】
【０１１５】
次に、物理的に離れた場所にスタンバイ環境が存在する場合の態様について、実施例３として説明する。なお、実施例１と共通する部分については説明を省略ないしは簡略化し、以下では差異点を中心に説明するものとする。
【０１１６】
図１９は、本実施例に係る、文書管理システムの構成の一例を示す図であり、物理的に離れた場所にスタンバイ環境が存在する様子を示している。図１９において、ＳＤＢ１９０１はＤＢ２０３のスタンバイ環境としてのデータベースであり、ＳＦＳ１９０２はＦＳ２０４のスタンバイ環境としてのファールサーバである。ＳＤＢ１９０１及びＳＦＳ１９０２は、ネットワーク１１７を通して、ＤＢ２０３及びＦＳ２０４と接続されており、相互に物理的に離れたロケーションに配置されている。一般的に、ＤＢ２０３とＳＤＢ１９０１との間の同期は、データベースアプリケーションやデータベースアプリケーションを提供しているベンダーの専用アプリケーションを用いて行われる。そのため、ＦＳ２０４とＳＦＳ１９０２との間の同期は、データベースとは別に行われることになる。従って、データベースとファイルサーバを併用するシステムの場合、リプリケーションされたスタンバイ環境としてのデータベースとファイルサーバは、ある時点においてデータの整合性がとれているとは限らない。そこで、本実施例では、ＳＦＳ１９０２をバックアップファイルサーバとして用いる。つまり、本実施例においてＳＦＳ１９０２は、前述したＢＦＳ２０５と同様の機能を有しつつ、ＦＳ２０４のスタンバイ環境として動作する。
【０１１７】
ＳＦＳ１９０２がＦＳ２０４のスタンバイ環境として動作する場合は、前述のリストア時と同様、ＳＤＢ１９０１のリプリケーションの完了ポイントに基づいて、ＳＦＳ１９０２のデータを更新することで、データの整合性を図る。このスタンバイ環境として動作する場合におけるデータの整合性を図るための処理は、前述の図１２のフローチャートで示したリストア処理と基本的に同じである。その際、ステップ１２０１においてはＤＢ２０３のリカバリポイントに代えてＳＤＢ１９０１におけるリプリケーション完了ポイントが取得されることになる。そして、整合性がとれてからスタンバイ環境を起動させることで、問題なくＤＢサーバとファイルサーバの併用が可能となる。なお、実施例１のリストア時にはＦＳ２０４とＢＦＳ２０５が連携して処理を実行していたが、本実施例のスタンバイ環境では、ＳＦＳ１９０２上で図５の機能ブロック図で示した各機能が動作することになる。
【０１１８】
（その他の実施例）
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2015108966.tif 000003
【図２】
2015108966.tif 000004
【図３】
2015108966.tif 000005
【図４】
2015108966.tif 000006
【図５】
2015108966.tif 000007
【図６】
2015108966.tif 000008
【図７】
2015108966.tif 000009
【図８】
2015108966.tif 000010
【図９】
2015108966.tif 000011
【図１０】
2015108966.tif 000012
【図１１】
2015108966.tif 000013
【図１２】
2015108966.tif 000014
【図１３】
2015108966.tif 000015
【図１４】
2015108966.tif 000016
【図１５】
2015108966.tif 000017
【図１６】
2015108966.tif 000018
【図１７】
2015108966.tif 000019
【図１８】
2015108966.tif 000020
【図１９】
2015108966.tif 000021