不知道大家今天看没看一个新闻，链家删库的程序员宣判了。

　　事情是这样的：

　　2018 年的时候，链家的一名技术人员因为不满公司的岗位调动，远程删除了公司服务器上的电子商务系统（ Oracle EBS ），总共 9 TB 的数据。。。

　　删完这 9 TB 大小的数据之后，他相当于把整个公司的账本给抹了：

　　链家成立以来所有的员工工资、采购报销记录、供应商的货款等等，全都没了。

　　说句不好听的，假如这些数据拿不回来，大家也别干活了，直接原地回家放假就完事了。

　　在公告里链家表示，他们花了 18 万解决这个事：

　　首先花了 10 万找数据公司恢复数据，但是恢复出来的数据不怎么能用。

　　后来他们只好又花了 8 万，从外面雇人重建了整套 EBS 系统。

　　听着挺心酸的，对吧。

　　不过不知道小伙伴们有没有发现一个华点：在这件事当中，链家先是找人恢复数据，但是没成功。

　　可他们还是老老实实掏了 10 万。

　　但是与此同时，网上各种各样的免费数据恢复软件也有不少，点个按钮就能一键恢复被删除的数据。

　　虽然八成也成功不了，但至少不要钱不是。

　　所以链家。。这是被二次割韭菜了吗？

　　差评君平常在后台也经常收到小伙伴们的消息，说自己一不小心把 U 盘里的文件给误删了，求助有关数据恢复的事项。

　　正好借着这个由头，咱们来稍微聊聊数据恢复是怎么一回事。

　　其实不管是免费软件、付费软件，还是专业的数据恢复机构，它们都是利用了硬盘的一个工作原理：

　　你删除的文件，并不是真的被删除了。

　　不知道小伙伴们拷文件的时候发现过一个现象没有：

　　假如复制一部电影的话，可能得慢慢悠悠的让进度条跑上一两分钟。

　　但是删除一部电影，一瞬间就搞定了。

　　这就是因为在点击删除的时候，系统只是给这部分数据打上了一个删除标记，但并没有真删。

　　听着可能有点绕，我们不妨拿图书馆举个例子：

　　差评君以前上学的图书馆里有上千本书，这么多书直接找肯定找不到。

　　所以图书管理员那里有个索引系统，哪本书在哪个位置都能查到。

　　我们往硬盘里复制文件，其实就相当于是往书架上放了一排书，然后告诉管理员我把哪本书放到了哪排货架上。

　　可要在删除文件的时候，硬盘偷了个懒——

　　它只是跟管理员说了一声那排清空了，但并没有真的把书从书架上撤走。

　　然后管理员就真的把这条索引涂掉了，这本书真的就找不到了。。。

　　硬盘倒是觉得自己很聪明：“反正下回有新书进来的时候一起搬走就好了嘛，现在费那个劲干嘛。”

　　这么做的好处显而易见，用户体感的删除速度变快了、硬盘的读写损耗变少了。

　　而且顺带着，文件恢复成功的概率也变高了 ——只要没有新的书进来，原来的书就还会在那儿。

　　只是我们以为它们已经不在了。

　　所以其实和很多小伙伴想的不太一样，数据恢复并不是施展时间の魔法，让时间倒转。

　　它仅仅是重新亲自去一排一排的货架上寻找，有哪些书明明还在，但是被索引给划掉了。

　　最终找到我们希望找回的文件。

　　而专业的数据恢复机构无非就是有无尘工作间以及更厉害的硬盘对拷设备，能够提高一些恢复成功率而已。

　　但是那些已经被彻底擦除的数据，谁都无能为力。

　　所以在坊间一直有个说法：固态硬盘的数据比传统的机械硬盘要难恢复很多。

　　这是因为，固态硬盘为了进一步提高读写速度，使用了一项名叫 TRIM 的技术。

　　而所谓的 TRIM ，实际上就是图书管理员雇了一个监工，负责定期检查那些已经被标记为撤走的书还在不在书架上。

　　假如这些书还在，他就会负责把这些书撤走。

　　这样以后再有新书上架的时候，就不用再额外花时间搬旧书了。

　　TRIM 技术让固态硬盘长期保持了高速可用的状态，但是对应着，数据恢复的成功率就无限降低了。

　　因此，不管是自己恢复还是找数据机构恢复，数据恢复成功的概率都大概是下面这样：

　　U 盘/数据机械盘>系统盘>>固态硬盘。

　　所以要是小伙伴们真的有数据保管的需求，重要资料最好还是放在机械硬盘上保存啊。

　　或者像差评君一样，搞个阵列 NAS 。

　　那么假如真的遇到了数据误删应该怎么做呢，差评君在这里再总结一下数据恢复的重点：

　　首先立刻强制关机，停止数据在硬盘上的读写操作。

　　接着烧根香。

　　接着找个拷盘器，配合数据恢复软件扫描并且复原被删除的数据。

　　或者直接找家数据恢复公司。

　　怎么样，大家学废了吗？

　　知道了这些之后，我们再来聊聊链家删库这件事。

　　照道理来说，链家财务系统的数据库还不至于使用高性能的固态硬盘，而机械硬盘上面的数据恢复概率还是不低的。

　　所以为什么链家最后花了十万也没能把数据找回来呢。

　　我们不妨来看看这起案件的审判书，上面提到，链家的技术人员是在发现财务系统连接不上之后，才开始查找问题的根源。

　　这个时候距离删库已经过去了一个多月，硬盘上已经不知道被写入了过多少新数据了。

　　并且这名员工在删除文件时，除了使用了标准的“ rm ”删除命令之外，还使用了“ shred ”文件粉碎命令。。。

　　相当于在标记删除的同时，还会在上面覆盖一层新的无用数据。

　　那些本来还有希望恢复的数据，在一个 shred 命令碾过去之后，也就被抹的什么都不剩了。

　　这。。是得跟公司有多大的仇啊。。。

　　其实就在去年二月份的时候，另一家公司“微盟”也发生过类似的事件。

　　微盟是一家给餐馆饭店小商铺提供在线付款支持的公司，帮助不怎么懂网络的个体商户对接支付宝微信云闪付一类的结算系统。

　　做的还挺大，已经上市了。

　　结果同样是有个员工不满公司待遇，把公司的核心业务系统给删干净跑路了。

　　你们看这个剧情，是不是完全一致。

　　不过毕竟是核心业务系统，微盟还是有备份的，不至于像链家这么头秃。

　　但是恢复备份的过程中还是产生了业务停摆。

　　据微盟统计，数据恢复期间至少有 300 万个商家无法接收顾客的付款，微盟因此赔付了 1.5 个亿。

　　股票的市值也在当天蒸发了接近 10 个亿。

　　然后那名删库的老哥，也自然而然被判了六年。

　　一般情况下，这种员工报复老板的事在坊间都是有不少瓜可吃的，比如人力关系什么的。。。

　　不过咱们本着不信、不传谣的态度，就不拿这些瓜说事了。

　　差评君最后想说的是， 犯法的事情不要干！不要干！

　　不然不但报复不了老板，还得把自己搭进去。。。

　　那样可就太不划算了。