Summary

  • Atlas’s Backup Compliance Policy sets a project-wide minimum and stops every user from deleting protected snapshots or shortening their retention after creation. Existing and new clusters inherit the floor.
  • Terminating a protected cluster preserves its existing snapshots according to the backup policy. Extra retention after the protected period has different deletion rights, giving the company two dates to manage rather than one reassuring age figure.

The owner gets a title, not an exception

Software buyers usually pay to give their administrators more power. MongoDB Atlas has a useful offer in the other direction: take away some power to destroy the past. Under its Backup Compliance Policy, being the project owner does not put a private shredder behind the desk.

The policy documentation bars users, regardless of role, from deleting protected snapshots or reducing their retention after they have been taken. Cloud Backup cannot simply be switched off. An individual cluster’s policy cannot fall below the project’s minimum.

That inconvenience is part of the protection purchased. A company may want its recovery history to survive an administrator’s hurried clean-up. It may want the same obstacle to confront an attacker holding that administrator’s account. Keeping an easy unilateral escape would weaken the restraint the buyer chose.

MongoDB also states the economic consequence: the policy limits the ability to lower backup storage costs by deleting copies or adjusting retention. The protection and the awkward budget conversation come from the same closed door. Finance should be in the room when the door is fitted.

The project is where the promise spreads

The documented prerequisite is a dedicated M10-or-larger cluster; this analysis concerns those Atlas Core deployments. The policy works at project level. Existing clusters are brought up to its requirements, and new clusters adopt them. A more demanding cluster policy can remain above the project floor.

That makes placement a commercial decision. Suppose a team puts a short-lived experiment in a project with a long retention requirement. The experiment can finish quickly while its protected history has much longer to run. Its project address has assigned part of the bill before anyone knows whether the experiment was useful.

Reducing a cluster’s backup frequency changes future backups and must still respect the minimum. Existing operation logs retain their original window. Changes to the protection policy apply to future snapshots; already protected history has its accepted dates.

A useful cost discussion therefore separates new commitments from the stock of old ones. Fewer promises made from tomorrow can help. They will not make every promise made yesterday expire tomorrow. The saving decision moves upstream, to the point at which a duration and a project were chosen.

A retired cluster leaves an estate

The cluster-termination procedure spells out the branches. With the protection policy enabled, Atlas keeps existing snapshots according to the backup policy after termination. Without that policy, a cluster using Cloud Backup offers an explicit choice to retain its existing snapshots. With Cloud Backup disabled, that option is unavailable.

On Atlas Core, the operation log used for point-in-time recovery can remain in a static state until it can no longer serve that recovery. This is preserved existing history. The terminated database stops producing fresh business operations.

The estate also occupies administrative space. Under the policy, a project with snapshots cannot be deleted. If all projects cannot be removed, the organisation cannot be deleted either. MongoDB says it uses the terminated cluster’s name to identify snapshots, preventing creation of another cluster with that name.

Someone must inherit the remaining copies, their dates and their bill. Active cluster hours are charged for the cluster’s working life; retained backup storage has its own cost. A storage line after retirement follows something still stored. The people reviewing it need the archive inventory, even if the product team has moved on.

Empty means the drawers are empty too

For a nonempty project, disabling the policy goes through the designated security or legal representative. That person opens a support case and completes an extensive verification process. MongoDB Support approves the request; project owners can then disable the policy. Administrative ownership and eligibility to start that request are separate jobs.

There is a precise empty-project exception. No active clusters, no paused clusters and no retained snapshots from terminated clusters may remain. An organisation owner or project owner can then disable the policy. An empty list of running databases satisfies only part of that definition while old copies remain.

The named person’s address belongs in the operating model. Setup records their name and the email address used for the support portal. A wrong address needs correction with Support. If the protection lasts longer than the employee’s tenure, the company needs a successor who can carry the process forward. The documents supply no observed customer handling time with which to price a particular request’s wait.

Keeping longer and protecting longer part company

Extra snapshot retention allows snapshots to remain beyond the protection period. During that extension, a user with the appropriate role can delete them. Atlas automatically deletes them when extra retention ends.

A copy can therefore stay on the shelf after its special deletion protection has expired. A buyer seeking resistance to an authorised user needs the protection end date. A buyer also seeking access to older history needs the extra-retention end date. A chart showing only total age buries the handover between those rights.

Overlapping schedules add another reason to inspect individual dates. MongoDB’s example combines daily snapshots kept for two days with Saturday weekly snapshots kept for three weeks. If the schedules produce the same snapshot, the longer weekly retention applies. Three weeks belongs to that example; the governing rule is precedence for the longer retention.

Counting photographs will not price the album

The dedicated-cluster cost guide describes ordinary Cloud Backups as generally incremental, with the underlying provider determining how incrementality works. Reported stored size and region feed the bill. A GB-month rate appears as daily GB-day line items, spreading the charge through time. Continuous Cloud Backups have their own rates and account for snapshots together with the internal operation log.

Certain configuration changes, failovers or underlying cloud maintenance can require multiple full snapshots. In the other direction, deleting one snapshot leaves data still referenced by others. Snapshot count multiplied by the current database size is a poor bill forecast; a proportional saving based on the number removed is equally shaky. A monetary estimate needs billed sizes, regions, retention dates and applicable rates.

This is a defensible product to buy deliberately: the company wants a past that its next administrator cannot casually erase. The purchase needs a correspondingly durable internal arrangement. Someone should still know why the copies exist and who pays for them after the service has stopped holding meetings.