MongoDB を本番環境に導入する場合は、データ損失を防ぐためのバックアップと復元の戦略を用意します。
このページでは、自己管理型配置のバックアップ方法について説明します。
MongoDB Atlas でホストされている配置のバックアップ メソッドの詳細については、「データのバックアップ、復元、アーカイブ 」を参照してください。
MongoDB Cloud Manager または Ops Manager を使用したバックアップ
MongoDB Cloud Managerは、 MongoDB用のホスティング型バックアップ、モニタリング、オートメーションサービスです。MongoDB Cloud Managerでは、レプリカセット および シャーディングされたクラスター のバックアップと復元をグラフィカル ユーザー インターフェースで行えます。
MongoDB Cloud Manager
重要
MongoDB Cloud Manager を使用してレプリカセットとシャーディングされたクラスターをバックアップするには、MongoDB Enterprise Server を使用する必要があります。詳細については、「MongoDB Enterprise のインストール」を参照してください。
MongoDB Cloud Manager は、 MongoDBデプロイのoplogデータを読み取ることで、レプリカセットとシャーディングされたクラスターをバックアップします。MongoDB Cloud Manager は設定された間隔でスナップショットを作成し、ポイントインタイムリカバリを提供します。
Tip
シャーディングされたクラスターのスナップショットは、他の MongoDB バックアップ メソッドでは実現が困難です。
MongoDB Cloud Manager Backup を使用するには、MongoDB Cloud Manager に登録してください。MongoDB Cloud Manager のドキュメントについては、MongoDB Cloud Manager に関するドキュメントを参照してください。
Ops Manager
Ops Manager を使用すると、 MongoDBサブスクリプションは自分のインフラストラクチャ上にMongoDB Cloud Managerと同じバックアップソフトウェアをインストールして実行できます。Ops Manager は Enterprise Advanced サブスクリプションで利用できます。
Ops Manager の詳細については、[MongoDB Enterprise Advanced] ページと「Ops Manager マニュアル」を参照してください。
基礎となるデータ ファイルのコピーによるバックアップ
注意
AES256-GCM を使用して暗号化されたストレージ エンジンに関する検討事項
AES256-GCM暗号化モードを使用する暗号化ストレージ エンジンの場合、 AES256-GCMはすべてのプロセスについて、キーと一意のカウンター ブロック値を使用することを求めます。
AES256-GCM 暗号で構成されたストレージ エンジンの場合:
- ホット バックアップからの復元
mongodが を実行中いる間に「ホット」バックアップで取得したファイルから復元すると、 MongoDB はスタートアップ時に「汚染された」キーを検出し、データベースキーを自動的にロールオーバーして、IV（Initialization Vector: 初期化ベクトル）の再利用を回避します。
- コールド バックアップからの復元
ただし、
mongodがを実行中いないときに「コールド」バックアップで取得したファイルから復元すると、 MongoDB はスタートアップ時に「汚染された」キーを検出せず、 IV の再利用によって機密性と整合性の保証が無効になります。コールド ファイルシステム スナップショットから復元した後にキーが再利用されるのを回避するため、 MongoDB に新しいコマンドライン オプション
--eseDatabaseKeyRolloverが追加されました。--eseDatabaseKeyRolloverオプションを使用して起動すると、mongodインスタンスはAES256-GCM暗号で構成されたデータベースキーをロールオーバーして終了します。
MongoDB Enterprise向けのファイルシステム ベースのバックアップを使用する場合は、「ホット」バックアップ機能を使用します。
ファイルシステムのスナップショットによるバックアップ
MongoDB がデータファイル を保存しているボリュームが点インタイム スナップショットをサポートしている場合は、それらのスナップショットを使って正確な時点でバックアップを作成します。ファイルシステム スナップショットはオペレーティング システムのボリューム マネージャーの機能であり、 MongoDBに固有のものではありません。オペレーティング システムは、ボリュームのスナップショットを取得し、バックアップのベースラインとして使用します。スナップショットの仕組みは、基礎となるストレージシステムによって異なります。例、 Linuxでは、論理ボリューム マネージャー（LVM）はスナップショットを作成できます。同様に、Amazon の EC2 用 EBSストレージシステムもスナップショットをサポートしています。
実行中の mongod プロセスの正確なスナップショットを取得するには、ジャーナリングを有効にし、ジャーナルを他の MongoDB データファイルと同じ論理ボリューム上に配置する必要があります。
シャーディングされたクラスターの一貫したスナップショットを取得するには、バランサーを無効にし、すべてのシャードとコンフィギュレーションサーバーからほぼ同じタイミングでスナップショットをキャプチャする必要があります。 シャーディングされたクラスターをバックアップするには、「データベース ダンプを使用して自己管理型シャーディングされたクラスターをバックアップする 」を参照してください。
LVMを使用してスナップショットを作成する完全な手順について詳しくは、「ファイルシステム スナップショットを使用した自己管理型配置のバックアップ」および「ファイルシステム スナップショットを使用したシャーディングされたクラスターのバックアップ」を参照してください。
cp または rsync を使用したバックアップ
ストレージ システムがスナップショットをサポートしていない場合、cp、rsync、または同様のツールを使用してファイルを直接コピーできます。複数のファイルのコピーはアトミック操作ではないため、ファイルをコピーする前に mongod への書き込みをすべて停止する必要があります。
基礎となるデータをコピーして作成されたバックアップは、レプリカセットのポイントインタイムリカバリをサポートしていないため、シャーディングされた大規模なクラスターでは管理が困難です。また、これらのバックアップにはインデックスに加え、基礎となるストレージ パディングとフラグメンテーションの重複が含まれるため、サイズが大きくなります。対照的に、mongodump のバックアップはサイズが小さくなります。
次を使用したバックアップ: mongodump
mongodump と mongorestore は、小規模の MongoDB 配置のバックアップと復元のためのツールです。詳細については、 「MongoDB ツールを使用したバックアップと復元」を参照してください。
シャーディングされたクラスターをバックアップするには、「データベース ダンプを使用して自己管理型シャーディングされたクラスターをバックアップする 」を参照してください。
バックアップ方法を比較する
次の表では、オンプレミス デプロイメントのバックアップ方法を比較しています。
バックアップに関する考慮事項 | Cloud Manager/Ops Manager | ファイルシステム スナップショット | |
|---|---|---|---|
バックアップRTO | 低/スナップショットの保存タイプに依存 | 低 | 高 |
バックアップの RPO | 低 | 高 | 高 |
バックアップ ストレージ コスト | 低/スナップショットの保存タイプに依存 | 平均 | 高 |
バックアップを管理するための従業員時間 | なし/スナップショットの保存タイプに依存 | 高 | 高 |
継続的なポイントインタイム バックアップと復元 | はい | No | No |
復元の複雑性 | 低（配置がオートメーション化されている場合） | 高（シャーディングされたクラスターに対して） | 低 |
シャーディングされたクラスターのバックアップの複雑性 | 低 | 高、追加手順が必要です | 高、追加手順が必要です |
ソースであるシャーディングされたクラスターの配置に対するバックアップの影響 | 低 | 高、書込みロックが必要です | 高、書込みロックが必要です |
シャーディングされたクラスターのバックアップにおける整合性 | 保証されます | 保証されていません。 | 保証されていません。 |
増分バックアップ | はい、日次の増分バックアップと週次のフル バックアップ | ストレージとツールに依存 | No |
バックアップの範囲を定義 | 有効、名前空間フィルタリングを使用 | No | はい |