Reverse incremental job out of space

[ortoscale]

Hi there.

My client run out of space on volume used for weekly backups. Job was set as reverse incremental. It looks like VBR got corrupted because of this. Message: Could not perform threshold check for backup location "\\srvsur-nas3\Vol3" due to space info retrievement fail!
Failed to delete oib******************************************23T180153.vrb' Undir failed Client error: Zlib decompression error: [-3
Unfortunately we cannot open support case at the moment, client didn't extend support. Do you think that out of space could corrupt main VRB file? Any ideas?

best regards, Matjaž

Veeam B&R 6.5 is used is this case.

[veremin]

Such error might indicate the problems with underlying device used as repository. You can try either to perform new active full or temporarily switch to other repository and see whether the problem persists.

Thanks.

[ortoscale]

Such error might indicate the problems with underlying device used as repository. You can try either to perform new active full or temporarily switch to other repository and see whether the problem persists.

Thanks.

Hello. Same underlying hw is also used as NFS and it looks healthy. Only problem was that volume runs out of space. Can that break VBR? Best regards.

[foggy]

Do you get this message for the CIFS-type repository? Does the client have Veeam B&R Patch#1 installed? Similar issue has been resolved there so probably it is worth updating. And of course, add some storage to the repository or adjust retention settings to avoid out of space issues.

[ortoscale]

Hello foggy.
I've just upgraded to the latest 6.5 patch 3. Volume is extended to 2,5 TB now, so we have 0,5 TB of free space. I'm performing backup repository scan right, now but it's already taking 23 minutes and counting ... How long can that take, any other ideas perhaps? Thanks, Matjaž

[ortoscale]

scan was finished at 24 minutes will report back.

[ortoscale]

same error: Zlib decompression error
I've tried to restore files from this particular backup - this backup is performing on a weekly basis for weeks - 1 year - and guess what, it looks like past backups are usable. I have no problem with duplicating a job and doing new backups with new job as long as I have past data available to restore if needed. Any ideas how this is possible. Maybe that zlib decompression error doesn't indicate overall corruption of VRB or corruption at all?

best regards, Matjaž

[foggy]

Did your job fail when you got this message?

[ortoscale]

Did your job fail when you got this message?

Yes. job completely failed.

[veremin]

Maybe that zlib decompression error doesn't indicate overall corruption of VRB or corruption at all?

Typically, it does. May be at some point backup chain became corrupted and the backup job couldn't proceed any longer. So, in this case, new active full backup seems like a valid remedy. Thanks.

[foggy]

Basically, due to some redundancy in how backup file is created and updated, you can always restore to the last known good state as well as any previous successful restore point. So failure of your job means that the new restore point was not created, however all previous are restorable.

[ortoscale]

Yep and I like that fact.
It does look like corruption was caused by 0 space on the volume not device failure. Older backups are still usable. I will create new jobs and move on with backups. Case closed.

[ortoscale]

Typically, it does. May be at some point backup chain became corrupted and the backup job couldn't proceed any longer. So, in this case, new active full backup seems like a valid remedy. Thanks.

active full didn't work.

[veremin]

Did It also fail with zlib decompression error? If so, can you try to backup to different repository and see whether it makes any difference? Thanks.