Backup & Restore overview
Backup on FPT MongoDB Enterprise is built from four pieces. Unlike some engines, the first two are already switched on for you — but that still does not mean your data is protected.
| Piece | What it does | On its own |
|---|---|---|
| Backup service | Reserves storage capacity and holds the policy every job uses | Backs up nothing |
| Backup job | The schedule that actually produces restore points | This is what creates recoverable data |
| PITR | Retains archived logs so you can recover to an exact moment | Needs a full backup, and takes effect from the next one onward |
| Restore | Creates a new cluster from a restore point or a moment in time | Never overwrites the original |
Backup and PITR are enabled by default when a MongoDB Enterprise cluster is created, but no data is protected until a backup job exists and has completed at least one run. Check the Backup tab of a new cluster before assuming it is covered.
What is on by default
When you provision a MongoDB Enterprise cluster, the backup and PITR services are enabled as part of creation. This differs from other FPT Database Engine engines, where both need enabling explicitly.
What is not automatic is the backup job — the schedule that produces restore points. Confirm one exists and has run.
Where to go next
| You want to | Go to |
|---|---|
| Check or change the backup schedule and retention | Change backup schedule |
| Recover the state captured by a backup | Restore from backup |
| Recover the state at an exact moment | Recover to point in time |
Recovery always creates a new cluster
Both recovery paths build a new cluster rather than repairing the existing one. Two consequences worth planning for:
- You need quota for a second cluster at the very moment you are recovering, which is the worst possible time to discover you are at your limit.
- Afterwards, repoint your application. Recovery never moves the endpoint for you.
What it costs
Backup storage is billed separately from the cluster. PITR adds to that, because archived logs are retained alongside the backups. Both are worth estimating up front, since capacity applies across every backup job on the cluster rather than per job.
Next steps
- Change backup schedule to confirm a job exists
- Notification so backup failures actually reach someone
- Restore from backup when you actually need to recover