讲解 AWS EC2 文件备份到 S3 的范围、IAM Role、aws s3 sync、Versioning、Lifecycle 和恢复演练。
把 EC2 文件同步到 Amazon S3,可以降低服务器或 EBS 故障导致文件同时丢失的风险。但同步成功不等于备份可恢复,仍需处理数据一致性、版本保护、最小权限、保留周期和恢复演练。
安全起点:先给 EC2 绑定只允许访问目标 S3 前缀的 IAM 角色,再用 aws s3 sync 同步静态文件。数据库目录、队列和运行时文件不能直接当普通文件备份,应先用官方工具生成一致性备份。S3 按存储、请求、版本和传输计费;首轮不要加入删除目标对象的选项。

先划定备份范围
| 数据 | 处理方式 |
|---|---|
| 用户上传文件 | 直接对象化或定时增量同步 |
| 应用配置 | 去除密钥后加密备份 |
| 数据库 | 先生成一致性逻辑或物理备份 |
| 缓存与临时文件 | 通常排除并从源重新生成 |
| 系统盘环境 | 配合 AMI、EBS 快照或基础设施代码 |
使用实例角色授权
为 EC2 关联只允许目标 Bucket 和前缀所需动作的 IAM Role,不在脚本保存长期 Access Key。需要 SSE-KMS 时,还要同时授予 KMS Key Policy 和 IAM 权限。
同步示例
aws s3 sync /srv/uploads s3://example-backup/prod/uploads/ \
--exclude '*.tmp' \
--only-show-errors
aws s3 ls s3://example-backup/prod/uploads/ --recursive --summarize
example-backup 必须替换为实际 Bucket。首次上线不要直接增加 --delete;该选项会删除目标端在源目录中不存在的对象,应先预演并结合版本控制。
版本与生命周期
启用 S3 Versioning 可保留对象的多个版本,降低覆盖和误删风险,但历史版本仍产生存储费用。Lifecycle 应按恢复窗口迁移或清理旧版本,不能只为省钱删除仍在恢复目标内的数据。
恢复演练
- 选择隔离目录或测试实例;
- 恢复指定时间点文件;
- 核对数量、哈希、权限和所有者;
- 启动应用并验证真实读取;
- 记录恢复时长和缺失依赖。
边界条件
S3 同步不是磁盘级快照,也不会自动保证运行中数据库一致性。跨区域复制、Object Lock 和不可变备份应根据合规与威胁模型单独设计。
先把范围分清
- 站点上传、配置导出、构建产物:确认写入边界后同步。
- 数据库:使用逻辑导出或原生备份,校验完成再上传。
- 缓存、临时目录、日志和依赖:按恢复价值排除,不能无差别备整盘。
做一次可控同步
替换本地目录、桶名和前缀,确认角色与区域后执行不带删除参数的命令:
aws s3 sync /srv/site-backup/ s3://YOUR_BUCKET/server-a/ --exclude "*.tmp" --only-show-errors随后用 aws s3 ls 核对时间和大小。同步不是不可变备份;源变化会覆盖同名对象,应启用版本控制,并为旧版本设置成本可接受的生命周期。
失败分支
AccessDenied:核对调用身份、桶策略、KMS 和前缀 ARN,不给管理员权限。- 对象有但恢复失败:检查权限、属主、符号链接和目录结构。
- 费用异常:查旧版本、未完成分段上传、跨区域与频繁小请求。
- 误用删除:立即停任务,用版本恢复;无版本只能依赖其他副本。
恢复验收
恢复到隔离目录或新实例,不覆盖生产源;核对数量、大小、抽样哈希、权限,再验证登录、上传和配置。数据库执行原生恢复与查询。保留一个已验证旧前缀。失败时继续使用原实例,不能用失败目录反向覆盖唯一好副本。
计划任务必须留下可判断结果
定时备份至少记录开始、结束、源目录、目标前缀、上传数量、失败数量和退出码,并对连续失败或备份量异常下降告警。不要把“脚本每天运行”当作成功。角色轮换、磁盘满、DNS 和系统时间变化都可能让任务静默失败。备份日期应来自受控前缀或对象元数据,避免同名覆盖后无法定位恢复点。
敏感文件要减少暴露
不要把应用环境变量、私钥和数据库口令原样放进所有人可读的桶。确需备份时使用受控加密与最小读取权限,并验证恢复人员能在审批后取用。S3 公共访问应保持关闭;网站公开素材与服务器私密备份不要混用同一前缀和权限策略。
首次恢复成功后记录所需 IAM 权限和实际用时,避免灾难发生时才发现备份操作者只有写入权限却不能读取版本。对大文件和大量小文件分别估算恢复时间;RTO 不应根据上传速度猜测。跨区域恢复还要预先确认目标区域、KMS 和网络费用。

