CBT and Hot Add failing after Instant VM Recovery

[dellock6]

Thanks Anton, so my test today was correct in showing the error with FLR.
The workaround is ok having multiple install, but for example my customer is the usual VMware Essentials + Veeam Essentials, and with only one Veeam backup server that acts also as proxy. Going for the reboot by now.
I follow rawtaz on asking: is it something will go out in Patch 4?

[Gostev]

We did not plan any more patches releases because currently it is looking like there are no major issues left to justify the release. Particularly, the issue discussed in this topic has a number of simple workarounds as mentioned above. So, the current plan is to fix this in the next minor release (6.1 in Q2). However, as always, depending on the number of support cases, specific issues may get private hotfixes before that (unlike patch release, those have very little impact on R&D). Thanks!

[vlinteractive]

I have installed the new patch on a new Veeam server, with the exact same configurations, but it didn't take long for this error to come back and haunt me... Please help, this is giving me nightmares and my boss is unhappy.

This can be fixed in the Backup Proxies section. Right-click on your proxy appliance(s), properties, then under 'transport mode', click 'choose', then switch it from Automatic to Network. This will stop the hot add warnings when you run backups (which are totally harmless, btw, but still annoying).

[dellock6]

On the other hand, you will loose performances failing to network mode. I would personally try to fix the error, rebooting the veeam server after a FLR, or disabling it as a proxy if it's a multi-server setup. Obviously waiting for the fix in the next release...

[smile_dav]

This can be fixed in the Backup Proxies section. Right-click on your proxy appliance(s), properties, then under 'transport mode', click 'choose', then switch it from Automatic to Network. This will stop the hot add warnings when you run backups (which are totally harmless, btw, but still annoying).

Yes, I know there's this workaround, but from a client's point of view, it doesn't make sense to them to lower their backup performance just because they want to restore a few files. Rebooting is probably the sensible workaround, but it's not viable in the long term.

I think it might also be a good feature in the coming release to set backup modes in each jobs?

[Gostev]

No, it does not make any sense whatsoever with the new architecture where jobs are no longer tied up to proxies. We'd rather just fix the issue in question in the next release (by the way, there is a hotfix already available through our support).

[GabesVirtualWorld]

Hi
How can I disable the local Veeam Backup Server as proxy? The only way I seem to be able to do this is by excluding it from each replication job.

Running into the hot add issue with my replication jobs What is the speed difference between hot add and network backup? I have a backup server and a proxy on my local site, replication over 10Mbit connection to remote site. How much difference in through put would I see?

Gabrie

[dellock6]

Hi Gabrie,
proxy role on the Veeam Server cannot be disable, there are many tricks to avoid it from using itself, like declaring it that it can only manage some "weird" datastore so it will never be invoked. To date this is the best choice I found, and I also asked fot the future the ability to have the Veeam Server acting only as a central console without proxy or repository roles.

About the speed, do you placed also a second proxy in the remote site? Difference can be felt if you have faster connections, but with 10 mbits wan this is the bottleneck whatever backup mode you choose.

Luca.

[GabesVirtualWorld]

Current setup:
Local site = Veeam Backup Server + Proxy with 4GB / 4vCPU
Local site = Proxy with 4GB / 4 vCPU
WAN link 10Mbit
Remote site = 1st Proxy with 4GB / 4 vCPU
Remote site = 2nd Proxy with 4GB / 4 vCPU

[foggy]

Don't forget also to specify the source-side repository to store replica metadata!

[GabesVirtualWorld]

Don't forget also to specify the source-side repository to store replica metadata!

Eeeuh.... What???

[foggy]

Replication does require a repository to store metadata. As explained in the UI when creating replica job, backup repository should be located closer to the source. Placing the metadata in the remote site slows down the replication process significantly (depending on the metadata size and the link speed) as the source agent pulls it over WAN.

[Gostev]

Default proxy can be easily disabled via PowerShell. There is a thread about this somewhere around here.

[GabesVirtualWorld]

Replication does require a repository to store metadata. As explained in the UI when creating replica job, backup repository should be located closer to the source. Placing the metadata in the remote site slows down the replication process significantly (depending on the metadata size and the link speed) as the source agent pulls it over WAN.

Ah ok, the default backup repository is used which is located on the C-drive of the Veeam Backup Server and has 36GB Free disk space.

[chrisdearden]

Default proxy can be easily disabled via PowerShell. There is a thread about this somewhere around here.

http://vpowercli.net/2011/12/09/disable ... -v6-proxy/

[GabesVirtualWorld]

Thx

[marcottt]

Hi,
a customer say same problem when restore a single file.
Waiting for a patch.

Marco

[Gostev]

Hi Marco, our support has had the hotfix for this in hands for a few weeks now...

[dellock6]

I can confirm the issue was generated using FLR and not by Instant Recovery, and since we got the patch the error went away.

[lhenshaw@advizex.com]

Hi all... was a patch released yet for this?

[Gostev]

See my previous post