选灾备方案前，先把现有备份的"盲区"列出来
集团要评估专业灾备（DR）方案（比较了 Datto、Druva 等几家），第一步是按标准流程填写 vendor 的 sizing form——列出每台服务器的硬件规格、角色、数据量，用来估算存储需求和报价。填这份清单的过程中，反而先暴露出现有备份体系里两个从来没被认真面对过的盲区。
盲区一：一台服务器”没有真正被备份”
清点服务器角色时发现，某台跑 RDS（远程桌面）服务的机器，VEEAM 因为兼容性问题始终无法正常备份。当时的应对方式是退回最原始的方案——用本机 Windows Server Backup 做本地备份，大小约 400GB。
这不是”没有备份”，但也远不是”有效的灾备”：本机备份意味着备份和生产数据physically 绑在同一台机器上，机器本身故障（硬件损坏、勒索软件加密整个磁盘）时，备份和数据一起完蛋。这台服务器在灾备版图里其实是一个长期存在、但从未被正式承认的缺口。
盲区二：数据库大小对不上账
另一台跑 SAP 的服务器，MSSQL 数据库的实际大小是 2-3TB，但每天跑出来的完整备份文件只有 590GB——差了整整四五倍。
这个差异当时没有人能立刻解释：是数据库里有大量从未清理的历史日志/临时表被压缩得特别好？是备份软件的某个排除规则悄悄跳过了什么？还是”2-3TB”这个估算本身就不准？无论答案是什么，任何拿不准数字的地方，都不该直接填进供应商的报价单——填错的数字只会算出一份错误的价格和一份错误的容量规划。
选型报价单填的是数字，但数字本身可能就是问题
正确的顺序
选灾备方案的第一份文档，不该是供应商的报价单，而是自己的**「现有防护现状盲区清单」**。
- 先审计覆盖率：逐台服务器核对”是否真的在被有效备份”，而不是”备份软件的任务列表里有没有它”——任务存在 ≠ 备份有效；
- 核实关键数据量：数据库、文件服务器的真实数据量和备份产出的大小要能互相解释，解释不了就要先查清楚，不要带着问号做容量规划；
- 拿准确数字再谈判：sizing form 填的数字越准，报价和后续的容量扩展越贴近实际，返工成本降到最低；
- 把发现的盲区本身也变成一个改进项——不必等 DR 方案上线才补，VEEAM 备不了的服务器可以先单独想办法（换 agent、隔离评估、或者先接受本机备份作为过渡但要写进风险清单）。
教训
- 供应商的报价单只对它收到的数字负责，它不会主动替你发现”这个数字本来就不准”；
- 备份任务”跑成功”和”覆盖到位”是两件事——要按服务器逐台核对角色和保护现状，才能画出真正的覆盖地图；
- 数据量对不上账的情况，本身就是一个值得单独立项排查的信号，不要把它当成”算了随便填一个数字”糊弄过去。