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

Backup Exec slow job rate

Created: 22 Dec 2013 | 3 comments

Hi,

I have a single backup exec 2012 SP3 media server running on windows 2008 R2. This media server is responsible for backing up 2 physical servers and 8 virtual machines.The VMware agent is configured to connect to vcenter.

The VM environment is running esxi 5.0

The backups have been running without issue since upgrading to 2012 approximately 6 months ago. The media server is fully patched and so are the servers. I currently backup all servers to disk and duplicate to LTO4 tape drive. The problem that i am having is that duplication from disk to tape for the VMware job has dropped from 1,300MB/sec down to 300-400MB/sec. The job rate from the physical server jobs duplicating from disk to tape does not have this problem as they still duplicate at 1300MB/sec, so it kind of looks like an issue with the VMware job. I have edited the backup job to back up straight to tape and the job rate is at 3,000+/sec.

I have checked AV scanning schedules and there is nothing scheduled or running during this time. Basically the backup to disk part of the job backs up using SAN transport method and runs at approximately 9,000+/sec and backups up 750GB of data within a couple of hours, this part of the backup is still consistent. So really the job rate changes when it is time to duplicate to tape.

Regards,

Operating Systems:

Comments 3 CommentsJump to latest comment

Gurvinder Rait's picture

Are you backing up to a B2D or a Deduplication storage folder ?   Duplicates should be allright from the B2D but Duplicates from Dedupe folder may take a little longer.

Jamie132's picture

Hi,

Thanks for the reply. No I am just backing up to b2d. I have two other jobs that backup b2d and then duplicate to tape without any issues. It is only the vmware job when duplicating to tape that is very slow. Backing up only b2d is super fast using SAN transport mode, and backing up directly to tape is also fast, however duplicating b2d to tape is where the slow down starts. I am wondering if it could be something to do with catalog or database.

Now that I think about it I haven't yet deleted and recreated the job. Perhaps I will give that a shot. Just wondering if anyone else have come across an issue like this before

Regards

lmosla's picture

Hello,

can you run SGMON debugging to get more information on what is going on?  see:  http://www.symantec.com/business/support/index?page=content&id=HOWTO11932

also what version of VMware are you using?