beiya123的博客

4、恢复被truncate的表。在下载完成的数据段文件内提取对应于各表的数据页，通过解析对应表的frm文件获取到表的表结构信息。7、由于直接从底层抓取出的记录可能存在主键不唯一（引擎在存储时产生的临时记录）和记录重复（缓冲段）以及乱码（扫描数据段时出现特征值匹配成功但不属于该表的数据段）等情况，提取出的记录可能存在异常，需要进行人工处理。5、恢复被delete数据的表，基本流程和恢复truncate表数据的流程基本一致，不同点在于数据解析时需要提取被标注为“delete”的记录。8、所有数据处理完成后。

北亚企安数据恢复工程师对数据库进行仔细排查，发现报错的原因是从重组的raid中提取出的dmp文件异常，导致dmp导入数据时报错。2、所有硬盘镜像完成后，查看镜像工具生成的日志，发现在storage manager和硬盘SMART状态中均没有报错的一块盘（非掉线盘）存在坏道，离线的2块硬盘存在大量不规律的坏道分布。根据坏道列表定位到目标镜像文件，经过分析发现ext3文件系统的部分关键源数据信息被坏道破坏，只能通过同一条带进行xor以及根据文件系统上下文关系的方式手动修复被损坏的文件系统。

7、获取到数据库数据后在数据恢复专用服务器内搭建数据库环境，创建数据库、用户、分配表空间等。数据恢复工程师借助expdp/exp工具尝试对导出数据库，但这两个工具导出数据库时依然有报错，数据库已经不可能进行修复。5、数据恢复工程师再次执行恢复命令，打开数据库，查询实例状态有无报错。4、经过修复发现，由于归档日志不连续，恢复数据库所需时间段的归档日志缺失，只能使用cancel参数进行不完全数据恢复。3、根据数据库的报错情况，数据恢复工程师试图借助在线日志恢复数据，使用recover database命令。

北亚企安数据恢复工程师到达现场后，将故障服务器中所有硬盘以只读方式进行完整镜像。镜像完成后将所有硬盘按照原样还原到原服务器中，后续的数据分析和数据恢复操作基于镜像文件进行，避免对原始磁盘数据造成二次破坏。发现服务器内丢失的数据是数据库文件，导致数据库报错。通过扫描分区，然后根据文件号拼接出格式化的磁盘中的数据文件，底层解析这些数据文件，插入到数据库中，数据完全恢复。由于管理员误操作不小心删除了该分区，数据库报错，无法使用。4、解析system和拼接成的数据文件，将test01用户到数据库中。

将所有镜像文件全部发开，根据对ext3文件系统的逆向以及日志文件的分析，获取到16块FC盘在存储中的盘序，RAID的块大小，RAID的校验走向和方式等信息。对该硬盘进行坏道镜像操作，在镜像过程中同时观察镜像的速度和稳定性，发现该盘的坏道并不多，但是存在大量的读取响应时间长的不稳定扇区。对备份的控制文件进行查看修改，取得其中的重建控制文件命令。3、虽然镜像速度很慢的那块盘镜像完成，但是拷贝策略导致现在的镜像是不完整的，调整拷贝策略，继续镜像被跳过的扇区，直到该盘所有扇区全部镜像完毕。全库备份完成，没有报错。

3、随机挑选表内数据交由用户方进行验证，并统计恢复出来的记录总数。经过验证，用户方确认数据正确，记录总数和原表内记录条数一致。第三种数据恢复方案的原理为模拟innodb引擎记录管理方式，根据表结构信息将二进制文件解析为字符记录。人为误操作使用Delete命令删除数据时未添加where子句进行筛选，结果是全表数据被删除，删除后未对该表进行任何操作。2、使用北亚企安自主开发的Mysql数据库恢复工具恢复mysql数据。本案例中用户方提供了表结构脚本，可以使用本工具中的5+3功能进行恢复。a、读取表结构信息。

mdb_catalog.wt文件是专门用于存储MongoDB中所有集合元数据的文件，MongoDB数据库启动时必须读取的相关信息都存储于_mdb_catalog.wt文件中。1、扫描MongoDB数据库所在分区的底层数据，但是没有扫描到和_mdb_catalog.wt文件有关的信息，使用其他扫描方式进行扫描，仍然无法查找到_mdb_catalog.wt文件相关信息，基本上可以确定该文件已被覆盖，无法通过恢复_mdb_catalog.wt文件的方式来修复数据库。结果发现拷贝过去的数据无法使用。

6、结合SQL Server数据库备份修复SQL Server数据库中加密的页。通过SQL Server数据库管理工具附加修改好的SQL Server数据库，并进行查询验证。经过上面的分析，我们知道SQL Server数据库与SQL Server数据库备份加密方式一样，每128K进行一次加密，加密大小为128字节。4、打开SQL Server数据库备份，发现也是每128K进行一次加密，加密大小也为128字节。2、打开被加密的SQL Server数据库，北亚企安数据恢复工程师发现数据库的头部已被破坏。

oracle数据库误执行truncate命令导致数据丢失是一种常见情况。通常情况下，oracle数据库误操作删除数据只需要通过备份恢复数据即可。也会碰到一些特殊情况，例如数据库备份无法使用或者还原报错等。下面和大家分享一例oracle数据库误执行truncate命令导致数据丢失的数据库数据恢复过程。

准备一台用来恢复数据的服务器，以只读方式挂载故障服务器上的硬盘，进行扇区级别的完整备份。北亚企安数据恢复工程师到现场进行检测，发现虚拟机可以正常启动，虚拟机上的数据库块文件丢失。5、校验提取出的Block文件的完整性及正确性，然后将提取出来的Block文件导入到hbase和hive数据库中。4、根据Block文件的key信息提取文件片段。拼接Block文件的片段并校验拼接后的Block文件的正确性。2、分析每个虚拟机磁盘的块文件、文件底层的聚合方式、每个磁盘中数据的分布情况、Block文件key。

SQL server数据库数据故障：SQL server数据库被加密，无法使用。数据库MDF、LDF、log日志文件名字被篡改。数据库备份被加密，文件名字被篡改。

由于该MongoDB数据库中存在Gridfs存储的大字段（文件）集合，所以可以通过查询集合中的记录确定记录类型，从而确定fs.files和fs.chunks集合的位置。在MongoDB数据库服务没有关闭的情况下拷贝MongoDB数据库文件，通常会导致mongod.lock文件以及WiredTiger.lock文件拷贝出错。此文件丢失会导致数据库无法获取数据库中集合对应的WT table名字、集合的创建选项、集合的索引信息等元。b、使用编译完成的wt工具，清洗回写MongoDB数据库的集合文件中的数据。

一台服务器中有一组由三块SAS硬盘组建的raid阵列。服务器上部署的数据库存储在D分区，数据库备份存储在E分区。服务器上一块硬盘指示灯显示红色。D分区不可识别。E分区虽然可以识别，但是E分区拷贝文件报错。管理员重启服务器，先离线的硬盘上线开始同步数据，同步没有完成的情况下管理员将服务器强制关机，之后没有动过服务器。

SQL Server数据库附加数据库过程中比较常见的报错是“错误 823”，附加数据库失败。如果数据库有备份则只需还原备份即可。但是如果没有备份，备份时间太久，或者其他原因导致备份不可用，那么就需要通过专业手段对数据库进行数据恢复。

本地服务器，安装的windows server操作系统。操作系统上部署MySQL单实例，引擎类型为innodb，表空间类型为独立表空间。该MySQL数据库没有备份，未开启binlog。人为误操作，在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除，删除后未对该表进行任何操作。

作为文档数据库，MongoDB不限制用户存储数据的体量和类型，因此适合大数据的应用环境，这对基于云的服务将特别有利。基于水平可扩展能力，以及与云服务的敏捷性结合，MongoDB数据库不但能够减少开发者的工作量，简化业务与项目的扩展流程，还能够提供高可用性和数据的快速恢复。北亚企安数据恢复工程师通过用户方的描述，以及对数据库环境和底层数据的检查，发现MongoDB数据库在迁移过程中丢失了_mdb_catalog.wt文件，所以导致数据库报错。4、创建一个全新的MongoDB数据库，并创建相应数据量的集合。

某ECS网站服务器，linux操作系统+mysql数据库。mysql数据库采用innodb作为默认存储引擎。在执行数据库版本更新测试时，操作人员误误将在本来应该在测试库执行的sql脚本在生产库上执行，导致生产库上部分表被truncate，还有部分表中少量数据被delete。

一块硬盘上存放的SqlServer数据库，windows server操作系统+NTFS文件系统。由于误操作导致分区损坏，需要恢复硬盘里的SqlServer数据库数据。

Oracle数据库常见故障表现：1、ORACLE数据库无法启动或无法正常工作。2、ORACLE ASM存储破坏。3、ORACLE数据文件丢失。4、ORACLE数据文件部分损坏。5、ORACLE DUMP文件损坏。

mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现：1、数据库无法进行查询等操作；2、使用mysqlcheck和myisamchk无法修复数据库。

Sybase数据库数据恢复环境：Sybase数据库版本：SQL Anywhere 8.0。Sybase数据库故障&分析：Sybase数据库无法启动。使用Sybase Central连接报错。数据库数据恢复工程师经过检测，发现Sybase数据库出现故障的原因是：异常断电造成Sybase数据库无法回写正常数据，导致多个存储页数据不一致，系统表描述和存储表不一致，部分存储页底层数据完全杂乱。

system01.dbf需要更多的恢复来保持一致性”，出现这个报错信息可能是由控制文件损坏、数据文件损坏，数据文件与控制文件的SCN不一致等原因所导致。system和用户表空间的数据文件都是正常的，可以尝试利用底层解析数据文件，恢复用户数据。一台Oracle数据库打开报错，报错信息： “system01.dbf需要更多的恢复来保持一致性，数据库无法打开”。结果发现SYSAUX01.DBF文件数据块（Data）检测失败的页总数和索引页（Index）检测失败的页总数都有数十页，其他文件检测正常。

存储掉盘超过上限，lun无法识别。管理员重组存储的位图信息并导出lun，发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。取出&并分析oracle数据库的控制文件。重组存储位图信息，重新导出控制文件中记录的数据文件，发现这些文件的大小依然为0kb。

一个运行在存储上的SQLServer数据库，有1000多个文件，大小几十TB。数据库每10天生成一个NDF文件，每个NDF几百GB大小。数据库包含两个LDF文件。存储损坏，数据库不可用。管理员试图恢复数据库，发现有数个ndf文件大小变为0KB。虽然NDF文件大小变为0KB，但是NDF文件在磁盘上还可能存在。可以尝试通过扫描&拼接数据库碎片来恢复NDF文件，然后修复数据库。

Oracle数据库数据恢复环境&故障：Oracle ASM磁盘组由4块磁盘组成。Oracle ASM磁盘组掉线 ，ASM实例不能mount。Oracle数据库故障分析&恢复方案：数据库数据恢复工程师对组成ASM磁盘组的磁盘进行分析。对ASM元数据进行分析发现ASM存储元数据损坏，导致磁盘组无法挂载。

打开oracle数据库时报错，报错信息：“system01.dbf需要更多的恢复来保持一致性，数据库无法打开”。急需恢复zxfg用户下的数据。出现上述报错的原因有：控制文件损坏、数据文件损坏、数据文件与控制文件的SCN不一致等。数据恢复工程师对数据库文件做进一步检测分析后发现sysaux01.dbf文件有坏块。修复sysaux01.dbf文件，启动数据库依然有许多查询报错。export和data pump工具无法使用，查询告警日志并分析报错，确认发生上述错误的原因就是sysaux01.dbf文件损坏。由于

经过对底层数据的分析，数据恢复工程师发现出现故障的原因是MFT表自身的文件记录的80属性DATARUNS在操作系统自检时被截断。服务器进入系统自动进行磁盘扫描修复时，管理员强制关机并断开了存储和服务器之间的连接，导致这台存储上的文件系统损坏，报错“文件或目录损坏且无法读取”。5、数据恢复工程师通过手工分析的方式尽量将数据恢复出来。恢复完成后分区可以正常打开，恢复出来的数据量和丢失的数据量基本一致，目录结构完整。6、经过用户方的仔细检测后，确认恢复出来的数据完整有效，认可数据恢复结果。

服务器数据恢复环境：一台linux操作系统网站服务器，该服务器上部署了几十个网站，使用一块SATA硬盘。服务器故障&原因：服务器在工作过程中突然宕机。管理员尝试重新启动服务器失败，于是将服务器上的硬盘拆下检测，发现很多坏扇区。联系当地的一家数据恢复公司处理，但是没有成功。

Oracle数据库故障：机房异常断电后，Oracle数据库启库报错：“system01.dbf需要更多的恢复来保持一致性，数据库无法打开”。数据库没有备份，归档日志不连续。用户方提供了Oracle数据库的在线文件，需要恢复zxfg用户的数据。Oracle数据库恢复方案：检测数据库故障；尝试挂起并修复数据库；解析数据文件。

存储中有一组由3块SAS硬盘组建的raid。上层win server操作系统层面划分了3个分区，数据库存放在D分区，备份存放在E分区。RAID中一块硬盘的指示灯亮红色，D分区无法识别；E分区可识别，但是拷贝文件报错。管理员重启服务器，导致离线的硬盘上线开始同步数据，同步还没有完成就直接强制关机了，之后就没有动过服务器。

SQL Server附加数据库出现错误823，附加数据库失败。数据库没有备份，无法通过备份恢复数据库。SQL Server数据库出现823错误的可能原因有：数据库物理页面损坏、数据库物理页面校验值损坏导致无法识别该页面、断电或者文件系统问题导致页面丢失。

Oracle数据库故障&检测：打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性，数据库无法打开”。数据库没有备份，无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件，急需恢复zxfg用户下的数据。出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏，数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后，发现sysaux01.dbf文件

删除Oracle数据库数据一般有以下2种方式：delete、drop或truncate。下面针对这2种删除oracle数据库数据的方式探讨一下oracle数据库数据恢复方法（不考虑全库备份和利用归档日志）。

某品牌服务器中有一组由4块SAS磁盘做的RAID5磁盘阵列。该服务器操作系统为windows server，运行了一个单节点Oracle，数据存储为文件系统，无归档。该oracle数据库的数据量不大，oracle数据库内只有一个用户，使用默认的users表空间，users表空间下仅有一个数据文件。

一台光纤存储中有一组由16块硬盘组成的raid。该存储出现故障导致数据丢失。RAID中2块盘掉线，还有1块盘smart状态为“警告”。

SQL Server数据库的数据无法被读取。经过数据库数据恢复工程师的初步检测，发现SQL Server数据库文件无法被读取的原因是底层File Record被截断为0，无法找到文件开头，而且数据表结构也已经损坏。镜像文件的前几十M和中间一部分空间被覆盖，系统表损坏，所以无法读取。

然后利用“select * from 表名 as of timestamp to_timestamp('删除时间点','yyyy-mm-dd hh24:mi:ss')”语句可以找回删除的数据。利用“insert into 表名 (select * from 表名 as of timestamp to_timestamp('删除时间点','yyyy-mm-dd hh24:mi:ss'))”语句就可以将恢复出来的数据插入原表中（注意要保证主键不重复）。如果确实需要恢复删除的数据又不想空间被浪费又该如何操作呢？

服务器数据恢复环境：某市教育局同友存储，存储中有一组由数块磁盘组建的raid5阵列，存储空间划分若干lun。每个lun中有若干台虚拟机，其中有数台linux操作系统的虚拟机为重要数据。服务器故障：raid崩溃导致存储无法启动。

数据库数据恢复环境：某品牌r520服务器，服务器中有7块SAS硬盘，这7块硬盘组建了一组2盘raid1阵列和一组5盘raid5阵列，raid1阵列存储空间安装操作系统，raid5阵列存储空间存放数据。服务器上部署sql server数据库，数据库存放在C盘。数据库故障：工作人员发现服务器的C盘容量即将耗尽，于是将sql server数据库路径指向D盘，在D盘生成了一个.ndf文件。一个多星期后，sql server数据库出现故障，连接失效，无法正常附加查询。

数据库数据恢复环境：5块硬盘组建一组RAID5阵列，划分LUN供windows系统服务器使用。windows系统服务器内运行了Sql Server数据库，存储空间在操作系统层面划分了三个逻辑分区。数据库故障：数据库文件丢失，主要涉及3个数据库，数千张表。数据库文件丢失原因未知，不能确定丢失的数据库文件的存放位置。数据库文件丢失后，服务器仍处于开机状态，所幸未写入大量数据。