immutable backup failed: object lock retention mismatch

TL;DR

Object lock retention mismatch happens when the backup tool tries to set a retention period the bucket governance, default retention or compliance mode will not accept, or shortens retention below what is already locked. Compare the bucket object lock defaults with the job retention settings, align the job to the bucket rules, and test with one small backup before resuming the full schedule.

immutable backup failed: object lock retention mismatch

Use this when

• Backup to an immutable bucket fails with object lock or retention errors.
• The job worked until retention settings changed on either side.
• New objects fail while existing locked objects sit untouched.

Not for this skill when

• Deletes fail because retention is still active. That is object lock working as designed.
• The bucket has no object lock and backups fail for other S3 errors.

Steps

1. Read the bucket object lock configuration: mode, default retention and any legal holds pattern. Verify: bucket lock rules are documented
2. Read the backup job retention and immutability period settings. Verify: job values are documented next to bucket values
3. Align the job immutability period to be within and consistent with the bucket defaults, avoiding shorten attempts on existing objects. Verify: settings no longer conflict on paper
4. Run a small test backup to the bucket and confirm the object lands with the expected lock metadata. Verify: the test object shows correct retention
5. Resume the full backup schedule and monitor the first cycle. Verify: jobs complete without retention mismatch errors

Variant phrasings

object lock retention mismatch backup immutability

The mismatch phrasing.

s3 object lock backup failed retention period

The period variant.

immutable backup job fails object lock settings

The settings wording.

Compatibility: AWS S3 Object Lock in compliance and governance modes and S3-compatible immutable stores used by Veeam and similar tools.

Why it happens

Immutability has two masters: bucket-level lock defaults enforced by the storage, and job-level retention the backup tool requests per object. When they disagree, especially on shortening or on mode, the storage refuses the write or the metadata update and the backup fails. The failure is configuration drift, not corruption, and it starts exactly when someone edits one side only.

Edge cases / pitfalls

• Compliance mode cannot be shortened by anyone, including root. Choose periods conservatively at design time.
• Test retention changes in a scratch bucket. Production immutable buckets punish experiments.
• Legal holds are separate from retention dates. A hold blocks changes even after retention expires.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SEvfDI8ZrRWd1q2MfpWTQA