一、前言

大数据时代，数据存储设备多种多样，便携的存储卡和U盘，大容量的机械硬盘，高读写速度的固态硬盘，以及高安全性的冗余磁盘阵列，可以说存储技术日新月异。然而，在我们日常的工作使用中也时常面临着数据丢失的困扰，不管是数据的误删除、格式化还是分区表的丢失与损坏，甚至是硬盘扇区的损坏，都给我们的正常使用带来了极大的不便。与此同时数据安全领域的前沿技术也在不断更新，针对不同的存储介质和不同的删除手段，形形色色的数据恢复工具也在不断地衍生和发展。

今天我们为大家测试了国际上比较主流的四款数据恢复工具，这些工具对于误删除、格式化和分区表损坏都有着很好的恢复效果，个别软件还具备着冗余磁盘阵列的分析与重组能力。参与测试的存储设备有市面上的高端固态硬盘，也有我们日常使用的U盘和机械硬盘，这些硬盘在删除或者格式化之后使用工具进行恢复有着不同的效果。

评测中对这些工具的使用做了详细的介绍，并且对比了不同的恢复工具在不同的数据丢失情形的具体表现效果，读者可以根据自己所面临的具体情形参考本评测做出不同的选择。

二、测试环境

操作系统 Windows 10 Pro 64-bit

处理器 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz

主板型号 iEi Technology Corp. - Intel B360 (V1.00)

内置硬盘 SAMSUNG MZMTD128HAFV-000 SCSI Disk Device (128GB)

存储介质 西部数据WD Blue 3D NAND SSD 1TB固态硬盘

Intel SSD DC 4600 480GB企业级固态硬盘

Seagate XF1230 480GB企业级固态硬盘

Kinston USB3.0 16GB U盘

测试工具：（均为商业注册版）

1、UFS Explorer Professional Recovery version 5.23.1

2、RecoveryMyFiles v5.2.1 Professional

3、 Recuva-Tech Editon v1.53.1087(64-bit)

4、R-STUDIO Network v8.5.170097

三、测试机构

鸿萌数据安全服务中心

四、软件简介

1. UFS Explorer Professional Recovery -version 5.23.1

UFS Explorer Professional Recovery

UFS Explorer Professional Recovery是一款强大的、综合的、但是易用的数据恢复软件，可以帮助用户进行快速和全面的数据恢复和反删除程序文件。支持各个版本的Windows系统的磁盘阵列恢复， UFS的资源管理与专业恢复可以帮助您从不同的操作系统的文件系统中恢复损坏或者丢失的文件。

2. RecoveryMyFiles v5.2.1 Professional

Recover My Files

Recover My Files是一款功能及其强大的数据恢复工具，支持恢复误删除，甚至是磁盘格式化后的文件。它可以自定义搜索的文件夹、文件类型，以提高搜索速度及准确性节约时间，在搜索过程中，提供了大量的信息，包括：文件名、文件/目录、尺寸、相关日期、状态、对一般性文档可直接预览等，让你更好地选择要恢复的文件。操作简单、快捷，需要的朋友请下载体验！Recover My Files可以恢复包括文本文档、图像文件、音乐和视频文件、以及删除的zip文件，可以以扇区的方式扫描硬盘。支持的格式包括：mpegpdf、pmd、png、ppt、pst、pub、rar、rtf、sdr、tar、txt、tiff、viso、wav、wmf、wpd、xls、zdp、zip、asf、avi、bmp、csv、doc、dbx、dwg、gif、gzip、html、jpeg、mdb、mov、mp3等，并且可以进行恢复预览。支持从硬盘、相机卡、USB、Zip、软盘、iPod、平板电脑和其他媒体设备中恢复，从回收站清空已清空中恢复文件，恢复意外删除文件即使您重新安装Windows，从硬盘出现故障的磁盘恢复，恢复一个分区错误的文件，从原始硬盘恢复数据，支持恢复文件、 照片、 视频音乐和电子邮件等多种文件类型，恢复格式包括exFAT，NTFS、 HFS、 HFS +等等。

3. Recuva-Tech Editon v1.53.1087(64-bit)

Recuva

Recuva 可以用来恢复那些被误删除的任意格式的文件，能直接恢复硬盘、闪盘、存储卡（如 SD 卡，MMC 卡等等）中的文件，只要没有被重复写入数据，无论格式化还是删除均可直接恢复，支持 FAT12，FAT16，FAT32，NTFS，exFat 文件系统。软件操作简单，搜索被删除文件的速度极快，选择好要扫描的驱动器后点击扫描按钮即可。

4. R-STUDIO Network v8.5.170097

R-Studio

R-Studio是一款强大和具成本效益的撤消删除与数据恢复软件。具备独一无二数据恢复技术的支持，它是面向恢复文件的最为全面数据恢复解决方案，适用于NTFS、NTFS5、ReFS、FAT12/16/32、exFAT、HFS/HFS+ (Mac)、Little 和 UFS1/UFS2的Big Endian variants (FreeBSD/OpenBSD/NetBSD/Solaris)，以及 Ext2/Ext3/Ext4 FS (Linux) 分区。它亦可针对严重毁损或未知的文件系统，使用原始文件恢复(扫描已知的文件类型)。亦可用于本地和网络磁盘，即使已格式化、毁损或删除该分区。弹性参数设置，让您得以全面控制数据恢复过程。R-Studio除了是一款功能完善的数据恢复工具，还包括:高级 RAID 重建模块、功能丰富的文本/十六进制编辑器、整个高级磁盘复制/成像模块位于一个软件中，这使得 R-Studio 成为了创建数据恢复工作站的理想解决方案。

R-Studio中文版实用程序恢复文件可以恢复:

没有进回收站而被直接删除的文件，或当回收站被清空时的文件;

因断电或病毒攻击导致的数据丢失;

在分区文件被格式化后，甚至用于不同文件系统;

如果硬盘上的分区结构已更改或损坏。在这种情况下，R-Studio 实用程序会扫描硬盘，尝试找到之前存在的分区并从中恢复文件。

从带有损坏扇区的硬盘中恢复。R-Studio数据恢复软件首先会将整个或部分磁盘复制到镜像文件，然后进行处理。如果硬盘上持续出现新损坏的扇区，必须立即保存其余信息，这一处理方式尤为有用。

五、恢复测试

图 5.1 RecoveryMyFiles v5.2.1 Professional扫描结果

图 5.2 RecoveryMyFiles v5.2.1 Professional恢复内容

图 5.3 RecoveryMyFiles v5.2.1 Professional恢复内容

恢复后文件属性

删除前文件属性

图 5.5 UFS Explorer Professional Recovery对文件删除后的扫描

测试结果分析：只是经过简单的删除操作，仍然能够扫描到已经删除的历史文件，但是原有文件名丢失，其路径为所在分区的X:/ROOT/$RECYCLE.BIN，即该分区的一个隐藏回收站目录。对恢复出来的文件打开后和原始文件进行比对，内容均无差别，大文件也能精确到字节无差别。

图 5.6 RecoveryMyFiles v5.2.1 Professional对格式化后的扫描

图 5.7 UFS Explorer Professional Recovery对格式化后的扫描j结果

测试结果分析：从扫描结果可以看出对于固态硬盘，格式化后使用工具对硬盘进行扫描，很难再扫描到可用文件

图 5.8 R-STUDIO对硬盘扇区进行扫描

图 5.9 R-STUDIO对硬盘文件的恢复情况

测试结果：使用R-STUDIO对硬盘进行扫描之后，能够很清楚的看到硬盘的存储痕迹，其中包括NTFS信息以及特定的档案数据块。恢复工具会自动判断原始文件类型，按照需要可选择有需要的文件进行恢复。

图 5.10 Priform Recuva - Technician Edition对硬盘文件的扫描结果

图 5.11 Priform Recuva - Technician Edition对硬盘文件的恢复

测试结果分析：使用Recuva对硬盘进行扫描之后，能够很清楚的看到已经删除的文件具体信息，其中包括文件名、路径、修改时间、文件大小和存储状态。我们可以发现，只是单纯的删除操作，未对硬盘进行过后续写入的话，文件的存储状态均为良好，经过恢复之后都能够找回完整的原始文件。

六、效果对比

表1 数据恢复工具使用效果对比

存储介质

固态硬盘

机械硬盘

U盘

丢失情形

删除

格式化

删除

格式化

删除

格式化

R-STUDIO

扫描不到可用文件

扫描不到可用文件

数据完整目录完整

数据完整目录损坏

数据完整目录完整

数据完整目录损坏

UFS Explorer

目录损坏文件完整

扫描不到可用文件

数据完整目录完整

数据完整目录完整

数据完整目录完整

数据完整目录损坏

RecoveryMyFiles

目录损坏文件完整

扫描不到可用文件

数据完整目录完整

数据完整目录完整

数据完整目录完整

数据完整目录损坏

Recuva

扫描不到可用文件

扫描不到可用文件

数据完整目录完整

数据完整目录完整

数据完整目录完整

数据完整目录可见

通过具体的恢复测试和上述的对比我们不难发现，不同的存储介质在经过删除或者格式化后，使用各个工具对数据进行恢复的结果也各不相同，大部分情况下都能恢复出完整的文件，但恢复后的文件目录时有损坏。

我们常用的U盘和机械硬盘在删除和格式化之后使用以上工具基本都能恢复出原始数据，读者可以根据恢复的形式和效果来选用，以上工具均可针对全盘或者分区进行恢复，也可设定文件的类型。R-studio在恢复数据时扫描信息与别的工具相比更为详细，对于恢复出的文件便于查找和导出。UFS和RecoveryMyFiles在使用上基本没有差异，在扫描后可以很清晰的看出文件的结构目录。Recuva适用于快速恢复，对于U盘的删除与格式化，可以快速扫描出已删除文件以及路径，并且显示出文件的覆盖情况和恢复成功的可能性，但是不能按照文件目录结构的形式显示出已扫描到的文件，比较适用于快速的恢复。

总结

随着电子信息行业的飞速发展和存储技术的不断迭代，多样的存储介质也被应用在我们工作生活中的各个方面。日常使用中的操作不当和误删除都会导致数据的丢失，这个时候，数据恢复工具的合理使用便可以为我们省去很多烦恼。

但是如果对于硬盘和恢复工具的使用没有充分的了解，鸿萌建议您不要轻易尝试，以免造成不可逆的数据覆盖。数据无价，谨慎操作。鸿萌数据安全中心，为您的数据保驾护航。

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

1、发现问题后立即停止一切涉及到“写”的动作。这是最最重要的问题。这样的操作会进一步扩大损失！涉及到“写操作”的动作有很多，如保存文件、建立新文件、删除文件。甚至操作系统的正常运行也会有大量的写操作，系统运行时会产生临时文件、网页缓存、文档访问记录、系统运行日志、QQ或MSN聊天记录等等，非常多。不过这些写操作在默认情况下都是写到系统分区(一般情况下是 C 盘)的。聊天记录一般保存在“我的文档”文件夹。如果是系统盘(C盘)的文件丢失，最好的办法应该是立即关掉电脑电源(不是正常的关机，正常关机也可能会有写操作)，然后再将硬盘挂到其它电脑上进行文件恢复。挂到其它电脑上以后，也要注意关闭Windows的系统还原，不要随意打开问题硬盘上的文件。因为打开文件的同时很可能会产生一些临时文件，造成二次破坏。(注：可见平时养成将个人文件保存到非系统盘的习惯是多么的重要)

2、自己不懂不要随意尝试。很多用户丢失数据后非常焦急，很想立即恢复数据，于是就想方设法尝试各种数据恢复的方法。所谓有病乱投医。但由于自己没有这方面的经验，东跑西撞胡乱操作一气，反而引起更严重的后果，导致数据彻底无法恢复。如果数据非常重要，最好的办法还是将硬盘送到专业的数据恢复公司去恢复。收费可能高点，但是数据无价呀。数据恢复确实是需要很高的技术的。

3、不要格式化。格式化是会破坏数据的！很可笑吧？这还用说？是的，需要说一下。因为有很多用户并不明白“格式化”是什么意思，大概认为格式化就是使文件更整齐吧。这是错误的，非常错误！有用户认为文件丢失后，用“误格式化后的文件恢复”功能恢复文件的成功率是很高的，所以先将分区格式化一下，再用这个功能就可以恢复数据了。不知道这样的谣传是从哪里出现的。千万不要格式化了。格式化就等于初始化，它会将分区的重要区域清零并重新设置。这将会导致恢复文件所需的重要信息丢失，从而降低数据恢复的成功率。

4、重建分区表功能不是万能的。不要什么原因造成的数据丢失都用“重建分区表”功能(就是搜索已丢失分区功能)来修复。这个功能虽然强大，但也有它特定的适用范围。它只适用于分区丢失的情况。如果分区还在，只是文件丢失了，或提示分区未格式化了，用这个功能是无济于事的。反而如果在未搜索到正确的分区的情况下执行了“保存分区表”命令，还会造成更大损失。

一、上期我们分享了SQL2000数据库的备份与还原，这期我们再来分享下SQL2008数据库的备份与还原。

二、SQL2008数据库的备份

1、登录sql server management studio

2、选择要备份的数据库，右键—任务—备份

3、添加备份目标，并输入备份文件的名称

4、这是选择好后的显示页面，确定再确定即开始备份并完成

三、数据库还原

1、选择要还原的数据库—右键—任务—还原

2、如图，刚才备份的数据库会直接显示，可以直接还原

3、注意选项中要勾选“覆盖现有数据库”，“还原为”的路径一定确保正确

4、另外一种情况是通过源设备选择还原的文件

5、“文件类型”要选择所有文件，否则看不到备份是文件

6、勾选“还原”，确定即可完成还原

近来，数据库安全问题频发，如何保障业务数据可靠、可用、可恢复性再次被业界提上议程。华为云数据库也适时推出表数据快速恢复功能，支持表级别的时间点数据恢复，帮助用户快速恢复 MySQL 数据库中某张表的数据，解决用户误删、误drop数据问题。

该功能适用于更细粒度的数据恢复。当用户在某个时间点删除了某个表，或者修改了某个表的一些记录时，只需对该表进行恢复，而不用将整个实例进行恢复，可以大幅节省恢复时间。

通过表级时间点恢复备份，用户可以根据需要恢复库表，且不会导致实例数据被覆盖。系统会自动生成以时间戳为后缀的库表名，也支持自定义恢复后的库表名，相当便利。

目前，该功能仅支持 MySQL 数据库。值得一提的是，自华为云 MySQL 搭载 HWSQL 内核后，增强连接池特性，并发量 5000 时性能依然稳定，QPS 超过 17万+，性能远超社区版。这对于高并发场景显著的行业，例如游戏行业而言，无啻于福音。

我们知道，游戏行业动辄百万级玩家同时在线，并发数达到 3000+，单实例 QPS 峰值 10万+，对数据库性能要求高。此外，由于玩家在线数量不确定，扩容开服、缩容合服的情况频繁，资源使用弹性大；行业竞争激烈，恶意攻击且攻击方式复杂多变，安全性要求也高。

华为云数据库 MySQL 的性能，单区足以支撑千万级用户在线，且支持一键 CPU/内存/存储空间扩容、添加只读副本，满足资源弹性伸缩需求。在安全性方面，华为云数据库提供了VPC、安全组、防 DDoS，防 SQL 注入，数据加密、SSL 加密连接等多维度安全策略，并获得了可信云、安全等保、CSA STAR 等多种权威认证，为数据库提供全方位高安全防护。

华为云 MySQL 在性能和安全上的突出表现，离不开技术的支持和功能的持续优化。

早前，华为云 MySQL 就引入了线程池功能，支持更多连接，对于大并发性能提升明显。并对 MySQL5.6 引入真正的多线程复制，大大降低社区版单线程复制导致的复制延迟。存储引擎 MyISAM 自动转换为 InnoDB，完全支持事务，同时避免表级锁，提高并发性。

此外，华为云 MySQL 还对 RDS 进行权限控制，对能影响实例稳定运行的命令进行权限控制，保障实例稳定可靠，提供更高安全保障。

近期，华为云 MySQL 上线了一系列新特性，不但对数据库性能进一步提升，而且首家彻底解决用户迁移上云要修改应用程序，以及传统数据库备份遭遇事务阻塞的问题。

本次 MySQL 推出的新功能，还包括配置了长时间超时事务，避免业务处理异常、造成超长事务带来的系统影响；支持动态开关线程池，针对高并发、小并发不同场景选择不同状态，且无需重启数据库。以及支持 root 账号 kill 掉其他 user 线程，提升用户体验等。

HUAWEI CONNECT 2018作为华为自办的面向ICT产业的全球性年度旗舰大会，将于2018年10月10日-12日在上海隆重举行。本届大会以"+智能，见未来"为主题，旨在搭建一个开放、合作、共享的平台，与客户伙伴一起共同探讨如何把握新机遇创造智能未来。

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

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

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

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

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

欢迎点击右上角+关注，反正动动手指也不会怀孕，更重要是希望能在工作中帮助到您。

前言

[代码笔记]为一系列的文章，从一个python,django完整项目的环境和工具讲起，随时供自己备查，进阶全栈工程师的狂暴之路。

开始

阿里云的RDS数据提供了默认的自动数据库备份功能，但当面临单表数据误删，或者单表误drop的情况，如果使用物理全备进行恢复呢？我就遇到这个麻烦问题。

因为这个备份文件的恢复并不是sql的全量备份，而是基于innodb的文件备份。

下载备份文件

首先从阿里云下载了名字类似为hins1751639_data_20170424063544.tar.gz的备份文件到本地。看到解压缩开的一堆文件如下图所示

tar-xzvfhins1751639_data_20170424063544.tar.gzhint

备份文件解压

其中wonderland目录下是当前的数据库里数据文件

我要用到的是web_store表，对应的文件为web_store.ibd和web_store.frm

找回表结构

表结构没丢的话直接跳过本节，看下一步

1进入mysql,创建一个新的临时数据库

CREATEDATABASEsstestDEFAULTCHARACTERSETutf8；

2创建一个表结构，和要恢复的表名是一样的。表里的字段无所谓,一定要是innodb引擎的

CREATETABLEweb_store(idint(11)NOTNULLAUTO_INCREMENT,namevarchar(128)NOTNULL,)ENGINE=InnoDBAUTO_INCREMENT=53DEFAULTCHARSET=utf8;

3关闭mysql

mysql.servicestop

4用需要恢复的web_store.frm覆盖新建的frm文件，我在mac本地的数据文件路径在/usr/local/mysql/data/sstest/

cpweb_store.frm/usr/local/mysql/data/sstest/web_store.frm

5参考资料说要修改my.ini里innodb_force_recovery=1，如果不成修改为2,3,4,5,6。，我在本地没有这个文件，跳过了这一步

6启动mysql

mysql.servicestartshowcreatetableweb_store

看到表结构

找回数据

2废掉表空间，使当前的ibd和frm分离

altertableweb_storediscardtablespace;

3把之前要恢复的.ibd文件复制到新的表结构文件下，使当前的ibd和frm发生关系

altertableweb_storeimporttablespace;

这里没错误的话就已经建立好了。

4把所有数据导出后，在新的数据库导入

参考命令

1导出一个表，包括表结构和数据

mysqldump-u用户名-p密码数据库名表名>导出的文件名mysqldump-uroot-ptestweb_store>web_store.sql

2在mysql里导入sql语句

source~/web_store.sql

3改变文件拥有者和群组权限，mysql有可能因为权限问题读去不了对应的frm和ibd文件

sudochown_mysql:wheelweb_store.frm

个人警醒

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

一、数据库备份

1、打开企业管理器，如图所示操作

2、一般选择完全备份，添加备份目的

3、选择备份目录，输入备份数据库名称，接着按下图操作即可，直至完成备份

二、数据库还原

2、如果之前备份了库，在此处可以直接还原，请选择“在现有数据库上强制还原”

2、从设备还原，比如从别的服务器上拷过来的备份库，选择设备，添加还原设备，如下图操作即可，直至还原完成

3、如果还原时提示数据库正在被占用，可通过分离功能清除连接再进行还原；注意：使用分离功能只是清除连接，不要点“确定”真的分离数据库

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