In Atlas Backup, how do scheduled cloud snapshots differ from continuous cloud backup?

## What Atlas Backup actually is On dedicated clusters, Atlas Backup is built on **cloud-provider volume snapshots** taken from a cluster node's disk, stored by Atlas in the cloud provider's region. You do not run a dump; you define a policy and Atlas executes it. A backup policy is a set of policy items, each with a frequency and a retention: - hourly snapshots retained for a couple of days, - daily snapshots retained for a week or a month, - weekly and monthly snapshots retained for longer. Retention is per item, which is how you build a tiered ladder without keeping everything forever. Snapshots can additionally be **distributed to other regions**, which is what makes a regional outage survivable rather than merely a machine failure. Free and low-end tiers do not get this. Backup planning in Atlas effectively starts at the dedicated tiers, and "we're on the free tier and assumed backups were on" is a real incident cause. ## Snapshot-only versus continuous With snapshots alone, the only recoverable states are the instants the snapshots were taken. If snapshots are hourly and a bad migration runs at 10:40, you can go back to 10:00 and lose forty minutes of legitimate writes. **Continuous Cloud Backup** closes that gap. Atlas captures oplog entries continuously, so a restore can name any timestamp inside the configured **restore window**: Atlas takes the nearest preceding snapshot and replays oplog up to your chosen moment. The window is a configuration choice with a cost — you are paying to retain oplog, so it covers recent history rather than the full snapshot retention. You can point-in-time restore inside the window; outside it you are back to snapshot boundaries. The practical rule: snapshot frequency sets how much data you can lose in the far past, the continuous restore window sets how precise you can be in the recent past, and neither affects how long the restore takes. ## Restoring Atlas offers three shapes of restore: 1. **Restore into a new cluster.** The safest option during an incident, because production stays up while you inspect the restored copy. 2. **Restore over an existing target cluster.** Atlas replaces that cluster's data. Destructive by design, and the wrong choice if you are still diagnosing. 3. **Download the snapshot.** For offline forensics or moving data out of Atlas. Two constraints bite in practice. First, **restore duration scales with data volume** — a multi-terabyte cluster is not restored in minutes, so your recovery-time expectation must be measured, not assumed. Second, **restores are cluster-wide**. Atlas has no per-collection restore: if someone drops one collection, the standard play is to restore the snapshot into a *new* cluster and copy that collection back into production, which is far less disruptive than rolling the whole cluster backwards and discarding an hour of unrelated valid writes. ## Guardrails A **Backup Compliance Policy** turns backup settings into a floor rather than a preference. Once enabled at the organization level, it enforces minimum retention and prevents deleting snapshots, shortening retention, or disabling backup — including by users who otherwise have full project rights. That is what makes the backup resistant to an attacker or a careless administrator, and disabling it deliberately requires going through MongoDB support. Anyone answering a ransomware question about Atlas should reach for this. ## What it does not give you - It is not an export. Snapshots are Atlas-managed artifacts; if your requirement is a copy outside the vendor, that is a separate pipeline. - `mongodump` is not a substitute at production scale: it is a logical read of live data through the query path, it competes with your workload, and its consistency guarantees are much weaker than a coordinated snapshot. - Backup is not high availability. Replica-set redundancy handles node loss; backup handles the classes of failure replication faithfully copies — a bad deploy, a dropped collection, a corrupting bug, a malicious wipe. ## Sanity checks to mention Say out loud that a backup policy nobody has restored from is a hypothesis. Periodically restore a snapshot into a scratch cluster, time it, and assert on the data. That exercise is what converts "we have hourly snapshots and continuous backup" into a defensible statement about how much you would lose and how long you would be down. Also confirm that snapshots exist in a second region if regional failure is in your threat model, and that anyone who can trigger a restore is a small, audited set of people.