警告
データダンプと復元でのフィールドの $ プレフィックスとの競合
MongoDB 5.0以降、ドキュメントフィールド名の前にドル記号（ $ ）を付けることができます。 ただし、コレクションのオプションのプレフィックスとしてドル記号が付いているフィールド名では、 mongodumpとmongorestoreは動作しません。
MongoDB 拡張 JSON（v 2 ）は、type wrapper と、type wrapper と同じ名前を持つフィールドを区別できません。 対応する BSON 表現に$プレフィックス付きキーが含まれる可能性がある場合は、拡張 JSON 形式を使用しないでください。 DBRefsメカニズムは、この一般ルールの例外です。
動作
一致するサーバー バージョンへの復元
mongorestoreを使用してmongodumpによって作成されたデータファイルを読み込む場合、ソース配置と宛先配置の MongoDB バージョンは次のいずれかである必要があります。
同一メジャー バージョン。
同一機能互換バージョン。
たとえば、ダンプの作成元が 4.4 を実行中のMongoDB 配置であった場合、復元先となる MongoDB 配置でも、バージョン 4.4 を実行しているか、FCV を 4.4 に設定している必要があります。
機能の互換性バージョンを変更するには、 setFeatureCompatibilityVersionを参照してください。
注意
mongodump から生成された BSON ファイルは、復元元と同じかそれ以降のバージョンを実行中の MongoDB 配置に復元できます。ただし、新しいバージョンの配置へのファイルの復元は、配置のアップグレード方法としては推奨されていません。配置のアップグレード方法については、アップグレードのドキュメントを参照してください。
この保証は、メタデータ、アーカイブ、または oplog リプレイ ファイルには適用されません。復元元と復元先の配置バージョンが異なる状態でこれらのファイルを復元しようとすると、mongorestore プロセスに失敗したり、サイレント障害が発生したり、メタデータが破損したりする可能性があります。
さらに、データファイルをロードするには、 mongorestoreのバージョンが、データファイルの作成に使用したmongodumpのバージョンと同じであることを確認してください。 たとえば、 mongodumpバージョン100.18.0を使用してダンプを作成した場合、それを復元するにはmongorestoreバージョン100.18.0を使用します。
挿入のみ
mongorestore では、新しいデータベースを作成することも、既存のデータベースにデータを追加することもできます。 ただし、 mongorestoreは挿入のみを実行し、更新は実行しません。 既存のデータベースとコレクションにドキュメントを復元し、既存のドキュメントの_idフィールドの値が復元するドキュメントと同じ場合、 mongorestoreはそれらのドキュメントを上書きしません。
ドキュメントの順序
デフォルトでは、 mongorestoreはランダムな順序でドキュメントを挿入できます。 復元プロセス中にドキュメント順序を維持するには、 --maintainInsertionOrderを使用します。
インデックスの再構築
mongorestore は、データを復元した後、 mongodumpによって記録されたインデックスを再作成します。
注意
featureCompatibilityVersion（FCV）が "4.0" またはそれ以前に設定されているMongoDBインストールの場合、既存のドキュメントのインデックスキーが制限を超えると、インデックスの作成がエラーになります。
この問題を回避するには、 ハッシュされたインデックス を使用するか、代わりに計算された値をインデックス化することを検討してください。 データを復元した後にインデックスの問題を解決するには、 mongodインスタンスのfailIndexKeyTooLongパラメータを false に設定して、ターゲット データベースのデフォルトのインデックス キーの長さ検証を無効にします。
system.profileコレクションを除外する
mongorestore は、 system.profileコレクション データを復元しません。
FIPS
mongorestore は 、FIPS モードを使用するように構成さ れたmongod /mongos への FIPS 準拠の接続を自動的に作成します。
書込み保証 (write concern)
--writeConcernオプションと--uri接続stringオプションの両方で書込み保証（write concern）を指定した場合、 --writeConcernの値が URI stringで指定された書込み保証（write concern）よりも優先されます。
時系列コレクション
MongoDB 5.0以降では、 mongorestoreを使用して 時系列コレクションを復元できます。 詳細については、「時系列コレクションの復元 」を参照してください。
時系列形式の変換全体での oplog 再生
MongoDB 8.x とMongoDB 9.0 では、時系列コレクションをさまざまな形式で保存します。
MongoDB 8.x では、時系列コレクションはビュー と別の
system.buckets.<collection>コレクションで構成されています。MongoDB 9.0 以降では、時系列コレクションは単一のコレクションです。
setFeatureCompatibilityVersionこの境界全体で機能の互換性バージョン（FCV）を変更するには、 を使用して、サーバーは各時系列コレクションを新しい FCV に一致する形式に変換します。サーバーはすべての変換をoplogに記録します。
各変換により、バケット書込みの対象となる名前空間も system.buckets.<collection> から <collection> に変更されます。変換の前に記録された oplog のエントリは、それに続くコレクション形式と一致しません。
その結果、mongorestore は変換にまたがるoplog範囲を再生できません。変換の両方の側のエントリを個別の範囲として復元し、2 回の復元の間にターゲットデプロイの FCV を変更します。
変換に先行するoplogエントリを再生します。
--oplogLimit変換の前にリプレイを停止するには、 を使用します。
ターゲット配置の FCV を変更します。
setFeatureCompatibilityVersionターゲットで を実行し、変換を生成したのと同じ FCV を同じ方向に変更します。
ターゲットの FCV の変更が必要です。 mongorestore は FCV を変更せず、変換全体で名前空間を書き換えません。ターゲットが両方の復元で 1 つの FCV に維持されている場合、2 番目の範囲のエントリは、ターゲットのコレクション形式と一致しない名前空間を付けます。その後復元は失敗します。
Database Tools100.18.0 以降、 はmongorestore --oplogReplay中に発生すると失敗し、変換に名前を付けるメッセージを表示します。 Database Toolsの以前のバージョンでは、代わりに不明なoplogコマンドが報告されています。
復元できないダンプが生成されないようにするには、 の実行中に FCVmongodump --oplog を変更しないでください。 を使用して自分でoplogmongodump --db=local --collection=oplog.rs --oplogFilemongodumpを取得し、 で再生すると、 は FCV の変更を検出できないため、復元する範囲が変換にまたがらないことを確認してください。
Atlas の無料クラスターとフレキシブルなクラスターでの の使用mongorestore
無料クラスター（M0）および Flex クラスターでは、次の制限が適用されます。
adminデータベースではmongorestoreを実行できません。 デフォルトでは、mongorestoreはこのデータベースをスキップします。--dbオプションを使用して宛先データベースをadminに設定すると、プログラムはエラーを返します。mongorestoreプログラムでは、次のオプションは使用できません。
クラッシュの動作
mongorestoreがクラッシュすると、システムが一貫性のない状態になり、データの一部のみが復元されて、すべてが復元されない可能性があります。クラッシュ後は、復元されたデータを削除し、プロセスを最初から再実行します。
注意
ターゲット クラスターのロールバック
復元プロセス中にクラスターがロールバックした場合は、復元されたデータまたはインポートされたデータをすべて削除し、プロセスを最初からやり直してください。 詳細については、 ロールバックに関するドキュメント を参照してください。
必要なアクセス権
アクセス制御 が有効になっている MongoDB 配置にデータを復元する場合、データに コレクション データを含まずにrestoresystem.profile を オプションなしで実行する 場合 、 ロールはバックアップからデータを復元するために必要な特権を提供します。mongorestore --oplogReplay。
注意
対象クラスターが MongoDB Atlas クラスターの場合は、代わりに Atlas admin ロールが必要です。MongoDB Atlas では、個別の restore ロール、権限、または権限アクションは提供されていません。詳細については、「データベースユーザーの設定」を参照してください。
バックアップ データにsystem.profileコレクション データが含まれている場合や--oplogReplayオプションを使用してmongorestoreを実行する場合は、追加の権限が必要です。
| バックアップ データに 組み込みロール |
|
|
バックアップ戦略での使用
スタンドアロン/レプリカセット
バックアップおよびリカバリ戦略の一部としてのmongorestoreの使用の概要については、「 MongoDB ツールを使用したバックアップと復元 」を参照してください。
シャーディングされたクラスター
mongodumpとmongorestoreをシャーディングされたクラスターのバックアップ戦略として使用するには、「データベース ダンプを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。
シャーディングされたクラスターではバックアップと復元に次のいずれかの連携的なプロセスも利用できます。これにより、書込みを受け入れながらシャード間のアトミック性が保証されます。