Inconsistent Backup
The oldest type of backup probably not consistent. The process of taking the backup was so simple, backup application starts at the beginning of a file structure and copies all of the data until it reaches the end, resulting in a backup (Inconsistent).
The reason which can make this backup inconsistent is that if any user added/modified after a backup but before it completed that would result in an inconsistent backup; the files in the backup are not consistent.
Mainly the volumes which have Random read and random writes application like databases these types of backups do not provide adequate protection because they only capture what is on disk. Example, with SQL Server there are a several different files, primary (MDF), log (LDF) and secondary (NDF) files and there could be active IOs which is still in memory. (The data in the database are stored in primary data files with an extension .mdf. Secondary data files, identified with a .ndf extension, are used to allow the data of a single database to be spread across more than one file, and optionally across more than one file system. Log files are identified with the .ldf extension.)
Crash-Consistent Backup
A crash-consistent backup is where all data is captured at the same point in time. A crash-consistent backup, as with an inconsistent backup, does not capture any data that is in memory or any pending I/O transactions which is in memory or cache. The term “crash” is used because if the data is recovered using this method it would be equivalent to restoring to the exact moment that the server had crashed. Crash-consistent backups can be used but it is important to perform the correct operational tasks to ensure you are restoring properly. For example with SQL Server you may need to replay transaction logs to get the database back to a consistent transactional state.
Application-Consistent Backup
Application-consistent backups provide the highest level of protection and consistency for the data, it captures the whole data which is on disk and also in the memory.
In case of Microsoft Windows this is achieved using the Volume Shadow Copy Service (VSS) which freezes I/O for certain period ( default 60 seconds for writer and 10s on FS ), flushes everything to disk and takes a block-level snapshot of the volume. VSS is provided as a framework in the Windows operating system that performs these operations by coordinating between Requester, Writer and Provider.
When a VSS request is initiated a VSS Writer (Eg. SqlServerWriter) will flush all I/O to ensure that the database is in a consistent state. Then the VSS Provider will take a block-level snapshot of the volume. Once this is completed the Provider notifies the Writer to resume operations.
