v8 - Hotadd disks not removed - incremental is full size

[romwarrior]

Support case #00691918

Over the weekend my Veeam server got forcibly rebooted in the middle of an active full backup of my file server. That job failed but a retry succeeded. Since then however, VMWare is unable to commit snapshots due to a locking issue, and the Veeam server VM still has the disks from the file server attached to it. Now the incrementals of my file server are all full size and the backup of the Veeam server is giving warnings that it is ignoring the file server disks because they are independent. Any suggestions?

[romwarrior]

So manually removing the disks from the Veeam VM in vCenter has resolved the snapshot issue. I am running another incremental backup that I can already tell will be full size again. This will be the third full size backup in a row. Is this all caused by the snapshotting issue?

[Vitaliy S.]

Hi Brett,

Can you please tell me how do determine that this is full backup run? Does your job use VMware CBT?

Thanks!

[romwarrior]

I am basing it on the byte size of the files:

VBK file on 11/30 = 1,539,237,451,776 bytes
VIB file on 12/1 = 1,539,223,238,144 bytes
VIB file today at 20% job completion = 308,364,771,328 bytes

I believe it thinks it is changed/new data, though, as one my copy jobs for this VM also has a similar 1.5 TB VIB file.

Yes, CBT is on and shows as such both for the VM and for each disk.

I did reset CBT on this VM last week but I had several incrementals after that that ran like normal. This didn't occur until after my active full got interrupted this weekend. However the retry of the interrupted active full was successful.

[Vitaliy S.]

I would recommend asking your technical engineer about VM moref ID for these runs. Is the same as a previous one, or it has changed for some reason. If it has changed, then it is expected to have full job pass.

[romwarrior]

So the issue with full size incrementals was resolved by:

1. Manually removing the disks of the file server VM from the Veeam server VM in vCenter.
2. Manually consolidating all snapshots in vCenter.
3. Letting the incremental job run one more time. This was still full size, resulting in three full size (1.5 TB) backups in a row.
4. The second run of the incremental job after consolidating snapshots was normal (4 GB).

However, now my offsite copy jobs are trying to move this supposed "new" data created by these full size incrementals. With the connection that I have this would take at least a week, which won't work. So since I can't reseed an existing copy job (right?) it looks like I will have to create and seed a new copy job which starts my GFS clock all over. Is there any way to avoid resetting all my GFS data? Is there any talk of a future version allowing to reseed an existing copy job so as not to lose GFS info?

[foggy]

Is there any way to avoid resetting all my GFS data? Is there any talk of a future version allowing to reseed an existing copy job so as not to lose GFS info?

I can't think of any. Though you're not "losing" GFS points, they will just not be handled by the job automatically anymore, but can be kept for the required amount of time and then removed manually.

[romwarrior]

Thanks, Alexander. I know I don't lose any restore points but it's frustrating to now have to handle them all manually now.

[veremin]

Hi, Brett, we're aware of that problem, and going to address it in one of next product updates. Thanks.

[romwarrior]

Good to hear, Vladimir. Thanks.

[veremin]

You're welcome. Feel free to contact us, should other help be required. Thanks.