Begginer Questions

[Jorgeg]

I'm in the procces of evaluating veeam backup. I currently use esXpress (great software btw) but the lack of GUI and lack of ESXi support made me look for alternatives namely veeam backup.
I've read your documentation and a few forum threads and got a few questions for you experts:

a) How many VM's can I backup concurrently (using network or VCB/SAN scenarios) ber ESX host ?

b) If I run veeam backup inside a vm can I use resource pools reservations (shares or limits) so that it does not eats up all the CPU and afects the other VM's running in the same ESX host ? If so what will be the impact in the backup jobs (besides slower backups). Will I get errors/backup failures ?

c) I still didn't understant what a veeam backup agent is...Is it a vm that is created on the esx host when I run a backup/restore of a vm on that host ? If I run concurrent backups on a ESX host will I get more than one veeam backup agent on that host ?

d) This is more a feature request than anything else. I need to be able to restore to RDM (virtual mode of course). All my vm's are sitting on virtual RDM LUN's. BTW, do I need to use VCB when backing up/restoring VM's with virtual RDM's ?

e) For disaster recovery do I need the veeam SQL database ? Or can I just install a windows server, veeam, esx hosts and import the veeam backups and I'll be ready to go ? I run our SQL Server on a VM so if I need it to restore veeam backups it would be a catch 22 situation. Also do I need to have VirtualCenter up and running or can I just restore directly to the esx host even if I used VCB for my veeam backups ?

f) When we buy veeam backup is the file level restore wizard included or is it an extra ?

Cheers,
Jorge

[Gostev]

Hello Jorge, thank you for your interest.

a) You can run multiple concurrent jobs if you'd like, but we do not recommend concurrent backup of VMs sharing the same storage. Parallel processing is not recommended because it causes issues in larger environments, especially around concurrent snapshot operations on the same LUN (causing snapshot/file operations timeouts, SCSI reservation timeouts etc. - all leading to backup failures). This is explained in more details in the following VMware document (see page 6). So you may get a little faster speed at cost of much worse backup reliability.
Again, you can setup multiple jobs and run them in parallel, but make sure your jobs are setup in a way to ensure that they are not accessing the same LUN simultaneously). In most cases, 2 jobs is enough to fully saturate your Veeam Backup console network and target backup storage I/O capacity. And if you are using VCB SAN on FC4, due to the speed this backup mode provides target backup storage disk speed becomes your bottleneck even with a single job, so running parallel jobs does not typically bring you any speed improvements here.

b) Yes you can do it, no impact aside of what you've already mentioned.

c) Veeam has 3 backup modes: VCB, agentless and service console agent. Best mode is selected depending on your environment, storage and host types. Service console agent is a small lightwieght app installed in ESX host service console during backup, and removed as soon as the job is finished. It also does compression and empty block removal to minimize the amount of data transfered. There is one agent per job started.

d) Yes, you can backup vRDM, but you need VCB.

e) No, you do not need SQL to restore. SQL hold only jobs configuration. The DR procedure you've described above is totally correct.

f) It is included at no extra charge, and actually was made a part of main setup program in the latest 3.1 release (instead of being separate download).

Hope this helps!

[Jorgeg]

Hi Gostev thank you for your helpful reply. I've got a few more questions if you don't mind:

a) If I set up a VM with VCB and veeam do I need to have VirtualCenter there also ? Currently is seating on a physical machine and I would like to keep it there.

b) I've been avoiding VCB because the requirement for windows access to the vm's storage scrares me, but I can see it would be a very good scenario regarding performance and freeing up my network. Can I use compression and deduplication in this scenario ?

c) When running backups over the network how are they sent to the destination ? over sc, vmkernel or the vm network ? I use blade servers with 4 nics and team all of then under the same vswitch. I then setup up vlans to segregate trafic (a vlan for sc, other for vmkernel, and others for vm's) so I need to understand where the backup traffic will go. Ideally I would like to setup a VLAN for backups/restores, if that makes sense for your product that is.

d) Regarding concurrent jobs, I'm running 2 backups per esx host times 13 hosts all at the same time. I backup over the network (1GB shared link) to a FTP server running Windows. All my vm's use virtual RDM's and all the vm's cfg, swap and RDM pointers sit on the same VMFS LUN. Each VM virtual RDM disk has a dedicated LUN. With this setup I'm able to full backup 50 vm's under 24 hours and I get about 500GB of backups files on the destination FTP server. My main concern is to run full backups under 24 hours. Using veeam and with my infrastructure what do you thing would be the best way of achiving this requirement ?

Cheers

[Gostev]

a) No, vCenter can be installed anywhere, or not installed at all. Veeam Backup supports standalone ESX hosts too.

b) You just need to follow the guideliness when deploying VCB, and disable a few settings in Windows - then you will be safe. VCB is very mature technology, this is exactly what most big shops are using. All other technologies are simply not good due to much larger backup windows (slower perfromance), and affecting both ESX hosts and storage. While with VCB, it is all done on storage level, not even touching ESX hosts.

We are actually removing VCB requirement with the next release (4.0) by providing direct SAN access for backup and replication (using new VMware APIs), so that would be minus one uknown from your backup equation.

Yes, compression and deduplication can be used no matter of what backup mode you choose.

c) In case of network backup mode, data flows over the service console network.

d) I would use VCB SAN mode if possible. Here's thorough analysis from one of our customers with 11 times larger deployment (5.5TB of data to backup), hope this helps: http://www.veeam.com/forums/viewtopic.php?f=2&t=812.

Btw what is the reason why have you decided to use vRDM instead of VMDK? It is not to typical, what are the benefits (just interested). I know that vRDM give almost no performance gain, but its backup and restore processes are far from ideal. VCB can only backup vRDM into VMDK, so you can only restore it as VMDK. Besides, VCB renames the VMDK file during backup (known issue with VCB), so you have to update the VMDK name in VMX file manually when restoring the entire VM.

[Jorgeg]

b) Great news regarding the the removal of VCB requirement. Can't wait for it to be available .Will it work for ESX 3.5 or just for vSphere ?

d) Fantastic analysis. SAN mode is the way (will wait for the removal of VCB requirement).


Below are my reasons to use vRDM. Feel free to comment then, I think that we're always learning and your feedback will surelly be enlightning.

1) When migrating from vmfs versions (like for instance from esx 2.5 to esx 3) its a lot easier to just create a new vmfs LUN we're all the vmx, swap and vRDM pointers stay, and then recreate the pointers of the vm's to the vRDM LUNs. In this may I don't need to migrate the vm's VMFS LUN's and avoid a lot of downtime and work.

2) I can use the SAN native tools to grow the vm's LUN's and then go to Windows/Linux and just expand the disks. If I used vmfs LUN's I would have and extra step to perform (grow VMFS).

3) Using a single vmfs were all the vm's snapshot's live avoids the trouble of calculating and accounting for the extra space that I would need for snapshots in every vmfs LUN of the virtual machines. I've never had a single issue with SCSI reservations and I do get a lot of snapshots when backing up a lot of vm's concurrently.

I supose that with vSphere thin provisioning and storage vmotion all this can change but for now I'm happy with my setup (and vmware still hasn't certified my CX500 for vSphere )

[Gostev]

Yes, direct SAN access will work with both ESX(i) 3.5 and ESX(i) 4. Full backup speed will be the same as today with VCB for both 3.5 and 4. Incremental backup speed for ESX(i) 3.5 will be the same as today with VCB. Incremental backup speed for ESX(i) 4.0 will be a few times faster than today with VCB due to some new capabilities unique to ESX(i) 4.0.

Thanks for the insight on vRDM, this is useful information for me (my knowledge of VM storage layer is pretty limited).