L,immutability prevents the removal of old points immediately while storage is filling.
Probable causes
- detention
- dimensioning.
- growth.
Verifications.
- Limit the impact. — Identify whether an endpoint, service, or whole site is affected.
- Collect evidence. — Keep the exact error message, timestamp, and associated logs.
- Test the simplest hypothesis first. — Compare the affected system with a known-good path.
- Correct the confirmed cause and validate the result. — Apply one controlled change at a time and retest.
Solutions.
- Correct the confirmed cause rather than the symptom.
- Document the change and its result.
- Establish monitoring if the fault can recur.
When to escalate?
Escalate if the impact expands, data are at risk, or remediation requires an irreversible change.
Immutable repository capacity focus
An immutable backup repository cannot immediately reclaim space from restore points that are still inside their protection window. Capacity planning must therefore use the locked data horizon, incoming change rate and retention policy together.
What to verify
- Measure free capacity, daily growth and the amount of data whose immutability period has not yet expired.
- Check whether recent full backups, synthetic operations or retention changes increased consumption faster than expected.
- Confirm that old restore points are genuinely still locked rather than being retained by an unrelated job or orphaned chain.
- Review repository filesystem health and reserved space before assuming every missing gigabyte is backup data.
Resolution path
Add capacity, redirect new backup chains to another repository, or adjust future retention where policy permits. Do not attempt to bypass immutability to create emergency free space.
Validation
Confirm that projected free space remains above the operational threshold until the oldest locked points naturally expire, then monitor the next backup cycle.