Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

FSRM and Data Deduplication may be adversely affected when you use Robocopy /MIR in Windows Server 2012


View products that this article applies to.

Summary

When you use the Robocopy utility together with the /MIR option in Windows Server 2012, Robocopy mirrors the source directory to the destination directory. First, all contents in the destination directory that do not exist in the source directory are deleted. Then, all files that the user can access are copied from the source directory to the destination directory. To copy the files and folders that the user cannot access, you should use the /B or /ZB option of Robocopy.

When you use the /MIR option to copy a whole volume <N:> to a destination volume <Q:>, the mirroring process applies to the System Volume Information folder. This is where some file server features store important metadata. The deletion phase of the mirroring process can result in a loss of metadata that is stored in the System Volume Information folder on the destination volume. Additionally, the copying phase of the mirroring process can result in metadata that is specific to the source volume being copied to the destination volume. This behavior interferes with various services on the file server. For example, the following services are affected:
  • File Server Resource Manager (FSRM)

    FSRM stores quotas, file screens, and other configuration information in the System Volume Information folder. If the folder is deleted, quotas, file screens, and other configuration information will not be enforced on the destination volume.
  • Data Deduplication

    Data Deduplication keeps the common chunk store in the System Volume Information folder. If the folder is deleted, the optimized files (reparse points) that are copied from the source volume become corrupted because the data chunks are not copied to the destination volume. 

    Moreover, issues occur if the source volume does not have Data Deduplication enabled while the destination volume does, or vice versa. The following are some examples:

    Note In the sample commands, P: is a volume that does not have Data Deduplication enabled, and M: is a volume that has data deduplication enabled.
    1. You execute the following command:
      robocopy P: M: /MIR 
      The result is that M:\System Volume Information is deleted. Therefore, the deduplicated files on M: are corrupted.
    2. You execute the following command:
      robocopy P: M: /MIR /ZB 
      The result is that M:\System Volume Information\Dedup is deleted. Therefore, the deduplicated files on M: are corrupted.
    3. You execute the following command:
      robocopy M: P: /MIR /ZB 
      The result is that all deduplication metadata is copied to the P:\System Volume Information\Dedup folder. Because the chunk store IDs on both volumes are the same, problems may occur in future migrations. 
    To work around the problems in these examples, use the /XD option to exclude the System Volume Information folder from the scope of the command. For example, the following command excludes the System Volume Information folder:
    robocopy P: M: /MIR [/ZB] /XD "System Volume Information" 

↑ Back to the top


Keywords: kbinfo, kbexpertiseadvanced, kbsurveytest, kb

↑ Back to the top

Article Info
Article ID : 2834834
Revision : 1
Created on : 1/7/2017
Published on : 6/5/2013
Exists online : False
Views : 463