B4 的备份策略：物理机也不能省

发布时间:2025-12-03 17:09

有种说法是物理机盘大又稳定，备份可以随意一点。这个想法要纠正：机器越稳，数据出事时的损失越大。B4 的备份按三件事搭：本地快照、异地副本、恢复演练。 一、本地快照：改动前的保险丝 数据目录建在 LVM（逻辑卷管理）的逻辑卷上，快照一条命令搞定：lvcreate -s -n data_snap -L 10G /dev/vg0/data，升级、批量改动前拍一个，出问题 lvconvert --merge 秒级回滚。要清楚快照不是备份——它和原数据在同一块盘上，盘坏了一起没，所以快照只负责防手滑，生命周期控制在几小时到几天。快照占用的空间随原卷写入增长，用完及时删：lvremove -f /dev/vg0/data_snap，也可以放进定时任务自动清理。 二、异地副本：真正的备份层 异地才叫备份。每天低峰把数据推到另一台机器或异地存储：rsync -avz --delete /data/ backup@异地机:/backup/data/；数据库场景先 mysqldump -uroot -p --single-transaction 导出再传，保证数据一致。保留策略按"每日版本留两周、每月全量留半年"这类节奏设定。--delete 参数要谨慎：确认源目录无误再用，否则源端误删会被原样同步到备份端。备份数据出公网前先加密，密钥与备份分开存放。备份文件落地后记一份校验值：md5sum 生成后与备份一起保存，定期抽查比对，防止存储静默损坏。 三、恢复演练：备份的最后一环 没验证过的备份等于没有备份。每季度做一次还原演练：把最近一份备份拉到测试机，完整走一遍恢复流程，记录耗时与遇到的问题，应用的配置、密钥、权限一并验证。演练还会暴露保留策略的漏洞——比如恢复三天前的数据实际需要四份文件的组合，这类坑只有演练能提前发现。演练结果记进台账，恢复耗时这个数字，出事时就是业务恢复时间的预期值。 备份策略定稿后写成文档：什么时间备份、存到哪里、保留多久、谁能执行恢复。物理机的稳定让数据风险容易被低估，文档和演练才是把风险摁住的手段。