Exchange and CBT

[chri5]

Due to some disk space issues I have been moving a number of mailboxes between databases on my exchange server. Usually my reversed incremental job takes about an hour but after moving about 15GB of mailboxes yesterday my backup went up to 10 hours with a vrb file of 75GB! I understand the overhead involved with reversed incremental and exchange creates a lot of changed blocks even without this sort of activity.

Would I be best changing to forward incremental during the mailbox moves, my concern is how long it would take to do a synthetic full?

Thanks
Chris

[dellock6]

Chris, if you are going to optimize disk content in incremental situation (regardless is forward or reverse) the next run will see a huge amount of changed blocks.
If you are running reverse incremental and you environment is not a 24h*7days, you can arrange to do your changes before the weekend so even an incremental can complete without impacting users.
Forward incremental can be faster in these situations since it creates only 1 I/O per saved byte, while reverse has a 3 I/O activity per saved byte.

To me, it's more an organizational aspect, you need to choose carefully "when" to do those maintenance...

Luca.

[chri5]

Thanks for the reply, we are 24*6 so I don't get much time to do these changes but guess I'll have to work around it.

Cheers
Chris

[dellock6]

Then, probably forward incremental can help you in reducing the backup windows.

Luca.

[chrisdearden]

Which version of exchange? As I understand it Exchange 2010 is a little more efficient about serializing its writes to reduce the numbers of changed blocks.

[dellock6]

Ah, for my testings is the opposite, it serializes writes to reduce I/O so it can run on cheap storage, but its wide-striping techniques is worst on CBT than previous versions. I wrote about it a while ago:

http://www.virtualtothecore.com/en/?p=3765

Luca.

[chri5]

Running Exchange 2007, I found that moving 15GB data between databases increased my backup transfer from it's normal 10GB approx. to over 80GB. I don't think exchange was designed with CBT backup in mind.

[dellock6]

Not at all! And from the technical info I read about, the engine behind the new Exchange (and also SQL 2012) would be even worst...
Sometimes I end up doing a full backup every night, in same cases it takes less than computing all changed blocks...

Luca.

[chri5]

Sometimes I end up doing a full backup every night, in same cases it takes less than computing all changed blocks.

The thought had crossed my mind, might need a bit more storage space though

[chrisdearden]

Ah, for my testings is the opposite, it serializes writes to reduce I/O so it can run on cheap storage, but its wide-striping techniques is worst on CBT than previous versions. I wrote about it a while ago:

http://www.virtualtothecore.com/en/?p=3765

Luca.

I suppose it depends on that block size ? If exchange 2007 writes to disk more often , would it not change more blocks for a given level of data change due to fragmentation of that data over the disk?

Moving 10Gb of Data from one db to another is presumably going to create something like 4 times that number of changed blocks given that each DB file and transaction log would have been written to ?

[dellock6]

It depends on the size of the vmdk also, CBT has variable size and it grows while the vmdk grows, but I think at every level, the way Exchange writes creates penalty on CBT. Not sure if it's 4 times, but for sure the penalty is there to see. Really nothing to do sadly, only size accordingly both production and backup storage to be fast enough to be complete backups in the desired timeframe. As I wrote in the article, Exchange on cheap storage is a false myth

Luca.