BackupCopy of a *.vbk file interrupted and after restarting creating new *.vib files in target repository ...

[Didi7]

Hello everybody,

we have another question how to handle the following situation ...

We have several site locations connected via WAN to our central datacenter location. In each site location, we have done one full backup of each VM available, from which we would like to have a backup from (i.e. only one *.vbk file of every selected VM in the source repository).

Now these VMs (full backup *.vbk files) from every site location have been transferred from the site locations to the central datacenter location with the help of BackupCopy-jobs (using source and target WAN accelerator).

Most of the VMs have been transferred without problems and some sites have transferred all their *.vbk without problems. We added more and more VMs to the selection within each BackupCopy job for each site (those that were already done were skipped). The biggest *.vbk files are from FileServers, which we included through respective vCenter VM folders and Tag selections at the end, when all other VMs had already been replicated.

Some of the bigger FileServers took very long, so that in the period of transaction some WAN-connections broke and the job told us, that connection was refused, so that we had to re-start them, as the jobs stopped after some retries. Sometimes we had to reboot the source and target WAN accelerator in order to continue the jobs. Unfortunately it didn't work without reboots. After reboot jobs could be restarted.

The result for some site locations and their respective FileServers is, that we see more than just one file in the target backup repository, e.g. we had to restart one BackupCopy job more than 5 times to finally reach completion status for a FileServer, that is more than 4TB in size.

When we look into the target backup repository, we now have 5 files with filenames similar to ...

(Names were shortened of course)
fileserver-2026-04-09-101900.vib => OK
fileserver-2026-04-08-104614.vib => Incomplete
fileserver-2026-04-07-135905.vib => Incomplete
fileserver-2026-04-06-095004.vib => Incomplete
fileserver-2026-04-02-171123.vbk => Incomplete

Now the question is, how to fix this and to avoid re-synchronisation of the complete FileServer, so that in the end, there is only one file left?

Do we need to activate 'Perform file health check' under 'Storage-level corruption guard' to fix this and will this in the end remove all *.vib files and create one single complete *.vbk file with Status 'OK' and everyhting else for this VM gets removed automatically ?

Or is this not fixable and we have to re-sync or even worser, seed data locally in the datacenter because the size is too big?

Regards,
Didi7

[david.domask]

Hi Didi7,

First, just a quick note "Incomplete" does not mean corrupt here, so Health Check is not relevant. Incomplete means that the restore point only has partial machine data for the recovery.

Over time, this should correct itself, however, if you want to have the chains looking correct "now", starting fresh and seeding those larger File Server backups is probably your best bet.

[Didi7]

Hello David,

first of all thank you for looking into our contents again. We understand that 'Incomplete' doesn't mean corrupt and that's why we assumed, if it's only incomplete, then maybe a Health Check can create a complete full backup file. Now we know that a Health Check does not solve our current situation.

Btw, seeding the data locally is a last resort currently. We would like to avoid that.

When you say, this should correct itself, the question is how?

Would it make sense to create another incremental backup for those VMs affected from the source hypervisor and instruct the BackupCopy job to create a new SyntheticFull in order to fix the current chain of incomplete *.vbk and *.vib backups in the backup target repository?

[david.domask]

When you say, this should correct itself, the question is how?

By default, Backup Copies run with Forever Forward Incremental retention. When the merge occurs, needed data for the full backup will be retained, and eventually all those incomplete points will be merged into a full complete point. A "complete" restore point means we have all the necessary data in the backup chain to restore from that point in time; right now your most recent increment is complete, so as the older files are merged out by retention, you will end up with a complete full.

Would it make sense to create another incremental backup for those VMs affected from the source hypervisor and instruct the BackupCopy job to create a new SyntheticFull in order to fix the current chain of incomplete *.vbk and *.vib backups in the backup target repository?[/url]

Enabling GFS potentially could work by enabling GFS, yes.