RAID 5, RAID 6 hoặc ZFS Multiple Drive Drop: Khôi phục mảng Synology, QNAP hoặc TrueNAS bị hỏng mà không phá hủy tính chẵn lẻ¶

Nghe Synology DiskStation, QNAP TS-series, máy chủ TrueNAS hoặc Linux mdadm máy chủ lưu trữ phát ra tiếng bíp liên tục trong khi báo cáo Volume Crashed, Pool Degraded / Faulted hoặc Multiple Drives Disconnected là trường hợp khẩn cấp về lưu trữ có nguy cơ cao. Khi một ổ đĩa rơi ra khỏi RAID 5, RAID lai Synology (SHR-1), hoặc ZFS RAIDZ1 pool, mảng chạy với độ dư thừa bằng 0 (degraded trạng thái), xây dựng lại các khối bị thiếu một cách nhanh chóng bằng cách đọc song song mọi đĩa còn lại. Nếu ổ đĩa thứ hai ngừng hoạt động ngoại tuyến vài giờ sau đó hoặc đưa ra Lỗi Đọc không thể phục hồi (URE) trong quá trình xây dựng lại trên một đĩa thay thế, phép toán chẵn lẻ bị hỏng và nhóm lưu trữ hoàn toàn ngoại tuyến. Các quản trị viên hoảng sợ thường hủy hàng terabyte dữ liệu có thể phục hồi trong sáu mươi giây tiếp theo bằng cách nhấp vào Khởi tạo, tạo lại mảng bằng mdadm --createhoặc buộc phải xây dựng lại trực tuyến ngay lập tức đối với phần cứng bị lỗi. Nếu thẻ điều khiển RAID phần cứng của bạn bị hỏng chứ không phải ổ đĩa, hãy chuyển sang Thẻ điều khiển RAID bị hỏng, nhập cấu hình nước ngoài và lý do bạn không bao giờ được khởi tạo đĩa; nếu một ổ cứng riêng lẻ nhấp chuột hoặc từ chối quay, hãy tham khảo ý kiến Lỗi ổ cứng và phục hồi dữ liệu hoặc Mảng RAID NAS bị xuống cấp, lỗi nhiều ổ đĩa và khôi phục ZFS/Btrfs. Nếu lỗi lưu trữ này làm vô hiệu hóa hình ảnh y tế của bệnh viện (PACS), công văn khẩn cấp hoặc cơ sở hạ tầng an toàn tính mạng, hãy gọi đến số khẩn cấp tại địa phương của bạn (911 ở Hoa Kỳ và Canada, 112 trên khắp Liên minh Châu Âu, 999 ở Vương quốc Anh) hoặc kiểm tra thư mục của chúng tôi về số khẩn cấp.

Làm điều này ngay bây giờ¶

1. DỪNG và KHÔNG nhấp vào "Khởi tạo", "Tạo nhóm", "Sửa chữa" hoặc chạy mdadm --create trên các ổ đĩa bị rơi: Nhấp vào Khởi tạo trong Synology DSM hoặc QNAP QTS hoặc đang chạy mdadm --create trong Linux, viết các siêu khối hoàn toàn mới và bắt đầu loại bỏ các sọc chẵn lẻ trên tất cả các đĩa thành viên. Ổ đĩa bị rơi thường vẫn giữ được 99.99% trong số các tệp của bạn còn nguyên vẹn, chỉ được đánh dấu là không đồng bộ bởi bộ đếm sự kiện của nó.
2. Tắt nguồn NAS hoặc máy chủ một cách sạch sẽ (hoặc rút nguồn nếu nó đang tích cực xây dựng lại trên các ổ đĩa nhấp chuột) để đóng băng bộ đếm sự kiện: Mỗi giây mảng vẫn trực tuyến ở trạng thái xuống cấp một phần, hệ điều hành sẽ tăng siêu khối Update Time và Events truy cập vào các đĩa còn sót lại trong khi đĩa bị rơi vẫn bị đóng băng ở số sự kiện cũ hơn. Nếu NAS đang cố gắng xây dựng lại tự động trên một ổ đĩa có thành phần xấu, việc tiếp tục đọc ổ đĩa đó có thể làm mất lớp phủ đĩa từ (head crash).
3. Gắn nhãn cho mỗi khe cắm ổ đĩa bằng bút đánh dấu hoặc băng dính (Bay 1, Bay 2, Bay 3, Bay 4) trước khi trượt bất kỳ khay nào ra: Trong khi Linux mdadm, LVM2và ZFS theo dõi thứ tự ổ đĩa bằng UUID bên trong mỗi siêu khối phân vùng, bộ điều khiển phần cứng cũ hơn và hướng dẫn sử dụng dmsetup việc tái tạo bảng yêu cầu thứ tự vị trí vật lý chính xác (0, 1, 2, 3...).
4. Không bao giờ cố gắng phục hồi, tập hợp lực hoặc fsck trực tiếp trên các ổ đĩa thành viên ban đầu; sao chép từng ổ đĩa từng chút một bằng cách sử dụng ddrescue đầu tiên: Trước khi chạy mdadm --assemble --force hoặc zpool import -F, đính kèm từng đĩa thành viên vào máy trạm Linux thông qua SATA/SAS trực tiếp (không bao giờ có cầu nối USB giá rẻ ẩn giấu SMART hoặc SCT ERC hết thời gian chờ) và sao chép nó với ddrescue vào các ổ đĩa dự phòng hoặc tập tin hình ảnh còn tốt.
5. Buộc lắp ráp mảng nhân bản một cách nghiêm ngặt ở chế độ CHỈ ĐỌC (--readonly hoặc -o readonly=on): Khi lắp ráp mdadm các mảng có bộ đếm sự kiện bị tách rời trong quá trình thả nhiều ổ đĩa đồng thời, luôn vượt qua --readonly (mdadm --assemble --force --readonly /dev/md0 ...). Ở chế độ chỉ đọc, không mdadm, LVM2, ext4, Btrfs, cũng không ZFS có thể ghi đè lên các sọc chẵn lẻ hoặc phát lại một nhật ký phá hoại.
6. Sao chép dữ liệu quan trọng nhất của bạn sang ổ đĩa sao lưu bên ngoài độc lập ngay sau khi được cài đặt ở chế độ chỉ đọc: Trước tiên, hãy di tản tài liệu, cơ sở dữ liệu, máy ảo và ảnh của bạn sang một ổ đĩa riêng, sau đó xóa sạch và kiểm tra ổ đĩa từ đầu.

Cây quyết định: phân loại khẩn cấp nhóm RAID và nhóm ZFS đa ổ đĩa¶

Sử dụng sơ đồ này để xác định xem mảng của bạn có bị giảm thời gian chờ hợp lý hay không (TLER / ERC không khớp), lỗi khu vực xấu đa đĩa thực sự trong quá trình xây dựng lại hoặc nhóm giao dịch ZFS (TXG) lỗi:

flowchart TD
    Start["Nhóm RAID 5 / RAID 6 / SHR / ZFS gặp sự cố sau khi hơn 2 ổ đĩa bị hỏng"] --> StopIO["DỪNG tất cả việc xây dựng lại và tắt nguồn NAS ngay lập tức"]
    StopIO --> Label["Dán nhãn mỗi khay ổ đĩa theo số khay (Bay 1 đến Bay N)"]
    Label --> ConnectLinux["Kết nối ổ đĩa thành viên với máy chủ cứu hộ Ubuntu Linux thông qua SATA / HBA trực tiếp"]

    ConnectLinux --> CheckSmart["Kiểm tra chế độ chỉ đọc SMART & siêu dữ liệu: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Có bất kỳ ổ đĩa nào nhấp chuột, từ chối quay hoặc thoát ngoại tuyến trong dmesg không?"}

    PhysicalHealth -->|"Có: Lỗi cơ học / Đầu trên hơn 2 ổ đĩa trong RAID 5"| Cleanroom["DỪNG cấp nguồn cho đĩa -> Gửi đến Phòng thí nghiệm phục hồi dữ liệu phòng sạch"]
    PhysicalHealth -->|"Không: Tất cả các ổ đĩa đều quay lên (Có thể có các thành phần xấu đang chờ xử lý hoặc thời gian chờ bị giảm)"| CloneAll["Sao chép mọi ổ đĩa thành viên bằng GNU ddrescue (Chuyển tiếp -> Quét ngược)"]

    CloneAll --> DisconnectOrig["Ngắt kết nối ổ đĩa gốc và làm việc nghiêm ngặt trên đĩa / hình ảnh nhân bản"]
    DisconnectOrig --> ArrayType{"Kiến trúc lưu trữ nào được sử dụng?"}

    ArrayType -->|"Synology DSM (SHR / RAID cổ điển)"| SynologyFlow["Kiểm tra sự kiện thông qua mdadm --examine -> Chỉ đọc tập hợp bắt buộc -> Kích hoạt chỉ đọc LVM2/Btrfs"]
    ArrayType -->|"QNAP QTS (HAL LVM RAID mỏng / dày)"| QnapFlow["Lắp ráp mdadm Chỉ đọc -> Kích hoạt lớp DRBD nếu có -> Quét siêu khối QNAP LVM2 tùy chỉnh"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Gương)"| ZfsFlow["Chạy zpool import -d /dev/disk/by-id -> Nhập chỉ đọc với Rollback: zpool import -f -o readonly=on -F"]
    ArrayType -->|"mdad mdm linux tiêu chuẩn"| LinuxFlow["So sánh Bộ đếm sự kiện -> Chạy mdadm --assemble --force --readonly -> Gắn hệ thống tập tin với -o ro,noload"]

Giai đoạn 1: Tại sao việc buộc xây dựng lại sẽ phá hủy dữ liệu (Tầng URE và Cùng một lô)¶

Để hiểu lý do tại sao việc nhấp vào Sửa chữa / Xây dựng lại hoặc thay thế một ổ đĩa và đợi 36 giờ thường gây ra sự cố toàn bộ mảng, bạn phải hiểu việc tái thiết chẵn lẻ gây ra áp lực cho phương tiện từ tính bị lão hóa như thế nào và lý do tại sao các ổ đĩa máy tính để bàn tiêu dùng rơi ra khỏi vỏ NAS.

1. Thực tế toán học của Lỗi đọc không thể phục hồi (UREs) trong quá trình xây dựng lại RAID 5 hoặc RAIDZ1¶

Trong xe 4 bánh RAID 5 hoặc ZFS RAIDZ1 khối nhóm, dữ liệu và khối chẵn lẻ (P) được sọc trên cả bốn đĩa bằng cách sử dụng OR độc quyền (XOR) phép tính (D1 XOR D2 XOR D3 = P). Nếu Ổ 2 chết hoàn toàn, mảng không còn dư thừa nào. Để xây dựng lại Drive 2 trên một đĩa thay thế hoàn toàn mới, NAS phải đọc mọi cung từ byte 0 đến hết đĩa trên Drive 1, Drive 3 và Drive 4 cùng một lúc (Reconstructed D2 = D1 XOR D3 XOR P).

Hãy xem điều gì sẽ xảy ra khi những ổ đĩa đó là bốn ổ cứng 12 terabyte (12.000 gigabyte) được mua từ cùng một lô sản xuất bốn năm trước: - Xây dựng lại 12 terabyte yêu cầu đọc 36 terabytes (2.88 x 1014 các bit riêng lẻ) liên tục trong 24 đến 48 giờ ở tải nhiệt và cơ học tối đa. - Ổ cứng tiêu dùng thường có Lỗi đọc không thể phục hồi (URE) đặc điểm kỹ thuật của 1 error in 1014 bits (12.5 terabytes) và các ổ đĩa cũ phát triển các lỗi khu vực tiềm ẩn thầm lặng (Current_Pending_Sector) ở những vùng lạnh của đĩa chưa được đọc trong nhiều năm. - Thời điểm Drive 3 chạm vào một khu vực xấu 4 kilobyte (0,004 megabyte) không thể đọc được trong khi Drive 2 vẫn bị thiếu hoặc được xây dựng lại một nửa, XOR phương trình có hai ẩn số (D2 và D3).

2. Tại sao ổ đĩa máy tính để bàn không có TLER / SCT ERC bị đuổi hoàn toàn vì 1 bad Sector¶

Đây là cái bẫy khiến nhiều ổ bị rớt thảm hại trên Synology, QNAP và Linux mdadm:

+-------------------------------------------------------------------------+
| WHY A SINGLE BAD SECTOR DROPS AN ENTIRE DRIVE DURING REBUILD            |
|                                                                         |
| 1. Drive 2 is dead/rebuilding. NAS reads Sector 849,102,400 on Drive 3. |
| 2. Drive 3 hits a weak magnetic spot (Current_Pending_Sector).          |
| 3. Consumer Drive Behavior (No TLER / SCT ERC):                         |
|    - Drive 3 enters deep internal error recovery for 30 to 120 seconds, |
|      stopping all SATA responses while retrying head positioning.       |
| 4. Linux Kernel / NAS Controller Timeout (Default 7 to 30 seconds):     |
|    - Kernel sees Drive 3 unresponsive for >30s -> Issues SATA bus reset |
|    - mdadm assumes Drive 3 is COMPLETELY DEAD and kicks it from array   |
| 5. RESULT: Both Drive 2 and Drive 3 are now marked FAULTY/REMOVED.      |
|    The entire RAID 5 array crashes offline immediately.                 |
+-------------------------------------------------------------------------+

Hãy chú ý điều gì thực sự đã xảy ra: Ổ đĩa 3 không chết. Nó có 99.999999% các khu vực lành mạnh và chỉ 1 hoặc 2 khu vực 4 kilobyte không thể đọc được (8 kilobytes ra khỏi 12 terabytes). Tuy nhiên bởi vì mdadm đã loại Drive 3 ra khỏi mảng do hết thời gian chờ lệnh 30 giây, toàn bộ tập hiển thị là Đã gặp sự cố. Nếu bạn sao chép Drive 3 bằng ddrescue (bỏ qua 8 kilobyte của các thành phần xấu và sao chép 12 terabyte còn lại một cách duyên dáng) và buộc tập hợp mảng ở chế độ chỉ đọc, bạn sẽ khôi phục gần như 100% tệp của mình.

3. Tại sao bạn KHÔNG BAO GIỜ được chạy mdadm --create hoặc nhấp vào "Khởi tạo"¶

Khi một mảng gặp sự cố, có hai huyền thoại mang tính hủy diệt lan truyền trên mạng: - Lầm tưởng 1: "Tạo lại mảng với thứ tự ổ đĩa giống hệt nhau bằng cách sử dụng mdadm --create." Ngay cả với --assume-clean, phiên bản hiện đại của mdadm mặc định khác nhau Data Offset giá trị tùy thuộc vào kernel và mdadm phát hành (2048 sectors vs 262144 sectors). Khi nào mdadm --create viết một phiên bản mới 1.2 siêu khối ở sai vị trí hoặc có kích thước khối không khớp, nó sẽ ghi đè lên LVM2 tiêu đề khối lượng vật lý hoặc ext4 siêu khối ở phía trước tập sách. - Lầm tưởng 2: "Hãy rút ổ đĩa thứ hai vừa bị rơi ra, cắm lại và nhấp vào Sửa chữa." Nếu Ổ 1 bị loại bỏ ba ngày trước (vì vậy dữ liệu của nó đã cũ 3 ngày) và Ổ đĩa 3 bị loại bỏ 10 phút trước (vì vậy dữ liệu của nó là hiện tại), việc kéo và cắm lại ổ đĩa sai hoặc buộc phải xây dựng lại với Ổ đĩa 1 được đánh dấu là "hoạt động" và Ổ đĩa 3 được đánh dấu là "dự phòng" sẽ khiến NAS ghi đè lên mảng cập nhật bằng các sọc chẵn lẻ cũ 3 ngày, làm hỏng mọi thư mục và tệp được sửa đổi lần trước 72 giờ.

Giai đoạn 2: Kiểm tra siêu khối và Event đếm an toàn trên máy chủ cứu hộ Linux¶

Để cứu mảng Synology, QNAP, TrueNAS hoặc Linux bị hỏng một cách an toàn, hãy xóa tất cả các ổ đĩa thành viên (sau khi gắn nhãn số khoang của chúng) và gắn chúng vào máy tính để bàn hoặc máy chủ chạy Ubuntu 22.04 LTS / 24.04 LTS (thậm chí được khởi động từ thẻ Live USB).

Bước 1: Cài đặt bộ công cụ cứu hộ pháp y trong Ubuntu¶

Mở một thiết bị đầu cuối trên máy cứu hộ Ubuntu của bạn và cài đặt các tiện ích cần thiết:

sudo apt-get update
sudo apt-get install -y gddrescue smartmontools mdadm lvm2 btrfs-progs xfsprogs zfsutils-linux

Bước 2: Ánh xạ mọi ký tự ổ đĩa, số sê-ri và bố cục phân vùng¶

Liệt kê tất cả các thiết bị khối được kết nối và số sê-ri phần cứng của chúng để bạn không bao giờ nhầm lẫn đĩa cứu hộ với đĩa NAS nguồn:

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,TYPE,MOUNTPOINTS

Xem bảng phân vùng của ổ Synology DSM, QNAP hoặc TrueNAS điển hình:

Bước 3: Kiểm tra mdadm --examine để xem tại sao mảng bị lỗi (Ma trận bộ đếm sự kiện)¶

Trên Synology, QNAP hoặc Linux mdadm mảng, hãy kiểm tra siêu dữ liệu RAID trên các phân vùng dữ liệu người dùng (ví dụ: phân vùng 3 trên /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) mà không cần gắn hoặc sửa đổi bất cứ điều gì:

sudo mdadm --examine /dev/sd[b-e]3 | grep -E "Filename|Magic|Update Time|Events|Array State|Device Role"

So sánh đầu ra trên cả bốn ổ đĩa:

/dev/sdb3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
    Update Time : Thu Oct 29 03:44:11 2026
         Events : 479012
   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdd3:
    Update Time : Sat Oct 31 14:12:04 2026
         Events : 482188
   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sde3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

Đọc câu chuyện pháp y này một cách cẩn thận: 1. /dev/sdc3 (Device Role 1) có một Events số lượng 479012 từ hai ngày trước (Oct 29). Ổ đĩa đó bị rớt đầu tiên cách đây hai ngày và đã ngoại tuyến kể từ đó. 2. /dev/sdb3 (Role 0) và /dev/sde3 (Role 3) cả hai đều có Events : 482190 Tại 14:12:09. 3. /dev/sdd3 (Role 2) có Events : 482188 Tại 14:12:04, chỉ 5 giây và 2 sự kiện phía sau sdb3 và sde3. 4. Kết luận: Bạn phải xây dựng lại mảng bằng cách sử dụng sdb3 (Role 0), sdd3 (Role 2) và sde3 (Role 3) (các bộ đếm sự kiện chỉ cách nhau 2 tích tắc), trong khi ** rời đi sdc3 (Role 1) hoàn toàn bị loại bỏ**.

Giai đoạn 3: Sao chép từng ổ đĩa một với GNU ddrescue¶

Trước khi chạy mdadm --assemble --force hoặc zpool import -F, sao chép từng ổ đĩa được yêu cầu (đặc biệt là ổ đĩa bị loại bỏ lần cuối do các thành phần xấu, chẳng hạn như /dev/sdd trong ví dụ trên) vào một ổ đĩa trống còn tốt có dung lượng bằng hoặc lớn hơn hoặc vào một ổ đĩa thô .img tập tin trên một khối lượng lưu trữ lớn.

Bước 1: Tại sao ddrescue với một tập tin bản đồ là bắt buộc¶

Tiêu chuẩn dd hủy bỏ trên khu vực xấu đầu tiên, hoặc với conv=noerror,sync lãng phí hàng giờ để mài đầu đọc của nó trên một rãnh bị hỏng trong khi hàng megabyte dữ liệu tốt liền kề không được lấp đầy. GNU ddrescue hoạt động theo nhiều bước thông minh: 1. Vượt qua 1 (Giai đoạn sao chép): Sao chép tất cả các vùng khỏe mạnh, phản hồi nhanh của đĩa ở tốc độ tuần tự tối đa (150 MB/s để 250 MB/s), ngay lập tức nhảy qua bất kỳ khối chậm hoặc không thể đọc được nào để ổ đĩa không bị quá nóng hoặc chết trước khi bạn nhận được 99.99% dữ liệu tốt. 2. Đạt 2 (Giai đoạn cắt xén): Đọc chính xác các cạnh của từng khối xấu từ cả mặt trước và mặt sau (reverse direction) để cách ly khu vực bị hư hỏng xuống khu vực phần cứng chính xác 4 kilobyte. 3. Đạt 3 (Giai đoạn cạo): Thử lại các khu vực bị hỏng một cách nhẹ nhàng mà không cần thiết lập lại bus một cách không cần thiết.

Bước 2: Chạy 2 giai đoạn ddrescue lệnh nhân bản¶

Luôn chỉ định mapfile (sdd_rescue.map). Nếu ổ nguồn sắp chết ngắt kết nối và yêu cầu một chu kỳ cấp nguồn, ddrescue đọc tệp bản đồ và tiếp tục ở byte chính xác nơi nó đã dừng lại mà không đọc lại một khu vực đã được sao chép:

# Stage 1: Fast forward pass skipping bad/slow blocks immediately (-n = no-scrape)
sudo ddrescue -f -n -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

# Stage 2: Targeted trimming and 3-retry scrape of the skipped bad sectors
sudo ddrescue -f -d -r 3 -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

Giai đoạn 4: Tái cấu trúc DSM Synology (SHR-1 / SHR-2 / RAID cổ điển), QNAP và Linux mdadm¶

Khi các ổ đĩa nhân bản của bạn (hoặc các thiết bị vòng lặp chỉ đọc) đã sẵn sàng và các ổ đĩa NAS ban đầu được rút phích cắm an toàn, hãy làm theo trình tự lắp ráp không phá hủy chính xác cho nền tảng của bạn.

Kịch bản A: Linux tiêu chuẩn mdadm hoặc RAID cổ điển Synology (RAID 5 / RAID 6)¶

1. Dừng bất kỳ phần nào md mảng mà Ubuntu có thể đã cố gắng khởi động:

   cat /proc/mdstat
   sudo mdadm --stop /dev/md127
   

2. Buộc lắp ráp các phân vùng nhân bản (sdb3, sdd3, sde3, bỏ qua những người đã chết từ lâu sdc3) ở chế độ chỉ đọc nghiêm ngặt:

   sudo mdadm --assemble --force --readonly --verbose /dev/md2 /dev/sdb3 /dev/sdd3 /dev/sde3
   

   Xem đầu ra: mdadm sẽ báo cáo forcing event count in /dev/sdd3(2) from 482188 up to 482190 và mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Xác minh mảng đang hoạt động và được đánh dấu (auto-read-only) hoặc (read-only):

   cat /proc/mdstat
   

Kịch bản B: RAID lai Synology (SHR-1 và SHR-2) với LVM2 và Btrfs / ext4¶

SHR của Synology (Synology Hybrid RAID) là Linux tiêu chuẩn 100 phần trăm mdadm + LVM2 (Logical Volume Manager): - Khi tất cả các ổ đĩa trong nhóm SHR có cùng kích thước (ví dụ: bốn ổ đĩa 8 terabyte), Synology sẽ tạo một ổ đĩa duy nhất mdadm Phân vùng RAID 5 (md2 trên phân vùng 3 của mỗi ổ đĩa) và đặt một LVM2 nhóm khối lượng (vg1000 hoặc vg1) ở trên md2. - Khi các ổ đĩa trong nhóm SHR có kích thước khác nhau (ví dụ: hai ổ đĩa 8 terabyte và hai ổ đĩa 16 terabyte), Synology sẽ tạo hai ổ đĩa riêng biệt mdadm mảng: md2 trên phân vùng 5 (8 TB slice trên cả 4 ổ đĩa trong RAID 5) và md3 trên Phân vùng 6 (phần còn lại 8 TB cắt trên hai ổ 16 TB trong RAID 1), sau đó nối md2 + md3 thành một LVM2 Nhóm khối lượng (vg1000).

Để gắn ổ đĩa Synology SHR chỉ đọc trên Ubuntu sau khi lắp ráp bắt buộc /dev/md2 (và /dev/md3 nếu SHR có kích thước hỗn hợp): 1. Quét các nhóm khối lượng và khối lượng vật lý Synology LVM2:

sudo pvscan
sudo vgscan
sudo lvscan

sudo vgchange -ay /dev/vg1000

sudo mkdir -p /mnt/synology_rescue
sudo mount -t ext4 -o ro,noload /dev/vg1000/lv /mnt/synology_rescue

sudo mkdir -p /mnt/synology_rescue
sudo mount -t btrfs -o ro,norecovery /dev/vg1000/lv /mnt/synology_rescue

sudo mount -t btrfs -o ro,norecovery,usebackuproot /dev/vg1000/lv /mnt/synology_rescue

Kịch bản C: Synology DSM 7+ Mã hóa ổ đĩa hoặc Mã hóa thư mục dùng chung (eCryptfs)¶

• Mã hóa thư mục dùng chung (@sharename@ thư mục chứa ECRYPTFS_FNEK_ENCRYPTED... tên tệp): Sao chép toàn bộ @encrypted_share@ tắt thư mục /mnt/synology_rescue trước tiên, sau đó gắn và giải mã nó trên Ubuntu bằng mật khẩu mã hóa Synology của bạn hoặc .key tập tin:

  sudo apt-get install -y ecryptfs-utils
  sudo mkdir -p /mnt/decrypted_share
  sudo mount -t ecryptfs -o ro /mnt/synology_rescue/@encrypted_share@ /mnt/decrypted_share
  

• ** Mã hóa toàn bộ khối lượng DSM 7.2+ (LUKS)**: Nếu /dev/vg1000/lv chương trình TYPE="crypto_LUKS" trong blkid, mở khóa nó ở chế độ chỉ đọc bằng cách sử dụng .rkey Tệp Khóa khôi phục được tải xuống khi ổ đĩa được tạo:

  sudo cryptsetup open --readonly --key-file /path/to/Volume1.rkey /dev/vg1000/lv synology_crypt
  sudo mount -o ro,norecovery /dev/mapper/synology_crypt /mnt/synology_rescue
  

Kịch bản D: QNAP QTS (LVM2 Thin Provisioning và DRBD lớp)¶

Các đơn vị NAS QNAP hiện đại (QTS 4.3+ / 5.x) chèn một nút đơn bên trong DRBD thiết bị (/dev/drbd1) giữa /dev/md1 và LVM2 Nhóm khối lượng (vg1). 1. Trước tiên hãy tập hợp các phân vùng dữ liệu QNAP (/dev/sd[b-e]3) chỉ đọc vào /dev/md1:

sudo mdadm --assemble --force --readonly /dev/md1 /dev/sdb3 /dev/sdd3 /dev/sde3

Giai đoạn 5: Giải cứu TrueNAS và Linux ZFS hồ bơi (RAIDZ1, RAIDZ2, RAIDZ3)¶

Nếu máy chủ lưu trữ của bạn chạy TrueNAS CORE, TrueNAS SCALE, Proxmox VE hoặc Ubuntu ZFS, thì quá trình khôi phục sẽ không được sử dụng mdadm. Thay vào đó, ZFS kết hợp trình quản lý âm lượng và sao chép khi ghi (CoW) thành một kiến trúc giao dịch duy nhất được xây dựng xung quanh Uberblocks và tuần tự Nhóm giao dịch (TXGs).

Bước 1: Kiểm tra 4 nhãn ZFS vdev (L0, L1, L2, L3) trên mỗi đĩa nhân bản¶

Mỗi phân vùng thành viên ZFS lưu trữ bốn bản sao cấu hình nhóm giống hệt nhau và một mảng gồm 128 Uberblocks cuối cùng (hai nhãn ở phía trước phân vùng, L0 và L1, và hai nhãn ở cuối, L2 và L3). Chạy zdb -l trên mỗi phân vùng nhân bản để kiểm tra trạng thái nhóm và Nhóm giao dịch được cam kết cao nhất (txg):

sudo zdb -l /dev/sdb2 | grep -E "name:|state:|txg:|guid:" | head -n 20

So sánh txg: số trên tất cả các ổ đĩa nhân bản. Giống như mdadmcủa Events bộ đếm, nếu một đĩa bị mất 5 phút trước khi mất điện hoặc mất đĩa thứ hai, thì đĩa đó txg sẽ thấp hơn một chút so với các đĩa còn lại.

Bước 2: Nhập nhóm ZFS ở chế độ Chỉ đọc nghiêm ngặt (-o readonly=on)¶

Trước tiên hãy kiểm tra các nhóm có thể nhập mà không cần gắn bất cứ thứ gì thông qua sudo zpool import -d /dev/disk/by-id. Không bao giờ nhập nhóm ZFS bị hỏng hoặc bị rơi nhiều đĩa ở chế độ đọc-ghi. Khi nhập khẩu với -o readonly=on, ZFS không cố gắng khởi động quá trình phục hồi, không viết Uberblocks mới và không thể làm hoảng loạn hạt nhân nếu bản đồ không gian bị hỏng (spacemap) gặp phải trong quá trình phân bổ ghi:

sudo mkdir -p /mnt/zfs_rescue
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue tank

Bước 3: Nếu zpool import thất bại với I/O error hoặc corrupted data, sử dụng Khôi phục TXG (-F và -T)¶

Nếu hai ổ đĩa bị rớt cách nhau vài giây trong một đợt ghi nặng, Nhóm giao dịch mới nhất (TXG N) có thể không đầy đủ trên các sọc chẵn lẻ còn sót lại, trong khi TXG N-1 hoặc TXG N-2 (được viết trước đó từ 5 đến 15 giây) nguyên vẹn 100% bên trong bộ đệm vòng Uberblock.

1. Kiểm tra bản xem trước khôi phục chạy khô không phá hủy (-F -n):

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F -n tank
   

   Nếu ZFS báo cáo Would be able to return pool to its state as of <timestamp>, chạy quá trình nhập khôi phục chỉ đọc mà không cần -n:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F tank
   

2. Nếu -F vẫn không thể gắn Uberblocks mới nhất, liệt kê các số Uberblock TXG lịch sử với zdb và nhập một TXG cũ cụ thể (-T):

   sudo zdb -e -ul /dev/sdb2 | grep -E "Uberblock|txg =|timestamp ="
   

   Chọn một txg số từ 30 đến 60 giây trước khi xảy ra va chạm (ví dụ: txg = 9481020) và nhập nhóm bị đóng băng tại thời điểm chính xác đó ở chế độ chỉ đọc:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -T 9481020 tank
   

Giai đoạn 6: Xác minh sau khôi phục và ngăn chặn các đợt xây dựng lại trong tương lai¶

Khi bạn đã sao chép 100 phần trăm dữ liệu đã khôi phục của mình từ /mnt/synology_rescue hoặc /mnt/zfs_rescue vào mục tiêu sao lưu độc lập, hãy làm theo danh sách kiểm tra cấu hình và phần cứng này trước khi đưa NAS của bạn vào hoạt động trở lại:

• Không bao giờ mua tất cả các ổ NAS từ cùng một nhà bán lẻ trong cùng một ngày: Các ổ đĩa từ cùng một lô sản xuất có chung lô đầu và chương trình cơ sở giống hệt nhau, khiến chúng bị lỗi cách nhau vài giờ trong quá trình xây dựng lại. Trộn theo lô hoặc nhà sản xuất (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• Chỉ sử dụng ổ đĩa NAS/Enterprise có TLER / SCT ERC đã bật (hoặc nâng cao Linux mdadm Thời gian chờ SCSI cho ổ đĩa máy tính để bàn): Dành cho ổ đĩa tiêu dùng trong Linux mdadm, sử dụng một udev quy tắc nâng cao /sys/block/sdX/device/timeout từ 30 giây để 180 giây vậy mdadm chờ ánh xạ lại khu vực nội bộ thay vì bỏ ổ đĩa.
• ** Di chuyển mảng có ổ đĩa lớn hơn 8 TB từ RAID 5 / SHR-1 / RAIDZ1 để RAID 6 / SHR-2 / RAIDZ2**: Với 12 TB để 24 TB ổ đĩa, thời gian xây dựng lại chẵn lẻ đơn vượt quá 30 giờ, tạo nên tính chẵn lẻ kép (RAID 6 / SHR-2 / RAIDZ2) quan trọng để tồn tại trong khu vực xấu trong quá trình phục hồi.
• Lịch trình hàng tháng Data Scrubbing (mdadm check / zpool scrub) và mở rộng SMART kiểm tra: Quét hàng tháng sửa chữa các lỗi khu vực tiềm ẩn (Current_Pending_Sector) trong khi tất cả các ổ đĩa đều trực tuyến.
• Hãy nhớ rằng RAID có tính sẵn sàng cao, không bao giờ là bản sao lưu: Hãy làm theo Chiến lược dự phòng 3-2-1 với một bản sao ngoại tuyến.

Số khẩn cấp khu vực và các quy trình của cơ quan¶

Việc ngừng lưu trữ ảnh hưởng đến mạng lưới chăm sóc sức khỏe, thông tin liên lạc khẩn cấp hoặc hồ sơ cá nhân theo luật định cần được báo cáo ngay lập tức:

• Hoa Kỳ và Canada: Quay số 911 nếu sự cố lưu trữ làm vô hiệu hóa hệ thống lâm sàng của bệnh viện (EHR / PACS) hoặc gửi đi. Báo cáo phần mềm ransomware nhắm mục tiêu vào NAS (DeadBolt, LockBit, Akira) tới CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov) hoặc Trung tâm An ninh mạng Canada (1-833-CYBER-88).
• Vương quốc Anh: Quay số999 dành cho các trường hợp khẩn cấp ảnh hưởng đến an toàn tính mạng hoặc chăm sóc NHS cấp tính. Theo GDPR của Vương quốc Anh, hãy đánh giá xem liệu việc mất dữ liệu cá nhân vĩnh viễn chưa được sao lưu có cần thông báo ICO (0303 123 1113) trong vòng 72 giờ.
• Liên minh Châu Âu: Quay số 112 trên khắp EU. Các thực thể theo Chỉ thị NIS2 phải báo cáo các trường hợp ngừng hoạt động lớn cho CSIRT quốc gia của họ trong vòng 24 giờ và các nguyên nhân gây mất dữ liệu cá nhân vĩnh viễn Điều 33 GDPR báo cáo trong vòng 72 giờ.
• Úc và New Zealand: Quay số 000 ở Úc hoặc 111 ở New Zealand; báo cáo sự cố về cơ sở hạ tầng hoặc ransomware NAS cho ACSC (1300 CYBER1) hoặc CERT New Zealand (0800 237 869).
• Ấn Độ và Châu Á - Thái Bình Dương: Quay số 112 ở Ấn Độ để ứng phó khẩn cấp; báo cáo sự cố lưu trữ cơ sở hạ tầng tới CERT-In (incident@cert-in.org.in) trong khoảng thời gian 6 giờ bắt buộc.

Câu hỏi thường gặp¶

Tại sao lại làm vậy mdadm --assemble --force từ chối khởi động mảng RAID 5 của tôi với not enough to start the array?¶

Trong xe 4 bánh đột kích 5 mảng, ít nhất 3 trên 4 ổ đĩa phải được chuyển đến mdadm --lắp ráp --lực lượng. Chạy sudo mdadm --examine /dev/sd[a-z]3 để kiểm tra lý do tại sao ổ đĩa thứ ba bị từ chối: hoặc bạn đã chuyển toàn bộ đĩa thay vì phân vùng (/dev/sdd thay vì /dev/sdd3), siêu khối của nó được đánh dấu là dự phòng do quá trình xây dựng lại bị gián đoạn hoặc trình biên dịch tự động của Ubuntu đã khóa một ổ đĩa vào trạng thái không hoạt động /dev/md127 thiết bị (chạy sudo mdadm --stop --scan đầu tiên, sau đó chạy lại mdadm --assemble --force --readonly).

Điều gì sẽ xảy ra nếu một ổ đĩa bắt đầu được xây dựng lại (Recovery = 12%) trước khi ổ đĩa thứ hai bị hỏng?¶

Nếu Ổ 2 bị hỏng, bạn đã lắp Ổ đĩa 2 thay thế và tại 12% tiến trình xây dựng lại Ổ 3 bị ngừng ngoại tuyến do khu vực xấu, không sử dụng Drive 2 thay thế được xây dựng lại 12%. Thay vào đó hãy sao chép bản gốc Ổ 3 với giải cứu. Bởi vì Ổ 3 hoàn toàn hiện hành cho đến khi quá trình xây dựng lại dừng ở mức 12%, buộc phải tập hợp mảng ở chế độ chỉ đọc bằng Ổ 1, giải cứu bản sao của Ổ 3 và Ổ 4 (bỏ Ổ 2) cung cấp cho bạn một mảng nhất quán.

Tôi có thể đặt ổ Synology hoặc QNAP của mình vào khung NAS hoàn toàn mới nếu bộ nguồn hoặc bo mạch NAS bị hỏng không?¶

Có, cả Synology (Di chuyển ổ cứng) và QNAP (Di chuyển NAS trực tiếp) lưu trữ cấu hình RAID trên các ổ đĩa. Tuy nhiên, nếu hai hoặc nhiều ổ đĩa đã bị loại bỏ (`Volume Crashed`) trước khi khung máy bị hỏng, không khởi động chúng bên trong khung máy NAS mới, vì trình hướng dẫn di chuyển có thể ghi đè lên các phân vùng hoặc kích hoạt quá trình xây dựng lại mang tính phá hủy. Trước tiên hãy cứu dữ liệu chỉ đọc trên Ubuntu.

Làm cách nào để biết ổ đĩa bị rơi có an toàn để sao chép hay không ddrescue so với việc cần một phòng thí nghiệm phòng sạch?¶

Kết nối ổ đĩa với SATA, bật nguồn và nghe trong 10 giây trong khi xem sudo dmesg -w. Nếu ổ đĩa phát ra các âm thanh nhấp chuột, cọ xát hoặc ù ù nhịp nhàng, quay lên và quay xuống hoặc báo cáo dung lượng là 0 B / 4,1GB trong lsblk, đầu đọc/ghi đã bị lỗi về mặt vật lý: hãy cắt điện ngay lập tức và sử dụng phòng thí nghiệm phòng sạch. Nếu ổ đĩa quay trơn tru, hiển thị hết công suất trong lsblkvà chỉ nhật ký Current_Pending_Sector hoặc lỗi hết thời gian chờ, hãy sao chép nó bằng giải cứu.

"Lỗ ghi RAID 5" là gì và nó hoạt động như thế nào ZFS hoặc Btrfs tránh nó khi mất điện?¶

Trong truyền thống đột kích 5 / đột kích 6 không có nhật ký, việc cập nhật một sọc yêu cầu ghi khối dữ liệu và khối chẵn lẻ vào hai đĩa cùng một lúc. Nếu mất điện trong khi ghi, dữ liệu và tính chẵn lẻ không còn khớp nữa ( viết lỗ). ZFS (`RAIDZ`) và Btrfs loại bỏ lỗ ghi bằng cách sử dụng Copy-on-Write (`CoW`), ghi mọi sọc mới vào các khối chưa sử dụng và chỉ cập nhật con trỏ Uberblock/gốc sau khi sọc đầy đủ đã có trên đĩa.

Tôi có thể sử dụng không? dmsetup lớp phủ để kiểm tra các tham số RAID mà không sửa đổi ổ đĩa nhân bản?¶

Có, bạn có thể tạo Copy-on-Write (`CoW`) phủ lên trên các thiết bị vòng lặp chỉ đọc (`losetup --read-only`) sử dụng Linux dmsetup (`snapshot` target) được hỗ trợ bởi các tệp thưa thớt trong /tmp. Bất kỳ viết từ mdadm --lắp ráp --lực lượng hoặc fsck -y đi vào đồ dùng một lần /tmp tập tin lớp phủ, cho phép bạn đặt lại sau 1 giây nếu cần.

Hướng dẫn liên quan¶

• Mảng RAID NAS bị xuống cấp, lỗi nhiều ổ đĩa và khôi phục ZFS/Btrfs
• Thẻ điều khiển RAID bị hỏng, nhập cấu hình nước ngoài và lý do bạn không bao giờ được khởi tạo đĩa
• Lỗi ổ cứng và phục hồi dữ liệu
• Chế độ chỉ đọc đột ngột của SSD và NVMe, 0% khối dự phòng và cứu hộ vô hiệu hóa TRIM
• rm -rf hoặc Shift+Delete ngẫu nhiên trên Linux, macOS hoặc Windows: kết nối lại chỉ đọc ngay lập tức
• Sao lưu máy tính, chiến lược 3-2-1 và khắc phục thảm họa
• Số khẩn cấp theo quốc gia

Nguồn và hướng dẫn chính thức¶

• Wiki đột kích Linux (raid.wiki.kernel.org) & Tổ chức hạt nhân Linux: Khôi phục RAID phần mềm bị lỗi (mdadm --assemble --force --readonly và Bộ đếm sự kiện không khớp).
• Tổ chức phần mềm miễn phí (GNU Project): GNU ddrescue Hướng dẫn sử dụng: Phục hồi dữ liệu pháp y từ phương tiện bị lỗi.
• Tài liệu OpenZFS (openzfs.github.io): Phục hồi nhập nhóm ZFS (zpool import -F, Nhập chỉ đọc và zdb Kiểm tra).
• Synology Inc.: Trung tâm kiến thức Synology: Làm cách nào tôi có thể sử dụng PC để khôi phục dữ liệu khi NAS Synology của tôi gặp trục trặc (mdadm + LVM2 Lắp đặt).
• Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) (Hoa Kỳ): Ấn bản đặc biệt 800-209: Nguyên tắc bảo mật cho cơ sở hạ tầng lưu trữ.