TSM for SharePoint Best Practices/Performance Tuning..

[Leigh]

Hi All,
We have a large TSM for SharePoint environment and the backup performance is lousy. Does anyone have any best practices or performance tuning information so I can check that my setup is optimal?

 

[Jeff_Jeske]

Are you using the OEM DocAve agent for SharePoint?

 

[spiffy]

Has anyone been able to find a performance tuning doc for TSM for SharePoint?

I am using TSM diskpool as the media device, and have set the maxfilesize from 50MB to 100MB(as per another post here in ADSM), but i want to know what is recommended in.

 

[Jeff_Jeske]

I'm not sure how much changing that size will help.

The only performance enhancment suggestion I've seen that does work is running multiple schedules at the same time.

 

[spiffy]

where do you set the multiple schedulers up? on the server that has the TSMSP Media Service?

do you need multiple nodenames too?

 

[Jeff_Jeske]

Instead of scheduling a backup of a-z at 1800 you schedule three jobs to process chunks of the entire site launch A-J, K-S, and T-Z all at 1800.

 

[spiffy]

This scheduling is done withing the Sharepoint Manager Application?
I did not install or configure this part when we got TSM for Sharepoint, so i am not familiar with the internals yet of the application...

thanks though, i will take a look.

 

[rallingham]

Front End Servers

If you have a large Sharepoint set up have you followed the rules of no more than 4 sharepoint boxes per frontend server? You can try splitting them up and it may help a bit.
However that said, Sharepoint backup is done via the LAN. That can slow things down. It may be possible to put a Storage Agent on the Front End Server for data transfer to TSM but the back end servers will still use the LAN.

 

[Jeff_Jeske]

When you say backup performance is crappy what are your throughput rates?

We have one Sharepoint server with two web servers. The current size of the server is 188GB and it has about 600k items. This server takes about 16 hours to perform a full backup. We run one full backup every month with daily incrementals in between.

A normal 12GB (average daily change) incremental backup of the same server takes only 1.5 hours.

I do feel the full backup is slow but that is expected. Even Microsoft will tell you that item level backups are slow and should be addressed via SharePoint recycle bin and document library versioning.

We tolerate the full backup as it only happens once a month. If it runs for 24 hours no big deal. We use the daily incrementals to protect sites that have not been configured with a bin or versioning. It is rare that we are asked to recover something as most restores come from the recycle bin.

In the event of a full DR we would fall back to the server level SQL DB backup performed by a standard TSM BACLIENT.

 

[rallingham]

Performance is crappy.

I should have noted that I was talking about a rather large farm with 40 odd servers and close to 20 TB of data. Going over the LAN can be a bit tough in a case like this. You then need multiple front end servers and balanced work-flow.
For your smaller installation you will be fine.
As I said I should have prefaced my comments as they pertain to a large enterprise setup.