一、 AWS Backup 控制台:协作逻辑与架构总览
AWS Backup 的左侧导航栏并非简单的菜单,而是一个完整的 "配置 -> 执行 -> 存储 -> 监控" 闭环。理解每一行的作用,能帮您快速定位问题。
1. 模块深度解读
| 模块名称 | 功能定义 | 在架构中的角色 |
|---|---|---|
| 控制面板 (Dashboard) | 全局监控 | 指挥官。每天早上看一眼,确认是否有红色的"Failed"作业。 |
| 备份计划 (Backup plans) | 策略定义 | 大脑。定义"每天几点备"、"存多久(Retention)"、"是否跨区域复制"。 |
| 受保护的资源 (Protected resources) | 资产清单 | 账本。查看当前纳管了多少个 EC2、RDS。如果数量少于 40,说明有漏网之鱼。 |
| 保管库 (Backup vaults) | 存储容器 | 保险柜 。数据物理存放的地方。建议开启 Vault Lock (锁),防止黑客删库。 |
| 作业 (Jobs) | 执行日志 | 记录员。备份失败了?还原进度多少了?都来这里查。 |
| 设置 (Settings) | 授权总闸 | 门禁。必须在此页面勾选 EC2, S3, RDS 等服务,AWS Backup 才有权操作它们。 |
2. 核心工作流程架构图
下图展示了从您配置策略到数据最终落盘的完整数据流向:
graph TD
%% 定义节点样式
classDef config fill:#e3f2fd,stroke:#1565c0,stroke-width:2px;
classDef process fill:#fff3e0,stroke:#ef6c00,stroke-width:2px;
classDef storage fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
subgraph 配置层
Settings[设置 Settings\n授权服务访问] --> Plan[备份计划 Backup Plan\n定义: 每日 02:00 / 保留 30 天]
end
subgraph 执行层
Plan --触发规则--> Assign[资源分配 Assign Resources\n抓取 EC2/RDS/S3]
Assign --> Job[作业 Jobs\n执行快照任务]
end
subgraph 存储层
Job --加密传输--> Vault[(保管库 Backup Vault\n独立存储/防删锁)]
end
%% 应用样式
class Settings,Plan config;
class Assign,Job process;
class Vault storage;
二、 EC2 备份操作:全量兜底策略 (推荐)
针对 40+ 台服务器,为了防止运维人员"忘记打标签"导致漏备,我们采用 "默认全量备份,例外手动排除" 的策略。
1. 操作步骤
-
创建/编辑备份计划:
- 进入
Backup plans-> 点击Assign resources(分配资源)。
- 进入
-
分配资源 (关键配置):
-
Assign by (分配依据): 选择
Resource type(资源类型)。 -
Select specific resource types: 勾选
EC2。 -
Instance ID: 务必留空不选(留空代表选中当前区域下"所有"实例,包括未来新建的)。
-
-
设置排除项 (Refine selection):
-
为了节省成本,排除临时测试机。
-
勾选 Exclude specific resources (排除特定资源)。
-
Exclude by tags: 设置 Key=
Backup, Value=No。
-
2. 策略逻辑流程图
下图展示了系统如何判断一台 EC2 是否需要执行备份:
graph TD
Start(备份计划定时触发\n例如: 每日凌晨 02:00) --> Scan[全量扫描当前区域\n所有 40+ 台 EC2 实例]
Scan --> Loop{逐台判断}
Loop --> CheckTag{检查标签:\nBackup == No ?}
CheckTag -- 是 (命中排除项) --> Skip[跳过备份\n(节省成本/测试机)]
CheckTag -- 否 (默认情况/无标签) --> ExecuteBackup[执行备份]
ExecuteBackup --> Snapshot[创建 EBS 快照\n+ 关联 AMI]
Snapshot --> Store[(存入 AWS Backup\n保管库)]
style Skip fill:#eee,stroke:#999,stroke-dasharray: 5 5
style Store fill:#9f9,stroke:#090,stroke-width:2px
三、 S3 备份:双层防御体系
S3 的备份需要 S3 原生功能 (省钱) 和 AWS Backup (防灾) 配合使用。
1. 第一层:S3 原生配置 (桶内管理)
-
开启版本控制 (Versioning):
- 必须开启。这是 AWS Backup 能工作的技术前提。
-
配置生命周期 (Lifecycle Rules) - 优化成本:
-
操作: 在 S3 控制台设置规则 -> 针对
Noncurrent versions(非当前版本) -> 设置 "7 天后永久删除"。 -
目的: 桶里只留最近 7 天的旧版本供开发人员快速回滚代码,防止 S3 存储费无限膨胀。
-
2. 第二层:AWS Backup 配置 (异地/防灾)
-
操作: 在备份计划中添加
S3资源。 -
目的: AWS Backup 会将数据复制到独立的 Vault。即使原桶被黑客清空,Vault 里的数据依然安全。
3. 双层防御架构图
graph TD
subgraph "第一层防御: S3 桶内原生管理 (短期回滚 & 成本控制)"
LiveObject[活跃文件 (Current Version)] --被覆盖/修改--> OldVersion[旧版本文件 (Noncurrent)]
OldVersion --滞留 7 天--> S3Lifecycle[S3 生命周期规则\n自动永久删除]
S3Lifecycle --> Deleted(彻底消失\n节省 S3 存储费)
end
subgraph "第二层防御: AWS Backup 独立保护 (长期合规 & 灾难恢复)"
BackupPlan(AWS Backup 计划\n每日定时抓取) --扫描整个桶--> Capture[捕获所有版本状态]
Capture --复制并加密--> IndependentVault[(独立备份保管库 Vault)]
IndependentVault --长期留存 30天+--> SafeData(数据安全\n即使原桶被删也能恢复)
end
style LiveObject fill:#fff,stroke:#333
style OldVersion fill:#ddd,stroke:#333,stroke-dasharray: 5 5
style IndependentVault fill:#ccf,stroke:#00f,stroke-width:2px
四、 RDS 备份:连续备份与秒级恢复 (PITR)
核心业务数据库(Core DB)必须开启此功能,以应对"逻辑错误"(如误删了一张表)。
1. 开启连续备份 (Continuous Backup)
-
在 AWS Backup 的
Backup Rule中,勾选 "Enable continuous backups for capable resources"。 -
注意: 开启后,AWS 会自动管理事务日志 (Binlog/WAL) 的上传。这里的恢复逻辑,第一步是恢复到指定的每天的备份时间点,如凌晨2点,然后在根据backup存储的binlog日志,恢复到指定的秒。
2. 恢复底层逻辑 (Snapshot + Transaction Logs)
假设您需要将数据库恢复到 今天上午 08:00:00(误删数据前一秒)。
AWS 后台会自动执行以下流程:
graph LR
%% 定义时间节点
T_Snap[02:00 AM\n最近的全量快照]
T_Target[Target: 08:00:00\n目标恢复时间点]
T_End[08:05 AM\n当前时间]
%% 恢复流程
Step1[1. 加载基准快照] -->|基于 02:00 快照| TempDB[(临时 RDS 实例\n数据停留在 02:00)]
subgraph "2. 事务日志重放阶段 (Log Replay)"
TempDB --> ReplayStart(开始重放日志)
Logs[(隐藏的事务日志流\nBinlog/WAL 存储于 S3)] -.->|注入 02:00-08:00 的操作| ReplayStart
ReplayStart -->|自动执行 SQL 增删改| Replaying(...)
end
Replaying --> Step3[3. 精准刹车]
Step3 -->|在 08:00:00 停止| FinalDB[(全新的 RDS 实例\n数据精确处于 08:00:00)]
%% 样式标记
style T_Snap fill:#eee,stroke:#333
style T_Target fill:#ff9,stroke:#f66,stroke-width:2px,color:red
style FinalDB fill:#9f9,stroke:#090,stroke-width:2px
五、 AWS Backup 全栈支持能力
除了上述三大件,您的架构中以下组件也应纳入 AWS Backup 统一管理:
全栈备份覆盖范围
graph TD
Central[AWS Backup\n统一管理控制台]
subgraph "计算与块存储"
EC2(EC2 实例) --> Central
EBS(EBS 卷) --> Central
end
subgraph "数据库 (支持 PITR 秒级恢复)"
RDS(RDS / Aurora) --> Central
MemoryDB(MemoryDB for Redis) --> Central
end
subgraph "文件与对象存储"
S3(S3 对象存储) --> Central
EFS(EFS 文件系统) --> Central
end
subgraph "大数据与分析"
OpenSearch(OpenSearch 服务) --> Central
DynamoDB(DynamoDB NoSQL) --> Central
end
classDef centralNode fill:#333,stroke:#fff,stroke-width:4px,color:#fff;
class Central centralNode;
六、 管理员"避坑"检查清单 (Checklist)
-
检查"僵尸快照": 全量备份策略下,已关机(Stopped)的 EC2 依然会产生备份费用。请定期清理废弃机器,或为其打上
Backup: No标签。 -
验证 Vault Lock: 检查您的 Backup Vault 是否开启了 Governance Mode 或 Compliance Mode。这是防止删库跑路的最后一道防线。
-
RDS 恢复验证: 记住,RDS 恢复会产生一个新的 Endpoint(连接地址)。恢复后,需要手动修改应用程序的数据库连接配置。
-
演练机制: 建议每季度挑选 1 台非核心 EC2 和 1 个 RDS 数据库进行一次 Restore Testing (还原测试),确保数据不仅能"备下来",还能"救回来"。