自动备份策略怎么设：保留周期、执行时间和恢复验证

自动备份策略的核心不是把 cron 跑起来，而是先回答三个问题：备份什么、保留多久、出事后怎么恢复。
把这三件事定下来，再用定时任务串起来，才算一套能用的策略。
本文以常见的 Linux 服务器为例，讲清设置思路和具体操作。

先确定备份对象和保留份数

动手写脚本前，先列一张清单，明确哪些数据丢了会真正影响业务：

• 数据库：MySQL、PostgreSQL 等，通常是最需要优先备份的对象。
• 网站程序与上传文件：代码目录、用户上传的图片和附件。
• 配置文件：Nginx、PHP、防火墙、cron 自身的配置。
• 系统关键数据：证书私钥、密钥文件这类小而重要的内容。

保留份数按业务容忍度来定。
一般做法是“近 7 天每天一份 + 近 4 周每周一份”，既覆盖误删误改，又不至于把磁盘撑满。
备份文件一定要估算体积，例如数据库压缩后 2GB，保留 11 份就要准备 20GB 以上空间。

全量还是增量，按数据量选

数据量小（几十 GB 以内）时，每天全量备份最简单，恢复也最直接。
数据量大或备份窗口紧张时，再考虑增量：

• 全量：每次完整复制，脚本简单，恢复只需一个文件。
• 增量：只备份变化部分，节省空间和时间，但恢复要按顺序叠加，链路更长。

对大多数中小站点，每天一次全量数据库备份加每周一次文件全量，已经够用。
不要为了“看起来专业”上复杂的增量方案，结果恢复时自己都理不清顺序。

用 cron 定时执行备份脚本

先写一个可手动执行的备份脚本，确认没问题再交给定时任务。
以 MySQL 备份为例，脚本放在 /opt/backup/mysql_backup.sh：

#!/bin/bash
DATE=$(date +%F)
BACKUP_DIR=/data/backup/mysql
mkdir -p "$BACKUP_DIR"
mysqldump -u backup_user -p'你的密码' --single-transaction --all-databases \
  | gzip > "$BACKUP_DIR/all_$DATE.sql.gz"
# 删除 7 天前的备份
find "$BACKUP_DIR" -name '*.sql.gz' -mtime +7 -delete

要点说明：

• --single-transaction 让 InnoDB 表在一致性快照下导出，减少锁表影响。
• 密码写在脚本里有泄露风险，生产环境建议用 ~/.my.cnf 存放凭据并设置 chmod 600。
• 脚本加执行权限：chmod +x /opt/backup/mysql_backup.sh。

然后编辑 crontab：crontab -e，加入一行：

30 2 * * * /opt/backup/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

这表示每天凌晨 2:30 执行。
时间要避开业务高峰和数据库的其他定时任务，日志重定向方便事后排查失败原因。

容易踩的几个坑

• 只备份本机：服务器磁盘损坏时，本机备份一起消失。至少把备份同步到另一台机器或对象存储。
• 脚本没做失败判断：mysqldump 失败时可能生成空文件，建议在脚本里检查退出码和文件大小，异常时发告警。
• 保留策略写反：-mtime +7 是删除 7 天前的文件，写错成 -7 会误删新备份。
• 备份目录权限过宽：备份含敏感数据，目录权限应限制为运维账号可读。

验证：恢复一次才算数

备份文件存在不代表能恢复。
建议每月至少做一次恢复演练：把备份文件解压导入一台测试库，确认表结构和数据完整。

日常可以先用这两条命令快速检查：

ls -lh /data/backup/mysql/
gzip -t /data/backup/mysql/all_$(date +%F).sql.gz

第一条看文件是否按天生成、体积是否正常；
第二条校验压缩包是否损坏。
再配合查看 /var/log/mysql_backup.log，确认最近一次执行没有报错。

常见疑问

备份频率设多高合适？
看数据变化速度。每天有大量订单或用户内容的站点，数据库建议每天至少一次，重要业务可加密到数小时一次；变化很少的展示站，每天一次足够。

备份文件要不要加密？
如果备份会传到公网存储或多人可访问的目录，建议加密，避免数据库内容泄露。

定时任务没执行怎么查？
先看 cron 服务是否运行，再查日志里有没有脚本报错，最后手动执行一次脚本，确认是脚本问题还是调度问题。

把备份对象、保留周期、执行时间、异地存放和恢复验证五件事定清楚，自动备份策略才算真正设好。
建议先按本文步骤完整执行一遍，再根据实际数据量调整频率和保留份数。