Introduction
Microsoft VSS – short for Volume ShadowCopy Storage – is used by Attix5 Pro when backing up open files to BackupVault. VSS is often misunderstood, and this guide seeks to explain how VSS works with Attix5 Pro and in general.
Note: The term “database” is used in this article, but applies to SQL Server databases and Exchange databases, and other VSS enabled applications.
Shadow Copy Storage Area use
Volume Shadow Copies can be used as a way of retaining multiple related versions of files. This functionality can be run on a schedule in Windows. However, whether this schedule is enabled or not, the Shadow Copy Storage Area disk space is used when backing up using VSS.
The disk space required within the Shadow Copy Storage Area causes confusion. It is often asked “how much space do you need for a VSS backup?” An incorrect assumption is that a 1:1 ratio is required. For example, a 50 GB database would require 50 GB of Shadow Copy Storage Area. 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, if a database consists of 100 blocks. A backup is started, and within the time it takes to run the backup, 2 blocks are written to. These 2 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 answer to the question, “how much space do you need for a VSS backup?” is: “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: http://technet.microsoft.com/en-us/library/cc785914(v=ws.10).aspx.
Example disk usage flow diagrams
The following examples use an Exchange database, but the principles equally apply to other databases.
Staged Backup – First backup
- Backup starts and 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.
- The unchanged blocks of the original files and changed blocks from the Shadow Copy Storage Area are read and compressed to the toBackup folder, taking up 25 GB.
- The compressed Exchange database copy is sent to the Storage Platform.
- With the send complete, the compressed copy of the Exchange database is moved to the cache for comparison on the next backup, taking up 25 GB of local disk space. (Note: If using Delta Blocking, a footprint file would be stored in the cache instead, taking up less than 1 MB).
Staged Backup – Second and subsequent backups
- Backup starts and 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.
- The unchanged blocks of the original files and changed blocks from the Shadow Copy Storage Area are read and compared against either a cache copy or footprint file of the previous backup. From this comparison, a patch is produced and written to the toBackup folder for sending to the Storage Platform, taking up 100 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. (Note: If using Delta Blocking, changes to the footprint file would be applied to the cache instead, with this continuing to take up less than 1 MB)
Streaming Backup – First backup
- Backup starts and 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.
- 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.
Streaming Backup – Second and subsequent backups
- 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.
- 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.
- 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.