Start with what is happening now. Each answer gives us a more useful next step.
First, protect the recovery points you already have
You may wish this had been caught earlier. Right now, the useful question is what recoverable data exists today. Do not manually delete backup files or format the destination to make room. Many backup products rely on chains of files; deleting one can affect more than one restore point.
Find the last successful backup
In the backup application, record the exact error, last successful job, most recent available recovery point, destination and current free space. Check whether this is the only copy or one of several. “Job succeeded” is a starting point; a test restore provides stronger evidence.
Is there a recent recovery point?
Preserve it while you investigate retention, capacity and growth. If possible, validate a small restore without altering the source.
Treat this as a recovery gap. Check other destinations, snapshots and offsite copies before changing this job. Escalate promptly if important data is at risk.
Why did the space run out?
Compare the expected retention policy with the actual number and size of recovery points. Look for a sudden increase in protected data, a new volume, failed cleanup or a job writing to the wrong destination. Avoid assuming the oldest visible file is safe to remove.
Choose a safe next action
The remedy depends on the backup product and chain: adding capacity, correcting retention, moving a repository, or creating a new destination may each be appropriate. Follow the product’s supported procedure and confirm a new backup and a test restore afterward.
What to tell us
Send the backup product and version, exact error, last success time, destination capacity and free space, retention settings, and a screenshot of available recovery points. We will establish what can be restored before changing the chain.