devops

EKS灾难恢复，简化：使用AWS Backup的原生备份

发布: (2025年12月22日 GMT+8 05:53)
7 min read
原文: Dev.to

Source: Dev.to

请提供您希望翻译的正文内容，我将按照要求保留链接、格式和技术术语，仅翻译正文部分。

转折点 – 2025年11月10日

上个月，AWS 终于通过 在 AWS Backup 中添加原生 Amazon EKS 支持，弥补了长期存在的缺口。
这并非一个小的功能发布；它标志着从自行备份工程转向托管可靠性的真正转变。

为什么这很重要

旧方式新方式
碎片化的恢复点 – 集群配置、EBS 快照和 S3 对象分散存放在不同位置。复合恢复点 – AWS Backup 将集群状态 以及 持久存储（EBS、EFS、S3）一起捕获为单一且一致的快照。
多种工具 – Velero、自定义脚本、手动管理的 S3 存储桶以及无尽的焦虑。统一视图 – EKS 备份位于您已用于 EC2、RDS、DynamoDB 等的同一 AWS Backup 控制台中。无需额外的控制器或每个集群的 Velero 代理。
脚本驱动的调度 – 集群内部的 CronJob。策略驱动的调度 – 定义备份计划（例如，“每 6 小时备份一次，保留 30 天”）。AWS 自动处理调度、加密、不可变性和生命周期。
压力大的恢复 – 手动、易出错，往往像赌博。无压力的恢复 – 在恢复工作流中，可以恢复整个集群、单个命名空间、单个持久卷（PV），甚至是全新创建的 EKS 集群。

立即可见的运营收益

  • 集群升级（例如，1.30 → 1.31）无需担心数据丢失。
  • AMI 部署如果未按计划进行。
  • 安全补丁应用时有安全网。
  • Kubernetes API 更改可能导致工作负载中断。

如果您在生产环境中运行 EKS，这项功能会悄然改变您夜间的睡眠质量。AWS 不仅仅是添加了一个备份选项；他们消除了整类运营压力。

实用指南：使用 AWS Backup 启用原生 EKS 备份

1. 将 EKS 添加为受保护资源

  1. 打开 AWS Backup 控制台。
  2. 选择 Settings → Configure resource。
  3. 勾选 Amazon EKS 并启用它。

Configure resource screen

2. 创建按需备份

  1. 在 Protected resources 视图中，点击 Create on‑demand backup。

Create on‑demand backup button

3. 设置备份角色

创建自定义 IAM 角色（例如 EKS-BACKUP-ROLE-EXAMPLE），并附加以下托管策略：

  • AWSBackupServiceRolePolicyForBackup
  • AWSBackupServiceRolePolicyForRestores

IAM role attachment screen

Policy list view

4. 验证备份进度

启动按需备份后，您会看到其状态变为 In progress。

Backup in progress view

5. 确认完成

您可以在 AWS Backup 控制台或直接在 EKS 控制台中验证备份已完成。

Backup completed view

TL;DR

  • AWS Backup 现在原生支持 Amazon EKS – 一键、基于策略的保护，涵盖控制平面状态和持久存储。
  • 复合恢复点 消除碎片化快照。
  • 统一控制台 为所有工作负载提供单一视图。
  • 设定即忘 的备份计划取代脆弱的 CronJob 和自定义脚本。
  • 恢复可靠 – 可对整个集群、命名空间级别或 PV 级别进行恢复，甚至恢复到全新集群。

今天就启用它，让灾难恢复从噩梦变为托管服务。

![Backup screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fkkmc6v25h0hmc0s4txt5.png)

That is how to back up; now moving to the **Restore process**.

### Initiating a Restore

1. Open **AWS Backup** → **Protected resources**.  
2. Click the **Resource ID** of the cluster you want to restore.  
3. Choose the **Composite recovery point** you created.  
4. Press the **Restore** button.

![Restore button screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fdauixjqk92f146ntwjzf.png)

### Choosing Restore Options

During the restore workflow, AWS Backup presents several recovery options:

- **Restore scope** – entire EKS cluster or a specific namespace.  
- **Restore destination** – original source cluster, an existing EKS cluster, or a brand‑new cluster created as part of the restore.

In this walkthrough I restored into a newly created EKS cluster to demonstrate the full capabilities of native EKS recovery and to validate how well the feature supports clean, isolated disaster‑recovery scenarios.

![Restore scope screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fguer8ohxzfccwft09200.png)

### Selecting Storage Resources

The next step asks you to select the storage resources to include in the restore.  
In my case no persistent storage was attached to the workloads, but AWS Backup also supports restoring data backed by **Amazon EBS**, **EFS**, and **S3**, ensuring that application data and cluster state remain consistent.

![Storage selection screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fp5f2v9ad64fcfq426wjk.png)

### Restoration in Progress

Once the restore is initiated, AWS Backup begins recreating the cluster based on the selected recovery options, provisioning a new EKS environment as specified. This doesn’t replace disciplined GitOps workflows or careful upgrade strategies, but it finally gives platform teams a native, reliable safety net. For production EKS environments, that’s a meaningful shift in operational confidence.

![Restore progress screenshot](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3sgwfxmyy72zkhprlvk6.png)

最终思考

在 AWS Backup 中原生支持 Amazon EKS，消除了平台团队过去必须自行管理的大量复杂性。它提供一致的、基于策略的备份以及可预测的恢复，而无需引入额外的控制器或运维负担。

重要注意事项

  • 并非所有 Kubernetes 资源都能原样恢复，尤其是外部集成和云托管服务。
  • 恢复时间在很大程度上取决于持久卷的大小和数据占用。
  • 快照、存储和保留的费用遵循标准的 AWS Backup 计费。
  • 这 并不 替代 GitOps——它通过提供最后一次已知良好的运行时恢复选项来补充 GitOps。

对于在 AWS 上运行生产 EKS 的团队而言，此功能并不能取代良好的工程实践，但它显著降低了集群级别故障的风险和压力。仅此一点，就足以让它成为 EKS 运维工具箱中的重要补充。

参考资料

Back to Blog

相关文章

阅读更多 »