排查在 Azure 备份中备份文件和文件夹时速度缓慢的问题Troubleshoot slow backup of files and folders in Azure Backup

本文提供故障排除指导,帮助你诊断使用 Azure 备份来备份文件和文件夹时备份性能缓慢的原因。This article provides troubleshooting guidance to help you diagnose the cause of slow backup performance for files and folders when you're using Azure Backup. 使用 Azure 备份代理备份文件时,备份过程花费的时间可能比预期要长。When you use the Azure Backup agent to back up files, the backup process might take longer than expected. 这种延迟可能由以下一个或多个原因所造成:This delay might be caused by one or more of the following:

在开始排查问题之前,建议下载并安装最新的 Azure 备份代理Before you start troubleshooting issues, we recommend that you download and install the latest Azure Backup agent. 我们经常更新备份代理,以修复各种问题、添加功能和改善性能。We make frequent updates to the Backup agent to fix various issues, add features, and improve performance.

此外,我们强烈建议查看 Azure Backup service FAQ(Azure 备份服务常见问题),确保所遇到的问题并非任何常见配置问题。We also strongly recommend that you review the Azure Backup service FAQ to make sure you're not experiencing any of the common configuration issues.

如果本文未解决你的 Azure 问题,请访问 MSDN 和 CSDN 上的 Azure 论坛。If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and CSDN. 可以在这些论坛上发布问题。You can post your issue in these forums. 还可提交 Azure 支持请求。You also can submit an Azure support request. 若要提交支持请求,请在 Azure 支持页上提交。To submit a support request, on the Azure support page.

原因:计算机存在性能瓶颈Cause: Performance bottlenecks on the computer

正在备份的计算机上可能有一些瓶颈导致延迟。Bottlenecks on the computer that's being backed up can cause delays. 例如,计算机读取或写入到磁盘的能力、用于通过网络发送数据的带宽,都可能会造成瓶颈。For example, the computer's ability to read or write to disk, or available bandwidth to send data over the network, can cause bottlenecks.

Windows 提供了名为性能监视器 (Perfmon) 的内置工具,用于检测这些瓶颈。Windows provides a built-in tool that's called Performance Monitor (Perfmon) to detect these bottlenecks.

下面列出的一些性能计数器和范围可帮助你诊断瓶颈,并获得最佳备份性能。Here are some performance counters and ranges that can be helpful in diagnosing bottlenecks for optimal backups.

计数器Counter 状态Status
逻辑磁盘(物理磁盘)--空闲率Logical Disk(Physical Disk)--%idle • 100% 空闲率到 50% 空闲率 = 正常• 100% idle to 50% idle = Healthy
• 49% 空闲率到 20% 空闲率 = 警告或监视• 49% idle to 20% idle = Warning or Monitor
• 19% 空闲率到 0% 空闲率 = 关键或超出规范• 19% idle to 0% idle = Critical or Out of Spec
逻辑磁盘(物理磁盘)--平均百分比磁盘读取或写入速率(秒)Logical Disk(Physical Disk)--%Avg. Disk Sec Read or Write • 0.001 毫秒到 0.015 毫秒 = 正常• 0.001 ms to 0.015 ms = Healthy
• 0.015 毫秒到 0.025 毫秒 = 警告或监视• 0.015 ms to 0.025 ms = Warning or Monitor
• 0.026 毫秒以上 = 关键或超出规范• 0.026 ms or longer = Critical or Out of Spec
逻辑磁盘(物理磁盘)--当前磁盘队列长度(适用于所有实例)Logical Disk(Physical Disk)--Current Disk Queue Length (for all instances) 80 个请求超过 6 分钟80 requests for more than 6 minutes
内存--池未分页字节Memory--Pool Non Paged Bytes • 消耗不到 60% 的池 = 正常• Less than 60% of pool consumed = Healthy
• 消耗 61% - 80% 的池 = 警告或监视• 61% to 80% of pool consumed = Warning or Monitor
• 消耗超过 80% 的池 = 关键或超出规范• Greater than 80% pool consumed = Critical or Out of Spec
内存--池分页字节Memory--Pool Paged Bytes • 消耗不到 60% 的池 = 正常• Less than 60% of pool consumed = Healthy
• 消耗 61% - 80% 的池 = 警告或监视• 61% to 80% of pool consumed = Warning or Monitor
• 消耗超过 80% 的池 = 关键或超出规范• Greater than 80% pool consumed = Critical or Out of Spec
内存--可用 MBMemory--Available Megabytes • 50% 或更多的内存可用 = 正常• 50% of free memory available or more = Healthy
• 25% 的内存可用 = 监视• 25% of free memory available = Monitor
• 10% 的内存可用 = 警告• 10% of free memory available = Warning
• 不到 100 MB 或 5% 的内存可用 = 关键或超出规范• Less than 100 MB or 5% of free memory available = Critical or Out of Spec
处理器--%处理器时间百分比(所有实例)Processor--%Processor Time (all instances) • 消耗不到 60% = 正常• Less than 60% consumed = Healthy
• 消耗 61% - 90% = 监视或注意• 61% to 90% consumed = Monitor or Caution
• 消耗 91% - 100% = 关键• 91% to 100% consumed = Critical

备注

如果判定罪魁祸首是基础结构,建议定期进行磁盘碎片整理以提高性能。If you determine that the infrastructure is the culprit, we recommend that you defragment the disks regularly for better performance.

原因:其他进程或防病毒软件正在干扰 Azure 备份Cause: Another process or antivirus software interfering with Azure Backup

在许多场合中,我们发现 Windows 系统中的其他进程对 Azure 备份代理进程的性能造成负面影响。We've seen several instances where other processes in the Windows system have negatively affected performance of the Azure Backup agent process. 例如,如果同时使用 Azure 备份代理和其他程序来备份数据,或者防病毒软件正在运行,因而锁定了要备份的文件,则文件中的多个锁可能会造成资源争用。For example, if you use both the Azure Backup agent and another program to back up data, or if antivirus software is running and has a lock on files to be backed up, the multiple locks on files might cause contention. 在此情况下,备份可能失败,或者作业花费的时间可能长于预期。In this situation, the backup might fail, or the job might take longer than expected.

在这种情况下,建议的最佳做法是关闭其他备份程序,并观察 Azure 备份代理的备份时间是否有所变化。The best recommendation in this scenario is to turn off the other backup program to see whether the backup time for the Azure Backup agent changes. 一般情况下,确保多个备份作业不在同一时间运行,就足以防止作业彼此干扰。Usually, making sure that multiple backup jobs are not running at the same time is sufficient to prevent them from affecting each other.

至于防病毒程序,我们建议排除以下文件和位置:For antivirus programs, we recommend that you exclude the following files and locations:

  • C:\Program Files\Microsoft Azure Recovery Services Agent\bin\cbengine.exe(进程)C:\Program Files\Microsoft Azure Recovery Services Agent\bin\cbengine.exe as a process
  • C:\Program Files\Microsoft Azure Recovery Services Agent\(文件夹)C:\Program Files\Microsoft Azure Recovery Services Agent\ folders
  • 暂存位置(如果未使用标准位置)Scratch location (if you're not using the standard location)

原因:备份代理在 Azure 虚拟机上运行Cause: Backup agent running on an Azure virtual machine

如果在 VM 上运行备份代理,其性能比在物理机上运行要慢。If you're running the Backup agent on a VM, performance will be slower than when you run it on a physical machine. 这是预期行为,因为存在 IOPS 限制。This is expected due to IOPS limitations. 但是,可以通过将正在备份的数据驱动器切换到 Azure 高级存储来优化性能。However, you can optimize the performance by switching the data drives that are being backed up to Azure Premium Storage. 我们正在努力解决此问题,将来的版本将有这方面的修复。We're working on fixing this issue, and the fix will be available in a future release.

原因:正在备份大量的(数百万个)文件Cause: Backing up a large number (millions) of files

移动大量数据所花费的时间比移动少量数据要长。Moving a large volume of data will take longer than moving a smaller volume of data. 但在某些情况下,备份时间不仅与数据大小相关,也与文件或文件夹数目相关。In some cases, backup time is related to not only the size of the data, but also the number of files or folders. 在备份几百万个小型文件(几个字节到几 KB)时更是如此。This is especially true when millions of small files (a few bytes to a few kilobytes) are being backed up.

出现此行为是因为,尽管我们是在备份数据并将它转到 Azure,但我们同时也在为文件创建目录。This behavior occurs because while you're backing up the data and moving it to Azure, Azure is simultaneously cataloging your files. 在某些罕见的情况下,目录操作花费的时间可能超过预期。In some rare scenarios, the catalog operation might take longer than expected.

以下迹象可帮助你了解瓶颈,并相应地采取后续步骤:The following indicators can help you understand the bottleneck and accordingly work on the next steps:

  • UI 显示数据传输进度UI is showing progress for the data transfer. 数据仍在传输。The data is still being transferred. 网络带宽或数据大小可能导致延迟。The network bandwidth or the size of data might be causing delays.
  • UI 未显示数据传输进度。UI is not showing progress for the data transfer. 打开位于 C:\Program Files\Azure Recovery Services Agent\Temp 中的日志,并检查日志中的 FileProvider::EndData 条目。Open the logs located at C:\Program Files\Azure Recovery Services Agent\Temp, and then check for the FileProvider::EndData entry in the logs. 此条目表示数据传输已完成,正在进行目录操作。This entry signifies that the data transfer finished and the catalog operation is happening. 请不要取消备份作业,Don't cancel the backup jobs. 而是再等待片刻,让目录操作完成。Instead, wait a little longer for the catalog operation to finish. 如果问题持续出现,请联系 Azure 支持部门If the problem persists, contact Azure support.