version 5: direct backup from datastore to datastore?

[vladimirh]

Hi, I have two questions

Q1/ Is it possible to realize direct backup from datastore to datastore on VMware vSphere with Veeam v5.0 as well as on version 4.x?
Situation:
HW Server A with vSphere 4.1 (no ESXi) is connected to 1st (main) iscsi datastore and 2nd (backup) iscsi datastore.
On HW Server A there are virtual servers installed that I need to backup.
HW Server B with ESXi 4.1 has low performance. There is virtual server with VMware vCenter and Veeam Backup and Recovery application.
If I test Veeam Backup and Recovery 4.1.x, I can setup direct backup job from main to backup datastore.
Than I see this backup job doesn't bring higher data flow between servers A and B.
But if I test Veeam BR 5.0 it seems that all data flow this way:
main datastore ---> server A ---> server B (Veeam) ---> server A ---> backup datastore.
This brings heavy network overload specially between servers A and B.
I think this is not good solution for me.
It is design?

Q2: There is note in User Guide (verison 5.0):
"Important! ESXi cannot be used to accommodate backup (VMware limitation).
For this reason, ESXi servers are not displayed in the Destination list."
My experience is that this limitation is related not only to free ESXi, it is related to licenced ESXi version too !!!
Why this limitation exists for licenced ESXi when VMware claims that next major version will be only ESXi?

Thank you.

[Gostev]

Q1: Both 4.1.x and 5.0 backup in exactly the same way if you select the same backup mode. There is no feature loss in v5 backup engine comparing to v4. Make sure you are using the same backup mode (you may want to review sticky FAQ topic about processing modes before that).

Q2: There are two reasons:

a) Because ESXi has too bad network I/O performance to be a backup target (you are going to have to ask VMware why is that so).

b) Because generally speaking, VMFS is the last place that you want to backup your data to. It is considered to be bad practice, because if something goes wrong with the host or VMFS itself, you will not be able to recover your backups. Instead, you should really be backing up to easily accessible, non-proprietary file systems with tons data recovery tools availalble (such as NTFS, ext3, etc). For example, in your case I would recommend mounting NTFS formatted iSCSI LUN to Veeam Backup server, and backing up there.

If you really have an urge of backing up to VMFS no matter what, create tiny Linux VM with big virtual disks, and backup to it (we support direct backup to Linux targets). If you already have a plan in mind (which I would really like to learn) on how you are going to recover backup files from VMFS data store when your ESX hosts die, or when VMFS corrupts, then you can recover Linux VM VMDK files in a similar manner, mount them to another VM, and extract required backup files.

And performance of backing up to Linux target will be 10x better than backing up to ESXi (that is - if we would support backing up to ESXi).

[vladimirh]

Hi Gostev,
thank you for your report and opinion
However I have still problem with setup of direct backup.

Recapitulation of my testing:

1st step:
I installed Veeam BR version 4.1. I setup job TEST, source: server A, my virtual guest (datastore A), destination: Server A, folder on datastore B. I started this job and I saw there was minimal network traffic between Server A and Server B.

2nd step:
I upgraded Veeam BR to version 5.0. I started same job TEST and there was very high network traffic between Server A and Server B.
This traffic is comparable with speed of read on datastore A and speed of write on datastore B
It is evident that Server B participates on backup process.

My backup procesing mode is Network
I tried to modify another various options of job with identic behavior.
Remark:
- On Server A is installed VMware vSphere 4.1
- Veeam BR is installed on W2K3 Server which is virtualized in ESXi 4.1 on Server B

I dont know where I make mistakes.
Help me please.
Thanks.

[Gostev]

Please retest full backup with 4.1 from scratch. There is simply no way to perform full backup of VM in network mode without generating

traffic is comparable with speed of read on datastore A and speed of write on datastore B

You know, full backup is about moving whole VM data from host A to host B over network. There is simply no miracles that would allow to perform full VM backup over network with only

minimal network traffic between Server A and Server B

[tsightler]

Anton,

Was the "Network" mode on Veeam 4.x the old, legacy "Veeam Agent" network mode rather than "vStorage API" network mode? I honestly can't remember, but I'm wondering if this is the difference he is seeing. Obviously if you used the old "Veeam Agent" network mode then the traffic was quite minimal between the two servers since the agent would preform the backup locally on the ESX server itself. Perhaps that's what he is referring too?

I think you can still get the old "legacy" processing modes in Veeam 5 with some preference options, right?

[Gostev]

Tom, there will always be full VM backup traffic on both host A and host B, whether OP is using "legacy" network mode, or vStorage API network mode. The only difference is whether this traffic will go direct, or though proxy.

Additionally, OP said he upgraded existing Veeam Backup install with existing v4 job. And upgrade does not change the job mode, so we can be 100% sure that both v4 and v5 jobs are both running in the same mode (whatever it is).

"Legacy" processing modes remain enabled if you upgrade from v4 to v5, so job processing selection step does not change for upgrading users (it still looks the same in v5 as it used to look in v4).

[lewislampkin]

generally speaking, VMFS is the last place that you want to backup your data to. It is considered to be bad practice, because if something goes wrong with the host or VMFS itself, you will not be able to recover your backups. Instead, you should really be backing up to easily accessible, non-proprietary file systems with tons data recovery tools availalble (such as NTFS, ext3, etc).

I had no idea that VMFS was not an ideal backup target.

But, your reasons given make sense.

Thanks.

[tsightler]

Tom, there will always be full VM backup traffic on both host A and host B, whether OP is using "legacy" network mode, or vStorage API network mode. The only difference is whether this traffic will go direct, or though proxy.

Are you 100% sure about this, because my memory disagree's with you. With older versions of Veeam using the "legacy Veeam network agent" mode, if your performed a backup from one ESX host to another ESX host, each ESX host would get an agent pushed to them and backup traffic only went between ESX host, the Veeam server pretty much just monitored the process (exactly like "legacy Veeam network agent" backup up ESX host agent to Linux host). If you chose the same ESX host for both backup source and destination, the two agents would simply talk locally.

Now, with vStorage API, the Veeam server is always involved with the transfer as a proxy, but I would swear this was not the case with previous versions. It was part of the reason we started using backups to Linux servers in the first place, because we really liked the "direct to target" architecture (we were originally performing backups two an ESX host with an NFS mount). Wasn't that even a selling point of Veeam 3 and prior versions, the "direct to target" architecture!!

Additionally, OP said he upgraded existing Veeam Backup install with existing v4 job. And upgrade does not change the job mode, so we can be 100% sure that both v4 and v5 jobs are both running in the same mode (whatever it is).

"Legacy" processing modes remain enabled if you upgrade from v4 to v5, so job processing selection step does not change for upgrading users (it still looks the same in v5 as it used to look in v4).

I saw where he said that on his test, but I'm still wondering if "network" mode somehow changes between versions. We upgraded our version and I no longer have "legacy" mode options, although I admittedly didn't have any previous jobs using those options. If your saying that an upgrade doesn't change a job from legacy mode to vStorage API network mode then I'll have to believe you since I've not tested it, but it would certainly explain his symptoms, and we've seen a couple of others mention similar behavior.

[Gostev]

Tom, you are correct, and this is exactly what I said in what you have quoted
The only difference is whether this traffic will go direct, or though proxy

Other than different path for data (direct, or through proxy), full VM backup will produce about same (large) amount of network traffic on source and target ESX hosts, not matter if you use "legacy" or vStorage API network mode.

Reading back through posts above I think I may have got confused with host/server naming. I understood that back up is done from ESX host A to ESX host B (and all my replies are based on this scenario). But, if backups is from one LUN to another LUN attached to the same ESX host, then legacy network mode will result in no network traffic, and vStorage API network mode will result in traffic going to backup server and back.

In all cases, legacy network mode is still there and can be enabled if necessary, as explained in FAQ. Of course, I highly recommend to avoid using legacy network mode with ESX 4.x because of 10x slower incremental backup speed, and 10x hit on production storage. vStorage API network mode is a better option all around for ESX 4.x, even though it comes at cost of little network traffic (aside of first job run, when full backup is performed and thus the traffic is significant).

And, of course, ideal solution in OP's scenario would be installing Veeam Backup server in a VM on ESX host A, and using the Virtual Appliance processing mode. This will give best of both worlds: both changed block tracking, and no network traffic.

[tsightler]

Tom, you are correct, and this is exactly what I said in what you have quoted
The only difference is whether this traffic will go direct, or though proxy

That's what I get for trying to answer forum posts in the middle of a million other things. You did quote correctly that it would go direct, but in the case of the same ESX host being both the source and the target (which was the OP's original issue) then the traffic never really leaves the ESX host with "legacy" network mode so you can see how vStorage API network mode will have a very different profile in this case.

And, of course, ideal solution in OPs scenario would be installing Veeam Backup server in a VM on ESX host A, and using the Virtual Appliance processing mode. This will give best of both worlds: changed block tracking, and no network traffic.

Yep, I would agree that's the best solution. It works great, and we use that at our remote sites for local backup.

[Gostev]

Thanks for trying to answer forum posts in the middle of a million other things!

[bhwong]

I have 2 questions over the discussed issue in this thread:

1. To ensure that backup traffic never leave the host in order to improve backup performance (and security), should I also require to vMotion the Proxy and Repository Server into the same host as well?

Even if VMFS volume for the VMs I'm backing up, is accessible from all ESXi hosts, it won't retrieve directly from the VMFS volume but it has to transferred from ESXi A (where the VMs to be backed up is running) to ESXi B (where Veeam VM is running)?

How is vStorage API network mode having a very different profile in this case as compared with "legacy" network mode?

2. Why is VMFS a bad idea as a backup storage? Is it easier to restore a backup from an NTFS volume than an VMFS volume? Does VMFS volume get corrupted easier compared with NTFS volume? And more difficult to fix a corrupted VMFS over a NTFS volume too?