Optimizing Exchange 2010 for backup

[jparr]

I am backing up my Windows environment over a 10mbit WAN connection using Veeam. The total used space in the datastore is about 1.5TB, with 200GB or so being the Exchange message store, and another 600GB being the file shares on the file server. The backups are quite efficient, DCs only replicate about 100MB each night, file server with 50 users actively working is less than 1GB each night. The problem child is the Exchange Server. Every night the Exchange job replicates just shy of 10GB of data. I really don't believe that we are generating 10GB of email each day, I think the dedupe/incremental magic doesn't work well for large files when transaction logs are being applied and their structure is changing. Are there any optimizations that can be made to the Exchange Server to store the data in a more Veeam replication friendly way?

[Vitaliy S.]

Exchange and SQL Server VMs will always generate large increments because these applications are heavily using transaction logs. This generates a lot of file system changes in the VM virtual disk, so there is no "special" magic/steps that should be taken to optimize the size of the incremental changes for these VMs.

On the other hand, you can reduce the size of the increment stored on the target repository by choosing WAN target in Advanced Job Settings -> Storage.

Hope this helps!

[itdirector]

We are in the same boat. Our Exchange 2010 live datastore server is about 700GB (about 400 mailboxes) & it generates about 80GB in changes every day; no way are we getting that much email. It is the way Exchange 2010 works. I haven't found a way around this issue.

On the ESXi server that the Exchange 2010 VM is on, the hard drive lights blink non-stop throughout the day, even on weekend when there is basically no load. (only Exchange 2010 VM's run on that ESXi box).

I've tried everything, including giving that Exchange 2010 datastore VM, 32GB of RAM & 4 vCPU's.

If anyone has any success with reducing the daily data change, or lowering the constant read/write to the harddisks, please share (we have a constant 9MB read / 7MB write on that VM - resource monitor within Windows).

Thx.

[Frosty]

You might want to check what the settings are for the mailbox database Maintenance Schedule, as that moves around large amounts of data in the mail stores. I've configured mine to only do maintenance at the weekends. So my weekday backups are small, but then I get much larger ones generated after the maintenance runs (anywhere from 30GB to 60Gb or more, that's with our 150 user Exchange environment).

[itdirector]

Thx Frosty; but with Exchange 2010 SP1, you can no longer set the maintenance schedule - it is automatic & throttled.

[smile_dav]

I haven't tried it, but does this work?

http://technet.microsoft.com/en-us/libr ... .141).aspx

[yizhar]

Hi.

From the Exchange side - the change rate values seems reasonable to me, and I don't think that you can optimize them further.
You can even expect to get higher change rates caused by normal operation, maintenance, or error (a single problematic activesyne device can cause lots and lots of disk IO), so your backup infrastructure should be able to handle even much higher change rates.

My suggestion - do not try to minimize exchange as your findings are normal and even modest.
Instead - try to improve and optimize the backup process, to be able to handle even more changes.
Some tips:
Do you have a local backup repository at production site, or is WAN backup/replica your only backup?
You should have a local repository and use it as the first line of protection - this can easily handle those change rates.
The backup/replica over WAN should be only the second copy of your systems.
Optimizing WAN backup:
* Plan for using the new WAN acceleration and copy jobs expected in next V7. These will not only improve WAN backups, but also be able to do it outside of the "backup window" because a copy job will use the onsite repository as source (primary backup at production site) , and not the production VM.
* Plan for upgrading WAN bandwidth if needed. These days upgrading from 10mbps to 20/30/50/100 will not be so expensive.
The 10mbps line you have today might not suite your needs.

Yizhar

[Ikes73]

Hi , I hope I can go on with this existing thread.
You can find a lot of similar threads concerning the backup of Exchange but I can't get a satisfying answer to my problem.
We backup our Exchange 2010 Full once a month, incremental daily. High compression, optimize for local target, use CBT and enable application-aware image processing.

The disk containing the edb's is about 500GB in size, an incremental backup gives 130 to 200GB data read ! (I believe that end-users are pretty inventive in their email beaviour , but ... that's a bit too much)
The disk containing the logs has an incremental backup data read of 26 GB.
Given 30 incrementals a month = 6 TB !!!

I do understand that exchange (2010) is performing an continious defrag and compacting in background which causes a lot of blocks moved around in comparing to actual data transfered.
Since CBT is block level ...

So there has to be a MUCH better way of backing up exchange databases I asume ?

I see the same on our SQL servers with that difference that SQL doesn't do defragging ?
On our dbase disk there is a daily data read around 30 GB on both SQL server. Log files are also on a different disk here.
I did some SQL scripting counting the daily data change and I can't get to 30GB (which is a lot for our relatively small environment).
How is SQL playing on block level and how can we tackle this ?

Tx in advance !

[foggy]

I've re-merged your post into more relevant discussion.

30-40% change rate is quite typical for Exchange server with 500GB mailbox store. Among possible steps to optimize size of increments are using smaller block sizes (WAN target) and scheduling Exchange maintenance tasks for specific days only. Btw, here's another existing topic regarding that: Exchange backup and replication files are huge.

SQL Server also generally uses small blocks and performs very small unique changes across the whole VM disk, while Veeam B&R copies the entire 1MB block (if default Local target setting is used) despite the fact that only, say, 4KB are changed within it.