# Flex backup and recovery planning > Source-anchored research for Flex backup and recovery planning. Run status: COMPLETED. Parent: [Flex Limitations and migration to Dedicated](https://llms-explorer.com/tree/flex-limitations-and-migration-to-dedicated/) · 4 facets · 22 facts · page: https://llms-explorer.com/tree/flex-backup-and-recovery-planning/ ## How it works - Flex does not support custom snapshot policies or on-demand snapshots. MongoDB recommends M10 or larger when finer-grained backups are required. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) ## Problems, failure modes and limitations - Atlas automatically backs up Flex clusters, and users cannot disable those backups. (high confidence) (verified as of 2026-10-15) — [source](https://www.mongodb.com/docs/atlas/backup-restore-cluster.md) - A September 6, 2025 forum author reported disabled Flex backup downloads and unexpected snapshot dates. The visible thread supplies no diagnosis or resolution, so it cannot establish failure frequency or a current product-wide defect. (low confidence) — [source](https://www.mongodb.com/community/forums/t/backups-disabled-and-with-wrong-date-on-flex-tier/328367) - An April 2025 user reported recovering manually with mongodump and mongorestore after a restore error. This is a single experience, not proof of a generally required Flex recovery procedure. (low confidence) — [source](https://www.mongodb.com/community/forums/t/can-i-downgrade-from-dedicated-to-flex-clusters/319319) - Flex backups are automatically enabled and cannot be disabled; Atlas takes one daily snapshot, beginning 24 hours after cluster creation. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - Do not promise that a Flex snapshot can be restored into another Flex cluster without testing: the backup overview says Flex or M10+ targets are supported, while the restore page explicitly says snapshots cannot be restored to a Flex target. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup-restore-cluster.md) - Planning inference: one daily snapshot without PITR cannot promise recovery to an arbitrary recent moment. A roughly one-day recovery-point gap assumes successful daily snapshots; it is not a guaranteed maximum data-loss bound, and a newly created Flex cluster has no scheduled snapshot during its first 24 hours. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) ## Comparisons and alternatives - Flex snapshot storage location can differ from deployment location: MongoDB maps Hong Kong to Australia and locations outside its listed groups to Ireland. Review this mapping when recovery planning includes residency constraints. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - For a Flex recovery runbook, define acceptable data loss (RPO) and downtime (RTO), restore into a separate test resource, validate accessibility and data integrity, and measure elapsed time through validation. AWS and IBM independently recommend regular restore tests against recovery objectives; this is general methodology rather than evidence of Atlas-specific features. (high confidence) — [source](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_backing_up_data_periodic_recovery_testing_data.html) - Planning inference: document and test the recovery destination and retained history rather than assuming a backup meets requirements. IBM explicitly checks frequency, retention and restore-region restrictions, and AWS calls for identifying backup locations and assessing recovery capability against RPO and RTO; IBM service-specific limits must not be transferred to Atlas. (high confidence) — [source](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_backing_up_data_periodic_recovery_testing_data.html) - Flex cannot perform Atlas primary-failover tests or simulate regional outages. Recovery rehearsals should therefore include actual snapshot restores and application validation rather than relying on these unavailable Atlas test controls. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/reference/flex-limitations.md) ## Facts and statements - The Flex-specific backup page specifies one daily snapshot starting 24 hours after cluster creation, retaining the latest eight; Prisma describes the same schedule and retention. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - Flex has no custom snapshot policies, on-demand snapshots, Continuous Backup, or point-in-time restore. MongoDB recommends M10 or larger for finer-grained backups. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - Planning inference: compare acceptable data loss with the latest completed daily snapshot, and allow for the initial 24-hour gap. Daily scheduling alone does not establish a guaranteed 24-hour RPO or a recovery-time guarantee. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - Flex snapshots restore only to replica sets, not sharded clusters; a sharded recovery destination therefore requires another tested recovery path. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - The Flex backup page requires Project Owner access, including for Organization Owners managing backups. It says Atlas CLI snapshot support is unavailable; the Go SDK reference separately exposes Flex snapshot listing, download, and restore-job API operations. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - Atlas's cluster-level restore procedure deletes existing target data and leaves the target unavailable during restoration. Recovery drills should use a disposable target. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-snapshot.md) - Validate backups through periodic restores, query restored data for completeness and usability, and compare measured recovery time and data age with RTO and RPO. AWS supplies independent recovery-testing guidance; AceMQ also recommends restore testing. (medium confidence) — [source](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_backing_up_data_periodic_recovery_testing_data.html) - Historical bug TOOLS-3822 silently skipped namespaces containing newline characters. MongoDB identifies Flex snapshots taken before July 17, 2025 as affected during restore or download. Database Tools 100.12.2 fixed mongorestore; the issue says Atlas's backend was upgraded. Treat this as a scoped historical defect, not evidence that current Flex snapshots generally lose collections. (low confidence) (verified as of 2026-07-02) — [source](https://jira.mongodb.org/browse/TOOLS-3822) - Flex does not support Continuous Backup or point-in-time restore. For a recovery requirement that depends on PITR, MongoDB recommends switching to Dedicated; the Flex backup page separately recommends M10 or larger for finer-grained backups. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/reference/flex-limitations.md) - The Flex-specific backup page documents retention of the last eight daily snapshots and supports downloading them. This retention statement conflicts with the general restore page, which says Flex allows only two snapshots; verify the available history before committing to a retention requirement. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md) - The Flex backup page requires Project Owner access to manage Flex backups and says the Atlas CLI does not support Flex backup snapshots. Establish and test the actual operator access and recovery interface in advance. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md)