Video Screencast Help


Created: 16 Mar 2012 • Updated: 13 May 2014 | 19 comments
This issue has been solved. See solution.


We have CASO and Media Servers running (multiple sites), with the replicated option for catalogs. However if we try a restore job on one of the MMSs for a backup that has been duplicated to the MMS, the catalog does not exist.

I'm thinking from a DR perspective here - i.e. a backup in the main site is duplicated to the remote site, then main site then blows up and we restore the data in the remote site and are back up and running.

Is this not the correct way of doing?

Comments 19 CommentsJump to latest comment

CraigV's picture


CASO servers don't duplicate to an's the other way around. To do this you need to set up the MMS to either replicate the job/catalog information to the CASO, or centralise this on the CASO.

Just be aware that if you centralise your job/catalog information and your CASO dies, so do your jobs on the MMS until such time as you get the CASO running again.

Check the link below for further information on this:


Alternative ways to access Backup Exec Technical Support:

Ldoodle's picture

That doesn't make any sense though.

As I said, I have 1 server in the main site (which as CASO), and 1 server in the remote site. What's the point in duplicating backups from the main site to the remote site if I can't then restore those backups in the remote site.

How would I achieve this?

CraigV's picture

OK...does your CASO run backups? If so, CASO does NOT replicate media/catalog information to another server.

I think you're misunderstanding how the CASO then works...CASO controls media servers and receives job logs etc, and can initiate jobs to MMS doesn't receive that information and replicate elsewhere. You'd have to back up the CASO server's Data/Catalogs folders.

If you want to duplicate backups from 1 site to the other, then your CASO should be on the remote site...not the other way around.

Also, please put in the details of how your backups are configured to run which I am sure will make things  a lot easier to understand!

Alternative ways to access Backup Exec Technical Support:

Ldoodle's picture

Yes the CASO does itself run backups. Moving the CASO to the remote site will only reverse the problem. I want/need a fully replicated system in both sites so if either site dies I can restore that sites data in the other site.

Basically, each site does its own backups, which are then duplicated to the other site. So site A's backups are duplicated to site B, and site B's backups are duplicated to site A.

I understand all that about CASO, I just didn't know it didn't replicate catalogs itself.

In terms of how backups are configured (we're using de-dupe); backup jobs runs on a schedule, then on completion the duplicate backup job runs, sending it to the other site.

Matt12345's picture


I'm running into the same issue in my environment.

I run CASO w/ dedupe and then duplicate backup sets to an offsite MMS with a shared dedupe folder. I cannot restore the duplicated data from the MMS without cataloging it first.

I'm a little ticked off about it too. Symantec was selling dedupe as "dedupe with replication". I take issue with their definition of replication. They should really call it "replication via a duplicate data job/policy bundled with tedious catalog jobs than need to be manually run at your DR site". This form of "replication" is something I could have cooked up on my own without shelling out a lot of money for a second dedupe license.

Ldoodle's picture

Thanks Matt,

I agree it is a major cockup on Symantec's side. Why on earth would you want to duplicate data to another site and then not be able to actually do anything with it. What is their solution then to any site in a multi site organization crumbling down? Every second counts in business these days so to say "manually catalog your data" is a stupid solution when we're talking terrabytes of data!

This is a major design flaw and I would like to see multiway catalog replication in a future patch (not just a new version altogether), and very soon, otherwise they can jog on all the way to the moon if they think I'm going to renew my maintenance.

This isn't a minor bug for us either, it is do or die.

CraigV's picture

...add it in as an Idea. It seems to be worth that!

Alternative ways to access Backup Exec Technical Support:

Colin Weaver's picture

Take a look at the private Cloud Whitepaper and read it as if the VPN link discussed in the document is just your WAN link. And then if the MMS is in the remote location tick the option to set this MMS as the private cloud server and that should cause the catalog files to end up on the MMS.

Ldoodle's picture

Thanks Craig, Colin - I will try the Private Cloud option and report back.

Another idea I have just thought of - we use Windows DFS-R between the 2 sites for file-based data. I wonder if it would be worth setting up a DFS location to store the catalog folder, which would be replicated at the file level so when a catlog is created/updated it is shipped off to the other site's file server.

Backup Exec would then be configured to use this location for its catalog folder.

Would that be do-able, and supported by Symantec?

CraigV's picture

...I haven't seen any mention of Symantec not supporting the catalogs being stored in a DFS location; they offer the option of changing the location as it is through BEutility...

Alternative ways to access Backup Exec Technical Support:

Matt12345's picture


I copied my catalog folder from my CASO server to my remote MMS (after backing up the original MMS's catalog folder) and was able to do a restore of my replicated data.

So what I have in place now is a scheduled task that uses robocopy to sync the CASO cat folder to a folder on my remote MMS. In the event that I need to do a restore I'll just swap this folder out for the original MMS one.

Another thought I had was to set this up as a post job command so it'll sync my cat after a dupe job runs.

DFSR should do the trick too, but I don't have that running in my production environment - and it seems silly [for me] to set it up just to sync my BE cats.

This is still a work in progress for me but I've been happy with my results thus far.


Ldoodle's picture

Colin, your link just redirects to the Community home page.

I tried just setting the MMS to be private cloud but the catalogs hven't been copied across.

EDIT: I have just re-read the Optimized Duplication PDF from Symantec (, and it states;

The SAN Shared Storage Option (SSO) can be used to enable device and catalog sharing between media servers. SSO does not offer any of the additional management or WAN-friendly catalog sharing mechanisms that are available when using CASO, so SSO is viewed as a non-recommended alternative.

which suggests 'WAN-friendly catalog sharing' should be doable in CASO.

Colin Weaver's picture

The Tech article works for me - try this link which is direct to the pdf in the tech article

Matt12345's picture

Thanks Colin,

While this might get the job done, I don't think it's a real solution. It seems like we're just throwing more money and another layer of complexity into the mix.

Maybe if we all submitted enhancement requests something might happen... or maybe not... It seems like this BE Cloud product is being touted like it's the answer to all of our problems.

ATowstonog's picture


I have read all articles about catalog replicating between CASO and MMS and  cann't finally understand how can I make 2 fully both direction equally Backup servers. I mean, if one of the servers (no matter CASO or MMS) will get down, I can easily restore failed server from another one. Is it possible to get 2 Backup Exec server with one general catalog/job list/media data?

Now I have one CASO and one MMS on physically different servers. All media data on NAS Drive. It is shared for MMS. MMS is fully controlled from CASO. Both configuration let me to see backup servers list, job list and storage content. If MMS is down, I can restore it without any trouble, but when CASO is down... I cann't even see any information about jobs or storage on MMS.
Please, could somebody me explain how must I configurate servers for such situation?
CraigV's picture

...your CASO is simply a management server in the ideal world, and doesn't do anything but manage your MMS servers. It should therefore not be running any jobs, but delegate and control if you choose the option to centralise.

If it does run jobs, there is still no reason to push the CASO server's jobs down to an MMS. It simply doesn't exist. There's a reason for the CASO controls everything.

You can look at copying catalogs etc between servers, but this becomes complicated.

Alternative ways to access Backup Exec Technical Support:

ATowstonog's picture

Other words, there is no method to have identical BE servers with general media data for situation, when one of them is down?

CraigV's picture

Neither ARCserve nor TSM do this by the by.

And no, the CASO allows you to restore data if an MMS is down, and initiate jobs. If the MMS or CASO dies and you have centralised your information, then no backups will run on the site servers.

Your other option is to backup the Data/Catalogs folders including the SQL instance, and if your media server dies, bring all that up on another server.

If you ran BE 2012 you could VM your backup server (assuming you were backing up to disk as your primary target), and keep this syncronised. Other than that, no...the CASO doesn't copy MMS servers between each other.

Alternative ways to access Backup Exec Technical Support:

Nasharat Maner's picture

Hi ATowstonog,

For below question, there is a work around available.

'when CASO is down... I cann't even see any information about jobs or storage on MMS.'

In this case, you can change ADAMM location of MMS to Local by modifying BE install through Add/Remove programs. This will convert MMS to standalone BE.

This will bring BE server back online and you can perform restore.

Once, CAS is up, you need to add this system to CAS.