备份 321 原则怎么落地

321 备份原则听起来像口号，拆开就三句话：三份副本、两种介质、一份异地。难点从来不在理解，而在落到每一类数据上。 三份副本怎么分 主数据算一份，每日增量算一份，每周全量算一份。数据库用 mysqldump 做逻辑全备，配合 binlog（数据库变更日志）做增量，恢复时按"全备加增量"回放： ``` mysqldump -ubackup -p --single-transaction mydb | gzip > mydb-$(date +%u).sql.gz ``` binlog 记得设过期，binlog_expire_logs_seconds 给个合理值，不然磁盘迟早被它吃满。文件名带星期数，自动滚动七天，磁盘压力不大。 两种介质的意思 副本不能全放同一块盘、同一类存储上。服务器本地盘放最近七天，对象存储或另一台机器放长期副本。两份介质的校验各自做：本地副本每月抽查解压，远端副本上传后核对大小与校验和。这样本地盘损坏、误删、勒索加密，任何一种事故都不会把所有副本一锅端。 一份异地的价值 机房级故障概率低，但真发生了，同机房的备份跟着一起没。异地传输走加密通道，rsync over ssh 或带凭据的存储工具都行，明文传备份等于把家底挂在网上。异地副本选另一个地域的存储，每月核对一次：拉得下来、解得开才算数。 ``` gzip -t mydb-1.sql.gz && echo OK ``` 按业务分级落地 不是所有数据都值得三副本全配置。核心业务库：每日全备加增量，异地留档；静态文件：每周全量；代码在仓库里，仓库本身就是副本，定期导出一份即可。日志类数据占空间大但恢复价值低，单独定低频策略，别和核心库抢备份窗口。分级的原则，是把预算花在恢复代价最高的数据上。 恢复演练别省 备份的终点是恢复。每季度抽一次，在测试机把备份真正恢复出来，跑通核心查询，演练记录留档：恢复到哪一步、耗时多少、缺什么文件，下一次备份策略就照着记录改。恢复耗时尤其要记——它决定真实事故里业务的最长中断时间。 321 落地之后，定期检查三件事：备份任务还在跑、副本数量够、恢复演练按时做。