Comprehensive data protection for all workloads
Post Reply
eric
Enthusiast
Posts: 39
Liked: never
Joined: Jan 01, 2006 1:01 am
Contact:

Exchange 2007 very slow backup/VSS failed

Post by 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. :cry:
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
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Exchange 2007 very slow backup/VSS failed

Post by Gostev »

Eric, you can cancel jobs at any time without any issues. Existing snapshot will be properly removed.
mdornfeld
Expert
Posts: 125
Liked: 3 times
Joined: Mar 23, 2009 4:44 pm
Full Name: Matt
Contact:

Re: Exchange 2007 very slow backup/VSS failed

Post by 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
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Exchange 2007 very slow backup/VSS failed

Post by 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
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Exchange 2007 very slow backup/VSS failed

Post by 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.
Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 280 guests