JP2023501788A - ブロックチェーンベースのバックアップおよび回復のためのシステムおよび方法 - Google Patents

Abstract

従来のデータストアでの使用のための、データバックアップおよび回復の、ブロックチェーンベースのシステムおよび方法が開示される。システムは、1つまたは複数のノードと記憶適合層とを含むブロックチェーンを含む。記憶適合層は、ブロックチェーンおよびデータストアとデータ通信し、データストレージからのデータをブロックチェーンに記憶する。データストアは、リレーショナルデータベース管理システムまたは他のタイプのデータストアであってよい。システムは、ブロックチェーン中のデータをデータストアに回復するように構成された回復適合層をさらに含む。回復適合層も、ブロックチェーンおよびデータストアとデータ通信する。

Description

本発明は、データバックアップおよび回復に関し、より詳細には、ブロックチェーン技術に基づくリアルタイムのデータバックアップおよび回復に関する。

ブロックチェーンとは、暗号技術を使って互いにリンクされたブロックにグループ化された、記録のリストである。ブロックチェーンシステムは、集団的参加および参加者の間のコンセンサスを用いて、トランザクションの信頼できる記録を維持するのに使われる。ブロックチェーンは、ノードと呼ばれる複数のネットワーク化デバイスによって共同で維持される分散型台帳技術として理解されてよい。ブロックチェーンはしたがって、分散型記憶システムであると思われてよい。

データベースバックアップおよび回復プロセスを使用する従来の記憶システムは概して、冗長ハードウェアおよび関連ソフトウェアへの多額の投資を必要とする。その上、実際のバックアップおよび回復周期は、実行された場合、通常、かなり労働集約的であり得る。したがって、しばしば、企業環境において、データのリアルタイムバックアップおよび回復が可能な、信頼できるシステムをセットアップするのにはコストがかかる。

リアルタイムデータバックアップのために、既存の技術を使用する従来のシステムはしばしば、強力なバックアップサーバの使用を必要とする。ただし、そのような強力なサーバの使用率はしばしば低く、このことが、すでに獲得されている計算リソースの膨大な浪費につながる。

バックアップサーバの中のバックアップデータに対して変更が行われた場合、システムが回復されると、生産データベース中のデータは不正確になる。したがって、様々な組織の必要を満たす、信頼できる、セキュアな、多用途の、安価なバックアップシステムが必要である。

バックアップおよび回復動作に関連した問題を緩和するための従来のやり方のうちの1つが、増分バックアップの使用である。増分バックアップ中、トランザクションログが、最終バックアップがとられてから行われた変更を識別するのに使用され、以前のバックアップ操作において考慮されなくてよい変更に関連付けられた内容のみが、次の増分バックアップ手順においてバックアップをとられることになる。

トランザクションログは、以前のデータベースバックアップまたはトランザクションログ記録バックアップ後に、データベースに対して行われる変更のみを記録するので、増分バックアップは、バックアップ操作の間の限られた期間中に行われるデータベース変更を記録するだけである。したがって、トランザクション記録バックアップまたは初期増分バックアップを引き受ける前に、完全なデータベースバックアップが必要とされる。

上述した手法の信頼性、セキュリティおよび一貫性に関連した、いくつかの問題がある。

信頼性に関しては、バックアップシステムの中心ノードが故障し得る可能性がある。バックアップトランザクションログに関連付けられた中心ノードまたは機械に問題がある場合、データ損失または損傷が起こる可能性があり、バックアッププロセス全体が失敗する可能性がある。

セキュリティおよび一貫性に関しては、トランザクションログに対するいかなる無認可変更も、必然的に、信用できない回復データにつながる場合がある。

したがって、従来のハードウェアデバイスおよび技術を使用するバックアップおよび回復システムに関連した、上述した問題のうちの少なくともいくつかを緩和するための、改良されたシステムおよび方法が必要とされている。

本発明の一態様によると、ブロックチェーンベースのバックアップおよび回復システムおよび方法が提供される。本発明の実施形態は、セキュアな、信頼できる、およびリアルタイム操作が可能な、ブロックチェーンベースのバックアップおよび回復システムを含む。

本発明の一態様によると、データストア、および複数のノードを含むブロックチェーンでの使用のためのデータバックアップおよび回復システムが提供され、このシステムは、1つまたは複数のプロセッサおよびメモリを含むサーバと、サーバ上で実行する記憶適合層であって、1つまたは複数のプロセッサは、ブロックチェーンおよびデータストアとデータ通信する、記憶適合層とを含み、記憶適合層は、データストア内に記憶されたデータの変更のサブセットに関連付けられたログを、ブロックチェーンに記憶する。

本発明の別の態様によると、システムは、データストアおよびブロックチェーンとデータ通信する回復適合層をさらに含むことができ、回復適合層は、ブロックチェーンから、記憶されたデータを取り出すことと、取り出された記憶データに対応するデータをデータストアに記憶することとを行うように構成される。

本発明の別の態様によると、データバックアップおよび回復の方法が提供される。この方法は、ユーザによってデータストアに記憶されたデータの変更のサブセットを、ログ中で追跡するステップと、ユーザを、ブロックチェーン上のアカウントにマッピングするステップと、アカウントの公開鍵を使ってログを暗号化するステップと、暗号化データをキャッシュに記憶するステップと、暗号化データをブロックチェーンに記憶するステップとを含む。

方法は、キャッシュからデータを取り出すステップと、ブロックチェーンアダプタを使って、データコンセンサスおよびグローバル検証のためのブロックチェーン中のブロックチェーンコントラクトをトリガするステップと、複数の前記ノードのうちの1つに、新たなデータ変更を記録するステップと、ブロックチェーン中でコンセンサス投票を実施するステップであって、前記新たなデータ変更が、ブロックチェーン中の変更履歴記録と衝突すると、コンセンサス投票は失敗し、衝突しない場合、前記新たなデータ変更をブロックチェーン中のブロックに記憶する、ステップとをさらに含み得る。

本発明のさらに別の態様によると、ブロックチェーンと、目標データストアと、コンピューティングデバイスとを含むリアルタイムデータ複製システムが提供される。コンピューティングデバイスは、ブロックチェーン上のすべてのブロックをリッスンするように適合されたブロックチェーンリスニングモジュールと、データ複製に関連した、ブロック上のトランザクションをフィルタリングするトランザクションフィルタと、フィルタリングされたトランザクションの内容を、目標データストア上での実行のためのデータ操作に変換するためのイベントジェネレータであって、トランザクション内容は、事前修正内容、修正された内容、および操作タイプを含む、イベントジェネレータと、実行後、目標データストアが、ブロックチェーンに対応するように修正されるようなデータ操作を実行するためのデータ回復モジュールとを含む。

本発明のさらに別の態様によると、ブロックチェーン用のデータバックアップおよび回復システムが提供され、このシステムは、データ適合層と、データ記憶システムとを含むサーバを含み、データ適合層はブロックチェーンに接続され、データ記憶システムは、1つまたは複数の記憶デバイスを有する分散型データストアを備え、データ適合層は、データ記憶システムとブロックチェーンとの間の通信を容易にするように適合される。データ適合層は、データ記憶システムにおけるデータ変更記録を監視するデータ変更監視モジュールと、監視される変更記録を標準データ変更記録にフォーマットするように適合されたデータ変換モジュールと、データをブロックチェーンに記録するためのブロックチェーンコントラクトとを含む。

図面は、単に例として、本発明の実施形態を示す。

本発明の実施形態を例示する、ブロックチェーンベースのバックアップおよび回復動作を使用するシステムの概略ブロック図である。 図1のシステムを使ってデータのバックアップをとるための例示的な手順の流れ図である。 本発明の例示的な実施形態におけるリアルタイムデータ同期手順を要約するフローチャートである。 図1のシステムを使ってデータを回復するための例示的な手順のフローチャートである。

本開示は、ブロックチェーンベースのバックアップおよび回復システムおよび方法について記載する。本発明の実施形態は、セキュリティ、信頼性、信用および/またはリアルタイム操作のための要件のうちの1つまたは複数を満足するように動作する、ブロックチェーンベースのバックアップおよび回復システムを含む。

本発明の様々な実施形態の記述が、以下で与えられる。本開示において、「備える」という用語とともに本明細書において使われるときの単語「a」または「an」の使用は、「1つ」を意味し得るが、「1つまたは複数」、「少なくとも1つ」および「1つまたは1つよりも多い」という意味とも一致する。単数形で表されるどの要素もまた、その複数形を包含する。複数形で表されるどの要素もまた、その単数形を包含する。本明細書で使用する「複数」という用語は、複数、たとえば、2つ以上、3つ以上、4つ以上、などを意味する。「上」、「下」、「上へ」、「下へ」、「垂直に」および「水平に」など、方向を示す用語が、相対参照のみを与える目的のために使われ、いかなる物品がどのように、使用中に位置決めされるべきであるか、またはアセンブリの中で、もしくは環境に相対して搭載されるべきであるかに対するいかなる限定も示唆することは意図していない。

「備える」、「有する」、「含む」、および「含める」という用語、ならびにそれらの文法的変異は、包括的またはオープンエンドであり、追加の、具陳されない要素および/または方法ステップを除外するものではない。組立て、使用または方法に関連して本明細書において使われる、「本質的に～からなる」という用語は、追加要素、方法ステップまたは追加要素と方法ステップの両方が存在し得るが、これらの追加は、具陳される組立て、方法、または使用が機能する様子に実質的に影響しないことを示す。組立て、使用、または方法に関連して本明細書において使われるときの「からなる」という用語は、追加要素および/または方法ステップの存在を除外する。

「ブロックチェーン」とは、コンピューティングデバイスの公共または私的ピアツーピアネットワークにおけるトランザクションを記録する、改竄防止の共有デジタル台帳である。台帳は、暗号学的ハッシュリンクされたブロックの、増大するシーケンシャルチェーンとして維持される。

ブロックチェーンのコンテキストにおける「ノード」とは、ブロックチェーンネットワーク上のデバイスである。デバイスは通常、プロセッサ可読命令をその上に有するメモリを含むプロセッサ可読媒体に相互接続されたプロセッサを有するコンピューティングデバイスである。

「第1の」、「第2の」、「第3の」などの用語は、説明目的のためにのみ使われ、相対的重要度を指示または含意するものと解釈してはならない。

本明細書の説明では、「搭載される」、「リンクされる」および「接続される」という用語は、別段に明示的に定義され、限定されない限り、広い意味で解釈されるべきであることにも留意されたい。たとえば、固定接続、もしくは組立て接続であってよく、または一体的に接続され、ハードワイヤードもしくはソフトワイヤードのいずれかであってよく、直接接続されるのであっても、媒介を通して間接的に接続されるのであってもよい。技術専門家にとって、本発明における上記用語の具体的な意味は、コンテキストにおいて理解されてよい。

本発明の実施形態を示す図面において、同じまたは同様の参照ラベルは、同じまたは同様の部分に対応する。本明細書の説明では、「複数」の意味は、別段に規定されていない限り、2つ以上を意味することに留意されたい。「上」、「下」、「左」、「右」、「内側」、「外側」、「前部」、「後部」、「先頭」、「末尾」という用語の方向または位置、すなわち図面に示す配向または位置関係は、指示されたデバイスまたは要素が特定の配向を有し、特定の配向で構築され、操作されなければならないことを指示または含意するのではなく、本発明を記載し、記述を簡素化する便宜のためにすぎず、したがって、本発明の限定として使われるわけではない。

I.システム概要
図1は、本発明の実施形態を例示する、ブロックチェーンベースのバックアップおよび回復動作を使用するシステムのブロック図を概略的に示す。システムは、データソース101、ログ追跡器モジュール102、イベントフィルタ103、イベントストア104、スマートコントラクトライター105、ブロックチェーン106、スマートコントラクト107、ノード108、回復管理モジュール109、目標データストア110、データ回復モジュール111、イベントジェネレータ112、トランザクションフィルタ113およびブロック転送114を含む。

記憶適合層115は、ログ追跡器モジュール102、イベントフィルタ103、イベントストア104、およびコントラクトライター105を含むように定義され得る。

回復適合層116は、データ回復モジュール111、イベントジェネレータ112、トランザクションフィルタ113およびブロック転送114を備え得る。

データソース101は、データソース101中のデータが変わると常に、変更ログを生成する。データソース101は、Oracle(登録商標)データベース、MySQL(登録商標)、マイクロソフトSQLサーバ(登録商標)、およびIBM DB2(登録商標)データベースなどのリレーショナルデータベース管理システム(RDBMS)であってよい。諒解され得るように、MySQL(登録商標)データベースはビン(bin)ログを生成し、Oracle(登録商標)データベースはやり直し(redo)ログを生成する。

ログ追跡器モジュール102は、ログに基づくデータ変更を記憶する。異なるデータソースに対して、異なるデータ追跡器プラグインが、データをキャプチャするのに使われる。たとえば、あるデータベースシステムでは、1つのデータ追跡器が、複製クライアントをエミュレートし、メインデータベースに接続してよく、メインデータベースは、トランザクションが成功したとき、トランザクションログをログ追跡器へ送ればよい。データソース101中のログをキャプチャした後、データ追跡器モジュール102は、データ変更を記憶するための内部構造またはフォーマットを生成する。

イベントフィルタ103は、構成設定に基づいてデータをフィルタリングする。すべてのデータが、ブロックチェーンへバックアップされる必要があるわけではない。イベントフィルタ103はしたがって、バックアップまたは回復および関連処理のための、あらかじめ定義された条件または選択基準に合致するデータを選択する。

イベントストア104は、イベントを一時的に記憶する。イベントストア104は、ブロックチェーンとデータソースとの間で速度を一致させる。データ変更の速度がブロックチェーン書込み速度よりも速い場合、データは、キャッシュまたはメッセージキューの中に一時的に記憶され、さらなる処理を待つ。キャッシュまたはメッセージキューは、このように、データソースにおける変更のデータレートを、ブロックチェーンへの書込みのデータレートに一致させるのを助ける。この場合、システムが破壊されたときであっても、キャプチャされたデータ変更は失われず、システムが回復されると処理を続けることができる。

スマートコントラクトライター105は、変更イベントを暗号化し、ブロックチェーンの中のコントラクトをトリガする。ライター105は、異なるブロックチェーンを一致させるためのプラグインでもある。

ブロックチェーン106は、複数の場所に展開され、コンセンサスのためのネットワークを生成する。この例示的な実施形態では、トランザクションのみが記憶され、したがって、ほぼすべてのブロックチェーンがサポートされ得る。

スマートコントラクト107は、ブロックチェーン106上で稼動するスマートコントラクトである。スマートコントラクト107は、変更されたデータを入力としてとり、変更データを提出したアカウントを認証し、特定の規則およびフォーマットとのデータ一致を調べる。ノードのほとんどがコンセンサスに同意した後、データは、トランザクションとしてブロックの中に記憶される。

ノード108は、ブロックチェーン106上のもう1つのノードであり、このブロックチェーンでは、トランザクションを含めているブロックが同期され、抽出され得る。

回復管理モジュール109は、データ回復プロセスを管理する。回復管理モジュール109は、データの正確なスナップショットへの回復またはソースデータと同期するためのリアルタイム回復を制御する。

目標データストア110は、データソース101において使われるタイプと同じタイプであっても、そうでなくてもよいデータストアである。たとえば、データソース101はOracle(登録商標)データベースであってよく、データストア110はMongoDB(登録商標)であってよい。同じデータタイプのデータストアを選んだ場合、所与のノードNode-N上のモジュールは、オリジナルデータソース101がクラッシュした場合にデータをデータソース101へ回復するために、Node-1において適用されてもよい。

本実施形態におけるデータ回復モジュール111は、目標データベースに合致するためのプラグインを含む。図に示す実施形態では、データ回復モジュール111は、一般的なJavaスクリプトオブジェクト表記(JSON)データを、特定のデータベース操作に変換する。たとえば、リレーショナルデータベースの場合、データ回復モジュール111は操作をSQLコマンドに変換し、NoSQLデータベースの場合、データ回復モジュール111は別の実行フォーマットを使う。

イベントジェネレータ112は、イベントデータを生成するのに使われる。トランザクションをフィルタにより除去した後、データが暗号化されるので、イベントを解読して、変更されたデータを得て、変更されたデータをJSONフォーマットに変換する必要がある。

トランザクションフィルタ113は、バックアップおよび回復動作に必要とされるトランザクションデータをフィルタにより除去する。1つのブロックが多くの種類のトランザクションを含める場合があり、適切なサブセットが、データバックアップ/回復トランザクションのためにフィルタリングされる。ブロックからトランザクションを抽出した後、回復側の関心に基づくイベントをフィルタにより除去することも必要である。たとえば、いくつかの目標ノードは、特定のテーブルに対する変更に関心があるだけであるが、他のノードは異なる関心を有し得る。

ブロック追跡器114は、ブロックチェーン106中の目標ブロックをキャプチャする。リアルタイム同期のために、追跡器114は、現在の同期ブロックから始め、チェーン中の最新ブロックで終わる。

II.バックアップ手順
図2は、図1に示すシステムなど、本発明の実施形態を例示するシステムを使って、データのバックアップをとるための例示的な手順200の流れ図を示す。以下で説明する手順200の各ステップは、プロセッサ実行可能命令を記憶するメモリに接続された、1つまたは複数のサーバコンピューティングデバイス上の1つまたは複数のプロセッサを含むシステム100によって実践されてよく、命令は、実行されると、プロセッサに、以下に具陳されるステップのうちの1つまたは複数を実施させる。

ステップ201において、データベース中でトランザクションが起こり、1つのデータが変更される。データベースを稼動することに関連付けられたプロセッサのうちの1つが、変更されたデータを記録し、ビンログまたはやり直しログの形のログを生成して、変更を記録する。

ステップ202において、バックアップサーバがデータベース複製クライアントをエミュレートし、データベースに接続する。データベースは、変更ログをバックアップサーバにコピーする。

ステップ203において、モニタがログにおける変更を監督する。

ステップ204において、ログは、未加工モードにある場合、通常、「before」データ、「after」データ、および変更タイプ(「挿入」、「消去」、または「更新」)を含める。

ステップ205において、リソースが制限され、データすべてがバックアップをとられる必要があるわけではない場合があるので、ユーザは、どのデータベース変更またはテーブル変更または列変更または行変更がブロックチェーン106にバックアップされるべきであるかを構成する。ログからデータを抽出した後、構成されたフィルタは、不要なデータをフィルタにより除去するために適用される。

ステップ206において、未加工データフォーマットは、異なるデータソース中では異なり得るので、データフォーマットを所望のもの(たとえば、JSONフォーマット)に変換するのに、アダプタが使われる。例示的なJSONフォーマットは、以下のように見える。
{"operator":"oliver", "source-db":"db1", "table":"salary", "operation":"insert", "before":[{"id":1, "name":"oliver", "salary":"1500.00"}, {"id":2, "name":"frank", "salary":"2000.00"}], "after":[{"id":1, "name":"oliver", "salary":"1510.00"}, {"id":2, "name":"frank", "salary":"2010.00"}]}

諒解され得るように、これは、元のSQLコマンドを記録するのではなく、データの変更のみを記録する。

ステップ207において、JSONイベントは、メッセージキューへ入れられる。ログ生成の速度は、ブロックチェーンコントラクトを呼び出すための速度に合わせて変動し得るので、メッセージキューは、変更されたデータをバッファリングするためのキャッシュとして働く。

ステップ208において、メッセージキューはJSONデータを一時的に記憶し、システムクラッシュの場合、セーブされていないデータは失われない。システムは、クラッシュから回復するとき、割込み点から継続する。

ステップ209において、メッセージキューからイベントが取り出される。コントラクトライターは、メッセージキューからJSONデータを取り出す。データの複数のセットがある場合、スマートコントラクトライターは、それらを取り出し、組み合わせて1つのJSON記録にする。

ステップ210において、ブロックチェーンを操作するために、アカウントが必要とされる。ログを用いて、データを操作するためのデータベースユーザを抽出し、そのユーザを構成ファイル中のブロックチェーンアカウントにマッピングすることができる。

ステップ211において、第三者がデータベース中の機密情報を読み取るのを防止するために、データが暗号化される。JSONデータは、アカウントの公開鍵を使って暗号化される。

ステップ212において、スマートコントラクトがブロックチェーン106中で呼び出される。入力は、暗号化されたJSONデータである。

ステップ213において、スマートコントラクトは、自動増加イベント識別子(ID)を生成する。ブロックチェーンでは、ブロックを生成するために時間が必要とされる。その期間中、複数のJSON記録が記憶される。1つのブロック中では、記録されたトランザクションの順序は保証されない。スマートコントラクトは、同じブロック内での順序を識別するための、各JSON記録についての自動増加順序IDを生成する。

ステップ214において、スマートコントラクトは、コンセンサスのために、ブロックチェーン中のほとんどのノード上で実行される。スマートコントラクトは、JSONデータのアカウントおよび正しさを検証する。ノードの過半数が同じ結果に投票した場合、スマートコントラクトの実行が成功する。

ステップ215において、スマートコントラクトの呼出しが成功した後、JSONデータは、スマートコントラクト入力としてブロックに記録される。

ステップ216において、生成されたブロックは、有効になる前に、ブロックチェーン中のコンセンサスを求めて再度投票される。

III.リアルタイムのデータ同期手順
図3は、本発明の例示的な実施形態におけるリアルタイムデータ同期プロセスを要約するフローチャートを示す。図示する実施形態では、ステップが以下に列挙されているプロセス300を使って、変更されたデータがリアルタイムで別のノードへ回復される。以下で説明する手順300の各ステップは、プロセッサ実行可能命令を記憶するメモリに接続された、1つまたは複数のサーバコンピューティングデバイス上の1つまたは複数のプロセッサを含むシステム100によって実践されてよく、命令は、実行されると、プロセッサに、以下に具陳されるステップのうちの1つまたは複数を実施させる。

ステップ301において、ブロックチェーン106は、暗号化されたJSONデータを含める新規ブロックを生成する。

ステップ302において、現在のブロック高さが、目標ブロックとして取得または指定され、同期ブロックは開始ブロックとして取得または指定される。

ステップ303において、プロセスは、チェーン中でブロックを監視し、開始ブロックから目標ブロックまでのブロック情報を取り出す。

ステップ304において、プロセスは、各ブロック中ですべてのトランザクションを抽出する。

ステップ305において、フィルタが適用される。ブロックチェーン上で稼動する他のサービスもあり得るので、このステップは、バックアップ/回復コントラクトによって生成されたトランザクションをフィルタにより除去する。

ステップ306において、プロセスは、トランザクションを解読し、アカウントの秘密鍵で平文JSONイベント記録を取り出す。ブロックチェーン106はすべてのノードによって見ることができるので、これにより、無認可ユーザがデータストレージ中の機密データを取り出すのを防止する。認可されたアカウントのみが、データにアクセスすることができる。

ステップ307において、プロセスは、スマートコントラクトによって生成された一意のIDに基づいてJSONイベントをソートする。複数のJSONイベントが同じブロック中に存在する場合、ブロックストレージ中での順序は、イベントの順序と同じでなくてよい。

ステップ308において、別のフィルタが適用される。回復された目標側は、データソースにおけるすべての変更に関心があるわけではない場合があるので、プロセスは、目標側が関心あるデータのみをフィルタにより除去する。

ステップ309において、プロセスは、JSONデータをデータ実行コマンドに変換するのに、プラグインを使う。異なる目標データストレージ用には、変更を適用するために異なるコマンドを使ってよい。

ステップ310において、プロセスは、異なるデータベース操作のために、JSONデータのタイプを調べる。

ステップ311において、「挿入」操作が、「after」データセクションの使用を引き起こして、目標ストアに挿入させる。

ステップ312において、「更新」操作が、JSONでのデータの「after」セクションの使用を引き起こして、ストア中の値を更新する。

ステップ313において、「消去」操作が、JSONでのデータの「before」セクションの使用を引き起こして、目標ストア中の一致する記録を見つけ、削除する。

ステップ314において、目標データ構造が、DDL(データ定義言語)操作のために、JSON記録における定義に従って変更される。

ステップ315において、現在のブロックが処理を終了された後、プロセスは、最新ブロックに達するまで、チェーン中の次のブロックへ進む。プロセスは次いで、ステップ303に進み、新規ブロックを処理し始める。

IV.回復手順
図4は、図1のバックアップおよび回復システムを使ってデータを回復するための例示的な手順のフローチャートである。以下で説明する手順400の各ステップは、プロセッサ実行可能命令を記憶するメモリに接続された、1つまたは複数のサーバコンピューティングデバイス上の1つまたは複数のプロセッサを含むシステム100によって実践されてよく、命令は、実行されると、プロセッサに、以下に具陳されるステップのうちの1つまたは複数を実施させる。

あるシナリオでは、目標データストアは、ブロック10,000にすでに同期されている。プロセスは、目標ストア状況をブロック8,000に回復する。プロセスは、ブロック10,000からブロック8,000までのブロックチェーン中の操作をすべて抽出し、データ変更を逆シーケンスで転じさせ、これは後退と呼ばれる。

別のシナリオでは、目標ストアはブロック8,000中にあり、状況をブロック10,000状況に移すことが必要である。プロセスは、ブロック8,000からブロック10,000までのブロックチェーン中の操作を抽出し、変更を順に適用し、これは前進と呼ばれる。

目標データストアに適用される操作は、これらの2つのシナリオにおいて異なる。

後退操作のためには、操作が「挿入」である場合、「after」値に一致するデータに対して、最初に「消去」が適用され、「消去」操作のためには、「before」値で「挿入」が適用される。

前進操作のために、操作は、JSONにおいて定義されるものと同じにされる。

例示的なプロセス400を、図4のフローチャートを用いて示し、以下で説明する。

ステップ401において、ブロックチェーンは、変更ログを順に含める。

ステップ402において、プロセスは、ローカルデータストアにおいて現在の同期ブロック高さを得る。

ステップ403において、プロセスは、現在の高さを、目標ブロック高さと照合する。同じである場合、目標状況にすでに達したことを意味し、抜け出せばよい。同じでない場合、プロセスは継続する。

ステップ404において、プロセスは、チェーン中のブロックを監視し、ブロック情報を取り出す。

ステップ405において、プロセスは、ブロック中のすべてのトランザクションを抽出する。

ステップ406において、プロセスは、バックアップ/回復スマートコントラクトによって生成されたトランザクションをフィルタにより除去する。

ステップ407において、プロセスは、ブロック中のトランザクションをアカウントの秘密鍵で解読する。

ステップ408において、同じブロック中で複数のイベントが起きた場合、プロセスは、スマートコントラクトによって生成された一意のIDを取り出し、このIDを使ってソートする。後退が必要とされる場合、プロセスは逆ソートを使うが、必要とされない場合は順ソートを使う。

ステップ409において、要求が関心をもつのを超えて、目標ストアが含めることができる場合、プロセスは、目標ストアが関心あるデータのみを取り出すために、フィルタを再度適用する。

ステップ410において、プロセスは、異なるデータストアタイプに基づいて、JSON記録をデータ実行コマンドに変換する。たとえば、リレーショナルデータベースはSQLコマンドに変換され、MongoDB/RedisはMongoまたはRedisコマンドに変換される。

ステップ411において、目標ブロックが現在のブロックよりも大きい場合、プロセスは前進するが、そうでない場合は後退する。プロセスは、JSONでのデータ変更操作のタイプを調べる。

ステップ412において、後退モードでは、操作が「挿入」である場合、プロセスは、「after」セクションと一致するデータで、目標ストアに「消去」アクションを適用する。

ステップ413において、後退モードでは、更新するために、プロセスは、データの「before」セクションを用いて、データを変更して元に戻す。

ステップ414において、後退モードでは、操作が「消去」である場合、プロセスは、JSONにおける「before」値で「挿入」アクションを適用する。

ステップ415において、データ構造が変わった場合、プロセスはデータ構造を変更して元に戻す。

ステップ416において、前進モードでは、プロセスはデータ変更操作を調べる。

ステップ417において、前進モードでは、プロセスは、JSONにおける「after」値で「挿入」を適用する。

ステップ418において、前進モードでは、プロセスは、JSONにおける「after」値で「更新」を適用する。

ステップ419において、前進モードでは、「before」値と一致するデータで「消去」を適用する。

ステップ420において、DDL用に、プロセスは、JSONにおいて定義される構造を変更する。

ステップ421において、プロセスは、チェーン中の次のブロックを得る。

以上、単に例として、本発明の実施形態を記載したが、添付の請求項によって定義される本発明は、例示的な実施形態の上記記述において説明した具体的な詳細によって限定されるものではなく、請求項の範囲から逸脱することなく、多くの変形および並べ替えが可能であることを理解されたい。

100 システム
101 データソース
102 ログ追跡器モジュール、データ追跡器モジュール
103 イベントフィルタ
104 イベントストア
105 スマートコントラクトライター、コントラクトライター
106 ブロックチェーン
107 スマートコントラクト
108 ノード
109 回復管理モジュール
110 目標データストア、データストア
111 データ回復モジュール
112 イベントジェネレータ
113 トランザクションフィルタ
114 ブロック転送、ブロック追跡器、追跡器
115 記憶適合層
116 回復適合層

ステップ411において、目標ブロックが現在のブロックよりも大きい場合、プロセスは前進するが、そうでない場合は後退する。プロセスは、JSONでのデータ変更操作のタイプを調べる。
後退モードでは、ステップ411aにおいて変更のタイプが判断される。

ステップ415において、データ構造が変わった場合、プロセスはデータ構造を変更して元に戻す。
ステップ412、413、414、または415の後、前のブロックがステップ411bにおいて取得され、方法はステップ403に戻る。

Claims (38)

1. データストア、および複数のノードを含むブロックチェーンでの使用のためのデータバックアップおよび回復システムであって、
   a)1つまたは複数のプロセッサおよびメモリを備えるサーバと、
   b)前記サーバ上で実行する記憶適合層であって、前記1つまたは複数のプロセッサは、前記ブロックチェーンおよび前記データストアとデータ通信する、記憶適合層と
   を備え、
   前記記憶適合層は、前記データストア内に記憶されたデータの変更のサブセットに関連付けられたログを前記ブロックチェーンに記憶する、システム。
2. 前記データストアおよび前記ブロックチェーンとデータ通信する回復適合層をさらに備え、
   前記回復適合層は、前記ブロックチェーンから記憶されたデータを取り出すことと、
   前記取り出した記憶データに対応するデータを前記データストアに記憶することと
   を行うように構成される、請求項1に記載のシステム。
3. 前記記憶適合層は、
   a)前記ログに基づいてデータ変更を記憶するログ追跡器モジュール、
   b)記憶されるべきイベントに関連付けられた前記ログのサブセットをフィルタリングするためのイベントフィルタ、
   c)フィルタリングされたイベントのログを記憶するためのイベントストア、および
   d)前記フィルタリングされたイベントに関連付けられたデータを前記ブロックチェーンに書き込むためのスマートコントラクトライター、
   のうちの1つまたは複数を備える、請求項1に記載のシステム。
4. 前記回復適合層は、
   a)データを前記データストアへ回復するためのデータ回復モジュール、
   b)イベントジェネレータ、
   c)トランザクションフィルタ、および
   d)ブロック転送モジュール、
   のうちの1つまたは複数を備える、請求項2に記載のシステム。
5. 前記データストアをさらに備える、請求項1に記載のシステム。
6. 前記データストアは、1つまたは複数のデバイスの間に分散される、請求項1に記載のシステム。
7. 前記データストアはリレーショナルデータベース管理システム(RDBMS)である、請求項1に記載のシステム。
8. 前記データストアは、MySQL(登録商標)データベースであり、
   前記ログはビンログを含む、請求項1に記載のシステム。
9. 前記データストアはOracle(登録商標)データベースであり、
   前記ログはやり直しログを含む、請求項1に記載のシステム。
10. 前記データストアはNoSQL(登録商標)データベースである、請求項1に記載のシステム。
11. 前記ブロックチェーンは、複数の異なるタイプのブロックチェーンのうちの1つであり、
    対応するブロックチェーンアダプタプラグインモジュールが、前記記憶適合層によって、前記ブロックチェーンとインターフェースするのに使われる、請求項1に記載のシステム。
12. データバックアップおよび回復の方法であって、
    a)ユーザによって、データストアに記憶されたデータの変更のサブセットをログ中で追跡するステップと、
    b)前記ユーザを、ブロックチェーン上のアカウントにマッピングするステップと、
    c)前記アカウントの公開鍵を使って前記ログを暗号化するステップと、
    d)暗号化データをキャッシュに記憶するステップと、
    e)前記暗号化データを前記ブロックチェーンに記憶するステップと
    を含む方法。
13. 前記ブロックチェーンは複数のノードを含み、前記方法は、
    a)前記キャッシュから前記データを取り出すステップと、
    b)前記ブロックチェーンのアダプタを使って、データコンセンサスおよびグローバル検証のための前記ブロックチェーン中のブロックチェーンコントラクトをトリガするステップと、
    c)前記複数のノードのうちの1つに、新たなデータ変更を記録するステップと、
    d)前記ブロックチェーン中でコンセンサス投票を実施するステップであって、
    i)前記新たなデータ変更が、前記ブロックチェーン中の変更履歴記録と衝突すると、前記コンセンサス投票は失敗し、
    ii)衝突しない場合、前記新たなデータ変更を前記ブロックチェーン中のブロックに記憶する、ステップと
    をさらに含む、請求項12に記載の方法。
14. 前記新たなデータ変更を前記ブロックに記憶する前記ステップは、ブロックチェーンスマートコントラクトを使って遂行される、請求項13に記載の方法。
15. 複数のトランザクションに対応する複数の変更イベントが前記ブロックに記録されると、前記トランザクションのシーケンスを識別するために、前記ブロックチェーンスマートコントラクトによって一意の順序IDが生成される、請求項14に記載の方法。
16. 前記キャッシュはメッセージキューである、請求項12に記載の方法。
17. 前記ログを暗号化する前記ステップに先立って、前記ログを標準フォーマットに変換するステップをさらに含む、請求項12に記載の方法。
18. 前記変更のデータレートを、前記ブロックチェーンに書き込むデータレートに一致させるステップをさらに含む、請求項12に記載の方法。
19. 一致させる前記ステップは、システムクラッシュの場合におけるデータ損失を防止する、請求項18に記載の方法。
20. a)ブロックチェーンと、
    b)目標データストアと、
    c)コンピューティングデバイスと
    を備えるリアルタイムデータ複製システムであって、前記コンピューティングデバイスは、
    i)前記ブロックチェーン上のすべてのブロックをリッスンするように適合されたブロックチェーンリスニングモジュールと、
    ii)データ複製に関連した、前記ブロック上のトランザクションをフィルタリングするトランザクションフィルタと、
    iii)前記フィルタリングされたトランザクションの内容を、前記目標データストア上での実行のためのデータ操作に変換するためのイベントジェネレータであって、前記トランザクションの内容は、事前修正内容、修正された内容、および操作タイプを含む、イベントジェネレータと、
    iv)実行後、前記目標データストアが、前記ブロックチェーンに対応するように修正されるような前記データ操作を実行するためのデータ回復モジュールと
    を備える、システム。
21. 前記データ操作を、前記目標データストア上での実行のための1つまたは複数のデータ実行コマンドに変換する目標データストアアダプタをさらに備える、請求項20に記載のシステム。
22. 同じブロック中の複数のトランザクション向けに、前記複数のトランザクションは、スマートコントラクトによって生成された、関連付けられた順序IDでソートされ、順に実行される、請求項20に記載のシステム。
23. 前記コンピューティングデバイスは、不要なイベントをフィルタにより除去し、そうすることによって、前記不要なイベントは、前記目標データストアの修正を生じない、請求項20に記載のシステム。
24. 前記フィルタリングは、前記ブロックチェーン内の前記トランザクションの特徴値に基づく、請求項20に記載のシステム。
25. 前記ブロックチェーンは、複数の異なるタイプのブロックチェーンのうちの1つであり、
    対応するブロックチェーンアダプタが前記ブロックチェーンリスニングモジュールによって使われる、請求項20に記載のシステム。
26. 前記コンピューティングデバイスは、前記フィルタリングされたトランザクションの内容を復号するのに秘密鍵を使う、請求項20に記載のシステム。
27. 前記コンピューティングデバイスは、前記目標データストアを、前記ブロックチェーンの所望のブロックロケーションに対応するように後退または前進させる、請求項20に記載のシステム。
28. ブロックチェーン用のデータバックアップおよび回復システムであって、
    データ適合層を備えるサーバであって、前記データ適合層は、
    データ記憶システムにおけるデータ変更記録を監視するデータ変更監視モジュールと、
    前記監視される変更記録を標準データ変更記録にフォーマットするように適合されたデータ変換モジュールと、
    データを前記ブロックチェーンに記録するためのブロックチェーンコントラクトと
    を備える、サーバと、
    データ記憶システムと
    を備え、
    前記データ適合層は前記ブロックチェーンに接続され、
    前記データ記憶システムは、1つまたは複数の記憶デバイスを有する分散型データストアを備え、
    前記データ適合層は、前記データ記憶システムと前記ブロックチェーンとの間の通信を容易にするように適合される、システム。
29. 前記データ適合層は、
    前記監視される変更記録を標準データ変更記録にフォーマットするように適合されたデータ変換モジュールをさらに備える、請求項28に記載のシステム。
30. 前記データ適合層は、前記データ変更記録をキャッシュするように適合されたデータキャッシュモジュールをさらに備える、請求項29に記載のシステム。
31. 前記データ適合層は、前記ブロックチェーンコントラクトをアクティブ化するためのブロックチェーン書込みモジュールをさらに備える、請求項30に記載のシステム。
32. 前記データ適合層は、前記ブロックチェーン上のすべてのトランザクション情報を監視し、前記データバックアップおよび回復システムに関連した特定のトランザクションをフィルタリングするブロックチェーン監視モジュールをさらに備える、請求項31に記載のシステム。
33. 前記データ適合層は、前記ブロックチェーン上に記録されたトランザクション記録をデータストアに回復するための回復モジュールをさらに備える、請求項32に記載のシステム。
34. 前記回復モジュールは、前記ブロックチェーンに対応する状態まで、前記データストアに適合される、請求項33に記載のシステム。
35. 前記データ適合層を、1つまたは複数のタイプのデータソースのうちのそれぞれの1つに適合させる1つまたは複数のプラグイン構成要素をさらに備える、請求項33に記載のシステム。
36. 前記データストアから前記データ変更記録を遮るデータ監視モジュールをさらに備える、請求項33に記載のシステム。
37. 前記データストアは、リレーショナルデータベース、非リレーショナルデータベース、ファイルシステムのうちの1つまたは複数を含む、請求項33に記載のシステム。
38. 前記データ変更記録の各々は標準フォーマットにフォーマットされる、請求項33に記載のシステム。

Images