（包含下载）静默错误：为什么看了那么多灾难，还是过不好备份这一关？
近日，关于腾讯云的一则事故在朋友圈刷屏。
事件回放
腾讯云披露的整个事件的基本情况如下：
8月6日 消息：近日，腾讯云用户“前沿数控”平台一块操作系统云盘，因受所在物理硬盘固件版本Bug导致的静默错误，文件系统元数据损坏。
腾云在声明中称，监控到异常后，第一时间向用户告知故障状态，并立即组织文件系统专家并联合厂商技术专家尝试修数据，最终终仍有部分数据完整性校验失败。此外，随即对固件版本有bug的硬盘全部进行下线处理，确保相关隐患全部排除。
第一时间制定如下“赔偿+补偿”方案，包括包括全额返还 3569 元费用以及提供 132900 元现金或云资源的额外补偿。不过，"前沿数控"基于自身评估就此次故障对腾讯云提出了高达 11，016，000 元的索赔要求，双方未达成一致。
而在用户端，『前沿数控』的声明则是：
...灾难就发生在2018年7月20日，近千万元级的平台数据全部丢失，包括经过长期推广导流积累起来的精准注册用户以及内容数据，这瞬间将一家创业公司摧毁….
...花了两年多心血打造的平台！当所有内容数据全部丢失，在这种情况下需要花多大代价才能恢复运营？还能运营得起来吗？拿这13万能用来干什么？那是我们公司的命脉！
...丢失的数据包括PC网页、H5、小程序共用的核心数据。平台注册的精准用户数据全部丢失、数十万条用户帖子全部丢失、行业品牌库数据及所有录入的资讯全都丢失。因为是高度垂直的行业，获得流量是极其困难的事情...
而更有网友找出腾讯云硬盘 99.9999999% 的可靠性承诺：
可是毕竟广告好不好，还要看疗效，9个9的可靠性，你也永远无法论证你不是那 0.00000001%。
什么是静默错误
既然腾讯以9个9的代价换来的这次惨痛事故，公告中的“静默错误”就非常值得关注了。那么什么是“静默错误”呢？
静默错误在英文中被称为：Silent Data Corruption，我们知道硬盘最核心的使命是正确的存入数据、正确的读出数据，在出错时及时抛出异常告警。磁盘出现异常的情形可能包括硬件错误、固件 BUG 或者软件 BUG、供电问题、介质损坏等，常规的这些问题都能够正常被捕获抛出异常，而最可怕的事情是，数据处理都是正常的，直到你使用的时候才发现数据是错误的、损坏的。这就是静默错误。
网上的一篇论文：Silent data corruption in SATA arrays: A solution - Josh Eddy August 2008 对静默错误进行了解释，我引用了一段文字进行说明，全文下载请关注公众号“数据和云”回复：122arch 获得（我偷懒扔到之前的目录中了）。
这篇文章提到：
有些类型的存储错误在一些存储系统中完全未报告和未检测到。 它们会导致向应用程序提供损坏的数据，而不会发出警告，记录，错误消息或任何类型的通知。 虽然问题经常被识别为静默读取失败，但根本原因可能是写入失败，因此我们将此类错误称为“静默数据损坏”。这些错误很难检测和诊断，更糟糕的是 它们实际上在没有扩展数据完整性检测功能的系统中相当普遍。
在某些情况下，当写入硬盘时，应该写入一个位置的数据实际上最终写入另一个位置。 因为某些故障，磁盘不会将此识别为错误，并将返回成功代码。 结果，RAID系统未检测到“错误写入”，因为它仅在硬盘发出错误信号时才采取措施。
因此，不仅发生了未检测到的错误，而且还存在数据丢失。 在图2中，数据块C应该覆盖数据块A，而是覆盖数据块B.因此数据块B丢失，数据块A仍然包含错误的数据！
结果，数据被写入错误的位置; 一个区域有旧的，错误的数据; 另一个区域丢失了数据，RAID系统和HDD都未检测到此错误。 检索B或C的访问将导致返回不正确的数据而不发出任何警告。
撕裂写入
在其他情况下，只有一些应该一起写入的扇区最终会出现在磁盘上。 这称为“撕裂写入”，其导致包含部分原始数据和部分新数据的数据块。 一些新数据已丢失，一些读取将返回旧数据。 同样，硬盘不知道此错误并返回成功代码，因此RAID无法检测到它。访问检索B将返回部分不正确的数据，这是完全不可接受的。
上文提到的“撕裂写入”，如果在 Oracle 数据库中发生，那么就是分裂块，当然 Oracle 数据库会自动检测这种情况。
那么“静默损坏”发生的概率有多少呢？该文提供了一组数据：
...一项针对NetApp数据库中150万个硬盘驱动器的学术研究在32个月内发现，8.5％的SATA磁盘会产生静默损坏。 某些磁盘阵列运行后台进程，以验证数据和RAID奇偶校验是否匹配，并且可以捕获这些类型的错误。 然而，该研究还发现，后台验证过程中错过了13％的错误。
那些未被发现的错误，就会成为企业的灾难。虽然我们不知道腾讯云所称的“静默错误”是否与此相关，但是静默错误的确值得大家去了解。
即便没有任何错误，数据也需要定期进行读取，以确保数据无误，在几年前，我遇到过一起案例，Oracle 数据库莫名的发生了一定批量的数据损坏，存储上没有任何错误，但是数据库端大量的分裂块，存储没有检测到错误，并且复制到灾备站点，最后导致了数据丢失。
你可能需要：
对错与利弊
我们姑且不要讨论谁对谁错，我们要知道：只要是硬件就有损坏的一天，只要是运维就有误操作的可能。而且，有一句名言说的好『小孩子才分对错,成年人只看利弊』。云给了我们便利之处，也就一定会有风险相随。
也许很多人已经忘记了广西移动在 2017年9月8号发生的大事故。仅仅因为一个代码 0 和 1 的输入，就引发了影响 80万 移动用户的大故障：
当晚凌晨，该工程师将代码输错（1输成0），导致格式化，进而让80万移动用户的数据遭到清空。事发后，中国移动10086收到了将近2万多条电话投诉，移动和华为立即启动紧急排查处理，整个事故在第二天早上10点才得以控制。
而近年，在云服务商处发生的重大事故可以说是『层出不穷』，国内国外尽皆如此，列举几个 2017 年的事故：
2017年1月20日，大约一定是受到川普上任的影响，突如其来的服务器故障影响了一大批炉石玩家，恢复时间长，由于意外断电，导致数据库损坏，不得不通过游戏回档恢复数据库的使用。（关于炉石传说的Oracle数据库故障不要以为你也可以幸免）
2月1日，除夕刚刚过完，荷兰的一个DBA在数据库复制过程中意外地删除了一个错误的服务器上的目录，删除了一个包含300GB的实时生产数据的文件夹。300G的数据库被删成4.5G，由于没有有效的备份，尝试了所有5个恢复工具都没有完成恢复。在丢失数据并恢复失败后，服务器彻底崩溃。（五重备份无一有效，还有哪些 rm -rf 和GitLab类似的忧伤？）
2月11日，网络剪报服务商 - Instapaper 遭受了超过31小时的服务中断，声明需要一个星期的数据库恢复时间，然而经过10天的恢复，也仅仅恢复了6个星期的数据。（云服务真的靠谱吗？ AWS 用户中断31小时仅恢复6周数据）
2017-04-05，位于纽约的云服务商 Digital Ocean 遭遇了一次长达4小时56分钟的停机事故，事故的原因是主数据库被删除了（primary database had been deleted），由于配置错误，本应指向测试环境的任务被指向了生产环境，测试任务包含的环境初始化过程删除了主生产数据库。（不以规矩不成方圆：Digital Ocean也删除了他们的数据库）
2017年6月 位于荷兰海牙的一家云主机商 verelox.com， 一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容，客户数据恢复希望渺茫。（参考：2017，那些我们一起删库跑路的日子）
而近在今年4月，香港一家云服务上也声明，因为管理员的 rm -rf /* 操作，导致所有的数据丢失：
正所谓，硬件一坏，谁也没招，线路再稳，蓝翔报销，功夫再高，也怕菜刀。
数据备份守则
对于运维来说，最重要的是提高自身的免疫力，获得高抗风险能力，从而在灾难中幸存下来。事关企业数据安危的情况，无论如何都不能疏忽大意。
所以，无论走的多远，也不要忘了最基本也正是最重要的备份，有效的备份才能让企业高枕无忧。怎样保证备份的有效性？那就要做到不仅仅备份，而且还要定期检测备份。
还记得Google曾经轰动一时的流水线删库事件，这可是团队作案哟，这么团结真的好吗？（时移世易：遵从既往经验致 1.5PB 数据删除，Google SRE是如何应对的？）
一个 Google Music 用户汇报某些之前播放正常的歌曲现在无法播放了。Google Music 的用户支持团队通知了工程师团队，这个问题被归类为流媒体播放问题进行调查。3 月 7 日，负责调查此事的工程师发现无法播放的歌曲的元数据中缺少了一个针对具体音频数据文件的指针，于是他就修复了这个歌曲的问题。
但是，Google 工程师经常喜欢深究问题，也引以为豪，于是他就继续在系统中查找可能存在的问题，当发现数据完整性损坏的真正原因时，他却差点吓出心脏病:这段数据是被某个保护隐私目的的数据删除流水线所删掉的。Google Music 的这个子系统的设计目标之一就是在尽可能短的时间内删除海量音频数据。
该流水线任务大概误删除了 60 万条音频文件，大概影响了 2.1 万用户.
没有什么是绝对可靠的，所以要选择相信自己。
我在多年以前总结的 DBA 四大守则，第一条就是『备份重于一切』。
针对Oracle数据库，一套 ADG 环境是最简单的数据保障，备库加上备份，就能够防范硬件故障这个层面的灾难性数据损失，MySQL 通过主备同样可以实现类似的架构。当然您的数据有多重要，应该采取的技术措施就应该有多完善，任何疏忽肯定都是在冒险。
然而对于企业来说，您必须要牢记的是：如果您不能承担数据全部丢失的损失，就要做好自主的可靠数据备份。依赖自己最可靠，依赖他人有风险。
针对种种安全风险，我曾经总结了提升数据库安全的"16条军规"供大家参考，很多朋友也向我们询问，如何做才能够彻底防范这类风险，我想你可以从以下16条建议中找到答案：
备份重于一切
我曾经在总结的DBA四大守则的第一条就指出，『备份重于一切』，有了有效的备份，即使遭遇灾难，也可以从容应对，对于重要的生产环境，适当建立备库进行数据保护，查询分担，也会减少生产库的风险；
唯一会让DBA们从梦中惊醒的就是:没有备份! 所以对于数据库运维来说，第一重要的是做好备份!有备方能无患!
严格管控权限
过度授权即是为数据库埋下安全隐患，在进行用户授权时一定要遵循最小权限授予原则，避免因为过度授权而带来的安全风险。本次安全风险，如果用户只具备最低权限，如不具备DDL权限，那么也不会遭到风险；
明确用户职责
应当明确不同的数据库用户能够用于的工作范围，应当使用普通用户身份的，就绝对不应该使用DBA的用户身份，只有职权相称，才能够避免错误，降低风险。 即便是拥有管理员职责的用户，也应当遵循以不同身份执行不同任务的习惯，比如SYS和SYSTEM用户的使用就应当进行区分和界定；
密码策略强化
毫无疑问，数据库用户应当使用强化的密码规则，确保弱口令带来的安全风险，很多数据泄露问题来自弱口令攻击和提权；
限制登录工具
明确限制不同工具的使用场景，明确规定工具的准确来源，或者通过堡垒机等来限制数据库访问。对于工具也可以做出明确规则和限制，如限制仅能通过SQL Developer访问生产，PL/SQL Developer工具仅能访问测试环境，以减少安全风险甚至误操作风险；
禁止远程DDL
可以限制DDL操作仅能在数据库服务器本地进行，禁止远程连接执行DDL操作，这一手段在很多公司被严格执行，如果具备这一规则，此次的事故可以被直接屏蔽掉；
使用绑定变量
在开发过程中，严格使用绑定变量，绑定变量可以防范SQL注入攻击，减少数据库安全风险；这次安全事故，很多用户开始猜测是SQL注入，走了很多分析上的弯路；
监控监听日志
监听日志记录了数据库访问的来源、程序等信息，包括恶意扫描，密码尝试等，一定要重视监听日志的作用，并对其进行分析和监控，以清楚的汇制数据库访问图谱；云和恩墨一直帮助用户通过监听日志分析来揭示风险，白求恩平台（ https://bethune.enmotech.com ）为用户免费提供这一分析纬度的预警；
数据网络隔离
数据库的网络环境应该一直隐藏在最后端，避免将数据库置于直接的访问连接之下，由此可以减少数据库的访问风险；
测试和生产隔离
互通就意味着同时可以访问，也就可能带来很多意想不到的安全风险，企业应当将测试环境和生产环境部署于不可互通，或者不可同时访问的网络环境中，避免因为错误连接而发生的数据库灾难。 分离部署一方面可以降低误操作的可能性，也可以屏蔽一些无关的访问可能，从而从网络链路上保证数据安全；
密码差异设置
有些测试环境或者非产品环境是利用产品环境恢复得到的，DBA在建立了测试环境后，就没有修改数据库用户的登录密码;经常性的，DBA也习惯在所有环境中设置通用的密码;这些习惯为系统带来了很多风险和不确定性。 我们建议用户在不同环境中采用不同的密码设置，这是因为一方面产品环境和测试环境面对的访问用户不同，密码设置相同则意味着产品环境的安全性完全得不到保障;另一方面，DBA登录到不同的数据库需要使用不同的密码，这进一步减低了DBA在错误的环境下执行命令的可能性。
重要数据加密
很多重要的数据，需要加密存储，最典型的就是用户和密码信息，大量的泄密事件本质上是因为缺乏最基本的加密防范，对重要数据实施一定的安全防护加密，是应当予以适时考虑的安全方面之一；
适时的软件升级
这里的软件指数据库软件，尤其是当Oracle已经发布了安全补丁，已知的安全漏洞被黑客利用，则更可能对数据库产生致命的伤害；
防范内部风险
不可否认，绝大部分安全问题都来自于企业内部，来自最紧密、最轻易的接触和访问，企业的人员变动，岗位变更，都可能导致数据安全问题的出现，单存依靠对管理员的信任不足以保障数据安全，必须通过规章、制度与规 范的约束才能够规避安全风险。
很多企业为了便利而舍弃规范、规章或者安全限制是得不偿失的做法。安全防范应当从内部做起，从限制约束自我做起，当最紧密相关的访问都遵从守则，那么系统的安全性就能够获得大幅度的提升。
树立安全意识
安全问题最大的敌人是侥幸，很多企业认为安全问题概率极低，不会落到自己的环境中，所以对于安全不做必要的投入，造成了安全疏忽。所以安全问题最大的敌人是我们自己，安全需要一点一滴的加强，逐步完善，云和恩墨一直帮助核心客户进行全面的安全评估，制定安全方案，守护数据安全。
开始安全审计
以Oracle数据库为例，数据库已经提供了很多安全防范的手段和方法，我们建议用户适当展开安全防范措施，开启部分任务审计，定期分析数据库风险，由此逐步完善数据库安全。
关注安全，更重要的是意识，阳光之下，并无新事，努力请从今日始！
这可能是你需要的：
数据驱动，成就未来，云和恩墨，不负所托！