Suppose your school management application stores student records in MongoDB. If the records are accidentally deleted, you may be able to recover them from a valid backup.

For example:

• You create a backup of the school database.
• Some student records are accidentally deleted.
• You restore the database from the backup.
• The backed-up records become available again.

Restoration recovers the state captured by the backup. It does not automatically recover changes made after that backup was created.

Suppose you created a backup using this command:

mongodump \
  --uri="mongodb://127.0.0.1:27017" \
  --db=school \
  --out="./school_backup"

The backup directory may contain files such as students.bson and students.metadata.json.

To restore the school database, run:

mongorestore \
  --uri="mongodb://127.0.0.1:27017" \
  --nsInclude="school.*" \
  "./school_backup/school"

This restores the backed-up collections whose namespaces match school.*.

Important: By default, restoration does not necessarily replace existing documents with the same identifiers. Review the destination database before restoring.

You can restore a specific database from a directory containing a dump.

mongorestore \
  --uri="mongodb://127.0.0.1:27017" \
  --nsInclude="school.*" \
  "./mongodb_backup"

The --nsInclude option filters the namespaces to restore. Here, only namespaces belonging to the school database are selected.

Confirm the backup directory structure before running the command, because the path must point to the directory containing the dump data.

If your backup contains a collection named students, you can restore only that collection using a namespace filter.

mongorestore \
  --uri="mongodb://127.0.0.1:27017" \
  --nsInclude="school.students" \
  "./students_backup"

This command selects the school.students namespace from the supplied dump directory.

If the collection was backed up under a different database name, adjust the namespace filter to match the namespace stored in the dump or use namespace mapping options as appropriate.

In the previous lesson, we created a compressed archive using mongodump.

mongodump \
  --uri="mongodb://127.0.0.1:27017" \
  --db=school \
  --archive="./school_backup.gz" \
  --gzip

Restore the archive with:

mongorestore \
  --uri="mongodb://127.0.0.1:27017" \
  --archive="./school_backup.gz" \
  --gzip

The --archive option identifies the archive file, and --gzip tells the tool to decompress the archived dump.

If the archive contains several databases, review its contents and use namespace filters when you only want to restore selected data.

If MongoDB authentication is enabled, provide a suitable username and authentication database.

mongorestore \
  --uri="mongodb://127.0.0.1:27017/?authSource=admin" \
  --username=backupUser \
  --nsInclude="school.*" \
  "./school_backup/school"

The tool prompts for the password. The backupUser account must have the permissions required to restore the selected data.

The example assumes the account is defined in the admin database. Change authSource if the account is defined elsewhere.

Do not store real passwords in source code, shared scripts, or publicly accessible files. Protect backup files because they may contain sensitive information.

By default, mongorestore merges restored data into the destination. The --drop option drops each destination collection before restoring its corresponding collection from the dump.

mongorestore \
  --uri="mongodb://127.0.0.1:27017" \
  --drop \
  --nsInclude="school.*" \
  "./school_backup/school"

Warning: This command can delete existing destination collections before restoring their backed-up versions. Test it on a separate database first, verify the backup, and confirm the target before using it.

The --drop option affects collections represented in the restore input; it is not a general command to empty every database on the server.

Sometimes you need to restore a backup into a test database instead of the original database.

The --nsFrom and --nsTo options can map the original namespace to a new namespace.

mongorestore \
  --uri="mongodb://127.0.0.1:27017" \
  --nsInclude="school.*" \
  --nsFrom="school.*" \
  --nsTo="school_test.*" \
  "./school_backup/school"

This maps collections from the school database to the school_test database, allowing you to test a restore without targeting the original database.

Verify the source dump and destination namespace before running the command.

After restoration, connect to MongoDB Shell and inspect the destination database.

mongosh

use school

show collections

db.students.find().limit(10)

You can also count the documents in a collection:

db.students.countDocuments({})

Compare the results with the backup expectations. Check important collections, indexes, document counts, and application functionality. A few visible documents alone do not prove that the entire backup was restored.

• mongorestore not found: Install MongoDB Database Tools and check PATH.
• Connection refused: Verify that MongoDB is running and that the host and port are correct.
• Authentication failed: Check the username, password, and authentication database.
• Permission denied: Ensure the account has the required restore privileges.
• Wrong backup path: Confirm that the directory or archive exists and contains valid dump data.
• Duplicate key errors: Check for existing documents with conflicting unique identifiers or indexes.
• Missing expected records: Check the namespace filter, source backup, and restoration output for errors.

1. Create a backup of the school database.
2. Restore it to a test database named school_test.
3. Display the collections in the restored database.
4. Check the number of student documents.
5. Create a compressed archive and restore it in a test environment.
6. Try restoring only the students collection.
7. Compare the restored records with the expected backup contents.
8. Explain the difference between mongodump and mongorestore.
9. Explain the purpose and risk of the --drop option.
10. Write a short recovery checklist for your database project.