Mongorestore preserveUUID

I have a difference between Windows10 & Linux doing the exact same operation:
Restoring a ‘dump’ into a different database.

I’m creating a ‘staging’ db from Live, so initially I create the new db using:

mongorestore --host= --username --password --authenticationDatabase=admin --nsFrom=db.* --nsTo=new-db.* --db=db --gzip ./backups/2020-12-01/db --verbose

** This works just fine on both platforms.

For daily updates, I want to update all collections, except 1. Works fine in Windows (dev), but not Linux (production)

mongorestore --host= --username --password --authenticationDatabase=admin --nsFrom=db.* --nsTo=new-db.* --db=db --gzip ./backups/2020-12-02/db --nsExclude db.settings --drop --preserveUUID ./backups/2020-12-03/db --verbose

I’ve narrowed it down to the ‘–preserveUUID’.

The error in Linux I get is:

Failed: new-db.test: error creating collection new-db.test: applyOps: (Location40655) Invalid name new-db.test for UUID 1da7ab34-65b9-4a2a-b613-acf7ad2b5b5a

I have absolutely no idea what this means, nor have I found any clues extensively searching Google and other forums.

My Mongo is 4.2. I upgraded ‘mongorestore’ to 100.2.1 on Linux- no change. Am flying blind.

Any ideas that I can pursue?

Further to this. The documentation for mongorestore --preserveUUID says this:
Restored collections use the UUID from the restore data instead of creating a new UUID for collections that are dropped and recreated as part of the restore.

To use --preserveUUID , you must also include the --drop option.

Further testing shows that the original problem (restoring the data from 1 database name to another) does not show up in mongorestore/mongodb 4.2.11 or 100.2.1/4.4.2. This is a good thing.

But, the problem arises on these later versions (on Windows & Linux platforms) when I’m restoring the ‘production’ server dump into the ‘staging’ server to the database with the same name:
mongorestore --gzip --db=db --dir="\db" --verbose --host= --drop --preserveUUID

It only works if:

  • –drop is used by itself
  • neither --drop and --preserveUUID are used. (get the expected duplicate errors)

It fails when --preserveUUID is included with --drop.

It seems reasonable to me to preserve UUID’s when wanting to create an exact copy of the production server’s Live database on a separate Staging server.

Thoughts anyone?

The solution, and in hindsight, obvious, is that you can’t ‘preserveUUID’ in the same instance!

UUID = “universal unique ID”- it can only exist once in an instance.

The solution was to create a 2nd instance (and in my case, on the same machine) as per the instructions:


This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.