What to do when a reversed chain is broken due to full NAS?

[Jamie Pert]

Ok, let's start by saying I experience this issue quite a few times a month due to having a lot of Veeam customers with a lot of differing setups - I have NOT logged a ticket for this exact issue, but if it means I can't get a discussion and peoples opinions below I will.

The situation is as follows. Veeam backs up to a NAS via a standard reversed incremental backup job - no clever config here (storage speed and capacity is irrelevant so to speak). Veeam is running fine for months on end, then the client does something which means that suddenly their repository doesn't have enough free space for a backup to complete.

The first time I'm involved is when a backup fails, I look at logs / jobs statistics and I see that suddenly their repository didn't have enough free space for a backup to complete (usually because someone has dumped some large files on the NAS, but sometimes because backup jobs haven't been well thought out (too many restore points for repository to allow for, growing virtual infrastructure etc).

A retry attempts to rollback the changes, but free space limits the jobs ability to do this. Before I know it I have a broken backup chain.

So I move the non Veeam files of the NAS, giving me let's say 600GB of free space, however the job tells me the last backup needs to be a full, so I now need to run an Active Full to in effect start a new chain - which requires ~1TB. What do I do? trimming off oldest retention / restore points doesn't free up enough space.

I know the bigger picture is to eliminate the possibility of the NAS filling up, but what remedial actions should I take when such an issue does occur?

[PTide]

Hi,

A retry attempts to rollback the changes, but free space limits the jobs ability to do this

So, you've already tried to re-run your job after you obtained enough space on your repo, correct? If that did not help to repair the chain, then please open a case with support and have your logs ready. Logs can be exported via "Help - Support" menu. There is not much we can do here to help you without logs.

Thank you.

[foggy]

Basically, backup file has some redundancy in it to provide restorability of the last known good state (as well as of any previous successful restore point) in such situations. So backup chain should not be corrupt and should be repaired during the next job run, unless some other reason prevents this, which should be investigated by support.