 |
一、误操作类
误删除、误格式化、误分区、误克隆等；
二、破坏类
病毒分区表破坏、病毒FAT、BOOT区破坏、病毒引起的部
分DATA区破坏；
三、软件破坏类
Format、 Fdisk、 IBM-DM、PartitionMagic、 Ghost等(注！冲零或低级格式化后的硬盘将无法修复数据）；
四、硬件故障类
0磁道损坏、硬盘逻辑锁、操作时断电、硬盘芯片烧毁、软盘/光盘/硬盘无法读盘；磁盘阵列崩溃,数据库损坏
五、加密解密
Zip、 Rar、 Office文档、windows2000/XP系统密码。
六、数据修复时间： 软件故障数据恢复 1~5小时 硬件故障数据恢复 1天~2天 硬盘开盘数据恢复 1天~3天 服务器数据恢复2小时~3天 RAID0数据恢复 2小时~3天 RAID5数据恢复 2小时~3天 磁盘阵列柜数据恢复 2小时~3天
|
 |
|
 |
|
|
 |
 |
| 文件系统基础知识（二）-亿嘉湖南数据恢复基础《八》 | | 出处：ChinaUnix.net 加入时间：2007-04-03 | <P><SPAN style="FONT-SIZE: 13px"><FONT color=darkred> 中科院计算所研究的“曙光”系列机群服务器上的文件系统COSMOS[22]和DCFS [23]，为曙光超级服务器提供了一个分布式的文件系统环境。为了获得较好的I/O性能，DCFS机群文件系统中的元数据服务器采用二级的树状结构、文件属性缓存、集中式目录缓存管理等技术，存储服务器主要采用了多线程和缓存技术。DCFS将整个名字空间根据目录关系划分成多个子空间，分配到不同的元数据服务器管理，取得较好的性能、扩展性和可用性。 </FONT></SPAN></P>
<P><SPAN style="FONT-SIZE: 13px"><FONT color=darkred> 从以上的分析中我们可以看出，最初远程文件访问和共享的需求，促使了NFS、AFS的出现；NFS结构中单个服务器在容量和性能方面的限制，使得使用多个储衿鹘峁沟姆植际轿募低吵鱿至耍蹦芄辉诟蠓段У墓阌蛲隙季哂泻芎美┱剐缘南低骋渤鱿至恕Ｖ螅孀磐缂际鹾痛排碳际醯姆⒄梗植际轿募低秤纸玈AN、对象磁盘等先进技术引进来，出现了基于SAN的分布式文件系统和基于对象存储的分布式文件系统。整个分布式文件系统中单个节点和整体的聚集速度在快速地增加。 </FONT></SPAN></P>
<P><SPAN style="FONT-SIZE: 13px"><FONT color=#8b0000> <SPAN style="FONT-SIZE: 13px"><FONT color=darkblue>分布式文件系统的体系结构在多年来经历了多次变化。这其中有软硬件技术发展的作用，也有应用需求变化的因素。下面我们根据不同的标准分析一下多年来分布式文件系统设计和实现过的主要的体系结构。 <BR>3.1 数据访问方式——带内模式和带外模式<BR> 在传统的分布式文件系统中，所有的数据和元数据都存放在一起，通过服务器提供。这种模式一般称之为带内模式（in-band mode）。随着客户端数目的增加，服务器就会成为整个系统的瓶颈。因为系统所有的数据传输和元数据处理都要通过服务器，不仅单个服务器的处理能力有限，存储能力受到磁盘容量的限制，吞吐能力也受到磁盘I/O 和网络I/O 的限制。 <BR> 于是一种新的分布式文件系统的结构出现了，那就是利用SAN技术，将应用服务器直接和存储设备相连接，大大提高数据的传输能力，减少数据传输的延时。在这样的结构里，所有的应用服务器都可以直接访问存储在SAN中的数据，而只有关于文件信息的元数据才经过元数据服务器处理提供，减少了数据传输的中间环节，提高了传输效率，减轻了元数据服务器的负载。每个元数据服务器可以向更多的应用服务器提供文件系统元数据服务。这种模式一般称之为带外模式（out-of-band mode）。最近的Storage Tank、CXFS、Lustre、BWFS等都采用这样的结构，因此它们可以取得更好的性能和扩展性。区分带内模式和带外模式的主要依据是关于文件系统元数据操作的控制信息是否和文件数据一起，都通过服务器转发传送。前者需要服务器转发，后者直接访问。 <BR>3.2 系统服务器的方式<BR> 分布式文件系统结构上有两种大的方式：一种是专用服务器结构（Dedicated Server）， 另外一种是无服务器结构（Serverless）[24]。<BR>Serverless 方式指系统中没有专用的系统服务器，所有的用户服务器都被当作系统服务器来使用。基于这种系统结构，所有的用户服务器都既是存储系统的系统服务器，又是存储系统的用户服务器。此时，一个用户服务器不仅要处理本系统的数据需求，而且，还要服务于其它系统的数据请求。这样的系统包括xFS、CFS/Veritas[52]和Fragipani。这种系统结构可以提供很高的性能上的可扩展性，但系统非常复杂，而且造成系统的管理困难。 <BR> 此外，由于有多个系统服务器，数据的一致性变为了一个重要的问题。例如，为了解决已知性问题，xFS使用哈希方式来寻找文件所在的服务器，而CFS则使用对于每个文件实行一主多从及令牌的办法。 <BR>Dedicated Server 方式采取专用服务器（群）。主要有以下几种形式：<BR>单个系统服务器，NFS over NASD/CMU 和Transoft File System/HP 就属于这种情况。由于只有一个系统服务器，数据的一致性问题得到很大的缓解，但其可扩展性受到很大限制。<BR> 多个系统服务器，SFS、GPFS、StorageTank、Lustre、BWFS和Tiger Shark 就属于这种情况。这种系统一般具有较好的可扩展性，但由于多个系统服务器的原因，数据一致性很难处理。在SFS中，一个文件只能由一个系统服务器来服务。文件到其相应的服务器的映射是由一个静态Hash函数完成的。由于一个文件只能映射到一个服务器，文件访问的同步及数据的一致性都可以得到较好地解决，而静态映射难以达到好的负载平衡效果。 <BR> 在Lustre、CXFS的实现中，在某一时刻只有一个活动的提供元数据服务的文件系统服务器。在Storage Tank 中，管理员根据文件目录结构将整个名字空间划分成多个文件集合（file set）。在某个特定的时刻，任何一个文件集合只能被映射到元数据服务器机群中的某一个，由它提供元数据管理服务。 <BR>3.3 文件与系统服务器的映射<BR>文件映射对于数据一致性有着相当的影响。文件到其相关的系统服务器的映射可分为两种： <BR> 单一映射，在任意时刻，一个文件最多只能映射到一个系统服务器。这种映射可以大大简化数据的一致性问题，这是由于每个文件只由一个系统服务器负责。当需对文件进行锁或契约操作时，这些操作都只限于相关的某一个服务器，而不是分布式的操作。但它也带来了几个复杂的问题，其中最重要的就是可扩展性问题。当采取单一映射时，对于一个文件而言，存储系统所能支持的访问是被相关的单一系统服务器的性能所限制。Lustre、StorageTank、BWFS均采用单一映射的方式。 <BR> 多维映射，在任意时刻，一个文件可以映射到多个系统服务器。这种映射会增加简化数据的一致性问题的复杂性。这是由于每个文件是由多个系统服务器负责。当需对文件进行锁或契约操作时，这些操作都必须通过所有相关的服务器协调。这样的操作就变成了分布式的操作，从而增加了系统的复杂度。但多维映射可以提供更高的系统可扩展性。 <BR>3.4 有状态和无状态<BR> 应用程序调用文件系统的接口，实现对数据的存取和管理。用户的每一次访问，都是对多个文件系统接口多次调用的结果。应用程序对文件系统接口的调用，是有顺序，有前后关系的。这些调用一般以open开始，close结束，构成一次会话（session）。应用程序调用open以后，获得一个打开文件的句柄（handle），关于文件的所有信息，都有文件系统（操作系统的一部分）记录。 <BR> 在分布式文件系统中，根据打开文件的状态由谁记录可以分为有状态的（stateful）分布式文件系统和无状态的（stateless）分布式文件系统。在有状态的分布式文件系统中，元数据服务器跟踪每一个打开的文件，记录文件的操作信息，比如当前的读写指针，当前的文件锁等信息。在无状态的分布式文件系统中，元数据服务器不记录任何打开文件的信息，包括读写指针和文件锁等信息。NFS本身是属于无状态的分布式文件系统，当然它有一个分开的锁管理程序来处理关于文件锁信息。最新的NFS第四版本加入了基于会话的语义，服务器需要记录一定的状态信息。有状态的和无状态的模式各有优缺点：由于前者不需要在每次进行通信时由客户机将状态信息带到服务器上，因此可以减少通信的数据量和通信次数，服务器也可以更好地进行客户机之间的协调；而后者则具有更好的可用性和失效恢复，因为文件的状态都记录在客户机，某个客户机的失效不影响其他客户机的操作。服务器的失效重启以后，服务器不需要进行很多的修复，客户机可以重做刚才的操作，快速恢复。 </FONT></SPAN></FONT></SPAN></P> | | 返回列表 | | | 上一篇： | | 下一篇： |  打印此页  关闭此页 |
|
|
|
