MONGORESTORE(1)

NAME
mongorestore - MongoDB Data Restoration Tool

  On this page

•   Synopsis

•   Availability

•   Usage in Backup Strategy

•   Syntax

•   Behavior

•   Required Access

•   Options

•   Examples

macOS Sierra and Go 1.6 Incompatibility

    Users running on macOS Sierra require the 3.2.10 or newer version of mongorestore.

SYNOPSIS

The mongorestore program loads data from either a binary database dump created by mongodump or the standard input (starting in version 3.0.0) into a mongod or mongos instance.

AVAILABILITY

The mongorestore tool is part of the MongoDB tools package. Consult the installation guide for your platform for instructions on how to install the tools package as part of your MongoDB installation.

The tools package is also available from the MongoDB Download Center, either as a separate tools download, or contained within the TGZ or ZIP downloads, depending on platform. On Windows, the MSI installer includes all tools as part of the default installation.

TIP

If downloading the TGZ or ZIP files from the Download Center, you may want to update your PATH environment variable to include the directory where you installed these tools. See the installation guide for your platform for more information.

USAGE IN BACKUP STRATEGY

  Standalones/Replica Sets

For an overview of mongorestore usage as part of a backup and recovery strategy, see /tutorial/backup-and-restore-tools.

  Sharded Clusters

mongodump and mongorestore cannot be part of a backup strategy for 4.2+ sharded clusters that have sharded transactions in progress as these tools cannot guarantee a atomicity guarantees of data across the shards.

For 4.2+ sharded clusters with in-progress sharded transactions, for coordinated backup and restore processes that maintain the atomicity guarantees of transactions across shards, see:

•   MongoDB Atlas,

•   MongoDB Cloud Manager, or

•   MongoDB Ops Manager.

SYNTAX

Run mongorestore from the system command line, not the mongo shell.

mongorestore [options] [<directory>/<BSON file>]

For example, to restore from a dump directory to a local mongod instance running on port 27017:

mongorestore  dump/

As mongorestore restores from the dump/ directory, it creates the database and collections as needed and logs its progress:

2019-07-08T14:37:38.942-0400 preparing collections to restore from
2019-07-08T14:37:38.944-0400 reading metadata for test.bakesales from dump/test/bakesales.metadata.json
2019-07-08T14:37:38.944-0400 reading metadata for test.salaries from dump/test/salaries.metadata.json
2019-07-08T14:37:38.976-0400 restoring test.salaries from dump/test/salaries.bson
2019-07-08T14:37:38.985-0400 no indexes to restore
2019-07-08T14:37:38.985-0400 finished restoring test.salaries (10 documents, 0 failures)
2019-07-08T14:37:39.009-0400 restoring test.bakesales from dump/test/bakesales.bson
2019-07-08T14:37:39.011-0400 restoring indexes for collection test.bakesales from metadata
2019-07-08T14:37:39.118-0400 finished restoring test.bakesales (21 documents, 0 failures)
2019-07-08T14:37:39.118-0400 restoring users from dump/admin/system.users.bson
2019-07-08T14:37:39.163-0400 restoring roles from dump/admin/system.roles.bson
2019-07-08T14:37:39.249-0400 31 document(s) restored successfully. 0 document(s) failed to restore.

You can also restore a specific collection or collections from the dump/ directory. For example, the following operation restores a single collection from corresponding data files in the dump/ directory:

mongorestore --nsInclude=test.purchaseorders dump/

If the dump/ directory does not contain the corresponding data file for the specified namespace, no data will be restored. For example, the following specifies a collection namespace that does not have a corresponding data in the dump/ directory:

mongorestore --nsInclude=foo.bar dump/

The mongorestore outputs the following messages:

2019-07-08T14:38:15.142-0400 preparing collections to restore from
2019-07-08T14:38:15.142-0400 0 document(s) restored successfully. 0 document(s) failed to restore.

For more examples, see Examples.

For more information on the options and arguments, see Options.

BEHAVIOR

  Insert Only

mongorestore can create a new database or add data to an existing database. However, mongorestore performs inserts only and does not perform updates. That is, if restoring documents to an existing database and collection and existing documents have the same value _id field as the to-be-restored documents, mongorestore will not overwrite those documents.

  Rebuild Indexes

mongorestore recreates indexes recorded by mongodump.

NOTE: For MongoDB 2.6 through MongoDB versions with featureCompatibilityVersion (fCV) set to "4.0" or earlier, creating indexes will error if an index key in an existing document exceeds the limit.

To avoid this issue, consider using hashed indexes or indexing a computed value instead. If you want to resolve the index issue after restoring the data, you can disable the default index key length validation on the target database by setting the mongod instance's failIndexKeyTooLong parameter to false.

  Version Compatibility

The data format used by mongodump from version 2.2 or later is incompatible with earlier versions of mongod. Do not use recent versions of mongodump to back up older data stores.

  Exclude system.profile Collection

mongorestore does not restore the system.profile collection data.

  FIPS

Starting in version 4.2, MongoDB removes the --sslFIPSMode option for mongorestore. mongorestore will use FIPS compliant connections to mongod/mongos if the mongod/mongos instances are configured to use FIPS mode.

  Write Concern

Starting in version 4.2, if you specify write concern in both the --writeConcern option and the --uri connection string option, the --writeConcern value overrides the write concern specified in the URI string.

In earlier versions, the two options are incompatible.

REQUIRED ACCESS

To restore data to a MongoDB deployment that has access control enabled, the restore role provides the necessary privileges to restore data from backups if the data does not include system.profile collection data and you run mongorestore without the --oplogReplay option.

If the backup data includes system.profile collection data or you run with --oplogReplay, you need additional privileges:
system.profile | If the backup data includes system.profile collection data and the target database does not contain the system.profile collection, mongorestore attempts to create the collection even though the program does not actually restore system.profile documents. As such, the user requires additional privileges to perform createCollection and convertToCapped actions on the system.profile collection for a database. Both the built-in roles dbAdmin and dbAdminAnyDatabase provide the additional privileges.
--oplogReplay | To run with --oplogReplay, create a user-defined role that has anyAction on resource-anyresource. Grant only to users who must run mongorestore with --oplogReplay.

OPTIONS

Changed in version 3.0.0: mongorestore removed the --filter, --dbpath, and the --noobjcheck options.

mongorestore

--help
    Returns information on the options and use of mongorestore.

--verbose, -v
    Increases the amount of internal reporting returned on standard output or in log files. Increase the verbosity with the -v form by including the option multiple times, (e.g. -vvvvv.)

--quiet
    Runs mongorestore in a quiet mode that attempts to limit the amount of output.

    This option suppresses:

•   output from database commands

•   replication activity

•   connection accepted events

•   connection closed events

--version
    Returns the mongorestore release number.

--uri=<connectionString>
    New in version 3.4.6.

    Specify a resolvable URI connection string (enclose in quotes) to connect to the MongoDB deployment.

    --uri="mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]"

    For information on the components of the connection string, see the Connection String URI Format documentation.

    NOTE: For TLS/SSL options, use the command-line options instead of the URI options for TLS/SSL (Available starting in 4.2).

    IMPORTANT: The following command-line options cannot be used in conjunction with --uri option:

•   --host

•   --port

•   --db

•   --username

•   --password (if the URI connection string also includes the password)

•   --authenticationDatabase

•   --authenticationMechanism

    Instead, specify these options as part of your --uri connection string.

--host=<hostname><:port>, -h=<hostname><:port>
    Default: localhost:27017

    Specifies a resolvable hostname for the mongod to which to connect. By default, the mongorestore attempts to connect to a MongoDB instance running on the localhost on port number 27017.

    To connect to a replica set, specify the replSetName and a seed list of set members, as in the following:

    --host=<replSetName>/<hostname1><:port>,<hostname2><:port>,<...>

    When specifying the replica set list format, mongorestore always connects to the primary.

    You can also connect to any single member of the replica set by specifying the host and port of only that member:

    --host=<hostname1><:port>

    Changed in version 3.0.0: If you use IPv6 and use the <address>:<port> format, you must enclose the portion of an address and port combination in brackets (e.g. [<address>]).

    NOTE: You cannot specify both --host and --uri.

--port=<port>
    Default: 27017

    Specifies the TCP port on which the MongoDB instance listens for client connections.

    NOTE: You cannot specify both --port and --uri.

--ssl
    New in version 2.6.

    Enables connection to a mongod or mongos that has TLS/SSL support enabled.

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

--sslCAFile=<filename>
    New in version 2.6.

    Specifies the .pem file that contains the root certificate chain from the Certificate Authority. Specify the file name of the .pem file using relative or absolute paths.

    Starting in version 3.4, if --tlsCAFile/net.tls.CAFile (or their aliases --sslCAFile/net.ssl.CAFile) is not specified and you are not using x.509 authentication, the system-wide CA certificate store will be used when connecting to an TLS/SSL-enabled server.

    To use x.509 authentication, --tlsCAFile or net.tls.CAFile must be specified unless using --tlsCertificateSelector or --net.tls.certificateSelector. Or if using the ssl aliases, --sslCAFile or net.ssl.CAFile must be specified unless using --sslCertificateSelector or net.ssl.certificateSelector.

    WARNING: Version 3.2 and earlier: For TLS/SSL connections (--ssl) to mongod and mongos, if the mongorestore runs without the --sslCAFile, mongorestore will not attempt to validate the server certificates. This creates a vulnerability to expired mongod and mongos certificates as well as to foreign processes posing as valid mongod or mongos instances. Ensure that you always specify the CA file to validate the server certificates in cases where intrusion is a possibility.

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

--sslPEMKeyFile=<filename>
    New in version 2.6.

    Specifies the .pem file that contains both the TLS/SSL certificate and key. Specify the file name of the .pem file using relative or absolute paths.

    This option is required when using the --ssl option to connect to a mongod or mongos that has CAFile enabled without allowConnectionsWithoutCertificates.

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

--sslPEMKeyPassword=<value>
    New in version 2.6.

    Specifies the password to de-crypt the certificate-key file (i.e. --sslPEMKeyFile). Use the --sslPEMKeyPassword option only if the certificate-key file is encrypted. In all cases, the mongorestore will redact the password from all logging and reporting output.

    If the private key in the PEM file is encrypted and you do not specify the --sslPEMKeyPassword option, the mongorestore will prompt for a passphrase. See ssl-certificate-password.

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

--sslCRLFile=<filename>
    New in version 2.6.

    Specifies the .pem file that contains the Certificate Revocation List. Specify the file name of the .pem file using relative or absolute paths.

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

--sslAllowInvalidCertificates
    New in version 2.6.

    Bypasses the validation checks for server certificates and allows the use of invalid certificates. When using the allowInvalidCertificates setting, MongoDB logs as a warning the use of the invalid certificate.

    Starting in MongoDB 4.0, if you specify --sslAllowInvalidCertificates or net.ssl.allowInvalidCertificates: true (or in MongoDB 4.2, the alias --tlsAllowInvalidateCertificates or net.tls.allowInvalidCertificates: true) when using x.509 authentication, an invalid certificate is only sufficient to establish a TLS/SSL connection but is insufficient for authentication.

    WARNING: Although available, avoid using the --sslAllowInvalidCertificates option if possible. If the use of --sslAllowInvalidCertificates is necessary, only use the option on systems where intrusion is not possible.

    If the mongo shell (and other mongodb-tools-support-ssl) runs with the --sslAllowInvalidCertificates option, the mongo shell (and other mongodb-tools-support-ssl) will not attempt to validate the server certificates. This creates a vulnerability to expired mongod and mongos certificates as well as to foreign processes posing as valid mongod or mongos instances. If you only need to disable the validation of the hostname in the TLS/SSL certificates, see --sslAllowInvalidHostnames.

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

--sslAllowInvalidHostnames
    New in version 3.0.

    Disables the validation of the hostnames in TLS/SSL certificates. Allows mongorestore to connect to MongoDB instances even if the hostname in their certificates do not match the specified hostname.

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

--username=<username>, -u=<username>
    Specifies a username with which to authenticate to a MongoDB database that uses authentication. Use in conjunction with the --password and --authenticationDatabase options.

    NOTE: You cannot specify both --username and --uri.

--password=<password>, -p=<password>
    Specifies a password with which to authenticate to a MongoDB database that uses authentication. Use in conjunction with the --username and --authenticationDatabase options.

    Changed in version 3.0.2: To prompt the user for the password, pass the --username option without --password or specify an empty string as the --password value, as in --password="" .

    NOTE: You cannot specify both --password and --uri.

--authenticationDatabase=<dbname>
    Specifies the authentication database where the specified --username has been created. See user-authentication-database.

    NOTE: You cannot specify both --authenticationDatabase and --uri.

--authenticationMechanism=<name>
    Default: SCRAM-SHA-1

    Specifies the authentication mechanism the mongorestore instance uses to authenticate to the mongod or mongos.

    Changed in version 4.0: MongoDB removes support for the deprecated MongoDB Challenge-Response (MONGODB-CR) authentication mechanism.

    MongoDB adds support for SCRAM mechanism using the SHA-256 hash function (SCRAM-SHA-256).
    Value | Description
    SCRAM-SHA-1 | RFC 5802 standard Salted Challenge Response Authentication Mechanism using the SHA-1 hash function.
    SCRAM-SHA-256 | RFC 7677 standard Salted Challenge Response Authentication Mechanism using the SHA-256 hash function. Requires featureCompatibilityVersion set to 4.0. New in version 4.0.
    MONGODB-X509 | MongoDB TLS/SSL certificate authentication.
    GSSAPI (Kerberos) | External authentication using Kerberos. This mechanism is available only in MongoDB Enterprise.
    PLAIN (LDAP SASL) | External authentication using LDAP. You can also use PLAIN for authenticating in-database users. PLAIN transmits passwords in plain text. This mechanism is available only in MongoDB Enterprise.

    NOTE: You cannot specify both --authenticationMechanism and --uri.

--gssapiServiceName=<serviceName>
    New in version 2.6.

    Specify the name of the service using GSSAPI/Kerberos. Only required if the service does not use the default name of mongodb.

    This option is available only in MongoDB Enterprise.

--gssapiHostName=<hostname>
    New in version 2.6.

    Specify the hostname of a service using GSSAPI/Kerberos. Only required if the hostname of a machine does not match the hostname resolved by DNS.

    This option is available only in MongoDB Enterprise.

--db=<database>, -d=<database>
    Specifies the destination database for mongorestore to restore data into when restoring from a BSON file. If the database does not exist, mongorestore creates the database. For example, the following restores the salaries collection into the reporting database.

    mongorestore --db=reporting dump/test/salaries.bson

    If you do not specify --db, mongorestore takes the database name from the data files.

    The use of --db and --collection options are deprecated when restoring from a directory or an archive file. Instead, to restore from an archive or a directory, see --nsInclude instead.

    NOTE: You cannot specify both --db and --uri.

--collection=<collection>, -c=<collection>
    Specifies the name of the destination collection for mongorestore to restore data into when restoring from a BSON file. If you do not specify --collection, mongorestore takes the collection name from the input filename. If the input file has an extension, MongoDB omits the extension of the file from the collection name.

    mongorestore --db=reporting --collection=employeesalaries dump/test/salaries.bson

    The use of --db and --collection options are deprecated when restoring from a directory or an archive file. Instead, to restore from an archive or a directory, see --nsInclude instead.

--nsExclude=<namespace pattern>
    New in version 3.4.

    Specifies a namespace pattern (e.g. "test.myCollection", "reporting.*", "dept*.bar") to exclude the matching namespaces from the restore. In the pattern, you can use asterisks * as wild cards. For an example of the wildcard pattern, see Restore Collections Using Wild Cards.

    You can specify --nsExclude multiple times to exclude multiple namespace patterns.

--nsInclude=<namespace pattern>
    New in version 3.4.

    Specifies a namespace pattern (e.g. "test.myCollection", "reporting.*", "dept*.bar") to restore only the namespaces that match the pattern. In the pattern, you can use asterisks * as wild cards. For an example of the wildcard pattern, see Restore Collections Using Wild Cards.

    You can specify --nsInclude multiple times to include multiple namespace patterns.

    If source directory or file (i.e. the directory/file from which you are restoring the data) does not contain data files that match the namespace pattern, no data will be restored.

    For collection names that contain non-ascii characters, mongodump outputs the corresponding filenames with percent-encoded names. However, to restore these collections, do not use the encoded names. Instead, use the namespace with the non-ascii characters.

    For example, if the dump directory contains dump/test/caf%C3%A9s.bson, specify --nsInclude "test.cafés".

--nsFrom=<namespace pattern>
    New in version 3.4.

    Use with --nsTo to rename a namespace during the restore operation. --nsFrom specifies the collection in the dump file, while --nsTo specifies the name that should be used in the restored database.

    --nsFrom accepts a namespace pattern as its argument. The namespace pattern permits --nsFrom to refer to any namespace that matches the specified pattern. mongorestore matches the smallest valid occurence of the namespace pattern.

    For simple replacements, use asterisks (*) as wild cards. Escape all literal asterisks and backslashes with a backslash. Replacements correspond linearly to matches: each asterisk in --nsFrom must correspond to an asterisk in --nsTo, and the first asterisk in --nsFrom matches the first asterisk in nsTo.

    For more complex replacements, use dollar signs to delimit a "wild card" variable to use in the replacement. Change Collections' Namespaces during Restore provides an example of complex replacements with dollar sign-delimited wild cards.

    Unlike replacements with asterisks, replacements with dollar sign-delimited wild cards do not need to be linear.

--nsTo=<namespace pattern>
    New in version 3.4.

    Use with --nsFrom to rename a namespace during the restore operation. --nsTo specifies the new collection name to use in the restored database, while --nsFrom specifies the name in the dump file.

    --nsTo accepts a namespace pattern as its argument. The namespace pattern permits --nsTo to refer to any namespace that matches the specified pattern. mongorestore matches the smallest valid occurence of the namespace pattern.

    For simple replacements, use asterisks (*) as wild cards. Escape all literal asterisks and backslashes with a backslash. Replacements correspond linearly to matches: each asterisk in --nsFrom must correspond to an asterisk in --nsTo, and the first asterisk in --nsFrom matches the first asterisk in nsTo.

    For more complex replacements, use dollar signs to delimit a "wild card" variable to use in the replacement. Change Collections' Namespaces during Restore provides an example of complex replacements with dollar sign-delimited wild cards.

    Unlike replacements with asterisks, replacements with dollar sign-delimited wild cards do not need to be linear.

--objcheck
    Forces mongorestore to validate all requests from clients upon receipt to ensure that clients never insert invalid documents into the database. For objects with a high degree of sub-document nesting, --objcheck can have a small impact on performance.

--drop
    Before restoring the collections from the dumped backup, drops the collections from the target database. --drop does not drop collections that are not in the backup.

    When the restore includes the admin database, mongorestore with --drop removes all user credentials and replaces them with the users defined in the dump file. Therefore, in systems with authorization enabled, mongorestore must be able to authenticate to an existing user and to a user defined in the dump file. If mongorestore can't authenticate to a user defined in the dump file, the restoration process will fail, leaving an empty database.

--dryRun
    New in version 3.4.

    Runs mongorestore without actually importing any data, returning the mongorestore summary information. Use with --verbose to produce more detailed summary information.

--oplogReplay
    After restoring the database dump, replays the oplog entries from a bson file. When used in conjunction with mongodump --oplog, mongorestore --oplogReplay restores the database to the point-in-time backup captured with the mongodump --oplog command.

    mongorestore searches for any valid source for the bson file in the following locations:

•   The top level of the dump directory, as in the case of a dump created with mongodump --oplog.

•   The path specified by --oplogFile.

•   <dump-directory>/local/oplog.rs.bson, as in the case of a dump of the oplog.rs collection in the local database on a mongod that is a member of a replica set.

    If there is an oplog.bson file at the top level of the dump directory and a path specified by --oplogFile, mongorestore returns an error.

    If there is an oplog.bson file at the top level of the dump directory, mongorestore restores that file as the oplog. If there are also bson files in the dump/local directory, mongorestore restores them like normal collections.

    If you specify an oplog file using --oplogFile, mongorestore restores that file as the oplog. If there are also bson files in the dump/local directory, mongorestore restores them like normal collections.

    For an example of --oplogReplay, see backup-restore-oplogreplay.

    NOTE: When using mongorestore with --oplogReplay to restore a replica set, you must restore a full dump of a replica set member created using ~bin.mongodump --oplog. mongorestore with --oplogReplay fails if you use any of the following options to limit the data be restored:

•   --db

•   --collection

•   --nsInclude

•   --nsExclude

    SEE ALSO: mongorestore Required Access

    SEE ALSO: mongodump --oplog

--oplogLimit=<timestamp>
    Prevents mongorestore from applying oplog entries with timestamp newer than or equal to <timestamp>. Specify <timestamp> values in the form of <time_t>:<ordinal>, where <time_t> is the seconds since the UNIX epoch, and <ordinal> represents a counter of operations in the oplog that occurred in the specified second.

    You must use --oplogLimit in conjunction with the --oplogReplay option.

--oplogFile=<path>
    New in version 3.4.

    Specifies the path to the oplog file containing oplog data for the restore. Use with --oplogReplay.

    If you specify --oplogFile and there is an oplog.bson file at the top level of the dump directory, mongorestore returns an error.

--keepIndexVersion
    Prevents mongorestore from upgrading the index to the latest version during the restoration process.

--noIndexRestore
    Prevents mongorestore from restoring and building indexes as specified in the corresponding mongodump output.

--noOptionsRestore
    Prevents mongorestore from setting the collection options, such as those specified by the collMod database command, on restored collections.

--restoreDbUsersAndRoles
    Restore user and role definitions for the given database. See /reference/system-roles-collection and /reference/system-users-collection for more information.

--writeConcern=<document>
    Default: majority

    Specifies the write concern for each write operation that mongorestore performs.

    Specify the write concern as a document with w options:

    --writeConcern="{w:'majority'}"

    If the write concern is also included in the --uri connection string, the command-line --writeConcern overrides the write concern specified in the URI string.

--maintainInsertionOrder
    Default: False

    If specified,

•   Starting in version 4.2, mongorestore inserts the documents in the order of their appearance in the input source. That is, both the bulk write batch order and document order within the batches are maintained.

•   In earlier versions, only the batch order is maintained; document order within batches are not maintained.

    Starting in MongoDB 4.2, specifying --maintainInsertionOrder also enables --stopOnError and sets numInsertionWorkersPerCollection to 1.

    If unspecified, mongorestore may perform the insertions in an arbitrary order.

--numParallelCollections=<int>, -j=<int>
    Default: 4

    Number of collections mongorestore should restore in parallel.

    If you specify -j when restoring a single collection, -j maps to the --numInsertionWorkersPerCollection option rather than --numParallelCollections.

--numInsertionWorkersPerCollection=<int>
    Default: 1

    New in version 3.0.0.

    Specifies the number of insertion workers to run concurrently per collection.

    For large imports, increasing the number of insertion workers may increase the speed of the import.

--stopOnError
    New in version 3.0.

    Forces mongorestore to halt the restore when it encounters an error.

    Starting in version 4.2, mongorestore, by default, continues when it encounters duplicate key and document validation errors. To ensure that the program stops on these errors, specify --stopOnError.

--bypassDocumentValidation
    Enables mongorestore to bypass document validation during the operation. This lets you insert documents that do not meet the validation requirements.

    New in version 3.2.1.

--gzip
    New in version 3.2.

    Restores from compressed files or data stream created by ~bin.mongodump --gzip

    To restore from a dump directory that contains compressed files, run mongorestore with the --gzip option.

    To restore from a compressed archive file, run mongorestore with both the --gzip and the --archive options.

--archive=<file>
    New in version 3.2.

    Restores from the specified archive file or, if the file is unspecified, from the standard input (stdin):

•   To restore from an archive file, run mongorestore with the --archive option and the archive filename

•   To restore from the standard input, run mongorestore with the --archive option but omit the filename.

    NOTE:

•   You cannot use the --archive option with the --dir option.

•   If you use the --archive option with the <path> parameter, mongorestore ignores <path> parameter.

•   mongorestore still supports the positional - parameter to restore a single collection from the standard input.

<path>
    The directory path or BSON file name from which to restore data.

    You cannot specify both the <path> argument and the --dir option, which also specifies the dump directory, to mongorestore.

--dir=string
    Specifies the dump directory.

•   You cannot specify both the --dir option and the <path> argument, which also specifies the dump directory, to mongorestore.

•   You cannot use the --archive option with the --dir option.

EXAMPLES

  Restore with Access Control

In the following example, mongorestore restores from /opt/backup/mongodump-2011-10-24 to a mongod instance running on port 27017 on the host mongodb1.example.net. The --uri string omits the user's password to have mongorestore prompt for the password.

mongorestore --uri="mongodb://user@mongodb1.example.net:27017/?authSource=admin" /opt/backup/mongodump-2011-10-24

Alternatively, you can specify the host, port, username, and authentication database using --host, --port, --username, and --authenticationDatabase. Omit --password to have mongorestore prompt for the password:

mongorestore --host=mongodb1.example.net --port=27017 --username=user --authenticationDatabase=admin /opt/backup/mongodump-2011-10-24

  Restore a Collection

New in version 3.4.

To restore a specific collection, use --nsInclude, passing in the full namespace (<database>.<collection>) of the collection.

For example, the following restores the collection named purchaseorders in the database test from the corresponding files located in the dump/ directory.

mongorestore --nsInclude=test.purchaseorders dump/

The mongorestore outputs the results, including the number of documents restored:

2019-06-28T19:23:42.858-0400   preparing collections to restore from
2019-06-28T19:23:42.858-0400   reading metadata for test.purchaseorders from dump/test/purchaseorders.metadata.json
2019-06-28T19:23:42.893-0400   restoring test.purchaseorders from dump/test/purchaseorders.bson
2019-06-28T19:23:42.896-0400   restoring indexes for collection test.purchaseorders from metadata
2019-06-28T19:23:42.991-0400   finished restoring test.purchaseorders (6 documents, 0 failures)
2019-06-28T19:23:42.991-0400   6 document(s) restored successfully. 0 document(s) failed to restore.

If the dump/ directory does not contain the corresponding data files for the specified namespace, no data will be restored:

2019-07-08T14:39:57.121-0400. preparing collections to restore from
2019-07-08T14:39:57.121-0400  0 document(s) restored successfully. 0 document(s) failed to restore.

Alternatively, you can restore a specific collection using the --db, --collection, and a .bson file:

mongorestore --db=test --collection=purchaseorders dump/test/purchaseorders.bson

2019-06-30T12:21:44.777-0400   checking for collection data in dump/test/purchaseorders.bson
2019-06-30T12:21:44.779-0400   reading metadata for test.purchaseorders from dump/test/purchaseorders.metadata.json
2019-06-30T12:21:44.813-0400   restoring test.purchaseorders from dump/test/purchaseorders.bson
2019-06-30T12:21:44.881-0400   restoring indexes for collection test.purchaseorders from metadata
2019-06-30T12:21:44.987-0400   finished restoring test.purchaseorders (6 documents, 0 failures)
2019-06-30T12:21:44.987-0400   6 document(s) restored successfully. 0 document(s) failed to restore.

  Restore Collections Using Wild Cards

New in version 3.4.

--nsInclude and --nsExclude support specifying the namespaces you wish to include or exclude from a restore operation using asterisks as wild cards.

The following example restores the documents in the dump/ sub-directory of the current directory that match the specified namespace pattern. The --nsInclude statement specifies to only restore documents in the transactions database while --nsExclude instructs mongorestore to exclude collections whose names end with _dev. mongorestore restores data to the mongod instance running on the localhost interface on port 27017.

mongorestore --nsInclude='transactions.*' --nsExclude='transactions.*_dev' dump/

  Change Collections' Namespaces during Restore

New in version 3.4.

MongoDB 3.4 added the --nsFrom and --nsTo options, which enable you to change the namespace of a collection that you are restoring. --nsFrom and --nsTo support using asterisks as wild cards and support using dollar signs to delimit "wild card" variables to use in the replacement.

Consider a database data that you have exported to a dump/ directory using mongodump. The data database contains the following collections:

•   sales_customer1

•   sales_customer2

•   sales_customer3

•   users_customer1

•   users_customer2

•   users_customer3

    Using --nsFrom and --nsTo, you can restore the data into different namespaces. The following operation

•   restores the sales_<customerName> collections in the data database to sales collections in the <customerName> database, and

•   restores the users_<customerName> collections to users collections in the <customerName> database.

    mongorestore --nsInclude='data.*' --nsFrom='data.$prefix$_$customer$' --nsTo='$customer$.$prefix$'

  Restore from an Archive File

To restore from an archive file, run restore with the new --archive option and the archive filename.

mongorestore --archive=test.20150715.archive

  Restore a Database from an Archive File

New in version 3.2.

To restore from an archive file, run restore with the new --archive option and the archive filename. For example, the following operation restores the test database from the file test.20150715.archive.

mongorestore --archive=test.20150715.archive  --nsInclude="test.*"

  Restore from Compressed Data

New in version 3.2: With the --gzip option, mongorestore can restore from compressed files or data stream created by mongodump.

To restore from a dump directory that contains compressed files, run mongorestore with the --gzip. For example, the following operation restores the test database from the compressed files located in the default dump directory:

mongorestore --gzip  --nsInclude="test.*" dump/

To restore from a compressed archive file, run mongorestore with the --gzip option and the --archive option. For example, the following operation restores the test database from the archive file test.20150715.gz.

mongorestore --gzip --archive=test.20150715.gz --nsInclude="test.*"

  Restore a Database from Standard Input

New in version 3.2.

To restore from the standard input, run mongorestore with the --archive option but omit the filename. For example:

mongodump --archive --db=test --port=27017 | mongorestore --archive --port=27018

AUTHOR
MongoDB Documentation Project

COPYRIGHT
2008-2019