|
||
|
Major Member
 加入日期: Aug 2004
文章: 188
|
群暉NAS修復Volume crash的方法
群暉NAS如果碰到Volume crash的狀況, 而硬碟仍可讀取, 但不能寫入, 官方旳建議是把資料全複製到其他硬碟, 把原先的Volume砍了, 再建新的Volume. 官方的建議就到此為止, 其他就沒有了.
我碰到的問題是, Volume crash後, 看得到的檔案只有一部分可以複製, 還有很多無法複製出來. 群暉官方提供的方法對我完全沒用, 於是我開始研究如何解決這個狀況. 其實NAS裡的工具程式可以修復Volume crash, 但群暉官方並沒提供方法, 是靠使用者社群自己試出來的. 首先, 理論上的分析, 會出現Volume crash, 原因不出三種組合, bad sector, file system error, RAID error. 第一種bad sector, 可以用DiskGenius或HDD Regenerator來掃, 然後試著修復. 如果找到bad sector而且修得好, 大概就解決了. DiskGenius掃描速度大概比HDDR快十倍, 我一顆6TB的HDD, 用HDDR要掃100小時, 用DiskGenius大概低於9小時. 我用HDDR修了不少顆HDD. DiskGenius只用來掃, 沒用來修復過. 第二種file system error, 如果file system是用ext4, 可以用fsck程式來檢查並自動修復. 如果是用btrfs格式, 我就不知道了. 我沒用過btrfs. 第三種RAID error, 可以用mdadm程式來修復. 我只試過修復SHR, 其他RAID 0,1... 照理說應該也可以, 但我沒試過. 詳細的教學, 網路上可以找到, 我主要是看這幾篇: https://serverfault.com/questions/6...ology-with-mdam https://xpenology.com/forum/topic/2...crashed-volume/ https://blogs.dbcloudsvc.com/life/f...f-synology-nas/ https://ilmvfx.wordpress.com/2020/1...crashed-volume/ 我自己的經驗, 碰過兩次Volume crash, 一次是在DSM6.2.3的黑群暉上, 因為檔案還可以全複製出來, 就全複製出來, 砍掉原本的Volume, 再重新建一個, 沒用到上面的方法. 後來又在一台跑DSM5.2的DS1010+上碰到Volume crash, 因為有大量的檔案看得到, 卻複製失敗, 才開始研究修復Volume crash的方法. 先看NAS log, 裡面有一段說found bad sector, 於是我先掃bad sector, 大概掃了百分之四十, 沒找到一個, 我判斷應該不是真的bad sector, 就改走修復file system的路, 用fsck檢查了一遍, 確實有錯誤, 就讓fsck自動修復. 不過, 修復後還是顯示Volume crash, 檔案還是複製不出來, 於是我用mdadm修復SHR. 修復SHR之後Volume就可以正常使用了. 如果當初一開始建Volume時, 只選Basic, 沒用RAID或SHR, 就只是單純的ext4格式, 那用fsck修復file system後就應該OK了. fsck和mdadm都要配合一堆參數, 每台NAS不一樣, 使用者得自己研究. 如果有用RAID或SHR, 就得用mdadm修復RAID. 程序比較複雜, 有好幾個步驟, 簡單來說: 第一步先進SSH, 並把DSM裡有各種服務, package, docker全關掉. 第二步輸入命令: cat /proc/mdstat, 確認有問題的那顆硬碟的狀態確實是Error. 記好硬碟設備的路徑, 像我的是/dev/md3和/dev/sdb5 第三步輸入命令: mdadm --detail /dev/md3, 找到一行Array UUID : (接著一串數字符號) 第四步輸入命令: mdadm --stop /dev/md3 和 syno_poweroff_task -d (這兩個命令是把所有使用硬碟的程序都關掉, 連WEBUI也不能連, 然後才能對硬碟RAID進行修復) 第五步輸入命令: mdadm -Cf /dev/md3 -e1.2 -n1 -l1 /dev/sdc3 -u(-u後面要填上Array UUID, 不含括號). 當畫面顯示"Continue creating array?" 按y, 然後就會得到"mdadm: array /dev/md3 started." 這樣就修復成功. 重開機後就發現Volume顯示正常, 而非crash, 而原來看得到卻不能複製的檔案也全部可以成功複製. 最後提醒, 這上面提到的方法, 只能修復特定問題的Volume crash, 不是所有的Volume crash都能修, 而且, 一旦用錯了, 會導致本來可用別的方法救回的資料變成救不回來. 所以, 這只能當成最後手段, 不想找資料救援服務, 想自己搞, 才要走這條路, 走了可能就沒法回頭了. 大概也是因為太複雜了, 所以群暉官方的建議不會提這個方法. |
|||||||
2022-08-24, 03:19 PM
#1
|
|
|
Basic Member
加入日期: Sep 2003
文章: 16
|
先記錄一下，希望不要有用到的一天...
|
||
|
2022-08-24, 04:58 PM
#2
|
|
|
Elite Member
  加入日期: Oct 2002
文章: 4,793
|
如果有條件
還是建議走定期備份 可以多一條簡單的還原方式
__________________
人性的醜陋就是，會在無權、無勢、善良的人身上挑毛病，卻在有權、有勢、缺德的人身上找優點。當無權、無勢、善良的人受到傷害的時候，還會站在所謂的道德制高點上，假惺惺地勸說無權、無勢、善良的人，一定要忍耐，一定要大度。 |
|
2022-08-24, 05:00 PM
#3
|
|
|
Elite Member
加入日期: Jun 2001 您的住址: 地球
文章: 6,231
|
NAS外接一顆備份硬碟會更好...
__________________
~愛由一個笑容開始，用一個吻來成長，用一滴眼淚來結束。 當你出生時你一個人在哭，而所有在旁的在笑，因此請活出你的生命， 當你死的時候，圍繞你的人在哭而你便是唯一在笑。~ |
|
2022-08-25, 10:55 AM
#4
|
|
|
Major Member
加入日期: Aug 2004
文章: 188
|
其實, 對於資料沒有備份的人, 如果碰上了Volume crash, 問我要不要用上面的方法修復, 我只能說, 有機會修好, 但風險自負.
但如果是資料有備份的人, 碰上Volume crash, 我會強烈強議先用上面的方法修復Volume. 因為跑fsck和mdadm大概不用十分鐘. 而備份的資料要倒回NAS, 一秒傳100MB, 3TB的資料要花30000秒, 約8個多小時. 好處很明顯. |
|
2022-08-26, 05:09 PM
#5
|
|
|
Power Member
加入日期: Sep 2003 您的住址: 新竹市
文章: 513
|
真的不知道群暉的機制，很容易發生crash，還是因為是黑的∼
這些教學我都有試過，沒有成功過 不過資料都還可以讀出來，轉移很麻煩 |
|
2022-09-06, 10:51 AM
#6
|
|
|
Major Member
加入日期: Aug 2004
文章: 188
|
最近又碰到兩次Volume crash的問題, 還好用上面的方法都救回來了. 看起來是硬碟本身的問題, 趕快把資料移到別顆硬碟上.
本來是用黑群暉的DSM 6.2.3, 正好最近boot loader有新發展, 有新的redpill recovery (https://github.com/RROrg/rr), 可以裝DSM 7.2.1, 測試了幾天, 很穩定, 更重要的是, 能支援RTL8125 PCIE網卡, 這樣就能升級到2.5GBe網路了. 在試用的過程中, 發現幾件有趣的事: 1. 群暉的硬碟做partition分割, 直到DSM 7.0和之前的版本, 都是第一個partition 2.4GB, 裝DSM, 第二個partition 2GB, 當SWAP, 第三個才是放資料的partition. 從7.1開始, 第一個partition改成8GB, 其他不變. 這樣一來, 就不能把另一台NAS上用DSM6.2的硬碟抽換到新的NAS(用DSM7.2.1), DSM 7.2.1會說不能裝. 但如果是直接同一台升級, 從6.2升級到7.2, 則可以安裝, 但第一個partition應該還是2.4GB, 以後哪天群暉的DSM需要超過2.4GB的安裝空間, 可能會因為空間不足出現不能升級的問題, 不過目前還沒問題就是了. 2. "syno_poweroff_task -d" 這個指令在DSM 7.2.1中已經消失, 不能用了. 要用什麼指令來替代還有待研究. 3. DSM裡有secure erase的功能, 用來清除硬碟裡的資料, 最好別用. 如果要用, 就要讓它從頭執行到結束, 不能中途關機. 我在執行secure erase後嫌它太慢, 又不能中斷執行, 就直接關機, 把硬碟拿到PC上去處理. 因為secure erase在執行時會把硬碟鎖住, BIOS/UEFI開機時會說這顆硬碟已被鎖住, 要輸入密碼才能使用. 查了一下, 密碼是"synology". 我的結論是, 如果要把整顆硬碟清空, 不要用DSM裡的secure erase, 改用PC來做比較快. 此文章於 2024-07-17 12:40 PM 被 ericshliao 編輯. |
|
2024-07-17, 12:35 PM
#7
|
|
|
Elite Member
加入日期: Mar 2001 您的住址: Rivia
文章: 6,990
|
DSM 對比 TrueNAS 已經完全沒有優勢了
完全不建議使用黑群輝 就算要用也千萬別用 SHR 然後你的 Volume crash 好像太頻繁了？！ 也許可以檢查記憶體或 CPU 之前曾經看過有 CPU 本身缺陷 會造成 RAID 算法出現異常導致資料損毀的案例 需要更新微碼解決
__________________
Folding@home with GPGPU集中討論串 Unix Review: ArchLinux●Sabayon●OpenSolaris 2008.5●Ubuntu 8.10 AVs Review: GDTC●AntiVir SS●ESS●KIS 09●NIS 09●Norton 360 V3  I Always Get What I Want. |
|
2024-07-17, 02:21 PM
#8
|
|
|
Major Member
加入日期: Aug 2004
文章: 188
|
引用:
TrueNAS我只聽過, 沒用過, 目前有一台裝UNRAID, 算好用. 我碰到出現Volume crash的都是白群暉, 黑群暉從沒出過問題, 應該是硬碟本身的問題, 都是同一顆硬碟, 應該是過熱導致, 跟CPU或RAM沒什麼關係. 至於 RAID, 我不敢用, 因為修復很麻煩. |
|
|
2024-07-17, 02:33 PM
#9
|
|
|
Elite Member
加入日期: Mar 2001 您的住址: Rivia
文章: 6,990
|
如果你的資料很重要的話
用 raid1，基本上你不會遇到上面你遇到的這些問題 基本上就是提示哪顆硬碟有問題就換掉 也不會增加維修難度與損壞風險 我對自己的儲存設備的態度如曹操的用人則學 用人不疑，疑人不用 當你懷疑某顆硬碟應該真的壞的時候 就不該再繼續使用了 而且你都用到 mdadm 指令了 你其實已經學會如何修 raid 而你自己不自知而已
__________________
Folding@home with GPGPU集中討論串 Unix Review: ArchLinux●Sabayon●OpenSolaris 2008.5●Ubuntu 8.10 AVs Review: GDTC●AntiVir SS●ESS●KIS 09●NIS 09●Norton 360 V3 I Always Get What I Want. |
|
2024-07-18, 12:23 PM
#10
|
|
