Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Move Backup Exec to new server when using a remote SQL database

Created: 08 Dec 2010 • Updated: 06 Jan 2013 | 10 comments
This issue has been solved. See solution.

I'm in the process of moving our Backup Exec 12.5 installation from a Windows 2008 Standard 32-bit server to a Windows 2008 Standard 64-bit server. I've been following the instructions at

http://www.symantec.com/business/support/index?pag...

The problem is that the instructions gloss over using a remote SQL database. Step 3, III. Installing Backup Exec on the new Backup Exec media server, is geared towards a local SQL instance. What is the procedure when you have your SQL database on a remote SQL Server?

I've stopped all Backup Exec services on the original Backup Exec media server, but during installation on the new server, when I'm asked to select an instance of SQL to install the database, I point to the exisiting SQL server and receive a message stating:

A Backup Exec database is already attached to Microsoft SQL Server FooSQL1. Another Backup Exec media server is probably using this SQL server as its database server. Select another SQL server to install the Backup Exec database to.

Where should I go from here?  Backup and delete the existing db, let Backup Exec create a new db, then restore the old one over the new? Unfortunately the documentation does not cover this situation (pretty typical, no?) and Symantec support wanted $250 to give me the answer as our support contract has lapsed - which led me here. :)

Comments 10 CommentsJump to latest comment

Sush...'s picture

You may try the following steps:

 

1) Stop all BE services on the old server. Stopm SQL Service on the SQL server

2) Copy the BEDB_DAT.MDF and BEDB_LOG.LDF files to seperate safe location from the SQL server. These files will be present in the SQL folder on the SQL server

3) Started SQL service on the SQL Server and then open the Management Studio console of SQL

4) Connect to the instance where Backup Exec Database (BEDB) resides and the delete the BEDB database from the Management Studio console of SQL.

5) Check that BEDB_DAT.MDF and BEDB_LOG.LDF files are deleted from the SQL folder. If they are still present then you have to delete them manually.

Note: Before deleting these files make sure that you have a Copy of these files as pointed in point (2)

 

6) Now start the Backup Exec installation on the new server and during the installation when you are asked to select an instance of SQL to install the database, point it to the exisiting SQL server

7) Make sure that the installation is completed successfully

8) On the SQL Server you will observe that new BEDB_DAT.MDF and BEDB_LOG.LDF files will be created in the SQL folder and also a new BEDB database will be seen in the Management Studio console of SQL

9) Now stop all BE services on the new server and also stop the SQL service

10) Copy the old files from point number (2) and paste (overwrite) it on the new files

11) Started SQL services and then Backup Exec services on new server

 

From my point of view the above steps should resolve your issue. If not then you always have the option of creating the jobs and settings all over again.

 

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

pkh's picture

I am wondering if it is easier to do this

1) Use BEUtility to backup the database and save the bedb.bak from the Data directory.

2) Uninstall the existing copy of BE and delete the remote instance of the BE database.

3) Install BE using a new instance on the remote SQL server as a database

4) Use BEUtility to restore the database from the bedb.bak which was saved in Step 1.

(BEUtility is located in the BE installation directory).

SOLUTION
Sush...'s picture

@PKH: Isn't that your response is same as the steps that I suggested?? The only thing is that I have given more detail steps like when to start and stop the services which is very important. Also taking the backup of database using BeUtility and creating BEDB.bak is same as copying the .Mdf and .Ldf files.....

 

Note: BeUtility should be used only with the help of Tech support. Thats the warning you get when you run the BeUtility

 

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Ken Putnam's picture

Note: BeUtility should be used only with the help of Tech support. Thats the warning you get when you run the BeUtility

 

So you are saying that one should place a Tech Support call to do something as simple as change the media server name or domain?  Both of which should be done using BEUtil? 

or to take a separate, known good,  backup before major reconfiguration or maintenance or upgrade of a media server? 

And I can think of several other situations to use BEUtil that I shouldn't have to pay for a Support Call. 

If the tool is that dangerous, it should not be included on the Install Media.  I agree that mis-using it can destroy a BE installation, but so can many other MS and third party utilities, none of which "should be used only with the help of Tech support"

 

And I competely agree with PKH  that copying a BAK file is not even close to being the same as copying the mdf/ldf files

If this response answers your concern, please mark it as a "solution"

CraigV's picture

...there shouldn't be any reason to use SQL Management Studio to mount the DBs with BE's use of SQL 2005 Express.

I have yet to see any documentation saying that BEutility is to be used exclusively by tech support. If there is, please provide the proof. But I believe it was built-in so that the average user could get around issues on their own, with enough reading up of, and knowledge of the product.

 

Cheers!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

pkh's picture

taking the backup of database using BeUtility and creating BEDB.bak is same as copying the .Mdf and .Ldf files.....

No. How can this be the same?  Taking a backup of the database using BEUtility is the same as copying the .mdf and .ldf.  Since when???

For my procedure, BEUtility takes care of the starting and stopping of BE service.  Hence, they are not listed.

Note: BeUtility should be used only with the help of Tech support. Thats the warning you get when you run the BeUtility

Yes. There is a warning when using BEUtility, but it is just that a warning.  Just like there are warnings when you are told to edit the registry.

Grand's picture

Thanks Sush and pkh.  I've already stopped all BE services on the older server, so I'll take last nights backup and restore it over the BE database from the new install (after backing that one up). It's not possible to stop the SQL server during office hours (BEDB is not running on it's own instance) so backup & restore is a better option for me.

pkh's picture

You should have used a seperate instance for your new BE database.  This is so that you can stop or start the BE instance without affecting your production instances.

Grand's picture

I inherited this installation, and didn't want to install another instance of SQL on the server as it's more of a "running - don't mess with it" installation. I've never had to stop the SQL instance yet - why would I have to? I'd think stopping the SQL services on the BE server and dismounting the db if needed would be enough for most maintenance tasks, though I'm sure there are procedures (BE Util?) that require stopping the SQL server that I'm not aware of, such as... ?

Swathi Turlapaty's picture

To rule out the negative discussions happening here on this thread regarding the solution provided by the TA, here is the confirmation that I got from the BE support team in regards to the 2 comments..

"The two processes outlined are two different ways of doing the same thing.  We normally opt to have the customer do the migration the way that the TA advised as there are fewer steps and less chance to mess up the install."