VSS guide

If you create and administer backups, you will have heard the term Microsoft Volume Shadow Copy Service (VSS). You may even know that VSS runs in the background while a backup takes place. Knowing that is usually enough but if you’re customizing your backups or encountering VSS problems it helps to know more. So let’s take a closer look at VSS, the virtual shadow copy service.

Creating consistent backups with VSS

Backups can take a long time, which is a problem because the data you are backing can be changing while it is being backed up. This means the backup contains data as it was at different points in time–it is not consistent. This inconsistency causes problems for data, especially application data like databases that are constantly changing. VSS solves the inconsistent data problem by creating and maintaining a point–in–time snapshot of the volume to be backed up. The backup job can then use this snapshot to get copies of the data that have changed since the backup job started.

How VSS works

The VSS is service that works with 3 subsystems to create and maintain VSS snapshots. The subsystems are called the VSS requester, the VSS writer and the VSS provider. To understand VSS you will need to understand how these 3 subsystems work.

The VSS process

Now that you know about the subsystems used by VSS, let’s look at how they work together to create a snapshot. Specifically, we will look at a snapshot created and maintained by a Microsoft VSS provider. The Microsoft VSS provider normally creates a snapshot on the same volume as the live data. If the live data changes, a copy of the previous version of that data is saved to a location called the shadow storage. By doing this, the snapshot is able to maintain a point–in–time version of the live data, that only requires disk space equivalent to the data that has changed.

How System Protection backups use VSS

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.

Faster incremental image backups

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.

Multiple restore points

The limitation of image backups is that each backup overwrites data that has changed, so you can only restore data from the previous backup. The only way to create a restore point for every backup would be to create a full image backup each time the job runs, and that would waste time and disk space.

This limitation is overcome by creating a persistent historical snapshot, on the backup destination. A historical snapshot is created before the backup jobs runs. This is a snapshot of the backup itself, so when the backup job then incrementally overwrites data in the backup, the historical snapshot maintains a copy of the data that was changed. This means that when a restore is performed, either the image backup or any of these historical snapshots (of data that changed) can be used to provide a restore point for each backup job that ran.