So, your backup server is a few years old and you find yourself in need of a newer, bigger, better, faster one. Just one problem, you want/need to keep your data from Backup Exec for compliance reasons. You have the perfect server that is ready to take on this new role. It is some new 64 bit monster with Windows 2008 R2, tons of I/O capacity, memory, disk space and more. Then you ask yourself, how do I move Backup Exec’s data from the old server to the new server and keep everything in working order? Time to check the technote database! So you head off to http://support.symantec.com and start doing some queries. You may find this technote:

In the last 10 years, there have been many who have followed this technote, for just this purpose. When you start reading it, there are some bold statements, and some restrictions. However, lets first review some of the components this technote will cover.

Today the SQL instance that hosts the BEDB is Microsoft SQL Server Express 2005 SP3. This version happens to be a 32 bit version when installed on either a 32 bit server, or on a 64 bit server. That is good news for customers who want to migrate from 32 bit operating systems, to 64 bit operating systems. That means there is really no difference in the database mounted on a 32bit OS, or a 64 bit OS, so you can carry it forward to a 64 bit OS without any compatibility issues. Furthermore, the Backup Exec Data and Catalogs on disk are files that are obviously transferrable between OS’s as well. The technote above is written to help move these three items between an old and new server. However, there are a few remaining items to consider.

One of the main items to consider is the configuration of the old and new server. The steps in the technote guide you through creating a matching configuration on the new server. If it is the same operating system as the previous install, then the same components and configuration items for that operating system will get laid down by the install. This should give a relatively similar configuration. The restriction at the top of the technote mentions operating systems of different versions. This is most likely for customers who tried to go backwards. Some examples where this would be broken would be:

Customer installed the Deduplication option on Windows Server 2008 (64 bit), then tries to move to Windows 2008 (32 bit). This option does not install the same on Windows 2008 (32 bit), so this will cause issues.

Customer has Microsoft Exchange (64 bit). Tries to move their data back to a Windows Server 2003 (32 bit) machine. Selections lists in the database would fail to protect these servers since they require tools that can only be present on a 64 bit machine.

These are just a couple examples of how this could lead to possible compatibility/supportability issues. There may also be additional issues when migrating from 32 bit to 64 bit operating systems of different operating system versions, though I am not personally aware of any. I know of customers who have successfully migrated this way, but it not a supported upgrade path as is called out in this technote:

There is also the added difficulty of having to move to a newer version of the product, and not being able to upgrade to the current version. Here is an example. A customer has Backup Exec 12.5 installed on a Windows 2000 Server. They would like to migrate to Backup Exec 2010 R3. However, Backup Exec 2010 R3 does not support installing on Windows 2000. In a situation like this, the only upgrade path is the following technote:

Again this technote lists similar restrictions as the previous technote. Most if not all of the restrictions have very valid reasoning. Primarily because of the work that is done during the install, with respect to these items. The Backup Exec Installation will often make some database changes in coordination with the migration scripts. It’s a carefully orchestrated flow to carry the configuration forward to the new version. Trying the steps in the technote against a server that meets the restrictions will be hit or miss. Mostly depending on the database version being migrated, and changes made in each version of the product after that version. For example, trying to migrate a database that is from the 12.5 product, using the migration(BEMIG) scripts in our 2010 R3 release will yield failures when the “Shared Storage Option” is installed. This is because the install does some of the work, and the scripts do the rest of the work during the migration sequence. The only reliable way to get upgraded when you meet the restrictions is through operating system upgrades, and the supported Backup Exec Install upgrade paths. Now, if you don’t meet the restrictions, then you are essentially using the migration scripts in the newer version of the product, to migrate your database to the new version. This is the same sequence that the Backup Exec Installer uses to migrate the database between versions. However, you should also be careful that the old configuration and new configuration match as closely as possible. Doing so will save you many hours of frustration and issues that could be avoided!

Another question I received, asked about lingering server/devices post upgrade, that are un-removable in the Backup Exec 2010 UI. This issue may happen when migrating to a server with a different server name and different hardware. It’s a difficult issue to solve for our support team, and usually requires their intervention to fully remove. For this reason, it is recommended that you migrate to a server with the same name, and similar configuration. It saves many hours of resolving configuration issues when you do. If you decide change your server name, you will not be able to carry forward a deduplication folder, or its associated jobs. You may also decide to recreate your selection lists for proper viewing. There may even be more items you find needing your attention when you do. Save yourself the headache and keep the same server name. Follow the technote and copy the data to the network, take the server offline, bring up the new server with the same name, and finish followng the technote. You will be glad you did!

I was browsing the forums tonight, and was reminded of another way to migrate data from one server to another. There is an option which allows you to copy jobs, selection lists, policies or server options between media servers. It doesn't copy catalogs, history, or other compliance related content. Just the releated definitions. The feature is great for someone with a small server with just a few jobs, and wants to migrate them just as they are from one machine to another. Below is an excerpt from the admin guide for 2010.

Copy to Media Server options

Backup Exec enables you to copy all jobs (including backup, report, and utility jobs), selection lists, and policies that were created on your media server to the same media server, or to another media server.

Moving a DeDupe installation from one server to another server is not a trivial task. I will try to address this in a future post, However, I first will need to have some discussions with a few of my colleagues before I can post anything official.

Why has Backup Exec not included it for install? Well, the biggest reason is that it has an installer requirement of MSI 4.5, which requires a reboot after installing. This increases the complexity of our install as we have to reboot in the middle of our install and restart. Its not rocket science, but its something we prefer not to do if we don't have to for your sake. You can always use your own 2008 R2 instance if you prefer, we will just not install it for you automatically. We are always looking at the benefits/trade-offs in newer technology like this.

As promised I have a technote that will help you migrate a DeDupe folder from one machine to a new machine.

Take a look at this technote: (http://www.symantec.com/docs/TECH160832). This technote simply provides you the option of just migrating the DeDupe folder to a new machine. It does not address moving the rest of the BE data along with it. So, this set of steps should bring it all together:

1. Delete the DeDupe store from the previous server.

This prepares the store for the move, but does not delete the DeDupe store data, it just simply removes it from the BE Configuration.

This will require you to retarget your jobs to a new location, so put the jobs on hold, give them a new target temporarily. Stop the services for BE.

2. Now, copy over the Data/Catalogs folders to the new server following the blog and technotes.
3. Next, copy over the DeDupe folder to the new machine.
4. Next, Import the DeDupe folder as described in Tech160832 above.
5. Next, Retarget the jobs back to the DeDupe store as they were originally.
6. Finally, run an inventory on the DeDupe store to re-associate the on disk catalogs with the imported DeDupe store.

One final note. As the article mentions, this is only valid with Backup Exec 2010 R3 and above.

If you follow the instructions in that technote, it will allow you to migrate your data successfully with 12.0. I would again recommend that you keep the same server name for the reasons listed above.

The steps in the technote have remained valid for many years. A few of the steps have been updated along the way, but overall, if you simply install the new product on the new machine with the same service packs, then stop your services, and copy over the data and catalog folders, then restart your services, 99% of the time everything will come up successfully.

One caveat is if you are using SSO, there is a datapartitionGUID registry value, and a datapartitionID registry value that needs to be renamed so that the server will recreate it with what it should be on service startup. This needs to be done prior to starting services.

Nick,
Great thread and I believe I have found the right place.
My scenario is that I have BE 2010 installed on a Win 2003 server and wanted to move it to a newer Win 2008r2 server of a different name. I followed the steps in http://www.symantec.com/docs/TECH67296. I didn't understand at the time that it was referencing the same OS versions. Everything was going all good until the next to last step during the cmd functions, specifically: 1> SELECT partitionname FROM datapartition (enter)
2>go
At this point I got an error stating msg 207, level 16, state 1 Server \BKUPEXEC, Line 1 Invalid column name 'new server name.
I have been on the phone with tech from overseas and was pointed to article 129826, that these are the steps I should be taking. That is all good and well, but what did the cmd steps from the other article do to my new BE 2010 install on the 2008 box? Tech had no good answer so I have been searching to find out if I should go ahead with the 129826 article and see what happens or is there a way to "undo" the cmd steps from the wrong article.
I can see from the thread that you can give me a best case option and look forward to a reply.
Latergater

I sent you an email to get more information, because I have limited information about the environment. For the purpose of this reply, I'll assume it is a stand alone server that you are moving. If the environment is more complicated, then that would be useful information to have.

So, Looking at TECH67296 there is the command it suggests you run against the BEDB. Looks like the following:

I know this reply is very late, but I honestly did not see it until reviewing the blog post for another reason. I did not get a notification of your post and I apologize for not replying sooner!

With respect to your question, I am a bit confused. You are asking about moving from 2010 R3 to 2012 (which is an install upgrade) on the same server. So, to say it another way, if you want to upgrade your Backup Exec install from an older version to a newer version on the same server, all you have to do is run the install for the newer version. If there are any limitations, the install should warn you or block you. If your current older version is a supported version we upgrade from, then the install will take care of the necessary work to move your older install to the current version. 2010 R3 -> 2012 is a supported upgrade path. We typically support 3 releases back. So upgrading 10d to 2012 would be blocked. You would have to upgrade to a version like 12.5 first as trial, then you could go to 2012.

Currently I'm not aware of any supported migration path for Backup Exec on a Windows Server to a Backup Exec Appliance. The shipping appliance configuration prevents using the steps mentioned above. Can you help me understand what your current configuration is, and how much you would like to migrate if it was possible?