情報処理装置、システム再開方法及びシステム再開プログラム
【課題】 障害をトリガに実行されるバックアップファイルのリストアを確実に実行できるようにする。
【解決手段】 本発明の情報処理装置は、バックアップファイルを記憶する外部記憶手段と、アプリケーションが利用するファイルを記憶するローカル記憶手段と、障害発生後のリブート時に、次のリブート時に、外部記憶手段からローカル記憶手段へバックアップファイルをリストアするか、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のリブート時に、どのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、上述の第１の情報に従い、バックアップファイルのリストアを制御するリストア制御手段とを有する。そして、リブート関連情報管理手段がアプリケーションの機能部とし、リストア制御手段がアプリケーションの外部機能部として構成されていることを特徴とする。
【解決手段】 本発明の情報処理装置は、バックアップファイルを記憶する外部記憶手段と、アプリケーションが利用するファイルを記憶するローカル記憶手段と、障害発生後のリブート時に、次のリブート時に、外部記憶手段からローカル記憶手段へバックアップファイルをリストアするか、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のリブート時に、どのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、上述の第１の情報に従い、バックアップファイルのリストアを制御するリストア制御手段とを有する。そして、リブート関連情報管理手段がアプリケーションの機能部とし、リストア制御手段がアプリケーションの外部機能部として構成されていることを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、システム再開方法及びシステム再開プログラムに関し、例えば、バックアップファイルからシステムを再開させる場合に適用して好適なものである
【背景技術】
【０００２】
一般に、高信頼性を求められるシステムにおいては、バックアップファイルを複数世代管理している。そのようなシステムでは、バックアップファイルをリストア（復元）する際に、複数世代からバックアップファイルを選択するために、何等かのロジックが必要になる。例えば、特許文献１では、ユーザがリストアするファイルを選択することが記載されている。
【０００３】
ＩＰ電話サービスを提供するコールサーバのように非常に高い信頼性を求められるシステムにおいては、システム停止時間を最短にするため、障害発生時には、自律的にプロセスの再起動を実施する仕組みを有している。さらに、現用ファイルでの再起動が不可能だと判断された場合、バックアップファイルからの復旧がシステム自律で実施される。このとき、リストアには、可能な限り新しいファイルで復旧させること、システム停止時間を最短にすることが求められる。このため、復旧対象のプログラムは、現用ファイルも含めて複数世代のファイルから最適なファイルを選択するロジックを持つ必要がある。このため、リストア機能も、そのプロセスの他の機能（例えば、ネットワーク通信機能や障害監視など）と同一プロセスに存在するのが一般的である。
【特許文献１】特開２００６−１７８６４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
バックアップファイルからの再開が必要となる主な原因は、アプリケーションの障害によるものである。例えば、新機能の追加やバグの修正などによりプログラムに改修があり、運用中のサーバ上の実行ファイルを更新する場合は、実績のないファイルでの起動となるため、このようなアプリケーションは障害が発生し易い。
【０００５】
一方、障害が発生する原因としては、改修によりプログラムが複雑化し、バグが埋め込まれることが挙げられる。
【０００６】
上述したリストア機能は、一般的には他の機能と同一プロセス内に存在するが、この場合、バグの埋め込みによるプロセス障害が、その障害からの復旧手段であるリストア機能に影響を及ぼす恐れがあった。
【０００７】
そのため、アプリケーションの障害をトリガに実行されるバックアップファイルのリストアを確実に実行することができる情報処理装置、システム再開方法及びシステム再開プログラムが望まれている。
【課題を解決するための手段】
【０００８】
第１の本発明の情報処理装置は、（１）少なくとも１つのバックアップファイルを記憶している外部記憶手段と、（２）アプリケーションが利用するファイルを記憶するローカル記憶手段と、（３）上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、（４）管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段とを有し、（５）上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されていることを特徴とする。
【０００９】
第２の本発明は、外部記憶手段に記憶されているバックアップファイルの中の１つを、アプリケーションが利用するファイルを記憶するローカル記憶手段にリストアしてシステムを再開することも可能なシステム再開方法において、（１）リブート関連情報管理手段が、上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理し、（２）リストア制御手段が、管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御すると共に、（３）上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されていることを特徴とする。
【００１０】
第３の本発明のシステム再開プログラムは、少なくとも１つのバックアップファイルを記憶している外部記憶手段と、アプリケーションが利用するファイルを記憶するローカル記憶手段とを含むコンピュータを、（１）上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、（２）管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段として機能させると共に、（３）上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されていることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、リストア制御手段を、複雑になりがちな他手段と切り分けて構築しているので、バックアップファイルのリストアを確実に実行できるようになる。
【発明を実施するための最良の形態】
【００１２】
（Ａ）主たる実施形態
以下、本発明による情報処理装置及びプロセス再開方法の一実施形態を、図面を参照しながら詳述する。実施形態の情報処理装置は、ＩＰ電話サービスを提供するコールサーバのような、非常に高い信頼性を求められるサーバである。
【００１３】
この実施形態は、リストア機能部を他の機能部と別プロセスとする。また、リストアする際に必要な世代判断のロジックを主たる機能部に持たせることでリストア機能を単純化している。これにより、障害が発生した場合でも、その復旧手段であるリストアを確実に行う方法である。
【００１４】
（Ａ−１）実施形態の構成
図１は、実施形態に係るサーバのリストア機能に関するシステム構成を示すブロック図である。なお、サーバは、ＣＰＵ、ＲＯＭ、ＲＡＭなどを備え、後述するＯＳやアプリケーションやバックアッププロセスの処理は、ハードウェア的にはＣＰＵが実行するものである。
【００１５】
例えば、コールサーバが該当するサーバ１には、ローカルディスク５などを有するハードウェアと、後述するソフトウェアを連携させるためのｌｉｎｕｘ（登録商標）などのＯＳ２が搭載されている。このＯＳ２上でアプリケーション３やバックアッププロセス４などのプロセスが動作する。アプリケーション３は、当該サーバ１が提供するサービスプロセス（例えば呼処理サービス）に係る処理を実行するものであり、ローカルディスク５上にある実行ファイルが実行されることにより起動する。
【００１６】
サーバ１の外部に設けられている外部ディスク７には、複数世代のバックアップファイルが保存されている。ローカルディスク５上に管理される再開情報ファイル６は、リストアに関する情報が記述されるファイルである。アプリケーション３は、次にリストアすべき世代を決定し、この再開情報ファイル６に書き込む動作を実行すると共に、次回起動時には、再度この再開情報ファイル６を読み込んで、さらに次のリストアすべき世代を決定するものである。バックアッププロセス４は、常駐せず、必要に応じて（障害発生時などに）、ＯＳ２又はアプリケーション３から起動されるものである。
【００１７】
ローカルディスク５や外部ディスク７は、ハードディスクや光ディスクで構成されているものに限定されず、他の大容量記憶装置に構成されていても良い。
【００１８】
図２は、再開情報ファイル６が保持する情報（設定項目）を示している。再開情報ファイル６では、次回リストアファイルＦ１１、次回起動ファイルＦ１２、リトライ回数Ｆ１３の情報を管理する。
【００１９】
次回リストアファイルＦ１１は、次回のシステム起動時に、外部ディスク７からリストアすべきファイルを表している。後述するように、ローカルディスク５に格納されている現用ファイルが、次回のシステム起動時に利用されることもあり、このような場合には、次回リストアファイルは「なし」となる。次回起動ファイルＦ１２は、次回のシステム起動時に、シンボリックリンク（一種のポインタである）「／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ」が指すべきリンク先を表している（図４〜図７参照）。リトライ回数Ｆ１３は、現在起動している世代のバックアップファイルを用いたリトライ回数を表している。
【００２０】
図３は、外部ディスク７に世代別に保存されているバックアップファイル例を示す説明図である。図３に示す例では、外部ディスク７には、前回ファイルＦ２１と保障ファイルＦ２２とが格納されている状態を示している。なお、バックアップファイルの数が２個に限定されないことは勿論である。
【００２１】
前回ファイルＦ２１は、例えば、前日の所定時刻に格納動作された、現在運用中のファイルの１世代前のファイルである。保障ファイルＦ２２は、前回ファイルよりも古い世代のファイルであり、起動することを保障し得るファイル（例えば、過去の障害時に正常起動ができたファイル）である。ここで、バックアップファイルとは、アプリケーションの実行ファイル、コンフィグファイル、各種データファイルなどが含まれるものである。外部ディスク７上のバックアップファイルを、ローカルディスク５上に復元し、アプリケーション３を起動することにより、バックアップ実施時点の状態でアプリケーション３を起動することができる。また、バックアップファイルからの起動では、可能な限り、新しいバックアップファイルで起動させようとする。図３の例の場合、前回ファイルＦ２１から起動を試みることになる。
【００２２】
図４〜図７は、ローカルディスク４についてアプリケーション２が使用するディレクトリ構成を示す説明図である。
【００２３】
図４〜図７において、ディレクトリ／ｄａｔａ／ｄａｔａ１〜／ｄａｔａ／ｄａｔａ３は、現用ファイル、バックアップファイルを示している。
【００２４】
例えば、図４〜図６において、ディレクトリ／ｄａｔａ／ｄａｔａ１は現用ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ２は保障ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ３は前回ファイルに係るディレクトリである。一方、図７において、ディレクトリ／ｄａｔａ／ｄａｔａ１は前回ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ２は保障ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ３は現用ファイルに係るディレクトリである。例えば、ディレクトリ／ｄａｔａ／ｄａｔａ３の前回ファイルをバックアップファイルとして用いた障害復旧（図６参照）が正常に終了したときには、図７に示す状態に移行する。
【００２５】
シンボリックリンク／ａｐｌ／ＲＥＡＬは、現用ファイルのディレクトリへのシンボリックリンクであり、／ａｐｌ／ＢＫ０は、保障ファイルのディレクトリへのシンボリックリンクであり、／ａｐｌ／ＢＫ１は、前回ファイルのディレクトリへのシンボリックリンクである。また、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／は、現用ファイルへのシンボリックリンク／ａｐｌ／ＲＥＡＬ、保障ファイルへのシンボリックリンク／ａｐｌ／ＢＫ０、又は、前回ファイルへのシンボリックリンク／ａｐｌ／ＢＫ１へのシンボリックリンクである。図４及び図７は、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／が／ａｐｌ／ＲＥＡＬにリンクしている場合を示しており、図５は、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／が／ａｐｌ／ＢＫ０にリンクしている場合を示しており、図６は、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／が／ａｐｌ／ＢＫ１にリンクしている場合を示している。
【００２６】
（Ａ−２）実施形態の動作
次に、実施形態の情報処理装置の動作（プロセス再開方法）を、図面を参照しながら説明する。以下では、現用ファイルを用いていた処理で障害が発生し、バックアップファイルでの立ち上げを繰り返す動作を説明する。
【００２７】
まず、現用ファイルを用いていた処理で障害が発生したためにリブートが発生する際の動作を、図８のシーケンス図を参照しながら説明する。
【００２８】
アプリケーション３が現用ファイルを用いて実行した処理で障害が発生すると、アプリケーション３からＯＳ２へシャットダウンが要求され、ＯＳ２はシャットダウン処理を開始する（Ｓ１）。このシャットダウン処理の中で、ＯＳ２によって、バックアッププロセス４が起動される。なお、アプリケーション３がバックアッププロセス４を起動するようにしても良い。現用ファイルを用いていた処理状況下では、ＯＳ２の管理下にある再開情報ファイル６（図２参照）の初期設定値は、次回リストアファイルが「なし」、次回起動ファイルが「ＲＥＡＬ」（現用ファイル）であり、リトライ回数が「０」である（Ｓ２）。起動されたバックアッププロセス４は、このような再開情報ファイル６を読み込むが（Ｓ３）、次回起動ファイルがＲＥＡＬであり、現在のシンボリックリンク／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎが指しているディレクトリもＲＥＡＬであって、同一なのでシンボリックリンクの変更等をしない（Ｓ４）。
【００２９】
その後、ＯＳ２がリブートされる（Ｓ５）。このような障害発生後の１回目のリブートがなされた後の動作を、図９のシーケンス図に示している。
【００３０】
ＯＳ２のリブート後、開始されたＯＳ２の起動処理の中で（Ｓ６）、バックアッププロセス４が起動される。これにより、バックアッププロセス４は、再開情報ファイル６を読み込むが（Ｓ７）、このときの次回リストアファイルが「なし」であることから、何らの処理も実行しない（Ｓ８）。ＯＳ２のリブート後、アプリケーション３は自律的に起動し（Ｓ９）、再開情報ファイル６の内容を更新する（Ｓ１０〜Ｓ１２）。その後、サービスプロセス（例えば呼処理プロセス）が起動される（Ｓ１３）。
【００３１】
再開情報ファイル６の更新処理は、再開情報ファイル６の読み込み、設定内容の算出、再開情報ファイル６の書き込みという一連の処理でなされる。
【００３２】
図１３は、更新内容の判定ロジックを示す説明図（フローチャート）である。アプリケーション３は、この更新内容の判定ロジックに従って、再開情報ファイル６を更新する。
【００３３】
図１３において、まず、再開情報ファイル６のリトライ回数（Ｆ１３）が、リブートで適用されたファイル（現用ファイル又はリストアされたバックアップファイル）について実行された予め定められている最大リトライ回数に達しているか否かを判別する（Ｓ１００）。なお、リストアされたバックアップファイルは、リストアされた時点で現用ファイルとなっている。
【００３４】
最大リトライ回数に達していなければ、再開情報ファイル６のリトライ回数を１インクリメントした後（Ｓ１０１）、そのインクリメント後のリトライ回数が最大リトライ回数と等しいか否かを判別する（Ｓ１０２）。インクリメント後のリトライ回数が最大リトライ回数より小さいならば、再開情報ファイル６を、図１３の「結果１」のようにする（Ｓ１０３）。すなわち、次回リストアファイルを「なし」、次回起動ファイルを「変更なし（今までのもののまま）」、リトライ回数を「インクリメント後の回数」とする。
【００３５】
一方、インクリメント後のリトライ回数が最大リトライ回数に等しい場合には、さらに、図３に示すような情報を参照し、次に起動するべき世代のバックアップファイルがあるか否かを判断する（Ｓ１０４）。次に起動するべき世代のバックアップファイルがあると、再開情報ファイル６を、図１３の「結果２」のようにし（Ｓ１０５）、次に起動するべき世代のバックアップファイルがないと、再開情報ファイル６を、図１３の「結果３」のようにする（Ｓ１０６）。「結果２」では、次回リストアファイルを「次世代（今のものの次の世代）」、次回起動ファイルを「変更なし（今までのもののまま）」、リトライ回数を「０」とする。「結果３」では、次回リストアファイルを「なし」、次回起動ファイルを「なし」、リトライ回数を「０」とし、アプリケーション３を停止する。リトライを、最下位の世代のファイルを適用して行う状態になり、しかも、最下位の世代のファイルを適用したリトライを最大リトライ回数行っても正常な再起動ができなかったため、アプリケーション３を停止することとしている。
【００３６】
上述したステップＳ１００の判断の肯定結果が得られたときには、図３に示すような情報を参照し、次に起動するべき世代のバックアップファイルがあるか否かを判断する（Ｓ１０７）。次に起動するべき世代のバックアップファイルがないと、再開情報ファイル６を、図１３の「結果３」のようにする（Ｓ１０６）。
【００３７】
これに対して、次に起動するべき世代のバックアップファイルがあると、さらに、次に起動するべき世代のバックアップファイルを用いた最大リトライ回数が０か否かを判別する（Ｓ１０８）。最大リトライ回数が０であれば、再開情報ファイル６を、図１３の「結果４」のようにし（Ｓ１０９）、最大リトライ回数が０でなければ、再開情報ファイル６を、図１３の「結果５」のようにする（Ｓ１１０）。「結果４」では、次回リストアファイルを「次世代」、次回起動ファイルを「次世代」、リトライ回数を「０」とする。「結果５」では、次回リストアファイルを「なし」、次回起動ファイルを「次世代」、リトライ回数を「０」とする。
【００３８】
ここで、現用ファイルでの最大リトライ回数が１回、前回ファイルや保障ファイルでの最大リトライ回数が０回に設定されているとする。このような設定は、コンフィグファイルに記述することで、ユーザによる設定が可能である。
【００３９】
図９のステップＳ１０〜Ｓ１２の再開情報ファイル６の更新では、図１３のステップＳ１０１によってリトライ回数が０から１にインクリメントされる。インクリメント後のリトライ回数「１」は最大リトライ回数に等しく、次の世代として前回ファイルが存在するため、図１３の「結果２」の内容で、再開情報ファイル６が更新される。
【００４０】
ステップＳ１３のプロセス起動処理の際に再び障害が発生すると、ＯＳ２は、シャットダウン処理を開始し（Ｓ１４）、このとき、バックアッププロセス４は再開情報ファイル６を読み込むが（Ｓ１５）、次回起動ファイルはＲＥＡＬ（現用ファイル）であっていままでと同じであるため、バックアッププロセス４は何もせず（Ｓ１６）、ＯＳリブートがなされる（Ｓ１７）。
【００４１】
ＯＳ２のリブート後（図１０）、ＯＳ２の起動処理が開始され（Ｓ１８）、この起動処理中に起動されたバックアッププロセス４は、再開情報ファイル６を読み込み（Ｓ１９）、読み込んだ再開情報ファイル６（図９のステップＳ１１参照）に従い、前回ファイルを外部ディスク７から、／ａｐｌ／ＢＫＦ１にロードする（Ｓ２０）。ロードには時間がかかるため、ＯＳ２は、バックアッププロセス４を動作させたまま、アプリケーション３の起動処理を実行する（Ｓ２１）。アプリケーション３では、図１３に示した判定ロジックに従って、再開情報ファイル６を更新する（Ｓ２２〜Ｓ２４）。その後、サービスプロセスが起動される（Ｓ２５）。
【００４２】
このときの再開情報ファイル６の更新では、図１３の「結果４」が適用され、次回リストアファイルを「２」（保障ファイル）、次回起動ファイルを「ＢＫ１」（前回ファイル）、リトライ回数を「０」とする。
【００４３】
サービスプロセスの起動中に、再び障害が発生すると、ＯＳ２は、シャットダウン処理を開始し（Ｓ２６）、このとき、バックアッププロセス４は再開情報ファイル６を読み込むが（Ｓ２７）、読み込んだ再開情報ファイルの次回起動ファイルが「ＢＫ１」であるので、／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎのシンボリックリンクを／ａｐｌ／ＢＫ１に変更する（Ｓ２８）。この変更により、シンボリックリンク構成は図４から図５に変化したことになる。
【００４４】
これにより、ＯＳリブート後のアプリケーション３は、通常通り／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ配下のファイルを実行することで、外部ディスク７からロードされた前回ファイルが復元されることになる。
【００４５】
このときのＯＳリブート後（Ｓ２９）の動作（図１１）を簡単に説明する。バックアッププロセス４は、外部ディスク７から保障ファイルをロードする（Ｓ３２）。また、アプリケーション３は、図１３の判定ロジックに従って、再開情報ファイル６を、次回リストアファイルを「なし」、次回起動ファイルを「ＢＫ２」（保障ファイル）、リトライ回数を「０」とするように更新する（Ｓ３４〜Ｓ３６）。障害発生により、ＯＳリブートが実行されると、シャットダウン処理中に、バックアッププロセス４は、／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎのシンボリックリンクを／ａｐｌ／ＢＫ２に変更する。この変更により、シンボリックリンク構成は図５から図６に変化したことになる。これにより、ＯＳリブート後のアプリケーション３は、外部ディスク７からロードされた保障ファイルから起動されることになる。
【００４６】
このときのＯＳリブート後（Ｓ４１）の動作（図１２）を簡単に説明する。ＯＳリブート後、バックアッププロセス４は、リストア要求がないことから外部ディスク７からのロードは行わない（Ｓ４４）。また、アプリケーション３は、図１３の判定ロジックに従って再開情報ファイル６を更新するが（Ｓ４６〜Ｓ４８）、このとき、これ以上のエスカレーションは行えず、図１３中の「結果３」と判定され、次回リストアファイルを「なし」、次回起動ファイルを「なし」、リトライ回数を「０」とするように更新する。図１２では記載していないが、仮に、この後、障害発生した場合は、ＯＳリブートせずアプリケーション３は停止する。
【００４７】
図１２は、この保障ファイルでのアプリケーション起動が成功した場合を示している。起動に成功すると（Ｓ４９）、アプリケーション３は、バックアッププロセス４によって、／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎのリンク先を／ａｐｌ／ＲＥＡＬに、／ａｐｌ／ＲＥＡＬのリンク先を／ｄａｔａ／ｄａｔａ３に変更する（Ｓ５０）。この変更により、シンボリックリンク構成は図６から図７に変化したことになる。
【００４８】
また、アプリケーション３は、再開情報ファイル６も、次回リストアファイルが「なし」、次回起動ファイルが「ＲＥＡＬ」（現用ファイル）、リトライ回数が「０」である初期状態に設定し直す（Ｓ５１、Ｓ５２）。
【００４９】
（Ａ−３）実施形態の効果
上記実施形態では、複雑になりがちな他機能部と、リストア機能部を別プロセスとするようにしたので、アプリケーションで障害が発生した場合でも、バックアップ機能には影響を与えず、バックアップファイルのリストア失敗を回避することができる（言い換えると、バックアップファイルのリストアを確実に実行できる）。
【００５０】
（Ｂ）他の実施形態
再開情報ファイル６の項目や構成は、上記実施形態ものに限らず、次にリストアすべき世代のバックアップファイル、次に起動すべきファイルが判定できれば良い。例えば、前回起動したファイルの情報やそのリトライ回数を格納するようにしておいて、それに基づいて、次にリストアすべき世代のバックアップファイル、次に起動すべきファイルを判定させるようにしても良い。
【００５１】
また、再開情報ファイル６のような仕組みを用いずに、アプリケーション３内で、次にリストアすべき世代、次に起動すべきファイルが判定できるようにしても良い。例えば、次にリストアすべき世代、次に起動すべきファイルの複数の組合せを、状態遷移図的な情報として管理するようにしても良い。
【図面の簡単な説明】
【００５２】
【図１】実施形態に係るサーバのリストア機能に関するシステム構成を示すブロック図である。
【図２】実施形態の再開情報ファイルが保持する情報（設定項目）を示す説明図である。
【図３】実施形態の外部ディスクに世代別に保存されているバックアップファイル例を示す説明図である。
【図４】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（１）である。
【図５】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（２）である。
【図６】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（３）である。
【図７】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（４）である。
【図８】実施形態におけるバックアップ再開動作を示すシーケンス図（１）である。
【図９】実施形態におけるバックアップ再開動作を示すシーケンス図（２）である。
【図１０】実施形態におけるバックアップ再開動作を示すシーケンス図（３）である。
【図１１】実施形態におけるバックアップ再開動作を示すシーケンス図（４）である。
【図１２】実施形態におけるバックアップ再開動作を示すシーケンス図（５）である。
【図１３】実施形態における、再開情報ファイルの更新内容の判定ロジックを示す説明図である。
【符号の説明】
【００５３】
１…サーバ、２…ＯＳ、３…アプリケーション、４…バックアッププロセス、５…ローカルディスク、６…再開情報ファイル、７…外部ディスク。
【技術分野】
【０００１】
本発明は、情報処理装置、システム再開方法及びシステム再開プログラムに関し、例えば、バックアップファイルからシステムを再開させる場合に適用して好適なものである
【背景技術】
【０００２】
一般に、高信頼性を求められるシステムにおいては、バックアップファイルを複数世代管理している。そのようなシステムでは、バックアップファイルをリストア（復元）する際に、複数世代からバックアップファイルを選択するために、何等かのロジックが必要になる。例えば、特許文献１では、ユーザがリストアするファイルを選択することが記載されている。
【０００３】
ＩＰ電話サービスを提供するコールサーバのように非常に高い信頼性を求められるシステムにおいては、システム停止時間を最短にするため、障害発生時には、自律的にプロセスの再起動を実施する仕組みを有している。さらに、現用ファイルでの再起動が不可能だと判断された場合、バックアップファイルからの復旧がシステム自律で実施される。このとき、リストアには、可能な限り新しいファイルで復旧させること、システム停止時間を最短にすることが求められる。このため、復旧対象のプログラムは、現用ファイルも含めて複数世代のファイルから最適なファイルを選択するロジックを持つ必要がある。このため、リストア機能も、そのプロセスの他の機能（例えば、ネットワーク通信機能や障害監視など）と同一プロセスに存在するのが一般的である。
【特許文献１】特開２００６−１７８６４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
バックアップファイルからの再開が必要となる主な原因は、アプリケーションの障害によるものである。例えば、新機能の追加やバグの修正などによりプログラムに改修があり、運用中のサーバ上の実行ファイルを更新する場合は、実績のないファイルでの起動となるため、このようなアプリケーションは障害が発生し易い。
【０００５】
一方、障害が発生する原因としては、改修によりプログラムが複雑化し、バグが埋め込まれることが挙げられる。
【０００６】
上述したリストア機能は、一般的には他の機能と同一プロセス内に存在するが、この場合、バグの埋め込みによるプロセス障害が、その障害からの復旧手段であるリストア機能に影響を及ぼす恐れがあった。
【０００７】
そのため、アプリケーションの障害をトリガに実行されるバックアップファイルのリストアを確実に実行することができる情報処理装置、システム再開方法及びシステム再開プログラムが望まれている。
【課題を解決するための手段】
【０００８】
第１の本発明の情報処理装置は、（１）少なくとも１つのバックアップファイルを記憶している外部記憶手段と、（２）アプリケーションが利用するファイルを記憶するローカル記憶手段と、（３）上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、（４）管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段とを有し、（５）上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されていることを特徴とする。
【０００９】
第２の本発明は、外部記憶手段に記憶されているバックアップファイルの中の１つを、アプリケーションが利用するファイルを記憶するローカル記憶手段にリストアしてシステムを再開することも可能なシステム再開方法において、（１）リブート関連情報管理手段が、上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理し、（２）リストア制御手段が、管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御すると共に、（３）上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されていることを特徴とする。
【００１０】
第３の本発明のシステム再開プログラムは、少なくとも１つのバックアップファイルを記憶している外部記憶手段と、アプリケーションが利用するファイルを記憶するローカル記憶手段とを含むコンピュータを、（１）上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、（２）管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段として機能させると共に、（３）上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されていることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、リストア制御手段を、複雑になりがちな他手段と切り分けて構築しているので、バックアップファイルのリストアを確実に実行できるようになる。
【発明を実施するための最良の形態】
【００１２】
（Ａ）主たる実施形態
以下、本発明による情報処理装置及びプロセス再開方法の一実施形態を、図面を参照しながら詳述する。実施形態の情報処理装置は、ＩＰ電話サービスを提供するコールサーバのような、非常に高い信頼性を求められるサーバである。
【００１３】
この実施形態は、リストア機能部を他の機能部と別プロセスとする。また、リストアする際に必要な世代判断のロジックを主たる機能部に持たせることでリストア機能を単純化している。これにより、障害が発生した場合でも、その復旧手段であるリストアを確実に行う方法である。
【００１４】
（Ａ−１）実施形態の構成
図１は、実施形態に係るサーバのリストア機能に関するシステム構成を示すブロック図である。なお、サーバは、ＣＰＵ、ＲＯＭ、ＲＡＭなどを備え、後述するＯＳやアプリケーションやバックアッププロセスの処理は、ハードウェア的にはＣＰＵが実行するものである。
【００１５】
例えば、コールサーバが該当するサーバ１には、ローカルディスク５などを有するハードウェアと、後述するソフトウェアを連携させるためのｌｉｎｕｘ（登録商標）などのＯＳ２が搭載されている。このＯＳ２上でアプリケーション３やバックアッププロセス４などのプロセスが動作する。アプリケーション３は、当該サーバ１が提供するサービスプロセス（例えば呼処理サービス）に係る処理を実行するものであり、ローカルディスク５上にある実行ファイルが実行されることにより起動する。
【００１６】
サーバ１の外部に設けられている外部ディスク７には、複数世代のバックアップファイルが保存されている。ローカルディスク５上に管理される再開情報ファイル６は、リストアに関する情報が記述されるファイルである。アプリケーション３は、次にリストアすべき世代を決定し、この再開情報ファイル６に書き込む動作を実行すると共に、次回起動時には、再度この再開情報ファイル６を読み込んで、さらに次のリストアすべき世代を決定するものである。バックアッププロセス４は、常駐せず、必要に応じて（障害発生時などに）、ＯＳ２又はアプリケーション３から起動されるものである。
【００１７】
ローカルディスク５や外部ディスク７は、ハードディスクや光ディスクで構成されているものに限定されず、他の大容量記憶装置に構成されていても良い。
【００１８】
図２は、再開情報ファイル６が保持する情報（設定項目）を示している。再開情報ファイル６では、次回リストアファイルＦ１１、次回起動ファイルＦ１２、リトライ回数Ｆ１３の情報を管理する。
【００１９】
次回リストアファイルＦ１１は、次回のシステム起動時に、外部ディスク７からリストアすべきファイルを表している。後述するように、ローカルディスク５に格納されている現用ファイルが、次回のシステム起動時に利用されることもあり、このような場合には、次回リストアファイルは「なし」となる。次回起動ファイルＦ１２は、次回のシステム起動時に、シンボリックリンク（一種のポインタである）「／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ」が指すべきリンク先を表している（図４〜図７参照）。リトライ回数Ｆ１３は、現在起動している世代のバックアップファイルを用いたリトライ回数を表している。
【００２０】
図３は、外部ディスク７に世代別に保存されているバックアップファイル例を示す説明図である。図３に示す例では、外部ディスク７には、前回ファイルＦ２１と保障ファイルＦ２２とが格納されている状態を示している。なお、バックアップファイルの数が２個に限定されないことは勿論である。
【００２１】
前回ファイルＦ２１は、例えば、前日の所定時刻に格納動作された、現在運用中のファイルの１世代前のファイルである。保障ファイルＦ２２は、前回ファイルよりも古い世代のファイルであり、起動することを保障し得るファイル（例えば、過去の障害時に正常起動ができたファイル）である。ここで、バックアップファイルとは、アプリケーションの実行ファイル、コンフィグファイル、各種データファイルなどが含まれるものである。外部ディスク７上のバックアップファイルを、ローカルディスク５上に復元し、アプリケーション３を起動することにより、バックアップ実施時点の状態でアプリケーション３を起動することができる。また、バックアップファイルからの起動では、可能な限り、新しいバックアップファイルで起動させようとする。図３の例の場合、前回ファイルＦ２１から起動を試みることになる。
【００２２】
図４〜図７は、ローカルディスク４についてアプリケーション２が使用するディレクトリ構成を示す説明図である。
【００２３】
図４〜図７において、ディレクトリ／ｄａｔａ／ｄａｔａ１〜／ｄａｔａ／ｄａｔａ３は、現用ファイル、バックアップファイルを示している。
【００２４】
例えば、図４〜図６において、ディレクトリ／ｄａｔａ／ｄａｔａ１は現用ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ２は保障ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ３は前回ファイルに係るディレクトリである。一方、図７において、ディレクトリ／ｄａｔａ／ｄａｔａ１は前回ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ２は保障ファイルに係るディレクトリであり、ディレクトリ／ｄａｔａ／ｄａｔａ３は現用ファイルに係るディレクトリである。例えば、ディレクトリ／ｄａｔａ／ｄａｔａ３の前回ファイルをバックアップファイルとして用いた障害復旧（図６参照）が正常に終了したときには、図７に示す状態に移行する。
【００２５】
シンボリックリンク／ａｐｌ／ＲＥＡＬは、現用ファイルのディレクトリへのシンボリックリンクであり、／ａｐｌ／ＢＫ０は、保障ファイルのディレクトリへのシンボリックリンクであり、／ａｐｌ／ＢＫ１は、前回ファイルのディレクトリへのシンボリックリンクである。また、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／は、現用ファイルへのシンボリックリンク／ａｐｌ／ＲＥＡＬ、保障ファイルへのシンボリックリンク／ａｐｌ／ＢＫ０、又は、前回ファイルへのシンボリックリンク／ａｐｌ／ＢＫ１へのシンボリックリンクである。図４及び図７は、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／が／ａｐｌ／ＲＥＡＬにリンクしている場合を示しており、図５は、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／が／ａｐｌ／ＢＫ０にリンクしている場合を示しており、図６は、シンボリックリンクｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ／が／ａｐｌ／ＢＫ１にリンクしている場合を示している。
【００２６】
（Ａ−２）実施形態の動作
次に、実施形態の情報処理装置の動作（プロセス再開方法）を、図面を参照しながら説明する。以下では、現用ファイルを用いていた処理で障害が発生し、バックアップファイルでの立ち上げを繰り返す動作を説明する。
【００２７】
まず、現用ファイルを用いていた処理で障害が発生したためにリブートが発生する際の動作を、図８のシーケンス図を参照しながら説明する。
【００２８】
アプリケーション３が現用ファイルを用いて実行した処理で障害が発生すると、アプリケーション３からＯＳ２へシャットダウンが要求され、ＯＳ２はシャットダウン処理を開始する（Ｓ１）。このシャットダウン処理の中で、ＯＳ２によって、バックアッププロセス４が起動される。なお、アプリケーション３がバックアッププロセス４を起動するようにしても良い。現用ファイルを用いていた処理状況下では、ＯＳ２の管理下にある再開情報ファイル６（図２参照）の初期設定値は、次回リストアファイルが「なし」、次回起動ファイルが「ＲＥＡＬ」（現用ファイル）であり、リトライ回数が「０」である（Ｓ２）。起動されたバックアッププロセス４は、このような再開情報ファイル６を読み込むが（Ｓ３）、次回起動ファイルがＲＥＡＬであり、現在のシンボリックリンク／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎが指しているディレクトリもＲＥＡＬであって、同一なのでシンボリックリンクの変更等をしない（Ｓ４）。
【００２９】
その後、ＯＳ２がリブートされる（Ｓ５）。このような障害発生後の１回目のリブートがなされた後の動作を、図９のシーケンス図に示している。
【００３０】
ＯＳ２のリブート後、開始されたＯＳ２の起動処理の中で（Ｓ６）、バックアッププロセス４が起動される。これにより、バックアッププロセス４は、再開情報ファイル６を読み込むが（Ｓ７）、このときの次回リストアファイルが「なし」であることから、何らの処理も実行しない（Ｓ８）。ＯＳ２のリブート後、アプリケーション３は自律的に起動し（Ｓ９）、再開情報ファイル６の内容を更新する（Ｓ１０〜Ｓ１２）。その後、サービスプロセス（例えば呼処理プロセス）が起動される（Ｓ１３）。
【００３１】
再開情報ファイル６の更新処理は、再開情報ファイル６の読み込み、設定内容の算出、再開情報ファイル６の書き込みという一連の処理でなされる。
【００３２】
図１３は、更新内容の判定ロジックを示す説明図（フローチャート）である。アプリケーション３は、この更新内容の判定ロジックに従って、再開情報ファイル６を更新する。
【００３３】
図１３において、まず、再開情報ファイル６のリトライ回数（Ｆ１３）が、リブートで適用されたファイル（現用ファイル又はリストアされたバックアップファイル）について実行された予め定められている最大リトライ回数に達しているか否かを判別する（Ｓ１００）。なお、リストアされたバックアップファイルは、リストアされた時点で現用ファイルとなっている。
【００３４】
最大リトライ回数に達していなければ、再開情報ファイル６のリトライ回数を１インクリメントした後（Ｓ１０１）、そのインクリメント後のリトライ回数が最大リトライ回数と等しいか否かを判別する（Ｓ１０２）。インクリメント後のリトライ回数が最大リトライ回数より小さいならば、再開情報ファイル６を、図１３の「結果１」のようにする（Ｓ１０３）。すなわち、次回リストアファイルを「なし」、次回起動ファイルを「変更なし（今までのもののまま）」、リトライ回数を「インクリメント後の回数」とする。
【００３５】
一方、インクリメント後のリトライ回数が最大リトライ回数に等しい場合には、さらに、図３に示すような情報を参照し、次に起動するべき世代のバックアップファイルがあるか否かを判断する（Ｓ１０４）。次に起動するべき世代のバックアップファイルがあると、再開情報ファイル６を、図１３の「結果２」のようにし（Ｓ１０５）、次に起動するべき世代のバックアップファイルがないと、再開情報ファイル６を、図１３の「結果３」のようにする（Ｓ１０６）。「結果２」では、次回リストアファイルを「次世代（今のものの次の世代）」、次回起動ファイルを「変更なし（今までのもののまま）」、リトライ回数を「０」とする。「結果３」では、次回リストアファイルを「なし」、次回起動ファイルを「なし」、リトライ回数を「０」とし、アプリケーション３を停止する。リトライを、最下位の世代のファイルを適用して行う状態になり、しかも、最下位の世代のファイルを適用したリトライを最大リトライ回数行っても正常な再起動ができなかったため、アプリケーション３を停止することとしている。
【００３６】
上述したステップＳ１００の判断の肯定結果が得られたときには、図３に示すような情報を参照し、次に起動するべき世代のバックアップファイルがあるか否かを判断する（Ｓ１０７）。次に起動するべき世代のバックアップファイルがないと、再開情報ファイル６を、図１３の「結果３」のようにする（Ｓ１０６）。
【００３７】
これに対して、次に起動するべき世代のバックアップファイルがあると、さらに、次に起動するべき世代のバックアップファイルを用いた最大リトライ回数が０か否かを判別する（Ｓ１０８）。最大リトライ回数が０であれば、再開情報ファイル６を、図１３の「結果４」のようにし（Ｓ１０９）、最大リトライ回数が０でなければ、再開情報ファイル６を、図１３の「結果５」のようにする（Ｓ１１０）。「結果４」では、次回リストアファイルを「次世代」、次回起動ファイルを「次世代」、リトライ回数を「０」とする。「結果５」では、次回リストアファイルを「なし」、次回起動ファイルを「次世代」、リトライ回数を「０」とする。
【００３８】
ここで、現用ファイルでの最大リトライ回数が１回、前回ファイルや保障ファイルでの最大リトライ回数が０回に設定されているとする。このような設定は、コンフィグファイルに記述することで、ユーザによる設定が可能である。
【００３９】
図９のステップＳ１０〜Ｓ１２の再開情報ファイル６の更新では、図１３のステップＳ１０１によってリトライ回数が０から１にインクリメントされる。インクリメント後のリトライ回数「１」は最大リトライ回数に等しく、次の世代として前回ファイルが存在するため、図１３の「結果２」の内容で、再開情報ファイル６が更新される。
【００４０】
ステップＳ１３のプロセス起動処理の際に再び障害が発生すると、ＯＳ２は、シャットダウン処理を開始し（Ｓ１４）、このとき、バックアッププロセス４は再開情報ファイル６を読み込むが（Ｓ１５）、次回起動ファイルはＲＥＡＬ（現用ファイル）であっていままでと同じであるため、バックアッププロセス４は何もせず（Ｓ１６）、ＯＳリブートがなされる（Ｓ１７）。
【００４１】
ＯＳ２のリブート後（図１０）、ＯＳ２の起動処理が開始され（Ｓ１８）、この起動処理中に起動されたバックアッププロセス４は、再開情報ファイル６を読み込み（Ｓ１９）、読み込んだ再開情報ファイル６（図９のステップＳ１１参照）に従い、前回ファイルを外部ディスク７から、／ａｐｌ／ＢＫＦ１にロードする（Ｓ２０）。ロードには時間がかかるため、ＯＳ２は、バックアッププロセス４を動作させたまま、アプリケーション３の起動処理を実行する（Ｓ２１）。アプリケーション３では、図１３に示した判定ロジックに従って、再開情報ファイル６を更新する（Ｓ２２〜Ｓ２４）。その後、サービスプロセスが起動される（Ｓ２５）。
【００４２】
このときの再開情報ファイル６の更新では、図１３の「結果４」が適用され、次回リストアファイルを「２」（保障ファイル）、次回起動ファイルを「ＢＫ１」（前回ファイル）、リトライ回数を「０」とする。
【００４３】
サービスプロセスの起動中に、再び障害が発生すると、ＯＳ２は、シャットダウン処理を開始し（Ｓ２６）、このとき、バックアッププロセス４は再開情報ファイル６を読み込むが（Ｓ２７）、読み込んだ再開情報ファイルの次回起動ファイルが「ＢＫ１」であるので、／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎのシンボリックリンクを／ａｐｌ／ＢＫ１に変更する（Ｓ２８）。この変更により、シンボリックリンク構成は図４から図５に変化したことになる。
【００４４】
これにより、ＯＳリブート後のアプリケーション３は、通常通り／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎ配下のファイルを実行することで、外部ディスク７からロードされた前回ファイルが復元されることになる。
【００４５】
このときのＯＳリブート後（Ｓ２９）の動作（図１１）を簡単に説明する。バックアッププロセス４は、外部ディスク７から保障ファイルをロードする（Ｓ３２）。また、アプリケーション３は、図１３の判定ロジックに従って、再開情報ファイル６を、次回リストアファイルを「なし」、次回起動ファイルを「ＢＫ２」（保障ファイル）、リトライ回数を「０」とするように更新する（Ｓ３４〜Ｓ３６）。障害発生により、ＯＳリブートが実行されると、シャットダウン処理中に、バックアッププロセス４は、／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎのシンボリックリンクを／ａｐｌ／ＢＫ２に変更する。この変更により、シンボリックリンク構成は図５から図６に変化したことになる。これにより、ＯＳリブート後のアプリケーション３は、外部ディスク７からロードされた保障ファイルから起動されることになる。
【００４６】
このときのＯＳリブート後（Ｓ４１）の動作（図１２）を簡単に説明する。ＯＳリブート後、バックアッププロセス４は、リストア要求がないことから外部ディスク７からのロードは行わない（Ｓ４４）。また、アプリケーション３は、図１３の判定ロジックに従って再開情報ファイル６を更新するが（Ｓ４６〜Ｓ４８）、このとき、これ以上のエスカレーションは行えず、図１３中の「結果３」と判定され、次回リストアファイルを「なし」、次回起動ファイルを「なし」、リトライ回数を「０」とするように更新する。図１２では記載していないが、仮に、この後、障害発生した場合は、ＯＳリブートせずアプリケーション３は停止する。
【００４７】
図１２は、この保障ファイルでのアプリケーション起動が成功した場合を示している。起動に成功すると（Ｓ４９）、アプリケーション３は、バックアッププロセス４によって、／ｏｐｔ／ａｐｐｌｉｃａｔｉｏｎのリンク先を／ａｐｌ／ＲＥＡＬに、／ａｐｌ／ＲＥＡＬのリンク先を／ｄａｔａ／ｄａｔａ３に変更する（Ｓ５０）。この変更により、シンボリックリンク構成は図６から図７に変化したことになる。
【００４８】
また、アプリケーション３は、再開情報ファイル６も、次回リストアファイルが「なし」、次回起動ファイルが「ＲＥＡＬ」（現用ファイル）、リトライ回数が「０」である初期状態に設定し直す（Ｓ５１、Ｓ５２）。
【００４９】
（Ａ−３）実施形態の効果
上記実施形態では、複雑になりがちな他機能部と、リストア機能部を別プロセスとするようにしたので、アプリケーションで障害が発生した場合でも、バックアップ機能には影響を与えず、バックアップファイルのリストア失敗を回避することができる（言い換えると、バックアップファイルのリストアを確実に実行できる）。
【００５０】
（Ｂ）他の実施形態
再開情報ファイル６の項目や構成は、上記実施形態ものに限らず、次にリストアすべき世代のバックアップファイル、次に起動すべきファイルが判定できれば良い。例えば、前回起動したファイルの情報やそのリトライ回数を格納するようにしておいて、それに基づいて、次にリストアすべき世代のバックアップファイル、次に起動すべきファイルを判定させるようにしても良い。
【００５１】
また、再開情報ファイル６のような仕組みを用いずに、アプリケーション３内で、次にリストアすべき世代、次に起動すべきファイルが判定できるようにしても良い。例えば、次にリストアすべき世代、次に起動すべきファイルの複数の組合せを、状態遷移図的な情報として管理するようにしても良い。
【図面の簡単な説明】
【００５２】
【図１】実施形態に係るサーバのリストア機能に関するシステム構成を示すブロック図である。
【図２】実施形態の再開情報ファイルが保持する情報（設定項目）を示す説明図である。
【図３】実施形態の外部ディスクに世代別に保存されているバックアップファイル例を示す説明図である。
【図４】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（１）である。
【図５】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（２）である。
【図６】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（３）である。
【図７】実施形態における、ローカルディスクについてアプリケーションが使用するディレクトリ構成を示す説明図（４）である。
【図８】実施形態におけるバックアップ再開動作を示すシーケンス図（１）である。
【図９】実施形態におけるバックアップ再開動作を示すシーケンス図（２）である。
【図１０】実施形態におけるバックアップ再開動作を示すシーケンス図（３）である。
【図１１】実施形態におけるバックアップ再開動作を示すシーケンス図（４）である。
【図１２】実施形態におけるバックアップ再開動作を示すシーケンス図（５）である。
【図１３】実施形態における、再開情報ファイルの更新内容の判定ロジックを示す説明図である。
【符号の説明】
【００５３】
１…サーバ、２…ＯＳ、３…アプリケーション、４…バックアッププロセス、５…ローカルディスク、６…再開情報ファイル、７…外部ディスク。
【特許請求の範囲】
【請求項１】
少なくとも１つのバックアップファイルを記憶している外部記憶手段と、
アプリケーションが利用するファイルを記憶するローカル記憶手段と、
上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、
管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段とを有し、
上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されている
ことを特徴とする情報処理装置。
【請求項２】
外部記憶手段に記憶されているバックアップファイルの中の１つを、アプリケーションが利用するファイルを記憶するローカル記憶手段にリストアしてシステムを再開することも可能なシステム再開方法において、
リブート関連情報管理手段が、上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理し、
リストア制御手段が、管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御すると共に、
上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されている
ことを特徴とするシステム再開方法。
【請求項３】
少なくとも１つのバックアップファイルを記憶している外部記憶手段と、アプリケーションが利用するファイルを記憶するローカル記憶手段とを含むコンピュータを、
上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、
管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段として機能させると共に、
上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されている
ことを特徴とするシステム再開プログラム。
【請求項１】
少なくとも１つのバックアップファイルを記憶している外部記憶手段と、
アプリケーションが利用するファイルを記憶するローカル記憶手段と、
上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、
管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段とを有し、
上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されている
ことを特徴とする情報処理装置。
【請求項２】
外部記憶手段に記憶されているバックアップファイルの中の１つを、アプリケーションが利用するファイルを記憶するローカル記憶手段にリストアしてシステムを再開することも可能なシステム再開方法において、
リブート関連情報管理手段が、上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理し、
リストア制御手段が、管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御すると共に、
上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されている
ことを特徴とするシステム再開方法。
【請求項３】
少なくとも１つのバックアップファイルを記憶している外部記憶手段と、アプリケーションが利用するファイルを記憶するローカル記憶手段とを含むコンピュータを、
上記アプリケーションの障害発生後のシステム再開時に、今回の次のシステム再開時に、上記外部記憶手段から上記ローカル記憶手段へバックアップファイルをリストアするか否か、する場合には、どのバックアップファイルかを決定できる第１の情報、並びに、次のシステム再開時に、現用ファイル及びバックアップファイルのどのファイルを適用するかを決定できる第２の情報を管理するリブート関連情報管理手段と、
管理されている第１の情報に従い、上記外部記憶手段から上記ローカル記憶手段へのバックアップファイルのリストアを制御するリストア制御手段として機能させると共に、
上記リブート関連情報管理手段が上記アプリケーションの機能部として構成され、上記リストア制御手段が上記アプリケーションの外部の機能部として構成されている
ことを特徴とするシステム再開プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００９−１２３０８２（Ｐ２００９−１２３０８２Ａ）
【公開日】平成２１年６月４日（２００９．６．４）
【国際特許分類】
【出願番号】特願２００７−２９８１９１（Ｐ２００７−２９８１９１）
【出願日】平成１９年１１月１６日（２００７．１１．１６）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
【公開日】平成２１年６月４日（２００９．６．４）
【国際特許分類】
【出願日】平成１９年１１月１６日（２００７．１１．１６）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
[ Back to top ]