Link to home
Start Free TrialLog in
Avatar of compdigit44

asked on

Windows 2012 R2 DFS Replication

We currently use DFS for our clustered file servers that host 20TB of data. We have some older volumes that the shares resides on which are mount point that we want to move away from and host each share on its own volume. I want to see what other think of my following plan.

1) Install DFS-R
2) On the server hosting the mount point create a new volume that will host the new share
3) In DFS-R setup replication so the data gets replicated from the old location to new location on the same server.
   For example: old \\serverA\MountPoint-A    new \\ServerA\NewShare
4) In DFS-N setup the new volume as a target.
My goal is to replicate all data to the new volume behind the seens with not downtime for users.
Is there a better way to replicate the data since it would be on the same server?
Avatar of Mahesh
Flag of India image

As far as i know, you cannot add different folder target in a same server to a same DFS replication group. You will get an error when trying to add a second folder target.
To move the folder to another drive, use Robocopy to copy files to second drive in multiple pass, under DFs publish new copied folder as a new folder target. U need to this on one folder at a time to minimize user impact
cutoff source folder

Avatar of compdigit44


It should like Windows 2016 can do volume base replication.

Could I slowly add new Files Server running Windows 2016 to my exiting windows 2012 dfs?  We have 20TB of data and using robcopy last time even to catch the diffs daily was painful
I just had a thought. While you cannot replicate data between volumes on the same server, I could setup the new volume on another server, set it up as a target and enable replication correct? If so now do you know when all the data has been copied
You are right
U can setup new server in existing DFS replication group and then allow data to be replicated
DFS is complex technology and when data size is large, most of the times I seen that initial replication takes so many days to complete or even gone in error and you need to trigger it again from scratch
There are so many factors affecting it namely:
Missing DFS hotfixes on source and target
File system permissions complexity
DFS database complexity
Server sizing issues
Staging Quota issues
file locking issues

hence I found DFS to be suitable when you start it from scratch where you don't have existing data to be copied / migrated

I would prefer to use file server in clustered mode with VSS screen shots enabled - that's my personnel choice

Any ways, for your scenario, prestage data along with database on target DFSR server and it should work
The steps involved
Ensure source and target server have adequate disk space, CPU and memory installed
Install all DFSR patches on source and target servers to avoid possible issues
export DFSR database from source server (clone)
copy source data with robocopy in multiple pass (robocopy by default copy data in incremental mode - so no fear of rework)
import dfsr database from previous export clone
allow for initial sync and that's all
The process is explained in below article:
U have to have 2012 / R2 / 2016 server for clone process to work

If you have 2008 R2 as source server, you can simply prestage data from robocopy and then wait for initial sync to get completed

Thank you for your feed back. i am glad my thought process what on the right path with adding the new volume to an other host and letting DFS-R to the rest. I have not had a change to review the links you sent but in the past have not imported the dfs db but is something that i have read can help with the initial seed transfer. I assume there are not issue with file/folder permissions getting replicated correct?
File system permissions mostly get replicated without issues because system account is used for DFS- Replication
If somehow system account is removed from ACL, you may face issues while replicating data, you may see conflicts etc or replication may not complete in timely manner
By cloning database and prestaging data to target server in advance, the file system permissions conflict issues can be avoided to much extent and then initial sync would get completed easily, after that both servers can replicate back and forth
If still you facing issues for replication, then you need to work out of the ways like taking ownership of source folder and flowing system account permissions, take out target server from replicated folder, delete replicated folder completely including DFSR database from target server, readding target server in replicated group etc.

Here is a high level over view of what I am thinking on my Windows 2012 R2 cluster DFS servers.

In DFS Manager on the target for one of the folder it would be something like this
 -> Old volume mount point \\serverA\Drive_1\share
-> New volume no mount point \\serverB\share

I would then setup replication between the share / volume on serverA to serverB. Please note my volumes are around 5TB. I would have both target listed and in the background replication would be running once completed I would remove the target for the Mount point location. Does this sound about right.

My concerns
1) Size of the staging area?
2) Running into issues with permission?
3) Extra load a servers if any?
4) NOt being certain all data copied over completely.

If you had to choose would you go with DFS-R or Robocopy?
If you want full replication path you can go ahead with that, it is typical / simple way and suitable if data size is less (in few GBs) and would take considerable amount of time if data size is big (Minimum 1 Weeks for 5 TB in normal conditions in your case I guess)

However as stated in my last comment, I would prefer prestaging DFSR data and clone of DFSR database on target server

Clone process is pretty straight forward
for data prestaging you can use robocopy, however if you have backup of data you can simply restore that data on target server very quickly
Robocopy will take much time to complete data copy

Other questions:
1) Size of the staging area? - should apply to 2012 also
 2) Running into issues with permission?
You can take entire folder ownership if you got issues - use Subinacl tool - its hassle free
 3) Extra load a servers if any?
Size your servers appropriately, you should have minimum 4 cores CPU and 16 GB of memory but depending on how many users are accessing, you can monitor CPU, memory usage and increase if required. As per my understanding, you need to increase memory up to 32 GB, also you should have extra 25% drive space initially to allocate for staging
 4) NOt being certain all data copied over completely.
I think I already provided answer above and in earlier comments

Thank you again for the great help. I were to restore the data to the new volume from backup, would you still recommend using DFS-R to catch any updated files post restore or robocopy? Regardless of doing the data restore from a backup I would still need to import / clone the DFS-DB correct?
Avatar of Mahesh
Flag of India image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks again...... I think I got it now. I know I asked this below about how will I know when DFS-R completes and you mentioned you did post a answer but believe I missed this... COuld you repost it since I am missing it from the prior thread. This is me being stupid .. sorry
I have posted it but not in words you would like to hear
when you add new member with DFSR, it 1st start one way sync and once all data copy / replication gets completed, it triggers event ID 4104 on target sever which tells you that initial sync is completed, it means replication is completed without errors / misses and now both servers can replicate data back and forth
If any data got missed out from initial replication, you won't get 4104 event ID
Until you initial sync get completed, you should not use target server to avoid issues