EBS快照最常见的误区，是把“创建了快照”当成“已经完成灾备”。真正能救命的不是截图里那一串snap- ID，而是三件事：快照是否能按计划自动产生、误删后是否还有缓冲区、恢复出来的卷能不能挂载并读到业务数据。

本文用AWS CLI演示一套适合小团队落地的EBS备份与恢复演练流程：给EBS卷打标签，用Amazon Data Lifecycle Manager自动创建和保留快照，用Recycle Bin给误删增加保留窗口，最后从快照创建新卷并挂载验证。示例以开发测试环境为主，生产环境必须结合RPO、RTO、合规要求、加密策略和变更窗口调整。

一、先把目标说清楚：快照不是“万能回档键”

AWS官方文档说明，EBS快照是EBS卷的时间点副本，并且是增量备份：只保存自上一个快照以来发生变化的数据块。这能减少重复数据带来的时间和存储成本，但也意味着删除快照时不能简单理解为“删一个文件省一份钱”，因为被多个快照引用的数据块仍可能保留。

还要注意一个更关键的事实：AWS不会自动替你备份EBS卷。官方文档明确提醒，出于数据韧性和灾难恢复，你需要定期创建EBS快照，或者使用AWS Backup、Amazon Data Lifecycle Manager等方式设置自动快照。

所以本次演练的目标不是“点一下创建快照”，而是形成一条闭环：

• 标签：只备份明确标记的资源，避免误扫和漏扫；
• 自动策略：按固定频率创建快照并保留指定周期；
• 误删保护：快照或卷被删除后，Recycle Bin还能保留一段时间；
• 恢复演练：创建新卷、挂载实例、校验文件；
• 记录结果：把RPO、恢复耗时和问题写进表格。

二、准备变量和标签

先配置演练变量：

export AWS_REGION="us-east-1"
export INSTANCE_ID="i-0123456789abcdef0"
export SOURCE_VOLUME_ID="vol-0123456789abcdef0"
export AVAILABILITY_ZONE="us-east-1a"
export DR_TAG_KEY="Backup"
export DR_TAG_VALUE="Daily"
export RESTORE_TAG="dr-restore-test"

aws configure get region
aws sts get-caller-identity

为目标卷打标签。后续DLM策略会根据标签筛选资源：

aws ec2 create-tags \
  --region "$AWS_REGION" \
  --resources "$SOURCE_VOLUME_ID" \
  --tags \
    Key="$DR_TAG_KEY",Value="$DR_TAG_VALUE" \
    Key=Owner,Value=platform-team \
    Key=Workload,Value=web-demo \
    Key=Env,Value=dev

验证标签：

aws ec2 describe-volumes \
  --region "$AWS_REGION" \
  --volume-ids "$SOURCE_VOLUME_ID" \
  --query "Volumes[0].{VolumeId:VolumeId,AZ:AvailabilityZone,Tags:Tags}" \
  --output table

标签治理看起来简单，但它决定了自动化策略是否可控。建议生产环境至少统一四个标签：Env、Owner、Workload、Backup。不要让同一个含义出现backup=true、Backup=Daily、bak=yes三套写法。

三、手动创建一次基线快照

在启用自动策略前，先手动创建一次基线快照，用来验证权限、加密、标签和查询命令是否正常：

BASE_SNAPSHOT_ID=$(aws ec2 create-snapshot \
  --region "$AWS_REGION" \
  --volume-id "$SOURCE_VOLUME_ID" \
  --description "baseline snapshot before DLM drill" \
  --tag-specifications "ResourceType=snapshot,Tags=[{Key=Name,Value=baseline-ebs-drill},{Key=Workload,Value=web-demo},{Key=Env,Value=dev}]" \
  --query SnapshotId \
  --output text)

echo "$BASE_SNAPSHOT_ID"

等待快照完成：

aws ec2 wait snapshot-completed \
  --region "$AWS_REGION" \
  --snapshot-ids "$BASE_SNAPSHOT_ID"

aws ec2 describe-snapshots \
  --region "$AWS_REGION" \
  --snapshot-ids "$BASE_SNAPSHOT_ID" \
  --query "Snapshots[0].{SnapshotId:SnapshotId,State:State,StartTime:StartTime,VolumeId:VolumeId,Encrypted:Encrypted}" \
  --output table

如果这里失败，先不要继续配置自动化。常见原因包括：当前IAM角色没有ec2:CreateSnapshot权限、卷不存在、区域不一致、KMS密钥权限不足。

四、用DLM创建自动快照策略

Amazon Data Lifecycle Manager可以为EBS卷和EC2实例自动管理快照和AMI生命周期。AWS官方文档说明，可以用AWS Backup或Amazon Data Lifecycle Manager自动创建、保留和删除EBS快照；DLM服务本身不额外收费，但快照存储仍按EBS快照计费。

DLM需要一个服务角色。很多账号可以使用默认角色；如果没有，可以创建：

aws iam create-service-linked-role \
  --aws-service-name dlm.amazonaws.com

创建策略文件dlm-policy.json：

{
  "ResourceTypes": ["VOLUME"],
  "TargetTags": [
    {
      "Key": "Backup",
      "Value": "Daily"
    }
  ],
  "Schedules": [
    {
      "Name": "daily-retain-7",
      "CreateRule": {
        "Interval": 24,
        "IntervalUnit": "HOURS",
        "Times": ["17:00"]
      },
      "RetainRule": {
        "Count": 7
      },
      "TagsToAdd": [
        {
          "Key": "CreatedBy",
          "Value": "DLM"
        },
        {
          "Key": "Drill",
          "Value": "EBS"
        }
      ],
      "CopyTags": true
    }
  ]
}

创建DLM策略：

aws dlm create-lifecycle-policy \
  --region "$AWS_REGION" \
  --description "Daily EBS snapshots for Backup=Daily volumes" \
  --state ENABLED \
  --execution-role-arn "arn:aws:iam::<ACCOUNT_ID>:role/AWSDataLifecycleManagerDefaultRole" \
  --policy-details file://dlm-policy.json

把<ACCOUNT_ID>替换为真实账号ID。可以用下面命令获取：

aws sts get-caller-identity --query Account --output text

验证策略：

aws dlm get-lifecycle-policies \
  --region "$AWS_REGION" \
  --query "Policies[].{PolicyId:PolicyId,Description:Description,State:State}" \
  --output table

上线建议：第一周先只选择开发测试卷，保留7个快照；确认策略稳定后，再按业务等级拆分Backup=Daily、Backup=Hourly、Backup=None。

五、配置Recycle Bin防误删

Recycle Bin的价值不是替代备份，而是给误删加一道缓冲。AWS官方文档说明，Recycle Bin可以在你删除EBS卷、EBS快照和EBS-backed AMI后，按你指定的保留期继续保留资源；在保留期到期前可以恢复，过期后会永久删除。

创建一个针对快照的保留规则示例：

aws rbin create-rule \
  --region "$AWS_REGION" \
  --resource-type EBS_SNAPSHOT \
  --retention-period RetentionPeriodValue=7,RetentionPeriodUnit=DAYS \
  --resource-tags ResourceTagKey=Workload,ResourceTagValue=web-demo \
  --description "Keep deleted EBS snapshots for 7 days for web-demo"

查看规则：

aws rbin list-rules \
  --region "$AWS_REGION" \
  --resource-type EBS_SNAPSHOT \
  --query "Rules[].{Identifier:Identifier,Status:Status,Retention:RetentionPeriod,Description:Description}" \
  --output table

注意成本边界：Recycle Bin本身不额外收费，但被保留的卷和快照仍按对应资源计费。别把保留期设得特别长，也不要把所有临时资源都放进同一条规则里。

六、从快照恢复新卷

AWS官方恢复文档强调，从快照创建的新卷必须和要挂载的实例位于同一个可用区。比如实例在us-east-1a，恢复卷也要创建在us-east-1a。

创建恢复卷：

RESTORE_VOLUME_ID=$(aws ec2 create-volume \
  --region "$AWS_REGION" \
  --volume-type gp3 \
  --snapshot-id "$BASE_SNAPSHOT_ID" \
  --availability-zone "$AVAILABILITY_ZONE" \
  --tag-specifications "ResourceType=volume,Tags=[{Key=Name,Value=$RESTORE_TAG},{Key=Purpose,Value=restore-drill},{Key=Env,Value=dev}]" \
  --query VolumeId \
  --output text)

echo "$RESTORE_VOLUME_ID"

等待卷可用：

aws ec2 wait volume-available \
  --region "$AWS_REGION" \
  --volume-ids "$RESTORE_VOLUME_ID"

挂载到测试实例：

aws ec2 attach-volume \
  --region "$AWS_REGION" \
  --volume-id "$RESTORE_VOLUME_ID" \
  --instance-id "$INSTANCE_ID" \
  --device /dev/sdf

连接实例后查看设备：

lsblk
sudo file -s /dev/xvdf

如果原卷有文件系统，创建挂载目录并挂载：

sudo mkdir -p /mnt/restore-test
sudo mount /dev/xvdf /mnt/restore-test
df -h /mnt/restore-test
ls -lah /mnt/restore-test

有些Nitro实例里设备名可能显示为/dev/nvme1n1，这时以lsblk输出为准，不要死记/dev/xvdf。

七、做一次最小可用的数据校验

只看到卷挂上了还不够，至少验证三类内容：

# 1. 关键目录是否存在
sudo test -d /mnt/restore-test/app && echo "app dir ok"

# 2. 关键配置是否能读取
sudo ls -lah /mnt/restore-test/etc 2>/dev/null || true

# 3. 业务文件数量是否符合预期
sudo find /mnt/restore-test -maxdepth 2 -type f | wc -l

如果是数据库卷，不能只靠文件数量判断。更好的做法是在测试环境拉起数据库进程，执行只读查询，确认版本、表结构和少量样本数据。

记录恢复演练表：

验收项	通过标准	记录
快照状态	completed	快照ID、完成时间
恢复卷	available并可attach	卷ID、AZ、类型
挂载	实例可识别并mount	设备名、挂载点
数据	关键目录/文件/查询可用	样本结果
时间	记录从开始恢复到可读数据耗时	RTO实测
清理	恢复卷已卸载并删除	删除时间

八、清理演练资源

演练结束后卸载并分离恢复卷：

sudo umount /mnt/restore-test

aws ec2 detach-volume \
  --region "$AWS_REGION" \
  --volume-id "$RESTORE_VOLUME_ID"

aws ec2 wait volume-available \
  --region "$AWS_REGION" \
  --volume-ids "$RESTORE_VOLUME_ID"

确认不再需要后删除恢复卷：

aws ec2 delete-volume \
  --region "$AWS_REGION" \
  --volume-id "$RESTORE_VOLUME_ID"

基线快照是否删除，要看是否命中Recycle Bin规则和团队保留策略。生产环境不要在没有变更记录的情况下手工删快照。

九、常见坑

第一，只备份不恢复。没有恢复演练的备份，价值只有一半。建议至少每月抽样恢复一次。

第二，卷和实例不在同一可用区。EBS卷只能挂载到同一AZ的EC2实例。

第三，KMS权限漏配。加密快照恢复时，创建卷、挂载实例和读取数据都可能受到KMS策略影响。

第四，把DLM保留周期设得太短。快照成功创建不代表业务回滚点足够。要按RPO设计频率和保留数量。

第五，误以为快照在S3控制台可见。EBS快照数据存储在Amazon S3中，但不能通过S3控制台或S3 API直接访问。

第六，删除快照不一定立刻明显降费。因为快照是增量的，被其他快照引用的数据块不会因为删除某个快照而全部释放。

结语

小团队做EBS灾备，不需要一开始就上很复杂的平台。先把标签、DLM自动策略、Recycle Bin误删保护和恢复演练四件事做成固定流程，就能避免很多“有快照但救不回来”的尴尬。

如需国际云服务器合规开户流程咨询、AWS资源规划、备份恢复、成本治理和运维支持，可通过平台私信说明业务区域、实例规模、RPO/RTO目标和预算上限。客户本人完成实名、验证码、支付和合同确认；本文不含返佣链接，不承诺固定节省比例。

官方资料

1. Amazon EBS snapshots：https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html
2. Automate data backups with AWS Backup and Amazon Data Lifecycle Manager：https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html
3. Replace an Amazon EBS volume using a snapshot：https://docs.aws.amazon.com/ebs/latest/userguide/ebs-restoring-volume.html
4. Recover deleted EBS volumes, EBS snapshots, and EBS-backed AMIs with Recycle Bin：https://docs.aws.amazon.com/ebs/latest/userguide/recycle-bin.html