Exchange 2007 very slow backup/VSS failed

[eric]

Hello All,

I am testing Veeam Backup on two ESX vCenter VM's. One, an Exchange 2007 server, is giving me trouble.

The server is 572GB. When I first ran the Replication job the VM summary screen reported that VSS Freeze failed to prepare. The job is running but the throughput is horrid, under 1 MB/s.
There is a termporary VM snapshot running on the Exchange VM. The Backup mode is service console agent.
The Storage is a Dell Equallogic SAN.
The destination ESX host is a DAS datastore.

At this rate it's going to take a long time to complete the first replication job. It's only done 5% in 7 hours...

Should I cancel this backup and try to determine the source of the problem or let the backup complete and then troubleshoot?

If I cancel the backup will this cause an issue with the Veeam snapshot on the VM?

Eric

[Gostev]

Eric, you can cancel jobs at any time without any issues. Existing snapshot will be properly removed.

[mdornfeld]

Eric,
Our exchange mailbox server (2003) also goes significantly slower on backup jobs then our other jobs. I have no idea why though...

Gustov, do you know why Exchange backups tend to take longer (I use VCB SAN - agentless for my settings with VSS enabled). Do you have tests at Veeam that show similar results, or are Eric and I anamolies?

Thank you. Matt

[tsightler]

Our Exchange server backups are also slow compared to many of our other systems, however, they are roughly the same as systems with other active databases. Exchange is basically a special purpose database server, during a normal day there are lots of small block changes made across a large portion of the EDB files, as well as log files being written, etc. I suspect that this random change of blocks spread across a relatively high percentage of the disk (compared to application servers or file servers) simply causes more processing overhead.

We have three servers that run at a very slow rate (roughly 25% of the performance of our other server). 1 is the Exchange server, and the other two are both active MSSQL servers which have a very high rate of random updates during the day. My guess is this is simply the worst case scenario for Veeam (lots of changed blocks spread randomly across the entire virtual disk).

I suspect this will be a scenario that will see huge improvements with the block change tracking feature in vSphere 4 once Veeam 4 hits the real world.

[Gostev]

Matt,

Generally speaking, if everything is about the same:
- same production VM storage;
- same backup storage and Veeam Backup server;
- about same VM sizes;
- about same amount of changes before incremental pass;
Then there should not be any big differences in incremental backup speed - because backup is done on image level, and actual VM content does not matter.

Tom's points above are valid; have you checked the size of increments for your Exchange server comparing to other servers? Also, VM size does matter because Veeam Backup has to get whole VM from storage to determing the changed blocks.

There is only one thing I can think of that could take very long in case of Exchange server: snapshot creation (more precisely, VSS freeze part of it). This can take as long as 10-15 mins, and this extra time affects the job's duration and so the avg. performance rate counter, which is calculated based on total job duration (not just the time when actual data transfer took place).

We should be able to do some profiling based on your logs and see what operation is taking much longer in case of Exchange server VM backup comparing to some other VM you are happy about.