bunny-lab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md
All checks were successful
GitOps Automatic Deployment / GitOps Automatic Deployment (push) Successful in 9s
Details

Browse Source
This commit is contained in:
Nicole Rappe
2025-10-14 06:44:59 -06:00
parent f854330de7
commit 1c7e6b11a5
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md
View File

@@ -103,8 +103,8 @@ In the Replication wizard that appears after about a minute, you can configure t
* **Next → Next** * **Next → Next**
* **Primary member**: pick the server with the **most up-to-date** copy of the data (e.g., `LAB-FPS-01`). * **Primary member**: pick the server with the **most up-to-date** copy of the data (e.g., `LAB-FPS-01`).
!!! warning "Important" !!! warning "Replication Behavior Explanation"
In DFSR, "Primary member" is used **only for initial sync conflict resolution**. It does **not** permanently dominate, and DFSR will not blindly wipe unique files on other members; conflicts are handled via versioning (e.g., "ConflictAndDeleted"). For large datasets, consider *pre-seeding* to reduce initial replication time via robocopy. When you first create a replication group, DFSR needs a baseline copy of the data to start from. You designate one server as the Primary Member to serve as that baseline. (e.g. `LAB-FPS-01`) During the first sync, DFSR assumes that whatever exists on the primary member's folder is the "truth." So if the same file exists on another server (e.g. `LAB-FPS-02`) but with different timestamps, sizes, or hashes, the primary member's copy wins - but only during this first synchronization. After that initial sync is complete, the "primary" flag loses all authority. Replication becomes multi-master, meaning every member can make changes, and DFSR uses its conflict resolution algorithm (based on version vectors, update sequence numbers, and timestamps) to decide which change wins going forward. In other words, no server remains “the boss” after initialization. Files unique to other member servers that only exist on them will not be wiped and will be replicated across all member servers including the primary member.
* **Topology**: `Full mesh` (good for two servers; for many sites, consider hub-and-spoke). * **Topology**: `Full mesh` (good for two servers; for many sites, consider hub-and-spoke).
* **Replication schedule**: leave **Full** (24x7) unless you need bandwidth windows. * **Replication schedule**: leave **Full** (24x7) unless you need bandwidth windows.