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 neu RAID 6 storage server, 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 i 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 i 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, a 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 yn yr Unol Daleithiau a Chanada, 112 ar draws yr Undeb Ewropeaidd, 999 yn y Deyrnas Unedig) neu edrychwch ar ein cyfeiriadur o rhifau brys.

Gwnewch hyn nawr¶

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, neu xfs_repair on a degraded, out-of-sync, or half-rebuilt RAID array:
4. Pam CHKDSK a 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) ar y ddau yriant hynny yn wahanol gan filoedd o drafodion. Os ydych chi'n gorfodi - cydosod arae gyda chenedlaethau gyriant anghymharol neu streipiau coll a chaniatáu fsck neu 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, and overwrites good data stripes with corrupted parity across every disk in the array.
5. NEVER click "Create Array", "Initialize", neu "Clear Configuration" in a hardware RAID BIOS, and NEVER run mdadm --create without --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 vs. 64K chunk, left-symmetric vs. left-asymmetric, neu 2048s vs. 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 neu 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 a 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 neu 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\)$ Os 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\)$ - Beth sy'n digwydd pan Drive B yn taro sengl annarllenadwy 4 KB sector (UNC gwall) yn 42% o'r ailadeiladu: - I gyfrifo'r sengl honno 4 KB rhwystro ymlaen C_new, rhaid i'r rheolydd * gael darlleniad dilys ohono Drive A, Drive B, a Drive D. - When Drive B yn dychwelyd caledwedd 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 fel FAILED / OFFLINE and aborts the entire rebuild. - At that moment, your array has two drives marked "Failed" (Drive C which was only 42% rebuilt, and Drive B which actually has 99.99998% healthy sectors and only 12 sectorau gwael).

2. Paham Event Counters (Update Time) penderfynu pa yriannau y mae'n rhaid i chi eu defnyddio ar gyfer adferiad¶

Bob tro a RAID 5 neu RAID 6 array yn ysgrifennu data neu'n newid cyflwr (fel gyriant yn gollwng), y metadata RAID (mdadm superblock neu galedwedd DDF metadata) cynyddrannau 64-bit Events cownter ar bob gyriant sy'n weithredol ar hyn o bryd.

Cymharer y mdadm --examine allbwn gyriant 4-gyriant nodweddiadol RAID 5 trychineb ble sdb methu ddoe (Events: 10450) a sdc gadael yn ystod ailadeiladu heddiw (Events: 10892):

• Rheol Aur Adfer RAID o'r tabl uchod:
• Sylwch ar hynny /dev/sda (10892), /dev/sdc (10890), a /dev/sdd (10892) bron yn union yr un fath Events cownteri o Today 14:22.
• Unwaith y byddwn yn clonio /dev/sdc ar yriant iach gan ddefnyddio ddrescue (gan adennill 99.9999% o'i sectorau a llenwi sero yr 8 sector annarllenadwy), gallwn orfodi cydosod /dev/sda + Cloned /dev/sdc + /dev/sdd (gan anwybyddu'r hanner-ailadeiladu /dev/sdb yn llwyr). Mae'r cyfuniad 3-gyriant hwnnw'n rhoi ** 100 y cant cyson, hyd at yr ail ddiraddiedig i ni RAID 5 arae** gyda sero rhwygo streipen.

Cam 2: Y sector cam wrth gam yn clonio'r ymgyrch sy'n methu GNU ddrescue¶

Cyn i chi gyffwrdd mdadm neu unrhyw declyn cydosod RAID, mae'n rhaid ** i chi ** glonio'r gyriant(au) a daflodd wallau darllen ar yriannau amnewid iach o gapasiti beit cyfartal neu fwy.

Cam 1: Paratowch yr amgylchedd achub Linux ac analluogi awto-gydosod¶

1. Cychwyn gweithfan Linux (neu gychwyn eich gweinydd o ffon USB fyw fel SystemRescue system-rescue.org neu Gweinydd Ubuntu Live) gyda'r gyriannau wedi'u cysylltu â phorthladdoedd safonol motherboard SATA neu LSI HBA yn IT Mode (pasio drwodd heb fod yn RAID).
2. ** Rhwystro Linux rhag ceisio cydosod neu osod eich arae RAID toredig ar y cychwyn yn awtomatig**:
3. Wrth gychwyn SystemRescue neu Ubuntu Live, gwiriwch cat /proc/mdstat. Pe bai Linux yn cydosod rhan yn awtomatig md dyfais yn y cefndir, stopiwch ef ar unwaith yn y modd diogel darllen yn unig cyn delweddu:

   mdadm --stop /dev/md*
   

4. ** Nodi pob gyriant yn ôl union fodel, rhif cyfresol, a maint beit** (peidiwch byth â dyfalu /dev/sdX llythyrau, oherwydd bod Linux yn ailbennu llythyrau gyriant ar draws ailgychwyniadau):

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

   Ysgrifennwch pa un /dev/sdX yn cyfateb i'ch Gyriant Ffynhonnell Methu (er enghraifft, /dev/sdc, cyfresol WCC4E12345) a pha /dev/sdY yw eich Gyriant Targed Gwag Newydd Sbon (er enghraifft, /dev/sdf, cyfresol ZGG9988776).

Cam 2: Rhedeg y 2-Stage GNU ddrescue protocol clonio (Defnyddiwch Mapfile bob amser)¶

Peidiwch byth â defnyddio safon dd (dd if=/dev/sdc of=/dev/sdf) ar yriant RAID sy'n methu: safonol dd naill ai'n erthylu ar y sector gwael cyntaf neu'n symud gwrthbwyso allbwn os sync wedi'i gamgyflunio, ac nid oes ganddo unrhyw gof o ba sectorau a lwyddodd. GNU ddrescue (gddrescue pecyn) yn defnyddio ffeil map cyflwr aml-pas deallus:

1. Pas 1: Clôn Di-Sgrapio Cyflym (-n flag) i Achub 99.99% o Sectorau Iach yn Gyntaf:

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

2. -f: Yn caniatáu ysgrifennu'n uniongyrchol i rwystro dyfais /dev/sdf (gwiriwch hynny mewn triphlyg /dev/sdc yw'r ffynhonnell a /dev/sdf yw'r targed gwag).
3. -n (--no-scrape): yn dweud ddrescue i neidio ar unwaith dros unrhyw ranbarth sector araf neu ddrwg heb falu'r pen darllen, gan achub pob gigabeit iach ar gyflymder uchaf (150 to 250 MB/s) cyn i iechyd y gyriant waethygu.
4. /root/raid_bay3_sdc.map: Yn arbed union gynnydd y sector bob 30 eiliad. Hyd yn oed os yw'r gyriant sy'n methu yn cloi i fyny ac yn gofyn am gylchred pŵer, gan ail-redeg yr un gorchymyn yn union â'r .map ffeil yn ailddechrau yn yr union sector lle daeth i ben.
5. Llwyddiant 2: Crafu Gwrthdroi/Tocio wedi'i Dargedu (-d -r1) i Adennill Sectorau Gwael Ymylol:
6. Unwaith y bydd Pas 1 wedi gorffen (pct rescued: 99.99%), gostwng goramser gorchymyn SCSI cnewyllyn fel bod pob sector gwael yn methu'n gyflym (5 seconds yn lle aros 30 to 180 seconds fesul sector):

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

7. Rhedeg Pass 2 gyda mynediad disg uniongyrchol (-d) ac 1 ailgynnig (-r 1):

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

8. ** Caewch i lawr, datgysylltwch y methiant gwreiddiol /dev/sdc gyrrwch, a gosodwch hi'n ddiogel ar silff**: O hyn ymlaen, byddwch yn gweithio'n gyfan gwbl gyda'ch clôn iach (/dev/sdf) a'ch gyrrwyr aelod iach eraill.

Cam 3: Gwasanaeth RAID Darllen yn Unig Diogel gan ddefnyddio Copy-on-Write (COW) troshaenau a mdadm¶

Nawr bod gennych glonau disg iach, ** pheidiwch byth â rhedeg mdadm --assemble --force yn uniongyrchol ar y gyriannau amrwd heb Copi-ar-Write amddiffynnol (COW) troshaen neu --readonly baner**. Pam? Oherwydd --force yn ailysgrifennu'r superblocks RAID ar y gyriannau, ac os yw dyddlyfr system ffeiliau (ext4 / XFS) yn ailchwarae'n awtomatig ar mount gan ddefnyddio'r cyfuniad gyriant anghywir, mae'n newid eich clonau yn barhaol.

Cam 1: Archwiliwch y metadata RAID ar draws yr holl yriannau aelod (mdadm --examine)¶

Rhedeg mdadm --examine ar bob gyriant aelod (neu raniad, e.e., /dev/sda1 neu /dev/sda3 ar yriannau Synology/QNAP NAS) ac arbedwch yr allbwn i ffeil testun:

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

Cam 2: Creu Copi-ar-Write annistrywiol (COW) Troshaenau Dyfais-Mapper (overlay-create)¶

Er mwyn gwarantu diogelwch 100 y cant fel bod hyd yn oed os ydych chi'n gorfodi-cydosod yr arae a rhedeg mount, mae sero bytes byth yn cael eu hysgrifennu i'ch gyriannau caled corfforol, creu dolen gyda chefnogaeth dm-snapshot Troshaenau Copïo-ar-Ysgrifennu i mewn /tmp (neu ar yriant crafu allanol):

# 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

Cam 3: Gorfodi-cydosod yr arae ar y dyfeisiau troshaen a gosod Darllen yn Unig¶

1. Cynullwch y mwyaf ffres N - 1 dyfeisiau troshaen gan ddefnyddio --assemble --force:

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

2. Pam rydym yn gadael y dreif hen/hanner-ailadeiladu allan (sdb3): gorfodi mdadm i ymgynnull gyda'r 3 gyriant diweddaraf (sda3, clonio sdf3, a sdd3) yn dwyn /dev/md99 ar-lein mewn modd diraddiedig glân ([U_UU]) gan ddefnyddio'r union wybodaeth ddiweddaraf Events cyflwr, tra ddrescue eisoes wedi achub y data rhag sdf3.
3. ** Ysgogi LVM (vgchange) os yw'ch NAS neu'ch gweinydd yn defnyddio LVM ar ben RAID (Synology SHR, QNAP, Proxmox, Ubuntu)**:

   pvscan
   vgscan
   vgchange -ay
   lvs
   

   (Os yw eich Synology NAS yn defnyddio Btrfs ar LVM neu Synology Hybrid RAID, fe welwch nawr /dev/vg1000/lv neu /dev/vg1/volume_1 ymddangos.)
4. ** Gosodwch y system ffeiliau yn y modd Darllen-yn-Unig llym a gwagiwch eich ffeiliau hanfodol ar unwaith**:

   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. ** Copïwch eich ffolderi mwyaf hanfodol gan ddefnyddio yn gyntaf rsync i yriant wrth gefn allanol**:

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

Cam 4: Achub Rheolwyr RAID Caledwedd (Dell PERC, LSI MegaRAID, HP Smart Array, Adaptec) a Phyllau ZFS/Btrfs¶

Beth pe bai eich arae yn cael ei reoli nid gan Linux mdadm, ond gyda Cerdyn Rheolydd RAID Caledwedd (Dell PERC H730/H740/H755, Broadcom / LSI MegaRAID, neu HP Smart Array) sydd bellach yn adrodd Virtual Disk Offline neu Foreign Configuration Found ar ôl i ail yrru daro yn ystod y gwaith ailadeiladu?

1. Cardiau RAID Caledwedd (Dell PERC, LSI MegaRAID, HP Smart Array)¶

1. NEVER click "Clear Foreign Configuration" neu "Initialize Virtual Disk":
2. Yn Dell PERC / LSI MegaRAID BIOS (Ctrl+R neu HII Cyfleustodau Ffurfweddu UEFI), Clear yn sychu'r metadata RAID o'r gyriannau, a Initialize yn trosysgrifo'r streipiau data.
3. Os gostyngodd gyriant iach all-lein yn fyr oherwydd cebl awyren rhydd neu seibiant, Import Foreign Configuration yn ceisio dwyn y dreif yn ol i mewn ; fodd bynnag, pe bai un gyriant yn disgyn wythnosau yn ôl ac eiliad yn gostwng heddiw, gall mewnforio'r ddau neu orfodi'r gyriant hen ar-lein trwy'r rheolydd BIOS lygru'r arae.
4. ** Y Dull Ail-greu Meddalwedd Diogel ar gyfer RAID Caledwedd (DDF Metadata / dmraid / R-Studio / UFS Explorer)**:
5. Safon storio cardiau RAID caledwedd SNIA DDF (Disk Data Format) metadata yn y sectorau terfynol ar ddiwedd pob gyriant caled, a data stripe ar draws y gyriannau sy'n dechrau yn y sector 0 (neu ar ôl gwrthbwyso pennyn bach) gan ddefnyddio safonol 64 KB, 128 KB, 256 KB, neu 512 KB meintiau talpiau (Left-Asymmetric neu Left-Symmetric).
6. Yn lle gamblo gyda BIOS cerdyn RAID caledwedd dinistriol:
   1. Labelwch bob gyriant yn ôl rhif slot a'u cysylltu â SATA safonol / di-RAID IT-Mode HBA ar weithfan adfer.
   2. Cloniwch y gyriant sector gwael gan ddefnyddio GNU ddrescue fel y dangosir yng Ngham 2.
   3. Agorwch y gyriannau wedi'u clonio yn UFS Explorer RAID Recovery neu R-Studio Technician, neu eu cydosod yn darllen yn unig yn Linux gan ddefnyddio dmsetup / mdadm --build: offer hyn yn awtomatig canfod y LSI / PERC / HP trefn streipen, maint talp (64K/512K), a chylchdroi cydraddoldeb mewn cof darllen yn unig 100 y cant heb adael i'r cerdyn RAID caledwedd ysgrifennu beit sengl i'ch gyriannau.

2. TrueNAS / ZFS (RAID-Z1 / RAID-Z2) a Synology Btrfs Methiannau prysgwydd/addrydd¶

Os yw'ch pwll yn defnyddio OpenZFS (RAID-Z1 neu RAID-Z2) ar TrueNAS neu Proxmox ac mae ail dreif yn taflu CKSUM / READ gwallau yn ystod a zpool replace resilver: 1. Pam mae ZFS yn trin sectorau gwael wrth ailseilio yn well na RAID caledwedd, a phan fydd yn dal i gloi: - Yn wahanol i gardiau RAID caledwedd naïf sy'n gollwng disg gyfan ar un sector gwael, mae ZFS yn parhau i ail-lenwi gorffennol lleol READ gwallau a logiau dim ond y llwybrau ffeil difrodi penodol yn zpool status -v. - Fodd bynnag, os yw'r ail yriant sy'n methu yn hongian y bws SATA/SAS (I/O timeout / dyrnu pen) neu'n disgyn yn gyfan gwbl all-lein (UNAVAIL / FAULTED), mae'r pwll yn mynd i mewn SUSPENDED cyflwr (pool I/O is currently suspended). 2. Sut i achub a SUSPENDED neu FAULTED ZFS RAID-Z1 / RAID-Z2 pwll: - Pwerwch i lawr yn lân, cloniwch y gyriant sy'n methu ar ddisg newydd iach gan ddefnyddio GNU ddrescue -f -n (Mae labeli rhaniad ZFS yn cynnwys yr union vdev GUID ar ddechrau a diwedd y ddisg, felly mae clon sector crai yn cael ei gydnabod yn awtomatig gan ZFS fel y gwreiddiol vdev aelod). - Datgysylltwch y gyriant sy'n marw yn gorfforol, gadewch y ddrescue clonio wedi'i gysylltu, a mewngludo'r pwll ZFS yn y modd Darllen yn Unig ** llym (readonly=on)** heb ddechrau trafodiad ysgrifennu nac ailddechrau’r ariannwr:

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

Cwestiynau cyffredin¶

Pam wnaethoch chi ddweud BYTH i redeg CHKDSK neu fsck pan fydd fy arae RAID yn mowntio gyda gwallau system ffeiliau ar ôl gollwng gyriant?¶

Ar yriant caled unigol, yn rhedeg CHKDSK neu fsck atgyweirio mân anghysondebau cyfeiriadur. Ar a arae RAID 5 neu RAID 6 aml-yrru a ddioddefodd ostyngiad gyriant dwbl neu ailadeiladu ymyrraeth, mae gwallau system ffeiliau bron bob amser yn cael eu hachosi gan Camlinio streipen RAID neu hen yrru aelod yn cael ei orfodi ar-lein (sy'n golygu pob 3ydd neu 4ydd 64 KB darn o ddata yn cael ei ddarllen o'r genhedlaeth gyriant anghywir). Os byddwch yn gadael CHKDSK /f neu fsck -y rhedeg ar arae RAID sydd wedi'i gamaleinio neu sydd allan o gysoni, mae'n camddehongli miliynau o ffeiliau dilys fel metadata llygredig, yn cwtogi coed cyfeiriadur, yn taflu darnau dienw i mewn coll+cafwyd, ac yn ysgrifennu blociau cydraddoldeb newydd ar draws pob gyriant, gan ei gwneud hi'n amhosibl yn fathemategol i byth ail-osod y cyfuniad gyriant cywir wedyn. Bob amser mount drwy Copi-ar-Ysgrifennu Darllen yn Unig (COW) troshaenau yn gyntaf.

Beth os yw'r gyriant newydd wedi'i ailadeiladu'n rhannol (42% cwblhau) A'r ail yrru a fethodd yn 42% A oes angen data ar y DDAU? A allaf eu cyfuno?¶

Oes. Mae hwn yn glasurol "Split-Horizon / Hybrid Clone" achub RAID. Tybiwch Gyrr 2 wedi marw yn llwyr ddydd Llun, fe wnaethoch chi roi i mewn Gyriant Newydd 2, a gwnaeth yr ailadeiladu i 42% (LBA 3,500,000,000) o'r blaen Gyrru 3 dioddef damwain pen angheuol yn LBA 3,500,000,000. Sylwch beth sydd gennych mewn gwirionedd: ar gyfer y 42% cyntaf o'r arae (0% i 42%), Gyriant Newydd 2 eisoes wedi cael ei hailadeiladu 100 y cant. Felly am y cyntaf 42% o'r ystod LBA, mae gennych set gyflawn o streipiau gan ddefnyddio Gyriant 1 + Gyriant Newydd 2 + Gyriant 4 (trin damwain Gyrru 3 fel y ddisg ar goll). Ac os Gyrru 3 dim ond ardal leol o'r sector gwael oedd ganddo 42% (ac yn ddarllenadwy o 43% i 100% via ddrescue), rydych chi'n defnyddio Gyriant 1 + Gyriant wedi'i Glonio 3 + Gyriant 4 am y gweddill 58% o'r arae.

Pam mae ail yriannau yn methu mor aml yng nghanol ailadeiladu RAID 5?¶

Mae dwy realiti peirianneg yn cyfuno i wneud RAID 5 yn ailadeiladu drwg-enwog am fethiannau gyriant dwbl: (1) Heneiddio Swp Unfath: Mae'r rhan fwyaf o ddefnyddwyr yn prynu 4 i 8 gyriant caled union yr un fath gan yr un adwerthwr ar yr un diwrnod (yr un firmware, yr un lot ffatri, yr un swp modur gwerthyd) a'u rhedeg ochr yn ochr ar yr un tymheredd yn union am 35,000 o oriau; pan fydd Drive 1 yn gwisgo allan, mae Drive 2 a Drive 3 ddyddiau i ffwrdd o'r un trothwy gwisgo mecanyddol. (2) Gwallau Darllen Anghywir Cudd (UREs): O dan weithrediad dyddiol arferol, 95% Nid yw sectorau archifol gyriant caled yn cael eu darllen am fisoedd ar y tro, felly mae sectorau drwg cudd heb eu darganfod. A RAID 5 ailadeiladu grymoedd yn barhaus 100% darlleniad arwyneb pob sector unigol ar draws pob gyriant sydd wedi goroesi (40 i 100 terabytes o ddarllen parhaus), gan ddatgelu ar unwaith unrhyw sector gwael cudd a gronnodd dros y flwyddyn ddiwethaf.

Sut ydw i'n gwybod pa ffeiliau yr effeithiwyd arnynt gan yr ychydig sectorau gwael annarllenadwy hynny ddrescue roedd yn rhaid i sero-lenwi?¶

GNU ddrescue yn cynnwys cyfleustodau fforensig adeiledig o'r enw ddrescuelog a ddru_ntfsfindbad / debugfs sy'n mapio'r union LBA sector heb ei adennill yn amrywio o'ch .map ffeil (statws = '-' sectorau gwael) trwy'r mathemateg stripe RAID yn uniongyrchol i dabl inod y system ffeiliau. Unwaith y byddwch yn gwybod pa 4 KB roedd blociau'n sero yn ystod clonio, gallwch chi ymholi debugfs (ich a ncheck ymlaen est4) neu btrfs arolygu-mewnol rhesymegol-datrys i argraffu'r union restr o 2 neu 3 enw ffeil a oedd yn gorgyffwrdd â'r sectorau drwg hynny, gan gadarnhau gyda sicrwydd mathemategol 100 y cant bod pob ffeil arall ar eich gweinydd aml-terabyte yn gwbl ddi-lygredd.

Canllawiau cysylltiedig¶

• RAID 5 neu RAID 6 Synology, QNAP, neu TrueNAS gollwng gyriant lluosog a pham mae gorfodi ailadeiladu yn dinistrio data
• Marwolaeth cerdyn rheolydd RAID, mewnforio cyfluniad tramor, a pham na ddylech fyth gychwyn disgiau
• Arae RAID NAS wedi diraddio, methiant gyriant lluosog, ac adferiad ZFS / Btrfs
• Methiant gyriant caled ac adfer data
• Copïau wrth gefn o gyfrifiaduron: strategaeth 3-2-1 ac adfer ar ôl trychineb
• Rhifau brys yn ôl gwlad

Ffynonellau a chanllawiau swyddogol¶

• Wiki Cyrch Linux (raid.wiki.kernel.org/index.php/Linux_Raid & Recovering_a_failed_software_RAID): * Cnewyllyn Swyddogol mdadm Protocol Adfer, Copi-ar-Ysgrifennu Dyfais-Mapper (dm-snapshot) troshaenau, a Events Gwrthgymodi*.
• GNU ddrescue Llawlyfr Peirianneg Swyddogol (gnu.org/software/ddrescue/manual/ddrescue_manual.html): Di-Sgrapio Aml-Gam (-n) a Mynediad Uniongyrchol (-d) Algorithmau Adfer Sector ar gyfer Cyfryngau Magnetig Methu.
• Sylfaen Wybodaeth Swyddogol Synology (kb.synology.com/en-global/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC): Mowntio mdadm + LVM2 + Btrfs / ext4 Cyfrolau NAS Darllen yn Unig ar Systemau Achub Ubuntu.
• Cymdeithas y Diwydiant Rhwydweithio Storio (SNIA): * Fformat Data Disg RAID Cyffredin (DDF) Manyleb ar gyfer Cludadwyedd Metadata Rheolydd RAID Caledwedd*.