别等服务器真“倒下”才想起备份：聊聊灾难恢复与演练这件事

大家好，我是Echo_Wish，一个在运维世界里被深夜告警叫醒无数次的人。今天咱聊一个听起来硬核，但实际上关乎公司生死、运维尊严，甚至是你“能不能按时下班”的话题——灾难恢复（Disaster Recovery，简称DR）。

讲真，在运维圈里，我见过太多“灾难恢复计划写得比考研政治还厚，但从来没演练过”的公司。
结果真出事故的时候，一群人像热锅上的蚂蚁，满办公室乱跑，最后只能对着服务器一句经典名言：

“不是我不行，是灾难太突然。”

其实灾难恢复不是做给PPT看的，也不是写给老板看的，它是 真能救命的。

一、什么是灾难恢复？说人话！

一句人话解释：

灾难恢复就是当你系统挂了，你能多快、多完整、多体面地把它救回来。

比如哪怕是：

• 机房断电
• 硬盘坏了
• 服务器被加密病毒锁了盘
• 某程序员 rm -rf / 不带犹豫（这是真实存在的痛）
• 云平台大规模宕机（今年发生的不止一次）

灾难恢复的目标只有一个：

系统中断时间最短，数据损失最小。

行业里有两个关键指标：

老板通常只看一句：

越小越好。

但你心里知道：

越小越贵。

二、灾难恢复计划怎么制定？流程不难，难的是坚持做

别整那些虚的，落地 DR 计划就四步：

1. 盘点家底：哪些系统重要？哪些数据库不能丢？哪些业务一挂就上热搜？
2. 定等级、定策略：核心业务→异地双活；普通业务→定期备份即可。
3. 准备备份与复制：这一步是关键，别只是喊口号。
4. 定期演练：不演练 = 没做。

说白了：

DR 不是设计出来的，是训练出来的。

三、备份和复制是实现灾难恢复的“底座”

✅ 备份（Backup）：存档，保护过去

✅ 复制（Replication）：同步，保障现在

一句话总结：

备份防“我没想到”，复制防“我扛不住”。

四、用代码来感受下灾难恢复不是玄学

1) 数据库备份

以 MySQL 为例，一句命令解决：

mysqldump -u root -p --single-transaction --master-data=2 mydb > /backup/mydb_$(date +%F).sql

再加一个简单的自动备份脚本：

#!/bin/bash
BACKUP_DIR="/backup/db"
mkdir -p $BACKUP_DIR
mysqldump -u root -p123456 mydb > "$BACKUP_DIR/db_$(date +%F_%H-%M).sql"
find $BACKUP_DIR -mtime +7 -delete   # 超过7天自动删除

一句话：备份不是问题，能不能找到备份才是。

2) 文件系统增量复制（rsync）

rsync -avz /var/www/ root@backup-server:/data/www/

这个命令就是“你干活，我跟着你同步”。

3) 进阶一点：实时复制 + 异地容灾

例如使用 DRBD 或者 Ceph + 双机热备
或者数据库用 主从 + 延迟从库（防止误删实时同步导致“秒死”）

CHANGE MASTER TO MASTER_HOST='10.1.1.10',
MASTER_USER='replica',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=120;
START SLAVE;

延迟从库关键句：

STOP SLAVE;
CHANGE MASTER TO MASTER_DELAY = 300;  -- 延迟5分钟
START SLAVE;

这个可以救许多“手滑删除大表”的运维兄弟。

真的，无价。

五、演练很重要：不演练 = 没做

很多公司 DR 做得很好，一演练就露馅：

• 恢复脚本过期
• IP、端口写死
• 备份文件恢复不完整
• 业务依赖没整理清楚
• “恢复”成了“追忆”

演练要做到：

演练不是为了证明自己强，而是：

降低恐慌、减少慌乱，让每个人知道自己该做什么。

六、最后说点心里话

在运维这行，很多“功劳都是隐形的”。

备份做得好没有人夸，
灾难恢复成功大家觉得理所当然。

但当事故发生，能把系统安全救回来时，
你会突然理解一件事：

运维的价值不是在顺风顺水的日子里体现的，而是在混乱和危险里守住底线的那一刻。

这不是技术，这是一种责任感。

所以——
兄弟姐妹们，
备份做了吗？复制配置了吗？演练跑了吗？