JP5683088B2 - 復旧システム、復旧方法及びバックアップ制御システム - Google Patents

Description

本発明は、復旧システム、復旧方法及びバックアップ制御システムに関し、例えば、サーバのハードディスクやサーバ自体の故障発生時にリストアするためのデータやプログラムのシステムに適用し得るものである。

常時稼動しているサーバにおいては、サーバの冗長化や、これに加えて重要なデータやプログラムを定期的にバックアップするのが一般的である。

さらに、高信頼性を求められているシステムにおいては、正常なバックアップデータが上書きされてもリストア可能とするために、複数世代のバックアップデータを保持し、故障発生時に、適切な世代のバックアップデータを選択してリストアを行う。

例えば、ＩＰ電話サービスを提供するコールサーバ等のように非常に高信頼性が求められるサーバにおいては、システム停止時間を最短にするため、障害発生時に自律的にプロセスの再起動を実施する仕組みを有している。さらに、現用ファイルの再起動が不可能だと判断された場合、バックアップデータを用いて復旧することが行われる。このとき、リストアには、可能な限り新しいファイルで復旧させること、システム停止時間を最短にすることが求められる。

サーバの障害発生時に確実かつ迅速な復旧を考慮すると、バックアップデータを自サーバや冗長化の待機系サーバに保持することが一般的である。

特許文献１には、稼動系サーバ及び待機系サーバからなる冗長構成において、稼動系サーバのＯＳマスタボリュームのＯＳ情報を、待機系サーバのＯＳバックアップボリュームにバックアップを行う技術が記載されている。

特許公開２００８−１９８１５２号公報

上述したように、従来、一般的にバックアップデータは、自サーバや冗長構成の待機系サーバ等に保持することとしている。

しかしながら、バックアップデータを保持する自サーバのハードディスク自体が故障した場合や、データやプログラムの不具合に伴い、待機系サーバに保持していたバックアップデータにも不具合が生じる場合がある。

そのため、自サーバのハードディスクが故障した場合や、待機系サーバが保持するバックアップデータに不具合が生じた場合でも、システムの停止時間をできるだけ短くして、確実に復旧することができるシステムが求められている。

本発明は、バックアップデータを保持する外部に退避するバックアップサーバを備え、このバックアップサーバに、バックアップの種別に応じてバックアップデータを分類して保持しておき、障害発生時に応じたバックアップ取得契機及びバックアップ取得先に基づき、迅速かつ確実にバックアップデータを取得して復旧処理を行う復旧システム、復旧方法及びバックアップ制御システムを提供する。

かかる課題を解決するために、第１の本発明の復旧システムは、（１）サーバが利用するファイルを種別毎に分類して記憶するローカル記憶手段と、（２）ローカル記憶手段に記憶するファイルを種別毎に記憶する外部記憶手段と、（３）少なくとも、サーバのシステム障害の態様に応じて取得するバックアップファイルの種別を取り決めた第１の情報を管理する情報管理手段と、（４）サーバにおいて自サーバによるリストアが困難である障害が発生した場合に、サーバの障害回復後、第１の情報に従ったリストア要求を送出するバックアップ制御手段と、（５）バックアップ制御手段からリストア要求を受け取り、このリストア要求で指定されている種別のファイルを外部記憶手段から取得し、サーバに転送する外部バックアップ制御手段とを備え、サーバが、外部バックアップ制御手段から取得したファイルを用いてリストアするリストア手段を有することを特徴とする。

第２の本発明の復旧方法は、（１）ローカル記憶手段が、サーバが利用するファイルを種別毎に分類して記憶するローカル記憶工程と、（２）外部記憶手段が、ローカル記憶手段に記憶するファイルを種別毎に記憶する外部記憶工程と、（３）情報管理手段が、少なくとも、サーバのシステム障害の態様に応じて取得するバックアップファイルの種別を取り決めた第１の情報を管理する情報管理工程と、（４）バックアップ制御手段が、サーバにおいて自サーバによるリストアが困難である障害が発生した場合に、サーバの障害回復後、第１の情報に従ったリストア要求を送出するバックアップ制御工程と、（５）外部バックアップ制御手段が、バックアップ制御手段からリストア要求を受け取り、このリストア要求で指定されている種別のファイルを外部記憶手段から取得し、サーバに転送する外部バックアップ制御工程とを有し、サーバが、外部バックアップ制御手段から取得したファイルを用いてリストアするリストア工程を有することを特徴とする。

第３の本発明のバックアップ制御システムは、（１）サーバが利用するファイルを種別毎に分類して記憶するローカル記憶手段と、（２）ローカル記憶手段に記憶するファイルを種別毎に記憶する外部記憶手段と、（３）少なくとも、サーバのシステム障害の態様に応じて取得するバックアップファイルの種別を取り決めた第１の情報を管理する情報管理手段と、（４）サーバにおいて自サーバによるリストアが困難である障害が発生した場合に、サーバの障害回復後、第１の情報に従ったリストア要求を送出するバックアップ制御手段と、（５）バックアップ制御手段からリストア要求を受け取り、このリストア要求で指定されている種別のファイルを外部記憶手段から取得し、サーバに転送する外部バックアップ制御手段とを備えることを特徴とする。

本発明によれば、自サーバのハードディスクが故障した場合や、待機系サーバが保持するバックアップデータに不具合が生じた場合でも、システムの停止時間をできるだけ短くして、確実に復旧することができる。

第１の実施形態のバックアップ制御システムの構成を示す構成図である。 バックアップデータ取得情報の構成を説明する説明図である。 バックアップ処理を示すフローチャートである。 バックアップ処理を説明する説明図である。 アプリケーションサーバのバックアップ制御による処理を示すフローチャートである。 アプリケーションサーバのバックアップ制御の処理を説明する説明図である。 バックアップサーバのバックアップ制御による処理を示すフローチャートである。 バックアップサーバのバックアップ制御の処理を説明する説明図である。 バックアップサーバが複数世代の前日ファイル、立ち上げ保障ファイルをバックアップする場合を示す構成図である。 バックアップサーバが外部ディスク又は専用サーバと接続する場合を示す構成図である。

（Ａ）主たる実施形態
以下では、本発明の復旧システム、復旧方法及びバックアップ制御システムの第１の実施形態を、図面を参照しながら説明する。この実施形態は、例えばＩＰ電話サービスを提供するコールサーバのような、非常に高い信頼性を求められるサーバに適用した場合を例示して説明する。

（Ａ−１）実施形態の構成
図１は、実施形態に係るバックアップ制御システムの構成を示す構成図である。図１において、第１の実施形態のバックアップ制御システム１は、アプリケーションサーバ１０と、このアプリケーションサーバ１０とは別に外部に設けたバックアップサーバ２０とを有して構成される。

なお、アプリケーションサーバ１０及びバックアップサーバ２０は、接続回線で接続されており、いずれもＣＰＵ、ＲＯＭ、ＲＡＭなどを備え、後述するＯＳやバックアップ制御部の処理は、ハードウェア的にはＣＰＵが実行するものである。

アプリケーションサーバ１０は、例えばコールサーバ等の高信頼性を求められるサーバが該当する。図１に示すように、アプリケーションサーバ１０は、アプリケーション１１、バックアップ制御部１２、オペレーティングシステム（ＯＳ）１３、ハードディスク１４等を少なくとも有するものである。

アプリケーションサーバ１０は、例えばＬｉｎｕｘ（登録商標）等の一般的なＯＳ１３を搭載しており、このＯＳ１３上で、アプリケーション１１やバックアップ制御部１２の処理が動作する。

アプリケーション１１は、アプリケーションサーバ１０が提供するサービスプロセス（例えば、呼処理サービス等）に係る処理を実行するものであり、運用中にはハードディスク１４上の実行ファイルを参照して実行したり、実行ファイルの更新をしたりするものである。

ハードディスク１４は、ＯＳ１３やアプリケーション１１のプログラム、アプリケーションの実行ファイル、及び、バックアップデータ取得情報１７などを格納する記憶領域である。また、ハードディスク１４は、バックアップデータを種別毎に分類して格納するものである。

このバックアップデータの種別としては、例えば、前日ファイル１５、立ち上げ保障ファイル１６、フルバックアップファイルがあり、これらファイルを種別毎に分類する。

前日ファイル１５には、例えば、毎日所定の時刻に、運用に利用されたファイルが格納される。これにより、現在の運用中の一世代前のファイルを格納することができる。また、立ち上げ保障ファイル１６は、アプリケーション１１のアップグレード後、新ファイルの起動時を保障するファイルが格納される。バックアップデータとは、アプリケーション１１の実行ファイル、コンフィグファイル、各種データなどが含まれるものである。

バックアップ制御部１２は、ＯＳ１３又はアプリケーション１１からのコマンドにより起動するものである。また、バックアップ制御部１２は、アプリケーションサーバ１０の起動後、各バックアップデータをバックアップする場合、バックアップデータの種別毎に分類してバックアップするものである。さらに、バックアップ制御部１２は、バックアップデータの格納先を、自サーバ１０のハードディスク１４、バックアップサーバ２０のハードディスク２３とする。

また、バックアップ制御部１２は、定期処理スレッドと、バックアップ制御スレッドとを有する。

定期処理スレッドは、アプリケーションサーバ１０の起動後に、毎日所定時刻になると、その日の運用中の実行ファイルを、ハードディスク１４の前日ファイル１５にバックアップするものである。

バックアップ制御スレッドは、後述するように、各バックアップファイルを自サーバ１０のハードディスク１４にバックアップする処理、各バックアップファイルを外部のバックアップサーバ２０に転送してバックアップするバックアップ処理とを行う。

さらに、バックアップ制御スレッドは、障害発生時に、リストアコマンドを受け取り、このコマンドで指定された種類のファイルを、指定された取得先から取得し、リストア処理を行う。

バックアップ制御スレッドは、アプリケーションアップグレード時に、アップグレードするアプリケーションの立ち上げ保障ファイルを、ハードディスク１４の立ち上げ保障ファイル１６にバックアップするものである。

また、バックアップ制御スレッドは、前日ファイル１５や立ち上げ保障ファイル１６の転送要求のコマンドが与えられると、ハードディスク１４に格納されている前日ファイル１５や立ち上げ保障ファイル１６を、バックアップサーバ２０に転送してバックアップサーバ２０のハードディスク２３にバックアップするものである。

さらに、バックアップ制御スレッドは、フルバックアップファイルの転送要求のコマンドが与えられると、ハードディスク１４から自サーバのフルバックアップファイルを取得し、そのフルバックアップファイルをバックアップサーバ２０に転送してハードディスク２３にバックアップするものである。

バックアップ制御スレッドがリストアを実施する場合、バックアップファイル取得契機となる障害発生時に、その障害態様に応じてバックアップデータの種別や取得先を指定したコマンドを受け取り、このコマンドの内容に従ってバックアップデータを取得する。バックアップデータを取得する先としては、後述するように、自サーバ１０のハードディスク１４又はバックアップサーバ２０のハードディスク２３とする。また、取得するバックアップデータの種別としては、前日ファイル、立ち上げ保障ファイル、フルバックアップファイル等がある。

コマンドでのバックアップデータの種別や取得先の指定は、バックアップデータ取得情報１７を参照して指定する方法を適用することができる。

図２は、バックアップデータ取得情報１７の構成を示す構成図である。バックアップデータ取得情報１７は、バックアップデータ種別、バックアップ取得先、障害種別、コマンド要求先とが対応づけられて設定されている。

例えば、アプリケーションサーバ１０のハードディスク１４が故障した場合、図２に示すように、取得するバックアップデータの種別を「フルバックアップファイル」とし、このバックアップデータの取得先を「バックアップサーバ２０のハードディスク２３」とする要求コマンドを、「バックアップサーバ２０のバックアップ制御部２２」を要求先として送信するようにする、ということを示す。

バックアップサーバ２０は、アプリケーションサーバ１０のアプリケーション１１が実行する実行ファイルをバックアップするサーバである。バックアップサーバ２０は、バックアップ制御部２１、ＯＳ２２、ハードディスク２３を少なくとも有するものである。

バックアップサーバ２０１は、バックアップ対象サーバごとのバックアップデータを、その種別毎に分類して格納する。また、バックアップサーバ２０は、１台のバックアップ対象サーバだけでなく、複数のバックアップ対象サーバのバックアップデータを格納するようにしてもよい。

バックアップサーバ２０は、例えば、Ｌｉｎｕｘ（登録商標）等の一般的なＯＳ２２を搭載しており、バックアップ制御部２１は、ＯＳ２２上で動作するものであり、運用中はハードディスク２３のデータを参照したり更新したりする。

なお、バックアップサーバ２０のハードディスク２３へのバックアップは、上述したようにアプリケーションサーバ１０のバックアップ制御部１２の処理により実現される。

バックアップ制御部２１は、アプリケーションサーバ１０のハードディスク１４の故障や、アプリケーションサーバ１０自体の故障の場合に、アプリケーションサーバ１０やハードディスク１４の故障回復後に、コマンドを受け取り、ハードディスク２３に格納されているバックアップデータを、アプリケーションサーバ１０に与えるものである。これにより、アプリケーションサーバ１０において、ＯＳやアプリケーションのプログラムを再インストールさせ、必要なファイルデータを用いてリストアさせることができる。

ここで、要求コマンドは、取得するバックアップデータの種別が記載されており、これに従って、バックアップ制御部２１は、前日ファイル２４、立ち上がり保障ファイル２５、フルバックアップファイル２６のいずれかを選択して、アプリケーションサーバ１０に転送する。

（Ａ−２）実施形態の動作
次に、この実施形態に係るバックアップ制御システムの処理の動作を、図面を参照しながら説明する。

（Ａ−２−１）バックアップ処理
まず、実施形態に係るバックアップ処理の動作を説明する。図３は、実施形態のバックアップ処理の動作を示すフローチャートである。図４は、実施形態のバックアップ処理の動作を説明する説明図である。

アプリケーションサーバ１０が起動すると、バックアップ制御部１２は、所定の時刻に定期処理スレッドを起動する。また、バックアップ制御部１２は、ＯＳ１３又はアプリケーション１１からコマンドを受信すると、そのコマンド要求に応じた処理を行うバックアップ制御スレッドを起動する（ステップＳ１０１）。

定期処理スレッドは、毎日所定の時刻に起動し、アプリケーション１１が実行に必要な実行ファイルをバックアップデータとして取得し、ハードディスク１４の前日ファイル１５に格納する（ステップＳ１０２）。

また、バックアップ制御スレッドは、ＯＳ１３又はアプリケーション１１からのコマンド要求を受信すると起動する（ステップＳ１０３）。

このとき、アプリケーション１１のプログラムをアップグレードした際に、アプリケーション１１が立ち上げ保障ファイルをバックアップ取得要求するコマンドをバックアップ制御部１２に与える。これを受信したバックアップ制御スレッドは、アップグレードのアプリケーションの起動保障行う立ち上げ保障ファイルをバックアップファイルとして取得し、ハードディスク１４の立ち上げ保障ファイル１６に格納する（ステップＳ１０４）。

また、コマンド投入により、前日ファイルバックアップサーバ転送要求を受信すると、バックアップ制御スレッドは、ハードディスク１４に保持されている前日ファイル１５をバックアップサーバ２０に転送する（ステップＳ１０５）。このとき、バックアップサーバ２０は、アプリケーションサーバ１０から受け取った前日ファイルをハードディスク２３の前日ファイル２４に格納する。

ここで、前日ファイルバックアップサーバ転送要求のコマンド投入は、例えば、ハードディスク１４に前日ファイル１５が格納された直後や、前日コマンド１５の取得終了後の所定時間経過後や毎日の所定時刻等とすることができる。

さらに、コマンド投入により、立ち上げ保障ファイルバックアップサーバ転送要求を受信すると、バックアップ制御スレッドは、ハードディスク１４に保持されている立ち上げ保障ファイル１６を、バックアップサーバ２０に転送する（ステップＳ１０６）。このとき、バックアップサーバ２０は、アプリケーションサーバ１０から受け取った立ち上げ保障ファイルをハードディスク２３の立ち上げ保障ファイル２５に格納する。

ここで、立ち上げ保障ファイルバックアップサーバ転送要求のコマンド投入は、ハードディスク１４に立ち上げ保障ファイル１６が格納された直後や、立ち上げ保障ファイル１６の取得終了後の所定時間経過後等とすることができる。

また、コマンド投入により、フルバックアップファイル取得・転送要求を受信すると、バックアップ制御スレッドは、ハードディスク１４に保持されている自サーバのフルバックアップを取得し、このフルバックアップファイルをバックアップサーバ２０に転送する（ステップＳ１０７）。そして、バックアップサーバ２０は、このフルバックアップファイルを、ハードディスク２３のフルバックアップファイル２６に格納する。

フルバックアップファイル取得・転送要求のコマンド投入は、例えば、前日ファイル１５又は立ち上げ保障ファイル１６のいずれかの格納直後としたり、これらの格納後所定時間経過後等とすることができる。

また、フルバックアップファイルは、前日ファイル１５をバックアップする際に、これを増分ファイルとして、それまでのフルバックアップファイルと合成していくようにしても良い。最初のフルバックアップファイル（第１日目）に、第２日目の増分ファイルを合成する。さらに、この合成したフルバックファイルに第３日目の増分ファイルを合成していくことでフルバックファイルを作成する。

上記のようにして、自サーバ１０及びバックアップサーバ２０に、前日ファイル、立ち上げ保障ファイル、フルバックアップファイルをバックアップデータとして保持させることができる。

（Ａ−２−２）バックアップ制御部１２によるリストア処理
次に、アプリケーションサーバ１０のバックアップ制御部１２によるリストア処理の動作を、図面を参照しながら説明する。

図５は、実施形態に係るリストア処理を示すフローチャートである。図６は、実施形態に係るリストア処理を説明する説明図である。

リストア処理は、ＯＳ１２又はアプリケーション１１からリストアコマンドを受信することにより、バックアップ制御部１２のバックアップ制御スレッドが実施する。

アプリケーションサーバ１０において障害が発生すると、ＯＳ１３はシャットダウン処理を開始する。このシャットダウン処理の中で、ＯＳ１３がバックアップデータの取得先及び取得種別を指定するリストアコマンドをバックアップ制御部１２に与え、バックアップ制御スレッドが起動する。なお、アプリケーション１１がリストアコマンドを投入することでバックアップ制御スレッドが起動するようにしても良い。

リストアコマンドを投入する際、発生した障害に応じたバックアップデータの種別及び取得先を指定するものとする。

ここで、バックアップデータの種別及び取得先の指定方法は、例えば、図２に示すように発生した障害態様に応じて、取得するバックアップデータの種別及び取得先が設定されているバックアップデータ取得情報１７を参照して指定する方法を適用することができる。

なお、図２のバックアップデータ取得情報１７では、説明便宜のために、バックアップデータ取得先が「アプリケーションサーバ」、「バックアップサーバ」のように記載しているが、取得先サーバのアドレス情報やリンク先等を記載するようにしても良い。

また、バックアップデータ種別についても、その種別を識別する識別情報や、ハードディスク１４及び２３におけるバックアップデータの格納先（リンク先）情報等としても良い。このように、コマンドに取得するバックアップデータの取得先及び種別を含ませることで、迅速なリストア処理を実現できる。

例えば、図２に示すように、アプリケーション１１にバグ等による障害が生じた場合には、アプリケーションサーバ１０のバックアップ制御部１２にコマンドが投じられる。

コマンド受信待ちをしているバックアップ制御スレッドが、リストアコマンドを受信すると（ステップＳ２０１）、そのコマンドで指定されているバックアップデータの取得先及び種別を確認する（ステップＳ２０２）。

バックアップデータ取得先が自サーバである場合（ステップＳ２０３）、バックアップ制御スレッドは、自サーバ１０のハードディスク１４から、コマンドで指定されたバックアップデータ（前日ファイル１５、立ち上げ保障ファイル１６）をロードする。そして、ＯＳ１３のリブート後、アプリケーション１１が自律的に起動し、指定されたバックアップデータを読み込むことでリストアを行う（ステップＳ２０４）。

また、バックアップデータ取得先がバックアップサーバ２０である場合（ステップＳ２０３）、バックアップ制御スレッドは、バックアップサーバ２０のハードディスク２３から、コマンドで指定されたバックアップデータ（前日ファイル２４、立ち上げ保障ファイル２５、フルバックアップファイル２６）を取得してロードする。そして、起動したアプリケーション１１がバックアップデータを読み込むことでリストアを行う（ステップＳ２０５）。

（Ａ−２−３）バックアップ制御部２１によるリストア処理
次に、バックアップサーバ２０のバックアップ制御部２１によるリストア処理の動作を、図面を参照しながら説明する。

図７は、バックアップサーバ２０のバックアップ制御部２１によるリストア処理を示すフローチャートである。図８は、バックアップサーバ２０のバックアップ制御部２１によるリストア処理を説明する説明図である。

図２に示すように、アプリケーションサーバ１０のハードディスク１４が故障した場合や、アプリケーションサーバ１０本体が故障した場合には、バックアップサーバ２０のバックアップ制御部２１にコマンドが投じられる。

例えば、アプリケーションサーバ１０において障害が発生し、０Ｓ１３がシャットダウン処理を開始する。その後、アプリケーションサーバ１０のハードディスク１４の故障又はアプリケーションサーバ１０本体の故障を回復する。

そして、故障回復後に、バックアップサーバ２０のバックアップ制御部２１に対してコマンドが投入される。このコマンド投入は、アプリケーションサーバ１０の故障回復後のリストア処理の一部の処理として自動的に投入されるようにしても良いし、また図示しない管理者端末の指示を受けて投入されるようにしても良い。

バックアップ制御部２１では、コマンド投入により、バックアップ制御スレッドが起動する（ステップＳ３０１）。バックアップ制御スレッドは、コマンドで指定されるバックアップデータを取得先及び種別を確認する（ステップＳ３０２）。

ここでは、取得するバックアップデータとしてフルバックアップファイル２６が指定されている。バックアップ制御スレッドは、コマンドで指定されているリンク先に基づき、ハードディスク２３から指定されたフルバックアップファイル２６を読み出し、アプリケーションサーバ１０のハードディスク１４に転送する（ステップＳ３０３）。

このフルバックアップファイル２６には、ＯＳやアプリケーションプログラムも含まれているので、アプリケーションサーバ１０は、バックアップサーバ１０から受信したフルバックアップファイル２６を用いて再開処理を行い、サーバ環境のリストアを実施する。これにより、ＯＳやアプリケーションプログラムをインストールする作業を軽減することができるので、迅速な対応が取れる。

次に、アプリケーションサーバ１０において、自サーバ１０のハードディスク１４のフルバックアップファイルからリストアした後、アプリケーションサーバのアプリケーションが古いファイルである場合の処理、図７（Ｂ）及び図８を参照して説明する。

なお、この場合、アプリケーションサーバ１０がフルバックアップファイルをバックアップする時と、バックアップサーバ２０が前日ファイル２４、立ち上げ保障ファイル２５をバックアップする時とが異なる場合（バックアップ取得タイミングが異なる場合）を想定する。

アプリケーションサーバ１０において、ハードディスク１４のフルバックアップファイルからリストアした後、アプリケーションサーバ１０のアプリケーションが古いファイルである場合、アプリケーションサーバ１０のバックアップ制御部１２にコマンドが投入される（ステップＳ４０１）。

このコマンドには、バックアップデータの取得先がバックアップサーバ１０のバードディスク２３であり、バックアップデータの種別が前日ファイル２４又は立ち上げ保障ファイル２５であることが指定されている（図２参照）。

アプリケーションサーバ１０において、バックアップ制御スレッドは、コマンドで指定されているバックアップデータの取得先及び種別を確認し（ステップＳ４０２）、バックアップサーバ２０に対して、コマンドで指定されバックアップデータ取得先及び種別の転送を要求する。

バックアップサーバ１０では、バックアップ制御部２１がバックアップ制御スレッドを起動し、投入されたコマンドで指定されているバックアップデータ種別である前日ファイル２４又は立ち上げ保障ファイル２５を、アプリケーションサーバ１０に転送する。アプリケーションサーバ１０は、バックアップサーバ１０から受信した前日ファイル２４又は立ち上げ保障ファイル２５を用いて、最新ファイルによる再開処理を行い、サーバ環境のリストアを実施する（ステップＳ４０３）。

（Ａ−３）実施形態の効果
以上のように、実施形態によれば、サーバのハードディスクの故障時やサーバ本体の故障時でも、バックアップサーバによるリストア処理が可能である。またサーバが冗長化等により複数存在している場合でも、バックアップサーバによるリストア処理ができる。

実施形態では、バックアップデータを外部のバックアップサーバに退避させ、バックアップするバックアップデータを種別毎に分類してバックアップし、バックアップデータの取得契機とバックアップデータの取得先を明確にしておく。これにより、バックアップデータの取得契機に、どの種別のバックアップデータをどの取得先から読み込むかを明確にすることができるので、迅速かつ早期なリストアを実現できる。

さらに、実施形態では、自サーバや冗長化の待機系サーバが故障した場合のリストア時に、バックアップサーバに退避しているバックアップデータにより、確実・迅速に対応することが可能となる。

（Ｂ）他の実施形態
上述した実施形態では、説明便宜上、バックアップサーバのハードディスク内に、前日ファイルと立ち上げ保障ファイルは、１世代しか保持していない場合を説明したが、例えば図９に示すように、バックアップサーバ２０が、複数世代の前日ファイルと立ち上げ保障ファイルを管理するようにしてもよい。

上述した実施形態では、バックアップサーバ自体がアプリケーションを搭載しない場合を例示したが、アプリケーションを搭載して、そのデータ・プログラムがバックアップ取得要とした場合でも、アプリケーションサーバのバックアップ制御部と同様、バックアップサーバのバックアップ制御部にてバックアップ・リストアが可能である。

さらに、例えば図１０に示すように、バックアップサーバ自体のバックアップ媒体（例えばハードディスクや光ディスクやバックアップ用テープ等）やサーバ（バックアップサーバ用のバックアップサーバ）を設けることで、バックアップサーバ自体のバックアップ・リストアが可能である。

冗長構成をとる場合、１台の現用系サーバに対してバックアップサーバを備え、また１台の予備系サーバに対して別のバックアップサーバを備えるようにしても良い。また、現用系サーバと予備系サーバとが、バックアップサーバを共用するようにしても良い。

１…バックアップ制御システム、
１０…アプリケーションサーバ、２０…バックアップサーバ
１１…アプリケーション、１２…バックアップ制御部、１３…ＯＳ、１４…ハードディスク、１５…前日ファイル、１６…立ち上げ保障ファイル、１７…バックアップデータ取得情報、
２１…バックアップ制御部、２２…ＯＳ、２３…ハードディスク、２４…前日ファイル、２５…立ち上げ保障ファイル、２６…フルバックアップファイル。

Claims (4)

1. サーバが利用するファイルを種別毎に分類して記憶するローカル記憶手段と、
   上記ローカル記憶手段に記憶するファイルを種別毎に記憶する外部記憶手段と、
   少なくとも、上記サーバのシステム障害の態様に応じて取得するバックアップファイルの種別を取り決めた第１の情報を管理する情報管理手段と、
   上記サーバにおいて自サーバによるリストアが困難である障害が発生した場合に、上記サーバの障害回復後、上記第１の情報に従ったリストア要求を送出するバックアップ制御手段と、
   上記バックアップ制御手段から上記リストア要求を受け取り、このリストア要求で指定されている種別のファイルを上記外部記憶手段から取得し、上記サーバに転送する外部バックアップ制御手段と
   を備え、
   上記サーバが、上記外部バックアップ制御手段から取得したファイルを用いてリストアするリストア手段を有することを特徴とする復旧システム。
2. 上記外部バックアップ制御手段は、上記サーバにおけるフルバックアップファイルのリストアの結果、アプリケーションが過去のファイルである場合、上記第１の情報に従ったリストア要求を受け取り、このリストア要求で指定されている種別のファイルを上記外部記憶手段から取得し、上記サーバに転送することを特徴とする請求項１に記載の復旧システム。
3. ローカル記憶手段が、サーバが利用するファイルを種別毎に分類して記憶するローカル記憶工程と、
   外部記憶手段が、上記ローカル記憶手段に記憶するファイルを種別毎に記憶する外部記憶工程と、
   情報管理手段が、少なくとも、上記サーバのシステム障害の態様に応じて取得するバックアップファイルの種別を取り決めた第１の情報を管理する情報管理工程と、
   バックアップ制御手段が、上記サーバにおいて自サーバによるリストアが困難である障害が発生した場合に、上記サーバの障害回復後、上記第１の情報に従ったリストア要求を送出するバックアップ制御工程と、
   外部バックアップ制御手段が、上記バックアップ制御手段から上記リストア要求を受け取り、このリストア要求で指定されている種別のファイルを上記外部記憶手段から取得し、上記サーバに転送する外部バックアップ制御工程と
   を有し、
   上記サーバが、上記外部バックアップ制御手段から取得したファイルを用いてリストアするリストア工程を有することを特徴とする復旧方法。
4. サーバが利用するファイルを種別毎に分類して記憶するローカル記憶手段と、
   上記ローカル記憶手段に記憶するファイルを種別毎に記憶する外部記憶手段と、
   少なくとも、上記サーバのシステム障害の態様に応じて取得するバックアップファイルの種別を取り決めた第１の情報を管理する情報管理手段と、
   上記サーバにおいて自サーバによるリストアが困難である障害が発生した場合に、上記サーバの障害回復後、上記第１の情報に従ったリストア要求を送出するバックアップ制御手段と、
   上記バックアップ制御手段から上記リストア要求を受け取り、このリストア要求で指定されている種別のファイルを上記外部記憶手段から取得し、上記サーバに転送する外部バックアップ制御手段と
   を備えることを特徴とするバックアップ制御システム。

Images