你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用 Data Box 通过 Azure 文件同步从网络连接存储 (NAS) 迁移到混合云部署
本迁移文章是适用于关键字 NAS、Azure 文件同步和 Azure Data Box 的几篇文章之一。 请检查本文是否适用于你的场景：
- 数据源：网络连接存储 (NAS)
- 迁移路线：NAS ⇒ Data Box ⇒ Azure 文件共享 ⇒ 与 Windows Server 同步
- 本地缓存文件：是，最终目标是完成 Azure 文件同步部署
如果你的场景与此不同，请参阅迁移指南表。
Azure 文件同步在直接附加存储 (DAS) 位置进行。 它不支持同步到网络附加存储 (NAS) 位置。 因此你需要迁移文件。 本文将指导你规划和实施这种迁移。
适用于
| 文件共享类型 | SMB | NFS |
|---|---|---|
| 标准文件共享 (GPv2)、LRS/ZRS |  |
 |
| 标准文件共享 (GPv2)、GRS/GZRS | |
|
| 高级文件共享 (FileStorage)、LRS/ZRS | |
|
迁移目标
目标是将 NAS 设备上的共享移到 Windows Server。 然后对混合云部署使用 Azure 文件同步。 在执行这种迁移时，需要保证生产数据的完整性以及迁移期间的可用性。 后者要求尽量减少服务中断时间，因此可在常规维护时段进行迁移，或者仅略微超出这些时段操作。
迁移概述
迁移过程包括多个阶段。 你将需要：
- 部署 Azure 存储帐户和文件共享。
- 部署一台运行 Windows Server 的本地计算机。
- 配置 Azure 文件同步。
- 使用 Robocopy 迁移文件。
- 执行切换。
以下各部分详细介绍了迁移过程的各个阶段。
提示
如果你返回到本文，请使用屏幕右侧的导航栏转到你离开的迁移阶段。
第 1 阶段：确定需要多少个 Azure 文件共享
在此步骤中，你将决定需要多少个 Azure 文件共享。 单个 Windows Server 实例（或群集）可以同步最多 30 个 Azure 文件共享。
卷上可能有更多文件夹当前作为 SMB 共享在本地共享给用户和应用。 描述此场景的最简单方法是设想 1:1 映射到 Azure 文件共享的本地共享。 如果共享数目够小，即单个 Windows Server 实例低于 30 个时，建议使用 1:1 映射。
如果共享数目超过 30 个，通常不需要将本地共享 1:1 映射到 Azure 文件共享。 请考虑以下选项。
共享分组
例如，如果人力资源 (HR) 部门有 15 个共享，则可以考虑将所有 HR 数据存储在一个 Azure 文件共享中。 将多个本地共享存储在一个 Azure 文件共享中不会阻止你在本地 Windows Server 实例上创建常规的 15 个 SMB 共享。 这只是意味着将这 15 个共享的根文件夹组织为公用文件夹下的子文件夹。 然后将此公用文件夹同步到 Azure 文件共享。 这样，这组本地共享便只需要云中的单个 Azure 文件共享。
卷同步
Azure 文件同步支持将卷的根同步到 Azure 文件共享。 如果同步卷根，则所有子文件夹和文件都会转到相同的 Azure 文件共享。
同步卷的根并非总是最佳选项。 同步多个位置有很多好处。 例如，这样做可帮助降低每个同步范围的项目数。 我们测试了 Azure 文件共享和 Azure 文件同步，每个共享有 1 亿个项目（文件和文件夹）。 但是，在单个共享中，最好试着将数目控制在 2000 万或 3000 万以下。 使用较少数量的项目设置 Azure 文件同步不只是对文件同步有利。在下面这些场景中，项目数量较少的优势也是显而易见的：
- 对云内容的初始扫描可以更快地完成，这会减少命名空间出现在启用 Azure 文件同步的服务器上的等待时间。
- 从 Azure 文件共享快照进行云端还原会更快。
- 本地服务器的灾难恢复可以显著提高速度。
- 可以更快地检测和同步在 Azure 文件共享中直接进行的更改（在同步之外）。
提示
如果你不知道你有多少个文件和文件夹，请使用 JAM Software GmbH 提供的 TreeSize 工具来确认。
部署映射的结构化方法
在稍后的步骤中部署云存储之前，请务必在本地文件夹与 Azure 文件共享之间创建映射。 此映射会告知，你要预配哪些 Azure 文件同步“同步组”资源以及具体数量。 同步组会将 Azure 文件共享和服务器上的文件夹关联在一起，并建立同步连接。
若要确定需要多少个 Azure 文件共享，请参考以下限制和最佳做法。 这样做有助于优化映射。
安装了 Azure 文件同步代理的服务器可与最多 30 个 Azure 文件共享同步。
Azure 文件共享部署在存储帐户中。 这样安排会使存储帐户成为 IOPS 和吞吐量等性能指标的缩放目标。
部署 Azure 文件共享时，应注意存储帐户的 IOPS 限制。 理想情况下，应该将文件共享按 1:1 与存储帐户映射。 但由于组织和 Azure 同时施加各种限制和制约，不一定始终能够实现这种映射。 如果无法在一个存储帐户中只部署一个文件共享，可考虑哪些共享会非常活跃和哪些将不会那么活跃，以确保不会将使用率最高的文件共享放置在同一存储帐户中。
如果计划将应用提升到将在本机使用 Azure 文件共享的 Azure，则可能需要提高 Azure 文件共享的性能。 如果现在甚至以后都可以这样使用，最好在其自己的存储帐户中创建一个标准 Azure 文件共享。
每个 Azure 区域的每个订阅的存储帐户限制为 250 个。
提示
考虑到这一点，通常需要将卷上的多个顶级文件夹分组到一个新的公用根目录中。 随后将这个新的根目录以及分组到其中的所有文件夹都同步到单个 Azure 文件共享。 此方法使你可以维持在每台服务器 30 个 Azure 文件共享同步的限制范围内。
在公用根下进行这种分组不会对数据访问产生影响。 你的 ACL 将保持原样。 只需要调整你在本地服务器文件夹上的任何共享路径（如 SMB 或 NFS 共享），现在你已将这些文件夹更改为公用根。 无其他更改。
重要
Azure 文件同步最重要的缩放矢量是需要同步的项目数（文件和文件夹）。 如需更多详细信息，请参阅 Azure 文件同步缩放目标。
最佳实践是使每个同步范围的项目数保持较低。 这是在将文件夹映射到 Azure 文件共享时要考虑的重要因素。 Azure 文件同步对每个共享使用 1 亿个项目（文件和文件夹）进行测试。 但是，在单个共享中，最好将项目数控制在 2000 万或 3000 万以下。 如果开始超过这些数量，请将命名空间拆分为多个共享。 如果一直大致低于这些数量，则可以继续将多个本地共享分组到相同 Azure 文件共享中。 这种做法可为你提供增长空间。
在这种情况下，可能能够以逻辑方式将一组文件夹同步到相同的 Azure 文件共享（使用前面提到的新的公用根文件夹方法）。 但是，重新分组文件夹使它们同步到两个（而不是一个）Azure 文件共享中可能会更好。 可以使用此方法使每个文件共享的文件和文件夹数在服务器间保持平衡。 还可以拆分本地共享并在更多的本地服务器上同步，从而增加每个额外服务器再同步 30 个 Azure 文件共享的能力。
常见文件同步方案和注意事项
| # | 同步方案 | 支持 | 注意事项（或限制） | 解决方案（或解决方法） |
|---|---|---|---|---|
| 1 | 将包含多个磁盘/卷和多个共享的文件服务器同步到同一目标 Azure 文件共享（合并） | 否 | 目标 Azure 文件共享（云终结点）仅支持与一个同步组同步。 同步组仅支持在每个已注册服务器上使用一个服务器终结点。 |
1) 首先将一个磁盘（其根卷）同步到目标 Azure 文件共享。 从最大的磁盘/卷开始将有助于满足本地存储要求。 配置云分层以将所有数据分层到云，从而释放文件服务器磁盘上的空间。 将其他卷/共享中的数据移到正在同步的当前卷。 继续逐个执行这些步骤，直到所有数据已分层到云/完成迁移。 2) 每次以一个根卷（磁盘）为目标。 使用云分层将所有数据分层到目标 Azure 文件共享。 从同步组中删除服务器终结点，使用下一个根卷/磁盘重新创建终结点，执行同步，然后重复该过程。 注意：可能需要重新安装代理。 3) 建议使用多个目标 Azure 文件共享（根据性能要求使用相同或不同的存储帐户） |
| 2 | 将包含单个卷和多个共享的文件服务器同步到同一目标 Azure 文件共享（合并） | 是 | 在同步到同一目标 Azure 文件共享的每个注册服务器上不能有多个服务器终结点（同上） | 同步包含多个共享或顶级文件夹的卷的根目录。 有关详细信息，请参阅共享分组概念和卷同步。 |
| 3 | 将包含多个共享和/或卷的文件服务器同步到单个存储帐户下的多个 Azure 文件共享（1:1 共享映射） | 是 | 单个 Windows Server 实例（或群集）可以同步最多 30 个 Azure 文件共享。 存储帐户是性能缩放目标。 IOPS 和吞吐量在文件共享之间共享。 将每个同步组的项数保持在每个共享包含 1 亿个项（文件和文件夹）以内。 理想情况下，最好在每个共享中包含不超过 2 千万到 3 千万个项。 |
1) 使用多个同步组（同步组数量 = 要同步到的 Azure 文件共享数量）。 2) 在此方案中，每次只能同步 30 个共享。 如果该文件服务器上的共享数超过 30 个，请使用共享分组概念和卷同步来减少源上的根目录或顶级文件夹数量。 3) 使用本地的其他文件同步服务器并将数据拆分/移到这些服务器，以解决源 Windows 服务器上的限制。 |
| 4 | 将包含多个共享和/或卷的文件服务器同步到其他存储帐户下的多个 Azure 文件共享（1:1 共享映射） | 是 | 单个 Windows Server 实例（或群集）最多可以同步 30 个 Azure 文件共享（相同或不同的存储帐户）。 将每个同步组的项数保持在每个共享包含 1 亿个项（文件和文件夹）以内。 理想情况下，最好在每个共享中包含不超过 2 千万到 3 千万个项。 |
方法同上 |
| 5 | 将包含单个根卷或共享的多个文件服务器同步到同一目标 Azure 文件共享（合并） | 否 | 同步组不能使用已在另一个同步组中配置的云终结点（Azure 文件共享）。 尽管同步组可以在不同的文件服务器上具有服务器终结点，但文件不能不同。 |
请遵循上述方案 #1 中的指导，并注意每次以一个文件服务器为目标的附加要点。 |
创建映射表
使用前面的信息来确定所需的 Azure 文件共享数目，以及现有数据的哪些部分最终会出现在哪个 Azure 文件共享中。
创建一个表来记录你的想法，这样你就可以在需要时进行参考。 保持井然有序非常重要，因为当你同时预配许多 Azure 资源时，可能会很容易丢失映射计划的详细信息。 下载以下 Excel 文件用作模板，以帮助创建映射。
|
下载命名空间映射模板。 |
第 2 阶段：部署 Azure 存储资源
在此阶段中，请查阅第 1 阶段中的映射表，并使用它来预配正确数量的 Azure 存储帐户和其中的文件共享。
Azure 文件共享存储在云中的 Azure 存储帐户中。 此处还需遵守另外一个性能注意事项适。
如果共享的活跃度很高（共享由多个用户和/或应用程序使用），则两个 Azure 文件共享就可能达到存储帐户的性能限制。
最佳做法是在部署存储帐户时，让每个存储帐户都有一个文件共享。 如果你有存档共享或预计文件共享的日常活跃度较低，可将多个 Azure 文件共享加入同一存储帐户。
相对于 Azure 文件同步，这些注意事项更适用于通过 Azure VM 进行的直接云访问。如果计划只在这些共享上使用 Azure 文件同步，则可以将多个文件共享分组到一个 Azure 存储帐户中。
如果已创建共享列表，应将每个共享映射到它所在的存储帐户。
在上一阶段中，你确定了适当数量的共享。 在此步骤中，你具有存储帐户到文件共享的映射。 现在，可部署适当数量的 Azure 存储帐户，其中包含相应数量的 Azure 文件共享。
请确保每个存储帐户的区域相同，并且与已部署的存储同步服务资源的区域相匹配。
注意
如果创建的 Azure 文件共享具有 100 TiB 的限制，则该共享只能使用本地冗余存储或区域冗余存储冗余选项。 使用 100 TiB 的文件共享之前，应考虑自己的存储冗余需求。
默认情况下，将创建具有 5 TiB 限制的 Azure 文件共享。 按照创建 Azure 文件共享中的步骤创建大型文件共享。
部署存储帐户时，还要考虑一个问题，那就是 Azure 存储的冗余。 请参阅 Azure 存储冗余选项。
资源的名称也很重要。 例如，如果将 HR 部门的多个共享归入一个 Azure 存储帐户中，则应适当地命名存储帐户。 同样，命名 Azure 文件共享时，应使用与本地对应项所用名称类似的名称。
第 3 阶段：确定需要多少台 Azure Data Box 设备
请仅在完成上一阶段后，才开始执行此步骤。 此时应创建 Azure 存储资源（存储帐户和文件共享）。 订购 Data Box 时，需指定 Data Box 要将数据移到哪些存储帐户。
在此阶段中，需要将上一阶段中迁移计划的结果映射到可用 Data Box 选项的各种限制。 这些考虑事项将帮助你针对将 NAS 共享移到 Azure 文件共享时要选择哪些 Data Box 选项以及需要多少台这种设备而进行规划。
若要确定需要多少台设备及设备类型，请考虑以下重要限制：
- 任一 Azure Data Box 设备可将数据移到最多 10 个存储帐户中。
- 每个 Data Box 选项都有其自己的可用容量。 请参阅 Data Box 选项。
请查阅迁移计划以找到你决定创建的存储帐户数以及每个帐户中的共享数。 然后，查看 NAS 上每个共享的大小。 通过组合使用这些信息，你可以进行优化并决定哪台设备应当将数据发送到哪些存储帐户。 可以使用两台 Data Box 设备将文件移到同一存储帐户中，但不要将单个文件共享的内容拆分到两台 Data Box 设备中。
Data Box 选项
对于标准迁移，请选择以下三个 Data Box 选项中的一个或多个：
- Data Box Disk。 Microsoft 将向你寄送一到五块 SSD 盘，其中每个盘的容量为 8 TiB，所有盘的最大总容量为 40 TiB。 由于加密和文件系统开销，可用容量大约少 20%。 有关详细信息，请参阅 Data Box Disk 文档。
- Data Box。 这是最常用的选项。 Microsoft 将向你寄送一台加固型 Data Box 设备，其工作方式类似于 NAS。 它的可用容量为 80 TiB。 有关详细信息，请参阅 Data Box 文档。
- Data Box Heavy。 此选项提供一台带轮子的加固型 Data Box 设备，其工作方式类似于 NAS。 该设备容量为 1 PiB。 由于加密和文件系统开销，可用容量大约少 20%。 有关详细信息，请参阅 Data Box Heavy 文档。
第 4 阶段：在本地预配合适的 Windows Server 实例
在等待 Azure Data Box 设备到货期间，你可以开始审查要与 Azure 文件同步配合使用的一个或多个 Windows Server 实例的需求。
- 以虚拟机或物理服务器的形式创建 Windows Server 2019 实例（最低版本为 Windows Server 2012 R2）。 也支持 Windows Server 故障转移群集。
- 预配或添加直接附加存储。 （DAS，与不受支持的 NAS 相对。）
部署的 Windows Server 实例的资源配置（计算和 RAM）主要取决于要同步的文件和文件夹数量。 如果有任何顾虑，我们建议使用性能更高的配置。
了解如何根据需要同步的项数来调整 Windows Server 实例的大小。
注意
前面链接的文章提供了一个表，其中列出了服务器内存 (RAM) 的范围。 可以对你的服务器使用该范围的下限数字，但应该预料到，这会导致初始同步花费的时间显著增加。
第 5 阶段：将文件复制到 Data Box
在 Data Box 到货后，你需要为其设置与 NAS 设备的无阻网络连接。 请按照订购的 Data Box 类型的设置文档进行操作：
根据 Data Box 的类型，可以使用 Data Box 复制工具。 目前，我们不建议使用这些工具迁移到 Azure 文件共享，因为它们不会以全保真度将文件复制到 Data Box。 请改用 Robocopy。
当 Data Box 到货时，其上已预先预配了可供在订购时指定的每个存储帐户使用的 SMB 共享。
- 如果你的文件进入高级 Azure 文件共享，则每个高级“文件存储”存储帐户都将有一个 SMB 共享。
- 如果文件进入标准存储帐户，则每个标准（GPv1 和 GPv2）存储帐户都将有三个 SMB 共享。 只有以
_AzFiles结尾的文件共享才与迁移相关。 请忽略任何块和页 blob 共享。
按照 Azure Data Box 文档中的步骤进行操作：
- 连接到 Data Box。
- 将数据复制到 Data Box。 可以使用 Robocopy（按照以下说明）或新的 Data Box 数据复制服务。
- 准备 Data Box 以上传到 Azure。
提示
作为 Robocopy 的替代方法，Data Box 已创建数据复制服务。 可以使用此服务将文件完全保真地加载到 Data Box 中。 遵循此数据复制服务教程，并确保设置正确的 Azure 文件共享目标。
Data Box 文档指定了一个 Robocopy 命令。 该命令不适合用于保持文件和文件夹的完全保真度。 请改用以下命令：
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），才能正确记录测试结果。 |
/LFSM |
仅适用于具有分层存储的目标。 当目标为远程 SMB 共享位置时则不受支持。 指定 Robocopy 在“低可用空间模式”下运行。此开关仅对具有分层存储且可能会在 Robocopy 完成之前耗尽本地容量的目标有用。 它是专门为启用 Azure 文件同步云分层的目标而添加的。 它可独立于 Azure 文件同步使用。在此模式下，每当文件复制会导致目标卷的可用空间低于“下限”值时，Robocopy 都会暂停。 可通过标志的 /LFSM:n 形式指定此值。 参数 n 在基数 2 nKB、nMB 或 nGB 中指定。 如果指定的 /LFSM 没有明确的下限值，则下限将设置为目标卷大小的 10%。 低可用空间模式与 /MT、/EFSRAW 或 /ZB 不兼容。 Windows Server 2022 中添加了对 /B 的支持。 请参阅下面的 Windows Server 2022 和 RoboCopy LFSM 部分了解详细信息，包括有关相关 bug 和解决方法的详细信息。 |
/Z |
谨慎使用在重启模式下复制文件。 只有在不稳定的网络环境下，才建议使用此开关。 由于额外的日志记录，此开关会明显降低复制性能。 |
/ZB |
谨慎使用使用重启模式。 如果访问被拒绝，此选项将使用备份模式。 由于检查点，此选项会明显降低复制性能。 |
重要
建议使用 Windows Server 2022。 使用 Windows Server 2019 时，请确保使用最新的修补程序级别或者至少安装了 OS 更新 KB5005103。 它包含适用于某些 Robocopy 方案的重要修补程序。
第 6 阶段：部署 Azure 文件同步云资源
在继续学习本指南之前，请等待所有文件均已进入正确的 Azure 文件共享。 传输和引入 Data Box 数据的过程需要一段时间。
要完成此步骤，你需要 Azure 订阅凭据。
为 Azure 文件同步配置的核心资源称为存储同步服务。 建议只为当前或将来同步同一组文件的所有服务器部署一项存储同步服务。 仅当有不同的服务器组，且这些服务器永不交换数据时，才创建多项存储同步服务。 例如，你可能有一些绝不会同步同一个 Azure 文件共享的服务器。 否则，最佳做法是使用一项存储同步服务。
为存储同步服务选择一个离你的位置最近的 Azure 区域。 所有其他云资源必须部署在同一区域中。 若要简化管理，请在订阅中创建一个包含同步和存储资源的新资源组。
有关详细信息，请参阅有关部署 Azure 文件同步的文章中关于部署存储同步服务的部分。请严格按照这部分内容操作。 后续步骤中有这篇文章其他部分的链接。
第 7 阶段：部署 Azure 文件同步代理
在本部分中，你将在 Windows Server 实例上安装 Azure 文件同步代理。
部署指南说明了需要关闭“Internet Explorer 增强的安全性配置”。 此安全措施不适用于 Azure 文件同步。将其关闭后，可以对 Azure 进行身份验证，而不会出现任何问题。
打开 PowerShell。 使用以下命令安装所需的 PowerShell 模块。 请确保按照提示安装完整的模块和 NuGet 提供程序。
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
如果从服务器访问 Internet 时遇到任何问题，现在可以解决这些问题。 Azure 文件同步使用与 Internet 的任何可用网络连接。 还支持要求代理服务器访问 Internet。 可以立即配置计算机范围的代理，也可以在代理安装期间指定仅由 Azure 文件同步使用的代理。
如果配置代理意味着需要为服务器打开防火墙，那么这种方法可能适合你。 服务器安装结束时，在完成服务器注册后，会有一个网络连接报表精确显示所选区域中 Azure 文件同步需要与之通信的 Azure 中的终结点 URL。 该报告还会告诉你需要进行通信的原因。 可以使用该报告将服务器上的防火墙锁定到特定的 URL。
还可以采用相对保守的方法，就是不完全打开防火墙。 可以改为限制服务器与更高级别的 DNS 命名空间进行通信。 有关详细信息，请参阅 Azure 文件同步代理和防火墙设置。 遵循自己的网络最佳做法。
在服务器安装向导结束时，将打开一个服务器注册向导。 从一开始将服务器注册到存储同步服务的 Azure 资源。
部署指南中详细地介绍了这些步骤，其中包含要首先安装的 PowerShell 模块：Azure 文件同步代理安装。
使用最新的代理。 可以从 Microsoft 下载中心下载：Azure 文件同步代理。
成功安装并注册服务器后，可以确认是否已成功完成此步骤。 转到 Azure 门户中的存储同步服务资源。 在左侧菜单中，转到“已注册的服务器”。 你将看到你的服务器已在此处列出。
第 8 阶段：在 Windows Server 实例上配置 Azure 文件同步
要完成此过程，已注册的本地 Windows Server 实例必须准备就绪，并已连接到 Internet。
此步骤将前面步骤中在 Windows Server 实例中设置的所有资源和文件夹绑定在一起。
- 登录 Azure 门户。
- 找到你的存储同步服务资源。
- 在每个 Azure 文件共享的存储同步服务资源中创建一个新的同步组。 在 Azure 文件同步术语中，Azure 文件共享是你在创建同步组时所述的同步拓扑中的云终结点。 在创建同步组时，为它提供一个熟悉的名称，便于你识别在那里同步的是哪组文件。 请确保引用具有匹配名称的 Azure 文件共享。
- 创建同步组后，该同步组的行会显示在同步组列表中。 选择名称（链接）可显示同步组的内容。 你将在“云终结点”下看到你的 Azure 文件共享。
- 找到“添加服务器终结点”按钮。 你在本地服务器上预配的文件夹将成为此服务器终结点的路径。
启用云分层功能，并在“初始下载”部分选择“仅限命名空间”。
重要
云分层是一项 Azure 文件同步功能，它允许本地服务器的存储容量小于云中的存储容量但本地服务器仍然有完整的命名空间可用。 在本地有用的数据也缓存在本地，以实现快速访问性能。 云分层是可选的。 可为每个 Azure 文件同步服务器终结点单独设置此功能。 如果 Windows Server 实例上没有足够的本地磁盘容量用于保存所有云数据，并且你想要避免从云中下载所有数据，则需要使用此功能。
针对需要进行配置以便同步的所有 Azure 文件共享/服务器位置，请重复相关步骤来创建同步组并添加匹配的服务器文件夹作为服务器终结点。 等待命名空间的同步完成。 以下部分将会介绍如何确保同步完成。
注意
创建服务器终结点后，将开始进行同步。 但是，同步需要枚举（发现）你通过 Data Box 移到 Azure 文件共享中的文件和文件夹。 因此，可能需要经过很长时间，云中的命名空间才会出现在服务器上，具体取决于命名空间的大小。
第 9 阶段：等待命名空间完全出现在服务器上
在继续执行后续的迁移步骤之前，请等待服务器已完全从云共享下载命名空间。 如果过早地开始将文件移到服务器上，将会造成不必要的上传甚至文件同步冲突。
若要确定服务器是否已完成初始下载同步，请在正在执行同步的 Windows Server 实例上打开事件查看器，并使用 Azure 文件同步遥测事件日志。 遥测事件日志位于事件查看器中的“应用程序和服务\Microsoft\FileSync\代理”下。
搜索最近的 9102 事件。
同步会话完成后，将记录事件 ID 9102。 事件文本中有一个表示下载同步方向的字段。 （HResult 需为零，文件需要下载。）
需要看到两个连续的此类型事件（包含此内容），才能确保服务器已完成命名空间的下载。 如果两个 9102 事件之间存在其他事件，也是没有问题的。
第 10 阶段：从 NAS 运行 Robocopy
在服务器完成从云共享初始同步整个命名空间后，你可以继续执行此步骤。 必须先完成初始同步才能继续执行此步骤。 有关详细信息，请参阅前一部分。
在此步骤中，你将运行 Robocopy 作业，以将云共享（其中包含自从创建共享分支以来在 NAS 上所做的最新更改）同步到 Data Box。 此次 Robocopy 运行可能很快就能完成，也可能需要一些时间，具体取决于 NAS 共享上发生的数据变动量。
警告
由于 Windows Server 2019 中的回归 Robocopy 行为，Robocopy 的 /MIR 开关与分层目标目录不兼容。 在此迁移阶段，不能使用 Windows Server 2019 或 Windows 10 客户端。 请在中间 Windows Server 2016 实例上使用 Robocopy。
下面是基本迁移方法：
- 在 NAS 设备上运行 Robocopy 以同步 Windows Server 实例。
- 使用 Azure 文件同步从 Windows Server 同步 Azure 文件共享。
运行首次本地复制，以复制到 Windows Server 目标文件夹：
- 标识 NAS 设备上的第一个位置。
- 标识已配置 Azure 文件同步的 Windows Server 实例上的匹配文件夹。
- 开始使用 Robocopy 进行复制。
以下 Robocopy 命令仅将差异内容（更新的文件和文件夹）从 NAS 存储复制到 Windows Server 目标文件夹。 然后，Windows Server 实例会将其同步到 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），才能正确记录测试结果。 |
/LFSM |
仅适用于具有分层存储的目标。 当目标为远程 SMB 共享位置时则不受支持。 指定 Robocopy 在“低可用空间模式”下运行。此开关仅对具有分层存储且可能会在 Robocopy 完成之前耗尽本地容量的目标有用。 它是专门为启用 Azure 文件同步云分层的目标而添加的。 它可独立于 Azure 文件同步使用。在此模式下，每当文件复制会导致目标卷的可用空间低于“下限”值时，Robocopy 都会暂停。 可通过标志的 /LFSM:n 形式指定此值。 参数 n 在基数 2 nKB、nMB 或 nGB 中指定。 如果指定的 /LFSM 没有明确的下限值，则下限将设置为目标卷大小的 10%。 低可用空间模式与 /MT、/EFSRAW 或 /ZB 不兼容。 Windows Server 2022 中添加了对 /B 的支持。 请参阅下面的 Windows Server 2022 和 RoboCopy LFSM 部分了解详细信息，包括有关相关 bug 和解决方法的详细信息。 |
/Z |
谨慎使用在重启模式下复制文件。 只有在不稳定的网络环境下，才建议使用此开关。 由于额外的日志记录，此开关会明显降低复制性能。 |
/ZB |
谨慎使用使用重启模式。 如果访问被拒绝，此选项将使用备份模式。 由于检查点，此选项会明显降低复制性能。 |
重要
建议使用 Windows Server 2022。 使用 Windows Server 2019 时，请确保使用最新的修补程序级别或者至少安装了 OS 更新 KB5005103。 它包含适用于某些 Robocopy 方案的重要修补程序。
如果在 Windows Server 实例上预配的存储量小于你的文件在 NAS 设备上使用的存储量，则已配置云分层。 当本地 Windows Server 卷已满时，将启动云分层，并对已成功同步的文件进行分层。 云分层将生成足够的空间，以便继续从 NAS 设备进行复制。 云分层每小时检查一次，以确定哪些内容已同步，并释放磁盘空间来使卷可用空间达到 99%。
Robocopy 需要移动的文件数可能会超过可在 Windows Server 实例本地存储的文件数。 Robocopy 移动内容的速度可能会比 Azure 文件同步上传文件并将其分层到本地卷之外的速度更快。 在这种情况下，Robocopy 将会失败。 我们建议以一种可以防止出现这种情况的顺序来处理共享。 例如，只移动 Windows Server 实例上的可用空间能够容纳的共享。 或者避免同时为所有共享启动 Robocopy 作业。 好消息是，/MIR 开关能够确保仅移动增量内容。 移动增量内容后，重启的作业不需要再次移动该文件。
执行切换
首次运行 Robocopy 命令时，用户和应用程序仍会访问 NAS 上的文件，并可能会更改这些文件。 Robocopy 将处理一个目录，接着处理下一个目录。 然后，NAS 上的用户可能会在第一个目录中添加、更改或删除某个在当前 Robocopy 运行期间不会处理的文件。 这是预期的行为。
首次运行涉及到将大量变动的数据通过 Azure 文件同步移到 Windows Server 实例和云中。首次复制可能需要很长时间，具体取决于：
- 上传带宽。
- 本地网络速度，以及 Robocopy 线程数与之匹配的情况。
- Robocopy 和 Azure 文件同步需要处理的项（文件和文件夹）的数量。
在初始运行完成后，再次运行该命令。
第二次针对共享运行 Robocopy 将会更快地完成。 Robocopy 只需传输自上次运行后发生的更改。 可以为同一共享运行重复的作业。
如果你认为停机时间可接受，则需要删除用户对基于 NAS 的共享的访问权限。 可以采取任何防止用户更改文件和文件夹的结构及内容的方式来完成此操作。 例如，可将 DFS 命名空间指向某个不存在的位置，或者更改共享上的根 ACL。
最后一次运行 Robocopy。 Robocopy 将拾取已遗漏的任何更改。 这最后一步所花费的时间取决于 Robocopy 的扫描速度。 可以通过测量上次运行的时长来估算该时间（相当于停机时间）。
在 Windows Server 文件夹上创建一个共享，并根据需要调整 DFS-N 部署来指向该文件夹。 请务必设置与 NAS SMB 共享上相同的共享级别权限。 如果你有一个已加入域的企业级 NAS，则用户 SID 将自动匹配，因为用户在 Active Directory 中，而 Robocopy 以全保真度复制文件和元数据。 如果在 NAS 上使用了本地用户，则需要：
- 重新创建这些用户作为 Windows Server 本地用户。
- 将已由 Robocopy 移到 Windows Server 实例的现有 SID 映射到新 Windows Server 本地用户的 SID。
现已完成将一个共享或一组共享迁移到通用根目录或卷（具体取决于第 1 阶段中的映射）的过程。
你可以尝试并行运行其中的几个副本。 建议每次处理一个 Azure 文件共享的范围。
弃用的选项：“脱机数据传输”
在 Azure 文件同步代理版本 13 之前，Data Box 集成是通过名为“脱机数据传输”的过程完成的。 此过程已被弃用。 在代理版本 13 中，此过程已替换为本文中所述的更简单、更快速的步骤。 如果知道要使用已弃用的“脱机数据传输”功能，仍可以这样做。 仍然可以通过使用特定的较旧的 AFS PowerShell 模块来使用此过程：
Install-Module Az.StorageSync -RequiredVersion 1.4.0
Import-module Az.StorageSync -RequiredVersion 1.4.0
# Verify the specific version is loaded:
Get-module Az.StorageSync
警告
2022 年 5 月 15 日之后，将无法再在“脱机数据传输”模式下创建服务器终结点。 使用此方法进行的迁移必须在 2022 年 7 月 15 日之前完成。 如果继续使用启用了“脱机数据传输”的服务器终结点运行迁移，则服务器将在 2022 年 7 月 15 日开始从服务器上传剩余文件，并不再利用使用 Azure Data Box 传输到暂存共享的文件。
疑难解答
最常见的问题是在 Windows Server 端运行 Robocopy 命令失败并出现“卷已满”消息。 云分层每小时进行一次，以从本地 Windows Server 磁盘中撤出已同步的内容。 其目标是使卷上的可用空间达到 99%。
让同步继续进行并让云分层释放磁盘空间。 可以在 Windows Server 实例上的文件资源管理器中观察该进度。
当 Windows Server 实例有足够的可用容量时，再次运行该命令即可解决问题。 遇到这种情况时，不会有任何中断。 可以放心地继续操作。 再次运行该命令只会带来不便。
若要排查 Azure 文件同步问题，请参阅下一部分列出的文章。
后续步骤
对于 Azure 文件共享和 Azure 文件同步，有更多的知识有待探索。以下文章可帮助你了解高级选项和最佳做法。 其中还提供了故障排除方面的帮助。 在适当的情况下，这些文章会包含 Azure 文件共享文档的链接。