Veeam Backup Best Practice

If you are going to run a physical to virtual conversion, make sure you run a defrag before the conversion: the reason being is when the VM is backed up via CBT it will produce large incremental .VBR files if there is file fragmentation. This works on a 1MB block size, so a single 1k change would mean a 1MB increment, thus if there is a linear structure to file patterns this will help reducing the size of the VBR file.

Pages Files on Windows VM’s are backed up as default via a full Veeam backup, as this data contained in the page file is inconsistent this will in turn produce large incremental VBR files. This is especially an issue with something like Exchange that uses database caching. To solve this create a separate VMDK and place the Windows page file on this disk and when the back job is created exclude this disk.

Make sure you follow this KB article when creating data stores for virtual machines that will be backed up via Veeam or you may have problems when the snapshot is created.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012384

Understanding VSS implementation in Vmware Backup and Replication products

VSS can be nightmare to fully get to grips with in Vmware backups, Scott Lowe wrote a great interpretation in his blog here.

http://blog.scottlowe.org/2010/02/09/partner-exchange-2010-session-techbc0320/trackback/ 

I would like to think I have good understanding of this so here is my view of VSS and VMware in a simplistic form.

In this example I will use Veeam utilizing the Vmware VSS provider backup on Windows 2003 running Microsoft Exchange. Ok so what is a VSS?  VSS is simply a framework that Microsoft introduced from Windows 2003/XP onwards that can coordinate with backup applications to produce a consistent and reliable copy of data, a VSS backup will be application consistent as opposed to Crash consistent, a good analogy would be to think of application consistent backup as a manual shut down of all services and then a copy and a crash consistent backup as simply to press the power off button on your server (good luck), The framework consists of 3 main components as below.

1. Requester  Backup application (Veeam)
2. Provider     Vmware Tools
3. Writer        Application (Exchange)

OK so how does this fit together in the above scenario?

1. Veeam Kicks of a backup and sends a message via the Virtual centre SDK to locate the machine and prepare for a snapshot.
2. Virtual Center locates the machine and sends a message via the VSS provider component in Vmware tools to start the Microsoft Volume Shadow copy service. 
3. The Microsoft Volume service will enumerate it's VSS writers and ask them to prepare for a copy backup.
4. The Exchange VSS writer coordinate with Exchange core components and will halt I/O flush any transactions in memory and then notify the VSS provider that all is OK.
5. Virtual Center will proceed and create a snapshot.
6. Veeam will now have access to read only copy of the VMDK and all writes will directed to the newly created delta file.

The VSS writer is a crucial part of this framework as it crucially deals with making the data consistent, another analogy would to think of the writer as a airline pilot going though a checklists that a plane is safe to take off if anything is not OK the plane will not take off (sorry but i do like an analogy!)
so in essence if it the writer cannot hold of the I/O or quiesce the data the backup will fail.

As Scott points out in his blog the you will notice the Vmware Tools VSS provider has rightly or wrongly it has limitations in that it can only call on the VSS Copy function of the backup and this is only limited to application level in Windows 2003 as we speak, so if you run an application with a VSS writer like Exchange, AD or SQL in 2008 you will limited to a simple OS level data quiesce, and this backup will be only crash consistent at application level. This is a issue if your backup application or San based replication can only leverage the Vmware VSS provider via Virtual Centre (most do).

Some people will argue that they will run guest based backups in conjunction with image based whereby the Guest backup will have full backup VSS functionally and will also deal with tasks such as database maintenance, this is a sensible as you can also run something like Eseutil as a option, it also should be noted that if you run something like CCR or Microsoft Data Protection manager that uses log shipping, a full VSS copy backup that truncates logs will cause issues as it will fall out of sync.
So it's very much six of one and half a dozen of the other, and it is something you should give a lot of thought as with the new VStorage API's, Changed block tracking and greatly improved backup speed and functionality around Vsphere there will be a lot of focus on moving towards Image based backups.

The good news is that if you use a backup or replication application that has a propriety backup agent that can be installed within the VM and have some synergy with Virtual Center you can leverage the full VSS functionally at different levels, this will cover Windows 2008 application level quiesce and you will also be able to perform tasks such as truncation of logs, good examples of this are Veeam, Falconstor and Backup Exec 2010 and also from a SAN replication perspective NetApp and the upcoming HP Lefthand SAN/IQ 8.5.

So to sumise I think it is prudent to fully look into any solution on a ongoing basis and trial any products on POC basis if you can...you will sleep better at night!