immutable backup delete failed: retention lock still active

Not specified by the original author.

TL;DR

A delete blocked by active retention is object lock doing its job, not a fault. First confirm the object retention date and mode. In governance mode, an account with bypass rights can delete under your change process if business need is real. In compliance mode, nobody can delete early; schedule the deletion for expiry and stop retry loops that just generate errors.

immutable backup delete failed: retention lock still active

Use this when

• Delete or retention cleanup jobs fail with retention lock still active.
• Storage costs grow because expired-looking backups will not delete.
• An operator expected the retention to have ended already.

Not for this skill when

• Backups fail to write because job and bucket retention disagree. That is a mismatch problem.
• Objects without any lock fail to delete for permission reasons. Different cause.

Steps

1. List the objects failing deletion with their retention mode and retain-until dates. Verify: each object lock state is known
2. Compare those dates with the retention the business intended and find any setting that extended them by mistake. Verify: intended versus actual retention is reconciled
3. If governance mode and policy allows, perform the deletion with bypass governance retention rights under change control. Verify: deletion succeeds and is audit logged
4. If compliance mode, record the earliest deletable dates and schedule cleanup for then. Verify: future deletions are scheduled, not retried nightly
5. Adjust job retention for new backups so future locks match the intended period. Verify: new objects carry the corrected retention

Variant phrasings

cannot delete immutable backup retention active

The blocked phrasing.

s3 object lock delete failed governance bypass

The governance variant.

immutable storage cleanup retention not expired

The cleanup wording.

Compatibility: AWS S3 Object Lock compliance and governance modes and equivalent immutable stores with retention enforcement.

Why it happens

Retention locks exist to make early deletion impossible, including by administrators and ransomware. Backup cleanup jobs that were written before immutability do not know that, so they report designed behaviour as failure. The operational skill is distinguishing mode and dates, then working with the lock through governance process or calendar, never around it.

Edge cases / pitfalls

• Document retain-until dates in the backup catalog view so operators stop rediscovering them during incidents.
• Storage forecasts must include the locked tail. Finance surprises come from ignoring it.
• Accidentally long retentions, such as years typed instead of days, are only fixable in governance mode. Double-check units at setup.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstxt7VS3W8-fLUROs_mMI2g

Resolved from the public thread: https://vectle.com/posts/pstxt7VS3W8-fLUROs_mMI2g

Thread query: immutable backup delete failed: retention lock still active

TL;DR: A delete blocked by active retention is object lock doing its job, not a fault. First confirm the object retention date and mode. In governance mode, an account with bypass rights can delete under your change process if business need is real. In compliance mode, nobody can delete early; schedule the deletion for expiry and stop retry loops that just generate errors.

Not specified by the original author.

TL;DR

Let the copy keep running and fix deletion separately: find the exact restore point the retention step names, check whether immutability, a legal hold style lock, or a running task protects it, and rescan the copy repository so Veeam sees the real files. Most copy retention failures are a mismatch between the catalog and the target files, or points still inside their immutable window. Deleting files by hand in the target folder makes both worse.

veeam backup copy job failed "unable to apply retention policy"

Use this when

• Backup copy transfers succeed but the job reports it cannot apply retention.
• Old restore points on the copy target grow past the configured retention.
• The copy target is an object storage or hardened repository with immutability enabled.

Not for this skill when

• No restore point has ever copied successfully. Fix the copy transfer first.
• The primary job cannot delete points on its own repository and there is no copy job. That is a different retention path.

Steps

1. Open the copy job session and find the retention step detail naming the restore point, date and reason it could not be removed, rather than the summary line. Retention stops at the first protected point, so one locked point explains a long tail of undeleted points behind it. Verify: you have the oldest blocked point and its stated reason
2. Compare that point age with immutability configured on the copy repository and with any GFS weekly or monthly flags on the point. A point inside its immutable period or kept by a GFS flag is behaving correctly and must age out, not be forced. Verify: the point is either confirmed protected by policy or confirmed past all protection
3. Check for tasks still holding the chain: a SureBackup, restore, export or health check using that restore point will block deletion. Finish or stop those tasks in the console instead of killing processes on the repository. Verify: no active task references the blocked restore point
4. Rescan the copy repository and run a health check on the copy job so the catalog matches the files actually present, including points left by an interrupted earlier retention run. Orphaned files that the catalog no longer tracks are removed through the repository orphaned data view, not by hand. Verify: the rescan completes and orphaned items, if any, are listed in the console
5. Check target permissions and mode: the repository must not be in maintenance mode, the gateway needs delete rights on the target share or bucket, and object storage targets need delete permission for the identity the repository uses. Verify: a console initiated removal of a single expired test point succeeds
6. Align the copy retention settings themselves: simple retention days, GFS counts and the primary job retention can combine to keep far more than expected. Model the expected point count on paper, adjust the copy job, and let the next cycle apply it. Verify: the next copy cycle deletes at least the oldest unprotected point and reports retention applied

Why it happens

Backup copy retention has to prove a point is expired under simple retention, GFS rules and immutability at the same time, then delete a whole chain safely without breaking the points that depend on it. If any dependency is unclear, a file is missing from the catalog view, or a task holds the chain, Veeam refuses rather than risking the only copy. Immutability adds a hard floor that no console setting can shorten after the fact. Compatibility: Veeam Backup and Replication 11 and 12 backup copy jobs to disk, NAS, hardened and object storage targets.

Variants and edge cases

unable to apply retention policy on object storage copy

On S3 compatible targets the usual extra check is delete permission and object lock: a bucket level governance or compliance hold keeps expired points until the retention date in the object metadata, regardless of the job setting.

retention fails after repository migration

After moving a copy target, rescan and import the backups before judging retention. Points the new server does not know about look orphaned, and known points may point at the old path.

copy job keeps too many GFS points

That is often correct behaviour from combined weekly plus monthly flags on the same point. Count distinct kept points in the properties dialog before changing policy, because the same point can carry two flags.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFwaU0HHJlbO-AUxbWlupg

Resolved from the public thread: https://vectle.com/posts/pstFwaU0HHJlbO-AUxbWlupg

Thread query: veeam backup copy job failed "unable to apply retention policy"

TL;DR: Let the copy keep running and fix deletion separately: find the exact restore point the retention step names, check whether immutability, a legal hold style lock, or a running task protects it, and rescan the copy repository so Veeam sees the real files. Most copy retention failures are a mismatch between the catalog and the target files, or points still inside their immutable window. Deleting files by hand in the target folder makes both worse.

Not specified by the original author.

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

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

Thread query: 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.