Backup disk size/cluster size

[duhaas]

Are there any recommendation when it comes to the disk formatsize/alignment? I am using ISCSI as the disk in which I am backing up vm's to, and just wanted to understand what best practices there might be when using the veeam backup software.

[Gostev]

If you are planning on doing VCB SAN backup on FC4, just make sure this target backup storage is fast (often being a bottleneck). Just do some write tests from Veeam Backup server to it. We use regular Windows API to write backup files - thus, it all goes through Windows system cache, and it is system that determines most effective way and block size to write the data, taking multiple factors into account... so no other target storage recommendations really...

And for network backups, or slower SAN hardware, network/SAN connection speed is usually a bottleneck, so you don't have to worry about storage speed.

[duhaas]

Thanks for the info, im my case, everything is iscsi, the backup storage disk, and the iscsi luns that we present to esx

[Gostev]

OK, no problems.

Just FYI, there is one interesting scenario possible - in case of all of these below is true:
- you use "fat" ESX (not ESXi)
- your backup storage disk is attached to your ESX (as a storage)
- you use "network" backup mode with service console connection enabled for your ESX host
- in backup job wizard, on backup destination step you select your ESX host and that backup storage disk attached to it as your destination

In that case, you will get fast LAN-free backups with all data going directly to backup storage (not through Veeam Backup server). This is because service console agent on your ESX host would write directly to backup storage disk.

Hope this helps!

[duhaas]

so your suggesting that i would create an iscsi lun, present it to all my esx servers and only use that disk for a backup destination for veeam. instead of presenting an iscsi lun to the backup server, and using that as its veeams destination.

[duhaas]

Also, do you see that clients get better performance going this route instead of using the vcb route, and instead using the network route??

[Gostev]

It depends on the size of your environment. This is good option for small deployment, no vCenter and just a few ESX hosts without shared storage. Then it makes sense to do this way and just create 1 job per host.

However, as soon as you have larger environment with vCenter and multiple ESX hosts in clusters with VMotion/DRS enabled, then you cannot really use this approach well. In this case, VCB SAN backup mode will be much better to use in terms of backup reliability and manageability.

Are you using 1Gb iSCSI?

[duhaas]

Yeah, using 1GB iscsi, with the Microsoft iscsi initiator. We have three esx hosts, virtual center. Just been trying to figure out where my bottle neck could be, have been getting spotty performance. Also, wanna know what folks would consider decent performance when it comes to iscsi backups. right now, if get between 15-25MB/sec

[Gostev]

In this case, bottlenecks are iSCSI target (if software target like OpenFile, then it could be very slow), and of course iSCSI that does add it own toll on network data transmission. iSCSI is not really viable unless you use hardware HBAs, dedicated LAN, and fast hardware iSCSI target. Even with that, some people say they don't consider iSCSI unless it is over 10Gb copper.

Anyway, so do I understand correctly that your ESX servers are using all the same iSCSI target as storage for VMs? In that case, there is no setup that can increase the speed you are getting really. One way or another, during each incremental backup cycle, full VM image will need to be retrieved over iSCSI/LAN from your iSCSI target for changes processing - either to ESX host by service console agent, or to Veeam Backup server (depending on the mode). So backup speed will always be limited to your iSCSI storage performance.

On the other hand, if you would use local storage on ESX hosts, then initial scenario with service console agent and ESX being backup target would give you better performance, since service console agent would be able to look for changed blocks on locally available storage (which is obviously many times faster than over 1Gb iSCSI).

[Gostev]

Note that we plan to provide enhanced incremental backup mode in the next major release (Veeam Backup 4.0) that will not require pulling whole VM for change analysis during each cycle, however that functionality would require vSphere ESX 4 hosts, since it would rely on some new vSphere functionality and APIs.