Would a multi CPU server be a good idea for Backup Exec

[Bill_Gist]

Our Backup Exec media server is Windows 2003 running on a machine with a single CPU, which is a Pentium running at 933 MHz.

We've just noticed that during the verify phase of our backup jobs, we peg the CPU at 100% usage.

We're thinking about getting a new server with a faster processor. Would it help if the new CPU has two (or more) processors?

We are running Backup Exec 9.1

[Deepali_Badave]

Hello,

Multi-processors in the Backup Exec server will not make any remarkable difference in the backup performance. The load will be dispersed based on the Operating System, but a single process will not be split between multiple processors.

Tape devices cause the most serious bottleneck in backup performance.

In the case of a standard, single process, non-compressed backup CPU can be of low speed. However, if multiple backup processes and software compression are used, higher speed CPU and more memory may be required.

If there are other processes running, for example: online backup, the CPU requirement will be high. Software compression adds additional overhead.


Performance of the backup job can be improved by checking the following option :

Click Tools | Options | Job Logs | Select "Summary Information Only"

Backup jobs will run effectively in dual processor environment.


NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[Bill_Gist]

In that situation where the verify phase of the backup job pegged our CPU, the destination of the backup output was a disk. So we believe that we need a faster processor.

I was wondering about the scenario where we are running another backup job at the same time, with the target being a different disk. In that scenario would Backup Exec be able to put that second job onto a second processor if there was one?

Or is Backup Exec just going to let Windows 2003 figure out what to do with the second processor, if there were one?

Thanks for being there to talke to me about this. I appreciate it.

[Ken_Putnam]

Multiple processors won't help there either

BackupExec is not written to multi-thread. If you want to run multiple B2D jobs, separate disk controllers or at least separate channels for each drive would be the place to start, and you'll need lots of RAM also. How much do you have in the present server? how much were you considering for the new one?

[Bill_Gist]

Thanks for your answers so far, I really appreciate it. Also thanks for asking about RAM. I was going to ask you if there's somewhere I could look while Backup Exec is running our B2D jobs to see how much memory would be helpful here.

Our current server has 512 MB of RAM

In the new server, I want to get plenty of RAM, without having so much that it goes to waste. Is there some rule of thumb or some formula that would tell us how much RAM Backup Exec can make good use of in the scenario where we are running, e.g. 4 B2D jobs, where each one is going to a separate disk, that's capable of say, 100 MegaBytes per second.

[Ken_Putnam]

It's been a while since I did much memory tuning, but with v7 and v8 I came to the conclusion that you needed 64MB per concurrent job to get acceptable throughput (those were tape jobs, and I never had more that two drives per SCSI channel.

if BackupExec has the same kind of bloat from level to level Microsoft's products do, I would suspect about half again would apply to v9 and v10, so say 96MB per concurrent job.

Back to the question of multiple CPUs. Is this going to be a dedicated BackupServer, or will anything else be done/housed on the same box? If it will not be a dedicated server, then a second CPU would make a difference

[Deepali_Badave]

Hello,

Please update us on this issue.

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[Bill_Gist]

Thanks to both of you Ken and Deepali. I believe I have the info I need now. I appreciate your help.