如果碰到原本使用的 NAS 開機不起來，不論是電源故障或主機板故障需要送修，假設你臨時可以再買一台新的 NAS 或同處理器系列的 NAS，可是當資料很急，又不能等修好再用時，有沒有辦法可以無痛移轉硬碟到新 NAS 上呢 ? 或者是想把舊機器升級，有辦法無縫接軌，讓硬碟直接在新機器上恢復服務嗎 ?
這次 CyberQ 實測了新機 TVS-h877AX 和舊機 TS-473A，兩台都是 QuTS hero，也都是 AMD Ryzen 平台，最省事的作法就是把舊機上的四顆硬碟原封不動搬到新機器上。實際做下來，資料、帳號與設定全部都在，可說能無痛升級、無痛轉移或無痛資料救援，唯一的關卡是新機器出廠預設給的韌體比舊硬碟上的既有系統舊，因此開機後儲存池會被停用，這時只要把韌體升到同一版之後，錯誤訊息就消失了。
CyberQ 依照當天的系統事件記錄整理出完整時間序與做法，方便遇到同樣狀況的讀者能參考與對照。
測試環境
| 項目 | 來源機 | 目標機 |
|---|---|---|
| 機種 | TS-673A | TVS-h877AX |
| CPU | AMD Ryzen V1500B5（4 核 8 緒） | AMD Ryzen 5 7645（6 核 12 緒） |
| 記憶體 | 8 GB | 16 GB |
| 韌體 | QuTS hero h6.0.2.3591（20260819） | 出廠 QuTS hero h5.2.8.3309（20251105） |
| 儲存池 | 4 × 10 TB，RAIDZ1，約 36 TB | 原封不動搬入，插在 3 到 6 號槽 |
從硬碟上的事件記錄看，來源機最後一次成功運作是前一段時間，假設之後主機板或電源故障、無法開機，所以可檢查硬碟上的資料是否停在那次正常關機的狀態，這也是可以放心直接搬移的前提，如果是運作中突然斷電，搬移後，最好先做一次儲存池檢查。
若來源 NAS 是因主機板或電源故障而突然停止運作，即使將硬碟移至新機後順利辨識儲存池，仍建議先確認 RAID 群組與硬碟健康狀態，並檢查重要資料。必要時可透過 QuTS hero 的 Pool Scrubbing 驗證 ZFS 資料區塊的完整性。
若偵測到資料錯誤，只要原有 RAID 仍具備足夠的冗餘能力，ZFS 就有機會自動修復。反之，若硬碟已損壞、RAID 超過容錯上限，或資料區塊缺乏有效副本，則應優先備份可讀取的資料，再進一步進行磁碟更換或資料救援，避免貿然重建而增加資料遺失風險。
第一次開機：RAID 群組被停用
把四顆硬碟插進 877AX 開機後，桌面右下角的系統健康直接亮紅燈，寫著「RAID 群組 1：此磁碟區已停用」，儲存空間顯示 0 位元組。磁碟健康度本身是良好，四顆硬碟都看得到。
這時候值得注意的是，伺服器名稱顯示的仍是原本的「cyberq-673a」。QuTS hero 的系統設定存在硬碟上，所以新機器一開機就沿用了舊機器的身分，只是韌體還是 877AX 出廠內建的 h5.2.8。
韌體版本必須一致
QNAP NAS 上的通知中心裡的警告說得很清楚。事件記錄中的完整訊息如下（10:32:53）：
[Firmware Update] The drive has come from a device with firmware version 6.0.2 Build 20260819 but this device’s firmware version is 5.2.8 Build 20251105. The firmware versions must be the same to use this drive.
也就是說，硬碟上的系統是 h6.0.2 建立的，而 877AX 出廠韌體是 h5.2.8，只要兩者版本不同，系統就就不會掛載儲存池，這是 QNAP 設定的保護機制，不用擔心是硬碟或資料出了問題，此時不需要也不應該做任何初始化或修復動作，切記，不然原本好好的儲存池就會被搞掛了。
同一個畫面還會看到 App Center 的錯誤。系統設定是從 h6.0.2 帶過來的，App Center 會依照那份清單嘗試安裝或更新套件，但目前跑的是 h5.2.8，於是出現幾筆版本不相容的錯誤。事件記錄裡共有三筆：
| 時間 | 套件 | 錯誤訊息 |
|---|---|---|
| 10:33:02 | netmgr | 需將 QTS 降版到 6.0.0 或更舊的相容版本 |
| 17:41:12 | File Station 5 | 需將 QTS 降版到 5.9.9 或更舊的相容版本 |
| 17:42:03 | 授權中心 | 需將 QTS 降版到 5.2.99 或更舊的相容版本 |
這些錯誤看起來怪怪的，但都是韌體不一致造成的連帶現象，升級韌體之後就會自行消失，請不需要照字面去降版。App Center 當時另外列出 5 個必要更新與 3 個一般更新，也同樣等韌體處理完再說。
最重要的處理是手動選擇更新正確的韌體
進入「控制台 > 系統 > 韌體更新」，頁面上方的橫幅已經寫著有 h6.0.2.3591 Build 20260819 可用。
這裡有一個容易踩錯的地方，如果選了「檢查更新」，跳出的對話框推薦的是機器出廠預設韌體當下這個時間點的最新版本 h5.2.10.3577（標示為最新更新），而不是 h6.0.2。如果你選了升到 h5.2.10 仍然和硬碟上的 h6.0.2 不同，儲存池依舊不會回來。要點選橫幅上的「立即更新」，確認版本資訊是 h6.0.2 再繼續。
更新過程很快，事件記錄如下：
| 時間 | 事件 |
|---|---|
| 17:43:06 | 開始下載 h6.0.2.3591 |
| 17:43:22 | 下載完成並開始解壓、更新 |
| 17:43:59 | 系統更新完成 |
| 17:44:26 | 重新開機 |
| 17:47:57 | 系統啟動完成 |
從開始下載到重新開機完成大約 5 分鐘，非常快，接著就是等重開機，大概 6 到 8 分鐘會完成更新程序，可透過瀏覽器進到這台 NAS 的管理介面。
結果：資料與設定全部延續
重新開機後儲存池恢復正常，共用資料夾的內容都在。
以命令列確認儲存池狀態，四顆硬碟組成的 RAIDZ1 為 ONLINE，沒有任何讀寫或校驗錯誤。
pool: zpool1
state: ONLINE
config:
zpool1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
(四顆 10 TB 硬碟) ONLINE 0 0 0
errors: No known data errors不但如此，延續下來的不只是資料，還包括下面這些：
使用者帳號與密碼
原本的帳號直接可以登入，SSH 的主機金鑰也與舊機器完全相同。用戶端若以 IP 記錄主機，因為位址變了，第一次連線仍會詢問是否信任，但比對指紋可以確認就是原本那台。
共用資料夾、權限與 Container Station 的映像都還在。
伺服器名稱沿用舊名，要自己改，因此這次在 17:53 改成新名稱。
網路位址會變
新機器的網卡不同，DHCP 拿到的是新位址，原本寫死舊 IP 的用戶端與掛載點要記得更新。
App Center 的必要更新也跟著順利完成。myQNAPcloud、QTS SSL Certificate 與通知中心在韌體升級前（17:41）就已更新成功；先前報錯的授權中心，以及 File Station 6 與 SMB Service，則是在韌體升級後（17:51 到 17:52）更新完成，「請降版」的錯誤沒有再出現。
搬遷前的檢查清單
記下來源機的韌體版本
控制台的系統狀態，或 SSH 下的 /etc/os-release）。
確認目標機可以升到同一版韌體
新機出廠韌體通常比較舊，插上硬碟後看到「RAID 群組已停用」屬於預期，直接升級韌體即可。
升級時手動選擇與來源相同的版本
不要只看「檢查更新」對話框推薦的版本。
韌體一致前不要處理 App Center 的錯誤
那些「請降版」的訊息會在升級後自行消失。
不要在儲存池停用時執行任何初始化或修復
資料並沒有損壞，所以這時候不要作其他的額外操作，不然資料就會被用戶自己搞掛。
搬遷後更新 IP 與主機名稱
檢查依賴舊 IP 的 NFS 掛載、備份工作與監控設定。
CyberQ 認為，整體來說，同為 QuTS hero 的機種之間搬硬碟非常順利，從第一次開機看到紅字，到資料全部回來，真正花時間的只有一次約 5 分鐘的韌體更新，重開機，進入管理介面後把 App Center 標示為需要更新的 App 做完更新即可。
以這次 QNAP TVS-h877AX 接手 TS-473A 的四顆硬碟為例，萬一儲存池檢查真的發現問題，並不代表資料就救不回來。實際上，要看的是錯誤發生在哪一層，以及原本的 RAID 是否還有足夠的容錯能力。
兩台 NAS 都採用 QuTS hero，底層是 ZFS，而不是一般 QTS 使用的 ext4。ZFS 的 Pool Scrubbing 會逐一驗證資料區塊的校驗碼（Checksum），發現資料損毀時，若還有正確的冗餘資料，就能嘗試自動修復，這與傳統的檔案系統檢查不同。
但有一個重要前提，ZFS 能發現資料錯誤，不代表一定能修復。 RAID 1、RAID 5、RAID 6、RAID 10 等不同設定下，能承受的故障情況也不同，以下是 CyberQ 實務上處理過和類似經驗的彙整。
儲存池檢查可能遇到的 7 種情況
| 檢查結果或狀況 | 可能原因 | 建議處理方式 |
|---|---|---|
| 1. 檢查完成，沒有錯誤 | ZFS 校驗碼正常，未發現資料區塊損毀 | 不必修復。再確認重要檔案、共用資料夾及應用程式能正常使用 |
| 2. 發現錯誤，但已自動修復 | 部分資料區塊損毀，但 RAID 仍保有正確的冗餘資料 | ZFS 自動修復後，檢查硬碟健康狀態及錯誤是否持續增加。若再次發生，需追查原因 |
| 3. RAID 降級（Degraded） | 一顆或多顆硬碟故障，但尚未超過 RAID 容錯能力 | 先確認備份，再依 QNAP 程序更換故障硬碟，等待 RAID 重建（Resilvering）完成 |
| 4. 發現無法修復的資料區塊 | ZFS 找不到正確副本，或 RAID 冗餘不足 | 確認受影響檔案，從有效的快照或獨立備份還原；無法保證完全修復 |
| 5. 儲存池唯讀（Read-Only） | RAID 容錯能力可能已耗盡，或發生嚴重儲存問題 | 優先搶救仍可讀取的資料，不要貿然拔除硬碟或強制重建 |
| 6. 儲存池無法啟用（Inactive） | 硬碟未被辨識、RAID 成員缺失、磁碟連線異常或儲存池損毀 | 先檢查韌體、硬碟辨識與連線。若屬於暫時斷線，可依官方流程嘗試恢復 RAID，若為實體故障，應先評估資料救援 |
| 7. Scrubbing 無法執行或中途失敗 | 可能是磁碟 I/O 問題、儲存池未正常掛載，或其他維護工作衝突 | 查看系統事件記錄，排除原因後再執行，不要反覆強制重試 |
上述狀態與處理原則，可參考 QNAP 的 儲存池狀態說明、磁碟狀態與使用類型、RAID 群組狀態，祝福大家更換 NAS、資料遷移與資料復原都能順利，平時也要做好 3-2-1 備份原則的實作喔。
