2017年5月12日，臭名昭著的勒索病毒永恒之蓝WannaCry利用139、445等端口存在的协议漏洞入侵了主机系统，并将主机上包括图片、文档、压缩包、音频、视频、可执行程序等几乎所有类型的文件加密成后缀名为“.WNCRY”的文件，这种加密方式采用的是更复杂的RSA加密方式，并且密钥大小不断增加，导致至今没有一个有效的解密方法。一时间，哀鸿遍野。

其实，勒索病毒远没有看上去的那么可怕，寄希望于通过支付勒索赎金获得密钥也仅仅是下下之策。更为有效的方式，其实是建立一套完整的数据持续保护（CDP）系统，通过数据的快速恢复让黑客的邪恶用心落空。亡羊而补牢，未为迟也。

WannaCry只是勒索病毒中的一种，在专业技术团队的世界里，无论是哪种勒索病毒，其实都有一定的应对之策。例如，对于被勒索病毒加密的文件，如果解不了密，可以采用恢复备份数据的方法，如利用真CDP恢复。

英方自主研发的字节级CDP技术已经成为行业的标配，拥有自主核心技术，成功应用在火箭军、浙江省检察院、河北公安消防总队、国金证券、中原地产等项目中，并且获得全国各地合作伙伴的信赖，福建意德信息技术有限公司（以下简称福建意德）便是其中一个。

福建意德在信息技术领域拥有众多品牌解决方案，在CDP技术方案中，福建意德采用英方真CDP方案，已经为区域用户构建起信息安全的最后一道防线。双方为了测试英方真CDP技术在病毒感染后数据库中数据恢复的表现，英方工程师刘东昌联合福建意德在真实生产环境中进行了WannaCry病毒测试恢复的演练。

测试效果如何，WannaCry勒索病毒是否造成生产库数据丢失，请看下文的详细测试过程。

【测试目的】

本次测试主要是用于验证生产机通过部署英方i2CDP软件进行实时备份后，工程师主动释放勒索病毒到生产机模拟生产机中毒，以检验数据能否通过i2CDP恢复，能否最大化的减少数据的丢失量。

【评判标准】

当释放病毒进行原数据库感染后，如果通过i2CDP回滚操作，在新的Oracle数据库中能够执行查询等操作，证明数据恢复成功。

【安全告知】

病毒感染测试，安全第一。测试环境需要满足端口开放，病毒释放和独立安全的虚拟机空间等条件，确保WannaCry病毒在恢复测试时安全可控，不会波及到其他IT系统和文件。因此，请各位专业人士严格按照安全规定进行，结束后销毁虚拟机和病毒。

【测试环境】

测试流程和软件配置如下。

例如，本次测试环境如下——

※操作系统版本

生产库：Windows server2008_R2、oracle 11g

备份主机：CentOS 6.4

备用库：Windows server2008_R2、 oracle 11g

※安装包准备

控制台：info2soft-ctrlcenter-6.1-21441.exe

节点：info2soft-i2node-6.1-21441.x86_64.exe

※测试数据准备——Oracle数据库数据

【测试场景及步骤】

场景——模拟生产库中WannaCry病毒恢复。

步骤如下图。

【释放病毒感染】

在安全空间释放WannaCry勒索病毒之后，很快就接收到了文件被感染后的勒索对话框，提示文件已被加密，提示支付虚拟货币以解密你的重要文件。

【CDP任意恢复】

文件被感染之后，工程师通过英方i2CDP进行数据恢复之后，在新的数据库中随机选取两个时间点对数据库进行查询，查询结果如下。

结果验证1（15:10:38秒）——左边为回滚规则，右边为恢复完数据后的查询结果。

结果验证2（15:48:58秒）——左边为回滚规则，右边为恢复完数据后的查询结果。

※两次查询都能顺利进行，证明恢复到新数据库的数据可用，恢复成功！

【测试结论】

根据本次工程师现场的测试结果，可以明确得出如下结论：

其一：通过英方真CDP可有效保护数据，在客户数据感染勒索病毒后，可通过i2CDP进行恢复。

其二：通过英方真CDP几乎不丢失任何数据，可将数据恢复至中病毒前任意时间点，精确到微秒级。

另外，针对非数据库数据的恢复（如独立桌面文件），根据勒索病毒是加密后进行源文件删除的特点，英方真CDP还能够通过找回被删除的原文件进行秒级恢复，并且不要定位感染时间。

人生大起大落落落落落落，实在是太刺激了，下面这真是一个悲伤的故事。

那年公司 ERP 系统刚进行升级。

因为公司陆续上了 MES 和 PDM 系统。为了加快整个公司信息化平台的统一，请了个第三方公司来做中间接口。

然后故事开始了。

某一个晚上，第三方人员问我要 ERP 的 SA 密码。

我很警惕：“你要干嘛?”

“我测试一下中间表。”

“有没有写表的操作?”

“没有，只有读表的操作。”

于是我放心的给了 SA 密码。给了 VPN 权限通道。放她进来了。

十分钟后…..

她带着哭腔打电话来(是的，对方做测试的是个 93 年的萌妹子。)

“吴哥哥， 服务器中毒了 。。。。”

我当时还在逛果壳呢，一听她说我服务器中毒了，我表示无比淡定。还以大哥的经验教训了一顿她。

“叫你不要往我服务器传插件嘛，这次帮你解决一下，下次不准了哟。”

我认为是小 case 呢，不就中毒了嘛，系统往回滚一天就好了。

然后悲剧的事情就出现了，远程进不去，于是我就去机房本地登录，居然也进不去。

我不死心，强制重启，居然还是进不去。我的服务器系统就这样崩了。。。

好在那几天在做开发，系统没有启用，于是我和我的老板汇报了这个情况：

“老大，我们服务器系统崩了。”

“哦，那就搞好它让它别崩。” 果然是霸道总裁啊。

当时数据和应用服务器我都是分开跑的，所以应用服务器奔溃了，我觉得也没多大事，就重新做系统吧。于是我重新做了个系统，然后喊萌妹子上来搭平台。

“小刘啊，你可害惨我了，一个下午给你重做服务器系统了，我基础环境都配置好了，你上来搭平台吧。”

萌妹子那是无比的歉意啊，又是答应请我吃饭又是答应请我看电影的。我都想系统再崩溃一次了。

按理说这样应该是没问题了，就在我走出机房，在外面抽了根烟，45 度仰望了一下天空，联想了一下和萌妹子点个 9 分熟的牛排，在喝一口二锅头这样浪漫的晚餐的时候。电话来了。

来电话的是萌妹子的老板。

“小吴，我想找一下 information.db 和 mfmedia.db 这两个总表没找到，你给我找一下。”

我都蒙了，从来没人问过我这样的问题，难道她老板不是 IT 行业的。

“ 数据库文件都在目录树里啊 ，自己去找啊。”

“没有。”

于是我登上服务器一看，我傻了。 所有的表都空了，所有的表都静静的躺在那，但是里面都空了。。。

不可能啊，我数据库是放在另外一台服务器上的，怎么可能会没有了。

于是我问萌妹子：“XXX，你到底做了什么操作啊，为毛我数据库都没了。”

萌妹子说：“我啥也没干啊，只是按照步骤一路点 YES。”

我才想起来， 在第一次配置基础环境的时候，建账套会提示是否初始环境，如果点是了，数据库就会被初始化 ，然后这位萌妹子傻傻的点了是。

“你知道不知道你干了什么， 公司 06 年到现在所有的数据，财务的，供应链的，进销存的全部都在这台服务器里，200 多个 G 数据，因为你一个是，全没了 。”

萌妹子也吓蒙了，话都说不出来了。

没办法，我再给我老板打电话。

“老板，有个好消息，有个坏消息。”

“直接说坏的。” 我就喜欢我们老板这么直接。

“恩。。恩。。那个。。就是那个。ERP 的数据没了。”

“哦，那就找回来。” 老板还是那么的霸气。我特么都要爱上他了。

“老板，我想你没明白这个的严重性。ERP 数据没了，从 06 年开始的都没了，这意味着就算找回来，整理所有的表，排错也需要 3 天左右时间，到时候所有的生产都要暂时停止。如果找不回来，我们可能就要倒闭了。”

我忽然有种掌握天下苍生的感觉。。。

对面沉默了 5 秒后，爆吼了一句：“吴 XX，你给我滚到我办公室来!!”

中间和老板手握手谈心，被老板亲切慰问的细节跳过不表。

当时公司高层对数据安全还没有那么重视，之前预算做的项目，我已经做了备份的计划书，一直没被审批下来，现在估计悔得肠子都清了。

于是我开始漫长的 数据恢复之旅 。

我之前已经做了个本地备份的计划，每天晚上会备份一次。我把希望都放在了它身上。等我把备份的数据库附件上去，发现时间居然都是两个星期之前的。

而且还有一些新表都没有，我联系对方，对方告知研发人员两个星期前做测试的时候把备份计划关了。。。

我心里万头草泥马奔腾而过。

最后没有办法，把老服务器又翻了出来，翻出之前的老数据，开始转换。

期间老板给我短信：“数据恢复进行的怎么样了呢。”

“报告，正在稳步进行中，按照目前的状况，可恢复的可能性超过 90%。” 别问我 90% 怎么算出来的，我就是哄他才这样说的。

“唉，真是心急呀，睡都睡不着。小吴呀，当初要是听你的，上了备份该多好呀。” 现在知道后悔了，哼哼。

“老大别担心，我会搞定的。” 是的，作为一位负责的员工，我就是这么让老大心安。

“恩，那就交给你了哦，熬夜少抽点烟哦。” 哎呀，瞬间觉得我老大萌萌哒有没有。

这里花了我一个晚上加一个白天。

数据转换好了，还有一些时间差的数据没法找到。于是通知各个部门，找单据，开始往里面补单子，一条一条的按照业务流程补进去。

为了协同更方便，在会议室加设了几十台电脑集体办公。。。

在大家一片怨声载道中，三天时间，终于把数据恢复了过来。三天内我没离开机房超过 10 米，吃喝拉撒都在机房，不对，拉撒不在。

这件事情造成的后果：

1. 大部分员工放假三天，我加班三天三夜。

2. 本来很爱我的大部分员工因为单据事件，集体转为黑我恨我了。

3. 公司立马批了我的计划，冷备，热备，异地容灾，全部上全了。

4.我挥刀自宫，自己罚了自己，扣除了自己一个月工资。

5.老板到现在还是在怀疑请的那家公司已经被我们竞争对手收买，是故意来破坏我们的。

6.萌妹子拉黑了我。

这真是个悲伤的故事。

看完了这个悲伤的故事，我们要回归理性， MySQL 数据库误删除后怎么办?

在日常运维工作中，对于数据库的备份是至关重要的!数据库对于网站的重要性使得我们对 MySQL 数据库的管理不容有失!

然而是人总难免会犯错误，说不定哪天大脑短路了，误操作把数据库给删除了，怎么办?

下面，就 MySQL 数据库误删除后的恢复方案进行说明。

工作场景

MySQL 数据库每晚 12:00 自动完全备份。

某天早上上班，9 点的时候，一同事犯晕 drop 了一个数据库!

需要 紧急恢复 可 利用备份的数据文件以及增量的 binlog 文件进行数据恢复 。

数据恢复思路

利用全备的 SQL 文件中记录的 CHANGE MASTER 语句 ，binlog 文件及其位置点信息，找出 binlog 文件中增量的那部分。

用 MySQLbinlog 命令将上述的 binlog 文件导出为 SQL 文件，并剔除其中的 drop 语句。

通过全备文件和增量 binlog 文件的导出 SQL 文件，就可以恢复到完整的数据。

实例说明

首先，要 确保 MySQL 开启了 binlog 日志功能。 在 /etc/myf 文件里的 [mysqld] 区块添加，如下图，然后重启 MySQL 服务。

1.在 ops 库下创建一张表 customers

2.现在进行全备份

参数说明：

-B：指定数据库

-F：刷新日志

-R：备份存储过程等

-x：锁表

Cmaster-data：在备份语句里添加 CHANGE MASTER 语句以及 binlog 文件及位置点信息

3.再次插入数据

4.此时误操作，删除了 test 数据库

此时，全备之后到误操作时刻之间，用户写入的数据在 binlog 中，需要恢复出来!

5.查看全备之后新增的 binlog 文件

这是全备时刻的 binlog 文件位置，即 mysql-bin.000002 的 106 行，因此 在该文件之前的 binlog 文件中的数据都已经包含在这个全备的 SQL 文件中了。

6.移动 binlog 文件，并导出为 SQL 文件

剔除其中的 drop 语句，查看 MySQL 的数据存放目录，由下面可知是在 /var/lib/mysql 下，将 binlog 文件导出 SQL 文件，并 vim 编辑它删除其中的 drop 语句。

注意：在 恢复全备数据之前必须将该 binlog 文件移出，否则恢复过程中，会继续写入语句到 binlog，最终导致增量恢复数据部分变得比较混乱。

7.恢复数据

查看数据库，看看 ops 库在不在。

此时恢复了全备时刻的数据。接着，使用 002bin.sql 文件恢复全备时刻到删除数据库之间，新增的数据。

再次查看数据库，发现全备份到删除数据库之间的那部分数据也 恢复 了!!

以上就是 MySQL 数据库增量数据恢复的实例过程!

最后，总结几点：

本案例适用于人为 SQL 语句造成的误操作或者没有主从复制等的热备情况宕机时的修复。

恢复条件为 MySQL 要开启 binlog 日志功能，并且要全备和增量的所有数据。

恢复时建议对外停止更新，即禁止更新数据库。

先恢复全量，然后把全备时刻点以后的增量日志，按顺序恢复成 SQL 文件，然后把文件中有问题的 SQL 语句删除(也可通过时间和位置点)，再恢复到数据库。

来源：51CTO

计 算 机 世 界

C HINA C OMPUTER W ORLD

关 于 IT 产 业 和 产 业 IT 的 一 切

这世界上有后悔药- houhuiyao.cc 后悔药数据恢复 站长语

前面介绍了误删部分数据恢复MySQL恢复delete的数据。部分数据恢复指的是非计划清理的那部分数据，存在恢复的需求的一点建议。通常情况下是碰不到这类问题的，做好准备也可以规避掉类似的问题。

有Delete误删数据，自然就联想到update误更新数据。本文探讨下MySQL update的数据恢复。

实际上update误更新数据的隐蔽性相对于delete更强，少数据了自然相对容易对比数目、数据的连续性等直观感受发现。而数据变更了，尤其是非字符型数据（字符型数据如标题、作者等。非字符型如类别ID，浏览量等）的变更，很难一眼就发现。比如有几十上百个分类属性，文章数几十万，在进行部分特征文章进行分类批量迁移时，误把不需要进行迁移的文章分类一并由编号33更改为了35，而此类文章可能本身就因为什么原因关注度就一般，迁移完都没有感觉哪里不妥。

此类情况很不易发现。虽然举的例子看起来关系很小，只是分类误更新了而已，后续还是可以发现了再调整。但如果这里调整的不是文章，而是有货币属性的，比如积分，代表用户可以透支的信用等级，甚至是利息，存款周期，货物价格等等。

来看一个鲜活的例子：

类似手滑的真实例子远不止这一两例。电商类的平台，想必价格管控复查等规范和流程都是健全的，依然避免不了意外（谁也不知道明天和意外哪个先来）。

虽然啰嗦，依然想再提醒下：后悔药数据恢复再次提醒：

1，首先需要说明的是，生产环境下慎重执行删除操作，除非你确实明白自己在做什么，否则不执行危险动作。

2，有条件的情况下，依靠系统来管理数据和数据库，尽可能降低潜在的管理的风险。

3，数据库有Update、Delete、Insert、Truncate、Drop类操作，先在测试环境执行一次，看结果和预期是否相符。生产环境执行前，先对要操作的表做一个备份，以防万一。

4，备份，备份，备份。

如果真的按照上面的提醒来操作，也几乎不可能会出现误删的情况除非是SQL自身存在逻辑不严谨问题 :)

如果确实发现误更新了，怎么办？1，和delete相比，update有一个问题，就是要确认哪个数据才是最终更新前的可靠数据。Delete删除时，所删除掉的数据就是本条记录最终版本的数据，找回这条数据即可完整的恢复好本条记录。而update的变更版本多，所以确切的找回那条数据并能确认就是更新前的版本是一大关键，否则找回来的旧版本数据和当前误更新了的数据本质上是没有什么区别的：都不准。

2，如果开启了binlog且日志完整，则相对容易找回数据。将binlog解析出来后，把最终导致误更新数据的那条SQL注释或者删除掉然后恢复数据即可，可以可以参考MySQL恢复误删的数据 。

3，从备份中把数据恢复出来，进行比对。这里需要注意的依然是数据的有效性问题，备份的数据是历史版本旧数据，无法确认更新前的最终版本。可以用于参考，运气好的话，误更新的字段内容也许备份前就是最终版本，可以直接使用。

4，有书面的单据或者其他纸质的内容、邮件等，可以用于确认数据的，都可以用于找回数据。

如何最大限度避免误更新？1，不要使用数据库，则没有烦恼！

2，参考上面的提醒。

3，严谨的操作和执行到位的流程，可以很好的避免这类问题。

4，找我们后悔药数据恢复houhuiyao.cc来提供服务吧，我们又稳又好用，这些操作都熟。

这世界上有后悔药– houhuiyao.cc 后悔药数据恢复 站长语

最近接触了多例MySQL数据库误清空数据，找我们来咨询数据恢复。有些已成功进行了数据恢复，有些因为客观原因很可惜数据丢失了。不管什么原因和什么结果，发生的案例都有借鉴价值，截图如下供参考。

这个案例是使用的阿里云，使用工具误清空了数据，没有备份。这个例子很有代表性，目前众多中小型网站、系统选择阿里云部署代码和数据，因为信任阿里云，却忘记了数据库是需要自己管理的，导致各种意外状况的发生。

这个案例更有代表性：新手上路！记得之前看过一个话题，说的是刚入职就删除了数据库是一种什么体验？ 想必不是愉快的体验。这个案例的数据库最终恢复了，还算挺好的结局！ 慎重，也许下次运气就没这么好了。

这个案例也很有代表性，都是“懂”技术的把数据库玩坏了。

还有其他各类案例，不一一列举了。

最后一点，也是最重要的一点：MySQL数据库有问题先别急着跑路，先联系后悔药数据恢复houhuiyao.cc，也许事情并没有那么糟糕！

随着科技越来越发达，现在手机的花样也越来越多了，什么全面屏、面部解锁、3D表情，真是让人目不暇接。由此也让手机成为了我们生活中必不可少的物品，这样的结果有好也有坏吧，我是比较倾向于好的一面。但是，随着使用手机的频次越来越多，也就意味着手机内产生的数据量越来越大，数据也越发变得重要！如何保护好自己的手机数据是一个问题，目前最好的方法就是开启自动备份数据或者定期手动备份数据了。但有些马大哈的朋友嫌麻烦就不做备份，导致哪一天不小心误删了手机文件或者手机发生意外数据丢失，这时候才来追悔莫及。

事实上，不小心丢失手机文件，及时采取措施的话还是可以将其恢复回来的，这是为什么呢？

一、为什么丢失的手机文件可以找回来？

这涉及到一个数据恢复的原理了，我们手机内的所有数据都存在数据库中，如果删除了手机数据，这块数据映射的数据库区域就会被标记为“未占用”状态，但此时数据还是存在于数据库中的，直到这块数据块区域被新数据占用了，原本的数据才会完全消失。所以，只要赶在删除数据被占用前就有机会对其进行恢复。

举个简单例子，存储在你手机数据库中的数据是这样子的：

数据丢失/删除后在数据库中是这样子的：

那我们要怎样赶在删除数据被新数据占用前将其恢复呢？

二、如何恢复手机已删除的文件？

切记先做好一件事情：不要再往手机存储新数据了，以免新数据把删除数据给占用了，到那时候神仙都救不回你的数据了。然后我们分别讲解安卓、iOS平台的数据恢复过程。

1、安卓手机恢复方法

安卓手机恢复数据最好先将手机给root了，用“强力一键Root”这个APP就可以给手机Root了，物如其名，一键就能Root，傻瓜化操作，非常简单，效果还不错。

然后再从应用商店下载个“手机数据恢复精灵”APP。

运行“手机数据恢复精灵”，进入界面可以看到他提供给我们的数据恢复功能。

根据需求选择数据恢复功能即可，对了，忘记告诉你一件事，如果是“图片恢复”的话就不用将手机Root哦，也就是说如果只用来恢复手机照片，前面Root手机的操作就不用做了。

进入“图片恢复”后，坐等结果出来，然后点击图片进行恢复即可。

其他的数据类型恢复同理。

2、苹果手机恢复方法

苹果手机的话，在App Store里找到“强力恢复精灵”这个APP并下载。

下载后运行，跟手机数据恢复精灵一样，他也提供了非常多的数据恢复类型选项给我们，根据需求选择即可。

接下来的步骤就跟手机数据恢复精灵差不多了，我就不再多讲。

以上就是手机文件的恢复技巧了，对你有帮助的请点个赞吧。

软件：用友，速达，管家婆，远光，奇安、金蝶、美萍、百威、广联达……等各种财务软件、医药软件、医院软件、汽配软件、服装软件、宾馆软件、书店软件、超市软件、OA办公自动化……等各种行业软件。

数据库：SQL，Oracle，Sybase，Access、dBase，FoxBase……等各种版本的新老数据库。

故障：数据库质疑，删除库内表，格式化，重做系统，重分区，系统还原，软件报错，数据错乱，备份覆盖，硬盘损坏……

收费：根据故障轻重和数据库文件的容量收费，500元起，数据库文件容量越大，工作量越大，耗时越长，收费越高。

涉密：如果客户数据涉密和隐私，可以签订《数据保密协议》，保证数据不会有任何形式的泄露。

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL数据库使用的比较多。

公检法部门在处理涉黄、诈骗的案件时，常常会遇到对涉案网站、论坛的服务器进行取证，有时嫌疑人为了毁灭罪证，故意删除数据，这就涉及到对MySQL数据库进行数据恢复、固定和取证。效率源科技的技术大咖针对一线办案人员遇到的痛点，写了这篇MySQL数据库删除数据的恢复指南，希望对办案人员有所启发。

binlog日志简介:

binlog 就是binary log，二进制日志文件，这个文件记录了MySQL所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间。

binlog日志包括两类文件：

1)二进制日志索引文件(文件名后缀为.index)：用于记录所有的二进制文件;2)二进制日志文件(文件名后缀为.00000*)：记录数据库所有的DDL和DML(除了数据查询语句select)语句事件。

binlog日志对于mysql数据库来说是十分重要的。在数据丢失的紧急情况下，可以尝试用binlog日志功能进行数据恢复操作。正是由于binlog日志以上的特性，在实际的案件取证中也可以通过binlog日志来恢复删除数据。要通过binlog日志恢复mysql数据库删除数据的前提：binlog日志确定是开启的。

查看binlog日志是否开启,有以下三种方法

方法一：打开MySQL数据库的配置文件(windows系统中的配置文件为my.ini，一般在安装目录的根目录下;Linux系统中配置文件为myf，一般在/usr/local/mysql/etc/目录下)，在配置文件中查看log-bin=MySQL-bin有没有被注释掉(每行第一个字符为#号表示该行被注释)，若没被注释表示开启，若被注释表示没有开启。

方法二：在MySQL命令行下使用show variables like ‘log_bin’;命令查看binlog日志是否开启，Value的值为ON表示开启，为OFF表示关闭。

方法三：在存放数据库的文件夹中是否存在mysql-bin.000001类似的文件，有则表示binlog日志功能是开启的。

在数据恢复过程中会用到的binlog日志操作命令

1、查看所有binlog日志列表：

在mysql命令界面输入命令： mysql> show master logs

2、查看master状态，即最后(最新)一个binlog日志的编号名称及其最后一个操作事件pos结束点(Position)值：

在mysql命令界面输入命令： mysql> show master status

3、刷新log日志，自此刻开始产生一个新编号的binlog日志文件：

在mysql命令界面输入命令：mysql> flush logs

注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志;在mysqldump备份数据时加 -F 选项也会刷新binlog日志

4、重置(清空)所有binlog日志：

在mysql命令界面输入命令：mysql> reset master

如何读取binlog日志中的内容?

1、使用mysqlbinlog自带查看命令法：

注: binlog是二进制文件，普通文件查看器cat more vi等都无法打开，必须使用自带的 mysqlbinlog 命令查看binlog日志与数据库文件在同目录中。

Mysql安装路径下的bin文件夹下输入以下命令：

C:\\xampp\mysql\bin>mysqlbinlog C:\\xampp\mysql\data\mysql-bin.000009

2、上面这种办法读取出binlog日志的全文内容较多，不容易分辨查看pos点信息，这里介绍一种更为方便的查询命令在MySQL的命令界面：

在mysql命令界面输入：mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

选项解析↓

IN 'log_name'：指定要查询的binlog文件名(不指定就是第一个binlog文件)FROM pos：指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)LIMIT [offset,]：偏移量(不指定就是0)row_count：查询总条数(不指定就是所有行)

删除数据案例及操作步骤:

下面我们通过一个实例操作来完整查看「如何通过binlog日志恢复MySQL数据库删除数据。

案例介绍:

现有MySQL数据库，其中有名为test的数据库，其中没有任何的表，怀疑数据被删除，在该电脑中还发现了该数据库的备份，备份最后被修改的时间为2018-11-21 15:27:12。

目的:

查看是否有删除的操作，如有删除尝试恢复出删除的表的内容。

思路分析:

1、判断数据库是否开启了binlog日志的功能;

2、通过binlog日志查询是否有删除的操作;

3、若删除了数据，通过binlog日志恢复数据库中的内容。

下图就是通过binlog日志实现增量恢复数据库删除数据的流程：

01.判断数据库是否开启了binlog日志：

在MySQL命令行下使用show variables like‘log_bin’;命令中log_bin的Value为ON，该数据库的binlog日志是开启的。

02.判断数据库是否有被删除的操作：

1)在mysql命令界面通过show master logs;命令查看binlog日志列表，发现一共有8条日志。

2)在mysql命令界面通过命令show binlog events in 'mysql-bin.000008';可以查看最后两条命令为“use ‘test‘;delete from t1，use `test`;DROP TABLE `t1`”由此可判断出数据库test中t1表中的内容被清空了，并且把表也删除了。

03.恢复数据库中删除的数据：

1)由于表t1被删除了，没有该表的数据结构无法直接通过binlog日志来恢复删除的数据;但是我们在电脑中发现了该数据库的备份，直接还原后就可以得到表t1的数据结构。(这里不做还原的详细解说，如果您想了解还原详细操作步骤，可在后台留言)。

恢复出的数据结构

2)备份最后修改时间为2018-11-21 15:27:12，MySQL-bin.000008的创建时间为2018-11-20 14:15:40，可以推断出备份后表t1的所有操作都在该日志中。

3)在mysql命令界面使用命令show binlog events in 'mysql-bin.000008';打开最后一个日志文件，找出开始和结尾的pos点，分别为：4和1223，如下图：

4)提取日志文件该段落：在mysql安装界面的bin目录下输入一下命令：mysqlbinlog C:\\xampp\data\mysql-bin.000008 --start-position=4 --stop-position=1223 -r 1.sql，该命令把日志文件中的所有语句提取到了bin目录下的1.sql中。

5)通过分析该sql文件可以发现其中记录了每一条命令的执行的时间，找到备份创建时间2018-11-21 15:27:12之后的所有命令另存为2.sql。如下图：

6)另存为2.sql后，把最后两条删除的命令去除，直接在数据库中运行，就可以恢复出表中的所有数据。

注意事项:

1、在恢复之前一定要确认MySQL数据库的binlog日志是开启的;2、若把表删除一定要想办法把表的数据结构找到，这样才能准确的恢复出数据;3、binlog日志中是记录了每条语句的执行时间的，可以通过时间来恢复;4、在截取插入语句的时候一定要注意不要把最后一条删除的语句截取到，不然恢复的数据又会被删除。

以上就是效率源科技的技术大咖针对使用binlog日志恢复MySQL数据库删除数据的方法，希望上述的问题解决思路能给公检法一线办案人员一些参考和帮助。如对文中的操作、描述有任何疑问，或者有相关数据库恢复案件协助支持也可以直接联系效率源科技，获得技术协助。

1.硬件设备清单：

2.故障描述：

需要进行数据恢复的服务器是一台r520型号存储，共有7块SAS硬盘分别组成raid1和raid5两组磁盘阵列。主要sql server数据库存放在C盘中，在使用过程中，客户发现C盘容量即将占满，于是将数据库路径指向了D盘，在D盘生成了一个.ndf文件。客户在继续使用了大约10天之后，数据库出现故障，连接失效，无法正常附加查询。

3.备份数据：

考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一其他原因导致数据无法再次恢复。使用dd命令或winhex工具将所有磁盘都镜像成文件。

4.故障分析：

(a)分析故障原因；由于数据库文件所在磁盘容量不足，导致数据库无法继续正常运行，出现逻辑错误。

(b)分析RAID组结构；客户服务器上共7块300G硬盘，其中2块硬盘做RAID 1，用于安装操作系统，其余5块硬盘做RAID 5存放数据。分析RAID 1和RAID 5的相关结构，重组虚拟出RAID 1和RAID 5，查看其中数据。

(c)分析原始数据库文件；由于客户在数据库发生故障之后，进行过多次数据库恢复尝试，并且每一次尝试都是在源环境下进行的，导致原始数据库文件被更改覆盖，并且磁盘空间被多次复写，无法使用尝试恢复之后的数据库文件进行修复。询问客户得知，客户在数据库发生故障的时候，备份过一分原始的故障数据库文件。

5.数据库修复：

从虚拟出的RAID 5空间中将客户之前备份的数据库文件拷贝出来，尝试在数据库中附加，附加失败，错误提示如下图一：

错误提示主数据库文件和次级数据库文件不匹配，查看.ndf文件底层，发现.ndf文件中几乎没有数据，尝试取消.mdf文件和.ndf文件之间关联，只用.mdf文件进行附加。尝试后发现，只用.mdf文件附加时也发生错误，但是错误提示改变。图二：

此时错误提示日志文件（.ldf）和数据库文件（.mdf）不匹配。之后对数据库尝试进行无数据库附加，附加成功。但是发现数据库系统表损坏，无法正常使用。图三

对数据库的系统表尝试修复，但由于系统表损坏过于严重，无法修复。数据库记录提取；解析数据库文件中的数据库记录；编写相应的程序提取数据库文件中的数据库记录；根据客户以前的数据库备份获取数据库中的表结构；重构表结构并肩提取出的数据库记录导入到新的表中。

6.数据验证：

由客户对提取出的数据库记录进行验证,所有数据完全恢复，本次数据恢复成功。

7.数据恢复结论：

在数据库使用过程中，要合理分配数据库文件所在磁盘空间，及时清理垃圾数据，保证数据库的正常、安全运行。

这世界上有后悔药-houhuiyao.cc 后悔药数据恢复 站长语

前面介绍了MySQL数据库在使用InnoDB引擎时，如果误删了数据表，在共享表空间MySQL数据表InnoDB引擎表误删恢复(共享表空间ibdata1)和独立表空间MySQL数据表InnoDB引擎表误删恢复(独立表空间innodb_file_per_table=1)的情况下如何恢复数据、如果不幸误删了数据库MySQL数据库误删恢复。

如果没有完整的把数据库或者表删除掉，而仅仅是删除了表里的部分数据，比如本文探讨的：delete命令数据误删恢复，这种情况应该发生的概率更大，毕竟有机会删除库和表的权限和命令通常控制的都很严（删库跑路是段子）。

有人会有疑惑，用delete命令去删除数据，不都是正常想删除掉的么，为何存在要恢复的情况。说的很对，确实想要删除的自然不必再恢复，怕就怕手滑，没打算删除的也一并干掉了。这里我们探讨的就是这类被误删的数据该如何恢复。

后悔药数据恢复再次提醒：

1，首先需要说明的是，生产环境下慎重执行删除操作，除非你确实明白自己在做什么，否则不执行危险动作。2，有条件的情况下，依靠系统来管理数据和数据库，尽可能降低潜在的管理的风险。3，数据库有Update、Delete、Insert、Truncate、Drop类操作，先在测试环境执行一次，看结果和预期是否相符。生产环境执行前，先对要操作的表做一个备份，以防万一。4，备份，备份，备份。

如果真的按照上面的提醒来操作，也几乎不可能会出现误删的情况除非是SQL自身存在逻辑不严谨问题 :)

如果确实误删了，该怎么办？1，InnoDB表中delete命令并不擦除真实的数据，只是做了一个删除标记，实际的数据内容依然存在。如果发现及时并且运气也不错，暂停下业务防止数据被物理覆盖，立即将数据文件拷贝出来，然后解析数据文件，使用percona的undrop-innodb工具进行最后的尝试。

2，如果开启了binlog，情况要好很多，将历史的binlog文件集中起来，解析出来全部的和所操作的表有关的SQL，剔除这条误删数据的delete命令，然后恢复数据。可以参考MySQL恢复误删的数据。

3，如果有备份，那么可以通过解析备份文件，将表数据提取出来进行恢复（备份文件过大如何提取部分数据，后续将探讨这个情况）。需要注意的是，备份结束后到误操作前这段时间内所产生的数据将无法找回，用历史数据回滚的数据不完整性需要自行评估，有其他条件可以补全数据的最好。

4，有些系统开启了日志功能，并且日志历史也均保留了下来，也可以尝试查找查找。

如何避免这种灾难式的事情发生？这个可能是更多人关注也更有意义的事。1，不使用数据库，这样就没有烦恼了。

2，参考前面的提醒，对生产环境存敬畏之心，谨慎操作、流程化操作，则问题出错的概率将可以降低到最小、影响面减少到最小。

3，也可以将数据库维护的苦活、累活、脏活交给我们来操作，毕竟我们又稳又好用，所有操作都熟。

误删了数据，想立即跑路？也许不用，联系下后悔药数据恢复houhuiyao.cc吧，我们将尽一切可能帮您找回数据。

故障描述：

5块2T硬盘组建RAID5，划分LUN供windows服务器使用。在windows服务器内装有Sql Server2008数据库。存储空间内共有三个逻辑分区，大小分别为500G、800G、2.3T。数据库文件丢失，主要涉及五个数据库，表个数约为6000个左右。丢失原因未知，且不能确定数据存储位置。三个数据库的大小分别为8G、15G、20G。在文件丢失后服务器仍处于开机状态，但并未写入大量数据。

初检流程：

1、使用RAID信息及内部数据块信息重组RAID。

2、提取LUN内三个分区镜像。

3、扫描文件系统内丢失文件，未找到被删除数据库文件。

4、初检结果为数据库文件丢失，通过文件系统角度无法恢复。

恢复流程：

1、制定恢复方案。在数据库文件被删除且判定为无法恢复文件后，只能通过扫描数据页，并提取页内记录的方式进行恢复。

2、使用北亚自主编数据页扫描程序扫描分区内数据页并提取。在分别扫描两个分区镜像后发现500G系统盘内数据页数量极少且数据页断裂情况严重，另一分区内扫描到数据页个数较多。暂定此分区为数据库文件存储空间。

3、重组系统表。Sql Server数据库使用系统表来管理所有用户表，在这些系统表内记录了各表的列数、数据类型及约束信息等。解析系统表过程中发现提取出的数据页内系统表损坏，无法正常读取信息。在与客户沟通后得知有备份文件，且备份完成后没有大量改动表结构，系统表可用。

4、还原备份。

5、分别提取三个库中各表表结构信息

6、解析表结构脚本。将各表的列信息存入数据库内便于后续使用。

7、解析系统表获取用户表id信息、关联表结构与数据页。（为保护客户隐私，后续步骤涉及用户表表名及数据页内数据部分均未截图）

8、新建数据库，使用北亚自主编写软件解析记录并导入到恢复环境内。

9、整理恢复结果。在此分区内除数据库文件外还存有备份文件若干，所以在导出记录后可能存在重复数据，必须去重。编写SQL存储过程进行去重。

10、客户验证数据。客户在查验过数据后表示数据可以接受，移交数据到客户存储设备，恢复成功。