We're currently using DFSR in Server 2008 to replicate from our head office to 3 branch offices across VPN links.
This way we have a local copy of all the companies files in each site, for quick access and fault tolerance. We decided against WAN Accelerators and centralised files for cost and speed reasons.
However, DFSR isn't cutting it for us. Since we have 100's of files open at once at the hub site, DFSR spends more time retrying open files than transferring closed ones, which creates a backlog. By around 11AM every day, there's close to 500 files in the backlog that doesn't get cleared until that evening.
This is a major problem because for most of the day the servers aren't in sync. To my understanding this is not something that can be corrected, so we are now looking at alternatives to DFSR to keep these servers in sync.
Does anyone currently use a system like this for their files, and if so, can you recommend the software that you are using?
Some examples I have found are GlobalScape WAFS, and PeerSync.
Best Answer
No synchronization tool can synchronize files that are open w/o running the risk of making inconsistent copies. Unless the tool has hooks into the application holding the file open to request that it "quiesce" the file there will always be a risk that a copy made of an open file will end up being inconsistent and unusable.
It sounds, to me, like you're going to be served poorly by just about any tool, given the profile of open files that you're talking about. I wonder if a version control system / document management system wouldn't possibly be a better fit for you.
I've used the SureSync synchronization tool from Software Pursuits, albeit not in the scenario you're distribing, and have been very pleased with it. It runs as a Windows service on the servers in the replication set and does delta transfers (with the "SPI Agent" add-on). It can replicate open files (can can quiesce VSS-aware applications), though you could potentially run into consistency issues, as I said above.
Response re: comments:
This is the classic fast/cheap/good triangle tradeoff. If you want your replicas to stay in sync throughout the day you're going to need to shell out a lot of money for fast connectivity. If you don't care that the replicas fall out of sync (but "catch up" overnight) then you can spend less money on fast connectivity.
I don't have any Customers who expect all files replicated in such a a manner to be "in sync" at all times on all servers. They don't have the money to spend on LAN-speed WAN connectivity to support it.
If you have a small corpus of files that need to be kept in sync more rigidly you could look at using this more real-time replication solution to cover those files and cover the rest of the files in a slower, less bandwidth-intensive replication solution.
You have to pay the piper somehow is, I guess, what I'm saying.