When a backup is initiated, VM Backup will request a Shadow Copy to be created on the host volume where the VM resides. This leverages the Microsoft Volume Shadow Copy Service and through diskshadow, it will capture the state of the volume (much like how system restore points do). 

The Shadow Copy taken will need to be kept on the host volume till the next backup is run since this is also used to determine the changed blocks for the backups. There are several safety precautions taken so as not to let the Shadow Copy grow too much such as:

A new Shadow Copy is taken if both criteria below are met:

• the free space of the volume is less than 30%
  
  
• the size of the Shadow Copy is greater than 25% of the free space of the volume

With each new Shadow Copy, VM Backup computes what is called a Bitmap of all the block changes and then deletes the older Shadow Copy as it would not be required anymore. These Bitmap files are what the CBT mechanism uses in order to determine the changed blocks for the next backups.

How we'll make use of the Shadow Copy

• VMs in the schedule will be backed up 4 at a time concurrently. All VMs in a schedule will make use of the same Shadow Copy, assuming all VMs are hosted on the same volumes
  
  
• If any other job is triggered manually, or as a separate schedule from the previous one, this will result in another Shadow Copy being created, so multiple Shadow Copies might be present at the same time temporarily, just until the other job has finished
  
  
• Shadow Copies will be active until all VMs using it finish their backup
  
  
• Once all VMs finish their backup, there will only be 1 Shadow Copy left per volume until the next backup

Standalone and Clustered Hosts

Besides the above, depending on your environment, one can have multiple Shadow Copies at a single point in time:

Standalone Hosts

• 1 Shadow Copy will be taken per volume, where the VMs are located

Clustered Hosts

For CDP Crash-Consistent backups (Maximum Frequency), 1 Shadow Copy will be taken per volume. This Shadow Copy will be shared with other nodes, which have VMs on the same cluster volume. This is known as VSS Cache Sharing

• Shadow Copies will be active till all VMs using it finish their backup

For CDP Application-Consistent backups, 1 Shadow Copy will be taken per volume per node. VSS Cache will not be shared.

• This is required in order to perform a guest-level VSS Shadow Copy for application consistency.

Additional Information

Upon a backup request, VM Backup will first make a check in a special database called VSS Repo which is a repository containing all active Shadow Copies being managed by VM Backup. If a VM needs a Shadow Copy and the VSS Repo does not already have this, a new one is created.

On the other hand, if another request is en-queued in less that 4 minutes for a Shadow Copy of the same volume, the VSS Repo will issue a Cache Hit and there won't be the need for a new Shadow Copy to get created.

A new Shadow Copy will only be created if a new job is triggered and more than 4 minutes have elapsed since the previous Shadow Copy creation, or the new request contains volumes which are not part of the previous Shadow Copy.

On a CSV environment, Crash Consistent Shadow Copies can be shared across multiple nodes in a cluster; meaning that only 1 Shadow Copy will be taken and shared with all nodes requiring to back up VMs from the same volume.

On the other hand, Application Consistent Shadow Copies cannot be shared across nodes in a cluster, resulting in multiple Shadow Copies taken. i.e. 1 Shadow Copy per volume per node.

If there is already existing Application Consistent Shadow Copy, and a Crash Consistent request is made, the initial Shadow Copy can be shared through a VSS Repo Cache Hit, but not the other way round.