VSS Crash and Application Consistency for Hyper-V and VMware Backups

When a live backup is performed on a Windows host, BackupChain uses VSS, which is a Windows component, to send a signal to all VSS aware services to prepare for backup.

Then, the operating system itself also prepares for backup and flushes all caches to disk.

Microsoft SQL Server, Microsoft Exchange, Hyper-V and VMware also also VSS aware systems. This means they also receive a 'prepare for backup' signal and process it by writing to their own data files.

In the case of Hyper-V and VMware, the VSS signal is also passed into each VM as well using the Hyper-V Integration Services or VMware Tools, respectively. For that reason it's also important to keep integration services always up-to-date.

When all file changes and caches are written to disk, the operating system allows no further write activity to virtual disks or any other file on the system until the backup is complete; however, all services continue to operate  without interruption while backups are in progress.

When live backups are generated using VSS aware services, such as Microsoft SQL Server, the backup is said to be Crash and Application Consistent. It is application consistent because the application (SQL Server) was signaled to prepare for a backup and performed its own preparations successfully.

A crash consistent backup does not offer application consistency is hence a backup where all of the above happened with the exception of VSS integration. The applications (and perhaps the OS itself) were not involved in the backup. Even though this can lead to data loss, the data loss is usually minimal when software is used that is capable or rolling back transactions. A crash consistent backup is similar to a power outage. Write access stops and the backup is taken using a snapshot. No further writes are occurring until the backup completes.

Most modern enterprise software can readily recover from power outages, such as SQL Server, the NTFS file system, or Microsoft Exchange; however, some applications cannot. For example, Microsoft Access may become corrupted when backups are taken live without shutting down the database. Microsoft Access isn't VSS aware either, so there is really no 100% stable live backup available on a direct file basis. (You could write SQL scripts, however, to attempt a live backup in Access).

When you power up a virtual machine that has been backed up live, a flag may be still set in the file system telling Windows it hasn't been shut down. You can safely ignore the warning if you have confirmed that VSS and the integration services are properly installed. To confirm VSS integration worked correctly inside the VM, check the VM's Event Viewer for VSS entries related entries around the time when the backup was started.

Download your 20-day of BackupChain today!