mongodump และ mongorestore สำหรับการสำรองข้อมูลทั้งหมด

mongodump creates a binary BSON snapshot of a database or collection. Unlike mongoexport, which produces human-readable JSON, mongodump preserves all BSON type information exactly—ObjectIds, dates, decimals, binary data—with zero loss of fidelity. This makes it the correct tool for full database backups and migrations between MongoDB clusters, while mongoexport is better for selective data sharing.

Running mongodump without arguments dumps all databases from the local MongoDB instance to a dump/ directory. Specify --uri, --db, and optionally --collection to narrow the scope. The output directory contains one subdirectory per database, each with .bson and .metadata.json files per collection.

Use --collection to dump only one collection from a database. This produces a single .bson file and its corresponding .metadata.json (which stores index definitions). Targeted collection dumps are useful for extracting a single collection for migration without backing up the entire database.

Large BSON dumps can consume significant disk space. Use --gzip to compress the output files as they are written. Each .bson file becomes a .bson.gz file, typically achieving 5-10x compression for typical document collections. Compression runs in the mongodump process and requires a matching --gzip flag in mongorestore to decompress.

Use --archive to write the entire dump to a single archive file instead of a directory tree. You can also pipe it to gzip or aws s3 cp for one-step compressed backup and upload. This is the most compact and portable dump format for automating backups in CI or cron jobs.

mongorestore reads a directory or archive created by mongodump and inserts the documents into a target MongoDB cluster. It recreates collections with their index definitions (from the .metadata.json files) after the data is loaded. Specify the target cluster with --uri and the source directory or archive with --dir or --archive.

By default, mongorestore restores to the same database name as in the dump. Use --nsFrom and --nsTo (namespace from/to) to restore to a different database or collection name. This is essential when cloning production data into a staging database with a different name.

Like mongoimport, mongorestore has a --drop flag that drops each collection before restoring it. Without --drop, mongorestore merges restored documents with any existing data—useful for partial restores. With --drop, you get a clean replacement of the collection, which is safer for full database restores to avoid stale data mixing with the backup.

For databases with many collections, mongorestore can restore multiple collections in parallel. Use --numParallelCollections (default: 4) to increase parallelism on servers with high I/O capacity. More parallel restores reduce total restore time but increase memory and CPU usage on both the client and server.

Automate daily backups by running a shell script from a cron job. The script creates a timestamped backup directory, runs mongodump, compresses the result, and optionally uploads it to S3 or another remote storage. Always verify the exit code of mongodump to detect failed backups before the previous backup is overwritten.

MongoDB Atlas provides automated Point-in-Time (PIT) backups that capture snapshots every 6 hours and allow restore to any second within the retention window (up to 35 days on M10+ tiers). Atlas backups do not use mongodump—they leverage filesystem-level snapshots at the storage engine level for zero-impact backups. For self-hosted MongoDB, mongodump is the primary backup mechanism, but it is a logical backup and cannot capture in-flight transactions.

In this lesson you learned: mongodump creates binary BSON backups preserving all type information, mongorestore reads those dumps and recreates collections with their indexes, and --drop, --nsFrom/--nsTo, and --gzip are essential flags for production backup workflows. Next up we write Node.js seed scripts to programmatically load data into MongoDB during development.