如何有效恢復誤刪的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調優


 

關注微信公衆號:大數據學習與分享,獲取更對技術乾貨

相關文章
相關標籤/搜索