台式机，笔记本，服务器硬盘数据恢复，RAID0，RAID1数据恢复，承接高难度硬盘数据恢复，磁头损坏，变形，移位，开盘等故障，各外部存储器，内存卡，数码相机，U盘，移动硬盘，手机数据恢复，红警数据恢复！

红警专业数据恢复公司

红警专业硬盘数据恢复：零七五五—八八八五八八零五

联络办法：零七五五—二五三二三七五八

1、逻辑故障：误分区、误格式化、误删除、误克隆、分区表信息丢失、引导扇区信息丢失、病毒破坏、黑客攻击等

2、物理故障：BIOS不认盘、硬盘异响、电机不转、磁头烧坏、磁头老化、磁头芯片损坏、磁头偏移、盘片划伤、磁组变形、电路板烧坏、外电路芯片击穿、接口断针等。

3、磁盘阵列（RAID）数据恢复：RAID0，RAID1，RAID0+1，RAID1+0，RAID5，RAID5+0，RAID5+1，RAID5+0+1，RAIDADG，RAID6，RAID5E，RAID5EE，JBOD，SAN，NAS。 磁盘阵列常见故障： ·系统不能启动、RAID信息破坏、由于某块硬盘掉线，替换后重建失败，系统崩溃、RAID信息丢失；

·硬盘（单块或多块）掉线、RAID卡损坏，更换后系统崩溃、分区信息丢失；

·硬盘坏道（物理、逻辑）、重新配置RAID阵列信息、磁盘顺序出错、动态磁盘数据库丢失或损坏；

·LINUX、UNIX系统启动不成功，或者分区不能mount，找不到分区；

·rebuild中途失败、rebuild成功后，分区找不到或者系统不能启动；

·红灯不停闪，或者黄灯不停闪（有的黄灯闪表示正在读取，有的是错误指示）；

·MBR损坏、DBR损坏、磁盘单块坏道、磁盘多块坏道．

4、数据库数据恢复：Access，Foxpro，SQL SERVER，ORACLE，MYSQL，DB2、Informix，Sybase等数据库修复。

5、文件修复：各种文件破损后的修复。

6、邮件修复：支持Foxmail、Outlook、Outlook Express、Exchange Server、Lotus Notes等邮件数据的恢复和修复。 7、可以破解系统密码和文件密码。

二、介质接口支持 可修复IDE、SATA、SCSI、FC、RAID磁盘阵列等；

三、操作系统支持 支持的操作系统DOS/Win9X、Mac、WinNT/2000/XP/2003、Linux、Unix、Novell等。

四、硬盘品牌分类 支持希捷、西部数据、迈拓、IBM、昆腾、日立、三星、东芝、富士通、易拓等。

五、支持的介质类型 支持硬盘、移动硬盘、MO、PD、U盘、ZIP、光盘、软盘、磁带、闪存、MP3、录音笔、MP4、PDA等。

地址：深圳市龙华东环一路东环天虹正对面（旭日大厦5楼全层）

数据备份与还原 基础概念： 备份，将当前已有的数据或记录另存一份； 还原，将数据恢复到备份时的状态。 为什么要进行数据的备份与还原？ 防止数据丢失； 保护数据记录。 数据备份与还原的方式有很多种，具体可以分为：数据表备份、单表数据备份、SQL备份和增量备份。

故障描述：

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

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

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

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

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

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

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.数据恢复结论：

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

数据库管理系统(database management system)是一种操纵和管理数据库的大型软件，是用于建立、使用和维护数据库，简称dbms。它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户通过dbms访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它提供多种功能，可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。它使用户能方便地定义和操纵数据，维护数据的安全性和完整性，以及进行多用户下的并发控制和恢复数据库。 按功能划分，数据库管理系统大致可分为6个部分： (1)模式翻译：提供数据定义语言(ddl)。用它书写的数据库模式被翻译为内部表示。数据库的逻辑结构、完整性约束和物理储存结构保存在内部的数据字典中。数据库的各种数据操作(如查找、修改、插入和删除等)和数据库的维护管理都是以数据库模式为依据的。 (2)应用程序的编译：把包含着访问数据库语句的应用程序，编译成在dbms支持下可运行的目标程序。 (3)交互式查询：提供易使用的交互式查询语言，如sql。dbms负责执行查询命令，并将查询结果显示在屏幕上。 (4)数据的组织与存取：提供数据在外围储存设备上的物理组织与存取方法。 ⑸事务运行管理：提供事务运行管理及运行日志，事务运行的安全性监控和数据完整性检查，事务的并发控制及系统恢复等功能。 (6)数据库的维护：为数据库管理员提供软件支持，包括数据安全控制、完整性保障、数据库备份、数据库重组以及性能监控等维护工具。 基于关系模型的数据库管理系统已日臻完善，并已作为商品化软件广泛应用于各行各业。它在各户服务器结构的分布式多用户环境中的应用，使数据库系统的应用进一步扩展。随着新型数据模型及数据管理的实现技术的推进，可以预期dbms软件的性能还将更新和完善，应用领域也将进一步地拓宽。 它所提供的功能有以下几项： （1）数据定义功能。DBMS提供相应数据语言来定义（DDL）数据库结构，它们是刻画数据库框架，并被保存在数据字典中。 （2）数据存取功能。DBMS提供数据操纵语言（DML），实现对数据库数据的基本存取操作：检索，插入，修改和删除。 （3）数据库运行管理功能。DBMS提供数据控制功能，即是数据的安全性、完整性和并发控制等对数据库运行进行有效地控制和管理，以确保数据正确有效。 （4）数据库的建立和维护功能。包括数据库初始数据的装入，数据库的转储、恢复、重组织，系统性能监视、分析等功能。 （5）数据库的传输。DBMS提供处理数据的传输，实现用户程序与DBMS之间的通信，通常与操作系统协调完成。 著名数据库管理系统 MS SQL SYBASE DB2 ORACLE MySQL ACCESS VF 常见的数据库管理系统 目前有许多数据库产品，如Oracle、Sybase、Informix、Microsoft SQL Server、Microsoft Access、Visual FoxPro等产品各以自己特有的功能，在数据库市场上占有一席之地。下面简要介绍几种常用的数据库管理系统。 Oracle Oracle是一个最早商品化的关系型数据库管理系统，也是应用广泛、功能强大的数据库管理系统。Oracle作为一个通用的数据库管理系统，不仅具有完整的数据管理功能，还是一个分布式数据库系统，支持各种分布式功能，特别是支持Internet应用。作为一个应用开发环境，Oracle提供了一套界面友好、功能齐全的数据库开发工具。Oracle使用PL/SQL语言执行各种操作，具有可开放性、可移植性、可伸缩性等功能。特别是在Oracle 8i中，支持面向对象的功能，如支持类、方法、属性等，使得Oracle 产品成为一种对象/关系型数据库管理系统。 Microsoft SQL Server Microsoft SQL Server是一种典型的关系型数据库管理系统，可以在许多操作系统上运行，它使用Transact-SQL语言完成数据操作。由于Microsoft

（本文内容由百度知道网友爱刷2646贡献）

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

事务是在数据库中完成单一逻辑功能的操作集合，每个事务由一个原子性和一致性的单元组成。所以要求每个事务必须遵守数据库的一致性约束。事务中成功结束时的数据库必须与事务启动时的数据库一致。但是在事务的运行期间，暂时的不一致性时允许的，但是发生故障时会导致困难。

确保事务的原子性和一致性是每个数据库本身的责任。具体点，是事务管理部分的责任。没有故障的时候，所有的事务都能完成，并且原子性很容易完成。然由于不同故障的存在一个事务不可能完全顺利的完成。如果要确保原子性的性质，那么该数据库的状态必须不受这个失败事务的影响。因此，该数据库恢复到这个失败事务开始执行前数据库所处的状态。发现系统故障和将该数据库恢复到这个失败事务开始执行前数据库所处的那个状态是这个数据库的责任。

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

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

一、附加数据库与分离数据库相反，只有分离的数据库才能附加，分离后的数据库不能再正常读取，只有附加后才能读取；而还原数据库是指在原有数据库的基础上进行，一般选择覆盖原有数据库，SQL中如果不存在这个库是不能还原的（物理设备上要有库文件）。客户的服务器需要重装，小编是先备份原库（使用软件或SQL备份或停止SQL直接拷走数据库文件或在PE下拷走），重装完成后拷回原位置直接附加（个人经验附加始终比还原快），使用还原的情况比较少。还原数据库小编之前已经分享过，这里不再赘述。今天小编来分享下数据库的分离与附加。

二、分离数据库

1、选中要分离的库—右键“所有任务”—分离数据库

2、如果存在数据库连接可“清除”，点击“确定”

3、分离成功

三、附加数据库

1、要在“数据库”上右键—所有任务—附加数据库

2、附加数据库界面：点击按钮

3、选择要附加的数据库文件，注意要选择.MDF的文件，.LDF是日志文件

4、选择好后的界面，注意“指定数据库所有者”，有的是sa，有的是其它的，比如科脉是km

5、点击“确定”，附加成功

四、有时候轻度数据库置疑也可以通过“分离—附加”来修复，不过还是不建议这样做。我是百家号作者小白信息说，专注电子信息领域经验分享、技术交流，感谢关注！