如何有效恢复误删的HDFS文件

HDFS是大数据领域比较知名的分布式存储系统,做为大数据相关从业人员,天天处理HDFS上的文件数据是常规操做。这就容易带来一个问题,实际操做中对重要数据文件的误删,那么如何恢复这些文件,就显得尤其重要。node

本文针对误删HDFS文件的问题,经过利用HDFS的内部机制,提供了如下几种方法:json

1. 回收站机制恢复安全

HDFS提供了回收站功能,当咱们执行hdfs dfs -rm -r some_file命令后,文件不会被当即删除。而是先将要删除的数据移动到当前用户的.Trash目录下,待超过必定时间(可经过参数配置)后才会真正执行删除的操做。服务器

首先看个例子:微信

[root@bigdatalearnshare-3 ~]# hdfs dfs -rm -r /bigdatalearnshare/test/stats.json 
20/07/24 16:42:35 INFO fs.TrashPolicyDefault: Namenode trash configuration: Deletion interval = 360 minutes, Emptier interval = 0 minutes.
20/07/24 16:42:35 INFO fs.TrashPolicyDefault: Moved: 'hdfs://bigdatalearnshare-1:9000/bigdatalearnshare/test/stats.json' to trash at: hdfs://bigdatalearnshare-1:9000/user/root/.Trash/Current/bigdatalearnshare/test/stats.json
Moved: 'hdfs://bigdatalearnshare-1:9000/bigdatalearnshare/test/stats.json' to trash at: hdfs://bigdatalearnshare-1:9000/user/root/.Trash/Current

 

从上面的例子能够看出,咱们在删除文件stats.json时,stats.json会被移到/user/root/.Trash/Current目录下:app

[root@bigdatalearnshare-3 ~]# hdfs dfs -ls /user/root/.Trash/Current/bigdatalearnshare/test
Found 1 items
-rw-r--r--   1 root supergroup        147 2020-07-24 16:42 /user/root/.Trash/Current/bigdatalearnshare/test/stats.json

 

若是咱们删除该文件的操做为误操做,此时HDFS的回收站机制就发挥重大做用了。咱们只需到回收站中找到误删的文件,而后移动(mv)到原来的目录,便可恢复误删的数据。分布式

注意:HDFS的回收站机制默认是关闭的,须要咱们在配置文件core-site.xml中配置一些参数,具体以下:oop

<property>
     <name>fs.trash.interval</name>
     <value>360</value>
     <description>检查点被删除后的分钟数。若是为零,垃圾桶功能将被禁用。
     该选项能够在服务器和客户端上配置。若是垃圾箱被禁用服务器端,则检查客户端配置。
     若是在服务器端启用垃圾箱,则会使用服务器上配置的值,并忽略客户端配置值。
     </description>
</property>

<property>
     <name>fs.trash.checkpoint.interval</name>
     <value>0</value>
     <description>垃圾检查点之间的分钟数。应该小于或等于fs.trash.interval。
     若是为零,则将该值设置为fs.trash.interval的值。每次检查指针运行时,
     它都会从当前建立一个新的检查点,并删除比fs.trash.interval更早建立的检查点。
     </description>
</property>

 

注意:经过回收站恢复误删的数据,要求时间不能超过fs.trash.interval配置的时间。学习

生产中为了防止误删数据,建议开启HDFS的回收站机制测试


 

 

2. 快照机制恢复

HDFS快照是文件系统的只读时间点副本。能够在文件系统的子树或整个文件系统上建立快照。

一个快照是一个所有文件系统、或者某个目录在某一时刻的镜像。快照的一些常见用例是数据备份,利用快照能够对重要数据进行恢复,防止用户错误性的操做,管理员能够经过以滚动的方式周期性设置一个只读的快照,这样就能够在文件系统上有若干份只读快照。若是用户意外地删除了一个文件,就能够使用包含该文件的最新只读快照来进行恢复。

HDFS的快照的特征以下:

  1. 快照的建立是瞬间的,代价为O(1),取决于子节点扫描文件目录的时间

  2. 当且仅当作快照的文件目录下有文件更新时才会占用小部份内存,占用内存的大小为O(M),其中M为更改文件或者目录的数量

  3. 新建快照的时候,Datanode中的block不会被复制,快照中只是记录了文件块的列表和大小信息快照不会影响正常的HDFS的操做

  4. 对作快照以后的数据进行的更改将会按照时间顺序逆序的记录下来,用户访问的仍是当前最新的数据,快照里的内容为快照建立的时间点时文件的内容减去当前文件的内容

下面咱们来实操说明如何利用快照恢复误删除的文件:

建立快照

为目录/bigdatalearnshare/snapshot建立名为snapshot-test的快照:

[root@bigdatalearnshare-3 ~]# hdfs dfsadmin -allowSnapshot /bigdatalearnshare/snapshotAllowing snaphot on /bigdatalearnshare/snapshot succeeded[root@bigdatalearnshare-3 ~]# hdfs dfs -createSnapshot /bigdatalearnshare/snapshot snapshot-testCreated snapshot /bigdatalearnshare/snapshot/.snapshot/snapshot-test

误删除操做

由于咱们为/bigdatalearnshare/snapshot建立了快照,此时咱们没法删除该目录:

[root@bigdatalearnshare-3 ~]#  hdfs dfsadmin -allowSnapshot /bigdatalearnshare/snapshot
Allowing snaphot on /bigdatalearnshare/snapshot succeeded
[root@bigdatalearnshare-3 ~]# hdfs dfs -createSnapshot /bigdatalearnshare/snapshot snapshot-test
Created snapshot /bigdatalearnshare/snapshot/.snapshot/snapshot-test

 

可是咱们能够hdfs dfs -rm -r命令该目录下文件。

若是此时,咱们误删了该目录下的重要文件,咱们就能够经过快照机制进行文件的恢复。具体以下:

[root@bigdatalearnshare-3 ~]# hdfs dfs -rm -r /bigdatalearnshare/snapshot
20/07/24 17:06:52 INFO fs.TrashPolicyDefault: Namenode trash configuration: Deletion interval = 360 minutes, Emptier interval = 0 minutes.
rm: Failed to move to trash: hdfs://bigdatalearnshare-1:9000/bigdatalearnshare/snapshot: The directory /bigdatalearnshare/snapshot cannot be deleted since /bigdatalearnshare/snapshot is snapshottable and already has snapshots

 

注意:快照机制进行文件的恢复,咱们要用cp命令,不能用mv,由于快照在这里是只读的。

[root@bigdatalearnshare-3 ~]# hdfs dfs -mv /bigdatalearnshare/snapshot/.snapshot/snapshot-test/stats.json /bigdatalearnshare/snapshot
mv: Modification on a read-only snapshot is disallowed

 


 

3. 编辑日志(edits)恢复

经过编辑日志恢复HDFS文件,适用于Hadoop集群没有开启回收站机制,也没有对重要数据进行快照处理的场景。

可是这种方式存在很大弊端,文件的恢复存在如下几种状况: 
1)所有恢复
2)部分恢复
3)彻底没有回复

这个主要和集群的繁忙状态有很大关系。并且经过这种方式恢复误删文件的代价很高,具体看如下介绍:

删除文件:

由于刚才开启了HDFS回收站机制,为了模拟文件被马上删除的状况,此处经过指定-skipTrash参数跳过回收站回收:

hdfs dfs -rm -r -skipTrash /bigdatalearnshare/testlog/stats.json

 

恢复数据

NameNode在收到删除命令时,会先将这个命令写到edits中,而后会告诉DataNode执行真正的文件删除操做。

因此咱们在误删文件后,须要作的是马上中止NameNode和DataNode节点,阻止删除命令的执行。而后找到执行删除操做发生时间对应的edits日志。

本次测试时,edits文件为edits_inprogress_0000000000000003454,该文件是二进制的形式,咱们能够经过HDFS命令将这个文件转换成可读的xml形式,以下:

hdfs oev -i edits_inprogress_0000000000000003454 -o edits_inprogress_0000000000000003454.xml

 

在edits_inprogress_0000000000000003454.xml中查找删除/bigdatalearnshare/testlog下文件stats.json的命令记录:

<EDITS>
  <RECORD>
    <OPCODE>OP_DELETE</OPCODE>
    <DATA>
      <TXID>3462</TXID>
          <LENGTH>0</LENGTH>
          <PATH>/bigdatalearnshare/testlog/stats.json</PATH>
          <TIMESTAMP>1595582828526</TIMESTAMP>
          <RPC_CLIENTID>dd918895-1482-4b0a-ab8e-d3b2b87c430d</RPC_CLIENTID>
          <RPC_CALLID>1</RPC_CALLID>
      </DATA>
  </RECORD>
</EDITS>

 

OP_DELETE表明删除操做,咱们能够将这个标记修改成安全的操做(如OP_SET_PERMISSIONS),若是这个命令在最后,能够直接删除,而后保存。再将修改后的编辑日志转换成计算机可以识别的格式:

hdfs oev -i edits_inprogress_0000000000000003454.xml -o edits_inprogress_0000000000000003454 -p binary

 

最后再启动NameNode和DataNode节点,查看误删文件的恢复状况。

 

关联文章:

必须掌握的分布式文件存储系统—HDFS

HDFS重要知识点

Hadoop调优


 

关注微信公众号:大数据学习与分享,获取更对技术干货

相关文章
相关标签/搜索