咱们晓得hdfs是hadoop体系上的文件系统，负责具体的数据文件存储，且如果一旦hdfs文件被误删除后，尤其是重要数据，对公司来说影响十分大。所以须要提前做一些平安预防措施，例如应用Hdfs Trash机制，或者重要目录利用Hdfs SnapShot性能，而后针对于删除的文件或者目录能够通过trash或者SnapShot机制来进行复原，如果数据的确曾经删除了（例如间接通过hadoop api进行delete，未配置SnapShot），如果想复原数据，就须要疾速采取肯定的措施了。上面咱们来别离介绍下这些复原数据的应用形式与机制。

Hdfs Trash（回收箱）

对于线上生产环境的HDFS，开启回收站性能是必不可少的。该性能相似于linux零碎的回收站设计，HDFS会为每个用户创立一个专属的回收站目录（/user/${user.name}/.Trash），用户删除文件时，实际上是被挪动到了回收站目录。用于预防当用户误删HDFS上的数据时，可能及时从回收站复原这些数据（当然回收站是防不住删库跑路的）。

应用这种形式的前提是在hdfs下面开启trash性能，默认是没有开启的。interval的值默认为0，单位是分钟。只须要在hadoop的配置文件core-site.xml中增加上面的内容：

<!--Enable Trash -->
<property>
      <name>fs.trash.interval</name>
      <value>120</value>
</property>
<property>
      <name>fs.trash.checkpoint.interval</name>
      <value>120</value>
</property>

增加好上述内容后，不须要重启后台程序，间接就会失效。执行删除操作后，会先将文件挪动到以后操作用户的.Trash/Current目录上面。

Hdfs SnapShot(快照)

hadoop从2.1版本后开始反对HDFS快照（SnapShot）性能，

快照创立瞬时性：除去inode的查问工夫，算法耗费O(1)复杂度。

只有在对快照批改时才会耗费额定内存：内存应用O(M)，M是被批改的文件或者目录数。

DataNode的block不被复制：快照文件记录block列表和文件大小。不做数据的拷贝复制。

快照不会对失常HDFS操作产生不利影响：所有的批改都依照工夫倒序排序，因而以后数据总能被间接拜访到。快照数据是依据与以后数据进行变更局部的差值计算得来的。

应用实例：

应用形式：

创立快照：

hdfs fs -allowSnapshot /test
hdfs fs -put test.txt /test
hdfs fs -createSnapshot /test import_data

将test文件删除：

hdfs fs -rmr /test/test.txt

误删除后就能够应用快照目录进行复原：

hdfs  fs  -cp /test/.snapshot/import-data/test.txt  /text
复原数据

然而如果间接调用hadoop delete api进行删除操作，是默认不会走trash机制的，同时也未配置快照性能的状况下，文件所对应的block数据曾经开始真正从底层文件系统层面进行删除，此时须要疾速的做出决断进行复原操作。因为须要进行数据服务（nn、dn），所以须要综合思考，去衡量复原数据和停服对线上服务的影响两者之间的利害关系。

首先梳理下hdfs delete的流程，如下图：

咱们能够看到hdfs delete流程中很多环节都是异步进行操作的，所以如果想复原数据，须要立刻做出决定是否进行停服，能够复原的数据量也取决于操作与停服间隔时间，还有集群的忙碌水平，所以可能复原全副或者局部数据，如果工夫过了很久了，在集群规模比拟大、集群比拟闲暇的状况下，可复原的数据量百分比就不能太乐观了。上面咱们来阐明下具体复原步骤（阐明：操作的前提是有删除操作之前的fsimage元数据，同时须要有备用的新集群）：

  1. 及时进行hdfs集群服务（nn、dn），阻止block数据从os上进一步被删除；

由上述的hdfs delete流程可知namenode删除block指令是通过datanode心跳一批批下发的，且datanode是通过异步线程删除block数据， 所以须要立刻进行服务过程，阻止datanode上的block文件进一步被删除；

  1. 拷贝删除数据前的元数据fsimage文件，并在新集群namenode加载

2.1) 通过hdfs审计log找到删除操作开始的确切工夫点；

2.2) 从fsimage备份的多个版本中，找到删除操作工夫点前的fsimage；

2.3) 停掉新集群所有过程(保留journalnode)，初始化新环境；

2.4) 停掉所有journalnode过程，在image目录替换为备份的fsimage文件，替换imaeg、edits、和所有journalnode目录下的VERSION文件为生产环境上的VERSION文件；

2.5) 启动namenode过程；

  1. 用fsck在新集群namenode获取数据块blockid，生成列表文件

./bin/hadoop fsck 误删目录  -files -blocks  (通过脚本生成blockid列表文件)

  1. 从原集群datanode上拷贝blockid对应的文件到新集群datanode

4.1) 在原集群每个datanode上生成要拷贝的blockid文件目录列表（编写脚本通过ancible执行）

4.2) 统计能够检索进去的存在的blockid文件数量（依照blockid去重）和总blockid数量的比例，依据比例状况判断数据恢复操作是否持续进行；

4.3) 在原集群每个datanode上拷贝blockid对应文件到新集群datanode（编写脚本通过ancible执行，scp，如果有多正本须要copy到不同datanode节点上）

4.4) 比照验证copy到新集群datanode节点上文件数量;

  1. 启动新集群datanode，查看新集群复原的数据量,文件数据可用性

5.1) 启动新集群上所有datanode;

5.2) 查看复原的文件数据量，测试文件数据的可用性

  1. 复原老集群服务

启动hdfs集群所有节点的服务过程；

7.从新集群distcp hdfs文件回老集群 

以上就是对于hdfs数据误删后数据恢复的步骤，有疑难或者谬误的中央的欢送沟通和斧正。

关键词：大数据培训