计划备份未启动

Backup 插件中的计划任务依赖 WP-Cron。WP-Cron 并不是真正的系统服务，而是由页面访问触发——在访问量很低的网站上，计划备份因此会错过自己的时间窗口。插件会在一个地方显示实际状态，而不是让人去猜。

是什么在推动运行

一次备份运行由多个短小的回合组成。推动它们的方式有两种：通过 cron 事件，以及通过后台脉冲。后台脉冲会在拥有管理员权限的人打开的每一个 wp-admin 页面上继续推进一小段，而且是在页面送出之后才进行。但它不会启动新的运行，只会把已经开始的运行继续往前推——对于一个从未开始的运行，它帮不上忙。

读取状态

1. 在 WordPress 菜单中打开“Kakapo Backup”条目。
2. 在左侧“状态”（德语：„Status“）组中切换到“状态”（德语：„Status“）这一项。
3. 在“WP-Cron 助手”卡片中读取状态行。
4. 在“配置”组的“计划任务”（德语：„Zeitplan“）下检查“计划备份”是否已开启，以及填写的“时间”是几点。
5. 回到“状态”（德语：„Status“）区域，在“诊断”卡片中点击“重新检查”。

• “计划任务已启用”——这里显示“否”时，说明“计划任务”（德语：„Zeitplan“）面板中的开关是关闭的，根本不会创建任何时间点
• “常量 DISABLE_WP_CRON”——显示“已设置”时，WordPress 不会自行启动 cron，此时必须使用系统 cron
• “下次计划运行”——显示时间和剩余时长，或者报告“未注册任何事件”
• “上次实际运行”——来自一个专门的计数器，它在 Backup 的 cron 事件触发时被设置；如果为空，就改为显示日志中最近一次成功的计划运行，只有连这个也没有时，那里才会写“从未观察到”

用系统 cron 取代页面访问

同一张卡片中包含两条现成的、用于真正系统 cron 的命令行，均为 15 分钟一次：方案 A 通过 curl 调用 wp-cron.php，方案 B 使用 WP-CLI。两个区块都已经填入了本安装的真实地址或真实路径，可以直接复制。只要没有设置 DISABLE_WP_CRON，卡片还会额外显示适用于 wp-config.php 的那一行。

define( 'DISABLE_WP_CRON', true );

已经开始的运行停住了

“诊断”卡片中有一行“可创建任务锁文件”。如果无法创建锁文件，就无法执行任何运行；该行明确把写入权限和 open_basedir 列为原因。下方的“Auto-Recovery”卡片可以通过“立即清理”清除卡住的运行显示，以及残留的临时文件和不完整的部分归档。超过十分钟没有任何动静的运行会被视为残留——它不会被丢弃，而是在下次启动时以相同的范围继续。