Exchange 2007 Backup using block tracking backup (VEEAM) registers EXTREME disk change per day


I have a virtual Exchange 2007 system (VMware VM's) that is being backed up by VEEAM every night using block-tracking / snapshotting (standard Veeam backup strategy).  The user load is about 200 active users.  Every night, the backup is taking in about 75GB of data for the mail store backup of (5 different databases).  However, if I look at the STORE SIZE, the store is not growing by this much at fact, if the store grows 1 - 2 GB per day, that's a VERY BUSY email day.  

I have other sites with MORE users running Exchange 2010 that is taking about .... 15GB of backup data (also using Veeam) and their daily store is growing by 5GB or more per day.

Can anyone think of any reason why this backup would be tracking SO MANY block changes?  We worked with VEEAM, and they also agreed that the backup was much larger than they would expect ... but we ultimately could not resolve this with Veeam.

Can anyone think of a way that I can track down why this disk is catching so many changes?  

About the Exchange system:

Exchange Version:  Exchange 2007 with latest SP and rollup
Exchange Setup:  5 mailbox DB's, 1 public folder, NO circular logging.  (1) CAS/HT server, (1) Mailbox server without CAS or HT roles
Windows Version:  Windows 2008 R2
VMWare Version:  VMware v5.5 clustered across (3) Dell hosts on an Equallogic SAN

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Before everybody starts "wading in" with oh, snapshots are not supported with Exchange...

VEEAM every night using block-tracking / snapshotting (standard Veeam backup strategy).

In response to this statement, *MOST* if not all backup applications with VMware vSphere, use the Storage API, and the only method to backup the parent VMDK, is to remove the lock of the parent VMDK, and call a snapshot routine, as part of the back, to maintain a consistent backup. Block Tracking was introduced in VMware vSphere 5.0 and later, which allows changed blocks to be tracked, which allows for a quicker and more efficient incremental backup.

So back to the question...if the blocks are changed on the parent vmdk, they are marked for backup.

You do not have any defragmentation processes, or defrag of the exchange database occurring which could cause these excessive block changes.

Again it's not actually a Veeam issue, Veeam just uses the information generated from VMware vSphere.

Have you run any scripts to check the daily change rate ? e.g. CBT changes from day to day, hour to hour...and then you can graph these changes, and see what the results are.

You could also try resetting the CBT tracking file.

If you want the poweshell scripts please ask.
jkeegan123Author Commented:
Yes I think anything than could get to the bottom of this would help... And I realize that this does have to be something that is changing or 'churning' the disk,and that it's not actually a veeam issue... I just can't figure out what is making so much 'change' when there is no data that I can see being added.... So yes, any suggestions that you could've offer to find out what could be doing those would be great.

I was thinning maybe it's a looping message, or a broken exchange indexing process... It's definitely not a Defrag process.

I don't think that resetting the chance file world be good since that would actually cause data to not get backed up I think, am i right?

Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
If you reset the tracking file, then in effect you are triggering a new Backup (FULL) again.

we use these scripts here

originally used for working out data sizes in replication via WANs, but we use them for sizing backup jobs, WAN replication, tracking large changes in VMs.

These scripts use CBT, so this is the info that is recorded in the VM change....and hence what Veeam would backup as an incremental, so if both these scripts and graphs also correlate with Veeam backups, then you will have to look further into the changes in the VM.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jkeegan123Author Commented:
@Andrew Hancock - I'd love to check out those scripts, this has not been resolved yet...we're just committed to having really large Exchange Backups.  For all I know, a message looping between folders via a rule could be causing this high level of churn.
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
scripts were linked to in last posting.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.