VBK corruption risk with backup Copy

[TAICT]

We have an environment with a daily backup schedule of 40 VM's (2TB), we use a weekly full and incrementals in between.
All the servers, backup server and main storage is in one serverroom.
We do a daily backup copy to a remote NAS over a 1Gbps link (in another building).
In the backup copy job, we set the amount of restore points to 3.
The first backup we did, was a VBK file, the next 2 backups were VIB's.
The 4th backup was a vib and after this backup, the oldest vib file was merged into the vbk file.

What happens when, at the moment of the merging, our backup environment goes down (for example, a disaster in our serverroom.
At that moment, our NAS is still up and on the NAS we have some VIB's and a VBK file that is in the middle of a writing/editing process.
Is the VBK usable when the merging/writing process is aborted abruptly because of a failure in our serverroom?
I can't find any clear information about this.
Our goal is to have a correct and consistent backup of our whole environment on the remote NAS on ANY time, also when our serverroom goes down during a backup or merging process

regards

[Shestakov]

Hello TAICT and welcome to the community!

What happens when, at the moment of the merging, our backup environment goes down (for example, a disaster in our serverroom.

In the course of backup copying once new increment is created VBR merges the oldest .vib with full backup (.vbk). During the merge process newer data blocks are being copied to the full backup. Even this process is interrupted in the middle you will still have 3 healthy restore points because the oldest .vib will not be deleted until all needed datablocks are copied to the full backup file.
Thanks!

[TAICT]

Indeed, the vib files are kept, but vib files are incremental files and rely on the VBK file. A clean .vib file alone is just delta information. You need a clean consistent .vbk + .vib file to have a valid last restore point. During the merge process, the vbk files is edited, so my question is if this .vbk file stays readable after an aborted write operation. (Without a valid .vbk, my .vib files are nothing).

[Shestakov]

All restore points will be recoverable, i.e. you will be able to restore from as many restore points as you set in the job settings (3 in your case). Since the merge is aborted you will have 4 backup files instead of 3 until the job runs again. But recoverability is not an issue here.

[foggy]

The fact is that despite the merge process is terminated, Veeam B&R knows where required blocks that consist the particular restore point are located. It is only the full restore point that is unrecoverable as some of the blocks in it are already replaced by the newer ones from the oldest increment and some are not, all subsequent restore points can still be applied to the full backup file to recover to the corresponding state.

[TAICT]

Ok, thanks for the answer.