Typically, Windows applications cannot copy the system partition because they are unable to copy open files. In cases where the user's hard disk is partitioned only as one drive, that meant the user could not image their system at all from within Windows. If the disk is large enough, it could mean that the user is out of commission for hours at a time while the program chugged away at creating an image.

Leading-Edge Technology
Acronis overcomes this issue of copying open Windows files by effectively freezing a moment of time. A special filter driver layers between file system drivers and volume drivers, allowing the software to create and backup consistent views of all files, including open files. The driver is installed above the volume drivers so it can see all the read and write requests passing to a volume — or partition.

When the IT manager or user initiates imaging of the hard disk drive containing the system volume, the filter driver flushes the file system mounted to that volume; then all the operations on the system volume are temporarily frozen. Immediately thereafter, the filter driver creates a point-in-time view of the system volume and a bitmap describing the used sectors on this volume. Once the bitmap is created, the filter driver unfreezes the I/O operations on the system volume. It generally takes just several seconds to create a point-in-time view of the volume. After that, the operating system continues working as usual and the software can start imaging of the system volume.

Acronis True Image reads the sectors on the system volume according to the created bitmap. Once a sector is read, the appropriate bit in the bitmap is reset. In its turn, the filter driver continues working to hold the point-in-time view of the system volume. Whenever the filter driver sees a write operation directed at the system volume, it checks whether these sectors are not backed-up yet, if they are not, the filter driver reads a copy of the sectors that will be overwritten into a special buffer created by the software, then it allows the sectors to be overwritten. Acronis True Image backups the sectors from the special buffer so that all the sectors of the point-in-time view of the system volume will be backed-up intact. Meanwhile, the operating system continues working and the user will not notice anything unusual in their operating system functionality.

Maybe it would be useful to the forum to describe exactly what "snapshot technology" is. The goal of snapshot technology is to instantaneously capture all of the data on a volume at a given point in time without interrupting I/O to that volume (without locking anything, stopping applications, etc). This is invariably implemented using an "upper volume class filter device driver" which intercepts I/O underneath the file system, but above the volume devices (see the storage stack diagram below). When the snapshot device driver is instructed by the backup application to establish a snapshot of a given volume, it immediately starts tracking changes that occur to that volume. Each time a write occurs on the volume the snapshot driver first copies off the old data that was already at the location into some scratch pad area and then allows the new write operation to continue on down to the device. Thanks to this copy-on-write mechanism, the snapshot driver is able to preserve all of the information necessary to expose to a backup application the data that was on a volume at a given point in time. Snapshot drivers usually expose the snapshot point-in-time by creating a virtual device similar to a volume device. The backup application will read the sectors on this virtual device in the same way that it would have read them from the real volume. The backup application *may* lock access to this virtual snapshot device, but keep in mind that this virtual device is generally only used by the backup application (it's not visible to normal applications). Locking the virtual snapshot device has no effect on the actual volume device that is being backed up - the real device is never locked and remains accessible to applications. Because snapshot device drivers sit within the storage stack itself, they have absolute control of the flow of I/O to the disk. When a snapshot driver is instructed to establish a snapshot, it takes only a few microseconds, if not less time, for it to halt I/O to the device and establish the necessary in-memory structures necessary to maintain mappings of which sectors have been changed (causing copy-on-write operations) since the establishment of the snapshot, and then to allow I/O to recommence. It's important to understand that there is a difference between the act of "taking a snapshot" and the act of "imaging the data on a snapshot". Taking a snapshot requires only a few microseconds, if not less time. Imaging the snapshot is the process of backing up all of the data that are exposed by the snapshot device driver for a particular point-in-time (usually exposed as I mentioned by a virtual volume device), which is all of the data on the drive at a given point in time, and this can be a lengthy process. When a plain-vanilla snapshot device driver creates a snapshot of a volume, it is instantaneously capturing the volume's state at a given time, and the state of the volume's data is very similar to the state of its data if you kill the power to the computer. This is called a "crash consistent" state. The reason for this is that, at any given time, many files are open and in use and also the file system itself can have structures which are write-cached and have not yet been flushed. Creating a plain-vanilla snapshot captures the data in this in-use state, so it's not a very clean snapshot (it's "crash consistent"). VSS was introduced with Windows XP, and one of its primary purposes is to facilitate the establishment of snapshots when the data is in a clean state. To do this, backup applications and snapshot drivers must be written to interact with VSS. VSS controls the snapshotting process. The backup application will ask VSS to take a snapshot, using a specified snapshot "provider" (snapshot device driver). VSS will then tell all VSS-aware "writers" (applications which generate data such as Exchange, Oracle, SQL, IIS, and many system services such as the registry, etc) to quiescence (meaning that these applications flush their files to disk in a state that is clean and then pause for a small moment until they are told to resume activity) and then VSS will send a special flush-and-hold message (IOCTL) to the file system on the volume on which the snapshot is being established and when the file system receives this flush-and-hold message it will flush all of its metadata to disk and it will then send this flush-and-hold message further down the stack and the file system will not send any more I/O down the stack until the flush-and-hold IOCTL is completed by the snapshot driver which resides below it (which establishes an I/O barrier at the file system level). When the snapshot driver receives the flush-and-hold IOCTL, it knows that all VSS-aware applications as well as the file system itself have flushed their data in a clean state, so it establishes the snapshot and then completes the flush-and-hold IOCTL, which completion event is then received by the file system driver above it at which point the file system driver releases I/O and passes the completed flush-and-hold IOCTL back to the VSS service, which then releases all of the VSS-aware applications. Through this mechanism, VSS-compliant backup software, which use VSS-compliant providers, can create backups of extremely high-load Exchange, Oracle, IIS, SQL, etc. servers on a regular basis without the need to stop any services or applications, without shutting down the machine, while also ensuring that the backups contain good clean data (databases will not need to be fixed/repaired if they are restored, because VSS ensures that they are captured in a good state).

On platforms older than XP, where VSS is not present, other techniques are used to obtain images which are better than crash consistent state images. For instance, some snapshot drivers implements their own I/O barrier at the file system level (using a file system filter driver), if necessary, and on platforms that lack VSS (Windows NT and 2000) the driver is capable of performing the file system flush-and-hold operation which is natively supported on XP+. This enables it to perform snapshots at a time when the file system's metadata has been flushed to disk. Coupled with this is a more manual quiescence process which is facilitated by the backup application itself, which enables users to specify scripts which they wish to be called before and after the establishment of the snapshot, which scripts can be used to stop/start services, etc (or in other words, the scripts are a way of quiescing important applications). While this is more tedious, it gives users of older platforms, that lack VSS, some of the advantages of VSS.

Windows Storage Stack

I/O within the Windows kernel flows from one driver to the next until it is finally passed directly to the hardware device. Each type of device typically has several layers of drivers that manage I/O as it flows to the device. For storage, I/O generally is initiated in user mode (from applications) and is passed to the kernel's I/O manager where it then forwarded to the appropriate file system driver, then to the volume class driver, then to the disk driver, and finally to the storage controller port driver. Filters can be added at any level in this stack.