Study guide
8.3 Backup, Restore & Performance Telemetry
MongoDB Associate Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Document Model & MongoDB Architecture
1.1 Document Model Fundamentals & BSON Data Types 1.2 Databases, Collections & Schema Flexibility 1.3 Distributed Architecture Fundamentals: Replica Sets & Sharded Clusters
2 Chapter 2: CRUD Operations: Create & Read
2.1 Document Insertion Operations 2.2 Query Selectors & Filter Operators 2.3 Array Queries & Element Evaluation 2.4 Projections, Cursor Methods & Collation
3 Chapter 3: CRUD Operations: Update & Delete
3.1 Field Update Operators 3.2 Array Update Operators & Positional Modifiers 3.3 Document Replacement & Deletion Operations 3.4 Atomic Find-and-Modify Operations
4 Chapter 4: Aggregation Framework Mastery
4.1 Pipeline Fundamentals & Core Stages ($match, $project, $addFields) 4.2 Grouping, Reshaping & Array Manipulation ($group, $unwind, $replaceWith) 4.3 Multi-Document Joins & Faceted Pipelines ($lookup, $facet, $bucket) 4.4 Materialization & Window Operations ($out, $merge, $setWindowFields) 4.5 Atlas Search: Search Index Definitions & $search Queries
5 Chapter 5: Indexing Strategies & Performance Optimization
5.1 Index Types & Storage Mechanics 5.2 Compound Indexes & the Equality-Sort-Range (ESR) Rule 5.3 Multikey Indexes & Array Indexing Constraints 5.4 Specialized Index Types: TTL, Partial, Unique & Text 5.5 Query Optimization & Explain Plan Analysis
6 Chapter 6: Data Modeling & Schema Design Patterns
6.1 Embedding vs. Referencing Tradeoffs 6.2 Core Schema Design Patterns 6.3 Schema Validation with JSON Schema
7 Chapter 7: Application Development & Driver Integration
7.1 Connection Strings & Connection Pool Management 7.2 Driver CRUD Paradigms & Object Mapping 7.3 Cursor Batching, Streaming & Memory Handling 7.4 Write Concerns, Read Concerns & Retryable Operations
8 Chapter 8: Developer Tooling & Administration Essentials
8.1 mongosh Scripting & Administrative Commands 8.2 Data Ingestion & Export Utilities 8.3 Backup, Restore & Performance Telemetry 8.4 Atlas Sample Dataset & Data Explorer
8.3 Backup, Restore & Performance Telemetry
Key Takeaways Explain This Topic AI
mongodump and mongorestore are binary backup and restoration utilities that export and ingest raw BSON (.bson) and index metadata (.metadata.json), preserving 100% type fidelity and index definitions.
Point-in-time consistent backups of live replica sets are achieved using 'mongodump --oplog' and restored via 'mongorestore --oplogReplay' to replay operations captured during the backup window.
Key backup flags include --archive (single consolidated stream), --gzip (compression), --nsInclude/--nsExclude (namespace filtering), and --drop (drops target collection before restore).
mongostat monitors real-time, second-by-second cluster operational telemetry, including CRUD rates, WiredTiger dirty/used cache percentages, active connections, and queued operations.
mongotop profiles read and write time utilization per collection, instantly identifying database I/O hotspots.
Last updated: September 2026
8.3 Backup, Restore & Performance Telemetry
Maintaining data durability, executing rapid disaster recovery, and diagnosing real-time performance bottlenecks are fundamental responsibilities in MongoDB database administration and application development. MongoDB provides a comprehensive suite of binary backup tools and command-line telemetry utilities:
mongodump & mongorestore : High-performance binary BSON backup and restoration utilities that preserve exact data types, index definitions, and collection metadata.
mongostat : Real-time server telemetry monitor that reports live CRUD operation throughput, active connections, lock queues, and WiredTiger cache pressure.
mongotop : Real-time profiling monitor that tracks CPU and lock time utilization on a per-collection basis.
1. Binary Backups: mongodump & mongorestore Fundamentals
Unlike mongoexport (which generates lossy, human-readable JSON or CSV text files), mongodump creates a binary BSON dump of the database. It connects directly to a running mongod or mongos instance, reads the raw documents, and outputs binary .bson files alongside .metadata.json files.
- Structure of a mongodump Output Directory
- By default, mongodump creates a directory named dump/ containing subdirectories for each database: dump/
- ├── ecommerce/
- │ ├── customers.bson <- Raw binary BSON document records
- │ ├── customers.metadata.json <- Index definitions, collection options, collations
- │ ├── orders.bson
- │ └── orders.metadata.json
- └── admin/
- ├── system.users.bson
- └── system.users.metadata.json
- Advantages of Binary BSON Dumps
100% BSON Type Fidelity : Types like Decimal128 , 64-bit Long , ISODate , ObjectId , and Binary are preserved bit-for-bit without string conversion or lossy float casting.
Index Definitions Restored Automatically : The .metadata.json files contain the full index specifications (compound indexes, partial indexes, TTL settings, unique constraints, and custom collation rules). mongorestore automatically rebuilds these indexes.
Storage Efficiency : Binary BSON combined with in-line compression ( --gzip ) is significantly smaller and faster to process than text-based JSON exports.
- 2. Advanced mongodump Capabilities & Point-in-Time Consistency
- The Critical --oplog Option for Live Consistent Snapshots
In an active production database, client applications continuously execute write operations while mongodump is running. If a dump takes 30 minutes to complete, documents dumped at minute 1 may reference documents modified or deleted by minute 29, resulting in an inconsistent backup snapshot.
To achieve Point-in-Time Consistency , mongodump provides the --oplog flag: # Capture a point-in-time consistent binary backup of an active replica set
- mongodump --uri="mongodb://primary.example.com:27017" \
- -oplog \
- -archive=./prod_backup_$(date +%Y%m%d).archive.gz \
- -gzip
How --oplog Works Internally:
When mongodump starts, it records the current timestamp on the primary's Oplog ( local.oplog.rs ).
It dumps the collection documents while simultaneously tailing and capturing all write operations recorded in the oplog during the dump window.
It writes these operations into an oplog.bson file in the root of the dump output.
When mongorestore is executed with --oplogReplay , it restores the collections and then applies the captured oplog entries up to the completion point, bringing the entire dataset into a mathematically consistent, point-in-time state.
Caution
--oplog Requirements: The --oplog option only works against replica set nodes (or master-slave instances) and only when dumping the entire cluster/server (you cannot use --oplog when specifying an individual collection via --collection ).
Essential mongodump Flags
Flag Purpose & Description
--archive=<filePath> Consolidates the entire backup into a single archive file instead of a folder hierarchy. If specified without a path ( --archive ), streams binary data directly to stdout .
--gzip Compresses BSON files or the archive stream using GZIP on the fly, dramatically reducing disk usage.
--nsInclude="<db>.<coll>" Granular namespace inclusion filter supporting wildcards (e.g., --nsInclude="sales.*" or --nsInclude="*.orders" ).
--nsExclude="<db>.<coll>" Granular namespace exclusion filter (e.g., --nsExclude="analytics.audit_logs" ).
--oplog Captures the oplog during the dump window to produce a point-in-time consistent snapshot.
3. Restoration Strategies with mongorestore
mongorestore reads binary BSON archives or directories produced by mongodump and writes the documents, collections, and index specifications back into a target MongoDB cluster.
Essential mongorestore Flags
--drop : Drops each collection from the target database before restoring it from the dump. This prevents duplicate key conflicts against preexisting documents.
--oplogReplay : Replays the oplog.bson captured during a mongodump --oplog backup to guarantee point-in-time consistency.
--nsInclude / --nsExclude : Selects specific namespaces to restore from an archive.
--nsFrom and --nsTo : Remaps namespaces dynamically during restoration (e.g., restoring data from production to a staging database).
--noIndexRestore : Restores collection documents without building secondary indexes. Useful for staging environments where developers want to inspect raw data immediately or build indexes in the background later.
--numParallelCollections <N> / -j <N> : Sets the number of collections to restore concurrently (defaults to 4).
- Practical mongorestore Commands # 1. Restore from a compressed single archive file with drop and oplog replay
- mongorestore --uri="mongodb://localhost:27017" \
- -archive=./prod_backup_20260902.archive.gz \
- -gzip \
- -drop \
- -oplogReplay
- # 2. Namespace Remapping: Restore 'production' database dump into 'staging'
- mongorestore --uri="mongodb://staging.example.com:27017" \
- -archive=./prod_backup.archive.gz \
- -gzip \
- -nsFrom="production.*" \
- -nsTo="staging.*"
- # 3. Restore a specific collection from a directory dump
- mongorestore --uri="mongodb://localhost:27017" \
- -db=ecommerce \
- -collection=customers \
- -drop \
- ./dump/ecommerce/customers.bson
- 4. Real-Time Operational Telemetry: mongostat
mongostat is a live diagnostic tool that provides a high-level, second-by-second overview of the status of a running mongod or mongos instance. It is analogous to the Unix vmstat or iostat utility.
- Running mongostat # Poll the database every 1 second (default)
- mongostat --uri="mongodb://localhost:27017"
- # Poll every 5 seconds, displaying 10 total iterations
- mongostat --uri="mongodb://localhost:27017" 5 10
Interpreting mongostat Output Columns insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time
*0 12500 *0 *0 0 150|0 2.1% 78.4% 0 16.4G 12.1G 0|15 1|4 4.2m 18.6m 450 2026-09-02T10:15:01Z
Column Group Metric Header Meaning & Diagnostic Significance
CRUD Rates insert , query , update , delete Number of respective operations executed per second. Asterisks (e.g., *0 ) indicate secondary replica node operations.
Cursor Batches getmore Number of getmore requests per second (fetching subsequent batches from open query cursors). High getmore relative to query indicates queries returning massive result sets.
Command Rate command Number of database commands executed per second (e.g. aggregate , findAndModify , count ). Format local|replicated in replica sets.
WiredTiger Cache dirty Percentage of the WiredTiger cache containing modified (dirty) bytes waiting to be flushed to disk. Critical: If dirty exceeds 20%, WiredTiger throttles incoming writes.
WiredTiger Cache used Percentage of configured WiredTiger cache currently occupied by data. If used exceeds 80%, background eviction threads aggressively page out clean data.
Checkpoints flushes Number of WiredTiger checkpoint flushes to disk during the polling interval. Typically 0 between 60-second checkpoint intervals.
Process Memory vsize / res Virtual memory ( vsize ) and Resident physical memory ( res ) allocated to the mongod process.
Lock Queues qr|qw Number of operations currently queued waiting for a lock ( qr = queued readers, qw = queued writers). Non-zero values indicate locking bottlenecks!
Active Clients ar|aw Number of operations currently actively executing ( ar = active readers, aw = active writers).
Network I/O net_in / net_out Network traffic entering and leaving the instance (in bytes, KB, or MB).
Connections conn Total number of open incoming client connection sockets.
Diagnostic Scenarios with mongostat
Unindexed Query Storm : query is high, res is saturated, used is near 100%, and qr spikes as CPU and memory churn searching unindexed collections.
Storage I/O Bottleneck : dirty exceeds 20%, qw (queued writers) rises steadily, and net_in drops because the disk cannot flush modified pages fast enough to accept new writes.
Connection Leak : conn continuously climbs until reaching maxConns , rejecting new client connections.
5. Collection-Level Profiling: mongotop
While mongostat monitors server-level operation counts and memory pressure, mongotop tracks the amount of time a mongod instance spends performing read and write operations on a per-collection basis .
- Running mongotop # Poll collection time utilization every 3 seconds
- mongotop --uri="mongodb://localhost:27017" 3
- Interpreting mongotop Output 2026-09-02T10:15:30Z
- ns total read write
- ecommerce.orders 1482ms 210ms 1272ms
- ecommerce.inventory 340ms 315ms 25ms
- ecommerce.customers 85ms 85ms 0ms
- admin.system.roles 0ms 0ms 0ms
ns : Target collection namespace ( <database>.<collection> ).
total : Total active time spent by mongod servicing operations on this collection during the polling interval.
read : Time spent servicing read operations (queries, aggregations, scans).
write : Time spent servicing write operations (inserts, updates, deletes).
- Diagnostic Value of mongotop
- Pinpointing Hotspots : Instantly answers: "Which specific collection is consuming 90% of our database I/O?"
Read vs. Write Characterization : Reveals whether a busy collection is read-dominated ( ecommerce.inventory spending 315ms reading) or write-dominated ( ecommerce.orders spending 1272ms writing).
6. Diagnostic Tool Comparison Matrix
Diagnostic Tool Scope of Inspection Primary Metrics Tracked When to Use
mongostat Entire mongod / mongos Server Instance Global ops/sec, CRUD rates, WiredTiger dirty / used cache %, qr|qw lock queues, conn Investigating server-wide degradation, cache pressure, or connection spikes
mongotop Per-Collection Namespace Elapsed CPU/lock time (ms) spent in read , write , and total per collection Identifying which specific collection is causing database I/O hotspots
db.currentOp() Individual In-Flight Operations / Threads opid , secs_running , planSummary ( COLLSCAN ), query filter, client IP Locating and killing specific slow or blocked queries in real time
db.stats() Database Storage Extents dataSize , storageSize , indexSize , freeStorageSize , document count Evaluating database capacity, compression ratio, and storage growth