你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用 DataBox 从网络附加存储 (NAS) 迁移到 Azure 文件共享
本迁移文章是涉及到“NAS”和“Azure DataBox”关键字的几篇文章中的一篇。 请检查本文是否适用于你的场景：
- 数据源：网络连接存储 (NAS)
- 迁移路线：NAS ⇒ DataBox ⇒ Azure 文件共享
- 不在本地缓存文件：由于最终目标是直接在云中使用 Azure 文件共享，因此没有使用 Azure 文件同步的计划。
如果你的场景与此不同，请参阅迁移指南表。
本文指导你完成一个端到端的过程，其中包括从 NAS 设备迁移到正常运行的 Azure 文件共享所需进行的规划、部署和网络配置。 本指南使用 Azure DataBox 进行批量数据传输（脱机数据传输）。
适用于
| 文件共享类型 | SMB | NFS |
|---|---|---|
| 标准文件共享 (GPv2)、LRS/ZRS |  |
 |
| 标准文件共享 (GPv2)、GRS/GZRS | |
|
| 高级文件共享 (FileStorage)、LRS/ZRS | |
|
迁移目标
目标是将 NAS 设备上的共享迁移到 Azure，并使其成为原生 Azure 文件共享。 无需 Windows Server 即可使用原生 Azure 文件共享。 在执行这种迁移时，需要保证生产数据的完整性以及迁移期间的可用性。 要满足后一项要求，需将停机时间尽量缩短，使之不会超过或者只略微超过例行维护时段。
迁移概述
迁移过程包括多个阶段。 你需要部署 Azure 存储帐户和文件共享并配置网络。 然后，你将使用 Azure DataBox 和 RoboCopy 迁移文件，以与更改保持同步。 最后，将用户和应用切换到新创建的 Azure 文件共享。 以下各部分详细介绍了迁移过程的各个阶段。
提示
如果你返回到本文，请使用右侧的导航栏转到你离开的迁移阶段。
第 1 阶段：确定需要多少个 Azure 文件共享
在此步骤中，你将决定需要多少个 Azure 文件共享。 卷上可能有更多文件夹当前作为 SMB 共享在本地共享给用户和应用。 根据要迁移到云的文件共享的数量，可以选择使用 1:1 映射或共享分组。
使用 1:1 映射
如果共享数目够小，建议使用 1:1 映射。 描述此场景的最简单方法是设想 1:1 映射到 Azure 文件共享的本地共享。
使用共享分组
如果有大量的文件共享，请考虑使用共享分组。 例如，如果人力资源 (HR) 部门有 15 个共享，则可以考虑将所有 HR 数据存储在一个 Azure 文件共享中。 这样，这组本地共享便只需要云中的单个 Azure 文件共享。
第 2 阶段：部署 Azure 存储资源
在此阶段，我们将预配 Azure 存储帐户和其中的文件共享。
请记住，Azure 文件共享部署在云中的 Azure 存储帐户中。 对于标准文件共享，这样安排会使存储帐户成为 IOPS 和吞吐量等性能数字的缩放目标。 如果将多个文件共享放置在单个存储帐户中，则会为这些共享创建一个包含 IOPS 和吞吐量的共享池。
通常情况下，如果你有存档共享或预计文件共享的日常活跃度较低，可将多个 Azure 文件共享加入同一存储帐户。 但是，如果共享的活跃度很高（共享由多个用户和/或应用程序使用），则需要在部署存储帐户时使每个帐户都有一个文件共享。 这些限制不适用于 FileStorage（高级）存储帐户，此类存储帐户为每个共享显式预配并保证性能。
注意
每个 Azure 区域的每个订阅的存储帐户限制为 250 个。 增加配额后，每个区域最多可以创建 500 个存储帐户。 有关详细信息，请参阅增加 Azure 存储帐户配额。
部署存储帐户时，另一个要考虑的问题是冗余。 请参阅 Azure 文件存储冗余。
默认创建具有 5 TiB 限制的 Azure 文件共享。 如果需要更多容量，可以创建大型文件共享（高达 100 TiB）。 但是，该共享只能使用本地冗余存储或区域冗余存储冗余选项。 使用 100 TiB 的文件共享之前，应考虑自己的存储冗余需求。
如果你已创建共享列表，则应将每个共享映射到创建它时所在的存储帐户。
资源的名称也很重要。 例如，如果将 HR 部门的多个共享归入一个 Azure 存储帐户中，则应适当地命名存储帐户。 同样，命名 Azure 文件共享时，应使用与本地对应项所用名称类似的名称。
现在，请按照创建 SMB 文件共享中的说明部署相应数量的 Azure 存储帐户，并在其中部署相应数量的 Azure 文件共享。 在大多数情况下，需要确保每个存储帐户的区域相同。
第 3 阶段：确定需要多少台 Azure DataBox 设备
只有在完成上一阶段后，才应开始此步骤。 此时应创建 Azure 存储资源（存储帐户和文件共享）。 在订购 DataBox 时，你需要指定 DataBox 将数据移动到哪些存储帐户。
在此阶段中，你需要将上一阶段中迁移计划的结果映射到可用 DataBox 选项的各种限制。 这些考虑事项将帮助你针对将你的 NAS 共享移动到 Azure 文件共享时应选择哪些 DataBox 选项以及需要多少台这种设备而进行规划。
若要确定你需要哪种类型的设备以及需要多少台，请考虑以下重要限制：
- 任何 Azure DataBox 都可以将数据移动到最多 10 个存储帐户中。
- 每个 DataBox 选项都有其各自的可用容量。 请参阅 DataBox 选项。
有关你决定创建的存储帐户的数量以及每个帐户中的共享数量，请查阅你的迁移计划。 然后，查看 NAS 上每个共享的大小。 通过组合使用这些信息，你可以进行优化并决定哪台设备应当将数据发送到哪些存储帐户。 你可以让两台 DataBox 设备将文件移动到同一存储帐户中，但不要将单个文件共享的内容拆分到 2 台 DataBox 中。
DataBox 选项
对于标准迁移，应当选择以下两个 DataBox 选项中的其一或两者的组合：
- DataBox：这是最常用的选项。 将向你寄送一台加固型 DataBox 设备，该设备的工作方式类似于 NAS。 它的可用容量为 80 TiB。 有关详细信息，请参阅 DataBox 文档。
- DataBox Heavy：此选项提供一台带轮子的加固型 DataBox 设备，其工作方式类似于 NAS，容量为 1 PiB。 由于加密和文件系统开销，可用容量大约少 20%。 有关详细信息，请参阅 DataBox Heavy 文档。
警告
不建议将 Data Box Disk 迁移到 Azure 文件共享中。 Data Box Disk 不保留文件元数据，例如访问权限 (ACL) 和其他属性。
第 4 阶段：预配临时 Windows Server
在等待 Azure DataBox 到货的过程中，可以先部署一个或多个 Windows Server，用于运行 RoboCopy 作业。
- 这些服务器的第一项用途是将文件复制到 DataBox。
- 这些服务器的第二项用途是，当 DataBox 仍在运输途中时，与 NAS 设备上发生的更改保持同步。 此方法可以最大程度地减少源端的停机时间。
RoboCopy 作业的工作速度主要取决于以下因素：
- 源和目标存储上的 IOPS
- 两者之间的可用网络带宽 在“故障排除”部分可以找到更多详细信息：IOPS 和带宽注意事项
- 可以快速处理命名空间中的文件和文件夹 在“故障排除”部分可以找到更多详细信息：处理快速
- RoboCopy 运行之间的更改次数 在“故障排除”部分可以找到更多详细信息：避免不必要的工作
在确定要提供给临时 Windows Server 的 RAM 和线程计数时，请务必注意引用的详细信息。
第 5 阶段：准备使用 Azure 文件共享
为了节省时间，应在等待 DataBox 到货的过程中处理此阶段。 使用此阶段中的信息，可以决定如何使 Azure 内部和外部的服务器与用户能够利用你的 Azure 文件共享。 最关键的决策是：
- 网络：使网络能够路由 SMB 流量。
- 身份验证：配置 Azure 存储帐户以进行 Kerberos 身份验证。 为存储帐户配置 AdConnect 和域加入可使你的应用和用户能够使用其 AD 标识进行身份验证
- 授权：针对每个 Azure 文件共享的共享级 ACL 将允许 AD 用户和组访问给定的共享；在 Azure 文件共享中，本机 NTFS ACL 将接管控制权。 然后，基于文件和文件夹 ACL 的授权将发挥作用，就像对本地 SMB 共享一样。
- 业务连续性：将 Azure 文件共享集成到现有环境通常需要保留现有的共享地址。 如果你尚未使用 DFS-Namespaces，请考虑在环境中建立该服务。 可将用户和脚本使用的共享地址保持不变。 你将使用 DFS-N 作为 SMB 的命名空间路由服务，方法是在迁移后将 DFS 命名空间目标重定向到 Azure 文件共享。
此视频是有关如何通过五个简单步骤将 Azure 文件共享直接安全地公开给信息工作者和应用的指南和演示。 该视频引用了以下主题的专用文档。 请注意，Azure Active Directory 现已更名为 Microsoft Entra ID。 有关详细信息，请参阅 Azure AD 的新名称。
第 6 阶段：将文件复制到 DataBox
当 DataBox 到达时，需要设置 DataBox 以建立与 NAS 设备的无障碍网络连接。 请按照你订购的 DataBox 类型的安装文档进行操作。
可能会有可供你使用的 DataBox 复制工具，具体取决于你的 DataBox 类型。 此时，不建议使用它们迁移到 Azure 文件共享，因为它们不能完全保真地将文件复制到 DataBox。 请改用 RoboCopy。
当你的 DataBox 到达时，它已预先预配了可供在订购时指定的每个存储帐户使用的 SMB 共享。
- 如果你的文件进入高级 Azure 文件共享，则每个高级“文件存储”存储帐户都将有一个 SMB 共享。
- 如果文件进入标准存储帐户，则每个标准（GPv1 和 GPv2）存储帐户都将有三个 SMB 共享。 只有以
_AzFiles结尾的文件共享才适用于你的迁移。 请忽略任何块和页 blob 共享。
按照 Azure DataBox 文档中的步骤进行操作：
- 连接到 Data Box
- 将数据复制到 Data Box
- 准备你的 DataBox 以发往 Azure
链接的 DataBox 文档指定了一个 RoboCopy 命令。 但是，该命令不适合于保持文件和文件夹的完全保真度。 请改用以下命令：
Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>
- 若要详细了解各个 RoboCopy 标志的详细信息，请查看即将发布的 RoboCopy 部分中的表格。
- 若要详细了解如何适当调整线程计数
/MT:n、优化 RoboCopy 的速度，并使 RoboCopy 成为数据中心内良好兼容的工具，请查看 RoboCopy 故障排除部分。
提示
作为 Robocopy 的替代方法，Data Box 已创建数据复制服务。 可以使用此服务将文件完全保真地加载到 Data Box 中。 遵循此数据复制服务教程，并确保设置正确的 Azure 文件共享目标。
第 7 阶段：在 NAS 中运行 RoboCopy 进行同步
在 DataBox 报告所有文件和文件夹都已放入计划的 Azure 文件共享后，你可以继续处理此阶段。 仅当 NAS 上的数据自 DataBox 复制启动以来可能已更改时，才需要运行 RoboCopy 进行同步。 在某些情况下当你出于存档目的使用某个共享时，你也许可以在 NAS 上停止对该共享进行更改，直到迁移完成。 也许还可以在迁移期间将 NAS 共享设置为只读，以此满足业务要求。
如果在迁移期间需要使共享可读/写，并且你只能承受很短的停机时间，那么，在将用户访问直接故障转移到 Azure 文件共享之前完成此 RoboCopy 同步步骤就很重要。
在此步骤中，你将运行 RoboCopy 作业，向你的云共享追加自从在 DataBox 上创建共享内容分支以来 NAS 上的最新更改。 此 RoboCopy 追加可能会快速完成，也可能会花费一段时间，具体取决于你的 NAS 共享上发生的数据变动量。
运行首次本地复制，以复制到 Windows Server 目标文件夹：
- 标识 NAS 设备上的第一个位置。
- 标识匹配的 Azure 文件共享。
- 在临时 Windows Server 上将 Azure 文件共享装载为本地网络驱动器
- 如前所述开始使用 RoboCopy 进行复制
装载 Azure 文件共享
在可以使用 RoboCopy 之前，需要使 Azure 文件共享可供通过 SMB 访问。 最简单的方法是将共享作为本地网络驱动器装载到计划用于 RoboCopy 的 Windows Server。
重要
在可以将 Azure 文件共享成功装载到本地 Windows Server 之前，需已完成“阶段：准备使用 Azure 文件共享”！
准备就绪后，查看在 Windows 中使用 Azure 文件共享操作指南文章，并装载要对其启动 NAS RoboCopy 同步的 Azure 文件共享。
RoboCopy
以下 RoboCopy 命令仅将差异内容（更新的文件和文件夹）从 NAS 存储复制到 Azure 文件共享。
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
| 开关 | 含义 |
|---|---|
/MT:n |
允许 Robocopy 以多线程方式运行。 n 的默认值为 8。 最大线程数为 128 个。 尽管较高的线程计数有助于使可用带宽饱和，但并不意味着线程越多，迁移就越快。 对 Azure 文件存储的测试表明，在 8 和 20 之间会体现出初始复制运行的均衡性能。 后续的 /MIR 运行会逐步受到可用计算与可用网络带宽的影响。 对于后续的运行，请让你的线程计数值尽量与处理器核心计数和每个核心的线程计数匹配。 考虑是否需要为生产服务器可能具有的其他任务预留核心。 通过 Azure 文件存储进行的测试表明，线程多达 64 个也可以获得良好的性能，但前提是处理器可以同时使它们保持活动状态。 |
/R:n |
第一次尝试复制失败的文件的最大重试计数。 在运行中文件复制永久失败之前，Robocopy 会尝试 n 次。 你可以优化运行的性能：如果你认为是超时问题导致了过去的失败，请选择值 2 或 3。 这在 WAN 链接上可能更常见。 如果你认为文件复制失败是因为它正在被使用，请选择“不重试”或值 1。 如果在几秒钟后重试，可能没有足够的时间让文件的使用中状态发生变化。 使文件保持打开状态的用户或应用可能需要数小时的时间。 在这种情况下，接受文件未能复制，然后在计划的一次后续 Robocopy 运行中捕获该文件，最终可能会成功复制文件。 这有助于使当前运行更快完成，而不会因多次重试而延长，最终在超过重试超时时间之后，由于文件仍处于打开状态而导致大量复制失败。 |
/W:n |
指定在尝试复制上一次复制尝试未成功的文件之前 Robocopy 等待的时间。 n 是两次重试之间的等待间隔（秒）。 /W:n 通常与 /R:n 一起使用。 |
/B |
在备份应用程序会使用的同一模式下运行 Robocopy。 此开关允许 Robocopy 移动当前用户无权访问的文件。 备份开关依赖于在管理员提升控制台或 PowerShell 窗口中运行 Robocopy 命令。 如果对 Azure 文件存储使用 Robocopy，请确保使用存储帐户访问密钥与域标识装载 Azure 文件共享。 如果不这样做，错误消息可能不会直观地引导你解决问题。 |
/MIR |
（将源镜像映射到目标）使 Robocpy 只复制源和目标之间的增量。 将复制空子目录。 将复制目标上已更改或不存在的项（文件或文件夹）。 将从目标上清除（删除）目标上存在但源上没有的项。 使用此开关时，要使源和目标文件夹结构完全匹配。 “匹配”表示从正确的源和文件夹级别复制到目标上的匹配文件夹级别。 只有这样，才能成功完成“追赶”复制。 当源和目标不匹配时，使用 /MIR 将导致大规模删除和重新复制。 |
/IT |
确保在某些镜像方案中保留保真度。 例如，如果在两个 RoboCopy 运行之间，文件遇到 ACL 更改和属性更新的情况，它将被标记为“隐藏”。 如果没有 /IT，RoboCopy 可能会遗漏 ACL 更改，并且不会将其传输到目标位置。 |
/COPY:[copyflags] |
文件副本的保真度。 默认值：/COPY:DAT。 复制标志：D= 数据，A= 属性，T= 时间戳，S= 安全性 = NTFS ACL，O= 所有者信息，U= 审核信息D。 审核信息无法存储在 Azure 文件共享中。 |
/DCOPY:[copyflags] |
目录副本的保真度。 默认值：/DCOPY:DA。 复制标记：D = 数据，A = 属性，T = 时间戳。 |
/NP |
指定不显示每个文件和文件夹的复制进度。 显示进度会明显降低复制性能。 |
/NFL |
指定不记录文件名。 提高复制性能。 |
/NDL |
指定不记录目录名。 提高复制性能。 |
/XD |
指定要排除的目录。 在卷的根目录上运行 Robocopy 时，请考虑排除隐藏的 System Volume Information 文件夹。 如果根据设计使用了它，其中的所有信息都特定于此确切系统上的确切卷，并且可按需重新生成。 复制此信息在云中或者将数据复制回另一个 Windows 卷时不会有任何帮助。 留下此内容不应被视为数据丢失。 |
/UNILOG:<file name> |
将状态以 Unicode 形式写入日志文件。 （覆盖现有日志。） |
/L |
仅适用于测试运行仅列出文件。 它们不会被复制，也不会被删除，并且也不会有时间戳。 通常与 /TEE 配合使用以获得控制台输出。 可能需要删除示例脚本中的标志（例如 /NP、/NFL 和 /NDL），才能正确记录测试结果。 |
/Z |
谨慎使用在重启模式下复制文件。 只有在不稳定的网络环境下，才建议使用此开关。 由于额外的日志记录，此开关会明显降低复制性能。 |
/ZB |
谨慎使用使用重启模式。 如果访问被拒绝，此选项将使用备份模式。 由于检查点，此选项会明显降低复制性能。 |
重要
建议使用 Windows Server 2022。 使用 Windows Server 2019 时，请确保使用最新的修补程序级别或者至少安装了 OS 更新 KB5005103。 它包含适用于某些 Robocopy 方案的重要修补程序。
提示
如果 RoboCopy 影响了你的生产环境、报告大量的错误，或者进展速度不符合预期，请查看“故障排除”部分。
用户完全转移
首次运行 RoboCopy 命令时，用户和应用程序仍将在 NAS 上访问文件，并有可能更改这些文件。 有可能出现这种情况：RoboCopy 处理了一个目录并移至下一个目录，然后源位置 (NAS) 中的用户添加、更改或删除了一个此时不会在当前 RoboCopy 运行中处理的文件。 这是预期的行为。
首次运行涉及到将大量已改动的数据移到 Azure 文件共享。 首次复制可能需要一段时间。 请查看“故障排除”部分，以更详细地了解哪些因素可能会影响 RoboCopy 的速度。
在初始运行完成后，再次运行该命令。
第二次为同一共享运行 RoboCopy 将会更快地完成，因为只需要传输自上次运行后发生的更改。 可以为同一共享运行重复的作业。
如果你认为停机时间是可接受的，则需要删除用户对基于 NAS 的共享的访问权限。 为此，可执行会阻止用户更改文件和文件夹结构及内容的任何步骤。 例如，使 DFS 命名空间指向不存在的位置，或者更改共享上的根 ACL。
运行最后一轮 RoboCopy。 它将选取可能已丢失的任何更改。 这最后一步所花费的时间取决于 RoboCopy 扫描的速度。 可通过测量上一轮运行所用的时间来估算时间（相当于故障时间）。
在 Windows Server 文件夹上创建一个共享，并根据需要调整 DFS-N 部署来指向该文件夹。 请务必设置与 NAS SMB 共享上相同的共享级别权限。 如果你有一个已加入域的企业级 NAS，那么用户 SID 将自动匹配，这是因为用户在 Active Directory 中，且 RoboCopy 会完全保真地复制文件和元数据。 如果在 NAS 上使用了本地用户，则需要将这些用户重新创建为 Windows Server 本地用户，并将 RoboCopy 移动到 Windows Server 上的现有 SID 映射到新的 Windows Server 本地用户的 SID。
你已将共享/共享组迁移到公共根或卷中。
你可以尝试并行运行其中的几个副本。 建议一次处理一个 Azure 文件共享的范围。
故障排除
给定 RoboCopy 运行的速度和成功率将取决于以下几个因素：
- 源和目标存储上的 IOPS
- 源和目标之间的可用网络带宽
- 快速处理命名空间中的文件和文件夹的能力
- RoboCopy 运行之间的更改数
- 需要复制的文件的大小和数量
IOPS 和带宽注意事项
在此类别中，你需要考虑源存储、目标存储以及连接这两者的网络的能力 。 可能的最大吞吐量由这三个组成部分中的最慢者决定。 请确保将网络基础结构配置为支持最佳传输速度来达到其最佳性能。
注意
尽管最理想的结果通常是尽可能快地复制，但还要考虑将本地网络和 NAS 设备用于其他（通常是业务关键的）任务。
当存在迁移可能独占可用资源的风险时，尽可能快地复制可能不可取。
- 请考虑在你的环境中最适合运行迁移的时间：白天、非工作时间或周末。
- 还请考虑在 Windows Server 上设立网络 QoS 来限制 RoboCopy 速度。
- 避免迁移工具不必要的工作。
RoboCopy 可通过指定 /IPG:n 开关来插入数据包间延迟，其中 n 是 RoboCopy 数据包之间的时间间隔（以毫秒为单位）。 使用此开关有助于避免 IO 受限设备和拥堵网络链路上的资源独占。
/IPG:n 无法用于将带宽限制精确到特定 Mbps。 请改用 Windows Server 网络 QoS。 RoboCopy 完全依靠 SMB 协议来满足各项网络需求。 使用 SMB 导致 RoboCopy 无法影响网络吞吐量本身，但它可减慢其使用速度。
类似的思路也适用于在 NAS 上观察到的 IOPS。 NAS 卷上的群集大小、数据包大小和一系列其他因素都会影响 IOPS 观测值。 引入数据包间延迟通常是控制 NAS 上的负载的最简单方法。 测试多个值，例如从大约 20 毫秒 (n=20) 到该数字的倍数。 引入延迟后，可评估其他应用现在是否可按预期方式工作。 通过此优化策略，你可在环境中找到最佳的 RoboCopy 速度。
处理速度
RoboCopy 将遍历它指向的命名空间，并评估每个文件和文件夹是否适合复制。 在初始复制和追加复制期间将评估每个文件。 例如，对相同的源和目标存储位置重复运行 RoboCopy/MIR。 这些重复运行有助于最大程度地减少用户和应用的停机时间，同时提高迁移文件的总体成功率。
我们通常默认带宽是迁移过程中的最大限制因素，也可能的确如此。 但枚举命名空间的能力可能会影响复制的总时间，对于包含更小文件的更大命名空间来说，复制总时间甚至更长。 思考一下，假定所有其他变数都相同，与复制总大小为 1 TiB，但数量更少的更大文件相比，复制 1 TiB 的小文件所耗时间要长得多。 因此，如果要迁移大量小文件，则传输速度可能会很缓慢。 这是预期的行为。
导致这种差异的原因是遍历命名空间所需的处理能力。 RoboCopy 通过 /MT:n 参数支持多线程复制，其中 n 表示要使用的线程数。 因此，在专门为 RoboCopy 预配计算机时，请考虑处理器核心的数量及其与提供的线程计数的关系。 最常见的是每个核心两个线程。 计算机的核心和线程计数是一个重要的数据点，可决定应该指定的多线程值 /MT:n。 还应考虑计划在给定计算机上并行运行的 RoboCopy 作业的数目。
与更少的线程相比，线程更多可更快地复制 1-TiB 的小文件。 同时，对 1 TiB 更大文件投入额外资源可能不会产生成比例的效益。 如果线程数较高，则会尝试通过网络同时复制更多的大文件。 这种额外的网络活动增加了受吞吐量或存储 IOPS 限制的可能性。
在第一次 RoboCopy 到空目标或使用大量更改文件的差异运行期间，你可能会受到网络吞吐量的限制。 在初始运行时，以较高的线程数开始。 较高的线程数（甚至超过计算机上当前可用的线程）有助于使可用网络带宽饱和。 后续 /MIR 运行会逐渐受到处理项的影响。 差异运行中的更改越少，通过网络传输的数据就越少。 相比于通过网络链接来移动命名空间项，你的速度现在更取决于处理命名空间项的能力。 对于后续运行，请将线程计数值与处理器核心计数和每个核心的线程计数相匹配。 考虑是否需要为生产服务器可能具有的其他任务预留核心。
提示
经验法则：第一次运行 RoboCopy 时（将移动延迟较高的网络的大量数据），会受益于过度预配线程计数 (/MT:n)。 后续运行将复制较少的差异，更有可能从网络吞吐量受限转变为计算受限。 在这些情况下，通常最好将 RoboCopy 线程计数与计算机上实际可用的线程数相匹配。 在这种情况下，过度预配可能会导致处理器产生更多与情景相关的波动，从而可能会减慢复制速度。
避免不必要的工作
避免在命名空间中进行大规模更改。 例如，在目录之间移动文件、大规模更改属性或更改权限 (NTFS ACL)。 尤其是 ACL 更改可能会产生很大的影响，因为它们通常对文件夹层次结构中位置较低的文件具有级联更改效果。 可能产生如下后果：
- 延长 RoboCopy 作业运行时，因为受 ACL 更改影响的每个文件和文件夹都需要更新
- 重用先前移动的数据可能需要重新复制。 例如，如果在早先复制文件后文件夹结构发生更改，则需要复制更多数据。 RoboCopy 作业无法“回放”命名空间更改。 下一个作业必须清除先前传输到旧文件夹结构中的文件，然后再次将文件上传到新文件夹结构中。
另一个重要方面是有效使用 RoboCopy 工具。 借助推荐的 RoboCopy 脚本，你将创建一个日志文件来放置错误并保存该文件。 可能会发生复制错误，这是正常的。 这些错误通常使得必须运行多轮复制工具，例如 RoboCopy。 有一个初始运行，例如从 NAS 到 DataBox 或从服务器到 Azure 文件共享。 还会使用 /MIR 开关执行一次或多次额外运行，以捕获并重试未复制的文件。
应最好准备来针对给定的命名空间范围运行多轮 RoboCopy。 后续运行将更快完成，因为它们需要复制的内容更少，但会越来越多地受到命名空间的处理速度限制。 运行多轮复制时，可禁止 RoboCopy 尝试在给定的运行中过度复制所有内容来加快每一轮的速度。 这些 RoboCopy 开关可造成很大的差异：
/R:nn = 重试复制失败文件的频率/W:nn = 两次重试之间需等待的秒数
/R:5 /W:5 是一个合理的设置，你可根据自己的喜好进行调整。 在本例中，失败的文件将重试 5 次，两次重试之间有 5 秒的等待时间。 如果文件仍无法复制，则下一个 RoboCopy 作业将重试。 通常，由于正在使用或超时问题而失败的文件最终可能会以这种方式成功复制。
后续步骤
对于 Azure 文件共享，有更多的内容有待探索。 以下文章可帮助了解高级选项和最佳做法，还包含疑难解答帮助。 这些文章链接到相应的 Azure 文件共享文档。