Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Job Rate time is too low.

Created: 10 Mar 2014 | 7 comments

Hi,

I was OK with job rate time backing up VMware VMs @ 3 to 4 GB/min with a total size of 400 GB (4 VMs). If you see attached file, the job rate was 3+ GB/min on 14th Feb, then it reduced to just 700 MB/min, then it went to 4GB/min next week, and aftrwards, its 600-700MB/min.

Any ideas for this variable behaviour.

 

Thanks

Rizwan Ul Haq

Operating Systems:

Comments 7 CommentsJump to latest comment

CraigV's picture

Hi Rizwan,

 

You might get job slow-downs if there is some sort of maintenance task going on, either patching, AV scans etc.

Have you checked the server and/or applications (including AV and VMware) to see if anything was being done at the same time as the backup?

Alternatively, I would really suggest you do the following:

1. Make sure you're using the Symantec drivers for your tape drive (tapeinst.exe will install them), and that if you have an autoloader or library, that Unknown Medium Changer shows up for the robotics;

2. Get your drive manufacturer's diagnostic utility and run a write test against the drive to see if you can get decent throughput. you would ideally need a blank or overwritable tape for this. Also run the tests necessary to prove the hardware has no issues;

3. Make sure you have the latest SP for BE installed and any subsequent patches.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Rizwan.Haq's picture

Craig, thanks for the reply.

 

Well nothing is happening on the machines, these are SQL machines though, but no user will connect, as these will serve users not before Aug/Sep this year. 

During the last month (since after the problem started), I added a VM to this set to be backed up, I thought it could be the cause (as it has got the AV installed in VM, other VMs dont have the AV installed), so I have removed it from the backup selections list today and currently the backup is going on. 

The backup started at a good speed of 3.5+ GB/min, now after an hours' operation, the rate has dropped to 1.3 GB/min, and it will keep on decreasing and will fix in between 600-700 MB/min.

About the robotics, it shows "unknown medium changer" - see attached pls.

I am getting a reasonably good speed on other backup jobs (other servers), like above 4 GB/min. 

I have Sp2 installed (14.0 1798.1244). Have seen changed made in SP3, but that doesnt apply to my configuration, so havent upgraded.

 

During the last few minutes in which I wrote above text, the job rate has dropped from 1.3 to 1.2 GB/min. Currently it is backing up a vmdk file !!

I will keep on changing the VMs selection and will see if it is a problem with a particular VM...

 

Any more suggestins, please advise. 

medium changer.jpg
CraigV's picture

...just make sure on the Drivers tab for the tape drive in Device Manager that it shows Symantec as the provider. If not, use tapeinst.exe to install the tape drivers and try again.

I'd recommend doing a write test on that drive and see if it gives you a sustained throughput.

You can also check the Job Log to see where the backup is taking the longest time.

Furthermore, how are you backing up these VMs? SAN Transport MOde, or across the LAN?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Rizwan.Haq's picture

Hi Craig,

 

Ok - for both the drivers tape and robotics arm the driver is provided by symantec (see attached.)

 

On the write test, yes it gives a constant throughput, and it has issues with VMs only.

 

On vmdk files, the job rate decreses !! and decreases !! and dies 

 

I am pulling VMs over LAN.

 

Currently I am converting one THINK provisioned VM to thin, considering it could be the fault !!

 

 

driver.jpg driver_tape.jpg
CraigV's picture

Converting? Have you tried to run the job by excluding that particular VM from the job?

It might cause performance issues...it would be something that's continuing in the background and if the backup is running at the same time that might cause some sort of performance contention.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Rizwan.Haq's picture

Hello Craig, yes converting from Thick to thin, as in thick the full space was allocated to the machine which was 500 GB, I assumed the problem could be with thick provisoned VM, as I saw cople of VMDK files in the data store instead on just one. 

I have come to the conclusion that issue is with VM backups. As the snapshots were not removed from the datastore. 

I now have converted the machine with just one vmdk file in it, and I will test the backup today and will write here about my findings.

In the mean time, you can send me some technical docs about VMs backup using Backup exec....

Thanks. 

CraigV's picture

Hi Rizwan,

 

Great, thanks. I don't think having thick LUNs would be the issue...maybe the converting to thin LUNs would be the reason, but I guess you're about to find out. Also, I don't see having multiple VMDKs as being a problem either.

Check below for more information around BE 2012 and AVVI-based backups:

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

http://www.youtube.com/watch?v=TT1Xx1rcRFE

You should also check out the Admin Guide as this has a lot of information regarding backing up VMware-based VMs:

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

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...