阿里云代支付服务 阿里云服务器备份与恢复实操

各位正在给服务器做备份时手抖点错按钮、恢复时发现快照早被自动清理、或者对着控制台三个‘备份’入口发呆的朋友——欢迎来到阿里云ECS备份与恢复的人间真实现场。

别急着翻文档。我刚在测试环境重装了7次系统、删了5个快照链、误删过一次生产库却靠3小时前提前打的快照满血复活——这篇不是教程，是带血丝的笔记。

一、先泼冷水：阿里云没给你‘一键备份全家桶’

很多人以为买了ECS就自动进保险柜了？醒醒，阿里云只负责给你一把锁（快照），钥匙（策略）得你自己焊、自己藏、自己定期检查锈没锈。

官方文档里那句‘快照可保障数据安全’后面其实还有一行小字：‘但不自动保留，不跨地域同步，不校验一致性，不替你记住哪天该删哪个快照’——这行字，我们加粗、标红、钉在工位墙上。

二、三把刀：快照｜镜像｜OSS归档，用对才叫备份

① 快照：你的‘时间胶片’，但不是‘时光机’

快照本质是磁盘某时刻的块级副本，优点：秒级创建、支持增量、成本低（按实际增量计费）。缺点：仅限同地域、同可用区挂载恢复；不能直接当启动盘；系统盘快照≠完整系统可启动。

实操要点：

• 系统盘快照恢复后，必须重新初始化实例（不是‘重启’！是‘重置系统盘’+‘重新绑定’），否则看到的还是旧系统；
• 数据盘快照恢复更简单：创建新云盘→选择快照→挂载到实例→fdisk -l确认设备名→mount /dev/vdb1 /data（路径按需改）；
• 千万别信‘自动快照策略=万无一失’——它默认只保留3份，且不会通知你第4份要覆盖第1份。上周我一个客户因没关自动清理，上线前发现最新快照是3天前的…

② 自定义镜像：能‘克隆’整台服务器的狠角色

镜像是快照的升级版：它打包了系统盘快照 + 实例配置（CPU/内存/网络）+ 可选的数据盘快照。最大优势：跨地域复制、可共享给其他账号、能直接创建新实例。

但注意两个致命细节：

• 创建镜像前必须停止实例（不是停机，是‘已停止’状态）；热创建？系统可能写缓存未落盘，镜像启动后蓝屏/启动卡死/分区表损坏——我在杭州节点试过3次，2次进不了GRUB；
• 阿里云代支付服务 数据盘若想进镜像，必须勾选‘同时创建数据盘快照’，且该快照会独立计费。很多人只选系统盘，结果新实例起来发现/data空空如也…

③ OSS手动归档：给关键数据上‘双保险’

快照和镜像都在云盘底层，万一整个可用区故障（虽然概率极低），它们可能一起消失。这时OSS就是你的‘异地保险柜’。

推荐姿势：

1. 每天凌晨2点用crontab执行脚本：tar -zcf /backup/www-$(date +%F).tar.gz /var/www && ossutil64 cp /backup/www-*.tar.gz oss://my-backup-bucket/；
2. OSS Bucket开启版本控制+跨区域复制（比如华东1→华北2），再配个生命周期规则：30天前的归档存储，90天后转低频；
3. 重点来了：每月1号手动上传一次‘校验文件’，比如md5sum /var/www/* > checksum_$(date +%F).txt，避免OSS传一半断电导致文件损坏却浑然不知。

三、恢复？别光点‘回滚’，先做三件事

很多同学恢复失败，不是操作错，是没做前置验证。请默念三遍：

“我确认快照创建时实例处于静默状态”
“我确认目标云盘类型（SSD/ESSD）支持该快照”
“我确认恢复后没有同名挂载点冲突（比如原挂载/data，新盘也想挂/data）”

分场景恢复口诀：

• 系统崩溃无法登录？ → 控制台选‘重置系统盘’→选快照→勾选‘重置后自动启动’→等3分钟，SSH密码不变，但所有软件重装（快照是盘，不是虚拟机）；
• 误删数据库？ → 新建云盘→选快照→挂载→cp /mnt/newdisk/var/lib/mysql/* /var/lib/mysql/→chown -R mysql:mysql /var/lib/mysql→systemctl start mysqld；
• 想换配置又怕丢数据？ → 先打镜像→新建高配实例→选择该镜像→启动后立刻停机→用新实例的系统盘快照覆盖旧实例（反向操作！）。

四、那些文档不说、但会让你凌晨三点爬起来的坑

• 快照链断裂：自动快照策略如果中间断过1次（比如账户欠费暂停），后续快照将丢失增量依赖，变成全量快照，费用暴涨+恢复变慢。解法：每月1日手动触发一次‘立即创建快照’，强制续链；
• 跨地域恢复失败：快照不能跨地域！但镜像可以。很多人把‘快照复制’和‘镜像复制’搞混——前者只是拷贝一份快照数据（仍属原地域），后者才是真正的迁移；
• 恢复后网站打不开：大概率是SELinux或防火墙拦截。快照恢复后，setenforce 0临时关闭SELinux，systemctl stop firewalld，确认服务正常后再逐步打开；
• 快照用了半年，恢复却报错‘快照不可用’：检查是否开启了‘快照自动清理’且设置了‘保留7天’——你以为它留7份，其实是‘7天内创建的快照’，过期全删。建议改成‘保留份数’模式。

五、终极建议：建立你的‘备份健康度日报’

别等出事才看。每周五下班前花5分钟执行：

1. 登录控制台→快照列表→筛选‘最近7天’→确认至少有3份有效快照（系统盘+核心数据盘各1）；
2. 进OSS→检查backup/www-目录下最新.tar.gz的LastModified时间是否≤24小时；
3. 随机选1个快照→创建新云盘→挂载→ls -lh /mnt/test/确认关键目录存在；
4. 最后，在团队群发条消息：[备份巡检] 2024-06-28 ✔️ 系统盘快照OK｜OSS归档OK｜验证挂载OK——仪式感，是运维最后的体面。

最后送一句掏心窝子的话：备份不是技术问题，是习惯问题。就像你不会只靠一把家门钥匙过日子，也不会只靠一次快照扛全年风险。

下次当你手悬在‘创建快照’按钮上方时，请默念：此刻多点1秒确认，未来少熬3小时夜。

（完）