备份与容灾

备份不是「把服务器打个包」，是按重要性分级、按级别定策略。

先做一张清单（这是唯一步不能跳的）：

| 数据 | 丢了会怎样 | 级别 |
|---|---|---|
| 站点源文件或构建产物 | 重建即可，但要时间 | 中 |
| data/*.json 内容数据 | 全站内容，丢了就白干 | 高 |
| 数据库（如有） | 用户数据，不可再生 | 最高 |
| 服务器配置 / Nginx 配置 | 重配一遍很烦 | 中 |
| 日志 | 丢了无所谓 | 低 |

分级策略：

• 最高：每日全量 + 实时/每小时增量，异地存两份，必须演练过恢复
• 高：每日备份，保留 30 天，异地一份
• 中：每周备份，保留 4 周
• 低：不备份或随服务器快照

关键认知：没演练过恢复的备份，等于没有备份。很多人出事才发现「备份脚本半年没跑成功过」。

合规：含用户个人信息的备份要加密存储，并写清保留期限。

备份脚本做四件事：打包、传走、记日志、失败告警。

#!/bin/bash
# backup.sh · 每日 03:10 执行
set -u
SRC="/www/wwwroot/你的域名"
DATE=$(date +%Y%m%d)
OUT="/tmp/site-$DATE.tar.gz"
tar -czf "$OUT" -C "$(dirname $SRC)" "$(basename $SRC)" || { echo "打包失败"; exit 1; }
coscli cp "$OUT" cos://你的桶/backup/ || { echo "上传失败"; exit 1; }
echo "$DATE ok $(du -h $OUT | cut -f1)" >> /var/log/backup.log
find /tmp -name 'site-*.tar.gz' -mtime +3 -delete

计划任务：宝塔 → 计划任务 → Shell 脚本 → 每天 03:10；或 crontab -e 加一行。

三条硬规则：

1. 异地：备份绝不能只留在同一台机器上（硬盘坏了两个一起没）
2. 失败要告警：脚本失败时发一条通知（钉钉 / 邮件），静默失败最可怕
3. 留多份：至少保留 7 份历史（今天坏了、昨天的备份也可能是坏的）

对象存储选型：腾讯云 COS / 阿里云 OSS，标准存储即可；开版本控制能防误删和勒索。

这一步 90% 的人会跳过，然后出事时才发现备份里少了个配置文件。

怎么演练（每季度一次，1 小时）：

1. 找一台干净环境：新开一台按量付费服务器（几块钱），或用本地虚拟机 / Docker
2. 只拿备份文件还原：假装原服务器已经炸了，不许去原机拷贝任何东西
3. 全过程计时：记下每一步耗时（下载备份、解压、恢复数据、改配置、启动、验证）
4. 验证业务可用：打开页面点一圈，不只是「文件存在」
5. 写演练记录：恢复总耗时 / 卡住的环节 / 备份里缺了什么

演练必会暴露的问题（提前预期）：

• 备份里没包含 Nginx 配置 → 补进去
• 数据库没备份或版本对不上 → 补逻辑备份
• 密钥、环境变量不在备份里 → 单独加密存一份
• 恢复耗时远超预期 → 考虑做服务器快照镜像

指标：把「恢复时间目标 RTO」写下来（比如 2 小时），演练结果超过它就改进方案。

演练完销毁环境，别留一台开着忘记关的服务器。

监控（备份本身也要被监控）：

• 备份日志里当天必须有成功记录 → 没记录就告警（见「服务器监控面板」场景）
• 对象存储里的备份文件大小突变（比如从 50MB 变成 1KB）也要告警——多半是打包失败了
• 每月一次：随机下载一份备份，解压看文件是否完整（ cheap 且有效）

成本：
| 项目 | 省钱做法 |
|---|---|
| 存储 | 用生命周期规则：30 天后转低频存储，90 天后删除 |
| 请求 | 别每分钟同步一次，每日一次足够 |
| 流量 | 备份走内网 / 同地域上传，通常免费 |

清理策略（写进脚本）：

• 本地临时包保留 3 天
• 对象存储：每日备份保留 30 天，每周备份保留 12 周，每月备份保留 12 个月
• 别无限保留：不清理的备份是纯成本，且含个人信息的数据无限保留本身就是风险

最后：把「备份策略 + 恢复步骤 + 联系人」写成一页文档，放在能被找到的地方（不是只有你自己电脑里）。真出事的时候，你需要的是照着做，不是回忆。