locked
DFS Replication Database is getting big RRS feed

  • Question

  • Hello Technet,

    I have a question:

    We are running a Windows Server 2008 Storage Server Installation that hosts a domain based DFS  namespace in our domain. The files on this server are being replicated to a second server for availability reasons. This works flawlessly.

    My issue is: I have notived that the replication folder for the DFS Service is getting bigger and bigger. I already have a ~82 GB "private" folder that is located under System volume information -> DFSR. What exactly is stored there and how can I shrink it? I believe it was significantly smaller in the past.

    Thank you für your suggestions.

    best regards
    Martin 

    Monday, May 7, 2012 7:52 AM

All replies

  • Hi Martin,

    Please check which file is growing up in that folder. In order to access the System Volume Information folder, you will need to add Administrator to NTFS permission first.

    Generally it is the DFSR database file which is growing up. You could do the following steps:

    1. Run “net stop dfsr”(without quotation marks) to stop DFSR service.
    2. Then rename dfsr.db to dfsr_old.db under folder database_GUID.
    3. Run “net start dfsr”(without the quotes) to start DFSR service again.
    4. Verify the new database file is created under C:\System Volume Information\DFSR\database_GUID

    If so, wait for some time to see if DFSR is still working fine before delete the DB file.


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

    Tuesday, May 8, 2012 8:13 AM
  • Hello Shaon,

    thanks for your reply.

    I checked the folder again and I think its not the actual dfsr database that is consuming the space on the drive.

    It seems that its the staging space for dfsr. 

    Within the private folder, that is located in the system volume information folder, there are dozens of folders that look something like this:

    "{0AA88331-7392-4EEB-B8C7-817C0EBD02B4}-{088D0331-B640-4D0B-8355-2E004E754AAA}"

    Many of these folders are pretty big (several GBs).  I don't know what to do with these folders, but they take up the most space on the drive.

    Any suggestions?

    Thanks again for reading and 

    best regards

    Martin

    Tuesday, May 8, 2012 12:00 PM
  • Hello,

    It seems like your staging is not been cleaned up? What is your current staging size quota, did you set it to high that the high watermark target is hard to reach? Please look at your events log if you see any of these:

    4206,4208, 4202,4204


    Isaac Oben MCITP:EA, MCSE,MCC View my MCP Certifications

    Tuesday, May 8, 2012 4:30 PM
  • Yes, I see a lot of these. What should I do, reduce the staging size?
    Wednesday, May 9, 2012 8:05 AM
  • Hello,

    With those events, you will need to increase your staging quota. Here are some helpful technet blogs to help the first blog also tells you how to calculate the amount pf quota you need.

    on point 4:DFSR Staging directory is too small for the amount of data being modified

    You will see DFS replication 4202, 4204, 4206 and 4208 events about this activity and if happens often (multiple times per day) your quota is too small. See the section Optimize the staging folder quota and replication throughput in the Designing Distributed File Systems guidelines for tuning this correctly. You can change the quota using the DFSR Management MMC (dfsmgmt.msc). Select Replication in the left pane, then the Memberships tab in the right pane. Double-click a replicated 

    http://blogs.technet.com/b/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspx

    Also monitor for staging clean up events in the DFS Replication event log (for example, event 4208 followed by 4206, which means that it was not possible to stage a file due to lack of space and no further clean up was possible), or frequent clean-up events (4202 followed by 4204). If more than a few such event-pair occurs every hour, then increase the size of staging by 50%.

    http://blogs.technet.com/b/filecab/archive/2006/03/20/422544.aspx

    Hope this helps..


    Isaac Oben MCITP:EA, MCSE,MCC View my MCP Certifications

    Wednesday, May 9, 2012 4:08 PM
  • Thank you very much for you reply.

    I read the articles and after that, I increased the quota for the affected pools accordingly.

    The most critical share has a ~6.5 GB staging folder. I increased the quota to 10.5 GB  (on all (both) members of the replication) and waited for a couple of days. Unfortunatly the staging size did not deacrease. Even after a couple of days, the staging size is still 6.5 GB.

    What surprises me, is that most of the files within the actual staging folder got created either yesterday or today. So I right know do not know if this bevaviour is normal or if I am really supposed to worry.

    Thanks for reading

    Martin

    Tuesday, May 15, 2012 6:42 AM
  • The problems with the staging size do persist.

    I again checked the top 3 folders in the staging folder.

    The first share had 6269 MB on May 7th, after increasing the staging size to 10GB and waiting until today, the size of the staging quota increased and is now at 13.563 MB. It has more then doubled. More then 12 GB of the total staging size resides in a folder that was last changened at  August 10th 2011.

    So without going into further details, the staging size seems to grow and grow and grow. What can I do about it? The actual Folders that contain the productive data are not bigger then 70GB, so I am pretty baffled that alone the staging folder can grow THIS big.

    Is it a viable option to stop and delete the replication and reestablish it or is there another, more professional way to solve it?




    • Edited by MartinAD Friday, May 25, 2012 10:49 AM
    • Proposed as answer by Alek.Meister Wednesday, June 21, 2017 3:56 AM
    • Unproposed as answer by Alek.Meister Wednesday, June 21, 2017 3:56 AM
    Friday, May 25, 2012 9:21 AM
  • 1.  Open a CMD prompt as an administrator on the DFSR server.
    2.  Get the GUID of the Replicated Folder you want to clean:

    WMIC.EXE /namespace:\\root\microsoftdfs path dfsrreplicatedfolderconfig get replicatedfolderguid,replicatedfoldername

    3.  Then call the CleanupConflictDirectory method:

    WMIC.EXE /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where “replicatedfolderguid='<RF GUID>'” call cleanupconflictdirectory


    • Proposed as answer by Alek.Meister Wednesday, June 21, 2017 4:01 AM
    • Unproposed as answer by Alek.Meister Wednesday, June 21, 2017 4:02 AM
    Wednesday, June 21, 2017 3:58 AM
  • Hello,

    Staging is an area where files are broken up at the source, sent to the source server's staging folder, then send to the replication partners staging folder, then reassembled and copied to the respective target server's destination folder.

    If your staging size is getting bigger that means you have many files that are being changed and replicated, perhaps you need more bandwidth so that the files can replicate faster.

    Sometimes the staging area grows larger during the day when users are actively moving, creating and editing files. The the staging size then starts to decrease during off peak hours when the replication is able to outpace the changes.

    It's not a problem, just make sure you have plenty disk space for the staging and also for the replication database to hold all the replication data. 


    Miguel Fra
    Falcon IT Services
    https://www.falconitservices.com

     


    • Edited by Miguel Fra Wednesday, June 21, 2017 5:43 AM
    Wednesday, June 21, 2017 5:41 AM