使用 RoboCopy 迁移到 Azure 文件共享

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

对于不同的源和部署组合，可以使用许多不同的迁移路线。 请参阅迁移指南表，找到最适合你的需求的迁移路线。

适用于

文件共享类型	SMB	NFS
标准文件共享 (GPv2)、LRS/ZRS
标准文件共享 (GPv2)、GRS/GZRS
高级文件共享 (FileStorage)、LRS/ZRS

AzCopy 与 RoboCopy 的比较

AzCopy 和 RoboCopy 是本质上不同的两种文件复制工具。 RoboCopy 使用任意版本的 SMB 协议。 AzCopy 是“云原生”的工具，只要目标位于 Azure 存储中，就可以使用它来移动数据。 AzCopy 依赖于 REST 协议。

作为受信赖的基于 Windows 的复制工具，RoboCopy 在以全保真度复制文件方面具备绝对的优势。 RoboCopy 提供丰富的功能集，并且能够以全保真度复制文件和文件夹，因此支持许多迁移方案。 请查看迁移概述文章中的文件保真度部分，详细了解以可能的最高保真度复制文件的重要性。

相比之下，AzCopy 只是最近才扩展为支持具有一定保真度的文件复制，并添加了第一组籍以称作迁移工具的功能。 但是，仍然存在差距，在将 AzCopy 标志与 RoboCopy 标志进行比较时，很容易对功能产生误解。

例如：RoboCopy /MIR 将源镜像到目标 - 这意味着会考虑已添加、已更改和已删除的文件。 使用“AzCopy -sync”的一个重要区别是，源上删除的文件不会在目标上删除。 因此，AzCopy 中提供的是不完整的差异复制功能集。 AzCopy 将不断发展。 目前，对于以 Azure 文件共享为目标的迁移场景，不建议使用 AzCopy。

迁移目标

目标是将数据从现有文件共享位置移到 Azure。 在 Azure 中，你会将数据存储在无需安装 Windows Server 即可使用的原生 Azure 文件共享中。 在执行这种迁移时，需要保证生产数据的完整性以及迁移期间的可用性。 要满足后一项要求，需将停机时间尽量缩短，使之不会超过或者只略微超过例行维护时段。

迁移概述

迁移过程包括多个阶段。 首先，你需要部署 Azure 存储帐户和文件共享。 接下来，你将配置网络，考虑使用 DFS 命名空间部署 (DFS-N)，或更新现有部署。 一旦要实际开始复制数据，你将需要考虑使用重复性的差异 RoboCopy 运行来最大程度地减少停机时间，最后将用户切换到新建的 Azure 文件共享。 以下各部分详细介绍了迁移过程的各个阶段。

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

在此阶段，我们将预配 Azure 存储帐户和其中的 SMB Azure 文件共享。

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

通常情况下，如果你有存档共享或预计文件共享的日常活跃度较低，可将多个 Azure 文件共享加入同一存储帐户。 但是，如果共享的活跃度很高（共享由多个用户和/或应用程序使用），则需要在部署存储帐户时使每个帐户都有一个文件共享。 这些限制不适用于 FileStorage（高级）存储帐户，此类存储帐户为每个共享显式预配并保证性能。

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

如果你已创建共享列表，则应将每个共享映射到创建它时所在的存储帐户。

资源的名称也很重要。 例如，如果将 HR 部门的多个共享归入一个 Azure 存储帐户中，则应适当地命名存储帐户。 同样，命名 Azure 文件共享时，应使用与本地对应项所用名称类似的名称。

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

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

使用此阶段中的信息，可以决定如何使 Azure 内部和外部的服务器与用户能够利用你的 Azure 文件共享。 最关键的决策是：

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

装载 Azure 文件共享

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

准备就绪后，请参阅将 Azure 文件共享与 Windows 配合使用。 然后装载要为其启动 RoboCopy 的 Azure 文件共享。

第 3 阶段：RoboCopy

以下 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> 

开关	含义
/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	谨慎使用 使用重启模式。 如果访问被拒绝，此选项将使用备份模式。 由于检查点，此选项会明显降低复制性能。

第 4 阶段：用户完全转移

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

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

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

第二次为同一共享运行 RoboCopy 将会更快地完成，因为只需要传输自上次运行后发生的更改。 可以为同一共享运行重复的作业。

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

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

在第 2 阶段中，你已配置用户，让他们使用其标识访问共享，并且应该已经制定了策略，让用户使用已建立的路径访问新 Azure 文件共享 (DFS-N)。

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

故障排除和优化

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

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

IOPS 和带宽注意事项

在此类别中，你需要考虑源存储、目标存储以及连接这两者的网络的能力 。 可能的最大吞吐量由这三个组成部分中的最慢者决定。 请确保将网络基础结构配置为支持最佳传输速度来达到其最佳性能。

当存在迁移可能独占可用资源的风险时，尽可能快地复制可能不可取。

• 请考虑在你的环境中最适合运行迁移的时间：白天、非工作时间或周末。
• 还请考虑在 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 运行会逐渐受到处理项的影响。 差异运行中的更改越少，通过网络传输的数据就越少。 相比于通过网络链接来移动命名空间项，你的速度现在更取决于处理命名空间项的能力。 对于后续运行，请将线程计数值与处理器核心计数和每个核心的线程计数相匹配。 考虑是否需要为生产服务器可能具有的其他任务预留核心。

避免不必要的工作

避免在命名空间中进行大规模更改。例如，在目录之间移动文件、大规模更改属性，或者更改目录和文件级别权限 (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 作业将重试。 通常，由于正在使用或超时问题而失败的文件最终可能会以这种方式成功复制。

估算存储交易费用

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

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

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

建议对自己的数据运行一些初始测试，以便更好地了解产生了多少事务。 这样就可以更好地了解文件迁移可能会生成的事务总数。

后续步骤

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

• 什么是 Azure 文件？
• 迁移概述
• 备份：Azure 文件共享快照
• 如何结合使用 DFS 命名空间和 Azure 文件存储