AWS Backup 核心操作与架构指南

一、 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. 操作步骤

  1. 创建/编辑备份计划:

    • 进入 Backup plans -> 点击 Assign resources (分配资源)。
  2. 分配资源 (关键配置):

    • Assign by (分配依据): 选择 Resource type (资源类型)

    • Select specific resource types: 勾选 EC2

    • Instance ID: 务必留空不选(留空代表选中当前区域下"所有"实例,包括未来新建的)。

  3. 设置排除项 (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)

  1. 检查"僵尸快照": 全量备份策略下,已关机(Stopped)的 EC2 依然会产生备份费用。请定期清理废弃机器,或为其打上 Backup: No 标签。

  2. 验证 Vault Lock: 检查您的 Backup Vault 是否开启了 Governance ModeCompliance Mode。这是防止删库跑路的最后一道防线。

  3. RDS 恢复验证: 记住,RDS 恢复会产生一个新的 Endpoint(连接地址)。恢复后,需要手动修改应用程序的数据库连接配置。

  4. 演练机制: 建议每季度挑选 1 台非核心 EC2 和 1 个 RDS 数据库进行一次 Restore Testing (还原测试),确保数据不仅能"备下来",还能"救回来"。

相关推荐
十月南城2 小时前
微服务化的收益与成本复盘——技术、组织与运维维度的综合账本
运维·微服务·云计算
mit6.8242 小时前
内存碎片|c++内存池|lua gc
架构
Yvonne爱编码2 小时前
边缘计算与云计算的协同发展:未来算力布局的核心逻辑
人工智能·云计算·边缘计算
Codebee2 小时前
Ooder-AIForm专用表单Skill解决方案
架构
编程武士2 小时前
API优先战略:数字时代架构设计的核心基石
架构·api
熏鱼的小迷弟Liu4 小时前
【消息队列】RabbitMQ的基本架构?
面试·架构·rabbitmq
源心锁12 小时前
丧心病狂!在浏览器全天候记录用户行为排障
前端·架构
Tony Bai14 小时前
【分布式系统】03 复制(上):“权威中心”的秩序 —— 主从架构、一致性与权衡
大数据·数据库·分布式·架构