备份与恢复规划:守护你的文件

备份与恢复规划的核心是两个数字：RPO（可接受的最大数据丢失时间）和 RTO（可接受的最大宕机时长）。先为每个业务负载定义这两个指标，再倒推技术方案。数据库 RPO 5分钟，就需要持续 WAL 归档；每周营销报告 RPO 24小时，一个夜间定时任务就够了。结合 3-2-1 原则——三份副本、两种介质、一份异地——并每季度做一次恢复演练。大多数"我们有备份"的故事以失败告终，原因只有一个：从来没人真正练过恢复。

RPO 与 RTO：起点数字

RPO（恢复点目标）= 可接受的最大数据丢失时间。RTO（恢复时间目标）= 可接受的最大停机时间。

各业务负载参考值：

电商生产数据库：RPO 5分钟，RTO 1小时
面向用户的文件上传：RPO 15分钟，RTO 2小时
内部文件服务器：RPO 24小时，RTO 8小时
邮件归档：RPO 24小时，RTO 48小时
营销分析数据：RPO 24小时，RTO 72小时

RPO/RTO 越紧，成本越高。5分钟 RPO 意味着持续复制（基础设施昂贵）；24小时 RPO 只需一个夜间任务（成本极低）。不要过度设计——并非每个负载都需要热备。

3-2-1 原则依然有效

三份数据副本、两种不同存储介质、一份异地存放。3-2-1 原则早于云计算时代，至今仍然适用：

主副本：生产存储（S3、EBS、PostgreSQL 磁盘）
次副本：不同介质或不同区域的备份（另一个带复制的 S3 桶、Glacier）
第三副本：异地，最好来自不同厂商或气隙隔离（Backblaze B2、本地磁带、保险柜中的物理磁盘）

厂商多元化很重要。一个被攻破的 AWS root 账户可以删除你所有的 AWS 备份。存放在 Backblaze、Wasabi 或本地的副本则能幸免于难。对于营收5000万元以下的企业，第二厂商副本每月大约增加350-1400元，却能抵御灾难性的租户级问题。

全量、增量与合成全量

三种备份策略：

全量备份：每次备份全部数据。简单，恢复快（单文件），存储占用大。
增量备份：只备份自上次以来变化的内容。存储高效，恢复需要全量+所有增量。
合成全量备份：服务端将全量与增量合并为新的虚拟全量。可从任意时间点快速恢复。

现代备份工具（Veeam、Rubrik、带剪枝的 restic、BorgBackup）在底层使用永久增量加合成全量模式。典型策略：每晚增量、每周合成全量，保留30份日备份+12份月备份+7份年备份（祖父-父-子轮换）。

对于日变化率5%的2TB文件服务器，永久增量模式一年保留期约需3-5TB存储——而每晚全量备份则超过700TB。

传输前先加密

备份不应以明文传输或存储。使用 AES-256-GCM 客户端加密（restic、Borg、Duplicacy、Veeam 等工具的默认配置），确保备份主机永远看不到明文数据。

密钥管理比算法选择更重要。如果加密密钥和备份存放在同一个 AWS 账户，那等于没加密——拿到 IAM 权限的攻击者两者都能拿到。密钥应存放在：

AWS KMS，使用跨账户密钥（跨账户解密）
带外环境中的 HashiCorp Vault
根密钥使用硬件安全模块（YubiKey、HSM）
关键密钥打印并密封保存纸质副本

定期轮换（每年一次），记录每次使用，并在生产环境生效前用轮换后的密钥测试恢复。

不可变性：勒索软件的克星

2025年的勒索软件攻击通常先针对备份——加密生产数据后，再删除或加密备份以阻止恢复。不可变备份能破解这一招。

实现方式：

S3 Object Lock（合规模式）：保留期内即便 root 也无法删除
Azure Blob 不可变存储：类似机制，在容器级别强制执行
Veeam 硬化 Linux 仓库：仅追加写入、仅 SSH 访问、无删除 API
保险柜中的物理磁带：终极气隙方案

对于业务关键数据，至少一份备份副本在保留期内应是不可变的。额外成本通常为零——你本来就要保留这份数据。勒索软件来袭时，其价值无可估量。

测试：不可跳过的环节

从未恢复过的备份不是备份，只是一种希望。按优先级制定测试计划：

一级（关键任务）：每季度完整恢复演练，每月随机文件恢复
二级（业务重要）：每半年完整恢复演练，每季度随机文件恢复
三级（标准）：每年完整恢复演练，每季度随机文件恢复

测试记录内容：

恢复耗时（对比 RTO）
数据是否与生产状态一致（与已知时间点的校验和对比）
权限或配置是否恢复失败
出了什么问题，如何修复

跳过测试的公司会在真实事故中才发现备份已损坏，那是最昂贵的学习时机。

数据库备份需要专项方案

文件和数据库的备份方式不同。在事务进行中复制 .pgdata 目录会损坏数据。请使用原生工具：

PostgreSQL：pg_basebackup + WAL 归档实现 PITR，pg_dump 用于逻辑备份
MySQL：Percona XtraBackup 热物理备份，mysqldump 逻辑备份
MongoDB：mongodump，带延迟从节点的副本集
Microsoft SQL Server：BACKUP DATABASE 原生备份，日志传送实现 PITR

对于 RPO 5分钟的500GB PostgreSQL 数据库，每晚基础备份+持续 WAL 归档至 S3，可实现过去30天任意秒的时间点恢复。恢复时间：拉取基础备份（30分钟）+回放 WAL 至目标时间（5-30分钟）。RTO 要求严格时需要一个随时可提升的温备副本。

应用一致性快照

文件系统快照（ZFS、Btrfs、AWS EBS、Azure 托管磁盘、GCP 持久盘）在块级别冻结某一时间点。对于数据库，需配合应用静默：

pg_start_backup('label')（PostgreSQL）或 FLUSH TABLES WITH READ LOCK（MySQL）
执行快照
pg_stop_backup() 或解锁

快照具备应用一致性——可直接用于恢复，无需崩溃恢复。AWS Backup、Azure Backup 和 Google Cloud Backup 已为常见数据库自动化此流程。

向第三方分发备份归档

当备份需要发送给外部方——审计机构、监管部门、受托继任人——传输本身需要谨慎处理。FTP 已过时；邮件附件有大小限制；交付 U 盘速度太慢。

端到端加密文件传输能干净地处理临时备份分发。HexaTransfer 支持最大10GB文件传输，采用 AES-256-GCM 客户端加密和一次性链接。适合向审计机构发送数据库快照，且无需给对方授权访问你的 S3 存储桶。

根据《个人信息保护法》（PIPL）和《数据安全法》（DSL）相关要求，向境外传输数据还需通过网信办（CAC）的安全评估或标准合同，务必提前确认合规路径。

文档是备份的一部分

世界上最好的备份，如果唯一会恢复的人正在休假，其他人都不知道怎么做，那也毫无意义。请记录：

备份了什么，没备份什么（明确的排除项）
每个负载的计划和保留策略
密钥管理和访问权限
含逐步命令的恢复手册
联系人列表（厂商支持、值班人员）
测试结果和日期

打印一份。在放有应急密钥的实体保险柜中存一份。如果你的备份恢复手册只存在于 Confluence 页面，而该页面依赖于刚刚宕机的基础设施，你就有麻烦了。纸张在一切失效时依然有效。

定义 RPO/RTO，实施带不可变性的 3-2-1，客户端加密，每季度测试，严格记录文档。备份成功10%靠技术，90%靠纪律。

免费试用 hexatransfer.com——无需注册，单次最大10GB。