做服务器运维或网站管理，压缩备份这事不能靠想起来就干一次。硬盘突然爆满、数据库被误删、网站被黑后恢复不了——这些大多不是技术不行，而是备份没排好。
别把排期当成填日历
很多人建个Excel表格，写上“每周一凌晨2点全站压缩”，然后就放心了。结果某天凌晨服务器负载飙升，备份卡死；或者遇上大版本更新，临时加了个数据库导出步骤，却忘了同步调整压缩脚本和保留周期，三天后发现磁盘被旧备份塞爆。
真正管用的排期逻辑，得拆开看三件事
1. 数据变动节奏决定频次
博客类站点，文章每月增几十篇，用「每周全量 + 每日增量」就够；电商后台订单库每小时写入上千条，就得考虑「每4小时快照 + 每日归档」。别照搬别人的时间表，先翻一周的access.log和binlog增长量，心里有数再定。
2. 压缩与存储必须联动设计
光压完扔到本地硬盘？风险太大。实际排期要包含：压缩完成时间、传输到异地存储耗时、校验MD5是否成功、旧备份清理触发点。例如：
# 每日凌晨3:15启动
0 3 * * * /backup/scripts/full_backup.sh &> /backup/logs/backup.log
# 传完自动校验并清理7天前的tar.gz
15 3 * * * /backup/scripts/cleanup_old.sh3. 给意外留出“错峰窗口”
系统升级、CDN刷新、大促压测期间，备份任务得临时让路。我们在排期表里加一列「冲突标记」：标红代表该时段禁用CPU密集型压缩（如gzip -9），改用pigz多线程或直接切到lz4快速压缩。实测同样10GB数据，lz4耗时不到gzip的1/5，虽体积略大，但抢出了22分钟空档。
一个小而硬的排期模板
不用复杂工具，一个带条件格式的Excel就能跑起来：
- 列A：日期（自动填充）
- 列B：备份类型（全量/增量/数据库dump）
- 列C：执行时间（精确到分钟，避开业务高峰）
- 列D：压缩方式（lz4/pigz/gzip-6）
- 列E：目标路径（本地/NAS/对象存储）
- 列F：保留天数（全量=30，增量=7，dump=14）
- 列G：备注（如「双11前3天停增量」）
这个表打印出来贴在工位旁，比任何自动化告警都管用——人眼扫一眼就知道今天该盯哪一步。
备份不怕慢，怕的是排期断层。压缩只是动作，排期才是心跳。