Ops Manager can store snapshots in an S3 or S3-compatible object store by writing snapshot data as blocks to an S3 bucket and tracking metadata in the Ops Manager application database. With immutable S3 snapshots, Ops Manager integrates with S3 Object Lock or an equivalent to provide the following capabilities:
Store snapshot data and backup metadata together in the S3 bucket.
Protect snapshot objects from deletion or modification until a defined retention period expires, enforced by the object store.
Import snapshots from an Object-Lock-enabled bucket into a new or rebuilt Ops Manager deployment for disaster recovery or migration.
Use this feature to protect backups against malicious or accidental deletion, such as ransomware attacks or operator error. You can restore backups in a new Ops Manager instance using only what you store in S3.
Important
This feature requires Ops Manager 8.0.19 or later.
How Immutable S3 Snapshots Work
After you configure an S3 snapshot store with an Object-Lock-enabled bucket and enable immutable backups:
Ops Manager writes snapshot blocks and the metadata required for restore into the S3 bucket, instead of keeping metadata only in the Ops Manager application database.
If configured, Ops Manager extends the Object Lock retention for each snapshot so that the object store prevents deletion or modification before the backup job retention window ends.
Ops Manager can discover and import these immutable snapshots from a pre-populated bucket into another Ops Manager instance by reading only what the S3 bucket stores.
Prerequisites
To use immutable S3 snapshots, ensure you have the following:
Ops Manager 8.0.19 or later, which includes support for snapshot immutability and S3 import.
S3 snapshot store (blockstore) configured in Ops Manager. Immutable snapshots support only S3-based snapshot stores, not MongoDB blockstores or filesystem snapshot stores.
Object store that supports Object Lock, such as AWS S3 or compatible appliances, with Object Lock enabled on the bucket. Most S3 providers require Object versioning for Object Lock to function, and some providers allow Object Lock only during bucket creation.
Standard backup requirements, such as a MongoDB Agent with backup enabled on suitable nodes and an oplog (operations log) store for point-in-time recovery (PITR).
Important
Immutable S3 snapshots protect snapshot data only. Oplog slices used for PITR continue to use your configured oplog store, which does not support Object Lock. Using an Object-Lock-enabled bucket for oplogs might cause failures in the oplog deletion path.
Considerations
When you plan immutable S3 snapshots, consider the following items:
No retroactive immutability. Ops Manager protects only snapshots written to a bucket with Object Lock after you enable immutable backup. Ops Manager does not apply Object Lock to existing snapshot objects.
Object Lock configuration. Ops Manager does not provide immutability for S3 buckets that do not support Object Lock. You must configure Object Lock on the bucket separately. Configuring Object Lock settings in Ops Manager or updating bucket settings after creation does not enable Object Lock on the bucket.
No automatic migration of existing data. The Migrate Backup Between S3 Stores feature lets you change which S3 snapshot store a backup job uses for future snapshots. It does not copy or move existing snapshot data between buckets.
Retention and Object Lock on managed stores. When a snapshot ages out according to the backup job retention policy, Ops Manager stops exposing it and attempts to delete related objects. Ops Manager can delete the objects only after the Object Lock retention period expires.
Retention on imported stores. Ops Manager never deletes data from imported stores. Retention affects only metadata visibility in Ops Manager.
Configure Immutable S3 Snapshots
To configure immutable S3 snapshots, complete the following tasks:
Enable immutable backups in Ops Manager.
Create an Object-Lock-enabled S3 bucket.
Configure a new S3 snapshot store in Ops Manager.
Switch existing backup jobs to the immutable S3 store.
Enable Immutable Backups
A feature flag in Ops Manager controls immutable backups. You must enable this flag before you configure the S3 snapshot store.
Create an Object-Lock-Enabled S3 Bucket
Note
You cannot enable Object Lock for an existing S3 snapshot store in Ops Manager. If you already use an S3 bucket for backups but need immutable snapshots, create a new bucket with Object Lock enabled and configure a new S3 snapshot store.
Configure a New S3 Snapshot Store in Ops Manager
This snapshot store serves as the target for immutable snapshots. Ops Manager writes both snapshot blocks and metadata for backups that use this store into the bucket.
Note
You still need a MongoDB instance to act as a metadata store for Ops Manager operations.
Switch Existing Backup Jobs to the Immutable S3 Store
For each backup job you want to protect with immutable snapshots:
When you switch stores:
Existing snapshots remain in the old store. Ops Manager does not move snapshots taken before the switch. They remain in the original S3 bucket and restore from that store until they expire based on your configured retention policy.
The first snapshot on the new store is full. This guarantees that Ops Manager stores all blocks for that snapshot in a single S3 snapshot store. Each restore fetches data from exactly one store.
Subsequent snapshots are incremental. Snapshots after the first full snapshot on the new store use incremental backup behavior.
Import Snapshots for Disaster Recovery
If you need to restore data from a pre-existing S3 bucket that contains immutable snapshots and backup metadata, you can import those snapshots into an Ops Manager deployment. Use this workflow for disaster recovery scenarios, such as restoring backups after rebuilding Ops Manager.
Important
Imported snapshots are for one-time restore operations only. Ops Manager does not manage the lifecycle of imported snapshots or include them in active backup schedules.
Ops Manager never deletes or grooms data from imported stores. You control the lifecycle of imported snapshot objects at the object storage layer.
Interactions with PITR
Point-in-time restore (PITR) combines a baseline snapshot with oplog data stored in an oplog store. Immutable snapshots affect only the baseline snapshot component:
When you switch to an immutable S3 snapshot store, PITR continues to work from existing snapshots and oplog data. Old snapshots remain in their original store, and the oplog store configuration does not change.
After the first full immutable snapshot completes on the new store, PITR can use that snapshot as the baseline and continue tailing oplogs from your configured oplog store.
PITR is not available for imported snapshots. You can restore imported snapshots only to the exact point when Ops Manager created the snapshot.
Failure Scenarios and Recovery
Immutable S3 snapshots do not introduce additional data-loss scenarios when you switch snapshot stores. Each snapshot restores from a single store, so restore logic does not require data from multiple buckets for one snapshot.
Crash Before the First Snapshot on the New Store
All existing snapshots remain in the original S3 store and are fully restorable.
PITR works from the most recent completed snapshot and oplog data.
Crash During the First Full Snapshot on the New Store
Ops Manager marks the in-progress snapshot to the new store as failed or incomplete and does not use it for restores.
The last successful snapshot in the original store remains the latest restorable snapshot.
After Ops Manager and the cluster recover, Ops Manager schedules a new full snapshot to the immutable store at the next snapshot window.
Because the first snapshot on the new store is always a full snapshot and each snapshot restores from a single store, restore logic does not depend on mixing data from multiple S3 buckets for a single snapshot.