- Posts: 1
- Liked: never
- Joined: May 16, 2013 6:21 pm
- Product Manager
- Posts: 24075
- Liked: 1807 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
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!
- Posts: 59
- Liked: 3 times
- Joined: Jan 19, 2012 8:53 pm
- Full Name: friedman
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).
- Posts: 183
- Liked: 42 times
- Joined: Dec 22, 2009 9:00 pm
- Full Name: Stephen Frost
- Posts: 44
- Liked: 4 times
- Joined: Sep 26, 2011 9:47 am
http://technet.microsoft.com/en-us/libr ... .141).aspx
- Service Provider
- Posts: 181
- Liked: 48 times
- Joined: Sep 03, 2012 5:28 am
- Full Name: Yizhar Hurwitz
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.
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.
- Posts: 9
- Liked: never
- Joined: Jul 03, 2013 3:36 pm
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 !
- Veeam Software
- Posts: 19285
- Liked: 1741 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
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.
Users browsing this forum: Baidu [Spider] and 35 guests