(57)【要約】【課題】復元によりソフトウェアやハードウェアの動作に不具合が発生する可能性を減らすこと。【解決手段】記憶部１１は、整合性を確認済であるソフトウェアのバージョンとファームウェアのバージョンとの組合せの情報を記憶する。処理部１２は、情報処理装置２０の動作環境を復旧する際に、情報処理装置２０におけるソフトウェアの復元先のバージョンと情報処理装置２０のハードウェア２３に対応するファームウェアの現在のバージョンとの組合せを確認する。処理部１２は、記憶部１１に記憶された情報に基づいて、当該ソフトウェアの復元先のバージョンおよび当該ファームウェアの現在のバージョンの少なくとも１つの変更の要否を判定し、変更要と判定すると変更のための組合せを特定する。【選択図】図１
2019020798.tif 000002
【特許請求の範囲】
【請求項１】
整合性を確認済であるソフトウェアのバージョンとファームウェアのバージョンとの組合せの情報を記憶する記憶部と、
対象装置の動作環境を復旧する際に、前記対象装置における前記ソフトウェアの復元先のバージョンと前記対象装置のハードウェアに対応する前記ファームウェアの現在のバージョンとの組合せを確認し、前記記憶部に記憶された前記情報に基づいて、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンの少なくとも１つの変更の要否を判定し、変更要と判定すると前記変更のための組合せを特定する処理部と、
を有する情報処理装置。
【請求項２】
前記処理部は、指定されたポリシーに応じて、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンのうち、変更対象を決定する、請求項１記載の情報処理装置。
【請求項３】
前記処理部は、前記ソフトウェアの復元先のバージョンを変更対象に決定すると、前記ファームウェアの現在のバージョンに対して整合性を確認済である前記ソフトウェアのバージョンのうち、最新のバージョンまたは復元先のバージョンとの差が最小のバージョンを、変更後のバージョンとして特定する、請求項１または２記載の情報処理装置。
【請求項４】
前記処理部は、前記ファームウェアの現在のバージョンを変更対象に決定すると、前記ソフトウェアの復元先のバージョンに対して整合性を確認済である前記ファームウェアのバージョンのうち、最新のバージョンまたは現在のバージョンとの差が最小のバージョンを、変更後のバージョンとして特定する、請求項１または２記載の情報処理装置。
【請求項５】
前記処理部は、変更後のバージョンの候補のうち、適用後の前記対象装置の再起動が不要である候補がある場合、前記再起動が不要である前記候補の中から、変更後のバージョンを特定する、請求項３または４記載の情報処理装置。
【請求項６】
前記ファームウェアは、複数であり、
前記処理部は、前記記憶部に記憶された前記情報に基づいて、複数の前記ファームウェアそれぞれの現在のバージョンに対して整合性を確認済である前記ソフトウェアのバージョン範囲を特定し、前記ソフトウェアの復元後のバージョンが前記バージョン範囲に属するか否かに応じて、前記変更の要否を判定する、
請求項１乃至５の何れか１項に記載の情報処理装置。
【請求項７】
前記処理部は、前記記憶部に記憶された前記情報に基づいて、前記ファームウェアの現在のバージョンおよび前記対象装置における他のソフトウェアの現在のバージョンに対して整合性を確認済である前記ソフトウェアのバージョン範囲を特定し、前記ソフトウェアの復元後のバージョンが前記バージョン範囲に属するか否かに応じて、前記変更の要否を判定する、請求項１乃至５の何れか１項に記載の情報処理装置。
【請求項８】
対象装置の動作環境を復旧する際に、前記対象装置におけるソフトウェアの復元先のバージョンと前記対象装置におけるハードウェアに対応するファームウェアの現在のバージョンとの組合せを確認し、
整合性を確認済である前記ソフトウェアのバージョンと前記ファームウェアのバージョンとの組合せの情報に基づいて、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンの少なくとも１つの変更の要否を判定し、変更要と判定すると前記変更のための組合せを特定する、
処理をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置およびプログラムに関する。
【背景技術】
【０００２】
コンピュータなどの装置には様々なソフトウェアがインストールされる。そこで、ソフトウェアの導入を支援する方法が考えられている。
例えば、クライアント端末にプリンタドライバを導入する際に、プリンタのファームウェアを当該プリンタドライバに対して動作保証されたファームウェアに更新する印刷システムの提案がある。
【０００３】
また、電子機器のファームウェアが新たなファームウェアに更新されると、新たなファームウェアのバージョンと整合性を有するソフトウェアのバージョンを検出し、当該バージョンのソフトウェアを自装置にインストールする情報処理装置の提案もある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−２３０４００号公報
【特許文献２】特開２０１４−１９１７９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
情報処理システムの運用では、ある装置に対してインストールされたソフトウェア（例えば、オペレーティングシステム、ミドルウェア、および、それらの設定データなど）のバックアップを行うことがある。バックアップにより取得されたバックアップデータにより、該当の装置のソフトウェアの環境をバックアップ時点の状態に復元可能である。
【０００６】
一方、ソフトウェアとハードウェアとは綿密に連携していることが少なくない。ハードウェアの動作はファームウェアにより制御される。ファームウェアは、機能追加や改善のためにアップデートされることがある。このため、例えば、ソフトウェアのバージョンのみをバックアップ時点の状態に復元しても、ファームウェアのバージョンと復元後のソフトウェアのバージョンとに不整合が生じることがある。両者に不整合があると、ファームウェアと復元後のソフトウェアとが適切に連携できず、ソフトウェアやハードウェアの動作に不具合が発生することがある。
【０００７】
１つの側面では、本発明は、復元によりソフトウェアやハードウェアの動作に不具合が発生する可能性を減らすことを目的とする。
【課題を解決するための手段】
【０００８】
１つの態様では、情報処理装置が提供される。情報処理装置は、記憶部と処理部とを有する。記憶部は、整合性を確認済であるソフトウェアのバージョンとファームウェアのバージョンとの組合せの情報を記憶する。処理部は、対象装置の動作環境を復旧する際に、対象装置におけるソフトウェアの復元先のバージョンと対象装置のハードウェアに対応するファームウェアの現在のバージョンとの組合せを確認し、記憶部に記憶された情報に基づいて、ソフトウェアの復元先のバージョンおよびファームウェアの現在のバージョンの少なくとも１つの変更の要否を判定し、変更要と判定すると変更のための組合せを特定する。
【発明の効果】
【０００９】
１つの側面では、復元によりソフトウェアやハードウェアの動作に不具合が発生する可能性を減らすことができる。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態の情報処理装置を示す図である。
【図２】バージョンの組合せの他の特定例を示す図である。
【図３】第２の実施の形態の情報処理システムを示す図である。
【図４】管理サーバのハードウェア例を示す図である。
【図５】管理対象のソフトウェアおよびファームウェアの例を示す図である。
【図６】管理サーバの機能例を示す図である。
【図７】変更履歴テーブルの例を示す図である。
【図８】バックアップ管理テーブルの例を示す図である。
【図９】依存関係テーブルの第１の例を示す図である。
【図１０】依存関係テーブルの第２の例を示す図である。
【図１１】依存関係管理情報の例を示す図である。
【図１２】依存関係管理情報の第１の具体例を示す図である。
【図１３】依存関係管理情報の第２の具体例を示す図である。
【図１４】依存関係管理情報の第３の具体例を示す図である。
【図１５】ポリシー情報の例を示す図である。
【図１６】再起動テーブルの例を示す図である。
【図１７】管理サーバの処理例を示すフローチャートである。
【図１８】バージョン選択処理例（その１）を示すフローチャートである。
【図１９】バージョン選択処理例（その２）を示すフローチャートである。
【図２０】バージョン選択処理例（その３）を示すフローチャートである。
【図２１】バージョン選択処理例（その４）を示すフローチャートである。
【図２２】依存関係管理情報の時系列に応じた変化例を示す図である。
【図２３】バージョン選択の具体例を示す図である。
【図２４】警告表示例（その１）を示す図である。
【図２５】警告表示例（その２）を示す図である。
【発明を実施するための形態】
【００１１】
以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。第１の実施の形態の情報処理システムは、情報処理装置１０，２０を含む。情報処理装置１０，２０は、ネットワークＮ１に接続されている。情報処理装置２０は、外部ハードウェア３０と接続されている。外部ハードウェア３０は、例えば、ディスクアレイやテープライブラリなどのストレージ装置やパケットを中継するスイッチなどの中継装置である。外部ハードウェア３０は、ネットワークＮ１に接続されている。
【００１２】
情報処理装置１０は、記憶部１１および処理部１２を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１２は、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１２はプログラムを実行するプロセッサでもよい。「プロセッサ」は、複数のプロセッサの集合（マルチプロセッサ）も含み得る。
【００１３】
情報処理装置２０は、メモリ２１、プロセッサ２２およびハードウェア２３を有する。メモリ２１は、不揮発性メモリおよび揮発性メモリを含む。メモリ２１は、ソフトウェアＸのプログラムを記憶する。プロセッサ２２は、メモリ２１に記憶されたソフトウェアＸのプログラムを実行する。ソフトウェアＸは、例えば、オペレーティングシステム（ＯＳ：Operating System）やミドルウェアなどである。ソフトウェアＸは、業務処理などに用いられるアプリケーションでもよい。ハードウェア２３は、情報処理装置２０の内蔵デバイスであり、例えば、ＮＩＣ（Network Interface Card）やストレージにアクセスするためのＲＡＩＤ（Redundant Arrays of Inexpensive Disks）カードなどである。
【００１４】
ハードウェア２３は、メモリ２３ａおよびプロセッサ２３ｂを有する。メモリ２３ａは、不揮発性メモリおよび揮発性メモリを含む。メモリ２３ａは、ファームウェアＹのプログラムを記憶する。プロセッサ２３ｂは、メモリ２３ａに記憶されたファームウェアＹを実行し、ファームウェアＹの機能により、ハードウェア２３の動作を制御する。プロセッサ２３ｂは、ファームウェアＹの機能によりソフトウェアＸと連携する。
【００１５】
外部ハードウェア３０は、メモリ３１およびプロセッサ３２を有する。メモリ３１は、不揮発性メモリおよび揮発性メモリを含む。メモリ３１は、ファームウェアＺのプログラムを記憶する。プロセッサ３２は、メモリ３１に記憶されたファームウェアＺのプログラムを実行し、ファームウェアＺの機能により、外部ハードウェア３０の動作を制御する。プロセッサ３２は、ファームウェアＺの機能によりソフトウェアＸと連携する。
【００１６】
例えば、ソフトウェアＸは、ファームウェアＹ，Ｚと連携することで、ハードウェア２３や外部ハードウェア３０の起動、停止および稼働情報の収集などを行う。
情報処理装置１０は、情報処理装置２０におけるソフトウェアＸのバージョンおよびファームウェアＹのバージョンを管理する。また、情報処理装置１０は、外部ハードウェア３０におけるファームウェアＺのバージョンを管理する。ここで、ソフトウェアＸのバージョンをバージョンｖ１と表す。ファームウェアＹのバージョンをバージョンｖ２と表す。ファームウェアＺのバージョンをバージョンｖ３と表す。
【００１７】
具体的には、記憶部１１は、バージョン管理テーブルＴ１を記憶する。バージョン管理テーブルＴ１は、ソフトウェアＸおよびファームウェアＹ，Ｚについて、整合性を確認済であるバージョンの組合せの情報を記憶する。
【００１８】
例えば、バージョン管理テーブルＴ１は、ソフトウェアＸのバージョンｖ１＝１に対して、ファームウェアＹの整合性を確認済であるバージョンｖ２の範囲１≦ｖ２≦３を示す情報を含む。これは、ソフトウェアＸのバージョンｖ１＝１に対して、ファームウェアＹのバージョンｖ２が１≦ｖ２≦３を満たす（ｖ１，ｖ２）の組合せが整合性を確認済であり、当該組合せであれば、ソフトウェアＸとハードウェア２３とが適切に連携可能であることを示す。
【００１９】
同様に、バージョン管理テーブルＴ１は、ソフトウェアＸのバージョンｖ１＝１に対して、ファームウェアＺの整合性を確認済であるバージョンｖ３の範囲１≦ｖ３≦２を示す情報を含む。これは、ソフトウェアＸのバージョンｖ１＝１に対して、ファームウェアＺのバージョンｖ３が１≦ｖ３≦２を満たす（ｖ１，ｖ３）の組合せが整合性を確認済であり、当該組合せであれば、ソフトウェアＸとハードウェア２３とが適切に連携可能であることを示す。
【００２０】
また、同様に、バージョン管理テーブルＴ１は、ｖ１＝２に対して、範囲１≦ｖ２≦４および範囲２≦ｖ３≦４を示すレコードを含む。更に、バージョン管理テーブルＴ１は、ｖ１＝３に対して、範囲２≦ｖ２≦５および範囲３≦ｖ３≦５を示すレコードを含む。
【００２１】
ここで、現時点において、バージョンｖ１＝３、バージョンｖ２＝４、バージョンｖ３＝４であるとする。
処理部１２は、情報処理装置２０の動作環境を復旧する際に、情報処理装置２０におけるソフトウェアＸの復元先のバージョンと情報処理装置２０のハードウェア２３に対応するファームウェアＹの現在のバージョンとの組合せを確認する。この場合、情報処理装置２０は、動作環境の復旧（または復元）の対象装置であるといえる。
【００２２】
処理部１２は、記憶部１１に記憶されたバージョン管理テーブルＴ１に基づいてソフトウェアＸの復元先のバージョンおよびファームウェアＹの現在のバージョンの少なくとも１つの変更の要否を判定する。処理部１２は、変更要と判定すると変更のための組合せを特定する。変更のための組合せは、ソフトウェアＸの復元先のバージョンとファームウェアＹの現在のバージョンとの不整合を回避するソフトウェアＸのバージョンおよびファームウェアＹのバージョンの組合せを示す。
【００２３】
ここで、動作環境の復旧処理は、情報処理装置２０において予め取得されたソフトウェアＸのバックアップデータを用いて行われる。動作環境の復旧処理自体では、ソフトウェアＸが復旧の対象となり、ファームウェアＹ，Ｚは復旧の対象ではない。
【００２４】
例えば、処理部１２は、ユーザによる動作環境の復旧指示Ｒ１を受け付けると、動作環境の復旧を開始する。復旧指示Ｒ１は、ソフトウェアＸの復元先のバージョンｖ１を１とする旨の指示を含む。あるいは、処理部１２は、復旧先の時刻または時刻に関連付けられた情報（例えば、リストア対象のバックアップデータの識別情報）を含む復旧指示を受け付けてもよい。この場合、処理部１２は、情報処理装置２０における過去の時刻でのソフトウェアＸのバージョンｖ１の情報を記録したログを参照して、ソフトウェアＸの復元先のバージョンｖ１を特定してもよい。
【００２５】
そして、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１＝１と、ファームウェアＹの現在のバージョンｖ２＝４との組合せを確認する。処理部１２は、（ｖ１，ｖ２）＝（１，４）の組合せに対し、バージョン管理テーブルＴ１に基づいて、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＹの現在のバージョンｖ２の少なくとも１つの変更の要否を判定する。本例では、バージョン管理テーブルＴ１によれば、ｖ＝１に対して整合性を確認済であるｖ２の範囲は、１≦ｖ２≦３である。したがって、（ｖ１，ｖ２）＝（１，４）の組合せは、整合性を確認済でなく、ソフトウェアＸおよびハードウェア２３の連携に不具合が生じ得る。このため、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＹの現在のバージョンｖ２の少なくとも１つについて変更要であると判定する。すると、処理部１２は、バージョン管理テーブルＴ１に基づいて、変更のための組合せとして、例えば、（ｖ１，ｖ２）＝（２，４）、または、（ｖ１，ｖ２）＝（１，３）を特定する。
【００２６】
同様に、処理部１２は、ソフトウェアＸの復元先のバージョンと、外部ハードウェア３０のファームウェアＺの現在のバージョンとの組合せを確認してもよい。例えば、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１＝１と、ファームウェアＺの現在のバージョンｖ３＝４との組合せを確認する。処理部１２は、（ｖ１，ｖ３）＝（１，４）の組合せに対し、バージョン管理テーブルＴ１に基づいて、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＺの現在のバージョンｖ３の少なくとも１つの変更の要否を判定する。本例では、バージョン管理テーブルＴ１によれば、ｖ＝１に対して整合性を確認済であるｖ３の範囲は、１≦ｖ３≦２である。したがって、（ｖ１，ｖ３）＝（１，４）の組合せは、整合性を確認済でなく、ソフトウェアＸおよび外部ハードウェア３０の連携に不具合が生じ得る。このため、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＺの現在のバージョンｖ３の少なくとも１つについて変更要であると判定する。すると、処理部１２は、バージョン管理テーブルＴ１に基づいて、変更のための組合せとして、例えば、（ｖ１，ｖ３）＝（２，４）、または、（ｖ１，ｖ３）＝（１，２）を特定する。
【００２７】
処理部１２は、変更のための組合せとして特定された（ｖ１，ｖ２）の組合せ候補および（ｖ１，ｖ３）の組合せ候補をマージした組合せを特定し、ソフトウェアＸおよびファームウェアＹ，Ｚに対するバージョン変更内容を警告として出力してもよい。上記の例の場合、ソフトウェアＸの復元先のバージョンｖ１を、ｖ１＝１ではなく、ｖ１＝２とすることで、現在のｖ２＝４、および、現在のｖ３＝４の両方との整合性を満たせる。すなわち、処理部１２は、（ｖ１，ｖ２，ｖ３）＝（２，４，４）の組合せを特定する。このため、処理部１２は、ソフトウェアＸとファームウェアＹ，Ｚとの整合性を満たすために、警告Ｒ２を出力することが考えられる。警告Ｒ２は、ソフトウェアＸの復元先のバージョンｖ１を、ｖ１＝２に変更要である旨を示す。
【００２８】
あるいは、上記の例の場合、ファームウェアＹの現在のバージョンｖ２をｖ２＝３に、ファームウェアＺの現在のバージョンｖ３をｖ３＝２にそれぞれ変更することで、ソフトウェアＸの復元先のバージョンｖ１＝１との整合性を満たせる。すなわち、処理部１２は、（ｖ１，ｖ２，ｖ３）＝（１，３，２）の組合せを特定する。このため、他の例では、処理部１２は、ソフトウェアＸとファームウェアＹ，Ｚとの整合性を満たすために、警告Ｒ３を出力することが考えられる。警告Ｒ３は、ファームウェアＹの現在のバージョンｖ２をｖ２＝３に、ファームウェアＺの現在のバージョンｖ３をｖ３＝２にそれぞれ変更要である旨を示す。
【００２９】
なお、整合性を満たすバージョンの組合せの特定方法の基準を示すポリシーを記憶部１１に予め設定可能としてもよい。例えば、ソフトウェアＸを旧バージョンへ復元するが、ファームウェアＹ，Ｚの現バージョンとの整合性を満たす最新のバージョンを選択するというポリシーであれば、処理部１２は、復元先のバージョンｖ１＝２とする警告Ｒ２を出力することが考えられる。このポリシーは、極力既にアップデート済の状態を活かして整合性を担保する組合せを導き出すポリシーであるといえる。
【００３０】
また、例えば、ソフトウェアＸの復元先のバージョンを変更せずに、ファームウェアＹ，Ｚのバージョンを、当該復元先のバージョンと整合性を満たす最新のバージョンにするというポリシーも考えられる。このポリシーの場合に、処理部１２は、（ｖ２，ｖ３）＝（３，２）に変更する旨の警告Ｒ３を出力することが考えられる。このポリシーは、極力バックアップ時の組合せに近い状態で整合性を合わせるポリシーであるといえる。
【００３１】
また、バージョン管理テーブルＴ１の内容によっては、処理部１２は、上記とは異なるバージョンの組合せを特定することも考えられる。
図２は、バージョンの組合せの他の特定例を示す図である。記憶部１１は、バージョン管理テーブルＴ１に代えて、バージョン管理テーブルＴ２を記憶する。
【００３２】
バージョン管理テーブルＴ２は、ｖ１＝１に対して、範囲１≦ｖ２≦３および範囲１≦ｖ３≦２を示すレコードを含む。また、バージョン管理テーブルＴ２は、ｖ１＝２に対して、範囲１≦ｖ２≦４および範囲２≦ｖ３≦４を示すレコードを含む。更に、バージョン管理テーブルＴ２は、ｖ１＝３に対して、範囲５≦ｖ２≦７および範囲３≦ｖ３≦５を示すレコードを含む。
【００３３】
ここで、現時点において、ｖ１＝３、ｖ２＝５、ｖ３＝４であるとする。
例えば、処理部１２は、ユーザによる動作環境の復旧指示Ｒ１を受け付けると、動作環境の復旧を開始する。復旧指示Ｒ１は、ソフトウェアＸの復元先のバージョンｖ１を１とする旨の指示を含む。あるいは、前述のように、処理部１２は、復旧先の時刻または時刻に関連付けられた情報（例えば、リストア対象のバックアップデータの識別情報）を含む復旧指示を受け付けてもよい。この場合、処理部１２は、情報処理装置２０における過去の時刻でのソフトウェアＸのバージョンｖ１の情報を記録したログを参照して、ソフトウェアＸの復元先のバージョンｖ１を特定してもよい。
【００３４】
そして、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１＝１と、ファームウェアＹの現在のバージョンｖ２＝５との組合せを確認する。処理部１２は、（ｖ１，ｖ２）＝（１，５）の組合せに対し、バージョン管理テーブルＴ２に基づいて、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＹの現在のバージョンｖ２の少なくとも１つの変更の要否を判定する。本例では、バージョン管理テーブルＴ２によれば、ｖ＝１に対して整合性を確認済であるｖ２の範囲は、１≦ｖ２≦３である。したがって、（ｖ１，ｖ２）＝（１，５）の組合せは、整合性を確認済でなく、ソフトウェアＸおよびハードウェア２３の連携に不具合が生じ得る。このため、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＹの現在のバージョンｖ２の少なくとも１つについて変更要であると判定する。すると、処理部１２は、バージョン管理テーブルＴ２に基づいて、変更のための組合せとして、例えば、（ｖ１，ｖ２）＝（２，４）、または、（ｖ１，ｖ２）＝（１，３）を特定する。
【００３５】
同様に、処理部１２は、ソフトウェアＸの復元先のバージョンと、外部ハードウェア３０のファームウェアＺの現在のバージョンとの組合せを確認してもよい。例えば、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１＝１と、ファームウェアＺの現在のバージョンｖ３＝４との組合せを確認する。処理部１２は、（ｖ１，ｖ３）＝（１，４）の組合せに対し、バージョン管理テーブルＴ２に基づいて、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＺの現在のバージョンｖ３の少なくとも１つの変更の要否を判定する。本例では、バージョン管理テーブルＴ２によれば、ｖ＝１に対して整合性を確認済であるｖ３の範囲は、１≦ｖ３≦２である。したがって、（ｖ１，ｖ３）＝（１，４）の組合せは、整合性を確認済でなく、ソフトウェアＸおよび外部ハードウェア３０の連携に不具合が生じ得る。このため、処理部１２は、ソフトウェアＸの復元先のバージョンｖ１およびファームウェアＺの現在のバージョンｖ３の少なくとも１つについて変更要であると判定する。すると、処理部１２は、バージョン管理テーブルＴ２に基づいて、変更のための組合せとして、例えば、（ｖ１，ｖ３）＝（２，４）、または、（ｖ１，ｖ３）＝（１，２）を特定する。
【００３６】
処理部１２は、変更のための組合せとして特定された（ｖ１，ｖ２）の組合せ候補および（ｖ１，ｖ３）の組合せ候補をマージした組合せを特定し、ソフトウェアＸおよびファームウェアＹ，Ｚに対するバージョン変更内容を警告として出力してもよい。上記の例の場合、ソフトウェアＸの復元先のバージョンｖ１を、ｖ１＝１ではなく、ｖ１＝２とし、ファームウェアＹの現在のバージョンｖ２をｖ２＝４とすることで、ｖ１，ｖ２，ｖ３の整合性を満たせる。すなわち、処理部１２は、（ｖ１，ｖ２，ｖ３）＝（２，４，４）の組合せを特定する。このため、処理部１２は、ソフトウェアＸとファームウェアＹ，Ｚとの整合性を満たすために、警告Ｒ４を出力することが考えられる。警告Ｒ４は、ソフトウェアＸの復元先のバージョンｖ１をｖ１＝２に、ファームウェアＹの現在のバージョンｖ２をｖ２＝４にそれぞれ変更要である旨を示す。
【００３７】
あるいは、上記の例の場合、ファームウェアＹの現在のバージョンｖ２をｖ２＝３に、ファームウェアＺの現在のバージョンｖ３をｖ３＝２にそれぞれ変更することで、ソフトウェアＸの復元先のバージョンｖ１との整合性を満たせる。すなわち、処理部１２は、（ｖ１，ｖ２，ｖ３）＝（１，３，２）の組合せを特定する。このため、他の例では、処理部１２は、ソフトウェアＸとファームウェアＹ，Ｚとの整合性を満たすために、警告Ｒ５を出力することが考えられる。警告Ｒ５は、ファームウェアＹの現在のバージョンｖ２をｖ２＝３に、ファームウェアＺの現在のバージョンｖ３をｖ３＝２にそれぞれ変更要である旨を示す。
【００３８】
情報処理装置１０によれば、復元によりソフトウェアやハードウェアの動作に不具合が発生する可能性を減らすことができる。具体的には次の通りである。
ソフトウェアＸは、ハードウェア２３や外部ハードウェア３０と連携して所定の処理を実行することもある。しかし、ソフトウェアＸのバージョンとファームウェアＹのバージョンとの組合せによっては、ソフトウェアＸとハードウェア２３とが適切に連携できないことがある。また、ソフトウェアＸのバージョンとファームウェアＺのバージョンとの組合せによっては、ソフトウェアＸと外部ハードウェア３０とが適切に連携できないことがある。
【００３９】
このため、ソフトウェアＸを、あるバックアップ時点のバージョンに復元すると、ソフトウェアＸのバージョンとファームウェアＹのバージョンとが不整合となり、ソフトウェアＸやハードウェア２３の動作に不具合が生じる可能性がある。同様に、ソフトウェアＸを、あるバックアップ時点のバージョンに復元すると、ソフトウェアＸのバージョンとファームウェアＺのバージョンとが不整合となり、ソフトウェアＸや外部ハードウェア３０の動作に不具合が生じる可能性がある。
【００４０】
そこで、処理部１２は、バージョン管理テーブルＴ１（または、バージョン管理テーブルＴ２）に基づいて、ソフトウェアＸの復元先のバージョンに対して不整合となるファームウェアＹのバージョンを特定する。そして、処理部１２は、ファームウェアＹの現バージョンで不整合が発生し得る場合には、不整合を回避するように、ソフトウェアＸの復元先のバージョンおよびファームウェアＹの少なくとも一方の変更内容を特定する。これにより、ソフトウェアＸの復元によって、ソフトウェアＸやハードウェア２３の動作に不具合が発生する可能性を減らすことができる。
【００４１】
また、上記のように、処理部１２は、ユーザにより指定されたポリシーに応じて、ソフトウェアＸの復元先のバージョンおよびファームウェアＹの現在のバージョンのうち、変更対象を決定してもよい。これにより、ユーザの運用方針に応じたバージョン変更を実現できる。
【００４２】
また、処理部１２は、ソフトウェアＸの復元先のバージョンを変更対象に決定すると、ファームウェアＹの現在のバージョンに対して整合性を確認済であるソフトウェアＸのバージョンのうち、最新のバージョンまたは復元先のバージョンとの差が最小のバージョンを、変更後のバージョンとして特定してもよい。あるいは、処理部１２は、ファームウェアＹの現在のバージョンを変更対象に決定すると、ソフトウェアＸの復元先のバージョンに対して整合性を確認済であるファームウェアＹのバージョンのうち、最新のバージョンまたは現在のバージョンとの差が最小のバージョンを、変更後のバージョンとして特定してもよい。これにより、上記と同様に、ユーザの運用方針（例えば、極力最新バージョンを使用する、または、極力更新回数を減らすなど）に応じたバージョン変更を実現できる。
【００４３】
更に、処理部１２は、上記変更後のバージョンの候補のうち、適用後の情報処理装置２０の再起動が不要である候補がある場合、当該再起動が不要である候補の中から、変更後のバージョンを特定してもよい。これにより、ユーザの業務への影響を抑えてバージョン変更を行うよう支援できる。
【００４４】
また、上記のように、処理部１２は、情報処理装置２０に内蔵のハードウェア２３だけでなく、情報処理装置２０の外部にある外部ハードウェア３０のファームウェアＺについても、同様にして、ソフトウェアＸの復元先のバージョンとの整合性を確認する。これにより、ソフトウェアＸの復元によって、ソフトウェアＸや外部ハードウェア３０の動作に不具合が発生する可能性を減らすことができる。
【００４５】
処理部１２は、ソフトウェアＸの復元先のバージョンおよびファームウェアＹ，Ｚの現在のバージョンの少なくとも１つに対して特定された変更後のバージョンを表示装置（図１，図２では図示を省略している）により表示させてもよい。
【００４６】
より具体的には、処理部１２は、ソフトウェアＸの復元先のバージョンおよびファームウェアＹ，Ｚの現在のバージョンに対する変更内容を含む警告を、情報処理装置１０に接続された表示装置に出力してもよい。これにより、ユーザは、表示装置により表示された警告を確認し、変更内容に従ったバージョンを適用するか否かを判断できる。
【００４７】
また、処理部１２は、ソフトウェアＸの復元先のバージョンおよびファームウェアＹ，Ｚの現在のバージョンの少なくとも１つに対して特定された変更後のバージョンの適用を情報処理装置２０に指示してもよい。
【００４８】
より具体的には、ユーザは、変更内容に従ったバージョンの適用を情報処理装置１０に指示することもできる。例えば、処理部１２は、当該指示に応じて、情報処理装置２０の動作環境の復旧を行い、その際に、ソフトウェアＸの復元先のバージョンを変更してもよい。あるいは、情報処理装置１０は、ファームウェアＹ，Ｚの現在のバージョンを変更してもよい。こうして、情報処理装置１０は、動作環境の復旧に当たり、ソフトウェアＸおよびファームウェアＹ，Ｚの動作に不具合が発生しないように支援することもできる。
【００４９】
［第２の実施の形態］
図３は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、管理サーバ１００、業務サーバ２００、ストレージ３００および公開サーバ４００を含む。公開サーバ４００は、ネットワーク４０に接続されている。ネットワーク４０は、ＬＡＮ（Local Area Network）でもよいし、インターネットでもよい。管理サーバ１００および業務サーバ２００は、スイッチ５０に接続されている。スイッチ５０は、データパケットを中継する中継装置である。スイッチ５０は、ネットワーク４０に接続されている。
【００５０】
管理サーバ１００は、業務サーバ２００にインストールされたソフトウェアのバージョンと、業務サーバ２００に関連するハードウェアを制御するファームウェアのバージョンとを管理するサーバコンピュータである。業務サーバ２００に関連するハードウェアは、例えば、業務サーバ２００の内蔵のハードウェアや、業務サーバ２００の外部のハードウェア（業務サーバ２００に外付けされたハードウェア）である。また、管理サーバ１００は、業務サーバ２００によるバックアップおよびリストアの処理を管理する。管理サーバ１００は、第１の実施の形態の情報処理装置１０の一例である。
【００５１】
業務サーバ２００は、ユーザの業務を支援するサーバコンピュータである。業務サーバ２００には、ＯＳ、ミドルウェアおよびアプリケーションなどの種々のソフトウェアがインストールされる。また、業務サーバ２００は、ネットワークインタフェースカード（ＮＩＣ：Network Interface Card）やストレージ３００と接続するためのホストバスアダプタ（ＨＢＡ：Host Bus Adapter）などの種々のハードウェアを含む。ハードウェアは、当該ハードウェアに組み込まれたファームウェアの機能により制御される。
【００５２】
業務サーバ２００により実行されるソフトウェアの動作環境（ソフトウェアのプログラムや設定データなど）は、所定のタイミングで（例えば、定期的に）バックアップされる。業務サーバ２００では、バックアップされたデータ（バックアップデータ）に基づいて、ソフトウェアの動作環境がリストア（復元）されることがある。業務サーバ２００は、第１の実施の形態の情報処理装置２０の一例である。
【００５３】
ストレージ３００は、業務サーバ２００の業務処理に用いられるデータを格納するストレージ装置である。ストレージ３００は、ストレージ３００に組み込まれたファームウェアの機能により制御される。ここで、ストレージ３００は、業務サーバ２００の外部のハードウェアであり、第１の実施の形態の外部ハードウェア３０の一例である。また、スイッチ５０も、第１の実施の形態の外部ハードウェア３０の一例である（スイッチ５０も、スイッチ５０のファームウェアにより制御される）。
【００５４】
公開サーバ４００は、業務サーバ２００で実行される各種のソフトウェアに対する機能追加プログラムや修正プログラム（パッチ）を業務サーバ２００に配布するサーバコンピュータである。ソフトウェアに適用されている追加プログラムや修正プログラムに応じて、ソフトウェアのバージョンが定められる。また、公開サーバ４００は、ストレージ３００やスイッチ５０を制御するファームウェアのプログラムをバージョン毎に配布する。公開サーバ４００は、複数設けられてもよい。例えば、ソフトウェアやハードウェアのベンダ毎に、公開サーバ４００が複数設けられることもある。
【００５５】
更に、公開サーバ４００は、ソフトウェアのバージョンと、ファームウェアのバージョンとの整合性を満たす組合せの情報を配布する。
図４は、管理サーバのハードウェア例を示す図である。管理サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６およびＮＩＣ１０７を有する。各ハードウェアは管理サーバ１００のバスに接続されている。業務サーバ２００および公開サーバ４００も管理サーバ１００と同様のハードウェアを用いて実現できる。
【００５６】
プロセッサ１０１は、管理サーバ１００の情報処理を制御するハードウェアである。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組合せであってもよい。
【００５７】
ＲＡＭ１０２は、管理サーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００５８】
ＨＤＤ１０３は、管理サーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＯＳのプログラム、アプリケーションプログラム、および各種データを記憶する。管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００５９】
画像信号処理部１０４は、プロセッサ１０１からの命令に従って、管理サーバ１００に接続されたディスプレイ６１に画像を出力する。ディスプレイ６１として、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００６０】
入力信号処理部１０５は、管理サーバ１００に接続された入力デバイス６２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス６２として、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００６１】
媒体リーダ１０６は、記録媒体６３に記録されたプログラムやデータを読み取る装置である。記録媒体６３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体６３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体６３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００６２】
ＮＩＣ１０７は、スイッチ５０を介して業務サーバ２００や公開サーバ４００と通信を行う。ＮＩＣ１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００６３】
図５は、管理対象のソフトウェアおよびファームウェアの例を示す図である。第２の実施の形態の情報処理システムでは、種々のソフトウェアやファームウェアが実行される。
例えば、業務サーバ２００は、仮想マシンＶＭ１を実現するオペレーティングシステム（ＯＳ）ａやＯＳａ上のソフトウェアＡおよびソフトウェアＢを有する。また、業務サーバ２００は、仮想マシンＶＭ２を実現するオペレーティングシステム（ＯＳ）ｂやＯＳｂ上のソフトウェアＦおよびソフトウェアＧを有する。また、業務サーバ２００は、仮想マシンＶＭ１，ＶＭ２を実現するソフトウェアであるハイパーバイザｈｖを有する。
【００６４】
業務サーバ２００は、業務サーバ２００のメインボードを制御するファームウェアＣ（サーバファームウェアＣ）を有する。例えば、ファームウェアＣのプログラムは、メインボード上の不揮発性メモリ（ＮＶＲＡＭ：Non-Volatile RAM）に書き込まれている。業務サーバ２００は、メインボード上に接続されたＲＡＩＤカードを制御するファームウェアＤを有する。例えば、ファームウェアＤのプログラムは、ＲＡＩＤカード上のＮＶＲＡＭに書き込まれている。業務サーバ２００は、メインボード上に接続されたＮＩＣを制御するファームウェアＥを有する。例えば、ファームウェアＥのプログラムは、ＮＩＣ上のＮＶＲＡＭに書き込まれている。
【００６５】
スイッチ５０は、スイッチ５０を制御するファームウェアＭを有する。例えば、ファームウェアＭのプログラムは、スイッチ５０が備えるＮＶＲＡＭに書き込まれている。
ストレージ３００は、ストレージ３００を制御するファームウェアＮを有する。例えば、ファームウェアＮは、ストレージ３００が備えるＮＶＲＡＭに書き込まれている。
【００６６】
公開サーバ４００は、依存関係ＤＢ（DataBase）４１０を有する。依存関係ＤＢ４１０は、ソフトウェアと他のソフトウェアとのバージョン間、または、ソフトウェアとファームウェアとのバージョン間の整合性の確認結果のＤＢである。例えば、依存関係ＤＢ４１０には、あるソフトウェアのバージョンと、当該ソフトウェアのバージョンに対し、整合性が保証されている他のソフトウェアのバージョンやファームウェアのバージョンとの組合せの情報を含む。
【００６７】
整合性は、例えば、ソフトウェアのベンダなどによる動作確認に応じて、当該ベンダにより保証される。あるソフトウェアと別のソフトウェアとの整合性が保証されたバージョンの組合せは、システムにおいて両方を組合せて使用した場合に、両ソフトウェアの動作に不具合がないことを確認済（整合性確認済）の組合せであるといえる。また、あるソフトウェアとファームウェアとの整合性が保証されたバージョンの組合せは、システムにおいて両方を組合せて使用した場合に、当該ソフトウェアの動作とファームウェアの動作とに不具合がないことを確認済（整合性確認済）の組合せであるといえる。
【００６８】
依存関係ＤＢ４１０は、管理サーバ１００に対して公開されている。管理サーバ１００は、公開サーバ４００から依存関係ＤＢ４１０の内容をダウンロードすることができる。
図６は、管理サーバの機能例を示す図である。管理サーバ１００は、ソフトウェア管理部１１０、インフラ管理部１２０およびバックアップ管理部１３０を有する。ソフトウェア管理部１１０、インフラ管理部１２０およびバックアップ管理部１３０の機能は、プロセッサ１０１により実現される。例えば、プロセッサ１０１は、ＲＡＭ１０２に記憶されたプログラムを実行することで、ソフトウェア管理部１１０、インフラ管理部１２０およびバックアップ管理部１３０の機能を発揮する。ただし、ソフトウェア管理部１１０、インフラ管理部１２０およびバックアップ管理部１３０の機能は、ＦＰＧＡやＡＳＩＣなどのハードワイヤードロジックにより実現されてもよい。
【００６９】
ソフトウェア管理部１１０は、管理情報記憶部１１１、ソフトウェア情報取得部１１２、インフラ情報取得部１１３、依存関係管理部１１４、バックアップ時刻取得部１１５、依存関係判定部１１６および連携指示部１１７を有する。
【００７０】
管理情報記憶部１１１は、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実現される。管理情報記憶部１１１は、管理情報を記憶する。管理情報は、例えば、業務サーバ２００におけるソフトウェアやファームウェアの更新の履歴やバックアップの履歴、および、公開サーバ４００からダウンロードされた依存関係ＤＢ４１０の情報を含む。
【００７１】
ソフトウェア情報取得部１１２は、業務サーバ２００から利用されているソフトウェアおよび当該ソフトウェアのバージョンの情報を取得し、依存関係管理部１１４に提供する。
【００７２】
インフラ情報取得部１１３は、業務サーバ２００の各種ハードウェアや業務サーバ２００の外部ハードウェアであるストレージ３００やスイッチ５０のファームウェアのバージョンの情報をインフラ管理部１２０から取得し、依存関係管理部１１４に提供する。
【００７３】
依存関係管理部１１４は、ソフトウェア情報取得部１１２およびインフラ情報取得部１１３から取得した情報に基づいて、ソフトウェアやファームウェアの更新の履歴を生成し、管理情報記憶部１１１に格納する。依存関係管理部１１４は、公開サーバ４００から依存関係ＤＢ４１０の内容をダウンロードし、管理情報記憶部１１１に格納する。
【００７４】
バックアップ時刻取得部１１５は、バックアップ管理部１３０からバックアップが行われた時刻を取得し、バックアップデータの識別情報に対応付けて、管理情報記憶部１１１に格納する。管理情報記憶部１１１には、バックアップデータの識別情報に対応付けて、バックアップデータ取得時の業務サーバ２００、ストレージ３００およびスイッチ５０のソフトウェアやファームウェアの構成情報が格納される。
【００７５】
依存関係判定部１１６は、バックアップ管理部１３０によるソフトウェアの動作環境の復旧が行われる場合に、ソフトウェアの復元先のバージョンと、ファームウェアの現在のバージョン（現バージョン）との組合せを確認する。依存関係判定部１１６は、管理情報記憶部１１１に記憶された依存関係ＤＢ４１０の内容を参照して、ソフトウェアの復元先のバージョンおよびファームウェアの現バージョンの少なくとも一方を変更要であるか否かを判定する。依存関係判定部１１６は、変更要である場合に、当該変更の内容を特定し、ディスプレイ６１に表示させる。変更の内容は、現バージョンからのバージョンダウンのこともあるし、現バージョンからのバージョンアップのこともある。
【００７６】
連携指示部１１７は、ソフトウェアの復元先のバージョンおよびファームウェアの現バージョンの少なくとも一方について変更要であると依存関係判定部１１６により判定された場合、ユーザによる当該変更の適用の指示を受け付ける。連携指示部１１７は、ユーザによる指示に応じて、ソフトウェアの復元先のバージョンの変更をバックアップ管理部１３０に指示する。あるいは、連携指示部１１７は、ファームウェアの現バージョンの更新をインフラ管理部１２０に指示する。
【００７７】
インフラ管理部１２０は、業務サーバ２００の内蔵のハードウェアや外付けのハードウェア（ストレージ３００やスイッチ５０）のファームウェアのバージョンを管理する。
インフラ管理部１２０は、インフラ情報記憶部１２１およびＦＷ（FirmWare）更新部１２２を有する。
【００７８】
インフラ情報記憶部１２１は、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実現される。インフラ情報記憶部１２１は、インフラ情報を記憶する。インフラ情報は、業務サーバ２００の内蔵ハードウェアのファームウェアであるファームウェアＣ，Ｄ，Ｅの現バージョンの情報を含む。また、インフラ情報は、業務サーバ２００の外部ハードウェアであるスイッチ５０のファームウェアＭのバージョンやストレージ３００のファームウェアＮの現バージョンの情報を含む。
【００７９】
ＦＷ更新部１２２は、業務サーバ２００、ストレージ３００およびスイッチ５０の何れかのファームウェアの更新（アップグレードまたはダウングレード）を、該当の装置に指示する。ＦＷ更新部１２２は、ファームウェアの更新結果を、インフラ情報記憶部１２１に記録する。また、ＦＷ更新部１２２は、業務サーバ２００、ストレージ３００およびスイッチ５０の何れかから、ファームウェアの更新を行った旨の通知を受け付けることもある（ＦＷ更新部１２２の指示に依らずにファームウェアの更新が行われた場合）。この場合も、ＦＷ更新部１２２は、当該ファームウェアの更新結果をインフラ情報記憶部１２１に記録する。
【００８０】
バックアップ管理部１３０は、バックアップ記憶部１３１、バックアップ制御部１３２およびリストア制御部１３３を有する。
バックアップ記憶部１３１は、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実現される。バックアップ記憶部１３１は、バックアップデータを記憶する。バックアップデータは、業務サーバ２００のソフトウェアの動作環境のバックアップである。業務サーバ２００のバックアップは、所定のタイミング（例えば、所定の周期）で行われる。
【００８１】
バックアップ制御部１３２は、業務サーバ２００のバックアップデータを取得し、バックアップ記憶部１３１に格納する。バックアップ制御部１３２は、バックアップデータの取得時刻（バックアップ時刻）を、バックアップ時刻取得部１１５に提供する。
【００８２】
例えば、バックアップ制御部１３２は、業務サーバ２００で実行されるＯＳやミドルウェアなどのソフトウェア、ソフトウェアの処理に用いられるデータや設定情報などをファイル単位でバックアップしてもよい。あるいは、バックアップ制御部１３２は、業務サーバ２００全体の情報を１つのイメージファイルとしてバックアップしてもよい。あるいは、バックアップ制御部１３２は、スナップショットと呼ばれる技術を用いて、業務サーバ２００のバックアップを行ってもよい。
【００８３】
リストア制御部１３３は、バックアップ記憶部１３１に記憶されたバックアップデータを用いて、業務サーバ２００の動作環境を特定の時点の状態に復元する。
図７は、変更履歴テーブルの例を示す図である。変更履歴テーブル１４１は、管理情報記憶部１１１に格納されている。変更履歴テーブル１４１は、時刻、コンポーネントおよびバージョンの項目を含む。
【００８４】
時刻の項目には、時刻が登録される。コンポーネントの項目には、管理サーバ１００による管理対象のコンポーネントの名称が登録される。コンポーネントとは、ソフトウェアおよびファームウェアの総称である。１つの時刻に対して、複数のコンポーネントが登録され得る。バージョンの項目には、該当の時刻における該当のコンポーネントのバージョンが登録される。
【００８５】
例えば、変更履歴テーブル１４１には、時刻が“ｔ１”、コンポーネントが“ソフトウェアＡ”、バージョンが“１．０”という情報が登録される。これは、時刻ｔ１におけるソフトウェアＡのバージョンが１．０であったことを示す。
【００８６】
変更履歴テーブル１４１には、時刻ｔ１における管理対象の他のコンポーネントのバージョンも同様に登録される。また、変更履歴テーブル１４１には、他の時刻について、ソフトウェアＡを含む複数のコンポーネントのバージョンも同様に登録される。変更履歴テーブル１４１における最新の時刻のコンポーネントのバージョンが、該当のコンポーネントの現バージョンを示す。
【００８７】
図８は、バックアップ管理テーブルの例を示す図である。バックアップ管理テーブル１５１は、管理情報記憶部１１１に格納されている。バックアップ管理テーブル１５１は、バックアップデータ、コンポーネントおよびバージョンの項目を含む。
【００８８】
バックアップデータの項目には、バックアップデータの識別名が登録される。コンポーネントの項目には、管理対象のコンポーネントの名称が登録される。１つのバックアップデータの識別名に対して、複数のコンポーネントが登録され得る。ただし、バックアップデータにはソフトウェアの情報は含まれるが、ファームウェアの情報は含まれない点に注意されたい。バージョンの項目には、該当のバックアップデータが取得された時点における該当のコンポーネントのバージョンが登録される。
【００８９】
例えば、バックアップ管理テーブル１５１には、バックアップデータが“バックアップＢａ”、コンポーネントが“ソフトウェアＡ”、バージョンが“ａ１”という情報が登録される。これは、バックアップデータ“バックアップＢａ”が取得された時点におけるソフトウェアＡのバージョンがａ１であったことを示す。
【００９０】
バックアップ管理テーブル１５１には、バックアップデータ“バックアップＢａ”に対して、他のコンポーネントのバージョンも同様に登録される。また、バックアップ管理テーブル１５１には、他のバックアップデータについて、ソフトウェアＡを含む複数のコンポーネントのバージョンも同様に登録される。
【００９１】
図９は、依存関係テーブルの第１の例を示す図である。依存関係テーブル１６１は、ソフトウェアＡの各バージョンに対して整合性確認済の他のコンポーネントのバージョンを示す情報である。依存関係テーブル１６１は、管理情報記憶部１１１に格納されている。依存関係テーブル１６１には、ソフトウェアＡバージョンおよびコンポーネントの項目を含む。
【００９２】
ソフトウェアＡバージョンの項目には、ソフトウェアＡのバージョンが登録される。コンポーネントの項目には、コンポーネント毎に、ソフトウェアＡの該当のバージョンに対して整合性が保証されたバージョン範囲が登録される。なお、依存関係テーブル１６１の例では、コンポーネントの項目にソフトウェアＡを含んでいる。ソフトウェアＡに対するバージョン範囲は、設定なし（ハイフン記号“−”で表している）である。また、ソフトウェアＡの該当のバージョンに対して依存関係（整合性有無）を考慮しなくてよい場合も、当該コンポーネントのバージョン範囲は、設定なしとなる。
【００９３】
例えば、依存関係テーブル１６１には、ソフトウェアＡバージョンが“１．０”、ソフトウェアＡのバージョン範囲が設定なし、ソフトウェアＢのバージョン範囲が“α(1.0,m)≦ｂ≦α(1.0,n)”、・・・、サーバファームウェアＣのバージョン範囲が“α(1.0,o)≦ｆｃ≦α(1.0,p)”、・・・、ストレージファームウェアＮのバージョン範囲が“α(1.0,r)≦ｆｎ≦α(1.0,s)”という情報が登録される。
【００９４】
これは、ソフトウェアＡのバージョン１．０に対して、整合性が保証されたソフトウェアＢのバージョン範囲がα(1.0,m)≦ｂ≦α(1.0,n)であることを示す。また、ソフトウェアＡのバージョン１．０に対して、整合性が保証されたファームウェアＣのバージョン範囲がα(1.0,o)≦ｆｃ≦α(1.0,p)であることを示す。更に、ソフトウェアＡのバージョン１．０に対して、整合性が保証されたファームウェアＮのバージョン範囲がα(1.0,r)≦ｆｎ≦α(1.0,s)であることを示す。
【００９５】
依存関係テーブル１６１には、ソフトウェアＡの他のバージョンについても同様に、整合性が保証された他のコンポーネントのバージョン範囲が登録される。
図１０は、依存関係テーブルの第２の例を示す図である。依存関係テーブル１６２は、ソフトウェアＢの各バージョンに対して整合性確認済の他のコンポーネントのバージョンを示す情報である。依存関係テーブル１６２は、管理情報記憶部１１１に格納されている。依存関係テーブル１６２には、ソフトウェアＢバージョンおよびコンポーネントの項目を含む。
【００９６】
ソフトウェアＢバージョンの項目には、ソフトウェアＢのバージョンが登録される。コンポーネントの項目には、コンポーネント毎に、ソフトウェアＢの該当のバージョンに対して整合性が保証されたバージョン範囲が登録される。なお、依存関係テーブル１６２の例では、コンポーネントの項目にソフトウェアＢを含んでいる。ソフトウェアＢに対するバージョン範囲は、設定なし（ハイフン記号“−”で表している）である。また、ソフトウェアＢの該当のバージョンに対して依存関係（整合性有無）を考慮しなくてよい場合も、当該コンポーネントのバージョン範囲は、設定なしとなる。
【００９７】
例えば、依存関係テーブル１６２には、ソフトウェアＢバージョンが“１．０”、ソフトウェアＡのバージョン範囲が“β(1.0,k)≦ａ≦β(1.0,l)”、ソフトウェアＢのバージョン範囲が設定なし、・・・、サーバファームウェアＣのバージョン範囲が“β(1.0,o)≦ｆｃ≦β(1.0,p)”、・・・、ストレージファームウェアＮのバージョン範囲が“β(1.0,r)≦ｆｎ≦β(1.0,s)”という情報が登録される。
【００９８】
これは、ソフトウェアＢのバージョン１．０に対して、整合性が保証されたソフトウェアＡのバージョン範囲がβ(1.0,k)≦ａ≦β(1.0,l)であることを示す。また、ソフトウェアＢのバージョン１．０に対して、整合性が保証されたファームウェアＣのバージョン範囲がβ(1.0,o)≦ｆｃ≦β(1.0,p)であることを示す。更に、ソフトウェアＢのバージョン１．０に対して、整合性が保証されたファームウェアＮのバージョン範囲がβ(1.0,r)≦ｆｎ≦β(1.0,s)であることを示す。
【００９９】
依存関係テーブル１６２には、ソフトウェアＢの他のバージョンについても同様に、整合性が保証された他のコンポーネントのバージョン範囲が登録される。
図９，図１０では、ソフトウェアＡに関する依存関係テーブル１６１およびソフトウェアＢに関する依存関係テーブル１６２を例示したが、他のソフトウェアおよびファームウェアに関する他の依存関係テーブルも管理情報記憶部１１１に格納されている。
【０１００】
図１１は、依存関係管理情報の例を示す図である。依存関係管理情報１７１は、管理情報記憶部１１１に記憶された各ソフトウェアおよび各ファームウェアの依存関係テーブルに基づいて、依存関係判定部１１６により作成され、管理情報記憶部１１１に格納される。依存関係管理情報１７１は、時刻ｔにおける、あるコンポーネントのバージョンと他のコンポーネントのバージョンとの依存関係を表す。依存関係管理情報１７１は、コンポーネント名、時刻ｔのバージョン、バージョン範囲の項目を含む。
【０１０１】
コンポーネント名の項目には、コンポーネントの名称が登録される。時刻ｔのバージョンの項目には、時刻ｔにおけるバージョンが登録される。バージョン範囲の項目には、該当のコンポーネントに対して、整合性が保証された他のコンポーネントのバージョン範囲が登録される。コンポーネント名の項目と同じコンポーネントに対するバージョン範囲は、設定なし（ハイフン記号“−”で表している）である。また、コンポーネント名の項目のコンポーネントに対して依存関係を考慮しなくてよい場合も、当該コンポーネントのバージョン範囲は、設定なしとなる。
【０１０２】
例えば、依存関係管理情報１７１には、コンポーネント名が“ソフトウェアＡ”、時刻ｔのバージョンが“１．０”、ソフトウェアＡのバージョン範囲が設定なし“−”、ソフトウェアＢのバージョン範囲が“α(1.0,m)≦ｂ≦α(1.0,n)”、・・・、サーバファームウェアＣのバージョン範囲が“α(1.0,o)≦ｆｃ≦α(1.0,p)”、・・・、ストレージファームウェアＮのバージョン範囲が“α(1.0,r)≦ｆｎ≦α(1.0,s)”という情報が登録される。
【０１０３】
これは、ソフトウェアＡのバージョン１．０に対して、整合性が保証されたソフトウェアＢのバージョン範囲がα(1.0,m)≦ｂ≦α(1.0,n)であることを示す。また、ソフトウェアＡのバージョン１．０に対して、整合性が保証されたファームウェアＣのバージョン範囲がα(1.0,o)≦ｆｃ≦α(1.0,p)であることを示す。更に、ソフトウェアＡのバージョン１．０に対して、整合性が保証されたファームウェアＮのバージョン範囲がα(1.0,r)≦ｆｎ≦α(1.0,s)であることを示す。
【０１０４】
依存関係管理情報１７１には、他のコンポーネントの時刻ｔのバージョンについても同様に、整合性が保証された他のコンポーネントのバージョン範囲が登録される。
依存関係判定部１１６は、依存関係管理情報１７１により、あるコンポーネントについて、時刻ｔにおける全ての他のコンポーネントのバージョンと整合性が保証されたバージョン範囲（集合）を得ることができる。
【０１０５】
例えば、ソフトウェアＡの列に着目すると、“β(1.0,k)≦ａ≦β(1.0,l)”、・・・、“γ(1.a,k)≦ａ≦γ(1.a,l)”、・・・、“ν(2.0,k)≦ａ≦ν(2.0,l)”の条件を全て満たすａの集合Ｓａ（ｔ）を得ることができる。
【０１０６】
この場合、Ｓａ（ｔ）＝｛［β(1.0,k)≦ａ≦β(1.0,l)］∧，・・・，∧［γ(1.a,k)≦ａ≦γ(1.a,l)］∧、・・・、∧［ν(2.0,k)≦ａ≦ν(2.0,l)］｝である。ここで、記号∧は、アンド演算（論理積）を表す。
【０１０７】
同様に、依存関係判定部１１６は、例えば、ソフトウェアＢのバージョンｂに対して集合Ｓｂ（ｔ）を得る。また、依存関係判定部１１６は、ファームウェアＣのバージョンｆｃに対して集合Ｓｆｃ（ｔ）を得る。依存関係判定部１１６は、ファームウェアＮのバージョンｆｎに対して集合Ｓｆｎ（ｔ）を得る。
【０１０８】
図１２は、依存関係管理情報の第１の具体例を示す図である。依存関係管理情報１７２は、依存関係管理情報１７１の時刻ｔ＝ｔａの場合を示している。時刻ｔａにおける各コンポーネントのバージョンは次の通りである。ソフトウェアＡのバージョンは“１．５”である。ソフトウェアＢのバージョンは“１．１”である。ファームウェアＣのバージョンは“７．０”である。ファームウェアＮのバージョンは“２．０”である。ここで、説明を簡単にするために、ソフトウェアＡ，ＢおよびファームウェアＣ，Ｎ以外のコンポーネントについては、依存関係を考慮しなくてよいものとする（図１３，図１４も同様）。
【０１０９】
依存関係管理情報１７１によれば、ソフトウェアＡのバージョンａが、他のコンポーネントとの整合性確保の上で満たすべき条件は、集合Ｓａ（ｔａ）で表される。Ｓａ（ｔａ）＝｛［１．０≦ａ≦２．０］∧［１．５≦ａ≦３．０］｝＝｛１．５≦ａ≦２．０｝である。
【０１１０】
ソフトウェアＢのバージョンｂが他のコンポーネントとの整合性確保の上で満たすべき条件は、集合Ｓｂ（ｔａ）で表される。Ｓｂ（ｔａ）＝｛［１．０≦ｂ≦２．５］∧［１．０≦ｂ≦２．０］∧［１．０≦ｂ≦１．５］｝＝｛１．０≦ｂ≦１．５｝である。
【０１１１】
ファームウェアＣのバージョンｆｃが他のコンポーネントとの整合性確保の上で満たすべき条件は、集合Ｓｆｃ（ｔａ）で表される。Ｓｆｃ（ｔａ）＝｛［２．０≦ｆｃ≦７．２］∧［２．０≦ｆｃ≦７．２］｝＝｛２．０≦ｆｃ≦７．２｝である。
【０１１２】
ファームウェアＮのバージョンｆｎが他のコンポーネントとの整合性確保の上で満たすべき条件は、集合Ｓｆｃ（ｔａ）で表される。Ｓｆｃ（ｔａ）＝｛１．０≦ｆｎ≦２．５｝である。
【０１１３】
図１３は、依存関係管理情報の第２の具体例を示す図である。依存関係管理情報１７３は、依存関係管理情報１７１の時刻ｔ＝ｔｂの場合を示している。ここで、時刻ｔｂは、時刻ｔａよりも後の時刻である。時刻ｔｂにおける各コンポーネントのバージョンは次の通りである。ソフトウェアＡのバージョンは“１．５”である。ソフトウェアＢのバージョンは“１．２”である。ファームウェアＣのバージョンは“７．２”である。ファームウェアＮのバージョンは“４．０”である。
【０１１４】
図１４は、依存関係管理情報の第３の具体例を示す図である。依存関係管理情報１７４は、依存関係管理情報１７３に対して、ソフトウェアＡ，Ｂを時刻ｔａの状態にリストアする場合の例を示している。依存関係管理情報１７４では、ファームウェアＣ，Ｎのバージョンは、依存関係管理情報１７３のバージョン（時刻ｔｂのバージョン）となる。一方、依存関係管理情報１７４では、ソフトウェアＡ，Ｂのバージョンは、依存関係管理情報１７２のバージョン（時刻ｔａ）のバージョンとなる。
【０１１５】
依存関係判定部１１６は、依存関係管理情報１７４に基づいて、各コンポーネントのバージョンが時刻ｔａへのリストア後も他のコンポーネントとの整合性が保証されたバージョンであるか否かを確認することができる。ここで、該当のコンポーネントがリストア後の状態で満たすべき条件を表すバージョン範囲を、例えば、集合Ｓａ（ｔａ’）と表すこととする。依存関係管理情報１７４によれば、Ｓａ（ｔａ’）＝［１．５≦ａ≦２．０］である。Ｓｂ（ｔａ’）＝［１．２≦ｂ≦１．５］である。Ｓｆｃ（ｔａ’）＝［２．０≦ｆｃ≦７．２］である。Ｓｆｎ（ｔａ’）＝［１．０≦ｆｎ≦２．５］である。
【０１１６】
例えば、依存関係判定部１１６は、リストア後のソフトウェアＡのバージョン“１．５”は、集合Ｓａ（ｔａ’）＝［１．５≦ａ≦２．０］に属するので、全ての他のコンポーネントとの整合性を満たすと判断する。
【０１１７】
依存関係判定部１１６は、リストア後のソフトウェアＢのバージョン“１．１”は、集合Ｓｂ（ｔａ’）＝［１．２≦ｂ≦１．５］に属さないので、一部のコンポーネントに対して不整合が発生すると判断する。
【０１１８】
依存関係判定部１１６は、ファームウェアＣのバージョン“７．２”は、集合Ｓｆｃ（ｔａ’）＝［２．０≦ｆｃ≦７．２］に属するので、全ての他のコンポーネントとの整合性を満たすと判断する。
【０１１９】
依存関係判定部１１６は、ファームウェアＮのバージョン“４．０”は、集合Ｓｆｎ（ｔａ’）＝［１．０≦ｆｎ≦２．５］に属さないので、一部のコンポーネントに対して不整合が発生すると判断する。
【０１２０】
更に、依存関係管理情報１７４によれば、ファームウェアＮのバージョン“４．０”に対して、ソフトウェアＢのバージョンｂは“１．２≦ｂ≦１．５”の範囲が整合性の保証されたバージョンであるが、ｂ＝１．１は、当該範囲に属さない。また、ソフトウェアＢに対して、ファームウェアＮのバージョンｆｎは“１．０≦ｆｎ≦２．５”の範囲が整合性の保証されたバージョンであるが、ｆｎ＝４．０は、当該範囲に属さない。したがって、依存関係判定部１１６は、ソフトウェアＢのリストア先のバージョン“１．１”と、ファームウェアＮの現バージョン“４．０”との間に不整合が発生すると判断する。
【０１２１】
このように、依存関係判定部１１６は、依存関係管理情報１７４に基づいて、複数のファームウェアそれぞれの現バージョンの全てに対して整合性を確認済であるソフトウェアＢのバージョン範囲を特定する。そして、依存関係判定部１１６は、ソフトウェアＢの復元後のバージョンが当該バージョン範囲に属するか否かに応じて、ソフトウェアＢの復元先のバージョンまたは他のコンポーネントの現バージョンの変更の要否を判定する。
【０１２２】
更に、依存関係判定部１１６は、リストア後も現バージョンと変わらないソフトウェアＡがある場合、依存関係管理情報１７４に基づいて、ファームウェアＣ，Ｎそれぞれの現在のバージョン、および、ソフトウェアＡの現バージョンの全てに対して整合性を確認済であるソフトウェアＢのバージョン範囲を特定する。そして、依存関係判定部１１６は、ソフトウェアＢの復元後のバージョンが当該バージョン範囲に属するか否かに応じて、ソフトウェアＢの復元先のバージョンまたは他のコンポーネントの現バージョンの変更の要否を判定する。
【０１２３】
図１５は、ポリシー情報の例を示す図である。ポリシー情報１８１は、管理情報記憶部１１１に格納されている。ポリシー情報１８１は、リストア時にコンポーネント間のバージョンに不整合が発生する場合に、整合性を保証するためのコンポーネントのバージョン変更方法に対するポリシーを規定する情報である。ポリシー情報１８１は、ポリシーＩＤ（IDentifier）およびポリシー内容の項目を含む。
【０１２４】
ポリシーＩＤの項目には、ポリシーを識別する識別情報が登録される。ポリシー内容の項目には、ポリシーの内容が登録される。
例えば、ポリシー情報１８１には、ポリシーＩＤが“１”、ポリシー内容が“依存関係を満たすバージョンのうち、最新バージョンを使用”という情報が登録されている。
【０１２５】
また、ポリシー情報１８１には、ポリシーＩＤが“２”、ポリシー内容が“依存関係を満たすバージョンのうち、現バージョンとの差が最小のバージョンを使用”という情報が登録されている。
【０１２６】
また、ポリシー情報１８１には、ポリシーＩＤが“３”、ポリシー内容が“依存関係を満たすバージョンのうち、適用後の再起動が不要なバージョンを使用”という情報が登録されている。
【０１２７】
また、ポリシー情報１８１には、ポリシーＩＤが“４”、ポリシー内容が“特定のコンポーネントのバージョンを固定し、ポリシーＩＤ“１”または“２”のポリシーに従って他のコンポーネントのバージョンを決定”という情報が登録される。ポリシーＩＤ“４”のポリシーでは、依存関係判定部１１６は、管理対象のコンポーネントのうち、１つのコンポーネントのバージョンを固定して依存関係を判定する。そして、依存関係判定部１１６は、固定されたコンポーネントのバージョンに対して、整合性が保証された他のコンポーネントのバージョンを導き出す。この際に、依存関係判定部１１６は、「最新のバージョン」（ポリシーＩＤ“１”）または「最も更新範囲が小さいバージョン」（ポリシーＩＤ“２”）の基準により該当のバージョンを特定する。
【０１２８】
依存関係判定部１１６は、ユーザにより指定されたポリシーに従って、不整合が発生する場合のコンポーネントのバージョン変更内容を特定する。バージョン変更内容の特定方法の具体例については後述される。
【０１２９】
図１６は、再起動テーブルの例を示す図である。再起動テーブル１９１は、管理情報記憶部１１１に格納されている。再起動テーブル１９１は、コンポーネントのバージョンについて、当該バージョンを適用した場合の再起動の要否を示す情報である。再起動テーブル１９１は、コンポーネント、バージョンおよび再起動の項目を含む。
【０１３０】
コンポーネントの項目には、コンポーネントの名称が登録される。バージョンの項目には、バージョンが登録される。再起動の項目には、該当のコンポーネントの該当のバージョンを適用した場合における適用先装置の再起動の要否が登録される。
【０１３１】
例えば、再起動テーブル１９１には、コンポーネントが“サーバファームウェアＣ”、バージョンが“１．０”、再起動が“要”という情報が登録されている。これは、ファームウェアＣのバージョン“１．０”を適用した後に、業務サーバ２００の再起動が必要であることを示す。
【０１３２】
また、例えば、再起動テーブル１９１には、コンポーネントが“サーバファームウェアＣ”、バージョンが“１．１”、再起動が“不要”という情報が登録されている。これは、ファームウェアＣのバージョン“１．１”を適用した後に、業務サーバ２００の再起動が不要であることを示す。
【０１３３】
再起動テーブル１９１には、他のコンポーネントについても、バージョン毎に、適用時の再起動要否が登録される。
次に、管理サーバによる処理手順を説明する。
【０１３４】
図１７は、管理サーバの処理例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。下記の手順は、管理サーバ１００が、所定のバックアップデータを指定したリストア指示を受けると開始される。リストア指示は、例えば、ユーザにより管理サーバ１００に入力される。
【０１３５】
（Ｓ１）依存関係管理部１１４は、管理対象装置の構成情報を取得し、当該構成情報を更新する。具体的には、依存関係管理部１１４は、ソフトウェア情報取得部１１２およびインフラ情報取得部１１３を介して、業務サーバ２００のソフトウェア構成やファームウェア構成の情報を取得する。また、依存関係管理部１１４は、インフラ情報取得部１１３を介して、業務サーバ２００の外部ハードウェアであるストレージ３００やスイッチ５０のファームウェア構成の情報を取得する。依存関係管理部１１４は、取得した構成情報について、前回と変更がある場合、管理情報記憶部１１１に記憶された変更履歴テーブル１４１に最新の状態を登録する。
【０１３６】
（Ｓ２）依存関係管理部１１４は、依存関係ＤＢ４１０の更新があるか否かを、公開サーバ４００に問い合わせる。依存関係ＤＢ４１０の更新がある場合、依存関係管理部１１４は、ステップＳ３に処理を進める。依存関係ＤＢ４１０の更新がない場合、依存関係管理部１１４は、ステップＳ４に処理を進める。
【０１３７】
（Ｓ３）依存関係管理部１１４は、公開サーバ４００から依存関係ＤＢ４１０の更新内容を取得し、取得した更新内容に基づいて、管理情報記憶部１１１に記憶された各コンポーネントの依存関係テーブルを更新する。
【０１３８】
（Ｓ４）リストア制御部１３３は、ユーザによるリストア指示により指定されたリストア対象のバックアップデータを選択する。依存関係判定部１１６は、当該バックアップデータの識別情報をリストア制御部１３３から取得する。依存関係判定部１１６は、バックアップデータの識別情報を基に、管理情報記憶部１１１に記憶されたバックアップ管理テーブル１５１を検索し、今回のリストアによる復元対象のソフトウェアの復元先のバージョンを特定する。また、依存関係判定部１１６は、バックアップ時刻取得部１１５により記録された該当のバックアップデータに対応する時刻（復元先の時刻）を、管理情報記憶部１１１から読み出す。
【０１３９】
（Ｓ５）依存関係判定部１１６は、ポリシーを選択する。例えば、依存関係判定部１１６は、ユーザにより指定されたポリシーＩＤに応じたポリシーを選択する。
（Ｓ６）依存関係判定部１１６は、ポリシーに応じたバージョン選択処理を実行する。バージョン選択処理の詳細は、後述される。
【０１４０】
（Ｓ７）依存関係判定部１１６は、ポリシーに従って適用されるコンポーネントのバージョンを表示する。
（Ｓ８）依存関係判定部１１６は、ステップＳ７の表示内容（表示されたコンポーネントのバージョン）を適用するか否かを判定する。適用する場合、依存関係判定部１１６は、ステップＳ９に処理を進める。適用しない場合、依存関係判定部１１６は、ステップＳ１０に処理を進める。例えば、依存関係判定部１１６は、ステップＳ７における表示内容を適用する旨の指示を受け付けた場合に、当該表示内容を適用すると判定し、当該表示内容を適用しない旨の指示を受け付けた場合に、当該表示内容を適用しないと判定する。
【０１４１】
（Ｓ９）連携指示部１１７は、バージョンの変更対象となる特定のファームウェアに対して、ステップＳ７で表示したバージョン（当該ファームウェアの現バージョンとは異なるバージョン）の適用をＦＷ更新部１２２に指示する。ＦＷ更新部１２２は、連携指示部１１７の指示に応じて、ファームウェアのバージョン変更を、該当のハードウェアを備える装置（業務サーバ２００、ストレージ３００およびスイッチ５０など）に指示する。これにより、ファームウェアのバージョン変更が行われる。
【０１４２】
（Ｓ１０）連携指示部１１７は、業務サーバ２００におけるバックアップデータのリストアの実行をリストア制御部１３３に指示する。リストア制御部１３３は、連携指示部１１７の指示に応じて、該当のバックアップデータによる業務サーバ２００のリストアを実行する。これにより、業務サーバ２００のソフトウェアの動作環境がバックアップデータの取得時点の状態に復元される。
【０１４３】
なお、ステップＳ６では、あるソフトウェア（復元対象のソフトウェアまたは他のソフトウェア）に対するバージョン変更が選択されることもある。この場合、ステップＳ１０において、連携指示部１１７は、該当のソフトウェアに対するバージョン変更をリストア制御部１３３に指示する。リストア制御部１３３は、例えば、業務サーバ２００のリストア完了後に、指示されたソフトウェアのバージョン変更を当該業務サーバ２００に指示する。業務サーバ２００は、管理サーバ１００または公開サーバ４００から該当のソフトウェアについて指定されたバージョンのプログラムを取得し、当該ソフトウェアのバージョンを変更する。
【０１４４】
次に、ステップＳ６のポリシーに応じたバージョン選択処理を例示する。選択対象となるポリシーの候補は、図１５で例示したポリシーＩＤ“１”、“２”、“３”、“４”である。まず、ポリシーＩＤ“１”が選択された場合を説明する。ポリシーＩＤ“１”は、“依存関係を満たすバージョンのうち、最新のバージョンを使用”するポリシーである。
【０１４５】
図１８は、バージョン選択処理例（その１）を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。以下の手順は、図１７のステップＳ６（ポリシーＩＤ“１”が選択された場合）に相当する。
【０１４６】
（Ｓ２１）依存関係判定部１１６は、各コンポーネントの依存関係テーブルに基づいて、リストア先の時刻に対応する依存関係管理情報を生成する。前述の例でいえば、時刻ｔｂから時刻ｔａの状態へリストアする場合、依存関係判定部１１６は、図１４で例示した依存関係管理情報１７４を生成する。依存関係判定部１１６は、変数ｘに１を代入する（ｘ＝１）。ここで、変数ｘは、今回生成された依存関係管理情報のバージョン範囲の項目における列番号を表す。例えば、依存関係管理情報１７４では、ｘ＝１の列は、バージョン範囲の項目におけるソフトウェアＡの列に相当する。また、ｘ＝２の列は、バージョン範囲の項目におけるソフトウェアＢの列に相当する。管理対象となるコンポーネント数をｎとすると、依存関係管理情報１７４におけるｘ＝ｎの列は、例えば、ファームウェアＮの列に相当する。
【０１４７】
（Ｓ２２）依存関係判定部１１６は、変数ｙに１を代入する（ｙ＝１）。依存関係判定部１１６は、Ｍａｘ（ｘ）にｚ（ｘ，ｙ）＝ｚ（ｘ，１）を代入する（Ｍａｘ（ｘ）＝ｚ（ｘ，１））。ここで、変数ｙは、依存関係管理情報の行番号を表す。例えば、依存関係管理情報１７４では、ｙ＝１の行は、ソフトウェアＡのバージョン“１．５”の行に相当する。また、ｙ＝２の行は、ソフトウェアＢのバージョン“１．１”の行に相当する。依存関係管理情報１７４におけるｘ＝ｎの行は、例えば、ファームウェアＮの列に相当する。また、ｚ（ｘ，ｙ）は、ｘ列目のコンポーネントＰｘのバージョンのうち、ｙ行目のコンポーネントＰｙと整合性を有するバージョンの最大値を示す。Ｍａｘ（ｘ）は、ｘ列目のコンポーネントＰｘのバージョンのうち、１〜ｎ行目のコンポーネントＰｙ（ｙ＝１〜ｎ）の全てと整合性を満たすバージョンの最大値を示す（Ｍａｘ（ｘ）は本手順により確定される目的値である）。なお、依存関係管理情報の（ｘ，１）に相当するバージョン範囲が設定なしの場合、依存関係判定部１１６は、ステップＳ２３〜Ｓ２５をスキップしてステップＳ２６を実行してよい。
【０１４８】
（Ｓ２３）依存関係判定部１１６は、ｙ行目のコンポーネントＰｙと整合性を満たすｘ列目のコンポーネントＰｘのバージョンのうちの最大値をバージョンｚ（＝ｚ（ｘ，ｙ））とする。
【０１４９】
（Ｓ２４）依存関係判定部１１６は、ｚ（ｘ，ｙ）がＭａｘ（ｘ）よりも小さい（ｚ（ｘ，ｙ）＜Ｍａｘ（ｘ））か否かを判定する。ｚ（ｘ，ｙ）がＭａｘ（ｘ）よりも小さい場合、依存関係判定部１１６は、ステップＳ２５に処理を進める。ｚ（ｘ，ｙ）がＭａｘ（ｘ）以上の場合、依存関係判定部１１６は、ステップＳ２６に処理を進める。
【０１５０】
（Ｓ２５）依存関係判定部１１６は、Ｍａｘ（ｘ）にｚ（ｘ，ｙ）を代入する（Ｍａｘ（ｘ）＝ｚ（ｘ，ｙ））。
（Ｓ２６）依存関係判定部１１６は、ｙにｙ＋１を代入する（ｙ＝ｙ＋１）。
【０１５１】
（Ｓ２７）依存関係判定部１１６は、ｙがｎよりも大きい（ｙ＞ｎ）か否かを判定する。ｙがｎよりも大きい場合、依存関係判定部１１６は、ステップＳ２８に処理を進める。ｙがｎ以下の場合、依存関係判定部１１６は、ステップＳ２３に処理を進める。
【０１５２】
（Ｓ２８）依存関係判定部１１６は、コンポーネントＰｘに対するバージョンＭａｘ（ｘ）を確定する。
（Ｓ２９）依存関係判定部１１６は、ｘにｘ＋１を代入する（ｘ＝ｘ＋１）。
【０１５３】
（Ｓ３０）依存関係判定部１１６は、ｘがｎよりも大きい（ｘ＞ｎ）か否かを判定する。ｘがｎよりも大きい場合、依存関係判定部１１６は、バージョン選択処理を終了する。ｘがｎ以下の場合、依存関係判定部１１６は、ステップＳ２２に処理を進める。
【０１５４】
こうして、依存関係判定部１１６は、各コンポーネントについて、他のコンポーネントとの依存関係を満たすバージョンのうち、最新のバージョンＭａｘ（ｘ）を選択することができる。
【０１５５】
次に、ポリシーＩＤ“２”が選択された場合を説明する。ポリシーＩＤ“２”は、“依存関係を満たすバージョンのうち、現バージョンとの差が最小のバージョンを使用”するポリシーである。
【０１５６】
図１９は、バージョン選択処理例（その２）を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。以下の手順は、図１７のステップＳ６（ポリシーＩＤ“２”が選択された場合）に相当する。
【０１５７】
（Ｓ４１）依存関係判定部１１６は、各コンポーネントの依存関係テーブルに基づいて、リストア先の時刻に対応する依存関係管理情報を生成する。前述の例でいえば、時刻ｔｂから時刻ｔａの状態へリストアする場合、依存関係判定部１１６は、図１４で例示した依存関係管理情報１７４を生成する。依存関係判定部１１６は、変数ｘに１を代入する（ｘ＝１）。変数ｘの意味は、ステップＳ２１の説明と同様である。
【０１５８】
（Ｓ４２）依存関係判定部１１６は、変数ｙに１を代入する（ｙ＝１）。依存関係判定部１１６は、Ｍｉｎ（ｘ）にｖ（ｘ，ｙ）＝（ｘ，１）を代入する（Ｍｉｎ（ｘ）＝ｖ（ｘ，ｙ）＝ｖ（ｘ，１））。依存関係判定部１１６は、Ｍａｘ（ｘ）にｚ（ｘ，ｙ）＝ｚ（ｘ，１）を代入する（Ｍａｘ（ｘ）＝ｚ（ｘ，ｙ）＝ｚ（ｘ，１））。依存関係判定部１１６は、ｘ列目のコンポーネントＰｘの現バージョンを変数Ａ（ｘ）に代入する。ここで、変数ｙ、Ｍａｘ（ｘ）およびｚ（ｘ，ｙ）の意味は、ステップＳ２２の説明と同様である。ｖ（ｘ，ｙ）は、ｘ列目のコンポーネントＰｘのバージョンのうち、ｙ行目のコンポーネントＰｙと整合性を有するバージョンの最小値を示す。Ｍｉｎ（ｘ）は、ｘ列目のコンポーネントＰｘのバージョンのうち、１〜ｎ行目のコンポーネントＰｙ（ｙ＝１〜ｎ）の全てと整合性を満たすバージョンの最小値を示す（Ｍｉｎ（ｘ）およびＭａｘ（ｘ）は本手順により確定される目的値である）。なお、依存関係管理情報の（ｘ，１）に相当するバージョン範囲が設定なしの場合、依存関係判定部１１６は、ステップＳ４３〜Ｓ４７をスキップしてステップＳ４８を実行してよい。
【０１５９】
（Ｓ４３）依存関係判定部１１６は、ｙ行目のコンポーネントＰｙと整合性を満たすｘ列目のコンポーネントＰｘのバージョンのうちの最小値をバージョンｖ（＝ｖ（ｘ，ｙ））とし、最大値をバージョンｚ（＝ｚ（ｘ，ｙ））とする。
【０１６０】
（Ｓ４４）依存関係判定部１１６は、ｚ（ｘ，ｙ）がＭａｘ（ｘ）よりも小さい（ｚ（ｘ，ｙ）＜Ｍａｘ（ｘ））か否かを判定する。ｚ（ｘ，ｙ）がＭａｘ（ｘ）よりも小さい場合、依存関係判定部１１６は、ステップＳ４５に処理を進める。ｚ（ｘ，ｙ）がＭａｘ（ｘ）以上の場合、依存関係判定部１１６は、ステップＳ４６に処理を進める。
【０１６１】
（Ｓ４５）依存関係判定部１１６は、Ｍａｘ（ｘ）にｚ（ｘ，ｙ）を代入する（Ｍａｘ（ｘ）＝ｚ（ｘ，ｙ））。
（Ｓ４６）依存関係判定部１１６は、ｖ（ｘ，ｙ）がＭｉｎ（ｘ）よりも大きい（ｖ（ｘ，ｙ）＞Ｍｉｎ（ｘ））か否かを判定する。ｖ（ｘ，ｙ）がＭｉｎ（ｘ）よりも大きい場合、依存関係判定部１１６は、ステップＳ４７に処理を進める。ｖ（ｘ，ｙ）がＭｉｎ（ｘ）以下の場合、依存関係判定部１１６は、ステップＳ４８に処理を進める。
【０１６２】
（Ｓ４７）依存関係判定部１１６は、Ｍｉｎ（ｘ）にｖ（ｘ，ｙ）を代入する（Ｍｉｎ（ｘ）＝ｖ（ｘ，ｙ））。
（Ｓ４８）依存関係判定部１１６は、ｙにｙ＋１を代入する（ｙ＝ｙ＋１）。
【０１６３】
（Ｓ４９）依存関係判定部１１６は、ｙがｎよりも大きい（ｙ＞ｎ）か否かを判定する。ｙがｎよりも大きい場合、依存関係判定部１１６は、ステップＳ５０に処理を進める。ｙがｎ以下の場合、依存関係判定部１１６は、ステップＳ４３に処理を進める。
【０１６４】
（Ｓ５０）依存関係判定部１１６は、Ｍａｘ（ｘ）≧Ａ（ｘ）≧Ｍｉｎ（ｘ）の場合はＡ（ｘ）を採用し、そうでない場合はＡ（ｘ）に近いＭａｘ（ｘ）またはＭｉｎ（ｘ）を採用する。すなわち、依存関係判定部１１６は、Ｍａｘ（ｘ）≧Ａ（ｘ）≧Ｍｉｎ（ｘ）の場合は、現バージョンＡ（ｘ）でコンポーネントＰｘのバージョンを維持すると決定する。一方、依存関係判定部１１６は、Ａ（ｘ）＞Ｍａｘ（ｘ）またはＭｉｎ（ｘ）＞Ａ（ｘ）の場合は、Ｍａｘ（ｘ），Ｍｉｎ（ｘ）のうち、現バージョンＡ（ｘ）との差が小さい方をコンポーネントＰｘの変更先のバージョンＶとして採用する。
【０１６５】
（Ｓ５１）依存関係判定部１１６は、ｘにｘ＋１を代入する（ｘ＝ｘ＋１）。
（Ｓ５２）依存関係判定部１１６は、ｘがｎよりも大きい（ｘ＞ｎ）か否かを判定する。ｘがｎよりも大きい場合、依存関係判定部１１６は、バージョン選択処理を終了する。ｘがｎ以下の場合、依存関係判定部１１６は、ステップＳ４２に処理を進める。
【０１６６】
こうして、依存関係判定部１１６は、各コンポーネントについて、他のコンポーネントとの依存関係を満たすバージョンのうち、現バージョンとの差が最小のバージョンＶを選択することができる。
【０１６７】
次に、ポリシーＩＤ“３”が選択された場合を説明する。ポリシーＩＤ“３”は、“依存関係を満たすバージョンのうち、適用後の再起動が不要なバージョンを使用”するポリシーである。
【０１６８】
図２０は、バージョン選択処理例（その３）を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。以下の手順は、図１７のステップＳ６（ポリシーＩＤ“３”が選択された場合）に相当する。
【０１６９】
（Ｓ６１）依存関係判定部１１６は、各コンポーネントの依存関係テーブルに基づいて、リストア先の時刻に対応する依存関係管理情報を生成する。前述の例でいえば、時刻ｔｂから時刻ｔａの状態へリストアする場合、依存関係判定部１１６は、図１４で例示した依存関係管理情報１７４を生成する。依存関係判定部１１６は、変数ｘに１を代入する（ｘ＝１）。変数ｘの意味は、ステップＳ２１の説明と同様である。
【０１７０】
（Ｓ６２）依存関係判定部１１６は、変数ｙに１を代入する（ｙ＝１）。依存関係判定部１１６は、フラグＲ＿Ｆｌａｇ（ｘ）に（初期値として）Ｔｒｕｅを設定する（Ｒ＿Ｆｌａｇ（ｘ）＝Ｔｒｕｅ）。依存関係判定部１１６はＭｉｎ（ｘ）にｖ（ｘ，ｙ）＝（ｘ，１）を代入する（Ｍｉｎ（ｘ）＝ｖ（ｘ，ｙ）＝ｖ（ｘ，１））。依存関係判定部１１６は、Ｍａｘ（ｘ）にｚ（ｘ，ｙ）＝ｚ（ｘ，１）を代入する（Ｍａｘ（ｘ）＝ｚ（ｘ，ｙ）＝ｚ（ｘ，１））。ここで、変数ｙ、Ｍａｘ（ｘ）およびｚ（ｘ，ｙ）の意味は、ステップＳ２２の説明と同様である。また、変数Ｍｉｎ（ｘ）およびｖ（ｘ，ｙ）の意味は、ステップＳ４２の説明と同様である。フラグＲ＿Ｆｌａｇ（ｘ）は、ｘ列目のコンポーネントＰｘのバージョン変更に伴う再起動要否を示すフラグである。Ｒ＿Ｆｌａｇ（ｘ）＝Ｔｒｕｅは、再起動要を示す。Ｒ＿Ｆｌａｇ（ｘ）＝Ｆａｌｓｅは、再起動不要を示す。なお、依存関係管理情報の（ｘ，１）に相当するバージョン範囲が設定なしの場合、依存関係判定部１１６は、ステップＳ６３〜Ｓ６７をスキップしてステップＳ６８を実行してよい。
【０１７１】
（Ｓ６３）依存関係判定部１１６は、ｙ行目のコンポーネントＰｙと整合性を満たすｘ列目のコンポーネントＰｘのバージョンのうちの最小値をバージョンｖ（＝ｖ（ｘ，ｙ））とし、最大値をバージョンｚ（＝ｚ（ｘ，ｙ））とする。
【０１７２】
（Ｓ６４）依存関係判定部１１６は、ｚ（ｘ，ｙ）がＭａｘ（ｘ）よりも小さい（ｚ（ｘ，ｙ）＜Ｍａｘ（ｘ））か否かを判定する。ｚ（ｘ，ｙ）がＭａｘ（ｘ）よりも小さい場合、依存関係判定部１１６は、ステップＳ６５に処理を進める。ｚ（ｘ，ｙ）がＭａｘ（ｘ）以上の場合、依存関係判定部１１６は、ステップＳ６６に処理を進める。
【０１７３】
（Ｓ６５）依存関係判定部１１６は、Ｍａｘ（ｘ）にｚ（ｘ，ｙ）を代入する（Ｍａｘ（ｘ）＝ｚ（ｘ，ｙ））。
（Ｓ６６）依存関係判定部１１６は、ｖ（ｘ，ｙ）がＭｉｎ（ｘ）よりも大きい（ｖ（ｘ，ｙ）＞Ｍｉｎ（ｘ））か否かを判定する。ｖ（ｘ，ｙ）がＭｉｎ（ｘ）よりも大きい場合、依存関係判定部１１６は、ステップＳ６７に処理を進める。ｖ（ｘ，ｙ）がＭｉｎ（ｘ）以下の場合、依存関係判定部１１６は、ステップＳ６８に処理を進める。
【０１７４】
（Ｓ６７）依存関係判定部１１６は、Ｍｉｎ（ｘ）にｖ（ｘ，ｙ）を代入する（Ｍｉｎ（ｘ）＝ｖ（ｘ，ｙ））。
（Ｓ６８）依存関係判定部１１６は、ｙにｙ＋１を代入する（ｙ＝ｙ＋１）。
【０１７５】
（Ｓ６９）依存関係判定部１１６は、ｙがｎよりも大きい（ｙ＞ｎ）か否かを判定する。ｙがｎよりも大きい場合、依存関係判定部１１６は、ステップＳ７０に処理を進める。ｙがｎ以下の場合、依存関係判定部１１６は、ステップＳ６３に処理を進める。
【０１７６】
（Ｓ７０）依存関係判定部１１６は、管理情報記憶部１１１に記憶された再起動テーブル１９１に基づいて、Ｍａｘ（ｘ）≧Ｂ（ｘ）≧Ｍｉｎ（ｘ）、かつ、再起動が不要なバージョンＢ（ｘ）があるか否かを判定する。Ｍａｘ（ｘ）≧Ｂ（ｘ）≧Ｍｉｎ（ｘ）、かつ、再起動が不要なバージョンＢ（ｘ）がある場合、依存関係判定部１１６は、ステップＳ７１に処理を進める。Ｍａｘ（ｘ）≧Ｂ（ｘ）≧Ｍｉｎ（ｘ）、かつ、再起動が不要なバージョンＢ（ｘ）がない場合、依存関係判定部１１６は、ステップＳ７２に処理を進める。
【０１７７】
（Ｓ７１）依存関係判定部１１６は、ステップＳ７０で特定されたバージョンＢ（ｘ）のうち、再起動不要な最大値をＭａｘ（ｘ）とし、Ｒ＿Ｆｒａｇ（ｘ）＝Ｆａｌｓｅに設定する。
【０１７８】
（Ｓ７２）依存関係判定部１１６は、ｘにｘ＋１を代入する（ｘ＝ｘ＋１）。
（Ｓ７３）依存関係判定部１１６は、ｘがｎよりも大きい（ｘ＞ｎ）か否かを判定する。ｘがｎよりも大きい場合、依存関係判定部１１６は、処理をステップＳ７４に進める。ｘがｎ以下の場合、依存関係判定部１１６は、ステップＳ６２に処理を進める。
【０１７９】
（Ｓ７４）依存関係判定部１１６は、Ｒ＿Ｆｌａｇ（ｘ）＝Ｆａｌｓｅの場合、再起動不要なバージョンとしてＭａｘ（ｘ）をディスプレイ６１に表示させる。また、依存関係判定部１１６は、Ｒ＿Ｆｌａｇ（ｘ）＝Ｔｒｕｅの場合、再起動要なバージョンとしてＭａｘ（ｘ）をディスプレイ６１に表示させる。なお、当該ステップＳ７４は、図１７のステップＳ７に相当する処理として実行される。
【０１８０】
こうして、依存関係判定部１１６は、各コンポーネントについて、他のコンポーネントとの依存関係を満たすバージョンのうち、適用後の再起動が不要なバージョンを優先的に選択することができる。
【０１８１】
次に、ポリシーＩＤ“４”が選択された場合を説明する。ポリシーＩＤ“４”は、“特定のコンポーネントのバージョンを固定し、ポリシーＩＤ“１”または“２”のポリシーに従って他のコンポーネントのバージョンを決定”するポリシーである。ポリシーＩＤ“４”が選択される場合、サブポリシーとして、ポリシーＩＤ“１”または“２”が選択される。
【０１８２】
図２１は、バージョン選択処理例（その４）を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。以下の手順は、図１７のステップＳ６（ポリシーＩＤ“４”が選択された場合）に相当する。
【０１８３】
（Ｓ８１）依存関係判定部１１６は、バージョン固定化対象のコンポーネントＰｋを決定する。例えば、コンポーネントＰｋは、ユーザによって指定されてもよい。例えば、ユーザの業務への影響が比較的大きいコンポーネントのバージョンを固定することが考えられる。そして、依存関係判定部１１６は、各コンポーネントの依存関係テーブルに基づいて、リストア先の時刻に対応する依存関係管理情報を生成する。前述の例でいえば、時刻ｔｂから時刻ｔａの状態へリストアする場合、依存関係判定部１１６は、図１４で例示した依存関係管理情報１７４を生成する。
【０１８４】
（Ｓ８２）依存関係判定部１１６は、ステップＳ８１で生成した依存関係管理情報を参照して、コンポーネントＰｋの固定化バージョン（固定化の対象となるバージョン）が、他のコンポーネントに対する整合バージョンの範囲内に収まるか否かを確認する。
【０１８５】
（Ｓ８３）依存関係判定部１１６は、コンポーネントＰｋがリストア対象であるか否かを判定する。リストア対象である場合、依存関係判定部１１６は、ステップＳ８４に処理を進める。リストア対象でない場合、依存関係判定部１１６は、ステップＳ８５に処理を進める。
【０１８６】
（Ｓ８４）依存関係判定部１１６は、リストア対象外のコンポーネントからコンポーネントＰｋのバージョン（固定化バージョン）と整合性が取れていないコンポーネントを特定する。そして、依存関係判定部１１６は、ステップＳ８６に処理を進める。
【０１８７】
（Ｓ８５）依存関係判定部１１６は、リストア対象のコンポーネントからコンポーネントＰｋのバージョン（固定化バージョン）と整合性が取れていないコンポーネントを特定する。そして、依存関係判定部１１６は、ステップＳ８６に処理を進める。
【０１８８】
（Ｓ８６）依存関係判定部１１６は、ステップＳ８４またはステップＳ８５で特定したコンポーネントを優先順位に応じて１つ選択する。ここで、コンポーネント毎の優先順位は、ユーザにより予め指定される、または、所定のルール（例えば、該当コンポーネントを用いた業務の重要度など）に従い予め生成される。
【０１８９】
（Ｓ８７）依存関係判定部１１６は、ステップＳ８６で選択したコンポーネントについて、他のコンポーネントとの整合性を満たすバージョンを特定する。このとき、依存関係判定部１１６は、該当のバージョンを特定するために、選択されたサブポリシー（ポリシーＩＤ“１”または“２”のポリシー）の基準を用いる。
【０１９０】
（Ｓ８８）依存関係判定部１１６は、ステップＳ８４またはステップＳ８５で特定した全コンポーネントについて、ステップＳ８６，Ｓ８７の処理を行ったか否か（全コンポーネントを処理済であるか否か）を判定する。特定した全コンポーネントを処理済である場合、依存関係判定部１１６は、バージョン選択処理を終了する。特定した全コンポーネントを処理済でない場合、依存関係判定部１１６は、ステップＳ８６に処理を進める。
【０１９１】
次に、図２１の手順によるバージョン選択の具体例を説明する。まず、依存関係管理情報の時系列に応じた変化例を説明する。
図２２は、依存関係管理情報の時系列に応じた変化例を示す図である。図２２では、説明を簡単にするために、ソフトウェアＡ，ＢおよびファームウェアＣ，Ｄが管理対象である場合を例示する。なお、図中、ソフトウェアＡなどを“ＳＷ（SoftWare）−Ａ”のように略記することがある。また、図中、ファームウェアＣなどを、“ＦＷ−Ｃ”のように略記することがある。また、図中、バージョンを“ｖｅｒ．”と略記することがある。
【０１９２】
図２２（Ａ）は、時刻ｔ１における依存関係管理情報１７５を例示する。図２２（Ｂ）は、時刻ｔ２における依存関係管理情報１７６を例示する。図２２（Ｃ）は、時刻ｔ３における依存関係管理情報１７７を例示する。
【０１９３】
なお、依存関係管理情報１７５，１７６，１７７では、各コンポーネントのバージョン範囲について、最小値および最大値を表記している。
ここで、時刻ｔ３で示される各コンポーネントのバージョンに対し、ソフトウェアＡのバージョンを“２．５”から時刻ｔ１のバージョン“２．２”にリストアし、ソフトウェアＢをリストアの対象外とする場合を想定する。このとき、更に、ソフトウェアＢの時刻ｔ３におけるバージョン“３．５”を固定化することを考える。
【０１９４】
図２３は、バージョン選択の具体例を示す図である。依存関係判定部１１６は、時刻ｔ３の状態から時刻ｔ１の状態へリストアする場合の依存関係管理情報１７８を作成する。時刻ｔ１の状態へリストアした場合の各コンポーネントのバージョンは次の通りである。ソフトウェアＡのバージョンは“２．２”である。ソフトウェアＢ（固定化対象）のバージョンは“３．５”である。ファームウェアＣのバージョンは“７．６”である。ファームウェアＤのバージョンは“１．５”である。
【０１９５】
バージョン固定化の対象であるソフトウェアＢは、リストアの対象外である（ステップＳ８３  Ｎｏ）。したがって、依存関係判定部１１６は、リストア対象のコンポーネントからソフトウェアＢのバージョンと整合性が取れていないコンポーネントを特定する（ステップＳ８５）。ここでは、リストア対象のコンポーネントはソフトウェアＡである。ソフトウェアＡの復元先のバージョン“２．２”に対して、ソフトウェアＢの整合性を満たす最小バージョンは“３”であり、最大バージョンは“３．４”である。固定化対象のソフトウェアＢのバージョン“３．５”は、ソフトウェアＡのバージョン“２．２”と整合性が保証された最大バージョン“３．４”よりも大きいバージョンである。このため、依存関係判定部１１６は、固定化対象のソフトウェアＢのバージョンと整合性が取れていないコンポーネントとして、ソフトウェアＡを特定する。
【０１９６】
そして、依存関係判定部１１６は、特定したコンポーネントを所定の優先順位に応じて１つ選択する（ステップＳ８６）。ここでは、特定したコンポーネントは、ソフトウェアＡの１つであり、依存関係判定部１１６は、ソフトウェアＡを選択する（特定したコンポーネントが複数の場合は優先順位の順に１つ選択する）。依存関係判定部１１６は、選択したコンポーネントについてソフトウェアＢの固定化されたバージョン“３．５”と整合するバージョンを特定する（ステップＳ８７）。ここでは、依存関係判定部１１６は、ソフトウェアＡの依存関係テーブル１６３に基づいて、リストア対象であるソフトウェアＡについて他のコンポーネントのバージョンに対して整合性が保証されたバージョンを選択する。依存関係判定部１１６は、ソフトウェアＡのリストア先のバージョンを変更することになる。
【０１９７】
具体的には、依存関係判定部１１６は、依存関係テーブル１６３に基づき、ソフトウェアＢのバージョン“３．５”、ファームウェアＣのバージョン“７．６”、ファームウェアＤのバージョン“１．５”の全てと整合性が保証されたソフトウェアＡのバージョン“２．４”、“２．５”を特定する。ここで、ソフトウェアＡの復元先のバージョン“２．２”は、他の全てのコンポーネントとの整合性を保つ上で満たすべきバージョン範囲“２．４”、“２．５”に含まれていないことになる。この場合に、依存関係判定部１１６は、ソフトウェアＡのバージョン“２．２”の復元による他のコンポーネントのバージョンとの不整合の発生を検出してもよい。
【０１９８】
依存関係判定部１１６は、ソフトウェアＡの他のコンポーネントとの整合性を満たすバージョン群｛“２．４”、“２．５”｝の中から、更に、１つのバージョンに絞り込む。例えば、依存関係判定部１１６は、ユーザにより指定されたサブポリシー（例えば、ポリシーＩＤ“１”や“２”に相当するポリシーなど）に従って、バージョンの絞り込みを行う。より具体的には、ポリシーＩＤ“１”（“依存関係を満たすバージョンのうち、最新のバージョンを使用”）がサブポリシーに選択された場合、依存関係判定部１１６は、バージョン群｛“２．４”、“２．５”｝のうち、“２．５”を選択することが考えられる。なお、本例では、ソフトウェアＡの現バージョンが“２．５”である。依存関係判定部１１６は、ソフトウェアＡのリストアを行うと、他のコンポーネントとの間に不整合が発生する旨を警告するメッセージを、ディスプレイ６１に表示させてもよい。
【０１９９】
図２４は、警告表示例（その１）を示す図である。例えば、依存関係判定部１１６は、ディスプレイ６１に警告画面７０を表示させてもよい。警告画面７０は、メッセージ７１、実行ボタン７２、キャンセルボタン７３およびポインタ７４を含む。
【０２００】
メッセージ７１は、「リストアによりコンポーネント間に不整合が発生します。」というメッセージを含む。また、メッセージ７１は、“（１）リストア対象：ソフトウェアＡ  （現バージョン２．５）”、および、“（２）リストア先バージョン：２．２”のメッセージを含む。更に、メッセージ７１は、“（３）リストアにより不整合となるコンポーネント”のリストとして、“ソフトウェアＢ  バージョン３．５”、“ファームウェアＣ  バージョン７．６”、および、“ファームウェアＤ  バージョン１．５”のメッセージを含む。
【０２０１】
実行ボタン７２は、リストアの実行入力を受け付けるボタンである。キャンセルボタン７３は、リストアのキャンセル入力を受け付けるボタンである。ユーザは、入力デバイス６２を操作することで、ポインタ７４により、実行ボタン７２またはキャンセルボタン７３に対する入力を行える。
【０２０２】
こうして、管理サーバ１００は、リストアによりソフトウェアやファームウェアの動作に不具合が発生することを防ぐことができる。
上記の例では、リストア対象でないソフトウェアＢのバージョンを固定化する例を示したが、リストア対象であるソフトウェアＡのリストア先のバージョンを固定化することもできる。その場合も、上記の手順により、依存関係判定部１１６は、不整合を回避するための他のコンポーネントのバージョンを特定する。
【０２０３】
図２５は、警告表示例（その２）を示す図である。図２２の例において、時刻ｔ３の状態から、時刻ｔ１の状態へソフトウェアＡをリストアし、ソフトウェアＡのリストア先のバージョンを“２．２”で固定する例を考える。本例でも、ソフトウェアＢは、リストア対象外である。この場合、依存関係判定部１１６は、ソフトウェアＡのリストア後に不整合となるコンポーネントとして、ソフトウェアＢのバージョン“３．５”、ファームウェアＣのバージョン“７．６”、ファームウェアＤのバージョン“１．５”を特定する。
【０２０４】
また、依存関係判定部１１６は、不整合を回避するコンポーネントのバージョンとして、ソフトウェアＢのバージョン“３．４”、ファームウェアＣのバージョン“７．２”、ファームウェアＤのバージョン“１．４”を特定する。これらは、ソフトウェアＡのリストア後のバージョン“２．２”との整合性が保証されている最新バージョンである（ソフトウェアＡのバージョン固定化に加え、最新バージョンを選択するポリシーを使用）。
【０２０５】
依存関係判定部１１６は、ソフトウェアＢ、ファームウェアＣおよびファームウェアＤのバージョンを、不整合を回避可能なバージョンに変更する選択を受け付けてもよい。例えば、依存関係判定部１１６は、ディスプレイ６１に警告画面８０を表示させてもよい。警告画面８０は、メッセージ８１、実行ボタン８２、バージョン変更ボタン８３、キャンセルボタン８４およびポインタ８５を含む。
【０２０６】
メッセージ８１は、“（１）リストア対象：ソフトウェアＡ  （現バージョン２．５）”、および、“（２）リストア先バージョン：２．２”のメッセージを含む。また、メッセージ８１は、“（３）リストアにより不整合となるコンポーネント”のリストとして、“ソフトウェアＢ  バージョン３．５”、“ファームウェアＣ  バージョン７．６”、および、“ファームウェアＤ  バージョン１．５”のメッセージを含む。
【０２０７】
更に、メッセージ８１は、“（４）不整合を回避するコンポーネントのバージョン”のリストとして、“ソフトウェアＢ  バージョン３．４”、“ファームウェアＣ  バージョン７．２”、および、“ファームウェアＤ  バージョン１．４”のメッセージを含む。
【０２０８】
実行ボタン８２は、“不整合を回避するコンポーネントのバージョン”を適用せずにリストアを実行する指示入力を受け付けるボタンである。
バージョン変更ボタン８３は、“不整合を回避するコンポーネントのバージョン”を、該当のコンポーネントに適用してリストアを行う旨の指示入力を受け付けるボタンである。
【０２０９】
キャンセルボタン８４は、リストアのキャンセル入力を受け付けるボタンである。
ユーザは、入力デバイス６２を操作することで、ポインタ８５により、実行ボタン８２、バージョン変更ボタン８３またはキャンセルボタン８４に対する入力を行える。
【０２１０】
依存関係判定部１１６は、バージョン変更ボタン８３に対する入力を受け付けると、連携指示部１１７に対して、該当のコンポーネントのバージョン変更を指示する。連携指示部１１７は、ＦＷ更新部１２２やリストア制御部１３３と連携して、業務サーバ２００や外部機器における該当のコンポーネントのバージョンを変更させる。各コンポーネントのバージョンについては、ソフトウェアＡのリストア前に変更させてもよいし、リストア後に変更させてもよい。
【０２１１】
こうして、管理サーバ１００は、リストアによりソフトウェアやファームウェアの動作に不具合が発生することを防ぐことができる。
ところで、近年、情報処理システムは複数のハードウェアやソフトウェアにより複雑に構成されており、それぞれの製品のバージョンにおける依存関係や整合性を考慮したシステム構築が求められている。特に、ハードウェアについては、当該ハードウェアを制御するファームウェア（制御用のソフトウェアともいえる）が実装され、ハードウェアの状態を監視する監視機構が組み込まれていることが多い。このため、ハードウェアであっても、実際の運用に用いる場合には、ファームウェアのバージョン毎の機能差や既存障害の考慮を要する。また、一部のソフトウェアについては、ハードウェアの制御（起動・シャットダウン）やハードウェア情報を収集するために、ファームウェアとの連携を行う。
【０２１２】
また、情報処理システムで行われるバックアップ処理では、一般的にソフトウェア（ＯＳ、ミドルウェア、データ／設定など）をバックアップする。一方、ファームウェアは、バックアップ対象外であることが多い。ところが、前述のように、ソフトウェアとハードウェアとは綿密に連携しているため、ソフトウェアの動作環境のみをリストアしても、システム全体としての安定稼働に支障をきたす可能性がある。また、同様に、ハードウェア同士の接続性に関しても、ファームウェアのバージョンにより機能差が存在すると、不整合が発生し、該当のハードウェアが正常に動作しないことがある。
【０２１３】
この点について、通常は、ソフトウェアのバックアップ／リストアとソフトウェアが動作する機器のファームウェアの管理を独立して行うことが多い。すなわち、システム単位でバックアップデータとシステムを構成するコンポーネントのバージョン情報を管理する仕組みや、リストアを実行する前に、これらのコンポーネント間でバージョンの不整合により問題が発生することを未然に防ぐ仕組みがなかった。
【０２１４】
例えば、ある時点で取得されたバックアップデータを用いてリストアする場合、バックアップデータに含まれるソフトウェアのバージョンと、システムを構成する他のソフトウェア、ファームウェアのバージョンとがバックアップ時点と異なっている可能性が高い。
第１の時点で取得した、バックアップデータに含まれるソフトウェアＳＡ（ｖ１．０）は、バックアップを取得した時点ではファームウェアＦＢ（ｖ１．０）と整合性の取れた状態である。第２の時点では、ファームウェアＦＢが運用中に新しいバージョン（ｖ２．０）にアップデートされていたとする。第２の時点でソフトウェアＳＡ（ｖ１．０）とファームウェアＦＢ（ｖ２．０）で整合性が取れていない場合、第１の時点のバックアップをリストアすると、問題が発生する。
【０２１５】
この様に、システムを構成するコンポーネント間の依存関係に問題が無いことを確認する必要があるが、複雑な依存関係を全て網羅した状況で整合性を確認することが難しい。また、各コンポーネント間の整合性については、ある時点で障害といった問題が発生した際に、依存するバージョン情報をタイムリーに把握する必要があるが、この様な情報に追随することは手動では困難である。
【０２１６】
より具体的には、あるバックアップデータをリストアする際には、以下のようなケースが運用上想定される。第１のケースは、極力バックアップ時の組合せに近い状態で整合性を合わせるケースである。また、第２のケースは、極力既にアップデート済みの状態を活かして整合性を担保する組合せを導き出すケースである。前者の場合は、全てのファームウェアをバックアップ時のバージョンに戻すことが最適と考えられる。しかし、古いバージョンに戻すことが不可能な場合や、古いバージョンへ戻すことに伴って機器やＯＳの再起動が必要になる場合が想定され、システムに対する影響度も考慮し、適用の可否を検討する必要がある。このように、それぞれの機器の複雑な依存関係を確認しながら、整合性が担保される組合せを導き出すことは困難であり、最適なポリシーに従って最適な解を導き出すには複数のパラメータを考慮する必要があり、困難である。
【０２１７】
そこで、管理サーバ１００は、ソフトウェアのバックアップに加えて、リストア時にファームウェアとの整合性を確保する機能を有する。
具体的には、管理サーバ１００は、バックアップ時にシステムを構成するコンポーネント（ハードウェアとソフトウェア）の構成リストと、各バージョンの情報を取得し、バックアップデータの識別情報に対応付けてバックアップ管理テーブル１５１に記録する。管理サーバ１００は、バックアップ管理テーブル１５１により、過去のバックアップ取得時点を安定稼働していたシステムの構成情報（各コンポーネントのバージョンの組合せ）の実績として使用可能である。また、管理サーバ１００は、公開サーバ４００からもユーザが安定稼働していると判断した異なる外部システムの構成情報を取得してもよい。更に、管理サーバ１００は、ソフトウェアなどのベンダが定期的に実施する動作検証結果（複数の機器を組合せた動作検証）の結果を使用することも可能である。
【０２１８】
各コンポーネントは動作要件として、依存する他のコンポーネントおよび他のコンポーネントのバージョンが存在する。管理サーバ１００は、各コンポーネントの他のコンポーネントとの依存関係を示す依存関係テーブルを保持し、複数のコンポーネントの依存関係を満たす組合せを導き出す。これにより、各コンポーネントについて動作要件を満たすバージョンの組合せを得ることができる。この際に、管理サーバ１００は、実際にシステムの運用方針に応じたポリシーに従って、適切な組合せを特定できる。また、管理サーバ１００は、特定した組合せのバージョンに合わせるため、既存のソフトウェアやファームウェアのアップデートやダウングレードの実行を可能とする。
【０２１９】
上記ポリシーは、ユーザによって予め指定可能である。例えば、最も安定稼働が考えられるのは、バックアップ時と同等のバージョンの組合せであるが、通常はバックアップ時より複数の機器のファームウェアが更新されている可能性がある。この場合、動作要件を満たしつつ、バックアップ時の最も近いバージョンに近づけることや、その他のシステムおよび開発元が組合せ検証として実績がある組合せに近づけるポリシーを予め用意することができる。
【０２２０】
更に、バージョンアップやバージョンダウンを実施すると、該当の装置の再起動が必要な場合が想定される。このため、管理サーバ１００は、再起動テーブル１９１を保持する。例えば、構成されるシステムがクラスター構成であれば、冗長化されているため、システムが許容可能な範囲であれば再起動可能である。逆に、冗長化されていない機器であれば再起動することはシステムが停止することとなり、システムの運用に影響が出る。この様に、システム構成に合わせ、システムへの影響を最小にすることを可能とする方針を予め用意し、コンポーネントのバージョン変更に伴うシステムへの影響を抑えられる。
【０２２１】
以上のように、管理サーバ１００によれば、バックアップ時点の各コンポーネントのバージョンをバックアップデータと関連付けて管理し、業務サーバ２００のリストア処理時に復元対象のソフトウェアの復元先のバージョンとの整合性を事前に確認可能にする。これにより、復元後のシステムにおけるソフトウェアやハードウェアの動作に不具合が発生する可能性を減らし、システム全体として安定稼働するように支援できる。また、管理サーバ１００は、復元により整合性の取れなくなるコンポーネントを表示する際に、ユーザにより選択されたポリシーに応じて、整合性が保証される組合せを提示することで、コンポーネントのバージョン変更に伴うユーザの作業の省力化を図れる。また、バージョン変更に伴う運用中にシステムに対する影響を抑えられる。
【０２２２】
なお、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体６３に記録できる。
【０２２３】
例えば、プログラムを記録した記録媒体６３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体６３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【０２２４】
以上の第１，第２の実施の形態を含む実施形態に関し、更に以下の付記を開示する。
（付記１）  整合性を確認済であるソフトウェアのバージョンとファームウェアのバージョンとの組合せの情報を記憶する記憶部と、
対象装置の動作環境を復旧する際に、前記対象装置における前記ソフトウェアの復元先のバージョンと前記対象装置のハードウェアに対応する前記ファームウェアの現在のバージョンとの組合せを確認し、前記記憶部に記憶された前記情報に基づいて、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンの少なくとも１つの変更の要否を判定し、変更要と判定すると前記変更のための組合せを特定する処理部と、
を有する情報処理装置。
【０２２５】
（付記２）  前記処理部は、指定されたポリシーに応じて、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンのうち、変更対象を決定する、付記１記載の情報処理装置。
【０２２６】
（付記３）  前記処理部は、前記ソフトウェアの復元先のバージョンを変更対象に決定すると、前記ファームウェアの現在のバージョンに対して整合性を確認済である前記ソフトウェアのバージョンのうち、最新のバージョンまたは復元先のバージョンとの差が最小のバージョンを、変更後のバージョンとして特定する、付記１または２記載の情報処理装置。
【０２２７】
（付記４）  前記処理部は、前記ファームウェアの現在のバージョンを変更対象に決定すると、前記ソフトウェアの復元先のバージョンに対して整合性を確認済である前記ファームウェアのバージョンのうち、最新のバージョンまたは現在のバージョンとの差が最小のバージョンを、変更後のバージョンとして特定する、付記１または２記載の情報処理装置。
【０２２８】
（付記５）  前記処理部は、変更後のバージョンの候補のうち、適用後の前記対象装置の再起動が不要である候補がある場合、前記再起動が不要である前記候補の中から、変更後のバージョンを特定する、付記３または４記載の情報処理装置。
【０２２９】
（付記６）  前記ファームウェアは、複数であり、
前記処理部は、前記記憶部に記憶された前記情報に基づいて、複数の前記ファームウェアそれぞれの現在のバージョンに対して整合性を確認済である前記ソフトウェアのバージョン範囲を特定し、前記ソフトウェアの復元後のバージョンが前記バージョン範囲に属するか否かに応じて、前記変更の要否を判定する、
付記１乃至５の何れか１つに記載の情報処理装置。
【０２３０】
（付記７）  前記処理部は、前記記憶部に記憶された前記情報に基づいて、前記ファームウェアの現在のバージョンおよび前記対象装置における他のソフトウェアの現在のバージョンに対して整合性を確認済である前記ソフトウェアのバージョン範囲を特定し、前記ソフトウェアの復元後のバージョンが前記バージョン範囲に属するか否かに応じて、前記変更の要否を判定する、付記１乃至５の何れか１つに記載の情報処理装置。
【０２３１】
（付記８）  前記ハードウェアは、前記対象装置の外部にあり、前記対象装置と接続されている外部ハードウェアを含む、付記１乃至７の何れか１つに記載の情報処理装置。
（付記９）  前記処理部は、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンの少なくとも１つに対して特定された変更後のバージョンを表示装置により表示させる、付記１乃至８の何れか１つに記載の情報処理装置。
【０２３２】
（付記１０）  前記処理部は、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンの少なくとも１つに対して特定された変更後のバージョンの適用を前記対象装置に指示する、付記１乃至９の何れか１つに記載の情報処理装置。
【０２３３】
（付記１１）  対象装置の動作環境を復旧する際に、前記対象装置におけるソフトウェアの復元先のバージョンと前記対象装置におけるハードウェアに対応するファームウェアの現在のバージョンとの組合せを確認し、
整合性を確認済である前記ソフトウェアのバージョンと前記ファームウェアのバージョンとの組合せの情報に基づいて、前記ソフトウェアの復元先のバージョンおよび前記ファームウェアの現在のバージョンの少なくとも１つの変更の要否を判定し、変更要と判定すると前記変更のための組合せを特定する、
処理をコンピュータに実行させるプログラム。
【符号の説明】
【０２３４】
１０，２０  情報処理装置
１１  記憶部
１２  処理部
２１，２３ａ，３１  メモリ
２２，２３ｂ，３２  プロセッサ
２３  ハードウェア
３０  外部ハードウェア
Ｎ１  ネットワーク
Ｔ１  バージョン管理テーブル
Ｒ１  復旧指示
Ｒ２，Ｒ３  警告
【図１】
2019020798.tif 000003
【図２】
2019020798.tif 000004
【図３】
2019020798.tif 000005
【図４】
2019020798.tif 000006
【図５】
2019020798.tif 000007
【図６】
2019020798.tif 000008
【図７】
2019020798.tif 000009
【図８】
2019020798.tif 000010
【図９】
2019020798.tif 000011
【図１０】
2019020798.tif 000012
【図１１】
2019020798.tif 000013
【図１２】
2019020798.tif 000014
【図１３】
2019020798.tif 000015
【図１４】
2019020798.tif 000016
【図１５】
2019020798.tif 000017
【図１６】
2019020798.tif 000018
【図１７】
2019020798.tif 000019
【図１８】
2019020798.tif 000020
【図１９】
2019020798.tif 000021
【図２０】
2019020798.tif 000022
【図２１】
2019020798.tif 000023
【図２２】
2019020798.tif 000024
【図２３】
2019020798.tif 000025
【図２４】
2019020798.tif 000026
【図２５】
2019020798.tif 000027