NAS 不是備份!

今天我從 QNAP 得到了一個非常有趣且具有啟發性的教訓:NAS 並不是備份,NAS 本身也需要備份。這種情況也可能發生在你身上。

我最近剛完成了對我的儲存空間進行 RAID 重整(scrubbing)。以前從未做過。由於遇到了一些問題,我將傾印日誌提交到工單。技術人員回覆我,告訴我有許多 ZFS 檔案系統錯誤無法修復,必須重新初始化 NAS,從頭開始!

這並不是因為硬碟損壞(錯誤出現在我的 SSD 和主要 RAID 硬碟上)。他說這種情況也會發生在良好的硬碟上,有時資料在寫入時會損毀,這是無法避免的。他說一定要確保你的資料都已經從 NAS 備份到其他地方,然後重新初始化並重新開始!我簡直不敢相信。

所以——再次提醒——NAS 本身並不是備份。你也許會將電腦備份到 NAS,但也要將 NAS 備份到其他地方!造成問題的不一定是硬碟損壞。

我真的很期待要做這件事!至少,我會回到 h5.2,因為 h5.3 真的還沒完成,而且只適合高可用性(High Availability)應用……

1個讚

這就是為什麼我一直對 Quts 以及它在背景中執行的所有操作感到有所疑慮。我最近曾考慮升級到 Quts,但目前我還是會繼續使用 Qts。

正確來說,NAS 絕對不是備份的可靠方式。RAID 也不是備份。因此才有 321 原則。這可能是擁有 NAS 和 RAID 時最大的誤解。他們能讓恢復時間最小化,但僅靠這些無法讓你免於火災或硬體故障的損失。

2個讚

無論是 QNAP、Syno 還是其他任何品牌

從來不是,也永遠不會是

如果 NAS 是備份(資料的副本),那麼 NAS 就是備份,可以從原始檔案重建

1個讚

我在2024年底購買了一台全新的TS-464C2,結果在一個月內就毀掉了我整個儲存池。我切換到QuTS Hero後,很快就在所有硬碟上發現了校驗和錯誤,這讓我意識到是NAS的問題,經過memtest(記憶體測試)證實了我的想法。

更糟的是,我從廠商那裡換了一台全新的設備作為替換,結果也有記憶體問題……

我每天都有雲端備份,所以只損失了幾個小時的資料,但復原卻花了我好幾天。

對於正在運行 QuTS Hero 的用戶,我建議定期開啟 SSH 連線並執行以下指令:

zpool status -v

以下是執行結果範例:

[Jono@NA9D-NAS ~]$ zpool status -v
  pool: zpool1
 state: ONLINE
status: 一個或多個裝置發生錯誤,導致資料毀損。應用程式可能會受到影響。
action: 如果可能,請還原相關檔案。否則請從備份還原整個儲存池。
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub 在 0 天 00:15:53 內修復 0 筆,於 2025 年 10 月 19 日 00:15:58 發現 2 個錯誤
 prune: 上次修剪 409 筆,累計修剪 2392 筆
        總修剪次數 #5,平均修剪速率 = 2986468 (entry/sec)
expand: 無請求
 renew: 無請求
config:

	NAME                                    STATE     READ WRITE CKSUM
	zpool1                                  ONLINE       0     0     2
	  mirror-0                              ONLINE       0     0     4
	    qzfs/enc_0/disk_0x1_24074767F6C0_3  ONLINE       0     0     4
	    qzfs/enc_0/disk_0x2_24534D52401A_3  ONLINE       0     0     4

errors: 在下列檔案中偵測到永久錯誤:

        zpool1/$SHADOW:<0x1> (181:1:0:5046392)
        zpool1/$SHADOW:<0x1> (181:1:0:5046393)

  pool: zpool2
 state: ONLINE
status: 一個或多個裝置發生錯誤,導致資料毀損。應用程式可能會受到影響。
action: 如果可能,請還原相關檔案。否則請從備份還原整個儲存池。
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub 在 5 天 04:25:26 內修復 0 筆,於 2025 年 10 月 24 日 04:25:37 發現 16 個錯誤
 prune: 上次修剪 2637224 筆,累計修剪 15879437 筆
        總修剪次數 #5,平均修剪速率 = 3490183 (entry/sec)
expand: 無請求
 renew: 無請求
config:

	NAME                                        STATE     READ WRITE CKSUM
	zpool2                                      ONLINE       0     0   364
	  raidz1-0                                  ONLINE       0     0   728
	    qzfs/enc_0/disk_0x3_5000CCA27EC5F5A5_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x4_5000CCA267CD00FE_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x5_5000CCA273F0B2D9_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x6_5000CCA27EC5A850_3  ONLINE       0     0     0

errors: 在下列檔案中偵測到永久錯誤:

        zpool2/$SHADOW:<0x1> (181:1:0:29628189)
        zpool2/$SHADOW:<0x1> (181:1:0:764458)
        zpool2/$SHADOW:<0x1> (181:1:0:12855854)
        zpool2/$SHADOW:<0x1> (181:1:0:784706)
        zpool2/$SHADOW:<0x1> (181:1:0:57489228)
        zpool2/$SHADOW:<0x1> (181:1:0:57232981)
        zpool2/$SHADOW:<0x1> (181:1:0:57499738)
        zpool2/$SHADOW:<0x1> (181:1:0:5362782)
        zpool2/$SHADOW:<0x1> (181:1:0:1036430)
        zpool2/$SHADOW:<0x1> (181:1:0:5493137)
        zpool2/$SHADOW:<0x1> (181:1:0:5355174)
        zpool2/$SHADOW:<0x1> (181:1:0:57241256)
        zpool2/$SHADOW:<0x1> (181:1:0:30161860)
        zpool2/$SHADOW:<0x1> (181:1:0:5499856)
        zpool2/$SHADOW:<0x1> (181:1:0:754404)
        zpool2/$SHADOW:<0x1> (181:1:0:13872636)

1個讚

我以前也遇過那些錯誤,但那已經是很久以前的事了。我不記得是怎麼修好的,可能是刪除並重新建立 RAID。我覺得那些錯誤發生在我的 UPS(不斷電系統)有問題的時候,當時常常有短暫的停電,電力會掉一到兩秒。自從我換了一台更好的 UPS 之後,就再也沒遇過這種情況了,而且我的一些硬碟已經運作了八年,還有一些是比較新的,像是兩到三年。

如果你有電力瞬間下降的情況,UPS 需要一點時間才能供電給 NAS,這可能就是造成錯誤的原因。

我多年來一直在教育我的客戶這件事,因為我曾經在 Netgear NAS 的 RAID 陣列崩潰時丟失過一些資料,後來同樣的事情又發生在我的 Synology NAS 上,但幸運的是,目前我的 QNAP NAS 設備還沒有發生過。不過,任何事情都不能掉以輕心,3-2-1 備份原則非常重要,因此我把主 NAS 上的所有資料都備份到次要 NAS 上。

順便說一下,我試過你的程式碼,看起來沒問題。
zpool1 和 zpool2 結果 → 錯誤:未發現已知資料錯誤

1個讚

@marcoi - 我這邊沒有遇到任何電力波動或類似的情況。誰知道呢。我的另一台 hero NAS 也都正常。正如 QNAP 技術人員告訴我的,發生原因不明。可能只是寫入時某些東西被損壞了。

好的。現在我要把這台傢伙恢復原廠設定,緊張指數爆表!

:grimacing:

我剛剛翻查了我過去 QNAP 工單的舊郵件。這件事其實發生在 2021 年,然後看起來他們在 2022 年時透過韌體修復了這個問題。

以下是工單內容

經過檢查,RD 團隊表示我們看到的錯誤代表永久性的 pool(儲存池)錯誤,遺憾的是無法修復,所以唯一的解決方法是建立新的 pool。
如果你的資料已經有備份在其他地方,那你只需要把原始資料複製回新的 pool 就可以了。如果沒有備份,那你可以把資料從這個 pool 複製出去,系統會自動跳過任何已損毀的檔案。

建立新 pool 後,團隊建議你排程每月執行 Pool Scrubbing(儲存池檢查),以防止這類問題再次發生(而不是事後才修復)。

簡單更新一下,團隊認為這不是硬體問題,但他們還不完全確定問題原因。
檔案系統的 “SHADOW” 層似乎發生了某種未知的損毀,但他們還在調查損毀的原因。

看起來會有一個新的 h5.0.0 韌體版本,預計在 3/31 發布,這個版本會修復 pool 損毀的問題。
我還在跟他們要更多資訊,但目前看來修復應該很快就會推出。

很抱歉回覆晚了,我正在跟團隊確認一些資訊。
我被告知很快會有新的 h5.0.0 韌體更新,預計幾天內發布,這個韌體可以防止未來的 pool 再次損毀。

如果已經有損毀的資料,目前似乎沒有辦法修復,但未來會有 h5.0.1 版本,可以清除現有 pool 的錯誤,讓它們能正常運作。

請留意即將推出的更新,如果有任何問題,請告訴我。

所以自從 2022 年以後我就沒再遇到這個錯誤了。

不太確定。這台 NAS 是去年底購買的,Hero 大約在四月或五月安裝在上面。

我在想是不是我升級到 h5.3 的時候出了什麼問題。

我現在要回到 h5.2,因為我不需要 HA。

這是有可能的。這取決於你對「備份」這個詞的理解。如果你認為只要有一份資料副本或只用一個裝置儲存你的資料就足以保障備份安全,那麼墨菲定律會讓你明白事實並非如此。321原則只是最低標準。