5

We're working with consultants on a large DFS replication project and we experienced a significant loss of data during the initial replication.

While trying to identify what happened the consultant came back and said this was due to using the same drive letter on both servers involved in the replication. I'm trying to determine if this is a legitimate concern.

Technical details are below:

Server 1 has a file share residing on the D: named Share 1 to sync to Server 2's D:
Server 2 has a file share residing on its D: named Share 2 to sync to Server 2's D:

Would cross syncing these two shares to each other cause an issue? The initial replication was going fine, completing around 60%, until the servers got confused and then Server 2 thought it had all of the data from Server 1 and instructed Server 1 to delete all the rest of its data because it was no longer needed.

Any light you folks can shed on this would be very much appreciated. Thank you.

Windows Ninja
  • 2,586
  • 19
  • 46
  • 70
  • You're replicating a share on server 1 to a share on server 2 and vice versa and they said that the problem was caused because the drive letters are the same? – joeqwerty Jan 20 '15 at 23:25
  • Did you use [preseeding](https://technet.microsoft.com/en-us/library/dn495052.aspx) for the initial replication? This is **very strongly** recommended. I usually use the robocopy method for preseeding. – Zoredache Jan 20 '15 at 23:45
  • As for duplicate identical paths on replica members. I have never seen that been a problem. I have on DFSR replication group copied to 5 different servers. They all have `D:\Apps` as the replicated directory. – Zoredache Jan 20 '15 at 23:50
  • Thanks. I'll bring up preseeding as we prepare for attempt #2 as that's a good idea. – Windows Ninja Jan 20 '15 at 23:57
  • If this was my consultant, I'd rip him a new one. Either for honestly not knowing DFS very well, or for telling me such a bad lie. – HopelessN00b Jan 21 '15 at 00:21

2 Answers2

8

No, this is absolutely not the source of your issue.

I have never seen any documentation that would support this claim, and furthermore, I manage an enterprise with 18 sites, dozens of DFS replication groups, half a dozen DFS namespaces containing hundreds of shares with terabytes of data and have never had an issue that our replication groups replicate almost exclusively from the same drive letter to the same drive letter. (I put a lot of effort into standardizing our server builds, so all our file servers have the same drive letters for the same volumes.)

For example:

enter image description here

Or if you prefer, here's one from the same drive letter and even folder path, for a file server migration:

enter image description here

Edit: I found another highly pertinent example which illustrates why DFS-R doesn't care about drive letters.

Below, a replication group I created for a fileserver migration. Among other problems, I'm combining two seperate volumes of departmental shares into one volume, so on the destination server, I have two replicated folders on the F: drive. (I'll drop the contents of both into a single folder later):

enter image description here

This works just fine because each replicated folder (even ones on the same volume) stores its own the metadata and DFS-R data precisely so that different replicated folders don't confuse each others' replication, as you can see below:

enter image description here

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
  • This is a great answer, thanks for putting the time into this response. – Windows Ninja Jan 21 '15 at 01:20
  • @WindowsNinja You got lucky that you asked about something I've had to put many hundreds of hours into, and happened to be working on this very moment, is all. If I can't show off what I've learned and done, it would all be a monumental waste of effort - not like the users would know the difference between a good DFS setup and a bad one. ;) – HopelessN00b Jan 21 '15 at 01:30
5

Using the same drive letter is not an issue that I have encountered. I have configured multiple servers for DFS and nearly every single time, I have a data volume on D:, followed by a directory structure that's relevant.

I do use the best practice analyzer, following any configuration, as well as Robocopy to preseed any data. Once replication starts, it very quickly finishes the job due to the small percentage of data change. Of course, times vary with data quantity.

The Best Practice Analyzer is a read-only app which won't change your configuration, but will give very salient and direct advice for remediation of any poorly executed configuration. It has saved me quite a few times.

Here is how to use Robocopy to preseed your data, quoting from the Technet Library:

To preseed the replicated files onto the destination server by using

Robocopy

Log on to the destination server with an account that is a member of the local Administrators group on both the source server and the destination server. Open an elevated command prompt. To preseed the files from the source to destination server, run the following command, substituting your own source, destination, and log file paths:

robocopy "<source replicated folder path>" "<destination replicated folder path>" /e /b /copyall /r:6 /w:5 /MT:64 /xd DfsrPrivate /tee /log:<log file path> /v

This command copies all contents of the source folder to the destination folder, with the following parameters:

Parameter                                 Description
"<source replicated folder path>"         Specifies the source folder to preseed on the destination server.
"<destination replicated folder path>"    Specifies the path to the folder that will store the preseeded files.
Important                                 The destination folder must not already exist on the destination server. To get matching file hashes, Robocopy must create the root folder when it preseeds the files.
/e                                        Copies subdirectories and their files, as well as empty subdirectories.
/b                                        Copies files in Backup mode.
/copyall                                  Copies all file information, including data, attributes, time stamps, the NTFS access control list (ACL), owner information, and auditing information.
/r:6                                      Retries the operation 6 times when an error occurs.
/w:5                                      Waits 5 seconds between retries.
MT:64                                     Copies 64 files simultaneously.
/xd DfsrPrivate                           Excludes the DfsrPrivate folder.
/tee                                      Writes status output to the console window, as well as to the log file.
/log <log file path>                      Specifies the log file to write. Overwrites the file’s existing contents. (To append the entries to the existing log file, use /log+ <log file path>.)
/v                                        Produces verbose output that includes skipped files.

For example, the following command replicates files from the source replicated folder E:\RF01 to data drive D: on the destination server:

robocopy.exe "\\srv01\e$\rf01" "d:\rf01" /e /b /copyall /r:6 /w:5 /MT:64 /xd DfsrPrivate /tee /log:c:\temp\preseedsrv02.log
HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Citizen
  • 1,103
  • 1
  • 10
  • 19
  • Thanks for the time you put into this response and you had the right information it just wasn't as good as the other response. I appreciate your help. – Windows Ninja Jan 21 '15 at 01:20
  • 1
    Paul, welcome to ServerFault. *Please* do not forget to post attributions when you are quoting existing documentation or blog articles. Quoting in itself is a good thing as a link target might become stale over time. But *adding* the source reference has the additional value of providing context to the quoted passage and makes sure your article does not look like plagiarism. – the-wabbit Jan 22 '15 at 14:50