<!-- llms-explorer concept facts · https://llms-explorer.com/tree/continuous-cloud-backup-pitr/ · pack 2026-10-23 · ~1656 tokens -->

# Continuous Cloud Backup (PITR)

> Source-anchored research for Continuous Cloud Backup (PITR). Run status: COMPLETED.

Parent: [MongoDB Backup and Restore](https://llms-explorer.com/tree/mongodb-backup-and-restore/) · 4 facets · 16 facts · page: https://llms-explorer.com/tree/continuous-cloud-backup-pitr/

## How it works

- Atlas states PITR can achieve an RPO as low as one minute. The one-minute Date & Time and one-second Oplog Timestamp input granularities do not guarantee zero data loss: recent writes that have not fully persisted to the oplog when restore starts may fall outside the recoverable window. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)

## Problems, failure modes and limitations

- Atlas configures the PIT restore window in Backup Policy, and the window cannot exceed hourly snapshot retention. Disabling Continuous Cloud Backup deletes its continuous backup history. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)

## Comparisons and alternatives

- MongoDB says enabling Continuous Cloud Backup increases monthly cluster cost. OhChimp's article, updated 2026-10-03, gives an AWS us-east-1 example: 115 GB of combined snapshot and oplog storage costs $106.25 per month under its tiered schedule versus $16.10 for snapshot-only storage (6.6x). The article says the ratio varies by region, provider, and backup-set size, so this is not a universal price multiplier. (medium confidence) (verified as of 2026-10-03) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)
- A March 14, 2024 report using Terraform provider 1.1.1 says changing the mongodbatlas_cloud_backup_schedule while cluster Cloud Backup and PIT flags remained enabled returned a 400 error: “Continuous Cloud Backup cannot be on without an hourly policy item.” The issue is stale and closed as not planned, so it documents a version-specific report rather than a verified current limitation. (low confidence) (verified as of 2024-03-14) — [source](https://github.com/mongodb/terraform-provider-mongodbatlas/issues/2029)
- Atlas documents a version-mismatch restriction: a Continuous Cloud Backup snapshot cannot be restored when its MongoDB version differs from the target cluster's current version. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)

## Facts and statements

- Atlas Continuous Cloud Backup supplements Cloud Backup with PITR by retaining the cluster oplog alongside snapshots. Atlas restores the nearest earlier snapshot and replays oplog entries to the requested time within the configured PIT restore window. (high confidence) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)
- MongoDB states that Continuous Cloud Backup can provide an RPO as low as one minute inside the configured restore window; that recovery-point target does not promise a fast restore. (high confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/atlas/architecture/current/backups.md)
- Atlas limits the configured point-in-time restore window to no longer than hourly snapshot retention; independent backup guides describe the same cap. (medium confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)
- Atlas warns that disabling Continuous Cloud Backup deletes its continuous history. It also excludes times between restore initiation and completion of a new snapshot, and recent writes that have not fully persisted to the oplog may fall outside the recoverable window. (low confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)
- A low RPO does not imply a low RTO: Atlas replays operations after restoring the preceding snapshot, while restore duration and post-restore performance depend on backup size, replay volume, and cloud-provider disk warming. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/backups.md)
- MongoDB's July 7, 2026 product update marked direct database- and collection-level restores from point-in-time Continuous Cloud Backups generally available, including restore into a running cluster with overwrite or new-namespace options. (medium confidence) (verified as of 2026-10-11) — [source](https://www.mongodb.com/products/updates/now-ga-collection-and-database-level-restores-in-atlas/)
- A first-person August 9, 2026 migration report says that moving from Atlas to a self-hosted replica set removed Atlas continuous backups and left production without snapshots or an off-box copy while replacement work was deferred; this single case supports treating backup replacement as a migration task. (low confidence) — [source](https://takiuddin.me/blog/a-backup-you-havent-restored-isnt-a-backup/)
- A MongoDB Community answer dated January 9, 2024 says that with a Backup Compliance Policy enabled, Atlas retains snapshots after cluster termination according to the backup policy and keeps the Continuous Cloud Backup oplog static only until Atlas can no longer use it for Continuous Cloud Backup. The answer recommends contacting support and does not establish an indefinite restore guarantee. (low confidence) (verified as of 2024-01-09) — [source](https://www.mongodb.com/community/forums/t/does-mongodb-atlas-retain-snapshots-for-deleted-clusters/261309/2)
- Atlas supports Date & Time restore input at one-minute granularity and Oplog Timestamp input at one-second granularity. OneUptime's March 2026 article also shows an Atlas CLI pointInTime restore command with a timestamp and target cluster. (medium confidence) (verified as of 2026-03-31) — [source](https://www.mongodb.com/docs/atlas/recover-pit-continuous-cloud-backup.md)
- Atlas describes PITR restore RTO as typically minutes to hours. Actual restore time depends on backup size, oplog replay volume, and cloud-provider disk warming. (high confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md)
- Percona Operator for MongoDB 1.23.1 documents that its PITR option affects only backups taken after enablement. This is a Percona-specific prerequisite and should not be assumed to describe Atlas behavior. (low confidence) (verified as of 2026-10-05) — [source](https://docs.percona.com/percona-operator-for-mongodb/1.23.1/backups-configure.html)
