I thought it might be useful to circle around on this one more time with some definitive thoughts. My apologies for the delay on this–a week of intensive BRS training (EMC's new Backup and Recovery Systems business unit formed out of the union of BURA, the previous EMC group to focus on backup, recovery, and archive, and Data Domain) took me away from my blogging.

So where we left things was this: if you want to do image level backups with vSphere 4.0 the present state of the art does not allow an application consistent backup (without the injection of an agent into the guest OS). The underlying reason for this has to do with the present state of VSS support in VMware Tools. Although I am optimistic that VMware will improve their support in the future, and address this issue to the benefit of backup applications like Avamar, at present they only support VSS snaps on Windows 2003 guests (and do not support the extended application VSS writers at all under Windows 2008).

In practical terms, that means we cannot get application consistent backups of Windows applications. However, we can get crash consistent backups. This is actually a pretty important distinction, and I wanted to raise it because I am not sure W. Curtis Preston did enough to describe this distinction in his post on the subject. And crash consistency is a heck of a lot better than corrupted backups (which is what I fear that many people might infer happens if you don't get application consistency).

So what does it mean to get a crash consistent backup?

Well, a crash consistent backup differs in two ways:

• First, it can be recovered to an application consistent state if you are willing to do apply the logs to the recovered application. Essentially the logs will play to determine the last consistent state of the application, and that is where you will be left. Generally that is all you will have to do (although for Active Directory there may be additional actions required).
• Second, and somewhat tangentially, you may need to groom the application post-backup. This kind of backup does not truncate the logs, inform the application that it has, in fact, been backed up. Nor does it flip the archive bit so that other backups or applications will detect that a backup has happened. Of all those, the first is probably the most important: it means that a script or administrative action will have to occur to trim the logs so they don't overflow the storage space.

So, to conclude: an application consistent backup is not possible at the image level, but this is not all bad. We now have an answer that is more shades of grey–or as us technical guys will often say when asked a question: “it depends.” Do you value application consistency first and foremost? Then Avamar and guest level backups are the right approach for you? Do you desire the value image level backups more than guest level, and are you willing to tolerate a crash consistent machine state? Then image level backups are the right approach.

From my perspective, my suspicion is that most people will opt for guest level backups. They are mature, stable, and offer a wide range of tools that support APIs for application backup like VSS. And with Avamar they have a trivial impact on CPU resources, even less of an impact on network resources, and happen as much as 90% faster than with a traditional backup application. And most compelling of all: you don't have to change anything about your backup methodology as you move from physical to virtual. Never underestimate the power of inertia. Again, my opinion only, but I think image level backups will be reserved for DR and archival purposes for the near to medium term.

Post written by: The Backup Blog