Mind your backs

[cby]

Just in case someone else experiences the same nasty behind the scenes Veeam shenanigans...

Before anyone jumps up and states the obvious, i.e. why are we running 6.5 B&R, we are also running version 8 which is what caused a major problem. The v6.5 & v8 boxes are in different locations.

The details are not really relevant suffice to say the v8 box was accessing a share on the v6.5 box. I was using v8 to do a file copy of a vbk file visible only on the v6.5 box.

The file copy job in v8 set up fine. When I came to run the job it failed. Not unexpected under the comms circumstances and no big deal. I would resort to local file copy on the v6.5 to a portable NAS drive and load/restore the file on the remote v8 system. Done that a number of times with no issues since later versions of B&R are backwards compatible when it comes to restores.

However, when I went to run a long-standing backup job on the v6.5 box I saw an error along the lines of "Backup console 6.5.0.144 is not compatible with installer service on blah, blah".

My suspicions were immediately raised. Had the attempted Veeam file copy using the v8 box screwed with v6.5?

I decided to re-install the last patch for 6.5 but this made no difference. Had v8 inserted something in the Veeam SQL database? Should I re-install Veeam 6.5? -- it can't be upgraded on this box for various reasons. We have stacks of scheduled backup jobs that would all fail and commissioning a new Veeam v8 box locally at such short notice was out of the question.

I contacted Veeam support, who as always were very helpful, just to confirm the consequences of re-installing Veeam 6.5 and not losing the current backup info. I suggested that the v8 activity had silently installed/overwritten something on the v6.5 box and as a result had created a business critical problem for us, i,e, no backups or replication!

Support fellow (William) said a file had been overwritten. When I asked if I could retrieve and overwrite the guilty file with a 6.5 copy would it sort the problem. He said that he thought it would.

Anyway, I discovered that the only file with a much later creation date than the other Veeam 6.5 files was one called VeeamDeploymentDll.dll. And it was confirmed when checking the version...8.0.

I overwrote the v8 file with a 6.5 copy, and bingo! All was fine.

Point of this post is that I am not at all happy that Veeam 8 should silently overwrite a crucial 6.5 file (or any file for that matter) without at least reporting what it would like to do and asking for confirmation. At the same time it should explain the consequences of this action, i.e it will render your Veeam B&R 6.5 useless!

[lando_uk]

So you setup a v8 repository on a v6.5 host. Hardly surprising that it screwed up.

[foggy]

Yep, behavior is totally expected, since v8 instance has auto-updated the component it was going to use on the server with older version. Different versions of components cannot coexist on the same server.

[cby]

Err, you both kind of missed the whole point. It's the fact that it installed the component without any warning when presumably it could detect what version it was going to overwrite.

And no, it's not 'totally expected ' behaviour in my book.

[tdewin]

But it does say so in the wizard when you are adding the server:
https://helpcenter.veeam.com/backup/vsp ... eview.html

Components will be added / removed. A more visual sign (e.g warning sign) could be added next to the "already exists" I guess. Would that solve it for you?

[Regnor]

Also doesn't sound special or evil to me.

[cby]

Who said evil? That's a bit emotive!

tdewin, that would be very helpful, thanks.