Burn-in ổ cứng QNAP: bắt ổ lỗi trước khi hết hạn đổi

Burn-in ổ cứng là gì, sao ổ mới tinh cũng phải test

Burn-in là cho ổ cứng mới chạy hết công suất từ vài giờ tới vài ngày. Có hai cách: chỉ đọc toàn bộ bề mặt, hoặc ghi kín rồi đọc lại để so. Mục đích rất đời thường. Ổ nào định "chết yểu" thì cho nó chết ngay lúc shop còn đổi mới, đừng để nó chọn đúng hôm đang gánh 6TB ảnh gia đình. Tới lúc đó bạn chỉ còn đường gửi bảo hành hãng, chờ vài tuần và ngồi nhìn RAID chạy chế độ degraded.

Ổ lỗi từ nhà máy hay bị va đập lúc vận chuyển thường lộ bệnh ngay trong vài ngày tải nặng đầu tiên. Burn-in chỉ dồn mấy ngày đó vào lúc ổ còn trống.

Burn-in làm được gì

• Bắt ổ lỗi trong hạn đổi mới. Shop ở VN thường cho đổi mới trong 5–15 ngày. Qua hạn là chuyển sang bảo hành hãng, chậm hơn nhiều.
• Có mốc SMART để so. Chụp bảng SMART lúc vừa bóc hộp, sau này chỉ số nào nhảy là thấy ngay. Tiện thể lộ luôn ổ đã qua sử dụng: ổ "mới" mà số giờ chạy hàng nghìn thì khỏi bàn.
• Không mất dữ liệu nào. Ổ được test lúc còn trống, trước khi tạo storage pool. Không có gì để mất, cũng không phải dựng lại pool.
• Phần lớn làm bằng giao diện. QTS có sẵn Complete Test, Scan for Bad Blocks và bảng SMART. Chỉ bài ghi phá huỷ bằng badblocks mới cần SSH hoặc một máy Linux riêng.

Mấy tình huống rất hay gặp

• Mua 2 ổ 8TB cho TS-264 hoặc TS-464 để chạy RAID 1, shop cho đổi mới 7 ngày. Bài toán là test mức nào để lỡ có lỗi vẫn kịp ôm ổ ra shop, chứ không phải tới ngày thứ 8 mới phát hiện rồi ngồi dò lại điều khoản bảo hành.
• Một người dùng r/qnap (03/2026) mua 2 ổ 24TB cho TS-464 và hỏi: Scan for Bad Blocks cộng SMART extended đã đủ chưa, hay phải burn-in đầy đủ? Trả lời ngắn: tuỳ hạn đổi. Bản dài nằm ở bước 2.
• Văn phòng nhỏ mua 4 ổ cho NAS 4 khay, không muốn test lần lượt từng ổ mất nửa tháng. Không cần thế: chạy song song được, tổng thời gian gần bằng test 1 ổ.

Đa số người dùng cắm ổ vào là tạo pool luôn. Burn-in tốn thêm 1–8 ngày, đổi lại bạn khỏi phải rebuild RAID vì một ổ chết ngay tuần đầu. Ai từ Synology sang thì định vị thế này: Complete Test của QTS tương đương S.M.A.R.T. extended test trong Storage Manager của DSM.

Vì sao bắt đầu bằng giao diện Storage & Snapshots

Làm bằng giao diện thì không cần SSH, không cài thêm gì, và không có cửa gõ nhầm tên ổ rồi xoá nhầm ổ đang chứa dữ liệu. Cả hai bài test đều không xoá dữ liệu.

Complete Test là self-test do chính firmware của ổ chạy. Scan for Bad Blocks thì QNAP khuyên dùng khi ổ đang báo Warning/Error, tức là trên ổ đang có dữ liệu. Hãng không ghi rõ chữ "read-only", nhưng theo cách hãng dùng thì đây là quét đọc, không xoá dữ liệu.

Mỗi bài tốn khoảng một lượt toàn ổ (8TB từ 11 giờ trở lên), vẫn vừa trong hạn đổi 5–7 ngày. Ổ Seagate IronWolf có thêm tab IronWolf Health Management (IHM), một số ổ WD có tab WDDA. Đây là công cụ của chính hãng ổ, tích hợp sẵn trong QTS. Có thì chạy thêm.

Chuẩn bị trước khi bóc hộp

• Firmware: hướng dẫn này viết cho QTS 5.2.11 và QuTS hero h6.0.2. Bản ổn định mới nhất là QTS 5.2.11.3661 build 20261023 (đăng 24/10/2026, vá lỗ hổng PHP2Shell) và QuTS hero h6.0.2.3656 build 20261023. QuTS hero có cùng cấu trúc Storage & Snapshots. QTS 6.1 vẫn đang Public Beta, đừng lên beta chỉ để test ổ.
• Giữ nguyên hộp, phụ kiện, hoá đơn. Điều kiện đổi mới phổ biến là "đầy đủ vỏ hộp, phụ kiện, không trầy xước". Xé hộp bừa hay vứt hộp là tự tay khoá cửa đổi mới.
• Hạn đổi tính từ ngày mua, không phải ngày nhận. Mua online thì ổ đã nằm trên xe giao hàng 1–3 ngày. Hạn 7 ngày có khi chỉ còn 4–5 ngày thực.
• Mua ở đâu, kể cả nashub.vn, cũng hỏi rõ hai câu: đổi mới bao nhiêu ngày, tính từ hôm nào.

Bước 1: Lắp ổ, KHÔNG tạo pool, chụp mốc SMART

Lắp ổ vào khay, mở Storage & Snapshots nhưng đừng bấm tạo storage pool. Ổ sẽ hiện ở trạng thái trống (free).

1. Vào Storage & Snapshots > Storage > Disks/VJBOD > Disks rồi chọn ổ mới.
2. Bấm Information để xem model, serial và firmware. Chụp màn hình lại, lát nữa cần serial này để khớp ổ khi chạy lệnh.
3. Vào Health > View Details > SMART Information và chụp toàn bộ bảng.

Tên menu ở trên lấy theo tài liệu QTS 5.1.x. Bố cục trên 5.2.11 tương tự; nút có nằm lệch chỗ một chút thì tìm trong cửa sổ Health của ổ.

Mấy dòng cần nhìn trong bảng SMART:

• 9 Power_On_Hours: ổ mới thường chỉ từ 0 tới vài giờ, do nhà máy chạy test.
• 5 Reallocated_Sector_Ct, 197 Current_Pending_Sector, 198 Offline_Uncorrectable: phải bằng 0.
• 199 UDMA_CRC_Error_Count: đếm lỗi đường truyền. Ghi lại số này để so sau.

Số giờ chạy cao bất thường, hoặc 5/197/198 khác 0 ngay lúc bóc hộp? Dừng luôn, khỏi test gì nữa, mang trả. Cách nhận diện ổ fake, ổ đã qua sử dụng và tra bảo hành theo serial đã có bài riêng trên nashub, bài này không nhắc lại.

Bước 2: Chọn mức test theo hạn đổi

Có ba mức, càng lên cao càng kỹ và càng lâu:

• Mức 1: Complete Test, có thể cộng thêm Scan for Bad Blocks. Chỉ đọc, làm hoàn toàn bằng giao diện.
• Mức 2: badblocks -w -t 0, ghi kín ổ bằng một pattern rồi đọc lại so sánh. Tốn 2 lượt.
• Mức 3: badblocks -w đủ 4 pattern. Tốn 8 lượt.

Bảng dưới là ước lượng của nashub, không phải số của hãng. Giả định: tốc độ tuần tự trung bình 200 MB/s, 1TB = 10¹² byte, một lượt là đọc hoặc ghi hết toàn ổ.

Quy ra ngày cho dễ hình dung: Mức 3 với ổ 8TB mất khoảng 3,7 ngày, ổ 16TB khoảng 7,4 ngày. Muốn bảng sát với ổ thật của bạn thì đo bằng Storage & Snapshots > Storage > Disks/VJBOD > Performance Test > Sequential read. Bài đo này thường đọc ở vùng ngoài của đĩa, nơi nhanh nhất, nên cộng thêm 20–30% khi tính tổng. Ổ lớp 5400/5640 RPM thường chậm hơn mốc 200 MB/s.

Thời gian Complete Test thì khỏi đoán, chính ổ có khai. Dòng Extended self-test routine recommended polling time trong smartctl -c cho biết con số này (lệnh ở phần nâng cao). Ví dụ thật trên forum: một ổ WD 10TB báo 1226 phút, tức khoảng 20 giờ, lâu hơn hẳn mức tính theo tốc độ.

Quy tắc gợi ý: tổng thời gian test không quá ½ hạn đổi, để còn thời gian ôm ổ ra shop.

Mức 3 cho ổ 8TB mất khoảng 4–5 ngày tính cả Complete Test chạy sau đó, ổ 16TB là 8–9 ngày. Nói gọn: hạn ngắn thì chạy một pattern.

Vậy 2 ổ 24TB trên TS-464 thì sao?

Cùng giả định 200 MB/s, một lượt ổ 24TB mất khoảng 33 giờ. Scan for Bad Blocks cộng SMART extended chính là Mức 1, tốn khoảng 2,8 ngày trở lên. Với hạn đổi 7 ngày, mức này vừa khít, nên câu trả lời là đủ. Có điều Mức 1 chỉ đọc, nên chỉ bắt được lỗi lộ ra khi đọc. Lỗi chỉ lộ lúc ghi thì phải nhờ badblocks -w.

Hạn đổi 15 ngày thì bạn có thể lên Mức 2: khoảng 2,8 ngày ghi-đọc cộng một lượt Complete Test, tổng chừng 4,2 ngày trở lên. Ổ cỡ này nhớ dùng -b 8192, lý do nằm ở phần lỗi hay gặp. Trước khi tính, đo tốc độ thật bằng Performance Test.

Bước 3: Chạy test trên giao diện QTS

Trình tự gọn: mốc SMART + Rapid Test → badblocks (nếu chọn Mức 2/3) → Complete Test → chụp SMART lần 2. Nếu chỉ chạy Mức 1:

1. Trong Health > View Details, mở tab Test và chạy Rapid Test, khoảng 1 phút. Bài này chỉ để loại ngay ổ hỏng sẵn.
2. Cũng ở tab Test, chọn Complete Test. Bấm xong thì đi làm việc khác. Ngồi canh không làm nó chạy nhanh hơn được giây nào.
3. Complete Test xong, chọn ổ > Action > Scan for Bad Blocks. Chạy lần lượt từng bài để kết quả dễ đọc và hai bài không giành nhau băng thông. Số bad block xem ở Health > Summary.
4. Chụp lại tab SMART Information và đặt cạnh ảnh mốc ở bước 1.

Ổ IronWolf thì chạy thêm bài test trong tab IHM. Ổ WD có tab WDDA thì xem thêm ở đó.

Bước 4: So trước/sau, giữ hay mang trả

Mang trả ngay nếu gặp một trong các dấu hiệu sau:

• Bất kỳ chỉ số nào trong 5/197/198 tăng, dù chỉ lên 1.
• badblocks báo khác 0/0/0 errors.
• Complete Test báo fail.
• QTS chuyển trạng thái ổ sang Warning hoặc Error.

Riêng 199 CRC tăng thì đừng vội đổ tội cho mặt đĩa. Lỗi này thường đến từ đường truyền: khay tiếp xúc kém, cáp hoặc dock USB tồi. Rút ổ ra lắp lại, đổi sang khay khác (hoặc đổi cáp/dock), rồi test lại. Còn Power_On_Hours và nhiệt độ thay đổi giữa hai lần chụp là chuyện bình thường.

Qua hết các điểm trên rồi mới tạo storage pool / RAID.

Nâng cao: badblocks ghi phá huỷ (Mức 2/3)

Cờ -w ghi 4 pattern (0xaa, 0x55, 0xff, 0x00) lên toàn ổ rồi đọc lại so sánh. Man page ghi thẳng: "This option erases data!". Nên chỉ chạy trên ổ mới, trống, chưa thuộc pool nào.

Cách an toàn hơn: chạy trên máy Linux riêng

Cắm ổ vào PC chạy Linux, hoặc boot USB Linux live, nối ổ qua SATA trực tiếp hay dock USB. Chạy xong mới lắp ổ vào QNAP. Cách này né hẳn rủi ro md9/md13 ở phần lỗi bên dưới. Ổ cắm qua dock USB có thể cần thêm -d sat cho smartctl.

Người dùng Windows lưu ý: đa số công cụ miễn phí phổ biến trên Windows chỉ quét đọc. Muốn test ghi-đọc toàn ổ thì dùng Linux live.

Chạy ngay trên QNAP qua SSH

Bật SSH ở Control Panel > Network & File Services > Telnet / SSH > Allow SSH connection. Chỉ tài khoản quản trị mới đăng nhập được. QTS không có sẵn badblocks, smartctl hay screen thì bạn có thể cài Entware. Đây là kho gói của bên thứ ba, không phải của QNAP, cài thủ công qua App Center. Entware hiện có badblocks 1.47.3-1, smartmontools 7.5-1 và screen 5.0.1-1, cài bằng opkg install badblocks smartmontools screen.

Bộ lệnh dưới đây chạy được cả trên QNAP lẫn Linux live, trong đó sdX là ổ cần test.

# 1. Xác định đúng ổ: SERIAL phải khớp với nút Information trên QTS
lsblk -o NAME,SIZE,MODEL,SERIAL
smartctl -i /dev/sdX | grep -i serial       # dùng khi máy không có lsblk

# 2. Riêng QNAP: sdX KHÔNG được có mặt trong md nào
cat /proc/mdstat

# 3. Mốc SMART + thời gian Complete Test do ổ tự khai
smartctl -i -A /dev/sdX > smart_truoc_sdX.txt
smartctl -c /dev/sdX | grep -A1 "Extended self-test"

# 4. Mỗi ổ một phiên screen (hoặc: tmux new -s bb_sdX)
screen -S bb_sdX

# 5a. Mức 2: một pattern (0x00)
badblocks -b 4096 -wsv -t 0 -o bb_sdX.txt /dev/sdX
# 5b. Mức 3: đủ 4 pattern
badblocks -b 4096 -wsv -o bb_sdX.txt /dev/sdX
# Ổ từ 18TB trở lên: đổi -b 4096 thành -b 8192

# 6. Complete Test sau badblocks (bấm trên giao diện QTS cũng được)
smartctl -t long /dev/sdX
smartctl -l selftest /dev/sdX

# 7. So SMART trước/sau
smartctl -i -A /dev/sdX > smart_sau_sdX.txt
diff smart_truoc_sdX.txt smart_sau_sdX.txt

Cờ -s hiện tiến độ theo %, -v in số lỗi đọc/ghi/sai dữ liệu dạng (0/0/0 errors). Muốn thoát phiên screen mà test vẫn chạy thì bấm Ctrl+A rồi D, quay lại bằng screen -r bb_sdX.

Test 4 ổ cùng lúc

Mỗi ổ một phiên screen riêng (bb_sda, bb_sdb…), chạy song song. Ổ cắm SATA hoặc nằm trong khay NAS thì tổng thời gian xấp xỉ test 1 ổ. Dock USB nhiều khay thì khác: các ổ chia chung băng thông của một cổng USB, càng nhiều ổ càng chậm.

Lỗi và cạm bẫy hay gặp

• Gõ nhầm sdX. badblocks -w không hỏi lại câu nào, nó ghi đè luôn. Gõ nhầm một chữ cái là ổ dữ liệu cũ thành ổ "mới tinh" theo nghĩa đen. Luôn khớp serial từ lsblk hoặc smartctl -i với nút Information trên QTS trước khi bấm Enter.
• md9/md13 của QNAP. Đây là các phân vùng hệ thống, được QTS mirror trên các ổ trong NAS. Ổ mới đã bị QTS phân vùng hoặc đưa vào md9/md13 mà bạn chạy -w lên /dev/sdX thì phần mirror hệ thống sẽ bị phá, QTS báo lỗi hoặc tự rebuild. Luôn kiểm cat /proc/mdstat trước khi chạy. Không chắc thì chuyển Mức 2/3 sang máy Linux riêng.
• Thiếu cờ -b. badblocks đếm block bằng số 32-bit, nên tối đa 2³² block. Với mặc định -b 1024, giới hạn chỉ khoảng 4 TiB (≈4,4TB). Với -b 4096, giới hạn là 16 TiB (≈17,6TB), nên ổ từ 18TB trở lên phải dùng -b 8192. Thiếu cờ thì badblocks dừng ngay với lỗi Value too large… must be 32-bit value.
• Mất SSH là đứt test. badblocks chạy ở foreground. Wi-Fi chập một cái, laptop ngủ một cái, là công chạy cả ngày đổ sông đổ biển. Luôn chạy trong screen/tmux.
• Nhầm hai loại "polling time". "S.M.A.R.T. polling time" trong cài đặt Disk Health của QNAP là chu kỳ (tính bằng phút) để NAS đọc SMART. "Recommended polling time" trong smartctl -c là thời gian ổ cần để chạy xong Extended test. Trùng tên, nhưng chẳng liên quan gì nhau.
• Complete Test không xong hoặc bị dừng. NAS cho ổ đi ngủ giữa chừng thì tạm tắt Enable disk standby mode ở Control Panel > System > Hardware > General (đường dẫn theo docs 5.0.x). Test xong thì bật lại, và tránh để NAS gánh tải nặng trong lúc test.
• Hoảng vì số raw lớn. Trên ổ Seagate, 1 Raw_Read_Error_Rate và 7 Seek_Error_Rate có raw value rất lớn là bình thường, do cách hãng mã hoá giá trị. Chỉ xét 5/197/198, và 199 khi nghi khay/cáp.
• Ổ nóng khi burn-in nhiều ổ cùng lúc. Bật cảnh báo ở tab Settings > Enable temperature alarm trong cửa sổ Health, và kiểm tra quạt NAS hoặc dock có chạy đủ không.

Chọn ổ NAS nào để burn-in xong yên tâm dùng

Các model dưới đây đều là ổ NAS-grade CMR, bảng lấy bản 8TB làm ví dụ. Một lưu ý chung: cùng một dòng sản phẩm có thể có nhiều model khác nhau về công nghệ ghi và vòng quay. Seagate IronWolf 8TB chẳng hạn, có ST8000VN004 (7200 RPM) và ST8000VN002 (lớp 5400 RPM, ~202 MB/s). Nên tra đúng mã model trên datasheet trước khi mua.

Gia đình/SOHO, NAS 2–4 khay như TS-264, TS-464: WD Red Plus, IronWolf hay N300 đều đúng bài. Red Plus có cache 256MB, một số model có WDDA ngay trong QTS. IronWolf có IHM tích hợp trong QTS và gói Rescue (dịch vụ cứu dữ liệu) 3 năm. N300 là ổ 7200 RPM trong phân khúc 180 TB/năm. Toshiba N300 bản bulk mang mã MN10ADA800S, mã cũ là HDWG480, gặp thì đừng tưởng nhầm hàng.

NAS nhiều khay, ghi liên tục, nhiều người dùng: nâng lên dòng Pro. WD Red Pro chạy được tới 24 khay, bảo hành 5 năm. IronWolf Pro bảo hành 5 năm kèm Rescue 3 năm. N300 Pro chịu 300 TB/năm, cũng bảo hành 5 năm. Đây là nâng cấp theo tải, không phải vì dòng thường có vấn đề.

Giá ổ cứng năm 2026 tăng mạnh: TechRadar ghi IronWolf 8TB tăng khoảng 95% so với 2025. Lúc viết bài, Red Plus 8TB dao động khoảng 8,4–11 triệu, IronWolf 8TB khoảng 10–11 triệu. Dòng Pro và N300 giá đang biến động, xem giá kho nashub.vn lúc mua.

Test đạt rồi: tạo pool, bật lịch kiểm tra, tắt SSH

• Tạo storage pool / RAID như bình thường. Giữ lại ảnh SMART lần 2 làm mốc cho cả đời ổ.
• Trong tab Settings của cửa sổ Health, hẹn lịch S.M.A.R.T. Test schedule định kỳ và giữ cảnh báo nhiệt độ. Muốn có dự đoán hỏng ổ thì cài thêm app DA Drive Analyzer của QNAP; app này cần bật "Share my disk analysis data with QNAP".
• Tắt Allow SSH connection ngay khi test xong, và tuyệt đối không mở cổng SSH ra Internet. Entware chỉ nên giữ lại nếu bạn thật sự còn dùng.
• Kết quả từ vài ổ không đủ để kết luận "hãng X hay lỗi". Burn-in chỉ trả lời câu hỏi về đúng cái ổ trước mặt bạn.

Một điều cuối: ổ qua burn-in chỉ chứng minh nó không chết yểu, không hứa nó sống lâu. RAID cũng không phải backup. Chuyện sống lâu là việc của bản backup thứ hai nằm ở chỗ khác, chứ không phải của mấy ngày bạn ngồi canh badblocks.