How does microsoft vss work

The way VSS works is simple, but you have to follow along. The VSS requestor announces that it needs to create a server snapshot. Before it creates the snapshot, it queries the server to determine which VSS writers have been installed so it can instruct the writer to disable its backup application.

The VSS requestor will instruct each writer to accomplish pre-backup tasks needed for data quiescence. After those tasks are completed, the requestor instructs the VSS provider to create a snapshot. The provider tells the requestor where to locate the data it needs, and then the backup process begins. When the backup is complete, the VSS requestor announces it has completed all the activities, and it instructs each VSS writer to perform any post-backup tasks necessary, so the computer and its applications can return to normal operation.

This means that they can clear their transaction logs and perform other maintenance tasks. Instead of using a traditional backup agent, such as with Exchange, the backup app with VSS can tell Exchange to quiesce itself. Then it creates a VSS snapshot, and then backs up the snapshot as it would with all the other files. Regularly scheduled VSS snapshots completely independent of a backup application. From this comparison, a patch is produced and written to the toBackup folder for sending to the Storage Platform, taking up MB.

The patch is sent to the Storage Platform. With the send complete, the patch is applied to the compressed copy of the Exchange database in the cache.

This continues to take up 25 GB of local disk space. The unchanged blocks of the original files and changed blocks from the Shadow Copy Storage Area are read and compressed on the fly to the Storage Platform. A footprint file is created in the toBackup folder. With the send complete, the footprint file for the Exchange database is moved to the cache for comparison on the next backup, taking up taking up less than 1 MB of disk space.

The unchanged blocks of the original files and changed blocks from the Shadow Copy Storage Area are read and compared against a footprint file of the previous backup. From this comparison, a patch is created and sent straight to the Storage Platform. The transfer is MB. With the send complete, the footprint file of the Exchange database in the cache is updated so that this can be used for the next backup.

This continues to take up less than 1 MB on disk. T E backup backupvault. So now that you know how the snapshot is maintained, how does the backup job use it?

Simple — The backup job asks the VSS service for the selected data and the following happens:. Note: The process of copying live data before it changes causes a small performance reduction for volume writes. The longer a snapshot is needed, the larger it will become; the more data changes the faster the snapshot grows. The space available for the snapshots must be sufficient to store all changes to the data while the snapshot exists. Step 3 The Microsoft VSS provider will then make the snapshot and maintain it, as the live data changes.

Step 4 So that backups are application consistent, any assigned VSS writers will advise on live data changes to the snapshot. Once a VSS aware application like Exchange Server knows that its data has been backed up, its VSS writer will perform some clean—up activities such as clearing its database transaction logs.

This can free up disk space and speed up the application. The backup job uses a variable path that points to both the snapshot and the volume the application is on. The VSS service will determine if the file requested by the backup is in the snapshot or the live data. BackupAssist never knows if the data it backed up came from the live data or the snapshot. System Protection uses snapshots to produce consistent backups in the way described in the previous sections.

However, there are two additional functions that System Protection can use a snapshot for. System Protection creates a full image backup when it first runs. If the data selection and destination do not change, the next backup will be incremental.

This is achieved by reviewing the data to be backed up and the data in the destination - to see what data changed. What has changed, is what is backed up.

Determining what data has changed consumes a lot of time but BackupAssist can do this quickly using snapshots. A snapshot knows what data has changed, because that is what it maintains. So, instead of deleting the snapshot after a backup, System Protection keeps the snapshot and uses it in the next backup to help identify that data that has changed.

This process is called incremental reading. With incremental reading enabled, a 20 min incremental image backup could be completed in 2 min. Note: This only works if the destination does not change and if the data selection does not change. For that reason, we advise that the same media is used at least for a week, so the performance gains can be achieved. System Protection cannot use incremental reading to enable fast incremental backups if the data source is a ReFS formatted drive.

The limitation of image backups is that each backup overwrites data that has changed, so you can only restore data from the previous backup.