一条可用的网站与数据库备份 cron

备份脚本越简单越可靠。下面这份脚本把网站文件和数据库一次备齐，按日期命名，自动清理旧备份，挂上 cron 之后不用再管，配置一次管多年，是运维里少有的高回报动作，值得花这半小时。 一份完整脚本 新建 /root/backup.sh： #!/bin/bash set -e DATE=$(date +%F) DIR=/backup mkdir -p $DIR tar -czf $DIR/web-$DATE.tar.gz /var/www/site mysqldump -ubackup -p'数据库密码' --single-transaction mydb | gzip > $DIR/db-$DATE.sql.gz find $DIR -type f -mtime +7 -delete --single-transaction 让 InnoDB 导出不锁表，白天跑也不影响业务。chmod +x /root/backup.sh 后手动执行一遍，确认无报错、产物完整。密码直接写在命令行有个隐患：执行瞬间 ps 里能看到，更稳妥的做法是把账号密码写进 /root/.my.cnf（权限 600），mysqldump 会自动读取，命令行里就不用带 -p 了，也避免终端历史和截屏把密码带出去。 挂上 cron crontab -e 加一行： 30 3 * * * /root/backup.sh >> /var/log/backup.log 2>&1 每天 3:30 执行，输出追进日志方便回查。注意 cron 环境和登录 shell 不同，mysqldump 这类命令建议写全路径，用 which mysqldump 查到路径后替换进去，避免 PATH 问题导致定时任务静默失败。静默失败是最阴险的形态：日志停在两周前没人发现，出事时才知道没备份，所以要在监控里加一条"备份文件是否按日更新"的检查，文件日期断档就告警。 保留与异地 脚本里 find -mtime +7 -delete 负责滚动清理，只留最近 7 天。只存在本机的备份不算完成：磁盘损坏或者被删库，同机备份一起陪葬。脚本末尾加一行，把备份推到另一台机器（比如另开一台低配云服务器专收备份）： rsync -az /backup/ backup@192.0.2.10:/srv/backup/ 传完顺手校验：rsync 本身有校验机制，多验一步 md5sum 更安心。备份脚本里含敏感信息，记得 chmod 600 /root/backup.sh 收紧权限。 恢复演练 备份的价值靠恢复来验证：每季度抽一份最近备份，tar -tzf 检查包完整性，数据库导入临时库确认能建表、出数据： gunzip < db-2026-10-01.sql.gz | mysql -ubackup -p mydb_test 恢复用的账号、路径、命令都写在运维手册里，别等出事那天现想，最好再找一个人照着手册独立走一遍，哪里写得不清楚当场就能发现。没做恢复演练的备份，只能算碰运气的文件副本。