Are you looking for a robust Windows Server backup solution? Try Vinchin Backup & Recovery!↘ Download Free Trial Distributed File System (DFS) makes it easier for users to access and manage files that are physically distributed across a network. DFS provides a single access point and a logical structure for the file system. With DFS, users can access files without needing to know their actual physical locations. DFS allows organizing shared folders from different computers within the same network into a unified, logical, hierarchical shared file system.
What is DFS?
DFS, an inherent distributed file sharing service on Microsoft Windows Server, facilitates enterprises in accessing the contents of shared folders through a singular pathway. Additionally, it establishes automatic connections to nearby servers based on client login locations, thereby bestowing load balancing and fault tolerance capabilities upon file servers.
The primary functionalities of DFS can be classified into two categories: provisioning a unified entry point for clients and accomplishing folder replication across diverse file servers. These two facets are implemented by two distinct components.
What is a DFS namespace?
A DFS namespace can be installed on a standalone member server or domain controller. As the name suggests, a namespace provides users with a logical access path. For instance, in an enterprise with multiple Windows shared servers, NAS shares, and Linux shares, it becomes inconvenient for users to remember each one individually. In such cases, a namespace server can be used to provide a unified access name, consolidating all the enterprise shared servers under this name. Users only need to remember this name to browse through all the shared folders within the organization.
A DFS namespace can be divided into a standalone namespace and a domain-based namespace.
A standalone namespace refers to using a dedicated server as the access point for DFS, where the server's name is used for external DFS access. The consequence of this setup is that if the server goes down, users won't be able to access it. However, it is possible to deploy the standalone namespace as a cluster role to achieve high availability in an active-passive mode.
The other deployment model is called a domain-based namespace. In this deployment model, when users access the DFS, they use the format domainnamedfsrootname. The benefit of deploying a domain-based namespace is that it allows the access name, namespace servers, target folders connected to the namespace, and other metadata information to be stored in Active Directory. By storing this metadata in Active Directory, multiple namespace servers can be registered for the same DFS root path. For example, there can be two namespace servers that jointly support the DFS root path domainnamedfsrootname. If one server becomes unavailable, the domain controller will return the client with the available address during the next client query, ensuring continuous access to the namespace.
What is DFS replication group?
When adding roles and features in Windows Server, DFS is divided into two components: DFS Namespace and DFS Replication Group.
The introduction of replication groups in DFS allows it to not only serve as a platform for convenient access but also support file-level automatic replication and fault tolerance. By configuring replication group, it allows the target servers to replicate folders among themselves to achieve fault tolerance.
The process of using a replication group is as follows:
Select target servers to participate in replication
Select the folders to copy on the target server
Select the replication topology, hub-distributor, interleaved, or no topology.
Configure replication bandwidth, replication time, replication file filters
Configuring the primary server for first replication
Configuring a replication group does not result in only one target server providing services. On the contrary, all target servers in the replication group can offer both read and write functionality. By default, each member server in the replication group operates on a multi-master synchronization mechanism, which means that each node can modify folder data. Starting from Windows Server 2008, it is possible to configure read-only replication group members, which is suitable for branch offices or scenarios where only read access is required, without the need for write access.
Note: DFS replication uses port 135 and RPC dynamic port by default. You can use the following command to fix the DFS replication RPC port:
dfsrdiag staticrpc /port:55555 /mem:dfs01
dfsrdiag staticrpc /port:55555 /mem:dfs02
How does DFS replication work?
Before learning about its working mechanism, here are components involved in it.
GUID (Globally Unique Identifier): DFS replication uses GUIDs to identify various components. Each replication group, replicated folder, replication group member, and replication folder volume is assigned a unique GUID.
USN Journal: DFSR (DFS Replication) monitors file changes using the USN (Update Sequence Number) journal of the NTFS. The USN journal is a circular log defined as part of the NTFS specification. Whenever a file or folder on an NTFS volume changes, a record is appended to the USN journal. The record typically includes the file name, change time, change type, and a unique update sequence number. The actual data is not recorded in the log, which helps keep the log file size manageable. Applications can monitor this USN journal to obtain updates on changes made to the NTFS file system.
In NTFS, it is possible to query the USN log for each file. The command is as follows:
fsutil usn readdata c:usn123.txt
When DFSR detects that a file in a replicated folder has added USN logs, it adds the updates of that file to the database managed by DFSR.
The DFSR service maintains an ESE database for each volume hosting a replicated folder. The ESE database is used by DFSR to store metadata about each file and folder within the replicated folder.
In the DFSR database, you may frequently encounter these five identifiers when debugging DFSR replication status:
UID
GVSN
File Name
NTFS File ID
Parent Folder UID
DFSR uses two different identifiers, UID and GVSN, to track the replication status.
UID is constructed based on the database GUID and the current database version number. It is a unique ID assigned to each file and folder within the replication database. Once assigned, the UID remains unchanged until the file or folder is deleted.
GVSN is also constructed based on the database GUID and the current database version number. It is assigned to each replicated file and folder. Every time a file or folder is updated, a new GVSN is assigned.
Therefore, the principle of DFS Replication can be summarized as follows:
When a file or folder undergoes a change, the NTFS USN records the change and updates the USN number. The DFS queries the USN journal from NTFS to see the updates. It then updates the DFSR database ID of the replication volume and updates the database ID to DFSR group GVSN. DFSR knows that the file or folder has changed on this server and notifies other nodes to replicate the incremental content using RDC, while maintaining the consistent update of the DFS version vector table of each node.
DFS replication suggestion: It is recommended to only replicate the confirmed result set data through DFS.
For example, if the DFS replicated directory contains production data as well as a TEMP folder that is constantly being deleted and modified during development and testing, the DFS directory will experience frequent replication due to the frequent modifications in the TEMP folder. Additionally, if a file is repeatedly overwritten or frequently added and removed from the directory, the file will be discarded to the Conflict and Deleted folder.
Protecting your Windows Server with a professional solution
It is not recommended to perform system cloning on DFS. However, it is recommended to use standard backup solutions to perform disk backup or bare metal backup of the DFS server.
Also, you can use Vinchin Backup & Recovery to protect data stored on your physical Windows Server machines.
Vinchin Backup & Recovery is a professional enterprise backup and disaster recovery solution, supporting backing up Windows/Linux server (like Windows 2022/2019/2016/2012/2012 R2/2008/2008 R2/2003/ 2003 R2), virtual machine, file server, NAS (from all brands), database, etc. providing easy protection for complex IT environment.
Vinchin’ s physical server backup solution utilizes VSS (Volume Shadow Copy Service) technique for Windows Server Backup to take application-aware snapshots of NTFS volumes, while a self-developed snapshot technique is also built in for Linux server users to guarantee the consistency of backup data.
A user-friendly web console will help easily perform bare metal backup and restore on Windows server. To backup your Windows server, just follow the steps below:
Select the Windows server > select the backup destination > select backup strategies > submit the job
Vinchin Backup & Recovery has been selected by thousands of companies and you can also start to use this powerful system with a 60-day full-featured trial! Also, contact us and leave your needs, and then you will receive a solution according to your IT environment.
Conclusion
DFS replication is a feature in Windows Server that enables the replication of files and folders between multiple servers in a distributed file system environment. It provides data redundancy, availability, and scalability by maintaining synchronized copies of files across different locations.
Vinchin Backup & Recovery is also an excellent solution for bare metal backup and recovery and provides more advanced features than Windows Server Backup so don’t miss the free trial.
