ADSM-L

Re: [ADSM-L] Exchange Legacy 2007 to VSS 2010 backup performance

2011-08-25 12:34:05
Subject: Re: [ADSM-L] Exchange Legacy 2007 to VSS 2010 backup performance
From: Ben Bullock <BBullock AT BCIDAHO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 25 Aug 2011 16:24:42 +0000
We recently moved from Exchange 2007 to 2010 on our environment. 
Just for a reference, we have about 3.3 TB of exchange data. Our TSM server is 
v5.5.5.0 running on AIX 6.1. The exchange servers have v6.1.3.0 of the TDP 
client, v6.2.2.0 of the BA client, Windows 2008 R2 SP1 and Exchange 2010 SP1.

We have found that the transfer of the data runs about the same once it starts 
moving data to TSM, but the VSS parts (which are no longer optional) caused our 
backups to take almost twice as long. 

We weren't able to find anything in the TDP documentation to tell us why 
backups were now taking twice as long, however by looking at the IO on the SAN 
and Exchange logs, we believe we were able to determine what was going on. Feel 
free to chime in if you think our assessment is incorrect.

By default, the TDP causes the exchange software do its own an integrity check 
of the database every time it does a backup, (either full, incremental or 
differential). We found that essentially doubles the time the backup takes, 
because it seems to read/check what it wants to send for the integrity check 
and then read/send the data to TDP/TSM on another pass. So you are essentially 
reading all the bits twice for every backup. It seems like a rather inefficient 
way to run it, but perhaps that's the way it has to be done.

There's a flag you can put in so that the integrity check is not called 
(/SKIPINTEGRITYCHECK), but there is an inherent risk in skipping it. Then 
again, it didn't do this check for the Legacy backups and we never had a 
corruption problem with the backups, but YMMV. Currently, a weekly full and 
daily differentials meet our SLA, and we are toying with the idea of leaving 
the integrity check on the fulls (and have it take twice as long as it used to) 
and turning it off for the differentials. Your choice may be different 
depending on your risk assessment.

Test it out for yourself and let us know if your experiences are any different 
from ours.

Ben

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Ian Smith
Sent: Wednesday, August 24, 2011 10:12 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Exchange Legacy 2007 to VSS 2010 backup performance

Our Mail/GroupWare service is migrating from Exchange 2007 to 2010 in the next 
few months. Currently we employ streaming (Legacy) backups across a private 
2Gbit bonded private link direct to LTO5 tape and get around 50MByte/s for 
fulls and around 16-20Mbyte/s for incrementals. In all we have about 20TB of 
mailstore.

I've searched the threads and the user docs, developerworks etc etc but can't 
find any real figures on how legacy versus vss backups compare. I suspect they 
will be slower, because of the additional steps in the whole VSS backup 
protocol but I'm happy to be surprised. If anybody has any real world figures 
that address the questions below, I'd be truly grateful.

1. Legacy versus VSS-assisted (MS VSS provider) backups of Exchange 2007 to TSM 
server.
2. VSS-assisted backups of Exchange 2007 versus 2010.

This is a big migration for all of us and I'd like to have an idea of what we 
should expect in testing.

Thanks
Ian Smith
Oxford University/ England.

The BCI Email Firewall made the following annotations
---------------------------------------------------------------------
*Confidentiality Notice: 

This E-Mail is intended only for the use of the individual
or entity to which it is addressed and may contain
information that is privileged, confidential and exempt
from disclosure under applicable law. If you have received
this communication in error, please do not distribute, and
delete the original message. 

Thank you for your compliance.

You may contact us at:
Blue Cross of Idaho 
3000 E. Pine Ave.
Meridian, Idaho 83642
1.208.345.4550

---------------------------------------------------------------------