云服务器快照与备份策略：数据安全的最后防线
先讲一个真实事故：某跨境电商团队在促销季前一天执行数据库迁移，一条 DELETE 语句因为漏写 WHERE 条件，瞬间清空了整张订单表。他们没有开启自动快照，最后靠两周前的一次手工备份恢复，丢了 13 天的订单数据和当天的全部流水。促销照常进行，但客服在"查不到订单"的投诉上忙了一整周。
这种事故里，云服务器本身没有责任——硬盘没坏、机房没断电，但数据照样丢了。没有备份，就没有"最后防线"。本文围绕快照（Snapshot）与备份（Backup）的区别、方案选型、策略设计和恢复演练，给出能直接落地的做法。
快照和备份，先分清两件事
很多人把快照和备份混为一谈，其实定位完全不同：
| 维度 | 快照（Snapshot） | 备份（Backup） |
|---|---|---|
| 本质 | 某个时间点的磁盘状态副本 | 可独立恢复的数据副本 |
| 存储位置 | 通常在同云厂商的对象存储 | 本地、异地或第三方存储 |
| 恢复粒度 | 整块磁盘/实例 | 文件、数据库、整机均可 |
| 典型用途 | 变更前回滚点、快速恢复 | 灾难恢复、长期归档 |
快照解决的是"改坏了能马上回去"，备份解决的是"整个机房挂了还能活"。常见误区是只做快照：账号被盗或区域级故障发生时，同一厂商存储里的快照可能一起消失，所以下文强调"快照 + 异地备份"的组合。
主流云厂商快照对比
三家主流厂商的快照都支持增量存储，即只保存自上次快照以来的变更块，首次全量、后续增量，成本因此可控：
| 特性 | AWS EBS 快照 | 阿里云快照 | 腾讯云快照 |
|---|---|---|---|
| 增量存储 | ✓ | ✓ | ✓ |
| 自动策略 | 生命周期管理 | 自动快照策略 | 定期快照 |
| 跨区域复制 | ✓ | ✓（镜像复制） | ✓ |
| 恢复速度 | 分钟级 | 分钟级 | 分钟级 |
| 存储价格 | $0.05/GB/月 | ¥0.12/GB/月 | ¥0.12/GB/月 |
参考：AWS EBS 快照文档 https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html · 阿里云快照文档 https://help.aliyun.com/zh/ecs/snapshot-overview
以一块 100GB 的数据盘为例，首月全量快照约 $5（AWS）；之后如果每天变更量只有 2GB，月增量成本约 $3——远低于整块盘按全量计费。这也是为什么快照策略必须做成"定期 + 增量"，而不是"想起来才打一个"。
第三方工具与数据库备份
快照管"整机"，数据库还需要应用层的一致性备份，避免备份出的数据处于事务中间态：
# MySQL 逻辑备份
mysqldump --single-transaction -u backup -p dbname > db_$(date +%F).sql
# PostgreSQL
pg_dump -Fc -U backup dbname > db_$(date +%F).dump
# MongoDB
mongodump --db dbname --gzip --archive=db_$(date +%F).archive
开源工具里，Restic 和 BorgBackup 都支持增量 + 加密 + 去重，适合做"推送到对象存储/异地"的自动化备份；Veeam 则适合多台虚拟机、需要图形界面管理的企业场景。
策略设计：频率、保留与 3-2-1
3-2-1 原则仍是黄金标准：3 份数据副本，2 种不同介质，1 份异地存储。
| 数据类型 | 备份频率 | 保留周期 |
|---|---|---|
| 系统盘快照 | 每天 | 7 天 |
| 数据盘快照 | 每 6 小时 | 30 天 |
| 数据库 | 每小时（binlog/归档） | 7 天 + 月度归档 |
| 配置文件 | 每次变更 | 90 天 |
用 AWS Backup 一条命令就能建好每日计划，自动打快照并按时清理：
aws backup create-backup-plan --backup-plan '{
"BackupPlanName": "daily-backup",
"Rules": [{
"RuleName": "daily-rule",
"TargetBackupVaultName": "default",
"ScheduleExpression": "cron(0 2 * * ? *)",
"StartWindowMinutes": 60,
"Lifecycle": { "DeleteAfterDays": 30 }
}]
}'
异地备份：最后一道保险
快照在区域级故障面前是无效的，用 cron + rclone 把关键数据推到异地对象存储是性价比最高的方案：
# 每天凌晨 3 点，把备份目录同步到异地 S3 兼容存储
30 3 * * * rclone sync /var/backup s3:my-bucket/backup --transfers 4 --fast-list
恢复演练：没有演练的备份等于没备份
RPO 和 RTO 不能只写在文档里。建议每季度做一次真实演练：
| 恢复目标 | 说明 | 建议值 |
|---|---|---|
| RPO (Recovery Point Objective) | 最大可接受的数据丢失量 | 1 小时 |
| RTO (Recovery Time Objective) | 恢复服务的目标时间 | 4 小时 |
演练至少覆盖三个动作：从快照新建实例并验证启动、从数据库备份恢复到最近时间点、用 rclone 拉回异地数据并校验完整性。测一次就知道：恢复脚本里的路径写没写错、密钥有没有失效、跨账号权限还通不通。
成本控制
| 优化方式 | 节省比例 | 说明 |
|---|---|---|
| 增量快照 | 60-80% | 只保存变更块 |
| 生命周期管理 | 30-50% | 自动删除过期快照 |
| 跨区域只备份核心数据 | 50% | 非关键数据本地备份 |
常见问题
只做快照够吗？ 不够。账号被盗、区域故障时快照可能一起丢失，必须叠加异地备份。
快照能防勒索病毒吗？ 能降低损失——只要保留周期内病毒还没把历史版本删掉，就能回滚。这也是"快照版本要留几天"的原因。
数据库要不要单独备份？ 要。整机快照可能出现事务不一致，应用层备份（mysqldump/pg_dump）才能保证逻辑一致性。
把快照、应用备份、异地副本三者组合起来，再配上季度演练，你的"最后防线"才算真正立起来。