如何解决 BackupBuddy 超时
已发表: 2020-05-15看到您的 BackupBuddy 备份超时可能会让人感到压力和困惑。 在这篇文章中，我们将讨论导致 BackupBuddy 超时的最常见问题类型以及如何解决这些问题。
为什么会出现BackupBuddy超时？
BackupBuddy 超时可能有多种原因，因此了解您的网站正在运行的服务器非常重要。 BackupBuddy 超时通常与每当 BackupBuddy 创建备份的 ZIP 存档时服务器如何处理备份有关。
如果运行备份的服务器无法处理整个过程，则 BackupBuddy 将停止压缩过程，从而导致超时。 压缩备份是备份的关键部分，因此了解一些故障排除步骤是很好的！
例如，最常见的超时发生在在 Litespeed（一种服务器软件）下运行的网站上。 为什么？ Litespeed 通常会在指定时间后取消长时间运行的 PHP 进程。 例如，如果它设置为在 25 秒后停止进程，那么如果备份没有达到每个块的最大时间，则结果将是超时。
更改每个块的最大时间
默认情况下，BackupBuddy 完成进程的最长执行时间由您的服务器配置定义。 要覆盖此设置，您可以考虑将每个块的最长时间设置更改为 20 秒。 这将拆分备份以在 20 秒内运行每个分块过程，从而缩短 25 秒的时间线。
我的服务器看起来没问题，那么下一步是什么？
如果您的服务器配置正确并且您仍然遇到超时，那么运行脚本或处理 ZIP 存档的服务器可能存在问题。 这方面的一个例子是运行zip 压缩，这是大多数站点推荐的。
启用 Zip 压缩
Zip 压缩减少了存储在备份中的文件的大小，但是，服务器可能运行该过程的时间过长并导致超时。 禁用 zip 压缩可能会增加整体 ZIP 存档大小，但如果服务器在压缩时遇到困难，它确实会有所帮助。 这是解决超时的最常见故障排除步骤。
BackupBuddy 超时故障排除
Litespeed 服务器
确保备份不会超时的第一个赌注是检查您的服务器配置。 下面的这段代码片段将允许 BackupBuddy 在 Litespeed 的约束之外运行。
如果您在 Litespeed 下运行，请尝试将其添加到您的 .htaccess 文件中：
<IfModule LiteSpeed> 禁用CgiOverride On 重写引擎开启 RewriteRule (wp-cron|backupbuddy|importbuddy)\.php - [E=noabort:1, E=noconntimeout:1] </IfModule>
注意：如果您找不到 .htaccess 文件，请确保您可以选择查看隐藏文件。
添加代码后，重新上传文件，以便它用您的新更改覆盖旧文件。
每个块的最大时间
BackupBuddy 的现代模式将使用 wp-cron 将您的备份分成块，但是，某些服务器可能会过早地切断它们的分块时间，从而导致超时。 如果您遇到超时，那么您可能需要考虑更改该值，以便它要求 BackupBuddy 在服务器报告的时间之前运行每个块。
邮编设置
如果您不是在 Litespeed 下运行，那么您很可能希望配置您的 BackupBuddy zip 设置以避免 BackupBuddy 超时。 这些设置与 BackupBuddy 将如何压缩备份严格相关。
第一步是查看您是否正在运行 zip 压缩。 如果您正在运行 zip 压缩并遇到超时，请尝试禁用它。 这解决了大约 70% 的问题，因为服务器（特别是共享服务器）没有压缩能力。
从 Zip 设置中禁用 zip 压缩，然后再次尝试备份。 您会注意到 ZIP 存档看起来有点大，但这是因为存档没有被压缩。
替代 ZIP 系统
如果您的备份在禁用 zip 压缩后仍然遇到超时， Alternative Zip 系统是一个很好的解决方案。 标准 ZIP 系统是实际的 ZIP 可执行文件（命令行）或库 (PclZip)。 给定备份根目录和排除列表，扫描站点并在内部确定 ZIP 存档的文件列表并构建它。 一旦进程开始，那么它就不能被中断并且大多数运行直到完成，一些服务器可能会遇到超时。
Alternative Zip System 进行扫描以构建 ZIP 存档的文件列表。 因为它可以控制它，所以它可以提供将添加到 ZIP 存档中的文件的可执行文件/库列表。 这允许替代 ZIP 系统执行“突发”，因为它希望在添加每组文件后重新获得控制权。 这有助于缓解服务器在压缩过程中可能遇到的任何超时。
启用备用邮编系统后，默认情况下将应用这些设置。
- 继续并将Zip 构建策略保留为“多突发/单步”，因为这将使 ZIP 存档构建得更快。“多突发/多步”策略是为在构建过程中超时的服务器制定的ZIP 存档。 如果您的备份在构建 ZIP 存档期间超时，那么您应该更改为“Multi-Burst/Multi-Step”。
- 每个块的最大时间选项是 BackupBuddy 应该允许 ZIP 存档构建在暂停和安排新的继续步骤之前运行的最长时间。 某些服务器会在没有通知的情况下过早超时，因此这会导致 ZIP 存档停止。 如果 ZIP 存档在压缩过程中超时，则在此处设置一个值将有助于缓解超时。 如果您的服务器的最大执行时间是 30 秒，那么您应该尝试将该值减少到 25 秒。 这将使 BackupBuddy 在 25 秒内运行每个进程，并且不会超过服务器设置的 30 秒执行时间。
- zip 构建突发之间的间隔选项将应用于每个 ZIP 存档构建突发之间。 某些服务器/主机可能会受益于在突发之间有一小段时间，以允许服务器赶上操作和/或允许通过分散 CPU 和磁盘使用率来减少随时间的平均负载。 此选项最好保持默认（2 秒）。
- 单个突发的最小内容大小 (MB)选项告诉 BackupBuddy 它应该为每个突发请求添加的最小内容量。 默认值是10MB，对于大多数服务器来说已经足够了。 除非服务器无法处理最少量的内容，否则最好保持此值不变。
- 单个突发的最大内容大小 (MB)选项告诉 BackupBuddy 它应该为每个突发请求添加的最大内容量。 默认值为 100MB。 但是，一些更便宜的托管计划可能无法处理所请求的这么多内容。 如果您启用了 Alternative Zip System 并且仍然遇到超时，那么您可能需要通过从 50MB 开始作为最大值来调整此设置。
在数据库转储期间超时的备份
有时，您可能会遇到备份在数据库部分超时的情况。 数据库步骤将所有行转储到各自的表中，并创建一个将添加到备份中的 .sql 文件。 在此步骤中可能会发生超时，主要有两个原因：正在转储的表以一种或另一种方式损坏，或者 wp-cron 存在问题。
损坏的数据库表
哪个表导致超时？ 您可能需要查看导致超时的表，因为它可能已损坏。 该表可以从 PhpMyAdmin 中查看，或者如果您的托管服务提供商提供数据库管理解决方案，则可以在那里查看。
- 尝试从备份中排除该表，看看是否可以缓解问题。 如果是这样，则该表很可能已损坏。
WP Cron
如果数据库中的第一个表超时，则 wp-cron 可能存在问题。 如果您不熟悉 wp-cron 及其运作方式，那么您可以查看我们的文档 WP cron。
BackupBuddy 运行一个 cronPass 步骤，该步骤将安排一个 cron 作业为数据库转储运行，因此如果此时有另一个插件运行 cron 作业，则可能会导致冲突。
- 如果您的站点使用任何缓存，则刷新缓存，因为这是 cron 的常见问题。
- 您也可以尝试暂时停用除 BackupBuddy 之外的所有插件以查找导致此冲突的插件。
- 您还可以检查服务器上是否启用了 wp-cron，是否禁用了 wp-cron 或者没有创建和/或设置不正确的 cron 作业。 这可能会导致 cron 问题。
您可以通过访问 BackupBuddy 服务器工具页面（BackupBuddy -> 服务器工具）查看您的服务器上是否启用了 wp-cron。 在“服务器”选项卡下，有一个特定于您的服务器环境的配置列表。
BackupBuddy 超时中的错误
备份期间也可能发生错误，主要是压缩过程，看起来像是超时。 在故障排除期间查看状态日志并查看在超时之前是否发生任何错误是一个好主意。
通常，最常见的错误类型是从 PHP 报告的。 最常见的错误类型是 PHP 内存。 如果您的服务器不支持 exec（命令行）ZIP 方法或 ZipArchive，那么它将使用 PclZip。 由于 PclZip 使用 PHP 作为 ZIP 实用工具，因此它依赖于 PHP 配置来运行 ZIP 任务。
每个运行 PHP 的站点都在其 php.ini 文件中设置了 PHP 内存，如果超过内存，则会返回此错误：
致命错误：允许的内存大小为 33554432 字节已用完（尝试分配 2348617 字节）
如果您的服务器不支持 exec，那么您将需要增加 PHP 内存以允许备份运行直到完成。
包起来
如您所见，当您看到 BackupBudy 超时时，需要考虑许多不同的因素。 在进行故障排除时阅读状态日志很重要，因为它提供了有关此超时发生原因的更多信息。 此外，了解您的服务器及其配置将使您在运行备份过程时更深入地了解其功能。 完成上述这些步骤将提供处理超时的最常见故障排除步骤。
如果您仍然遇到 BackupBuddy 超时问题，我们的支持团队随时待命。 立即访问 iThemes 帮助台以打开支持票。
