JP2004361994A - データ管理装置、データ管理方法及びプログラム - Google Patents
データ管理装置、データ管理方法及びプログラム Download PDFInfo
- Publication number
- JP2004361994A JP2004361994A JP2003155928A JP2003155928A JP2004361994A JP 2004361994 A JP2004361994 A JP 2004361994A JP 2003155928 A JP2003155928 A JP 2003155928A JP 2003155928 A JP2003155928 A JP 2003155928A JP 2004361994 A JP2004361994 A JP 2004361994A
- Authority
- JP
- Japan
- Prior art keywords
- data
- operating system
- management
- storage device
- target operating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operations
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operations
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking using middleware or operating system [OS] functionalities
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operations
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking using middleware or operating system [OS] functionalities
- G06F11/1484—Generic software techniques for error detection or fault masking using middleware or operating system [OS] functionalities involving virtual machines
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2105—Dual mode as a secondary aspect
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
【課題】計算機の障害復旧に必要なデータを従来よりも確実に保存することのできるデータ管理装置を提供すること。
【解決手段】管理対象となる動作ＯＳ１よりも安全性を高めた管理用ＯＳ２を用意し、この管理用ＯＳ２は、ＯＳ状態検出部２０１が動作ＯＳ１の状態を検出するとともに、データ抽出部２０２が動作ＯＳ１の記憶装置１０２のデータを読み出すという形で両ＯＳが連携して動作し、障害復旧に必要な全ての情報が逐次管理ＯＳ２の持つ記憶退避装置２０３に残ることが保証される。これによって、データ保存のスケジューリングの難しさを取り除き、コンピュータウイルス被害等によってデータ管理システムそのものが障害を受ける危険性があるという問題点が解決される。
【選択図】 図１
【解決手段】管理対象となる動作ＯＳ１よりも安全性を高めた管理用ＯＳ２を用意し、この管理用ＯＳ２は、ＯＳ状態検出部２０１が動作ＯＳ１の状態を検出するとともに、データ抽出部２０２が動作ＯＳ１の記憶装置１０２のデータを読み出すという形で両ＯＳが連携して動作し、障害復旧に必要な全ての情報が逐次管理ＯＳ２の持つ記憶退避装置２０３に残ることが保証される。これによって、データ保存のスケジューリングの難しさを取り除き、コンピュータウイルス被害等によってデータ管理システムそのものが障害を受ける危険性があるという問題点が解決される。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、計算機に係る障害を復旧させるために計算機に係るデータの待避や復元を行うデータ管理装置、データ管理方法及びプログラムに関する。
【０００２】
【従来の技術】
計算機の障害は、ハードウェアの故障またはソフトウェア（記憶装置のデータ）の誤った修正等によって起こるが、障害復旧にあたっては、障害発生以前におけるソフトウェアの状態を正確に復元させることができるか否かが最も重要なポイントである。従来より知られている計算機障害復旧装置においては、大まかに３つの手法がある。
【０００３】
まず、第１の方法は、記憶装置を多重化し、動作ＯＳが第１の記憶装置に書き込んだのと同じデータを第２の記憶装置にも書き込むことにより、万一、第１の記憶装置のデータが破壊されても第２の記憶装置に保存されたデータを利用し復元させる方法である。例えば、動作ＯＳから第２の記憶装置は直接アクセスできない仕組みにしておき、障害が発生した時点で起動記憶装置（起動ディスク）を第１の記憶装置から第２の記憶装置に切替えることにより、瞬時に障害復旧することが可能となる（例えば、特許文献１参照）。この方式は、ハードディスク等の記憶装置が物理的に動作不能になった場合など、即座に直前の障害発生時に復旧できるという利点のあるものである。しかし、計算機の障害発生後に直ちに完全に動作不能となるタイプの障害発生はあまり多くなく、実際には、障害発生後も動作を続け、例えば数日後に障害報告を受けて障害復旧を試みる場合が多いのであるが、この方式によれば過去の障害発生時のデータは既に廃棄されているから、障害を復旧することはできない。すなわち、どの時点が障害発生のタイミングであるかを、リアルタイムには検出できないから、この方式では障害復旧に必要なデータは失われてしまう可能性が極めて高い。
【０００４】
次に、第２の方法として、動作ＯＳ上に、データのバックアップのためのソフトウェアを常時動作させ、または必要と思われるタイミングに動作させることにより、動作ＯＳが変更した記憶装置内のデータを逐次第２の記憶装置に保存していく方法がある。例えば、新しいアプリケーションのインストールによって障害が発生することを防ぐために、アプリケーションのインストール直前の状態（スナップショット）を保存しておくという方式がある。例えば、米国ＭｉｃｒｏｓｏｆｔＴＭ社製品のＷｉｎｄｏｗｓ ＭｅＴＭ（２０００年９月発売）に「システムの復元」という機能として実装されている（例えば、非特許文献２参照）。この方式を利用すれば、第１の方法とは異なり、複数の状態を保存しておくことが可能であるから、障害復旧に必要なデータが残っている可能性が高まる。しかし、この方式は、障害復旧に必要なデータもまた動作ＯＳのデータとして管理されているため、障害復旧のためのソフトウェア自身が障害を受ける可能性があり、やはり障害復旧に必要なデータは失われている可能性が高い。例えば、今日多く見られるコンピュータウイルスと呼ばれるシステム破壊を目的としたソフトウェアによって受ける被害に対してはほとんど無力であることが問題となっている。
【０００５】
次に、第３の方法として、動作ＯＳとは別に、データのバックアップを目的とするＯＳを別途動作させることにより、バックアップ作業の際に一旦動作ＯＳを停止（シャットダウン）させ、停止している状態のデータを保存しておく方法がある。例えば、米国ｓｙｍａｎｔｅｃＴＭ社の「Ｎｏｒｔｏｎ ＧｈｏｓｔＴＭ」という製品などに採用されている（例えば、非特許文献３参照）。これは現在最も広く用いられている方法であり、動作ＯＳの挙動に全く影響されることなく障害復旧に必要なデータが確実に保存できるという利点がある。しかし、この方式は、保存すべき「動いている状態」が今であるということを予め知っていなければならないため、例えばＯＳを破壊するかもしれない危険な操作をする前に保存（バックアップ）しておくという目的には利用できるものの、一般にいつ発生するか判らない障害に対し、その障害発生前の状態に戻すという一番重要な目的にはほとんど役に立たない。
【０００６】
【非特許文献１】
Ａｐｐａｒａｔｕｓ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ ｐｒｏｖｉｄｉｎｇ ａ ｔｒａｎｓｐａｒｅｎｔ ｄｉｓｋ ｄｒｉｖｅ ｂａｃｋ−ｕｐ ＵＳＰ ６，１７５，９０４ （２００１／１／１６）
【０００７】
【非特許文献２】
ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｊａｐａｎ／ｅｎａｂｌｅ／ｔｒａｉｎｉｎｇ／ｋｂｌｉｇｈｔ／ｔ００６／３／１７．ｈｔｍ
【０００８】
【非特許文献３】
ｈｔｔｐ：／／ｗｗｗ．ｓｙｍａｎｔｅｃ．ｃｏｍ／ｒｅｇｉｏｎ／ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ
【０００９】
【発明が解決しようとする課題】
上述したように従来、計算機の障害復旧に必要なデータが保存されているか否かは、さまざまな状況に依存しており、必ずしも復旧することができる保証はないという問題があった。
【００１０】
本発明は、上記事情を考慮してなされたもので、計算機の障害復旧に必要なデータを従来よりも確実に保存することのできるデータ管理装置、データ管理方法及びプログラムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、対象オペレーティングシステムの持つ記憶装置のデータを管理するデータ管理システムにおいて、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムを設け、前記管理用オペレーティングシステムが、前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出する動作状態検出手段と、前記動作検出手段により検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出する抽出手段と、抽出された前記データを退避させるための退避用記憶手段とを備えたことを特徴とする。
【００１２】
好ましくは、前記管理用オペレーティングシステムは、前記対象オペレーティングシステムより高い安全性を有するものであるようにしてもよい。
【００１３】
また、本発明は、対象オペレーティングシステムの持つ記憶装置のデータを、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムにより管理するデータ管理方法であって、前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出するステップと、検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出するステップと、抽出された前記データを退避用記憶装置に退避させるステップとを有することを特徴とする。
【００１４】
また、本発明は、対象オペレーティングシステムの持つ記憶装置のデータを、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムにより管理するデータ管理装置としてコンピュータを機能させるためのプログラムであって、前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出する機能と、検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出する機能と、抽出された前記データを退避用記憶装置に退避させる機能とをコンピュータに実現させるためのプログラムである。
【００１５】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００１６】
本発明では、管理用オペレーティングシステムは対象オペレーティングシステムの動作状態を知り、例えば動作ＯＳが停止したことや新規アプリケーションをインストールしようとしていることなどの情報を得て記憶装置からデータを取り出すことができるため、ユーザが対象オペレーティングシステムの動作状態を意識することなく、障害復旧に必要なデータをより確実に退避させておくことが可能となり、障害発生以前の或る時点に復旧させるためのデータを持つことが可能になる。
【００１７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００１８】
（第１の実施形態）
図１に、本発明の第１の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。
【００１９】
図中、１は動作ＯＳ（対象オペレーティングシステム）、２は管理用ＯＳ（管理用オペレーティングシステム）（データ管理システム）である。動作ＯＳ１は、障害を復旧させたい対象のＯＳである。管理用ＯＳ２は、専ら動作ＯＳ１の障害復旧作業のために用意され、動作ＯＳ１の障害の障害復旧を目的として、動作ＯＳ１に関係するデータ（若しくはファイル）の退避などを行うためのＯＳである。詳しくは後述するように、管理用ＯＳは、動作ＯＳ１に比較してより高い安全性を持たせるようにするのが好ましい。
【００２０】
なお、一般にＯＳとは計算機を管理するソフトウェアの部分のみ指すこともあるが、本実施形態においては、記憶装置等の周辺機器をも含んだシステムを指すものとする。ただし、計算機システムは複数のＯＳがインストールされ稼働する場合があるので、ここでは、その一主体である動作ＯＳが利用する部分のみや管理用ＯＳが利用する部分のみを指すものとなる。
【００２１】
システム構成としては、大きく分けて、図２に示すように動作ＯＳ１と管理用ＯＳ２とが別々の計算機Ａ，Ｂ上で実現される構成と、図３に示すように動作ＯＳ１と管理用ＯＳ２とが同一の計算機Ｃ上で実現される構成とが可能である。前者の場合、動作作ＯＳ１と管理用ＯＳ２とを、ＬＡＮ等で接続して同一の計算機室や同一のビル内などの近接した場所に設置する形態や、広域ネットワーク等で接続して物理的に離れた場所に設置する形態など、種々の設置形態が可能である。
【００２２】
動作ＯＳ１は、プログラムの実行等を行うための処理実行部１０１と、処理実行部１０１がデータの書き込みや読み出し等を行う記憶装置１０２とを有する。
【００２３】
記憶装置１０２は、典型的には、ハードディスクやフラッシュメモリ装置などの物理的な記憶媒体であるが、処理実行部１０１がデータの書き込みや読み出しを行うものであれば、記憶媒体を持たないものであってもよい。例えば、動作ＯＳ１は通信回線を持ち、その通信回線を経由して外部の記憶装置にデータを書き込みおよび外部の記憶装置からデータを読み込むような場合も可能である。
【００２４】
管理用ＯＳ２は、ＯＳ状態検出部２０１とデータ抽出部２０２と記憶退避装置２０３を有する。
【００２５】
図４に、管理用ＯＳ２が記憶装置１０２のデータを退避する手順の一例を示す。
【００２６】
ＯＳ状態検出部２０１は、対象となる動作ＯＳ１の動作状態（動作状況）を検出する（ステップＳ１１）。すなわち、対象となる動作ＯＳ１の処理実行部１０１の動作状態に関する情報を取得する。
【００２７】
データ抽出部２０２は、検出された動作状態に応じて記憶装置１０２から退避すべきデータを抽出する（読み出す）（ステップＳ１２）。
【００２８】
データ抽出部２０２は、抽出したデータを、記憶退避装置２０３へ退避させる（書き込む）（ステップＳ１３）。
【００２９】
以下、ＯＳ状態検出部２０１による動作ＯＳ１の動作状態の検出について詳しく説明する。
【００３０】
動作の状態に関する情報としては、例えば、「処理実行部１０１が動作ＯＳ１の終了処理を行い、動作を停止する（すなわち、シャットダウンする）」という情報がある。
【００３１】
例えば、動作ＯＳ１が動作を停止する直前に停止の予告メッセージをネットワーク上に流す場合に、管理用ＯＳ２は、その予告メッセージを受信し、ＯＳ状態検出部２０１は、動作ＯＳ１が間もなく停止することを知る。
【００３２】
なお、この通知をより確実に行うために、例えば、予告メッセージを受信した管理用ＯＳ２が動作ＯＳ１のネットワークインターフェースに対するＩＣＭＰメッセージ（ＩＮＴＥＲＮＥＴ ＣＯＮＴＲＯＬ ＭＥＳＳＡＧＥ ＰＲＯＴＯＣＯＬ）を流すなどして、動作ＯＳ１が実際に停止したことを確認するようにしてもよい。
【００３３】
ここでは、予告メッセージがネットワーク上に流される場合を例にとって説明したが、管理用ＯＳ２に動作ＯＳ１の停止を伝える手段あるいはＯＳ状態検出部２０１が動作ＯＳ１の停止を検出する手段には特に限定はなく、どのような方法によってもよい。
【００３４】
動作の状態に関する情報の他の例としては、「処理実行部１０１が動作ＯＳ１の処理を開始する（すなわち、ＯＳをブートする）」という情報がある。
【００３５】
例えば、動作ＯＳ１が動作を開始した直後にＯＳの再起動メッセージをネットワーク上に流す場合に、管理用ＯＳ２は、その再起動メッセージを受信し、ＯＳ状態検出部２０１は、動作ＯＳ１が処理を開始したことを知る。
【００３６】
この再起動メッセージには、動作ＯＳ１の起動オプションを含むとより効果的である。起動オプションは、例えば、動作ＯＳ１がどのようなサービス（デーモン）を実行しようとしているか、ＯＳのバージョンは何か、何の目的で動作ＯＳ１が起動されたかなどを示す情報である。例えば、この動作ＯＳ１がＣＡＤシステムの利用を目的として起動されたことが予め判っていれば、その情報を後述するデータ抽出部２０２が利用し、ＣＡＤファイルの更新を優先して処理するといった効率化が可能になる。また、起動オプションに相当する情報は、再起動メッセージに含む方法をとるのではなく、単独のメッセージとして随時送信する方法をとっても構わない。
【００３７】
ここでは、再起動メッセージがネットワーク上に流される場合を例にとって説明したが、管理用ＯＳに動作ＯＳ１の再起動を伝える手段あるいはＯＳ状態検出部２０１が動作ＯＳ１の再起動を検出する手段には特に限定はなく、どのような方法によってもよい。
【００３８】
また、動作の状態に関する情報のさらに他の例としては、動作ＯＳ１そのものの内部動作に関する情報が考えられる。
【００３９】
例えば、「処理実行部１０１が記憶装置１０２に対してデータの書き込みを行った」という情報である。この場合、全てのデータ書き込み情報を逐一利用してもよいし、処理を効率化するために特定のデータ書き込み情報のみを利用してもよい。
【００４０】
後者の特定のデータ書き込みとは、例えば、ＯＳのシステム領域の書き換えなどの重大な書き込みであったり、あるいは、アプリケーションのインストール時に作成されるファイルへの書き込みであったりする。何を特定のデータ書き込みとして扱うべきかについては、動作ＯＳ１の性質やまたその利用目的などに応じて決定するのが好ましい。これは、例えば、動作ＯＳ１の性質や利用目的などから特定のデータ書き込みを求めるためのルールを定義ファイルに記述するなどして実現することができる。
【００４１】
また、動作の状態に関する情報に含まれるデータの中身に関しても、書き込みしたファイル名であることも考えられるし、また、その記憶装置上の場所（トラック番号やファイルのノード番号等）であることも考えられるし、また、場合によってはファイルの更新内容（３行目のデータをこのようなデータに書き換えた等）であることも考えられる。こういったルールも同様に定義ファイルに記述するなどして実現するようにしてもよい。
【００４２】
動作の状態に関する情報のさらに他の例としては、動作ＯＳ１が他の計算機と通信を行ったというものが考えられる。
【００４３】
これも、例えば、前述したデータ書き込みの場合と同様、全ての通信記録の中からルールに従って必要な情報を採用すればよい。例えば、ＯＳのアップデートをするための通信（すなわち、アップデートサイトとの通信）があれば、重要な変更がなされると予測することができるし、危険なＷＷＷサイト（例えば、多くの複雑なスクリプトが書かれたサイトや、危険だと予め判っているサイトなど）へのＷＷＷアクセスがあれば、コンピュータウイルスが入った可能性があると推定することができる。
【００４４】
なお、上記では、予め定められた動作状態が検出された場合に、該動作状態に応じて記憶装置１０２から退避すべきデータを抽出し、これを記憶退避装置２０３へ退避させるものであったが、これに加えて、予め定められた時間が経過するごとにも、記憶装置１０２から退避すべきデータを抽出し、これを記憶退避装置２０３へ退避させるようにしてもよい。なお、予め定められた動作状態が検出されたことと、予め定められた時間が経過したこととが同時に発生した場合には、例えば、前者を優先するものとしておけばよい。
【００４５】
次に、データ抽出部２０２による退避すべきデータの記憶装置１０２からの読み出し及び記憶退避装置２０３へのデータ退避について詳しく説明する。
【００４６】
データを記憶装置１０２から読み出す方法は主として２通りの方法が可能である。１つは、実際に記憶装置１０２に記憶されているデータを通常のデータ読み出しと同様の方法で読み出す方法であり、もう１つは、処理実行部１０１から記憶装置１０２への書き込み命令が出た際にその信号を直接読み取ることによってデータを読み出すのと同等の効果を得る方法である。ただし、前記したような物理的な記憶装置を内包しない記憶装置の場合には後者の方法を用いる。
【００４７】
データ抽出部２０２は、抽出したデータを、記憶退避装置２０３へ書き込む。この書き込みは、通常のファイルシステム等の書き込みとは異なり、時系列を考慮した書き込みとなる（例えば、あるデータを記憶装置１０２から読み出した時刻もしくは記憶退避装置２０３へ書き込んだ時刻を、該あるデータに対応付けて保存しておく）。すなわち、当該データの更新履歴を管理するのと同様の処理を行う。
【００４８】
例えば、図５に示すように、３日前にデータ抽出部２０２が取り出し記憶退避装置２０３に書き込んだ“ｆｏｏ”という名前のファイルのデータ（このときの内容をａで表す）が存在する場合、その後（例えば、１日前）に再度データ抽出部２０２が“ｆｏｏ”という名前のファイルのデータ（このときの内容をｂで表す）を取り出して記憶退避装置２０３の同一名のファイルのデータに上書きすると、３日前の状態に復旧させるためのデータ（すなわち、内容ａのデータ）が欠落してしまうから、例えば障害発生が２日前であったとすると、その障害を復旧させることができない可能性が出てしまう。そこで、各時点（例えば、各退避時点）における同一名のファイルのデータはそれぞれ区別して、それぞれが保存されるような方法によって、この書き込みを行う。なお、この区別は、例えば、記憶退避装置２０３に退避した時刻や、バージョン番号等によって行えばよい。図６は、“ｆｏｏ”という名前のファイルのバージョンで内容を区別して、各バージョンのデータを保存するようにした例である。
【００４９】
また、例えば、ファイル“ｆｏｏ”が一旦削除された後に、 “ｆｏｏ”という名前のファイルが再度作成される場合があるので（削除されてから再度作成されるまでの間、ファイル“ｆｏｏ”は存在しないことになる）、“ｆｏｏ”が削除された場合には、その旨を示す情報を記憶退避装置２０３に保存しておくのが望ましい。図７は、ｔ３の時点でファイル“ｆｏｏ”が削除されたことを示す情報を退避した例を示す（なお、ｆｏｏ（ｔ４，ｖｅｒ１）は、ｆｏｏ（ｔ１，ｖｅｒ１）とは、バージョン番号は同じであるが、時刻情報が異なるので、内容は異なる）。
【００５０】
また、ファイル“ｆｏｏ”が新たに作成されたものか、修正されたものか、削除されたものかの区別を示す情報を、ファイル“ｆｏｏ”に対応付けて保存しておくようにしてもよい。
【００５１】
また、例えば、パス名の異なる“ｆｏｏ”という名前のファイルが複数存在し得る場合には、それらは異なるファイルとして扱うものとする。
【００５２】
データ抽出部２０２が記憶装置１０２より抽出したデータを記憶退避装置２０３に書き込むにあたっては、ＯＳ状態検出部２０１によって検出された動作ＯＳ１の動作状態を示す情報を利用すると好ましい。これは動作ＯＳ１の状態を保存するには動作ＯＳ１の現況（現在の動作状態）を意識しておくのが望ましいからである。
【００５３】
例えば、動作ＯＳ１が完全に停止した状態であれば、データ抽出部２０２が記憶装置１０２よりデータを取り出している間に記憶装置１０２のデータが変更されることがないことが保証されることになる。このような場合には、データの取り出しのスケジューリングを意識する必要がなくなり、とにかく考えられる全てのデータを保存しておけばよい。そのデータに基づけば、次に動作ＯＳ１が起動（電源オン）するであろう時点での状態を将来いつでも取り出すことができる。
【００５４】
一方、動作ＯＳ１が動作している場合にはデータ抽出部２０２が記憶装置１０２よりデータを取り出している間にも、記憶装置１０２のデータが変更されることがある。このような場合には、データ抽出部２０２がやみくもに記憶装置１０２のデータを読み出すのでは効率が良くない場合がある。例えば、ユーザが特定の文書ファイルを編集していることが把握できるときには、関連ファイルが秒単位で変更されることがあり得るのであり、そういったファイルに注目して重点的にデータを取り出すと効果的である。
【００５５】
また、他のケースとしては、動作ＯＳ１が新たなアプリケーションを登録しようとしている際には、システム関連のファイル変更が重要なポイントとなり、それらのファイル（共通のライブラリファイルや、システム設定ファイルなど）に注目して重点的にデータを取り出すと効果的である。
【００５６】
これらは、例えば、動作ＯＳ１の性質を考慮した上でデータ抽出部２０２のアルゴリズムを設計すると、より効果を発揮する場合もある。例えば、現在知られているいくつかのＯＳでは、ユーザが最近編集したファイルを簡単に取り出せる仕組みが用意されており、最近編集されたファイルの一覧あるいはそれらファイルへのポインタが一箇所にまとまって管理されている。動作ＯＳ１が、そのような性質のＯＳである場合には、当該動作ＯＳ１に対しては、その情報を利用することにより、ユーザが現在どのようなファイルを重点的に操作（変更）しているかを知り、データの取り出しの際の情報とすることができる。
【００５７】
また、例えば、現在知られているいくつかのＯＳでは、新規のアプリケーションをインストール（登録）したりアンインストール（削除）したりするためのインタフェースが統一されており、アプリケーションのインストールやアンインストールを行う際には、必ず決められたソフトウェアが起動することになっている。動作ＯＳ１が、そのような性質のＯＳである場合には、当該動作ＯＳ１に対しては、その情報を利用することにより、現在、障害復旧を行うにあたっての重要な変更が行われようとしていることを、データ抽出部２０２が知ることにより、データの取り出しの際の情報とすることができる。
【００５８】
なお、データ抽出部２０２が記憶装置１０２より抽出したデータを記憶退避装置２０３に書き込むにあたっては、ＯＳ状態検出部２０１によって検出された動作ＯＳ１の動作状態を示す情報をも当該データに対応つけて記憶するようにしてもよい。
【００５９】
以上のように、管理用ＯＳ２が動作ＯＳ１の動作状態を知り、例えば動作ＯＳ１が停止したことや、新規アプリケーションをインストールしようとしていることなどの情報を得て記憶装置１０２からデータを取り出すことができるようにすることによって、ユーザが動作ＯＳ１の状態を意識することなく、障害復旧に必要なデータを保存しておくことが可能となり、バックアップのし忘れの心配がなくなるため、種々多様な状況で障害が発生した場合においても、障害発生以前の任意の時点に復旧させるためのデータを記憶退避装置２０３に持つことが保証される（あるいは、それが期待される）。
【００６０】
例えば、実際の障害発生から３日後に障害発生を認識した場合に、１日前や２日前の保存データを用いたときには障害発生前の状態が得られないので、障害を復旧させることはできないが、３日前の保存データを用いたときには障害が復旧されることを知ることができ、記憶装置１０２の状態を３日前の状態に戻すことによって、障害発生直前の状態に計算機を復旧させることが可能となる。
【００６１】
なお、記憶退避装置２０３に退避したデータをユーザが直接利用できないようにしてもよい。このようにすれば、たとえコンピュータウイルスを含むファイルが記憶退避装置２０３に退避されていても、コンピュータウイルスが発動しない蓋然性が非常に高くなり、管理用ＯＳ２側がコンピュータウイルスにより被害を受けることを未然に防止することができる。
【００６２】
ところで、仮に管理用ＯＳ２の安全性が動作ＯＳ１の安全性と同程度又はそれ以下であると、コンピュータウイルスのような悪意のソフトウェアによって動作ＯＳ１が被害を受けた場合、同じ原因により、管理用ＯＳ２も同時に被害を受け、結局、障害復旧することはできない危険性があるので、好ましくは、管理用ＯＳ２を動作ＯＳ１よりも安全性を高めたものにしておくのが望ましい。このようにすれば、管理用ＯＳ２が動作ＯＳ１と同時に障害を発生する確率を概ねゼロに（あるいは、非常に低く）することができる。
【００６３】
一般に動作ＯＳ１はアプリケーション実行に必要なさまざまな機能を実現しなくてはならないので安全性をあまり高めることができないが、管理用ＯＳ２は機能を限定することができるため動作ＯＳ１に比べ安全性を高めることが比較的容易に可能である。
【００６４】
例えば、動作ＯＳ１がＷＷＷサーバである場合、ＷＷＷサーバのセキュリティーホールにより障害を受ける危険性があるが、管理用ＯＳ２にはＷＷＷサーバをインストールしておく必要がないため、かかる原因により管理用ＯＳ２に障害が発生することはあり得ない。したがって、動作ＯＳ１よりも安全性を高めた管理用ＯＳ２に動作ＯＳ１の障害復旧機能を分離するという構成を採ることによって、従来よりも確実性の高い計算機システムを実現することが可能となる。
【００６５】
上記のように、管理用ＯＳ２の安全性を動作ＯＳ１に比較してより高めておくことによって、仮に動作ＯＳ１がコンピュータウイルス等によって破壊されたとしても管理用ＯＳ２は破壊されないことが期待される。ここで、安全性を高めるとは一般にいくつかの方法がある。
【００６６】
まず、第１に、（ＯＳそれ自体に）セキュリティ・ホールが少ない（又は無い）ことが知られているＯＳを管理用ＯＳ２に採用する方法がある。この場合、管理用ＯＳ２は、必ずしも絶対的にセキュリティ・ホールが少ないもの（例えば、現に存在する最もセキュリティ・ホールが少ないＯＳ）でなくても、動作ＯＳ１に比較して、よりセキュリティ・ホールの少ないＯＳを用いて構わない（よりセキュリティ・ホールの少ないＯＳが、セキュリティ・ホールの無いＯＳであれば、理想的である）。動作ＯＳ１においては、目的とするアプリケーションを動作させる必要があるため、必ずしも安全なＯＳを選択することはできないが、管理用ＯＳ２においては、安全なＯＳを選択するということが可能である。
【００６７】
第２に、（動作ＯＳ１と管理用ＯＳ２とに同じＯＳが用いられているか、あるいは動作ＯＳ１と管理用ＯＳ２とで異なるＯＳが用いられているが各ＯＳの持つ安全性が同程度であるような場合であっても）、管理用ＯＳ２の機能を制限することによって安全性を高める方法がある。管理用ＯＳ２の機能は、動作ＯＳ１に比較して、より制限されていればよく、管理用の機能のみ持つようにしてもよいし、管理用の機能以外の機能をも持っていても構わない。動作ＯＳ１においては、目的とするアプリケーションを稼働させるために、必要となる多くのサービスをインストールし、動作させなければならず、また必要なプログラム（コマンド）も多くインストールしておかなければならないが、管理用ＯＳ２においては、動作ＯＳ１を管理するだけの目的に使えばよいので、不要となるサービス（ほとんどのサービス）を停止させておけば安全性が高まる。また、プログラム（コマンド）も必要なものは限られるため、不要なプログラム（コマンド）を削除しておけば、セキュリティ・ホールのあるコマンドの動作によってシステムが障害を受けるといった危険性を下げることが可能である。
【００６８】
第３に、管理用ＯＳ２は動作ＯＳ１とは異なる動作環境としておく方法がある。例えば、動作ＯＳ１がＷＷＷサーバであるとすれば、動作ＯＳ１は必ずインターネットに接続させる必要があるが、管理用ＯＳ２は動作ＯＳ１を管理するのが目的であるからその必要はない。また、ファイアウォールを運用するなどにより、ネットワーク外からの動作ＯＳ１へのアクセスに比較して、管理用ＯＳ２へのアクセスをより厳しく制限しておくことも可能である。また、音声の入出力ドライバなど、本システムに必要のない機能は管理用ＯＳ２では動作しないように設定しておくことも可能である。
【００６９】
以上例示した３つの手段は、少なくとも一つ採用すれば、安全性を高めたと言うことができるが、好ましくは複数を併用するとより安全性を高めることが期待される。
【００７０】
なお、上記の他にも、例えば、特に重要なデータを管理する場合などで、管理用ＯＳ２を多重化するといった手法により、システムの信頼性若しくは安全性を高める方法も可能である。その際、多重化した管理用ＯＳ２ごとに使用するＯＳを異ならせるようにしてもよい（多重化した管理用ＯＳ２の全てが同時にコンピュータウィルスの被害を受けたために記憶装置１０２のデータの退避が不能になることを、概ねゼロもしくは非常に低い確率にすることができる）。
【００７１】
以上説明したように、本実施形態では、動作ＯＳ１とは別に管理用ＯＳ２を設け、この管理用ＯＳ２が動作ＯＳ１の状態に応じてデータの退避等を行うことにより、動作ＯＳ１の障害復旧に必要なデータをユーザが意識することなく自動的に管理用ＯＳ２の記憶退避装置２０４に保存し続けることが可能になる。また、管理用ＯＳを動作ＯＳに比べてより安全性を高めるとより効果的である。ユーザは、待避された（保存された）データを用いて動作ＯＳ１の障害復旧を行うことができる。あるいは、待避された障害発生前のデータをもとにして所望のアプリケーションの実行を再開することができる。
【００７２】
（第２の実施形態）
次に、図８に、本発明の第２の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。
【００７３】
この構成例は、管理用ＯＳ２（データ管理システム）が、図１の構成例に加えて、データ復旧部２０４を備えている。データの退避の処理については基本的には第１の実施形態と同様である。以下では、第１の実施形態と相違する部分を中心に説明する。
【００７４】
図９に、管理用ＯＳ２が記憶退避装置２０３から記憶装置１０２へ退避データを書き戻す手順の一例を示す。
【００７５】
管理用ＯＳ２は、ユーザから復旧時点を指定する情報を含む復旧の指示を受ける（ステップＳ２１）。
【００７６】
データ復旧部２０４は、指定された復旧時点を指定する情報に基づいて、記憶退避装置２０３から、記憶装置１０２へ書き戻すべきデータを抽出する（ステップＳ２２）。
【００７７】
記憶退避装置２０３は、抽出したデータを、記憶装置１０２へ書き戻す（ステップＳ２３）。
【００７８】
復旧時点の指定には種々の方法が考えられる。
【００７９】
例えば、ユーザは、所望する日時（あるいは、現在から溯るべき時間等）を指定し、データ復旧部２０４は、記憶装置１０２の内容を復旧させることができる復旧可能時点（例えば、過去に実際にデータ退避が行われた時点）のうちから、指定された日時に最も近いもの（あるいは、指定された日時以前で最も近い当該指定された日時に最も近いもの）を選択し、記憶装置１０２の状態がその時点の状態になるように、記憶退避装置２０３から、記憶装置１０２へ書き戻すべきデータを抽出するようにしてもよい。
【００８０】
例えば、“ｆｏｏ”という名前のファイルの退避・復旧を例にとって説明する。図１０のように、“ｆｏｏ”という名前のファイルに関する情報が、時刻ｔ３，ｔ５，ｔ９，ｔ１４でそれぞれ退避されたとする。ただし、時刻ｔ３以前には当該ファイルは存在しないものとする。また、時刻ｔ９では当該ファイルが削除された旨の情報が保存されたものとする。例えば、ユーザから復旧時刻として時刻ｔ８が指定された場合に、“ｆｏｏ”という名前のファイルについては、時刻ｔ８以前で最も近い時刻ｔ５が選択され、そのときに退避されたバージョン番号２のデータによる復旧が行われる（例えば、バージョン番号２のデータが記憶装置１０２へ書き戻される）。また、例えば、時刻ｔ４が指定された場合には、時刻ｔ４以前で最も近い時刻ｔ３が選択され、そのときに退避されたバージョン番号１のデータによる復旧が行われる。また、例えば、時刻ｔ１２やｔ２が指定された場合には、“ｆｏｏ”という名前のファイルは存在しないので、そのための復旧がなされる（例えば、記憶装置１０２から“ｆｏｏ”という名前のファイルが削除される）。また、例えば、時刻ｔ１５が指定された場合には、時刻ｔ１５以前で最も近い時刻ｔ１４が選択され、そのときに退避されたバージョン番号１のデータによる復旧が行われる。なお、ｆｏｏ（ｔ１４，ｖｅｒ１）は、ｆｏｏ（ｔ３，ｖｅｒ１）とは、バージョン番号は同じであるが、時刻情報が異なるので、内容は異なる（ｆｏｏ（ｔ１４，ｖｅｒ１）は、“ｆｏｏ”という名前のファイルが一旦削除された後に再度作成されたものである）。
【００８１】
また、例えば、ユーザは、所望する日時等と、データを退避するにあたって検出された動作ＯＳ１の動作状態（例えば、シャットダウン、ブート、あるいはインストール等）とを指定し、データ復旧部２０４は、データを退避するにあたって検出された動作状態が指定された動作状態と一致する復旧可能時点のうちから、指定された日時に最も近いもの（あるいは、指定された日時以前で最も近い当該指定された日時に最も近いもの）を選択するようにしてもよい。
【００８２】
また、例えば、管理用ＯＳ２は、記憶退避装置２０３に記憶された情報をもとに、復旧可能時点を示す日時等（あるいは、日時等と動作ＯＳ１の動作状態との組合せ）を一覧表として提示し、ユーザは、提示された日時等（あるいは、日時等ととの組合せ）のうちから所望のものを選択するようにしてもよい。
【００８３】
また、ファイル名を指定して、当該ファイル名のファイルについてのみ、復旧処理できるようにしてもよい。
【００８４】
その他、種々のバリエーションが可能である。
【００８５】
以下、障害復旧を行う場合について詳しく説明する。
【００８６】
まず、動作ＯＳ１の障害の発生は、例えば、ハードウェアの故障の他、あるソフトウェアの動作中にそのソフトウェアの全部又は一部の機能が利用不能に陥ったことや、計算機が予期しない動作をしたことなどがユーザによって認識されるに至ることによって、発見される。
【００８７】
ユーザが動作ＯＳ１の障害発生を認識した場合、一旦、処理実行部１０１の動作を停止させ、ハードウェアの故障等があればその修理を行った後に、記憶装置１０２の内容を、障害発生前の状態に書き戻すことにより、障害を復旧することができる。
【００８８】
前述したように、障害復旧に必要なデータは記憶退避装置２０３に格納されていることが保証（あるいは期待）されているが、記憶退避装置２０３に格納されているデータは過去に記録した全てのデータ（あるいは時系列上で複数の時点での状態に係るデータ）であり、障害復旧に必要でないデータも含まれ得る。まず、データ復旧部２０４は、記憶退避装置２０３に格納されているデータから、記憶装置１０２に書き戻すべきデータを抽出する。
【００８９】
書き戻すべきデータが何であるかはケースバイケースであり、それは例えばシステム管理者等が判断する。例えば、３日前の午後３時に動作ＯＳ１がコンピュータウィルスの被害を受けたと判定された場合、その直前の状態に戻すことを試みる。それは、３日前の午後２時５９分頃の状態であるかもしれないし、またはそれ以前に動作ＯＳ１をシャットダウンした時刻、例えば３日前の午前５時であるかもしれない。あるいは、３日前の午前５時の状態に戻した上で、午後２時５９分までに特定部分（ディレクトリ）に追加されたファイルを加えたものであるかもしれない。これは運用している動作ＯＳ１の性質によって変わるものであり、システム管理者等が判断する。この判断情報を、データ復旧部２０４に入力することによって、データ復旧部２０４は障害復旧処理を開始する。
【００９０】
なお、上記ではシステム管理者等が判断情報を入力するとしたが、システム構成によっては入力しないものであっても、もちろんよい。例えば、常に、前回に動作ＯＳ１をシャットダウンした時点の状態に復旧するというものであってもよい。
【００９１】
データ復旧部２０４は、入力された復旧の方法を決める判断情報、または予め決められてる復旧方法に従い、記憶装置１０２に書き戻すためのデータを記憶退避装置２０３より取り出し、記憶装置１０２に書き込みを行う。記憶装置１０２への書き込みが終了したら、それはすなわち障害のない動作ＯＳ１の状態が再現できたということを意味するものであるから、再び処理実行部１０１が動作ＯＳ１の起動を行うことによって、障害の復旧を行うことができる。
【００９２】
なお、記憶装置１０２の状態をある時点の状態に復旧した後は、記憶退避装置２０３に保存されているデータのうち、その時点以降の任意の状態に復旧させるのに必要なデータを破棄するようにする構成も可能である。
【００９３】
ところで、動作ＯＳ１の障害の発生は認識できたが、記憶装置１０２の状態をどの時点の状態に戻せばよいか把握できない場合が考えられる。このような場合のために、例えば、データ復旧部２０４に、記憶装置１０２の状態を、ユーザが指定した状態に仮に戻す機能を設けるようにしてもよい。この場合、ユーザはその仮に戻した記憶装置１０２の状態で動作ＯＳ１を起動して障害が復旧しているかどうかを判断するといった操作を、指定する記憶装置１０２の状態を少しずつ過去に溯らせるようにして繰り返し行うことによって、障害が復旧する状態を見出し、このときの記憶装置１０２の状態に確定させる指示をユーザが管理用ＯＳ２に与え、この指示によって、データ復旧部２０４は、記憶装置１０２の状態を確定させるようにしてもよい。
【００９４】
（第３の実施形態）
次に、図１１に、本発明の第３の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。この構成例は、データ管理システムが、図８の管理用ＯＳ２の他に、遠隔管理装置３をも含むものである。データの退避や障害からの復旧の処理については基本的には第２の実施形態と同様である。以下では、図８の構成例と相違する部分を中心に説明する。
【００９５】
管理用ＯＳ２には、例えばネットワーク４等を介して、遠隔管理装置３が接続されている。遠隔管理装置３は、１つでも複数でもよい。ここでは、説明を簡略化するために、１つであるとする。なお、遠隔管理装置３は、例えば、典型的には、インターネットや電話回線等のネットワークを介してサーバセンタなどの離れた場所に設置する形態が可能であるが、これに限定されるものではなく、例えば、計算機の補助装置として遠隔管理装置３を採用し、動作ＯＳ１、管理用ＯＳ２、遠隔管理装置３を一体として設置する形態も可能である。
【００９６】
管理用ＯＳ２のデータ抽出部２０２は、記憶退避装置２０３に障害復旧に必要なデータを保存するのみならず、（遠隔記憶退避装置３０２へ保存させるために）遠隔管理装置３のデータ受信部３０１へも障害復旧に必要なデータを送信する。
【００９７】
記憶退避装置２０３と遠隔記憶退避装置３０２へのデータ保存方法には、記憶退避を２重化する第１の形態（記憶退避装置２０３と遠隔記憶退避装置３０２に同一のデータを保存する方法）、一部のデータのみについて２重化する第２の形態（遠隔記憶退避装置３０２には、記憶退避装置２０３に保存するデータの一部のデータのみを保存する方法）、データごとに保存方法を制御する第３の形態（データによって記憶退避装置２０３のみに保存するか遠隔記憶退避装置３０２のみに保存するか両方に保存するかを決定する方法）など種々の方法がある。
【００９８】
第２の形態の具体例としては、例えば、管理用ＯＳ２のデータ抽出部２０２は、管理用ＯＳ２自身の持つ記憶退避装置２０３へは、障害復旧に必要な全てのデータを保存し、遠隔管理装置３のデータ受信部３０１へは、障害復旧に必要なデータのうち特に重要なデータ（例えば、システムのライブラリファイルに関するデータ等）のみに限定して送信するという方法も考えられる。
【００９９】
データ受信部３０１は、受信したデータの全てを遠隔記憶退避装置３０２に保存する。なお、データ受信部３０１は、受信したデータのうち必要と判断される一部のみを遠隔記憶退避装置３０２に保存するようにする構成も可能である。
【０１００】
このように、障害復旧に必要なデータを記憶退避装置２０３だけでなく遠隔記憶退避装置３０２にも保存しておくことにより、より安全性を高めることが可能である。
【０１０１】
例えば、動作ＯＳ１と管理用ＯＳ２の両者が同一の場所にある場合には、火災などによって物理的に同時に破壊される場合があり得るが、遠隔管理装置３をインターネット等で接続された他の場所にあるサーバセンタ等に設置することにより、障害復旧に必要なデータをより確実に保管することができ、たとえ動作ＯＳ１と管理用ＯＳ２の両者が物理的に同時に破壊されたとしても、遠隔記憶退避装置３０２に保存されたデータを用いて障害復旧を行うことができる。
【０１０２】
また、典型的な利用例としては、遠隔管理装置３をインターネットで接続された特に安全に管理されたサーバセンタ内に設置することにより、管理用ＯＳ２の破壊などのリスクを意識することなく、いつでも障害の復旧できる計算機をユーザに提供できるという利点が生じる。
【０１０３】
遠隔データ復旧部３０３は、先に説明したデータ復旧部２０４の機能と同様、記憶装置１０２に書き戻すべきデータを取り出す機能を持つ。遠隔データ復旧部３０３は、遠隔記憶退避装置３０２より必要なデータを取り出し、データ復旧部２０４に送信する。データ復旧部２０４は、遠隔データ復旧部３０３から受信したデータのみを利用し、もしくは記憶退避装置２０３から取り出したデータのみを利用し、または遠隔データ復旧部３０３からのデータおよび記憶退避装置２０３からのデータを利用して、障害復旧に必要なデータの記憶装置１０２への書き込みを行う。あるいは、遠隔データ復旧部３０３は、データ復旧部２０４にデータを送信することなく、直接に記憶装置１０２へデータを送り、記憶退避装置２０３のデータを利用しないということも考えられる。また、これらの処理はオフラインで行われることも考えられる。つまり、通常はネットワークを介して遠隔管理装置３をサーバセンタで運用するが、障害発生の報告を受けたサーバセンタ職員が遠隔記憶退避装置３０２（ハードディスクなど）を動作ＯＳ１の設置場所に持参し、記憶装置１０２を復旧させるような場合もあり得る。
【０１０４】
なお、図１１の構成例は、図８の構成例に遠隔管理装置３を付加した場合であったが、図１に遠隔管理装置３（ただし、遠隔データ復旧部３０３は除く）を付加した構成も可能である。
【０１０５】
（第４の実施形態）
次に、図１２に、本発明の第４の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。この構成例は、障害復旧作業をさらに迅速に行えるようにするため、図１の記憶装置１０２の部分に記憶変換機能を付加したものである。データの退避の処理については基本的には第１の実施形態と同様である。以下では、第１の実施形態と相違する部分を中心に説明する。
【０１０６】
ここで、障害発生検知時には、図１２の動作ＯＳ１側の記憶退避装置２０３は、管理用ＯＳ２側に接続されており、第１の実施形態と同様に、障害からの復旧に必要なデータが保存されているものとする（図１参照）。
【０１０７】
また、障害発生が検知された後には、本実施形態では、動作用ＯＳ１の持っていた記憶退避装置（図示せず）が取り外されるとともに、管理用ＯＳ２の持っていた記憶退避装置２０３が取り外されて（実際に移送されて）動作ＯＳ１側へ接続される（図１２は、この状態を示している）。
【０１０８】
本実施形態では、処理実行部１０１は、データの読み出しや書き込みを記憶変換装置４０１に対して行う。
【０１０９】
記憶変換装置４０１は、処理実行部１０１から受けた書き込みデータを、接続された記憶退避装置２０３へそのまま書き込む。ここで、そのまま書き込むとは、時系列を考慮して必要なデータを破壊しないように書き込むという意味であり、これについては既に説明した図１におけるデータ抽出部２０２が記憶退避装置２０３に書き込みを行う場合と同様である。
【０１１０】
他方、処理実行部１０１がデータの読み出しを行う際には、記憶変換装置４０１より行う。
【０１１１】
記憶変換装置４０１は、（障害発生検知後に管理用ＯＳ２側から取り外されて接続された）記憶退避装置２０３からデータを読み出すにあたって、障害発生時点以降のデータではなく、障害発生直前の時点のデータを読み出す。例えば、ユーザから３日前と指定された場合には、３日前のデータを読み出すような機能を持つ。
【０１１２】
記憶変換装置４０１は、例えば、データ抽出部２０２の機能とデータ復旧部２０４のような機能を持てばよい。
【０１１３】
このように、処理実行部１０１が記憶退避装置２０３へのデータの書き込みや読み出しを記憶変換装置４０１を介して行うことにより、あたかも通常の記憶装置へのデータの書き込みや読み出しを行っているかのように動作させることができる。すなわち、記憶変換装置４０１と記憶退避装置２０３の組み合わせてできた装置を、一つの記憶装置１０２´とすると、これが図１における通常の記憶装置１０２と同等の機能で動作することになる。
【０１１４】
また、記憶退避装置２０３が移動された後には、管理用ＯＳ２のデータ抽出部２０２は、記憶装置１０２´からのデータ（実際には、記憶変換装置４０１からのデータ）を受信し、記憶退避装置２０３の代わりに新たに接続した記憶退避装置２０３´への書き込みを、第１の実施形態と同様に行えばよい。
【０１１５】
このように、記憶変換装置４０１を追加した障害復旧を行うことにより、記憶装置１０２へのデータのに書き戻しのような復旧作業を行うことなく、瞬時に動作ＯＳ１を障害発生前の状態で動作させることができる。この方法によれば、瞬時に障害を復旧することができ、例えばオンラインショッピングサイトのサービス等を行っている計算機システムのように、動作ＯＳ１を長期間停止できないあるいは無停止で運用させることが重要であるような算機システムには特に効果的である。
【０１１６】
なお、この構成を障害復旧中の一時的な特殊構成と考えず、最初から記憶装置及び記憶退避装置が、いずれも、記憶変換装置４０１と記憶退避装置２０３を包含する装置であるとすれば、記憶装置と記憶退避装置とを区別することなく、障害が発生するたびに両者を入れ換えるようにする構成も可能である。この場合、管理用ＯＳ２において、データ抽出部２０２の役割を記憶変換装置４０１が果たすようにすれば、データ抽出部２０２を省くことが可能である。
【０１１７】
また、図１２では、管理用ＯＳ２の記憶退避装置２０３のデータをもとに障害復旧を行う例を示したが、図１２の構成例に更に図１１の遠隔管理装置３（ただし、遠隔データ復旧部３０３は除く）を付加し、上記と同様に、障害発生検知時に、管理用ＯＳ２の記憶退避装置２０３または遠隔管理装置３の遠隔記憶退避装置３０２を動作ＯＳ１側に接続して、記憶退避装置２０３または遠隔記憶退避装置３０２のデータをもとに障害復旧を行うようにする構成も可能である。
【０１１８】
また、この例は、障害発生時の一時的な復旧措置を迅速化させる目的のものであるから、一時的に管理用ＯＳ２を取り外し、記憶変換装置４０１を加えた動作ＯＳ１のみで動作させるという運用も可能である。
【０１１９】
（変形例）
本実施形態では、第１〜第４の実施形態で説明した各構成に関する変形例について説明する。
【０１２０】
＜１＞各実施形態に係る計算機システムを高性能化する一つの手法として、保存データ量を削減することも可能である。管理用ＯＳ２のデータ抽出部２０２が、抽出したデータを記憶退避装置２０３にデータを保存する際、データを逐次そのまま記憶させていくのでは、保存すべきデータが膨大になるが、既に記憶されている過去の退避データを記憶退避装置より読み出し、再利用することにより、保存データを削減し、性能を向上させることが可能である。
【０１２１】
例えば、内容の変更されていない単位データ（ファイル）の保存を省略したり、ごく一部だけが変更されている単位データ（ファイル）に対してはその差分データのみを保存するなどにより、保存データを大幅に削減することができる。これは、遠隔管理装置３においてデータ受信部３０１が遠隔記憶退避装置３０２にデータを保存する際にも用いることができる。
【０１２２】
また、ＯＳ状態検出部２０１が、動作ＯＳ１の実行が終了したことを検出し、その情報を記憶装置１０２からデータを取り出す際に利用することができる。
【０１２３】
利用方法の一例としては、例えば、動作ＯＳ１の実行終了時には、通常のデータ保存時よりも詳細なデータを保存する方法がある。つまり、動作ＯＳの起動途中とは異なる実行終了時特有のデータを追加して保存する。
【０１２４】
また、他の利用方法例としては、動作ＯＳ１の実行終了後には、記憶装置１０２のデータ内容全てを保存し、それ以外の場合には前回の動作ＯＳ１の実行終了時のデータに基づく差分データのみを保存するようにする方法がある。これによって、障害復旧に必要なデータの保存をより効率的に行うことができる。
【０１２５】
また、このような方法を取ることにより、障害復旧処理時にどのデータを採用すべきか判りやすくなる場合がある。例えば、「３日前の午後３時２１分のデータ」と表示されているよりも「３日前の、一番最後にＯＳの実行を終了した時のデータ」と表示されている方が好都合である場合があると考えられる。
【０１２６】
このように、動作ＯＳの実行が終了したことを検出し、その情報を記憶装置からデータを取り出す際に利用することによって、データの保存処理を効率化したり、障害復旧処理を簡便にしたりする効果が期待できる。
【０１２７】
また、ＯＳ状態検出部２０１が、動作ＯＳ１の実行が終了したことを検出することができるため、例えば、「障害復旧機能の起動」といった特別の作業を行う必要はなく、計算機のユーザからは、実際には動作ＯＳ１と管理用ＯＳ２とが動いているにもかかわらず、あたかも動作ＯＳ１だけが動いていて、その通常使っている動作ＯＳ１をそのまま使っている感覚で使えるという利点がある。
【０１２８】
＜２＞また、ＯＳ状態検出部２０１が、動作ＯＳ１の実行処理部１０１が記憶装置１０２のデータに変更を加えたことを検出し、その情報を記憶装置１０２からデータを取り出す際に利用することができる。一般に、管理用ＯＳ２が動作ＯＳ１の記憶装置１０２の内容だけを見てその内容の変化をリアルタイムに知るためには記憶装置１０２の全体を繰り返し検索する必要があるが、動作ＯＳ１が記憶装置１０２の内容に変更を加えたことを直接にデータ抽出部２０２に伝える手段があれば、記憶装置１０２の内容のうち変更されたと判っている部分のみを検索すれば済むため、データを取り出す効率が良くなる。例えば、動作ＯＳ１の処理実行部１０１のデータ処理に関するシステムコールを改造し、データ抽出部２０２に記憶装置に関連する情報（ファイル名やノード番号等）を伝える仕組みにすることによりこの機能が実現できる。
【０１２９】
＜３＞また、本実施形態を一般の計算機に実装する一つの手法として、他のＯＳを実行するための仮想計算機ソフトウェアを用いる手法がある。
【０１３０】
仮想計算機ソフトウェアとしては例えばＶＭｗａｒｅ（Ｊ． Ｓｕｇｅｒｍａｎ， ｅｔ． ａｌ， Ｖｉｒｔｕａｌｉｚｉｎｇ Ｉ／Ｏ Ｄｅｖｉｃｅｓ ｏｎ ＶＭｗａｒｅ Ｗｏｒｋｓｔａｔｉｏｎ■ｓ Ｈｏｓｔｅｄ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ， ２００１ ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ， ２００１／７／２５）がある。
【０１３１】
この場合、一つの主たるＯＳ（ホストＯＳと呼ぶ）上で動作する仮想計算機ソフトウェアを用意する。この仮想計算機は、ＣＰＵを直接実行し、さまざまな周辺デバイスを仮想化して組み込むことにより、あたかも実際の計算機が動いているかのごとく動作し、実際の計算機とほぼ同等の性能で動作するものである。仮想計算機ソフトウェアは、ホストＯＳ上に１つまたは複数動作させることができ、それぞれの仮想計算機に副たるＯＳ（ゲストＯＳと呼ぶ）を実装することができるため、結果として１台の計算機上に２つ以上所望する数だけＯＳを同時に動作させることができる。この仕組みを用いて、動作ＯＳ１と管理用ＯＳ２とを同時に１台の計算機上に実装することができる。
【０１３２】
これにより、特別な計算機装置を用意することなく、１台の計算機で容易に本計算機システムを実装することが可能となる。
【０１３３】
例えば、本実施形態を計算機に実装するにあたって、図１３に例示するように、管理用ＯＳ２は、他のＯＳを実行するための仮想計算機ソフトウェア２２を持ち、動作ＯＳ１は該ソフトウェア２２上で動作するという構成が可能である。この様子を障害復旧を確実に行うためには、動作ＯＳと管理用ＯＳを同時に動かすことが望ましいが、仮想計算機ソフトウェアを用いることにより、特別な計算機装置を用意することなく、１台の計算機で容易に本計算機システムを実装することが可能となる。
【０１３４】
また、仮想計算機ソフトウェアを使う利点としては、動作ＯＳ１と管理用ＯＳ２とが同一のハードウェアを共有していることから、管理用ＯＳ２のＯＳ状態検出部が、動作ＯＳ１の処理実行部１０１からの情報を受け取るための実装が容易になり、また、管理用ＯＳ２のデータ抽出部２０２が動作ＯＳ１の記憶装置１０２からのデータを受け取るための実装も容易になる。
【０１３５】
さらには、障害の復旧時においても、データ復旧部２０４が記憶退避装置２０３からのデータをもとに記憶装置１０２に復旧のためのデータを書き込む実装も容易になり、また、その性能も向上することが期待できるという効果がある。
【０１３６】
この方法の場合、ゲストＯＳはホストＯＳの上に実装される以上、安全性はゲストＯＳがホストＯＳを上回ることは通常考えられない。なぜなら、ホストＯＳが破壊された場合、必然的にゲストＯＳも破壊される可能性が高いからである。したがって、動作ＯＳ１は必ずゲストＯＳとして実装され、管理用ＯＳ２はゲストＯＳであってもホストＯＳであってもよい。
【０１３７】
また、１つの管理用ＯＳ１に対して複数の動作ＯＳ２がゲストＯＳとして実装されることも可能であるし、また、遠隔管理装置３も、このゲストＯＳまたはホストＯＳとして実装されることも可能である。
【０１３８】
また、この方法の場合、ホストＯＳを起動すると同時にゲストＯＳを起動させることができるため、計算機のユーザからは、実際には動作ＯＳ１と管理用ＯＳ２とが動いているにもかかわらず、あたかも動作ＯＳ１だけが動いていて、その通常使っている動作ＯＳ１をそのまま使っている感覚で使えるという環境を自然に実現することができるという効果もある。
【０１３９】
＜４＞また、以上では、１つの管理用ＯＳ２が１つの動作ＯＳ１を管理対象とするものであったが、図１４に例示するように、１つの管理用ＯＳ２が複数の動作ＯＳ１を管理対象とすることも可能である。図１４は、ｎ台の計算機Ａ１〜Ａｎ上でそれぞれ動作する動作ＯＳ１を、それら計算機Ａ１〜ＡｎとＬＡＮあるいはインターネット等のネットワーク８で接続された計算機Ｂ上で動作する管理用ＯＳ２が管理対象とする例である。
【０１４０】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１４１】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１４２】
【発明の効果】
本発明によれば、計算機の障害復旧に必要なデータを従来よりも確実に保存することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図２】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【図３】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【図４】管理用ＯＳの処理手順の一例を示すフローチャート
【図５】管理用ＯＳの処理について説明するための図
【図６】管理用ＯＳの処理について説明するための図
【図７】管理用ＯＳの処理について説明するための図
【図８】本発明の第２の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図９】管理用ＯＳの処理手順の一例を示すフローチャート
【図１０】管理用ＯＳの処理について説明するための図
【図１１】本発明の第３の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図１２】本発明の第４の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図１３】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【図１４】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【符号の説明】
１…動作ＯＳ、２…管理用ＯＳ、３…遠隔管理装置、４，８…ネットワーク、２２…仮想計算機ソフトウェア、１０１…処理実行部、１０２，１０２´…記憶装置、２０１…ＯＳ状態検出部、２０２…データ抽出部、２０３，２０３´…記憶退避装置、２０４…データ復旧部、３０１…データ受信部、３０２…遠隔記憶退避装置、３０３…遠隔データ復旧部、４０１…記憶変換装置、Ａ，Ａ１〜Ａｎ，Ｂ〜Ｄ…計算機
【発明の属する技術分野】
本発明は、計算機に係る障害を復旧させるために計算機に係るデータの待避や復元を行うデータ管理装置、データ管理方法及びプログラムに関する。
【０００２】
【従来の技術】
計算機の障害は、ハードウェアの故障またはソフトウェア（記憶装置のデータ）の誤った修正等によって起こるが、障害復旧にあたっては、障害発生以前におけるソフトウェアの状態を正確に復元させることができるか否かが最も重要なポイントである。従来より知られている計算機障害復旧装置においては、大まかに３つの手法がある。
【０００３】
まず、第１の方法は、記憶装置を多重化し、動作ＯＳが第１の記憶装置に書き込んだのと同じデータを第２の記憶装置にも書き込むことにより、万一、第１の記憶装置のデータが破壊されても第２の記憶装置に保存されたデータを利用し復元させる方法である。例えば、動作ＯＳから第２の記憶装置は直接アクセスできない仕組みにしておき、障害が発生した時点で起動記憶装置（起動ディスク）を第１の記憶装置から第２の記憶装置に切替えることにより、瞬時に障害復旧することが可能となる（例えば、特許文献１参照）。この方式は、ハードディスク等の記憶装置が物理的に動作不能になった場合など、即座に直前の障害発生時に復旧できるという利点のあるものである。しかし、計算機の障害発生後に直ちに完全に動作不能となるタイプの障害発生はあまり多くなく、実際には、障害発生後も動作を続け、例えば数日後に障害報告を受けて障害復旧を試みる場合が多いのであるが、この方式によれば過去の障害発生時のデータは既に廃棄されているから、障害を復旧することはできない。すなわち、どの時点が障害発生のタイミングであるかを、リアルタイムには検出できないから、この方式では障害復旧に必要なデータは失われてしまう可能性が極めて高い。
【０００４】
次に、第２の方法として、動作ＯＳ上に、データのバックアップのためのソフトウェアを常時動作させ、または必要と思われるタイミングに動作させることにより、動作ＯＳが変更した記憶装置内のデータを逐次第２の記憶装置に保存していく方法がある。例えば、新しいアプリケーションのインストールによって障害が発生することを防ぐために、アプリケーションのインストール直前の状態（スナップショット）を保存しておくという方式がある。例えば、米国ＭｉｃｒｏｓｏｆｔＴＭ社製品のＷｉｎｄｏｗｓ ＭｅＴＭ（２０００年９月発売）に「システムの復元」という機能として実装されている（例えば、非特許文献２参照）。この方式を利用すれば、第１の方法とは異なり、複数の状態を保存しておくことが可能であるから、障害復旧に必要なデータが残っている可能性が高まる。しかし、この方式は、障害復旧に必要なデータもまた動作ＯＳのデータとして管理されているため、障害復旧のためのソフトウェア自身が障害を受ける可能性があり、やはり障害復旧に必要なデータは失われている可能性が高い。例えば、今日多く見られるコンピュータウイルスと呼ばれるシステム破壊を目的としたソフトウェアによって受ける被害に対してはほとんど無力であることが問題となっている。
【０００５】
次に、第３の方法として、動作ＯＳとは別に、データのバックアップを目的とするＯＳを別途動作させることにより、バックアップ作業の際に一旦動作ＯＳを停止（シャットダウン）させ、停止している状態のデータを保存しておく方法がある。例えば、米国ｓｙｍａｎｔｅｃＴＭ社の「Ｎｏｒｔｏｎ ＧｈｏｓｔＴＭ」という製品などに採用されている（例えば、非特許文献３参照）。これは現在最も広く用いられている方法であり、動作ＯＳの挙動に全く影響されることなく障害復旧に必要なデータが確実に保存できるという利点がある。しかし、この方式は、保存すべき「動いている状態」が今であるということを予め知っていなければならないため、例えばＯＳを破壊するかもしれない危険な操作をする前に保存（バックアップ）しておくという目的には利用できるものの、一般にいつ発生するか判らない障害に対し、その障害発生前の状態に戻すという一番重要な目的にはほとんど役に立たない。
【０００６】
【非特許文献１】
Ａｐｐａｒａｔｕｓ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ ｐｒｏｖｉｄｉｎｇ ａ ｔｒａｎｓｐａｒｅｎｔ ｄｉｓｋ ｄｒｉｖｅ ｂａｃｋ−ｕｐ ＵＳＰ ６，１７５，９０４ （２００１／１／１６）
【０００７】
【非特許文献２】
ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｊａｐａｎ／ｅｎａｂｌｅ／ｔｒａｉｎｉｎｇ／ｋｂｌｉｇｈｔ／ｔ００６／３／１７．ｈｔｍ
【０００８】
【非特許文献３】
ｈｔｔｐ：／／ｗｗｗ．ｓｙｍａｎｔｅｃ．ｃｏｍ／ｒｅｇｉｏｎ／ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ
【０００９】
【発明が解決しようとする課題】
上述したように従来、計算機の障害復旧に必要なデータが保存されているか否かは、さまざまな状況に依存しており、必ずしも復旧することができる保証はないという問題があった。
【００１０】
本発明は、上記事情を考慮してなされたもので、計算機の障害復旧に必要なデータを従来よりも確実に保存することのできるデータ管理装置、データ管理方法及びプログラムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、対象オペレーティングシステムの持つ記憶装置のデータを管理するデータ管理システムにおいて、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムを設け、前記管理用オペレーティングシステムが、前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出する動作状態検出手段と、前記動作検出手段により検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出する抽出手段と、抽出された前記データを退避させるための退避用記憶手段とを備えたことを特徴とする。
【００１２】
好ましくは、前記管理用オペレーティングシステムは、前記対象オペレーティングシステムより高い安全性を有するものであるようにしてもよい。
【００１３】
また、本発明は、対象オペレーティングシステムの持つ記憶装置のデータを、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムにより管理するデータ管理方法であって、前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出するステップと、検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出するステップと、抽出された前記データを退避用記憶装置に退避させるステップとを有することを特徴とする。
【００１４】
また、本発明は、対象オペレーティングシステムの持つ記憶装置のデータを、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムにより管理するデータ管理装置としてコンピュータを機能させるためのプログラムであって、前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出する機能と、検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出する機能と、抽出された前記データを退避用記憶装置に退避させる機能とをコンピュータに実現させるためのプログラムである。
【００１５】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００１６】
本発明では、管理用オペレーティングシステムは対象オペレーティングシステムの動作状態を知り、例えば動作ＯＳが停止したことや新規アプリケーションをインストールしようとしていることなどの情報を得て記憶装置からデータを取り出すことができるため、ユーザが対象オペレーティングシステムの動作状態を意識することなく、障害復旧に必要なデータをより確実に退避させておくことが可能となり、障害発生以前の或る時点に復旧させるためのデータを持つことが可能になる。
【００１７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００１８】
（第１の実施形態）
図１に、本発明の第１の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。
【００１９】
図中、１は動作ＯＳ（対象オペレーティングシステム）、２は管理用ＯＳ（管理用オペレーティングシステム）（データ管理システム）である。動作ＯＳ１は、障害を復旧させたい対象のＯＳである。管理用ＯＳ２は、専ら動作ＯＳ１の障害復旧作業のために用意され、動作ＯＳ１の障害の障害復旧を目的として、動作ＯＳ１に関係するデータ（若しくはファイル）の退避などを行うためのＯＳである。詳しくは後述するように、管理用ＯＳは、動作ＯＳ１に比較してより高い安全性を持たせるようにするのが好ましい。
【００２０】
なお、一般にＯＳとは計算機を管理するソフトウェアの部分のみ指すこともあるが、本実施形態においては、記憶装置等の周辺機器をも含んだシステムを指すものとする。ただし、計算機システムは複数のＯＳがインストールされ稼働する場合があるので、ここでは、その一主体である動作ＯＳが利用する部分のみや管理用ＯＳが利用する部分のみを指すものとなる。
【００２１】
システム構成としては、大きく分けて、図２に示すように動作ＯＳ１と管理用ＯＳ２とが別々の計算機Ａ，Ｂ上で実現される構成と、図３に示すように動作ＯＳ１と管理用ＯＳ２とが同一の計算機Ｃ上で実現される構成とが可能である。前者の場合、動作作ＯＳ１と管理用ＯＳ２とを、ＬＡＮ等で接続して同一の計算機室や同一のビル内などの近接した場所に設置する形態や、広域ネットワーク等で接続して物理的に離れた場所に設置する形態など、種々の設置形態が可能である。
【００２２】
動作ＯＳ１は、プログラムの実行等を行うための処理実行部１０１と、処理実行部１０１がデータの書き込みや読み出し等を行う記憶装置１０２とを有する。
【００２３】
記憶装置１０２は、典型的には、ハードディスクやフラッシュメモリ装置などの物理的な記憶媒体であるが、処理実行部１０１がデータの書き込みや読み出しを行うものであれば、記憶媒体を持たないものであってもよい。例えば、動作ＯＳ１は通信回線を持ち、その通信回線を経由して外部の記憶装置にデータを書き込みおよび外部の記憶装置からデータを読み込むような場合も可能である。
【００２４】
管理用ＯＳ２は、ＯＳ状態検出部２０１とデータ抽出部２０２と記憶退避装置２０３を有する。
【００２５】
図４に、管理用ＯＳ２が記憶装置１０２のデータを退避する手順の一例を示す。
【００２６】
ＯＳ状態検出部２０１は、対象となる動作ＯＳ１の動作状態（動作状況）を検出する（ステップＳ１１）。すなわち、対象となる動作ＯＳ１の処理実行部１０１の動作状態に関する情報を取得する。
【００２７】
データ抽出部２０２は、検出された動作状態に応じて記憶装置１０２から退避すべきデータを抽出する（読み出す）（ステップＳ１２）。
【００２８】
データ抽出部２０２は、抽出したデータを、記憶退避装置２０３へ退避させる（書き込む）（ステップＳ１３）。
【００２９】
以下、ＯＳ状態検出部２０１による動作ＯＳ１の動作状態の検出について詳しく説明する。
【００３０】
動作の状態に関する情報としては、例えば、「処理実行部１０１が動作ＯＳ１の終了処理を行い、動作を停止する（すなわち、シャットダウンする）」という情報がある。
【００３１】
例えば、動作ＯＳ１が動作を停止する直前に停止の予告メッセージをネットワーク上に流す場合に、管理用ＯＳ２は、その予告メッセージを受信し、ＯＳ状態検出部２０１は、動作ＯＳ１が間もなく停止することを知る。
【００３２】
なお、この通知をより確実に行うために、例えば、予告メッセージを受信した管理用ＯＳ２が動作ＯＳ１のネットワークインターフェースに対するＩＣＭＰメッセージ（ＩＮＴＥＲＮＥＴ ＣＯＮＴＲＯＬ ＭＥＳＳＡＧＥ ＰＲＯＴＯＣＯＬ）を流すなどして、動作ＯＳ１が実際に停止したことを確認するようにしてもよい。
【００３３】
ここでは、予告メッセージがネットワーク上に流される場合を例にとって説明したが、管理用ＯＳ２に動作ＯＳ１の停止を伝える手段あるいはＯＳ状態検出部２０１が動作ＯＳ１の停止を検出する手段には特に限定はなく、どのような方法によってもよい。
【００３４】
動作の状態に関する情報の他の例としては、「処理実行部１０１が動作ＯＳ１の処理を開始する（すなわち、ＯＳをブートする）」という情報がある。
【００３５】
例えば、動作ＯＳ１が動作を開始した直後にＯＳの再起動メッセージをネットワーク上に流す場合に、管理用ＯＳ２は、その再起動メッセージを受信し、ＯＳ状態検出部２０１は、動作ＯＳ１が処理を開始したことを知る。
【００３６】
この再起動メッセージには、動作ＯＳ１の起動オプションを含むとより効果的である。起動オプションは、例えば、動作ＯＳ１がどのようなサービス（デーモン）を実行しようとしているか、ＯＳのバージョンは何か、何の目的で動作ＯＳ１が起動されたかなどを示す情報である。例えば、この動作ＯＳ１がＣＡＤシステムの利用を目的として起動されたことが予め判っていれば、その情報を後述するデータ抽出部２０２が利用し、ＣＡＤファイルの更新を優先して処理するといった効率化が可能になる。また、起動オプションに相当する情報は、再起動メッセージに含む方法をとるのではなく、単独のメッセージとして随時送信する方法をとっても構わない。
【００３７】
ここでは、再起動メッセージがネットワーク上に流される場合を例にとって説明したが、管理用ＯＳに動作ＯＳ１の再起動を伝える手段あるいはＯＳ状態検出部２０１が動作ＯＳ１の再起動を検出する手段には特に限定はなく、どのような方法によってもよい。
【００３８】
また、動作の状態に関する情報のさらに他の例としては、動作ＯＳ１そのものの内部動作に関する情報が考えられる。
【００３９】
例えば、「処理実行部１０１が記憶装置１０２に対してデータの書き込みを行った」という情報である。この場合、全てのデータ書き込み情報を逐一利用してもよいし、処理を効率化するために特定のデータ書き込み情報のみを利用してもよい。
【００４０】
後者の特定のデータ書き込みとは、例えば、ＯＳのシステム領域の書き換えなどの重大な書き込みであったり、あるいは、アプリケーションのインストール時に作成されるファイルへの書き込みであったりする。何を特定のデータ書き込みとして扱うべきかについては、動作ＯＳ１の性質やまたその利用目的などに応じて決定するのが好ましい。これは、例えば、動作ＯＳ１の性質や利用目的などから特定のデータ書き込みを求めるためのルールを定義ファイルに記述するなどして実現することができる。
【００４１】
また、動作の状態に関する情報に含まれるデータの中身に関しても、書き込みしたファイル名であることも考えられるし、また、その記憶装置上の場所（トラック番号やファイルのノード番号等）であることも考えられるし、また、場合によってはファイルの更新内容（３行目のデータをこのようなデータに書き換えた等）であることも考えられる。こういったルールも同様に定義ファイルに記述するなどして実現するようにしてもよい。
【００４２】
動作の状態に関する情報のさらに他の例としては、動作ＯＳ１が他の計算機と通信を行ったというものが考えられる。
【００４３】
これも、例えば、前述したデータ書き込みの場合と同様、全ての通信記録の中からルールに従って必要な情報を採用すればよい。例えば、ＯＳのアップデートをするための通信（すなわち、アップデートサイトとの通信）があれば、重要な変更がなされると予測することができるし、危険なＷＷＷサイト（例えば、多くの複雑なスクリプトが書かれたサイトや、危険だと予め判っているサイトなど）へのＷＷＷアクセスがあれば、コンピュータウイルスが入った可能性があると推定することができる。
【００４４】
なお、上記では、予め定められた動作状態が検出された場合に、該動作状態に応じて記憶装置１０２から退避すべきデータを抽出し、これを記憶退避装置２０３へ退避させるものであったが、これに加えて、予め定められた時間が経過するごとにも、記憶装置１０２から退避すべきデータを抽出し、これを記憶退避装置２０３へ退避させるようにしてもよい。なお、予め定められた動作状態が検出されたことと、予め定められた時間が経過したこととが同時に発生した場合には、例えば、前者を優先するものとしておけばよい。
【００４５】
次に、データ抽出部２０２による退避すべきデータの記憶装置１０２からの読み出し及び記憶退避装置２０３へのデータ退避について詳しく説明する。
【００４６】
データを記憶装置１０２から読み出す方法は主として２通りの方法が可能である。１つは、実際に記憶装置１０２に記憶されているデータを通常のデータ読み出しと同様の方法で読み出す方法であり、もう１つは、処理実行部１０１から記憶装置１０２への書き込み命令が出た際にその信号を直接読み取ることによってデータを読み出すのと同等の効果を得る方法である。ただし、前記したような物理的な記憶装置を内包しない記憶装置の場合には後者の方法を用いる。
【００４７】
データ抽出部２０２は、抽出したデータを、記憶退避装置２０３へ書き込む。この書き込みは、通常のファイルシステム等の書き込みとは異なり、時系列を考慮した書き込みとなる（例えば、あるデータを記憶装置１０２から読み出した時刻もしくは記憶退避装置２０３へ書き込んだ時刻を、該あるデータに対応付けて保存しておく）。すなわち、当該データの更新履歴を管理するのと同様の処理を行う。
【００４８】
例えば、図５に示すように、３日前にデータ抽出部２０２が取り出し記憶退避装置２０３に書き込んだ“ｆｏｏ”という名前のファイルのデータ（このときの内容をａで表す）が存在する場合、その後（例えば、１日前）に再度データ抽出部２０２が“ｆｏｏ”という名前のファイルのデータ（このときの内容をｂで表す）を取り出して記憶退避装置２０３の同一名のファイルのデータに上書きすると、３日前の状態に復旧させるためのデータ（すなわち、内容ａのデータ）が欠落してしまうから、例えば障害発生が２日前であったとすると、その障害を復旧させることができない可能性が出てしまう。そこで、各時点（例えば、各退避時点）における同一名のファイルのデータはそれぞれ区別して、それぞれが保存されるような方法によって、この書き込みを行う。なお、この区別は、例えば、記憶退避装置２０３に退避した時刻や、バージョン番号等によって行えばよい。図６は、“ｆｏｏ”という名前のファイルのバージョンで内容を区別して、各バージョンのデータを保存するようにした例である。
【００４９】
また、例えば、ファイル“ｆｏｏ”が一旦削除された後に、 “ｆｏｏ”という名前のファイルが再度作成される場合があるので（削除されてから再度作成されるまでの間、ファイル“ｆｏｏ”は存在しないことになる）、“ｆｏｏ”が削除された場合には、その旨を示す情報を記憶退避装置２０３に保存しておくのが望ましい。図７は、ｔ３の時点でファイル“ｆｏｏ”が削除されたことを示す情報を退避した例を示す（なお、ｆｏｏ（ｔ４，ｖｅｒ１）は、ｆｏｏ（ｔ１，ｖｅｒ１）とは、バージョン番号は同じであるが、時刻情報が異なるので、内容は異なる）。
【００５０】
また、ファイル“ｆｏｏ”が新たに作成されたものか、修正されたものか、削除されたものかの区別を示す情報を、ファイル“ｆｏｏ”に対応付けて保存しておくようにしてもよい。
【００５１】
また、例えば、パス名の異なる“ｆｏｏ”という名前のファイルが複数存在し得る場合には、それらは異なるファイルとして扱うものとする。
【００５２】
データ抽出部２０２が記憶装置１０２より抽出したデータを記憶退避装置２０３に書き込むにあたっては、ＯＳ状態検出部２０１によって検出された動作ＯＳ１の動作状態を示す情報を利用すると好ましい。これは動作ＯＳ１の状態を保存するには動作ＯＳ１の現況（現在の動作状態）を意識しておくのが望ましいからである。
【００５３】
例えば、動作ＯＳ１が完全に停止した状態であれば、データ抽出部２０２が記憶装置１０２よりデータを取り出している間に記憶装置１０２のデータが変更されることがないことが保証されることになる。このような場合には、データの取り出しのスケジューリングを意識する必要がなくなり、とにかく考えられる全てのデータを保存しておけばよい。そのデータに基づけば、次に動作ＯＳ１が起動（電源オン）するであろう時点での状態を将来いつでも取り出すことができる。
【００５４】
一方、動作ＯＳ１が動作している場合にはデータ抽出部２０２が記憶装置１０２よりデータを取り出している間にも、記憶装置１０２のデータが変更されることがある。このような場合には、データ抽出部２０２がやみくもに記憶装置１０２のデータを読み出すのでは効率が良くない場合がある。例えば、ユーザが特定の文書ファイルを編集していることが把握できるときには、関連ファイルが秒単位で変更されることがあり得るのであり、そういったファイルに注目して重点的にデータを取り出すと効果的である。
【００５５】
また、他のケースとしては、動作ＯＳ１が新たなアプリケーションを登録しようとしている際には、システム関連のファイル変更が重要なポイントとなり、それらのファイル（共通のライブラリファイルや、システム設定ファイルなど）に注目して重点的にデータを取り出すと効果的である。
【００５６】
これらは、例えば、動作ＯＳ１の性質を考慮した上でデータ抽出部２０２のアルゴリズムを設計すると、より効果を発揮する場合もある。例えば、現在知られているいくつかのＯＳでは、ユーザが最近編集したファイルを簡単に取り出せる仕組みが用意されており、最近編集されたファイルの一覧あるいはそれらファイルへのポインタが一箇所にまとまって管理されている。動作ＯＳ１が、そのような性質のＯＳである場合には、当該動作ＯＳ１に対しては、その情報を利用することにより、ユーザが現在どのようなファイルを重点的に操作（変更）しているかを知り、データの取り出しの際の情報とすることができる。
【００５７】
また、例えば、現在知られているいくつかのＯＳでは、新規のアプリケーションをインストール（登録）したりアンインストール（削除）したりするためのインタフェースが統一されており、アプリケーションのインストールやアンインストールを行う際には、必ず決められたソフトウェアが起動することになっている。動作ＯＳ１が、そのような性質のＯＳである場合には、当該動作ＯＳ１に対しては、その情報を利用することにより、現在、障害復旧を行うにあたっての重要な変更が行われようとしていることを、データ抽出部２０２が知ることにより、データの取り出しの際の情報とすることができる。
【００５８】
なお、データ抽出部２０２が記憶装置１０２より抽出したデータを記憶退避装置２０３に書き込むにあたっては、ＯＳ状態検出部２０１によって検出された動作ＯＳ１の動作状態を示す情報をも当該データに対応つけて記憶するようにしてもよい。
【００５９】
以上のように、管理用ＯＳ２が動作ＯＳ１の動作状態を知り、例えば動作ＯＳ１が停止したことや、新規アプリケーションをインストールしようとしていることなどの情報を得て記憶装置１０２からデータを取り出すことができるようにすることによって、ユーザが動作ＯＳ１の状態を意識することなく、障害復旧に必要なデータを保存しておくことが可能となり、バックアップのし忘れの心配がなくなるため、種々多様な状況で障害が発生した場合においても、障害発生以前の任意の時点に復旧させるためのデータを記憶退避装置２０３に持つことが保証される（あるいは、それが期待される）。
【００６０】
例えば、実際の障害発生から３日後に障害発生を認識した場合に、１日前や２日前の保存データを用いたときには障害発生前の状態が得られないので、障害を復旧させることはできないが、３日前の保存データを用いたときには障害が復旧されることを知ることができ、記憶装置１０２の状態を３日前の状態に戻すことによって、障害発生直前の状態に計算機を復旧させることが可能となる。
【００６１】
なお、記憶退避装置２０３に退避したデータをユーザが直接利用できないようにしてもよい。このようにすれば、たとえコンピュータウイルスを含むファイルが記憶退避装置２０３に退避されていても、コンピュータウイルスが発動しない蓋然性が非常に高くなり、管理用ＯＳ２側がコンピュータウイルスにより被害を受けることを未然に防止することができる。
【００６２】
ところで、仮に管理用ＯＳ２の安全性が動作ＯＳ１の安全性と同程度又はそれ以下であると、コンピュータウイルスのような悪意のソフトウェアによって動作ＯＳ１が被害を受けた場合、同じ原因により、管理用ＯＳ２も同時に被害を受け、結局、障害復旧することはできない危険性があるので、好ましくは、管理用ＯＳ２を動作ＯＳ１よりも安全性を高めたものにしておくのが望ましい。このようにすれば、管理用ＯＳ２が動作ＯＳ１と同時に障害を発生する確率を概ねゼロに（あるいは、非常に低く）することができる。
【００６３】
一般に動作ＯＳ１はアプリケーション実行に必要なさまざまな機能を実現しなくてはならないので安全性をあまり高めることができないが、管理用ＯＳ２は機能を限定することができるため動作ＯＳ１に比べ安全性を高めることが比較的容易に可能である。
【００６４】
例えば、動作ＯＳ１がＷＷＷサーバである場合、ＷＷＷサーバのセキュリティーホールにより障害を受ける危険性があるが、管理用ＯＳ２にはＷＷＷサーバをインストールしておく必要がないため、かかる原因により管理用ＯＳ２に障害が発生することはあり得ない。したがって、動作ＯＳ１よりも安全性を高めた管理用ＯＳ２に動作ＯＳ１の障害復旧機能を分離するという構成を採ることによって、従来よりも確実性の高い計算機システムを実現することが可能となる。
【００６５】
上記のように、管理用ＯＳ２の安全性を動作ＯＳ１に比較してより高めておくことによって、仮に動作ＯＳ１がコンピュータウイルス等によって破壊されたとしても管理用ＯＳ２は破壊されないことが期待される。ここで、安全性を高めるとは一般にいくつかの方法がある。
【００６６】
まず、第１に、（ＯＳそれ自体に）セキュリティ・ホールが少ない（又は無い）ことが知られているＯＳを管理用ＯＳ２に採用する方法がある。この場合、管理用ＯＳ２は、必ずしも絶対的にセキュリティ・ホールが少ないもの（例えば、現に存在する最もセキュリティ・ホールが少ないＯＳ）でなくても、動作ＯＳ１に比較して、よりセキュリティ・ホールの少ないＯＳを用いて構わない（よりセキュリティ・ホールの少ないＯＳが、セキュリティ・ホールの無いＯＳであれば、理想的である）。動作ＯＳ１においては、目的とするアプリケーションを動作させる必要があるため、必ずしも安全なＯＳを選択することはできないが、管理用ＯＳ２においては、安全なＯＳを選択するということが可能である。
【００６７】
第２に、（動作ＯＳ１と管理用ＯＳ２とに同じＯＳが用いられているか、あるいは動作ＯＳ１と管理用ＯＳ２とで異なるＯＳが用いられているが各ＯＳの持つ安全性が同程度であるような場合であっても）、管理用ＯＳ２の機能を制限することによって安全性を高める方法がある。管理用ＯＳ２の機能は、動作ＯＳ１に比較して、より制限されていればよく、管理用の機能のみ持つようにしてもよいし、管理用の機能以外の機能をも持っていても構わない。動作ＯＳ１においては、目的とするアプリケーションを稼働させるために、必要となる多くのサービスをインストールし、動作させなければならず、また必要なプログラム（コマンド）も多くインストールしておかなければならないが、管理用ＯＳ２においては、動作ＯＳ１を管理するだけの目的に使えばよいので、不要となるサービス（ほとんどのサービス）を停止させておけば安全性が高まる。また、プログラム（コマンド）も必要なものは限られるため、不要なプログラム（コマンド）を削除しておけば、セキュリティ・ホールのあるコマンドの動作によってシステムが障害を受けるといった危険性を下げることが可能である。
【００６８】
第３に、管理用ＯＳ２は動作ＯＳ１とは異なる動作環境としておく方法がある。例えば、動作ＯＳ１がＷＷＷサーバであるとすれば、動作ＯＳ１は必ずインターネットに接続させる必要があるが、管理用ＯＳ２は動作ＯＳ１を管理するのが目的であるからその必要はない。また、ファイアウォールを運用するなどにより、ネットワーク外からの動作ＯＳ１へのアクセスに比較して、管理用ＯＳ２へのアクセスをより厳しく制限しておくことも可能である。また、音声の入出力ドライバなど、本システムに必要のない機能は管理用ＯＳ２では動作しないように設定しておくことも可能である。
【００６９】
以上例示した３つの手段は、少なくとも一つ採用すれば、安全性を高めたと言うことができるが、好ましくは複数を併用するとより安全性を高めることが期待される。
【００７０】
なお、上記の他にも、例えば、特に重要なデータを管理する場合などで、管理用ＯＳ２を多重化するといった手法により、システムの信頼性若しくは安全性を高める方法も可能である。その際、多重化した管理用ＯＳ２ごとに使用するＯＳを異ならせるようにしてもよい（多重化した管理用ＯＳ２の全てが同時にコンピュータウィルスの被害を受けたために記憶装置１０２のデータの退避が不能になることを、概ねゼロもしくは非常に低い確率にすることができる）。
【００７１】
以上説明したように、本実施形態では、動作ＯＳ１とは別に管理用ＯＳ２を設け、この管理用ＯＳ２が動作ＯＳ１の状態に応じてデータの退避等を行うことにより、動作ＯＳ１の障害復旧に必要なデータをユーザが意識することなく自動的に管理用ＯＳ２の記憶退避装置２０４に保存し続けることが可能になる。また、管理用ＯＳを動作ＯＳに比べてより安全性を高めるとより効果的である。ユーザは、待避された（保存された）データを用いて動作ＯＳ１の障害復旧を行うことができる。あるいは、待避された障害発生前のデータをもとにして所望のアプリケーションの実行を再開することができる。
【００７２】
（第２の実施形態）
次に、図８に、本発明の第２の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。
【００７３】
この構成例は、管理用ＯＳ２（データ管理システム）が、図１の構成例に加えて、データ復旧部２０４を備えている。データの退避の処理については基本的には第１の実施形態と同様である。以下では、第１の実施形態と相違する部分を中心に説明する。
【００７４】
図９に、管理用ＯＳ２が記憶退避装置２０３から記憶装置１０２へ退避データを書き戻す手順の一例を示す。
【００７５】
管理用ＯＳ２は、ユーザから復旧時点を指定する情報を含む復旧の指示を受ける（ステップＳ２１）。
【００７６】
データ復旧部２０４は、指定された復旧時点を指定する情報に基づいて、記憶退避装置２０３から、記憶装置１０２へ書き戻すべきデータを抽出する（ステップＳ２２）。
【００７７】
記憶退避装置２０３は、抽出したデータを、記憶装置１０２へ書き戻す（ステップＳ２３）。
【００７８】
復旧時点の指定には種々の方法が考えられる。
【００７９】
例えば、ユーザは、所望する日時（あるいは、現在から溯るべき時間等）を指定し、データ復旧部２０４は、記憶装置１０２の内容を復旧させることができる復旧可能時点（例えば、過去に実際にデータ退避が行われた時点）のうちから、指定された日時に最も近いもの（あるいは、指定された日時以前で最も近い当該指定された日時に最も近いもの）を選択し、記憶装置１０２の状態がその時点の状態になるように、記憶退避装置２０３から、記憶装置１０２へ書き戻すべきデータを抽出するようにしてもよい。
【００８０】
例えば、“ｆｏｏ”という名前のファイルの退避・復旧を例にとって説明する。図１０のように、“ｆｏｏ”という名前のファイルに関する情報が、時刻ｔ３，ｔ５，ｔ９，ｔ１４でそれぞれ退避されたとする。ただし、時刻ｔ３以前には当該ファイルは存在しないものとする。また、時刻ｔ９では当該ファイルが削除された旨の情報が保存されたものとする。例えば、ユーザから復旧時刻として時刻ｔ８が指定された場合に、“ｆｏｏ”という名前のファイルについては、時刻ｔ８以前で最も近い時刻ｔ５が選択され、そのときに退避されたバージョン番号２のデータによる復旧が行われる（例えば、バージョン番号２のデータが記憶装置１０２へ書き戻される）。また、例えば、時刻ｔ４が指定された場合には、時刻ｔ４以前で最も近い時刻ｔ３が選択され、そのときに退避されたバージョン番号１のデータによる復旧が行われる。また、例えば、時刻ｔ１２やｔ２が指定された場合には、“ｆｏｏ”という名前のファイルは存在しないので、そのための復旧がなされる（例えば、記憶装置１０２から“ｆｏｏ”という名前のファイルが削除される）。また、例えば、時刻ｔ１５が指定された場合には、時刻ｔ１５以前で最も近い時刻ｔ１４が選択され、そのときに退避されたバージョン番号１のデータによる復旧が行われる。なお、ｆｏｏ（ｔ１４，ｖｅｒ１）は、ｆｏｏ（ｔ３，ｖｅｒ１）とは、バージョン番号は同じであるが、時刻情報が異なるので、内容は異なる（ｆｏｏ（ｔ１４，ｖｅｒ１）は、“ｆｏｏ”という名前のファイルが一旦削除された後に再度作成されたものである）。
【００８１】
また、例えば、ユーザは、所望する日時等と、データを退避するにあたって検出された動作ＯＳ１の動作状態（例えば、シャットダウン、ブート、あるいはインストール等）とを指定し、データ復旧部２０４は、データを退避するにあたって検出された動作状態が指定された動作状態と一致する復旧可能時点のうちから、指定された日時に最も近いもの（あるいは、指定された日時以前で最も近い当該指定された日時に最も近いもの）を選択するようにしてもよい。
【００８２】
また、例えば、管理用ＯＳ２は、記憶退避装置２０３に記憶された情報をもとに、復旧可能時点を示す日時等（あるいは、日時等と動作ＯＳ１の動作状態との組合せ）を一覧表として提示し、ユーザは、提示された日時等（あるいは、日時等ととの組合せ）のうちから所望のものを選択するようにしてもよい。
【００８３】
また、ファイル名を指定して、当該ファイル名のファイルについてのみ、復旧処理できるようにしてもよい。
【００８４】
その他、種々のバリエーションが可能である。
【００８５】
以下、障害復旧を行う場合について詳しく説明する。
【００８６】
まず、動作ＯＳ１の障害の発生は、例えば、ハードウェアの故障の他、あるソフトウェアの動作中にそのソフトウェアの全部又は一部の機能が利用不能に陥ったことや、計算機が予期しない動作をしたことなどがユーザによって認識されるに至ることによって、発見される。
【００８７】
ユーザが動作ＯＳ１の障害発生を認識した場合、一旦、処理実行部１０１の動作を停止させ、ハードウェアの故障等があればその修理を行った後に、記憶装置１０２の内容を、障害発生前の状態に書き戻すことにより、障害を復旧することができる。
【００８８】
前述したように、障害復旧に必要なデータは記憶退避装置２０３に格納されていることが保証（あるいは期待）されているが、記憶退避装置２０３に格納されているデータは過去に記録した全てのデータ（あるいは時系列上で複数の時点での状態に係るデータ）であり、障害復旧に必要でないデータも含まれ得る。まず、データ復旧部２０４は、記憶退避装置２０３に格納されているデータから、記憶装置１０２に書き戻すべきデータを抽出する。
【００８９】
書き戻すべきデータが何であるかはケースバイケースであり、それは例えばシステム管理者等が判断する。例えば、３日前の午後３時に動作ＯＳ１がコンピュータウィルスの被害を受けたと判定された場合、その直前の状態に戻すことを試みる。それは、３日前の午後２時５９分頃の状態であるかもしれないし、またはそれ以前に動作ＯＳ１をシャットダウンした時刻、例えば３日前の午前５時であるかもしれない。あるいは、３日前の午前５時の状態に戻した上で、午後２時５９分までに特定部分（ディレクトリ）に追加されたファイルを加えたものであるかもしれない。これは運用している動作ＯＳ１の性質によって変わるものであり、システム管理者等が判断する。この判断情報を、データ復旧部２０４に入力することによって、データ復旧部２０４は障害復旧処理を開始する。
【００９０】
なお、上記ではシステム管理者等が判断情報を入力するとしたが、システム構成によっては入力しないものであっても、もちろんよい。例えば、常に、前回に動作ＯＳ１をシャットダウンした時点の状態に復旧するというものであってもよい。
【００９１】
データ復旧部２０４は、入力された復旧の方法を決める判断情報、または予め決められてる復旧方法に従い、記憶装置１０２に書き戻すためのデータを記憶退避装置２０３より取り出し、記憶装置１０２に書き込みを行う。記憶装置１０２への書き込みが終了したら、それはすなわち障害のない動作ＯＳ１の状態が再現できたということを意味するものであるから、再び処理実行部１０１が動作ＯＳ１の起動を行うことによって、障害の復旧を行うことができる。
【００９２】
なお、記憶装置１０２の状態をある時点の状態に復旧した後は、記憶退避装置２０３に保存されているデータのうち、その時点以降の任意の状態に復旧させるのに必要なデータを破棄するようにする構成も可能である。
【００９３】
ところで、動作ＯＳ１の障害の発生は認識できたが、記憶装置１０２の状態をどの時点の状態に戻せばよいか把握できない場合が考えられる。このような場合のために、例えば、データ復旧部２０４に、記憶装置１０２の状態を、ユーザが指定した状態に仮に戻す機能を設けるようにしてもよい。この場合、ユーザはその仮に戻した記憶装置１０２の状態で動作ＯＳ１を起動して障害が復旧しているかどうかを判断するといった操作を、指定する記憶装置１０２の状態を少しずつ過去に溯らせるようにして繰り返し行うことによって、障害が復旧する状態を見出し、このときの記憶装置１０２の状態に確定させる指示をユーザが管理用ＯＳ２に与え、この指示によって、データ復旧部２０４は、記憶装置１０２の状態を確定させるようにしてもよい。
【００９４】
（第３の実施形態）
次に、図１１に、本発明の第３の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。この構成例は、データ管理システムが、図８の管理用ＯＳ２の他に、遠隔管理装置３をも含むものである。データの退避や障害からの復旧の処理については基本的には第２の実施形態と同様である。以下では、図８の構成例と相違する部分を中心に説明する。
【００９５】
管理用ＯＳ２には、例えばネットワーク４等を介して、遠隔管理装置３が接続されている。遠隔管理装置３は、１つでも複数でもよい。ここでは、説明を簡略化するために、１つであるとする。なお、遠隔管理装置３は、例えば、典型的には、インターネットや電話回線等のネットワークを介してサーバセンタなどの離れた場所に設置する形態が可能であるが、これに限定されるものではなく、例えば、計算機の補助装置として遠隔管理装置３を採用し、動作ＯＳ１、管理用ＯＳ２、遠隔管理装置３を一体として設置する形態も可能である。
【００９６】
管理用ＯＳ２のデータ抽出部２０２は、記憶退避装置２０３に障害復旧に必要なデータを保存するのみならず、（遠隔記憶退避装置３０２へ保存させるために）遠隔管理装置３のデータ受信部３０１へも障害復旧に必要なデータを送信する。
【００９７】
記憶退避装置２０３と遠隔記憶退避装置３０２へのデータ保存方法には、記憶退避を２重化する第１の形態（記憶退避装置２０３と遠隔記憶退避装置３０２に同一のデータを保存する方法）、一部のデータのみについて２重化する第２の形態（遠隔記憶退避装置３０２には、記憶退避装置２０３に保存するデータの一部のデータのみを保存する方法）、データごとに保存方法を制御する第３の形態（データによって記憶退避装置２０３のみに保存するか遠隔記憶退避装置３０２のみに保存するか両方に保存するかを決定する方法）など種々の方法がある。
【００９８】
第２の形態の具体例としては、例えば、管理用ＯＳ２のデータ抽出部２０２は、管理用ＯＳ２自身の持つ記憶退避装置２０３へは、障害復旧に必要な全てのデータを保存し、遠隔管理装置３のデータ受信部３０１へは、障害復旧に必要なデータのうち特に重要なデータ（例えば、システムのライブラリファイルに関するデータ等）のみに限定して送信するという方法も考えられる。
【００９９】
データ受信部３０１は、受信したデータの全てを遠隔記憶退避装置３０２に保存する。なお、データ受信部３０１は、受信したデータのうち必要と判断される一部のみを遠隔記憶退避装置３０２に保存するようにする構成も可能である。
【０１００】
このように、障害復旧に必要なデータを記憶退避装置２０３だけでなく遠隔記憶退避装置３０２にも保存しておくことにより、より安全性を高めることが可能である。
【０１０１】
例えば、動作ＯＳ１と管理用ＯＳ２の両者が同一の場所にある場合には、火災などによって物理的に同時に破壊される場合があり得るが、遠隔管理装置３をインターネット等で接続された他の場所にあるサーバセンタ等に設置することにより、障害復旧に必要なデータをより確実に保管することができ、たとえ動作ＯＳ１と管理用ＯＳ２の両者が物理的に同時に破壊されたとしても、遠隔記憶退避装置３０２に保存されたデータを用いて障害復旧を行うことができる。
【０１０２】
また、典型的な利用例としては、遠隔管理装置３をインターネットで接続された特に安全に管理されたサーバセンタ内に設置することにより、管理用ＯＳ２の破壊などのリスクを意識することなく、いつでも障害の復旧できる計算機をユーザに提供できるという利点が生じる。
【０１０３】
遠隔データ復旧部３０３は、先に説明したデータ復旧部２０４の機能と同様、記憶装置１０２に書き戻すべきデータを取り出す機能を持つ。遠隔データ復旧部３０３は、遠隔記憶退避装置３０２より必要なデータを取り出し、データ復旧部２０４に送信する。データ復旧部２０４は、遠隔データ復旧部３０３から受信したデータのみを利用し、もしくは記憶退避装置２０３から取り出したデータのみを利用し、または遠隔データ復旧部３０３からのデータおよび記憶退避装置２０３からのデータを利用して、障害復旧に必要なデータの記憶装置１０２への書き込みを行う。あるいは、遠隔データ復旧部３０３は、データ復旧部２０４にデータを送信することなく、直接に記憶装置１０２へデータを送り、記憶退避装置２０３のデータを利用しないということも考えられる。また、これらの処理はオフラインで行われることも考えられる。つまり、通常はネットワークを介して遠隔管理装置３をサーバセンタで運用するが、障害発生の報告を受けたサーバセンタ職員が遠隔記憶退避装置３０２（ハードディスクなど）を動作ＯＳ１の設置場所に持参し、記憶装置１０２を復旧させるような場合もあり得る。
【０１０４】
なお、図１１の構成例は、図８の構成例に遠隔管理装置３を付加した場合であったが、図１に遠隔管理装置３（ただし、遠隔データ復旧部３０３は除く）を付加した構成も可能である。
【０１０５】
（第４の実施形態）
次に、図１２に、本発明の第４の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す。この構成例は、障害復旧作業をさらに迅速に行えるようにするため、図１の記憶装置１０２の部分に記憶変換機能を付加したものである。データの退避の処理については基本的には第１の実施形態と同様である。以下では、第１の実施形態と相違する部分を中心に説明する。
【０１０６】
ここで、障害発生検知時には、図１２の動作ＯＳ１側の記憶退避装置２０３は、管理用ＯＳ２側に接続されており、第１の実施形態と同様に、障害からの復旧に必要なデータが保存されているものとする（図１参照）。
【０１０７】
また、障害発生が検知された後には、本実施形態では、動作用ＯＳ１の持っていた記憶退避装置（図示せず）が取り外されるとともに、管理用ＯＳ２の持っていた記憶退避装置２０３が取り外されて（実際に移送されて）動作ＯＳ１側へ接続される（図１２は、この状態を示している）。
【０１０８】
本実施形態では、処理実行部１０１は、データの読み出しや書き込みを記憶変換装置４０１に対して行う。
【０１０９】
記憶変換装置４０１は、処理実行部１０１から受けた書き込みデータを、接続された記憶退避装置２０３へそのまま書き込む。ここで、そのまま書き込むとは、時系列を考慮して必要なデータを破壊しないように書き込むという意味であり、これについては既に説明した図１におけるデータ抽出部２０２が記憶退避装置２０３に書き込みを行う場合と同様である。
【０１１０】
他方、処理実行部１０１がデータの読み出しを行う際には、記憶変換装置４０１より行う。
【０１１１】
記憶変換装置４０１は、（障害発生検知後に管理用ＯＳ２側から取り外されて接続された）記憶退避装置２０３からデータを読み出すにあたって、障害発生時点以降のデータではなく、障害発生直前の時点のデータを読み出す。例えば、ユーザから３日前と指定された場合には、３日前のデータを読み出すような機能を持つ。
【０１１２】
記憶変換装置４０１は、例えば、データ抽出部２０２の機能とデータ復旧部２０４のような機能を持てばよい。
【０１１３】
このように、処理実行部１０１が記憶退避装置２０３へのデータの書き込みや読み出しを記憶変換装置４０１を介して行うことにより、あたかも通常の記憶装置へのデータの書き込みや読み出しを行っているかのように動作させることができる。すなわち、記憶変換装置４０１と記憶退避装置２０３の組み合わせてできた装置を、一つの記憶装置１０２´とすると、これが図１における通常の記憶装置１０２と同等の機能で動作することになる。
【０１１４】
また、記憶退避装置２０３が移動された後には、管理用ＯＳ２のデータ抽出部２０２は、記憶装置１０２´からのデータ（実際には、記憶変換装置４０１からのデータ）を受信し、記憶退避装置２０３の代わりに新たに接続した記憶退避装置２０３´への書き込みを、第１の実施形態と同様に行えばよい。
【０１１５】
このように、記憶変換装置４０１を追加した障害復旧を行うことにより、記憶装置１０２へのデータのに書き戻しのような復旧作業を行うことなく、瞬時に動作ＯＳ１を障害発生前の状態で動作させることができる。この方法によれば、瞬時に障害を復旧することができ、例えばオンラインショッピングサイトのサービス等を行っている計算機システムのように、動作ＯＳ１を長期間停止できないあるいは無停止で運用させることが重要であるような算機システムには特に効果的である。
【０１１６】
なお、この構成を障害復旧中の一時的な特殊構成と考えず、最初から記憶装置及び記憶退避装置が、いずれも、記憶変換装置４０１と記憶退避装置２０３を包含する装置であるとすれば、記憶装置と記憶退避装置とを区別することなく、障害が発生するたびに両者を入れ換えるようにする構成も可能である。この場合、管理用ＯＳ２において、データ抽出部２０２の役割を記憶変換装置４０１が果たすようにすれば、データ抽出部２０２を省くことが可能である。
【０１１７】
また、図１２では、管理用ＯＳ２の記憶退避装置２０３のデータをもとに障害復旧を行う例を示したが、図１２の構成例に更に図１１の遠隔管理装置３（ただし、遠隔データ復旧部３０３は除く）を付加し、上記と同様に、障害発生検知時に、管理用ＯＳ２の記憶退避装置２０３または遠隔管理装置３の遠隔記憶退避装置３０２を動作ＯＳ１側に接続して、記憶退避装置２０３または遠隔記憶退避装置３０２のデータをもとに障害復旧を行うようにする構成も可能である。
【０１１８】
また、この例は、障害発生時の一時的な復旧措置を迅速化させる目的のものであるから、一時的に管理用ＯＳ２を取り外し、記憶変換装置４０１を加えた動作ＯＳ１のみで動作させるという運用も可能である。
【０１１９】
（変形例）
本実施形態では、第１〜第４の実施形態で説明した各構成に関する変形例について説明する。
【０１２０】
＜１＞各実施形態に係る計算機システムを高性能化する一つの手法として、保存データ量を削減することも可能である。管理用ＯＳ２のデータ抽出部２０２が、抽出したデータを記憶退避装置２０３にデータを保存する際、データを逐次そのまま記憶させていくのでは、保存すべきデータが膨大になるが、既に記憶されている過去の退避データを記憶退避装置より読み出し、再利用することにより、保存データを削減し、性能を向上させることが可能である。
【０１２１】
例えば、内容の変更されていない単位データ（ファイル）の保存を省略したり、ごく一部だけが変更されている単位データ（ファイル）に対してはその差分データのみを保存するなどにより、保存データを大幅に削減することができる。これは、遠隔管理装置３においてデータ受信部３０１が遠隔記憶退避装置３０２にデータを保存する際にも用いることができる。
【０１２２】
また、ＯＳ状態検出部２０１が、動作ＯＳ１の実行が終了したことを検出し、その情報を記憶装置１０２からデータを取り出す際に利用することができる。
【０１２３】
利用方法の一例としては、例えば、動作ＯＳ１の実行終了時には、通常のデータ保存時よりも詳細なデータを保存する方法がある。つまり、動作ＯＳの起動途中とは異なる実行終了時特有のデータを追加して保存する。
【０１２４】
また、他の利用方法例としては、動作ＯＳ１の実行終了後には、記憶装置１０２のデータ内容全てを保存し、それ以外の場合には前回の動作ＯＳ１の実行終了時のデータに基づく差分データのみを保存するようにする方法がある。これによって、障害復旧に必要なデータの保存をより効率的に行うことができる。
【０１２５】
また、このような方法を取ることにより、障害復旧処理時にどのデータを採用すべきか判りやすくなる場合がある。例えば、「３日前の午後３時２１分のデータ」と表示されているよりも「３日前の、一番最後にＯＳの実行を終了した時のデータ」と表示されている方が好都合である場合があると考えられる。
【０１２６】
このように、動作ＯＳの実行が終了したことを検出し、その情報を記憶装置からデータを取り出す際に利用することによって、データの保存処理を効率化したり、障害復旧処理を簡便にしたりする効果が期待できる。
【０１２７】
また、ＯＳ状態検出部２０１が、動作ＯＳ１の実行が終了したことを検出することができるため、例えば、「障害復旧機能の起動」といった特別の作業を行う必要はなく、計算機のユーザからは、実際には動作ＯＳ１と管理用ＯＳ２とが動いているにもかかわらず、あたかも動作ＯＳ１だけが動いていて、その通常使っている動作ＯＳ１をそのまま使っている感覚で使えるという利点がある。
【０１２８】
＜２＞また、ＯＳ状態検出部２０１が、動作ＯＳ１の実行処理部１０１が記憶装置１０２のデータに変更を加えたことを検出し、その情報を記憶装置１０２からデータを取り出す際に利用することができる。一般に、管理用ＯＳ２が動作ＯＳ１の記憶装置１０２の内容だけを見てその内容の変化をリアルタイムに知るためには記憶装置１０２の全体を繰り返し検索する必要があるが、動作ＯＳ１が記憶装置１０２の内容に変更を加えたことを直接にデータ抽出部２０２に伝える手段があれば、記憶装置１０２の内容のうち変更されたと判っている部分のみを検索すれば済むため、データを取り出す効率が良くなる。例えば、動作ＯＳ１の処理実行部１０１のデータ処理に関するシステムコールを改造し、データ抽出部２０２に記憶装置に関連する情報（ファイル名やノード番号等）を伝える仕組みにすることによりこの機能が実現できる。
【０１２９】
＜３＞また、本実施形態を一般の計算機に実装する一つの手法として、他のＯＳを実行するための仮想計算機ソフトウェアを用いる手法がある。
【０１３０】
仮想計算機ソフトウェアとしては例えばＶＭｗａｒｅ（Ｊ． Ｓｕｇｅｒｍａｎ， ｅｔ． ａｌ， Ｖｉｒｔｕａｌｉｚｉｎｇ Ｉ／Ｏ Ｄｅｖｉｃｅｓ ｏｎ ＶＭｗａｒｅ Ｗｏｒｋｓｔａｔｉｏｎ■ｓ Ｈｏｓｔｅｄ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ， ２００１ ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ， ２００１／７／２５）がある。
【０１３１】
この場合、一つの主たるＯＳ（ホストＯＳと呼ぶ）上で動作する仮想計算機ソフトウェアを用意する。この仮想計算機は、ＣＰＵを直接実行し、さまざまな周辺デバイスを仮想化して組み込むことにより、あたかも実際の計算機が動いているかのごとく動作し、実際の計算機とほぼ同等の性能で動作するものである。仮想計算機ソフトウェアは、ホストＯＳ上に１つまたは複数動作させることができ、それぞれの仮想計算機に副たるＯＳ（ゲストＯＳと呼ぶ）を実装することができるため、結果として１台の計算機上に２つ以上所望する数だけＯＳを同時に動作させることができる。この仕組みを用いて、動作ＯＳ１と管理用ＯＳ２とを同時に１台の計算機上に実装することができる。
【０１３２】
これにより、特別な計算機装置を用意することなく、１台の計算機で容易に本計算機システムを実装することが可能となる。
【０１３３】
例えば、本実施形態を計算機に実装するにあたって、図１３に例示するように、管理用ＯＳ２は、他のＯＳを実行するための仮想計算機ソフトウェア２２を持ち、動作ＯＳ１は該ソフトウェア２２上で動作するという構成が可能である。この様子を障害復旧を確実に行うためには、動作ＯＳと管理用ＯＳを同時に動かすことが望ましいが、仮想計算機ソフトウェアを用いることにより、特別な計算機装置を用意することなく、１台の計算機で容易に本計算機システムを実装することが可能となる。
【０１３４】
また、仮想計算機ソフトウェアを使う利点としては、動作ＯＳ１と管理用ＯＳ２とが同一のハードウェアを共有していることから、管理用ＯＳ２のＯＳ状態検出部が、動作ＯＳ１の処理実行部１０１からの情報を受け取るための実装が容易になり、また、管理用ＯＳ２のデータ抽出部２０２が動作ＯＳ１の記憶装置１０２からのデータを受け取るための実装も容易になる。
【０１３５】
さらには、障害の復旧時においても、データ復旧部２０４が記憶退避装置２０３からのデータをもとに記憶装置１０２に復旧のためのデータを書き込む実装も容易になり、また、その性能も向上することが期待できるという効果がある。
【０１３６】
この方法の場合、ゲストＯＳはホストＯＳの上に実装される以上、安全性はゲストＯＳがホストＯＳを上回ることは通常考えられない。なぜなら、ホストＯＳが破壊された場合、必然的にゲストＯＳも破壊される可能性が高いからである。したがって、動作ＯＳ１は必ずゲストＯＳとして実装され、管理用ＯＳ２はゲストＯＳであってもホストＯＳであってもよい。
【０１３７】
また、１つの管理用ＯＳ１に対して複数の動作ＯＳ２がゲストＯＳとして実装されることも可能であるし、また、遠隔管理装置３も、このゲストＯＳまたはホストＯＳとして実装されることも可能である。
【０１３８】
また、この方法の場合、ホストＯＳを起動すると同時にゲストＯＳを起動させることができるため、計算機のユーザからは、実際には動作ＯＳ１と管理用ＯＳ２とが動いているにもかかわらず、あたかも動作ＯＳ１だけが動いていて、その通常使っている動作ＯＳ１をそのまま使っている感覚で使えるという環境を自然に実現することができるという効果もある。
【０１３９】
＜４＞また、以上では、１つの管理用ＯＳ２が１つの動作ＯＳ１を管理対象とするものであったが、図１４に例示するように、１つの管理用ＯＳ２が複数の動作ＯＳ１を管理対象とすることも可能である。図１４は、ｎ台の計算機Ａ１〜Ａｎ上でそれぞれ動作する動作ＯＳ１を、それら計算機Ａ１〜ＡｎとＬＡＮあるいはインターネット等のネットワーク８で接続された計算機Ｂ上で動作する管理用ＯＳ２が管理対象とする例である。
【０１４０】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１４１】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１４２】
【発明の効果】
本発明によれば、計算機の障害復旧に必要なデータを従来よりも確実に保存することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図２】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【図３】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【図４】管理用ＯＳの処理手順の一例を示すフローチャート
【図５】管理用ＯＳの処理について説明するための図
【図６】管理用ＯＳの処理について説明するための図
【図７】管理用ＯＳの処理について説明するための図
【図８】本発明の第２の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図９】管理用ＯＳの処理手順の一例を示すフローチャート
【図１０】管理用ＯＳの処理について説明するための図
【図１１】本発明の第３の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図１２】本発明の第４の実施形態に係るデータ管理システムを含む計算機システムの構成例を示す図
【図１３】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【図１４】動作ＯＳ１及び管理用ＯＳ２の実現形態について説明するための図
【符号の説明】
１…動作ＯＳ、２…管理用ＯＳ、３…遠隔管理装置、４，８…ネットワーク、２２…仮想計算機ソフトウェア、１０１…処理実行部、１０２，１０２´…記憶装置、２０１…ＯＳ状態検出部、２０２…データ抽出部、２０３，２０３´…記憶退避装置、２０４…データ復旧部、３０１…データ受信部、３０２…遠隔記憶退避装置、３０３…遠隔データ復旧部、４０１…記憶変換装置、Ａ，Ａ１〜Ａｎ，Ｂ〜Ｄ…計算機
Claims (22)
- 対象オペレーティングシステムの持つ記憶装置のデータを管理するデータ管理システムにおいて、
前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムを設け、
前記管理用オペレーティングシステムが、
前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出する動作状態検出手段と、
前記動作検出手段により検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出する抽出手段と、
抽出された前記データを退避させるための退避用記憶手段とを備えたことを特徴とするデータ管理システム。 - 前記管理用オペレーティングシステムは、前記対象オペレーティングシステムに比較して、よりセキュリティ・ホールの少ないものであることを特徴とする請求項１に記載のデータ管理システム。
- 前記管理用オペレーティングシステムは、前記対象オペレーティングシステムに比較して、より機能が制限されたものであることを特徴とする請求項１に記載のデータ管理システム。
- 前記対象オペレーティングシステムは外部のネットワークへ接続する機能を包含するものであるのに対し、前記管理用オペレーティングシステムは外部のネットワークへ接続する機能を包含しないものであることを特徴とする請求項１に記載のデータ管理システム。
- 外部のネットワークから前記対象オペレーティングシステムへのアクセスに比較して外部のネットワークから前記管理用オペレーティングシステムへのアクセスをより厳しく制限することを特徴とする請求項１に記載のデータ管理システム。
- 前記管理用オペレーティングシステムのソフトウェアは、前記対象オペレーティングシステムのソフトウェアが動作する計算機と同一の計算機上で動作することを特徴とする請求項１に記載のデータ管理システム。
- 前記管理用オペレーティングシステムは、前記対象オペレーティングシステムのソフトウエアを実行可能な仮想計算機のソフトウエアを含み、前記対象オペレーティングシステムのソフトウエアは、該仮想計算機上で動作することを特徴とする請求項１に記載のデータ管理システム。
- 前記管理用オペレーティングシステムのソフトウェアは、前記対象オペレーティングシステムのソフトウェアが動作する計算機とは異なる計算機上で動作することを特徴とする請求項１に記載のデータ管理システム。
- 前記データ管理システムは、前記管理用オペレーティングシステムとは独立して設けられた１又は複数の遠隔管理装置を更に備え、
前記遠隔管理装置は、前記抽出手段により抽出された前記データの全部又は一部を退避させるための遠隔退避用記憶手段を含むことを特徴とする請求項１に記載のデータ管理システム。 - 前記管理用オペレーティングシステムは、前記記憶手段の内容を過去の或る時点の状態に復旧させるべく前記退避用記憶手段に退避されたデータを前記記憶手段へ書き戻す手段を更に備えたことを特徴とする請求項１に記載のデータ管理システム。
- 前記管理用オペレーティングシステムは、前記記憶手段の内容を過去の或る時点の状態に復旧させるべく前記退避用記憶手段又は前記遠隔退避用記憶手段に退避されたデータを前記記憶手段へ書き戻す手段を更に備えたことを特徴とする請求項９に記載のデータ管理システム。
- 前記遠隔管理装置は、前記記憶手段の内容を過去の或る時点の状態に復旧させるべく前記遠隔退避用記憶手段に退避されたデータを前記記憶手段へ書き戻す手段を更に備えたことを特徴とする請求項９に記載のデータ管理システム。
- 前記対象オペレーティングシステムは、前記退避用記憶手段が接続された場合に、該接続された退避用記憶手段に退避されたデータを、過去の或る時点に前記記憶装置に記憶されていたデータとして読み出す手段を含むことを特徴とする請求項１に記載のデータ管理システム。
- 前記対象オペレーティングシステムは、前記退避用記憶手段又は前記遠隔退避用記憶手段が接続された場合に、該接続された退避用記憶手段又は遠隔退避用記憶手段に退避されたデータを、過去の或る時点に前記記憶装置に記憶されていたデータとして読み出す手段を含むことを特徴とする請求項１に記載のデータ管理システム。
- 前記抽出手段は、抽出した前記データを退避するのに先立って、既に退避されている退避データに基づいて該抽出したデータをよりデータ量の少ない形態に変換することを特徴とする請求項１に記載のデータ管理システム。
- 前記変換は、抽出した前記データに対応する過去の時点のデータが既に退避されている場合に、該過去の時点のデータを基準にして該抽出したデータを圧縮するものであることを特徴とする請求項１５に記載のデータ管理システム。
- 前記予め定められた動作状態は、前記対象オペレーティングシステムがその実行を終了することを示す第１の動作状態を含むことを特徴とする請求項１に記載のデータ管理システム。
- 前記予め定められた動作状態は、前記対象オペレーティングシステムがその実行を開始することを示す第２の動作状態を含むことを特徴とする請求項１に記載のデータ管理システム。
- 前記予め定められた動作状態は、前記対象オペレーティングシステムがアプリケーションプログラムのインストールを実行することを示す第３の動作状態を含むことを特徴とする請求項１に記載のデータ管理システム。
- 前記予め定められた動作状態は、前記対象オペレーティングシステムが前記記憶装置内のデータに変更を加えたことを示す第４の動作状態を含むことを特徴とする請求項１に記載のデータ管理システム。
- 対象オペレーティングシステムの持つ記憶装置のデータを、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムにより管理するデータ管理方法であって、
前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出するステップと、
検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出するステップと、
抽出された前記データを退避用記憶装置に退避させるステップとを有することを特徴とするデータ管理方法。 - 対象オペレーティングシステムの持つ記憶装置のデータを、前記対象オペレーティングシステムとは独立した管理用オペレーティングシステムにより管理するデータ管理装置としてコンピュータを機能させるためのプログラムであって、
前記対象オペレーティングシステムの動作状態が予め定められた複数の動作状態のいずれかに該当する場合に、該対象オペレーティングシステムの動作状態を検出する機能と、
検出された前記動作状態に応じて前記記憶装置から退避させるべきデータを抽出する機能と、
抽出された前記データを退避用記憶装置に退避させる機能とをコンピュータに実現させるためのプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003155928A JP2004361994A (ja) | 2003-05-30 | 2003-05-30 | データ管理装置、データ管理方法及びプログラム |
| US10/718,520 US20040255183A1 (en) | 2003-05-30 | 2003-11-24 | Data management method and apparatus and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003155928A JP2004361994A (ja) | 2003-05-30 | 2003-05-30 | データ管理装置、データ管理方法及びプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004361994A true JP2004361994A (ja) | 2004-12-24 |
Family
ID=33508289
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003155928A Pending JP2004361994A (ja) | 2003-05-30 | 2003-05-30 | データ管理装置、データ管理方法及びプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040255183A1 (ja) |
| JP (1) | JP2004361994A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100737522B1 (ko) | 2005-12-02 | 2007-07-10 | 한국전자통신연구원 | 마이그레이션 데이터 모니터링 방법 및 시스템 |
| JP2007323244A (ja) * | 2006-05-31 | 2007-12-13 | Nec Corp | 仮想サーバ管理システムおよびその方法ならびに管理サーバ装置 |
| EP2154626A2 (en) | 2008-08-13 | 2010-02-17 | Fujitsu Ltd. | Anti-virus method, computer, and recording medium |
| JP2010277595A (ja) * | 2010-06-22 | 2010-12-09 | Nec Corp | 仮想サーバ管理システムおよびその方法ならびに管理サーバ装置 |
| JP2013218481A (ja) * | 2012-04-06 | 2013-10-24 | Nippon Telegr & Teleph Corp <Ntt> | データベースシステム |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7702966B2 (en) * | 2005-09-07 | 2010-04-20 | Intel Corporation | Method and apparatus for managing software errors in a computer system |
| CN101154253B (zh) * | 2006-09-26 | 2011-08-10 | 北京软通科技有限责任公司 | 计算机安全防护方法及计算机安全防护装置 |
| JP4809209B2 (ja) | 2006-12-28 | 2011-11-09 | 株式会社日立製作所 | サーバ仮想化環境における系切り替え方法及び計算機システム |
| US12613692B1 (en) * | 2024-03-15 | 2026-04-28 | Hewlett Packard Enterprise Development Lp | Transformer utility of a network device management system to facilitate an in-service software upgrade procedure |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5469573A (en) * | 1993-02-26 | 1995-11-21 | Sytron Corporation | Disk operating system backup and recovery system |
| US5907672A (en) * | 1995-10-04 | 1999-05-25 | Stac, Inc. | System for backing up computer disk volumes with error remapping of flawed memory addresses |
| US5926836A (en) * | 1996-12-03 | 1999-07-20 | Emc Corporation | Computer and associated method for restoring data backed up on archive media |
| US6073220A (en) * | 1997-09-03 | 2000-06-06 | Duocor, Inc. | Apparatus and method for providing a transparent disk drive back-up |
| DE69832096T2 (de) * | 1997-12-12 | 2006-07-13 | Alcatel USA Sourcing, L.P., Plano | Netzwerkverwaltung |
| US6901493B1 (en) * | 1998-02-24 | 2005-05-31 | Adaptec, Inc. | Method for protecting data of a computer system |
| US6266784B1 (en) * | 1998-09-15 | 2001-07-24 | International Business Machines Corporation | Direct storage of recovery plan file on remote server for disaster recovery and storage management thereof |
| US7089449B1 (en) * | 2000-11-06 | 2006-08-08 | Micron Technology, Inc. | Recovering a system that has experienced a fault |
| US7114184B2 (en) * | 2001-03-30 | 2006-09-26 | Computer Associates Think, Inc. | System and method for restoring computer systems damaged by a malicious computer program |
-
2003
- 2003-05-30 JP JP2003155928A patent/JP2004361994A/ja active Pending
- 2003-11-24 US US10/718,520 patent/US20040255183A1/en not_active Abandoned
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100737522B1 (ko) | 2005-12-02 | 2007-07-10 | 한국전자통신연구원 | 마이그레이션 데이터 모니터링 방법 및 시스템 |
| JP2007323244A (ja) * | 2006-05-31 | 2007-12-13 | Nec Corp | 仮想サーバ管理システムおよびその方法ならびに管理サーバ装置 |
| EP2154626A2 (en) | 2008-08-13 | 2010-02-17 | Fujitsu Ltd. | Anti-virus method, computer, and recording medium |
| US8176558B2 (en) | 2008-08-13 | 2012-05-08 | Fujitsu Limited | Anti-virus method, computer, and recording medium |
| JP2010277595A (ja) * | 2010-06-22 | 2010-12-09 | Nec Corp | 仮想サーバ管理システムおよびその方法ならびに管理サーバ装置 |
| JP2013218481A (ja) * | 2012-04-06 | 2013-10-24 | Nippon Telegr & Teleph Corp <Ntt> | データベースシステム |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040255183A1 (en) | 2004-12-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| TWI495997B (zh) | 用於自管理處理之方法、裝置、及機器可讀取媒體 | |
| US8024601B2 (en) | Restarting method using a snapshot | |
| US7447888B2 (en) | Method for restoring computer operating system | |
| US11221927B2 (en) | Method for the implementation of a high performance, high resiliency and high availability dual controller storage system | |
| US10509646B2 (en) | Software update rollbacks using file system volume snapshots | |
| CN115729647B (zh) | 服务器启动管理系统及方法 | |
| JP2003208314A (ja) | オペレーティングシステムの自動入れ替え可能な計算機システムおよびそのシステムを利用したオペレーションシステムの自動入れ替え方法 | |
| JP2004361994A (ja) | データ管理装置、データ管理方法及びプログラム | |
| CN111090546B (zh) | 一种操作系统重启方法、装置、设备及可读存储介质 | |
| CN113849235A (zh) | 控制方法、装置及电子设备 | |
| US11226875B2 (en) | System halt event recovery | |
| US20160004607A1 (en) | Information processing apparatus and information processing method | |
| CN110457899B (zh) | 一种操作系统保护系统及方法 | |
| WO2024000535A1 (zh) | 分区表更新方法、装置、电子设备及存储介质 | |
| KR101209943B1 (ko) | 윈도우즈 하이브 파일을 이용한 선택적 복원 시스템 및 방법 | |
| CN121858357A (zh) | 基于xfs文件系统的掉电保护方法、装置、设备及介质 | |
| CN120371608A (zh) | 一种嵌入式设备分区文件监控与备份方法及系统 | |
| JP4141680B2 (ja) | データベース管理システム及びデータベースシステムの管理方法 | |
| JP5290064B2 (ja) | ソフトウェア切り替え装置及びソフトウェア切り替え方法並びにそのプログラム | |
| CN115904815A (zh) | 操作系统的更新控制方法、装置及电子设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060829 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060912 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070123 |