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

前端之家收集整理的这篇文章主要介绍了如何有效恢复误删的HDFS文件前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

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

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目录下:

[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中配置一些参数,具体如下:

<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调优


 

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

原文链接:/hadoop/991893.html

猜你在找的Hadoop相关文章