Inquiridor

Files backlogged in several DFS Replication Folder

Pergunta

I have a DFS setup between two sites. The sites are linked through a 1 Mbps dedicated symetrical link, and as of yet there are no aparent conectivity issues. DFS is running Windows 2008r2 and ejenal2 is running Windows Storage Server 2008 r2. Servers are
fully patched until one week ago. The total size of the replicated folders between sites is roughly 1.7 TB.

As of a couple of months ago the several of replicated folders seem to have fallen out of sync. I have viewed a couple of dfsrdiag backlog commands and have encountered mixed results:

I fiddled a bit with the quota settings on DV, putting them from 40GiB to 400GiB. I also updated the firmware on the Ejenal2 server. That I did just moments before I posted my original post three days ago. BTW the 400 GiB setting I pulled out of my <explicit>.
The 32 largest files on DV only amount to 24 GiB.

Todas as Respostas

If your data were to change at a rate of 1% per day in almost perfect conditions it would use your link solidly for 5 hours. Have you checked the performance of the link to see if it is at maximum usage ?

Can you look at your events log and post any events ID related to dfs-r? I am looking to see if you have any of the following staging area events:

Event ID: 4202
Severity: Warning

The DFS Replication service has detected that the staging space in use for the replicated folder at local path (path) is above the high watermark. The service will attempt to delete the oldest staging files. Performance may be affected.

Event ID: 4204
Severity: Informational

The DFS Replication service has successfully deleted old staging files for the replicated folder at local path (path). The staging space is now below the high watermark.

Event ID: 4206
Severity: Warning

The DFS Replication service failed to clean up old staging files for the replicated folder at local path (path). The service might fail to replicate some large files and the replicated folder might get out of sync. The service will automatically retry staging
space cleanup in (x) minutes. The service may start cleanup earlier if it detects some staging files have been unlocked.

Event ID: 4208
Severity: Warning

The DFS Replication service detected that the staging space usage is above the staging quota for the replicated folder at local path (path). The service might fail to replicate some large files and the replicated folder might get out of sync. The service will
attempt to clean up staging space automatically.

Yes, there are a couple of instances of each of those errors on the Ejenal2 server. The Ejenal2 server is the one used on the local office, the DFS is in the data center and used more as a data collector than an actual share.

. Here is a breakdown of them:

5014 80 instances in the last 7 days
4202 19 instances in the last 7 days
4304 1 instance in the last 7 days

In the past I have tried to get rid of them, but have not been succesful at that.

I have done some numbers on the shares with the most back logs. In all cases, the quota is well above the size of the 32 largest files, in some of them I might have gone overboard and assigned a too ample quota (400 GB quota, 24 GB 32 largest files).

I have come to the conclusion that if I can't fix it by this next week, I'll just erase everything and reseed DFS with a copy of the current data.

Before testing to recreate the DFS replication group, you could test to recreate DFS database:

1. Stop and ALSO disable the DFSR service on <ServerA> server (don't just simply stop it)

2. In Windows Explorer open the specific drive

3. Right click on the "System Volume Information" directory and select Properties\Security

Note: You might need to select the option for "Show hidden files, folders or drives" and also uncheck "Hide protected operating system files" in the folders view options to be able to even see the "System Volume Information" directory.

4. Grant your user account that you're logged in with (if a member of Administrators group this will also suffice) "Full Control" to the "System Volume Information" directory.

Note: You may get an error on setting security on some files - this is expected.

1. By <Server A> I guess you mean the server on regional offices, and not on the datacenter. If that is the case it would be Ejenal2?

2. The problematic servers I exposed in my original post are actually part of a larger array. We have four remote offices, all which are replicating to our data center. Will removing the database affect any of the other locations?

AsI mentioned in the end of my reply, <ServerA> will be set as Primary member. So it should be the server which has more updated data.

Note: As DFSR stopped working for a while, we may get updated data on more than 1 server target. If that is the case, you will first try to do a robocopy for copying udpated files from other servers to <ServerA>.

TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.