## 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.

```text
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/pst_Fw_aU0HHJlbO-AUxbWlupg