如何有效恢复误删的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的快照的特征如下：
- 快照的创建是瞬间的，代价为O(1)，取决于子节点扫描文件目录的时间
- 当且仅当做快照的文件目录下有文件更新时才会占用小部分内存，占用内存的大小为O(M)，其中M为更改文件或者目录的数量
- 新建快照的时候，Datanode中的block不会被复制，快照中只是记录了文件块的列表和大小信息快照不会影响正常的HDFS的操作
- 对做快照之后的数据进行的更改将会按照时间顺序逆序的记录下来，用户访问的还是当前最新的数据，快照里的内容为快照创建的时间点时文件的内容减去当前文件的内容
下面我们来实操说明如何利用快照恢复误删除的文件：
创建快照：
为目录/bigdatalearnshare/snapshot创建名为snapshot-test的快照：
[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误删除操作：
因为我们为/bigdatalearnshare/snapshot创建了快照，此时我们无法删除该目录：
[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但是我们可以hdfs dfs -rm -r命令该目录下文件。
如果此时，我们误删了该目录下的重要文件，我们就可以通过快照机制进行文件的恢复。具体如下：
[root@bigdatalearnshare-3 ~]# hdfs dfs -ls /bigdatalearnshare/snapshot/.snapshot/snapshot-test
Found 1 items
-rw-r--r-- 1 root supergroup 147 2020-07-24 17:00 /bigdatalearnshare/snapshot/.snapshot/snapshot-test/stats.json
[root@bigdatalearnshare-3 ~]# hdfs dfs -cp /bigdatalearnshare/snapshot/.snapshot/snapshot-test/stats.json /bigdatalearnshare/snapshot
[root@bigdatalearnshare-3 ~]# hdfs dfs -ls /bigdatalearnshare/snapshot
Found 1 items
-rw-r--r-- 1 root supergroup 147 2020-07-24 17:14 /bigdatalearnshare/snapshot/stats.json注意：快照机制进行文件的恢复，我们要用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 disallowed3.编辑日志(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节点，查看误删文件的恢复情况。