1.冗余goal設置目標（goal），是指文件被拷貝的份數，設定了拷貝的份數后是可以通過mfsgetgoal 命令來證實的，也可以通過mfsrsetgoal 來改變設定。/usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/test1 ? ?設置文件/mnt/mfs/test1有三個副本/usr/local/mfs/bin/mfsgetgoal /mnt/mfs/test1/mnt/mfs/test1: 3用mfsgetgoal –r 和mfssetgoal –r 同樣的操作可以對整個樹形目錄遞歸操作，其等效于mfsrsetgoal命令。實際的拷貝份數可以通過mfscheckfile 和mfsfile info 命令來查看。注：一個不包含數據的零長度的文件,盡管沒有設置為非零的目標（the non-zero "goal"）,但用mfscheckfile 命令查詢將返回一個空的結果；將文件填充內容后，其會根據設置的goal創建副本；這時再將文件清空，其副本依然作為空文件存在。假如改變一個已經存在的文件的拷貝個數，那么文件的拷貝份數將會被擴大或者被刪除，這個過程會有延時。可以通過mfscheckfile 命令來證實。對一個目錄設定“目標”，此目錄下的新創建文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的拷貝份數?？梢酝ㄟ^mfsdirinfo來查看整個目錄樹的信息摘要。2.垃圾回收站一個刪除文件能夠存放在一個“ 垃圾箱”的時間就是一個隔離時間， 這個時間可以用mfsgettrashtime 命令來驗證，也可以用mfssettrashtime 命令來設置：/usr/local/mfs/bin/mfssettrashtime 64800 /mnt/mfs/test1/usr/local/mfs/bin/mfsgettrashtime /mnt/mfs/test1/mnt/mfs/test1: 64800 時間的單位是秒。就像文件被存儲的份數一樣, 為一個目錄設定存放時間是要被新創建的文件和目錄所繼承的。數字0 意味著一個文件被刪除后, 將立即被徹底刪除，在想回收是不可能的。刪除文件可以通過一個單獨安裝MFSMETA 文件系統。特別是它包含目錄/ trash (包含任然可以被還原的被刪除文件的信息)和/ trash/undel (用于獲取文件)。只有管理員有權限訪問MFSMETA(用戶的uid 0，通常是root)。/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1被刪文件的文件名在“垃圾箱”目錄里還可見,文件名由一個八位十六進制的數i-node 和被刪文件的文件名組成，在文件名和i-node 之間不是用“/”,而是用了“|”替代。如果一個文件名的長度超過操作系統的限制（通常是255 個字符），那么部分將被刪除。通過從掛載點起全路徑的文件名被刪除的文件仍然可以被讀寫。移動這個文件到trash/undel 子目錄下，將會使原始的文件恢復到正確的MooseFS 文件系統上路徑下（如果路徑沒有改變）。如果在同一路徑下有個新的同名文件，那么恢復不會成功。從“垃圾箱”中刪除文件結果是釋放之前被它站用的空間(刪除有延遲,數據被異步刪除)。在MFSMETA中還有另一個目錄reserved，該目錄內的是被刪除但依然打開的文件。在用戶關閉了這些被打開的文件后，reserved 目錄中的文件將被刪除，文件的數據也將被立即刪除。在reserved 目錄中文件的命名方法同trash 目錄中的一樣，但是不能有其他功能的操作。3. 快照snapshotMooseFS 系統的另一個特征是利用mfsmakesnapshot 工具給文件或者是目錄樹做快照。
/usr/local/mfs/bin/mfsmakesnapshot source ... destinationMfsmakesnapshot 是在一次執行中整合了一個或是一組文件的拷貝，而且任何修改這些文件的源文件都不會影響到源文件的快照， 就是說任何對源文件的操作,例如寫入源文件，將不會修改副本(或反之亦然)。也可以使用mfsappendchunks：/usr/local/mfs/bin/mfsappendchunks destination-file source-file ...當有多個源文件時，它們的快照被加入到同一個目標文件中（每個chunk 的最大量是chunk）。4. MFS chunkservers 的維護若每個文件的goal（目標）都不小于2，并且沒有under-goal 文件（這些可以用mfsgetgoal –r和mfsdirinfo 命令來檢查），那么一個單一的chunkserver 在任何時刻都可能做停止或者是重新啟動。以后每當需要做停止或者是重新啟動另一個chunkserver 的時候，要確定之前的chunkserver 被連接，而且要沒有under-goal chunks。5.MFS元數據備份與恢復通常元數據有兩部分的數據：主要元數據文件metadata.mfs，當mfsmaster 運行的時候會被命名為metadata.mfs.back元數據改變日志changelog.*.mfs，存儲了過去的N 小時的文件改變（N 的數值是由BACK_LOGS參數設置的，參數的設置在mfschunkserver.cfg 配置文件中）。主要的元數據文件需要定期備份，備份的頻率取決于取決于多少小時changelogs 儲存。元數據changelogs 實時的自動復制。1.6版本中這個工作都由metalogger完成。5.1 MFS Master的恢復一旦mfsmaster 崩潰（例如因為主機或電源失敗），需要最后一個元數據日志changelog 并入主要的metadata 中。這個操作時通過mfsmetarestore 工具做的，最簡單的方法是：/usr/local/mfs/bin/mfsmetarestore -a如果master 數據被存儲在MooseFS 編譯指定地點外的路徑，則要利用-d 參數指定使用：/usr/local/mfs/bin/mfsmetarestore -a -d /opt/mfsmaster5.2 從MetaLogger中恢復Master找回metadata.mfs.back 文件，可以從備份中找，也可以中metalogger 主機中找（如果啟動了metalogger 服務），然后把metadata.mfs.back 放入data 目錄，一般為{prefix}/var/mfs從在master 宕掉之前的任何運行metalogger 服務的服務器上拷貝最后metadata 文件，然后放入mfsmaster 的數據目錄。利用mfsmetarestore 命令合并元數據changelogs，可以用自動恢復模式mfsmetarestore –a，也可以利用非自動化恢復模式：mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs或者強制使用metadata.mfs.back創建metadata.mfs，可以啟動master，但丟失的數據暫無法確定。

轉載于:https://blog.51cto.com/breezey/1339421

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的MFS分布式存储三：备份与恢复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。