Udostępnij za pośrednictwem

Understanding DFSR conflict algorithms (and doing something about conflicts)

  • Artykuł

Ned here again. I’m frequently asked to explain the DFSR conflict algorithm – i.e. what happens when files are created or modified on two servers before replication takes place. What we don’t document well is that there are actually three conflict algorithms and they all behave quite differently. I am breaking these out into scenarios for easier understanding.

(Note: updated 3/25/2011 with some newer behaviors)

Scenario 1: Brand new files in initial sync with different versions of the file on each server.

  • Two servers, A and B
  • Both have a folder called c:rfdata
  • Folder contains a file called salespitch.pptx
  • On server A, salespitch.pptx is dated July 2009. On server B, salespitch.pptx is dated October 2009 and was modified by a user very recently.
  1. I setup a new Replication Group.
  2. I make c:rfdata the Replicated Folder.
  3. I make Server A the Primary Server.

Result: salespitch.pptx from A (dated July 2009) will now exist on both servers. The October version will be conflicted on B and it will lose the conflict.

Explanation: When setting a server as Primary, it wins all conflicts no matter what. This is the so-called “Initial Sync conflict algorithm”.

Scenario 2: Existing files that have been replicated previously and are now being modified on two servers before replicating.

  • Two servers, A and B
  • Both are in an existing Replication Group (not performing initial sync) with a replicated folder pointing to c:rfdata
  • Folder contains a file called salespitch.pptx
  • Replication is latent (in my test, I disconnected network cable from Server A)
  1. I modify the salespitch.pptx file on both servers. On Server A, I modified salespitch.pptx last.
  2. I plug the network cable back in to allow replication to resume.

Result: The file I modified last (i.e. the newest file with the latest UTC time stamp) replicates from A to B. B loses the conflict and his older copy will be conflicted.

Explanation: This is the classic “last writer wins conflict algorithm” that is usually described for DFSR.

Scenario 3: New files that were created on both servers before replicating, but initial sync is not happening

  • Two servers, A and B
  • Both are in a Replication Group with a replicated folder pointing to c:rfdata
  • Replication is latent (in my test, I disconnected network cable from Server A)
  1. I copy an old file to both server A and B – so this file is “new” to DFSR on both servers.
  2. I modify one file on server B.
  3. I plug the network cable back in on A.

Result (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 without KB2450944 installed): The old file on A is replicated to B, and B loses the conflict.
Result (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 with KB2450944 installed): The new file on B is replicated to A, and A loses the conflict.

Explanation: This was the only time an older file would win and this was the so-called “New to DFSR file conflict algorithm”. The reasoning was that when it came to two files being created, the oldest one was likely the most important as it has been in use the longest. But this turned out to be too confusing and likely to cause other issues, so it was changed to match the more consistent "last writer wins" behavior in a hotfix later.

That’s all well and good. But how do I get my conflicted files back when the “wrong” one wins?

You have a few options here:

  1. Use DPM – Data Protection Manager provides on-the-fly backups of files and near-line recovery. This way your odds are highest that the latest versions of the file have been backed up.
  2. Use Volume Shadow Copies – You can configure automatic backups of files on your DFSR servers. Then when users delete or conflict files, the data can be easily restored. With a little training, your users can even restore files themselves and not have to spend time with the help desk. Note also that if you are still running XP or (Dog forbid) Win2000, you need to install a client to let users restore their own files. See TechNet and Windows Help for configuring this on a per-OS basis and make sure you read through the best practices info. VSC does not replace regular backups!
  3. Use backups – Windows Server Backup, NT Backup (if still on Win2003 R2), or 3rd parties should be used to back up
    your data every day. This way no matter what, you can always get back to yesterday’s copy of a file.
  4. Use the restoredfsr.vbs script – Unsupported, as-is, and provided without warranty, this script may be your only hope if you have no created backups and shadow copies. Use it at your own risk. The script is hosted on Code Gallery (https://code.msdn.microsoft.com/restoredfsr). As always, the script requires you to edit a few variables before running – see the script for how-to documentation. You run it with:CSCRIPT.EXE restoredfsr.vbs

Hopefully this makes more sense now.

- Ned “the mediator” Pyle

Comments

  • Anonymous
    October 09, 2010
    The comment has been removed

  • Anonymous
    October 09, 2010
    Little correction to myself, because I've counted the wrong bit ^^ 'So, to get a decision for "FileOrFolder" you only have to calculate, if the Bit 5 [0x10] is set [1] in the attribute value, because only this bit indicates a folder. If it is not set, the test will indicate a file.'

  • Anonymous
    October 11, 2010
    The comment has been removed

  • Anonymous
    October 13, 2010
    The comment has been removed

  • Anonymous
    October 15, 2010
    That wasn't the route I took, but I appreciate the link. I rewrote the script last night and now it handles files versus folders in a foolproof manner. Thanks for bugging me to finally square it away for good.

  • Anonymous
    May 27, 2015
    The comment has been removed

  • Anonymous
    May 27, 2015
    The comment has been removed