Docs Menu
Docs Home
/
MongoDBマニュアル
/ /

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

項目一覧

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

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

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

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

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

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 に関するドキュメントを参照してください。

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 では、論理ボリューム マネージャー( Logical Volume Manager: LVM)を使用してスナップショットを作成できます。同様に、Amazon の EC2 用 EBS ストレージ システムもスナップショットをサポートしています。

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

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

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

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

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

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

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

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

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

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

ただし、レプリカセットについては、 MongoDB Cloud ManagerまたはMongoDB Ops Managerを検討してください。

シャーディングされたクラスターをバックアップするには、「データベース ダンプを使用して自己管理型シャーディングされたクラスターをバックアップする 」を参照してください。

注意

mongodumpmongorestoreをシャーディングされたクラスターのバックアップ戦略として使用するには、「データベース ダンプを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。

シャーディングされたクラスターではバックアップと復元に次のいずれかの連携的なプロセスも利用できます。これによりシャード間のトランザクションはアトミック性が継続的に保証されます。

詳細については、「 MongoDB ツールを使用した自己管理型配置のバックアップと復元 」および「 データベース ダンプを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。

戻る

Cluster Parameters