Submit feedback on
Continuous Backup Enabled on Non-Production MongoDB Atlas Clusters
We've received your feedback.
Thanks for reaching out!
Oops! Something went wrong while submitting the form.
Close
Continuous Backup Enabled on Non-Production MongoDB Atlas Clusters
Hierony Manurung
CER:

CER-0326

Service Category
Databases
Cloud Provider
Service Name
MongoDB Atlas
Inefficiency Type
Inefficient Configuration
Explanation

MongoDB Atlas offers two backup mechanisms for dedicated clusters: Cloud Backups (scheduled snapshots using the underlying cloud provider's native snapshot functionality) and Continuous Cloud Backup, which adds point-in-time recovery by continuously capturing the cluster's oplog — a log of all write operations. Continuous Cloud Backup is an optional add-on for M10+ dedicated clusters that stores both snapshots and oplog data, enabling restoration to any specific second within a configurable restore window. While this capability is critical for production workloads with strict Recovery Point Objectives (RPOs), it provides limited value on development, testing, or staging clusters where data is typically transient, synthetic, or easily reproducible.

This inefficiency commonly arises when organizations apply infrastructure-as-code templates or centralized backup policies uniformly across all environments without differentiating between production and non-production recovery requirements. Because Continuous Cloud Backup continuously captures and stores oplog data in object storage, storage charges accumulate based on both the configured restore window and the volume of write activity on the cluster. Clusters with moderate to high write throughput generate proportionally larger oplogs, amplifying the cost impact. MongoDB's own architecture guidance explicitly recommends against enabling backup for development and test environments, recognizing that the cost of continuous oplog storage rarely justifies the recovery benefit for non-critical workloads.

Relevant Billing Model

MongoDB Atlas backup storage is billed separately from cluster compute costs. The key billing dimensions are:

  • Backup storage is charged per GB-month based on the total size of retained snapshots and oplog data, with rates varying by cloud provider and region
  • Continuous Cloud Backup adds incremental costs on top of standard Cloud Backup by storing oplog data in addition to snapshots — billing is based on the combined size of snapshots plus oplog storage
  • Backup charges appear as daily line items (GB-days) but represent monthly storage charges — longer restore windows result in larger oplog retention and higher costs
  • Write-heavy clusters generate more oplog data, directly increasing continuous backup storage costs regardless of whether point-in-time recovery is ever used

Backup costs can approach or equal the total storage capacity of the cluster volume depending on how the underlying cloud provider stores snapshots and the configured retention policies. For Continuous Cloud Backup specifically, Atlas calculates costs based on the combined total of snapshot and oplog size, with tiered pricing that applies after an initial free allowance (see Cluster Configuration Costs for current rates and examples).

Detection
  • Identify all MongoDB Atlas clusters designated as development, testing, staging, or other non-production environments
  • Review whether Continuous Cloud Backup (point-in-time recovery) is enabled on any non-production clusters
  • Assess whether the data stored in non-production clusters is transient, synthetic, or reproducible from other sources, reducing the need for granular recovery
  • Evaluate the write activity levels on non-production clusters to understand the relative oplog storage cost being incurred
  • Confirm whether backup configurations align with documented environment criticality and recovery requirements for each cluster tier
  • Review whether a Backup Compliance Policy is enforcing Continuous Cloud Backup across all clusters, including non-production environments where it may not be warranted
Remediation
  • Disable Continuous Cloud Backup on non-production clusters where point-in-time recovery is unnecessary — note that disabling this feature permanently deletes all existing oplog data, though snapshots remain intact
  • Retain standard Cloud Backup (scheduled snapshots) on non-production clusters where basic disaster recovery is still required, adjusting snapshot frequency and retention to match the environment's actual recovery needs
  • For truly ephemeral development environments where data recovery is not critical, consider disabling backups entirely on M10+ dedicated clusters to eliminate backup storage costs altogether
  • Differentiate infrastructure-as-code templates and backup policies by environment tier, ensuring that Continuous Cloud Backup is reserved for production or compliance-critical workloads
  • If a Backup Compliance Policy is enforcing point-in-time recovery across all clusters, work with MongoDB Support to adjust the policy scope so non-production clusters are excluded
  • Establish periodic reviews of backup configurations across all clusters to detect and correct policy drift as new environments are provisioned
Submit Feedback