Hi All,
I'm backing up 20 VM's, and all seem to be backing up quickly except for Exchange. The Exchange server has about 250 users, and the Mail Store is about 30GB.
Even on days that there is little to no Email activity, it will take 4 or 5 hours to backup Exchange. We have SQL servers that are very busy, and they only take an hour or less.
It's running Windows 2008 Server x64 with Exchange 2007... VM Hardware Version 7. VMWare Tools are up to date. We're running vSphere 4 Update 1.
Any ideas?
Thanks!
-Mike
-
wocomike
- Influencer
- Posts: 23
- Liked: 1 time
- Joined: Dec 16, 2009 12:50 am
- Contact:
-
tsightler
- VP, Product Management
- Posts: 6011
- Liked: 2843 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Exchange Backup Slow
Exchange is always one of the worst cases for Veeam. How much VBR data is being written for your Exchange server during each backup? Exchange generally runs a "maintenance" process from 1-5AM each night (I think that's the default time). This "maintenance" touches a lot of blocks over the entire Exchange store so even quiet nights have a lot of change.
Our Exchange server is about 550 users, about 400GB, and generally sees 110-130GB of VBR data for every business day. It's much less on the "quiet" nights, only 50-60GB, but still a lot compared to the traffic.
I have my own theory as to why Exchange is so bad in concert with Veeam. It goes something like this: because the changed blocks are so spread out, it causes a lot of Veeam block (which are 1MB in size) to be changed. For every changed block Veeam has to read the old block from the previous backup file, write the old block to the rollback file, read the new block from the source server, write the new block to the backup file. That means for every 1MB block that changed, 4MB of data has to be read. In my example above, even with block change tracking my 110-130GB of VBR data generates 440-520GB of data that has to be transferred. That's a lot of data compared to all the other backups, and especially hard on the target storage since 3/4 of that data is read or written to the target disk.
Are you using Veeam 4? Is block change tracking working? How big are your rollbacks? Answer these questions and we'll see if there's anything else going on instead of the "normal" Exchange overhead.
Our Exchange server is about 550 users, about 400GB, and generally sees 110-130GB of VBR data for every business day. It's much less on the "quiet" nights, only 50-60GB, but still a lot compared to the traffic.
I have my own theory as to why Exchange is so bad in concert with Veeam. It goes something like this: because the changed blocks are so spread out, it causes a lot of Veeam block (which are 1MB in size) to be changed. For every changed block Veeam has to read the old block from the previous backup file, write the old block to the rollback file, read the new block from the source server, write the new block to the backup file. That means for every 1MB block that changed, 4MB of data has to be read. In my example above, even with block change tracking my 110-130GB of VBR data generates 440-520GB of data that has to be transferred. That's a lot of data compared to all the other backups, and especially hard on the target storage since 3/4 of that data is read or written to the target disk.
Are you using Veeam 4? Is block change tracking working? How big are your rollbacks? Answer these questions and we'll see if there's anything else going on instead of the "normal" Exchange overhead.
Who is online
Users browsing this forum: arun.kumar, Semrush [Bot] and 116 guests