使用 RoboCopy 迁移到Azure文件共享

适用于： ✔️ SMB 文件共享

此迁移文章介绍如何使用 RoboCopy 将文件移动或迁移到 SMB Azure文件共享。 RoboCopy 是一个颇受信赖的知名文件复制实用工具，其中提供的功能集非常适合用于迁移。 它使用 SMB 协议，这使得它广泛适用于支持 SMB 的任何源和目标组合。

  • 数据源：支持 SMB 协议的任何源，例如网络连接存储（NAS）、Windows或 Linux 服务器、其他Azure文件共享，等等
  • 迁移路径：从源存储 ⇒ 使用 RoboCopy 的 Windows 计算机 ⇒ 到 Azure 文件共享
  • 本地没有缓存文件：因为最终目标是直接在云中使用Azure文件共享，因此没有计划使用Azure 文件同步。

Important

对于不同的源和部署组合，可以使用许多不同的迁移路线。 在完成本文中的步骤之前，请确保已阅读 迁移概述，确定 RoboCopy 是最适合需求的工具，并部署了迁移所需的Azure存储资源。

AzCopy 与 RoboCopy

AzCopy 和 RoboCopy 本质上是不同的工具。 RoboCopy 使用 SMB，并以全保真复制文件，非常适合迁移。 关于文件保真度的更多信息，请参见迁移基础。 AzCopy 是一款云原生工具，使用 REST 技术。

关键的行为区别是： RoboCopy /MIR 会将源头镜像到目标。 它处理添加、更改和删除的文件。 AzCopy 同步不会从目标端移除源端删除的文件，这使得迁移场景中源文件不完整。 因此，不要在以 Azure 文件共享为目标的迁移场景中使用 AzCopy。

装载Azure文件共享

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

Important

使用 admin 级访问权限装载 Azure 文件共享：可以通过具有管理员级别权限的 Azure RBAC 角色进行基于标识的访问（推荐），或者使用存储帐户密钥（安全性较低）。

查看 将 Azure 文件共享与 Windows 配合使用 ，然后挂载要用于启动 RoboCopy 的 SMB Azure 文件共享。

使用 RoboCopy 将文件复制到Azure文件共享

以下 RoboCopy 命令将仅将源存储中的差异（已更新的文件和文件夹）复制到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>
Switch Meaning
/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 ACL，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 谨慎使用
使用重启模式。 如果访问被拒绝，此选项将使用备份模式。 由于检查点的缘故，此选项会明显降低拷贝性能。

RoboCopy 可能会报告即使不需要数据传输，也复制了文件。 发生此行为的原因是 robocopy 在生成输出时会评估文件数据和元数据的更改。

若要正确解释结果，请查看命令输出中的文件状态：

  • 较新的：文件数据已复制到目标位置。
  • 已修改：仅更新元数据;文件数据不会重新编码。

在这两种情况下，RoboCopy 可能会报告字节计数，就像传输数据一样。 验证复制操作时，此行为可能会导致混淆。

Important

建议使用Windows Server 2022或更高版本。 使用Windows Server 2019时，请确保安装最新的修补程序级别或至少OS 更新KB5005103。 它包含适用于某些 Robocopy 方案的关键修补程序。

Tip

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

完成迁移切换操作

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

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

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

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

达到可接受的故障时间之后，需要移除用户对源共享的访问权限。 为此，可执行会阻止用户更改文件和文件夹结构及内容的任何步骤。 例如，使 DFS 命名空间指向不存在的位置，或者更改每个共享上的 ACL。

运行最后一轮 RoboCopy。 它将检测到可能被忽略的任何更改。 这最后一步所花费的时间取决于 RoboCopy 扫描的速度。 可以通过测量上一轮运行所用的时间来估算时间（相当于停机时间）。

可以尝试在不同的源与目标共享之间并行运行上述几种复制操作。 如果要这样做，请记得控制好网络吞吐量以及核心数与线程数之比，以免系统开销过大。

故障排除和优化

给定 RoboCopy 运行的速度和成功率将取决于以下几个因素：

  • 源和目标存储上的 IOPS
  • 源和目标之间的可用网络带宽
  • 快速处理命名空间中的文件和文件夹的能力
  • RoboCopy 运行之间的变更次数
  • 需要复制的文件的大小和数量

IOPS 和带宽注意事项

在此类别中，考虑 源存储、 目标存储以及连接它们的 网络 。 这三个部件中最慢的决定了最大可能的吞吐量。

Caution

尽管最理想的结果通常是尽可能快地复制，但还要考虑将本地网络和 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 会遍历您指定的命名空间，并在初始运行期间以及后续每次补跑期间，判断是否需要复制每个文件和文件夹。 这些重复运行可以减少停机时间，并提高迁移文件的整体成功率。

带宽并不总是最受限的因素。 对于拥有大量小文件的大型命名空间，命名空间枚举速度对总复制时间的影响可能大于吞吐量。 复制1 TiB的小文件所需时间远长于复制1 TiB较大文件。 预计会出现这种差异。

RoboCopy 通过选项 /MT:n 支持多线程副本， 其中 n 代表可使用线程数量。 在为RoboCopy配置机器时，考虑处理器核心数（大多数CPU每个核心提供两个线程）以及你计划并行运行多少个RoboCopy作业。

更多线程能更快地复制小文件，但它们可能无法为大文件带来相应的优势。 大文件的线程数越大，吞吐量或IOPS约束的概率就会增加。

在初始运行RoboCopy时，使用高线程数来饱和可用的网络带宽。 对于后续变更较少的 /MIR 运行，处理速度会成为瓶颈，因此应使线程数与处理器核心数一致。 考虑是否需要将核心预留用于生产服务器上的其他任务。

Tip

经验法则：第一次运行 RoboCopy 时（将传输高延迟网络中的大量数据）受益于过度配置线程计数 (/MT:n)。 后续运行将复制较少的差异，更有可能从网络吞吐量受限转变为计算受限。 在这些情况下，通常最好是让 RoboCopy 线程计数与计算机上实际可用的线程数匹配。 在这种情况下，过度预配可能会导致处理器产生更多与情景相关的波动，从而可能会减慢复制速度。

在迁移过程中避免更改命名空间

避免在命名空间中进行大规模更改。例如，在目录之间移动文件、大规模更改属性，或者更改目录和文件级别权限 (NTFS ACL)。 尤其是 ACL 更改可能会产生很大的影响，因为它们通常对文件夹层次结构中位置较低的文件具有级联更改效果。 可能产生如下后果：

  • 延长 RoboCopy 作业运行时，因为受 ACL 更改影响的每个文件和文件夹都需要更新
  • 重用早先移动的数据可能需要重新复制。 例如，如果在早先复制文件后文件夹结构发生更改，则需要复制更多数据。 RoboCopy 作业无法“回放”命名空间更改。 下一个作业必须清除先前传输到旧文件夹结构中的文件，然后再次将文件上传到新文件夹结构中。

另一个重要方面是有效使用 RoboCopy 工具。 使用推荐的 RoboCopy 脚本，你将创建并保存一个用于记录错误的日志文件。 可能会发生复制错误，这是正常的。 这些错误通常使得需要运行多个轮复制工具（例如 RoboCopy：从 NAS 到 DataBox 或服务器到 Azure 文件共享），并使用 /MIR 开关运行一个或多个额外运行来捕获和重试未复制的文件。

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

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

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

使用 Robocopy 将文件从Azure 文件存储快照复制到本地驱动器

可以使用 Robocopy 将 Azure 文件共享中的 SMB 快照视图的文件和文件夹复制回本地驱动器。 有关详细信息，请参阅 从共享快照将数据复制回本地驱动器。

估算存储交易费用

开始Azure 文件存储迁移时，RoboCopy 会将文件和文件夹复制到Azure。 根据Azure 文件存储的计费模型，可能会收取交易费用。 请参阅了解计费。

如果 HDD（标准）Azure文件共享使用即用即付计费模型，则很难估计迁移将生成的事务数。

  • 根据源的已使用存储容量来估算交易数是不可行的。 交易数随命名空间项（文件和文件夹）数量及其迁移的属性数量而增加，而不是随它们的大小增加。 例如，迁移 1 GiB 的小型文件比迁移 1 GiB 更大的文件需要更多事务。
  • 为了减少停机时间，你可能需要多次从源头到目标执行复制操作。 每次复制操作都会处理所有源和目标项目，尽管后续的执行会更快完成。 初始操作后，仅通过网络传输复制进程之间产生的差异。 需要强调的是，虽然传输的数据较少，但所需的事务数可能会保持不变。
  • 复制同一文件两次，所产生的交易数可能不同。 在处理在之前的复制运行中迁移的项目时，可能只会产生少量的读取事务。 相比之下，在复制运行之间对元数据或内容的更改可能需要更多的事务来更新目标。

对你自己的数据做一些初步测试，更好地了解文件迁移会产生多少交易。

后续步骤

下面的文章将帮助你了解高级选项和最佳做法。

  • Last updated on