|
ESX SERVER文件系统(VMFS)恢复方案浏览数:4325次
故障类型: 基于ESX SERVER的常见数据丢失。 典型特征: 1. 因光纤存储设备连接至非ESX环境,共享未互斥,对存储改写(重新系统,WINDOWS初始化,格式化等),导致存储结构损坏; 2. 卷升级、变更时分区表或VMFS卷结构异常; 3. VMFS存储中误删除虚拟机/文件; 4. 误删除/重建数据存储。 恢复方案 检测流程 1. 检测是否存在硬件故障,如硬件故障,先解决硬件故障; 2. 以只读方式检测故障表现,并参考客户对故障的描述。 恢复流程 1. 以只读方式对故障存储做完整镜像备份,只对镜像盘操作,保证原盘数据不被破坏; 2. 在备份中进行数据分析及恢复操作:按分区表结构、VMFS结构(节点区、索引区、目录及数据区)的顺序依次分析数据损坏情况,并针对性地做重组恢复; 3. 恢复后的数据会暂存在另一个安全的存储,避免对原数据的覆盖。 验收流程 1. 对已恢复数据做容量及数量统计,是否与数据丢失前吻合; 2. 对已恢复的数据做完整性验证,确保节点区及底层逻辑等方面正确无误; 3. 对客户指定的关键文件进行重点验证,确保客户关键数据成功恢复。 恢复的成功率 1. 针对非ESX服务器对VMFS改写的情况 这类改写实际上要考虑对VMFS的破坏情况,如果仅仅是WINDOWS初始化、划分分区或文件系统格式化(未写入数据文件)数据破坏不严重,恢复可能性较高。如果破坏严重,如整个VMFS前100MB完全覆盖,数据恢复的难度将非常之大,如果是有结构的数据,如ORACLE或SQL SERVER数据库,可以通过文件系统内部关系进行恢复,但像RAR、多媒体文件等将很难恢复。 2. 针对卷升级、变更时分区表或VMFS卷结构异常 通常此类突发性故障对数据的损坏程度不高,恢复的可能性较高。恢复的可能性主要取决于节点区、索引区、目录及数据区是否被破坏(通常VMFS前500M很关键)。 3. 针对VMDK误删除 VMFS删除VMDK后,如果没有新数据写入,数据依然存储于VMFS中,但存储本身却不会再保留指向数据区的索引信息。这时候,需要对原VMDK文件内部结构进行分析, 才可以确定数据恢复的算法及可靠性。如同VMFS破坏严重的情况,如果VMDK内部存储的是像数据库文件一样的规则文件,可恢复性将很高,否则,就需要仔细地发现和整理数据恢复的算法了,有些时候,数据可能无法在有效时间内恢复成功。 数据安全科普 1. 典型的光纤存储分配错误是遇到最多的ESX上的数据故障,因VMFS的CLUSTER是基于几台ESX SERVER之间的约定,故而当存储被非ESX系统接管时,便会以独占的模式进行管理,这会导致存储结构的损坏。 2. 针对软件故障,在数据丢失后,应尽可能减小对存储的操作,有时候,即使是开着机,什么也不做,也可能导致灾难进一步加剧,条件允许的话,最好损坏后,对磁盘或存储卷做完整备份。 3. 针对硬盘故障,在设备无法正常工作后,应尽可能少的加电,以避免设备的进一步损坏。 4. 做好备份方案,尽可能避免单存储备份,如数据非常重要,可考虑异地备份。 选择服务商的标准 数据恢复有别于一般维修行业,目前市场鱼龙混杂,不同服务商的技术水平和职业素质千差万别,数据丢失后交由非专业人员进行各种检测与恢复操作造成盘片划伤、数据完全覆盖,最终数据无法恢复的情况常有发生,用户从寻找低价到不惜代价拯救数据的例子比比皆是。因此,恢复重要数据必须寻求专业、正规的数据恢复公司帮助,切勿贪图便宜造成无法挽回的损失。是否专业考量的因素有: 设备,拥有独立的无尘洁净间,保证开盘操作在百级无尘的洁净环境下进行,市场上很多数据恢复公司都表示有无尘洁净室,但事实上能让客户亲眼所见的只是凤毛麟角,寥寥可数。 技术,就像病重的人手术一样,资深数据恢复工程师对硬件和逻辑结构均有丰富经验,能果断准确地判定该如何抢救数据,机会可能只有一次,有时一次的误操作足以让数据返魂乏术。 效率,一般情况下普通故障当天能完成,即使开盘恢复也只1-3天,需要一段时间才能完成的极有可能是中间商,即接单后转给第三方赚取差价,成功率与数据安全毫无保障。 |