Inventory takes over a day

[teevee]

Hello, 

I have backup exec 2010 R3 running at two sites on Windows Server 2008 R2 with a CASO and MMS.  Each site backs up it's local servers, and then duplicates the jobs across to the other site.  This alone is working fairly well, however the only way to actually recover that data at the other site is to run an inventory and then catalog the media and this is where I think something must be wrong.

Running the inventory job on one of these devices is taking over a day to complete, and during that time it impacts the other backup jobs causing them to fail or miss their windows, so it's really not even do-able.  I tried running it yesterday, but it ran for 9 hours and was only 26% complete and caused the first job of the night to fail so I cancelled it.

Each site is set up with dedupe on an 18TB volume running on a RAID 6 (12 x 2TB 7200 drives), my backup speeds are decent but the inventory is ridiculous.

Is there some other way to recover this data at the other site without running an inventory?  I've tried just looking up the specific media used, cataloging it and recovering but it fails.  I must have something mis-configured.  Each job runs a full backup to 'keep indefinitely' media except for 2 of them, and there are only 9 jobs total between sites totalling about 1.5TB which dedupes to about 17 GB actual stored data.  I work for a retail chain so there are no weekends when it comes to backup windows, that's why we just take a full backup every night.

Can anyone see some glaring mistake here?

Thanks

[Colin_Weaver]

Have you configured the Private Cloud setup (one of the options in a CASO-MMS config)?

http://www.symantec.com/docs/TECH172464

When you read the above docs just be aware that they are written for an MSP setup, as such whenever you see a reference to a VPN link juts think of that as you site to site WAN link

Also read them and understand the scenarios they discuss before you think about implementation. The documents do discuss more than one scenario

[teevee]

Colin, 

Things got busy and I didn't have time to read through this today, just looked through it some now.  I do have the MMS set up as a private cloud, and the duplicate jobs are going site to site but the problem lies with the inventory job.  We're looking to have this set up as a disaster recovery-type solution where if the CASO goes up in flames we can restore the jobs from that site in a reasonable amount of time at the MMS location (also vise versa if the MMS goes up in flames).  We just have the 2 servers and they each have 18 TB dedupe volumes.  

On page 43/44 it says to remove the MMS option so it's a stand alone server and then inventory the device and then recover.  I'm a little wary on actually testing that out as we do have live backups running at each site, but even if it's a stand alone server should I expect a faster inventory?  I did notice as I ran the inventory job you could see a spike pattern on the network interface which I was a little surprised by, I figured it would just have to scan through what it has locally and figure out which media belongs to which jobs.

From what I've seen in this article there doesn't appear to be a way to have these duplicated jobs ready to be restored without performing an inventory first.  Another option I've considered is moving from a RAID 6 to a RAID 10 which would still leave about 12 TB of storage, but not sure if the performance increase would be significant enough.

[teevee]

Playing around with this, it seems to work sometimes when restoring a duplicated job on the CASO that originated on the MMS.  When I go into the restore, the media is already there and catalogued so the inventory isn't necessary, however this is still hit or miss whether the job fails or not.

Is there some way to have this same functionality on the MMS?  I have private cloud enabled on the MMS and the CASO, and catalogs are set as replicated on the MMS, but there's no option to set that on the CASO it seems.  When I go to set up a restore job on the MMS the media isn't available in the list, and if I try to go to the media on the MMS and catalog the individual files it fails.  

Edit:  Also noticed just now that if I restore a job from the MMS on the CASO, specifying the source as the deduple volume on the CASO, it still seems to try and pull the data from the MMS.  To get around this I stopped the backup exec services on the MMS and it then restores much faster and doesn't saturate our WAN connection.  So at least it seems to be somewhat working in one direction, but I need it in both directions.

There must be some way to replicate the catalogs in the same fashion that the MMS does to the CASO?

[teevee · Accepted solution]

Found what looks to be a promising work around here:

https://www-secure.symantec.com/connect/forums/catalogs-9

Specifically:

"Ldoodle,

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.

-Matt"

Going to give this a shot and hopefully it does the trick.

[Colin_Weaver]

Ahh I didn't notice you wanted to do bi-directional operation the private cloud was setup for a DR site type of  operation, not a both sites live copy data for DR in opposite directions. I am not sure what our best options are for yoru scenario - althoguh you should be able to get one direction to work.

[teevee]

Yeah the one direction of restoring an MMS job on the CASO does in fact work, however I need to stop services on the MMS for certain jobs for some reason or it tries to restore from the MMS and ends up failing as I think it's timing out over the WAN (only 10 Mb).