备份做了等于白做？厦门中小企业数据备份3个致命错误

备份做了等于白做？厦门中小企业数据备份3个致命错误 - 所有行业IT解决方案

你有没有想过，你们公司的数据备份可能根本没用？

上周五下午，翔安工业区一家电子厂的老板打电话过来，声音急得不行——服务器被勒索病毒加密了，ERP和MES系统全停，年底的订单数据打不开。我问他："备份呢？"他说："有啊，每天晚上自动备份到NAS上。"

问题就出在这儿。

我远程看了一眼网络拓扑——NAS挂在服务器同一个内网段，共享目录的读写权限全开，连密码都没设。勒索病毒进来之后，不只加密了服务器上的源文件，顺着网络共享把NAS上的备份文件夹也一并加密了。备份文件后缀也变成了.cbt，跟源文件一样，谁也读不了。

老板愣住了："那……备份不是白做了？"

说实话，这种场景我们见太多了——不是没做备份，是备份做了等于没做。据一份行业统计，大约65%的中小企业有数据备份措施，但其中近一半的备份在灾难发生时无法成功恢复。问题不是出在"要不要备份"，而是"怎么备份才靠谱"。

今天聊三个最常见的坑，都是真金白银换来的教训。（说到这个，我泡了杯茶慢慢写，因为这话题我能讲一下午）

坑一：备份跟数据放一起，没有隔离

这是最要命的，也是最常见的。

我见过的企业，有把备份文件放到服务器第二块硬盘的，有挂个移动硬盘每天凌晨自动同步的，也有像前面说的那样丢到内网NAS上的——本质上都一样：备份和源文件之间没有真正的隔离。

中了勒索病毒后，病毒同样有权限访问这些"备份"。它们会先枚举网络共享，发现可写目录直接开干。没设权限隔离的NAS备份，在勒索病毒面前就是一盘菜。

怎么解决？离线备份和不可变存储两条路。
离线备份更简单：备份完成后，让备份介质脱离网络。外置硬盘备份完拔掉就行。对，就这么简单，但多数企业嫌麻烦做不到——我猜你们公司的备份硬盘是不是也一直插在服务器上？
不可变存储更高端一点：群晖NAS的"快照+副本锁定"功能，备份文件写入后设为只读，谁都不能删不能改——管理员也不行。这个功能在防勒索场景下确实好用。

厦门本地部署一套带快照锁定的NAS方案，设备加配置服务大概四五千起步，比一次服务器挂了找应急响应便宜得多。

坑二：备份了但从来不验证

这比第一个坑更隐蔽。备份任务天天跑成功，日志里写的都是"Succeeded"——但备份文件可能早就坏了，你并不知道。

湖里创新园一家做跨境电商的公司就栽在这上面。他们用Windows Server自带的备份功能，每天都显示"备份成功"。直到有一次数据库崩了需要恢复，才发现三个月前的备份文件就已经损坏了——中间三个月每天备份的都是"损坏的副本"，日志却一直显示绿色通过。

备份的意义不在于"做了备份"，而在于"能恢复"。无法恢复的备份等于没有备份。

正确做法两条：
一是定期做恢复演练，每季度至少抽一次，从备份里恢复一个文件看看能不能正常打开。别嫌麻烦，花20分钟验证一下，比出事后再查日志说"早知道"有用多了。
二是用带完整性校验的备份工具。Veeam Community版免费，Duplicati也是开源的，都支持备份后自动校验哈希值，文件不一致了会有告警。

部署一套自动化备份校验方案在厦门大概两三千配置费。相比一次数据丢失可能带来的影响——NCSA数据显示60%的中小企业在数据丢失后6个月内倒闭——这个投入我觉得没必要犹豫。

坑三：所有备份都在同一栋楼里

同安工业集中区一家食品加工厂，去年年底车间电路老化引发小火灾。火不大，灭火器就搞定了，但消防水喷淋系统启动后，二楼机房的服务器和旁边的备份NAS全泡了水。本地备份做得再好，物理层面的火灾水灾一来，源数据和备份数据一起玩完。

这也就是3-2-1备份策略被当成行业标准的原因——简单说就是：数据存3份，用2种不同的东西装，其中1份必须放到不同地方。比如服务器一份、NAS一份、云端一份。NAS和云是两种不同介质，云放在异地机房，本地着火了也烧不到。

具体怎么落地？厦门电信企业宽带100M对称上下行一年大概两三千，再加阿里云OSS做异地同步，每月多花一两百块——相当于一个人在外面吃顿火锅的钱。开启WORM（一次写入多次读取）策略后，上传到云端的备份文件在设定保护期内不可删改，勒索病毒进了内网也拿它没办法。

最后说两句

备份这事说起来真没什么技术含量，但90%的企业会踩以上三个坑里的至少一个。核心就三句：隔离、验证、异地。

戴维信安在厦门做了十来年IT服务，帮不少企业重新搭过备份方案。我们发现大多数时候问题不在于企业不舍得花钱，而在于"花了钱但没有正确配置"——备份设备买了、软件装了，但隔离没做、验证没跑、异地没配，结果跟没备份一样。

你们公司的数据，今天备份了吗？备份文件你确定能恢复吗？如果明天早上服务器开不了机，你要花多久才能把业务跑起来——这几个问题，找个时间确认一下，比出事后再翻日志有用得多。