When Ceph S3 Object Lock belongs in your backup and records design
Object Lock lets an S3 bucket on Ceph RGW refuse deletion or overwrite of an object for a set retention period, which is the control a team needs when backups or regulated records must stay unchanged even if an administrator account or stolen credential is misused. The feature is exposed through the S3-compatible API of the Ceph Object Gateway, so applications and backup tools that already speak S3 can request protection without a new client. Whether it belongs in your design depends on what you must protect, for how long, and who can change the rules. The Ceph Object Gateway documentation describes the S3-compatible API surface and the surrounding features, but the exact Object Lock behavior, including which retention modes exist, how legal holds work, what default retention rules can be set, and how versioning interacts with locked objects, depends on the Ceph release you run. Confirm those details against the documentation for your release (Tentacle or Squid, or an older release still in service) and test them on a non-production cluster before you write them into a retention policy. Do not rely on a summary, including this one, for the semantics an auditor will test.
Decide early which data needs the lock and which does not. Backup repositories, archive copies and records with a legal retention obligation are the usual candidates. Working data that changes often is a poor fit, because locked objects cannot be cleaned up until retention expires, and the storage cost of holding them grows with the retention period. Ask your backup software vendor whether it writes to S3 Object Lock buckets, which headers and settings it sends, and how it handles a lock it did not expect. Then confirm the retention period with the owner of the records or the backup policy, not with the storage team. Object Lock is one layer of a ransomware-resistant backup target, not the whole design. Plan separate credentials for the backup writer and the people who administer the cluster, limit who can change bucket configuration, and keep a copy of backup data outside the blast radius of the cluster itself. Test a restore from a locked bucket on a schedule, because a lock that protects bad data for years does not help if the restore path has never been exercised.
Object Lock configuration options and when each fits
This table compares the Object Lock choices a team makes on a Ceph RGW bucket, from enablement at creation to legal hold. Read each row for the use case it suits and the points to confirm in the Ceph release documentation before you commit a bucket to a design. Most of the risk sits in choices that cannot be changed later, so settle those first.
| Option | What it controls | When it fits | What to confirm before choosing |
|---|---|---|---|
| Bucket-level enablement at creation | Whether Object Lock can be used on the bucket at all, set when the bucket is created | Backup targets and records archives that must be immutable from the first object written | Whether your Ceph release lets you enable Object Lock on an existing bucket, and the exact client flags required at creation |
| Bucket versioning | Keeps every object version so locked versions are preserved alongside newer writes | Any bucket where a retention rule must protect overwritten or deleted data | How versioning must be enabled for Object Lock in your release, and how it interacts with lifecycle expiration rules |
| Default retention rule per bucket | Applies a retention mode and period to new object versions that do not specify their own | Backup targets where the backup software may not set retention on every object | Available retention modes in your release, how defaults apply to multipart uploads, and who is allowed to change the default |
| Per-object retention set by the writing application | Sets retention on each object version at write time, overriding the bucket default | Application-controlled retention, such as records systems that know each document's required hold period | Whether your backup or archive tool sends retention headers, and how the client library signs and validates them |
| Legal hold | Blocks deletion of a specific object version independently of any retention period | Litigation, investigations or audits where data must stay immutable until a hold is released | Whether legal hold is supported in your release and the API calls needed to set and release it, plus who holds release authority |
| Retention mode behavior | Determines whether a locked version can be shortened or removed by privileged users | Stricter records retention where administrators must not bypass the lock | Differences in how each mode can be bypassed, and whether bypass requires a specific permission in your release |
| Governance and access model | Who can write, read, extend or bypass locks through RGW users and policies | Multi-team clusters where backup operators and storage administrators have different roles | Which IAM and bucket policy actions govern lock changes, and how these map to your authentication setup |
How bucket versioning and retention rules interact on RGW
Object Lock on an RGW bucket depends on versioning, so the first decision is whether the bucket is versioned before any retention is set. Retention is attached to a specific object version, not to a key name. On a versioned bucket, a delete request normally adds a delete marker and leaves the earlier versions in place, which is why a locked version can survive an attempted deletion. An overwrite also creates a new version rather than replacing the old bytes, so the protected version stays readable. On an unversioned bucket the same operations can destroy data, so an immutability design that skips versioning does not protect anything. Confirm in the Object Gateway documentation for your release, either Squid or Tentacle, how Object Lock is enabled at bucket creation, whether it can be enabled later, and what the delete and overwrite semantics are for each case. Do not assume general S3 behavior carries over unchanged.
Default retention rules apply to objects written after the rule exists, not to objects already in the bucket. Teams often assume that adding a default retention period protects the existing backup set, and it does not. Existing data needs its own retention applied, or it must be copied into a bucket where the default is already in effect. Confirm in the documentation whether the default is set per bucket, whether it is a fixed period or a day count, how it interacts with a retention period set explicitly on an individual object, and which identity can change or remove a retention setting. These answers decide who can shorten protection and whether a compromised administrator account can do so.
Locked versions consume capacity until their retention ends, and the bucket keeps every version it holds. A backup job that writes a full copy each night under a 30-day lock can therefore hold far more data than the live dataset suggests. Capacity planning should size from the retained version count and the change rate, not from the current bucket size, and should allow headroom for the cluster to stay below its full thresholds. Ask the implementer for a worked calculation using your own change rate and retention period, and check it against the Ceph capacity guidance for your pool layout, including the replication or erasure coding overhead. Plan the cost of that capacity as a recurring item, because it grows with retention and does not shrink when the backup window closes.
Setting up an Object Lock bucket on Ceph RGW
This sequence takes a Ceph Object Gateway bucket from an unconfigured state to a verified immutable backup target, with each step confirmed by a check before the next one starts. It produces a bucket where locked object versions cannot be deleted or overwritten by the backup account, and a tested restore path.
Confirm release and gateway configuration
Before any bucket is created, the platform engineer confirms the Ceph release running in the cluster and reads the Object Gateway documentation for that release to check how Object Lock, bucket versioning and default retention are configured and enabled. Confirm the exact Object Lock and retention behavior with the vendor documentation for your release, not from memory of older versions. The step is done when the release version is recorded in the change ticket and the team has a written list of the RGW settings it will use.
Create a dedicated RGW backup user
The storage administrator creates a separate Object Gateway user for the backup software, distinct from administrator and general application accounts, and issues S3 access keys scoped to that user. The backup user should be able to write and read backup objects but should not hold permissions to change bucket lock settings or administer the gateway. The check is an S3 listing and a write test made with only these credentials, followed by a confirmation that administrative calls made with the same keys are refused.
Create the bucket with Object Lock enabled
The administrator creates the bucket with Object Lock turned on at creation time, using the S3 interface or an administrative client that supports the Object Lock request header. Confirm with the vendor documentation whether Object Lock must be set at creation for your release, since enabling it later may not be possible. The step is complete when a bucket-level query returns that Object Lock is enabled and versioning is active, and the result is saved with the change record.
Set a default retention rule
If your release supports a default retention rule on the bucket, the administrator sets a governance or compliance mode and a retention period that matches the backup policy agreed with the data owner. Confirm which modes your release supports and what each one lets privileged accounts do before choosing one. Verify the rule by uploading a small test object without specifying retention and checking that the object version reports the default retention mode and an expiry date. If the release does not support a default rule, the team must set retention on each object at upload and document that requirement in the backup tooling.
Write a test object and check retention metadata
The backup user uploads a test object and the team retrieves its metadata with an S3 client to confirm the retention mode, the retain-until date and the legal hold status. The administrator then reads the object's version identifier and records it. The step is done when the metadata matches the bucket policy and the object version ID is stored for the next tests.
Attempt delete and overwrite as the backup user
Using only the backup user's credentials, the engineer tries to delete the test object version and to overwrite it with new content, then tries to shorten its retention. Each attempt should be refused by the gateway with an access or lock error, and the refusals should be logged. The check is complete when all three attempts fail as expected and the object version still exists with unchanged content. Any attempt that succeeds means the configuration is wrong, and go-live must stop until the cause is found and the test is rerun from the start.
Test restore from a locked copy
Before go-live, the team restores a set of locked backup objects into a separate, non-production location using the same tooling and procedures planned for a real incident. The restored data is compared with the source using checksums or the backup tool's verification report, and the time the restore took is recorded for the runbook. The step is done when the restored data matches, the restore procedure is written down and the owners of the backup and recovery process have signed off. Confirm with the backup software vendor that its restore path works against Object Lock buckets on your release.
Security risks that Object Lock does not solve on its own
Object Lock enforces retention at the storage layer, but it only holds if the people and systems that can change retention settings, delete data or reach the cluster are controlled. The cards below cover the surrounding controls that decide whether a locked bucket stays locked.
Credential compromise of RGW users
An attacker holding the access key of an RGW user that owns a locked bucket may still be able to write new versions, change bucket settings or attempt deletions, depending on the policy attached to that user. Object Lock limits what can be removed during retention, but it does not limit who can write. Review which users hold S3 keys for backup buckets, rotate them on a schedule, and keep each backup writer on its own user with the narrowest policy that still lets it upload. Confirm with your Ceph version how Object Lock behaves for each operation you plan to allow.
Bucket policies and retention changes
Who may change default retention, lock configuration or bucket policy decides how long data is protected. A user with broad bucket permissions may be able to alter settings that a backup team assumed were fixed. Write bucket policies that deny retention and lock configuration changes to all but a small administrative group, and test those denials as part of acceptance. Document the change path so that any retention change is approved, logged and traceable.
Cephadm host and dashboard access
Anyone with root on a cluster host, or with access to cephadm, can modify daemons, configuration and the data path underneath RGW, which bypasses S3 controls entirely. The Ceph Dashboard supports single sign-on through SAML 2.0, and through OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. Review which administrators and identity groups can reach the Dashboard and the host SSH path, and restrict both to managed, audited access.
Encryption in transit between daemons
Traffic between clients, monitors, OSDs and gateways can expose object data or credentials if it crosses networks you do not control. The messenger v2 protocol on port 3300 offers a secure mode that encrypts all post-authentication traffic with AES-GCM and adds integrity checks. Confirm that secure mode is enabled for the cluster and that it works with every client type in your environment. Encryption in transit does not protect data at rest, so plan encryption for OSDs separately.
Audit logging of S3 requests
If a locked object is targeted, you need evidence of who attempted what, when, and from where. Object Lock prevents deletion but does not by itself produce a record that an investigator can use. Decide where RGW request logs are sent, how long they are retained, and who can read or alter them. Store logs in a location that the backup writers cannot modify, and test that a denied delete attempt appears in the log. Ask your team to confirm which log fields your Ceph release provides.
Where an immutable Ceph bucket fits in different backup architectures
In this pattern the backup software writes its files, or its own object format, straight into an RGW bucket over the S3 API. Object Lock is applied at the bucket level, and the backup tool's retention settings either match the bucket's default retention or set retention per object. The bucket becomes the only immutable copy, so the design depends on the tool using S3 calls that Object Lock accepts without changing the protection.
- Data flow: the backup client authenticates to the RGW endpoint, uploads objects or multipart parts, and the gateway stores each version under the lock rules in force at write time.
- Software requirements to confirm: whether the tool needs versioning enabled before it writes, whether it sends retention headers per object or relies on defaults, and whether it calls delete or lifecycle operations that a locked version cannot satisfy.
- Credential scope: the account the tool uses should be able to write but not change bucket lock configuration or remove locked versions. Confirm this with the RGW user and policy model in your release.
- Multipart and checksum behavior: confirm how the tool handles interrupted uploads, which leave incomplete parts that still consume space until cleaned up.
- Usual failure point: the tool attempts to prune old backups using delete calls, receives errors it does not handle, and either fills the bucket with retained versions or stops silently. Test a full retention cycle before go-live.
Before relying on this pattern, confirm the exact retention behavior with the backup vendor and with a restore test against your Ceph release.
Here the backup software writes to an intermediate repository, which then stores its data in the Ceph bucket. The repository may provide its own immutability features, such as write-once segments, protected snapshots or a hardened local target. Object Lock on the bucket then protects the repository's files from being deleted or overwritten during the retention window, so the two layers have to be designed together.
- Data flow: the backup server writes to a repository that packs data into large objects, and the repository pushes those objects to the bucket on a schedule.
- Layered retention: decide which layer owns the retention clock. If the repository deletes objects on its own schedule, the bucket must hold them for at least as long as the repository's recovery window.
- Software requirements to confirm: whether the repository supports S3 Object Lock as a storage target, whether it can detect lock status, and whether it requires a specific bucket layout or versioning state.
- Repository maintenance: confirm whether compaction, index rebuilds or consistency checks rewrite existing objects, since a rewrite creates new versions that the bucket must retain.
- Usual failure point: the repository's own pruning removes or rewrites objects that Object Lock has locked. The repository reports success while the bucket accumulates versions, and storage consumption rises beyond the plan.
Ask the repository vendor to document, in writing, which of its operations issue deletes or overwrites against the bucket.
In this pattern no backup product is involved. Applications, such as document systems, case management tools or audit log exporters, write records directly to a bucket that holds them for a regulatory or contractual period. The data is not a backup copy, so the design focuses on record integrity, retention classes and who can change them, and on keeping the application's own delete logic from conflicting with the lock.
- Data flow: each application writes records under a prefix or bucket dedicated to its retention class, with metadata that identifies the record and its retention end date.
- Retention classes: map each record type to a bucket or a default retention rule, and document who approves changes to those rules.
- Application behavior to confirm: whether the application deletes or overwrites records on its own, whether it uses versioning-aware clients, and whether it can recover from a refused delete.
- Legal holds and exceptions: confirm how holds are applied and removed, and who is authorized to do so, since holds sit outside the default retention period.
- Usual failure point: an application's cleanup job fails on locked objects, retries endlessly, or is patched to write to unlocked buckets to get around the error. Check that the application's error handling and change control prevent this.
Records teams should ask their assessors and counsel which retention rule applies before the first write, because the answer determines how the bucket is configured.
Limits to confirm in your environment before you rely on Object Lock
Object Lock protects data only within the behavior your chosen Ceph release actually implements, so the limits below need checking before backups depend on it. Each item is a question to answer with the Object Gateway documentation and a test cluster, not a promise about how your deployment will behave.
Supported lock modes and APIs
Confirm which Object Lock modes, retention settings and bucket-level and object-level API calls your Squid or Tentacle release supports for the S3 operations your backup software uses. Compare the release you plan to deploy with the Object Gateway documentation, then test each call your tooling makes, including how it handles a request the gateway rejects. Do not assume that a feature present in AWS S3 is present in RGW with identical semantics.
Multisite replication of locked objects
Find out how multisite replication handles locked objects, versions and retention metadata on the secondary zone, and whether a locked copy on the secondary is protected by the same rules as the primary. A replicated copy that is not locked on the second site can be deleted there, which weakens the recovery path. Test a delete and an overwrite on each zone during a controlled failover before you rely on the second site as an immutable target.
Lifecycle rules and retention
Lifecycle expiration rules can be scheduled to remove objects, and you need to confirm how they interact with retention periods. Check whether an expiration rule can delete a version that is still under a retention lock, and whether it only marks a delete marker. Review every lifecycle policy on locked buckets with your backup owner, and test the rule against an object whose retention has not yet ended.
Capacity growth from retained versions
Retained versions and delete markers consume raw capacity until their retention ends, which can change how much space your backup target needs. Estimate growth from your change rate and retention period using a test bucket, then compare it with the cluster's usable capacity and full-ratio thresholds. Ask your storage team to model this against your erasure coding or replication profile, because overhead applies to every retained version.
Release lifecycle and upgrade timing
Squid has an estimated end of life of October 31, 2026, and Tentacle has an estimated end of life of June 1, 2027. A backup target that depends on Object Lock needs a planned upgrade before its release loses support, and a test of retention behavior after each upgrade. Confirm the current dates on the Ceph releases page at the time you plan, since estimates can change.
Questions buyers ask about Object Lock cost, effort and ownership
What drives the cost of an immutable Ceph backup target?
The main cost drivers are raw capacity, the number of copies your retention policy requires, and the hardware and network design underneath the Object Gateway. Object Lock with versioning keeps every protected object version, so storage consumption grows with retention length and change rate, not just with the size of the primary data. One-time costs include hardware, the initial design, the build and the acceptance tests. Recurring costs include power, space, drive replacement, support and the staff time spent monitoring capacity. A written quote should show each of these separately, state the assumed retention period and change rate, and list which items the client buys directly and which DeployOpen delivers.
Can our own team configure Object Lock on Ceph without a partner?
Often yes, if your team already runs Ceph and understands S3 bucket configuration. Enabling Object Lock on a bucket, setting a default retention rule and applying retention to individual objects are standard S3 operations, and the Ceph Object Gateway documentation covers the supported settings. The harder work sits around that configuration: separating credentials so no single backup client can delete or shorten retention, testing that the backup software behaves correctly with locked objects, and proving recovery from a locked copy. Ask your team to confirm the exact Object Lock features in the Ceph release you run before assuming a setting is available.
How long does a scoped Object Lock build and test usually take?
Duration depends on how many backup sources write to the target, how much of the backup workflow must change, and how much testing your recovery objectives require. The build itself is usually short compared with the validation work: confirming that deletes and overwrites fail as intended, that lifecycle rules do not expire protected versions early, and that a full restore works from the locked copy. Your written scope should list the backup sources in scope, the bucket layout, the test cases and the acceptance criteria. Ask for the duration in the quote and check which assumptions it depends on, such as access to test hosts and staff availability.
What does the work need from our backup and storage teams?
The work needs time and access from both teams. Backup administrators must provide the backup software configuration, the job schedules, the retention requirements they must meet and a restore test window. Storage administrators must provide access to the Ceph cluster or a planned environment, network details, capacity figures and the change process for production. Security or compliance owners should confirm the retention period, who may approve early changes, and how key and credential administration is separated. Agree on these inputs before the engagement starts, because missing decisions about retention or credentials are the most common cause of delay.
How do retention periods and capacity affect the budget over time?
Retention is the largest variable in the running cost. A longer lock period means more object versions held at once, so the capacity you must keep free grows with each backup cycle, and the cluster needs headroom for recovery and rebalancing. Ask the quote to model capacity at the end of the retention period, not only on day one, and to state the assumed daily change rate and compression ratio. Also ask how the design handles expiry: when locked versions age out, space returns only after lifecycle processing runs. Plan a yearly review of retention and capacity with your storage owner.
Does an Object Lock design make us compliant with a retention standard?
No. Object Lock is a storage control that helps you enforce retention, and DeployOpen prepares the systems, configuration and evidence that assessors review. Only independent auditors and certification bodies issue audit reports, attestations or certifications. Ask which controls your assessor expects to see, such as how retention is enforced, how administrative access is restricted and how changes are logged, and map each one to a configuration and an evidence source. Confirm the requirements with your assessor before the build starts so the test evidence answers their questions.
What ongoing support should we budget for after the build?
After the build, the recurring work is monitoring capacity, reviewing retention settings, testing restores on a schedule and applying Ceph updates within supported release windows. Ceph's releases page states that actively maintained releases receive periodic backports and security fixes, so your plan should include a regular upgrade cycle. Support can be handled by your own team or by a retainer with DeployOpen, and the written scope should say which tasks are included, how often restore tests run and who responds to incidents. Ask for the support model and its responsibilities in writing, not only a monthly figure.
How DeployOpen scopes and delivers Object Lock on Ceph
DeployOpen plans and delivers Ceph S3 Object Lock for immutable storage inside your own infrastructure, starting from the backup and record retention rules your organization must meet. The work runs from a written, fixed scope through testing, documentation and handover, with ongoing support available as a retainer.
How we scope
- Inventory which backup tools, archives and record types will write to Object Lock buckets and their retention needs.
- Agree the Object Lock mode, default retention periods, versioning rules and who may shorten or bypass retention.
- Define the written deliverables, environments in scope, responsibilities and timeline before any configuration starts.
How we build
- Enable Object Lock and versioning on RGW buckets and set default retention rules in a staging environment first.
- Configure backup clients and lifecycle rules so that data written to protected buckets matches the agreed retention plan.
- Test deletion, overwrite and retention expiry attempts, and record the results against the scoped requirements.
How we hand over
- Document bucket settings, retention defaults, credential ownership and the steps for reviewing or changing retention.
- Provide restore test procedures so your team can prove that protected backups are recoverable within their retention window.
- Deliver evidence of configuration and test results that your auditors or assessors can review, without us issuing any attestation.
How we support
- Ongoing support, upgrades and periodic retention testing are available as a retainer after handover.
- Review Ceph release changes that affect RGW, Object Lock behavior or the backup tools writing to these buckets.
- Confirm with your team and vendors which Object Lock capabilities your chosen Ceph release supports before committing to a design.
