# 一、事件概述
在一台存储服务器（H3C UniServer R4300 G3）上部署安克诺斯（Acronis）备份虚拟化环境，出现严重存储耗尽及虚拟机不可用故障。
## 1. 硬件与资源信息
* 服务器型号：H3C UniServer R4300 G3
* CPU：2 × 32 核（约 2.89 GHz）
* 内存：255.66 GB
* 存储容量：145.86 TB
## 2. 架构设计
* 在该服务器上部署虚拟化环境
* 运行 2 套 Acronis 备份系统虚拟机
* 每个虚拟机分配约 62TB 存储空间
* 合计备份虚拟化存储约 124TB
# 二、故障现象
## 1. 故障表现
运行大概两年后，某日出现以下现象：
* 两个 Acronis 备份虚拟机同时无法访问
* 管理平台提示存储不可用 / 无法写入
* 虚拟化平台页面无明显异常
* 存储空间显示“已耗尽”
## 2. 现场排查
通过 SSH 登录虚拟化宿主机发现：
* 某一虚拟机出现异常大快照文件：
-rw-r--r-- 1 root root 514 Dec 7 2023 安克诺斯-10.53.123.98-39151d94.hlog -rw-r--r-- 1 root root 14 Jun 22 01:16 安克诺斯-10.53.123.98-aux.xml -rw------- 1 root root 120.0G Jun 22 01:48 安克诺斯-10.53.123.98-flat.vmdk -rw------- 1 root root 264.5K Jun 21 05:46 安克诺斯-10.53.123.98.nvram -rw------- 1 root root 570 Jun 22 01:48 安克诺斯-10.53.123.98.vmdk -rw-r--r-- 1 root root 77 Jun 22 00:46 安克诺斯-10.53.123.98.vmsd -rwxr-xr-x 1 root root 4.0K Jun 22 01:48 安克诺斯-10.53.123.98.vmx -rw------- 1 root root 0 Apr 29 06:30 安克诺斯-10.53.123.98.vmx.lck -rw------- 1 root root 3.8K Dec 13 2023 安克诺斯-10.53.123.98.vmxf -rw------- 1 root root 241.9G Jun 22 01:49 安克诺斯-10.53.123.98_1-000001-sesparse.vmdk -rw------- 1 root root 377 Jun 22 00:46 安克诺斯-10.53.123.98_1-000001.vmdk -rw------- 1 root root 23.2T Jun 22 01:49 安克诺斯-10.53.123.98_1-000002-sesparse.vmdk -rw------- 1 root root 361 Jun 22 01:16 安克诺斯-10.53.123.98_1-000002.vmdk -rw------- 1 root root 60.0T Jun 23 01:59 安克诺斯-10.53.123.98_1-flat.vmdk -rw------- 1 root root 551 Jun 22 01:48 安克诺斯-10.53.123.98_1.vmdk
# 三、根本问题分析
## 1. 核心问题：超大快照失控
该虚拟机产生了：23TB 级别 sesparse 快照文件
属于严重异常情况。
## 2. 快照形成机制问题
快照链结构：
* base disk
* snapshot-000001
* snapshot-000002（23TB）
说明：
* 快照长期未合并
* 备份任务持续写入
* 未触发自动 consolidation
* 存储持续膨胀
---
## 3. 存储耗尽链式反应
当快照增长到 23TB 后：
* 触发 datastore 写满
* 两个备份系统同时失效
* 虚拟机无法继续写入
* 备份系统服务崩溃
---
# 四、性能与恢复评估
## 1. 磁盘合并理论耗时
基于实际测算：
1:35:37am up 23:58, 1161 worlds, 2 VMs, 17 vCPUs; CPU load average: 0.06, 0.07, 0.07 DEVICE PATH/WORLD/PARTITION DQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd Gnaa.574eac82b03b3018 - 32 - 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 naa.600508b1001c144c140ec89e8ca2546a - 32 - 1 0 3 0.03 344.67 143.61 201.06 16.19 17.76 2.98 0.01 t10.D4963627F63686070CE37AAF5EB5EDD5 - 1014 - 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 23TB ≈ 24,000,000 MB 16MB/s 实际吞吐 ≈ 1,500,000 秒 ≈ 416 小时 ≈ 17 天（理论最慢情况）
---
## 2. 结论
* 即使系统正常运行
* 快照整合也需要 **数天至数周**
* 在生产环境不可接受
# 五、事故根因总结
## 1. 架构设计问题
* 单机承载 2 套大型备份系统
* 每个系统分配 60TB+ 存储
* 未做容量冗余设计
## 2. 快照管理失控
* 长期运行快照未合并
* 未设置快照生命周期限制
* 未监控 sesparse 增长
---
# 六、直接影响
* 两套备份系统全部不可用
* 存储空间耗尽
* 业务备份中断
* 快照合并耗时极长
* 存在数据风险（合并中断即可能损坏）
---
# 七、经验教训总结
## 1. 快照不能长期存在
必须控制：
* ≤ 24 小时生命周期
* ≤ 1TB 建议阈值（生产环境）
## 2. 必须建立快照监控机制
必须监控：
* snapshot size
* sesparse file growth rate
* consolidation task duration
* datastore free space
---
## 3. 存储必须预留“突发空间”
## 1. 架构重建（强烈建议）
* 拆分 Acronis VM
* 独立存储池
* 限制单 VM 最大容量
## 2. 快照策略整改
* 禁止长期 snapshot
* 设置自动清理策略
* 强制监控 consolidation
