Comprehensive data protection for all workloads
Post Reply
pigbloke
Novice
Posts: 9
Liked: never
Joined: May 07, 2010 1:28 pm
Full Name: Nick Boarman
Contact:

Backup throughput question

Post by pigbloke »

Hi

I have just inastalled Veeam 4.1.1 on a VM in our VMware environment for evaluation. The first thing I thought I'd do was do a quick backup test on an inactive VM to get a feel for the throughput.
Created a backup job using network mode, started the job - 40GB backed up in 23 minutes.
Ran the job again - 40GB backed up in 46 seconds, great.
Created a second job using Virtual Appliance mode, started the job - 40GB backed up in 26 minutes.
Ran the job again - 40GB backed up in 13 minutes, not so good.
I ran the jobs a few more times with the same results.

I then powered on the backed up VM and ran the jobs again:
Network mode - 1:46 minutes
VA mode - 2:20 minutes
I again ran the jobs a few more times with very similar results.

I know this seems trivial, but is there a reason for the disparity in throughput using VA mode when the VM was powered down? Is this expected behaviour? We are unlikely to back up inactive VMs in the real world but I want to make sure I haven't made any fundemental errors in my backup job config before I start testing in earnest next week.

Many Thanks

Nick
Gostev
Chief Product Officer
Posts: 31814
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup throughput question

Post by Gostev »

Nick, yes - there are some issues with leveraging СBT (changed block tracking) on powered off VMs. I had devs researching this for me a few months ago, and the conclusion was that with powered-off VMs, under certain circumstances VMware API does not return correct changeID information, so Veeam Backup has to scan whole VM to determine changes since last job run (which drops processing rate). It was also noted during our research that performing power-on cycle on affected VM makes the issue go away.

So bottom line is - you are not doing anything wrong, it is indeed possible to see this issue with turned off VMs. If the issue is encountered, backup will still be performed correctly, because after getting invalid changeID, our product will automatically failover to using native change tracking mechanism (to ensure there's no data loss or inconsistency). But due to this, backup will go slower than with CBT (which is what you are seeing).

Thanks!
pigbloke
Novice
Posts: 9
Liked: never
Joined: May 07, 2010 1:28 pm
Full Name: Nick Boarman
Contact:

Re: Backup throughput question

Post by pigbloke »

Gostev, thanks for the comprehensive answer, that explains the problem I'm seeing. I'll carry on my testing with my config as it stands and run all my backups on powered on VMs.
Nick
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 90 guests