mongodb-backups

MongoDB Backups and Restore

From running thousands of production backups. The defaults and the docs leave out the parts that bite during an actual restore.

Dump from a secondary, stream straight to object storage

Point mongodump at a secondary so the backup doesn't add load to the primary, and pipe the archive directly to S3 with no intermediate file on disk. On a replica set, --oplog captures a consistent point-in-time snapshot.

mongodump --host mongodb-secondary.internal:27017 \
  --username "$U" --password "$P" --authenticationDatabase admin \
  --db "$DB" --oplog --gzip --archive \
  | aws s3 cp - "s3://bucket/$DB/$(date +%Y%m%d_%H%M%S).dump.gz"

Keep a latest.dump.gz alias next to the timestamped file so restore scripts always know where to look.

Save a collection inventory with every backup

You cannot inspect a --gzip --archive after the fact. There is no list, peek, or inspect flag, it's an opaque binary blob, and --dryRun finishes before the archive is demuxed so it tells you nothing. So write the collection list at backup time, right beside the dump:

mongosh --quiet --host "$HOST" -u "$U" -p "$P" --authenticationDatabase admin \
  --eval "db.getSiblingDB('$DB').getCollectionNames().forEach(c => print(c))" \
  | aws s3 cp - "s3://bucket/$DB/$(date +%Y%m%d_%H%M%S).collections.txt"

Six months later when you need a selective restore, you read the file instead of trying to remember what was in the archive.

The --nsInclude trap on gzipped archives

The docs say --nsInclude filters a restore to specific collections. It does, from a directory dump (one .bson per collection). But from a --gzip --archive, which is what almost every production pipeline uses, --nsInclude (and --nsFrom/--nsTo) silently restore everything anyway and throw duplicate-key errors on the collections you never asked for. The archive is a single multiplexed stream that mongorestore can't seek, so the namespace filter doesn't hold. This is real and long-standing (JIRA TOOLS-2023, open over six years).