使用Azure Data Box将数据脱机迁移到Azure 文件同步

本文介绍如何使用 Azure Data Box 将数据从本地 Windows Server 批量迁移到 Azure 文件共享，然后在源服务器上设置 Azure 文件同步 以实现持续同步。 请检查本文是否适用于你的场景：

本迁移指南中所述的三个依序步骤的示意图。插图旁边的栏详细描述了每个步骤。

  • 数据来源：Windows Server 2016 或更新版本，安装 Azure 文件同步 并指向原始文件集。
  • 迁移路径：Windows Server 2016 或更高版本 ⇒ Data Box ⇒ Azure 文件共享 ⇒ 与 Windows Server 上的原始文件位置同步
  • 在本地缓存文件：是的，最终目标是部署 Azure 文件同步，以从文件当前所在位置同步这些文件。

使用 Azure Data Box 是一个可行的路径，可将大量数据从本地Windows Server移动到单独的Azure文件共享，然后（可选）在原始源服务器上添加Azure 文件同步。

你有不同的迁移路径可供选择。 遵循正确的原则非常重要：

  • 你的数据存储在Windows Server 2016或更新的服务器上，你计划在该服务器上安装Azure 文件同步并同步原始位置。 在这种情况下，你不会希望上传所有文件，你会选择使用 Data Box，然后使用文件同步来管理持续的更改。 如果你的方案是这样，可以参考本文中所述的迁移路径。
  • 你的数据位于某个无法或不愿安装 Azure 文件同步 的源上，例如网络附加存储 (NAS) 设备或其他服务器。 相反，创建一个新的空服务器，并在该服务器上使用 Azure 文件同步。 如果你的方案是这样，则本迁移指南并不适合你。 相反，请查看“通过Data Box从NAS迁移到Azure 文件同步”，或者在迁移概览页面找到最适合你场景的指南。
  • 对于其他所有场景，请查看Azure文件共享迁移指南表，该表为所有迁移场景提供了良好的起点。

迁移概述

迁移过程包括多个阶段。 您需要：

  • 部署存储帐户和文件共享。
  • 部署一台或多台 Azure Data Box 设备，将数据从你的 Windows Server 2016 或更新版本迁移。
  • 使用权威上传配置Azure 文件同步。

以下各部分详细介绍了迁移过程的各个阶段。

阶段 1：确定所需的Azure文件共享数

在本迁移指南中，必须继续使用包含你的文件的本地直接附加存储 (DAS)。 Data Box 将从该位置馈送，Azure 文件同步也将在该位置上设置。 NAS（网络附加存储）不适用于此迁移路径。

可以通过设置 Azure 文件同步 sync groups 来确定哪些同步，每个组确定一组文件之间的同步位置。 每个同步组至少有一个服务器位置，称为服务器终结点和一个Azure文件共享，称为 cloud 终结点。

可以将一组文件的子路径同步到其自己的Azure文件共享。 这种设置意味着需要多个同步组来完全覆盖一组文件。 本部分的余下部分将介绍您的选择。 如果你需要重构数据，请在继续本指南前进行，订购数据盒或设置同步。

注意

在开始迁移前，确保你的文件和文件夹结构符合你想要的长期状态。 在迁移过程中避免不必要的文件夹重组。 这种重组降低了使用 Azure Data Box 进行初始批量文件传输到 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 中的 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文件共享而不是一个。 可以使用此方法使每个文件共享的文件和文件夹数在服务器间保持平衡。 您还可以分配本地共享，并跨更多本地服务器进行同步，以便每个额外服务器能够同步多达 30 个 Azure 文件共享。

重要

Azure 文件同步最重要的缩放向量是需要同步的项目数（文件和文件夹）。 有关详细信息，请查看 Azure 文件同步 缩放目标。

常见文件同步方案和注意事项

同步场景 支持 注意事项（或限制） 解决方案（或解决方法）
具有多个磁盘/卷和多个共享的文件服务器到同一目标Azure文件共享（合并） 否 目标Azure文件共享（云终结点）仅支持与一个同步组同步。

同步组仅支持每个已注册的服务器一个服务器终结点。		 1） 首先将一个磁盘（其根卷）同步到目标Azure文件共享。 从最大的磁盘/卷开始，将帮助满足本地存储要求。 配置云分层以将所有数据分层到云，以便释放文件服务器磁盘上的空间。 将数据从其他磁盘分区/共享移动到正在同步的当前分区。 一个接一个地继续执行步骤，直到所有数据分层到云或迁移。
2) 每次以一个根卷（磁盘）为目标。 使用云分层将所有数据分层到目标Azure文件共享。 从同步组中删除服务器终结点，使用下一个根卷/磁盘重新创建终结点，同步，然后重复此过程。 请注意，可能需要重新安装代理。
3） 建议根据性能要求使用多个目标Azure文件共享（相同或不同的存储帐户）。
带有单个卷和多个共享的文件服务器，指向同一目标的 Azure 文件共享（合并） 是 对于每个已注册的服务器，不能有多个服务器终结点同步到同一目标 Azure 文件共享（与前面的方案相同）。 同步多个共享或顶级文件夹所在卷的根目录。
具有多共享和/或多卷的文件服务器映射到一个存储帐户下的多个 Azure 文件共享（1:1 共享映射） 是 单个Windows Server实例（或群集）最多可以同步 30 个Azure文件共享。

存储帐户是性能评估的目标。 IOPS 和吞吐量在文件共享之间共享。

将每个同步组的项目数保持在每个共享的 1 亿个项目（文件和文件夹）内。 最好保持低于每股 20 或 3000 万。		 1） 使用多个同步组（同步组数 = 要同步到的Azure文件共享数）。
2）在此方案中，一次只能同步 30 个份额。 如果该文件服务器上的共享数超过 30 个，请使用共享分组和卷同步来减少源中根文件夹或顶级文件夹的数量。
3） 在本地使用其他Azure 文件同步服务器，并将数据拆分或移动到这些服务器，以解决源Windows Server实例的限制。
具有多个共享和/或卷的文件服务器，将多个 Azure 文件共享映射到不同存储帐户下的各个 Azure 文件共享（1:1 映射） 是 单个Windows Server实例（或群集）最多可以同步 30 个Azure文件共享（相同或不同的存储帐户）。

将每个同步组的项目数保持在每个共享的 1 亿个项目（文件和文件夹）内。 最好保持低于每股 20 或 3000 万。		 与前面的方法相同。
具有单个根卷或共享目录的多个文件服务器将合并到同一目标 Azure 文件共享中 否 同步组无法使用已在另一个同步组中配置的云终结点（Azure文件共享）。

尽管同步组可以在不同的文件服务器上具有服务器终结点，但文件不能不同。		 按照第一个方案中的指导进行操作，并额外考虑一次只针对一个文件服务器。
跨租户拓扑（在租户间使用托管身份验证） 否 存储同步服务、服务器资源（Azure Arc启用的服务器或Azure VM）、存储帐户上的托管标识和 RBAC 分配必须全部位于同一Microsoft Entra租户中。 不支持跨租户拓扑。 跨租户设置会失败身份验证和授权，服务器无法连接。 若要继续，请确保在同一 Microsoft Entra 租户中创建所有资源（同步服务、服务器、托管标识和 RBAC 分配）。

创建映射表

显示映射表示例的图表。下载以下文件以查看和使用此图像的内容。

使用前面的信息来确定您需要多少个Azure文件共享，以及现有数据的哪些部分将最终存储于哪个Azure文件共享中。

创建一个表来记录你的想法，以便在需要时引用它。 保持井然有序非常重要，因为在同时配置许多 Azure 资源时，可能会容易丢失映射计划的详细信息。

阶段 2：部署Azure存储资源

在此阶段中，请查阅阶段 1 中的映射表，并使用它来预配其中正确的Azure存储帐户和文件共享数。

Azure文件共享存储在Azure存储帐户中的云中。 此处还有另一层次的性能考量需应用。

如果你有高度活跃的共享（许多用户和/或应用程序使用的共享），则两个Azure文件共享可能会达到存储帐户的性能限制。

最佳做法是在部署存储帐户时，让每个存储帐户都有一个文件共享。 如果您有归档文件共享或预期这些文件共享的日常活动量低，则可以将多个 Azure 文件共享汇集到同一个存储帐户中。

与Azure 文件同步相比，这些注意事项更适用于直接云访问（通过Azure VM）。如果计划只对这些共享使用Azure 文件同步，可将多个共享分组到单个Azure存储帐户中。

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

在上一阶段中，你确定了适当数量的股份。 在此步骤中，你可以将存储帐户映射到文件共享。 现在，部署相应数量的Azure存储帐户，并在其中部署相应数量的Azure文件共享。

请确保每个存储帐户的区域相同，并且与已部署的存储同步服务资源的区域相匹配。

注意

如果创建具有 100 TiB 限制的Azure文件共享，该共享只能使用本地冗余存储或区域冗余存储冗余选项。 使用 100 TiB 的文件共享之前，应考虑自己的存储冗余需求。

默认情况下，Azure文件共享仍使用 5 TiB 限制创建。 按照 创建Azure文件共享中的步骤创建大型文件共享。

部署存储帐户时的另一个注意事项是Azure 存储冗余。 请参阅 Azure 存储 冗余选项。

资源的名称也很重要。 例如，如果将 HR 部门的多个共享分组到Azure存储帐户中，则应相应地命名存储帐户。 同样，在为Azure文件共享命名时，应使用类似于本地对应项的名称。

阶段 3：确定所需的Azure Data Box设备数

请仅在完成上一阶段后，才开始执行此步骤。 此时应创建Azure存储资源（存储帐户和文件共享）。 订购 Data Box 时，需指定 Data Box 要将数据移到哪些存储帐户。

在此阶段，将上一阶段迁移计划的结果映射到可用数据盒选项的极限。 这些因素帮助你制定计划，决定选择哪些数据盒选项，以及需要多少选项才能将服务器共享迁移到Azure文件共享。

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

  • 任何Azure Data Box设备都可以将数据移到最多 10 个存储帐户中。
  • 每个 Data Box 选项都有其自己的可用容量。 请参阅 Data Box 选项。

请参阅您的迁移计划，了解您决定创建的存储账户数量及每个账户中的份额。 然后查看服务器上各个共享项的大小。 结合这些信息，你可以优化并决定哪台设备应该向哪个存储账户发送数据。 可以使用两台 Data Box 设备将文件移到同一存储帐户中，但不要将单个文件共享的内容拆分到两台 Data Box 设备中。

Data Box 选项

对于标准迁移，请选择以下三个 Data Box 选项中的一个或多个：

Option Description 可用容量 详细信息
Data Box 磁盘 Azure 会向你寄送 1 到 5 块 SSD 磁盘，每块容量均为 8 TiB，总容量最多为 40 TiB。 由于加密和文件系统开销，容量比原始容量大约少20%。 Data Box Disk 文档
数据盒 最常见的选择。 Azure 会向你寄送一台加固型设备，其工作方式与 NAS 类似。 80、120或525 TiB，具体取决于SKU不同。 Data Box 文档

注意

对于 Data Box，仅支持通过 SMB 复制数据。 通过数据复制服务不支持复制数据，因为这无法保持文件的完整性。

第 4 阶段：将文件复制到 Data Box

当您的 Data Box 送达后，请进行设置，并确保其与您的 Windows Server 之间的网络连接畅通无阻。 请按照订购的 Data Box 类型的设置文档进行操作：

根据 Data Box 的类型，可以使用 Data Box 复制工具。 这些工具不推荐用于迁移到 Azure 文件共享，因为它们不会以完整的方式将你的文件复制到 Data Box。 请改用 Robocopy。

当 Data Box 到货时，其上已预先预配了可供在订购时指定的每个存储帐户使用的 SMB 共享。

  • 如果你的文件存储在 SSD Azure 文件共享中，则每个 SSD“FileStorage”存储帐户都对应一个 SMB 共享。
  • 如果文件进入 HDD 存储帐户，那么每个 HDD 按需付费存储帐户将拥有三个 SMB 共享。 只有以 _AzFiles 结尾的文件共享才与迁移相关。 请忽略掉任何块 Blob 和页 Blob 共享。

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

  1. 连接到 Data Box。
  2. 将数据复制到 Data Box。
  3. 准备“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 命令。 如果使用 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），才能正确记录测试结果。
/LFSM 仅适用于具有分层存储的目标。 当目标为远程 SMB 共享位置时则不受支持。
指定 Robocopy 在“低可用空间模式”下运行。此开关可对具有分层存储的目标有用，这些目标可能会在 Robocopy 完成之前耗尽本地容量。 它专为使用配置了Azure 文件同步云分层的目标环境而添加。 它可以独立于 Azure 文件同步 使用。在此模式下，每当文件复制会导致目标卷的可用空间低于“最低值”时，Robocopy 都会暂停。 可通过标志的 /LFSM:n 形式指定此值。 参数 n 在基数 2 nKB、nMB 或 nGB 中指定。 如果指定的 /LFSM 没有明确的下限值，则下限将设置为目标卷大小的 10%。 低可用空间模式与 /MT、/EFSRAW 或 /ZB 不兼容。 Windows Server 2022中添加了对 /B 的支持。 有关相关 bug 和解决方法的详细信息，请参阅下面的Windows Server 2022和 RoboCopy LFSM 部分。
/Z 谨慎使用在重启模式下复制文件
。 只有在不稳定的网络环境下，才建议使用此开关。 由于额外的日志记录，复制性能会显著下降。
/ZB 谨慎使用
采用重启模式。 如果访问被拒绝，此选项将使用备份模式。 由于检查点过程，此选项会明显降低复制性能。

重要

建议使用Windows Server 2022。 使用Windows Server 2019时，请确保安装最新的修补程序级别或至少OS 更新KB5005103。 它包含适用于特定 Robocopy 场景的重要修补程序。

RoboCopy 可能会报告即使不需要数据传输，也复制了文件。 发生此行为的原因是 robocopy 在生成输出时会评估文件数据和元数据的更改。 若要正确解释结果，请查看命令输出中的文件状态：

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

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

阶段 5：部署Azure 文件同步云资源

在继续本指南之前，请等待所有文件到达正确的 Azure 文件共享。 传输和引入 Data Box 数据的过程需要一段时间。

要为Azure 文件同步配置的核心资源称为 Storage Sync Service。 建议只为当前或将来同步同一组文件的所有服务器部署一个服务。 仅当有不同的服务器组，且这些服务器永不交换数据时，才创建多项存储同步服务。 例如，你可能有些服务器必须始终不同步同一个 Azure 文件共享。 否则，最佳做法是使用一项存储同步服务。

选择一个靠近您位置的 Azure 区域用于存储同步服务。 所有其他云资源必须部署在同一区域中。 若要简化管理，请在订阅中创建一个包含同步和存储资源的新资源组。

有关详细信息，请参阅有关部署 Azure 文件同步 的文章中关于部署 Storage Sync Service 的 部分。请只遵循文章的此部分。 在后续步骤中，将有该文章内容其他部分的链接。

阶段 6：部署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门户中的存储同步服务资源。 在左侧菜单中，转到“已注册的服务器”。 你将看到你的服务器已在此处列出。

阶段 7：在现有Windows Server上配置Azure 文件同步

注册的本地Windows Server实例必须准备好并连接到 Internet 才能完成此过程。

此步骤将前面步骤中在Windows Server实例上设置的所有资源和文件夹关联在一起。

  1. 登录到 Azure 门户。
  2. 找到你的存储同步服务资源。
  3. 为每个Azure文件共享在存储同步服务资源中创建一个新的 sync group。 在 Azure 文件同步 术语中，Azure 文件共享将在您通过创建同步组描述的同步拓扑中成为一个云终结点。 在创建同步组时，为它提供一个熟悉的名称，便于你识别在那里同步的是哪组文件。 请确保引用具有匹配名称的 Azure 文件共享。
  4. 创建同步组后，该同步组会作为一列显示在同步组列表中。 选择名称（链接）可显示同步组的内容。 你将在 Cloud 终结点下看到 Azure 文件共享。
  5. 找到“添加服务器端点”按钮。 你在本地服务器上预配的文件夹将成为此服务器终结点的路径。

图中显示了 Azure 门户中“创建服务器终结点”向导的一个部分。其中一个复选框已被高亮显示，该复选框对应于使用数据为 Azure 文件共享进行初始填充的场景。如果你要将 Azure 文件同步连接到与之前复制到 Data Box 时相同的本地位置，请选中此复选框。

进入“创建服务器终结点”向导后，利用文件夹路径下提供的复选框。 仅当已输入的路径指向的文件和文件夹结构与 Azure 文件共享中的结构（Data Box 已将文件和文件夹移入此命名空间）相同，才进行此项选择。

如果文件夹层次结构不匹配，则此问题将显示为无法自动解决的差异。 请避免出现不匹配的情况，否则为 Data Box 流程所做的任何投入都不会产生回报。 所有数据都将在Azure文件共享中删除。 需要从本地服务器上传所有数据。 目录结构必须匹配，以便通过Azure Data Box进行批量迁移，并使用服务器的最新更改无缝更新云共享。

注意

启用此复选框会将初始同步模式设置为以本服务器路径中的内容为准，权威性地覆盖Azure文件共享中的文件和文件夹。此选项仅适用于同步组中的第一个服务器终结点。

为新的服务器终结点配置权威上传后，可以可选地启用云分层。

云分层是Azure 文件同步的一个功能，它允许本地服务器的存储容量小于云中存储的容量，但仍具有完整的命名空间可用。 在本地有用的数据也缓存在本地，以实现快速访问性能。 云分层是可选的。 可以为每个Azure 文件同步服务器终结点单独设置它。 使用此功能可使本地存储占用空间保持固定，同时仍为用户提供本地性能缓存，并在云中存储冷数据。

欲了解更多信息，请参阅 云分层概览 ，或仔细查看可用于微调本地服务器缓存和分层内容的不同 云分层策略 。

完成迁移

创建服务器端点后，同步功能正常。 但同步仍需要枚举（发现）你通过 Azure Data Box 移动到 Azure 文件共享中的文件和文件夹。 根据命名空间的大小，服务器上的最新更改同步到云端可能需要很长时间。 你的用户不受影响，可以继续使用服务器上的数据。 此策略可实现零停机时间的云迁移。

对于需要配置同步的所有Azure文件共享/服务器位置，请重复创建同步组的步骤，并将匹配的服务器文件夹添加为服务器终结点。 你使用了Azure Data Box将文件移动到多个Azure文件共享中。 创建将本地数据连接到这些Azure文件共享的所有服务器终结点后，即可完成迁移。

后续步骤

关于Azure文件共享和Azure 文件同步，还有更多值得探索的内容。以下文章将帮助您了解高级选项、最佳实践和故障排除方法。 这些文章包含Azure文件共享文档的链接（如果适用）。

  • Last updated on