VSS for SMB File Shares
In the next generation of Windows Server, Windows Server 2012, Hyper-V introduces support for storing virtual machine files on SMB 3.0 file shares. This blog post contains more detail on the SMB 3.0 enhancements to support this scenario.
Volume Shadow Copy Service (VSS) is a framework that enables volume backups to be performed while applications on a system continue to write to the volumes. To support applications that store their data files on remote SMB file shares, we introduce a new feature called “VSS for SMB File Shares” in Windows Server 2012. This feature enables VSS-aware backup applications to perform application consistent shadow copies of VSS-aware server applications storing data on SMB 3.0 file shares. Prior to this feature, VSS only supported performing shadow copies of data stored on local volumes.
Technical Overview
VSS for SMB File Shares is an extension to the existing VSS infrastructure and consists of four parts:
• A new VSS provider named “File Share Shadow Copy Provider” (fssprov.dll). The File Share Shadow Copy Provider is invoked on the server running the VSS-aware application and manages shadow copies on remote Universal Naming Convention (UNC) paths where the application stores its data files. It relays the shadow copy request to File Share Shadow Copy Agents.
• A new VSS requestor named “File Share Shadow Copy Agent” (fssagent.dll). The File Share Shadow Copy Agent is invoked on the file server hosting the SMB 3.0 file shares (UNC path) storing the application’s data files. It manages file share to volume mappings and interacts with the file server’s VSS infrastructure to perform shadow copies of the volumes backing the SMB 3.0 file shares where the VSS-aware applications stores their data files.
• A new RPC protocol named “File Server Remote VSS Protocol” (MSFSRVP). The new File Share Shadow Copy Provider and the new File Share Shadow Copy Agent are using this new RPC based protocol to coordinate shadow copy requests of data stored on SMB file shares.
• Enhancements to the VSS infrastructure to support the new File Share Shadow Copy provider, including API updates.
The diagram below provides a high-level architecture of how VSS for SMB File Shares (red boxes) fits into the existing VSS infrastructure (blue boxes) and 3rd party requestors, writers and providers (green boxes).
The following steps describe the basic Shadow Copy sequence with VSS for SMB File Shares.
A. The Backup Server sends backup request to its Backup Agent (VSS Requestor)
B. The VSS Requestor gather writer information and normalizes UNC path(s)
C. The VSS Service retrieves the writer metadata information and returns it to the VSS requestor
D. The VSS Service sends Prepare Shadow Copy request to the VSS writers involved and the VSS writers flushes buffers and holds writes
E. The VSS Service sends the Shadow Copy creation request to the File Share Shadow Copy Provider for any UNC paths involved in the Shadow Copy Set
E.1. The File Share Shadow Copy Provider relays the Shadow Copy creation request to the File Share Shadow Copy Agent on each remote File Server involved in the Shadow Copy Set
E.2. The File Share Shadow Copy Agent initiates writer-less Shadow Copy creation request to the VSS Service on the File Server
E.3. The VSS Service on the File Server completes Shadow Copy request using the appropriate VSS hardware or system providers
E.4. The File Share Shadow Copy Agent returns the Shadow Copy path (Shadow Copy Share) to the File Share Shadow Copy Provider
F. Once Shadow Copy creation sequence completes on the Application Server, the VSS requestor on the Application Server can retrieve the Shadow Copy properties from the VSS Service
G. Based on the Shadow Copy device name from the Shadow Copy properties on the Application Server, the Backup Server can access the data on the Shadow Copy shares on the File Servers for backup. The Shadow Copy share will have the same permissions as the original share.
Once the Shadow Copy on the application server is released, the Shadow Copies and associated Shadow Copy shares on the file servers are destroyed.
If the shadow copy sequence fails at any point, the shadow copy sequence is aborted and the backup application will need to retry.
For additional details on processing a backup under VSS, see https://msdn.microsoft.com/en-us/library/aa384589(VS.85).aspx
For additional details on the File Server Remote VSS Protocol, which is being used by the File Share Shadow Copy Provider and File Server Shadow Copy Agent, see https://msdn.microsoft.com/en-us/library/hh554852(v=prot.10).aspx
Requirements and supported capabilities
VSS for SMB File Shares requires:
- Application server and file server must be running Windows Server 2012
- Application server and file server must be domain joined to the same Active Directory domain
- The “File Server VSS Agent Service” role service must be enabled on the file server
- The backup agent must run in a security context that has backup operators or administrators privileges on both application server and file server
- The backup agent/application must run in a security context that has at least READ permission on file share data that is being backed up.
VSS for SMB File Shares can also work with 3rd party Network Attached Storage (NAS) appliances or similar solutions. These appliances or solutions must support SMB 3.0 and File Server Remote VSS Protocols.
VSS for SMB File Shares support:
- Application server configured as single server or in a failover cluster
- File servers configured as a single server or in a failover cluster with continuously available or scale-out file shares
- File shares with a single link DFS-Namespaces link target
VSS for SMB File Shares has the following limitations:
- Unsupported VSS capabilities
- Hardware transportable shadow copies
- Writable shadow copies
- VSS fast recovery, where a volume can be quickly reverted to a shadow copy
- Client-Accessible shadow copies (Shadow Copy of Shared Folders)
- Loopback configurations, where an application server is accessing its data on SMB file shares that are hosted on the same application server are unsupported
- Hyper-V hosts based Shadow Copy of virtual machines, where the application in the virtual machine stores its data on SMB file shares is not supported.
- Data on mount points below the root of the file share will not be included in the shadow copy
- Shadow Copy shares do not support failover
Deployments
The most common deployment of VSS for SMB File Shares is expected to be with Hyper-V, where a Hyper-V server is storing the virtual machine files on remote SMB file share.
The following sections outlines some example deployments and describe the behavior of each deployment.
Example 1: Single Hyper-V server and file server
In this deployment there is a single Hyper-V server and a single file server, both un-clustered. The file server has two volumes attached to it, each with a file share. The virtual machine files for VM A are stored on \\fileserv\share1, which is backed by Volume 1. Some virtual machine files for VM B are stored on \\fileserv\share1, which is backed by Volume 1, and some are stored on \\fileserv\share2, which is backed by Volume 2. The virtual machine files for VM C are stored on \\fileserv\share2, which is backed by Volume 2.
When the backup operator performs a Shadow Copy of VM A, the Hyper-V VSS writer will add \\fileserv\share1 to the Shadow Copy set. Once ready, the File Share Shadow Copy Provider relays the Shadow Copy request to \\fileserv. On the file server, the File Share Shadow Copy Agent invokes the local VSS service to perform a Shadow Copy of Volume 1. Volume 2 will not be part of the Shadow Copy set, since only \\fileserv\share1 was reported by the VSS writer. When the Shadow Copy sequence is complete, a Shadow Copy share \\fileserv\share1@{GUID} will be available for the backup application to stream the backup data. Once the backup is complete, the backup application releases the Shadow Copy set and the associated Shadow Copies and Shadow Copy shares are destroyed.
If the backup operator performs a Shadow Copy of VM B, the Hyper-V VSS writer will report both \\fileserv\share1 and \\fileserv\share2 in the Shadow Copy set. On the file server side, this will result in a Shadow Copy of both Volume 1 and Volume 2 and two Shadow Copy shares \\fileserv\share1@{GUID} and \\fileserv\share2@{GUID} are created.
If the backup operator performs a Shadow Copy of VM A and VM B, again the Hyper-V VSS writer will report both \\fileserv\share1 and \\fileserv\share2 in the Shadow Copy set. On the file server side, this will result in a Shadow Copy of both volumes and creation of two Shadow Copy shares.
Example 2: Two Hyper-V servers and a single file server
In this deployment there are two Hyper-V server and a single file server, all un-clustered. The file server has two volumes attached to it, each with a file share. The virtual machine files for VM A are stored on \\fileserv\share1, which is backed by Volume 1. Some virtual machine files for VM B is stored on \\fileserv\share1, which is backed by Volume 1, and some are stored on \\fileserv\share2, which is backed by Volume 2. The virtual machine files for VM C are stored on \\fileserv\share2, which is backed by Volume 2.
When the backup operator performs a Shadow Copy of VM B, the Hyper-V VSS writer will report both \\fileserv\share1 and \\fileserv\share2 in the Shadow Copy set. Once ready, the File Share Shadow Copy Provider relays the Shadow Copy request to \\fileserv. On the file server, the File Share Shadow Copy Agent invokes the local VSS service to perform a Shadow Copy of Volume 1 and Volume 2, since both share1 and share2 are in the Shadow Copy set. When the Shadow Copy sequence is complete, two Shadow Copy shares \\fileserv\share1@{GUID} and \\fileserv\share2@{GUID} will be available for the backup application to stream the backup data. Once the backup is complete, the backup application releases the Shadow Copy set and the associated Shadow Copies and Shadow Copy shares are destroyed.
In this deployment the backup operator cannot perform a Shadow Copy of VM A in combination of either VM B or VM C, as they are running on separate Hyper-V hosts. The backup operator can perform a Shadow Copy of VM B and VM C, since both are running Hyper-V server 2.
It is also worth noting that the backup operator cannot perform Shadow Copy of VM A and VM B (or VM C) in parallel, since the VSS service on the file server can only perform one Shadow Copy at a time. Note that this restriction is only for the time it takes to create the Shadow Copies, not for the entire duration of the backup session.
Example 3: Two Hyper-V servers and two file servers
In this deployment there are two Hyper-V server and two file servers, all un-clustered. Each file server has a volume attached to it, each with a file share. The virtual machine files for VM A are stored on \\fileserv1\share, which is backed by Volume 1 on File Server 1. Some virtual machine files for VM B is stored on \\fileserv1\share, which is backed by Volume 1 on File Server 1, and some are stored on \\fileserv2\share, which is backed by Volume 1 on File Server 2. The virtual machine files for VM C are stored on \\fileserv2\share, which is backed by Volume 1 on File Server 2.
When the backup operator performs a Shadow Copy of VM B, the Hyper-V VSS writer will report both \\fileserv1\share and \\fileserv2\share in the Shadow Copy set. When ready, the File Share Shadow Copy provider relays a Shadow Copy request to both \\fileserv1 and \\fileserv2. On each file server, the File Share Shadow Copy Agent invokes the local VSS service to perform a Shadow Copy of the volume backing the file share. When the Shadow Copy sequence is complete, two Shadow Copy shares \\fileserv1\share1@{GUID} and \\fileserv2\share2@{GUID} will be available for the backup application to stream the backup data. Once the backup is complete, the backup application releases the Shadow Copy set and the associated Shadow Copies and Shadow Copy shares are destroyed on both file servers.
Similar to the previous deployment example, the backup operator cannot perform a Shadow Copy that spans virtual machines across multiple Hyper-V servers.
Similar to the previous deployment example, the backup operator cannot perform Shadow Copy of VM A and VM B in parallel, since the VSS service on file server 1 can only perform one Shadow Copy at a time. However, it is possible to perform Shadow Copy of VM A and VM C in parallel since the virtual machines files are stored on separate file servers.
Example 4: Two Hyper-V servers and a File Server cluster
In this deployment there are two Hyper-V servers and a cluster, configured as a Failover Cluster. The failover cluster has two cluster nodes, node1 and node2. The administrator has configured a file server cluster role, \\fs1, which is currently online on node1, with a single share, \\fs1\share, on volume 1. To utilize both cluster nodes, the administrator has configured a second file server cluster role, \\fs2, which is currently online on node2, with a single share, \\fs2\share, on volume 2.
When the backup operator performs a Shadow Copy of VM A, the Hyper-V VSS writer will report \\fs1\share in the Shadow Copy set. When ready, the File Share Shadow Copy Provider relays a Shadow Copy request to \\fs1. As part of the exchange between the File Share Shadow Copy Provider and the File Share Shadow Copy Agent, the Agent will inform the Provider of the physical computer name, node1, which is actually performing the Shadow Copy.
On node1, the File Share Shadow Copy Agent invokes the local VSS service to perform a Shadow Copy of the volume backing the file share. When the Shadow Copy sequence is complete, a Shadow Copy share \\node1\share@{GUID} will be available for the backup application to stream the backup data. Notice the Shadow Copy share, \\node1\share@{GUID}, is scoped to the cluster node, node1, and not the virtual computer name, \\fs1.
Once the backup is complete, the backup application releases the Shadow Copy set and the associated Shadow Copies and Shadow Copy shares are destroyed. If for some reason the file server cluster role is moved to, or fails over to, node2 before the backup sequence is complete, the Shadow Copy share and the Shadow Copy becomes invalid.If the file server cluster roles is moved back to node1 the Shadow Copy and the corresponding Shadow Copy share will become valid again.
Example 5: Two Hyper-V servers and a Scale-Out File Server cluster
In this deployment there are two Hyper-V servers and a cluster, configured as a Failover Cluster. The failover cluster has two cluster nodes, node1 and node2. The administrator has configured a scale-out file server cluster role. The scale-out file server cluster role is new in Windows Server 2012 and is different than the traditional file server cluster role in a number of ways:
- Uses Clustered Shared Volumes, which is a cluster volume that is accessible on all cluster nodes
- Uses Distributed Network Names, which means the virtual computer name is online on all cluster nodes
- Uses scale-out file shares, which means the share is online on all cluster nodes
- Uses the DNS round robin mechanism to distribute file server clients across cluster nodes
The administrator has configured a single Scale-Out File Server, \\sofs, with a single share, \\sofs\share, backed by a single CSV volume, CSV1. Because of DNS round robin, Hyper-V server 1 is accessing the virtual machine files for VM A, on \\sofs\share, through node1 and Hyper-V server 2 is accessing the virtual machine files for VM B and VM C, on \\sofs\share, through node2.
When the backup operator performs a Shadow Copy of VM B and C, the Hyper-V VSS writer will report \\sofs\share in the Shadow Copy set. When ready, the File Share Shadow Copy Provider relays a Shadow Copy request to \\sofs. As part of the exchange between the File Share Shadow Copy Provider and the File Share Shadow Copy Agent, the Agent will inform the Provider of the physical computer name which is actually performing the Shadow Copy. In this scenario, the physical computer name will be the name of the CSV coordinator node, and the File Share Shadow Copy Provider will connect to the cluster node that is currently the CSV coordinator node, which could be node1.
On node1, the File Share Shadow Copy Agent invokes the local VSS service to perform a Shadow Copy of the CSV volume backing the file share. When the Shadow Copy sequence is complete, a Shadow Copy share \\node1\share@{GUID} will be available for the backup application to stream the backup data. Notice the Shadow Copy share, \\node1\share@{GUID}, is scoped to the cluster node, \\node1, and not the virtual computer name, \\fs, similar to example 4.
Once the backup is complete, the backup application releases the Shadow Copy set and the associated Shadow Copies and Shadow Copy shares are destroyed. If for some reason node1 becomes unavailable before the backup sequence is complete, the Shadow Copy share and the Shadow Copy become invalid. Actions, such as moving the CSV coordinator for CSV1 to node 2, do not affect the Shadow Copy share.
Installation and configuration
This section contains information about installing and configuring the File Share Shadow Copy Provider and File Share Shadow Copy Agent.
Installation of File Share Shadow Copy Provider
The File Share Shadow Copy Provider is installed by default on all editions of Windows Server, so no further installation is necessary.
Installation of File Share Shadow Copy Agent
To install the File Share Shadow Copy Agent on the file server(s), do the following on each file server:
Do the following, with administrative privileges, to install the File Server role and the File Server Shadow Copy Agent role service on each file server:
GUI
1. In the Server Manager Dashboard click Add roles and features
2. In the Add Roles and Features Wizard
a. In the Before you begin wizard page, click Next
b. In the Select installation type wizard page, select Role-based or feature-based installation
c. In the Select destination server wizard page, select the server where you want to install the File Share Shadow Copy Agent
d. In the Select server roles wizard page:
d.i. Expand File and Storage Services
d.ii. Expand File Services
d.iii. Check File Server
d.iv. Check File Server VSS Agent Service
e. In the Select features wizard page, click Next
f. In the Confirm installation selections, verify File Server and File Server VSS Agent Service are listed, and click Install
PowerShell
1. Start elevated Windows PowerShell (Run as Administrator)
2. Run the following command:
Add-WindowsFeature -Name File-Services,FS-VSS-Agent
Add backup user to Backup Operators local group on file server
The user context in which the shadow copy is performed must have the backup privilege on the remote file server(s) that are part of the shadow copy set.
Commonly this is done by adding the user that is performing the shadow copy to the Backup Operators group on the file server(s).
To add a user to the local Backup Operators group, do the following with administrative privileges on each file server:
GUI
1. In the Server Manager Dashboard click Tools and select Computer Management
2. In Computer Management:
a. Expand Local Users and Groups
b. Expand Groups
c. In the results pane , double click Backup Operators
d. In the Backup Operators Properties page , click Add
e. Type the username to add to the Backup Operators group, click OK
f. In the Backup Operators Properties page , click OK
g . Close Computer Management
Windows PowerShell
1. Start elevated Windows PowerShell (Run as Administrator)
2. Run the following commands, adjusting user account and file server name to your environment:
$objUser = [ADSI]("WinNT://domain/user")
$objGroup = [ADSI]("WinNT://fileserv/Backup Operators")
$objGroup.PSBase.Invoke("Add",$objUser.PSBase.Path)
Perform a Shadow Copy
To perform a Shadow Copy of an applications data that is stored on a file share, a VSS-aware backup application that supports VSS for SMB File Shares functionality must be used.
Note: Windows Server Backup in Windows Server 2012 does not support VSS for SMB File Shares.
The following section shows examples of performing a Shadow Copy of a virtual machine that has its data files stored on a SMB file share, using:
- DISKSHADOW
- Microsoft System Center Data Protection Manager 2012 SP1 CTP1
The following diagram illustrates the configuration of the setup used for the examples in this section:
The following details the configuration of the virtual machine:
1. Start elevated Windows PowerShell (Run as Administrator) and do the following:
PS C:\Users\administrator.SMBTEST> Get-VM | select VMName, State, Path | FL
VMName : vm1
State : Running
Path : \\smbsofs\vm\vm1\vm1
DISKSHADOW
To perform a Shadow Copy of virtual machine using DISKSHADOW on the Hyper-V hosts (clausjor04):
1. Start elevated Windows PowerShell (Run as Administrator) and do the following:
PS C:\Users\administrator.SMBTEST> DISKSHADOW
Microsoft DiskShadow version 1.0
Copyright (C) 2012 Microsoft Corporation
On computer: CLAUSJOR04, 5/30/2012 5:34:42 PM
DISKSHADOW> Set Context Persistent
DISKSHADOW> Set MetaData vm1backup.cab
DISKSHADOW> Begin Backup
DISKSHADOW> Add Volume \\smbsofs\vm\vm1
DISKSHADOW> Create
Alias VSS_SHADOW_1 for shadow ID {7b53b887-76e5-4db8-821d-6828e4cbe044} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {2bef895d-5d3f-4799-8368-f4bfc684e95b} set as environment variable.
Querying all shadow copies with the shadow copy set ID {2bef895d-5d3f-4799-8368-f4bfc684e95b}
* Shadow copy ID = {7b53b887-76e5-4db8-821d-6828e4cbe044} %VSS_SHADOW_1%
- Shadow copy set: {2bef895d-5d3f-4799-8368-f4bfc684e95b} %VSS_SHADOW_SET%
- Original count of shadow copies = 1
- Original volume name: \\SMBSOFS\VM\ [volume not on this machine]
- Creation time: 5/30/2012 5:35:52 PM
- Shadow copy device name: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}
- Originating machine: FSF-260403-09
- Service machine: CLAUSJOR04.SMBTEST.stbtest.microsoft.com
- Not exposed
- Provider ID: {89300202-3cec-4981-9171-19f59559e0f2}
- Attributes: No_Auto_Release Persistent FileShare
Number of shadow copies listed: 1
DISKSHADOW> End Backup
The Set Context Persistent command (and attributes), highlighted in orange, sets the Shadow Copy to be persistent, meaning that it is up to the user or application to delete the Shadow Copy when done.
The Set MetaData stores the metadata information for the Shadow Copy, which is needed for restore, in the specified file.
The Add Volume command, highlighted in yellow, adds the UNC path to the Shadow Copy set. You can specify multiple paths by repeating the Add Volume command.
The Create command, initiates the Shadow Copy. Once the Shadow Copy creation is complete, DISKSHADOW outputs the properties of the Shadow Copy. The Shadow Copy device name, highlighted in green, is the path for the Shadow Copy data, which we can copy to the backup store using XCOPY or similar tools.
During the backup session, you can see the virtual machine status reporting “Backing up..” in Hyper-V Manager. The backup session starts with the CREATE command and ends with the END BACKUP command in the DISKSHADOW sequence above.
After the Shadow Copy is complete, we can browse the Shadow Copy share (Shadow Copy device name from above) and copy the data we want to back up to an alternate location:
1. Start elevated Windows PowerShell (Run as Administrator) and do the following:
PS C:\Users\administrator.SMBTEST> Get-ChildItem -Recurse -Path "\\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}"
Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 5/30/2012 5:19 PM vm1
Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 5/30/2012 5:19 PM vm1
-a--- 5/30/2012 5:35 PM 8837436928 vm1.vhd
Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1\vm1
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 5/30/2012 5:19 PM Virtual Machines
Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1\vm1\Virtual Machines
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 5/30/2012 5:19 PM 87B27972-46C2-406B-87A4-C3FFA1FB6822
-a--- 5/30/2012 5:35 PM 28800 87B27972-46C2-406B-87A4-C3FFA1FB6822.xml
Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1\vm1\Virtual
Machines\87B27972-46C2-406B-87A4-C3FFA1FB6822
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 5/30/2012 5:22 PM 2147602688 87B27972-46C2-406B-87A4-C3FFA1FB6822.bin
-a--- 5/30/2012 5:22 PM 20971520 87B27972-46C2-406B-87A4-C3FFA1FB6822.vsv
Once we are done copying the data, we can go ahead and delete the Shadow Copy, as highlighted below:
1. Start elevated Windows PowerShell (Run as Administrator) and do the following:
PS C:\Users\administrator.SMBTEST> DISKSHADOW
Microsoft DiskShadow version 1.0
Copyright (C) 2012 Microsoft Corporation
On computer: CLAUSJOR04, 5/30/2012 5:44:21 PM
DISKSHADOW> Delete Shadows Volume \\smbsofs\vm
Deleting shadow copy {7b53b887-76e5-4db8-821d-6828e4cbe044} on volume \\SMBSOFS\VM\ from provider {89300202-3cec-4981-91
71-19f59559e0f2} [Attributes: 0x04400009]...
Number of shadow copies deleted: 1
Restore data from a Shadow Copy
To restore the virtual machine data from the backup store back to its original location:
1. Start elevated Windows PowerShell (Run as Administrator) and do the following:
DISKSHADOW> Set Context Persistent
DISKSHADOW> Load MetaData vm1backup.cab
DISKSHADOW> Begin Restore
DISKSHADOW> //xcopy files from backup store to the original location
DISKSHADOW> End Restore
The Load MetaData command loads the metadata information for the Shadow Copy, which is needed for restore, from the specified file.
After issuing the Begin Restore command, you can copy the virtual machine files from the backup store to the original location (\\smbsofs\vm\vm1). See this TechNet article for more information on XCOPY restore of Hyper-V
Data Protection Manager 2012 SP1 CTP1
To perform data protection with Microsoft System Center Data Protection Manager 2012 SP1 CTP1 (DPM), we create a new protection group that includes the virtual machine we want to protect. After installing the DPM agent on the Hyper-V server and allocate some disk to the storage pool, we can create a protection group using the following steps:
1. In the System Center 2012 DPM Administrator Console, select Protection
2. In the Protection view, select New
3. In Create New Protection Group wizard, do the following
a. In Welcome, click Next
b. In Select Protection Group Type, select Servers
c. In Select Group Members
c.i. Locate the server where the VM is running
c.ii. Expand the Hyper-V node
c.iii. Select the virtual machine you want to backup (see screenshot below)
c.iv. Click Next
d. In Select Data Protection Method
d.i. Enter a protection group name
d.ii. Select I want short-term protection using Disk
d.iii. Click Next
d.e. Complete the remainder of the wizard using defaults
When the protection group is created and the initial replica is completed, you should see the following in the DPM Administrator Console:
If you inspect the application server during the initial replica using DISKSHADOW, you will be able to see the Shadow Copy in progress. The following shows the list shadows all during the creation of the initial replica:
DISKSHADOW> list shadows all
Querying all shadow copies on the computer ...
* Shadow copy ID = {c0024211-bd08-4374-ac47-399df2d20075} <No Alias>
- Shadow copy set: {28e88c97-f5b1-4124-ae7b-83f5600d54ff} <No Alias>
- Original count of shadow copies = 1
- Original volume name: \\SMBSOFS.SMBTEST.STBTEST.MICROSOFT.COM\VM\ [volume not on this machine]
- Creation time: 5/30/2012 6:49:35 PM
- Shadow copy device name: \\FSF-260403-09.SMBTEST.STBTEST.MICROSOFT.COM\VM@{B6995DEF-A951-4379-9A3E-0B3
619FB9A6A}
- Originating machine: FSF-260403-09
- Service machine: CLAUSJOR04.SMBTEST.stbtest.microsoft.com
- Not exposed
- Provider ID: {89300202-3cec-4981-9171-19f59559e0f2}
- Attributes: Auto_Release FileShare
Number of shadow copies listed: 1
The highlighted in yellow is the remote UNC path which DPM specified for the Shadow Copy. The highlighted in green is the Shadow Copy device name, where DPM access the Shadow Copy data for replication. The highlighted in orange are the attributes used when DPM created the Shadow Copy. In this case the Shadow Copy is auto-release, meaning that the Shadow Copy is automatically released and deleted once DPM stops using it.
Tips and Tricks
Event logs
VSS for SMB File Shares logs events for the Agent and Provider respectively. The event logs can be found on this path in Event Viewer:
- Microsoft-Windows-FileShareShadowCopyProvider
- Microsoft-Windows-FileShareShadowCopyAgent
Encryption
By default the network traffic between the computer running the VSS provider and the computer running the VSS Agent Service requires mutual authentication and is signed. However the traffic is not encrypted, as it doesn’t contain any user data. It is possible to enable encryption of network traffic.
You can control this behavior using Group Policy (gpedit.msc) in “Local Computer Policy->Administrator Templates->System->File Share Shadow Copy Provider”. You can also configure it in a Group Policy Object in the Active Directory domain.
Garbage collecting orphaned Shadow Copies
In case of unexpected computer restarts or similar events on the application server after the Shadow Copy has been created on the file server, some Shadow Copies may be left as orphaned on the file server. It is important to remove these Shadow Copies to ensure best possible system performance. By default the VSS Agent Service will remove Shadow Copies older than 24 hours.
You can control this behavior using Group Policy in “Local Computer Policy->Administrator Templates->System->File Share Shadow Copy Agent”. You can also configure it in a Group Policy Object in the Active Directory domain.
Long running shadow copies
The VSS Agent Service maintains a sequence timer during Shadow Copy creation requested by an application server. By default the VSS Agent Service will abort a Shadow Copy sequence if it doesn’t complete in 30 minutes to ensure other application servers are not blocked for extended period of time. To configure the file server to use a different value through the registry, set the following registry on each file server
Set-ItemProperty -Path "HKLM: SYSTEM\CurrentControlSet\Services\fssagent\Settings" LongWriterOperationTimeoutInSeconds-Value 1800 –Force
If you are using a Scale-Out File Server, it may be necessary to adjust the cluster property SharedVolumeVssWriterOperationTimeout as well. The default value is 1800 seconds (minimum is 60 seconds and maximum is 7200 seconds). The backup user is expected to tweak this value based on the expected time for the VSS writer operations during PrepareForSnapshot and PostSnapshot calls (whichever is higher). For example, if a VSS writer is expected to take up to 10 minutes during PrepareForSnapshot and up to 20 minutes during PostSnapshot, the recommended value for SharedVolumeVssWriterOperationTimeout would be 1200 seconds.
Accessing file shares using IP addresses
In general you should use hostnames (e.g. \\fileserver\share\) or fully qualified domain names (e.g. \\fileserver.smbtest.stbtest.microsoft.com\share\) when configuring your application server to use SMB file shares. If for some reason you need to use IP addresses (e.g. \\192.168.1.1\share\), then the following are supported:
Note: DNS reverse lookup (IP address to host name) must be available to successfully use IP addresses).
IPv4:
Strict four-part dotted-decimal notation, e.g.\\192.168.1.1\share
IPv6:
1. Global IPv6 and its literal format, e.g.,
\\2001:4898:2a:3:2c03:8347:8ded:2d5b\share \\2001-4898-2a-3-2c03-8347-8ded-2d5b.ipv6-literal.net\share
2. Site Local IPv6 format (Start with FEC0:) and its literal format
\\fec0::1fd9:ebee:ea74:ffd8%1\share
\\fec0--1fd9-ebee-ea74-ffd8s1.ipv6-literal.net\share
3. IPv6 tunnel address and its literal format
\\2001:4898:0:fff:0:5efe:172.30.182.42\share \\2001-4898-0-fff-0-5efe-172.30.182.42.ipv6-literal.net\share
IPv6 Link Local addresses (Starts with FE80:) are not supported.
Conclusion
I hope you enjoyed this introduction to VSS for SMB File Shares and agree how this feature is useful to being able to provide backup of application servers that store their data files on SMB file shares, which includes host-based backup of Hyper-V computers storing virtual machines on SMB file shares.
Claus Joergensen
Principal Program Manager
Windows File Server Team