![如何使用连接点而不是驱动器号来组织多个磁盘上的多个共享的 DFS 复制?](https://linux22.com/image/661939/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8%E8%BF%9E%E6%8E%A5%E7%82%B9%E8%80%8C%E4%B8%8D%E6%98%AF%E9%A9%B1%E5%8A%A8%E5%99%A8%E5%8F%B7%E6%9D%A5%E7%BB%84%E7%BB%87%E5%A4%9A%E4%B8%AA%E7%A3%81%E7%9B%98%E4%B8%8A%E7%9A%84%E5%A4%9A%E4%B8%AA%E5%85%B1%E4%BA%AB%E7%9A%84%20DFS%20%E5%A4%8D%E5%88%B6%EF%BC%9F.png)
我正在配置一个将利用命名空间和复制的新 DFS 设置。两个成员服务器是运行 Windows Server 2012 R2 的虚拟机。
由于许多共享的大小从数百 GB 到数 TB 不等,我希望将这些共享存储在它们自己的虚拟磁盘上,而不是为所有共享设置一个大(数十 TB)虚拟磁盘。我希望能够使用连接来创建统一的逻辑结构,而不是为每个磁盘分配一个驱动器号,如下所示,其中每个共享文件夹实际上是指向另一个卷上的文件夹的连接(当然,在每个成员服务器上,相应的卷具有不同的标识符,连接就是原因):
C:\File Shares\
Share1\
===连接点===>\\?\Volume{11111111-1111-1111-1111-111111111111}\File Shares\Share1\
Share2\
===连接点===>\\?\Volume{22222222-2222-2222-2222-222222222222}\File Shares\Share2\
Share3\
===连接点===>\\?\Volume{33333333-3333-3333-3333-333333333333}\File Shares\Share3\
Windows 资源管理器和命令提示符等应用程序可以毫无问题地浏览此结构,我能够从每个C:\File Shares\ShareX
连接点创建共享并毫无问题地访问它们。然而,DFS-R 似乎不喜欢它。使用上述连接点之一创建复制组后,事件日志中会生成事件 6064:
DFS 复制服务无法复制本地路径 C:\File Shares\Share1 处的已复制文件夹,因为本地路径不是现有的、可访问的本地文件夹的完全限定路径名。
我怀疑问题在于 DFS-R 根本不支持使用连接点作为复制文件夹。 DFS 复制:常见问题 (FAQ)指出“连接点也未复制,并且 DFS 复制会为遇到的每个连接点记录事件 4406。”,但这似乎是指复制文件夹包含连接点,而不是复制文件夹是连接点。事实上,如果我将驱动器号X:
、Y:
和分配Z:
给上述卷,那么 DFS-R做使用这些连接点:
C:\File Shares\
Share1\
===连接点===>X:\File Shares\Share1\
Share2\
===连接点===>Y:\File Shares\Share2\
Share3\
===连接点===>Z:\File Shares\Share3\
这很接近我想要的,因为每个共享和复制组都引用一个C:\File Shares\ShareX\
连接点,但每个连接点仍然必须使用驱动器号来定义,如果可能的话,我想把它们从等式中去掉。更令人困惑的是,几周前我能够使用引用没有驱动器号的卷的连接点来复制共享,但现在由于同样的 6064 错误,它不再复制。我不确定它一开始是如何工作的。
有没有人有这种设置的经验?我似乎找不到有关使用 DFS-R 处理没有分配驱动器号的卷的任何信息。除了创建新共享时的一些额外工作外,使用连接来组织复制文件夹是否存在任何陷阱或缺点?