Can anyone share their restore experiences that restored both indexes and mongodb_id?
As per MongoDB documentation here By default, mongorestore looks for a database backup in the dump/ directory.
New in version 3.6:
All MongoDB collections have UUIDs by default. When MongoDB restores collections, the restored collections retain their original UUIDs. When restoring a collection where no UUID was present, MongoDB generates a UUID for the restored collection.
UUID() has the following syntax:
UUID(<string>)
Parameter Type Description
hex string
Optional. Specify a 36 character string to convert to a UUID BSON object. If not provided, MongoDB generates a random UUID in RFC 4122 v4 format.
Changed in version 3.6: In earlier versions of the mongo shell, UUID required a hexadecimal string argument. See the 3.4 manual.
It's returns A BSON UUID object
.
I noticed the indexes are lost and _id has new values after
mongorestore.
@Will, As JJussi has already said that mongorestore should recreate all indexes what mongodump has recorded.
For Example
I have mongodump in my C:\data\dump
folder. Which contains the database folder 100YWeatherSmall
,citibike
,city
,ships
,video
with their (.bson & .json) file. These database I had already restored in MongoDB 3.6.

Here again i am going to mongorestore to these databases dump file in MongoDB 3.6.
As you can see that mention all databases has already in MongoDB.

Note: Here I have highlighted the some database name due to security reason.
Here I am going to mongorestore through the below command.
C:\Program Files\MongoDB\Server\3.6\bin>mongorestore --verbose C:\data\dump
Note: Run mongorestore from the system command line, not the mongo shell.
video.movies
database dump restore report status
- E11000 duplicate key error collection: video.movies index: _id_ dup key: { : ObjectId('58c59c6b99d4ee0af9e0eef0') }
- E11000 duplicate key error collection: video.movies index: _id_ dup key: { : ObjectId('58c59c6b99d4ee0af9e0eef1') }
- E11000 duplicate key error collection: video.movies index: _id_ dup key: { : ObjectId('58c59c6b99d4ee0af9e0eef2') }
- E11000 duplicate key error collection: video.movies index: _id_ dup key: { : ObjectId('58c59c6b99d4ee0af9e0eef3') }
- E11000 duplicate key error collection: video.movies index: _id_ dup key: { : ObjectId('58c59c6b99d4ee0af9e0eef4') }
100YWeatherSmall.data
database dump restore report status
- E11000 duplicate key error collection: 100YWeatherSmall.data index: _id_ dup key: { : ObjectId('5553a98ee4b02cf7150e1cc8') }
- E11000 duplicate key error collection: 100YWeatherSmall.data index: _id_ dup key: { : ObjectId('5553a98ee4b02cf7150e1cca') }
- E11000 duplicate key error collection: 100YWeatherSmall.data index: _id_ dup key: { : ObjectId('5553a98ee4b02cf7150e1ccc') }
- E11000 duplicate key error collection: 100YWeatherSmall.data index: _id_ dup key: { : ObjectId('5553a98ee4b02cf7150e1ccd') }
- E11000 duplicate key error collection: 100YWeatherSmall.data index: _id_ dup key: { : ObjectId('5553a98ee4b02cf7150e1cd0') }
citibike.trips
database dump restore report status
- E11000 duplicate key error collection: citibike.trips index: _id_ dup key: { : ObjectId('572bb8232b288919b68b258e') }
- E11000 duplicate key error collection: citibike.trips index: _id_ dup key: { : ObjectId('572bb8232b288919b68b25ad') }
- E11000 duplicate key error collection: citibike.trips index: _id_ dup key: { : ObjectId('572bb8232b288919b68b2608') }
- E11000 duplicate key error collection: citibike.trips index: _id_ dup key: { : ObjectId('572bb8232b288919b68b26c5') }
- E11000 duplicate key error collection: citibike.trips index: _id_ dup key: { : ObjectId('572bb8232b288919b68b26da') }
Here you can noticed that all during mongorestore
it's showing index: _id_ dup key:
because that index: id is already exist in that database & collection .
That means whatever mongodump has created the index:id & ObjectId that is same index:id & ObjectId is same mongorestore in MongoDB.
Here the below mention reports is the citibike.trips mongorestore complete mongodump restore reports.
2018-05-30T10:56:31.962+0300 [########################] citibike.trips 835MB/835MB (100.0%)
2018-05-30T10:56:31.962+0300 restoring indexes for collection citibike.trips from metadata
2018-05-30T10:56:32.106+0300 finished restoring citibike.trips (1990273 documents)
2018-05-30T10:56:32.126+0300 done
For example here I have only mention the citibite.trips restore complete reports. The message is showing restoring indexes for collection citibike.trips from metadata.
So, as per above conclusion we can say that mongorestore
, store the same index:_id_
& ObjectId
, which mongodump
has created.
For your further ref here , here and here
mongoexport
andmongoimport
, and to get anything "close to" what you actually don't describe very well here, you need to force it by specific options – Neil Lunn May 29 '18 at 21:20mongorestore
. I am guessing index and _id were lost because the database and collections were created when I run my backend application which happened beforemongorestore
– Will May 30 '18 at 4:07_id
will be lost if database and collections are created beforemongorestore
.Thanks everyone who looked into this problem! – Will May 30 '18 at 4:18