What are Application-Consistent Backups?

Most applications have specific backup needs that should be optimized to make protection and recovery as fast and successful as possible.  Inexperienced administrators often wrongly assume that by simply copying data from an entire volume or virtual machine that their backup will be application-consistent, or safe to use.  If the application is restored in an inconsistent state, the database may not function correctly as its data could be corrupted. Understanding the processes which are triggered when a backup is requested helps administrators make the best decisions for how to protect their workloads.  To create a consistent SQL backup, a series of tasks will be triggered to complete any open transactions, temporarily pause any new write requests, and flush any buffers or caches.

Windows Server users can request that their backups are consistent by using the Volume Shadow Copy Service (VSS) framework.  When a backup for an application is requested VSS will trigger the tasks needed to make the backup application-consistent.  Windows Server does include a basic backup utility (Windows Server Backup) and several applications include a built-in backup process (SQL Server Maintenance Plan), but large organizations will likely need to use an enterprise backup provider that supports VSS.  Enterprises may need to back up their databases differently based on different compliance requirements, corporate policies, schedules, recovery time objectives, and recovery point objectives, to separate the application’s data from the VM it is running inside, protect a subset of databases, set different offsite replication schedules and more. Instead of focusing on Volume Shadow Copy as a whole, this blog post will explain the importance of using application-consistent backups for enterprise Microsoft applications such as Active Directory, Hyper-V, SQL, and Exchange.

A Brief History of Backup Consistency

Early backup tools could only take a snapshot of a single file that worked fine for isolated services or end-user applications as there were no dependencies on other files.  This did not work for distributed applications using multiple files as the workload could be left in an inconsistent state if the data across their files were at different points in time.

The next generation of backup tools offered “crash-consistent” backups, which meant that any linked files would be backed up simultaneously.  This ensured that all the files were at the same point in time when they were protected which created a backup that could recover from a crash and function correctly.  However, there could still be some data loss if other types of transactions were in flight over the network or stored in a cache that had not yet written the data to a disk.

Most enterprises require “application-consistent” backups to ensure that all the data for a specific service is protected and recoverable.  This means that the backup provider will pause all new requests (quiesce the file system) and flush every cache or buffer which the application is using to ensure that all data is captured.  Many applications have unique requirements and will provide VSS or its backup requestor with a customized file to trigger each of the tasks needed for an “application-consistent” backup.

Volume Shadow Copy Service (VSS)

Microsoft’s backup framework, VSS, is used by its own applications (Active Directory, Hyper-V, SQL, and Exchange, etc.) as well as third-party ISVs that develop software that runs on Windows Server.  VSS is described in detail in this Altaro blog about Understanding Application Backups with Volume Shadow Copy Service (VSS).  Windows Server includes 34 built-in VSS writers for application-consistent backups.  For any backup provider that your organization is considering, make sure that they support VSS with application-consistent backup for each of your line-of-business workloads.  As one of the industry leaders in protection, Altaro Software supports …

Application-Consistent Backups with Active Directory

Consistency is important for the Active Directory (AD) database because identity management and security are critical for all organizations. With each component of AD, full backups are always recommended since so many problems that can arise from inconsistent database recoveries, including the disappearance of new users, password not being updated, and stale security policies.  Make sure that you use the built-in VSS writer for Active Directory and pay attention to Microsoft’s recommendations for how to handle Active Directory Tombstones after a restore.  For security reasons, it is a good best practice to encrypt the backup file for AD.  There are in-box VSS writers for Active Directory Domain Services (NTDS) VSS Writer, Active Directory Federation Services Writer, Active Directory Lightweight Directory Services (LDS) VSS Writer, and Active Directory Rights Management Services (AD RMS) Writer.

Application-Consistent Backups with SQL Server

Application-consistent backups are important for your writable databases so make sure that you are using a VSS writer with SQL Server.  If an inconsistent backup is created, then during recovery it may have an error, be inaccessible, have corrupt data, or otherwise be unusable.  To increase the disk access speed, SQL Server will usually not write directly to the disk, but use write-optimized log files which cache the writes and flush them at different times so this gets purged during a VSS-induced backup.  Additionally, the Database Engine locks the data file, so part of the VSS process will permit the SQL Writer Services to access and copy the data files while SQL is still running.  Whether you are using the built-in SQL Server Maintenance Plan or a third-party backup provider, make sure that it supports VSS.  Some additional recommendations are given by Microsoft for the SQL Writer Service.

Application-Consistent Backups with Exchange Server

Exchange Server has similar considerations to SQL Server since the application does not write directly to its database, but instead uses logs.  This provides crash-consistency, ensuring that the database does not become corrupt if the service is unexpectedly shut down. However, any data in the log files or caches which has not been written to the main database will be lost.  An inconsistent Exchange Server can result in lost messages, meetings, security policies, or contacts. Exchange Server also has built-in backup utilities which should also be evaluated when a backup plan is created.  There are many design considerations that may vary depending on the Exchange version and configuration, so it is strongly recommended to learn more about Exchange backups, restore and disaster recovery directly from Microsoft.

Application-Consistent Backups with Hyper-V

Virtual Machines (VMs) should always use application-consistent backups, or they may become corrupted and not be able to restart after an unplanned shutdown.  When Hyper-V triggers an application-consistent backup, called a “Saved State”, all of the transactions and data which are in transit or in memory are flushed to the disk.  This includes the data for both the VM and the virtualized application running inside the guest operating system.  If this guest application has its own VSS writer, then make sure that is installed so that it can participate in the backup process.  This backup is called a “Child VM Snapshot” which ensures that the data within the VM is also in an application-consistent state.  For additional details, check out Microsoft’s best practices for backing up and restoring VMs.

Alternatives to Application-Consistent Backups

Sometimes it may not be possible to request an application-consistent backup, such as when the software does not come with its own VSS writer, or if your organization has created its own distributed application.  The easiest solution is to run your application inside a Hyper-V virtual machine and call the VSS writer for Hyper-V.  This will always result in a backup that is at least crash-consistent, so it can be restored to a previous point in time where it is fully operational, however, data loss can occur.

If you need to take an application-consistent backup for a custom application, the easiest option is to temporarily shut the application down, then take the backup.  This can be done by creating a script that is called before the backup begins to gracefully shutdown the application and its dependent services which should quiesce the file system and flush any data that is inflight.  After the backup is successfully completed, a second script should be triggered to automatically restart the application in the appropriate startup order, then verify it is back online.

For organizations with developers, another alternative is to create their own VSS writer.  Microsoft has documented this process and the VSS APIs in detail, and it has been used by dozens of third-party enterprise ISVs.  No matter what application you are running, always make sure you understand the separate backup tasks which are happening.  This helps you ensure that the service is crash-consistent and application-consistent so that you can detect errors with your backup or recovery.