Backup and Restore

A backup you have never restored is a hope. The Database Tools from Compass and Tools give you one you can rehearse in seconds: mongodump writes BSON plus per-collection metadata, mongorestore reads it back. Both need --authenticationDatabase admin once authentication is on.

mongodump --uri="mongodb://127.0.0.1:28110/shop?directConnection=true" \
  -u rootops -p Str0ng-Root-Pass --authenticationDatabase admin --out=bk/2026-09-22 --gzip
mongorestore --uri="mongodb://127.0.0.1:28110/?directConnection=true" \
  -u rootops -p Str0ng-Root-Pass --authenticationDatabase admin --gzip \
  --nsFrom='shop.*' --nsTo='shop_restored.*' bk/2026-09-22

2026-09-22T11:58:12.581+0800   done dumping `shop.orders` (5 documents)
2026-09-22T11:58:19.483+0800   finished restoring `shop_restored.orders` (5 documents, 0
  failures)
2026-09-22T11:58:19.484+0800   restoring indexes for collection `shop_restored.orders` from
  metadata
2026-09-22T11:58:19.624+0800   6 document(s) restored successfully. 0 document(s) failed to
  restore.

The dump mirrors the namespace: orders.bson.gz holds the documents, orders.metadata.json.gz the collection options and index definitions. Restoring under a different database name, which --nsFrom and --nsTo do by rewriting namespaces on the way in, is what makes the rehearsal safe — db.orders.getIndexes() on shop_restored reports ["_id_","sku_1"], so the indexes came back with the documents.

Three limits decide whether mongodump is enough. It reads through the normal query path, so dumping a busy collection competes with your application for cache and I/O — point it at a hidden secondary. It is not point-in-time: --oplog captures the window the dump spans so mongorestore --oplogReplay can roll forward to a consistent instant. And it scales with data size, so past a few hundred gigabytes use volume snapshots or managed continuous backup. Users live in admin.system.users, which a --db shop dump omits: back up admin too.