我们正在将带有 2.7TB NTFS 文件的本地 Windows 文件服务器迁移到 Azure（我们有 100 mb/s VPN 站点到站点连接到 Azure）
人们会推荐什么最好的方式来传输我们的文件，同时保持 NTFS 权限不变？
我们可以在文件服务器上重新创建大约 20 个网络共享，但不想重新创建 300 多个用户的 NTFS 目录权限。
我们创建了一个 Azure 服务器并在本地服务器（一个 2008R2 Windows Server，在 VMware 中虚拟化了 3 个驱动器）之间设置了 DFS 文件复制，但是我们在让它工作时遇到了问题，它适用于少量文件但不起作用他们都。
有没有人使用 ez copy 或 Azure 导出服务（向 Azure 发送硬盘）这些方法中的任何一种都可以保持 NTFS 权限不变吗？
我们目前有两个 6 岁的 linux 文件服务器（HP DL320 和 DL380），它们开始成为狗。DL320只使用RAID1中设置的10K IDE驱动器，360使用RAID10中设置的6个驱动器。文件服务通过 Samba，而 DL320 目前有更多的问题。
我们打算迁移到 Windows Server 2003（2008 将不支持我们旧的 Win98 工作站 - 当我们的旧软件被转换时，我们无法再摆脱它们 3 年）。但是，我想知道购买 SAN 而不是购买具有更快驱动器的更新机器是否更有意义？
我们的规格
有什么想法吗？
windows windows-server-2003 storage-area-network file-server samba
我们目前使用 2 个带有 DFS 的 Windows 2008 R2，但发现了一些问题：
这些问题是否存在于集群中？意思是，如果我们在成员集群中的文件夹上设置权限/配额，该集群的所有成员都会继承权限/配额吗？我们将拥有一台专用服务器 (HP P4300 Lefthand)，我们也计划将其用于文件服务器。所以，我们的选择是：DFS 或故障转移集群。
我几乎没有发现有关 Server 2012 的此错误的信息。关于 Server 2003 的此错误的大量信息以及 Microsoft 的更新包修复程序以及有关如何解决 Server 2008 的错误的说明和 2008 R2，但 2012 没有。
在安装文件系统资源管理器 (FSRM) 角色后，在 Server 2012 和 Server 2012 R2（版本无关紧要）上发生错误：
Event ID 8197
Source: SRMSVC
File Server Resource Manger Service error: Unexpected error.
Error-specific details:
Error: GetVolumeNameForVolumeMountPoint, 0x800700001, incorrect function
每次重启时以及服务重启后（特别是服务启动后 30 秒）也会出现此错误。此错误发生在两台戴尔服务器上：PowerEdge R720 和 PowerEdge R620。
我发现的第一件事是，这只发生在使用 UEFI 时。服务器使用标准 BIOS 时没有错误。我本可以停在那里并坚持使用 BIOS，但我不想失去 UEFI 和 server 2012 的任何新功能。
最初，我认为这是戴尔 UEFI 实施的问题，因为它发生在我的新服务器以及运行在戴尔 PowerEdge ESX 主机上的虚拟机中。但是，我能够使用在非戴尔硬件上运行的另一个 VM 重现此错误。这意味着问题出在 Microsoft 上。在 UEFI 上的 Server 2008 …
我们目前正在为 Windows 文件服务器实施 DR 策略。我们已经排除了存储复制，因为它是一项预览功能，而故障转移群集旨在实现高可用性，而不是灾难恢复。DFSR 在复制打开/锁定的文件方面也存在缺陷，使其不适合该任务。
文件服务器虚拟机的 SAN 到 SAN 复制对我来说似乎是最好的方法，尽管我被警告不要这样做，因为复制是未在更高级别合并的原始副本，可能会导致不一致文件系统或损坏的文件。然而，这个事实适用于以这种方法复制的任何服务器，而且我们的 DR 计划中的其他服务器也使用这种方法。VSS/以前的版本也可以始终用于恢复任何损坏的文件。
进行 SAN 复制的好处是否大于文件损坏的风险？或者有没有更好的方法为文件服务器做 DR？也许有一种产品可以执行更高级别的复制/快照，以最大限度地减少数据中的逻辑不一致？
注意：集群运行的是 vSphere 5.5
我计划将文件共享从 Windows Server 2003 迁移到 Server 2012 R2（它有超过 500 GB 的数据。仅供参考 - 它没有 DFS）。
我想到使用以下命令将数据从源服务器复制到目标服务器：
robocopy "\\Source server\folder\" "\\Target server\folder\" /S /E /COPY:DATSOU /R:1 /W:10 /TEE /log:<log path.txt>
在切换期间，我计划再次运行相同的命令来复制任何新的/修改过的文件。
上述命令是否有任何问题，我是否需要在切换期间包含“/XO”以排除再次复制现有文件？
windows-server-2003 file-server robocopy windows-server-2012
我希望将我们的 DFS-R 文件服务器移动到 SoFS，以适应 Windows Server 2012 R2 远程桌面服务中的用户配置文件磁盘。
DFS-R 不给我们任何故障转移能力，所以如果我们失去主文件服务器，用户的配置文件将被卸载。
我打算在VMware中创建两个节点作为VM，并且需要一个共享存储的解决方案。我们的 VMware 集群在我们的 SAN 上有数据存储，所以我想知道我是否可以在 VMware 级别使用共享 VMDK 来处理这种情况？如果这是可能的，任何人都可以向我指出有关如何以这种方式配置共享存储的一组很好的说明吗？
在这种情况下，共享存储有什么注意事项吗？
有没有人之前在 VMware 上创建了 SoFS 设置并有任何可能有用的建议？
我计划在不久的将来在我们公司的一个部门部署一个文件服务器。最好它应该支持通过 SMB 和 NFS 的文件级访问，此外，iSCSI 支持将是一个加分项。内置备份/复制功能也将是一个很好的加分项。
我的 homelab 目前有一台物理服务器，稍后将用于生产，因此我围绕它建立了一个测试实验室。另外，如有必要，我可以从我的公司再借一台服务器。我已经对这个主题进行了简短的研究，并在存储空间之上的 FreeNAS 和 Windows 文件服务器之间进行了选择作为可能的候选者。
我已经测试过 FreeNAS，但性能不佳。由于某种原因，我最多只能做到 250 MBps。我的服务器中有 Intel 10GbE NIC，以及 2x E5-2603 v3 和 96GB 内存。Zpool 是具有 LSI MegaRAID 2208 和 JBOD 模式的 RAIDZ2 – 9 驱动器。也许我在配置中犯了一些错误，因为我不是 Linux 专家，所以我会尝试在那里测试存储空间。
有没有其他可行的免费/低成本文件服务器解决方案？我的目标是构建最具成本效益的解决方案来进行测试，然后将其投入生产。我之前的 FreeNAS 设置是否存在硬件配置错误？
非常感谢！
我正在设计一个基于 ZFS 的文件服务器，我正在考虑在 RAID 1 中使用 USB 闪存驱动器作为引导设备。似乎很少有人这样做，我想知道为什么。据我所知，使用 USB 闪存驱动器有一些好处：
许多服务器都有一个内部 USB 端口，可以从内部和外部端口启动。
关于 MLC 闪存如何限制在 10k-100k 写入周期并且可能不够可靠的评论肯定会出现。我不太关心这个，但也许我应该关心。文件服务器不经常写入操作系统磁盘，仅用于日志等。Super Talent 的闪存驱动器的额定写入周期为 100k。在 RAID 1 中使用两个并且可能在设置 3 年后更换其中一个仍然比替代方案便宜，我相信足够可靠。使用 ZFS，可以快速检测到写入错误。
那么为什么这并不常见呢？
我有一项任务是将 SOFS 共享移动到 FS，通常用于集群服务器。不幸的是，我不是 Windows Server 的专家。有人做这个任务吗？我想得到帮助并逐步重新配置它。这个想法是删除 SOFS 共享并创建同名的 FS 共享。附加放置 SOFS 共享的磁盘。但是重新配置后如何处理此共享的权限？
提前感谢您的提示。
附加信息：我已经测试了从 SOFS 到 FS 的一些时刻。1. 为文件服务器集群的虚拟机创建新的小磁盘（1G），并附加它。初始化它没有任何字母 2。将此磁盘添加到故障转移群集管理器的磁盘并将其添加到群集共享卷（它分配给群集共享卷）。3. 创建了作为横向扩展文件服务器的新角色 4. 使用新磁盘创建了经过测试的 3 个共享。5. 在每个共享中放置一些文件夹和文件。6. 删除了这个角色 7. 从集群共享卷中删除了磁盘（磁盘获得了可用存储状态） 8. 为其分配了一个驱动器号 9. 从 AD 中删除了旧名称 10. 创建了作为 FS 的新角色，与原来的名称相同用于 SOFS 和附加的测试磁盘 11. 使用键入自定义路径 - 从旧共享中选择需要，为 SOFS 创建与以前相同名称的新 SMB 共享。似乎文件夹和文件的所有 NTFS 权限仍然存在，但我不是绝对舒尔（试图检查它）。共享权限也可能存在，但我不完全确定。这就是为什么我之前问过如何获得所有权限并在角色更改后实施它们？
最好的问候，维克多