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

Merge data (tape catalogs, indexes) from BE 2010 to new 2012 servers

Created: 16 Jun 2014 • Updated: 21 Aug 2014 | 14 comments
This issue has been solved. See solution.

Some similar requests give me the impression that the following cannot be done. I'm hoping someone can tell me I'm wrong.

I have two backup systems running in parallel: one is a standalone BE 2010 media server with an attached tape library; the other is a 2012 CASO infrastructure with two media servers. I want to attach the tape library from the 2010 server to one of the 2012 media servers and retire the 2010 server. 

How can I migrate the tape catalogs etc. from the 2010 server to BE 2012? I don't need to migrate the jobs, we will create new backup jobs on 2012, but I do need to be able to perform historical restores from the tapes written by the 2010 server over the last few years. There are many tapes; recalling and cataloging all the tapes would be a big job.

For example, would this work:

  1. Upgrade the BE2010 server (let's call it old-server) to BE2012
  2. Add old-server to CASO and centralise (distribute?) the database & catalogs
  3. Move the tape library to one of the other BE2012 media servers
  4. Test that the new server can do restores from old tapes
  5. Remove old-server (will this remove the catalogs etc.?)
Operating Systems:

Comments 14 CommentsJump to latest comment

rrolling's picture

Thanks that is part of the solution. However it still requires that we recall and inventory hundreds of tapes from offsite storage, as the document states:

Note:  Even though the Restore Selections reflecting the catalogs migrated from another media server may now show, a restore operation can only be performed after an inventory of the respective media has been performed. When catalogs are copied to a media server that has not used or inventoried the media in question, the media information is not present in the Backup Exec Advanced Device And Media Management (ADAMM) database, and the restore job will fail do to it referencing a media ID that is unknown.

I'm not completely sure what that means. If it means the restore job will fail, and ask for the correct media, then I can live with that. But I suspect it means that the restore job will fail without any useable information about which tape is needed.

Colin Weaver's picture

Did you also do disk based backup jobs on the old server?

If you didn't then easiest method is:

1) Move the library to one of your new servers and configure it

2) Inventory that library

3) Copy the catalogs folder from old server to new server

4) restart the services (or run CatRebuildindex -r) on the new server

5) create a special media set to move all of the tapes from the old server into so that that have a reasonable overwrite protection period as otherwise they will be in one of the default backup sets and might get used/overwritten too early

If you did used to run disk jobs then you ONLY want the catalogs for the tape jobs which kind of makes step 3 harder as you will have to look in the catalog folders. the the *.fh and *.xml files that contain media names that match your tape barcode formats 

Only one of the .fh or .xml will contain the tape names (sorry I can't remember which and am not in the office to check) and once you find it you would need all the files that start with the same long GUIDs as those that contain tape names. Once you know which of the two file type contains the names and assuming your tape label prefix is reasonably unique you might be abe to isolate all the GUIDS using the old command prompt "find" command

Notes:

Each tape may have more than one set of catalog files as the catalog files are linked to backup sets and you may have more than one of those on a tape

You do not need the BEDB as you have said you  do not need all your jobs and the inventory will add your media to your new database.

This process would lose your exact tape overwrite protection settings (hence step 5) but as you cannot merge Backup Exec databases (you can only migrate during initial setup of a new server) this is unavoidable.

The reason you cannot just copy all the content of the catalog folder if you were using backup to disk jobs is that you will almost certainly have duplicated use of either .bkf or .img names and this will cause conflicts betwen catalogs and media inventory

rrolling's picture

Colin, thanks for the tip about putting inventoried tapes into a new media set. There are no backups to disk on old-server. I reckon your steps work for the tapes that are already in the library. Offsite storage tapes will still have to be recalled and inventoried.

rrolling's picture

I replied to VJware's suggestion but it went to the moderators, I don't know how long that will take to come back. The link is helpful but only part of the solution.

The document says, "When catalogs are copied to a media server that has not used or inventoried the media in question, the media information is not present in the Backup Exec Advanced Device And Media Management (ADAMM) database, and the restore job will fail do to it referencing a media ID that is unknown."

Not sure what that means. If it means the job will fail but also provide the ID(s) of the media required, then maybe I can live with that.

VJware's picture

This is where the "inventory" comes into the picture and is to be run prior to a restore.

rrolling's picture

Exactly what I was hoping to avoid. There are many many tapes created over a number of years and stored offsite at a paid facility; recalling all the tapes is expensive and the inventory is a big task. 

VJware's picture

An inventory is a must, without it, BE would not be able to identify the media.

rrolling's picture

That's what I was dreading.

So we have a Backup Exec server with a database that has all the inventory information of all these tapes and another Backup Exec server that doesn't have the information, and the only way to get the information from one to the other is... there isn't any way. BE is too dumb to talk to the server next to it, it has to read all the tapes. Grrr.

Anyway, thanks for the information. 

pkh's picture

I don't see why you are so fearful of doing an inventory.  When you move the catalogs to your new server, all the backup sets on the tapes would be available to on the new server.  You will see the tape information on the new server as if they were on the old server.  If you want to restore from a backup set residing on Tape1, then you have to put Tape1 into the tape library and do an inventory of Tape1 so that BE knows that Tape1 is on online and is available for use.  You don't have to inventory the rest of the tape.

If you are using barcode labels, it is even faster.  You just need to either import the tape into the library or put the tape in the library and do a scan.

rrolling's picture

I apologise for the confusion, I will try to clarify.

The tape inventory is only a problem if we would have to recall and inventory all the tapes from offsite storage before we can do the first restore job from the old tapes. That would be a costly and time-consuming exercise. I understood VJware to be saying that was the case.

However, if it is possible to determine what tapes are required to fulfil a particular restore request without first inventorying all the tapes, then there is no problem. We simply recall the correct tapes from offsite storage, inventory just those tapes, then run the restore job.

For example, maybe we would kick off a restore job as soon as the client asks for some old data, expecting the job to fail with a message that enumerates the required tapes. That would be fine.

VJware's picture

Let me clear this up.. What I meant was an inventory is required prior to the restore. However, I didn't mean to run an inventory for all tapes prior to the first restore, just the inventory of specific tapes which are required for the restore.

SOLUTION
pkh's picture

The restore job will prompt for the appropriate tapes.