备份：

就是将一个当前数据库系统中的“活”着的数据库，转换为一个死的不可操作的“数据文件”的过程。

恢复：

就是将“死”的数据文件，还原为活的可操作的数据库。

备份操作

在没有登录数据库系统的时候（登录前），使用mysql安装文件夹中的bin目录中的mysqldump命令来实现备份：

备份语法：

mysqldump -h要连接的数据库服务器 -u用户名 -p 要备份的数据库名 >要备份到的目标文件完整路径

注意：该命令需要在管理员模式下运行。

恢复操作：

通常的恢复操作，用于两种场景：

1，数据库迁移：从一台电脑，迁移到另一台电脑。

2，数据库本地还原：原数据库可能某种原因，损毁了，需要恢复！

而这里的演示，只能使用本地从一个数据库备份后，还原到另一个数据库中！！！

还原语法：

mysql -h数据库服务器 -u用户名 -p 要恢复的数据库名 < 要恢复的数据库文件完整路径

虚拟主机。

主机控制面板点击数据库，然后点击 管理mysql数据库（UTF8版）

选择自己的数据库，然后点击导出按钮即可导出。

点击导入按钮，即可选择本地的sql文件导入恢复数据库。

注意：导入恢复数据时，请确认备份好当前数据，以免导入后覆盖重要数据，导入时会因为主键冲突无法导入，这时需要清空数据库才可以导入，同样，若要清空也请先做好备份。

背景

环境：MariaDB数据库，存储引擎InnoDB

数据库名：douniu

损坏方式：不明

备份情况：有一个表结构的备份，没有开启binlog

结果：可以启动、登录，无法对表执行select/desc/drop等操作

方案

1. 在一个新的server（我的是centos6）上创建一个mysql5.6 建议使用rpm安装（简单）具体安装自行百度，因为5.6版本较高，且默认使用每个表独享数据文件

2. 登录并创建douniu数据库

createdatabase douniu;

3. 创建备份的表结构

usedouniu

sourcexxxxx;

4. 导出要恢复的表的数据文件作为备份（新创建的）例如tb_game_result.ibd

5. 分离舍弃表空间文件

altertable tb_game_result discard tablespace;

6. 使用ue查看导出的新的tb_game_result.ibd查看第三行的第三列和第五列

或者使用下面的命令在linux操作系统查看

hexdump -C tb_game_result.ibd |head -n 3 |tail -n 1|awk'{print $6$7}'

7. 替换space id

使用ue打开老的tb_game_result.ibd，把刚刚看到的00 和10替换到老的文件里

8. 把修改后的tb_game_result.ibd文件上传至服务器

9. 修改文件的owner和权限，我这里是mysql

chownmysql.mysqltb_game_result.ibdchmod660tb_game_result.ibd

10. 导入表空间文件

altertable tb_game_result importtablespace;

11. Test

select * from tb_game_result;

转载请保留以下内容：

本文来源自天善智能社区老头子博客，

原文链接：https://ask.hellobi/blog/azzo/6219

经常有网站管理员因为各种原因和操作，导致网站数据误删，而且又没有做网站备份，结果不知所措，甚至给网站运营和盈利带来负面影响。所以本文我们将和大家一起分享学习下如何通过Mysql的二机制日志(binlog)来恢复数据。

系统环境：

操作系统：CentOS 6.5 X64 (虚拟机)；

WEB服务：PHP+Mysql+apache；

网站：为方便，直接在本地用蝉知系统搭建一个DEMO站点；

操作步骤：

1.开启binlog功能及基本操作；

2.往站点添加数据；

3.刷新binlog日志；

4.删除数据；

5.binlog日志内容解析；

6.恢复指定数据；

1.开启binlog功能及基本操作

要使用Mysql的binlog日志功能，首先要在Mysql的配置文件中开启该功能，操作很简单。找到Mysql的配置文件，在文件中添加一行”log_bin = mysql-bin”即可。其实在我安装的各种Mysql环境中，该功能通常都是默认开启的。

开启binlog功能后，在mysql的数据库目录下就会有诸如mysql-bin.000001、mysql-bin.000002等文件，这就是mysql的二进制日志文件。每当mysql启动或手动刷新日志后都会新建一个二进制日志文件。

首先我们mysql命令行中，用”show master logs”命令查看已有的binlog文件。

2.往站点添加数据

在网站后台文章模块里，我添加了几条测试数据。

3.刷新binlog日志

此前mysql的binlog文件为mysql-bin.000001，并且在网站后台往数据库中添加了三篇文章。现在我们刷新binlog日志，会生成新的mysql-bin.000002文件，如下：

flushlogs; showmasterlogs;

4.删除数据

这里我把刚才添加的三篇文章都删除掉。

5.binlog日志内容解析

Mysql的二进制日志文件记录的mysql的操作，比如刚才的删除操作，我们来看下日志文件的具体内容。

使用mysql的mysqlbinlog命令：

mysqlbinlog/data/mysql/mysql-bin.000002

注意：因为我本地mysqlbinlog无法识别binlog配置中的default-character-set=utf8，所以这里我在命令中加上了” –no-defaults”才起作用，大家引以为鉴。

下面是日志内容部分截图：

6.恢复指定数据；

在通过mysql的binlog日志恢复数据时，我们可以指定恢复到具体时间点，这有点像服务器快照管理。所以我们现在要恢复刚才删除的那篇文章，可以从删除之前找一个时间点，并恢复到那个时间点即可。

有关mysqlbinlog命令的使用方法，我们可以通过mysqlbinlog的帮助命令进行查看，如下：

mysqlbinlog–no-defaults–help

如帮助文档所示，可以通过指定时间或指定位置来恢复数据，这里我以指定时间为例给大家演示。

我们来查看下日志文件mysql-bin.000001，如下：

mysqlbinlog-no--defaults/data/mysql/mysql-bin.000001

通过前面操作步骤我们知道，在删除数据之前，我们生成了mysql-bin.000002日志文件，所以我们只要恢复到这个时间点即可，上图中我已找到了这个时间。

命令如下：

mysqlbinlog–no-defaults–stop-datetime=’2017-04-1109:48:48’/data/mysql/mysql-bin.000001|mysql–uroot–p123456

这时我们在看后台，发现刚才删除的三篇文章都已恢复回来了，从而到达我们期望的目的。

总结：

本文和大家分享了如何通过mysql的二进制日志文件恢复数据。但还是要提醒大家，在平时要做好网站数据备份，现在的一些主流CMS建站系统都会内置数据库备份功能，比如这里我用的蝉知系统，数据是网站的命脉，做好数据备份以避免后期不必要的麻烦或损失。

首先确认开启 mysql binlog 日志进入 mysql 查看所有的二进制日志文件

4. 格式化查看binlog日志文件

5. 查看test数据库 b 表的数据

6. 修改b数据表数据,id为2的数据

7. 查看binlog日志

从上图中可以看到做修改的操作结束位置（end_log_pos）303

8. 现在开始恢复到修改前的数据

退出 mysql操作界面：

mysqlbinlog --stop-position=302 /data/mysqldb/mysql-bin.000001 | grep mysql -uroot -p

命令含义:将302之前的所有事件操作重新执行一边（不包括刚才的修改操作）

注释：--stop-position = 302 是因为之前的改变操作是在303执行的 所有恢复到302位置

9. 查看命令执行结果

10. 备份相关命令

mysqlbinlog --start-position=302 /data/mysqldb/mysql-bin.000001 | grep mysql -uroot -p

命令含义:将302之后的所有事件操作重新执行一边（不包括302之前的操作）

mysqlbinlog --start-position=302 --stop-position=500 /data/mysqldb/mysql-bin.000001 | grep mysql -uroot -p

命令含义:将302到500之间的所有事件操作重新执行一边

这世界上有后悔药-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吧，我们将尽一切可能帮您找回数据。

这世界上有后悔药-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吧！

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

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

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

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

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

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

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

有的时候因为web服务器掉电或者其他原因意外重启导致数据库损坏，作为站长的我们可以使用mysql自带的mysqlcheck命令来快速修复所有的数据库。

1、在开始运行中输入CMD,启动命令行. 进入MYSQL的bin目录：

入图片描述

2、运行MYSQL自带的mysqlcheck修复命令

运行：mysqlcheck -A -o -r -uroot -p888888

注意，将888888改成你自己的root用户密码

然后就会自动进行修复操作：

注意：在修复过程中，如果看到有error的提示，表示这个表示坏的，无法修复的，对于含有坏表的数据库，你只能删除它，或停止它，不然会影响整个MYSQL的稳定，造成MYSQL自动停止。(提示"The storage engine for the table doesn't support repair"的表不需要处理)

如果修复太快看不到结果,可以运行

mysqlcheck -A -o -r -uroot -p888888 >>C:\mysqlerror.txt

将888888改为你自己的MySQL root密码，运行后打开C:\mysqlerror.txt就可以看到了.

是不是很方便呢，作为站长的我们很轻松的就可以掌握这个方法！

这世界上有后悔药- 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来提供服务吧，我们又稳又好用，这些操作都熟。