你是否也有这样的经历，不小心删除的通话记录恰好有非常重要的信息？（就是这么巧，不然故事怎么继续呢？）效率源妹儿也经常收到对删除通话记录恢复的需求，今天就给大家分享几种删除通话记录恢复方法，希望可以帮助找回重要的通话记录。

1、登录运营商网上营业厅或者手机营业厅APP查询；登录网上营业厅，点击“详单查询”，或是营业厅手机APP上的“详单查询”，如下图。通过网上营业厅或是营业厅手机APP可查询最近6个月的通话记录。

2、去运营商营业厅打印通话记录清单；

带上机主身份证或是服务密码，直接在营业厅的自助机上打印最近6个月通话记录即可。3、使用效率源SPF9139智能手机数据恢复取证系统（以下简称SPF9139）恢复删除通话记录；

打开程序进入SPF9139主界面并登录，将需要恢复通话记录的手机接入到SPF9139，根据系统提示进入数据提取界面，选择通话记录数据提取，则可以提取该手机的通话记录数据，包括被删除的通话记录。

SPF9139是效率源为面向专业司法取证领域而设计的一体化手机数据取证产品，集手机数据镜像、数据提取、删除恢复、智能检视、数据筛选及报告导出功能于一身的全能型取证产品。在数据删除方面，SPF9139采用SQLite数据库恢复技术，对手机中已删除信息，进行数据级恢复，进一步保证数据提取内容的完整性。不仅支持对通话记录的恢复还能支持对短信、联系人、QQ微信等第三方应用、图片、视频、语音等数据文件进行恢复。以上就是恢复被删除的通话记录的方法，希望可以帮助大家找回被删除的通话记录。

昨天，我和在Famigo公司的同事Cody 和 Shaun 一起去参加 MongoDallas研讨会。我们在几个月前听说了这个会议，感到去这个会议将会是次有趣的活动。我们公司几乎所有的东西都是存储在MongoDB里的，Cody会在这个会议上做一次演讲介绍我们的使用情况。

会议办的非常好，进行的过程中没有出什么意外情况。(跟上次活动一样，10gen公司给会议提供了大量的饮料。)午餐期间，我们跟 GameStop公司的几个家伙侃大山。其中有个人问我们在正式环境服务器上做过的最糟的一件事情是什么。我想不出什么，但Cody给大家讲了一个他在以 前的岗位上的一个故事。是他把完全重写的代码放到服务器上后，整个环境立即崩溃了。

可结果却是，我在下午实现了我对生产环境犯下的最大的错误。

午餐之前，在两个演讲之间，我检查了一下我们的服务器，看看是否一切正常。我发现了一个异常，跟保持唯一数据值有关。我们的API中的一个竞争关系的条件语句导致了数据库中的两个账户保存了相同的email地址，但每个账户的email地址必须是唯一的。

我迅速的定位了问题，在我们的缺陷跟踪系统了添加了一条记录，描述了问题的原因，以及产生冲突的账户。我删除了这个账户，因为它没有跟任何数据关联，我们的客户在下次登录时，系统会自动初始化一条记录。

然后，我继续查找，看看数据库中是否还有其它产生冲突的账户。我循环数据库里的每个账户，依次保持它们(没有做任何改变)；有问题的数据会在保持时抛出异常信息。我在Python的交互shell里编码，所以当时的代码并没有保留下来，但它们大概是这样的：

from mongoengine import connectfrom models import Familyconnect('the-production-database')for family in Family.objects:family.save()

代码执行完并没有出现异常，于是我关掉了笔记本，把注意力重新放到会议上。几个小时后，Cody收到了大量的报告服务器响应变慢的邮件。他迅速的打开了笔记本，我在旁边看着他的屏幕。当我看到这一幕时，几乎诱发了我的心脏病：

>>> Family.objects.count() 38

这数量少了好几个数量级！我们极度不安，从会议厅里溜了出去。

事情很快就明白了，我们的账户信息，而且只是账户信息，被弄丢了。我查看新近出现的账户信息，把它们加入的时间和我最后一次提交操作的时间对比。它们不可思议的接近。

不幸的是，我的屏幕会话没有足够的回滚信息来让我看看今天早些时间究竟做了什么。因为我是在交互式shell里执行的，我找不到任何历史记录。最大可能的猜测，我应该是干了类似这样的事情：

for family in Family.objects: family.delete()

我晕倒！执行save 和 delete操作都不会返回任何信息，所以在看着账户信息在屏幕上滚动时没有发现任何的异常。(我并不确认究竟是怎么回事，但这是最简单的解释。奥坎氏简化论在这里打倒了我的自负。)

会场的网速很差劲，而且找不到电源插座，于是我们收拾起东西，匆忙的想找一家附近咖啡馆。结果发现，达拉斯市中心所有的咖啡馆下午4点钟全关门了。幸运的是，它们提供24小时的免费wifi，于是我们就在一家星巴克外面安营扎寨，开始了工作。

（达拉斯这个地方要比我们预想的冷的多。当我们离开奥斯汀时，那里是华氏80度，阳光明媚。而在达拉斯，这里一直40度，阴天，有风。我们三个穿着T恤、牛仔裤的人挤在笔记本前，希望能在冻僵前尽快解决问题。）

这周早期，我们有个数据库备份，我们把它导入到了我们的开发环境中，Cody把它恢复到了一个独立的数据库里。我写了一个脚本，把丢失的账户信息一一从一个数据库导入另一个数据库。很幸运，进行的很顺利，所有的信息都恢复了。

剩下还有一些要做的事情，要检查所有对这些数据的引用都指向了正确的地方，但最重要的大火是已经被扑灭了。11月17号，它一直保留下来，成为了我们的备份宣传日。

编者按：开发人员总以为自己误删了数据是天大的事情。的确如此，但是“罪不至死”。本文作者Zachary Kuhn在“Those two times where I clearly had no clue what I was doing as a developer”一文中分享了自己的亲身遭遇，并认为犯了错误不重要，重要的是要有所得。

上周我与同事们进行了一次关于职业生涯中搞砸了一些事情的简短谈话。这确实会沦为他人笑柄，却更给我们带来了珍贵的教训。重要的是，我们应该分享那些曾经的错误，这样其他人就可以从其中学习。下文是最近在我身上发生的例子。

为什么有如此多误删生产数据库的事情发生？

几个月前，Reddit上有一篇文章，讲了一名初级开发人员在上班的第一天就删除了生产数据库的事。我们都很憷于读到这类犯了这类无法让人忘却的大错误的文章。因为我们离这些也不远，而大多数人都是“死里逃生”。

在我的第一份工作中，一位高级数据库管理员在上班第一天就误删了生产数据库。这类故事情节比比皆是。这个团队从一个星期的备份中恢复了他导致的错误，并让他继续工作。十年后，他们依然将其作为笑点。

今年早些时候，我被派去检查一个客户的生产数据上的问题。他们进行了小范围的非公开测试，结果网站上没有显示任何内容。我想查查是否是存在漏洞或是易损性问题导致了这一结果。

我通过了生产机器上的签名环节，然后打开了数据库。内容库（articles table）内空空如也。这证实了我们在网站上看到的情况是真实的。

用户库（users table）内依然有用户数据存在。真让人奇怪。所以情况是我们丢失了所有内容，但是至少测试用户的信息依然存在。我们给出的解释是这是一个测试行为，所以这些事情有可能发生。

接下来的几分钟一片混乱。我不记得自己做了什么。我不认为自己笨到在控制台上执行了删除用户库的操作。但是事实就是这么发生了，现在后台既没有了内容库，也没有了用户库。这真实下了我一大跳。

然后我的大脑就开始转动起来思考如何解决这个问题。我真的把用户库给删掉了吗？是的。我们存备份了吗？没有。我们应该如何告诉客户这个事情？不知道。

我犹记得自己走向项目经理那里，坐在她身边，向她解释了发生了什么事情时的场面。因为我们的内容库中没有内容，这就是为什么网站上空空如也的原因。同时，我还删除了用户库。他们现在需要重新邀请所有的用户，如果他们能够弄清楚谁是谁。

我回到了自己的办公室，垂头丧气。

不过，我还是没有接受这件事。我们一开始是如何失去这些东西的？

我开始不停地往深处想。半是为了否认这件事，半是想要挽回面子。不久，我注意到了一些重要事情。

在服务器上还存在着其他5个数据库。其中一个数据库的名字和我刚才看到的数据库名字很像。

当我查看这个数据库的时候，发现所有的内容都在里面。用户库也安然无恙。结果证明，是一个配置变动无意中改变了生产设置，使站点指向了一个全新的数据库。我之前所看的用户信息是什么？种子数据。

真是谢天谢地。早上的神经紧张和胃酸让我觉得很不舒服，但是我们“恢复”了数据，并在坏消息传开之前找到了真正的问题。

从这件事中可以吸取很多教训。其中一点是关于最简单原则：我们总是在做的备份，也许是开发人员最有成效的挽救药。

继续前进但不要冲得过前

我最近犯的一个错误不太引人注目。事实上，这是一个经由小错误所引起的小错误最终导致了一场混乱的故事。

我们面临的是一个时间紧迫的项目。

在初次会议上，我们团队一致认为完成它会花费比预定时间多一倍的时间。这个最后期限一开始就对我们产生影响，让我宽松地通过了身份认证部分而留有更多时间去关注客户所实际关注的功能设计。

我只是在一个单一页面测试了身份验证测试，但是当时还不了解它们将如何被组合在一起。

把它单列出来是我做的一个错误决定。我忽略了一些重要事情：

用户在登陆之后会从cookie中加载内容，但是这个页面却试图在没有任何等待的情况下进行加载。根据事件的发生顺序，用户会得到带来服务器的反映，说其是未经授权的。身份验证也未检查令牌是否过期。如果用户不经常访问这个网站。那么当其再一次访问时，网站需要用户登出再登入才会运行。令牌应该基于每个请求进行更新，但是我从未花费时间去理解其发生前后的规则。所以，这又产生了一个时间问题。如果我们同时发送了几个请求，根据它们返回的顺序，用户会得到那个在后来的请求中无法使用的令牌。

我们匆匆忙忙地赶着项目，却仍花费了比规定多一倍的时间。区别之处在于有更多的漏洞，并需要花更多时间去跟踪并修复这些漏洞。

这使我感到窘迫。之后因为整件事情变得比较糟糕哦而让我在公众场合感到羞愧。

我想说的是：在此之后，我花费了时间去学习认证程序。我现在了解了OAuth、JWT、刷新令牌和到期行为。我仔细研究了其他人所编写的身份验证代码。我能够在不同的语言和框架中建构身份验证程序。

将失败转化为未来的成功

这是我从那些表现糟糕的事情中所获得的经验。如果你愿意，那么几乎所有好的结果都会由此而来。

如果有人能从自己的错误中汲取教训，那么他就会比现在更优秀。我试着不去打击那些第一次犯错误的队友。他们通常都知道自己把事情搞的一团糟。

我也正尝试不对那些不断犯同样错误的人施加压力。他们仍然值得同情。

如果在错误中做到这4点，那么你就会不断成长：

嘲笑自己。从中汲取经验教训。改正错误。分享自己的错误，让其他人也有所收获。

最后，我想讲一个关于错误价值的轶事。20世纪初，IBM的首席执行官托马斯·J·沃森曾遇到过一名员工，这名员工的一系列糟糕决策让公司付出了巨大代价。当沃森被问到是否会解雇这名员工时，他回应道：

“不，我刚在他身上花了60万美元的培训费。为什么要让别人白白捡去这个便宜？”

原文链接：

编译组出品。编辑：郝鹏程

如何找回已删除的微信聊天记录？简单教程如今微信等社交工具应用更加广泛，在工作、生活、学习上都用到了微信，微信已经逐渐成为我们日常沟通中的一个主流工具，微信聊天记录一多，我们可能会需要清除一些，但是，若是不小心错手删除了重要的微信聊天记录的话，应该怎样找回微信聊天记录呢?

在恢复之前，我们谈一谈手机微信的储存及恢复的原理。手机中的微信是SQLite数据库进行信息存储的，当用户误删除微信聊天记录时，我们是不需要担心的。因为SQLite数据库对于删除的记录并没有真正的删除，只是把它们打上了删除标记的逻辑删除标签。也就是说，微信来哦天记录删除了，我们是可以借助一些工具实现微信删除记录的快速恢复的。

请将手机用数据线和电脑连接起来，确保手机数据线接口可以被windows平台正常识别，安卓手机需要root处理，苹果手机请在电脑中下载最新的iTunes软件，然后利用iTunes软件备份苹果手机数据。这样恢复起来恢复很容易。

首先我们把手机和电脑进行链接（最好是已经升级过iTunes的）如果没有升级的话那么恢复出来都是很久之前删除的文件。

然后打开我们下载安装好的迅捷微信聊天记录恢复软件（下载地址：https://crsky/soft/93730.html），如果手机连接好了会提示我们的已经连接。

请打开迅捷微信聊天记录软件，利用软件的从iTunes备份文件恢复功能扫描苹果手机备份数据，软件扫描后，我们便可以看见删除的微信聊天记录，包含图片、语音、文字。

根据上面扫描到的结果我们可以看到类别都分的很清楚了。大家根据自己的需要选择要恢复的文件即可，这里我们选择微信选项。并在需要恢复的前面打勾即可（其他的选项根据自己的需求选择即可）

选择好恢复对象以后点击右侧上面的导出按钮，即可恢复并到处当前选中人员的聊天记录了。

至此我们已经解决了微信聊天记录删除了怎么恢复的难题。主要强调下后期对于比较重要的微信聊天记录还是建议大家主动进行备份，这样也方便以后即使被删除了也可以很容易的就恢复回来。

故障描述：

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、客户验证数据。客户在查验过数据后表示数据可以接受，移交数据到客户存储设备，恢复成功。

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数据库删除数据的方法，希望上述的问题解决思路能给公检法一线办案人员一些参考和帮助。如对文中的操作、描述有任何疑问，或者有相关数据库恢复案件协助支持也可以直接联系效率源科技，获得技术协助。

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

那年公司 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 的 一 切

U盘作为移动存储工具，很是受广大人民喜爱。不仅仅因为它的功能便携带，它的外观设计的爷们美观，有很多人都会选择挂在某个地方当作饰品，既实用又美观。如果U盘中的数据被格式化了那该怎样才能找回数据呢？

U盘删除的文件还储存在U盘的数据库中，只是我们看不见，想要恢复使用数据恢复软件就可以了，本篇将给大家讲解U盘删除文件的恢复方法：

　　步骤1，通过数据线连接U盘和电脑，打开顶尖数据恢复软件（http://cjxz/softs/679.html），主界面上有六大恢复功能，鼠标放在任意功能上可以看见该功能的可恢复内容，这里点击“U盘手机相机卡恢复”。

　　步骤2，点击选中U盘，然后一键按下“下一步”按钮进入文件扫描阶段，请耐心等待文件扫描结束。

　　步骤3，文件扫描结果出来后，左侧选择要恢复的文件格式文件夹，然后查看文件夹的中文件是否是要恢复的那一个，点击勾选要恢复的文件，接着点击“下一步”按钮（如果扫描结果中没有找到要恢复的文件，请用户选择“万能恢复”重新扫描）。

　　步骤4，选一个目录储存恢复出来的文件，点击“浏览”，在弹出的对话框中设置即可，最后点击“下一步”按钮恢复文件。

U盘里面的数据其实很脆弱，我们要小心保护，想要恢复U盘删除文件的小伙伴，使用以上的方法就可以完成恢复了，一般情况我们可以达到100%的成果，但是如果发现U盘文件无法恢复，那么说明你在U盘文件删除后，又在U盘中添加了新的数据，这样就会将之前的文件覆盖掉，导致无法恢复，所以，文件删除后，请勿对U盘进行读写操作。

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

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

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

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

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

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

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

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

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

1、安卓手机恢复方法

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

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

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

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

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

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

2、苹果手机恢复方法

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

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

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

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

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

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

本文将探讨下MySQL数据库误删恢复。

后悔药数据恢复提醒您：

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

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

3，数据库有Update、Delete、Insert、Truncate、Drop类操作，先在测试环境执行一次，看结果和预期是否相符。生产环境执行前，先对要操作的表做一个备份，以防万一。后续将针对每个危险动作如何在生产执行时即准备好危机应对动作做一个探讨。

4，备份，备份，备份。

数据库误删，不管是使用的rm -rf testdb还是drop database testdb，最终的效果都是一样的：数据目录下的testdb目录及目录下的文件都不可见了(和之前介绍的Linux下恢复删除的情况一致)，实际上文件内容依然还在那里如果没有数据覆盖上去的话。

#测试环境准备命令：mysql> create database testdb;Query OK, 1 row affected (0.08 sec)mysql> mysql> use testdb; Database changed mysql> mysql> create table aa(id int not null primary key, name varchar(20)); Query OK, 0 rows affected (0.34 sec)mysql> mysql> insert into aa values(1,'a'),(2,'b'),(3,'c'),(4,'d'); Query OK, 4 rows affected (0.17 sec) Records: 4 Duplicates: 0 Warnings: 0mysql> select * from aa; +----+------+ | id | name | +----+------+ | 1 | a | | 2 | b | | 3 | c | | 4 | d | +----+------+ 4 rows in set (0.00 sec)

testdb数据库表文件：

#删除数据库：#使用SQL命令 drop database testdb;#使用rm rm -rf testdb/

那么，这种情况下的数据库恢复动作就简单了，参考前面介绍Innodb引擎时的恢复方法即可：

1，完整的恢复testdb目录及目录下的文件即可找回删除掉的库名和表数据，然后针对具体的表引擎，将数据重新导入到数据库中即可。

2，如果找回的是非完整的，那么操作思路是一样的，能恢复多少恢复多少，剩余的如果实在找不回来，从最近一次的备份里提取，然后依靠其他手段比如单据来补全数据。

还是不知道怎么恢复MySQL数据库？找后悔药MySQL数据恢复houhuiyao.cc吧！