VxFS文件系统破坏数据恢复分析
近期接手一个怪异的数据恢复案例，基本环境是：HP-UX小型机连接HP EVA存储，从EVA上划分1TB的逻辑卷（LUN）给HP-UX小型机使用，LVM逻辑结构是一个VG中只包含1TB的物理硬盘（PV），在这个VG中划分出13个LV。
故障现象：这个小机是生产环境下使用的，某天下午3点多钟发现客户端访问不了，检查服务器，发现oracle数据库所在的文件系统全部mount不上，oracle数据库因此全部停止。由于数据库备份是半个月之前的，丢掉的十几天的数据，如果不能及时找回来，接下来的补救工作将是十分繁重的，因为这涉及到整个工厂的生产业务。
客户首先请到HP原厂资深工程师从美国进行远程分析，经过彻夜分析，发现存储本身没有问题，损坏的oravg是逻辑层的问题，从LVM深层次分析，发现LVM信息全部被破坏，唯一的办法是重构LVM信息，而且重构的前提是有oravg信息备份。运气还好，找到前一个月的VG备份信息oravg.conf.old文件，通过vgrestore命令，把VG新息还原到了出问题的PV上，最后结果，4个LV能mount上，如下：
/dev/oravg/lv102_**** Good
/dev/oravg/lvK12 Bad
/dev/oravg/lvK12_102_**** Good
/dev/oravg/lvmirrlogA Bad
/dev/oravg/lvmirrlogB Bad
/dev/oravg/lvoraarch` Bad
/dev/oravg/lvoriglogA Bad
/dev/oravg/lvoriglogB Bad
/dev/oravg/lvsapreorg Bad
/dev/oravg/lvsapdata1 Good
/dev/oravg/lvsapdata2 Good
/dev/oravg/lvsapdata3 Bad
/dev/oravg/lvsapdata4 Bad
其余9个LV没能正常mount，按照用户的说法，在这一个月时间内，这个VG内的LV没有进行过扩容或者收缩，那么这个VG信息备份文件oravg.conf.old提供的信息是正常的，不正常的就是LV上的数据了。
因为用户需要恢复的重要数据是oracle数据库，如果我能把oracle数据库表空间文件提取出来，那数据恢复就能取得成功。我们把重点工作放在/dev/oravg/lvsapdata3和/dev/oravg/lvsapdata4这两个LV上，按照oracle数据库页面特征对整个1TB的逻辑卷进行扫描收集信息，把收集到的信息进行二次整理，找出丢失掉的oracle表空间文件。分析的结果是我们在整个1TB的LUN中找到两套Oracle实例，一套实例名称 是K13，一套实例名称是K12，K13的实例保留的相对完整，K12受破坏比较严重。经过跟客户核实发现，K13数据库实例是一个月之前他们做的一个测试系统，测试完成以后，就把数据迁移到生产系统K12实例上了，然后把K13实例全部删除掉。
从收集到的oracle数据库页面分布结果看，K12数据库实例受损严重，要完整恢复几乎不可能，就算要50%恢复也不理想，所以最后就宣布数据恢复失败。
造成数据严重破坏的原因我们一直在讨论，造成破坏的现象是：数据遭受破坏地方，几乎是被符合oracle数据页面结构的数据写入的，数据写入的方式不是在文件系统环境中写入，而是跳出文件系统层面直接以dd的方式或者以oracle裸设备方式写入。就我个人角度出发，要么是恶意的数据破坏操作，用某个oracle表空间文件dd到某些文件系统；要么是oracle本身的bug，在申请数据空间的时候出现指针错误而写入错误的地方。
一下附加oravg信息：
# vgdisplay -v /dev/oravg
— Volume groups —
VG Name /dev/oravg
VG Write Access read/write
VG Status available
Max LV 2047
Cur LV 13
Open LV 13
Cur Snapshot LV 0
Max PV 2048
Cur PV 1
Act PV 1
Max PE per PV 1023975
VGDA 2
PE Size (Mbytes) 1
Unshare unit size (Kbytes) 1024
Total PE 1023975
Alloc PE 765952
Current pre-allocated PE 0
Free PE 258023
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 2.2
VG Max Size 1023975m
VG Max Extents 1023975
Cur Snapshot Capacity 0p
Max Snapshot Capacity 1023975m
—Logical volumes —
LVName /dev/oravg/lvK12
LVStatus available/syncd
LVSize (Mbytes) 20480
Current LE 20480
Allocated PE 20480
UsedPV 1
LVName /dev/oravg/lvoraarch
LVStatus available/syncd
LVSize (Mbytes) 30720
Current LE 30720
Allocated PE 30720
UsedPV 1
LVName /dev/oravg/lvmirrlogA
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvmirrlogB
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvoriglogA
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvoriglogB
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvsapreorg
LVStatus available/syncd
LVSize (Mbytes) 10240
Current LE 10240
Allocated PE 10240
UsedPV 1
LVName /dev/oravg/lvsapdata3
LVStatus available/syncd
LVSize (Mbytes) 163840
Current LE 163840
Allocated PE 163840
UsedPV 1
LV Name /dev/oravg/lvsapdata4
LVStatus available/syncd
LVSize (Mbytes) 184320
Current LE 184320
Allocated PE 184320
UsedPV 1
LVName /dev/oravg/lvsapdata1
LVStatus available/syncd
LVSize (Mbytes) 163840
Current LE 163840
Allocated PE 163840
UsedPV 1
LVName /dev/oravg/lvsapdata2
LVStatus available/syncd
LVSize (Mbytes) 163840
Current LE 163840
Allocated PE 163840
UsedPV 1
LVName /dev/oravg/lvK12_102_****
LVStatus available/syncd
LVSize (Mbytes) 10240
Current LE 10240
Allocated PE 10240
UsedPV 1
LVName /dev/oravg/lv102_****
LVStatus available/syncd
LVSize (Mbytes) 10240
Current LE 10240
Allocated PE 10240
UsedPV 1
—Physical volumes —
PVName /dev/dsk/c12t0d1
PVName /dev/dsk/c14t0d1Alternate Link
PVName /dev/dsk/c4t0d1 Alternate Link
PVName /dev/dsk/c6t0d1 Alternate Link
PVName /dev/dsk/c24t0d1 Alternate Link
PVName /dev/dsk/c26t0d1Alternate Link
PVName /dev/dsk/c20t0d1Alternate Link
PVName /dev/dsk/c22t0d1Alternate Link
PVStatus available
TotalPE 1023975
FreePE 258023
Current pre-allocated PE 0
Autoswitch On
Proactive Polling On
数据库学习，认识Sybase及其历史
Sybase SQL Server 4.0 C released in 1990.
Sybase SQL Server 4.2 C released in 1991.
Sybase SQL Server 4.8 C released in 1992.
Sybase SQL Server 4.9 C also released in 1992, along with version 4.9.1; version 4.9.2 was released in 1993.
Sybase System X, aka Sybase SQL Server 10.0 C released in 1993.
Sybase SQL Server 11.0 C released in 1995.
Adaptive Server Enterprise 11.5 C released in 1997.
Adaptive Server Enterprise 11.9 C released in 1998. It does not appear that version 11.9.0 was ever publicly released; instead 11.9.2 was the released version, and 11.9.3 was the first **** bit version made available.
Adaptive Server Enterprise 12.0 C released in 1999.
Adaptive Server Enterprise 12.5 C released in 2001.
Adaptive Server Enterprise 12.5.0.1 C released in 2002, along with version 12.5.0.2.
Adaptive Server Enterprise 12.5.0.3 C released in 2003, along with version 12.5.1.
Adaptive Server Enterprise 12.5.2 C released in 2004, along with version 12.5.3.
Adaptive Server Enterprise 12.5.3a C released in 2004/2005.
Adaptive Server Enterprise 12.5.4 C released in 2006.
Adaptive Server Enterprise 15.0 C released in 2005, along with version 12.5.3.
Adaptive Server Enterprise 15.0.1 C released in 2006.
Adaptive Server Enterprise 15.0.2 C due for release in 2007.
Release Bulletin Adaptive Server Enterprise 15.0.3 for HP-UX 2008-12-16
数据恢复高端技术梦想实现–UNIX文件系统不老的传说
从事数据恢复工作的工程师大都知道，数据恢复技术很大一部分涉及到不同的文件系统类型，比如Windows系统下，常用的有NTFS、FAT、exFAT三种类型文件系统；在LINUX系统下，常用的有Ext2/Ext3/Ext4、XFS、ReiserFS等文件系统；苹果操作系统常用的有HFS/HFS+/HFSX文件系统；常见的UNIX文件系统有UFS/UFS2、JFS/JFS2、VxFS等。在这些文件系统中，UNIX文件系统是普通电脑用户很少有机会接触到的，因为这些文件系统往往在专用的小型机上应用，而小型机是价格不菲的UINX服务器，大都部署在企业级应用上，比如金融业的银行、保险、证券等，电信行业，国家电网，国家税务等等重量级单位。UINX服务器以稳定性好、安全性好等等是诸多关键应用的有力保障。
目前世界上的UINX服务器主要以IBM、HP、Oracle（收购原先Sun Unix服务器部分）为主，都是软硬件结合的产品，除了Oracle 的 Solaris发布可安装在x86平台unix版本之外，IBM的AIX和HP的HP-UX只能在自家的硬件平台上运行，UINX学习爱好者通过VMWARE虚拟机环境还没有办法虚拟出AIX和HP-UX环境，如果想学习这两种系统，通过购买二手小型机是比较好的选择。
UNIX服务器数据恢复是一门高端数据恢复技术，虽然说UNIX服务器是稳定性、安全性很好，但由于硬件机械故障、人为失误因素等等原因，也有可能造成数据丢失的现象。不同的工程师或者不同的团队在实施项目的时候，如果漏掉一个很小的安全细节，就会成为日后文件丢失的缺口，比如备份脚本中把文件备份在同一个物理存储上，当存储崩溃，所做的备份也就随存储丢失；再比如粗心工程师执行rm命令引发的惨案等等。UNIX服务器数据恢复技术难度远远大于Windows文件系统下的数据恢复，就拿IBM AIX下的JFS/JFS2文件系统来说，它本身公开的技术资料很少，很难查阅到详细的结构信息，在我的数据恢复技术研究路程中，JFS/JFS2文件系统结构的分析花费了我大量的时间和精力。
我有幸参与了IBM的一个非常经典的案例分析，当时情况是某个证券交易系统出现异常，普通用户登录不了，经IBM工程师检查发现，/etc目录权限被更改，但是不知道如何被更改，到底是人为的还是程序BUG，证券公司要求IBM公司严查，一定要找出原因来。我到达现场以后，要求他们把主机系统设计到的LV都镜像出来，把这些LV都拿出来分析。IBM派来几路人马，要在一天之内把这个事情弄清楚。我负责的技术部分就是查出在指定的某个20分钟时间段内，有哪些文件创建、修改、删除，还有查找主机执行命令记录（现有history记录不存在的），按照这个要求，我在几个小时内把报告整理出来，交给IBM总负责这件事情的技术人员，我说我的工作已经完成了，就看你们最后的汇总了。在几个小时后，所有参与的工程师在一起听一个从美国派来工程师分析，下定结论是：程序的bug引起的。而我的分析报告中，有该程序相关文件的创建记录，别的文件没有发生异常，说明我按照他们要求提取出了有用的信息。
很多人认为IBM的工程师都能了解AIX文件系统的内部结构，其实不是这样的，无论工程师的级别多么高，除了IBM文件系统设计实验室的工程师知道以外，别的很少深入到文件系统内部详细结构这个级别。像我们第三方机构或个人想了解到这个层次，就连一些IBM工程师也认为是不可能的，但是我们做到了。我们走的是逆向分析过程，只要到一定程度，就可以一片一片揭开JFS/JFS2神秘的面纱，数据恢复技术的高深和奥妙就体现在无穷无尽的探索和研究之中。
本文由达思数据恢复总工程师覃廷良撰写，转发请注明出处:http://www.bnuol.com达思数据恢复
分享我的数据恢复经历，IBM文件系统及存储故障数据恢复
在数据恢复行业里，我算是较早的一批从事数据恢复技术服务的工程师之一，我的技术方向重点都放在软件逻辑故障数据恢复领域里，对于硬件级别修复提不起太多的兴趣。在软件逻辑故障数据恢复方向中，我的技术重点又放在了各类文件系统研究及数据库故障恢复技术。本文向大家分享我的IBM AIX JFS/JFS2文件系统及存储故障数据恢复经历，回顾近十年来我的技术成长历程。
初出茅庐篇：2004年9月份，接到宁夏某国税局一个7133阵列故障：由于突然掉电， 7133 阵列从 IBM M80 中消失，通过后台管理察看，两组阵列中每组阵列各自有两块盘被踢出阵列，强行 ONLINE 也加不回到阵列中，在 AIX 系统层面上， IBM 高级工程师判断为不可恢复的。这个案例到现在我还记忆犹新，这是我第一次接触AIX阵列故障，尤其是7133阵列，这玩艺儿销售价不菲，当时能买得起的基本上是IBM的大户，硬盘接口是SSA接口，估计现在从事数据恢复的同行也没几个人能有机会见到这样的硬盘。当时我们最强技术是RAID数据重组，我分析出这两组RAID是双循环模式，于是按照HP双循环组合方式重组，把组合好的两块目标硬盘连接到IBM 140P小型机上，尝试importvg，没能成功！IBM公司派来一个高级工程师前来协助恢复，我们折腾了一天，没有太多进展。国税局那边时间消耗不起，最后研究决定，要是在第二天上班之前，数据还没有恢复出来，就放弃恢复，启用别的方案。因为数据涉及面非常广，负责这一块的信息中心主任几乎崩溃。由于熬夜折腾的，我也坚持不住，半放弃状态回家休息，回家说是睡觉，其实也不能入眠，脑子老想着这事。到了晚上10点钟，凭感觉，我觉得这个数据是能恢复出来的，不知道是哪个环节出了问题，最大的问题可能在Raid组合上。于是我又跑回公司，继续分析，最后终于找出问题了，RAID组合是双循环，HP双循环是左异步，而7133阵列双循环是左同步，连夜更改了组合程序，最后在凌晨5点钟，把数据在小型机上mount成功，接着把oracle数据库文件通过FTP客户端下载到PC机上。上班时间到了，IBM工程师半信半疑过来看数据，经验证，数据恢复完美！由此，我开始了IBM AIX数据恢复研究之路！
深入内核(LVM)篇：记不清是什么时间了，有个案例是IBM SAN光纤存储，划分了好几个LUN，使用JFS2文件系统。故障现象是：由于LV损坏，文件系统mount不上，后来经过几路人重建了LV信息，数据还是没有找回来，最后寻求数据恢复技术支持。我当时就有一个梦想，就是写一个自己的程序，直接读取AIX JFS/JFS2文件系统，恢复其中丢失的数据，苦于没有资料没法研究。这个案例终于让我有机会深入研究AIX LVM结构，有个非常经典的帖子：http://bbs.loveunix.net/viewthread.php?tid=76187&extra=&page=1 ，记录了当时的导论过程。要知道，LVM是AIX下文件系统分区空间分配的架构，了解它，你只是了解某个LV的空间具体分配和使用情况，以及VG的一些特点，但是对于JFS/JFS2文件系统来说，了解LVM还不能深入JFS/JFS2内部。了解了LVM结构，就相当于了解Windows下分区表结构和Boot扇区结构。
天价恢复“分区表”的经历：某个上市公司的ERP系统数据库采用Oracle安装在IBM AIX下，维护工程师不小心chdev -l hdiskX -a pv=clear，在经过几轮抢修，还是没有恢复正常，最后经由赛门铁克工程师推荐找到了我，我说可以恢复，这相当于Windows下的分区表损坏，我可以修复回来，不过价钱不像windows下500-600那么便宜，这种分区表的恢复，我们的价钱是最低5万块钱，最后我只更改了不到20个字节的内容，文件系统就能正常mount上了。这就是我恢复一个天价分区表的经历。（其他内容待续）
本文由达思数据恢复总工程师覃廷良撰写，转发请注明出处:http://www.bnuol.com
苹果文件系统数据删除后数据恢复技术难度大
苹果主流文件系统是HFS/HFS+/HFSX，广泛应用于苹果硬件产品，其中包括MAC机器、IPHONE、IPAD、IPOD系列。在数据恢复业务 中，经常会碰到苹果设备的数据恢复案例，例如MAC机器误删除了数据，MAC机器分区损坏误格式化等，IPHONE、IPAD同步以后照片等资料丢 失，IPHONE、IPAD误删除文件等等，都属于苹果HFS/HFS+/HFSX文件系统级别的数据丢失，数据恢复也要从文件系统的结构特点去分析挖掘 才能得出正确的恢复方法。
HFS/HFS+/HFSX文件系统采用B+ Tree的文件目录存储结构。当创建一个文件时，操作系统就会往B+ Tree的结构中添加一个节点；当删除一个文件时，就会从B+ Tree的结构中释放一个节点。删除后释放出的节点大都会清空数据指针信息，所以要从原始节点信息去寻找删除文件的指针信息，几乎是不可能的事情。
好在HFS/HFS+/HFSX在格式化的时候可以带有日志功能，就像我写的另一篇文章“给你一个惊喜：EXT3/EXT4文件系统数据删除后的数据恢复”一样，文件系统带有日志功能，对文件的操作记录（创建、更改、删除）会在日志中保留有相关记录信息。
但 是苹果文件系统日志在记录方式上，跟EXT3/EXT4等日志文件系统采用的记录方法不一样，在EXT3/EXT4文件系统上，当删除一个文件，操作系统 先把这个文件的inode节点信息保存在日志文件中，然后才去清除原始inode的数据指针信息，这样我们从日志文件中能找到该文件删除之前的inode 完整的信息，找到inode，我们就能把文件恢复出来。在苹果文件系统中，当创建一个文件时，文件的节点信息先保存在日志里，然后再写入文件系统相应位 置；当删除一个文件时，文件系统把删除后清空的节点信息写入日志中，然后才去更新文件原始节点信息，这样一来，删除文件后，日志文件中的节点信息和文件原 始节点信息都是一样的，都是清空后的节点信息，这个节点信息对于数据恢复来说，没有任何用处！既然这样，我们讨论从日志文件恢复删除文件到底有没有可能 呢？
一切皆有可能！我在开始研究苹果文件系统的时候，也是认为不可能实现文件删除后的恢复，但是经过了几个数据恢复案例以后，我得出的结 论是：有可能恢复！我们来想想，文件的创建、修改、删除，都是往日志中记录节点信息的，在删除的这个环节上，节点信息记录的是清空数据指针后的信息，对数 据恢复没有任何帮助。但是文件系统中文件的存在，它的必经之路是“创建”，有可能还有“修改”，到最后才有可能“删除”，我们从文件的“创建”和“修改” 这两个环节中，去寻找日志中的文件节点记录信息，如果有，就能恢复出来！当然，苹果文件系统的日志文件空间分配也是有限的，当日志文件占满以后，会循环使 用该文件存储空间，如果有大量的文件操作，删除文件以后，不一定能找到它的“创建”和“修改”痕迹，这样就不好恢复，除非文件是连续存放在磁盘中，否则很 难拼接出他的原始内容。
另外，顺便提一下IPHONE的通讯录、短消息、邮件等删除后的恢复技术，对IPHONE中通讯录、短消息、邮件 等删除操作并没有涉及到文件系统成面，涉及到的关键技术是sqllite数据库，经过对sqllite数据库底层结构的完全剖析，通讯录、短消息、邮件等 删除还是可以恢复的，IPHONE经过几代的升级，通讯录、短消息、邮件的记录方式以及预留的反删除选项增加，所以IPHONE通讯录、短消息、邮件等删 除以后，只要没有太多数据写入，数据恢复可能性还是很大的。
根据以上技术分析，我们把苹果文件系统删除数据后的恢复技术集成到了D-Recovery For MAC 数据恢复软件中。想学习的朋友可以从http://www.d-recovery.org上下载。 
本文由达思数据恢复总工程师覃廷良撰写，转发请注明出处:http://www.bnuol.com
给你一个惊喜：EXT3/EXT4文件系统数据删除后的数据恢复
值得庆幸的是，Ext3/Ext4文件系统是一种日志型文件系统，当格式化分区的时候，文件系统分配一个inode号等于8的文件作为分区日志文件，Linux把它叫做Journal文件，Journal就是日志的意思。这个Journal文件的大小是格式化的时候定好的，根据整个分区总体大小来决定Journal分配空间大小，一般数值是****MB、128MB、256MB等，这个文件不会太大。
我们虽然找到了恢复的门路，但细心的人会发觉，这个Journal文件大小是固定的，它所记录的内容是有限的，如果 Journal文件存满了，它会自动释放前面的空间，循环使用，周而复始，所以Journal文件记录的永远是最新的操作记录。
我们举个例子，删除100 个文件和删除10万个文件的区别，删除100个文件时，假如只需要记录100个文件名和100个inode信息，这个Journal文件能轻松存放这些信息。删除10万个文件时，需要记录10万个文件名和10万个inode信息，这个数量这个Journal文件恐怕不能一次性保存下来，它只能循环使用它的空间，只记录最后操作删除文件的信息。从这个角度看，Ext3/Ext4文件系统数据删除以后的是否能恢复，是有条件的。
下面我们用达思数据恢复软件D-Recovery For Linux来演示一下怎样恢复Ext3/Ext4文件系统删除后的数据。
1、首先我们在VMWARE下的Linux虚拟机格式化一个10GB的硬盘,格式化成Ext3文件系统
（格式化分区，我们看到格式化过程中出现Creating journal (32768 blocks)，这个步骤就是创建journal日志文件。）
2、格式化完成以后,mount分区，往分区中写入数据
（mount格式化后的分区,mount到/mysql目录下）
（通过SSH客户端，把数据上传到/mysql挂载的文件系统下）
3、数据写入完成，umount /mysql，用D-Recovery For Linux 展开分区
（umount 文件系统）
（根目录信息）
（ucenter目录下的文件）
（我们还看到，MetaDataDir下有个$Journal文件，这就是日志文件，大小128MB）
4、删除ucenter目录，然后用D-Recovery For Linux扫描，对比结果
（删除ucenter目录）
（展开后ucenter目录不见了）
（扫描丢失文件，选择根据日志恢复）
（扫描过程）
（扫描完成以后,左边多出一个JournalRoot目录,该目录下显示出被删除的文件,这些文件就是原先ucenter目录下的文件）
小结：
Ext3/Ext4文件系统下数据删除后的恢复原理上很简单，就是根据日志文件残留inode信息来恢复，由于日志文件大小有限，不可能记录下大量文件操作过程中产生的记录。D-Recovery For Linux能应对Ext3/Ext4文件系统下少量文件删除以后的恢复，恢复方法简单易用。若是面对大量文件的删除恢复，目前还没有很好的解决方案。但是对于大文件以及oracle数据库文件的恢复，可以采用逆向推算和oracle数据文件特点来提取，也能达到很好的效果。
任何数据能恢复的前提是，这个要恢复的数据没有被新写入的数据覆盖。
本文使用的D-Recovery For Linux数据恢复工具，最新版本请从达思官网下载：http://www.d-recovery.org
本文由达思数据恢复总工程师覃廷良撰写，转发请注明出处:http://www.bnuol.com
小型机数据恢复经验杂谈
小型机习惯上用来指UNIX服务器，在服务器市场中处于中高端位置。UNIX服务器具有区别X86服务器和大型主机的特有体系结构，基本上，各厂家UNIX服务器使用自家的UNIX版本和处理器。比如IBM公司采用Power处理器和AIX操作系统，Sun公司采用SPARC处理器架构和Solaris操作系统，HP采用PA-RISC架构（现在转向于安腾处理器）和HP-UX操作系统。
小型机一般在关键的数据处理业务上使用，比如电信、银行、证券、保险、电力等行业上使用比较多，其性能稳定得到绝大多数用户的青睐。小型机也存在数据丢失的现象，在数据恢复服务中偶尔会遇到小型机用户致命数据丢失的情况，而小型机数据恢复技术往往掌握在极少数人的手里，所以用户需要支付的数据恢复服务价格往往比较高。如果能用高价恢复出小型机中丢失的数据，相对于数据完全丢失带来的损失会小很多的话，用户还是会选择数据恢复服务的。
在国内，经历小型机数据恢复案例最多的，不谦虚的讲，恐怕我国内是数一数二工程师。我现在把小型机数据丢失的几种类型总结一下：
1、磁盘阵列损坏引起的数据丢失：磁盘阵列损坏，阵列上的数据会全部丢失。需要数据恢复服务的用户，往往是在备份技术上出问题，在备份方案上把备份数据和业务数据放在同一个存储设备上，存储设备出问题，所有数据都不可读取！
2、文件系统故障引起的数据丢失：文件系统不能正常mount，或者提示各种参数错误，比如超级块、Inode、目录等等损坏引起的逻辑故障。
3、人为误删除数据、lv、vg、pv引起的数据丢失：粗心的工程师最容易犯的错误就是误删除。
以上3种情况，都是由于备份不到位或者连备份文件一起丢失造成的严重后果。出现问题最多的往往是第3种情况–认为因素造成数据丢失。
小型机存储中存放的数据大都是非常重要的数据，一旦发现数据丢失后，马上停止写入操作，数据一般都能完美恢复，但是需要高超恢复技术，因为小型机文件系统结构比较复杂，需要相当的深入研究和实践经验才能解析透文件系统。
LINUX EXT3邮件服务器数据rsync覆盖后的数据恢复
数据软硬件环境：
服务器上操作系统是RedHat，外接8块盘Raid5的盘柜，盘柜分成一个分区，文件系统是EXT3，存放着用户邮件数据，包含一千多个域名的上万人使用的商用电子邮件帐户数据。
数据丢失原因:
用户用rsync命令把一个空的文件系统远程同步到邮件服务器上,这种错误的操作导致了原先存储中的500多GB的数据只剩下了300GB,另外200GB数据在文件系统中看不见,也就是丢失了!
数据恢复方案:
数据存放在一个1.6TB的分区中,文件系统是ext3。我们把这个分区dd到一个2TB的硬盘中，经过初步扫描dd镜像出来的文件系统，发现丢失的文件一部分属于删除状态，一部分文件名已经被覆盖，要恢复的邮件数量上几万封。对于ext3文件系统，一旦删除了千万级数量的文件，数据恢复的时候想保留完整的目录结构几乎是不可能的，所以数据恢复结果不会考虑目录结构的问题。
经过几经导论，我们把所有丢失掉的邮件一封一封恢复出来，最后用程序按照域名、用户名、收件人、发件人的分类方法，把邮件按照一定的目录结构重新整理出来，得出的数据再跟邮件系统进行内容帐户匹配，最终比较完美的还原出丢失的邮件。
附：rsync工具介绍
rsync(remote sync)，顾名思义，就是远程同步工具，利用它可以将服务器A上面的数据同步到服务器B上面，特别是对于小文件传输的效果很好，所以有很多人用它做增量备份，如mysql日志文件的增量备份。
它的特性如下：
1、可以更新整个目录树和文件系统；
2、可以保留文件的软链接、硬链接、权限信息、属主信息、设备和时间信息；
3、无须特殊权限即可安装；
4、内部的流水线提高了多文件传输的速度；
5、可以使用ssh、rsh或者socket链接进行传输；
6、支持匿名传输
本文出自达思(http://www.dstfix.cn)工程师覃廷良blog
数据“被”覆盖有假象，SQL数据库恢复终极绝招（数据恢复高级技术）
很多数据恢复工程师包括一些数据恢复技术爱好者经常会问同样一个问题：“数据一旦被覆盖了，还能不能恢复呀？我听说国外能恢复被覆盖以后的数据，据说只要是覆盖操作在7次以内，都能恢复出来，国内有没有这种技术呀？”这种问题困惑很多人，也困惑很多年，到现在也只是停留在传说阶段，没有人能够证实！市面上有一些数据擦除工具，在进行数据毁灭擦除的时候往往有一个选项：擦除1遍？擦除3遍？擦除7遍？我在怀疑是不是一种心理作用。在我目前认知的数据恢复技术领域，我坚决的认为：只要覆盖一遍，数据就不可恢复！如果说能恢复，那已经超出目前世界商业数据恢复技术领域，可能是个传说吧。
本文的重点是要揭开数据覆盖假象问题，并不讨论数据被覆盖以后的恢复技术。所谓的“数据覆盖假象”，就是数据丢失或者被破坏以后，数据恢复工程师没能恢复出用户需要的文件，就主观的认为数据“被”覆盖了，其实丢失的数据“尸体”可能完整的躺在硬盘中，或者以支离破碎的“尸体”碎片散落在硬盘的多个位置上。真正的数据恢复高级技术，就是把数据“尸体”从硬盘中捞出来，运气好的话，一个丢失的文件数据“尸体”连续存放在硬盘中，恢复就较为简单。如果数据分成多段存放在硬盘中，数据恢复工程师就得把所有的数据段（数据碎片）捞出来，然后进行拼接，最终化腐朽为神奇，还原出丢失的数据完整的“尸体”，再进行文件内容确认，数据恢复就基本结束。
我们以一个实际的数据恢复案例来讲解：
实际环境：
在Windows 2003 Server操作系统下，采用NTFS分区类型，装了一个MS SQL Server 2005数据库，一共有10个数据库在用，其中有一个数据名称是xiangmu01，对应两个物理文件xiangmu01.mdf和xiangmu01.ldf，这个数据库使用有两年多时间，xiangmu01.mdf大小有18GB，xiangmu01.ldf大小有30GB，存放路径为d:database。
数据丢失过程：
某个粗心的工程师在使用服务器时，从MS SQL Server企业管理器中创建了一个新的数据库，名称为xiangmu001，创建时使用默认存储路径，默认路径把数据库xiangmu001的物理文件创建在了C盘的MS SQL Server安装路径上，他及时发现，想把数据xiangmu001删除了，重新创建，把物理文件存放到d:database下，灾难就在这一步降临，错误的把xiangmu01数据库删除了，然后再创建xiangmu001数据库，把物理文件路径更改成d:database，企业管理器出现提示“该数据库名称已经存在”，停下来检查，脑袋嗡的一声“删错了数据库！”。
这个时候工程师想的第一件事就是找备份来还原！！！！于是在E盘中找到xiangmu01.bak文件，还记得核准时间，又一阵心慌意乱，这个备份是半年前的，检查一下这个库的备份脚本，早在半年前不起用了，不知道什么原因。于是又做了一个大胆的操作–“还原这个备份文件”。
他还原的步骤是，先创建xiangmu01数据库，物理文件名称和路径跟原来数据库一样，于是在d:database下由于删除xiangmu01数据库丢失掉的两个物理文件xiangmu01.mdf和xiangmu01.ldf，又出现在d:database目录下，按照数据恢复行业词汇就是“同名覆盖”。创建好了新的xiangmu01数据库，就用xiangmu01.bak来还原，祸不单行，这个xiangmu01.bak文件是坏的，还原不了。到了这里，瞒也瞒不住，上报领导，挽救数据！！
数据恢复是否有可能：
我们先不评价数据丢失过程怎样的XXX，就这个案例而言，数据恢复成功的可能性到底有没有？？根据不同的数据恢复公司，接到这样的数据恢复案例，会有如下3种处理情况：
1、直接认为要恢复的数据发生了“同名覆盖”，起码数据库文件头部被破坏，不可恢复！
2、会按照数据库mdf文件类型对整个分区进行扫描，提取出若干个mdf文件，挨个去验证，看看有没有好的，（这种恢复方式几乎不能成功），最后宣告恢复失败！
3、尝试按照MS SQL Server数据库页面碎片对整个分区进行扫描，因为数据库比较多，数据库页面碎片个数非常多，如果再加上对NTFS文件系统结构的熟悉了解，在扫描数据库页面碎片的时候，排除掉当前分区中正常存在的mdf文件的页面信息，单独提取硬盘分区NTFS文件系统中正常情况下不存放数据区域的数据库页面碎片，就是丢失掉的或者以前曾经存放过的mdf文件内容。通俗的讲，就是该分区被认为空闲的、可用的那部分空间中，就是我们丢失的数据所在的地方。提取出被遗失的所有数据库碎片页面，然后按照一定规律来拼接，最终还原出删除的mdf文件。
数据库碎片页面的概念：
数据库文件在设计的时候都是按照一定的有规律的形式来存放的，数据库文件内部结构相当于一个小型的文件系统，我们了解NTFS文件系统，它有“簇”的概念，就是文件存放分配的最小单元。在数据库文件里头，有Page即“数据页”的概念，就是数据库文件结构按照一页一页存放，每一个页面占用16sec或者32sec或者别的更大点的数，对于MS SQL Server来说，每一页的大小有16sec，每个数据页有自己的页面编号等信息，每个页面有自己的校验方式等等，我们在提取数据库页面的时候，就根据这些规律来的。当把所有数据库页面碎片提取出来以后，怎样把这些页面拼接成一个文件，又是一门数据恢复艺术！
数据恢复结果：
本案例在达思数据恢复公司最终成功恢复，达思D-Recovery For MS SQL Server数据库恢复软件是在软件研发人员耗费大量时间和精力出品的的国内少有的MS SQL Server数据库恢复软件。在数据库恢复技术领域，往往能化腐朽为神奇！
首先，它有数据库碎片提取功能，有一定的碎片智能组合功能，如果某条组合线路出现分叉，可以人工查看，确定正确的组合线路，最终能把mdf文件相对完整的拼接出来。
其次，它可以直接读取mdf文件内容，如果有某些数据页面被覆盖或者被破坏，它可以绕过这些坏页面，把mdf文件中正常的数据记录提取出来，然后进行数据还原。在mdf文件局部损坏的情况下，MS SQL Server环境没有办法修复mdf文件，没办法读取mdf文件中的数据，这时候D-Recovery For MS SQL Server就发挥它强大的数据库内容提取功能！
揭开数据覆盖假象：
对本案例而言，出现了同名文件覆盖的现象，大多数人都认为是数据被覆盖了！在NTFS文件系统中，同名覆盖，往往意味着原先文件MFT表项和后面覆盖过来的文件的MFT表项是同一个，MFT表项ID号（如果有ID号）不会更改，更改的只是MFT表项内部的数据指针！这样通过任何数据恢复工具扫描，不会找出原始文件MFT内部数据指针，找到的都是新覆盖的文件的MFT表项信息。
数据区会不会也被新文件覆盖呢？答案是不一定！Windows操作系统在分配新覆盖过来的文件空间的时候，有可能会按照旧文件的指针分配，有可能分配新的数据空间，这就看Windows NTFS 文件系统文件空间分配机制了！如果说，新文件分配新空间，跟原始文件空间不发生重叠，那原始文件内容将不会受影响！
为什么按照mdf文件类型来恢复，没能找出正确的文件？数据库文件xiangmu01.mdf已经使用了两年多，数据库在创建的时候，数据库文件根据需要分配空间，而不是一开始就分配很大的空间，所以在以后使用过程中，空间分配分散很严重，在硬盘上不可能连续存放！按照类型扫描恢复文件大都基于数据文件连续存放，否则恢复出来的文件只正确包含文件地一段数据信息！
小结：
数据覆盖不是想当然，要经过最底层的分析，才能得出正确的恢复方法！
本文首发于达思硬盘数据恢复公司，作者：达思总工覃廷良，转载请注明出处http://www.bnuol.com
西门子6块盘HP服务器RAID数据恢复成功案例
2011年9月2日，达思数据恢复中心接到了西门子（中国）有限公司SIS部门的咨询电话，大概情况是早上客户端用户反映有一组6块盘的阵列数据无法访问，网管人员进行排查后发现该阵列柜中1号、5号盘亮黄灯提示报警，重启阵列无效。随后阵列柜售后服务商上门检测，初步判断是硬盘硬件故障引起，承诺可以更换磁盘，但无法解决数据恢复的难题。
由于数据的重要性，SIS部门很快与我中心取得了联系，就数据灾难现场的状态做了一个大致的沟通，并在数据恢复工程师的指导下切断了电源，避免因误操作而造成二次破坏的可能，保证现场的完整性。达思凯瑞技术（北京）有限公司，作为西门子（中国）指定的数据恢复服务提供商，第一时间响应并安排高级工程师赴现场查看情况，检测故障出现的根源，并根据实际情况迅速制定出数据抢救方案。
（本文先发表于达思数据恢复网站:http://www.bnuol.com,转载请注明）
该阵列由6块成员盘组成，硬盘型号为富士通MBD2300RC，单盘容量300G，SAS接口。为了保证数据的安全性，我们选择将6块成员盘的镜像文件给做出来，然后再对镜像文件进行分析及数据的重组工作，规避对原盘进行任何可能的写操作。由于1、5号盘存在硬件故障，所以数据恢复的关键就在如何做出这两块盘的镜像文件。
在达思数据专家的努力下，不到4个小时就成功的将1号故障盘的镜像文件完整做出来，但5号盘损坏比较严重，有一个磁头损坏，镜像不是特别完整。针对此种情况，达思专家优先分析了已做磁盘镜像文件的底层结构，判断出该阵列是一个RAID5级别的组合，根据RAID5阵列组合的结构特点，选择了缺5号盘重组数据的方案，也就是说利用数据冗余的特点，通过剩余5块盘的数据推算出5号盘磁盘上的数据。
数据重组完成后，将虚拟的阵列组合完整的镜像到一块大容量磁盘上，客户三个分区数据完整展现，目录结构跟数据丢失之前完全一致，SQL2005数据库附加成功，数据验证成功。
D-Recovery For RAID 数据恢复软件界面