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
-
- Novice
- Posts: 9
- Liked: never
- Joined: May 07, 2010 1:28 pm
- Full Name: Nick Boarman
- Contact:
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Backup throughput question
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!
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!
-
- Novice
- Posts: 9
- Liked: never
- Joined: May 07, 2010 1:28 pm
- Full Name: Nick Boarman
- Contact:
Re: Backup throughput question
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
Nick
Who is online
Users browsing this forum: Google [Bot] and 90 guests