ESX 4.1 VAAI SAN Offload + Equallogic and B&R v5 SAN Backup

[ctchang]

Questions about ESX 4.1 VAAI SAN Offload + Equallogic and B&R v5 SAN Backup

We still have three questions, one is taking snapshots on ESX local storage and save to the same ESX local storage but on a different VMFS, the other is taking VM snapshots on SAN storage and then save to the same SAN storage, both situations lead to a common question if Veeam B&R supports LAN of SAN OFF Load?

Question 1:
For Veeam B&R v5 SAN ONLY Backup mode, we need to run the following on our B&R server.

================
MAKE SURE TO RUN diskpart (Or you will overwrite your VM’s! obviously not good!)

So, run
automount disable
automount scrub

exit

Then reboot.
================

The problem is Equallogic volume DOES NOT SUPPORT READ ONLY, and EQL strongly suggest NOT TO attach other iSCSI initiator other than ESX ones for ESX lun as it will potentially corrupt the VMDK lun.

I would like to MAKE SURE HOW SAFE it is to actaully directly attach to SAN LUN from B&R server, has anyone come across any problem like corrupting your LUN somehow?


Question 2:
We would like to save the backup files (vbr?) on to one of the ESX local (2T) VMFS storage, is it possible?

So, the backup source and target is the same in our case (of course it's not recommended, but just want to explorer this situation more)

This means if I want to backup VMs on the ESX host and save the backup image on THE SAME ESX Host local storage but a differetn raid group or VMFS, the VM snapshots STILL HAS TO TRAVEL from the ESX host to Veeam Backup Service server (where is the same as vCenter as we will install B&R on it in our case), then save the snapshot back to the SAME ESX HOST again ???

Oh...no...is there any way to offload that? I mean can Veeam issue a command to tell the ESX that it's backing up the VM and save to it's own local storage, then there is no need to travel on LAN, just take the snap from VM's VMFS and save to its own snapshot backup VMFS.

I mean our Equallogic SAN has just released a new feature in FW5.0.2 for ESX4.1 that it enables VAAI or Storage Hardware Acceleration, it allows the SAN to directly clone/copy/take snapshots on the SAN array WITHOUT travel out the iSCSI network or LAN or via ESX. This saved 90% of the LAN or iSCSI network traffic as well as reduced the unnecessary CPU on ESX or Veeam Backup Service Server.

Does Veeam supports this kind of offload feature with ESX 4.1 now?

Questions 3:
So if this is how it works, then can I say SAN backup also worked the same, the target VM for snapshot has to travel out of SAN VMFS (which attached to ESX host) via iSCSI to Veeam Backup Service (on vCenter server in our case), then save the snap back to SAN again via Veeam Backup Service (I understand B&R service need to directly connect to that particular SAN volume and able to see VMs on that VMFS).

In other words, is there a way to issue a command to tell our Equallogic SAN "hey, you are actually saving the snapshot on yourself, so there is no need for you to send the VM snapshot via iSCSI network to me and then ask me to send back the completed snapshot to you again, just take the snap within yourself is the most efficient way) The situation is different that 1, as we can already in vCenter to take snapshot on a VM, and the snapshot no longer needs to travel out iSCSI SAN network, with VAAI/Storage Hardware Acceleration enabled in ESX 4.1 with our EQL SAN, the EQL just take the snap of that VM within itself. So if this is the case, can't Veeam B&R act the same as vCenter (I thought it's integrated with vCenter via vStorage API somehow already), just use VAAI to offload the snapshot directly to SAN, is it possible as our storage already support such thing, it will greatly reduce the backup windows to seconds instead of minutes, even for the 1st time full backup copy.


Please kindly let me know the answer to the above 2 questions.

Thanks you very much again!

Regards.
Jack

[Gostev]

1. It is safe. Equallogic is arguably most common SAN among Veeam Backup customers, everyone does this for years now.

2. I think there are 2 separate questions.
a) Yes, it is possible to backup to local ESX storage if you have "full" ESX host, right-click the host in the Servers tree and make sure service console credential are specified, then you will be able to pick it on the destination step and select the datastore to store backups on. However, backing up to VMFS is by no means recommended and is a bad practice, because if your ESX gets fried, you will not be able to access your backups. For best protection, I recommend to backup to NTFS formatted Equallogic LUN instead, or locally attached storage on Veeam backup server. Also, you should replicate backups to another storage (ideally offsite).

b) Data always has to travel to Veeam Backup server, since this is where all processing is done (such as compression and dedupe). VAAI offload is possible for operations on raw data, which is not the case with backups which we dedupe and compress heavily before writing to target storage.

3. Not possible. Again, snapshot data has to travel to Veeam Backup server for processing in all cases.

[ctchang]

It's is crystal clear.

Just one last question, can we add this to the feature request in coming version release?

As frankly speaking, say for example SAN backp, it doesn't make sense if the backed data on VMFS has to travel out of the iSCSI SAN, then being read by B&R Server, then send it back again to the SAN.

Oh...wait, I see what you mean, the key is...the VMs that are being backed up NEED TO HAVE DEDUPLICATION AND COMPRESSED on B&R server, that's why the VM data HAS TO BE SENT out of its storage (no matter iSCSI/NFS/Local on ESX) as ESX/Equallogic/NFS has no way to do this Deduplication or/and compression.

So it's perfectly making sense now.

[ctchang]

1. It is safe. Equallogic is arguably most common SAN among Veeam Backup customers, everyone does this for years now.

2. I think there are 2 separate questions.
a) Yes, it is possible to backup to local ESX storage if you have "full" ESX host, right-click the host in the Servers tree and make sure service console credential are specified, then you will be able to pick it on the destination step and select the datastore to store backups on. However, backing up to VMFS is by no means recommended and is a bad practice, because if your ESX gets fried, you will not be able to access your backups. For best protection, I recommend to backup to NTFS formatted Equallogic LUN instead, or locally attached storage on Veeam backup server. Also, you should replicate backups to another storage (ideally offsite).

b) Data always has to travel to Veeam Backup server, since this is where all processing is done (such as compression and dedupe). VAAI offload is possible for operations on raw data, which is not the case with backups which we dedupe and compress heavily before writing to target storage.

3. Not possible. Again, snapshot data has to travel to Veeam Backup server for processing in all cases.

Final question: How much speed improvment does v5 get comparing to v4?

[Vitaliy S.]

There is an improvement, but you should agree that the performance rates heavily depend on the hardware/backup server/job mode and other configurations you use. I cannot tell you the exact figures (don't want to set false expectations), as you might see lower or even significantly higher rates in your environment. From our side, I can assure you we've followed all known best practices while working on our backup engine to make your backup jobs run faster compared to v4.

[ctchang]

May I know where can we locate a list of official best practices for B&R v5?

Thanks.

[Vitaliy S.]

Basically, all best practices regarding backup server deployment and configuration stayed the same except for the new features. You may want to check our website for whitepapers and Evaluator's Guide for some tips, besides, you may use forum's search on some setup and configuration recommendations.

As for Veeam B&R v5, then all documentation (User Guide/ Release Notes e.t.c) will be uploaded to the website with the come out of v5. Thanks!

[ctchang]

I think many complained Veeam lacks of an official Best Practice, it's better to consolidate all the best practice for v5 and make it a PDF, instead asking your user and potential buyers to search for themselves from the forum. I am sure you are the BEST PERSON to do that job, as you know EXACTLY those important information locates, if you ask me, to be honest, I don't have a clue where to start.

So please help me (a just joined partner and paid customer) and all others to finalize an OFFICIAL BEST PRACTICE and we look forward seeing it on Wed when v5 is out.

Thank you very much for your kind consideration.

[Vitaliy S.]

Thanks for the feedback, that's right we are always working on various whitepapers/manuals regarding best practices, consolidating all frequently asked question into one place to help you with the product.

[ctchang]

Thanks for the feedback, that's right we are always working on various whitepapers/manuals regarding best practices, consolidating all frequently asked question into one place to help you with the product.

Thanks! That would be really helpful!
Please help us to extract those Best Practices from various whitepapers/manuals and consolidate into one Bible.