cancel
Showing results for 
Search instead for 
Did you mean: 

Slow B2D speeds in Backup Exec Quickstart 2010 R3

Estranger
Level 3

I'm trying to perform a full B2D backup of a 2003 R2 Enterprise server with Backup Exec Quickstart 2010 R3 (fully up to date) and I'm getting a very slow job rate of around 100MB/min. The B2D location is a HDD cartridge connected via an internal Dell RD1000 Sata drive carriage. Apart from the excruciatingly slow transfer speed I'm also noting a single core jumping up to 80-90% when the backup task runs as per the attached image. Dragging and dropping files to the removable drive yields usual speed for a 5400rpm drive. The server is generally under a very minimal load when the backup task starts and even whilst the task is running disk, pagefile, ram and CPU usage are all quite low. I have tried defragging the servers hdds and disabling anti-virus and get the same result. I'm not really sure what else I can try to fix these slow speeds.

The server is mostly used for crystal reports and mass mailing and has Apache web server installed to display html results of the crystal reports and has 1 SQL db of 1gb running.

B2Dtest all passes except for 1 warning:
Traverse Volume Info - WARNING - FindFirstVolumeMountPoint() failed: (0x3ed) The volume does not contain a recognized file system.

Server specs are:
1x INTEL XEON E5520 PROCESSOR (2.26GHZ, 4CORE)
8GB MEMORY FOR 1CPU (4X2GB DUAL RANK RDIMMS)
2X 320GB SATA 7.2K 3.5" HDD (RAID 1)
1x PERC 6/I RAID CONTROLLER CARD 256MB PCIE 1.0

OS is 2003 R2 Enterprise SP2


Any idea on where I can go next would be greatly appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions

Estranger
Level 3

All sorted! Turns out the application designed to set the SATA port's DMA enable hadn't worked. Re-installed it and restarted the server and am now happily backing up at 2000MB/min+. Also explains the massive spike in CPU because that one thread would have been trying to handle all the data transfer.

Once I noticed the DMA issue I did a seach and found this article that I'd never seen before.

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

 

Thanks again to both of you for your help!

View solution in original post

5 REPLIES 5

CraigV
Moderator
Moderator
Partner    VIP    Accredited

Those server specs look fine, so I'd start by checking to make sure that the B2D folder is excluded from any AV scan, and that the BE services are also excluded.

You can test this from a Windows perspective by stopping the BE services, and then running an NTbackup of the data. If the speeds are the same, then the issue lies with the device itself.

Thanks!

pkh
Moderator
Moderator
   VIP    Certified

What happens when you backup to a B2D folder defined on a internal drive, not RDX.

Estranger
Level 3

I added the Removable B2D folder to the exclusions and also added all the BE services to the exclusions and got the same result. I stopped all BE services and ran NTbackup and it ran just as slowly as BE was. When NTBackup was running that same one core jumps up to 90% usage.

I defined new B2D folders both on one of the NAS's and on the RAID which is being backed up. Those went through fine. Expected speeds on both and about a 5% rise in CPU usage spread across all 8 cores.

Tried excluding VSS and system state from the backup but it still runs slowly and often hangs at the 4GB mark.

Seems it is definately related to that RDX drive and that massive spike in CPU usage on that one core. Unfortunately I can't see any obvious sign of what is spiking that core.

 

Thanks to both of you for your help.

CraigV
Moderator
Moderator
Partner    VIP    Accredited

...OK, so this eliminates BE as the issue. See if you can increase the priority of whichever application runs the backup during the run and see if this helps at all.

Thanks!

Estranger
Level 3

All sorted! Turns out the application designed to set the SATA port's DMA enable hadn't worked. Re-installed it and restarted the server and am now happily backing up at 2000MB/min+. Also explains the massive spike in CPU because that one thread would have been trying to handle all the data transfer.

Once I noticed the DMA issue I did a seach and found this article that I'd never seen before.

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

 

Thanks again to both of you for your help!