cancel
Showing results for 
Search instead for 
Did you mean: 

Migrate BEDB without using BEUTIL

bobS432
Level 3

Hi,

I need to migrate the BEDB from one SQL server to another, however using the BEUTIL program is unfortunately out of the question due to the service restart it performs on SQL (the SQL server is shared by several other applications).

Now in terms of doing this, the course of action would I assume be:

  1. Stop BE services.
  2. Backup and restore BEDB using native SQL backup from one db server to the next.
  3. ??? change connection strings for BE somehow ???
  4. Restart BE services and verify it works as expected.

How can I accomplish step 3, I can't seem to find anywhere the SQL database connection is set with BE?

Thanks in advance,


Bob.

9 REPLIES 9

Riyaj_S
Moderator
Moderator
Employee Accredited Certified

Please try steps mentioned in following technote :

https://www.veritas.com/support/en_US/article.TECH37752

If service fails to start then check registry entries mentioned in following technote :

https://www.veritas.com/support/en_US/article.000011571

Thanks and Regards,

Riyaj

Thanks for your reply.

The first article is about BEUTILITY, which is unfortunately what I explicitly can't use.

For the second, I tried manually migrating the SQL database and amending the connection string settings as specified in the second article, and the services start and the client loads seemlingly correctly, showing the correct jobs etc. However, one big issue was this made my entire job history disappear, whether trying to restore a file or otherwise. As doing this basically invalidates all my existing backups, its not really workable so I have reverted and the job history came back.

Is there an additional bit of configuration somewhere, or something that is dependant on that old instance that needs to be changed beyond what is mentioned in that article (that article does say it is for BE 2010, and I'm running 15).

Thanks in advance,

 

Bob.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

It is bad practice to install the Backup Exec database in the same instance as production databases for other business critical applications. As such I recommend you re-think your idea and keep it in a separate instance (or at very least limit the types of databses in the instance to IT systems such as Insight Manager etc that are less critical to business operations)

 

You have already found one of the reasons for why it is bad practice - i.e. there might be a need for a service restart against the instance that runs the BEDB. Other reasons relate to how you DR restore the environment with all your databases in the same instance.

Its not really my decision to make, it is what it is.

So what we're basically saying is that fundamentally the BEUTILITY tool does some auto-magical things in the background while transferring databases that no one know's how to replicate manually? I mean if true thats quite an astonishingly scary proposition for a tool focused around backup and recovery. 

Or is there something additional that needs to be done to recover my job histories once the db has been moved?

 

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

Do you mean job histories or job logs? Job Histories are contained inside the BEDB but job logs are held in a path on the BE server itself

The job histories, but its to the point that upon changing the connection string BE appears to not know about any previous backups and therefore starts new backups as it thinks its missed the ones it did successfully complete previously.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

Can to you see restore selections for the job that ran before your changes as this might be a catalog location issue with not correctly setting the catalog registry keys.

Note you may have to open up a formal support case (or just accept that things have been reset) in order to sort this out

As an aside one problem with manually changing Backup Exec's installation is that patch installs, repair installs and uninstalls may no longer work so going off track in this way may have long term side effects.

No, it removed the restore selections as well.

If I move the db back and undo the few reg changes mentioned in https://www.veritas.com/support/en_US/article.000011571 then it all works again and comes back. Its like there's an additional configuration entry beyond whats mentioned in the above that needs to be set. I've tried looking everywhere that seems obvious, but alas I'm stumped. Any ideas? 

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

You might have to either accept a servcie restart of SQL or follow my earlier advice about best practice and explain this to whoever is insisting you merge it in a shared DB (especially as if your attempts to move things manually  does break the ability to do patch installs etc you may not find out for a while and have further problems if you continue)

Another outside option if you must move it is:

Backup the BEDB (including BEDB Encryption Key depending on version) , catalogs and job logs

Uninstall BE

Re-install BE but specify the remote SQL instance during the install (which should setup BE using the SQL instance correct registryo settings for catalogs etc BUT with an empty BEDB)

Then replace the catalogs, BEDB and job logs with those that you backed up ealier.