Showing results for 
Search instead for 
Did you mean: 

Speeding up the Backup Exec Console (Not backup speeds)

I have a six node cluster with Backup Exec installed on each with 12 SAN resources attached throughout. Data total is over 100 TB, roughly 200 TB worth of backups a week (1 full with 4 incrementals) and I have a primary SSO with almost 200 GB of data in the catalog, with well over 200,000 files..

Needless to say we are increasing our SAN is increasing quite a bit and I'm getting a lot more jobs with a lot more data.

I don't have BE clustered as the Admin guide says I am not neccessarily compatible. Personally I don't want to try it because I can't reboot these systems except once a month. Anyways, I have a few questions that I was unable to find in the forums, or anywhere else for that matter,  to help organize my jobs and/or speed up my console.


1 - Would clustering be prefered? 

2 -  Can I set it up so one job utilizes more than one drive? Right now I have several jobs per server.

3 - Is there a way to set up a policy made job to have the job name or selection list name in the restore menu somewhere?

4 - When copying jobs is there a way, besides opening and saving the selection list, to not use the server being copied from?


#4 is odd, I found that it looks like BE "pipes" jobs through the server I created the job on when they are copied to another server.

ie copying selection list "E:\*.* SUBDIR" from server1 to server2

I would really appreciate the help, I am hitting my head against my desk trying to get this working.


6 node Cluster on Windows Server 2008 Enterprise, running Backup Exec 2010 R3 SP3

11 Replies

Hello JQuat, what version of

Hello JQuat, what version of Backup Exec are you using?

Sorry! I thought it was in

Sorry! I thought it was in there, 

Backup Exec 2010 R3 SP3 on Windows Server 2008 Enterprise.

Hi, 1. Clustering will offer


1. Clustering will offer you protection and availability of your media server. If the active node has issues, simply fail over to the inactive node and continue. However, clustering will not give you additional speed!

2. If by drive you mean backing up to disk, then yes. You would simply go to the B2D in question under the Devices tab, and then increase the # of concurrent jobs. You can continue doing this until the speed is saturated and you notice a drop-off in throughput to the disk.
If by drive you mean tape, then is 1-to-1 and you cannot send multiple servers to the same tape drive at the same drive. BE does not support this.

3. No...restores are based on the backup job. If you have 3 backup policies, you can't have 1 restore list. However, you could be able to go through the restore wizard and select a server, which will then prompt you for a specific tape.

4. You can try this in a CASO (Centralised Admin Server Option) environment where jobs are created on the CASO which manages the jobs themselves. Check below:


Thank you for the reply! My

Thank you for the reply!

My backups are Backup to Tape over a 4GBps fiber channel. My backup speeds are fine (just want to iterate that) It's the laggy-ness of of the console that is bugging me. I read in the BE Tuning guide

hat a catalog shouldn't exceed 750 GB, which is fine, my total is around 200 GB. However the total number of catalog files well exceeds the 200,000 files recommended, unless that means actual files that make up the catalog not files being backed up.

Also my data folders are pushing 200 MB on each server, I have roughly 60 jobs per server.

I apologize I didn't include this information in the original post but would that cause a slow down? If really got bad when more data was being added to my backups. Would setting up Clustering distribute the catalog/data folders? I have other backup servers that are not attached to the cluster that run fine without the wait times and lag.

Thanks for the other answers, but to ask another question about #4 Would doing a CASO and a Clustering be redundant? Clustering sets up a virtual server right? Or are you saying one or the other?

Thanks again!

...1 way of limiting the

...1 way of limiting the amount of catalogs is to set the retention time for this.

By default, BE will prune the catalogs every 90 days. You could set this lower on each server in question, which just means when you need to restore data from outside the range the catalogs are kept, the tape needs to be recatalogged.

Another way to limit the size of catalogs is to ensure you're not retaining all the job info.

So, to answer:

1. I suspect that means 200000 files in the catalog. I've backed up more files than that and never had an issue.

2. I don't think that clustering is going to distribute the information. I haven't set up a BE cluster (you can read up in the BE 2010 Admin Guide for more information), but it's going to need some sort of central location in order to create the cluster in the first place. If both servers have different Catalogs folders (ie. they're not shared!), then when it comes to restore data from a tape which doesn't have a catalog on the current active node, you're going to have to recatalog the tape.


Thanks again!   My job

Thanks again!
My job requires 90 day retention, and I set up the catalog to prune that already. I can't go any lower because it will take to long to recatalog the media and I have a pretty quick turn around time for my restores.

My actual shared catalog is only around 15k items, so that's probably not the problem. I am still hesitant to try clustering, We did it to an older SAN that also backed up the same way and that ended up using the copper network instead of the Fiber, much easier to manage but slower.

I've rebuilt the database, re-indexed the catalog and tried just about everything. I suppose I'll try breaking the SSO up and rebuilding that next.

I've gone through all six of

I've gone through all six of my nodes and cleared the alert history, reassociated them with the SSO and verified all the selection lists are pointing to the local node. Still takes 5+ minutes to edit a selection list.

...hit the support flag, but

...hit the support flag, but if nobody frmo Symantec picks up on this here and contacts you, I'd recommend opening a support call with Symantec directly. Post back here when you get a solution.

1 last thing to check...make sure that any AV installed isn't perhaps scanning the BE services. If so, put in exclusions for them, and then try editing a selection list again.


I'm pretty confident it's not

I'm pretty confident it's not our antivirus, we have four other backup servers and they all run fine. Although this just occured to me, at one time we had Enterprise Vault running, we never installed the agent but the services are on all the nodes. We shut them down a while ago, I can't recall if that is when the console began to lag.

Try re-registering

Try re-registering pvcalendar.ocx on the media server.

Open a cmd and browse to the Backup Exec directory. Run regsvr32 pvcalendar.ocx

Restart all BE services and retry editing the selection list.

Secondly, are you using the express edition of SQL ? If yes, what is the size of the BE database ?

Any CPU /memory spikes when the selection list is edited ? Does it take 5+ mins when creating a new selection list ?

Lastly, does this selection list contain any EV servers ?

I will try that.

I will try that. (re-registering pvcalender.ocx) Although do I do this on just the Primary SSO? (I'm assuming yes but want to verify)

Please Note that opening a selection list is just an example of problems I am having with the server. The slowdown is apparent on nodes. The following is slower than other BE servers on our network, Restarting Services, Connecting to a server, displaying jobs and job history, editing a backup job, creating a backup job,  creating a selection listsearching the catalog, deleting alerts, and several other misc things. I used to attribute it to the size of my catalogs, number of backup jobs, and amount of data being backed up. Now it's just getting unbearable, and takes 5+ minutes to do a simple task, i.e. opening and closing a selection list.

To answer your other questions, this is all coming from our Primary SSO, which is Node 3:

Looks like SQL Server 2005 is installed.

In programs and features it shows Microsoft SQL Server 2005, Microsoft SQL Server Native Client, Microsoft SQL Server Setup Support Files (english), and Microsoft SQL Server VSS Writer.

In "C:\Program Files\Symantec\Backup Exec\Data" "bedb_dat.mdf" is 91 MB, and "bedb_log.ldf" is 10 MB.

CPU doesn't get above 20% usage when opening/editing a selection list, each server is identical with 18 GB Ram and usage stays at 10.3 GB, and Dual Intel Xeon E5640 processors.

I just verified all this information.

Only Node 5 backups up our EV server, but as I said that hasn't been in production for nearly a year. However in Programs and Features "Symantec Enterprise Vault - FSA Agent (x64)" is installed. The EV services are not running.

Thanks again.