關於我自己

▼

2017年4月20日 星期四

FreeNAS 複寫失敗的處理實例與心得



傳說中的 Bug


FreeNAS 用了這麼多年，終於被我遇到威傑科技 Jackson Wang 兄所提 Replication 的坑。

也就是當複寫一旦失敗後就不會繼續，永遠停在那裡。





發生狀況


首先，系統發出一封通知信
Hello, 
The replication failed for the local ZFS StorageX/vmimg while attempting to apply incremental send of snapshot auto-20170415.0316-2m -> auto-20170417.0316-2m to 172.16.1.XXX


接著，問題發生的徵兆如下

  • Push 發送端會有 replication failed 的錯誤
  • Pull 接收端則是在快照介面，最後有一個 recv 名稱開頭的快照，容量為 0，表示失敗



而在 /var/log/messags 中，則有這段的訊息



從此之後，這兩台之間的複寫工作就再也不會成功。



嘗試解法


試了幾個招數，想要強制刪除這個快照讓複寫恢復正常運作：

  1. 手動從介面刪除該故障快照，失敗（dataset is Busy）
     
  2. 指令 zfs destroy 刪除該快照，失敗（dataset is Busy）
     
  3. 指令 zfs release 釋放它，失敗（no such tag on this dataset）

當中也試著用 ps aux | grep zfs 找出是否接收端有 Process 咬住 Dataset，卻也沒有發現。




確認結果


上述確認都沒辦法處理，最後只好放大絕 reboot 這台 FreeNAS，重開機完成後，已確認可以正常從介面刪除。

接下來複寫工作恢復正常，FreeNAS 有把故障這幾天的快照一一推送到接收端，解決！

目前來看，除了花錢購買 VRP (Volume Replication Package) 模組這條路之外，只能採用美中不足的「重開機 + 手動刪除快照」方法，希望 FreeNAS 上能有更好的解法出現。




最新戰況


2017/4/22 更新：


又發生了。

測試發現，從我在 FreeNAS 裡用 Jail 安裝 Duplicati 做檔案備份至雲端的機制後，這個情況才開始有產生。

每當 Replication Failed 發生時，我先做 Snapshot 給 Duplicati 讀取的那一份也從快照清單上消失，我備份前的 Script 是：

zfs destroy  資料集路徑@名稱
zfs snapshot 資料集路徑@名稱

目前初步懷疑這個「快照」的動作，是造成頻繁 Failed 的原因之一，已做修改，繼續觀察中。


2017/4/26 更新：


觀察了四天，只要有做上述的快照銷毀與產生就會發生。

拿掉以後，確認複寫都已正常沒有再出現過失敗，因此幾乎可證明是我上面寫的 Script 所造成。

也就是說，用來接收遠端推過來複寫的這個 Dataset，最好不要另外再自己做其它快照，不管是手動還是排程，都會因此影響複寫接收的成功率。



發佈：