RAID 5 or RAID 6 Degraded Array With Second Drive Failing During Rebuild (Why Never Run CHKDSK or fsck, ddrescue Sector Cloning, and mdadm Read-Only Assembly)¶

Replacing a failed hard drive in a degraded RAID 5 ຫຼື RAID 6 ເຄື່ອງແມ່ຂ່າຍການເກັບຮັກສາ, Synology DiskStation, QNAP NAS, Linux mdadm array, or Dell PERC / HP Smart Array / LSI MegaRAID hardware controller only to watch a second remaining member drive throw UNC (Uncorrectable Read Error) bad sectors, Pending Sectors, or drop offline at 42% of the parity rebuild is one of the most dangerous storage emergencies in enterprise and home-lab computing. In a single-parity RAID 5 array (N - 1 fault tolerance), the mathematical XOR reconstruction of the replacement disk requires reading every single sector (LBA 0 to the final LBA) across 100 percent of the remaining N - 1 member drives simultaneously. When modern high-capacity 8 TB ກັບ 24 TB helium drives (purchased from the same manufacturing batch and subjected to identical thermal and vibration hours) undergo a multi-terabyte sequential rebuild read, a single latent media defect (URE) or weak read head on a second drive causes the RAID controller to abort the rebuild, kick the second drive out as Faulty / Crashed, and mark the entire storage pool Offline / Crashed / Superblock Event Count Mismatch.

Do not panic, and do not force a second rebuild or run filesystem repair utilities (fsck, e2fsck, xfs_repair, or Windows CHKDSK). Even when a second drive in RAID 5 (or third drive in RAID 6) develops 50 ກັບ 5,000 bad sectors and gets kicked out of the array, 99.9999 percent of the sectors on that "failed" second drive are still 100 percent readable. By immediately halting the array, cloning every unstable member disk sector-by-sector onto healthy spare drives using GNU ddrescue, and assembling the cloned images in Read-Only / --assume-clean overlay mode (mdadm + dmsetup Copy-on-Write loop overlays), you can mount the filesystem safely and copy out virtually every file intact. For NAS appliance specifics and hardware controller failures, read our companion guides on RAID 5 or RAID 6 Synology, QNAP, or TrueNAS multiple drive drop, RAID controller card death and foreign configuration import, ແລະ NAS RAID array degraded and ZFS/Btrfs recovery. If your server failure impacts life-safety systems or medical infrastructure, contact your local emergency number (911 ໃນສະຫະລັດແລະການາດາ, 112 ໃນ​ທົ່ວ​ສະ​ຫະ​ພາບ​ເອີ​ຣົບ​, 999 ໃນສະຫະລາຊະອານາຈັກ) ຫຼືກວດເບິ່ງລາຍການຂອງພວກເຮົາ ຕົວເລກສຸກເສີນ.

ເຮັດອັນນີ້ດຽວນີ້¶

1. Abort any active parity rebuild or scrub immediately and power down the array cleanly (or disconnect SATA/SAS backplane power if a drive is making mechanical clicking or scraping noises):
2. Why letting a stalling rebuild continue destroys the array: When a member drive hits a bad sector patch (LBA read timeout) or has a degrading read/write head (media scratch), leaving the RAID controller retrying sectors for hours grinds the microscopic magnetic platter coating into dust across the entire track cylinder, turning a recoverable 20-sector defect into a catastrophic full-platter head crash.
3. NEVER run CHKDSK /f, fsck -y, e2fsck, btrfs check --repair, ຫຼື xfs_repair on a degraded, out-of-sync, or half-rebuilt RAID array:
4. ເປັນຫຍັງ CHKDSK ແລະ fsck cause 100% permanent data destruction on out-of-sync RAID: If Drive 2 dropped out on Tuesday and Drive 3 dropped out during Thursday's rebuild, the mdadm or hardware RAID Event Counter (Update Time) on those two drives differs by thousands of transactions. If you force-assemble an array with mismatched drive generations or missing stripes and allow fsck ຫຼື CHKDSK to write to the array, the filesystem checker sees broken inode trees caused by misaligned RAID stripes, deletes millions of valid directory entries into lost+found, ແລະຂຽນທັບເສັ້ນດ່າງຂໍ້ມູນທີ່ດີດ້ວຍຄວາມສະເໝີພາບທີ່ເສຍຫາຍໃນທົ່ວທຸກແຜ່ນໃນອາເຣ.
5. ** ບໍ່​ເຄີຍ​ຄລິກ​ໃສ່​ "Create Array", "Initialize", ຫຼື "Clear Configuration" in a hardware RAID BIOS, and NEVER run mdadm --create ໂດຍບໍ່ມີການ --assume-clean and a Copy-on-Write (COW) loop overlay**:
6. Running a standard mdadm --create (without --assume-clean and matching exact chunk size, layout, and data offset) immediately begins writing new parity stripes across all disks, destroying the filesystem superblock and B-trees if any single parameter (512K ທຽບກັບ 64K chunk, left-symmetric ທຽບກັບ left-asymmetric, ຫຼື 2048s ທຽບກັບ 262144s data offset) is wrong by even one sector.
7. Label every physical hard drive slot (Bay 0 / Bay 1 / Bay 2 / Bay 3 and serial number) with a permanent marker or tape BEFORE pulling a single drive out of the chassis:
8. Write the exact bay number and serial number on the top label of each drive. Knowing the physical bay order and checking mdadm --examine metadata saves hours of stripe-order reconstruction later.
9. Clone the failing drive(s) sector-by-sector to healthy new drives using GNU ddrescue (with a mapfile) over direct motherboard SATA/HBA ports BEFORE attempting any RAID assembly:
10. Never attempt to assemble or mount a RAID array using the physically dying drive itself. Connect the failing drive to a non-RAID SATA/AHCI or LSI IT-Mode HBA port on a Linux rescue workstation, disable OS auto-mounting, and run ddrescue -f -n /dev/sdX /dev/sdY rescue_driveX.map so the healthy fast sectors are evacuated in pass one before touching bad sector zones.
11. Assemble the cloned drives in Read-Only mode (mdadm --assemble --readonly or using dmsetup / losetup RAM/file overlays):
12. By placing a disposable Copy-on-Write (COW) overlay file on top of each cloned member disk, you can test-mount the array, replay an ext4 ຫຼື XFS journal, or even test a virtual rebuild while guaranteeing that zero bytes are ever modified on your underlying disk clones.

Decision tree: rescuing a RAID 5 or RAID 6 array when a second drive fails during rebuild¶

Follow this forensic storage recovery workflow to recover your array without losing a single surviving stripe:

flowchart TD
    Start["RAID 5 (2nd Drive) or RAID 6 (3rd Drive) Fails / Drops Offline During Rebuild"] --> StopNow["STEP 1: Abort Rebuild Immediately & Power Down Array (Prevent Platter Scoring on Failing Drive)"]

    StopNow --> SoundCheck{"Did the Failing Drive Make Loud Clicking, Beeping, or Grinding Sounds?"}

    SoundCheck -->|"YES: Mechanical Head Crash / Stiction"| CleanRoom["STOP: Do Not Power That Drive On Again. Send ONLY the Mechanically Failed Drive (Plus 1 Healthy Drive for Stripe Reference) to a Cleanroom Lab to Image Onto a Clone"]

    SoundCheck -->|"NO: Spins Smoothly, Failed Due to Bad Sectors (UNC / Pending / Timeout)"| LabelDrives["STEP 2: Label Every Drive With Its Exact Bay Number & Serial Number -> Connect to Linux Workstation via Direct SATA / IT-Mode HBA"]

    LabelDrives --> InspectMeta["Run 'mdadm --examine /dev/sd*' and 'smartctl -a /dev/sd*' on All Drives (Record Update Time, Events Counter, Role, Chunk Size, Layout, Data Offset)"]

    InspectMeta --> CloneDrives["STEP 3: Clone Every Degraded / Bad-Sector Drive to a Healthy Spare Drive Using 'ddrescue -f -n' (Fast Pass First, Then Scrape Pass With Mapfile)"]

    CloneDrives --> PickFreshest["Identify the N-1 (RAID 5) or N-2 (RAID 6) Drives With the HIGHEST / MOST RECENT 'Events' Counter (Never Mix a Stale Old Dropped Drive With Fresh Drives)"]

    PickFreshest --> CowOverlay["STEP 4: Create Read-Only Loop / 'dmsetup' Copy-on-Write (COW) Overlays Over the Cloned Drives So Original Clones Cannot Be Modified"]

    CowOverlay --> AssembleRO["Run 'mdadm --assemble --force --readonly' on the Overlay Devices -> Mount Filesystem Read-Only ('mount -o ro,noload') -> Copy All Critical Data to External Storage"]

Phase 1: Understanding why a second drive fails during a RAID rebuild (XOR Parity Math & Event Counters)¶

To understand why your array crashed mid-rebuild and why your data is still recoverable, examine how RAID 5 ແລະ RAID 6 actually work on disk.

1. How XOR parity reconstruction works and why 1 bad sector aborts an entire rebuild¶

In a 4-drive RAID 5 array (Drive A, Drive B, Drive C, Drive D), data is split into fixed-size chunks (typically 64 KB ຫຼື 512 KB) striped across the disks, where one chunk in each row holds the XOR Parity (P): $\(\text{Parity } P = A \oplus B \oplus C\)$ If Drive C fails completely and you insert a blank Replacement Drive C_new, the RAID controller must reconstruct every stripe on C_new by calculating: $\(C_{\text{reconstructed}} = A \oplus B \oplus P\)$ - What happens when Drive B hits a single unreadable 4 KB sector (UNC error) at 42% of the rebuild: - To calculate that single 4 KB block on C_new, the controller must have a valid read from Drive A, Drive B, ແລະ Drive D. - When Drive B returns a hardware Read Error (Sense Key 03h / 11h Unrecovered Read Error) after 7 seconds (TLER / ERC timeout), consumer and enterprise RAID controllers are often programmed with a catastrophic default behavior: instead of skipping that single 4 KB sector, logging a zero block, and finishing the other 99.9999% of the rebuild, the RAID controller marks Drive B as FAILED / OFFLINE and aborts the entire rebuild. - At that moment, your array has two drives marked "Failed" (Drive C ເຊິ່ງພຽງແຕ່ 42% ສ້າງຂຶ້ນໃຫມ່, ແລະ Drive B ເຊິ່ງຕົວຈິງແລ້ວມີ 99.99998% ຂະ​ແຫນງ​ການ​ສຸ​ຂະ​ພາບ​ແລະ​ພຽງ​ແຕ່​ 12 ຂະ​ແໜງ​ການ​ທີ່​ບໍ່​ດີ).

2. ເປັນຫຍັງ Event Counters (Update Time) ກໍານົດ drive ທີ່ເຈົ້າຕ້ອງໃຊ້ສໍາລັບການຟື້ນຕົວ¶

ທຸກໆຄັ້ງ ກ RAID 5 ຫຼື RAID 6 array ຂຽນຂໍ້ມູນຫຼືການປ່ຽນແປງສະຖານະ (ເຊັ່ນ: drive ຫຼຸດລົງ), metadata RAID (mdadm superblock ຫຼືຮາດແວ DDF metadata) ເພີ່ມເປັນ 64-bit Events ໂຕ້ຕອບ ຢູ່ໃນໄດຣຟ໌ທັງໝົດທີ່ເຮັດວຽກຢູ່ໃນຂະນະນີ້.

Compare the mdadm --examine ຜົນຜະລິດຂອງ 4-drive ປົກກະຕິ RAID 5 ໄພພິບັດຢູ່ໃສ sdb ລົ້ມເຫລວມື້ວານນີ້ (Events: 10450) ແລະ sdc ອອກ​ໄປ​ໃນ​ລະ​ຫວ່າງ​ການ​ສ້າງ​ຄືນ​ໃຫມ່​ຂອງ​ມື້​ນີ້ (Events: 10892):

• **ກົດ​ລະ​ບຽບ Golden ຂອງ​ການ​ຟື້ນ​ຕົວ RAID ຈາກ​ຕາ​ຕະ​ລາງ​ຂ້າງ​ເທິງ **​:
• ສັງເກດເຫັນວ່າ /dev/sda (10892), /dev/sdc (10890), ແລະ /dev/sdd (10892) ທັງ​ຫມົດ​ມີ virtually ຄື​ກັນ​ Events counters ຈາກ Today 14:22.
• ເມື່ອພວກເຮົາ clone /dev/sdc ໃສ່​ການ​ຂັບ​ລົດ​ສຸ​ຂະ​ພາບ​ໂດຍ​ນໍາ​ໃຊ້​ ddrescue (ການຟື້ນຕົວ 99.9999% ຂອງຂະແຫນງການຂອງຕົນແລະສູນການຕື່ມ 8 ພາກສ່ວນທີ່ບໍ່ສາມາດອ່ານໄດ້), ພວກເຮົາສາມາດບັງຄັບ-ປະກອບ /dev/sda + Cloned /dev/sdc + /dev/sdd (ບໍ່​ສົນ​ໃຈ​ການ​ສ້າງ​ໃຫມ່​ເຄິ່ງ​ຫນຶ່ງ​ /dev/sdb ຫມົດ). ການປະສົມປະສານ 3-drive ນັ້ນເຮັດໃຫ້ພວກເຮົາມີຄວາມສອດຄ່ອງ 100 ເປີເຊັນ, ເຊື່ອມໂຊມເຖິງວິນາທີ RAID 5 array** ບໍ່ມີການຈີກຂາດເສັ້ນດ່າງ.

ໄລຍະ 2: ການ cloning ຂະແຫນງການຂັ້ນຕອນໂດຍຂັ້ນຕອນຂອງການຂັບລົ້ມເຫລວກັບ GNU ddrescue¶

ກ່ອນທີ່ທ່ານຈະສໍາຜັດ mdadm ຫຼືເຄື່ອງມືປະກອບ RAID ໃດນຶ່ງ, ເຈົ້າ ຕ້ອງ ໂຄນໄດຣຟ໌ທີ່ຖິ້ມຄວາມຜິດພາດໃນການອ່ານໃສ່ໄດຣຟ໌ທົດແທນທີ່ມີສຸຂະພາບດີຂອງຄວາມຈຸຂອງໄບຕ໌ເທົ່າກັນ ຫຼືໃຫຍ່ກວ່າ.

ຂັ້ນຕອນທີ 1: ກະກຽມສະພາບແວດລ້ອມການກູ້ໄພ Linux ແລະປິດການປະກອບອັດຕະໂນມັດ¶

1. ບູດສະຖານີບ່ອນເຮັດວຽກ Linux (ຫຼືບູດເຊີບເວີຂອງເຈົ້າຈາກແຜ່ນ USB ທີ່ມີຊີວິດຊີວາເຊັ່ນ SystemRescue system-rescue.org ຫຼື Ubuntu Live Server) ກັບໄດທີ່ເຊື່ອມຕໍ່ກັບມາດຕະຖານ ພອດ SATA motherboard ຫຼື LSI HBA ໃນ IT Mode (ບໍ່ຜ່ານ RAID).
2. ** ປ້ອງ​ກັນ Linux ຈາກ​ການ​ພະ​ຍາ​ຍາມ​ອັດ​ຕະ​ໂນ​ມັດ​ທີ່​ຈະ​ປະ​ກອບ​ຫຼື​ຕິດ​ຕໍ່​ອາ​ເຣ RAID ທີ່​ແຕກ​ຫັກ​ຂອງ​ທ່ານ​ກ່ຽວ​ກັບ​ການ boot **​:
3. ເມື່ອເປີດ SystemRescue ຫຼື Ubuntu Live, ໃຫ້ກວດເບິ່ງ cat /proc/mdstat. ຖ້າ Linux ປະກອບບາງສ່ວນໂດຍອັດຕະໂນມັດ md ອຸປະກອນໃນພື້ນຫຼັງ, ຢຸດມັນທັນທີໃນໂໝດປອດໄພແບບອ່ານເທົ່ານັ້ນກ່ອນທີ່ຈະຖ່າຍຮູບ:

   mdadm --stop /dev/md*
   

4. ** ກໍາ​ນົດ​ການ​ຂັບ​ລົດ​ທຸກ​ໂດຍ​ຕົວ​ແບບ​ທີ່​ແນ່​ນອນ​, ຈໍາ​ນວນ serial​, ແລະ​ຂະ​ຫນາດ byte ** (ບໍ່​ເຄີຍ​ເດົາ​ໄດ້​ /dev/sdX ຕົວອັກສອນ, ເພາະວ່າ Linux ມອບໝາຍຕົວອັກສອນຂັບຄືນໃໝ່ໃນທົ່ວການປິດເປີດໃໝ່):

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

   ຂຽນອັນໃດ /dev/sdX ສອດຄ້ອງກັບ Failing Source Drive ຂອງທ່ານ (ຕົວຢ່າງ: /dev/sdc, ລໍາດັບ WCC4E12345) ແລະອັນໃດ /dev/sdY ແມ່ນBrand-New Blank Target Drive ຂອງທ່ານ (ຕົວຢ່າງ: /dev/sdf, ລໍາດັບ ZGG9988776).

ຂັ້ນຕອນທີ 2: ດໍາເນີນການ 2-Stage GNU ddrescue ໂປຣໂຕຄອນໂຄລນ (ໃຊ້ໄຟລ໌ແຜນທີ່ສະເໝີ)¶

ຢ່າໃຊ້ມາດຕະຖານ dd (dd if=/dev/sdc of=/dev/sdf) ໃນ RAID drive ທີ່ລົ້ມເຫລວ: ມາດຕະຖານ dd ທັງການເອົາລູກອອກໃນຂະແຫນງທີ່ບໍ່ດີທໍາອິດຫຼືປ່ຽນຜົນຜະລິດຊົດເຊີຍຖ້າ sync ມັນຖືກຕັ້ງຄ່າຜິດ, ແລະມັນບໍ່ມີຄວາມຊົງຈໍາກ່ຽວກັບຂະແຫນງການໃດທີ່ປະສົບຜົນສໍາເລັດ. GNU ddrescue (gddrescue package) ໃຊ້ແຜນທີ່ລັດ multi-pass ອັດສະລິຍະ:

1. ** ຜ່ານ 1: Clone ບໍ່ຂູດໄວ (-n flag) ເພື່ອ​ຊ່ວຍ​ເຫຼືອ 99.99% ຂອງ​ຂະ​ແຫນງ​ການ​ສຸ​ຂະ​ພາບ​ເປັນ​ຄັ້ງ​ທໍາ​ອິດ **​:

   ddrescue -f -n -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
   

2. -f: ອະນຸຍາດໃຫ້ຂຽນໂດຍກົງເພື່ອບລັອກອຸປະກອນ /dev/sdf (** ໃຫ້​ກວດ​ເບິ່ງ​ສາມ​ຄັ້ງ /dev/sdc ແມ່ນແຫຼ່ງແລະ /dev/sdf ແມ່ນ​ເປົ້າ​ຫມາຍ​ເປົ່າ **).
3. -n (--no-scrape): ບອກ ddrescue ທັນທີທັນໃດກະໂດດຂ້າມຂົງເຂດຂະແຫນງການທີ່ຊ້າຫຼືບໍ່ດີໂດຍບໍ່ມີການ grinding ຫົວອ່ານ, rescuing gigabytes ສຸຂະພາບທັງຫມົດດ້ວຍຄວາມໄວສູງສຸດ (150 to 250 MB/s) ກ່ອນທີ່ສຸຂະພາບຂອງຂັບຈະຮ້າຍແຮງຂຶ້ນ.
4. /root/raid_bay3_sdc.map: ບັນທຶກຄວາມຄືບໜ້າຂອງຂະແໜງການທີ່ແນ່ນອນທຸກໆ 30 ວິນາທີ. ເຖິງແມ່ນວ່າ drive ທີ່ລົ້ມເຫລວຈະລັອກຂຶ້ນແລະຕ້ອງການວົງຈອນພະລັງງານ, ດໍາເນີນການຄໍາສັ່ງດຽວກັນກັບ the .map ໄຟລ໌ສືບຕໍ່ຢູ່ໃນຂະແຫນງທີ່ແນ່ນອນບ່ອນທີ່ມັນຢຸດ.
5. ** ຜ່ານ 2: ເປົ້າໝາຍ Reverse/Trimming Scrape (-d -r1) ເພື່ອ​ຟື້ນ​ຕົວ​ຂະ​ແຫນງ​ການ​ທີ່​ບໍ່​ມີ​ຂອບ​ເຂດ **​:
6. ເມື່ອ Pass 1 ສໍາເລັດ (pct rescued: 99.99%), ຫຼຸດເວລາອອກຄໍາສັ່ງ SCSI kernel ເພື່ອໃຫ້ແຕ່ລະພາກສ່ວນທີ່ບໍ່ດີລົ້ມເຫລວຢ່າງໄວວາ (5 seconds ແທນທີ່ຈະລໍຖ້າ 30 to 180 seconds ຕໍ່​ຂະ​ແຫນງ​ການ):

   echo 5 > /sys/block/sdc/device/timeout
   

7. ແລ່ນ Pass 2 ດ້ວຍການເຂົ້າເຖິງແຜ່ນໂດຍກົງ (-d) ແລະ 1 ລອງອີກຄັ້ງ (-r 1):

   ddrescue -f -d -r 1 -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
   

8. ** ປິດ​ລົງ​, ຕັດ​ການ​ເຊື່ອມ​ຕໍ່​ຕົ້ນ​ສະ​ບັບ​ທີ່​ລົ້ມ​ເຫຼວ​ /dev/sdc ຂັບ​ລົດ​, ແລະ​ຕັ້ງ​ມັນ​ຢ່າງ​ປອດ​ໄພ​ໃນ shelf **​: ຈາກ​ຈຸດ​ນີ້​ຕໍ່​ໄປ​, ທ່ານ​ຈະ​ເຮັດ​ວຽກ​ສະ​ເພາະ​ແຕ່​ກັບ clone ທີ່​ມີ​ສຸ​ຂະ​ພາບ​ຂອງ​ທ່ານ (/dev/sdf) ແລະສະມາຊິກທີ່ມີສຸຂະພາບດີຂອງທ່ານຂັບລົດ.

ໄລຍະທີ 3: Safe Read-Only RAID assembly ໂດຍໃຊ້ Copy-on-Write (COW) overlays ແລະ mdadm¶

ໃນ​ປັດ​ຈຸ​ບັນ​ທີ່​ທ່ານ​ມີ clones disk ມີ​ສຸ​ຂະ​ພາບ​, ** ບໍ່​ເຄີຍ​ແລ່ນ​ mdadm --assemble --force ໂດຍກົງໃນ drives ດິບໂດຍບໍ່ມີການປ້ອງກັນ Copy-on-Write (COW) overlay ຫຼື --readonly ທຸງ **. ເປັນຫຍັງ? ເນື່ອງຈາກວ່າ --force rewrites the RAID superblocks on the drives , ແລະຖ້າຫາກວ່າວາລະສານລະບົບໄຟລ໌ (ext4 / XFS) replays ອັດຕະໂນມັດກ່ຽວກັບການ mount ໂດຍໃຊ້ການປະສົມປະສານຂອງ drive ທີ່ບໍ່ຖືກຕ້ອງ, ມັນປ່ຽນແປງການ clones ຂອງທ່ານຢ່າງຖາວອນ.

ຂັ້ນ​ຕອນ​ທີ 1​: ການ​ກວດ​ສອບ metadata RAID ໃນ​ທົ່ວ​ທັງ​ຫມົດ drives ສະ​ມາ​ຊິກ (mdadm --examine)¶

ແລ່ນ mdadm --examine ໃນທຸກໆ drive ສະມາຊິກ (ຫຼືການແບ່ງສ່ວນ, ເຊັ່ນ, /dev/sda1 ຫຼື /dev/sda3 ຢູ່ໃນໄດຣຟ໌ Synology/QNAP NAS) ແລະບັນທຶກຜົນອອກມາເປັນໄຟລ໌ຂໍ້ຄວາມ:

mdadm --examine /dev/sd[a,b,d,f]* > /root/raid_metadata_audit.txt
cat /root/raid_metadata_audit.txt

ຂັ້ນຕອນທີ 2: ສ້າງ Copy-on-Write ທີ່ບໍ່ທໍາລາຍ (COW) Device-Mapper overlays (overlay-create)¶

ເພື່ອ​ຮັບ​ປະ​ກັນ​ຄວາມ​ປອດ​ໄພ 100 ສ່ວນ​ຮ້ອຍ​ດັ່ງ​ນັ້ນ​ເຖິງ​ແມ່ນ​ວ່າ​ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ບັງ​ຄັບ​ປະ​ກອບ​ອາ​ເຣ​ແລະ​ແລ່ນ​ mount, zero bytes ເຄີຍຂຽນໃສ່ຮາດໄດທາງກາຍຍະພາບຂອງເຈົ້າ, ສ້າງແບບ loop-backed dm-snapshot Copy-on-Write overlays in /tmp (ຫຼືຢູ່ໃນ drive scratch ພາຍນອກ):

# Create a small sparse COW file + loop device for each member partition (e.g., sda3, sdf3, sdd3)
mkdir -p /root/cow
for dev in sda3 sdf3 sdd3; do
    truncate -s 20G /root/cow/${dev}.cow
    loop_base=$(losetup --find --show --read-only /dev/${dev})
    loop_cow=$(losetup --find --show /root/cow/${dev}.cow)
    sz=$(blockdev --getsz /dev/${dev})
    echo "0 $sz snapshot $loop_base $loop_cow P 8" | dmsetup create ovl_${dev}
done

ຂັ້ນ​ຕອນ​ທີ 3​: ບັງ​ຄັບ​ປະ​ກອບ​ອາ​ເຣ​ກ່ຽວ​ກັບ​ອຸ​ປະ​ກອນ​ການ​ວາງ​ຊ້ອນ​ແລະ​ຕິດ​ຕັ້ງ Read-Only​¶

1. ** ປະ​ກອບ​ຄວາມ​ສົດ​ທີ່​ສຸດ​ N - 1 overlay ອຸ​ປະ​ກອນ​ການ​ນໍາ​ໃຊ້​ --assemble --force**:

   mdadm --assemble --force --verbose /dev/md99 /dev/mapper/ovl_sda3 /dev/mapper/ovl_sdf3 /dev/mapper/ovl_sdd3
   

2. ເປັນ​ຫຍັງ​ພວກ​ເຮົາ​ອອກ​ຈາກ​ການ​ຂັບ​ແຂງ / ເຄິ່ງ​ສ້າງ​ໃຫມ່ (sdb3): ບັງຄັບ mdadm ເພື່ອປະກອບກັບ 3 ໄດທີ່ທັນສະໄຫມ (sda3, cloned sdf3, ແລະ sdd3) ເອົາ /dev/md99 ອອນ​ໄລ​ນ​໌​ໃນ​ຮູບ​ແບບ​ຊຸດ​ໂຊມ​ທີ່​ສະ​ອາດ ([U_UU]) ການ​ນໍາ​ໃຊ້​ຫລ້າ​ສຸດ​ທີ່​ແນ່​ນອນ​ Events ລັດ, ໃນຂະນະທີ່ ddrescue ກູ້ຂໍ້ມູນຈາກ sdf3.
3. ** ເປີດໃຊ້ LVM (vgchange) ຖ້າ NAS ຫຼືເຄື່ອງແມ່ຂ່າຍຂອງທ່ານໃຊ້ LVM ຢູ່ເທິງສຸດຂອງ RAID (Synology SHR, QNAP, Proxmox, Ubuntu)**:

   pvscan
   vgscan
   vgchange -ay
   lvs
   

   (ຖ້າ Synology NAS ຂອງທ່ານໃຊ້ Btrfs ໃນ LVM ຫຼື Synology Hybrid RAID, ໃນປັດຈຸບັນທ່ານຈະເຫັນ /dev/vg1000/lv ຫຼື /dev/vg1/volume_1 ປາກົດ.)
4. **ຕິດ​ຕັ້ງ​ລະ​ບົບ​ໄຟລ​໌​ໃນ​ຮູບ​ແບບ​ການ​ອ່ານ​ເທົ່າ​ນັ້ນ​ທີ່​ເຄັ່ງ​ຄັດ​ແລະ​ຍົກ​ຍ້າຍ​ໄຟລ​໌​ທີ່​ສໍາ​ຄັນ​ຂອງ​ທ່ານ​ທັນ​ທີ **​:

   mkdir -p /mnt/raid_rescue
   # For ext4:
   mount -o ro,noload /dev/md99 /mnt/raid_rescue
   # (Or if noload refuses due to dirty journal, mount the COW overlay normally so the journal replays into the disposable COW file)
   mount -o ro /dev/md99 /mnt/raid_rescue
   # For Btrfs (Synology NAS):
   mount -t btrfs -o ro,usebackuproot,nologreplay /dev/vg1000/lv /mnt/raid_rescue
   

5. ** ສຳເນົາໂຟນເດີທີ່ສຳຄັນທີ່ສຸດຂອງເຈົ້າກ່ອນໂດຍໃຊ້ rsync ໄປຍັງໄດຣຟ໌ສຳຮອງພາຍນອກ **:

   rsync -avP --ignore-errors /mnt/raid_rescue/ /mnt/external_backup_usb/
   

ໄລຍະທີ 4: Rescuing Hardware RAID Controllers (Dell PERC, LSI MegaRAID, HP Smart Array, Adaptec) ແລະ ZFS / Btrfs Pools¶

ຈະເປັນແນວໃດຖ້າ array ຂອງທ່ານຖືກຈັດການໂດຍ Linux mdadm, ແຕ່ໂດຍ ** Hardware RAID Controller Card ** (Dell PERC H730/H740/H755, Broadcom / LSI MegaRAID, ຫຼື HP Smart Array) ທີ່​ລາຍ​ງານ​ໃນ​ປັດ​ຈຸ​ບັນ Virtual Disk Offline ຫຼື Foreign Configuration Found ຫຼັງ​ຈາກ​ການ​ຂັບ​ຄັ້ງ​ທີ​ສອງ hiccupped ໃນ​ລະ​ຫວ່າງ​ການ​ສ້າງ​ໃຫມ່​?

1. ບັດ RAID ຮາດແວ (Dell PERC, LSI MegaRAID, HP Smart Array)¶

1. ** ບໍ່​ເຄີຍ​ຄລິກ​ໃສ່​ "Clear Foreign Configuration" ຫຼື "Initialize Virtual Disk"**:
2. ໃນ Dell PERC / LSI MegaRAID BIOS (Ctrl+R ຫຼື HII UEFI Configuration Utility), Clear ເຊັດ metadata RAID ຈາກໄດ, ແລະ Initialize ຂຽນທັບເສັ້ນດ່າງຂໍ້ມູນ.
3. ຖ້າໄດຣຟ໌ທີ່ມີສຸຂະພາບດີຫຼຸດລົງແບບອອບໄລນ໌ເນື່ອງຈາກສາຍສາກຫຼັງວ່າງ ຫຼືໝົດເວລາ, Import Foreign Configuration ຄວາມ​ພະ​ຍາ​ຍາມ​ທີ່​ຈະ​ນໍາ​ເອົາ​ການ​ຂັບ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​; ** ຢ່າງ​ໃດ​ກໍ​ຕາມ​, ຖ້າ​ຫາກ​ວ່າ​ຫນຶ່ງ​ໄດ້​ຫຼຸດ​ລົງ​ອາ​ທິດ​ຜ່ານ​ມາ​ແລະ​ຄັ້ງ​ທີ​ສອງ​ຫຼຸດ​ລົງ​ໃນ​ມື້​ນີ້​, ການ​ນໍາ​ເຂົ້າ​ທັງ​ສອງ​ຫຼື​ການ​ບັງ​ຄັບ​ໃຫ້​ການ​ຂັບ stale ອອນ​ໄລ​ນ​໌​ໂດຍ​ຜ່ານ​ການ​ຄວບ​ຄຸມ BIOS ສາ​ມາດ​ເຮັດ​ໃຫ້​ອາ​ເຣ ** ເສຍ​ຫາຍ​.
4. ** ວິ​ທີ​ການ​ຟື້ນ​ຟູ​ຊອບ​ແວ​ທີ່​ປອດ​ໄພ​ສໍາ​ລັບ​ການ RAID ຮາດ​ແວ (DDF ເມຕາເດຕາ / dmraid / R-Studio / UFS Explorer)**:
5. ຮາດແວ RAID ບັດເກັບຮັກສາມາດຕະຖານ SNIA DDF (Disk Data Format) metadata ໃນຂະແຫນງການສຸດທ້າຍໃນຕອນທ້າຍຂອງແຕ່ລະຮາດໄດ, ແລະຂໍ້ມູນເສັ້ນດ່າງໃນທົ່ວໄດທີ່ເລີ່ມຕົ້ນຈາກຂະແຫນງການ. 0 (ຫຼືຫຼັງຈາກການຊົດເຊີຍ header ຂະຫນາດນ້ອຍ) ໂດຍໃຊ້ມາດຕະຖານ 64 KB, 128 KB, 256 KB, ຫຼື 512 KB ຂະ​ຫນາດ​ຕ່ອນ (Left-Asymmetric ຫຼື Left-Symmetric).
6. ແທນທີ່ຈະຫຼີ້ນການພະນັນດ້ວຍຮາດແວ RAID card BIOS ທີ່ທໍາລາຍ:
   1. ຕິດປ້າຍກຳກັບໄດທັງໝົດຕາມເລກສະລັອດຕິງ ແລະເຊື່ອມຕໍ່ພວກມັນກັບ ** SATA ມາດຕະຖານ / ບໍ່ແມ່ນ RAID IT-Mode HBA** ໃນ​ສະ​ຖາ​ນີ​ການ​ຟື້ນ​ຕົວ​.
   2. Clone the bad-sector drive ໂດຍໃຊ້ GNU ddrescue ດັ່ງທີ່ສະແດງຢູ່ໃນໄລຍະ 2.
   3. ເປີດ drives cloned ໃນ UFS Explorer RAID Recovery ຫຼື R-Studio Technician, ຫຼືປະກອບພວກມັນແບບອ່ານຢ່າງດຽວໃນ Linux ໂດຍໃຊ້ dmsetup / mdadm --build: ເຄື່ອງມືເຫຼົ່ານີ້ຈະກວດພົບອັດຕະໂນມັດ LSI / PERC / HP ລຳດັບເສັ້ນດ່າງ, ຂະໜາດຕ່ອນ (64K/512K), ແລະ parity rotation ໃນ 100 ສ່ວນ​ຮ້ອຍ​ຄວາມ​ຊົງ​ຈໍາ​ອ່ານ​ເທົ່າ​ນັ້ນ​ໂດຍ​ບໍ່​ເຄີຍ​ໃຫ້​ຮາດ​ແວ RAID card ຂຽນ​ດຽວ byte ກັບ​ການ​ຂັບ​ລົດ​ຂອງ​ທ່ານ​.

2. TrueNAS / ZFS (RAID-Z1 / RAID-Z2) ແລະ Synology Btrfs ຂັດຂັດ/Resilver ລົ້ມເຫລວ¶

ຖ້າສະນຸກເກີຂອງເຈົ້າໃຊ້ ** OpenZFS (RAID-Z1 ຫຼື RAID-Z2)** ໃນ TrueNAS ຫຼື Proxmox ແລະຂັບທີສອງຖິ້ມ CKSUM / READ ຄວາມ​ຜິດ​ພາດ​ໃນ​ລະ​ຫວ່າງ a zpool replace ເງິນຄືນ: 1. ** ເປັນ​ຫຍັງ ZFS ຈັດການ​ຂະ​ແຫນງ​ການ​ທີ່​ບໍ່​ດີ​ໃນ​ລະ​ຫວ່າງ​ການ resilvering ດີກ​່​ວາ RAID ຮາດ​ແວ​, ແລະ​ໃນ​ເວ​ລາ​ທີ່​ມັນ​ຍັງ​ຕິດ​ຕັ້ງ ​: - ບໍ່ເຫມືອນກັບບັດ RAID ຮາດແວທີ່ໄຮ້ດຽງສາທີ່ລຸດລົງແຜ່ນທັງຫມົດຢູ່ໃນຂະແຫນງທີ່ບໍ່ດີດຽວ, ZFS ຍັງສືບຕໍ່ແກ້ໄຂອະດີດທ້ອງຖິ່ນ. READ ຂໍ້ຜິດພາດແລະບັນທຶກພຽງແຕ່ເສັ້ນທາງໄຟລ໌ທີ່ເສຍຫາຍສະເພາະໃນ zpool status -v. - ຢ່າງໃດກໍຕາມ, ຖ້າການຂັບທີ່ລົ້ມເຫລວທີສອງຈະວາງສາຍ SATA / SAS bus (I/O timeout / thrashing ຫົວ​) ຫຼື​ຫຼຸດ​ລົງ​ຫມົດ offline (UNAVAIL / FAULTED), ສະນຸກເກີເຂົ້າໄປໃນ SUSPENDED ລັດ (pool I/O is currently suspended). 2. ວິ​ທີ​ການ​ຊ່ວຍ​ເຫຼືອ A SUSPENDED ຫຼື FAULTED ZFS RAID-Z1 / klzzwx0201 ສະ​ນຸກ​ເ **​: - ພະລັງງານລົງຢ່າງສະອາດ, ໂຄນໄດເວີທີ່ລົ້ມເຫລວໃສ່ແຜ່ນການທົດແທນທີ່ມີສຸຂະພາບດີໂດຍໃຊ້ GNU ddrescue -f -n (ປ້າຍພາທິຊັນ ZFS ປະກອບມີທີ່ແນ່ນອນ vdev GUID ໃນຕອນເລີ່ມຕົ້ນແລະສິ້ນສຸດຂອງແຜ່ນ, ດັ່ງນັ້ນການໂຄນຂອງຂະແຫນງວັດຖຸດິບຖືກຮັບຮູ້ໂດຍອັດຕະໂນມັດໂດຍ ZFS ເປັນຕົ້ນສະບັບ vdev ສະມາຊິກ). - ຕັດການເຊື່ອມຕໍ່ໄດທີ່ເສຍຊີວິດທາງດ້ານຮ່າງກາຍ, ອອກຈາກ lzzwxh:0205 clone ເຊື່ອມຕໍ່, ແລະນໍາເຂົ້າສະນຸກເກີ ZFS ໃນ ** ໂຫມດອ່ານເທົ່ານັ້ນທີ່ເຄັ່ງຄັດ (readonly=on) ໂດຍ​ບໍ່​ມີ​ການ​ເລີ່ມ​ຕົ້ນ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​ການ​ຂຽນ​ຫຼື​ສືບ​ຕໍ່ resilver​:

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

ຄຳຖາມທີ່ມັກຖາມເລື້ອຍໆ¶

ເປັນຫຍັງເຈົ້າຈຶ່ງເວົ້າວ່າ ບໍ່ເຄີຍແລ່ນ CHKDSK ຫຼື fsck ເມື່ອ RAID array ຂອງຂ້ອຍຕິດຢູ່ກັບຂໍ້ຜິດພາດຂອງລະບົບໄຟລ໌ຫຼັງຈາກ drive ຫຼຸດລົງ?¶

ໃນຮາດດິດດຽວ, ແລ່ນ CHKDSK ຫຼື fsck ແກ້ໄຂຄວາມບໍ່ສອດຄ່ອງຂອງໄດເລກະທໍລີເລັກນ້ອຍ. ສຸດ ກ multi-drive RAID 5 ຫຼື RAID 6 array ທີ່ປະສົບກັບການຫຼຸດລົງຂອງ double-drive ຫຼືການຂັດຂວາງການສ້າງໃຫມ່, ຄວາມຜິດພາດຂອງລະບົບໄຟລ໌ແມ່ນເກືອບສະເຫມີເກີດມາຈາກ RAID stripe misalignment ຫຼືການຂັບລົດສະມາຊິກ stale ຖືກບັງຄັບອອນໄລນ໌ (ຫມາຍຄວາມວ່າທຸກໆ ທີ 3 ຫຼື ທີ 4 64 KB chunk ຂອງ​ຂໍ້​ມູນ​ແມ່ນ​ໄດ້​ຖືກ​ອ່ານ​ຈາກ​ການ​ຜະ​ລິດ​ການ​ຂັບ​ຜິດ​)​. ຖ້າທ່ານປ່ອຍໃຫ້ CHKDSK /f ຫຼື fsck -y ແລ່ນຢູ່ໃນອາເຣ RAID ທີ່ບໍ່ສອດຄ່ອງ ຫຼືບໍ່ສອດຄ່ອງກັນ, ມັນຕີຄວາມຫມາຍຜິດລ້ານໄຟລ໌ທີ່ຖືກຕ້ອງເປັນ metadata ທີ່ເສຍຫາຍ, ຕັດຕົ້ນໄມ້ໄດເລກະທໍລີ, ຖິ້ມຊິ້ນສ່ວນທີ່ບໍ່ມີຊື່ເຂົ້າໄປໃນ ຫາຍ+ພົບ, ແລະຂຽນ parity blocks ໃຫມ່ໃນທົ່ວ drives ທັງຫມົດ, ເຮັດໃຫ້ມັນເປັນໄປບໍ່ໄດ້ທາງຄະນິດສາດທີ່ເຄີຍປະກອບປະສົມປະສານຂອງ drive ທີ່ຖືກຕ້ອງຫຼັງຈາກນັ້ນ. ສະເຫມີ mount ຜ່ານ ອ່ານເທົ່ານັ້ນ Copy-on-Write (ງົວ) ການຊ້ອນກັນ ທໍາອິດ.

ຈະ​ເປັນ​ແນວ​ໃດ​ຖ້າ​ຫາກ​ວ່າ drive ການ​ທົດ​ແທນ​ບາງ​ສ່ວນ​ທີ່​ສ້າງ​ໃຫມ່ (42% ສໍາເລັດ) ແລະໄດທີສອງທີ່ລົ້ມເຫລວ 42% ທັງສອງມີຂໍ້ມູນທີ່ຈໍາເປັນ? ຂ້ອຍສາມາດສົມທົບພວກມັນໄດ້ບໍ?¶

ແມ່ນແລ້ວ. ນີ້ແມ່ນການກູ້ໄພ RAID ແບບຄລາສສິກ "Split-Horizon / Hybrid Clone". ສົມມຸດວ່າ ຂັບ 2 ໄດ້ເສຍຊີວິດຢ່າງສົມບູນໃນວັນຈັນ, ທ່ານໃສ່ໃນ New Drive 2, ແລະ​ການ​ກໍ່​ສ້າງ​ໃຫມ່​ໄດ້​ເຮັດ​ໃຫ້​ມັນ​ 42% (LBA 3,500,000,000) ກ່ອນ ຂັບ 3 ໄດ້​ຮັບ​ເຄາະ​ຮ້າຍ​ຫົວ​ເສຍ​ຊີ​ວິດ​ຢູ່ LBA 3,500,000,000. ສັງເກດເຫັນສິ່ງທີ່ເຈົ້າມີຕົວຈິງ: ສໍາລັບ 42% ທຳອິດຂອງອາເຣ (0% ກັບ 42%), New Drive 2 ​ໄດ້​ຮັບ​ການ​ກໍ່ສ້າງ​ຄືນ​ໃໝ່ 100 ​ເປີ​ເຊັນ​ແລ້ວ. ດັ່ງນັ້ນສໍາລັບຄັ້ງທໍາອິດ 42% ຂອງລະດັບ LBA, ທ່ານມີຊຸດເສັ້ນດ່າງທີ່ສົມບູນໂດຍໃຊ້ ຂັບ 1 + ໄດໃຫມ່ 2 + ໄດ 4 (ການປິ່ນປົວຂັດຂ້ອງ ຂັບ 3 ເປັນແຜ່ນທີ່ຂາດຫາຍໄປ). ແລະຖ້າ ຂັບ 3 ພຽງແຕ່ມີ patch ຂະແຫນງການທີ່ບໍ່ດີຢູ່ໃນທ້ອງຖິ່ນ 42% (ແລະສາມາດອ່ານໄດ້ຈາກ 43% ກັບ 100% via ddrescue), ທ່ານໃຊ້ Drive 1 + Cloned Drive 3 + Drive 4 ສໍາລັບສ່ວນທີ່ເຫຼືອ 58% ຂອງອາເຣ.

ເປັນຫຍັງໄດທີສອງລົ້ມເຫລວເລື້ອຍໆໃນກາງ RAID 5 ກໍ່ສ້າງໃຫມ່?¶

ຄວາມເປັນຈິງທາງດ້ານວິສະວະກໍາສອງອັນປະສົມປະສານກັນເພື່ອເຮັດໃຫ້ RAID 5 ສ້າງ​ຄືນ​ໃຫມ່​ທີ່​ມີ​ຊື່​ສຽງ​ສໍາ​ລັບ​ຄວາມ​ລົ້ມ​ເຫຼວ double-drive​: (1​) ອາຍຸຊຸດທີ່ຄືກັນ: ຜູ້​ໃຊ້​ສ່ວນ​ໃຫຍ່​ຊື້ 4 ຫາ 8 ຮາດ​ດິດ​ທີ່​ດຽວ​ກັນ​ຈາກ​ຮ້ານ​ຂາຍ​ຍ່ອຍ​ດຽວ​ກັນ​ໃນ​ມື້​ດຽວ​ກັນ (ເຟີມແວດຽວກັນ, ຫຼາຍໂຮງງານດຽວກັນ, batch motor spindle ດຽວກັນ) ແລະດໍາເນີນການໃຫ້ເຂົາເຈົ້າຂ້າງຄຽງຢູ່ໃນອຸນຫະພູມດຽວກັນຄືກັນອ້ອຍຕ້ອຍສໍາລັບ 35,000 ຊົ່ວໂມງ; ເມື່ອ Drive 1 ສິ້ນເປືອງ, Drive 2 ແລະ Drive 3 ແມ່ນມື້ທີ່ຫ່າງຈາກຂອບເຂດການສວມໃສ່ກົນຈັກດຽວກັນ. (2) Latent Uncorrectable ຄວາມຜິດພາດການອ່ານ (UREs): ພາຍໃຕ້ການດໍາເນີນງານປະຈໍາວັນປົກກະຕິ, 95% ຂະແຫນງການເກັບຂໍ້ມູນເຢັນຂອງຮາດໄດບໍ່ຖືກອ່ານເປັນເວລາຫລາຍເດືອນ, ດັ່ງນັ້ນຂະແຫນງທີ່ບໍ່ດີທີ່ລ້າໆຍັງບໍ່ໄດ້ຮັບການຄົ້ນພົບ. ກ RAID 5 ກໍ່ສ້າງ​ກຳລັງ​ຢ່າງ​ຕໍ່​ເນື່ອງ 100% ການອ່ານພື້ນຜິວຂອງແຕ່ລະຂະແຫນງການດຽວໃນທົ່ວທຸກໄດທີ່ມີຊີວິດລອດ (40 ຫາ 100 terabytes ຂອງການອ່ານຢ່າງຕໍ່ເນື່ອງ), ເປີດເຜີຍທັນທີທັນໃດພາກສ່ວນທີ່ບໍ່ດີ latent ທີ່ສະສົມໃນປີທີ່ຜ່ານມາ.

ຂ້ອຍຈະຮູ້ໄດ້ແນວໃດວ່າໄຟລ໌ໃດໄດ້ຮັບຜົນກະທົບຈາກພາກສ່ວນທີ່ບໍ່ດີທີ່ບໍ່ສາມາດອ່ານໄດ້ບໍ່ຫຼາຍປານໃດ ddrescue ຕ້ອງສູນຕື່ມບໍ?¶

GNU ddrrescue ປະ​ກອບ​ມີ​ອຸ​ປະ​ກອນ forensic ການ​ກໍ່​ສ້າງ​ໃນ​ທີ່​ເອີ້ນ​ວ່າ​ ddrescuelog ແລະ ddru_ntfsfindbad / debugfs ທີ່ວາງແຜນຂອບເຂດ LBA ຂອງຂະແຫນງການທີ່ບໍ່ໄດ້ຟື້ນຟູທີ່ແນ່ນອນຈາກຂອງທ່ານ .ແຜນທີ່ file (ສະຖານະ = '-' ພາກສ່ວນທີ່ບໍ່ດີ) ໂດຍຜ່ານຄະນິດສາດເສັ້ນດ່າງ RAID ໂດຍກົງກັບຕາຕະລາງ inode ຂອງລະບົບໄຟລ໌. ເມື່ອເຈົ້າຮູ້ວ່າອັນໃດ 4 KB ຕັນແມ່ນສູນເຕັມໃນລະຫວ່າງການໂຄນ, ທ່ານສາມາດສອບຖາມໄດ້ debugfs (ໄອເຊັກ ແລະ ກວດເຊັກ ສຸດ ext4) ຫຼື btrfs inspect-internal logical-resolve ເພື່ອພິມອອກບັນຊີລາຍຊື່ທີ່ແນ່ນອນຂອງ 2 ຫຼື 3 ຊື່ໄຟລ໌ທີ່ທັບຊ້ອນພາກສ່ວນທີ່ບໍ່ດີເຫຼົ່ານັ້ນ, ຢືນຢັນດ້ວຍຄວາມແນ່ນອນທາງຄະນິດສາດ 100 ເປີເຊັນວ່າທຸກໆໄຟລ໌ອື່ນໆໃນເຄື່ອງແມ່ຂ່າຍຫຼາຍ terabyte ຂອງທ່ານບໍ່ເສຍຫາຍຢ່າງສົມບູນ.

ຄູ່ມືທີ່ກ່ຽວຂ້ອງ¶

• RAID 5 ຫຼື RAID 6 Synology, QNAP, ຫຼື TrueNAS ຫຼາຍ drive ຫຼຸດລົງແລະເປັນຫຍັງການບັງຄັບໃຫ້ສ້າງໃຫມ່ທໍາລາຍຂໍ້ມູນ
• ການເສຍຊີວິດບັດຄວບຄຸມ RAID, ການນໍາເຂົ້າການຕັ້ງຄ່າຈາກຕ່າງປະເທດ, ແລະເປັນຫຍັງທ່ານບໍ່ຄວນເລີ່ມຕົ້ນແຜ່ນດິດ
• NAS RAID array ຖືກຊຸດໂຊມ, ຄວາມລົ້ມເຫຼວຂອງ drive ຫຼາຍ, ແລະການຟື້ນຕົວ ZFS/Btrfs
• ຄວາມລົ້ມເຫຼວຂອງຮາດດິດແລະການຟື້ນຕົວຂໍ້ມູນ
• Computer backups: 3-2-1 strategy and disaster recovery
• ຕົວເລກສຸກເສີນຕາມປະເທດ

ແຫຼ່ງຂໍ້ມູນແລະຄໍາແນະນໍາຢ່າງເປັນທາງການ¶

• Linux Raid Wiki (raid.wiki.kernel.org/index.php/Linux_Raid & Recovering_a_failed_software_RAID): * Kernel ຢ່າງເປັນທາງການ mdadm Recovery Protocol, Device-Mapper Copy-on-Write (dm-snapshot) ການວາງຊ້ອນກັນ, ແລະ Events ການ​ໂຕ້​ຕອບ *.
• GNU ddrescue ຄູ່ມືວິສະວະກຳທີ່ເປັນທາງການ (gnu.org/software/ddrescue/manual/ddrescue_manual.html): ການບໍ່ຂູດຫຼາຍໄລຍະ (-n) ແລະ​ການ​ເຂົ້າ​ເຖິງ​ໂດຍ​ກົງ (-d) ຂັ້ນຕອນການຟື້ນຕົວຂອງຂະແໜງການສຳລັບສື່ແມ່ເຫຼັກທີ່ລົ້ມເຫລວ.
• ພື້ນຖານຄວາມຮູ້ທາງການ Synology (kb.synology.com/en-global/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC): * ການຕິດຕັ້ງ mdadm + LVM2 + Btrfs / ext4 NAS Volumes Read-Only on Ubuntu Rescue Systems*.
• ສະມາຄົມອຸດສາຫະກໍາເຄືອຂ່າຍການເກັບຮັກສາ (SNIA): ຮູບແບບຂໍ້ມູນແຜ່ນ RAID ທົ່ວໄປ (DDF) ຂໍ້ມູນຈໍາເພາະສໍາລັບ Hardware RAID Controller Metadata Portability.