531 - How Redstor's software uses VSS

Note: The term “database” here applies equally to SQL Server databases and Exchange databases, as well as other VSS writer-enabled applications.

Shadow copy storage area use

It is well documented that shadow copy storage area disk space is required when backing up using VSS, but the amount of space required within causes confusion. It is often assumed that a 1:1 ratio is required (e.g. a 35 GB database would use 35 GB of shadow copy storage area), but this is not correct.

When running a backup using VSS, the copy-on-write method is used.

After a backup is initiated, copy-on-write copies any blocks that are to be changed in the original files to the shadow copy storage area.

When reading the files to be backed up, the unchanged blocks can be read from the original file, and the original versions of the changed blocks can be read from the shadow copy storage area. These are then assembled into the full file at the point in time that the backup was run.

For example, a database consists of 100 blocks. A backup is started, and within the time it takes to run the backup, two blocks are written to. These two blocks are copied into the shadow copy storage area before being overwritten. The backup reads the unchanged blocks from the shadow copy storage area, and has a complete version of the database at the point that the backup ran.

The amount of space needed within the shadow copy storage area will vary depending on the size of the original database and on the rate of change of the database. If changes occur during the backup, for example maintenance tasks, more space will be needed.

More details of the copy-on-write method can be found here.

toBackup and cache use

When using VSS with Redstor Pro, disk space is not needed in the toBackup folder. The database is read from the unchanged blocks of the original files, and the changed blocks in the shadow copy storage area, and streamed directly to the Storage Platform. 

When running a second backup, the unchanged blocks of the original files and changed blocks in the shadow copy storage area are read and compared against a footprint file of the previous backup. From this comparison, a patch is produced, which is read and compressed as it is sent to the Storage Platform.

In the case where multiple identical copies of a file are present, we employ deduplication, i.e. the file is transferred to the Storage Platform only once.

Disk usage 

The following example uses an Exchange database, but the principles apply equally to other databases.

First backup

1. The backup starts and a VSS snapshot is taken of the Exchange database. Any changes to the Exchange database are now tracked, with the original blocks copied to the shadow copy storage area.
2. The unchanged blocks of the original files and changed blocks from the Shadow Copy Storage Area are read and compressed on route to the Storage Platform. A footprint file is created in the toBackup folder.
3. 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.

Second and subsequent backups

1. Backup starts and a VSS snapshot is taken of the Exchange database. Any changes to the Exchange database are now tracked, with the original blocks copied to the shadow copy storage area.
2. 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 100 MB.
3. 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.