When you’re running MongoDB in production, backups are non-negotiable. But not all backup strategies are equal. The gap between a good backup strategy and a bad one only becomes visible at the worst possible moment: when you actually need to restore.
Many teams reach for the most familiar tools first: Volume snapshots or mongodump/mongorestore + a cron job and a prayer. These approaches may work for a single server, but as your deployments grow in complexity, their limitations start to bite. Percona Backup for MongoDB (PBM) was built specifically to address those limitations.
Cloud volume snapshots are fast, cheap, and largely automatic. But they have a fundamental flaw when used with MongoDB: a snapshot captures the state of a disk at a moment in time, but the database must perform crash recovery before it becomes available. This is generally safe, but it is not equivalent to a clean shutdown. Unless the database is quiesced first (which means stopping writes and using a file system freeze), a snapshot is unlikely to represent a consistent state. On a standalone MongoDB, you might get away with it, however in a replica set or sharded cluster, it becomes dangerous. Writes that were acknowledged with weaker write concerns (for example w:1) may be missing from the backup.
In addition to that, in a sharded environment each shard is an independent replica set. A snapshot taken across multiple volumes at slightly different moments will capture different points in time for each shard. The result is a backup that, when restored, can contain orphaned or missing documents, or data that violates cross-shard consistency — problems that may not surface until well after a restore.
mongodump is a useful tool, but it has significant limitations as a primary backup strategy for production replica sets, especially in sharded clusters. It’s best suited for logical exports, migrations, or smaller deployments rather than large-scale disaster recovery.
Because it performs a full logical export of all data, backup times increase with database size, making it impractical for multi-terabyte deployments. It also generates significant disk, CPU, and network I/O, lacks native incremental backup capabilities, and by itself cannot provide point-in-time recovery.
In sharded clusters, obtaining a consistent backup requires careful coordination across all shards and the config servers, adding operational complexity.
Restore times are another problem. A logical restore via mongorestore parses and reinserts documents one by one. For large datasets, this can take hours or even days — far longer than the recovery time objective most organizations can tolerate.
Neither of these tools was designed for continuous, automated, point-in-time recovery in a modern production environment. That’s exactly the gap PBM fills.
PBM is a distributed, highly available backup solution built natively for MongoDB replica sets and sharded clusters. It runs as a lightweight agent on every node in the cluster, allowing backup operations to be coordinated across the deployment rather than relying on a single backup host.
Logical and physical backups can be taken from secondary nodes, keeping the load off the primary and minimizing the impact on application performance. If some replica set members are unavailable, PBM can automatically select from other eligible nodes to complete the backup, helping ensure backup operations continue without manual intervention and increasing the overall resilience of the backup process.
When performing a backup of a sharded cluster, PBM coordinates across all shards to ensure they all capture data at exactly the same logical point in time. It achieves this by leveraging MongoDB’s cluster time and oplog coordination to guarantee cross-shard consistency — something neither snapshots nor mongodump can reliably provide.
Rather than waiting for a scheduled backup window, PBM streams the oplog from every shard or replica set member to your backup storage every few minutes. This continuous streaming dramatically shrinks your Recovery Point Objective (RPO).
Your recovery options are not limited to fixed snapshots taken every 6, 12, or 24 hours. Instead, you can restore to any arbitrary second within your retention window. If a bad deploy starts corrupting data, you can pinpoint the exact moment it started and recover to just before it.
In addition to logical backups, PBM can perform physical backups by copying the underlying WiredTiger data files directly, rather than re-reading documents through the query layer. This makes both backup and restore significantly faster than a logical approach with mongodump/mongorestore.
Large datasets that would take hours to restore logically can be recovered in a fraction of the time, directly shrinking your Recovery Time Objective (RTO). While physical backup capabilities are available only in upstream MongoDB Enterprise, PBM brings this backup approach to the broader MongoDB community.
mongodump remains a practical choice for migrating small datasets or exporting specific collections. Snapshots have a place as a secondary safety net or for infrastructure-level disaster recovery. But as a primary backup strategy for a production MongoDB deployment, neither gives you the consistency, automation, or recovery granularity that modern applications demand.
PBM was purpose-built to meet those demands. Consistent sharded backups, high availability with no single point of failure, continuous oplog streaming, and physical backup speeds combine to deliver a backup solution that can genuinely support aggressive RPO and RTO targets.
If you’re running MongoDB in production and you’re not using PBM, it’s worth asking whether your current backup strategy would actually hold up when it matters most.
Resources
RELATED POSTS
