What you will learn

MongoDB stores databases and collections rather than relational schemas. mongodump/mongorestore preserve BSON types; mongoexport/mongoimport serve a different interchange purpose. This small lab uses a write pause to establish a consistent copy boundary.

Before you begin

Install Database Tools compatible with both servers. Prepare TLS-protected connection details and accounts with the required backup/restore privileges. Use a private archive directory and a destination database that can be created for this exercise. Passwords are prompted rather than embedded in the URI.

1. Inspect the source collections

use tutorial
db.getCollectionNames()
db.events.countDocuments({})
db.events.getIndexes()

Record collection options, indexes, and representative BSON values. If the application is writing, a simple database-scoped dump must not be presented as a consistent multi-collection snapshot. Pause writers for this exercise; an online replica-set backup requires a separately valid oplog/snapshot procedure.

2. Create the compressed archive

mongodump --uri="mongodb://host1.sample.com:27017/?tls=true" \
  --username=backup_user --authenticationDatabase=admin \
  --db=tutorial --archive=tutorial.archive.gz --gzip

Configure the trusted CA as required by your deployment. Check the exit code and backup log. A nonempty archive alone does not prove a complete backup.

3. Restore to a different database

mongorestore --uri="mongodb://host2.sample.com:27017/?tls=true" \
  --username=restore_user --authenticationDatabase=admin \
  --archive=tutorial.archive.gz --gzip --stopOnError \
  --nsInclude="tutorial.*" --nsFrom="tutorial.*" --nsTo="tutorial_restore.*"

Explicit namespace selection prevents accidentally restoring unrelated databases. Do not add --drop for a first rehearsal; restore into a new namespace and retain the original.

4. Exercise the restored data

use tutorial_restore
db.events.countDocuments({})
db.events.getIndexes()
db.events.findOne({event_id: 1})

Compare options and BSON types as well as values. Test the application against the restored namespace and verify that indexes support its normal queries.

Example output

The following is an illustrative, normalized lab result, not output captured from a live customer system. Your versions, addresses, timings, and row counts will differ.

// Example countDocuments({}) for a three-document fixture
3

// Example findOne({event_id: 1}) in tutorial_restore
{ _id: 1, event_id: 1, message: 'ready' }

Create this synthetic fixture in the source to reproduce these values. A real dump may contain ObjectId values and additional fields; compare the BSON types as well as the displayed text.

Verify the result

No documents or index builds failed, expected collections exist, and the sample documents retain their types. Compare counts only at a known quiet boundary. Confirm the application account has appropriate access in the new namespace.

Troubleshooting

Duplicate-key errors usually indicate a nonempty target or index mismatch. Authentication failures can involve the authentication database rather than the data database. Unsupported options or BSON features require checking Database Tools/server compatibility.

Recovery and next steps

An unsuccessful rehearsal leaves the original database authoritative. Preserve its archive and restore log, correct the issue, and restore into another clean namespace. A live cutover needs a separate final-write and application-routing plan.

References