資料恢復 · 2026年10月23日 · ComputerKing 團隊

香港中小企 RAID 恢復：重建之前停一停，救數據定救陣列要分清楚

NAS 彈 degraded 警告，千祈唔好即刻撳重建。先分清救數據定救陣列上線，睇停手清單、換碟流程同多盤故障點分。

重點摘要

NAS 彈 degraded 警告嗰陣最危險：先停手睇清楚故障原因，再決定救數據定重建陣列，亂試重建只會令資料更難救返。

第 1 節：夜晚彈出 degraded 警告嗰刻，你最要做嘅嘢係停一停

假設有一個畫面：星期五夜晚，公司 NAS 彈出 degraded 警告，話有一隻碟出咗問題。老闆心諗，聽日星期六仲要出貨，今晚搞掂佢就最好。值班同事心急，想即刻撳重建，等陣列自己修返好。呢個心態好正常，但係今篇文章要講嘅重點就係，呢一刻心急撳掣，往往就係令小問題變大問題嘅開始。

呢個假設情境唔係真實個案，只係用嚟帶出一個好多中小企都會遇到嘅抉擇。公司資料通常冇第二份完整備份，或者備份好耐冇試過還原，陣列一出事，成間公司嘅運作就好似企喺一條幼線上。喺呢個時候，決定嘅次序比速度更加重要。

核心決策句好簡單，開頭就要講清楚：你要救嘅係數據，定係你要救嘅係陣列上線？兩個目標用嘅做法完全唔同。如果你要救數據，就唔好喺未搞清楚故障原因之前改原碟。如果你手頭已經有一份驗證過、還原得到嘅備份，而你嘅目標只係想令陣列重新上線，咁先至適合直接諗重建。好多災難都係因為將兩個目標撈亂咗：明明想救數據，但係做咗只適合救陣列上線嘅動作，結果數據反而俾重建過程寫壞咗。

多間恢復公司一致建議嘅黃金規則係，做得愈少，保留嘅選擇愈多。呢句說話聽落好保守，但係背後有好實際嘅原因。RAID 陣列入面每一個寫入動作，都有機會覆蓋本來仲救得返嘅資料。相反，停手、影相、記低配置、睇記錄，呢啲動作唔會改寫硬碟，之後無論你揀邊條路，都仲有得揀。一旦你撳錯掣，行錯一步，好多時就冇得返轉頭。

業界一致指出，操作員錯誤，而唔係原本硬件故障，係永久 RAID 數據遺失嘅主要原因。換錯碟、重新初始化陣列、反覆強制陣列上線，係最常見嘅錯誤。講到尾，硬件壞一隻碟好多時仲有得救，但係人手喺驚慌之下連續做錯幾個決定，就好容易將一個本來可以處理嘅單碟故障，變成冇得救嘅局面。所以今篇文章嘅主線唔係教你點樣撳掣最快，而係教你喺撳掣之前點樣停一停、分清楚、再決定。

第 2 節：各級容錯上限決策版對照

上一輪已經講過基本容錯表，今輪用決策版再講一次，重點唔係背數字，而係講明邊個位係分界線。以下表格講嘅係控制器正常重建嘅容錯上限，唔係專業離線恢復嘅上限。超出上限唔等於數據一定全滅，但係等於唔可以用正常重建救返，要轉去離線虛擬重建或者專業評估，而且部分 stripe 有機會救唔返。

表 1：各 RAID 級別正常重建容錯上限

有幾點決策上一定要記住。第一，RAID 5 degraded 之後，陣列實際上係以零冗餘運作，直到重建完成。Degraded 唔係已經修好，只係仲行得。好多中小企見到 degraded 之後仲讀寫到，就以為冇事，拖幾個星期先處理，呢段時間就係最危險嘅空窗期。第二，RAID 6 雖然容 2 隻，但係重建時間比 RAID 5 更長，因為多一重 parity 計算，窗口期更長，唔好寫成 RAID 6 就一定安全。第三，SUSE 官方文件講得好清楚，RAID 5 同一時間唔可以多過一隻硬碟故障，RAID 6 即使喺數據恢復過程中再有兩隻硬碟故障，系統仍可繼續運作而無數據遺失，呢個講法指嘅係雙 parity 設計上限之內，唔係無限保障。

選級別嗰陣都要講取捨，唔好一刀切。有個別來源建議，碟大約 8TB 以上，或者陣列多過 6 隻碟，就考慮 RAID 6 或者 RAID-Z2，因為重建時間長，第二隻碟喺重建期間出事嘅機會都大咗。另一個個別來源建議，碟大約 12TB 起，或者陣列大過 4 至 5 個 bay，就轉 RAID 6。反過嚟講，細陣列、細碟、有完整備份嘅 RAID 5，仍然有佢嘅位置。重點唔係邊個級別最勁，而係你嘅陣列大細、碟容量、備份狀態，同你願意承受幾長嘅零冗餘窗口，要一齊睇。

第 3 節：重建前停手清單，講清楚點解唔好做

呢節係今輪主線，唔只列清單，仲要講每個動作點解危險。以下全部都係停手項目，意思係見到相關情況嗰陣，唔好做呢啲動作。呢張清單入面冇包括先抄走可讀資料嗰個步驟，因為嗰個步驟只適用喺第 4 節講嘅分流情況，兩者要分開睇，唔好撈埋一齊。

表 2：重建前停手清單

除咗上面呢張表，重建前仲有幾樣嘢一定要做，呢啲唔係寫入動作，而係記錄同確認動作。第一，影相加標籤加記低配置，拆任何嘢之前，先將每隻碟按 bay 位置標籤，影低碟 bay 同現時碟順序，記低每隻碟型號同序號、NAS 或者控制器型號、RAID 級別、成員碟數目、碟容量、stripe size（如果知道）、邊啲碟故障或者被替換或者做過 hot spare、近期 rebuild、遷移、擴充、換碟記錄。第二，睇 log 定性故障，邊隻碟跌出、幾時跌出、係咪重建途中跌出，log 係證據，唔係叫你即刻再試重建嘅指令。第三，確認替換碟容量等於或者大過故障碟，介面 SATA 或者 SAS 要一致，熱備援碟都要符合同樣要求，容量至少等於要頂替嘅故障碟（混容量陣列以最大碟為準）。第四，確認供電穩定同散熱正常，重建係全速連續讀寫，過熱同斷電都係重建失敗嘅常見幫兇，UPS 嘅作用見第 11 節。

仲要分清楚三個好容易撈亂嘅動作。第一個係初始化碟，即係寫入新分割表或者 metadata，會破壞原有佈局。第二個係重新建立陣列，即係用舊碟開一個新 RAID，新 metadata 會覆蓋舊 metadata。第三個係正常換碟重建，即係用一隻全新或者已清空嘅替換碟，控制器向嗰隻碟寫入重建數據，本身係合法操作，但係前提係已經確認故障碟同剩低嗰啲碟健康，詳細分界見第 5 節。分唔清楚呢三個動作，就好容易喺介面度撳錯掣。

第 4 節：分流步驟，先抄走可讀資料只適用喺一種情況

呢節要講得特別清楚，因為上一批出事位就係將兩件事撈埋一齊。停手同先抄走可讀資料係兩件唔同嘅事，適用情況完全唔同，唔可以掉轉。

先講停手訊號，見到以下任何一項，即刻停手，唔好諗住先抄走資料。任何碟發出 clicking、grinding、scraping 聲，碟唔轉，BIOS 或者 UEFI 完全認唔到碟，SMART 完全讀唔到，水浸、火燒、撞擊、電湧之後嘅故障，多隻碟同時完全機械故障，軟件恢復工具完全讀唔到任何一隻碟嘅數據，重建已經失敗過一次，第二隻碟已經跌出，控制器已經認唔到陣列，volume 顯示 RAW、0 bytes、Foreign Configuration，陣列唔再掛載，重建過程出現錯誤，多隻碟突然同時跌出。呢啲全部都係即刻停手訊號，唔係自行備份嘅觸發條件。掉碟、異聲、認唔到碟、第二隻跌出，絕對唔係叫你快啲抄走資料，而係叫你即刻停手送修，保留原碟同原順序，等專業評估。

咁邊種情況先可以考慮先抄走可讀資料呢？一定要同時符合以下全部條件，缺一就唔好做。陣列只係進入 degraded 模式，未完全故障，已經確認只有一隻碟故障，剩低嗰啲碟健康，全部碟喺 BIOS 或者 UEFI 入面都認得到，冇異常聲音，SMART 數據讀得到，故障原因睇落係控制器錯誤、metadata 損壞或者檔案系統損壞，而唔係物理損壞。喺呢種情況之下，先至可以考慮喺重建之前，先將最重要嘅檔案抄去另一隻健康裝置，減低之後重建失敗嗰陣嘅損失。呢個步驟嘅前提係碟仲讀得到，而且你抄走資料嘅動作係讀取，唔係向故障陣列寫入。

仲有一點要講明，抄走資料唔等於備份還原，更加唔等於已經安全。抄走最重要檔案只係減低損失，之後你仲要面對陣列點處理嘅決定。如果你抄走資料嗰陣發現檔案讀到一半就停、速度極慢、成日彈錯誤，呢啲都係碟況惡化嘅訊號，應該即刻停手，唔好硬抄落去。硬抄落去同反覆開關機一樣，都係對已經受壓嘅碟加壓。

所以成個邏輯係咁樣分。第一步，睇下有冇停手訊號，有就停手，唔好做任何抄寫或者重建。第二步，如果冇停手訊號，而陣列只係 degraded 單碟故障，碟仲讀得到，先至考慮先抄走最重要檔案。第三步，抄完之後再按第 5 節嘅換碟流程決定點做。將第二步寫入停手清單，或者將停手訊號當成抄資料嘅觸發條件，兩個方向都係錯，今篇文章特登分開兩節講，就係要避免呢種混淆。若成因指向控制器、供電、背板或線材，唔好入第 5 節換碟流程，轉去第 8 節同專業評估；第 5 節只適用於已確認係碟本身故障且需要換碟嘅情況。

第 5 節：換碟流程同重建風險，次序錯一步就差好遠

如果已經通過第 4 節嘅分流，確認只係 degraded 單碟故障，碟仲讀得到，冇停手訊號，咁先至可以諗換碟流程。開閘條件同第 3 節一致：未做 image、未按第 4 節抄走最重要檔案之前，唔好喺原陣列上撳重建。若成因指向控制器、供電、背板或線材，唔好入第 5 節換碟流程，轉去第 8 節同專業評估；第 5 節只適用於已確認係碟本身故障且需要換碟嘅情況。換碟流程嘅重點係次序同確認，唔係速度。以下流程綜合 Synology 同 QNAP 廠方指引寫成，實際介面用詞按型號可能略有唔同，操作之前一定要對照自己部機嘅介面。

表 3：換碟流程同每一步嘅重建風險

有幾點要特別提醒。第一，QNAP 廠方講明，兩隻碟同時喺 warning 狀態嗰陣，換碟同重建過程入面有更高風險，碟可能喺呢個過程入面故障，導致數據遺失。如果重建未能成功完成，廠方指引係聯絡 QNAP 支援，而唔係自行重試初始化或者強制修復。第二，熱備援 hot spare 嘅價值係縮短 degraded 空窗期，因為人手發現加買碟加換碟往往要幾日，而 hot spare 可以即刻開始重建。但係 hot spare 唔係備份，hot spare 本身都要定期檢查健康，否則出事嗰陣先發現後備碟都壞，就等於冇後備。第三，有個別管理員指出，重建本身對已經處於危急狀態嘅陣列施加嘅壓力，可能大過先備份嘅壓力，自動重建可能喺你有機會做新鮮備份之前就殺死陣列。所以第 4 節嘅分流次序唔係多餘步驟，而係保命步驟。

重建時間方面都要有合理期望。有個別來源講，16TB 或者 20TB 碟嘅重建，係一段持續全碟讀取，可以由 12 個鐘去到幾日，期間剩低嗰啲碟長期接近全負荷。另一個指南估算，多 TB 陣列重建要 7 至 24 個鐘以上，視乎碟速、控制器效率同負載。RAID 5 重建往往要 12 至 24 個鐘，呢個數字來自個別指南，唔係廠方對所有陣列嘅承諾。時間愈長，窗口期愈長，呢個就係點解大容量碟陣列要更加小心，見第 6 節。

第 6 節：點解重建期間最危險，三種風險要分開講

好多人以為重建期間最危險，係因為第二隻碟會死埋。要分開三種唔同機制，否則讀者會以為只要第二隻碟冇死晒就冇事。

第一種風險係第二隻實體碟故障。RAID 5 或者 SHR-1 只可以承受一隻碟故障，重建期間第二隻再壞，陣列即失去重建所需資料。有個別來源講得好直接，重建期間陣列係以零冗餘運作，如果第二隻碟有潛伏壞扇區，重建失敗就會遺失數據。RAID 6 或者 SHR-2 可以承受兩隻，RAID 10 就要睇第二隻壞嘅係咪同一 mirror 組嘅另一半。RAID 10 重建係由同一 mirror 嘅生存碟讀取，唔使成個陣列計 parity，所以第二隻碟故障嗰陣，只有壞到同一對 mirror 嘅另一半先至會致命。分清楚呢點好重要，因為 RAID 10 嘅重建負荷同 RAID 5 完全唔同。

第二種風險係 URE，即係不可恢復讀取錯誤，都叫 latent sector errors。重建要由頭讀晒所有存活碟，只要入面有一個 stripe 讀唔到，就無法用 parity 還原嗰個 stripe。以下門檻數字全部有個別來源限定語，唔係肯定統計。個別來源建議嘅規格數字係，消費級 SATA 一般為每 10^14 bit 一次 URE，大約每 12.5TB 一次，企業級 SATA 或者 SAS 為每 10^15 bit 一次，大約每 125TB 一次。維基百科對 URE 嘅講法係，企業級碟嘅 unrecoverable bit error 率通常保證低於每 10^15 bit 一 bit，桌面級碟低於每 10^14 bit 一 bit。呢啲數字係規格上限，唔係時間表。

點解要強調上限同實測嘅分別呢？因為唔同來源用唔同假設計出唔同數字，抽一個當事實就會誤導。舉例，DS Security 試算，單隻 14TB 碟有 112 萬億 bit，7 碟 RAID 5 重建要讀大約 84TB，用 10^14 規格計，遇到讀取錯誤嘅機會大約 19%，DS Security 自述為每 5 次 RAID 5 重建就有 1 次因 URE 失敗嘅推論，呢個係 DS Security 嘅試算，唔係實測統計。Rossmann Group 講，4 碟 RAID 5、12TB 碟嘅全量重建，對照最壞情況規格，上限機率大約 62%，但係同時強調場上多數碟讀得遠超規格，真正主導因素係同批存活碟喺持續讀取負荷之下嘅相關機械故障。仲有一個較舊嘅例子，來自 Attingo，10^-14 嘅 URE 率，大約每讀 12TB 出現一次無法恢復錯誤，3 隻 500GB 碟嘅 RAID 5，重建統計失敗大約 8%，呢個例子年代同假設已經過時，唔好直接套落今日大容量碟。三個數字差咁遠，原因就係假設唔同，唔係邊個啱邊個錯，而係話俾你聽，單一機率數字唔可以當成你嗰個陣列嘅命運。

控制器對 URE 嘅反應都唔一樣，唔好寫一出 URE 就全滅。舊式同部分 HP Smart Array 會中止重建，現代 Dell PERC 同 LSI 或者 Broadcom MegaRAID 會將受影響 stripe 標記之後繼續，Linux mdadm 會記錄壞 block 之後繼續。結果可能只係個別 stripe 資料受損，而唔係全陣列離線。呢個分別好重要，因為重建失敗同個別檔案損壞，係兩個唔同層次嘅後果，處理方法都唔同。預防方向有來源支持，定期 scrubbing 背景掃描可以提早發現之後用冗餘重建壞 sector，降低重建嗰陣先撞到 URE 嘅風險，詳細見第 11 節。

第三種風險係重建本身對存活碟嘅負荷加時間。重建係陣列做過最高壓力嘅操作，要讀取每一隻存活碟嘅每一個 sector 嚟重新計算遺失數據。三個機制導致第二隻碟喺重建期間故障：URE、已經老化嘅碟喺持續負荷之下嘅機械壓力、ERC 或者 TLER 超時不匹配導致健康消費級碟俾踢出陣列。陣列入面嗰啲碟多數同時間買、同批生產、負載相近，傾向喺相近時間出問題。第一隻碟壞之後，剩低嗰啲已經累積相同開機時數，喺重建嘅連續順序負荷之下，勉強運作嘅磁頭組件可以故障。呢個就係第 7 節會再講嘅相關故障，唔好將佢當成巧合。

第 7 節：多盤同時故障，點分真壞、俾踢出、控制器問題

呢節係今輪新角度嘅核心，要用先分類、後決定嘅結構，唔好將所有兩隻碟紅燈寫成同一種情況。

情況 A：兩隻碟真係物理故障。徵狀參考包括有碟發出 clicking、grinding、scraping 聲，唔轉，BIOS 或者 UEFI 完全認唔到，SMART 完全讀唔到，水浸、火燒、撞擊歷史。決策好清楚，即刻停手，唔好再通電試。多碟物理故障要專業處理，DIY 通電只會加劇盤片損傷。呢個情況同第 4 節嘅停手訊號完全一致，見到就停，唔好諗住抄資料。

情況 B：第二隻碟仲讀得到，只係喺重建期間俾控制器踢出。機制係消費級碟冇 ERC 或者 TLER，讀取壞 sector 嗰陣會長時間重試，控制器等唔切就將佢標記為故障踢出。NAS 級碟例如 Seagate IronWolf、WD Red Plus 或者 Pro 有 ERC 或者 TLER 支援，可以較快回報錯誤，等陣列用 parity 處理，而唔係成隻踢走。重點係，俾踢出唔等於碟已死，但係喺未做 image 之前將佢強行插返入去再重建，係賭博，因為控制器可能用錯誤狀態覆寫 parity。個別來源對 RAID 5 或者 SHR-1 雙碟故障嘅離線恢復講法係，先用 write-blocked 方式逐隻做 image，再用未俾重建掂過嘅 stripe 嘅 parity 離線重建，重建中途嘅 stripe 會有新舊 parity 混合狀態，要鑑證分析先分得到。Synology SHR-1 雙碟故障嘅部分恢復概念要講明係部分，唔好寫全部救返。兩個故障碟都有份貢獻嘅 stripe 無法用 parity 重建，對應檔案會標記為無法存取，只有一個故障碟有份貢獻嘅 stripe 先可以用剩低成員同 parity 重建。

情況 C：兩隻碟同時顯示故障，但係根源係控制器、供電、背板、線材。控制器故障可以令多隻健康碟同時顯示為故障，令用戶喺 troubleshooting 嗰陣混亂，好多人喺呢個階段嘗試隨機 rebuild，導致不可逆轉損毀。檢查清單好簡單，先睇係咪全組碟同時跌出，定係逐隻先後跌出。全組同時跌出指向控制器、供電、背板，逐隻先後跌出指向碟老化或者 URE。睇 log 時間戳，唔好憑紅燈數量估。控制器問題詳細見第 8 節。

情況 D：SSD 或者 NVMe 快取碟出事，拖垮成個 NAS volume。Synology NAS 用 M.2 NVMe 做讀寫快取嗰陣，快取碟持有未提交嘅 dirty data 同 Btrfs metadata。SHR-1 重建嘅持續 I/O 期間，消費級 NVMe 可能過熱或者超過 TBW 壽命而離線。快取碟一消失，快取內未提交嘅 dirty data 同 Btrfs metadata 遺失，可令 volume 損毀或無法存取。重建永久停頓，volume 變得無法存取。提醒好清楚，NAS 唔好只睇 HDD 燈，快取碟、SSD pool 都係故障點，重建之前要一齊檢查 SMART 同溫度。

第 8 節：控制器、寫入快取、寫入漏洞，同碟壞完全唔同嘅處理

控制器死咗，碟可能完全健康。控制器故障嘅本質係，作業系統唔再知道點組裝陣列，碟本身健康，但係陣列唔見咗。換同型號替換控制器都唔一定解決，因為新控制器可能嘗試初始化陣列，而唔係讀取碟上現有配置。虛擬重建概念就係喺呢度發揮作用，控制器壞但係成員碟完好嗰陣，可以用軟件虛擬組裝陣列，讀取現有數據，唔使向原碟寫入。呢個同控制器重建嘅分別在於讀同寫，一個係抽取數據，一個係改寫陣列。個別公司自述嘅專業做法係，實驗室只係要裸碟，唔使控制器、伺服器 bay 或者外殼，佢哋會逐隻做 sector 級分析，推斷碟順序、stripe size、RAID 類型，再虛擬重建，即使客戶唔知自己用緊咩 RAID 都可以推斷。

寫入快取加電池備份故障，係最靜嘅數據遺失。機制係，寫入快取嘅數據喺未寫入碟之前，只係喺控制器記憶體入面。如果控制器用 write-back cache 而冇有效備份電源，斷電嗰陣快取入面嘅寫入就會遺失，而應用程式早已收到已寫入確認，呢種情況叫 lost write。單控制器陣列冇可靠嘅快取恢復機制去抵禦控制器故障，雙控制器陣列用 mirrored caching，先將寫入寫入兩個控制器嘅快取，確認之後先回報完成，一個控制器故障嗰陣，另一個可以將緩衝寫入碟。Intel 官方支援文件講明，斷電之後出現 controller cache was lost，volumes may be inconsistent，check-consistency required 訊息，通常發生喺 virtual drive 寫入政策設為 Always Write Back，而又冇接備份單元，或者備份單元已壞。Intel 明言 lost data cannot be recovered，之後步驟只係確認訊息同繼續開機，唔係救返遺失嘅快取數據。Dell PERC 文件講，TBBU 可以喺意外斷電嗰陣為記憶體模組提供最多 72 個鐘不間斷供電。換故障控制器嗰陣，要先關機之後拔走全部物理碟，將 TBBU 轉移到新控制器，新控制器一定要冇舊配置，開機之後控制器會將快取數據寫入 virtual disk。決策點好清楚，見到 cache lost 或者 battery failed 警告，唔好即刻撳掣繼續當冇事，要先理解邊啲寫入可能已遺失、邊啲 volume 要做一致性檢查，而且一致性檢查本身都會寫入，重要數據應該先評估備份或者離線抄出，再做檢查。

RAID 寫入漏洞 write hole，係斷電加碟故障一齊嚟先爆。定義係，部分 stripe 更新唔係原子操作。如果主機喺數據寫入同 parity 寫入之間斷電，碟上 parity block 就會同數據 block 唔匹配。之後有碟故障要重建嗰陣，重建會讀到過時 parity，將錯誤數據永久寫入重建碟。正常運作嗰陣未必察覺，因為控制器直接由數據碟讀取，損壞只會喺 degraded 陣列要靠過時 parity 重建嗰陣先浮現。緩解方法有幾個，硬件 RAID 用電池備份快取喺斷電之後寫回數據，Broadcom MegaRAID 喺電池低、故障、缺失、重新學習期間，會將 Write Back with BBU 政策轉為 Write Through。用 UPS 令伺服器喺電池耗盡之前乾淨關機，Linux mdadm 預設用 bitmap 防寫入漏洞，ZFS RAIDZ 用先寫 log 再寫陣列嘅方式避免寫入漏洞。寫入漏洞唔係每次斷電都發生，更加唔係 RAID 5 獨有嘅日常故障，要寫成斷電加之後再壞碟嘅組合風險。

Foreign configuration 係另一個常見陷阱。徵狀參考包括重建失敗之後 volume 顯示 0 bytes、檔案損壞或者缺失、碟標記為 Foreign Configuration、檔案系統顯示 RAW 或者未配置。決策係見到以上任何一種，即刻關機，唔好再寫入。每多試一次，覆寫可恢復數據嘅機會就大一分。仲要提醒，唔好將 import foreign configuration 同 clear foreign configuration 撈亂，前者係嘗試讀取舊配置，後者係清除佢。喺未做 image 之前，任何一個掣都唔好亂撳，要先影低畫面、記低原配置。

第 9 節：人為誤操作點分，誤刪、誤格式化、誤重建後果差好遠

好多人將所有唔見檔案講成同一回事，但係技術上完全唔同，救返嘅方向都唔同。以下對照表一定要分開睇。

表 4：人為誤操作對照

補充一點，刪除分割區通常只係抹走識別符，即係地圖，唔係數據本身，除非開新 volume、格式化空間或者繼續寫入數據，先會覆寫想救返嘅檔案。仲要再強調一次第 1 節嘅分別，重建係寫入還原冗餘，恢復係唯讀抽取數據。喺不穩定情況之下自動重建可以覆寫部分可讀 sector，永久破壞本來可以救返嘅數據。恢復軟件嘅正確流程參考係咁樣：停寫入、之後安全關機、之後標籤碟、之後逐隻做 clone、之後確認 RAID 參數，包括級別、stripe size、parity rotation、碟順序、邊隻缺失、之後虛擬重建、之後掃描檔案系統、之後將檔案抄去另一隻健康儲存裝置。呢個次序入面冇一步係喺原陣列上亂試。

第 10 節：RAID 對備份對照，備份還原同專業恢復係兩條路

RAID 嘅作用係可用性，唔係還原能力。多個來源用同一句說話劃清界線：RAID 負責令陣列喺死一隻碟之後仍然運作，備份先負責喺資料俾刪、加密、燒毀、浸水之後還原資料。講得再直接啲，RAID 保護你唔會因為死一隻碟即刻停工，但係對於誤刪、勒索軟件、成部機俾電湧打死，RAID 乜都做唔到。RAID 令磁碟故障唔會造成停機，但係會即時複製刪除同損壞，所以 RAID 係一份資料加更好嘅上線時間，而唔係兩份獨立資料。

表 5：RAID 對備份對照，邊種災難邊一層先救到你

3-2-1 規則一定要寫準定義：3 份，即係原檔加兩份備份；2 種唔同媒體，舉例 NAS 硬碟加外置硬碟，或者本地磁碟加雲端；1 份異地，即係同辦公室物理分隔嘅地點，火災、水浸、盜竊嗰陣唔受同一事件影響。3-2-1-1-0 進階版喺 3-2-1 之上再加：多一個 1，即係一份不可改或者離線或者氣隙副本，令勒索軟件即使取得管理員權限都改唔到、刪唔到；0 即係零錯誤，即係備份經過驗證、真正還原得到，唔係備份程式顯示成功就算。個別來源指出，現代勒索軟件會主動搵備份嚟破壞，全部 copy 都喺同一網絡入面就等於全部都暴露。以下 Sophos 調查數字已註明來源同年份，唔係今日香港統計：Sophos 2024 年 3 月報告講，大約 94% 勒索軟件受害者表示攻擊者曾經嘗試破壞備份，而呢啲嘗試入面，大約 57% 成功。

中小企落地嘅 3-2-1 組合可以咁樣諗，唔係唯一標準答案。第 1 份係辦公室 NAS 或者伺服器上嘅工作原檔，RAID 只係令佢唔會因為死一隻碟即停。第 2 份係另一部備份專用 NAS、外置硬碟、備份伺服器，排程自動備份，最好有版本保留同快照，應付誤刪。第 3 份係異地，雲端備份或者輪換式外置碟，每星期帶走一份，入面至少一份要做到不可改或者離線。第 0 步係定期做還原演習，抽一個檔案、抽一個資料夾、抽一次整機還原，確認備份唔係得個名。頻率原則來自個別來源，異地副本幾耐更新一次，答案係睇你負擔得起失去幾多時間嘅資料，即係 RPO 由老闆定，唔係由 IT 估。

決策樹邏輯如下：第一條分界係有冇可驗證備份。有備份，而且曾經成功還原測試過，優先用備份還原，唔好用故障陣列做實驗，備份還原係最快、最平、最少風險嘅路。有備份，但係從未測試過還原，先喺隔離環境試還原一個檔案或者一個資料夾，確認備份唔係空殼先再全量還原。好多中小企嘅備份失敗，係到出事嗰刻先發現備份根本還原唔到。冇備份，數據又重要，即刻停手，跳去專業評估，唔好用故障陣列做試下嘅重建。

自己處理得嘅情況一定要同時符合以下全部條件，缺一就停手。全部碟喺 BIOS 或者 UEFI 入面都認得到，冇異常聲音。SMART 數據讀得到，即使有少量錯誤，故障原因係控制器錯誤、metadata 損壞或者檔案系統損壞，而唔係物理損壞。陣列只係進入 degraded 模式，未完全故障，而且已經確認只有一隻碟故障，剩低嗰啲碟健康。已經做咗全部存活碟嘅 image，或者至少已經抄走最重要檔案去另一隻健康裝置，而且有 UPS 同穩定供電。以上只適用於已確認單碟故障、剩低嗰啲碟健康，而且已做 image 或已按第 4 節抄走最重要檔案去另一隻健康裝置嘅情況（開閘條件同第 3 節一致：未做 image、未按第 4 節抄走最重要檔案之前，唔好喺原陣列上撳重建）；如果唔確定，應該先停手。專業處理嘅典型流程如下，唔係 ComputerKing 流程：逐隻碟做 image，原碟唔改，之後由 metadata 或者 parity 特徵推斷 stripe size、parity rotation、碟順序、RAID 級別，之後虛擬重建，之後檔案系統恢復，之後驗證完整性，之後交付去安全裝置。仲要寫明，唔好寫送去專業就一定救返晒，專業評估先可以講到有幾大機會、要幾耐、要幾錢，評估之前唔好承諾。

第 11 節：香港實務，監察、買碟、溫度、UPS，樣樣都係日常功課

監察要分三層，缺一層都唔算監察完成。第一層係陣列狀態，包括 Storage Pool 或者 Volume 狀態，正常、Degraded、Rebuilding、Crashed。QNAP 廠方說明，儲存池狀態係 Degraded 嗰陣，意思係池入面有一個或者多個 RAID group 處於 degraded 模式，degraded 模式之下數據仲可以讀寫，但係通常效能會下降。重建期間儲存池效能都會下降。第二層係個別硬碟 SMART，見下面。第三層係系統記錄同警示，要開電郵或者推送通知，唔好只靠得閒登入睇下。有個別來源指出，好多 RAID 慘劇都係因為冇設定任何警示，直到太遲先發現問題。

SMART 要睇邊幾個數值，一定要寫屬性編號，唔好只寫健康良好。Reallocated Sector Count，屬性 5，非零即係硬碟已經將壞扇區映射去後備扇區，數字持續增長代表即將故障。Current Pending Sector，屬性 197，非零即係有不穩定扇區等候重新映射。趨勢比單次數字更加重要，數字一路上升先係最危險嘅訊號。溫度方面，個別第三方指南建議負載之下低過 50°C 為理想，但係呢個係指南建議，唔係廠方保證值，唔可以寫成超過 50°C 即會壞。SMART 測試種類方面，短測試做初步篩查，長測試或者擴展測試會逐扇區讀全碟，耗時以鐘計。以下數字係第三方估算，輕負載之下大約每 TB 要 1 至 2 個鐘，10TB 碟大約 10 至 20 個鐘，實際視乎負載而定，唔可以寫成廠方承諾。

Data scrubbing 或者 RAID scrubbing，係定期讀晒全陣列、驗證 checksum 或者 parity、早啲修復潛伏壞扇區嘅保養動作。佢嘅價值在於，重建嗰陣先發現 URE 就太遲。Synology 手冊講，RAID 或者檔案系統 scrubbing 係數據維護功能，會檢查儲存池之後修復任何檢測到嘅數據不一致，建議定期做 scrubbing，維持數據一致性，避免喺硬碟故障嗰陣遺失關鍵數據。QNAP 手冊講，RAID scrubbing 有助維持 NAS 上數據一致性，QTS 會掃描 RAID 5 或者 RAID 6 group 嘅 sector，自動嘗試修復任何檢測到嘅錯誤，QNAP 建議至少每月做一次 RAID scrubbing，維持系統健康，防止數據遺失。2026 年個別實務文章同樣建議每月做一次 data scrub，等潛伏壞扇區早啲俾發現同修復，唔好等到重建嗰陣先撞到。以下實務建議係操作建議，唔係廠方強制：每月一次 scrub，安排喺非繁忙時間，因為 scrub 期間讀寫速度會下降；每 3 至 6 個月做一次完整健康檢查；有 Warning 嘅碟唔好等到變 Failed 先處理，見第 5 節 QNAP 兩隻 Warning 碟嘅處理。

買碟陷阱要講 CMR 對 SMR。個別來源講得好直接，任何行 RAID、ZFS、Synology SHR、Unraid parity 或者任何冗餘陣列嘅 NAS，都應該買 CMR 碟，避免 drive-managed SMR。安全名單方面，2026 年 10 月覆核嘅個別來源列出 Seagate IronWolf 同 IronWolf Pro、WD Red Plus 同 WD Red Pro、Toshiba N300 同 N300 Pro 都係 CMR。應該避免放入陣列嘅例子包括普通 WD Red EFAX 2 至 6TB、WD Blue 3.5 吋 EZAZ、Seagate BarraCuda 4TB 同 8TB 3.5 吋、Toshiba P300 4TB 同 6TB。機制係 SMR 軌道重疊，改寫嗰陣要重寫鄰近軌道，長時間連續寫入或者重建嗰陣速度會急跌，後果可以係重建拖幾日，甚至新碟俾陣列踢出。驗證方法好重要，只睇品牌系列名唔夠，同一系列唔同容量可以唔同技術，一定要查確切型號嘅官方 datasheet。個別來源提醒，唔同容量嘅同一家族，轉速、快取、CMR 定 SMR 都可以唔同，所以要查確切型號 datasheet。NAS 級碟方面，韌體針對多碟震動、長時間運作同 RAID 環境調校，桌面碟喺 RAID 入面較容易因為超時俾陣列誤判踢出。

香港氣候同機房環境，以下門檻數字全部係個別來源建議，唔係廠方規格。香港屬於亞熱帶海洋性氣候，長期高溫高濕。機房或者伺服器房嘅參考範圍來自 ASHRAE TC 9.9，個別來源建議溫度範圍係 18°C 至 27°C，有助維持設備安全溫度條件。濕度方面，多個機房指南建議相對濕度大約 45% 至 55% 為佳，較寬嘅實務範圍為 40% 至 60%。溫度建議同樣係 18°C 至 27°C，目標大約 20°C 至 22°C。高濕嘅害處係結露會導致硬件腐蝕同提早故障，低濕嘅害處係靜電會損壞敏感元件。溫度同硬碟故障嘅關係方面，研究綜述指出，平均溫度喺大約 22 至 45°C 嗰陣平均故障率較低，長期高過 40°C 會令 3 年以上舊碟嘅故障率明顯上升，偶爾短時間升到 52°C 唔等於即時故障，但係長期高溫會縮短壽命。呢段係社群整理嘅舊研究綜述，唔係廠方規格。香港中小企實務陷阱由上述來源推論，寫明為實務推論，唔好偽裝成統計：NAS 塞喺冇冷氣嘅儲物室、窗邊、焗促嘅櫃入面，夏天室溫好容易超過 27°C 建議上限，兼且多碟本身發熱互相加熱；冷氣夜晚或者假期關掉，室溫急升急跌，濕度隨之波動，增加結露風險；塵加潮濕加高溫三者疊加，風扇同散熱效能下降，形成惡性循環。對策係保持通風、唔好塞櫃、定期清塵、裝溫濕度感應加超標警示、冷氣唔好喺假期全關，或者至少保持抽濕同通風。

以下 Backblaze 數字係大型數據中心機隊數字，唔係中小企保證，唔可以套用為中小企 RAID 恢復成功率。Backblaze 2025 全年 AFR 係 1.36%，較 2024 年 1.55% 下降，2025 年第 4 季 AFR 係 1.13%，終身 AFR 係 1.30%，樣本係 344,196 隻硬碟、30 個型號。機隊組成方面，14 至 16TB 碟佔 52%，20TB 以上碟佔接近 23%，首隻 26TB 碟喺 2025 年第 4 季投入服務。最可靠型號舉例方面，2025 年 WDC WUH722222ALE6L4 22TB，44,577 隻在役，全年 AFR 0.47%，Seagate ST16000NM001G 16TB，34,563 隻，AFR 0.54%，呢個係第三方報道整理 Backblaze 數據，樣本同年份已喺上面註明，唔可以寫成所有 WD 或者 Seagate 碟都係呢個故障率。個別來源仲指出，硬碟廠商話 AFR 好低，唔等於你嗰台 NAS 好安全，個別型號、舊碟、同批碟嘅風險可以高得多，而且 AFR 唔等於你嗰台 NAS 嘅故障機率。

UPS 對防雷拖板對照，係今輪指定要講清嘅分別，拖板只防突波，停電即斷，只有 UPS 先提供斷電緩衝。

表 6：UPS 對防雷拖板對照

個別來源講得好直接，突波保護器對於停電乜都做唔到，對於電壓過低乜都做唔到，佢只有一個工作，就係鉗制突波，而且呢個工作做得好，但係冇第二個工作。UPS 係一個有電池同腦嘅突波保護器，有市電嗰陣將電傳去設備，同時為內部電池充電，斷電嗰陣幾毫秒之內轉去電池。突波保護器做到嘅嘢，UPS 一般都做到，而且通常 joule 額定值更高，揀 UPS 唔會失去任何嘢，只會多咗保障。UPS 俾系統時間完成操作同乾淨關機，用一種突波保護器做唔到嘅方式保護數據完整性。突波保護器唔會防停電，佢設計嚟分流過高電壓，唔係提供後備電源，要喺停電期間繼續運行設備，就要用 UPS。

UPS 實務設定一定要寫齊，否則 UPS 等於冇裝。NAS 一定要插喺 UPS 嘅電池加突波插座，唔係只得突波嘅插座。用 USB 線連接 UPS 同 NAS，或者 SNMP 網絡方式，之後喺 DSM 或者 QTS 開啟 UPS 支援，確認 NAS 識別到 UPS 資訊。Synology 方面，開 Control Panel，去 Hardware & Power，再去 UPS 分頁，剔 Enable UPS support，將 UPS 類型設為 USB UPS，撳 Device Information 確認 NAS 同 UPS 真係溝通緊。QNAP 方面，插 USB 線之後，揀斷電之後 NAS 會關機定係進入自動保護模式。QNAP 廠方特別指出，不論設定幾耐，只要 UPS 剩低電量低過 15%，NAS 會喺斷電之後 30 秒之內自動關機或者進入自動保護模式。仲要開啟電力恢復之後自動重啟，否則 NAS 安全關機之後會一直停喺關機狀態，假期冇人撳掣就等於停機。UPS 運行時間期望要寫實，一般桌面 UPS 喺正常負載之下只提供大約 5 至 15 分鐘，設計目的就係夠時間存檔加安全關機，唔係發電機，唔係用嚟捱過幾粒鐘停電。防雷拖板嘅老化陷阱都要提，突波保護器嘅 joule 預算用完之後，外表同新嘅一樣、仍然通電，但係已經失去保護作用，個別來源建議按日曆更換，大約 3 至 5 年，或者經歷嚴重突波事件之後即刻更換，唔好睇外表判斷。UPS 電池本身都會老化，要定期做電池測試同按廠方建議更換電池，一台電池已死嘅 UPS 等於冇 UPS。多台 NAS 共用一台 UPS 嗰陣，要計算總負載，唔好超載，仲要確認主 NAS 嘅網絡 UPS 伺服器功能可以通知另外嗰啲 NAS 關機。

停電對 RAID 嘅傷害，寫入漏洞已經喺第 8 節講過，呢度補充香港辦公室實務提醒。大廈維修、跳掣、雷暴季節嘅短暫斷電加復電突波，係香港辦公室常見嘅組合風險。只裝防雷拖板而冇 UPS，NAS 會喺寫入中途硬斷電。停電本身未必即時燒硬件，真正嘅資料風險係寫入中途斷電同復電嗰陣嘅突波，如果斷電嗰刻啱啱寫緊碟，就可能出現損壞檔案或者損壞陣列。

第 12 節：價錢，香港收費需個別報價，海外價錢唔可以當香港價錢

呢節要守死一條線。研究報告講明，未搵到任何一間香港公司喺公開網頁列出港元 RAID 恢復價目表，所以文章入面關於 ComputerKing 或者香港收費，只可以寫需個別報價或者檢測之後先報價，唔可以寫任何具體港元數字。2014 至 2015 年一份 HKICPA 會員優惠 PDF 已經過期，唔可以當成 2025 至 2026 年價錢引用，今輪唔會再引用嗰份文件。

海外公司公開價錢只供背景理解，以下例子全部已註明公司名、地區、貨幣，只供參考，香港收費需個別報價。以下例子全部係該公司自述，唔係行業公價，更加唔係 ComputerKing 收費。Rossmann Group，美國，NAS 重建失敗之後恢復，該公司自述按碟分級，韌體損壞或者 URE 導致控制器踢碟，屬於韌體維修級 US$600 至 US$900，重建期間第二隻碟物理磁頭故障，屬於磁頭更換級 US$1,200 至 US$1,500，另加配對 donor 碟，只係要做 imaging 嘅健康碟，屬於簡單複製級 US$100，離線 RAID 重建、parity 分析、LVM 或者 Btrfs 檔案系統提取已經包括喺按碟價錢入面，無診斷費、無數據無收費，全部係該公司自述。$300 Data Recovery，美國，按碟收費，該公司自述，2 乘 1TB SATA RAID-0 係 US$600，4 乘 500GB SAS RAID-5 係 US$1,200，24 乘 3TB SAS RAID-6 係 US$12,000，如果完全無法恢復，唔收費。Guildford Data Recovery，英國，該公司自述，RAID 數據恢復服務固定起點 £500 加 VAT，免費診斷之後先有書面報價，之後先開始收費工作。呢啲數字點解差咁遠，原因就係價錢取決於故障類型、碟數、容量、係咪要 cleanroom 或者 donor 零件、工程師時間、緊急程度。恢復按碟計價，唔係按陣列一口價，即使只有一隻碟故障，實驗室仲要做 image 全部成員、分析 stripe 佈局、重建 volume。所以香港收費一定要寫需個別報價，檢測之後報價，批准之後先開始，絕對唔可以將任何海外 US$ 或者 £ 價錢直接寫成港元，更加唔可以寫 RAID 恢復一般 HK$幾多起，或者香港市價大約 HK$幾多，更加唔可以寫成功率幾多百分比。

第 13 節：常見誤解，逐句拆穿

1. RAID 就係備份，錯。RAID 只保護碟故障，唔保護多碟故障超出容錯、控制器故障、成部機或者環境故障，包括水浸、火災、盜竊，更加唔保護檔案系統損壞、惡意或者意外刪除或者修改，包括病毒、錯誤應用程式寫入、rm 錯檔案、喺現有檔案系統上 mkfs。

2. RAID 1 或者 RAID 10 鏡像就等於備份，錯。鏡像係即時複製，刪咗、損壞咗、加密咗，全部 mirror 即時一齊刪、一齊壞、一齊加密，備份先有時間點版本可以還原。

3. 有熱備援就萬無一失，錯。熱備援只係縮短 degraded 時間，唔係消除重建風險，熱備援只能保護有冗餘嘅邏輯碟，RAID 0 除外，預測性啟動都唔保證 100%，熱備援碟容量一定要至少等於要頂替嘅故障碟（混容量陣列以最大碟為準），介面一定要一致，專用熱備援喺故障之後重建加之後 copyback 返原位，令控制器搬數據嘅時間加倍。

4. 熱備援一插就即刻安全，錯。重建本身對已經處於危急狀態嘅陣列施加嘅壓力，可能大過先備份嘅壓力，自動重建可能喺你有機會做新鮮備份之前就殺死陣列。

5. NAS 顯示 degraded，撳個掣重建就搞掂，錯。QNAP 官方指引要求，兩隻碟同時警告嗰陣，先備份，再逐隻換、逐隻等重建完成，重建期間唔好移除另外嗰啲碟。

6. 逐隻換碟試下邊隻壞，錯。每次換碟、每次重建都係寫入，試錯本身已經喺度破壞原有佈局，正確做法係先睇 log、對序號、做 image，再決定。

7. RAID 5 壞一隻，換咗就即刻安全，錯。換碟只係重建嘅開始，重建完成之前陣列仍然係零冗餘，重建期間第二隻碟出 URE 或者故障，成個陣列可以崩潰。

8. RAID 6 就一定安全，錯。RAID 6 容 2 隻，但係重建時間更長、寫入懲罰更高，18TB 以上大碟，RAID 6 都有機會唔夠，呢個係 DS Security 嘅判斷。

9. 控制器換個新嘅就搞掂，錯。新控制器可能用唔同碟順序、唔識舊 metadata，甚至嘗試初始化，換控制器之前一定要先做 image、影低原配置，唔好直接喺原碟上試。

10. SSD RAID 同 HDD RAID 一樣救，唔同。SSD RAID 更加複雜，TRIM 會抹走已刪數據、wear leveling 會改變數據位置、控制器加密會增加難度，所以 SSD 陣列出事，DIY 空間更加細。

11. 同批碟一齊買好划算，壞咗先算，風險好大。成批買、成批裝、負載相近，傾向喺相近時間故障，中小企買碟應該考慮分批、做 SMART 監察、預留冷備援碟，而唔係等壞先買。

12. 備份放喺同一部 NAS 嘅另一個資料夾就夠，唔夠。同一部 NAS、同一控制器、同一電源、同一勒索軟件感染範圍，全部 copy 可以一次過無，offsite 或者離線 copy 先係分界線。

13. Degraded 仲用到，等得閒先處理，錯。Degraded 即係已經用晒安全網，重建期間零冗餘，拖延等於將自己暴露喺第二隻碟故障加 URE 之下。

14. 防雷拖板等於 UPS，錯。拖板只防突波，停電即斷，只有 UPS 先提供斷電緩衝加自動安全關機，見第 11 節表 6。

15. 有 UPS 就唔使備份，錯。UPS 防斷電寫入損毀，唔防誤刪、勒索、火災、成機俾盜。

16. 重建完成等於資料 100% 無損，錯。重建成功只代表陣列回復冗餘，仲要驗證關鍵檔案同檢查記錄，見第 5 節步驟 8。

第 14 節：中小企實務 Checklist，貼喺機房門口都得

每月做一次：登入 NAS 檢查儲存池狀態，正常、Degraded、Rebuilding；檢查每隻碟 SMART，屬性 5、197 係咪非零或者上升，溫度係咪異常；跑一次 RAID 或者檔案系統 scrub，QNAP 廠方建議每月一次；確認備份排程有執行、冇失敗記錄；確認 UPS 識別正常、電池狀態正常。

每季做一次：跑一次長 SMART 測試，安排喺非繁忙時間；抽查還原，隨機抽一個資料夾由備份還原，確認開得到；檢查機房或者 NAS 擺放位置嘅通風、溫度、濕度；檢查防雷拖板安裝日期，3 至 5 年到期即換。

每年或者按需要做一次：檢視硬碟年齡，3 至 4 年以上舊碟列入輪換預算，逐隻換、逐隻等重建完成；檢視 RAID 級別，碟容量已經升到 12TB 以上或者碟數已經增到 5 隻以上，考慮下次換機或者重建嗰陣轉 RAID 6 或者 SHR-2；做一次完整還原演習，包括異地備份；更新碟位記錄表，包括型號、序號、槽位、購買日期、保養到期日。

一出事，死碟或者 Warning，即刻做：即刻備份最重要資料，未備份先備份，唔好先換碟，呢句只適用喺第 4 節講嘅分流情況，如果見到第 4 節嘅停手訊號，就即刻停手，唔好抄；開閘條件同第 3 節一致：未做 image、未按第 4 節抄走最重要檔案之前，唔好喺原陣列上撳重建；用管理介面加 Locate 加 LED 確認壞碟槽位，影相、記低；插入等於或者更大容量嘅 CMR NAS 新碟去同一槽位；減輕負載，等重建完成，期間唔拔碟、唔斷電、唔亂撳初始化；重建完成之後驗證陣列狀態加抽查關鍵檔案；兩隻碟同時 Warning，逐隻換，每隻等重建完成先換下一隻；重建失敗、第二隻碟再壞、有異響，停手，保留原碟同原順序，尋求專業評估，收費需個別報價，唔可以即場估價。

最後講多次，今篇文章唔係教你點樣喺屋企用免費軟件救晒成個陣列，而係教你點樣喺最驚慌嗰刻，做出最少破壞嘅決定。停一停、分清楚、睇 log、影相、記低配置、確認備份、確認停手訊號，呢啲動作花嘅時間好短，但係可以保住之後好多選擇。相反，心急撳多兩下掣，好快就可以將一個本來可以處理嘅問題，變成冇得返轉頭嘅問題。公司資料值錢嘅地方，唔係喺硬碟值幾多錢，而係喺冇咗佢之後，公司要停幾耐、同埋有幾多嘢永遠搵唔返。呢個代價，喺撳掣之前諗清楚，永遠都比撳完掣之後先諗平得多。

常見問題 FAQ

Q1：RAID 5 壞 2 隻仲有冇得救？

正常重建救唔返，因為 RAID 5 只容 1 隻故障。超出上限唔等於數據一定全滅，但係要轉去離線虛擬重建或者專業評估，而且部分 stripe 有機會救唔返。見第 2 節同第 7 節情況 B，千祈唔好喺原陣列上再試重建。

Q2：重建失敗一次，仲可唔可以再試多次？

唔好。第一次失敗已經係訊號，話俾你聽陣列狀態唔穩定，再試一次只會再寫多一次，覆蓋更多本來仲有機會救返嘅資料，應該即刻停手，視之為專業恢復情況。見第 3 節。

Q3：換錯碟點算？

即刻停手，唔好再拔碟、唔好再撳重建、唔好初始化。影低現時碟位同畫面，記低邊隻碟本來喺邊個 bay、邊隻碟俾換錯，保留原碟同原順序，之後尋求專業評估。換錯碟本身已經可以將壞 1 隻變成壞 2 隻嘅局面，見第 5 節步驟 2。

Q4：控制器壞咗，係咪等於數據冇晒？

唔一定。控制器壞咗，碟可能完全健康，只係作業系統唔再知道點組裝陣列。喺成員碟完好嘅情況之下，可以用軟件虛擬組裝陣列，讀取現有數據，唔使向原碟寫入。換控制器之前一定要先做 image、影低原配置，唔好直接喺原碟上試。見第 8 節。

Q5：有備份，仲使唔使理 RAID？

要理。備份係還原資料嘅後路，RAID 係令陣列喺死一隻碟之後仍然運作嘅保障，兩者作用唔同。仲要記住，備份一定要試過還原先算數，從未測試過嘅備份，到出事嗰刻先發現還原唔到，就太遲。見第 10 節。

Q6：熱備援係咪等於備份？

唔係。熱備援只係縮短 degraded 時間，令重建早啲開始，唔係消除重建風險，更加唔係獨立資料副本。誤刪、勒索軟件加密、火災、水浸，熱備援全部擋唔到，只有異地或者離線備份先擋得到。見第 5 節同第 10 節。

Q7：防雷拖板係咪等於 UPS？

唔係。拖板只防突波，停電即斷，只有 UPS 先提供斷電緩衝，經 USB 或者 SNMP 通知 NAS 自動安全關機。NAS 一定要插喺 UPS 嘅電池加突波插座，唔係只得突波嘅插座，否則 UPS 等於冇裝。見第 11 節表 6。

來源連結

• recoverit.wondershare.com
• diskgenius.com
• techchef.in
• tapscape.com
• turbogeek.co.uk
• copyprogramming.com
• ds-security.com
• documentation.suse.com
• maple-hosting.com
• storagemath.org
• diskinternals.com
• datarecovery.com
• guildforddatarecovery.co.uk
• hetmanrecovery.com
• recoverhdd.com
• recoverit.wondershare.com
• qnap.com
• recoverit.wondershare.com
• rossmanngroup.com
• us.informatiweb-pro.net
• docs.oracle.com
• en.wikipedia.org
• attingo.com
• recoverhdd.com
• 300dollardatarecovery.com
• thefreelibrary.com
• intel.com
• manualshelf.com
• bracknelldatarecovery.co.uk
• rossmanngroup.com
• louwrentius.com
• data-recovery-basics.com
• techchefmadhuri.medium.com
• techchef.in
• vantagetech.com
• forums.tomshardware.com
• techchef.in
• technologyinc.in
• novabackup.com
• inventivehq.com
• managednerds.tech
• fixmypcstore.com
• editorialge.com
• raidisnotabackup.com
• diskinternals.com
• orderfactory.com
• medium.com
• mdrepairs.com
• pitsdatarecovery.com
• fivestardatarecovery.com
• scot-comp.co.uk
• ehelperteam.com
• netcomtech.co.za
• drivesaversdatarecovery.com
• qnap.com
• diskinternals.com
• backblaze.com
• ir.backblaze.com
• howtogeek.com
• howtogeek.com
• diskinternals.com
• bohrium.com
• fone.tips
• raid-recovery-guide.com
• dev.to
• zimaspace.com
• dosya.dev
• virtualitgroup.com
• veeam.com
• managedbackup.asia
• community.veeam.com
• pitsdatarecovery.co.uk
• startech.com
• ituonline.com
• wundertech.net
• manua.ls
• manua.ls
• docs.qnap.com
• wundertech.net
• smarttechbuying.com
• k7uutech.substack.com
• lsp.global
• raid-recovery-guide.com
• louwrentius.com
• computingforgeeks.com
• xda-developers.com
• xda-developers.com
• ontrack.com
• storware.eu
• newtechapac.com
• cc-techgroup.com
• manua.ls
• copyprogramming.com
• coursereps.upsu.net
• coursereps.upsu.net
• copyprogramming.com
• qnap.com
• hetmanrecovery.com
• qnap.com
• manua.ls
• copyprogramming.com
• community.spiceworks.com
• recolte-app.com
• dev.to
• medium.com
• xda-developers.com
• caitek.com
• community.spiceworks.com
• nascompares.com

相關文章

• 香港中小企 RAID 恢復：壞咗點算、邊啲嘢千祈唔好做
• 香港用家備份策略完整指南：3-2-1 法則點做先叫真備份？Time Machine、Windows、雲端同離線碟點分工
• 家用／細辦公室 NAS 點揀、點配、點備份？RAID、3-2-1 同遠程存取安全完整指南