#!/bin/bash set -euo pipefail mysqldump --single-transaction blog > /backup/db.sql tar -czf /backup/files.tar.gz wp-content
备份任务每天显示成功，真去还原发现包只有 200MB，正常应该 1.8GB，脚本最后的 echo 照样打印了 done，退出码是 0。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：脚本里几条命令顺序执行，中间 mysqldump 失败没有中断，后面的 tar 接着打了一个不完整的目录。最后一条 echo 成功，整个脚本的退出码就是 0。
这次卡住的地方就在「备份脚本 set -e」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
处理上按这个顺序：脚本开头加 set -euo pipefail 任何一步失败立即退出；每条关键命令后判断退出码 失败就写日志并返回非零；备份完成后比对文件大小 低于阈值直接报警。
确认没问题再收工，故意让 mysqldump 失败一次，任务返回非零，并且没有生成新的压缩包。