整站打包出来十几个 G，压缩和上传都要很久，实际有用的内容没那么多。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，缓存、日志与备份文件本身也被打进包，体积被无关文件撑大，真正需要的内容占比很小。
「备份打包排除」这类改动最怕改一半，回滚脚本先准备好，再动生产。改完顺手把文档补一句，省得下次自己重新推一遍。
tar --exclude='./wp-content/cache' --exclude='./logs' --exclude='*.zip' -czf site.tgz . du -sh * | sort -rh | head
监控和日志的时间要对上，时区不一致会多绕很大一圈。临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
具体做法是，先统计各目录体积；打包时排除缓存与日志；数据库单独导出。
最后用这个标准收尾，备份包体积下降一半以上，内容完整可用。