Mongorestore to a different database

Question

In MongoDB, is it possible to dump a database and restore the content to a different database? For example like this:

mongodump --db db1 --out dumpdir
mongorestore --db db2 --dir dumpdir

But it doesn't work. Here's the error message:

building a list of collections to restore from dumpdir dir

don't know what to do with subdirectory "dumpdir/db1", skipping...

done

Solution 1

You need to actually point at the "database name" container directory "within" the output directory from the previous dump:

mongorestore -d db2 dumpdir/db1

And usually just <path> is fine as a positional argument rather than with -dir which would only be needed when "out of position" i.e "in the middle of the arguments list".

p.s. For archive backup file (tested with mongorestore v3.4.10)

mongorestore --gzip --archive=${BACKUP_FILE_GZ} --nsFrom "${DB_NAME}.*" --nsTo "${DB_NAME_RESTORE}.*"

Solution 2

mongodump --db=DB_NAME --out=/path-to-dump
mongorestore --nsFrom "DB_NAME.*" --nsTo "NEW_DB_NAME.*" /path-to-dump

Solution 3

In addition to the answer of Blakes Seven, if your databases use authentication I got this to work using the --uri option, which requires a recent mongo version (>3.4.6):

mongodump --uri="mongodb://$sourceUser:$sourcePwd@$sourceHost/$sourceDb" --gzip --archive | mongorestore --uri="mongodb://$targetUser:$targetPwd@$targetHost/$targetDb" --nsFrom="$sourceDb.*" --nsTo="$targetDb.*" --gzip --archive

Solution 4

Thank you! @Blakes Seven

Adding Docker notes: container names are interchangeable with container ID's

(assumes authenticated, assumes named container=my_db and new_db)

dump:

docker exec -it my_db bash -c "mongodump --uri mongodb://db:password@localhost:27017/my_db --archive --gzip | cat > /tmp/backup.gz"

copy to workstation:

docker cp my_db:/tmp/backup.gz c:\backups\backup.gz

copy into new container(form backups folder):

docker cp .\backup.gz new_db:/tmp

restore from container tmp folder:

docker exec -it new_db bash -c "mongorestore --uri mongodb://db:password@localhost:27017/new_db --nsFrom 'my_db.*' --nsTo 'new_db.*' --gzip --archive=/tmp/backup.gz"

View more solutions

Comments

[Cyker]

Thank you! This worked. I think one must specify the subdirectory in the dump folder when using the -d option and the dump folder itself when not using -d. That's it.

[Sergio Rykov]

Can you suggest solution for archived dumps( --gzip --archive) ?

[Philiiiiiipp]

@SergioRykov Seems like this is a known bug jira.mongodb.org/browse/TOOLS-1234 and will be resolved in 3.3.10. At the moment there is no support for that.

[Hamburml]

@Philiiiiiipp Looks like this is now supported. To be honest --nsInclude --nsExclude --nsFrom and --nsTo looks overcomplicated. I have a backup done with --archive and --gzip and I want to restore this backup in a different database. How can I do that? I think I need nsFrom and nsTo but not nsInclude and nsExclude because I don't want something to be excluded. The whole backup should be restored and only the name of the database changes.

[ibai]

I have tested this solution and it works, the only problem is that the DBRefs still point to the initial database entries instead of the "nsTo" database entries.

[Greg]

Thank you!!! Adding Docker notes (assumes authenticated, assumes named container=my_db and new_db) dump: docker exec -it my_db bash -c "mongodump --uri mongodb://db:password@localhost:27017/my_db --archive --gzip | cat > /tmp/backup.gz" copy: docker cp my_db:/tmp/backup.gz local-drive\backup.gz restore: docker exec -it new_db bash -c "mongorestore --uri mongodb://db:password@localhost:27017/new_db --nsFrom 'my_db.*' --nsTo 'new_db.*' --gzip --archive=/tmp/backup.gz"

[Donald Duck]

While this code may answer the question, providing additional context regarding how and/or why it solves the problem would improve the answer's long-term value.

[Zala Janaksinh]

save my 3 hrs. but still missing authentication process

[Mostafa Nazari]

read docs.mongodb.com/database-tools/mongodump, there are different switches for authentication like --username, --password, etc. @ZalaJanaksinh