如何有效恢復誤刪的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/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節點，查看誤刪文件的恢復情況。
關聯文章：
關注微信公眾號：大數據學習與分享，獲取更對技術乾貨
