Back up to a San is very slow

[snowsnake]

Good morning.  About 3 weeks ago I began noticing that my daily incremental back ups were running slower than usal.  They would average 560 mb a minute now they are running at 70mb a minute.  This is also happening with my full tape backups on the weekends.  They all use to run around 560mb a minute and no anywhere from 33 to 60 mb a minute.  I am not sure what else to check.  The servers are both Dell's, a 2850 and a 2950 and I am running a Dell 3000i san.  I am using Symantec 12.5 back up.  Like I have stated before, I am not sure why this has slowed down.  Any help would be appricated.

Thanks

[Symanticus]

May I know what is your deployment strategy ?

perhaps using -SAN mode backup can faster the backup process.

[CraigV]

If you're using a SAN, look into SAN SSO which ships with Backup Exec (and is licensed).
It will allow you to utilise the full speed of your SAN, taking the network out of the equation. It will allow you to share your tape drive with other servers, and they can backup to that (assuming that your tape drive is connected to the SAN).
Backup times will increase, because currently your backups are going across the LAN. 4Gbps SAN vs. 1Gbps LAN...
Have you considered this?

[teiva-boy]

Mr SnowSnake,

Please try to use something like the built-in FTP program via command line with WIndows and copy data from the SAN to a host.

When the transfer is complete, you will have a throughput figure in Kb/s.

There is a bottleneck somewhere in your network, and that dramatic change in throughput happened more than likley becuase of some sort of environmental change.  Whether it be software, driver, disk config, AV software, etc...  

Disable AV, test again, update NIC drivers, and tape drivers, test again, defrag, and even playing with MPIO if your array supports it.

[CraigV]

MPIO will help with multi-pathing, and assuming that the tape drive is also connected to the SAN.
However, those jobs are going across the LAN...that's always going to be the bottleneck, and SAN SSO will help with this.

[CraigV]

Any news on this one...?

[Symanticus]

Hi Craig, does that means SAN SSO license is another option that we have to purchase separately ?

and one last question, so in this case by using the iSCSI SAN connection sharing the same switch we can backup the host into the iSCSI SAN storage off the LAN ?

Thanks.

[CraigV]

Hi Albert,

SAN SSO is another license that you need to buy, yes. From there you run a wizard on the server that has BEWS on it, and you need a license for a full installation of BEWS on any other server you want to backup via the SAN. The benefit of this is that it offers backups at SAN speeds, and takes the performance hit off your LAN. Your jobs would therefore finish a lot quicker.
You can read up on it here:

http://support.veritas.com/docs/258734

[Symanticus]

OK, thanks for the clarification Craig.

Cheers.

[ajanelson]

Did you purchase the SAN SSO? did it help?
I am also suffering from slow backups to a SAN using ISCSI.

From reading the docs on the SAN option it helps with syncing multiple media servers sharing one san. I only have one media server talking to one san

[CraigV]

snowsnake: Any news on closing this off as a solution if it worked at all?




ajanelson: It cut my backup times down by about 60%...it really does help. 4GB SAN is far quicker than running across a 1GB LAN (or slower).

[teiva-boy]

SSO and iSCSI dont mix.

SSO is meant for sharing tape not storage.  I see no mention of a bottleneck to tape, just to disk.


I do not believe SSO is the answer to this problem 

[CraigV]

...the actual problem lies when backing up to tape as well...states that clearly, hence suggesting looking at SAN SSO, which would actually help in decreasing backup times to tape.

Thanks.

[ajanelson · Accepted solution]

I have managed to solve my problem.

The media server is connected to a SAN via an 2GB ISCSI link. Manually copying a file via this link produced the expected speeds. However, backing up was very slow (about 200MB/min).
I couldn't see how the slow backup speeds was caused by the network.

I then saw an article from a similar case and a suggestion was to cxheck fragmentation.
I saw that the ISCSI SAN partition was heavily fragmented. I used auslogics Disk defrag to defrag and optimise the SAN partition.

My backups are now running as expected. Currently performing a GRT backup of Exchange at 1115.0 MB/min. before this used to run at 150MB/min.