(57)【要約】ディザスタ・リカバリのための方法は、第１のデータベースからの少なくとも一部の情報を、バックアップ・システムにバックアップ情報としてコピーするステップを含む。また本方法は、増分変更を第２のデータベース内に格納するステップも含む。増分変更は、第１のデータベース内の少なくとも一部の情報に対する変更を表わす。本方法はさらに、第１のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元するステップを含む。
2005523517.tif 000002
【特許請求の範囲】
【請求項１】
ディザスタ・リカバリのための方法であって、
第２のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を第１のデータベース内に格納するために伝達するステップと、
バックアップ・システム内に以前に格納されている第２のデータベースからの情報の少なくとも一部を含むバックアップ情報および増分変更の少なくとも一方を受け取るステップと、
第２のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元するステップと、を含むディザスタ・リカバリのための方法。
【請求項２】
第２のデータベースを復元するステップが、
バックアップ情報を第２のデータベース内に格納するステップと、
増分変更を、第２のデータベース内の少なくとも一部の情報に対して行なうステップと、を含む請求項１に記載の方法。
【請求項３】
増分変更を受け取るステップが、
第１の増分変更をバックアップ・システムから受け取るステップと、
第２の増分変更を第１のデータベースから受け取るステップと、を含む請求項１に記載の方法。
【請求項４】
第２のデータベースを復元するステップが、
バックアップ情報を第２のデータベース内に格納するステップと、
第１の増分変更を、第２のデータベース内の少なくとも一部の情報に対して行なうステップと、
第１の増分変更を行なった後で、第２の増分変更を、第２のデータベース内の少なくとも一部の情報に対して行なうステップと、を含む請求項３に記載の方法。
【請求項５】
復元時間を受け取るステップをさらに含み、
第２のデータベースを復元するステップが、
バックアップ情報を第２のデータベース内に格納するステップと、
第１の増分変更に付随する第１の時間が復元時間を超えていないときに、第２のデータベース内の少なくとも一部の情報に対して第１の増分変更を行なうステップと、
第２の増分変更に付随する第２の時間が復元時間を超えていないときに、第２のデータベース内の少なくとも一部の情報に対して第２の増分変更を行なうステップと、を含む請求項３に記載の方法。
【請求項６】
増分変更を第１のデータベース内に格納するために伝達するステップが、
少なくとも１つのファイル・システム内の増分変更を検出するステップと、
複数の時間ウィンドウのそれぞれの間に検出される複数の増分変更を蓄積するステップと、
それぞれの時間ウィンドウの後で、蓄積された増分変更を第１のデータベース内に格納するために伝達するステップと、を含む請求項１に記載の方法。
【請求項７】
第２のデータベースからの情報の少なくとも一部を、バックアップ・システム内にバックアップ情報として格納するために伝達するステップをさらに含む請求項１に記載の方法。
【請求項８】
第２のデータベースからの情報の少なくとも一部をバックアップ・システムに伝達する前に、増分変更を検出して第１のデータベース内に格納するために伝達するように動作可能である複製タスクを開始するステップを、さらに含む請求項７に記載の方法。
【請求項９】
タスク・ファイルにアクセスして、増分変更についてモニタすべき第１のファイルと、増分変更についてモニタすべき第１のフォルダと、増分変更についてモニタすべき第１のレジストリと、モニタリングから除外すべき第２のファイルと、モニタリングから除外すべき第２のフォルダと、モニタリングから除外すべき第２のレジストリとのうちの少なくとも１つを特定するステップをさらに含む請求項８に記載の方法。
【請求項１０】
増分変更が、第２のデータベース内のファイルまたはレジストリの少なくとも一部に対する変更を表わす請求項１に記載の方法。
【請求項１１】
ディザスタ・リカバリのためのシステムであって、
少なくとも１つのコンピュータ可読媒体と、
少なくとも１つのコンピュータ可読媒体上でエンコードされるロジックと、を備え、
前記ロジックは、実行時に、
第２のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を第１のデータベース内に格納するために伝達するステップと、
バックアップ・システム内に以前に格納されている第２のデータベースからの情報の少なくとも一部を含むバックアップ情報および増分変更の少なくとも一方を受け取るステップと、
第２のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元するステップと、を行なうように動作可能であるシステム。
【請求項１２】
前記ロジックが、
バックアップ情報を第２のデータベース内に格納するステップと、
増分変更を、第２のデータベース内の少なくとも一部の情報に対して行なうステップとによって、第２のデータベースを復元するように動作可能である請求項１１に記載のシステム。
【請求項１３】
前記ロジックが、
第１の増分変更をバックアップ・システムから受け取るステップと、
第２の増分変更を第１のデータベースから受け取るステップとによって、増分変更を受け取るように動作可能である請求項１１に記載のシステム。
【請求項１４】
前記ロジックが、
バックアップ情報を第２のデータベース内に格納するステップと、
第１の増分変更を、第２のデータベース内の少なくとも一部の情報に対して行なうステップと、
第１の増分変更を行なった後で、第２の増分変更を、第２のデータベース内の少なくとも一部の情報に対して行なうステップとによって、第２のデータベースを復元するように動作可能である請求項１３に記載のシステム。
【請求項１５】
前記ロジックがさらに、復元時間を受け取るように動作可能であり、
前記ロジックは、
バックアップ情報を第２のデータベース内に格納するステップと、
第１の増分変更に付随する第１の時間が復元時間を超えていないときに、第２のデータベース内の少なくとも一部の情報に対して第１の増分変更を行なうステップと、
第２の増分変更に付随する第２の時間が復元時間を超えていないときに、第２のデータベース内の少なくとも一部の情報に対して第２の増分変更を行なうステップとによって、第２のデータベースを復元するように動作可能である請求項１３に記載のシステム。
【請求項１６】
前記ロジックがさらに、第２のデータベースからの情報の少なくとも一部を、バックアップ・システム内にバックアップ情報として格納するために伝達するように動作可能である請求項１１に記載のシステム。
【請求項１７】
ディザスタ・リカバリのためのシステムであって、
情報を格納するように動作可能な第１のデータベースと、
１つまたは複数のプロセッサとを備え、
前記１つまたは複数のプロセッサは、
第１のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を第２のデータベース内に格納するために伝達するステップと、
バックアップ・システム内に以前に格納されている第１のデータベースからの情報の少なくとも一部を含むバックアップ情報および増分変更の少なくとも一方を受け取るステップと、
第１のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元するステップと、
を行なうように共同して動作可能であるシステム。
【請求項１８】
前記１つまたは複数のプロセッサが、
バックアップ情報を第１のデータベース内に格納するステップと、
増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップとによって、第１のデータベースを復元するように共同して動作可能である請求項１７に記載のシステム。
【請求項１９】
前記１つまたは複数のプロセッサが、
第１の増分変更をバックアップ・システムから受け取るステップと、
第２の増分変更を第１のデータベースから受け取るステップとによって、増分変更を受け取るように共同して動作可能である請求項１７に記載のシステム。
【請求項２０】
前記１つまたは複数のプロセッサが、
バックアップ情報を第１のデータベース内に格納するステップと、
第１の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップと、
第１の増分変更を行なった後で、第２の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップとによって、第１のデータベースを復元するように共同して動作可能である請求項１９に記載のシステム。
【請求項２１】
前記１つまたは複数のプロセッサがさらに、復元時間を受け取るように共同して動作可能であり、
前記１つまたは複数のプロセッサが、
バックアップ情報を第１のデータベース内に格納するステップと、
第１の増分変更に付随する第１の時間が復元時間を超えていないときに、第１のデータベース内の少なくとも一部の情報に対して第１の増分変更を行なうステップと、
第２の増分変更に付随する第２の時間が復元時間を超えていないときに、第１のデータベース内の少なくとも一部の情報に対して第２の増分変更を行なうステップとによって、第１のデータベースを復元するように共同して動作可能である請求項１９に記載のシステム。
【請求項２２】
前記１つまたは複数のプロセッサがさらに、第１のデータベースからの情報の少なくとも一部を、バックアップ・システム内にバックアップ情報として格納するために伝達するように共同して動作可能である請求項１７に記載のシステム。
【請求項２３】
ディザスタ・リカバリのためのシステムであって、
少なくとも１つの第１のファイル・システム内の情報に対する複数の増分変更を検出するように動作可能なファイル・システム・モニタと、
複数の増分変更を受け取るように、および受け取った複数の増分変更を決められた時間間隔の間蓄積するように、動作可能であるトランザクション・アキュームレータと、
複製タスクを実行するように動作可能なサービスであって、複製タスクは、蓄積された増分変更を受け取るように、および蓄積された増分変更を、第２のファイル・システム内に格納するために伝達するように動作可能である、サービスと、を備え、
少なくとも１つの第１のファイル・システムを、バックアップ情報および増分変更の少なくとも一方を用いて復元することができ、バックアップ情報は、バックアップ・システム内に以前に格納されている少なくとも１つの第１のファイル・システムからの情報の少なくとも一部を含むシステム。
【請求項２４】
ディザスタ・リカバリのためのシステムであって、
増分変更を第１のデータベース内に格納するために伝達する手段であって、増分変更は、第２のデータベース内の少なくとも一部の情報に対する変更を表わす、手段と、
バックアップ情報および増分変更の少なくとも一方を受け取る手段であって、バックアップ情報は、バックアップ・システム内に以前に格納されている第２のデータベースからの情報の少なくとも一部を含む、手段と、
第２のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元する手段と、を備えるシステム。
【請求項２５】
ディザスタ・リカバリのための方法であって、
第１のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を受け取るステップと、
増分変更を第２のデータベース内に格納するステップと、
増分変更を、第１のデータベースの復元にて用いるために伝達するステップであって、第１のデータベースの復元を、バックアップ情報および増分変更の少なくとも一方を用いて行ない、バックアップ情報は、バックアップ・システム内に以前に格納されている第１のデータベースからの情報の少なくとも一部を含む、ステップと、を含む方法。
【請求項２６】
増分変更が第１の増分変更を含み、
前記方法がさらに、
第２の増分変更を受け取るステップと、
第２の増分変更を第２のデータベース内に格納するステップと、
第２の増分変更をバックアップ・システム内に格納するために伝達するステップであって、バックアップ・システムは、第２の増分変更を、第１のデータベースの復元にて用いるために伝達するように動作可能である、ステップと、を含む請求項２５に記載の方法。
【請求項２７】
第１の増分変更を第２のデータベース内に格納するステップが、第１の増分変更を第１のフォルダ内に格納するステップを含み、
第２の増分変更をバックアップ・システム内に格納するために伝達するステップが、第２の増分変更を含む第２のフォルダの少なくとも一部を、バックアップ・システム内に格納するために伝達することを含む請求項２６に記載の方法。
【請求項２８】
第２のフォルダの少なくとも一部を、バックアップ・システム内に格納するために伝達する前に、第２のフォルダの名前を古い名前から新しい名前に変更するステップであって、新しい名前にはタイムスタンプが含まれるステップと、
第１のフォルダを作成するステップであって、第１のフォルダは第２のフォルダの古い名前を有するステップと、をさらに含む請求項２７に記載の方法。
【請求項２９】
増分変更が、第１のデータベース内の第１のファイル・システム・フォルダ内に位置する第１のファイルに付随し、第１のファイル・システム・フォルダは第１のドライブ・フォルダ内に位置し、第１のファイルはファイル名を有し、
増分変更を第２のデータベース内に格納するステップが、増分変更を第２のファイル・システム・フォルダ内に位置する第２のフォルダ内に格納するステップを含み、第２のファイル・システム・フォルダは第１のファイル・システム・フォルダに付随し、第２のファイル・システム・フォルダは、第１のドライブ・フォルダに付随する第２のドライブ・フォルダ内に位置し、第２のファイルはファイル名を有する請求項２５に記載の方法。
【請求項３０】
増分変更を第２のファイル内に格納するステップが、
第２のドライブ・システム・フォルダが存在するかどうかを判定するステップと、
第２のドライブ・システム・フォルダが存在しない場合に、それを作成するステップと、
第２のファイル・システム・フォルダが存在するかどうかを判定するステップと、
第２のファイル・システム・フォルダが存在しない場合に、それを作成するステップと、
第２のファイルが存在するかどうかを判定するステップと、
第２のファイルが存在しない場合に、それを作成するステップと、を含む請求項２９に記載の方法。
【請求項３１】
増分変更が複数のタイムスタンプ・フォルダの１つに格納され、タイムスタンプ・フォルダの１つが現在の時間間隔を表わし、残りのタイムスタンプ・フォルダの少なくとも１つが、少なくとも１つの以前の時間間隔を表わす請求項２５に記載の方法。
【請求項３２】
復元時間を受け取るステップをさらに含み、
増分変更を、第１のデータベースの復元にて用いるために伝達するステップが、
タイムスタンプ・フォルダに付随する、増分変更が格納される時間が、復元時間を超えているかどうかを判定するステップと、
タイムスタンプ・フォルダに付随する時間が復元時間を超えていないときに、増分変更を、第１のデータベースの復元にて用いるために伝達するステップと、を含む請求項３１に記載の方法。
【請求項３３】
バックアップ情報を受け取るステップと、
バックアップ情報をバックアップ・システム内に格納するステップと、をさらに含む請求項２５に記載の方法。
【請求項３４】
増分変更が、第１のデータベース内のファイルまたはレジストリの少なくとも一部に対する変更を表わす請求項２５に記載の方法。  
【請求項３５】
ディザスタ・リカバリのためのシステムであって、
少なくとも１つのコンピュータ可読媒体と、
少なくとも１つのコンピュータ可読媒体上でエンコードされるロジックと、を備え、
前記ロジックは、実行時に、
第１のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を受け取るステップと、
増分変更を第２のデータベース内に格納するステップと、
増分変更を、以前に格納されている第１のデータベースからの情報の少なくとも一部を含むバックアップ情報および増分変更の少なくとも一方を用いて復元された第１のデータベースの復元に用いるために伝達するステップと、
を行なうように動作可能であるシステム。
【請求項３６】
増分変更が第１の増分変更を含み、
前記ロジックがさらに、
第２の増分変更を受け取るステップと、
第２の増分変更を第２のデータベース内に格納するステップと、
第２の増分変更を、第２の増分変更を第１のデータベースの復元にて用いるために伝達するように動作可能であるバックアップ・システム内に格納するために伝達するステップと、
を行なうように動作可能である請求項３５に記載のシステム。
【請求項３７】
前記ロジックが、第１の増分変更を、第２のデータベース内の第１のフォルダ内に格納するように動作可能であり、
前記ロジックが、第２の増分変更を、第２のデータベース内の第２のフォルダ内に格納するように動作可能であり、
前記ロジックが、第２のフォルダの少なくとも一部を、バックアップ・システム内に格納するために伝達することによって、第２の増分変更をバックアップ・システム内に格納するために伝達するように動作可能であり、
前記ロジックはさらに、
第２のフォルダの少なくとも一部をバックアップ・システム内に格納するために伝達する前に、第２のフォルダの名前を古い名前からタイムスタンプを含む新しい名前に変更するステップと、
第２のフォルダの古い名前を有する第１のフォルダを作成するステップと、
を行なうように動作可能である請求項３６に記載のシステム。
【請求項３８】
増分変更が、第１のデータベース内の第１のファイル・システム・フォルダ内に位置する第１のファイルに付随し、第１のファイル・システム・フォルダは第１のドライブ・フォルダ内に位置し、第１のファイルはファイル名を有し、
前記ロジックは、
第１のドライブ・システム・フォルダに付随する第２のドライブ・システム・フォルダが第２のデータベース内に存在するかどうかを判定するステップと、
第２のドライブ・システム・フォルダが存在しない場合に、それを作成するステップと、
第１のファイル・システム・フォルダに付随する第２のファイル・システム・フォルダが、第２のデータベース内に存在するかどうかを判定するステップと、
第２のファイル・システム・フォルダが存在しない場合に、それを作成するステップと、
ファイル名を有する第２のファイルが存在するかどうかを判定するステップと、
第２のファイルが存在しない場合に、それを作成するステップと、
増分変更を第２のファイル内に格納するステップと、によって増分変更を格納するように動作可能である請求項３５に記載のシステム。
【請求項３９】
増分変更が複数のタイムスタンプ・フォルダの１つに格納され、タイムスタンプ・フォルダの１つが現在の時間間隔を表わし、残りのタイムスタンプ・フォルダの少なくとも１つが、少なくとも１つの以前の時間間隔を表わし、
前記ロジックはさらに、復元時間を受け取るように動作可能であり、
前記ロジックは、
タイムスタンプ・フォルダに付随する、増分変更が格納される時間が、復元時間を超えているかどうかを判定するステップと、
タイムスタンプ・フォルダに付随する時間が復元時間を超えていないときに、増分変更を第１のデータベースの復元にて用いるために伝達するステップとによって、増分変更を第１のデータベースの復元にて用いるために伝達するように動作可能である請求項３５に記載のシステム。
【請求項４０】
前記ロジックがさらに、
バックアップ情報を受け取るステップと、
バックアップ情報をバックアップ・システム内に格納するステップと、を行なうように動作可能である請求項３５に記載のシステム。
【請求項４１】
ディザスタ・リカバリのためのシステムであって、
増分変更を格納するように動作可能な第１のデータベースと、
１つまたは複数のプロセッサとを備え、
前記１つまたは複数のプロセッサは、
第２のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を受け取るステップと、
増分変更を第１のデータベース内に格納するステップと、
増分変更を、バックアップ・システム内に以前に格納されている第２のデータベースからの情報の少なくとも一部を含むバックアップ情報および増分変更の少なくとも一方を用いて復元された第２のデータベースの復元に用いるために伝達するステップと、
を行なうように共同して動作可能であるシステム。
【請求項４２】
増分変更が第１の増分変更を含み、
前記１つまたは複数のプロセッサがさらに、
第２の増分変更を受け取るステップと、
第２の増分変更を第１のデータベース内に格納するステップと、
第２の増分変更を、第２の増分変更を第２のデータベースの復元にて用いるために伝達するように動作可能であるバックアップ・システム内に格納するために伝達するステップと、
を行なうように共同して動作可能である請求項４１に記載のシステム。
【請求項４３】
前記１つまたは複数のプロセッサが、第１の増分変更を、第１のデータベース内の第１のフォルダ内に格納するように共同して動作可能であり、
前記１つまたは複数のプロセッサが、第２の増分変更を、第１のデータベース内の第２のフォルダ内に格納するように共同して動作可能であり、
前記１つまたは複数のプロセッサが、第２のフォルダの少なくとも一部を、バックアップ・システム内に格納するために伝達することによって、第２の増分変更をバックアップ・システム内に格納するために伝達するように共同して動作可能であって、
前記１つまたは複数のプロセッサはさらに、
第２のフォルダの少なくとも一部をバックアップ・システム内に格納するために伝達する前に、第２のフォルダの名前を古い名前からタイムスタンプを含む新しい名前に変更するステップと、
第２のフォルダの古い名前を有する第１のフォルダを作成するステップと、を行なうように共同して動作可能である請求項４２に記載のシステム。
【請求項４４】
増分変更が、第２のデータベース内の第１のファイル・システム・フォルダ内に位置する第１のファイルに付随し、第１のファイル・システム・フォルダは第１のドライブ・フォルダ内に位置し、第１のファイルはファイル名を有し、
前記１つまたは複数のプロセッサは、
第１のドライブ・システム・フォルダに付随する第２のドライブ・システム・フォルダが第１のデータベース内に存在するかどうかを判定するステップと、
第２のドライブ・システム・フォルダが存在しない場合に、それを作成するステップと、
第１のファイル・システム・フォルダに付随する第２のファイル・システム・フォルダが、第１のデータベース内に存在するかどうかを判定するステップと、
第２のファイル・システム・フォルダが存在しない場合に、それを作成するステップと、
ファイル名を有する第２のファイルが存在するかどうかを判定するステップと、
第２のファイルが存在しない場合に、それを作成するステップと、
増分変更を第２のファイル内に格納するステップと、によって増分変更を格納するように共同して動作可能である請求項４１に記載のシステム。
【請求項４５】
増分変更が複数のタイムスタンプ・フォルダの１つに格納され、タイムスタンプ・フォルダの１つが現在の時間間隔を表わし、残りのタイムスタンプ・フォルダの少なくとも１つが、少なくとも１つの以前の時間間隔を表わし、
前記１つまたは複数のプロセッサはさらに、復元時間を受け取るように共同して動作可能であり、
前記１つまたは複数のプロセッサは、
タイムスタンプ・フォルダに付随する、増分変更が格納される時間が、復元時間を超えているかどうかを判定するステップと、
タイムスタンプ・フォルダに付随する時間が復元時間を超えていないときに、増分変更を第２のデータベースの復元にて用いるために伝達するステップとによって、増分変更を第２のデータベースの復元にて用いるために伝達するように共同して動作可能である請求項４１に記載のシステム。
【請求項４６】
前記１つまたは複数のプロセッサがさらに、
バックアップ情報を受け取るステップと、
バックアップ情報をバックアップ・システム内に格納するステップと、を行なうように共同して動作可能である請求項４１に記載のシステム。
【請求項４７】
ディザスタ・リカバリのためのシステムであって、
複製タスクを実行するように動作可能なサービスであって、複製タスクは、少なくとも１つの第１のファイル・システム内の少なくとも一部の情報に対する変更を表わす増分変更を受け取るように動作可能であり、複製タスクはまた、増分変更を第２のファイル・システム内に格納するように動作可能であり、複製タスクはさらに、増分変更を、少なくとも１つの第１のファイル・システムの復元にて用いるために伝達するように動作可能であり、少なくとも１つの第１のファイル・システムの復元を、バックアップ情報および増分変更の少なくとも一方を用いて行ない、バックアップ情報は、バックアップ・システム内に以前に格納されている少なくとも１つの第１のファイル・システムからの情報の少なくとも一部を含む、サービスと、
複製タスクを制御するように動作可能なインターフェースと、を備えるシステム。
【請求項４８】
ディザスタ・リカバリのためのシステムであって、
データベース内の少なくとも一部の情報に対する変更を表わす増分変更を受け取るための手段と、
増分変更を格納するための手段と、
増分変更を、データベースの復元にて用いるために伝達する手段であって、データベースの復元を、バックアップ情報および増分変更の少なくとも一方を用いて行ない、バックアップ情報は、バックアップ・システム内に以前に格納されているデータベースからの情報の少なくとも一部を含む、手段と、を備えるシステム。
【請求項４９】
ディザスタ・リカバリのための方法であって、
第１のデータベースからの情報の少なくとも一部を含むバックアップ情報を受け取るステップと、
バックアップ情報をバックアップ・システム内に格納するステップと、
増分変更を第２のデータベースから受け取るステップであって、増分変更は、第１のデータベース内の少なくとも一部の情報に対する変更を表わす、ステップと、
増分変更をバックアップ・システム内に格納するステップと、
増分変更およびバックアップ情報を、第１のデータベースの復元にて用いるために伝達するステップと、を含む方法。
【請求項５０】
増分変更を、第２のデータベース内に格納するために受け取るステップと、
増分変更を第２のデータベース内に格納するステップと、
増分変更を第２のデータベースから、バックアップ・システム内に格納するために伝達するステップと、をさらに含む請求項４９に記載の方法。
【請求項５１】
ディザスタ・リカバリのためのシステムであって、
少なくとも１つのコンピュータ可読媒体と、
少なくとも１つのコンピュータ可読媒体上でエンコードされるロジックと、を備え、
前記ロジックは、実行時に、
第１のデータベースからの情報の少なくとも一部を含むバックアップ情報を受け取るステップと、
バックアップ情報をバックアップ・システム内に格納するステップと、
第１のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を第２のデータベースから受け取るステップと、
増分変更をバックアップ・システム内に格納するステップと、
増分変更およびバックアップ情報を、第１のデータベースの復元にて用いるために伝達するステップと、を行なうように動作可能であるシステム。
【請求項５２】
前記ロジックがさらに、
増分変更を、第２のデータベース内に格納するために受け取るステップと、
増分変更を第２のデータベース内に格納するステップと、
増分変更を第２のデータベースから、バックアップ・システム内に格納するために伝達するステップと、を行なうように動作可能である請求項５１に記載のシステム。
【請求項５３】
ディザスタ・リカバリのためのシステムであって、
バックアップ情報を格納するように動作可能なバックアップ・システムと、
１つまたは複数のプロセッサとを備え、
前記１つまたは複数のプロセッサは、
第１のデータベースからの情報の少なくとも一部を含むバックアップ情報を受け取るステップと、
バックアップ情報をバックアップ・システム内に格納するステップと、
第１のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を第２のデータベースから受け取るステップと、
増分変更をバックアップ・システム内に格納するステップと、
増分変更およびバックアップ情報を、第１のデータベースの復元にて用いるために伝達するステップと、を行なうように共同して動作可能であるシステム。
【請求項５４】
第２のデータベースをさらに備え、
前記１つまたは複数のプロセッサがさらに、
増分変更を、第２のデータベース内に格納するために受け取るステップと、
増分変更を第２のデータベース内に格納するステップと、
増分変更を第２のデータベースから、バックアップ・システム内に格納するために伝達するステップと、を行なうように共同して動作可能である請求項５３に記載のシステム。
【請求項５５】
ディザスタ・リカバリのためのシステムであって、
第１のデータベースからの情報の少なくとも一部を含むバックアップ情報を受け取る手段と、
増分変更を第２のデータベースから受け取る手段であって、増分変更は、第１のデータベース内の少なくとも一部の情報に対する変更を表わす、手段と、
バックアップ情報および増分変更を格納する手段と、
増分変更およびバックアップ情報を、第１のデータベースの復元にて用いるために伝達する手段と、を備えるシステム。
【請求項５６】
ディザスタ・リカバリのための方法であって、
第１のデータベースからの情報の少なくとも一部を、バックアップ・システムに、バックアップ情報としてコピーするステップと、
増分変更を第２のデータベース内に格納するステップであって、増分変更は、第１のデータベース内の少なくとも一部の情報に対する変更を表わす、ステップと、
第１のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元するステップと、を含む方法。
【請求項５７】
増分変更が第１の増分変更を含み、
前記方法がさらに、第２の増分変更を第２のデータベースからバックアップ・システムへコピーするステップを含み、
第１のデータベースを復元するステップは、第１のデータベースを少なくとも１つのバックアップ情報を用いて復元するステップを含み、第１の増分変更は第２のデータベース内に格納され、第２の増分変更はバックアップ・システム内に格納される請求項５６に記載の方法。
【請求項５８】
前記方法が、復元時間を受け取るステップをさらに含み、
第１のデータベースを復元するステップが、
バックアップ情報を第１のデータベース内に格納するステップと、
バックアップ・システム内に格納される第２の増分変更に付随する第１の時間が、復元時間を超えているかどうかを判定するステップと、
第１の時間が復元時間を超えていないときに、第２の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップと、
第２のデータベース内に格納される第１の増分変更に付随する第２の時間が、復元時間を超えているかどうかを判定するステップと、
第２の時間が復元時間を超えていないときに、第１の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップと、を含む請求項５７に記載の方法。
【請求項５９】
第２のデータベースおよびバックアップ・システムが単一のプラットフォーム上に存在する請求項５６に記載の方法。
【請求項６０】
ディザスタ・リカバリのためのシステムであって、
少なくとも１つのコンピュータ可読媒体と、
少なくとも１つのコンピュータ可読媒体上でエンコードされるロジックと、を備え、
前記ロジックは、実行時に、
第１のデータベースからの情報の少なくとも一部を、バックアップ・システムに、バックアップ情報としてコピーするステップと、
第１のデータベース内の少なくとも一部の情報に対する変更を表わす増分変更を第２のデータベース内に格納するステップと、
第１のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元するステップと、を含むシステム。
【請求項６１】
増分変更が第１の増分変更を含み、
前記ロジックがさらに、第２の増分変更を第２のデータベースからバックアップ・システムへコピーするように動作可能であり、
前記ロジックが、第１のデータベースを少なくとも１つのバックアップ情報を用いて復元するように動作可能であり、第１の増分変更は第２のデータベース内に格納され、第２の増分変更はバックアップ・システム内に格納される請求項６０に記載の方法。
【請求項６２】
前記ロジックがさらに、復元時間を受け取るように動作可能であり、
前記ロジックは、
バックアップ情報を第１のデータベース内に格納するステップと、
バックアップ・システム内に格納される第２の増分変更に付随する第１の時間が、復元時間を超えているかどうかを判定するステップと、
第１の時間が復元時間を超えていないときに、第２の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップと、
第２のデータベース内に格納される第１の増分変更に付随する第２の時間が、復元時間を超えているかどうかを判定するステップと、
第２の時間が復元時間を超えていないときに、第１の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップとによって、第１のデータベースを復元するように動作可能である請求項６１に記載の方法。
【請求項６３】
第２のデータベースおよびバックアップ・システムが単一のプラットフォーム上に存在する請求項６０に記載の方法。
【請求項６４】
ディザスタ・リカバリのためのシステムであって、
情報を格納するように動作可能な第１のデータベースと、
バックアップ情報を格納するように動作可能なバックアップ・システムであって、バックアップ情報は、第１のデータベースからの情報の少なくとも一部を含む、バックアップ・システムと、
増分変更を格納するように動作可能な第２のデータベースであって、増分変更は、第１のデータベース内の少なくとも一部の情報に対する変更を表わす、データベースと、
１つまたは複数のプロセッサであって、バックアップ情報および増分変更の少なくとも一方を用いて第１のデータベースを復元するように共同して動作可能である、１つまたは複数のプロセッサと、を備えるシステム。
【請求項６５】
増分変更が第１の増分変更を含み、
前記１つまたは複数のプロセッサがさらに、第２の増分変更を第２のデータベースからバックアップ・システムへコピーするように共同して動作可能であり、
前記１つまたは複数のプロセッサが、第１のデータベースを少なくとも１つのバックアップ情報を用いて復元するように共同して動作可能であり、第１の増分変更は第２のデータベース内に格納され、第２の増分変更はバックアップ・システム内に格納される請求項６４に記載のシステム。
【請求項６６】
前記１つまたは複数のプロセッサがさらに、復元時間を受け取るように共同して動作可能であり、
前記１つまたは複数のプロセッサは、
バックアップ情報を第１のデータベース内に格納するステップと、
バックアップ・システム内に格納される第２の増分変更に付随する第１の時間が、復元時間を超えているかどうかを判定するステップと、
第１の時間が復元時間を超えていないときに、第２の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップと、
第２のデータベース内に格納される第１の増分変更に付随する第２の時間が、復元時間を超えているかどうかを判定するステップと、
第２の時間が復元時間を超えていないときに、第１の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップとによって、第１のデータベースを復元するように共同して動作可能である請求項６５に記載のシステム。
【請求項６７】
第２のデータベースおよびバックアップ・システムが単一のプラットフォーム上に存在する請求項６４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は一般に、コンピューティング・システムの分野に関し、より詳細には、ディザスタ・リカバリ（障害回復）のための方法およびシステムに関する。
【背景技術】
【０００２】
ディザスタ・リカバリ・システムは通常、コンピュータ・ファイルをバックアップしてデータの損失から保護する。典型的なディザスタ・リカバリ・システムでは、ファイルを定期的に、テープまたは他のバックアップ・システムにコピーする。これは通常、設定された時間間隔の間に、たとえば夜のオフ・タイムの間または週末に行なわれる。コンピュータ・システムが故障したときには、ディザスタ・リカバリ・システムは、最新のバックアップを用いてコンピュータ・システムを復元することができる。これには通常、ファイルをバックアップ・システムからコピーして、コンピュータ・システムへ戻すことが伴う。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のディザスタ・リカバリ・システムにおける問題は、コンピュータ・システムを復元できる状態が、最後のバックアップの時間のときに存在していた状態だけであるということである。通常は、最後のバックアップの後に行なわれたファイルの変更はどれも失われる。
【課題を解決するための手段】
【０００４】
概要
本開示では、これまでのシステムおよび方法に付随する問題および不利点を実質的に低減または解消する、ディザスタ・リカバリのための改善された方法およびシステムを提供する。詳細には、データベースの完全バックアップを行なうことに加えて、データベースに対する増分変更を記録し、これを増分バックアップとしてアーカイブすることができる。そしてデータベースを復元することを、完全バックアップ、１つまたは複数の増分バックアップ、および／または現在のアンアーカイブされた増分変更を用いて、行なうことができる。
【０００５】
１つの実施形態においては、ディザスタ・リカバリのための方法には、少なくとも一部の情報を、第１のデータベースからバックアップ・システムへバックアップ情報としてコピーするステップが含まれる。また本方法には、第２のデータベース内に増分変更を格納するステップが含まれる。増分変更は、第１のデータベース内の少なくとも一部の情報に対する変更を表わしている。本方法にはさらに、第１のデータベースを、バックアップ情報および増分変更の少なくとも一方を用いて復元するステップが含まれる。
【０００６】
特定の実施形態においては、本方法にはさらに、第２の増分変更を、第２のデータベースからバックアップ・システムへコピーするステップが含まれる。この実施形態においては、第１のデータベースを復元するステップには、バックアップ情報、第２のデータベースに格納される増分変更、およびバックアップ・システムに格納される第２の増分変更のうちの少なくとも１つを用いるステップが含まれる。
【発明を実施するための最良の形態】
【０００７】
図１は、本開示の一実施形態によるディザスタ・リカバリ・システム１００を例示する典型的なブロック・ダイアグラムである。例示した実施形態においては、システム１００には、１次サーバ１０２、２次サーバ１０４、ネットワーク１０６、および１つまたは複数のクライアント１０８が含まれている。本開示の範囲から逸脱することなく、システム１００の他の実施形態を用いても良い。
【０００８】
動作の一態様においては、１次データベース１１０には、１次サーバ１０２によって用いられる情報が格納される。データベース１１０には、たとえば、オン・ライン・ウェブ・サービスをクライアント１０８に提供するために１次サーバ１０２によって用いられる情報が格納される。またデータベース１１０には、レジストリ情報、たとえばオペレーティング・システムによって用いられる構成情報が格納されても良い。データベース１１０内の情報は、時間とともに変化する場合がある。たとえばクライアント１０８によって、情報が付加され、変更され、または削除される場合である。また１次サーバ１０２内のデータベース１１０は、故障するかまたは動作不能になる場合もある。たとえばハードウェアまたはパワーの故障が起こる場合である。
【０００９】
１次データベース１１０が再び動作可能になった後に、データベース１１０内の情報を復元することが必要となる場合がある。特定の例としては、データベース１１０が、故障した後に情報を失う場合があり、そしてその情報をデータベース１１０へ、データベース１１０がサービスを再入力し得る前に、コピーする必要があることが考えられる。１つの実施形態においては、１次データベース１１０内に格納される情報の少なくとも一部を定期的に、バックアップ・システム１１２内へコピーまたはアーカイブしても良い。データベース１１０内の情報に変更を加えたときに、変更を２次データベース１１４内に格納しても良い。２次データベース１１４内での変更を、バックアップ・システム１１２内に定期的にアーカイブしても良いし、しなくても良い。そして１次データベース１１０を、バックアップ・システム１１２および／または２次データベース１１４内の情報を用いて、復元しても良い。
【００１０】
１次サーバ１０２はネットワーク１０６に結合されている。この文書では、用語「結合する」は、２つ以上のコンポーネント間の任意の直接または間接的な通信を指し、これらのコンポーネントが互いに物理接触しているかどうかによらない。また用語「通信」は、物理的に離れたコンポーネント間、または単一の物理ユニット内のコンポーネント間の通信を指しても良い。１次サーバ１０２は、システム１００内の種々の機能の１つまたは複数を行なうように動作可能である。１次サーバ１０２は、たとえば、オン・ライン・ウェブ・サービスをクライアント１０８にネットワーク１０６を介して提供するように動作可能なウェブ・サーバを表わすことができる。また１次サーバ１０２は、組織の従業員によって用いられる情報を格納するように動作可能なデータベース・サーバを表わすこともできる。１次サーバ１０２は、本開示の範囲から逸脱することなく、システム１００内の他の任意のおよび／またはさらなる機能を行なうことができる。１次サーバ１０２は、システム１００内の少なくとも１つの機能を実行するように動作可能な任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを含んでいても良い。例示した実施形態においては、１次サーバ１０２には、クライアント１０８によって使用される情報を格納するように動作可能なデータベース１１０が含まれている。本開示の範囲から逸脱することなく、１次サーバ１０２の他の実施形態を用いても良い。
【００１１】
２次サーバ１０４はネットワーク１０６に結合されている。２次サーバ１０４には、ディザスタ・リカバリ動作を行なうためにシステム１００によって用いられる情報が格納されても良い。たとえば２次サーバ１０４には、１次サーバ１０２内のデータベース１１０を復元するために用いられる情報が格納されても良い。この文書では、用語「復元する」は、データベース内に格納される情報を以前の状態に戻すことを指す。以前の状態は、たとえば、データベース１１０の故障の時間にまたはその付近に存在していても良い。また以前の状態は、データベース１１０の故障の前の時間に存在していても良い。１つの実施形態においては、２次サーバ１０４には、１次サーバ１０２のデータベース１１０内の情報の完全バックアップが格納されても良い。また２次サーバ１０４には、データベース１１０内の情報に加えられた変更が格納されても良い。データベース１１０が故障して再び動作可能になった後で、２次サーバ１０４が、バックアップ情報および増分変更を１次サーバ１０２に伝達して、１次サーバ１０２がこの情報を用いてデータベース１１０を復元しても良い。２次サーバ１０４には、少なくとも１つの１次データベース１１０を復元するために用いられる情報を格納しおよび情報の検索を容易にするように動作可能な任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが含まれていても良い。例示した実施形態においては、２次サーバ１０４には、バックアップ・システム１１２および２次データベース１１４が含まれている。本開示の範囲から逸脱することなく、２次サーバ１０４の他の実施形態を用いても良い。
【００１２】
ネットワーク１０６は、１次サーバ１０２、２次サーバ１０４、およびクライアント１０８に結合されている。ネットワーク１０６によって、システム１００のコンポーネント間の通信が容易になる。ネットワーク１０６は、たとえば、インターネット・プロトコル（ＩＰ）パケット、フレーム・リレー・フレーム、非同期転送モード（ＡＴＭ）セル、および／または任意の好適なフォーマットの任意の好適な他の情報を、ネットワーク・アドレス間で通信する。ネットワーク１０６には、１つまたは複数のローカル・エリア・ネットワーク（ＬＡＮ）、メトリポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネットとして知られるグローバル・コンピュータ・ネットワークの全部または一部、および／または１つまたは複数の位置にある他の任意の通信システムが含まれていても良い。
【００１３】
クライアント１０８はネットワーク１０６に結合されている。クライアント１０８は、ユーザが、１次サーバ１０２のデータベース１１０に含まれる情報にアクセスしおよび／またはこれを変えられるように動作可能である。たとえば、クライアント１０８は、データベース照会を、１次サーバ１０２に対してネットワーク１０６を介して送信しても良い。これはたとえば、指定された情報をデータベース１１０から検索するためのリクエストである。またクライアント１０８は、１次サーバ１０２に命令を送信して、１次サーバ１０２がデータベース１１０内に含まれる情報を付加、変更、または削除するように、指示することもできる。クライアント１０８には、ネットワーク１０６を介して通信しおよび／または情報を受け取るように動作可能な任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが含まれていても良い。クライアント１０８には、たとえば、ウェブ・ブラウザを実行するデスクトップ・コンピュータが含まれていても良い。
【００１４】
１次データベース１１０は、システム１００内の１つまたは複数の機能を実行するように１次サーバ１０２によって用いられる情報を格納するように、動作可能である。この文書では、用語「データベース」は、情報の収集物を指しても良い。情報は、文書または他のファイル内に、レジストリ内に、ファイルおよび／またはレジストリの収集物内に、および／または任意の好適な他の構造内に存在しても良い。１つの実施形態においては、データベース１１０には、ウェブ・サービスをクライアント１０８にネットワーク１０６を介して提供するために１次サーバ１０２によって用いられる情報が、格納されても良い。特定の例として、データベース１１０には、１次サーバ１０２を用いるビジネスの顧客の名前、アドレス、および製品注文が格納されても良い。本開示の範囲から逸脱することなく、データベース１１０には、他の任意のおよび／またはさらなる情報が格納されても良い。データベース１１０には、情報を格納しおよび情報の検索を容易にするように動作可能な任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが含まれていても良い。データベース１１０への情報の格納には、種々のデータ構造、配置、および／またはコンパイルのどれを用いても良い。データベース１１０には、たとえば、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、または任意の好適な他の揮発性または不揮発性の記憶および検索デバイスが含まれていても良い。図１では、１次データベース１１０が１次サーバ１０２内に存在する様子を例示しているが、１次データベース１１０は、１次サーバ１０２によってアクセス可能であればどんな位置にあっても良い。
【００１５】
バックアップ・システム１１２は、１次データベース１１０および／または２次データベース１１４から情報を格納またはアーカイブするように動作可能である。たとえば、バックアップ・システム１１２は、１次データベース１１０内の情報の全部または一部を受け取って、この情報を格納しても良い。特定の例としては、バックアップ・システム１１２は、情報を１次データベース１１０から、データベース１１０の完全バックアップ１１６の間に受け取っても良い。データベース１１０が故障して再び動作可能になったときに、バックアップ・システム１１２はバックアップ情報を１次サーバ１０２に伝達しても良く、また１次サーバ１０２はこのバックアップ情報を用いてデータベース１１０を復元しても良い。加えて、１つの実施形態においては、バックアップ・システム１１２は、２次データベース１１４内に格納される情報の少なくとも一部を格納またはアーカイブしても良い。情報を２次データベース１１４からバックアップ・システム１１２へアーカイブすることを、増分バックアップ１２０と言っても良い。バックアップ・システム１１２には、情報を格納しおよび／または情報の検索を容易にするように動作可能な任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが、含まれていても良い。例示した実施形態においては、バックアップ・システム１１２には、テープ・バックアップ・システムが含まれている。本開示の範囲から逸脱することなく、バックアップ・システム１１２の他の実施形態を用いても良い。
【００１６】
２次データベース１１４は、データベース１１０内の情報に加えられた変更を特定する情報を格納するように動作可能である。１つの実施形態においては、２次データベース１１４には、１つまたは複数の増分変更１１８が格納される。増分変更１１８は、１次データベース１１０内の情報が、最後の完全バックアップ１１６の後で変更される仕方を記述するものであっても良い。１つの実施形態においては、増分変更１１８は、データベース操作、たとえば１次データベース１１０にデータを書き込み、１次データベース１１０からデータを削除し、または１次データベース１１０内のデータを変更する操作に対応する。特定の実施形態においては、増分変更１１８は、１次データベース１１０の変更されたセグメントを特定するものであっても良い。特定の例として、情報が１次データベース１１０内のテーブルに加えられた場合に、増分変更１１８は、そのテーブル、テーブルに加えられた情報、およびテーブル内のどこに情報が加えられたかを特定するものであっても良い。情報が１次データベース１１０内のテーブルから削除された場合に、増分変更１１８は、そのテーブルおよびどの情報がテーブルから削除されたかを特定するものであっても良い。情報が１次データベース１１０内のテーブル内で変更された場合に、増分変更１１８は、そのテーブルおよびそのテーブル内に含まれる変更された新しい情報を特定するものであっても良い。本開示の範囲から逸脱することなく、他の情報が、増分変更１１８内に含まれていても良く、および／または２次データベース１１４内に格納されても良い。この明細書では、増分変更１１８を、１次データベース１１０内のファイルに対する変更を表わしていると説明することもあるが、増分変更１１８は、１次データベース１１０内のどの情報に対する変更を表わしても良い。特定の例としては、増分変更１１８は、１次データベース１１０内のレジストリに加えられた変更を表わすことができる。２次データベース１１４には、情報を格納しおよび情報の検索を容易にするように動作可能な任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが含まれていても良い。２次データベース１１４への情報の格納は、種々のデータ構造、配置、および／またはコンパイルのどれを用いても良い。図１では、２次データベース１１４が２次サーバ１０４内に存在する様子を例示しているが、２次データベース１１４は、２次サーバ１０４によってアクセス可能であればどんな位置にあっても良い。
【００１７】
動作の一態様においては、１次サーバ１０２内の１次データベース１１０が故障したときに、システム１００は２次サーバ１０４を用いて、ディザスタ・リカバリを行なう。特定の実施形態においては、ディザスタ・リカバリ動作には２つの一般的なフェーズ、バックアップ・フェーズおよびリカバリ・フェーズが含まれる。バックアップ・フェーズには、少なくとも一部の情報を１次データベース１１０から、２次サーバ１０４へ、バックアップ・システム１１２および／または２次データベース１１４へ、コピーすることが含まれていても良い。リカバリ・フェーズには、少なくとも一部の情報をバックアップ・システム１１２および／または２次データベース１１４からコピーして、１次データベース１１０へ戻すことで、１次データベース１１０を以前の状態へ復元することが含まれていても良い。
【００１８】
１つの実施形態においては、ディザスタ・リカバリ動作のバックアップ・フェーズには、完全バックアップ１１６と２次サーバ１０４内への増分変更１１８の格納とを実行することが含まれる。完全バックアップ１１６では、少なくとも一部の情報を、１次データベース１１０から２次サーバ１０４内のバックアップ・システム１１２にコピーする。特定の実施形態においては、完全バックアップ１１６には、すべての情報を１次データベース１１０からバックアップ・システム１１２へコピーすることが含まれる。他の特定の実施形態においては、完全バックアップ１１６には、１次データベース１１０内の情報のサブセットをバックアップ・システム１１２へコピーすることが含まれる。完全バックアップ１１６に含まれる情報を、ユーザが指定しても良い。これはたとえば、ユーザが、クライアント１０８を用いて、または１次サーバ１０２もしくは２次サーバ１０４に対するインターフェースを用いて、または任意の好適な他の方法で、行なう。
【００１９】
この実施形態においては、完全バックアップ１１６に加えて、１次データベース１１０内の情報に加えられた変更を、増分変更１１８として２次データベース１１４内に記録しても良い。１つの実施形態においては、増分変更１１８を２次データベース１１４内に、次の完全バックアップ１１６が始まるまで格納する。次の完全バックアップ１１６が始まった後に、２次データベース１１４を再初期化しても良い。これはたとえば、２次データベース１１４内に格納される何れかの増分変更１１８を削除することによって行なう。特定の実施形態においては、２次データベース１１４内に格納される増分変更１１８を、時間に基づいて分割しても良い。たとえば、増分変更１１８を、増分変更１１８がいつ生じたのかに基づいて、異なるファイルまたはデータ・ストアに格納しても良いし、それぞれのファイルまたはデータ・ストアが、異なる時間間隔に対応していても良い。この文書では、用語「それぞれの」は、特定された項目の少なくともサブセットのそれぞれを指す。
【００２０】
この実施形態においては、バックアップ・システム１１２内に格納されるバックアップ情報および２次データベース１１４内に格納される増分変更１１８を用いて、データベース故障の場合に１次データベース１１０を復元しても良い。言い換えれば、１次データベース１１０の以前の状態が、バックアップ・システム１１２内に格納されるバックアップ情報および２次データベース１１４内に格納される増分変更１１８を用いて再現される。詳細には、１次サーバ１０２は、バックアップ情報をバックアップ・システム１１２から１次データベース１１０へコピーすることができ、その結果、１次データベース１１０は、最後の完全バックアップ１１６の時間にまたはその付近に存在していた状態まで復元される。１次サーバ１０２は、１次データベース１１０をこの状態に保つことができる。また１次サーバ１０２は、増分変更１１８の一部または全部を２次データベース１１４から受け取って、これらの増分変更１１８を１次データベース１１０内に再現することができる。たとえば、１次サーバ１０２は、データベース・テーブルからの情報の削除を表わす増分変更１１８を受け取ることができ、そして１次サーバ１０２は、特定された情報をデータベース・テーブルから削除することによって、１次データベース１１０内の変更を行なうことができる。このようにして、１次サーバ１０２は、２次データベース１１４内に格納される増分変更１１８を用いて、１次データベース１１０を、最後の完全バックアップ１１６の時間とデータベース故障の時間との間に存在していた状態まで復元することができる。特定の実施形態においては、１次サーバ１０２は、増分変更１１８を順次再現して、最後の完全バックアップ１１６の時間から始めてデータベース故障の時間に達するまでまたは所望の時間に達するまで続ける。１次データベース１１０を復元するのは、データベース故障の時間までとするべきなのか、または他の時間までとするべきなのかを、ユーザが指定できるようにしても良い。
【００２１】
他の実施形態においては、２次サーバ１０４は、１つまたは複数の増分バックアップ１２０を、ディザスタ・リカバリ動作のバックアップ・フェーズの間に行なっても良い。この実施形態においては、２次データベース１１４内に格納される増分変更１１８を、バックアップ・システム１１２内にコピーまたはアーカイブしても良いが、アーカイブされた増分変更１１８を、２次データベース１１４から削除する必要がなくても良い。特定の例としては、２次サーバ１０４は、バックアップ・システム１１２内の増分変更１１８を、１５または３０分ごとにアーカイブすることができるが、任意の好適な他の時間間隔を用いても良い。このように２次データベース１１４は、増分変更１１８を、限られた時間間隔の間だけ格納しても良い。特定の実施形態においては、２次サーバ１０４内の増分変更１１８を、増分変更１１８がいつ生じたのかに応じて、異なるファイルまたはデータ・ストアに格納しても良い。そして増分バックアップ１２０は、ファイルまたはデータ・ストアの１つまたは複数を、バックアップ・システム１２０へコピーする。
【００２２】
この実施形態においては、バックアップ・システム１１２内に格納される完全バックアップ情報、バックアップ・システム１１２内に増分バックアップ１２０として格納される増分変更１１８、および２次データベース１１４内に格納される増分変更１１８を用いて、１次データベース１１０を復元しても良い。この実施形態においては、１次サーバ１０２は、バックアップ情報をバックアップ・システム１１２から１次データベース１１０にコピーして、その結果、１次データベース１１０を、最後の完全バックアップ１１６の時間にまたはその付近に存在していた状態まで復元することができる。１次サーバ１０２は、１次データベース１１０をこの状態に保つことができる。また１次サーバ１０２は、増分バックアップ１２０の一部または全部をバックアップ・システム１１２から受け取って、これらの増分バックアップ１２０内に含まれる増分変更１１８を再現することができる。この結果、１次データベース１１０は、最後の増分バックアップ１２０を受け取って実行した時間にまたはその付近に存在していた状態まで復元される。この場合もやはり、１次サーバ１０２は１次データベース１１０をこの状態に保つことができ、または１次サーバ１０２は、２次データベース１１４内に格納される増分変更１１８を受け取って実行することができる。特定の実施形態においては、１次サーバ１０２は、バックアップ・システム１１２および２次データベース１１４の両方の増分変更１１８を順次再現する。またユーザに、１次データベース１１０の復元先の時間を指定するオプションを与えても良い。
【００２３】
これまでの説明では、情報が２次サーバ１０４内に、ディザスタ・リカバリ動作のバックアップ・フェーズの間に格納され得る種々の仕方が説明されている。また１次データベース１１０が、ディザスタ・リカバリ動作のリカバリ・フェーズの間に２次サーバ１０４内の情報を用いて復元され得る種々の仕方も説明されている。他の任意のおよび／またはさらなる方法および技術を用いて、情報を２次サーバ１０４内にバックアップ・フェーズの間に格納すること、および／または１次データベース１１０をリカバリ・フェーズの間に復元することを、本開示の範囲から逸脱することなく行なっても良い。たとえば、システム１００をプログラミングして、１次データベース１１０が、データベース１１０の故障の時間にまたはその付近に存在していた状態まで常に復元するようにすることができる。この実施形態においては、ユーザには、１次データベース１１０を、データベース１１０の故障の前に存在していた状態まで復元するオプションを与えなくても良い。
【００２４】
図１では、ディザスタ・リカバリ・システム１００の一例の実施形態を例示しているが、種々の変更をシステム１００に対して、本開示の範囲から逸脱することなく行なっても良い。たとえば、図１では１つの１次サーバ１０２および１つの２次サーバ１０４を例示しているが、システム１００は、好適であればどんな数の１次サーバ１０２および／または２次サーバ１０４を含んでいても良い。特定の例としては、システム１００には複数の１次サーバ１０２、たとえば１〜８つの１次サーバ１０２を、それぞれの２次サーバ１０４に対して含めることができる。また図１では、２次サーバ１０４をバックアップ・システム１１２および２次データベース１１４を含むとして例示しているが、バックアップ・システム１１２およびデータベース１１４は、別個のプラットフォーム上に存在することができる。加えて図１では、サーバ１０２および１０４を用いることが例示されているが、任意の好適な他のコンピューティングまたは通信デバイスをシステム１００内で用いても良い。
【００２５】
図２Ａおよび２Ｂは、本開示の一実施形態による１次および２次データベース１１０および１１４を例示する典型的なブロック・ダイアグラムである。詳細には、図２Ａでは、一例としての２つの１次データベース１１０が２つの１次サーバ１０２内にある場合を例示し、図２Ｂでは、一例としての２次データベース１１４が２次サーバ１０４内にある場合を例示している。図２Ａおよび２Ｂに図示したデータベース・コンテンツは、説明するためだけのものである。データベース１１０および１１４は、本開示の範囲から逸脱することなく、他の任意のおよび／またはさらなる情報を好適な任意の配置で、含んでいても良い。
【００２６】
図２Ａでは、２つの１次データベース１１０ａおよび１１０ｂのコンテンツは、標準的なフォルダ・システムを用いてサブ分割されている。フォルダ・システム内では、コンテンツがフォルダの階層に分割されていても良い。それぞれのフォルダは、情報、アプリケーション、さらなるフォルダ、ファイル、レジストリ、無コンテンツ、および／または他の任意のコンテンツを含んでいても良い。この明細書では、増分変更１１８がフォルダ２００および２０２内のファイルに加えられると説明する場合もあるが、増分変更１１８は、本開示の範囲から逸脱することなく、フォルダ２００および２０２の他の任意のコンテンツに作用しても良い。
【００２７】
例示した実施形態においては、データベース１１０ａのコンテンツは、２つのドライブ・フォルダ２００ａおよび２００ｂに分割され、一方でデータベース１１０ｂのコンテンツは、単一のドライブ・フォルダ２００ｃ内に存在する。１つの実施形態においては、データベース１１０には、複数の物理ドライブおよび／または論理ドライブが含まれていても良い。例示した実施形態においては、データベース１１０は、ドライブ・フォルダ２００ａおよび２００ｂによって表わされる２つの物理および／または論理ドライブを有し、データベース１１０ｂは、ドライブ・フォルダ２００ｃによって表わされる１つの物理および／または論理ドライブを有する。
【００２８】
それぞれのドライブ・フォルダ２００内では、データベース１１０のコンテンツがさらに、ファイル・システム・フォルダ２０２にサブ分割されていても良い。ファイル・システム・フォルダ２０２は、たとえば、情報データベース１１０内の異なるカテゴリの情報を表わすことができる。例示した実施形態においては、ドライブ・フォルダ２００ａは、３つのファイル・システム・フォルダ２０２ａ〜２０２ｃに分割されている。フォルダ２０２ａには、１次サーバ１１０ａによって実行可能なアプリケーションが含まれていても良い。フォルダ２０２ｂには、ユーザが交換サーバ・アプリケーションを用いて情報を通信および共有できるように指示および情報が含まれていても良い。フォルダ２０２ｃには、一時的に格納されるべき情報が含まれていても良い。ファイル・システム・フォルダ２０２のコンテンツは、１次サーバ１０２によって実行されるアプリケーションが使用する特定のファイル、さらなるフォルダ、データベース・テーブル、および／または任意の他の情報を含むことができる。フォルダ２００〜２０２は、本開示の範囲から逸脱することなく、フォルダのさらなる層を用いてさらにサブ分割されていても良い。
【００２９】
ディザスタ・リカバリ動作の一態様においては、１次データベース１１０内の少なくとも一部の情報を、バックアップ・システム１１２に完全バックアップ１１６の間にコピーしても良く、またその情報の増分変更１１８をモニタしても良い。１つの実施形態においては、１次データベース１１０内のすべての情報を、バックアップ・システム１１２にコピーし、またその情報の増分変更１１８をモニタする。他の実施形態においては、１次データベース１１０内の情報のサブセットを、バックアップ・システム１１２にコピーし、またその増分変更１１８をモニタする。特定の実施形態においては、ユーザは、１次データベース１１０内のどのフォルダ２００〜２０２および／またはファイルを、バックアップ・システム１１２にコピーし、および／またはその増分変更１１８をモニタすべきかを指定しても良い。これはたとえば、１次データベース１１０内の情報の一部が、時間とともに変更しない場合に有用であり得る。
【００３０】
ディザスタ・リカバリ動作の他の態様においては、１次データベース１１０内の情報に対する増分変更１１８を、２次サーバ１０４の２次データベース１１４内に格納しても良い。たとえば、情報を、１次データベース１１０ａおよび１１０ｂ内で、付加し、変更し、または削除しても良く、これらの変更を２次データベース１１４内に記録しても良い。
【００３１】
図２Ｂに、２次データベース１１４の一例を例示する。例示した実施形態においては、２次データベース１１４は、標準的なフォルダ・システムを用いて増分変更１１８を格納する。例示した実施形態においては、２次データベース１１４には、アプリケーション・フォルダ２５０、増分変更フォルダ２５２、１つまたは複数のサーバ・フォルダ２５４、１つまたは複数のタイムスタンプ・フォルダ２５６、１つまたは複数のドライブ・フォルダ２５８、および１つまたは複数のファイル・システム・フォルダ２６０が含まれている。この実施形態においては、２次サーバ１０４は、増分変更１１８を、ファイル・ドライブ・フォルダ２５８および／またはファイル・システム・フォルダ２６０内に位置するファイル内に格納しても良い。本開示の範囲から逸脱することなく、他の実施形態および／または配置を用いても良い。
【００３２】
アプリケーション・フォルダ２５０が示すフォルダ内において、ディザスタ・リカバリ・アプリケーションに関連する情報が２次データベース１１４内に格納されても良い。特定の例としては、アプリケーション・フォルダ２５０には、１つまたは複数の１次データベース１１０に加えられる増分変更１１８、１次データベース１１０を復元するために用いられるアプリケーション・ファイル、および／または好適であれば他のどんな情報が含まれていても良い。
【００３３】
増分変更フォルダ２５２は、１つまたは複数の１次データベース１１０に加えられる増分変更１１８が格納されても良い。増分変更フォルダ２５２は、たとえば、増分変更１１８を、アプリケーション・フォルダ２５０内に格納される他の情報から離しておくことができても良い。
【００３４】
それぞれのサーバ・フォルダ２５４には、特定の１次サーバ１０２によって加えられる増分変更１１８が格納されても良い。例示した実施形態においては、２次データベース１１４には、２つのサーバ・フォルダ２５４ａおよび２５４ｂが、すなわち一方は、１次データベース１１０ａを有する第１の１次サーバ１０２用であり、もう一方は、１次データベース１１０ｂを有する第２の１次サーバ１０２用である、が含まれていても良い。こうすることによって、たとえば、単一の２次データベース１１４が、複数の１次サーバ１０２に対する増分変更１１８を、分離して格納することができても良い。好適な任意の数の１次サーバ１０２に対して、２次データベース１１４が対応していても良い。１つの実施形態においては、２次データベース１１４は、１〜８つの１次サーバ１０２に対応していても良い。
【００３５】
タイムスタンプ・フォルダ２５６は、増分変更１１８を加えることができる異なる時間間隔を表わしている。例示した実施形態においては、それぞれのサーバ・フォルダ２５４には、少なくとも２つのタイムスタンプ・フォルダ２５６が含まれている。「現在」とラベル付けされた１つのタイムスタンプ・フォルダ２５６には、現在の時間間隔からの増分変更１１８が格納されており、少なくとも１つの他のタイムスタンプ・フォルダ２５６には、以前の時間間隔からの増分変更１１８が格納されている。本開示の範囲から逸脱することなく、任意の数のタイムスタンプ・フォルダ２５６を用いる他の実施形態を用いても良い。たとえば、２次データベース１１４は、最後の完全バックアップ１１６から経過したそれぞれの時間間隔に対してタイムスタンプ・フォルダ２５６を含むことができる。
【００３６】
例示した実施形態においては、現在の時間間隔以外の時間間隔を表わすタイムスタンプ・フォルダ２５６に、タイムスタンプ・ラベルが含まれている。この文書では、用語「タイムスタンプ」は、日付および／または時間を少なくとも部分的に特定しまたは表わすように動作可能である任意の情報または構造を指す。特定の実施形態においては、これらのタイムスタンプ・フォルダ２５６のそれぞれに、そのタイムスタンプ・フォルダ２５６内に２次サーバ１０４が増分変更１１８を格納することをいつ開始または停止するかを特定するタイムスタンプが、含まれていても良い。たとえば１つの実施形態においては、タイムスタンプ・フォルダ２５６には、一日の異なる時刻に起こった増分変更１１８が格納されていても良く、それぞれのタイムスタンプは、一日の特定の時刻を特定しても良い。本開示の範囲から逸脱することなく、日付および／または時間に関連してまたは関連せずに、他のラベルをタイムスタンプ・フォルダ２５６に与えても良い。
【００３７】
２次データベース１１４内のそれぞれのドライブ・フォルダ２５８が、１次データベース１１０内のドライブ・フォルダ２００に対応していても良い。２次データベース１１４内のそれぞれのファイル・システム・フォルダ２６０が、１次データベース１１０内のファイル・システム・フォルダ２０２に対応していても良い。
【００３８】
動作の一態様においては、増分変更１１８を、ドライブ・フォルダ２５８、ファイル・システム・フォルダ２６０、および／または２次データベース１１４内の他のフォルダ内に位置するファイル内に格納する。特定の実施形態においては、２次データベース１１４内のファイルは、スパース・ファイルである。以下の説明では、タイムスタンプ・フォルダ２５６内に位置するファイルの収集物をデータ・ストアと言う。
【００３９】
変更が１次データベース１１０内の情報に加えられたときに、変更を２次サーバ１０４に増分変更１１８として伝達しても良い。２次サーバ１０４は、増分変更１１８に関連する１次サーバ１０２を特定しても良い。また２次サーバ１０４は、その１次サーバ１０２内のどこに増分変更１１８が加えられたかを特定しても良い。たとえば増分変更１１８が、１次データベース１１０のドライブ・フォルダ２００内のファイルに作用した場合に、２次サーバ１０４は、そのドライブ・フォルダ２００を特定しても良い。増分変更１１８が、１次データベース１１０のファイル・システム・フォルダ２０２内のファイルに作用した場合に、２次サーバ１０４は、そのファイル・システム・フォルダ２０２、およびそのファイル・システム・フォルダ２０２に関連するドライブ・フォルダ２００を特定しても良い。２次サーバ１０４はさらに、増分変更１１８の作用を受けた１次データベース１１０内のファイルを特定しても良い。
【００４０】
２次サーバ１０４は、この情報および／または他の情報を用いて、２次データベース１１４内の適切なフォルダにアクセスしても良い。たとえば２次サーバ１０４は、特定された１次サーバ１０２に付随するサーバ・フォルダ２５４にアクセスしても良い。また２次サーバ１０４は、そのサーバ・フォルダ２５４内に含まれる現在のタイムスタンプ・フォルダ２５６にアクセスしても良い。２次サーバ１０４はさらに、特定されたドライブ・フォルダ２００に関連するドライブ・フォルダ２５８、および／または特定されたファイル・システム・フォルダ２０２に関連するファイル・システム・フォルダ２６０にアクセスしても良い。２次データベース１１４内の適切なフォルダにアクセスした後、２次サーバ１０４は、増分変更１１８をそのフォルダ内に格納しても良い。たとえば２次サーバ１０４は、増分変更１１８を、特定されたファイルに関連する２次データベース１１４内のファイル内に格納しても良い。１つの実施形態においては、２次サーバ１０４は増分変更１１８を、その増分変更１１８の作用を受けた１次データベース１１０内のファイルと同じ名前のファイル内に格納しても良い。特定の例としては、増分変更１１８が、１次データベース１１０内の「ｐｕｂ１．ｅｄｂ」という名前のファイルに作用した場合に、２次サーバ１０４が増分変更１１８を、２次データベース１１４内の「ｐｕｂ１．ｅｄｂ」という名前のファイル内に格納しても良い。このようにして２次サーバ１０４は、１次データベース１１０のフォルダ階層の少なくとも一部を、２次データベース１１４内に再現しても良い。
【００４１】
特定の実施形態においては、２次サーバ１０４は増分変更１１８を、２次データベース１１４の「現在」のタイムスタンプ・フォルダ２５６内に、所定の時間間隔が経過するまで格納し続けても良い。時間間隔が経過した後で、２次サーバ１０４は、「現在」のタイムスタンプ・フォルダ２５６を閉じてその名前を変更する。たとえば２次サーバ１０４は、ラベル・タイムスタンプ・フォルダ２５６を、一日の日付および時刻を用いてラベル付けしても良い。また２次サーバ１０４は、新しい「現在」のタイムスタンプ・フォルダ２５６を作成して、より多くの増分変更１１８を、新しいタイムスタンプ・フォルダ２５６内に格納し始めても良い。増分変更１１８を新しいタイムスタンプ・フォルダ２５６内に格納する一方で、２次データベース１１４は、タイムスタンプ・フォルダ２５６内の増分変更１１８をバックアップ・システム１１２に、増分バックアップ１２０として伝達しても良い。増分バックアップ１２０が完了した後で、２次データベース１１４は、名前が変更されたタイムスタンプ・フォルダ２５６を削除しても良い。次に２次サーバ１０４は、「現在」のタイムスタンプ・フォルダ２５６の名前を変更して新しいタイムスタンプ・フォルダ２５６を作成することによって、プロセスを、次の時間間隔が経過した後に繰り返しても良い。他の実施形態においては、２次サーバ１０４は、増分バックアップ１２０を実行する前に複数の時間間隔が経過するまで待機しても良い。
【００４２】
２次サーバ１０４を、適切なタイムスタンプ・フォルダ２５６、ドライブ・フォルダ２５８、および／またはファイル・システム・フォルダ２６０に入力して、増分変更１１８を格納していると説明してきた。これは、フォルダ２５６〜２６０が存在し、またこれらに２次サーバ１０４がアクセスできることを仮定している。特定の実施形態においては、１次データベース１１０に対する完全バックアップ１１６を開始する時点で、その１次データベース１１０に関連する増分変更１１８を、２次データベース１１４から削除しても良い。これはたとえば、適切なサーバ・フォルダ２５４のコンテンツを削除することによって行なっても良い。その結果、２次サーバ１０４は、タイムスタンプ・フォルダ２５６、ドライブ・フォルダ２５８、および／またはファイル・システム・フォルダ２６０を、増分変更１１８を格納する前に作成することが必要となる場合がある。また２次サーバ１０４は、増分変更１１８を２次データベース１１４内に格納するためのファイルを作成することが必要となる場合がある。この実施形態においては、２次サーバ１０４が増分変更１１８を受け取ったときに、２次サーバ１０４は、適切なフォルダ２５６〜２６０およびファイルが２次データベース１１４内に存在しているかどうかを判定しても良い。存在していない場合には、２次サーバ１０４は、必要なフォルダ２５６〜２６０および／または必要なファイルを作成しても良い。
【００４３】
１つの実施形態においては、増分変更１１８が、１次データベース１１０のドライブ・フォルダ２００またはファイル・システム・フォルダ２０２のコンテンツに加えられない場合には、２次データベース１１４には、対応するドライブ・フォルダ２５８またはファイル・システム・フォルダ２６０がなくても良い。たとえば、例示した実施形態においては、ドライブ・フォルダ２５８ｅには、「ＡＰＰＳ」および「交換サーバ」という名前のファイル・システム・フォルダ２６０ｉ〜２６０ｊが含まれている。これらのファイル・システム・フォルダ２６０ｉ〜２６０ｊは、図２Ａのファイル・システム・フォルダ２０２ａ〜２０２ｂに対応する。このことは、増分変更１１８が、ファイル・システム・フォルダ２０２ａ〜２０２ｂのコンテンツに加えられたことを示している。しかし他の実施形態においては、ドライブ・フォルダ２５８ｅには、ファイル・システム・フォルダ２６０ｉがない可能性がある。このことは、増分変更１１８が、「ＡＰＰＳ」ファイル・システム・フォルダ２０２ａのコンテンツには、時間間隔タイムスタンプ・フォルダ２５６ｃによって表わされる時間間隔の間に、まったく加えられなかったことを意味する場合がある。
【００４４】
システム１００によってモニタされて２次データベース１１４内に格納される増分変更１１８は、特定の要求に応じて変化しても良い。１つの実施形態においては、１次データベース１１０を含むデータベース動作の中には、必ずしも、増分変更１１８を形成して２次データベース１１４内に格納することに至らないものがある。特定の例として、ユーザは、１次データベース１１０内のファイルからの情報を、開け、閉じ、または読んでも良い。これらの動作は、データベース・ファイル内のデータを変えないため、増分変更１１８を２次データベース１１４内に格納する必要はない。
【００４５】
他のデータベース動作が、増分変更１１８の形成および２次データベース１１４内への格納につながっても良い。たとえばユーザが、データを、１次データベース１１０内のファイルに書き込んでも良い。それが行なわれたときに、２次サーバ１０４は、同じ名前のファイルが２次データベース１１４の適切なフォルダ２５８または２６０内に現れたかどうかを判定して、存在しない場合にはファイルを作成して、新しく書き込まれたデータをそのファイル内に増分変更１１８として格納しても良い。またユーザは、１次データベース１１０内のファイルを削除しても良い。この場合、２次サーバ１０４は、２次データベース１１４内の対応するファイルを、削除されたとしてマーキングしても良い。同様に、ユーザは１次データベース１１０内のサブツリーを削除して、その結果、１次データベース１１０内のフォルダ２００または２０２のコンテンツを削除しても良い。それが行なわれたときに、２次サーバ１０４は、２次データベース１１４内の対応するフォルダ２５８または２６０のコンテンツを削除して、対応するフォルダ２５８または２６０を、削除されたとしてマーキングしても良い。ユーザはさらに、１次データベース１１０内のファイルの名前を変更しても良い。その場合、２次サーバ１０４は、２次データベース１１４内の対応するファイルの名前を、古い名前から新しい名前に変更して、古い名前を有する新しいファイルを２次データベース１１４内に作成し、新しいファイルを、削除されたとしてマーキングしても良い。加えてユーザは、１次データベース１１０内のファイルの１つまたは複数の特性に作用する他の種々の命令を実行しても良い。たとえば、ユーザは、ＳｅｔＢａｓｉｃｌｎｆｏおよびＳｅｔＣｏｍｐｒｅｓｓｉｏｎなどの命令を実行して、１次データベース１１０内のファイルに付随する情報および／または圧縮を変えても良い。またユーザは、ＳｅｔＳｅｃｕｒｉｔｙおよびＳｅｔＳｅｃｕｒｉｔｙＢｙＮａｍｅなどの命令を実行して、１次データベース１１０内のファイルのセキュリティ特性を変えても良い。ユーザはさらに、１次データベース１１０内のファイルを切り取って、ファイルのサイズを小さくしても良い。これらの動作に対して、２次サーバ１０４は、新しいファイル情報、ファイル・セキュリティ情報、およびファイル長を、２次データベース１１４内の対応するファイル内に格納しても良い。その他に、１次データベース１１０内のレジストリに変更を加えたときに、すなわち、たとえばオペレーティング・システムが、レジストリ内に構成情報を付加し、更新し、または除去したときに、その変更を２次データベース１１４内に格納しても良い。本開示の範囲から逸脱することなく、他の増分変更１１８を２次データベース１１４内に格納しても良い。
【００４６】
図２Ａおよび２Ｂでは、例として１次および２次データベース１１０および１１４を例示しているが、本開示の範囲から逸脱することなく、種々の変更をデータベース１１０および１１４に加えても良い。たとえば、フォルダ２００〜２０２およびフォルダ２５０〜２６０は説明のためだけのものである。他の任意のフォルダおよび／またはさらなるフォルダを、データベース１１０および／または１１４内で用いても良い。また、好適であれば情報のどんな配置も、フォルダ・システムの代わりに用いても良い。
【００４７】
図３は、本開示の一実施形態によるディザスタ・リカバリ・アーキテクチャ３００の一部を例示する典型的なブロック・ダイアグラムである。アーキテクチャ３００は、たとえば、１次サーバ１０２および２次サーバ１０４上で実行されるソフトウェア・ルーチンを表わしている。例示した実施形態においては、アーキテクチャ３００には、ファイル・システム・モニタ（ＦＳＭ）３０２、ファイル・システム・トランザクション・サーバ（ＦＳＴＳ）３０４、１次サービス３０６、２次サービス３０８、およびコンソール・アプリケーション３１０が含まれている。本開示の範囲から逸脱することなく、他の実施形態アーキテクチャ３００を用いても良い。
【００４８】
ファイル・システム・モニタ３０２は、１つまたは複数のファイル・システム３１２ａ〜３１２ｃ（まとめてファイル・システム３１２と言う）内のファイルに対する増分変更１１８をモニタおよび検出するように、動作可能である。ファイル・システム３１２は、たとえば、図２Ａに示したデータベース・アーキテクチャをサポートしても良い。特定の実施形態においては、ファイル・システム・モニタ３０２は、ファイル・システム３１２内のファイルまたはレジストリ上で実行される書き込み、作成、名前変更、および削除の動作を検出しても良い。ファイル・システム・モニタ３０２が増分変更１１８を検出したときに、ファイル・システム・モニタ３０２は、ファイル・システム・トランザクション・サーバ３０４に通知しても良い。たとえば、ファイル・システム・モニタ３０２が、データのブロックがファイルに付加されたことを検出した場合には、ファイル・システム・モニタ３０２は、ファイル・システム・トランザクション・サーバ３０４に、作用を受けたファイルの名前、データのブロックが書き込まれたアドレス、およびデータ・ブロックのサイズを通知しても良い。ファイル・システム・モニタ３０２には、１つまたは複数のファイル・システム３１２内の増分変更１１８を検出するように動作可能である、任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが含まれていても良い。ファイル・システム・モニタ３０２には、たとえば、１次サーバ１０２内の１つまたは複数のプロセッサによって実行されるカーネル・モード・ソフトウェア・ドライバが含まれていても良い。
【００４９】
ファイル・システム・トランザクション・サーバ３０４は、ファイル・システム・モニタ３０２によって特定された増分変更１１８を受け取って、増分変更１１８を所定の時間間隔の間だけ蓄積するように、動作可能である。たとえば、ファイル・システム・トランザクション・サーバ３０４は、増分変更１１８を、５秒間のウィンドウの間だけ蓄積しても良い。ファイル・システム・トランザクション・サーバ３０４には、増分変更１１８を受け取って蓄積するように動作可能である任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが含まれていても良い。ファイル・システム・トランザクション・サーバ３０４には、たとえば、１次サーバ１０２内の１つまたは複数のプロセッサによって実行されるカーネル・モード・ソフトウェア・ドライバが含まれていても良い。特定の実施形態においては、ファイル・システム・トランザクション・サーバ３０４は、ファイル・システム・モニタ３０２のクライアント・プロセスとして機能する。他の実施形態においては、増分変更１１８の蓄積を行なわなくても良く、ファイル・システム・トランザクション・サーバ３０４をアーキテクチャ３００から省略しても良い。
【００５０】
１次サービス３０６および２次サービス３０８は、１次サーバ１０２と２次サーバ１０４との間の通信を容易にするように動作可能である。たとえば１次サービス３０６は、蓄積された増分変更１１８をファイル・システム・トランザクション・サーバ３０４から受け取って、増分変更１１８を２次サービス３０８に伝達しても良い。２次サービス３０８は、増分変更１１８を１次サービス３０６から受け取って、増分変更１１８をファイル・システム３１４に書き込んでも良い。ファイル・システム３１４は、たとえば、図２Ｂに示したデータベース・アーキテクチャをサポートしても良い。１次サービス３０６および２次サービス３０８には、１次サーバ１０２と２次サーバ１０４との間の通信を容易にするように動作可能である任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせが含まれていても良い。１次サービス３０６および２次サービス３０８には、たとえば、１次サーバ１０２および２次サーバ１０４内の１つまたは複数のプロセッサによってそれぞれ実行されるユーザ・モード・アプリケーションが含まれていても良い。
【００５１】
コンソール・アプリケーション３１０は、システム１００内のディザスタ・リカバリ動作を制御するためのインターフェースを与えるように動作可能である。コンソール・アプリケーション３１０によって、たとえばユーザが、ディザスタ・リカバリ動作を、スクリプト・ファイルを用いて制御できるようになっていても良い。特定の例として、ユーザは、適切なスクリプト命令を用いることで、２次データベース１１４内のデータ・ストアを名前を変更しまたは削除しても良い。またユーザは、適切なスクリプト命令を用いることで、システム１００に、１次データベース１１０を復元させることもできる。本開示の範囲から逸脱することなく、ディザスタ・リカバリ動作を制御する他の方法、たとえばアプリケーション・プログラミング・インターフェース（ＡＰＩ）を用いることによる方法を、用いても良い。
【００５２】
１つの実施形態においては、１次サービス３０６および／または２次サービス３０８が、１つまたは複数のタスクの実行をサポートする。タスクは、ディザスタ・リカバリ機能性の一部または全部を実行する１次サービス３０６および／または２次サービス３０８によるプロセス・ランを表わしていても良い。たとえば、１つまたは複数の複製タスクによって、１次データベース１１０に加えられた増分変更１１８を２次データベース１１４内に複製することが引き起こされても良い。特定の実施形態においては、ユーザが複製タスクを開始し、停止し、および制御することが、たとえばコンソール・アプリケーション３１０を通して入力された適切なスクリプト命令を用いることなどによって、行なわれても良い。
【００５３】
この実施形態においては、タスク・ファイルを複製タスクが用いて、増分変更１１８を２次データベース１１４内に複製しても良い。タスク・ファイルは、たとえば、増分変更１１８をモニタすべき、１次データベース１１０内のファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチを特定しても良い。またタスク・ファイルは、除外して増分変更１１８をモニタすべきでない、１次データベース１１０内のファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチを特定しても良い。タスク・ファイルはさらに、ディザスタ・リカバリ動作で用いられるタイムアウト・パラメータおよび他のパラメータを特定しても良い。タスク・ファイルは、たとえば、マニュアルで編集することができおよび／また標準的なＡＰＩを用いてプログラムにより編集することができるＩＮＩファイルを表わしても良い。
【００５４】
動作の一態様においては、ユーザは、複製タスクを特定の１次サーバ１０２に対して作動させても良い。特定の実施形態においては、複製タスクを完全バックアップ１１６が始まる前に作動させることで、その１次サーバ１０２によって完全バックアップ１１６の間に加えられるわずかな増分変更１１８も、システム１００内に確実に捕らえられるようにする。１次サービス３０６は、タスク・ファイルを読み取って、どのファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチをモニタすべきかを特定しても良い。また１次サービス３０６は、ファイル・システム・トランザクション・サーバ３０４を、これらのファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチをモニタするように構成しても良い。そしてファイル・システム・トランザクション・サーバ３０４は、ファイル・システム・モニタ３０２によって検出されるわずかな増分変更１１８もモニタして、モニタされたファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチに加えられた増分変更１１８を報告し、除外されたファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチに加えられた増分変更１１８を無視しても良い。２次サービス３０８は、２次データベース１１４を初期化して、増分変更１１８を格納しても良い。たとえば、２次サービス３０８は、「現在」のタイムスタンプ・フォルダ２５６を、適切なサーバ・フォルダ２５４の下に作成しても良い。また１次サービス３０６および２次サービス３０８は、通信リンク、たとえばネットワーク１０６上のリンクを確立しても良い。
【００５５】
またユーザは、複製タスクの動作を停止しても良い。それが行なわれたときには、１次サービス３０６および２次サービス３０８は、増分変更１１８を伝達することを停止しても良い。ユーザは続けて、現在のデータ・ストアを削除しても良く、その結果、２次データベース１１４内の現在のタイムスタンプ・フォルダ２５６を削除しても良い。またユーザは、現在のデータ・ストアの名前を変えることが、２次データベース１１４内の現在のタイムスタンプ・フォルダ２５６の名前を日付および時間を反映するように変えることなどによって、可能である。現在のデータ・ストアの名前を変えた後で、ユーザは複製タスクを再開しても良い。こうすることで、システム１００は再び、増分変更１１８をモニタして、新しい現在のデータ・ストア、たとえば新しいタイムスタンプ・フォルダ２５６内に記録する。
【００５６】
図３では、ユーザが、コンソール・アプリケーション３１０を用いてシステム１００内のディザスタ・リカバリ動作を制御できると説明してきた。システム１００を、複製タスクを自動的に開始および停止し、データ・ストアの名前を変更し、および／またはデータ・ストアを必要に応じて削除するように構成することもできる。
【００５７】
図３では、ディザスタ・リカバリ・アーキテクチャ３００の一部の一例を示しているが、本開示の範囲から逸脱することなく、種々の変更をアーキテクチャ３００に加えても良い。たとえば、図３の機能的な区分は、説明するためだけのものである。本開示の範囲から逸脱することなく、種々の機能的コンポーネントを、特定の要求に応じて互いに組み合わせることまたは除去することができる。また、アーキテクチャ３００のコンポーネント３０２〜３１０の機能を、任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを用いて実行しても良い。これにはたとえば、好適な任意のデバイス、たとえばランダム・アクセス・メモリ、リード・オンリ・メモリ、特定用途向け集積回路（ＡＳＩＣ）、またはフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）に格納されるロジックが含まれていても良い。
【００５８】
図４は、本開示の一実施形態によるディザスタ・リカバリのための方法４００を例示する典型的なフローダイアグラムである。方法４００を図１のシステム１００に関して説明する場合もあるが、本開示の範囲から逸脱することなく、方法４００は好適な他のどんなシステムが用いても良い。
【００５９】
システム１００は、ステップ４０２において、１次データベース１１０内の情報の完全バックアップ１１６を行なう。これにはたとえば、１次サーバ１０２が１次データベース１１０内の情報の一部または全部を、バックアップ・システム１１２へ伝達することが含まれていても良い。バックアップ・システム１１２は、２次サーバ１０２および／または他の好適なプラットフォーム上に存在していても良い。
【００６０】
システム１００は、ステップ４０４において、１次データベース１１０内の情報に加えられた増分変更１１８をモニタする。これにはたとえば、１次サーバ１０２が、１次データベース１１０内の情報に加えられた増分変更１１８を特定して、増分変更１１８を２次サーバ１０４へ伝達することが含まれていても良い。またこれには、２次サーバ１０４が、増分変更１１８を２次データベース１１４内に記録することが含まれていても良い。これにはさらに、２次サーバ１０４が、１つまたは複数の増分バックアップ１２０を行なうことが、すなわち２次サーバ１０４が少なくとも一部の増分変更１１８を２次データベース１１４からバックアップ・システム１１２内へ格納することが、含まれていても良い。
【００６１】
ステップ４０６において、１次データベース１１０が故障する。これにはたとえば、１次データベース１１０が、１次データベース１１０を動作不能にするハードウェアまたはソフトウェアのエラーを被ることが含まれていても良い。またこれには、１次サーバ１０２が停電を被ることが含まれていても良い。本開示の範囲から逸脱することなく、ステップ４０６においてデータベース故障の他の原因が生じても良い。ステップ４０８において、１次データベース１１０が再び動作可能になる。これにはたとえば、技術者がハードウェアまたはソフトウェアのエラーを解決すること、１次サーバ１０２に対するパワーを復元すること、および／またはデータベース故障を解決する任意の好適な他の是正処置が、含まれていても良い。
【００６２】
ステップ４１０において、システム１００が１次データベース１１０を復元する。これにはたとえば、バックアップ・システム１１２が、最後の完全バックアップ１１６から情報を１次サーバ１０２へ伝達することが含まれていても良い。これにはまた、バックアップ・システム１１２が増分変更１１８を、１つまたは複数の増分バックアップ１２０から１次サーバ１０２へ伝達することが含まれていても良い。これにはさらに、２次データベース１１４が少なくとも１つの増分変更１１８を、１次サーバ１０２へ伝達することが含まれていても良い。加えてこれには、１次サーバ１０２が、２次サーバ１０４からの情報を用いて１次データベース１１０を復元することが含まれていても良い。１次サーバ１０２は、１次データベース１１０を、データベース故障の時間にまたはその付近に存在していた状態に、データベース１１０の故障の前に存在していた状態に、および／または任意の好適な他の状態に復元しても良い。
【００６３】
図４では、ディザスタ・リカバリのための方法４００の一例を例示しているが、本開示の範囲から逸脱することなく、種々の変更を方法４００に加えても良い。たとえば、システム１００は１次データベース１１０を、最後の完全バックアップ１１６からの情報を用いて、増分変更１１８を用いずに、復元することができる。これはたとえば、システム１００が１次データベース１１０を、最後の完全バックアップ１１６の時間に存在していた状態に復元しているときに行なわれることが考えられる。本開示の範囲から逸脱することなく、他の変更を方法４００に加えても良い。
【００６４】
図５は、本開示の一実施形態による１次サーバ１０２におけるファイル・バックアップのための方法５００を例示する典型的なフローダイアグラムである。方法５００は、たとえば１次サーバ１０２が、ディザスタ・リカバリ動作のバックアップ・フェーズの間に用いても良い。方法５００の説明を、図１の１次サーバ１０２に関して行なうことがあるが、本開示の範囲から逸脱することなく、方法５００は好適な他のどんなプラットフォームが用いても良い。
【００６５】
ステップ５０２において、１次サーバ１０２は、１次データベース１１０内でモニタすべき情報を特定する。これにはたとえば、１次サービス３０６および／または２次サービス３０８によって実行される複製タスクの作動が含まれていても良い。またこれには、複製タスクが、１次データベース１１０内の１つまたは複数のファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチを特定するタスク・ファイルをアクセスすることが含まれていても良い。タスク・ファイル内のファイル、フォルダ２００〜２０２、レジストリ、および／またはレジストリ・ブランチは、たとえばユーザ・システム１００のユーザが特定しても良い。
【００６６】
ステップ５０４において、１次サーバ１０２は、特定された情報を、完全バックアップ１１６の間にバックアップ・システム１１２に伝達する。これにはたとえば、１次サーバ１０２が、任意の特定されたファイルをバックアップ・システム１１２へ伝達することが含まれていても良い。またこれには、１次サーバ１０２が、任意の選択されたフォルダ２００〜２０２のコンテンツを、バックアップ・システム１１２へ伝達することが含まれていても良い。
【００６７】
ステップ５０６において、１次サーバ１０２は、１つまたは複数のファイル・イベントの発生を検出する。ファイル・イベントは、たとえば、新しい情報をデータベース１１０内の既存のまたは新しいファイルへ加えること、データベース１１０内の既存の情報を変更すること、またはデータベース１１０から既存の情報を削除することを表わしていても良い。ファイル・イベントは、ステップ１０４で行なわれる完全バックアップ１１６の前に、完全バックアップ１１６の間に、および／または完全バックアップ１１６の後で、生じることができる。１つの実施形態においては、ファイル・イベントの検出を、ファイル・システム・モニタ３０２が行なっても良い。
【００６８】
ステップ５０８において、１次サーバ１０２は、ファイル・イベントを所定の時間の間隔の間、蓄積する。これにはたとえば、ファイル・システム・トランザクション・サーバ３０４が、複数のファイル・イベントをファイル・システム・モニタ３０２から、所定の時間の間隔の間に、たとえば５秒間のウィンドウの間に、受け取ることが含まれていても良い。またこれには、ファイル・システム・トランザクション・サーバ３０４が、５秒間のウィンドウの間に受け取ったファイル・イベントを組み合わせて、１つまたは一連のメッセージにすることが含まれていても良い。
【００６９】
ステップ５１０において、１次サーバ１０２は、ファイル・イベントを２次データベース１１４に、増分変更１１８として伝達する。これにはたとえば、ファイル・システム・トランザクション・サーバ３０４がメッセージまたは一連のメッセージを１次サービス３０６へ伝達すること、および１次サービス３０６がメッセージを２次サービス３０８へ伝達することが、含まれていても良い。
【００７０】
ステップ５１２において、１次サーバ１０２は、最後の完全バックアップ１１６からの時間が閾値を超えているかどうかを判定する。これにはたとえば、１次サーバ１０２が、最後の完全バックアップ１１６からの時間が、ユーザによって確立された閾値時間間隔を超えているかどうかが含まれていても良い。最後の完全バックアップ１１６からの時間が閾値を超えていない場合には、１次サーバ１０２はステップ５０６へ戻って、さらなるファイル・イベントの発生を検出する。そうでない場合には、１次サーバ１０２はステップ５０４へ戻って、別の完全バックアップ１１６を行なう。特定の実施形態においては、１次サーバ１０２は完全バックアップ１１６を、１日に１回または１年に１回、行なっても良い。
【００７１】
図５では、１次サーバ１０２でのファイル・バックアップのための方法５００の一例を例示しているが、本開示の範囲から逸脱することなく、種々の変更を方法５００に加えても良い。たとえば１次サーバ１０２は、１次データベース１０２内の情報のすべてをモニタすることができる。この実施形態においては、ステップ５０２において、１次サーバ１０２は、モニタすべき情報を特定する必要はなくても良い。また１次サーバ１０２は、ファイル・イベントを２次サーバ１０４へ伝達することを、ステップ５０８においてファイル・イベントを蓄積することなく行なうことができる。加えて１次サーバ１０２は、完全バックアップ１１６をいつ行なうかを決定するための任意の好適な方法を用いることができ、および最後の完全バックアップ１１６からの時間が閾値時間を超えているかどうかを判定することに限定されない。
【００７２】
図６は、本開示の一実施形態による２次サーバ１０４におけるファイル・バックアップのための方法６００を例示する典型的なフローダイアグラムである。方法６００は、たとえば２次サーバ１０４が、ディザスタ・リカバリ動作のバックアップ・フェーズの間に用いても良い。方法６００の説明を、図１の２次サーバ１０４に関して行なう場合もあるが、本開示の範囲から逸脱することなく、方法６００は好適な他のどんなプラットフォームまたはプラットフォームが用いても良い。また方法６００の説明を、単一の１次サーバ１０２に関して行なう場合もあるが、複数の１次サーバ１０２を２次サーバ１０４がサポートしても良い。
【００７３】
ステップ６０２において、２次サーバ１０４はバックアップ情報を、完全バックアップ１１６の間に１次データベース１１０から受け取る。これにはたとえば、２次サーバ１０４が情報を、１次サーバ１０２からネットワーク１０６を介して受け取ることが含まれていても良い。ステップ６０４において、２次サーバ１０４は、バックアップ情報をバックアップ・システム１１２内に格納する。これにはたとえば、バックアップ・システム１１２がバックアップ情報を、１次データベース１１０から１つまたは複数のコンピュータ可読媒体、たとえば磁気テープまたはコンパクト・ディスク上に記録することが含まれていても良い。またこれには、２次サーバ１０４が２次データベース１１４を、たとえば１次サーバ１０２に関連するサーバ・フォルダ２５４の任意のコンテンツを削除することによって、初期化することが含まれていても良い。
【００７４】
ステップ６０６において、２次サーバ１０４が、増分変更１１８を１次データベース１１０から受け取る。これにはたとえば、２次サービス３０８が、増分変更１１８を含む１つまたは複数のメッセージを、１次サービス３０６から受け取ることが含まれていても良い。増分変更１１８の受け取りは、ステップ６０４においてバックアップ情報をバックアップ・システム１１２内に格納する前、格納する間、および／または格納する後に行なっても良い。ステップ６０８において、２次サーバ１０４が、増分変更１１８を現在のデータ・ストアに格納する。これにはたとえば、２次サービス３０８が増分変更１１８を、２次データベース１１４内の「現在」のタイムスタンプ・フォルダ２５６に含まれる１つまたは複数のファイル内に格納することが含まれていても良い。またこれには２次サービス３０８が、１つまたは複数のフォルダ２５６〜２６０、および／または増分変更１１８を２次データベース１１４内に格納するための１つまたは複数のファイルを、作成することが含まれていても良い。
【００７５】
ステップ６１０において、２次サーバ１０４は、トリガ・イベントが発生するかどうかを判定する。トリガ・イベントは、たとえば、所定の時間間隔が経過すること、またはユーザから命令を受け取ることを表わしていても良い。トリガ・イベントが検出されない場合には、２次サーバ１０４はステップ６０６へ戻って、さらなる増分変更１１８を受け取って格納する。２次サーバ１０４がトリガ・イベントを検出した場合には、２次サーバ１０４は続けて、増分バックアップ１２０を行なう。ステップ６１２において、２次サーバ１０４は、現在のデータ・ストアを閉じてその名前を変更する。これにはたとえば、２次サーバ１０４が、２次データベース１１４内の現在のタイムスタンプ・フォルダ２５６の名前を、日付および時間を反映するラベルを含むように変更することが含まれていても良い。ステップ６１４において、２次サーバ１０４は、名前が変更されたデータ・ストアを、増分バックアップ１２０の間にバックアップ・システム１１２内に格納する。これにはたとえば、２次データベース１１２が、名前が変更されたタイムスタンプ・フォルダ２５６内の情報を、バックアップ・システム１１２へ伝達することが含まれていても良い。ステップ６１６において、２次サーバ１０４は、新しい現在のデータ・ストアを２次データベース１１４内に作成する。これにはたとえば、２次サーバ１０４が新しいタイムスタンプ・フォルダ２５６を、名前「現在」を有する２次データベース１１４内に作成することが含まれていても良い。２次サーバ１０４による新しいデータ・ストアの作成は、ステップ６１４で行なわれる増分バックアップ１２０の前、増分バックアップ１２０の間、および／または増分バックアップ１２０の後であっても良い。ステップ６１８において、２次サーバ１０４は、名前が変更されたデータ・ストアを２次データベース１１４から削除する。これにはたとえば、２次サーバ１０４が、名前が変更されたタイムスタンプ・フォルダ２５６、およびそのタイムスタンプ・フォルダ２５６のコンテンツのすべてを、データベース１１４から削除することが含まれていても良い。２次サーバ１０４はステップ６０６に戻って、さらなる増分変更１１８を受け取って新しいデータ・ストア内に格納する。
【００７６】
図６では、２次サーバ１０４におけるファイル・バックアップのための方法６００の一例を例示しているが、本開示の範囲から逸脱することなく、種々の変更を方法６００に加えても良い。たとえば他の実施形態においては、２次サーバ１０４は増分バックアップ１２０を行なわない。また方法６００では、２次サーバ１０４が、単一のデータ・ストアをバックアップ・システム１１２に、それぞれの増分バックアップ１２０の間にコピーすることを例示しているが、２次サーバ１０４は、より多くのデータ・ストアをバックアップ・システム１１２に、増分バックアップの間にコピーすることができる。この実施形態においては、方法６００を変更して、新しいデータ・ストアを第１のトリガ・イベントの後に作成し、増分バックアップ１２０を第２のトリガ・イベントの後に行なうようにすることができる。さらに方法６００では、バックアップ・システム１１２および２次データベース１１４が、同じプラットフォーム、たとえば２次サーバ１０４上に位置すると仮定している。他の実施形態においては、バックアップ・システム１１２および２次データベース１１４は、異なるプラットフォーム上に位置していても良く、それぞれのプラットフォームが、例示したステップのサブセットを行なっても良い。
【００７７】
図７は、本開示の一実施形態による２次サーバ１０４におけるファイル復元のための方法７００を例示する典型的なフローダイアグラムである。方法７００は、たとえば２次サーバ１０４が、ディザスタ・リカバリ動作のリカバリ・フェーズの間に用いても良い。方法７００の説明を、図１の２次サーバ１０４に関して行なう場合もあるが、本開示の範囲から逸脱することなく、方法７００は好適な他のどんなプラットフォームまたはプラットフォームを用いても良い。また方法７００の説明を、単一の１次サーバ１０２に関して行なう場合があるが、複数の１次サーバ１０２を２次サーバ１０４がサポートしても良い。
【００７８】
ステップ７０２において、２次サーバ１０４がタイム・フレームを特定する。タイム・フレームは、１次データベース１１０を復元するべき時間を表わしていても良い。タイム・フレームは、たとえば、１次データベース１１０の故障時のまたはその付近の時間、データベース１１０の故障の前の時間、および／または任意の他の好適な時間を表わしていても良い。２次サーバ１０４は、特定されたタイム・フレームを、ユーザ、たとえばクライアント１０８またはコンソール・アプリケーション３１０を用いるユーザから、または任意の好適な他の仕方で、受け取っても良い。
【００７９】
ステップ７０４において、２次サーバ１０４は、最後の完全バックアップ１１６からのバックアップ情報を１次データベース１１０へ伝達する。これにはたとえば、バックアップ・システム１１２が、最後の完全バックアップ１１６からのバックアップ情報を、１次サーバ１０２へネットワーク１０６を介して伝達することが含まれていても良い。
【００８０】
ステップ７０６において、２次サーバ１０４は、最後の完全バックアップ１１６が行なわれた時間が、特定された時間を超えているかどうかを判定する。これにはたとえば、２次サーバ１０４が、最後の完全バックアップ１１６が始まった時間を、ステップ７０２で受け取った特定された時間と比較することが含まれていても良い。最後の完全バックアップ１１６に付随する時間が、特定された時間を超えている場合には、方法７００は終了する。２次サーバ１０４は、１次データベース１１０を復元するためのさらなるアクションを取る必要はない。
【００８１】
そうでない場合には、ステップ７０８において、２次サーバ１０４は最早の増分バックアップ１２０を選択する。ステップ７１０において、２次サーバ１０４は、選択された増分バックアップ１２０に付随する時間が、特定された時間を超えているかどうかを判定する。そうである場合には、２次サーバ１０４は、１次データベース１１０を復元するためのさらなるアクションを取る必要はなく、方法７００は終了する。そうでない場合には、ステップ７１２において、２次サーバ１０４は、選択された増分バックアップ１２０内に含まれる増分変更１１８を１次データベース１１０へ伝達する。これにはたとえば、バックアップ・システム１１２が、選択された増分バックアップ１２０内の増分変更１１８を、１次サーバ１０２へネットワーク１０６を介して伝達することが含まれていても良い。
【００８２】
ステップ７１４において、２次サーバ１０４は、処理するべき増分バックアップ１２０がバックアップ・システム１１２内にさらに残っているかどうかを判定する。さらなる増分バックアップ１２０が残っている場合には、ステップ７１６において、２次サーバ１０４は次の増分バックアップ１２０を選択する。これにはたとえば、２次サーバ１０４が、次の増分バックアップ１２０として、現在の増分バックアップ１２０の後に続いて行なわれたものを選択することが含まれていても良い。次に２次サーバ１０４は、ステップ７１０に戻って、新しく選択された増分バックアップ１２０内での増分変更１１８を、１次データベース１１０へ伝達するべきかどうかを判定する。
【００８３】
ステップ７１４において増分バックアップ１２０が残っていない場合には、ステップ７１８において、２次サーバ１０４は、２次データベース１１４内の最早のタイムスタンプ・フォルダ２５６を選択する。これにはたとえば、２次サーバ１０４が、最早のタイムスタンプ・ラベルを有するタイムスタンプ・フォルダ２５６を特定することが含まれていても良い。またこれには、２次サーバ１０４が、１次データベース１１０に関連するサーバ・フォルダ２５４内の最早のタイムスタンプ・フォルダ２５６を特定することが含まれていても良い。
【００８４】
ステップ７２０において、２次サーバ１０４は、選択されたタイムスタンプ・フォルダ２５６に付随する時間が、特定された時間を超えているかどうかを判定する。これにはたとえば、２次サーバ１０４が、選択されたタイムスタンプ・フォルダ２５６のタイムスタンプを、特定された時間と比較することが含まれていても良い。特定された時間が、選択されたタイムスタンプ・フォルダ２５６に付随する時間を超えている場合には、方法７００は終了する。そうでない場合には、ステップ７２２において、２次サーバ１０４は、選択されたタイムスタンプ・フォルダ２５６内に含まれる増分変更１１８を１次データベース１１０に伝達する。これにはたとえば、２次サーバ１０４が、増分変更１１８を１次サーバ１０２へ、ネットワーク１０６を介して伝達することが含まれていても良い。
【００８５】
ステップ７２４において、２次サーバ１０４は、２次データベース１１４内にタイムスタンプ・フォルダ２５６がさらに存在しているかどうかを判定する。処理するべきタイムスタンプ・フォルダ２５６がさらに残ってはいない場合には、方法７００は終了する。タイムスタンプ・フォルダ２５６がさらに残っている場合には、ステップ７２６において、２次サーバ１０４は次のタイムスタンプ・フォルダ２５６を選択する。これにはたとえば、２次サーバ１０４が、連続する次のタイムスタンプを有するタイムスタンプ・フォルダ２５６を選択することが含まれていても良い。そして２次サーバ１０４は、ステップ７２０へ戻って、新しく選択されたタイムスタンプ・フォルダ２５６を処理する。
【００８６】
図７では、２次サーバ１０４におけるファイル復元のための方法７００の一例を例示しているが、本開示の範囲から逸脱することなく、種々の変更を方法７００に加えても良い。たとえば、２次サーバ１０４をプログラミングして、１次データベース１１０が、データベース１１０の故障の時間にまたはその付近に存在していた状態に自動的に復元するようにすることができる。この場合、２次サーバ１０４は、タイム・フレームを受け取る必要はなく、受け取った時間を、最後の完全バックアップ１１６、増分バックアップ１２０、およびタイムスタンプ・フォルダ２５６に付随する時間と比較する必要もない。また、バックアップ・システム１１２および／または２次データベース１１４内に格納されるそれぞれの増分変更１１８を、増分変更１１８が加えられた時間を示すようにタイムスタンプすることができる。この実施形態においては、２次サーバ１０４は、それぞれの増分変更１１８に付随するタイムスタンプを、ステップ７０２で受け取った時間と比較することができる。このように、２次サーバ１０４は、増分バックアップ１２０および／またはタイムスタンプ・フォルダ２５６内に含まれるすべての増分変更１１８を１次サーバ１０２に伝達する必要はない。さらに方法７００では、バックアップ・システム１１２および２次データベース１１４が、同じプラットフォーム、たとえば２次サーバ１０４上に、位置していると仮定している。他の実施形態においては、バックアップ・システム１１２および２次データベース１１４は、異なるプラットフォーム上に位置していても良く、それぞれのプラットフォームが、例示したステップのサブセットを行なっても良い。加えて図７では、２次サーバ１０４が、情報を１次サーバ１０２へ伝達するべきかどうかの判定を、特定された時間を用いて行なうことが例示されている。他の実施形態においては、２次サーバ１０４は、適切な情報をすべて１次サーバ１０２へ伝達することができ、１次サーバ１０２が、情報を１次サーバ１０２へ送るべきかどうかの判定を、特定された時間を用いて行なう。
【００８７】
図８は、本開示の一実施形態による１次サーバ１０２におけるファイル復元のための方法８００を例示する典型的なフローダイアグラムである。方法８００は、たとえば１次サーバ１０２が、ディザスタ・リカバリ動作のリカバリ・フェーズの間に用いても良い。方法８００の説明を、図１の１次サーバ１０２に関して行なう場合があるが、本開示の範囲から逸脱することなく、方法８００は好適な他のどんなプラットフォームが用いても良い。
【００８８】
ステップ８０２において、１次サーバ１０２は、バックアップ情報をバックアップ・システム１１２から受け取る。これにはたとえば、１次サーバ１０２が、１次データベース１１０の故障の前に行なわれた最後の完全バックアップ１１６の間に格納される情報を受け取ることが含まれていても良い。ステップ８０４において、１次サーバ１０２が、バックアップ情報を１次データベース１１０内に格納する。これにはたとえば、１次サーバ１０２が、バックアップ・システム１１２から受け取ったバックアップ情報を、１次データベース１１０内の適切なフォルダ２００〜２０２内に格納することが含まれていても良い。この結果、１次データベース１１０が、最後の完全バックアップ１１６の時間にまたはその付近に存在していた状態に復元される。
【００８９】
ステップ８０６において、１次サーバ１０２は、１つまたは複数の増分変更１１８をバックアップ・システム１１２から受け取る。増分変更１１８は、たとえば、１つまたは複数の増分バックアップ１２０の間にバックアップ・システム１１２内に格納されても良い。ステップ８０８において、１次サーバ１０２は、１次データベース１１０内に格納される情報に対して増分変更１１８を再現する。これにはたとえば、１次サーバ１０２が、増分変更１１８を受け取って、同じ変更を１次データベース１１０内の情報に対して行なうことが含まれていても良い。この結果、１次データベース１１０が、最後の増分変更１２０の時間にまたはその付近に存在していた状態に復元される。
【００９０】
ステップ８１０において、１次サーバ１０２は、１つまたは複数の増分変更１１８を２次データベース１１４から受け取る。これにはたとえば、２次サーバ１０４が増分変更１１８を、１つまたは複数のタイムスタンプ・フォルダ２５６から、１次サーバ１０２へネットワーク１０６を介して伝達することが含まれていても良い。ステップ８１２において、１次サーバ１０２は、２次データベース１１４から受け取った増分変更１１８を１次データベース１１０内に再現する。この結果、１次データベース１１０が、１次データベース１１０の故障の時間にまたはその付近に存在していた状態に復元される。
【００９１】
図８では、１次サーバ１０２におけるファイル復元のための方法８００の一例が例示されているが、本開示の範囲から逸脱することなく、種々の変更を方法８００に加えても良い。たとえば方法８００は、１次データベース１１０を、データベース故障の時間にまたはその付近に存在していた状態に復元すると例示される。また１次データベース１１０を、データベース１１０の故障の前に存在していた状態に復元することもできる。１つの実施形態においては、１次サーバ１０２は１次データベース１１０の復元を、ステップ８０２〜８０４を用いて、ステップ８０６〜８１２を用いずに、行なうことができる。また１次サーバ１０２は、１次データベース１１０の復元を、ステップ８０２〜８０８を用いて、ステップ８１０〜８１２を用いずに、行なうこともできる。本開示の範囲から逸脱することなく、例示したステップのサブセットを用いる他の実施形態を用いることもできる。
【００９２】
本開示を、好ましい実施形態および一般的に関連する方法に関して説明してきたが、好ましい実施形態および方法の修正および置換が当業者には明らかである。したがって、好ましい典型的な実施形態についての前述の説明は、本開示を規定するものでも制約するものでもない。本開示の趣旨および範囲から逸脱することなく、他の変更、置換、および修正も可能であり、これは、以下の特許請求の範囲に規定されている通りである。
【図面の簡単な説明】
【００９３】
【図１】本開示の一実施形態によるディザスタ・リカバリ・システムを例示する典型的なブロック・ダイアグラムを示す図である。
【図２Ａ】本開示の一実施形態による１次および２次データベースを例示する典型的なブロック・ダイアグラムである。
【図２Ｂ】本開示の一実施形態による１次および２次データベースを例示する典型的なブロック・ダイアグラムである。
【図３】本開示の一実施形態によるディザスタ・リカバリ・アーキテクチャの一部を例示する典型的なブロック・ダイアグラムである。
【図４】本開示の一実施形態によるディザスタ・リカバリのための方法を例示する典型的なフローダイアグラムである。
【図５】本開示の一実施形態による１次サーバにおけるファイル・バックアップのための方法を例示する典型的なフローダイアグラムである。
【図６】本開示の一実施形態による２次サーバにおけるファイル・バックアップのための方法を例示する典型的なフローダイアグラムである。
【図７】本開示の一実施形態による２次サーバにおけるファイル復元のための方法を例示する典型的なフローダイアグラムである。
【図８】本開示の一実施形態による１次サーバにおけるファイル復元のための方法を例示する典型的なフローダイアグラムである。
【図１】
2005523517.tif 000003
【図２Ａ】
2005523517.tif 000004
【図２Ｂ】
2005523517.tif 000005
【図３】
2005523517.tif 000006
【図４】
2005523517.tif 000007
【図５】
2005523517.tif 000008
【図６】
2005523517.tif 000009
【図７】
2005523517.tif 000010
【図８】
2005523517.tif 000011
【手続補正書】
【提出日】平成17年1月21日(2005.1.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１９
【補正方法】変更
【補正の内容】
【請求項１９】
前記１つまたは複数のプロセッサが、
第１の増分変更をバックアップ・システムから受け取るステップと、
第２の増分変更を第２のデータベースから受け取るステップとによって、増分変更を受け取るように共同して動作可能である請求項１７に記載のシステム。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項６１
【補正方法】変更
【補正の内容】
【請求項６１】
増分変更が第１の増分変更を含み、
前記ロジックがさらに、第２の増分変更を第２のデータベースからバックアップ・システムへコピーするように動作可能であり、
前記ロジックが、第１のデータベースを少なくとも１つのバックアップ情報を用いて復元するように動作可能であり、第１の増分変更は第２のデータベース内に格納され、第２の増分変更はバックアップ・システム内に格納される請求項６０に記載のシステム。
【手続補正３】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項６２
【補正方法】変更
【補正の内容】
【請求項６２】
前記ロジックがさらに、復元時間を受け取るように動作可能であり、
前記ロジックは、
バックアップ情報を第１のデータベース内に格納するステップと、
バックアップ・システム内に格納される第２の増分変更に付随する第１の時間が、復元時間を超えているかどうかを判定するステップと、
第１の時間が復元時間を超えていないときに、第２の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップと、
第２のデータベース内に格納される第１の増分変更に付随する第２の時間が、復元時間を超えているかどうかを判定するステップと、
第２の時間が復元時間を超えていないときに、第１の増分変更を、第１のデータベース内の少なくとも一部の情報に対して行なうステップとによって、第１のデータベースを復元するように動作可能である請求項６１に記載のシステム。
【手続補正４】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項６３
【補正方法】変更
【補正の内容】
【請求項６３】
第２のデータベースおよびバックアップ・システムが単一のプラットフォーム上に存在する請求項６０に記載のシステム。
【国際調査報告】
2005523517.tif 000012
2005523517.tif 000013
2005523517.tif 000014