Backup recover from backup repository run out os space

[massimiliano.rizzi]

==================================================
Support case ID #5206746
==================================================

Hello,

we are successfully running in production Veeam Backup & Replication 6.1 for VMware (build 6.1.0.181). We have set up a job to back up virtual machines in the production environment using Direct SAN Access to the VMFS datastores and a combination of active full backups performed on Saturday and forward incremental backups performed Sunday through Friday.

Sadly on Sunday, July 15 our EMC CLARiiON AX4-5F Dual SP enclosure suffered an unexpected shutdown (that we have investigated with EMC Technical Support) while Veeam Backup & Replication 6.1 was about to complete the weekly active full VMware backup resulting in an corrupted/inconsistent weekly .vbk file. As a result we managed to remove the latest corrupted/inconsistent .vbk file from disk manually and started a new chain with an active full backup scheduled on Monday, July 16 @ 11pm and subsequent forward incremental backups performed from Tuesday, July 17 through Friday, July 20.

As for our current backup job settings, a new chain has also started on Saturday, July 21 with an active full backup scheduled @ 11pm and a subsequent forward incremental backup has been successfully performed on Sunday, July 22 as expected. Sadly we forgot to unselect “Monday” within the “Perform active full backups periodically” -> “Weekly on selected days” job properties window resulting in a new active full backup being started yesterday @ 11pm instead of a forward incremental backup as usual and in our on disk backup repository running out of space. Once again we have managed to remove the latest corrupted/inconsistent .vbk file from disk manually (the 406 GB .vbk file in the screenshot I have attached to this s.r.).

Since we already have a consistent weekly .vbk file on disk (as a result of the new chain started on Saturday, July 21 with the active full backup started @ 11pm) can I feel free to go ahead with subsequent forward incremental backups, or should I once again start over with an active full backup ?

Thank you for your support and for your patience.

Regards,
Massimiliano

[massimiliano.rizzi]

Hello Foggy,

thank you for your prompt reply.

I was afraid the only solution would have been to start a new chain with an active full backup.

It's my bad, I did not unselect “Monday” within the “Perform active full backups periodically” -> “Weekly on selected days” job properties window resulting in a new unwanted active full backup being started yesterday.

Have a great day !

Massimiliano

[foggy]

Massimiliano, I've deleted my previous post as it was not accurate enough. Most likely the job will fail at the next run due to missing vbk file (as you've deleted it manually). To avoid running a new active full, you can try to remove the backup chain from backups using the corresponding option in the Veeam B&R console and then map the job to existing backup files on disk. I'm not sure however, whether it does the trick, need to test (depends on the fact whether the record about failed active full is stored in vbm file). Otherwise you still can perform a new active full to start the chain from scratch.

[foggy]

Seems my initial assumption was, for all that, correct. No way to avoid a new full in your case, the job automatically starts a new full in case of the previous full backup failure (nevermind the vbk file was manually deleted). And mapping would not help here either.

[massimiliano.rizzi]

Hello Foggy,

thank you very much for writing further and for the additional details for each reply.

I did not have the opportunity to test in our lab environment whether in case of a previous full backup failure a new full could be avoided using the steps described in your previous reply, I have always managed to start a new chain from scratch especially when dealing with our customers data.

As for your last reply, I understand that starting a new chain from scratch is the only solution.

Again, thank you for your patience and for the details provided in each reply.

Regards,
Massimiliano