Refer Backup Exec software compatibility list . Check the backup exec database repository section under Backup Exec Feature specific compatibility. This lists all supported SQL version on which BE can host its database.
Refer Backup Exec software compatibility list . Check the backup exec database repository section under Backup Exec Feature specific compatibility. This lists all supported SQL version on which BE can host its database.
If your company plans on migrating from SQL 2014 globally to 2016 or newer, currently upgrading a SQL instance installed and used by BE isn't going to be easy even possible right now. After some time working with the Veritas support I thought I could share some details nonetheless:
It's really disappointing to realize that in 2019 with the new BE 20.4 Veritas still ships SQL 2014 32-bit while BE itself has been 64-bit only since BE15 (that's 2 major releases by now). SQL Server 2014 is the last version made available for 32-bit at all and reaching end of mainstream support this year. All newer SQL Server releases are only made available in 64-bit editions. At some point Veritas will *have to* provide a working and supported upgrade path for its customers.
To note: Upgrading from 32- to 64-bit editions of SQL Server in-plase is not supported by Microsoft at all.
(https://docs.microsoft.com/en-us/sql/database-engine/install-windows/supported-version-and-edition-upgrades-2017?view=sql-server-2017)
So far I've not been pleased with the Veritas support engineers who at some point even wanted to talk me into SQL 2017 wasn't supported (contradicting the SCL) or that they'd support SQL 2014 with BE even after MS ending mainstream support for 2014. (Veritas cannot backport fixes into MS SQL 2014, this would be possible with an open source DBMS)
Warnings ahead if you intend to upgrade the default BKUPEXEC instance:
Your only way to migrate any given MS SQL 32-bit instance according to Microsoft is to export/import or attach/detach from the old to a new instance at some point. At some point the software on the other end needs to know about possibly changed connection parameters.
In the case of Backup Exec the article I've been pointed at (https://www.veritas.com/support/en_US/article.100001771) has not worked for us. beutility at some point in the process detaches the BEDB database from the old install yet fails to re-attach onto the new instance. The end result was that the database was not attached to neither the old, nor the new instance and BE services would not start.
The new SQL Server instance was installed according the Veritas' own instructions (https://www.veritas.com/support/en_US/article.100023028). But I have been able to reproduce this with any given combination when attempting to move the DB from 2014 x86 -> 2017 x64, 2014 x86 -> 2014 x64 and even 2014 x86 -> x86.
Had I not taken a DB dump with beutility before the attempt, would have resulted in further disruption of services. In our case the restore of the DB with beutility worked but the was left with the DB wrong owner of teh DB ending up in ODBC connectivity errors thrown by Backup Exec.
Before you restarting all BE services, using SQL Studio, check that the 'BEDB' owner is 'sa' and that under the the DB's ->Options -> Miscellaneous -> Trustworthy is set to TRUE.
If there is anything that I can share going forward I'll try to update this thread. For the moment I'd not encourage attempting the upgrade of the SQL Server instance used by Backup Exec if it is the default 32-bit 2014 version.
Thank you for the heads up! I was planning to migrate from SQL Express 2014 x86 to SQL Express 2017 x64. Have you tried migrating again since this post?
