自己管理型配置のバックアップメソッド

項目一覧

MongoDB Cloud Manager または Ops Manager を使用したバックアップ

基礎となるデータファイルのコピーによるバックアップ
次を使用したバックアップ: mongodump

MongoDB を本番環境に配置する場合、データ損失イベントが発生した際にバックアップをキャプチャして復元するための戦略を立てる必要があります。

このページでは、の自己管理型配置のバックアップ方法について説明します。

でホストされている配置のバックアップMongoDB Atlas メソッドの詳細については、「データのバックアップ、復元、アーカイブ」を参照してください。

MongoDB Cloud Manager または Ops Manager を使用したバックアップ

MongoDB Cloud Manager は、MongoDB 用のホスティング型バックアップ、モニタリング、オートメーションサービスです。MongoDB Cloud Manager では、MongoDB レプリカセットおよびシャーディングされたクラスターのバックアップと復元をグラフィカルユーザーインターフェースで行えます。

MongoDB Cloud Manager

MongoDB Cloud Managerは、MongoDB 配置のバックアップと復元をサポートしています。

MongoDB Cloud Manager は、MongoDB の配置の oplog データを読み取ることで、MongoDB のレプリカセットとシャーディングされたクラスターを継続的にバックアップします。また、設定された間隔でデータのスナップショットを作成し、MongoDB のレプリカセットとシャーディングされたクラスターのポイントインタイムリカバリを提供します。

Tip

シャーディングされたクラスターのスナップショットは、他の MongoDB バックアップメソッドでは実現が困難です。

MongoDB Cloud Manager Backup を使用するには、MongoDB Cloud Manager に登録してください。MongoDB Cloud Manager のドキュメントについては、MongoDB Cloud Manager に関するドキュメントを参照してください。

Ops Manager

MongoDB Ops Managerを使用すると、 MongoDBサブスクリプションは、自分のインフラストラクチャ上でMongoDB Cloud Managerを強化する同じコアソフトウェアをインストールして実行できます。 MongoDB Ops Managerは、 MongoDB Cloud Managerと同様の機能を持ち、Enterprise Advanced サブスクリプションで利用できるオンプレミスソリューションです。

Ops Manager の詳細については、[MongoDB Enterprise Advanced] ページと「Ops Manager マニュアル」を参照してください。

基礎となるデータファイルのコピーによるバックアップ

注意

AES256-GCM を使用して暗号化されたストレージエンジンに関する検討事項

AES256-GCM 暗号化モードを使用して暗号化されたストレージエンジンの場合、AES256-GCM はすべてのプロセスについて、キーとユニークなカウンターブロック値を使用することを求めます。

AES256-GCM 暗号で構成されたストレージエンジンの場合:

ホットバックアップからの復元
バージョン 4.2 以降、「ホット」バックアップ（mongod が実行されている状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出し、データベースキーを自動的にロールオーバーして、IV（Initialization Vector: 初期化ベクトル）の再利用を回避できるようになりました。
コールドバックアップからの復元
ただし、「コールド」バックアップ（mongod が実行されていない状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出できず、IV を再利用すると、機密性と整合性における保証が無効になります。
バージョン 4.2 以降では、コールドファイルシステムスナップショットから復元した後にキーが再利用されるのを回避するため、MongoDB に新しいコマンドラインオプション --eseDatabaseKeyRollover が追加されました。--eseDatabaseKeyRollover オプションを使用して起動すると、mongod インスタンスは AES256-GCM 暗号で構成されたデータベースキーをロールオーバーして終了します。

通常、MongoDB Enterprise 向けのファイルシステムベースのバックアップを使用する際は、可能な限り「ホット」バックアップ機能を使用します。

ファイルシステムのスナップショットによるバックアップ

MongoDB の配置のバックアップを作成するには、MongoDB の基礎データファイルのコピーを作成します。

MongoDBがデータファイルを保存しているボリュームがポイントインタイムスナップショットをサポートしている場合、このスナップショットを使ってMongoDBシステムのバックアップを正確な時点で作成できます。ファイルシステムスナップショットはオペレーティングシステムのボリュームマネージャーの機能であり、 MongoDBに固有のものではありません。ファイルシステムスナップショットでは、オペレーティングシステムがボリュームのスナップショットを取得し、データバックアップのベースラインとして使用します。スナップショットの仕組みは、基礎となるストレージシステムによって異なります。例、 Linuxでは、論理ボリュームマネージャー（LVM）はスナップショットを作成できます。同様に、Amazon の EC 2用 EBSストレージシステムもスナップショットをサポートしています。

実行中の mongod プロセスの正確なスナップショットを取得するには、ジャーナリングを有効にし、ジャーナルを他の MongoDB データファイルと同じ論理ボリューム上に配置する必要があります。ジャーナリングを有効にしないと、スナップショットの一貫性や有効性は保証されません。

シャーディングされたクラスターの一貫したスナップショットを取得するには、バランサーを無効にし、すべてのシャードとコンフィギュレーションサーバーからほぼ同じタイミングでスナップショットをキャプチャする必要があります。シャーディングされたクラスターをバックアップするには、「データベースダンプを使用して自己管理型シャーディングされたクラスターをバックアップする」を参照してください。

LVM を使用してスナップショットを作成する手順について詳しくは、「ファイルシステムスナップショットを使用した自己管理型配置のバックアップと復元」および「ファイルシステムスナップショットを使用した自己管理型シャーディングされたクラスターのバックアップ」を参照してください。

`cp` または `rsync` を使用したバックアップ

ストレージシステムがスナップショットをサポートしていない場合、cp、rsync、または同様のツールを使用してファイルを直接コピーできます。複数のファイルのコピーはアトミック操作ではないため、ファイルをコピーする前に mongod への書き込みをすべて停止する必要があります。停止しない場合、無効な状態でファイルがコピーされます。

基礎となるデータをコピーして作成されたバックアップは、レプリカセットのポイントインタイムリカバリをサポートしていないため、シャーディングされた大規模なクラスターでは管理が困難です。また、これらのバックアップにはインデックスに加え、基礎となるストレージパディングとフラグメンテーションの重複が含まれるため、サイズが大きくなります。対照的に、mongodump のバックアップはサイズが小さくなります。

次を使用したバックアップ: `mongodump`

mongodumpは MongoDB database からデータを読み取り、 mongorestoreツールが MongoDB database にデータを入力するために使用できる高忠実度 BSON ファイルを作成します。 mongodumpとmongorestoreは、小規模な MongoDB 配置のバックアップと復元のための簡単で効率的なツールですが、大規模なシステムのバックアップを取得するには理想的ではありません。

mongodumpとmongorestoreは実行中のmongodプロセスに対して動作し、基礎となるデータファイルを直接操作できます。デフォルトでは、 mongodumpはローカルデータベースの内容をキャプチャしません。

mongodump はデータベース内のドキュメントのみをキャプチャします。結果として得られるバックアップはスペース効率に優れていますが、mongorestore または mongod は、データ復元後にインデックスを再構築する必要があります。

MongoDB インスタンスに接続すると、 mongodumpはmongodのパフォーマンスに悪影響を与える可能性があります。データがシステムメモリよりも大きい場合、クエリによってワーキングセットのメモリが不足し、ページフォールトが発生します。

mongodumpが出力をキャプチャしている間も、アプリケーションはデータの変更を続けることができます。レプリカセットの場合、は、操作中に発生するmongodump --oplogoplog エントリに含める mongodumpオプションを提供します。これにより、対応するmongorestore操作で、取得された oplog を再生できるようになります。 --oplogで作成されたバックアップを復元するには、 mongorestoreと--oplogReplayオプションを併用します。