FastBack Performance/Best Practice???

[jwoods]

Just curious how others are managing their Fastback jobs and dealing with performance. I have an Exchange server using LCR with 10 storage groups. I've found that I can't clump those all into one job, as this bogs down Fastback. Sometimes jobs abort. It seems that spreading the storage groups across multiple jobs works better.

Has anyone else experienced something similar? Is this common among D2D solutions? Anyone know of any best practices for Fastback?

Thanks.
jwoo

 

[mccleld]

Hey jwoods,

I've been on vacation and not keeping an eye on the FastBack subforum here so have only just spotted this.

The only statement on FastBack performance that I've seen, other than the FB Server hardware specification in the installation and user-guide, is this IBM technote which discusses FastBack Server Disk Repository IO requirements:

https://www-304.ibm.com/support/entdocview.wss?uid=swg1IC70531&myns=swgtiv&mynp=OCSS9NU9&mync=E

Unfortunately this is reactive performance monitoring, highlighting performance issues after you've already configured your FastBack Server - what I'd prefer is some pro-active/planning advice along the lines of how best to set up your repository volumes etc. For the main TSM Server component, this kind of advice is widely available, just not yet for FastBack.

HTH,

____________
David Mc
London, UK