RAID rebuild trên Synology: tính thời gian & tối ưu tốc độ

RAID rebuild là gì, khác Data Scrubbing ở đâu

Ổ cứng trong NAS báo lỗi, bạn rút ra thay ổ mới — chuyện đó DSM tự lo, không cần tắt máy, càng không cần vái tứ phương tìm phần mềm cứu dữ liệu như hồi ổ cứng máy tính thường bị hỏng. Cái NAS làm ngay sau đó gọi là rebuild, Synology đặt tên là "Repair Storage Pool": nó tính lại toàn bộ dữ liệu đã mất từ parity (RAID5/6/SHR) hoặc copy nguyên trạng (RAID1/10), rồi ghi hết lên ổ mới. Trong lúc này pool ở trạng thái Degraded — vẫn đọc/ghi bình thường, nhưng đã mất khả năng chịu lỗi, và chạy chậm hơn ngày thường vì ổ nào cũng đang è cổ vừa phục vụ dữ liệu vừa ghi rebuild.

Dễ nhầm với rebuild là Data Scrubbing — cũng nằm trong Storage Manager nhưng làm việc hoàn toàn khác: quét định kỳ trên một mảng đang khỏe mạnh để tìm và sửa lỗi dữ liệu ẩn (bit rot, sector lỗi chưa lộ ra). Data Scrubbing chỉ chạy trên Btrfs + SHR/RAID5/RAID6/RAID F1 từ 3 ổ trở lên. Bấm nhầm nút này khi ổ đã chết thì chịu, chẳng giải quyết được gì — cần Repair chứ không phải Scrub.

Rebuild mất bao lâu? Công thức và những thứ quyết định tốc độ

Công thức thô, đủ dùng để ước lượng trước khi thay ổ:

Thời gian rebuild (giờ) ≈ Dung lượng ổ cần rebuild (GB) ÷ (Tốc độ rebuild thực tế MB/s × 3600)

Vấn đề nằm ở "tốc độ thực tế" — con số này không cố định, bị kéo xuống bởi hàng loạt yếu tố cùng lúc:

• Loại RAID: RAID6/SHR-2 phải tính 2 lần parity nên chậm hơn RAID5/SHR-1 dù cùng dung lượng.
• Số ổ trong mảng: nhiều ổ hơn thường đọc/ghi song song nhanh hơn, nhưng cũng đồng nghĩa nhiều điểm có thể nghẽn I/O hơn.
• Resync Speed Limit: giới hạn tốc độ bạn (hoặc DSM mặc định) đặt cho tiến trình rebuild — đặt thấp thì NAS mượt hơn nhưng rebuild kéo dài ra rõ rệt.
• Tải I/O song song: Surveillance Station ghi hình, Active Backup chạy full backup, torrent tải xuyên đêm — tất cả giành băng thông đĩa với rebuild.
• Ổ CMR hay SMR: đây là yếu tố hay bị bỏ qua nhất và ảnh hưởng nặng nhất, nói kỹ ở phần lỗi thường gặp bên dưới.

Vì nhiều biến số đan xen như vậy, đừng kỳ vọng một con số chính xác đến phút — chỉ nên coi công thức trên là cách ước lượng biên độ, để canh lịch chứ không phải canh giờ.

Rebuild trong thực tế mất bao lâu — bảng tham khảo

Số liệu dưới đây gom từ cộng đồng người dùng Synology, không phải cam kết chính thức từ hãng — máy của bạn có thể nhanh hơn hoặc chậm hơn tùy cấu hình và tải thực tế.

Nhìn bảng này rút ra một điều: cùng là "thay ổ 8TB" mà thời gian dao động từ 20 giờ tới vài ngày. Trường hợp xấu nhất 12 ngày không phải vì ổ dở, mà vì Resync Speed Limit bị bóp quá thấp — tự làm khó mình. Nếu đang rebuild mảng RAID6 lớn và thấy tiến độ tính bằng ngày chứ không phải giờ, đó là chuyện bình thường, không phải dấu hiệu NAS đang hấp hối.

Theo dõi tiến trình ngay trong Storage Manager

Vào Storage Manager > Storage, chọn pool đang ở trạng thái "Repairing" — DSM hiển thị sẵn % hoàn thành và ETA (thời gian ước tính còn lại) ngay trên widget, không cần mở terminal gõ lệnh gì cả. Cứ để đó, thỉnh thoảng ghé xem là đủ.

Việc nên làm thêm: bật thông báo để không phải ngồi canh màn hình. Vào Control Panel > Notification, bật cảnh báo qua email hoặc app DS Finder khi storage pool chuyển sang Degraded/Critical. Không có gì tệ hơn việc mảng chạy thiếu redundancy cả tuần mà chẳng ai để ý — vì màn hình Storage Manager không phải thứ ai cũng mở mỗi ngày.

Chỉnh Resync Speed Limit, Auto Repair và Hot Spare

Ba công tắc này nằm gọn trong Storage Manager, chỉnh xong là xong, không đụng SSH:

• Resync Speed Limit (Storage Manager > Storage > Global Settings > Advanced Repair Settings): có hai mức, Max là tốc độ khi hệ thống đang rảnh, Min là tốc độ đảm bảo khi có tác vụ khác đang chạy song song. Đây chính là tham số tương đương speed_limit_max/speed_limit_min của mdadm dưới nền — chỉnh trong GUI là đủ. Đặt Max cao thì rebuild nhanh nhưng ổ nóng hơn, NAS ì hơn lúc dùng song song; đặt thấp thì ngược lại. Không có đáp án đúng tuyệt đối, tùy bạn có đang cần dùng NAS gấp trong lúc rebuild hay không.
• Auto Repair (cùng mục Advanced Repair Settings): bật một lần, DSM tự khởi động rebuild ngay khi phát hiện ổ lỗi — không cần ai thức dậy lúc 2 giờ sáng bấm nút Repair thủ công.
• Hot Spare (Storage Manager > HDD/SSD hoặc ngay trong storage pool): gán một ổ dự phòng rảnh rỗi, rebuild sẽ bắt đầu gần như tức thì khi ổ chính hỏng. Chỉ áp dụng cho RAID có chịu lỗi (RAID 1/5/6/10/F1, SHR từ 2 ổ trở lên) và cần NAS có ổ trống để gán — hợp với máy từ 5 khay trở lên.

Rủi ro thật sự: cửa sổ mất redundancy

Đây là phần nhiều người bỏ qua vì "NAS vẫn dùng bình thường mà, có sao đâu". Có đấy. Trong lúc RAID5/SHR-1 đang rebuild, mảng đã mất khả năng chịu lỗi — ổ thứ hai chết trong khoảng thời gian này đồng nghĩa mất trắng dữ liệu, không có gì cứu được nữa. Rủi ro này còn cao hơn mức tưởng tượng vì các ổ trong cùng mảng thường mua cùng lô, dùng cùng số giờ, già đi gần như đồng thời — ổ đầu tiên hỏng vì mỏi thì ổ thứ hai cũng chẳng còn trẻ trung gì, chỉ là chưa tới lượt thôi.

Với mảng nhiều khay hoặc chứa dữ liệu quan trọng, đây là lý do nên cân nhắc RAID6/SHR-2 ngay từ đầu thay vì RAID5/SHR-1 — chịu được 2 ổ hỏng cùng lúc. Đặc biệt khi dùng ổ dung lượng lớn (12TB, 16TB trở lên), vì rebuild càng lâu thì cửa sổ rủi ro càng kéo dài — theo bảng ở trên, ổ 16TB rebuild cả ngày là bình thường.

Backup trước khi rebuild — RAID không phải backup

Nói lại cho rõ vì hay bị hiểu lầm: RAID (kể cả RAID6/SHR-2) là công cụ chống downtime khi một ổ hỏng, không phải bản sao lưu. Nếu phát hiện ổ sắp hỏng mà vẫn còn kịp đọc dữ liệu, chạy ngay một lượt Hyper Backup ra ổ ngoài, NAS thứ hai hoặc cloud trước khi rút ổ ra thay. Trong lúc rebuild đang chạy, tránh luôn các tác vụ I/O nặng không cấp thiết — ghi hình liên tục trên Surveillance Station, Active Backup đồng loạt nhiều máy, tải torrent — vừa kéo dài thời gian rebuild vừa làm nóng toàn bộ ổ còn lại trong mảng, đúng lúc chúng cần "khỏe" nhất.

Lỗi thường gặp khi rebuild

• Lắp nhầm ổ SMR vào mảng. Ổ SMR đời cũ hoặc ổ desktop giá rẻ gắn nhầm vào NAS khiến rebuild chậm bất thường — có ghi nhận kéo dài tới 9 ngày, thậm chí bị DSM đánh dấu "Abnormal" và rớt khỏi mảng giữa chừng do timeout ghi. Cách xử lý: tra datasheet model ổ trước khi lắp, chỉ dùng dòng NAS-grade CMR (xem bảng chọn ổ bên dưới). Buồn cười ở chỗ ngay trong cùng một dòng sản phẩm, có model dùng CMR và model dùng SMR khác nhau — đọc kỹ mã model, đừng đoán mò theo tên dòng.
• Rebuild đứng hình, % tăng rất chậm. Thường do ổ mới lắp vào có sector lỗi chưa lộ ra từ trước. Cách phòng: chạy Data Scrubbing định kỳ (Storage Manager > Storage Pool > Data Scrubbing) trên mảng đang khỏe để phát hiện sớm sector hỏng, trước khi cần rebuild thật.
• Chủ quan không backup vì "vẫn dùng được". Đây chính xác là giai đoạn nguy hiểm nhất như đã nói ở phần rủi ro — backup trước khi thao tác thay ổ nếu còn kịp.
• Chạy tác vụ nặng song song với rebuild — kéo dài thời gian, tăng nhiệt độ cả mảng.
• Bấm nhầm Repair với Data Scrubbing — hai nút khác chức năng trong Storage Manager, dùng nhầm không giải quyết được ổ đang hỏng.

Chọn ổ NAS-grade để rebuild êm, ít gặp sự cố

Chọn đúng ổ ngay từ đầu là cách rẻ nhất để tránh rơi vào tình huống rebuild bất thường ở trên. Ba dòng CMR chuẩn NAS phổ biến nhất hiện nay, chọn theo số khay và tải thực tế:

Với NAS gia đình lưu ảnh, backup máy tính, chạy Plex nhẹ, WD Red Plus, Seagate IronWolf hay Toshiba N300 đều là lựa chọn chuẩn — cả ba đều CMR, workload 180TB/năm, bảo hành 3 năm, đủ dùng thoải mái. Lên tới 4-8 khay hoặc chạy Surveillance Station/Active Backup cho nhiều máy, nâng cấp lên bản Pro của từng hãng (WD Red Pro, IronWolf Pro, N300 Pro) — RPM và workload rating cao hơn giúp rebuild nhanh hơn trên mỗi TB và chịu tải liên tục tốt hơn; IronWolf Pro còn kèm 3 năm dịch vụ cứu dữ liệu Rescue. Từ 8 khay trở lên với mảng dung lượng lớn, ưu tiên hẳn dòng Pro ở dung lượng cao (12-24TB) vì số ổ nhiều đồng nghĩa xác suất phải rebuild cũng cao hơn theo thời gian.

Nói đến CMR/SMR: quan trọng không phải né hãng nào, mà là chọn đúng dòng NAS-grade kể trên theo tải thực tế — tất cả các model trong bảng đều CMR, gia đình dùng dòng tiêu chuẩn là đủ, tải nặng thì lên Pro.

Tùy chọn nâng cao: xem chi tiết rebuild qua SSH

Phần này không bắt buộc, chỉ dành cho ai rành dòng lệnh và muốn debug khi rebuild có dấu hiệu bất thường (đứng hình, tốc độ tụt đột ngột). SSH vào NAS rồi chạy:

cat /proc/mdstat

Lệnh này cho % hoàn thành và tốc độ tính bằng K/sec theo thời gian thực, chi tiết hơn widget trên DSM. Muốn xem sâu hơn về từng ổ trong mảng RAID đó thì dùng:

mdadm --detail /dev/mdX

(thay mdX bằng số md tương ứng của storage pool). Với luồng theo dõi rebuild thông thường, widget trong Storage Manager là đủ — hai lệnh này chỉ cần khi có gì đó thực sự không ổn.

Tóm gọn lại

Rebuild vài chục giờ đến vài ngày là chuyện bình thường, không phải NAS đang chết. Việc của bạn chỉ là: bật Auto Repair + Hot Spare từ trước, chỉnh Resync Speed Limit theo nhu cầu thực tế, bật thông báo Degraded, và quan trọng nhất — backup dữ liệu quan trọng ra ngoài trước khi đụng vào ổ đĩa. Chọn đúng ổ NAS-grade ngay từ đầu thì phần lớn kịch bản rebuild bất thường ở trên coi như loại bỏ được trước khi nó kịp xảy ra — tiền chênh lệch vài trăm nghìn giữa ổ desktop và ổ NAS-grade rẻ hơn nhiều so với một đêm mất ngủ ngồi canh thanh % chạy.