RAID 5 vai RAID 6 degradēts masīvs ar otrā diska atteici atjaunošanas laikā (kāpēc nepalaidiet CHKDSK vai fsck, ddrescue Sector Cloning un mdadm tikai lasāmo montāžu)¶

Bojāta cietā diska nomaiņa bojātā RAID 5 vai RAID 6 krātuves serveris, Synology DiskStation, QNAP NAS, Linux mdadm masīvs vai Dell PERC / ZS Smart Array / LSI MegaRAID aparatūras kontrolieris, lai skatītos otrā atlikušā dalībnieka diska metienu UNC (Nelabojama lasīšanas kļūda) slikti sektori, Pending Sectors, vai pametiet bezsaistē vietnē 42% paritātes atjaunošana ir viena no visbīstamākajām krātuves ārkārtas situācijām uzņēmumu un mājas laboratoriju skaitļošanā. Vienparitātē RAID 5 masīvs (N - 1 defektu tolerance), aizstājējdiska matemātiskā XOR rekonstrukcija prasa nolasīt katru sektoru (LBA 0 līdz galīgajam LBA) pāri 100 procentiem no atlikušā N - 1 dalībnieks brauc vienlaicīgi. Kad mūsdienu lieljaudas 8 TB uz 24 TB hēlija diskdziņi (iegādāti no vienas un tās pašas ražošanas partijas un pakļauti identiskām termiskām un vibrācijas stundām) tiek pakļauti vairāku terabaitu secīgai atjaunošanai, tiek konstatēts viens latentais datu nesēja defekts (URE).Faulty / Crashed** un atzīmējiet visu krātuves baseinu Offline / Crashed / Superblock Event Count Mismatch.

Nekrītiet panikā un nepiespiediet otro pārbūvi vai nepalaidiet failu sistēmas labošanas utilītas (fsck, e2fsck, xfs_repairvai Windows CHKDSK). Pat otrreiz iebraucot RAID 5 (vai trešā iebraukšana RAID 6) attīstās 50 uz 5,000 sliktos sektorus un tiek izmests no masīva, 99,9999 procenti sektoru šajā "neizdevušos" otrajā diskā joprojām ir 100% salasāmi. Nekavējoties apturot masīvu, klonējiet katru nestabilo dalībnieku disku pa sektoram uz veseliem rezerves diskdziņiem, izmantojot GNU ddrescue un klonēto attēlu apkopošana programmā Read-Only / --assume-clean pārklājuma režīms (mdadm + dmsetup Kopēšanas-rakstīšanas cilpas pārklājumus), varat droši uzstādīt failu sistēmu un kopēt praktiski visus neskartus failus. Lai uzzinātu par NAS ierīču specifiku un aparatūras kontrollera kļūmēm, izlasiet mūsu pavadošās rokasgrāmatas RAID 5 vai RAID 6 Synology, QNAP vai TrueNAS vairāku disku nolaišana, RAID kontrollera kartes nāve un ārvalstu konfigurācijas importēšana, un NAS RAID masīvs ir degradēts un ZFS/Btrfs atkopšana. Ja servera kļūme ietekmē dzīvības drošības sistēmas vai medicīnas infrastruktūru, sazinieties ar vietējo neatliekamās palīdzības numuru (911 ASV un Kanādā, 112 visā Eiropas Savienībā, 999 Apvienotajā Karalistē) vai pārbaudiet mūsu direktoriju neatliekamās palīdzības numuri.

Dariet to tagad¶

1. Nekavējoties pārtrauciet jebkuru aktīvās paritātes atjaunošanu vai tīrīšanu un tīri izslēdziet masīvu (vai atvienojiet SATA/SAS aizmugures paneļa barošanu, ja diskdzinis rada mehāniskus klikšķus vai skrāpējumus):
2. Kāpēc, ļaujot turpināt bremzējošu pārbūvi, tiek iznīcināts masīvs: kad dalībnieka disks sasniedz slikta sektora ielāpu (LBA lasīšanas taimauts) vai tam ir degradējoša lasīšanas/rakstīšanas galviņa (media scratch), atstājot RAID kontrollera atkārtotu mēģinājumu sektorus stundām ilgi, mikroskopiskā magnētiskā šķīvja pārklājums sasmalcina putekļos visā trases cilindrā, pārvēršot atgūstamu 20-sector defekts par katastrofālu pilnas šķīvja galvas avāriju.
3. ** NEKAD neskrien CHKDSK /f, fsck -y, e2fsck, btrfs check --repair, vai xfs_repair degradētā, nesinhronizētā vai daļēji pārbūvētā RAID masīvā**:
4. Kāpēc CHKDSK un fsck izraisīt 100% neatgriezenisku datu iznīcināšanu ārpus sinhronizācijas RAID: ja 2. diska darbība tika pārtraukta otrdien un 3. diska darbība tika pārtraukta ceturtdienas atjaunošanas laikā, mdadm vai aparatūras RAID Event Counter (Update Time) šajos divos diskos atšķiras ar tūkstošiem darījumu. Ja piespiedu kārtā montējat masīvu ar neatbilstošām disku paaudzēm vai trūkstošām svītrām un atļaujat fsck vai CHKDSK lai rakstītu masīvā, failu sistēmas pārbaudītājs redz bojātus inode kokus, ko izraisa nepareizi izlīdzinātas RAID svītras, izdzēš miljoniem derīgu direktoriju ierakstu lost+found, un pārraksta labas datu joslas ar bojātu paritāti katrā masīva diskā.
5. ** NEKAD neklikšķiniet "Create Array", "Initialize", vai "Clear Configuration" aparatūras RAID BIOS un NEKAD nepalaidiet mdadm --create bez --assume-clean un kopēšana uz rakstīšanas (COW) cilpas pārklājums**:
6. Standarta izpilde mdadm --create (bez --assume-clean un precīza gabala izmēra, izkārtojuma un datu nobīdes saskaņošana) nekavējoties sāk rakstīt jaunas paritātes svītras visos diskos, iznīcinot failu sistēmas superbloku un B-kokus, ja kāds atsevišķs parametrs (512K vs. 64K gabals, left-symmetric vs. left-asymmetric, vai 2048s vs. 262144s datu nobīde) ir nepareizs pat par vienu sektoru.
7. Apzīmējiet katru fizisko cietā diska slotu (Bay 0 / Bay 1 / Bay 2 / Bay 3 un sērijas numurs) ar pastāvīgu marķieri vai lenti PIRMS viena diska izņemšanas no šasijas:
8. Uzrakstiet precīzu nodalījuma numuru un sērijas numuru uz katra diskdziņa augšējās etiķetes. Fiziskās līča kārtības pārzināšana un pārbaude mdadm --examine metadati ietaupa stundas svītru secības rekonstrukcijas vēlāk.
9. ** Klonējiet bojāto(-os) disku(-s) pa sektoram, lai, izmantojot jaunus, veselīgus diskus GNU ddrescue (ar mapes failu), izmantojot tiešos mātesplates SATA/HBA portus PIRMS RAID montāžas mēģinājuma**:
10. Nekad nemēģiniet salikt vai uzstādīt RAID masīvu, izmantojot pašu fiziski mirstošo disku. Savienojiet bojāto disku ar SATA/AHCI vai LSI, kas nav RAID IT-Mode HBA ports Linux glābšanas darbstacijā, atspējojiet OS automātisko montāžu un palaidiet ddrescue -f -n /dev/sdX /dev/sdY rescue_driveX.map tāpēc veselīgie ātrie sektori tiek evakuēti pirmajā piegājienā, pirms pieskaras slikto sektoru zonām.
11. Salieciet klonētos diskus Read-Only režīms (mdadm --assemble --readonly vai izmantojot dmsetup / losetup RAM/failu pārklājumi):
12. Novietojot vienreizlietojamo Copy-on-Write (COW) pārklājuma failu virs katra klonētā dalībnieka diska, varat pārbaudīt, uzstādīt masīvu, atkārtoti atskaņot ext4 vai XFS žurnālu vai pat pārbaudīt virtuālu pārbūvi , vienlaikus garantējot, ka jūsu pamatā esošajos diska klonos nekad netiek mainīti nulle baiti.

Lēmumu koks: RAID 5 vai RAID 6 masīva glābšana, ja atjaunošanas laikā neizdodas otrs disks¶

Izpildiet šo kriminālistikas krātuves atkopšanas darbplūsmu, lai atgūtu masīvu, nezaudējot nevienu atlikušo joslu:

flowchart TD
    Start["RAID 5 (otrais disks) vai RAID 6 (trešais disks) neizdodas / pāriet bezsaistē atjaunošanas laikā"] --> StopNow["1. DARBĪBA. Nekavējoties pārtrauciet pārbūvi un izslēdziet masīvu (novērsiet šķīvju punktu skaitīšanu neveiksmīga diska gadījumā)"]

    StopNow --> SoundCheck{"Vai neveiksmīgais disks radīja skaļus klikšķus, pīkstienus vai slīpēšanas skaņas?"}

    SoundCheck -->|"JĀ: mehāniskā galvas avārija/sastīšana"| CleanRoom["PĀRTRAUKT: neieslēdziet to vēlreiz. Nosūtiet TIKAI mehāniski neizdevušos disku (plus 1 veselīgs disks svītru atsaucei) uz tīrās telpas laboratoriju, lai izveidotu attēlu uz klona"]

    SoundCheck -->|"NĒ: griežas vienmērīgi, neizdevās sliktu sektoru dēļ (UNC / gaida / noildze)"| LabelDrives["2. DARBĪBA: marķējiet katru disku ar precīzu nodalījuma numuru un sērijas numuru , > izveidojiet savienojumu ar Linux darbstaciju, izmantojot tiešo SATA/IT režīma HBA"]

    LabelDrives --> InspectMeta["Palaidiet 'mdadm --examine /dev/sd*' un 'smartctl -a /dev/sd*' visos diskos (ieraksts atjaunināšanas laiks, notikumu skaitītājs, loma, gabala lielums, izkārtojums, datu nobīde)"]

    InspectMeta --> CloneDrives["3. DARBĪBA. Klonējiet katru degradēto/sliktā sektora disku uz veselīgu rezerves disku, izmantojot 'ddrescue -f -n' (vispirms ātrā caurlaide, pēc tam nokasīšana ar Mapfile)."]

    CloneDrives --> PickFreshest["Identificējiet N-1 (RAID 5) vai N-2 (RAID 6) diskus, izmantojot AUGSTĀKO/JAUNĀKO notikumu skaitītāju (nekad nesajauciet novecojušu, vecu, pamestu disku ar jauniem diskdziņiem)"]

    PickFreshest --> CowOverlay["4. DARBĪBA. Izveidojiet tikai lasāmu cilpu/dmsetup kopēšanas un rakstīšanas (COW) pārklājumus virs klonētajiem diskdziņiem, lai oriģinālos klonus nevarētu modificēt"]

    CowOverlay --> AssembleRO["Palaidiet 'mdadm --assemble --force --readonly' pārklājuma ierīcēs -> Mount Filesystem Read-Only ('mount -o ro,noload') -> Kopēt visus kritiskos datus uz ārējo krātuvi."]

1. fāze: izpratne par to, kāpēc otrais disks neizdodas RAID atjaunošanas laikā (XOR Parity Math & Event Counters)¶

Lai saprastu, kāpēc jūsu masīvs avarēja atjaunošanas laikā un kāpēc jūsu dati joprojām ir atkopjami, pārbaudiet, kā to izdarīt RAID 5 un RAID 6 faktiski strādā diskā.

1. Kā XOR paritātes rekonstrukcijas darbi un kāpēc 1 sliktais sektors pārtrauc visu pārbūvi¶

4 piedziņā RAID 5 masīvs (Drive A, Drive B, Drive C, Drive D), dati tiek sadalīti fiksēta izmēra gabalos (parasti 64 KB vai 512 KB) svītraini pāri diskiem, kur viens gabals katrā rindā satur XOR paritāti (P): $\(\text{Paritāte} P = A \oplus B \oplus C\)$ Ja Drive C pilnībā neizdodas, un jūs ievietojat tukšu Replacement Drive C_new, RAID kontrollerim ir jārekonstruē katra svītra C_new aprēķinot: $\(C_{\text{reconstructed}} = A \oplus B \oplus P\)$ - Kas notiek, kad Drive B trāpa vienu neizlasāmu 4 KB sektors (UNC kļūda) plkst 42% no pārbūves: - Lai aprēķinātu šo singlu 4 KB bloķēt C_new, kontrollerim jābūt derīgai lasīšanai no Drive A, Drive B, un Drive D. - Kad Drive B atgriež aparatūru Read Error (Sense Key 03h / 11h Unrecovered Read Error) pēc 7 sekundēm (TLER / ERC noildze), patērētāju un uzņēmumu RAID kontrolleri bieži tiek ieprogrammēti ar katastrofālu noklusējuma darbību: ** tā vietā, lai izlaistu šo vienu 4 KB sektoru, ierakstot nulles bloku un pabeidzot otru 99.9999% no pārbūves, RAID kontrolleris atzīmē Drive B kā FAILED / OFFLINE un pārtrauc visu pārbūvi**. - Tajā brīdī jūsu masīvam ir divi diskdziņi ar atzīmi "Neizdevās" (Drive C kas bija tikai 42% pārbūvēta, un Drive B kam patiesībā ir 99.99998% veselīgas nozares un tikai 12 slikti sektori).

2. Kāpēc Event Counters (Update Time) nosakiet, kuri diskdziņi ir jāizmanto atkopšanai¶

Katru reizi a RAID 5 vai RAID 6 masīvs raksta datus vai maina stāvokli (piemēram, disks pazūd), RAID metadati (mdadm superbloks vai aparatūra DDF metadati) palielinās par 64 bitiemEvents skaitītājs visos pašlaik aktīvajos diskos.

Salīdziniet mdadm --examine tipiska 4 piedziņas izeja RAID 5 katastrofa kur sdb vakar neizdevās (Events: 10450) un sdc izkrita šodienas rekonstrukcijas laikā (Events: 10892):

• ** RAID atkopšanas zelta likums no iepriekšējās tabulas**:
• Ievērojiet to /dev/sda (10892), /dev/sdc (10890), un /dev/sdd (10892) visiem ir praktiski identiski Events skaitītāji no Today 14:22.
• Kad mēs klonējam /dev/sdc uz veselīgu disku, izmantojot ddrescue (atgūstot 99,9999% tā sektoru un aizpildot 8 nelasāmos sektorus), mēs varam piespiest montēt /dev/sda + Cloned /dev/sdc + /dev/sdd (neņemot vērā daļēji pārbūvēto /dev/sdb pilnībā). Šī 3 piedziņu kombinācija nodrošina ** 100 procentīgi konsekventu, līdz sekundei degradētu RAID 5 masīvs** ar nulles svītru plīsumu.

2. fāze: pakāpeniska bojātā diska sektora klonēšana ar GNU ddrescue¶

Pirms pieskaraties mdadm vai jebkuru RAID montāžas rīku, jums jā jāklonē disks(-i), kas izraisīja lasīšanas kļūdas, uz veseliem rezerves diskdziņiem ar vienādu vai lielāku baitu ietilpību.

1. darbība. Sagatavojiet Linux glābšanas vidi un atspējojiet automātisko montāžu¶

1. Sāknējiet Linux darbstaciju (vai palaidiet serveri no tiešās USB atmiņas kartes, piemēram, SystemRescue system-rescue.org vai Ubuntu Live Server) ar diskdziņiem, kas savienoti ar standarta mātesplates SATA portiem vai LSI HBA IT Mode (Ne-RAID caurlaide).
2. Novērsiet, ka Linux sāknēšanas laikā automātiski mēģina salikt vai pievienot jūsu bojāto RAID masīvu:
3. Sāknējot SystemRescue vai Ubuntu Live, pārbaudiet cat /proc/mdstat. Ja Linux automātiski samontēja daļēju md ierīci fonā, nekavējoties apturiet to tikai lasāmajā drošajā režīmā pirms attēlveidošanas:

   mdadm --stop /dev/md*
   

4. Identificējiet katru disku pēc precīza modeļa, sērijas numura un baita lieluma (nekad neuzminēt /dev/sdX burti, jo Linux atkārtoti piešķir diska burtus pēc atkārtotas palaišanas):

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

   Uzrakstiet, kuras /dev/sdX atbilst jūsu Neatbilstoša avota diskam (piemēram, /dev/sdc, sērija WCC4E12345) un kuras /dev/sdY ir jūsu pilnīgi jauns tukšais mērķa disks (piemēram, /dev/sdf, sērija ZGG9988776).

2. darbība: palaidiet 2 posmu GNU ddrescue klonēšanas protokols (vienmēr izmantojiet Mapfile)¶

Nekad neizmantojiet standarta dd (dd if=/dev/sdc of=/dev/sdf) bojātā RAID diskdzinī: standarta dd vai nu pārtrauc pirmo slikto sektoru, vai arī maina izvades nobīdes, ja sync ir nepareizi konfigurēts, un tam nav atmiņas par to, kuri sektori ir veiksmīgi. GNU ddrescue (gddrescue pakotne) izmanto viedo vairākkārtēju stāvokļa kartes failu:

1. 1. pārlaide: ātrs, nenokasošs klons (-n karogs), lai vispirms glābtu 99,99% veselīgo nozaru:

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

2. -f: ļauj rakstīt tieši bloķētajā ierīcē /dev/sdf (** Trīsreiz pārbaudiet to /dev/sdc ir avots un /dev/sdf ir tukšs mērķis**).
3. -n (--no-scrape): Stāsta ddrescue lai nekavējoties pārlēktu pāri jebkuram lēna vai slikta sektora apgabalam, nesasmalcinot lasīšanas galviņu, izglābjot visus veselos gigabaitus ar maksimālo ātrumu (150 to 250 MB/s) pirms diska veselība pasliktinās.
4. /root/raid_bay3_sdc.map: saglabā precīzu sektora progresu ik pēc 30 sekundēm. Pat ja bojātais disks tiek bloķēts un ir nepieciešams barošanas cikls, atkārtoti izpildiet to pašu komandu ar .map fails tiek atsākts tieši tajā sektorā, kur tas apstājās.
5. 2. pāreja: Mērķtiecīga atpakaļgaitas/apgriešanas skrāpēšana (-d -r1), lai atgūtu marginālās sliktās nozares:
6. Kad 1. pāreja ir pabeigta (pct rescued: 99.99%), samaziniet kodola SCSI komandas taimautu, lai katrs sliktais sektors ātri neizdodas (5 seconds tā vietā, lai gaidītu 30 to 180 seconds katrā nozarē):

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

7. Palaidiet Pass 2 ar tiešu piekļuvi diskam (-d) un 1 atkārtots mēģinājums (-r 1):

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

8. Izslēdziet, atvienojiet oriģinālu, ja neizdodas /dev/sdc brauciet un droši novietojiet to plauktā: no šī brīža jūs strādāsit tikai ar savu veselīgo klonu (/dev/sdf) un citi jūsu veselie biedri brauc.

3. fāze: droša tikai lasāma RAID montāža, izmantojot funkciju Copy-on-Write (COW) pārklājumus un mdadm¶

Tagad, kad jums ir veseli diska kloni, nekad nepalaidiet mdadm --assemble --force tieši uz neapstrādātajiem diskdziņiem bez aizsargājošas kopēšanas-uzrakstīšanas (COW) pārklājums vai --readonly karogs. Kāpēc? Jo --force pārraksta RAID superblokus uz diskdziņiem un, ja failu sistēmas žurnāls (ext4 / XFS) tiek automātiski atskaņots uzmontējot, izmantojot nepareizu diska kombināciju, un tas neatgriezeniski maina jūsu klonus.

1. darbība: pārbaudiet RAID metadatus visos dalībnieku diskos (mdadm --examine)¶

Skrien mdadm --examine katrā dalībnieka diskā (vai nodalījumā, piemēram, /dev/sda1 vai /dev/sda3 Synology/QNAP NAS diskos) un saglabājiet izvadi teksta failā:

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

2. darbība: izveidojiet nesagraujošu kopēšanu rakstīšanas režīmā (COW) Ierīces kartētāja pārklājumi (overlay-create)¶

Lai garantētu 100 procentu drošību, lai pat tad, ja jūs ar spēku saliktu masīvu un palaistu mountJūsu fiziskajos cietajos diskos jebkad tiek ierakstīts nulle baitu, izveidojiet cilpas atbalstu dm-snapshot Copy-on-Write pārklājumus iekšā /tmp (vai ārējā scratch diskā):

# 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. darbība. Piespiedu kārtā salieciet masīvu pārklājuma ierīcēs un uzstādiet tikai lasāmu¶

1. Salieciet svaigākos N - 1 pārklājuma ierīces, izmantojot --assemble --force:

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

2. Kāpēc mēs atstājam novecojušo/puspārbūvēto disku (sdb3): piespiežot mdadm montēt ar 3 jaunākajiem diskdziņiem (sda3, klonēti sdf3, un sdd3) atnes /dev/md99 tiešsaistē tīrā degradētā režīmā ([U_UU]), izmantojot precīzu jaunāko Events stāvoklis, kamēr ddrescue jau izglāba datus no sdf3.
3. Aktivizēt LVM (vgchange), ja jūsu NAS vai serveris izmanto LVM papildus RAID (Synology SHR, QNAP, Proxmox, Ubuntu):

   pvscan
   vgscan
   vgchange -ay
   lvs
   

   (Ja jūsu Synology NAS izmanto Btrfs uz LVM vai Synology Hybrid RAID, jūs tagad redzēsit /dev/vg1000/lv vai /dev/vg1/volume_1 parādās.)
4. Instalējiet failu sistēmu stingri tikai lasīšanas režīmā un nekavējoties evakuējiet savus kritiskos failus:

   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. Vispirms nokopējiet vissvarīgākās mapes rsync uz ārējo rezerves disku:

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

4. fāze: aparatūras RAID kontrolleru glābšana (Dell PERC, LSI MegaRAID, HP Smart Array, Adaptec) un ZFS / Btrfs Pools¶

Ko darīt, ja jūsu masīvu pārvalda nevis Linux mdadm, bet ar Aparatūras RAID kontrollera karti (Dell PERC H730/H740/H755, Broadcom / LSI MegaRAID, vai HP Smart Array), kas tagad ziņo Virtual Disk Offline vai Foreign Configuration Found pēc otrā piedziņas žagas atjaunošanas laikā?

1. Aparatūras RAID kartes (Dell PERC, LSI MegaRAID, HP Smart Array)¶

1. ** NEKAD neklikšķiniet "Clear Foreign Configuration" vai "Initialize Virtual Disk"**:
2. Dell PERC / LSI MegaRAID BIOS (Ctrl+R vai HII UEFI konfigurācijas utilīta), Clear izdzēš RAID metadatus no diskdziņiem un Initialize pārraksta datu joslas.
3. Ja veselīgs disks uz īsu brīdi pārtrūka bezsaistē vaļīga aizmugurējā paneļa kabeļa vai taimauta dēļ, Import Foreign Configuration mēģinājumi atgriezt disku; tomēr, ja viens disks nokrita pirms nedēļām un otrs šodien, abu importēšana vai novecojušā diska piespiešana tiešsaistē, izmantojot kontrollera BIOS, var sabojāt masīvu.
4. Droša programmatūras rekonstrukcijas metode aparatūras RAID (DDF Metadati / dmraid / R-Studio / UFS Explorer):
5. Aparatūras RAID karšu veikala standarts SNIA DDF (Disk Data Format) metadati pēdējos sektoros katra cietā diska beigās un svītroti dati visos diskos, sākot no sektora 0 (vai pēc nelielas galvenes nobīdes), izmantojot standarta 64 KB, 128 KB, 256 KB, vai 512 KB gabalu izmēri (Left-Asymmetric vai Left-Symmetric).
6. Tā vietā, lai spēlētu azartspēles ar destruktīvu aparatūras RAID kartes BIOS:
   1. Marķējiet visus diskus pēc slota numura un pievienojiet tos standarta SATA/nav RAID IT-Mode HBA atkopšanas darbstacijā.
   2. Klonējiet sliktā sektora disku, izmantojot GNU ddrescue kā parādīts 2. fāzē.
   3. Atveriet klonētos diskus UFS Explorer RAID Recovery vai R-Studio Technician vai salieciet tos tikai lasāmā režīmā operētājsistēmā Linux, izmantojot dmsetup / mdadm --build: šie rīki automātiski nosaka LSI / PERC / HP svītru secība, gabala izmērs (64K/512K) un paritātes rotāciju 100% lasāmajā atmiņā, neļaujot aparatūras RAID kartei ierakstīt jūsu diskdziņos nevienu baitu.

2. TrueNAS/ZFS (RAID-Z1 / RAID-Z2) un Synology Btrfs Skrubja/sudraba atteices¶

Ja jūsu baseins izmanto OpenZFS (RAID-Z1 vai RAID-Z2) uz TrueNAS vai Proxmox un otrā diska metienu CKSUM / READ kļūdas a laikā zpool replace sudrabs: 1. Kāpēc ZFS apstrādā sliktos sektorus atkārtotas sudrabošanas laikā labāk nekā aparatūras RAID un kad tas joprojām tiek bloķēts: - Atšķirībā no naivām aparatūras RAID kartēm, kas nomet visu disku vienā sliktā sektorā, ZFS turpina atjaunoties pēc lokalizācijas. READ kļūdas un reģistrē tikai konkrētus bojāto failu ceļus zpool status -v. - Tomēr, ja otrais bojātais disks uzkaras SATA/SAS kopnē (I/O timeout / galvas dauzīšana) vai pakrīt bezsaistē (UNAVAIL / FAULTED), baseins ienāk SUSPENDED valsts (pool I/O is currently suspended). 2. Kā glābt a SUSPENDED vai FAULTED ZFS RAID-Z1 / RAID-Z2 baseins: - Tīri izslēdziet barošanu, klonējiet bojāto disku uz veselīga rezerves diska, izmantojot GNU ddrescue -f -n (ZFS nodalījumu etiķetes ietver precīzu vdev GUID diska sākumā un beigās, tāpēc ZFS automātiski atpazīst neapstrādātu sektora klonu kā oriģinālu vdev biedrs). - Atvienojiet fiziski mirstošo disku, atstājiet ddrescue izveidojiet savienojumu ar klonu un importējiet ZFS pūlu stingrā tikai lasīšanas režīmā (readonly=on), nesākot rakstīšanas darījumu vai neatsākot sudrabu:

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

Bieži uzdotie jautājumi¶

Kāpēc tu teici NEKAD neskrien CHKDSK vai fsck kad mans RAID masīvs tiek pievienots ar failu sistēmas kļūdām pēc diska nolaišanas?¶

Darbojas vienā atsevišķā cietajā diskā CHKDSK vai fsck novērš nelielas direktoriju neatbilstības. Uz a vairāku disku RAID 5 vai RAID 6 masīvs, kuram tika nomests dubultdisks vai tika pārtraukta pārbūve, failu sistēmas kļūdas gandrīz vienmēr izraisa RAID svītru novirze vai novecojis elementa disks tiek piespiests tiešsaistē (tas nozīmē katru 3 vai 4 64 KB Datu daļa tiek nolasīta no nepareizas diska paaudzes). Ja ļausi CHKDSK /f vai fsck -y palaist nepareizi izlīdzinātā vai nesinhronizētā RAID masīvā, miljoniem derīgu failu nepareizi interpretē kā bojātus metadatus, saīsina direktoriju kokus, izmet nenosauktus fragmentus pazaudēts+atrasts, un ieraksta jaunus paritātes blokus visos diskos, padarot matemātiski neiespējamu pēc tam atkal salikt pareizo disku kombināciju. Vienmēr uzstādiet caur Tikai lasāma kopēšana uz rakstīšanas (GOVS) pārklājumus vispirms.

Ko darīt, ja daļēji pārbūvētais rezerves disks (42% pabeigts) UN otrais disks, kas neizdevās plkst 42% ABIEM ir vajadzīgi dati? Vai es varu tos apvienot?¶

Jā. Šī ir klasiska "Split-Horizon / Hybrid Clone" RAID glābšana. Pieņemsim Braukt 2 pirmdien pilnībā nomira, tu ieliki Jaunais disks 2, un pārbūve to izdevās 42% (LBA 3 500 000 000) iepriekš Braukt 3 gadā cieta nāvējošu galvas triecienu LBA 3 500 000 000. Ievērojiet, kas jums patiesībā ir: par pirmie 42% no masīva (0% uz 42%), Jaunais disks 2 jau ir 100 procenti rekonstruēts. Tātad par pirmo 42% no LBA diapazona, jums ir pilns svītru komplekts, izmantojot 1. disks + jauns 2. disks + 4. disks (ārstējot avāriju Braukt 3 kā trūkstošais disks). Un ja Braukt 3 bija tikai lokalizēts sliktā sektora ielāps 42% (un ir lasāms no 43% uz 100% izmantojot ddrescue), jūs izmantojat 1. disks + klonēts 3. disks + 4. disks par atlikušo 58% no masīva.

Kāpēc RAID 5 atjaunošanas laikā otrie diskdziņi tik bieži neizdodas?¶

Divas inženiertehniskās realitātes apvienojas RAID 5 pārbūvē, kas ir bēdīgi slavena ar dubultpiedziņas kļūmēm: (1) Identiska partijas novecošana: Lielākā daļa lietotāju pērk 4 līdz 8 identiskus cietos diskus no viena mazumtirgotāja tajā pašā dienā (tā pati programmaparatūra, tā pati rūpnīcas partija, tā pati vārpstas motora partija) un darbiniet tos blakus tieši tādā pašā temperatūrā 35 000 stundas; kad 1. piedziņa nolietojas, 2. piedziņa un 3. piedziņa ir dienu attālumā no tā paša mehāniskā nodiluma sliekšņa. (2) Latentas nelabojamas lasīšanas kļūdas (URE): parastā ikdienas darbībā, 95% cietā diska aukstie arhīva sektori netiek lasīti vairākus mēnešus vienlaikus, tāpēc latenti sliktie sektori paliek neatklāti. A RAID 5 atjaunošanas spēki nepārtraukti 100% katra sektora virsmas nolasījums katrā atlikušajā braucienā (40 līdz 100 terabaiti nepārtraukta lasīšana), nekavējoties atklājot visus latentos sliktos sektorus, kas uzkrājušies pēdējā gada laikā.

Kā es varu zināt, kurus failus ietekmēja daži nelasāmie sliktie sektori, kas ddrescue vajadzēja aizpildīt nulli?¶

GNU ddrescue ietver iebūvētu kriminālistikas utilītu, ko sauc ddrescuelog un ddru_ntfsfindbad / atkļūdojumi kas kartē precīzi neatgūto sektora LBA diapazonus no jūsu .karte fails (statuss = '-' slikti sektori), izmantojot RAID svītru matemātiku, tieši uz failu sistēmas inode tabulu. Tiklīdz jūs zināt, kura 4 KB Klonēšanas laikā bloki tika aizpildīti ar nulli, varat vaicāt atkļūdojumi (icheck un ncheck ieslēgts ext4) vai btrfs inspect-internal logical-resolve lai izdrukātu precīzu sarakstu ar 2 vai 3 failu nosaukumiem, kas pārklājās ar šiem sliktajiem sektoriem, ar 100% matemātisko pārliecību apstiprinot, ka visi citi faili jūsu vairāku terabaitu serverī ir pilnībā nesabojāti.

Saistītie ceļveži¶

• RAID 5 vai RAID 6 Synology, QNAP vai TrueNAS vairāku disku nomešana un kāpēc piespiedu pārbūve iznīcina datus
• RAID kontrollera kartes nāve, ārvalstu konfigurācijas importēšana un kāpēc nekad nedrīkst inicializēt diskus
• NAS RAID masīvs ir degradēts, vairāku disku kļūme un ZFS/Btrfs atkopšana
• Cietā diska kļūme un datu atkopšana
• Datoru dublējumkopijas: 3-2-1 stratēģija un atkopšana pēc avārijas
• Ārkārtas palīdzības numuri pa valstīm

Avoti un oficiālās vadlīnijas¶

• Linux Raid Wiki (raid.wiki.kernel.org/index.php/Linux_Raid & Recovering_a_failed_software_RAID): Oficiālais kodols mdadm Atkopšanas protokols, Ierīces kartētāja kopēšana rakstīšanas režīmā (dm-snapshot) Pārklājumi un Events Pretsaskaņošana.
• GNU ddrescue Oficiālā inženieru rokasgrāmata (gnu.org/software/ddrescue/manual/ddrescue_manual.html): Daudzfāzu neskrāpēšana (-n) un tiešā piekļuve (-d) Nozares atkopšanas algoritmi neveiksmīgiem magnētiskajiem datu nesējiem.
• Synology oficiālā zināšanu bāze (kb.synology.com/en-global/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC): * Montāža mdadm + LVM2 + Btrfs / ext4 NAS sējumi tikai lasāmi Ubuntu glābšanas sistēmās*.
• Krātuves tīklu nozares asociācija (SNIA): Kopējais RAID diska datu formāts (DDF) Aparatūras RAID kontrollera metadatu pārnesamības specifikācija.