Service console agent or NBD mode: questions

[Moebius]

I was under the initial impression that backing up a VM in the service console agent ("Network") mode was the same thing as the vStorage API "network" (NBD) mode. It appears I was wrong.
Could anybody explain how these two modes differ?

One installation I have consists of 6 ESX 3.5 hosts (IBM Blade Server H with 6x 2-socket quad-core blades) with FC SAN shared storage (IBM DS4700). The Veeam server is a separate, physical Windows 2003 box with 1 TB of local storage. The VC is a VM.
The Veeam 4.0 server sees the VC and the hosts only through the LAN (1 GB Ethernet link).

I experimented various backup modes and destinations to see which one is faster and the results left me pretty perplexed. I made several full backups of the same VM, a W2k3 domain controller with 36 GB of disk.
The overall performance has undoubtedly improved upgrading from Veeam 3.1 to 4.0. However, I would still expect a better speed of each job.
Furthermore, I'm even more confused when I compare the job results obtained with different settings. Please bear with me:

1. Backup mode: "Network" (Service console agent) - destination: localhost (Veeam server): 41 MB/s (optimal compression); 56 MB/s (low compression)
2. Backup mode: "Network" (Service console agent) - destination: shared storage (vmfs datastore on the SAN): 46 MB/s (optimal); 51 MB/s (low)
3. Backup mode: vStorage API (NBD) - destination: localhost (Veeam server): 22 MB/s (optimal); 27 MB/s (low)
4. Backup mode: vStorage API (NBD) - destination: shared storage (vmfs datastore on the SAN): 23 MB/s (optimal); 22 MB/s (low)

On another, smaller installation, I have two ESXi 3.5 hosts with local storage only (no SAN). Also in this case the Veeam server is on a physical box on the LAN.
In this case, the backup tests were made on vStorage NBD mode or on Network agentless mode, using the Veeam server storage as destination. Also in this case, the network, agentless mode gave significantly better results (though the absolute speed values were much lower than the respective values of the full-ESX installation).

Are these results to be expected? Why is it that the "Network" mode is always about 2 times faster than the recommended vStorage mode? I kind of expected exactly the opposite. Or am I missing something important here?

And, would I see much better results upgrading to ESX 4?

[Gostev]

Lucio, most of your questions are answered in my long post here:
http://www.veeam.com/forums/viewtopic.p ... 2041#p8442

In short, if you want to do network backups, stick Veeam Network mode while you are on ESX 3.5, then switch to vStorage API Network mode after you upgrade to ESX4 (you will get very significant boost in incremental backup speed).

But of course, given that you have shared FC storage, vStorage API SAN mode will be even better choice hands down (whether you are using ESX(i) 3.5 or ESX(i) 4.0). Upgrading to ESX(i) 4.0 and using vStorage API SAN mode is how you get our promised "10x" increase in the backup speed.

[tsightler]

Disclaimer: I am not an Veeam employee, just a user, but here's my explanation:

1. Backup mode: "Network" -- This method uses a simple "agent" that runs in the ESX service console and, for all practical purposes, simply copies all of the files from the VMFS over the network. Whether full or incremental, it has to read all of the files, but for incrementals it only sends "changed blocks" to the backup server.

2. Backup mode: "vStorage API" (NBD) -- This method copies the data from from the ESX console using the Network Block Device, which is basically a method of presenting a block device on one system to another system across the network. This method is generally one of the slowest methods because the ESX host has to read the data and present it to the Veeam server, while the Veeam server has to transfer the entire VMDK file via the network.

In general, the vStorage API mode that is "recommended" is vStorage API SAN mode. With vStorage API SAN mode the Veeam server access the underlying storage directly so the ESX host isn't even involved in the process, well, except to create and remove the snapshot.

That being said, if you were using ESX 4, vStorage API via NBD would still likely be MUCH faster than "Network" (Service Console Agent) mode. That's because, with ESX 4, you can leverage block change tracking, so, only blocks that have changed since the last backup have to be pulled across the NBD device. In most cases, with ESX 4, vStroage API (NBD) would still beat Network mode because, while the Network mode also only sends changed blocks, it has to scan the entire VMDK to determine what blocks have changed, while vStorage API (NBD) mode can use the block change tracking file to know which blocks have changed.

So to summarize, with ESX 3.5, I'd expect Network (Service Console Agent) mode to almost always be faster than vStorage API (NBD) mode, but with ESX 4, it's the exact opposite. On the other hand, vStorage API (SAN) mode would generally be faster than Network mode with ESX 3.5, and MUCH faster with ESX 4.

I hope I got all of that right.

[Gostev]

Yes, you did get this right. Thank you