6

We are currently working on implementing a DR strategy. Instead of SAN-SAN replication, it has been decided to have 2 live file servers replicating via DFSR. However, I don't know whether or not this is a good idea.

Example: DFS does not replicate locked files. Let's say a user has a spreadsheet open for weeks. They do save periodically, but the file still remains open. Then, the active file server goes down and users are redirected to another server, where the file hasn't been replicated.

Is there a way to mitigate that scenario? Am I misunderstanding something? Or is DFSR not designed to be a DR technology?

Edit: What other deficiencies does DFSR have in a DR context, other than my example above?

Bigbio2002
  • 2,763
  • 11
  • 34
  • 51

3 Answers3

4

I've just moved away from a DFS-R environment because of the very reason you described above. Locked files are impossible to deal with and causes all kinds of conflicts especially if both servers are being used like a proper failover (so users are hitting both servers at once).

To me, DFS-R is decent for replicating over WAN/VPN connections to remote offices and not as a DR solution. I highly advise getting some sort of shared storage and using Failover Clusters which have improved quite a bit in 2012 R2 (I'm still on 2008 R2, but it's served us well so far).

Nathan C
  • 14,901
  • 4
  • 42
  • 62
  • 1
    `[...]conflicts especially if both servers are being used like a proper failover (so users are hitting both servers at once).` - The DFS-R documentation is very clear that it is not a good solution in scenarios where the same file is accessed on multiple replicas by different users. In that case, a proper collaboration solutions (like a SharePoint document library) is appropriate. – MDMarra Dec 12 '14 at 18:41
  • @MDMarra I see...they certainly make it *very* easy to do with DFS Namespaces though – Nathan C Dec 12 '14 at 18:44
  • 2
    Think about non-shared resources like home directories, read-only archives, etc. Those are all excellent candidates for both DFS-R and DFS-N. Additionally, you can use a namespace to direct all users at a single replica and then flip it to the other in the event of a failure. There's no mandate that the load be evenly distributed in a DFS-N scenario. – MDMarra Dec 12 '14 at 18:47
2

It is not designed for DR. Not in this way - in this case the user is the problem. I am not sure anything will handle that nicely.

DR also is a crappy scenario it will happily replicate a virus encrypting your files (or deleting them).

TomTom
  • 50,857
  • 7
  • 52
  • 134
  • 2
    Any good DR plan has multiple layers to it. DFS-R can ensure that critical shares are available quickly while proper backups (and the ability/equipment to restore them at the DR site) can protect you from the scenario you've described. – MDMarra Dec 12 '14 at 18:49
  • 1
    Generally you will find that DR is much more a last resort in planning than backuos. At least for most companies. – TomTom Dec 13 '14 at 07:50
0

Yes and no, keep a delay between the sync to be sure to not sync a erase or a corruption. It's only a good way to keep file you don't want to loose, but it's a minimal "backup" scenario.

I would host that server in another location and on a local storage. (as I does not know your SAN topology)

yagmoth555
  • 16,300
  • 4
  • 26
  • 48
  • Backup isn't always synonymous with DR. Can you explain why a DFSR Replica isn't appropriate for a file server DR scenario? – MDMarra Dec 12 '14 at 18:24
  • @MDMarra - First I suggest about a Storage Replica, not DFRS Replica. This way bypass file open problem. "Storage Replica (SR) is a new feature that enables storage-agnostic, block-level, synchronous replication between servers for disaster recovery, as well as stretching of a failover cluster for high availability." from http://blogs.technet.com/b/craigf/archive/2014/10/04/getting-started-with-storage-replica-in-windows-server-technical-preview.aspx – yagmoth555 Dec 12 '14 at 18:34
  • @MDMarra - Second point, where would be the system state ? ready to loose the AD ? DR without AD is not good. – yagmoth555 Dec 12 '14 at 18:35
  • Please re-read my comment. The OP asks if DFS-R is an appropriate technology to protect a file server in a DR scenario. You say "no." In fact, it's the first word in your answer. I'm asking you to explain why you don't think that it is an appropriate technology. I understand the value in SR, but I don't understand why you don't think DFS-R is appropriate. – MDMarra Dec 12 '14 at 18:35
  • @MDMarra - Oh, yes, it's more a gray line then. DFR-R reporting was not done to plan on it for DR, but we fall in opinion based now. You need to do manually reporting each day to monitor it, and we dont talk about locked files. – yagmoth555 Dec 12 '14 at 18:40
  • @MDMarra - Like I told after my No, I still think DFS is a good way to keep critical file kinda safe, but I would not rely only on it for DR. SAN-SAN is block level like the Storage Replica I discuss. After thinking more to it, I keep my No. Why? In all method we discuss there, there is no offline backup and a corruption can happen and be copied over. We are more talking crash recovery, not disaster recovery. – yagmoth555 Dec 12 '14 at 19:04
  • How does storage replication or SAN replication solve the problems that you just identified with DFS-R? They are all vulnerable in the same way. – MDMarra Dec 12 '14 at 20:13
  • @MDMarra - My bad english, sorry. Check my last comment, I told all method we discussed. For the OP I suggest a DFS that sync only at night hosted on another storage than the SAN and on another room for a DR. – yagmoth555 Dec 12 '14 at 20:42