You may notice that you cannot choose to store Shadow Copies on an attached VHD, and that when configuring Shadow Copy protection on an attached VHD, there are no other locations available to store the copies on, other than the protected VHD volume.
This behavior is by design. Illustrated below is the behavior you may see while working with attached VHDs and Shadow Copies. I’ll provide some additional information at the end of this post that will explain why this behavior is occurring.
To get into a configuration where we’ll see the behavior I’m describing:
We create our VHD in Fig.1
Remember the size of the destination volume for shadow copies must be at least 300mb before you can store a single shadow copy on the volume
Here, in Fig.2, I’m making it 350mb so that there wouldn’t be any concern about the volume being too small and thereby omitted from the list of possible locations.
Below in Fig.3, we’re going through the steps of initializing the new disk
Now, in Fig.4, we’re putting a simple volume on it
(Fig.5) Enabling Shadow Copies on the C:\ volume
In Fig.5 above, I’ve pulled up the properties of the C:\ in preparation to enable Volume Shadow Copies. You can see here, that Disk 3 (F:\) is present in the list of volumes that we can enable the feature on. F:\ is the attached VHD we created in Fig.2.
In Fig.6, let’s enable Shadow Copies on C:\ and then choose to put the copies on our F:\ drive…
Whoa… where’d the F:\ drive go?
As you can see from the list, the attached F: (VHD file) is not listed as a valid target for Shadow Copy Storage.
Also, while you can configure the attached VHD to be protected with Shadow Copies, you cannot store the Shadow Copies on any other volume but itself.
Why is this happening?
A virtual volume cannot be used as the target volume for the snapshot of another volume, and the volume can only hold shadow copies associated with its own snapshots. VSS will constrain the shadow copy storage area for attached VHDs to only allow the volume to host its own shadow copies. This behavior will ensure that the volume is self consistent, and therefore, maintain its portability. Portability is one of the bigger design goals behind the ability to create and mount VHDs under Windows 7 and 2008/R2. The end result of this behavior is that snapshots of the volume will travel with the volume as it is deployed and moved around your environment so there’s never a need to worry about a volume missing when it comes time to restore a previous version of a file.
For additional information, be sure to visit these links:
Frequently Asked Questions: Virtual Hard Disks in Windows 7
Understanding Virtual Hard Disks with Native Boot
Thanks for taking the time to read this. I hope it’s helped you understand one of the caveats that can be seen when using Native VHD support!
Support Escalation Engineer
Microsoft Enterprise Platforms Support