咱们晓得 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 文件进一步被删除；

2. 拷贝删除数据前的元数据 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 过程；

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

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

4. 从原集群 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 节点上文件数量;

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

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

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

6. 复原老集群服务

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

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

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

关键词：大数据培训