VSS for SMB File Shares

Note: this post originally appeared on https://aka.ms/clausjor by Claus Joergensen.

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 3^rd 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 http://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 http://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 3^rd 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> Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}

  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 Writer Verify command specifies that the backup or restore operation must fail if the writer or component is not included. For more information see this TechNet article.

  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