[BUG] Installation of R2 upgrades DB schema, rejected by 7.0

[m1m1n0]

Hi all,

I was unfortunate to have to reinstall Veeam Backup and Replication from scratch for reasons outside of the scope of this message. However the previous installation was already upgraded to version 7.0 R2, which also upgraded the DB schema. Now I'm not able to point any installers to the old DB schema because fresh installation of 7.0 complaints that the schema is of a newer version, and R2 is only an upgrade to 7.0 installed software which needs to be installed beforehand. This forced me to create a new schema during installation and upgrade to R2, and now I'm lost in how to change the DB back.

I suspect this scenario was never tested nor considered when R2 was created. Or did I misunderstand something?

Thanks for help!

[foggy]

Please contact technical support for assistance in changing the database version number.

[ph1l1pp]

I'm having the same issue. I'm planning a hardware replacement and OS upgrade (w2k3 -> w2012) of my Veeam server (v7 R2). During testing the Veeam B&R and Enterprise Manager installation i was also not able to connect to the transferred database because it was in use with a newer version (v7 r2) than the installer 7.0.690.
How can I install Veeam B&R and Enterprise Manager to connect to the transferred database?

[foggy]

Philipp, the answer is the same, support will be able to change the DB version so you could connect to it with the 690 build.

[m.novelli]

I had recently the same issue after a (partially) failed update of Veeam 6.5 to Veeam 7.0 where I've applied R2 patch to try to recover the installation

I had to reconfigure from scratch the backup jobs because of the DB version number mismatch

Would be nice to have a KB article about this issue and steps to recover the DB

Marco

[foggy]

I will pass this feedback to support guys, however I think it is just safer to ask them for assistance in cases where manual interference with Veeam B&R database is required.

[lobo519]

Why does Veeam not make a fully patched executable available? I am trying to move my Veeam server but the new one cannot take over the existing databases because the database is R2 and the intall files are not. I'm forced to create new databases then switch to the old ones after I patch the new server.

Enterprise manager is not happy!

[foggy]

No need to create new DB, just ask support for instructions on changing the DB version.

[lobo519]

I would think you would want to reduce your calls to support and I think providing and fully patch version would be and easy way to avoid these calls. Or at the very least publish the instructions.

[m.novelli]

I would think you would want to reduce your calls to support and I think providing and fully patch version would be and easy way to avoid these calls. Or at the very least publish the instructions.

I love the idea to have a fully updated setup instead of a base setup + cumulative patch

Marco

[Gostev]

This issue does not generate enough support calls to justify doing this. Basically, it does not make sense for us to waste a few weeks on packaging and testing the new maintenance release just to reduce the amount of support calls by 3-5 in a given month. The price is way too high (delaying the next release for the same few weeks).

[lobo519]

OK - well can you publish the procedure so we don't have to wait 12 hours for support to answer?

[m.novelli]

This issue does not generate enough support calls to justify doing this. Basically, it does not make sense for us to waste a few weeks on packaging and testing the new maintenance release just to reduce the amount of support calls by 3-5 in a given month. The price is way too high (delaying the next release for the same few weeks).

Well add a minimum of 3 support calls in the last couple of years that I din't open

I've faced this issue during failed upgrades, instead of opening a support ticket for me was faster to reinstalled Veeam from scratch and reconfigure the backup job. If there is a DB schema trick I would love to know it

Marco

[Gostev]

OK - well can you publish the procedure so we don't have to wait 12 hours for support to answer?

Correct. The first step with every common issue is creating a support KB article (unless of course the procedure is too complex for end user to handle). Support makes the decision to create KB article based on the volume of support cases around it. Obviously, with over a thousand different support cases opened weekly, they cannot document every single issue in a KB.

[tsightler]

Also, remember that there are a couple of other fairly simple workarounds for this issue:

1. Just use the configuration backup when you move Veeam to a new server. Install fresh V7, then R2 patch, then restore configuration backup.

2. Install fresh V7 with new DB, then apply R2 patch, then detach and replace database with copy of old DB that was already patched to R2.

[lobo519]

I did option #2 but I just found it cumbersome. I assume the configuration backup doesn't retain history which is why I opted for #2.

[m1m1n0]

2. Install fresh V7 with new DB, then apply R2 patch, then detach and replace database with copy of old DB that was already patched to R2.

This will not work because the DB has a "fingerprint" of the original server and it's UUID and it will complain that the database is used by another instance. However one could go as far as change the new server's ID in the registry to match to what's in the DB.

This issue does not generate enough support calls to justify doing this. Basically, it does not make sense for us to waste a few weeks on packaging and testing the new maintenance release just to reduce the amount of support calls by 3-5 in a given month. The price is way too high (delaying the next release for the same few weeks).

I'll be more cautious about trusting the company where developers have such an attitude. Basically you're telling us that "yes the product has a flaw but your experience is not important to us until you generate enough noise" and "our build systems and test automations are from last decade and don't really work". And finally "we receive so few support calls that our service and support fees are unreasonably high". Be careful in what you say publicly please. You don't always have to explain why your answer is a NO.

[lobo519]

Gostev - Please take a look at Case # 00492006.

I'm not trying to be a jerk but I would like to point out why a KB article would be helpful in this instance. The support rep I am dealing with is really not giving this case any sort of attention and has thrown quick fix responses (guesses) at me since yesterday.

[Gostev]

I'll be more cautious about trusting the company where developers have such an attitude. Basically you're telling us that "yes the product has a flaw but your experience is not important to us until you generate enough noise" and "our build systems and test automations are from last decade and don't really work". And finally "we receive so few support calls that our service and support fees are unreasonably high". Be careful in what you say publicly please. You don't always have to explain why your answer is a NO.

I am not going to comment on your quotes of me, because those are completely made up and is NOT what I said in the first place

Just wanted to note that there is no "flaw" or "bug" in the product in this case. There is the supported way to restore product configuration to the new server from configuration backup, as Tom described on the previous page. And there are other creative ways too, which may work great in certain scenarios, but be cumbersome in other. Based on the amount of people attempting to use those other ways, we cannot justify improving user experience around them when stacking this activity against other priorities. And in software development and support, it is *ALL* about priorities. Some issues and activities are more important than other.

But generally speaking, it sounds like you are complaining about me setting right expectations, and saying that I should not be describing Veeam processes openly. But I do think this is the right thing to do? For example, if you prefer different attitude to these kind of problems, then knowing our way, you may as well consider changing the vendor to the one with the different approach to similar issues? As much as we like to see you being our customer, ultimately it is more important that you use the vendor practicing approaches you are more comfortable with, than remain forever-unhappy Veeam customer...

Gostev - Please take a look at Case # 00492006.

I'm not trying to be a jerk but I would like to point out why a KB article would be helpful in this instance. The support rep I am dealing with is really not giving this case any sort of attention and has thrown quick fix responses (guesses) at me since yesterday.

Thanks, I have sent this comment to the Support Management list along with the suggestion to re-evaluate the amount of support cases for this configuration restore approach, and consider creating the support KB article to help future users. Remember that you can submit feedback to the Support Management right from the customer support portal (in fact, your note will go to the exact same distribution list I have used).

Also, how much history do you really care to get back with the configuration restore? Right now, we do not back it up only to reduce the configuration backup size and restore times, as the history can be huge. Would you rather use normal configuration backup/restore approach if we backed up and restored the history, but only last X days or records?

[Ben Milligan]

a KB article would be helpful in this instance.

Here you go! http://www.veeam.com/kb1845

[lobo519]

MUCH appreciated!

[Gostev]

Here comes our Director of Support for North America

[m.novelli]

Thanks!

[lohelle]

I had to reinstall Veeam due to some deleted files (or something) with a client.

When reinstalling and choosing to use an existing database, I am told that the database is newer than the version I'm installing.
I tried creating a new database (veeambackup2), and then after setup (and updating to the current patch level) changing the database used in registry.
I am then told that the backup console on server (the current server name) is using this database.
I should maybe have backed up the sqllockinfo-key after reinstall..

What is the best way to solve this? Can I delete a key in the database to be able to use the old database?

[lohelle]

I think I solved it myself.
I deleted the sqllockinfo-key, and then everything started nicely.

[foggy]

Lars, I'm glad you were able to resolve this yourself. I've merged you posts to the existing topic discussing another ways of resolving this situation. Thanks!

[dkvello]

it says that the existing database was created with a newer version.

The server itself is on 7.0R2 Patch4, but there is no newer build of enterprise manager available than the one on

Backup&Replication.7.0.0.690.ISO

How do I solve this ?

[foggy]

Dag, please refer to this KB article for the solution.

[dkvello]

I guess I'll just wait for R8

As others have said though. It would be wise to have an updated .ISO with these patches where all components worked with the current B&R version. Especially when there is DB Schema incompatibilities like this.

[foggy]

Agree, and we would certainly do this if this generated sufficient amount of support requests to justify the effort required. Besides, there is an easy workaround available.

Anyway, thanks for the feedback.