生产环境的备份设计首先要回答的不是选择什么软件，而是发生故障后能接受丢失多少数据、多长时间恢复。如果一台CentOS服务器既跑Nginx又跑MySQL，只备份/var/www会丢掉数据库账号、定时任务和系统调优参数。因此策略设计必须从业务影响出发，拆解备份对象和层级，而不是先把某个备份工具用起来再说。
一、从恢复目标倒推备份范围
备份策略的起点是恢复点目标RPO和恢复时间目标RTO。RPO回答的是最多能接受丢失多长时间的数据，RTO回答的是故障后多久必须恢复服务。举例来说，一个电商站点的订单库可能要求RPO小于5分钟，而一个内部文档系统也许能接受丢失一天的数据。不同RPO直接决定数据库备份频率、是否开启二进制日志、是否需要异地同步。
在CentOS中，系统级配置集中在/etc目录，包括网络配置、服务启动项、SSH密钥、定时任务等。这部分内容体积不大，但一旦丢失，重新配置耗时巨大。应用数据通常位于/var/www、/opt、/srv或用户自定义目录，数据库数据常见于/var/lib/mysql。日志文件虽然不一定要长期保留，但排查问题时需要近期日志，可以纳入短期备份。
常见备份范围可以归纳为：
- 系统配置：
/etc、/root、/var/spool/cron - 应用数据：站点代码、上传文件、配置文件
- 数据库：MySQL或MariaDB数据、二进制日志
- 自定义服务：systemd unit文件、脚本目录
数据库与静态文件必须分开处理，因为数据库备份需要保证事务一致性，而文件备份可以简单归档。把两者混在一起，要么数据库可能不一致，要么文件备份被不必要地拖慢。
二、文件级备份：tar与rsync的组合
静态文件如站点代码、用户上传资源、配置文件，适合用tar做归档，配合rsync做增量同步。tar的优点是能够生成一个完整的时间点快照，便于恢复到指定日期；rsync的优点是只传输变化部分，节省带宽和磁盘空间。生产环境中通常会两者结合：每天用tar生成全量或增量归档，再通过rsync把归档同步到异机或备份存储。
下面是一个tar全量备份示例，把系统配置和站点目录分别打包：
#!/bin/bash DATE=$(date +%F) mkdir -p /backup/$DATE tar -czf /backup/$DATE/etc.tar.gz /etc tar -czf /backup/$DATE/www.tar.gz /var/www tar -czf /backup/$DATE/opt.tar.gz /opt
执行tar时建议加上-p选项保留文件权限和属主，否则恢复后可能出现权限错误。对于大量小文件，tar会比直接拷贝更高效，因为它把多个文件合并成单个流，减少了文件系统元数据操作。
rsync更适合跨主机同步，可以使用--delete让目标目录与源目录保持一致，也可以结合--link-dest实现硬链接增量，节省备份空间。下面是一个同步站点目录到备份服务器的示例：
rsync -avz --delete /var/www/ root@192.168.1.20:/backup/www/
需要注意的是，如果使用--delete，目标目录中源目录已删除的文件也会被移除，这在误删文件后可能反而造成备份丢失。因此对于生产环境，更稳妥的做法是保留多版本快照，而不是让备份目录完全镜像当前状态。可以用tar做每日快照，再单独用rsync做实时或近实时镜像。
三、数据库备份要解决一致性问题
数据库备份如果直接拷贝/var/lib/mysql数据目录，很可能拿到不一致的数据，尤其当数据库正在写入时。InnoDB存储引擎虽然支持崩溃恢复，但直接拷贝的文件并不能保证可用于恢复。正确的做法是使用数据库自带的备份工具，逻辑备份和物理备份各有适用场景。
逻辑备份使用mysqldump，它会导出SQL语句，恢复时重新执行建表、插入数据。对于InnoDB表，必须加上--single-transaction参数，这样备份过程中不会锁表，应用仍然可以读写。示例命令如下：
mysqldump --single-transaction --routines --triggers -u root -p mydb > /backup/mydb.sql
这里>是重定向符号，在HTML标签中需要转义，实际脚本里就是普通的输出重定向。--routines和--triggers用于备份存储过程和触发器，否则恢复后这些对象会丢失。
如果数据库规模较大，逻辑备份恢复速度较慢，可以考虑物理热备工具mariabackup或xtrabackup。这类工具会复制InnoDB数据文件并记录二进制日志位置，支持在线备份。MariaDB官方提供的mariabackup用法如下：
mariabackup --backup --target-dir=/backup/mariadb-full --user=root --password=你的密码
物理备份的优势是备份和恢复速度快，适合大数据量场景，但备份文件体积较大，且跨版本恢复时需要保持兼容。无论选择哪种方式，都应该开启二进制日志，这样即使主备份是每天一次，也能通过重放binlog恢复到最近的时间点。二进制日志可以配置在/etc/my.cnf中，设置log-bin=/var/lib/mysql/mysql-bin和合理的过期时间。
四、调度自动化与分层保留
人工执行备份不可靠，必须借助cron实现自动化。一个完整的每日备份脚本应该包含文件备份、数据库备份、备份结果记录和过期清理。脚本放在/usr/local/bin下，并赋予执行权限。下面是一个简化示例：
#!/bin/bash DATE=$(date +%F) BACKUP_DIR=/backup/daily/$DATE mkdir -p $BACKUP_DIR # 文件备份 tar -czf $BACKUP_DIR/etc.tar.gz /etc tar -czf $BACKUP_DIR/www.tar.gz /var/www # 数据库备份 mysqldump --single-transaction -u root -p'你的密码' mydb > $BACKUP_DIR/mydb.sql # 记录日志 echo "Backup completed at $(date)" >> /var/log/backup.log
对应的crontab条目可以设置为每天凌晨2点执行，并输出标准错误到日志文件：
0 2 * * * /usr/local/bin/backup.sh > /var/log/backup.log 2>&1
注意2>&1中的&在HTML中需要转义，实际脚本里它表示把标准错误重定向到标准输出。如果使用cron，还需要确认脚本中的路径都是绝对路径，因为cron的环境变量与登录shell不同。
保留策略建议采用分层保存：每天保留最近7天的备份，每周保留最近4周的备份，每月保留最近12个月的备份。可以用find命令定期清理过期文件。例如删除7天前的每日备份：
find /backup/daily -type f -mtime +7 -delete
对于周备和月备，可以在每周一或每月1号把当天备份复制到对应目录，再用find按天数清理。不要把find -delete直接指向正在写入的目录，最好先测试路径，避免误删。
五、恢复演练与监控告警
备份的价值只有在恢复成功后才能真正体现。很多团队每天执行备份，却从不验证备份文件能否恢复，直到真正故障时才发现压缩包损坏、数据库dump不完整或者权限错误。因此恢复演练应当纳入运维流程，至少每季度做一次，并记录恢复耗时、步骤和遇到的问题。
文件恢复相对简单，将tar.gz解压到临时目录，检查关键文件是否存在、权限是否正确。数据库恢复则需要先停止应用写入，再执行mysql导入逻辑备份，或者用mariabackup --prepare和--copy-back恢复物理备份。恢复演练最好在隔离的测试服务器上进行，避免影响生产环境。
备份任务本身也需要监控。可以编写一个简单的校验脚本，检查最近的备份文件是否生成、大小是否合理，如果没有新备份就发送告警邮件。示例如下：
#!/bin/bash LATEST=$(find /backup/daily -type f -name '*.tar.gz' -mmin -1440 | wc -l) if [ "$LATEST" -lt 1 ]; then echo "No fresh backup found" | mail -s "Backup Alert" admin@ippipp.com fi
此外还要监控备份目录的磁盘使用率，避免磁盘写满导致备份中断。可以用df -h /backup配合阈值判断，或者接入Zabbix、Prometheus等监控系统。备份任务的标准输出和错误输出也建议统一收口到日志平台，方便事后排查。
六、常见误区与避坑建议
第一个常见误区是只备份应用代码，忽略数据库和配置文件。应用代码可以重新部署，但用户数据和数据库账号一旦丢失往往无法恢复。/etc目录体积小却极其关键，SSH主机密钥、网络配置、防火墙规则都在其中。第二个误区是备份存储与生产服务器放在同一块磁盘或同一台物理机上，一旦磁盘损坏，备份也一起丢失。至少要把备份同步到异机，重要业务还需要考虑异地容灾。
第三个误区是只做全量备份，不配置增量或差异备份，导致备份窗口越来越长、磁盘占用越来越大。对于变化不大的系统，可以每周全量、每天增量；对于变化频繁的数据库，可以每日全量配合binlog实时备份。第四个误区是恢复演练只停留在纸面，没有实际操作。恢复过程涉及的权限、依赖、版本兼容问题只有在真实演练中才会暴露。
建议把备份策略文档化，明确备份范围、频率、保留周期、责任人、恢复步骤和验证方法。文档要随着业务变化持续更新，而不是写完后束之高阁。只有把备份、恢复、监控、演练形成一个闭环，CentOS生产环境的数据安全才有实际保障。