How VSS Works

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.

toBackup and cache use

When using VSS with Attix5 Pro in Staged Backup mode, disk space is needed in the toBackup folder for a compressed copy of the database files when running the first backup. The copy is read from the unchanged blocks of the original files, and the changed blocks in the Shadow Copy Storage Area. It is then compressed to the toBackup folder. Staged Backup mode is the only option in releases prior to V7.0.

When using VSS with Attix5 Pro in Streaming Backup mode, 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. Streaming Backup is only available from V7.0 onwards.

When running a second backup in either Staged or Streaming Backup, the unchanged blocks of the original files and changed blocks in 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. In Streaming Backup, this is read and compressed on the fly when sent to the Storage Platform. With Staged Backup, the patch is written to the toBackup folder before sending to the Storage Platform.

Example disk usage flow diagrams

The following examples use an Exchange database, but the principles equally apply to other databases.

 

Staged Backup - First backup

 

  1. 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.
  2. 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.
  3. The compressed Exchange database copy is sent to the Storage Platform.
  4. 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

 

  1. 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.
  2. 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.
  3. The patch is sent to the Storage Platform.
  4. 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 

 

  1. 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.
  2. 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.
  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. 

Streaming Backup – 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.
0 (0)
Article Rating (No Votes)
Rate this article
    Attached Files
    There are no attachments for this article.
    Comments
    There are no comments for this article. Be the first to post a comment.
    Name
    Email
    Security Code Security Code
    Related Articles RSS Feed
    View Attix5 log files using the LogViewer
    Viewed 2985 times since Fri, Oct 31, 2014
    How to run a Speedcheck and Healthcheck
    Viewed 1615 times since Fri, Aug 14, 2015
    Perform a SPCommsTest to the Attix5 Storage Platform
    Viewed 1879 times since Fri, Oct 31, 2014