数据备份的 3-2-1 原则与加密备份
RainLeather
5 min read
能让你从勒索、误删、硬件报废里活过来的，不是"我有备份"这句信念，而是"备份可用、且与生产隔离、且别人拿走了也读不了"这三条同时成立。3-2-1 原则解决前两点，加密解决第三点。
3-2-1 是什么
- 3 份数据：1 份生产 + 2 份备份，避免单份损坏就全没。
- 2 种介质：备份分散在不同类型载体（例如本地磁盘 + 对象存储），同一种介质批量故障不会一锅端。
- 1 份离线/异地：至少一份不在同一物理位置或不在同一可写网络里，挡住本地灾难和勒索软件的横向加密。
经验上，只做"同机器另一个目录"的备份等于没做——磁盘坏了、机器被勒索，两份一起没。判断一份备份算不算数，先看它和生产是否在同一个故障域。
自动化的前提是能恢复
手动备份最大的敌人是遗忘。用定时任务把备份变成不可协商的例行：
# 每天增量、每周全量，落到独立挂载点
0 3 * * * /usr/bin/restic backup /srv/app --repo /mnt/backup-remote
# 保留策略：最近 7 天每日、最近 4 周每周、最近 6 月每月
0 4 * * 0 /usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
边界条件：备份脚本成功退出不等于数据可恢复。restic/borg 这类工具都提供 check 命令校验仓库完整性，应定期跑并把结果送进告警。更关键的是做一次真实恢复演练——从备份还原到干净机器，确认业务能起来。很多团队第一次演练才发现备份里缺了某张表或密钥。
加密备份：让"拿走了也无害"
备份往往包含和 production 同等敏感的数据，而备份副本常落在第三方存储、离线硬盘这些控制力更弱的地方。静态加密是底线：
# restic 用仓库密码做端到端加密，密钥不出本地
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init --repo s3:s3.example.com/bucket
# 若担心密码单点，可用密钥文件 + 独立保管的密钥分片
要点：加密密钥不能和备份存在同一位置，否则等于没加密。把密钥放进独立的密钥管理，或离线分片保管，恢复时再拼回。
踩坑：把"传输加密"误当"静态加密"。只走 HTTPS 上传，落盘后明文，存储侧或被拖库的人照样能读。必须确认是仓库级静态加密（如 restic/borg 的客户端加密），而非仅链路加密。
异地那份要"不可写"
勒索软件的逻辑是顺着可写权限一路加密。如果备份仓库对生产机是可写挂载，它大概率也会被一起加密。更稳的架构是：生产机只能"推"到备份机，备份机上的删除/改写需要独立的高权限凭据，且保留不可变（immutable / WORM）副本。部分对象存储支持对象锁，设定保留期内连账号管理员都无法改删，这正是为对抗勒索设计的。
备份的边界
3-2-1 不覆盖所有数据。数据库的一致性快照要在静默或事务一致点做，否则还原出半笔交易；密钥和配置要和应用数据一起备份，否则有数据也起不来；纯代码可从源码库重建，不必进业务备份。把"哪些必须备、备到什么一致点、多久能恢复（RTO）"写清楚，备份才从仪式变成保障。
恢复演练要算进恢复时间
备份的价值由 RTO（多久能恢复）和 RPO（最多丢多少）定义，不是有文件就行。演练时计时：从决定恢复到业务可读，跨了多久？还原后发现缺了密钥、配置文件没一起备、DNS 切换没预案，都会把 RTO 拉长到不可接受。把这些依赖项写进恢复手册，和备份本身一起版本化。
数据库一致性怎么保
文件拷贝对数据库不够。在写入高峰直接拷数据目录，还原出来可能是半笔事务。做法要么在静默点做一致性快照，要么用数据库自带的逻辑或物理备份工具保证事务一致。还原后务必跑一致性校验，确认没有断裂的外键或缺失的表。
密钥与配置是备份的一部分
只备份业务数据，恢复时发现加解密密钥、TLS 证书、环境变量文件没一起留，业务照样起不来。把启动所需的最小密钥集纳入独立、加密、分人保管的备份，并演练拿数据加拿密钥能否真起来。很多团队第一次完整演练才发现自己一直少备了某份配置。
备份的访问控制容易被忘
备份仓库的读取权限本身也要收紧。谁能恢复数据，谁就拿到一份等价生产的数据。把恢复权限和日常运维权限分开，恢复动作留审计日志并走多人审批，避免单人就能把全部历史数据导出带走。异地副本的存储凭据同样按最小权限发，且和日常云访问凭据隔离。
1 view
0 likes
0 comments