Restoring database produces E11000 duplicate key error

Working with Data Developer Tools
1

Hello everyone,
I dumped my database using this command:

mongodump --uri
‘mongodb+srv://ACCOUNT_NAME:PASSWORD@cluster0.fklgt.mongodb.net/DATABASE_NAME’ --archive=“DATABASE_DUMP” --forceTableScan

Then I tried to restore it using this:

mongorestore --uri
‘mongodb+srv://ACCOUNT_NAME:PASSWORD@cluster0.fklgt.mongodb.net/DATABASE_NAME’ --archive=“DATABASE_DUMP” --nsFrom=‘DATABASE_NAME.’ --nsTo='DATABASE_NAME_COPY.’

But, this is what gets logged for each collection:

2021-11-28T13:28:48.359+0000 restoring to existing collection
DATABASE_NAME.admins without dropping

2021-11-28T13:28:48.359+0000 restoring DATABASE_NAME.admins from archive
‘DATABASE_DUMP’

2021-11-28T13:28:48.464+0000 continuing through error: E11000
duplicate key error collection: .admins index: id dup key: {
_id: ObjectId(‘xxxxxxxxxxxxxxxxxxxxxxxxxx’) }

2021-11-28T13:28:48.464+0000 continuing through error: E11000
duplicate key error collection: DATABASE_NAME.admins index: id dup key: {
_id: ObjectId(‘yyyyyyyyyyyyyyyyyyyyyyyy’) }

2021-11-28T13:28:48.464+0000 finished restoring DATABASE_NAME.admins (0
documents, 2 failures)

And in the end this is what gets logged:

2021-11-28T13:28:48.567+0000 no indexes to restore for collection
DATABASE_NAME.admins

2021-11-28T13:28:48.664+0000 0 document(s) restored successfully.
152793 document(s) failed to restore.

I usually dump and restore without any problem. So I have no idea why is this happening.

2

hi.
I had the same error for creating a new document.
I deleted the database and the error is went.
It must be a logic Error.
check you’re operator for updating the document.
this error will happen when you do a bad query to the database.
I hope to be helpful.

1 Like
3

restoring to existing collection DATABASE_NAME.admins without dropping

Hi @Ghrib_Ahmed,

It looks like you may have previously restored a backup to the DATABASE_NAME_COPY namespace.

Since your current mongorestore options do not include --drop, it is expected that a restore will encounter duplicate key exceptions when documents with the same _id already exist in the target database. If you ran this mongorestore command line twice in succession, the outcome would be as per your example: all documents will already have been inserted and will fail to be restored.

If the target database definitely does not exist and you are still experiencing this behaviour, please provide some further details to try to reproduce the issue:

  • versions of mongodump and mongorestore used (as reported by running each with --version)
  • MongoDB server version for your Atlas deployment

Regards,
Stennie

4

No, with every restore I change the value of DATABASE_NAME_COPY and I also tested with different databases and I keep getting the same result.
And keep in mind, I used to do this without any problem.

Here are the requested versions:

mongodump version: 100.5.0
git version: 460c7e26f65c4ce86a0b99c46a559dccaba3a07d
Go version: go1.16.3
os: linux
arch: amd64
compiler: gc

mongorestore version: 100.5.0
git version: 460c7e26f65c4ce86a0b99c46a559dccaba3a07d
Go version: go1.16.3
os: linux
arch: amd64
compiler: gc

MongoDB server version for the Atlas deployment: M0