TrueNAS báo pool DEGRADED: chẩn đoán đúng rồi mới thay ổ

Pool DEGRADED là gì, và vì sao chưa nên đụng tay

TrueNAS báo pool DEGRADED, và phản xạ đầu tiên của đa số chúng ta là mở tab shop đặt ổ mới. Cất thẻ vào đã. DEGRADED nghĩa là pool ZFS vẫn chạy, dữ liệu vẫn đọc được, nhưng đã mất một phần dự phòng.

Cái khó là cùng một cảnh báo có thể do ổ chết, cáp lỏng, HBA trục trặc hoặc RAM lỗi. Đoán sai, nhẹ thì mua ổ oan. Nặng thì rút nhầm ổ còn sống, và pool sập thật.

Chẩn đoán đúng giúp bạn:

• Giữ được tiền mua ổ nếu thủ phạm là cáp, HBA hoặc RAM.
• Tránh dùng zpool clear để che một ổ đang hỏng dần.
• Rút đúng ổ, nhờ đối chiếu bằng serial thay vì tên sdX.
• Biết chính xác file nào đã mất để khôi phục từ backup.

Vài tình huống để thấy vì sao không nên vội:

• Ổ báo lỗi nhưng chưa chắc hỏng. Một thread trên forum TrueNAS kể về ổ FAULTED với 300 lỗi ghi, sau reboot chỉ resilver 6,64 GB rồi về ONLINE. Người hỗ trợ xem SMART và FARM không thấy lỗi đủ nặng. Đặt ổ mới ngay lúc đó là kết luận khi chưa đủ chứng cứ.
• Lỗi nghi do cáp quá dài. Ở một trường hợp khác, sau scrub và khởi động lại, các ổ hết báo lỗi nhưng vẫn còn một lỗi báo mất file. Bộ đếm về 0 không có nghĩa là file đã được cứu.
• NAS gia đình RAIDZ1 chưa có backup, một ổ chết. Chép ảnh và giấy tờ quan trọng ra ngoài trước, Replace sau. Làm ngược lại là đem cả album gia đình ra đánh cược với một đợt resilver.

Ai đến từ Synology sẽ thấy khác ngay: Storage Manager dẫn bạn qua thao tác Repair, còn TrueNAS bắt bạn tự đọc chẩn đoán. Đổi lại, nó cho biết lỗi của từng ổ và từng file. Mới làm quen với hệ này thì đọc thêm TrueNAS là gì.

Bài này bám TrueNAS Community Edition 25.10.8 "Goldeye", bản ổn định mới nhất (phát hành 5/11/2026). TrueNAS 27 mới ở 27-RC.1, bản 27.0 dự kiến đầu 12/2026, máy production nên chờ. CORE không còn phát triển tích cực, nên bài chỉ ghi chỗ khác biệt theo tài liệu 13.0.

Quy trình này chỉ dành cho pool có dự phòng. Stripe mất một ổ là mất toàn bộ dữ liệu.

Việc đầu tiên: chưa rút, chưa clear, chưa reboot

Mở System > Shell, chạy lệnh dưới rồi lưu output lại. Cộng đồng báo bộ đếm có thể về 0 sau reboot hoặc export (chưa thấy văn bản OpenZFS xác nhận), nên đây có thể là bằng chứng duy nhất bạn còn.

sudo zpool status -v <pool>

Sau đó kiểm backup, trước mọi việc gây tải. Xem lần chạy gần nhất ở Data Protection (Replication, Cloud Sync, TrueCloud Backup) và thử khôi phục một file. Snapshot nằm cùng pool không thay được backup, vì pool mất thì snapshot đi theo.

Chưa có backup thì chép dữ liệu quan trọng ra ngoài trước khi resilver. Tài liệu TrueNAS (bản 24.10) khuyên tránh replication, SMB, NFS, rsync, test SMART và scrub trong lúc resilver, nên để sau là muộn.

Đọc output của zpool status

Dòng dưới là log thật từ forum. Ba con số lần lượt là READ, WRITE, CKSUM. Để ý tên ổ là partuuid, không phải sdX, lát nữa còn phải map sang serial.

ef694f04-9d55-49a2-9ad2-f7d4c419f832  FAULTED  63  300  0  too many errors

• READ/WRITE: lỗi I/O khi đọc hoặc ghi.
• CKSUM: ổ trả về dữ liệu sai mà không báo lỗi.

Cái bẫy nằm ở CKSUM. Khi một khối không thể tái tạo, CKSUM được ghi cho mọi ổ chứa khối đó (zpoolconcepts). Thấy số đều trên nhiều ổ kèm permanent errors thì đừng vội kết luận cả dàn ổ cùng hỏng.

Ngưỡng mặc định trên Linux là 10 lỗi trong 600 giây (vdevprops), trên CORE là hơn 50 lỗi trong 60 giây (zfsd). Nhãn FAULTED cho biết số lỗi đã vượt ngưỡng, chưa cho biết lỗi xuất phát từ đâu.

Cây quyết định: lỗi nằm ở đâu

1. Dòng errors: có Permanent errors? Có thì xử lý nhánh P, đồng thời đi tiếp câu 2.
2. Có bao nhiêu ổ mang số khác 0? Nhiều ổ thì vào nhánh H, một ổ thì sang câu 3.
3. Ổ đó ở trạng thái nào? REMOVED hoặc UNAVAIL thì vào nhánh R. FAULTED, DEGRADED hoặc ONLINE có lỗi thì vào nhánh S.

Đọc SMART trong Shell

Nhánh H và S đều cần SMART. Giao diện SMART đã bị gỡ ở 25.10, GUI chỉ còn thẻ Disk Health, nên phải đối chiếu trong Shell. Forum TrueNAS có nhắc sẽ đưa lại một phần, chưa rõ ở bản nào. Test long cũng tăng tải, nên chỉ chạy sau khi đã kiểm backup.

sudo smartctl -a /dev/sdX        # CORE: /dev/ada0 hoặc /dev/da0
sudo smartctl -t long /dev/sdX   # test dài

Ngưỡng theo flowchart chính thức của TrueNAS, tính trên giá trị raw:

• ID 197 trên 5: test long fail thì thay. Pass thì theo dõi, số tăng liên tục thì thay.
• ID 199 đang tăng: đây là lỗi kết nối, chưa phải lúc thay ổ.
• ID 10: kiểm tra nguồn trước, trừ khi ổ quay lên xuống liên tục.
• ID 1 và 7 trên ổ Seagate: raw lớn là bình thường, tính theo flowchart rồi mới kết luận.

Nhánh H: lỗi rải trên nhiều ổ, chưa mua ổ vội

Nhiều ổ cùng hỏng một lúc là chuyện hiếm. Một thứ chúng dùng chung bị lỗi thì dễ xảy ra hơn nhiều. Xem log và sơ đồ controller:

sudo dmesg | grep -iE "ata|sas|reset|timeout"
ls -l /dev/disk/by-path/      # ổ nào sau controller nào
sudo dmesg | grep -i edac     # lỗi RAM ECC

• ID 199 tăng: nghi cáp hoặc backplane (theo flowchart).
• Lỗi chỉ ở các ổ sau cùng một HBA hoặc backplane: nghi phần đó (kinh nghiệm cộng đồng).
• Không có CRC, không có reset, lỗi trải trên nhiều controller: nghi RAM. Cộng đồng khuyên chạy MemTest86 khoảng 4 lượt, tắt XMP. Flowchart chính thức không có nhánh RAM.
• Ổ rớt rồi hiện lại khi tải cao: nghi nguồn (kinh nghiệm cộng đồng).
• Đang dùng card RAID: chuyển sang HBA/IT mode, đây là khuyến cáo chính thức.

Sửa xong thì scrub, clear, rồi scrub lại. Nếu thủ phạm là RAM, dữ liệu có thể đã hỏng trước khi tính checksum nên scrub không phát hiện được. Dữ liệu quan trọng thì đối chiếu với backup.

Nhánh R: ổ biến mất

Mã thường gặp là ZFS-8000-2Q. Kiểm tra cáp, nguồn, cắm lại, đổi cổng. Ổ hiện lại thì đưa về pool, resilver thường chỉ chép phần thiếu:

sudo zpool online <pool> <ổ>

Ổ vẫn không xuất hiện thì sang phần Replace.

Nhánh S: lỗi tập trung ở một ổ

Mã thường gặp là ZFS-8000-9P.

• SMART xấu theo bảng trên: Replace.
• SMART sạch và đã rõ nguyên nhân tạm thời: clear theo điều kiện ở mục sau.
• SMART sạch mà chưa rõ nguyên nhân: đổi cáp hoặc cổng. Lỗi đi theo ổ là do ổ, ở lại cổng là do đường truyền. Mẹo này là kinh nghiệm chung, không có trong flowchart.

Nhánh P: permanent errors

Mã thường gặp là ZFS-8000-8A. ZFS không tự sửa được các file trong danh sách này, cách duy nhất là khôi phục từ backup.

• Đường dẫn file bình thường: hỏng dữ liệu thường, thường xóa được.
• Dạng dataset:<0x1ea>: cộng đồng cho biết dạng này thường xuất hiện sau khi file đã bị xóa, hoặc liên quan metadata.
• File còn nằm trong snapshot: theo cộng đồng, phải xóa cả các snapshot đó.
• Hỏng metadata toàn pool: theo tài liệu chính thức, phải hủy pool và dựng lại từ backup.

Trình tự: khôi phục hoặc xóa file, scrub, clear, scrub lại.

Khi nào mới được zpool clear

zpool clear là lệnh dễ gây nghiện nhất trong ZFS. Gõ một phát, số lỗi về 0, tâm hồn thanh thản, rồi lần scrub sau lỗi quay lại vì nguyên nhân còn nguyên. Chỉ clear khi đủ cả ba điều kiện:

1. Đã rõ và đã sửa nguyên nhân.
2. Scrub không làm số lỗi tăng thêm.
3. SMART không xấu.

sudo zpool clear <pool> [<ổ>]
sudo zpool scrub <pool>

Clear sớm còn làm mất dữ liệu theo dõi xu hướng, thứ bạn cần để biết ổ có đang xấu dần không. Tài liệu 25.10 không nhắc nút Clear nào nên ở đây dùng lệnh. Lỗi vẫn tăng sau hai lần lặp thì backup, ghi lại tên file hỏng và xin trợ giúp.

Xác định đúng ổ vật lý

• Ổ còn thấy: đọc Serial trong Disk Info, hoặc map partuuid sang serial bằng lệnh dưới.
• Ổ đã mất: giao diện có thể không còn thông tin. Lúc đó dùng phép loại trừ: so serial của mọi ổ còn thấy với nhãn trên ổ. Alert có thể kèm serial, nhưng từng có báo cáo sai nên vẫn phải đối chiếu.
• Máy không hot-swap: tắt máy, đọc nhãn, kiểm tra lại serial rồi mới thay.

sudo lsblk -o +PARTUUID,NAME,LABEL,SERIAL   # SCALE/Community Edition
glabel status                               # CORE: map gptid

Thay ổ bằng Replace trên 25.10.8

Dùng GUI thay vì zpool replace, lệnh đó để dành khi GUI lỗi. Lý do thực tế: Disk Info hiện serial và model ngay trên màn hình thao tác. Replace cũng tự wipe ổ mới rồi resilver, và chặn ổ còn phân vùng hoặc dữ liệu nếu chưa bật Force.

Đường vào khác nhau theo bản, nên đừng bám menu trong các hướng dẫn cũ:

• 25.10.x, 27-RC.1: Storage Dashboard > widget VDEVs > View VDEVs > mở VDEV > chọn ổ.
• 24.10, 25.04: Storage Dashboard > widget Topology > Manage Devices.
• CORE 13.0: Storage > Pools > biểu tượng bánh răng > Status > ⋮ của ổ.

Các bước theo tài liệu Replacing Disks 25.10:

1. Chuẩn bị ổ mới có dung lượng bằng hoặc lớn hơn, không thuộc pool nào. Ổ này sẽ bị xóa sạch.
2. Vào View VDEVs, chọn ổ, ghi lại serial.
3. Bấm Offline trong widget ZFS Info.
4. Thay ổ vật lý.
5. Bấm Replace trong Disk Info. Trong hộp thoại Replacing disk, chọn Member Disk, chỉ bật Force khi chắc chắn. Preserve disk description mặc định bật. Bấm Replace Disk.
6. Theo dõi đến khi pool về Online, nhớ refresh màn hình để thấy số mới.

Nếu có hot spare, dùng Detach ổ hỏng để spare thành thành viên chính thức, rồi tạo spare mới qua Add VDEV. Cách này tránh hai lần resilver.

Ổ thay thế nên là CMR, vì Hardware Guide 25.10 ghi ổ SMR có thể làm resilver chậm và kém tin cậy hơn. Cùng một dòng sản phẩm có thể có cả model CMR lẫn SMR, nên tra mã model trên datasheet trước khi mua.

Burn-in thì sao? Mình thấy đây là đánh đổi: burn-in nhiều ngày cũng là kéo dài thời gian pool thiếu dự phòng. Với RAIDZ1 hoặc Mirror 2 ổ, tốt nhất có sẵn một ổ đã burn-in. Chưa có thì ít nhất đọc SMART ổ mới, rồi cân nhắc theo tình trạng backup.

Resilver: rủi ro theo từng layout

Resilver chỉ xử lý dữ liệu ZFS biết là đã lỗi thời, không chép toàn bộ dung lượng ổ (zpool-scrub). Mình không đưa con số thời gian nào, vì ETA ban đầu rất thô, tốc độ giảm khi pool đầy và phân mảnh, và RAIDZ resilver nhiều ngày không hiếm.

Bảng dưới tính sau khi đã mất 1 ổ, ổ hỏng thêm nằm cùng vdev:

Đó là lý do bước kiểm backup đứng trước Replace. Còn chuyện chọn layout thì xem bài mở rộng RAIDZ, có bảng dung lượng Mirror/RAIDZ.

Lỗi hay gặp

• Thấy CKSUM nhiều ổ là mua ổ hàng loạt. Thủ phạm mà là sợi cáp thì nó vẫn nằm đó chờ dàn ổ mới. Chạy nhánh H trước.
• Rút nhầm ổ còn sống. Cắm lại ngay, đừng bấm Replace trong lúc hoảng. Pool bị suspend có thể quay lại bằng zpool clear nếu các ổ truy cập được.
• "Disk offline failed - no valid replicas". Chạy Scrub rồi Offline lại.
• "device is too small" trên 25.10 dù hai ổ cùng số byte (NAS-138678). Trường hợp trên forum xử lý được bằng reboot rồi Replace lại. Forum cũng khuyên kiểm tra BIOS ở chế độ AHCI và bật SATA Hot Plug.
• Bật Force trên nhầm ổ. Force xóa sạch ổ được chọn, nên đối chiếu serial trước khi bấm.
• Chồng việc trong lúc resilver. Replace hủy scrub đang chạy, và ZFS chỉ cho chạy một việc scrub hoặc resilver tại một thời điểm.

Tùy chọn nâng cao

• Cắm ổ mới song song: ổ cũ còn đọc được và còn cổng trống thì cắm ổ mới rồi Replace mà chưa Offline, để giữ dự phòng suốt lúc resilver (zpool-replace). Tài liệu 24.10 có mục thay ổ còn khỏe, tài liệu 25.10 không mô tả, nên đừng mặc định GUI 25.10 làm y hệt.
• Ưu tiên resilver: System Settings > Advanced Settings > widget Storage > Configure > "Run Resilvering At Higher Priority At Certain Times".
• Lệnh phụ: zpool status -L (tên thiết bị hiện tại), -p (số chính xác), -s (I/O chậm), zpool scrub -e (chỉ scrub file đã biết lỗi, cần feature head_errlog).

Để lần sau đỡ toát mồ hôi

• Dán nhãn serial lên khay khi ổ còn khỏe, đỡ một buổi tối dò từng ổ sau này.
• Giữ backup ngoài pool và thỉnh thoảng thử khôi phục một file.
• Theo dõi sức khỏe ổ bằng app Scrutiny trong catalog TrueNAS, nhất là từ khi GUI không còn giao diện SMART.
• Pool RAIDZ1 hoặc Mirror 2 ổ thì có sẵn một ổ đã burn-in trong tủ.

Pool DEGRADED chưa phải án tử. ZFS đang báo bạn còn thời gian, miễn đừng dùng nó để rút nhầm ổ.