Storage Replica or DFS Storage Replication: Best Use Cases for Each

While Microsoft’s Distributed File System (DFS) replication certainly has its place, it is not an ideal fit for every situation. In some cases, an organization may be much better off using the newer Windows Server Storage Replica feature instead.

When DFS Replication Makes Sense

Although DFS is an aging technology, there are some situations in which it might be best to continue using DFS replication, as opposed to switching to Storage Replica.

For example, DFS may be the only viable choice for organizations that are running older versions of Windows Server. Storage Replica is a fairly recent addition to Windows Server, and runs on Windows Server 2016 and later.

A second situation in which it may be best to continue using DFS storage replication is if the replication traffic is bandwidth-constrained. This isn’t to say that Windows Server storage replication can’t function in low-bandwidth environments. Storage Replica can be configured to use either synchronous or asynchronous replication. Regardless, DFS replication just seems to excel in environments that suffer from extreme bandwidth limitations.

The Case for Transitioning to Storage Replica

DFS storage replication was initially introduced as a solution for increasing file server performance. At the time, bandwidth was in very short supply for branch offices. As such, organizations often deployed DFS as a way to make copies of file data available locally in branch offices, while also synchronizing that data to the main office.

One of the main reasons why DFS hasn’t aged well is because of the way that it replicates data. Some bloggers describe DFS storage replication as a file-level replication solution. Others describe it as a block-level replication engine.

In many ways, both of these viewpoints are correct.

DFS monitors the file system in an effort to detect file modifications or newly created files. If such activities are detected, the DFS replication engine replicates the modified or newly written storage blocks. In other words, even though the DFS replication engine replicates individual storage blocks, those replication operations are tied to activities occurring at the file level.

Because of the way that DFS storage replication works, it cannot replicate open files. This means that there are certain types of files that generally are not replicated because they are almost always open. This can include things like application database files or PST files that are connected to Outlook. (Archived PST files can be replicated without issue because those files are not being held open.)

Another issue with DFS storage replication is that, because DFS replication works at the file level, there are limits to the amount of data that can be replicated. These limits have evolved over time, but Windows Server 2012 R2 and later have the following limits:

At first glance, these limits might seem to be a non-issue. Given the way that data continues to grow, however, these limits could be exceeded rather easily. Just last week, for example, I created a 600 GB video file. That’s more than double the DFS limit.

In contrast, Windows Storage Replica works at the volume level rather than the file level. This means that you don’t have to worry about open files.

In addition, Storage Replica was designed for disaster recovery. While it is true that Storage Replica is not a backup solution per se, replicating storage can help a business keep mission-critical workloads online in the event that a failure impacts the organization’s primary data copy (the data source that is being replicated to the secondary destination).

Finally, it is worth considering the fact that the Windows Server Storage Replica feature is simply newer, and can therefore take advantage of Windows features and capabilities that DFS replication cannot. For example, Storage Replica can leverage thin provisioning, and can leverage technologies such as RoCE, RDMA and InfiniBand.