导航：首页 > 服务器 >

微软DFS基础知识及复制原理

发表于：2026-11-01 作者：千家信息网编辑

千家信息网最后更新 2026年11月01日，老王前阵子有幸参与过一个银行的DFS咨询项目，也借机会入门学习下DFS，现将学习到的知识整理出来与大家分享，不对之处欢迎指正DFS是微软Windows Server上面自带的分布式文件共享服务，通过使

千家信息网最后更新 2026年11月01日微软DFS基础知识及复制原理

老王前阵子有幸参与过一个银行的DFS咨询项目，也借机会入门学习下DFS，现将学习到的知识整理出来与大家分享，不对之处欢迎指正

DFS是微软Windows Server上面自带的分布式文件共享服务，通过使用DFS，可以帮助企业通过单一路径就可以访问到所有共享文件夹的内容，同时可以根据客户端登陆位置自动联系就近的服务器，提供文件服务器负载均衡和容错能力。

DFS的主要功能分为两大块为客户端提供统一的入口，实现不同文件服务器文件夹的复制，两大块功能分别由两个组件实现

DFS命名空间：可以安装在单独的成员服务器或域控，命名空间顾名思义，为用户提供一个逻辑的访问路径，例如，企业中有很多台windows共享服务器，很多NAS共享，linux共享，用户需要一个一个记住很不方便，这时候就可以通过命名空间服务器，提供一个统一的访问名称，把企业的共享服务器都发布到这个访问名称下，用户只需要记住这个名称，就可以浏览企业里面所有的共享文件夹

DFS命名空间分为独立命名空间和域命名空间，独立命名空间即单独找一个服务器，以这台服务器的名称作为DFS对外访问，导致的结果就是一个这台服务器宕机，则用户无法访问，但是可以把独立命名空间部署为群集角色以获得AP模式的高可用，另外一种是域命名空间，这种部署模型部署出来之后，用户访问时会是\\domainname\dfsrootname这种方式访问，好处是通过域命名部署，可以把访问名称，命名空间服务器，由命名空间连接到的文件夹，文件夹目标，这些元数据信息都会存放在AD里面，实际上就在活动目录数据库的这个位置一份

CN=,CN=Dfs-Configuration,CN=System,DC=Contoso,DC=Com

这样做了之后，用户的命名空间服务器就可以注册多个，例如可以有两台命名空间服务器，共同支持\\domainname\dfsrootname这个DFS根路径，一旦一台服务器坏了，下次客户端查询时DC会返回给客户端可用的地址，始终确保命名空间的访问可以正常

DFS客户端从DFS命名空间访问文件夹的流程如下

独立根命名空间

客户端输入\\08server1\share\docs 访问请求
客户端DFS client发送一个查询请求，查询\\08server1\share根目标，请求发送至08server1
08server1返回根目标地址
客户端像根目标服务器查询docs目标服务器
根目标服务器根据目标选择算法，为客户端提供文件夹目标列表
客户端向列表第一位文件目标服务器发送请求

域命名空间

客户端输入\\contoso.com\share\docs 访问请求
客户端向DC服务器发送请求查询根目标服务器地址
DC服务器查询AD数据库，返回根目标服务器地址列表
客户端选择第一个根目标，向根服务器发送到文件夹目标的请求
根目标服务器根据目标选择算法，为客户端提供文件夹目标列表
客户端向列表第一位文件目标服务器发送请求

当DC或独立命名空间对客户端返回根目标服务器地址后，默认情况下会被缓存在客户端，独立命名空间为300秒，域命名空间为1800秒，在秒数内不会再次请求根目标服务器地址

通常情况下如果DFS使用量较大，建议单独部署DFS命名空间服务器，如果请求不多，可以和DFS复制服务器放在一起，让DFS复制服务器既承担复制功能，也承担命名空间提供功能

如果只部署一台命名空间服务器，当命名空间服务器宕机后，客户端将无法通过路径范围访问共享，回退至访问单台服务器模型

如果命名空间部署到域控服务器，容易引发访问名称不一致问题，例如，客户端1指向域控1，客户端2指向域控2，域控1部署了命名空间服务器，域控2部署没有部署，那么指向域控2的客户端将没法访问到DFS根目标名称，因此要不然就不选择用域控部署命名空间服务器，要不然就被客户端指向的所有域控都部署命名空间服务器。

DFS的默认目标选择算法如下

1.从同一站点目标服务器随机排列在列表顶部

2.客户外部站点目标按AD站点Cost最低到最高的顺序列出

3.相同Cost的推荐被分组在一起

4.在每个组中目标按随机顺序列出

管理员也可以通过DFS管理单元手动修改目标选择算法，例如修改为最低Cost为首选提供

DFS目标服务器启动时会检测当前DC是否为多站点架构，如果是，我应该归于哪个站点，当客户端对DFS命名空间服务器发送请求时，命名空间会根据上述目标选择算法，为客户端提供经过排序的目标服务器列表

如果都是同站点内，则客户端将随机选择目标服务器

在Windows Server中添加角色和功能时DFS分为两个，一个为DFS命名空间，一个是DFS复制组

在命名空间看来，主要分为命名空间服务器和目标服务器，除了命名空间服务器外，所有的文件夹目标都是目标服务器，你们进入了我的逻辑区域，我会在我的命名空间为你们创建link

复制组的引入，让DFS不仅从一个提供便捷访问的平台，也可以支持文件级别的自动复制容错，通过配置复制组，可以让之间目标服务器相互复制文件夹，以实现容错，引入复制组概念后，每台目标服务器变成一个复制成员服务器，复制组成员服务器仅支持微软windows server，就不支持其它平台了，使用复制组的流程如下

选择要参与复制的目标服务器
选择要目标服务器上要复制的文件夹
选择复制拓扑，集散，交错，或无拓扑，交错即各节点互相复制，集散即各节点之间不复制，都与一个主节点复制，无拓扑即事后配置拓扑
配置复制带宽，复制时间，复制文件筛选器
配置首次复制时主服务器

配置了复制组后，并不会因为配置了复制组而导致只有一个目标服务器提供服务，相反，复制组的所有目标服务器默认都可以对外提供读写功能，例如站点A有目标服务器A，站点B有目标服务器B，两个目标服务器配置了复制，文件夹中的数据会在两个站点间进行同步，站点A客户端访问会是目标服务器A响应，站点B客户端访问会是目标服务器B响应，一旦其中一台服务器宕机，会从命名空间服务器给出的算法中选择下一个目标服务器，如果没有配置复制组的情况下，也是类似的，只不过各自访问各自的文件，没有复制机制。

默认情况下各个复制组成员服务器是多主同步机制，即每个节点都可以修改文件夹数据，2008开始支持配置只读复制组成员，只读复制组成员只可以执行读操作，不能写入。适用于分支机构，不需要写入只要读取的场景

DFS复制组配置好了之后，2008开始走RDC远程压缩算法复制机制，即每次复制仅复制修改过的数据，DFS复制仅支持复制关闭的文件，例如office文件，图片文件等，用户上传完就关闭，不会一直打开的，如果是VHDX或SQL MDF这类始终打开不会被关闭的文件，则不适用DFS，它们始终不会被复制，DFS复制不具备版本控制能力，如果一个文件同时在两方打开，将以关闭文件一方为准。

DFS复制默认情况下使用135端口及RPC动态端口，可通过以下命令固定DFS复制RPC端口

dfsrdiag staticrpc /port:55555 /mem:dfs01

dfsrdiag staticrpc /port:55555 /mem:dfs02

接下来我们再来看下DFS复制的工作机制

涉及到的组件

GUID：DFS复制使用GUID作为标识，每一个复制组，复制文件夹，每个复制组成员，每个复制文件夹卷的DFSR数据库，都将被分配一个GUID

USN Journal日志：DFSR通过NTFS的USN日志监测文件变化，关于USN Journal简单来说，它是一种被定义为NTFS 规范之一的循环日志，NTFS 卷上文件和文件夹的变化，都会向USN日志中追加记录，记录一般包括：文件名，变化时间，变化类型和一个USN唯一更新编号，而实际的数据不会记录，这样也可以保持记录文件足够小，应用程序可以监视此USN日志的以获得NTFS文件系统更新。

NTFS中每一个文件都可以查询到它的USN日志，查询命令如下

fsutil usn readdata c:\usn\123.txt

如果我们对文件进行修改，再次查看USN日志，可以看到，USN编号发生变化，作为NTFS 上的文件ID的"文件参考号"和指示父文件夹的"父文件参考号"没有改变

当DFSR 检测到为复制文件夹中的文件添加了USN 日志时，它会将该文件的更新添加到由 DFSR 管理的数据库

DFSR服务在承载复制文件夹的卷上为每个卷维护一个ESE数据库。DFSR使用此数据库存储有关复制文件夹中每个文件和文件夹的元数据

在DFSR数据库中，以下信息相关联，如果调试日志DFSR 跟踪的复制状态时，这五个编号你会经常看见

o UID

o GVSN

o 文件名称

o NTFS文件ID

o 父文件夹的UID

DFSR 使用UID（唯一标识符）和GVSN（全球版本序列号）两个不同的ID跟踪复制的状态。

UID 基于数据库GUID（复制文件夹所在卷）和当前数据库版本号进行修改而构造，是唯一分配给文件和文件夹的ID ，分配给每个复制文件和复制文件夹，一旦分配，UID 将不会被更改，直到文件或文件夹被删除

GVSN 基于数据库GUID（复制文件夹所在卷）和当前数据库版本号进行修改而构造，分配给每个复制文件和复制文件夹，每次文件或文件夹发生更新，都会分配一个新的GVSN

UID 和GVSN 都采用以下格式编写。

{DB GUID} - 版本

实际的形式如下

{0440DC0A-B3D0-49EC-AD01-B5A236AAF788}-v12

第一半{0440DC0A-B3D0-49EC-AD01-B5A236AAF788} 的部分，是基于复制文件夹所在卷DFSR数据库的GUID ，V12的部分是DFSR已经认识到更新的序列号。通过结合这两个信息，我们可以得到一个唯一的ID。

UID和GVSN只有在文件或文件夹初始化创建时才保持一致，一旦文件或文件夹发生变化，则GVSN改变，UID不变。

实验验证DFS复制时UID GVSN的改变

环境介绍

一台DC，两台DFS server，各自承载DFS命名空间与DFS复制组角色

复制组名称\\oa.com\share\doc

存在于DFS01和DFS02 C盘的doc目录被指定为复制文件夹

当前在DFS01服务器doc目录创建一个cc.txt文件

使用以下命令可以查询出当前DFS复制文件夹的UID与GVSN

wmic /namespace:\\root\microsoftdfs path DfsrIdRecordInfo where "filename like '%cc.txt%'" get * /format:textvaluelist

{8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7} 是DFS01 DFSR数据库GUID ，可以看到在初始化期间UID和GUID保持一致

可以通过DFSRDIAG Guid2name命令看到

dfsrdiag guid2name /RGName:doc /guid:{8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7}

UID GVSN的编号正是由复制文件夹所在卷DFSR数据库+版本号构成

接下来在DFS02编辑修改CC.TXT后再次在DFS02服务器查看UID GVSN，可以看到UID并没有发生改变，但GVSN发生改变

我们再次使用dfsrdiag guid2name 命令检查DB GUID

dfsrdiag guid2name /RGName:doc /guid:{6B8002DE-784B-45AA-B566-9114DC96C959}

可以看到当前复制组GVSN正是DFS02的DFSR数据库，CC.txt最后是在DFS02更新。

DFSR收到GVSN发生变化后，通知其它节点与其更新，通过RDC传输增量数据

如果这时DFS01再次更新内容，则DFS01的DFSR数据库复制组ID将再次变成GVSN，但版本号增加

由此我们可以简单总结下DFS复制的原理，当一个文件或文件夹发生更改操作时，NTFS USN会记录更改，更新USN编号，下次DFS从NTFS查询USN日志时可以看到更新，随即更新成员复制文件夹所在卷的DFSR数据库ID，并将数据库ID更新至DFSR复制组GVSN，DFSR得知文件或文件夹在这个服务器上发生了更改，通知其它节点使用RDC与其进行复制增量内容，并维护各节点DFS版本向量表更新一致。

DFS复制建议，建议通过DFS进行复制的复制文件夹，始终只复制确认下来的结果集数据，举个例子，如果DFS复制目录里面有生产数据还有一个TEMP文件夹，TEMP文件夹会随着开发测试而不断的删除和修改，则DFS目录会因为里面的TEMP目录频繁修改而导致频繁复制，而且如果程序多次重复写入，或频繁从目录删除又添加文件，则该文件会被丢弃至Conflict and Deleted文件夹。

DFS共享文件夹DfsrPrivate目录用途解答

Staging ：DFS复制临时存放文件夹，所有要被复制的文件都会被放置在这个文件夹，再推送给其它节点，建议设置暂存大小尽可能大一些

Conflict and Deleted ：用于处理冲突时被丢弃一方的修改文件，例如一个文件，节点1和节点2同时修改，节点2最后修改，节点2修改的版本作为最新版本生效，节点1修改的版本则被丢弃至该文件夹，复制过程中删除的文件也会被放置在该文件夹下

Deleted：如果在成员身份下取消勾选将删除的文件移动到冲突和删除文件夹，deleted文件夹将生效，再删除的文件会被放置在deleted文件夹

Installing：当文件超过64KB时，并不会直接复制到对方节点上，要被复制的文件会经过RDC计算先放在staging floder，复制发生时首先会被拷贝至对方节点上Installing路径下，之后再放置到正确路径下

PreExisting ：在初始化复制时，例如如果要从DFS01复制到DFS02，DFS02如果复制文件夹中已经存在文件，已存在的会被放置在PreExisting路径下，PreExisting路径中的文件夹不参与DFS复制

DFS监控维护

DFS支持通过CMD，Powershell，WMI，MMC管理，DFS的监控可以从事件管理器-应用程序和服务日志 DFS Replication，性能计数器，SCOM进行基本监控。

更深入的DFS也有类似于windos cluster log的详细排错日志，默认位于C:\Windows\debug目录下

DFS详细日志管理如下

设置：调试日志严重性

默认值：4

范围：1-5

WMIC语法：

wmic / namespace：\\ root \ microsoftdfs path dfsrmachineconfig set debuglogseverity = 5

设置：调试日志消息

默认值：200000

范围：1000到4294967295（FFFFFFFF）

WMIC语法：

wmic / namespace：\\ root \ microsoftdfs path dfsrmachineconfig set maxdebuglogmessages = 500000

设置：调试日志文件

默认值：100

范围：1到10000

WMIC语法：

wmic / namespace：\\ root \ microsoftdfs path dfsrmachineconfig set maxdebuglogfiles = 200

设置：调试日志文件路径

默认值：％windir％\ debug

WMIC语法：

wmic / namespace：\\ root \ microsoftdfs path dfsrmachineconfig set debuglogfilepath ="d：\ dfsrlogs"

注：路径必须手动创建; 如果不是，在服务重启时，将使用缺省值％windir％\ debug。

设置：启用调试日志记录（默认启用调试日志记录）

默认值：TRUE

范围：TRUE或FALSE

WMIC语法：

wmic / namespace：\\ root \ microsoftdfs path dfsrmachineconfig set enabledebuglog = true

下为详细日志中一个受到更新的过程

20180326 09:52:25.365 2612 INCO 4825 InConnection::UpdateProcessed Received Update. updatesLeft:0 processed:1 failures:0 sessionId:3 open:0 updateType:0 processStatus:0 connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc update:

+present 1

+nameConflict 0

+attributes 0x20

+ghostedHeader 0

+data 0

+gvsn {6B8002DE-784B-45AA-B566-9114DC96C959}-v13

+uid {8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7}-v11

+parent {41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}-v1

+fence Default (3)

+clockDecrementedInDirtyShutdown 0

+clock 20180326 01:52:25.258 GMT (0x1d3c4a516a7334d)

+createTime 20180325 13:40:27.685 GMT

+csId {41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

+hash DB24292A-77575CB4-2B878C24-FC62C351

+similarity 00000000-00000000-00000000-00000000

+name CC.txt

20180326 09:52:25.365 2612 INCO 5551 InConnection::CommitSession Connection in sync connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc commitedSessionsWithUpdateFailures:0

20180326 09:52:25.365 2612 IINC 392 IInConnectionCreditManager::ReturnCredits [CREDIT] Credits have been returned. creditsToReturn:1 totalConnectionCreditsGranted:0 totalGlobalCreditsGranted:0 csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} sessionTaskPtr:00000000004BF350

20180326 09:52:25.365 2612 UPMG 427 UpdateWorker::ConsumeUpdates No pending updates. connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csName:doc csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

20180326 09:52:25.365 2140 INCO 8561 InConnection::InConnectionContentSetContext::Hibernate Hibernating: connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

20180326 09:52:25.365 2140 UPMG 580 UpdateManager::FinalizeUpdateManager Finalizing UpdateManager connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csName:doc csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

20180326 09:52:25.381 2040 OUTC 2885 OutConnectionContentSetContext::TransportRequestVvUp Received request for VvUp csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE} rgName:doc ptr:00000000004BEF20

20180326 09:52:25.381 2040 SRTR 2242 SERVER_RequestVersionVector Sent requested version vector. connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} seqNumber:6 requestType:REQUEST_NORMAL_SYNC changeType:all

20180326 09:52:25.381 2040 SRTR 2331 SERVER_AsyncPoll Processing AsyncPoll call. connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE}

20180326 09:52:25.397 2040 SRTR 2331 SERVER_AsyncPoll Processing AsyncPoll call. connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE}

常用参数介绍

参数	描述	当前案例
CSID	复制文件夹GUID	{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}
ConnID	复制链接GUID	{C05077DD-90EF-4059-A695-E5158F8E4DB5}
Parent	复制文件所在文件夹ID	{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}-v1
UID	原始文件记录	{8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7}-v11
GVSN	修改文件记录	{6B8002DE-784B-45AA-B566-9114DC96C959}-v13