排查在 Azure 备份中备份文件和文件夹时速度缓慢的问题

本文提供故障排除指导,帮助你诊断使用 Azure 备份来备份文件和文件夹时备份性能缓慢的原因。 使用 Azure 备份代理备份文件时,备份过程花费的时间可能比预期要长。 这种延迟可能由以下一个或多个原因所造成:

在开始排查问题之前,建议下载并安装最新的 Azure 备份代理。 我们经常更新备份代理,以修复各种问题、添加功能和改善性能。

此外,我们强烈建议查看 Azure Backup service FAQ(Azure 备份服务常见问题),确保所遇到的问题并非任何常见配置问题。

如果本文未解决 Azure 问题,请访问 Microsoft Q&A 和 Stack Overflow 上的 Azure 论坛。 可以在这些论坛上发布问题。 还可提交 Azure 支持请求。 若要提交支持请求,请在 Azure 支持页上提交。

原因:备份作业在未优化模式下运行

  • MARS 代理可以使用 USN(更新序列号)变更日志在优化模式下运行备份作业,也可以通过扫描整个卷来检查目录或文件的更改,在未优化模式下运行备份作业 。

  • 未优化模式的速度较慢,因为代理必须扫描卷上的每个文件,并与元数据进行比较以确定更改的文件。

  • 如需验证运行模式,请从 MARS 代理控制台打开“作业详细信息”并检查状态,查看是否显示“正在传输数据(未优化,可能需要更长时间)”,如下所示:

    Screenshot shows backup jobs running in unoptimized mode.

  • 在以下条件下,备份作业会以未优化模式执行:

    • 首次备份(也称为初始复制)将始终在未优化模式下运行。
    • 如果上一个备份作业失败,则下一个计划的备份作业将在未优化模式下运行。

原因:计算机存在性能瓶颈

正在备份的计算机上可能有一些瓶颈导致延迟。 例如,计算机读取或写入到磁盘的能力、用于通过网络发送数据的带宽,都可能会造成瓶颈。

Windows 提供了内置工具性能监视器 (Perfmon) 来检测这些瓶颈。

下面列出的一些性能计数器和范围可帮助你诊断瓶颈,并获得最佳备份性能。

计数器 状态
逻辑磁盘(物理磁盘)--空闲率
  • 100% 空闲率到 50% 空闲率 = 正常
  • 49% 空闲率到 20% 空闲率 = 警告或监视
  • 19% 空闲率到 0% 空闲率 = 严重或超出规范
  • 逻辑磁盘(物理磁盘)--平均百分比磁盘读取或写入速率(秒)
  • 0.001 毫秒到 0.015 毫秒 = 正常
  • 0.015 毫秒到 0.025 毫秒 = 警告或监视
  • 0.026 毫秒以上 = 严重或超出规范
  • 逻辑磁盘(物理磁盘)--当前磁盘队列长度(适用于所有实例) 80 个请求超过 6 分钟
    内存--池未分页字节
  • 消耗不到 60% 的池 = 正常
  • 消耗 61% - 80% 的池 = 警告或监视
  • 消耗超过 80% 的池 = 严重或超出规范
  • 内存--池分页字节
  • 消耗不到 60% 的池 = 正常
  • 消耗 61% - 80% 的池 = 警告或监视
  • 消耗超过 80% 的池 = 严重或超出规范
  • 内存--可用 MB
  • 50% 或更多的内存可用 = 正常
  • 25% 的内存可用 = 监视
  • 10% 的内存可用 = 警告
  • 不到 100 MB 或 5% 的内存可用 = 严重或超出规范
  • 处理器--处理器时间百分比(所有实例)
  • 消耗不到 60% = 正常
  • 消耗 61% - 90% = 监视或注意
  • 消耗 91% - 100% = 严重
  • 注意

    如果判定罪魁祸首是基础结构,建议定期进行磁盘碎片整理以提高性能。

    原因:其他进程或防病毒软件干扰 Azure 备份

    在许多场合中,我们发现 Windows 系统中的其他进程对 Azure 备份代理进程的性能造成负面影响。 例如,如果同时使用 Azure 备份代理和其他程序来备份数据,或者防病毒软件正在运行,因而锁定了要备份的文件,则文件中的多个锁可能会造成资源争用。 在此情况下,备份可能失败,或者作业花费的时间可能长于预期。

    在这种情况下,建议的最佳做法是关闭其他备份程序,并观察 Azure 备份代理的备份时间是否有所变化。 一般情况下,确保多个备份作业不在同一时间运行,就足以防止作业彼此干扰。

    如果你在服务器上安装了防病毒软件,请针对以下项将排除规则添加到防病毒扫描中:

    • scratch 和 bin 文件夹位置(<InstallPath>\Scratch\*<InstallPath>\Bin\*)下的每个文件和文件夹。
    • cbengine.exe

    原因:备份代理在 Azure 虚拟机上运行

    如果在 VM 上运行备份代理,其性能比在物理机上运行要慢。 这是预期行为,因为存在 IOPS 限制。 但是,可以通过将正在备份的数据驱动器切换到 Azure 高级存储来优化性能。 我们正在努力解决此问题,将来的版本将有这方面的修复。

    原因:备份的文件数过大(数百万个)

    移动大量数据所花费的时间比移动少量数据要长。 但在某些情况下,备份时间不仅与数据大小相关,也与文件或文件夹数目相关。 在备份几百万个小型文件(几个字节到几 KB)时更是如此。

    出现此行为是因为,尽管我们是在备份数据并将它转到 Azure,但我们同时也在为文件创建目录。 在某些罕见的情况下,目录操作花费的时间可能超过预期。

    以下迹象可帮助你了解瓶颈,并相应地采取后续步骤:

    • UI 显示数据传输进度。 数据仍在传输。 网络带宽或数据大小可能导致延迟。
    • UI 未显示数据传输进度。 打开位于 C:\Program Files\Microsoft Azure Recovery Services Agent\Temp 中的日志,并检查日志中的 FileProvider::EndData 条目。 此条目表示数据传输已完成,正在进行目录操作。 请不要取消备份作业, 而是再等待片刻,让目录操作完成。 如果问题持续出现,请联系 Azure 支持部门

    如果尝试备份大型磁盘,建议使用 Azure Data Box 进行第一次备份(初始复制)。 如果无法使用 Data Box,则在通过网络进行长时间数据传输期间,环境中发生的任何暂时性网络问题都会导致备份失败。 若要防止备份失败,可以向初始备份添加几个文件夹,并保持以增量方式添加更多文件夹,直到将所有文件夹成功备份到 Azure。 后续增量备份将相对较快。

    后续步骤