In this article, we will talk a little about a very simple and necessary mechanism in every small company today. This is of course the "Distributed File System" (DFS) and Distributed File System Replication Service (DFSR). The replication mechanism, as a built-in solution in the Windows Server OS family, appeared back in 2000 in Windows Server 2000. Since then, the solution has grown very seriously in terms of its functionality and fault tolerance. Today, with just a few clicks, a huge number of parameters are configured with default values that will suit 99% of companies.
This article will literally show the main points for setting up the basic elements of this service. But this mechanism is not exhausted on this, and if you did not know about this service before, then this article is for you.
What types of replication exist
This replication group is created almost automatically when a second target is added to the distributed file system.
An independent replication group is needed in cases where you need not "shared" folders, to simply replicate any folders between two or more different servers.
If everything is clear and simple with the replication of end objects in the namespace, then there is one more feature with independent replication groups, since this group can be created of two types:
A universal replication group is needed for mutual bidirectional replication of files and folders contained in it. Such a group is just used when creating a replication group for the final objects of the namespace.
A data collection replication group is needed to copy all files and folders, say, to a backup server. At the same time, if some files are changed or deleted on the backup server, this will not affect the original object in any way. This functionality is convenient for implementing one-way data exchange, for example, between a protected segment and a DMZ (the solution is not ideal in terms of security!)
A little about the nuances
- When creating a replication group, no matter what type, you can set the data transfer rate by day of the week and hour. This is very useful to reduce network load during business hours. Especially in cases where the company has many branches in different cities and / or countries.
- The service is extremely stable and, in the vast majority of failures, recovers itself and continues to work correctly. Even if the server crashes.
- A replicated folder cannot use databases (of any type) because replicas are transferred not by sector, but by files. For example, DBase, MS Access, and MS Excel file sharing are not allowed.
- If you use the same write replica in different cities/countries and people frequently modify the same file, a collision may occur. And it turns out that at the same time in two branches the same file was modified by two people. Then the DFSR service will place the latest version of the file on both replicas, and move the conflicting file to the folder “[Drive]:\[ReplicationFolder]\DfsrPrivate\ConflictAndDelete” and write information about the file to the configuration file “[Drive]:\[ReplicationFolder]\DfsrPrivate \ConflictAndDeletedManifest.xml".
- The "ConflictAndDeleted" folder has a 4GB limit by default. You can change this limit.
- Intermediate storage has a default limit of 4 GB. If you or users upload a larger file, this file will not be able to replicate, but DFSR will endlessly try to copy it. If you expect users to do this, immediately change the storage limit up.