分布式存储恢复hbase和hive数据库报告

分布式存储数据恢复设备清单及基本描述

初检方案及过程

数据恢复初检方式：根据与客户电话沟通及现场检测，按故障表现，作如下判断：

故障表现：客户共配置16台服务器节点，在每台物理服务器上，有大约3台左右的虚拟机，在虚拟机上配置的分布式，上层部署的hbase数据库和hive数据库，数据库底层文件删除，导致数据库不能使用，需要进行存储数据恢复。

恢复概率预判：

经过现场对客户环境的简单检测，虚拟机还可以正常启动，虚拟机里面的数据库块文件有丢失，块文件丢失之后，没有对整个集群环境在进行数据的写入，底层的数据损坏可能性会比较小。

综上所述，由于在删除之后，没有在继续写入数据，具有较大的可恢复性，但是由于现阶段还没有对底层结构进行分析，再加上hbase和hive的算法和底层结构十分复杂，具体的恢复概率无法判断，还需在之后具体的恢复过程中才可以知晓。

分布式存储数据恢复服务流程

1、前期备份流程

  A、从物理服务器底层做备份，将原存储设备断电、关机。

  B、从虚拟机层面备份，通过网络直接备份虚拟机底层磁盘文件。

  C、准备一台恢复操作服务器（北亚提供），在恢复平台上以只读方式挂载服务器硬盘，使用北亚磁盘备份工具(或 dd等工具)进行完整的扇区对扇区的备份。

  D、备份完成后，提供详细报告，涉及威信的健康状态及可能存在的坏道列表。

  E、将服务器硬盘交回给用户(建议原样恢复)，之后不再直接操作原介质。

2、块文件结构分析

  A、对每个虚拟机磁盘的块文件进行分析；

  B、分析文件底层的聚合方式；

  C、分析每个磁盘中数据的分布情况；

3、Block文件key分析

  A、定位数据库文件中的key信息；

  B、提取并解析数据库文件中key信息；

  C、整合数据库文件key信息。

4、Block文件拼接

  A、根据Block文件的key信息提取文件片段；

  B、对Block文件的片段进行拼接；

  C、校验拼接后的Block文件的正确性。

 5、Block文件导入

  A、校验提取出的Block文件完整性及正确性；

  B、把提取出来的Block文件导入到hbase和hive数据库中；

6、数据验证

  A、由用户主导对数据本身进行详细验证。

  B、如发现新问题，重新检验上述所有恢复过程。

数据恢复服务承诺 

1、整个过程不会对客户的原盘有任何的写操作，以确保原盘的数据安全

2、尽可能保证服务的操作可逆，确保人力可控范围内操作可回溯。

3、提供后期数据保管和服务跟踪。

4、以上所有操作在有备份的情况下进行，若不成功不影响其他方案继续。

数据恢复周期预估

说明：总时间控制在20个工作日，上表中的时间只是预估，以实际情况为准。

分布式存储数据恢复成功率预估

数据安全救援的可靠度应超过 80%。参考：2020年全年企业级数据安全救援的成功率为 84.3%。因不存在同步及基本可排除的硬件故障。 

虚拟服务器数据恢复案例_raid阵列恢复案例

一.服务器数据丢失过程介绍

需要进行数据恢复的服务器是一台由16块硬盘组成的raid6磁盘阵列。由于磁盘阵列中有一块硬盘因为物理故障掉线，导致服务器上层虚拟机无法正常使用，部分分区丢失，管理员重启物理服务器后发现上层数据依然不在，需要通过服务器底层数据进行数据恢复。

二.北亚数据恢复工程师初检服务器

北亚数据恢复工程师对服务器上层数据进行检测发现由于硬盘突然掉线导致了上层虚拟机文件系统被破坏，想要恢复数据可以通过拼接文件碎片的方式进行。

三.虚拟服务器数据恢复结果

按照数据恢复工程师初检是判定的数据恢复思路，需要对服务内现有的文件碎片进行拼接。拼接原理为通过fbb源文件的位图信息中的512M位图信息进行拼接，但通常情况下服务器上层虚拟机损坏的元文件指针类型不同会导致指向的数据索引位置也不同，现在虚拟机的元文件已经损坏，通过服务器现有数据是无法确认指针类型是哪种指向的。如果指针指向的位置不是fbb元文件区域，则此方法将无法恢复数据。

因此只能通过逆向验证的方法假设上层虚拟机的损坏元文件指针确实指向fbb中的512M位图，按照这一思路直接对服务器底层数据进行扫描和拼接。在拼接过程中不断进行数据检验。

在数据拼接时发现了两个目录，经过数据验证发现这两个目录十分相似，判断其中一个目录里为备份数据。于是工程师详细对比了目录一与目录二中的目录、文件、底层数据，两个目录中的数据完全一致，确认其中之一为备份数据，因此只需恢复这两个目录中的任意一个数据即可完整恢复数据了。

数据恢复工程师对目录一进行继续拼接后发现文件系统被严重破坏，所有的文件都无法正常打开和使用，没办法只能对目录二进行拼接和恢复。数据恢复工程师对目录二中的数据进行了拼接恢复，经过验证发现大部分文件可以正常使用。

服务器数据恢复工程师继续对不完整的数据部分进行提取、拼接、手动修复，成功恢复了服务器内的所有数据，经客户工程师亲自对数据进行验证，服务器上层虚拟机可以正常使用，数据完整，本次数据恢复成功。

Lustre分布式文件系统数据恢复案例

服务器数据恢复环境：

5台服务器节点，每台服务器节点配置一组RAID5，每组6块硬盘，其中1块设置为热备盘。

系统环境为Lustre分布式文件系统，5台服务器共同存储全部的数据文件。

服务器故障&检测：

机房漏水导致服务器进水，服务器中的部分硬盘损坏。每组服务器有2块及以上的盘掉线。由于短时间同时掉线2块及以上硬盘导致RAID5崩溃，服务器,数据无法正常读取。

服务器数据恢复过程：

1、为避免对原盘数据造成二次破坏，使用工具对故障服务器中所有正常硬盘进行镜像备份。后续操作全部基于镜像完成。

2、通过更换磁头、修复固件等方式修复无法读取的故障硬盘，并镜像故障硬盘中的数据。

3、北亚数据恢复工程师通过分析磁盘中数据规律获取到RAID校验形式、条带大小、盘序等RAID相关信息，并根据这些RAID信息虚拟重组出所有RAID整列。

4、解析Lustre分布式文件系统。

Lustre分布式系统由元数据卷（MDS）和数据卷（OST）组成，重组RAID后就可以看到MDS分区和OST分区。Lustre文件系统中所有文件的文件名、文件路径等属性信息存放在MDS分区，而文件对应的数据内容全部存放在OST分区中。

MDS分区是一个EXT3文件系统，除了节点类型为文件的解析方式有所变化外，其余所有解析方式和Ext3一样。

从MDS中获取到整个Lustre中所有文件的目录结构，文件名称，文件编号，所属OST号等属性信息。

根据从MDS中获取到的目录结构，文件名称，文件编号，所属OST号等属性信息，北亚数据恢复工程师整理重构出文件的原始路径，并定位到索引的OST卷及相关数据区域，获取相关数据文件。

5、通过万兆网络将恢复出的所有数据拷贝到用户准备好的设备环境中。

服务器数据恢复结果：

用户亲自检查恢复出来的数据，确认数据文件基本全部恢复出来，随机抽取部分文件进行校验，文件正确无误，目录结构完好。本次数据恢复完成。

服务器SQL server数据库被加密恢复方案

一、服务器数据库基本情况介绍

客户一台服务器上的数据库被病毒加密无法使用，数据库是SQL server数据库2008R2，服务器上有多个数据库，其中2个数据库及备份文件被加密，文件名发生变化，数据库无法使用，需要对服务器上的数据库进行数据恢复。经过初步沟通后北亚数据恢复中心安排工程师前往客户现场进行数据恢复。

二、备份客户服务器内的所有数据

北亚数据恢复中心的工程师前往客户现场后对数据库进行了初步检测后，为避免数据恢复操作过程中对服务器原始数据造成破坏，首先对客户的服务器进行了安全的数据备份，将客户服务器上的所有数据备份到北亚数据恢复存储池中。接下来的数据分析、数据恢复操作将全部在北亚数据恢复存储池中进行，不会对客户原始数据造成任何破坏，即使无法恢复客户数据也不会导致客户的原始数据环境发生变化。在保障原始服务器环境的条件下进行数据恢复。   

三、数据库加密分析及数据恢复方案

借助一款专用的数据恢复软件winhex打开客户的SQLserver数据库，查看数据库底层数据是否被破坏，经过查看发现数据库底层数据中的头部信息被破坏。

2、根据数据库底层数据分部规律分析查找病毒的加密方式，经过分析发现该数据库页为8K，将底层数据按8K切块并向下查找分析加密方式，经过分析发现病毒采用的是每隔128k进行一次大小为125字节的加密。

3、继续对数据库备份文件底层数据进行分析，发现加密规律通数据库部分的加密规律完全相同。

SqlServer数据库起始页标志为01 0F，数据恢复工程师在底层检索数据库页的起始标志，经过检索发现数据库备份的头部记录并没有被破坏，原来数据库备份的头部记录了数据库的备份信息，数据库页的起始位置发生了向下偏移，这就导致了数据库中的加密位置和数据库备份数据中的加密位置刚好错开，因此数据库备份中的起始标志未被破坏。

4、由于数据库加密位置与数据库的备份文件加密位置刚好错开，因此可以结合数据库备份文件对数据库中的加密页进行数据修复，数据恢复工程师通过数据库管理工具将修复好的数据库进行附加检查，通过检查验证，数据库可以正常使用。经过客户工程司亲自对恢复的数据进行验证，确认数据库内的所有数据完整，本次数据恢复圆满成功。

RAID5常见故障介绍及raid5故障后常规操作方法

一、raid5常见故障介绍

1. 服务器硬件出现故障或者RAID阵列卡故障；

2. 服务器意外断电导致磁盘阵列故障；

3. 服务器阵列上的磁盘出现物理故障，如：电路板坏、磁头损坏、盘面坏、坏扇区、固件坏等；

4. 管理员在维护服务器过程中由于误操作导致硬盘盘序出现错误；

5. raid在同步数据或者重建过程中，同组raid阵列中有其他硬盘掉线导致同步失败；

6. 配置raid阵列信息出错等误操作导致数据丢失。

二、RAID5磁盘阵列故障后需要注意哪些问题

1. RAID5磁盘阵列出现故障或者数据丢失后建议不要盲目进行rebuild操作。

Rebuild操作就是利用阵列的校验功能，根据阵列内其他正常硬盘内的数据，将损坏硬盘的数据进行计算生成并同步到热备盘中。这种操作适合阵列中有1块硬盘掉线的情况，一旦阵列中有2块硬盘出现故障掉线了，则通常掉线顺序有先有后，如果在第一块硬盘掉线后服务器已经进行过写入操作的话，此时第一块掉线的硬盘数据已经久不更新，rebuild只能对先掉线的磁盘做Rebuild，如果对后掉线的磁盘进行重建操作，部分阵列虽然能正常工作，但数据错乱，一些文件不能打开，给用户带来不可挽回的损失。

2. 如果有硬盘掉线不建议盲目进行强制上线操作。

在北亚数据恢复中心恢复的raid5数据恢复案例中，有部分raid阵列数据丢失原因是因为阵列中有一块硬盘离线以后没有及时更换硬盘，此后服务器出现故障或者正常重启，原本离线的硬盘重新上线，而原本在线的硬盘反而故障离线，数据不能正常使用。

用户对后离线的硬盘进行强制上线操作，磁盘阵列进行自动同步，导致数据新旧混乱，服务器数据丢失。因为原来离线的盘又自动上线，大多数阵列卡会检验校验信息，一旦发现校验信息不正确，会重新计算校验信息，致使不能缺盘恢复数据，将会数据恢复失败。

3. 千万不要进行初始化操作。

初始化是一种类似于低级格式化的操作，一旦对阵列进行初始化操作，那么这个阵列内所有硬盘的底层数据将全部被清零，此时将导致阵列数据无法恢复。

4. 重新配置磁盘阵列信息时要保证与原始配置信息一致。

如果需要重新配置磁盘阵列信息时，一定要注意与原始配置信息保持一致，一旦重新配置的参数与原始信息不一致，将导致阵列内多数文件无法打开，造成数据丢失。并且多数服务器都有重新配置阵列信息后自动初始化的功能，这将导致数据无法恢复。

5. 在进行数据恢复尝试前请务必对服务器内的所有硬盘进行扇区级的镜像备份，避免破坏原始数据，如果有条件，可以联系数据恢复中心获取技术指导。

三、RAID5故障数据恢复方案

1. 镜像服务器内所有数据。

按照一定的顺序将服务器内的所有硬盘进行排序编号，然后将每块硬盘进行镜像备份，也可以将服务器携带至北亚数据恢复中心，由数据恢复工程师进行镜像操作。

2. 将镜像文件交给数据恢复中心进行底层数据分析，重组raid阵列，导出用户数据。

3. 对导出的所有数据进行验证，确认无误后重新搭建服务器环境，将恢复的数据迁移回服务器内即可。