## TL;DR
A repository out of space stops every job pointing at it. First stop the space bleeding: check for orphaned chains, oversized synthetic operations and retention that never deletes because a chain is incomplete. Then free space safely, expand the repository or move a job, and set capacity alerts before it fills again.

```text
veeam backup failed repository out of space
```

## Use this when
- Veeam jobs fail writing to the repository with out of space.
- Repository free space in the console is at or near zero.
- Retention cleanup logs show deletions blocked or skipped.

## Not for this skill when
- A single VM datastore is full and snapshots cannot consolidate. That is hypervisor storage, not the repository.
- Object storage quota errors from a cloud tier. Those name the bucket or quota.

## Steps
1. Measure repository use by job and by chain age to find orphaned or unexpectedly large chains. Verify: the biggest consumers are listed with sizes
2. Check retention and delete orphaned backup files through the Veeam console under orphaned backups, never by deleting files in the filesystem first. Verify: orphaned data is removed through the console and space is reclaimed
3. If a chain cannot delete because it is incomplete, run the retention or remove the restore points from configuration as Veeam directs for that state. Verify: blocked deletions clear
4. Expand the repository volume, add an extent to the scale-out repository, or move one job to another repository. Verify: free space exceeds one full backup cycle plus 20 percent headroom
5. Set repository capacity warnings at 80 and 90 percent and rerun a failed job. Verify: alerts are configured and the job completes

## Variant phrasings
### veeam repository out of space retention
The retention-cause phrasing.
### veeam no space left repository fix
The plain wording variant.
### veeam scale out repository full
The scale-out specific phrasing.

Compatibility: Veeam Backup and Replication 11 and 12 repositories on Windows, Linux hardened, and scale-out repositories with performance and capacity tiers.

## Why it happens
Repositories fill predictably when data grows faster than retention shrinks, and unpredictably when failed jobs leave orphaned chains, synthetic fulls need a second full worth of scratch space, or deleted VM data stays because its chain is shared. The console free-space figure is the only safe guide because filesystem deletes desync the Veeam database.

## Edge cases / pitfalls
- Synthetic full day can need space for the new full before the old one is released. Plan for the peak, not the average.
- Forever-forward chains grow until a transform runs. Check transform schedules on space-tight repositories.
- Deduplicating storage shows logical and physical use differently. Trust the appliance physical figure for runout dates.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PQimhthV3HZkZ0Rq-XYvtw