使用 Data Box 从网络附加存储（NAS）迁移到 Azure 文件共享

这篇迁移文章是涉及 NAS 和 Azure Data Box 关键词的几篇文章之一。 请检查本文是否适用于你的场景：

  • 数据源：网络连接存储 (NAS)
  • 迁移路径：NAS ⇒ 数据盒⇒ Azure文件共享
  • 不在本地缓存文件：由于最终目标是直接在云中使用 Azure 文件共享，因此没有使用 Azure 文件同步的计划。

如果你的场景与此不同，请参阅迁移指南表。

注意

Data Box 支持 NFS 作为复制协议，所以你可以用它从服务 NFS 的 NAS 复制数据。 不过，Data Box 不支持将数据直接导入到 NFS Azure 文件共享中。 本指南仅涵盖 SMB 文件共享目标。

本文指导你完成一个端到端的过程，其中包括从 NAS 设备迁移到正常运行的 Azure 文件共享所需进行的规划、部署和网络配置。 本指南使用Azure Data Box进行批量数据传输（离线数据传输）。

迁移目标

目标是将 NAS 设备上的共享迁移到 Azure，并使其成为原生 Azure 文件共享。 无需 Windows Server 即可使用原生 Azure 文件共享。 在执行这种迁移时，需要保证生产数据的完整性以及迁移期间的可用性。 要满足后一项要求，需将停机时间尽量缩短，使之不会超过或者只略微超过例行维护时段。

迁移概述

迁移过程包括多个阶段。 首先，部署Azure存储账户和文件共享，并配置网络。 然后，通过Azure Data Box和RoboCopy迁移文件，以赶上变化。 最后，将用户和应用切换到新创建的 Azure 文件共享中。 以下各部分详细介绍了迁移过程的各个阶段。

提示

如果你返回本文，请使用右侧的导航栏跳转到你离开的迁移阶段。

第 1 阶段：确定需要多少个 Azure 文件共享

确定你需要多少个 Azure 文件共享。 你的磁盘卷上可能有更多文件夹当前本地作为 SMB 共享共享给用户和应用程序。 根据你想迁移到云端的文件共享数量，选择一对一映射或共享分组。

使用 1:1 映射

如果你的股份数量很少，可以使用一对一的映射。 最容易理解这种情况的方式，是设想一个与 Azure 文件共享一一对应的本地部署共享。

使用共享分组

如果有大量的文件共享，请考虑使用共享分组。 例如，如果人力资源 (HR) 部门有 15 个共享，则可以考虑将所有 HR 数据存储在一个 Azure 文件共享中。 这样，对于这组本地共享，只需要一个云中的 Azure 文件共享。

第 2 阶段：部署 Azure 存储资源

在此阶段，预配 Azure 存储账户及其中的文件共享。

请记住，Azure 文件共享部署在云中的 Azure 存储帐户中。 对于 HDD（标准）文件共享，这种安排使得存储帐户成为性能数字（如 IOPS 和吞吐量）的规模目标。 如果将多个文件共享放置在单个存储帐户中，则会为这些共享创建一个包含 IOPS 和吞吐量的共享池。

通常情况下，如果你有存档共享或预计文件共享的日常活跃度较低，可将多个 Azure 文件共享加入同一存储帐户。 不过，如果你有活动非常频繁的文件共享（许多用户和应用程序都会使用的共享），请部署每个仅包含一个文件共享的存储帐户。 这些限制不适用于 FileStorage（SSD）存储帐户，在这些帐户中，为每个共享的性能进行显式预配并提供保证。

注意

每个 Azure 区域的每个订阅的存储帐户限制为 250 个。

部署存储帐户时，另一个要考虑的问题是冗余。 请参阅 Azure 文件存储冗余。

如果你列出了自己的文件共享列表，请将每个文件共享对应到创建该共享时所在的存储帐户。

资源的名称也很重要。 例如，如果你将人力资源部门的多个共享分组到一个Azure存储账户中，适当命名该存储账户。 同样，当你为Azure文件共享命名时，使用与本地文件相似的名称。

现在，请按照创建 SMB 文件共享中的说明部署相应数量的 Azure 存储帐户，并在其中部署相应数量的 Azure 文件共享。 大多数情况下，确保每个存储账户的区域相同。

第 3 阶段：确定需要多少台 Azure Data Box 设备

只有在完成上一阶段后才开始这一步。 此时，你应该已经创建了Azure存储资源，包括存储账户和文件共享。 在你的数据盒订单中，你需要指定数据盒将数据移入哪些存储账户。

在此阶段，将上一阶段迁移计划的结果映射到可用数据盒选项的极限。 这些考量可帮助你规划应选择哪些 Data Box 选项，以及为将 NAS 共享迁移到 Azure 文件共享而需要多少个 Data Box。

若要确定你需要哪种类型的设备以及需要多少台，请考虑以下重要限制：

  • 任何 Azure Data Box 都可以将数据迁移到最多 10 个存储账户。
  • 每个数据盒选项都有其可用的容量。 请参阅 “Data Box”选项。

请参考你的迁移计划，了解你决定创建的存储账户数量以及每个账户中的份额。 然后，查看 NAS 上每个共享的大小。 结合这些信息，你可以决定哪个设备应该把数据发送到哪个存储账户。 你可以让两个数据盒设备将文件转移到同一个存储账户，但不要将单个文件共享的内容分拆到两个数据盒设备之间。

Data Box 选项

  • 数据盒 这是最常见的选择。 它是一款坚固耐用的数据盒设备，工作原理类似NAS。 产品交付给您时，提供 80 TiB 的可用容量。 有关详细信息，请参阅 Data Box 文档。

警告

不建议将 Data Box 磁盘迁移到 Azure 文件共享。 Data Box 磁盘不会保留文件元数据，例如访问权限（ACL）和其他属性。

第 4 阶段：预配临时 Windows Server

在等待 Azure Data Box 设备到货期间，你已经可以部署一台或多台运行 RoboCopy 作业所需的 Windows 服务器。 关于操作系统版本要求，请参见 RoboCopy部分的重要说明。

  • 利用这些服务器将文件复制到数据盒。
  • 利用这些服务器在数据盒传输过程中，跟踪NAS设备上发生的变化。 此方法可以最大程度地减少源端的停机时间。

你的 RoboCopy 作业运行速度主要取决于以下因素：

  • 源和目标存储上的 IOPS
  • 它们之间的可用网络带宽
    更多详细信息请参阅：IOPS 和带宽考量
  • 快速处理命名空间
    中的文件和文件夹的功能查找更多详细信息： 处理速度
  • RoboCopy 运行
    之间的更改的数量查找更多详细信息：避免不必要的工作

在决定为临时Windows Server提供内存和线程数时，请记住上述细节。

第 5 阶段：准备使用 Azure 文件共享

为了节省时间，在等待数据盒到来时继续这个阶段。 有了这一阶段的信息，你可以决定服务器和用户如何使用你的 Azure 文件共享。 最关键的决策是：

  • 网络：使网络能够路由 SMB 流量。
  • 身份验证：配置 Azure 存储帐户以进行 Kerberos 身份验证。 Microsoft Entra Connect 和将存储帐户加入域可让应用和用户使用其 AD 标识进行身份验证。
  • 授权：每个 Azure 文件共享的共享级别 ACL 允许 AD 用户和组访问该共享，而在 Azure 文件共享中，原生 NTFS ACL 接管。 然后，基于文件和文件夹 ACL 的授权将发挥作用，就像对本地 SMB 共享一样。
  • 业务连续性：将Azure文件共享集成到现有环境中通常涉及保留现有共享地址。 如果尚未使用 DFS 命名空间，请考虑在环境中建立它。 你可以保留用户和脚本使用的共享地址，保持不变。 你将使用 DFS-N 作为 SMB 的命名空间路由服务，方法是在迁移后将 DFS 命名空间目标重定向到 Azure 文件共享。

第六阶段：将文件复制到你的数据盒

当你的 Data Box 到达后，请设置 Data Box，并确保它与 NAS 设备之间的网络连接畅通无阻。 按照你订购的数据盒类型的设置文档操作。

根据数据盒类型，你可能可以使用数据盒复制工具。 目前，请勿将它们用于迁移到 Azure 文件共享，因为它们无法以完整保真的方式将文件复制到 Data Box。 请改用 RoboCopy。

当你的 Data Box 到达时，系统会为你在订购时指定的每个存储帐户提供已预配好的 SMB 共享。

  • 如果您的文件存放在 Azure SSD 文件共享中，则每个 SSD“文件存储”存储帐户对应一个 SMB 共享。
  • 如果你的文件存入 HDD 存储帐户，则每个 HDD 即用即付存储帐户有三个 SMB 共享。 只有以 _AzFiles 结尾的文件共享才适用于你的迁移。 请忽略掉任何块 Blob 和页 Blob 共享。

按照 Azure Data Box 文档中的步骤进行操作：

  1. 连接到 Data Box
  2. 将数据复制到 Data Box
  3. 检查RoboCopy日志文件中的错误，确认所有文件都成功复制。
  4. 准备你的数据盒以准备前往Azure

链接中的Data Box文档规定了RoboCopy命令。 然而，该命令不适合保持完整文件和文件夹的完整性。 该命令之所以使用 /MT:32 ，是因为它是本地局域网副本到数据盒，延迟可忽略不计，因此这里线程数比第七阶段基于WAN的追赶副本更合适：

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 进行同步

在 Data Box 报告已将所有文件和文件夹放入计划使用的 Azure 文件共享后，继续执行此阶段。 只有当 NAS 上的数据自 Data Box 复制开始以来可能已发生变化时，才需要补做一次 RoboCopy。 在某些情况下当你出于存档目的使用某个共享时，你也许可以在 NAS 上停止对该共享进行更改，直到迁移完成。 也许还可以在迁移期间将 NAS 共享设置为只读，以此满足业务要求。

如果你需要在迁移过程中读写共享，且只能承受一小段停机时间窗口，这个追赶RoboCopy步骤非常重要，必须在用户访问直接切换到Azure文件共享之前完成。

在这一步中，运行 RoboCopy 作业，使你的云共享与自将共享复制到 Data Box 之后 NAS 上的最新更改保持同步。 这次用于追赶进度的 RoboCopy 可能会很快完成，也可能需要一些时间，具体取决于你的 NAS 共享中发生的变更量。

执行首次本地复制，将其复制到 Windows Server 目标文件夹：

  1. 标识 NAS 设备上的第一个位置。
  2. 标识匹配的 Azure 文件共享。
  3. 将 Azure 文件共享装载为临时 Windows Server 上的本地网络驱动器。
  4. 如前所述，使用 RoboCopy 启动副本。

装载 Azure 文件共享

在可以使用 RoboCopy 之前，需要使 Azure 文件共享可供通过 SMB 访问。 最简单的方法是将共享作为本地网络驱动器装载到计划用于 RoboCopy 的 Windows Server。

重要

在成功将 Azure 文件共享装载到本地 Windows Server 之前，必须完成 阶段 5：准备使用 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 命令。 如果你用 Robocopy 管理 Azure 文件存储，确保你用存储账户访问密钥挂载 Azure 文件共享，而不是用域身份。 如果不这样做，错误消息可能不会直观地引导你解决问题。
/MIR （将源镜像映射到目标）使 Robocpy 只复制源和目标之间的增量。 将复制空子目录。 将复制目标上已更改或不存在的项（文件或文件夹）。 将从目标上清除（删除）目标上存在但源上没有的项。 使用此开关时，要使源和目标文件夹结构完全匹配。 “匹配”表示从正确的源和文件夹级别复制到目标上的匹配文件夹级别。 只有这样，才能成功完成“追赶”复制。 当源和目标不匹配时，使用 /MIR 将导致大规模删除和重新复制。
/IT 确保在某些镜像场景中保持精确性。
例如，如果在两个 RoboCopy 运行之间，文件遇到 ACL 更改和属性更新的情况，它将被标记为“隐藏”。 如果没有 /IT，RoboCopy 可能会遗漏 ACL 更改，并且不会将其传输到目标位置。
/COPY:[copyflags] 文件副本的保真度。 默认值：/COPY:DAT。 复制标志：D= 数据，A= 属性，T= 时间戳，S= 安全性 = NTFS 访问控制列表，O= 所有者信息，U= 审核信息。 审核信息无法存储在 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时，确保安装了最新的补丁级别或至少是操作系统更新KB5005103。 它包含适用于特定 Robocopy 场景的重要修补程序。

提示

如果 RoboCopy 影响了你的生产环境、报告大量的错误，或者进展速度不符合预期，请查看“故障排除”部分。

用户切换

首次运行 RoboCopy 命令时，用户和应用程序仍将在 NAS 上访问文件，并有可能更改这些文件。 有可能出现这种情况：RoboCopy 处理了一个目录并移至下一个目录，然后源位置 (NAS) 中的用户添加、更改或删除了一个此时不会在当前 RoboCopy 运行中处理的文件。 这是预期的行为。

第一次运行涉及将大量已处理的数据移到 Azure 文件共享。 首次复制可能需要一段时间。 请查看“故障排除”部分，以更详细地了解哪些因素可能会影响 RoboCopy 的速度。

初始运行完成后，再次执行该命令。

第二次针对同一共享运行 RoboCopy 时，它会更快完成，因为它只需要传送自上次运行以来发生的更改。 可以为同一共享运行重复的作业。

如果你认为停机时间是可接受的，则需要删除用户对基于 NAS 的共享的访问权限。 为此，可执行会阻止用户更改文件和文件夹结构及内容的任何步骤。 例如，使 DFS 命名空间指向不存在的位置，或者更改共享上的根 ACL。

运行最后一轮 RoboCopy。 它能捕捉可能被遗漏的任何变化。 这最后一步所花费的时间取决于 RoboCopy 扫描的速度。 可通过测量上一轮运行所用的时间来估算时间（相当于故障时间）。

在 Windows Server 文件夹上创建一个共享，并根据需要调整 DFS-N 部署以便指向它。 请务必设置与 NAS SMB 共享上相同的共享级别权限。 如果你拥有一个已加入域的企业级 NAS，由于用户存在于 Active Directory 中，因此用户 SID 将自动匹配，且 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 数据包之间的时间间隔（以毫秒为单位）。 使用该交换机有助于避免I/O受限设备和拥挤网络链路的资源被垄断。

/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 复制到 Data Box，或从服务器复制到 Azure 文件共享；然后使用 /MIR 开关再额外运行一次或多次，以处理并重试未复制成功的文件。

做好准备，针对给定的命名空间范围多次运行 RoboCopy。 后续运行会更快完成，因为需要复制的内容更少，但也越来越受到命名空间处理速度的限制。 运行多轮复制时，可通过无需让 RoboCopy 在给定的运行中尽全力复制所有内容来加快每一轮的速度。 这些 RoboCopy 开关可造成很大的差异：

  • /R:n n = 重试复制失败文件的频率
  • /W:n n = 两次重试之间需等待的秒数

/R:5 /W:5 是一个合理的设置，你可根据自己的喜好进行调整。 在本例中，失败的文件将重试 5 次，两次重试之间有 5 秒的等待时间。 如果文件仍无法复制，则下一个 RoboCopy 作业将重试。 最终，以这种方式可以成功复制通常由于正在使用或超时问题而失败的文件。

另请参阅

  • Last updated on