RAID 5, RAID 6 või ZFS mitme draivi väljalangemine: kokkujooksnud Synology, QNAP või TrueNAS-i massiivi taastamine ilma pariteeti hävitamata¶

Synology DiskStationi, QNAP TS-seeria, TrueNAS-i serveri või Linuxi kuulamine mdadm salvestusserver piiksub pidevalt, kui teavitatakse teatest Käsi krahh, Pool on halvenenud / vigane või Mitme draivi on lahti ühendatud, see on suure panusega salvestushäda. Kui üks draiv kukub välja a RAID 5, Synology hübriid-RAID (SHR-1), või ZFS RAIDZ1 bassein, massiiv töötab null koondamisega (degraded olek), rekonstrueerides puuduvad plokid jooksvalt, lugedes paralleelselt kõiki ülejäänud kettaid. Kui teine draiv katkeb tundide pärast võrguühenduseta või kuvab taastamatu lugemisvea (URE) poole asenduskettale ümberehitamise ajal pariteedi matemaatika laguneb ja salvestuskogum läheb täielikult võrguühenduseta. Paanikas administraatorid hävitavad sageli järgmise kuuekümne sekundi jooksul terabaite taastatavaid andmeid, klõpsates nupul Initsialiseeri, luues massiivi uuesti mdadm --createvõi sundides rikkis riistvara koheselt võrgus ümber ehitama. Kui teie riistvaraline RAID-kontrolleri kaart ise suri, mitte kettad, lülitage sisse RAID-kontrolleri kaardi surm, võõrkonfiguratsiooni import ja miks te ei tohi kunagi kettaid initsialiseerida; Kui mõni kõvaketas klõpsab või keeldub üles keeramast, konsulteerige kõvaketta rike ja andmete taastamine või NAS RAID-massiivi halvenemine, mitme draivi rike ja ZFS/Btrfs-i taastamine. Kui see salvestustõrge keelab haigla meditsiinilise pildistamise (PACS), hädaabi saatmine või eluohutuse infrastruktuuri, helistage kohalikule hädaabinumbrile (911 Ameerika Ühendriikides ja Kanadas, 112 kogu Euroopa Liidus, 999 Ühendkuningriigis) või vaadake meie kataloogi hädaabinumbrid.

Tehke seda kohe¶

1. Peatage ja ÄRGE klõpsake "Initsialiseeri", "Loo bassein", "Paranda" ega käivitage mdadm --create mahakukkunud draivil: klõpsates Synology DSM-is või QNAP QTS-is nuppu Initsialiseeri või käivitage mdadm --create Linuxis kirjutab uhiuusi superplokke ja alustab kõigi liikmete ketaste paarsusribade nullimist. Välja kukkunud draiv tavaliselt ikka peab 99.99% teie failid on terved, sünkroonimisest väljas on märgitud ainult selle sündmuste loendur.
2. Sündmusloendurite külmutamiseks lülitage NAS või server puhtalt välja (või tõmmake toide, kui see taastab aktiivselt klõpsavate draivide vahel).: iga sekund jääb massiivi osaliselt halvenenud olekus võrku, operatsioonisüsteem suurendab superplokki Update Time ja Events säilinud ketaste loendur, samal ajal kui maha kukkunud ketas jääb vanema sündmusenumbri juurde külmutatuks. Kui NAS proovib vigaste sektoritega draivi automaatset ümberehitamist, võib draivi lugemise jätkamine eemaldada magnetplaadi katte (head crash).
3. Märgistage iga draivi sahtli pesa füüsilise markeri või lindiga (Bay 1, Bay 2, Bay 3, Bay 4) enne salve välja libistamist: Linuxi ajal mdadm, LVM2ja ZFS Jälgige draivi järjekorda UUID-ga iga partitsiooni superploki, vanemate riistvarakontrollerite ja käsiraamatu sees dmsetup tabeli rekonstruktsioonid nõuavad täpset füüsilist pesa järjekorda (0, 1, 2, 3...).
4. Ärge kunagi proovige taastada, jõuga kokku panna või fsck otse algsetel liikmete draividel; kloonige iga draivi bitti kasutades ddrescue esimene: enne jooksmist mdadm --assemble --force või zpool import -F, ühendage iga liikmeketas Linuxi tööjaamaga otsese SATA/SAS-i kaudu (mitte kunagi odav USB-sild, mis varjab SMART või SCT ERC timeouts) ja kloonige see koos ddrescue tervetele varudraividele või pildifailidele.
5. ** Sundmonteerige kloonitud massiiv rangelt ONLY REACH-režiimis (--readonly või -o readonly=on)**: Kokkupanemisel mdadm massiivid, mille sündmuste loendurid triivisid üksteisest samaaegse mitme draivi languse ajal, läbivad alati --readonly (mdadm --assemble --force --readonly /dev/md0 ...). Kirjutuskaitstud režiimis mitte kumbki mdadm, LVM2, ext4, Btrfs, ega ZFS saab paarsusribasid üle kirjutada või hävitavat ajakirja uuesti esitada.
6. Kopeerige oma kõige olulisemad andmed kohe pärast kirjutuskaitstud ühendamist sõltumatule välisele varukettale: evakueerige oma dokumendid, andmebaasid, virtuaalsed masinad ja fotod esmalt eraldi draivi, seejärel pühkige ja testige kettaid nullist.

Otsuste puu: mitme draiviga RAID ja ZFS-i basseini hädaolukorra triaaž¶

Kasutage seda vooskeemi, et teha kindlaks, kas teie massiivi loogiline ajalõpu langus (TLER / ERC mittevastavus), tõeline mitme ketta vigase sektori tõrge ümberehitamise ajal või ZFS-i tehingugrupp (TXG) viga:

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS Pool jooksis pärast 2+ draivi väljalangemist kokku"] --> StopIO["Peatage kõik ümberehitused ja lülitage NAS kohe välja"]
    StopIO --> Label["Märgistage iga kettasalve lahtri numbri järgi (laht 1 kuni laht N)"]
    Label --> ConnectLinux["Ühendage liikmete draivid Ubuntu Linux Rescue Hostiga otse SATA / HBA kaudu"]

    ConnectLinux --> CheckSmart["Kontrollige SMART-i ja metaandmete kirjutuskaitstust: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Kas mõni draiv klõpsab, keeldub pöörlemast või katkestab võrguühenduseta dmesgis?"}

    PhysicalHealth -->|"Jah: mehaaniline / pea rike 2+ draivil RAID 5-s"| Cleanroom["Peata toitekettad -> Saada puhasruumi andmete taastamise laborisse"]
    PhysicalHealth -->|"Ei: kõik draivid pöörlevad üles (võivad olla ootel halvad sektorid või ajalõpu langus)"| CloneAll["Kloonige iga liikmeketas GNU ddrescue abil (edasipääs -> tagurpidi kraapimine)"]

    CloneAll --> DisconnectOrig["Ühendage lahti originaaldraivid ja töötage rangelt kloonitud ketaste / piltidega"]
    DisconnectOrig --> ArrayType{"Millist salvestusarhitektuuri kasutatakse?"}

    ArrayType -->|"Synology DSM (SHR / klassikaline RAID)"| SynologyFlow["Kontrollige sündmusi mdadm kaudu --examine -> Force-Assemble kirjutuskaitstud -> Aktiveeri LVM2 / Btrfs kirjutuskaitstud"]
    ArrayType -->|"QNAP QTS (HAL LVM õhuke / paks RAID)"| QnapFlow["Koguge mdadm kirjutuskaitstud -> Aktiveerige DRBD kiht, kui see on olemas -> Kontrolli kohandatud QNAP LVM2 superplokke"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / peegel)"| ZfsFlow["Käivitage zpool import -d /dev/disk/by-id -> Import kirjutuskaitstud tagasipööramisega: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Standardne Linux mdadm"| LinuxFlow["Võrdle sündmuste loendureid -> Käivita mdadm --assemble --force --readonly -> Ühendage failisüsteem käsuga -o ro,noload"]

1. etapp: miks hävitab ümberehitamise sundimine andmed (URE ja sama partii kaskaad)¶

Et mõista, miks nupul Paranda/ümberehita klõpsamine või ühe draivi asendamine ja 36-tunnine ootamine põhjustab sageli massiivi täieliku krahhi, peate mõistma, kuidas paarsuste rekonstrueerimine mõjutab vananevat magnetkandjat ja miks tarbija lauaarvuti draivid NAS-i korpustest välja kukuvad.

1. Taastamatute lugemisvigade matemaatiline reaalsus (UREs) RAID 5 või RAIDZ1 ümberehitamise ajal¶

4-ajamiga RAID 5 või ZFS RAIDZ1 bassein, andme- ja paarsusplokid (P) on triibulised üle kõigi nelja ketta, kasutades eksklusiivset VÕI (XOR) arvutamine (D1 XOR D2 XOR D3 = P). Kui Drive 2 sureb täielikult välja, pole massiivi järelejäänud liiasust null. Drive 2 ümberehitamiseks uhiuuele asenduskettale peab NAS samaaegselt lugema iga üksikut sektorit 0-st baidist kuni ketta lõpuni draivi 1, draivi 3 ja draivi 4 puhul (Reconstructed D2 = D1 XOR D3 XOR P).

Mõelge sellele, mis juhtub, kui need draivid on neli 12 terabaiti (12 000 gigabaiti) kõvaketast, mis on ostetud samast tootmispartiist neli aastat tagasi: - 12 terabaidi taastamine nõuab lugemist 36 terabytes (2.88 x 1014 üksikud bitid) pidevalt 24-48 tunni jooksul maksimaalse termilise ja mehaanilise koormuse juures. - Tarbijate kõvaketastel on tavaliselt taastamatu lugemisviga (URE) spetsifikatsioon 1 error in 1014 bits (12.5 terabytes) ja vananevatel draividel tekivad vaiksed varjatud sektori vead (Current_Pending_Sector) ketta külmades piirkondades, mida pole aastaid loetud. - Hetkel, kui Drive 3 tabab ühtainsat loetamatut 4 kilobaiti (0,004 megabaiti) vigast sektorit, samal ajal kui Drive 2 on endiselt puudu või pooleldi ümber ehitatud, XOR võrrandil on kaks tundmatut (D2 ja D3).

2. Miks töölauadraivid ilma TLER / SCT ERC saada 1 halva sektori pärast täielikult välja¶

Siin on lõks, mis põhjustab Synology, QNAP ja Linuxi mitme draivi katastroofilisi kukkumisi 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.                 |
+-------------------------------------------------------------------------+

Pange tähele, mis tegelikult juhtus: Drive 3 ei ole surnud. On 99.999999% terved sektorid ja ainult 1 või 2 loetamatut 4 kilobaidist sektorit (8 kilobytes välja 12 terabytes). Ometi sellepärast mdadm lükkas draivi 3 massiivist välja 30-sekundilise käsu ajalõpu tõttu, kuvatakse kogu helitugevus kui Jõkkes. Kui kloonite Drive 3 koos ddrescue (mis jätab graatsiliselt vahele 8 kilobaiti vigaseid sektoreid ja kopeerib ülejäänud 12 terabaiti) ja kirjutuskaitstud massiivi sundmonteerimisel taastate peaaegu 100 protsenti oma failidest.

3. Miks sa ei tohi KUNAGI joosta mdadm --create või klõpsake "Initsialiseeri"¶

Kui massiiv jookseb kokku, levib võrgus kaks hävitavat müüti: - Müüt 1: "Looge massiiv uuesti täpselt sama draivijärjekorraga, kasutades mdadm --create Isegi koos --assume-clean, kaasaegsed versioonid mdadm vaikimisi erinev Data Offset väärtused olenevad tuumast ja mdadm vabasta (2048 sectors vs 262144 sectors). Millal mdadm --create kirjutab uue versiooni 1.2 superplokk vale nihkega või sobimatu tüki suurusega, kirjutab see üle LVM2 füüsilise helitugevuse päis või ext4 superplokk helitugevuse esiosas. - Müüt 2: "Tõmmake välja teine draiv, mis just kukkus, ühendage see uuesti ja klõpsake nuppu Paranda." Kui Drive 1 langes välja kolm päeva tagasi (seega on selle andmed 3 päeva aegunud) ja Drive 3 langes välja 10 minutit tagasi (nii et selle andmed on praegused), põhjustab vale draivi tõmbamine ja uuesti sisestamine või taasehitamise sundimine, kui Drive 1 on märgitud "aktiivne" ja Drive 3, mis on tähistatud "massiiviga" üle , 3 päeva vanad aegunud paarsusribad, mis rikuvad kõik viimase 72 tunni jooksul muudetud kataloogid ja failid.

2. etapp: superplokkide ja Event loendab turvaliselt Linuxi päästehostis¶

Kokkujooksnud Synology, QNAP, TrueNAS või Linuxi massiivi ohutuks päästmiseks eemaldage kõik liikmedraivid (pärast nende lahtrinumbrite märgistamist) ja ühendage need lauaarvuti või serveriga, kus töötab Ubuntu 22.04 LTS / 24.04 LTS (isegi reaalajas USB-mälupulgalt käivitatuna).

1. samm: installige kohtuekspertiisi päästetööriistade komplekt Ubuntusse¶

Avage oma Ubuntu päästeseadmes terminal ja installige vajalikud utiliidid:

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

2. samm: kaardistage iga draivitäht, seerianumber ja partitsiooni paigutus¶

Loetlege kõik ühendatud plokkseadmed ja nende riistvara seerianumbrid, et mitte kunagi segi ajada päästeketast lähte-NAS-kettaga:

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

Vaadake tüüpilise Synology DSM, QNAP või TrueNAS draivi partitsioonitabelit:

3. samm: kontrollige mdadm --examine et näha, miks massiiv kokku jooksis (The Event Counter Matrix)¶

Synology, QNAP või Linuxi puhul mdadm massiivi, uurige kasutajaandmete sektsioonide RAID-i metaandmeid (näiteks partitsioon 3 /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) ilma midagi paigaldamata või muutmata:

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

Võrrelge kõigi nelja draivi väljundit:

/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)

Lugege see kohtuekspertiisi lugu hoolikalt läbi: 1. /dev/sdc3 (Device Role 1) on Events arv 479012 kaks päeva tagasi (Oct 29). See draiv langes esimesena välja kaks päeva tagasi ja on sellest ajast peale võrguühenduseta olnud. 2. /dev/sdb3 (Role 0) ja /dev/sde3 (Role 3) on mõlemal Events : 482190 juures 14:12:09. 3. /dev/sdd3 (Role 2) on Events : 482188 juures 14:12:04, vaid 5 sekundit ja 2 sündmust taga sdb3 ja sde3. 4. Järeldus: peate massiivi rekonstrueerima, kasutades sdb3 (Role 0), sdd3 (Role 2) ja sde3 (Role 3) (mille sündmuste loendurid on vaid 2 linnukese kaugusel), lahkumisel sdc3 (Role 1) täielikult välja.

3. etapp: iga draivi kloonimine GNU ddrescue¶

Enne jooksmist mdadm --assemble --force või zpool import -F, kloonige iga vajalik draiv (eriti draiv, mis kukkus viimasena välja vigaste sektorite tõttu, nt /dev/sdd ülaltoodud näites) tervele tühjale, võrdse või suurema võimsusega kettale või töötlemata kettale .img fail suurel salvestusmahul.

1. samm: miks ddrescue koos kaardifailiga on kohustuslik¶

Standardne dd katkeb esimesel vigasel sektoril või koos conv=noerror,sync raiskab tunde oma lugemispeade jahvatamisele kahjustatud rajal, täites samal ajal megabaite kõrvalolevaid häid andmeid. GNU ddrescue töötab intelligentsetes mitmeastmelistes passides: 1. Esimene läbimine (kopeerimisfaas): kopeerib kõik ketta terved ja kiiresti reageerivad piirkonnad täiskiirusel (150 MB/s juurde 250 MB/s), hüpates kohe üle kõigist aeglastest või loetamatutest plokkidest, et draiv ei kuumeneks üle ega sureks enne, kui 99.99% head andmed. 2. Lõpe 2 (kärpimisfaas): loeb kuni iga vigase ploki täpsete servadeni nii eest kui ka tagant (reverse direction), et isoleerida kahjustatud ala täpselt 4 kilobaidise riistvarasektorini. 3. Lõpetus 3 (kraapimisfaas): proovib kahjustatud sektoreid õrnalt uuesti ilma siini asjatult lähtestamata.

2. samm: käivitage 2-etapp ddrescue klooni käsk¶

Määrake alati kaardifail (sdd_rescue.map). Kui sureva allika ajam katkeb ja nõuab toitetsüklit, ddrescue loeb kaardifaili ja jätkab täpselt samast baidist, kust see pooleli jäi, ilma ühtki juba kopeeritud sektorit uuesti lugemata:

# 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

4. etapp: Synology DSM-i rekonstrueerimine (SHR-1 / SHR-2 / Classic RAID), QNAP ja Linux mdadm¶

Kui teie kloonitud draivid (või kirjutuskaitstud silmusseadmed) on valmis ja algsed NAS-draivid on ohutult lahti ühendatud, järgige oma platvormi täpset mittepurustavat koostejärjestust.

Stsenaarium A: standardne Linux mdadm või Synology Classic RAID (RAID 5 / RAID 6)¶

1. Peatage kõik osalised md massiiv, mida Ubuntu võis proovida käivitada:

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

2. Kloonitud partitsioonide sundmonteerimine (sdb3, sdd3, sde3, jättes välja ammu surnud sdc3) rangelt kirjutuskaitstud režiimis:

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

   Vaadake väljundit: mdadm annab aru forcing event count in /dev/sdd3(2) from 482188 up to 482190 ja mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Veenduge, et massiiv on aktiivne ja märgitud (auto-read-only) või (read-only):

   cat /proc/mdstat
   

Stsenaarium B: Synology hübriid-RAID (SHR-1 ja SHR-2) koos LVM2 ja Btrfs / ext4¶

Synology SHR (Synology Hybrid RAID) on 100% standardne Linuxmdadm + LVM2 (Logical Volume Manager): - Kui kõik SHR-i kogumis olevad draivid on ühesuurused (näiteks neli 8 terabaidist draivi), loob Synology ühe mdadm RAID 5 partitsioon (md2 iga draivi partitsioonile 3) ja asetab an LVM2 mahu grupp (vg1000 või vg1) peal md2. - Kui SHR-i kogumis olevad draivid on erineva suurusega (näiteks kaks 8 terabaidist draivi ja kaks 16 terabaidist draivi), loob Synology kaks eraldi mdadm massiivid: md2 üle partitsiooni 5 (8 TB lõigake RAID 5 kõigil neljal draivil) ja md3 üle partitsiooni 6 (ülejäänud 8 TB lõika RAID 1 kahele 16 TB draivile), seejärel liitub md2 + md3 singlisse LVM2 Mahurühm (vg1000).

Synology SHR-i kirjutuskaitstud köite ühendamiseks Ubuntule pärast sundmonteerimist /dev/md2 (ja /dev/md3 kui erineva suurusega SHR): 1. Synology LVM2 füüsiliste mahtude ja mahurühmade otsimine:

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

Stsenaarium C: Synology DSM 7+ mahukrüptimine või jagatud kausta krüptimine (eCryptfs)¶

• Jagatud kausta krüptimine (@sharename@ kaustad, mis sisaldavad ECRYPTFS_FNEK_ENCRYPTED... failinimed): Kopeerige kogu @encrypted_share@ kaust väljas /mnt/synology_rescue esmalt ühendage ja dekrüpteerige see Ubuntus, kasutades oma Synology krüpteerimisparooli või .key fail:

  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
  

• DSM 7.2+ täismahuline krüptimine (LUKS): Kui /dev/vg1000/lv näitab TYPE="crypto_LUKS" sisse blkid, avage see kirjutuskaitstult, kasutades nuppu .rkey Köite loomisel alla laaditud taastevõtme fail:

  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
  

Stsenaarium D: QNAP QTS (LVM2 Thin Provisioning ja DRBD kiht)¶

Kaasaegsed QNAP NAS seadmed (QTS 4.3+ / 5.x) sisestage sisemine üksiksõlme DRBD seade (/dev/drbd1) vahel /dev/md1 ja LVM2 Mahurühm (vg1). 1. Esmalt pange QNAP-i andmepartitsioonid jõuga kokku (/dev/sd[b-e]3) kirjutuskaitstud /dev/md1:

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

5. etapp: TrueNASi ja Linuxi päästmine ZFS basseinid (RAIDZ1, RAIDZ2, RAIDZ3)¶

Kui teie salvestusserver töötab TrueNAS CORE, TrueNAS SCALE, Proxmox VE või Ubuntu ZFS, taastamine ei kasuta mdadm. Selle asemel ühendab ZFS köitehalduri ja kopeerimise-kirjutamisel (CoW) failisüsteemi üheks tehinguarhitektuuriks, mis on üles ehitatud Uberblockide ja järjestikuste tehingurühmade (TXGs).

1. samm: kontrollige 4 ZFS vdevi silti (L0, L1, L2, L3) igal kloonitud kettal¶

Iga ZFS-i liikmesektsioon salvestab neli identset basseini konfiguratsiooni koopiat ja massiivi viimasest 128 Uberblockist (kaks silti partitsiooni esiosas, L0 ja L1ja kaks silti päris lõpus, L2 ja L3). Jookse zdb -l igal kloonitud partitsioonil, et kontrollida kogumi olekut ja kõrgeimat tehingugruppi (txg):

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

Võrrelge txg: numbrid kõigis kloonitud draivides. Täpselt nagu mdadm's Events loendur, kui üks ketas kukkus välja 5 minutit enne toitekadu või teise ketta väljalangemist, siis selle txg on pisut madalam kui ülejäänud kettad.

2. samm: importige ZFS-i kogum ainult kirjutuskaitstud režiimis (-o readonly=on)¶

Kõigepealt kontrollige imporditavaid basseine ilma nende kaudu midagi paigaldamata sudo zpool import -d /dev/disk/by-id. Ärge kunagi importige kahjustatud või mitme kettaga ZFS-i kogumit lugemis-kirjutamisrežiimis. Kui imporditakse koos -o readonly=on, ZFS ei ürita algatada resilverit, ei kirjuta uusi Uberblokke ega saa kerneli paanikasse sattuda, kui ruumikaart on rikutud (spacemap) ilmneb kirjutamise eraldamisel:

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

3. samm: kui zpool import ebaõnnestub I/O error või corrupted data, kasutage TXG tagasipööramist (-F ja -T)¶

Kui kaks draivi langesid tugeva kirjutamispurske ajal teineteisest mõne sekundi jooksul välja, siis uusim tehingugrupp (TXG N) võivad säilinud paarsusribadel olla mittetäielikud, samas TXG N-1 või TXG N-2 (kirjutatud 5-15 sekundit varem) on Uberblocki rõngaspuhvris 100 protsenti puutumata.

1. Testige mittepurustavat kuivkäivitamisega tagasipööramise eelvaadet (-F -n):

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

   Kui ZFS teatab Would be able to return pool to its state as of <timestamp>, käivitage kirjutuskaitstud tagasipööramise import ilma -n:

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

2. ** Kui -F ei saa ikka veel uusimaid Uberblocke paigaldada, loetlege ajaloolised Uberblock TXG numbrid zdb ja importida konkreetne vanem TXG (-T)**:

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

   Vali a txg number 30 kuni 60 sekundit enne kokkupõrget (näiteks txg = 9481020) ja importige sellel täpselt sel ajahetkel külmutatud kogum kirjutuskaitstud režiimis:

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

6. etapp: taastamisjärgne kontroll ja tulevaste ümberehituskaskaadide vältimine¶

Kui olete 100 protsenti taastatud andmetest kopeerinud /mnt/synology_rescue või /mnt/zfs_rescue sõltumatule varunduse sihtmärgile, järgige seda riistvara ja konfiguratsiooni kontroll-loendit enne oma NAS-i uuesti kasutuselevõttu:

• Ärge kunagi ostke kõiki NAS-draive samalt jaemüüjalt samal päeval: samast tootmispartiist pärit draivid jagavad identseid peapartiisid ja püsivara, mis põhjustab nende ümberehitamise ajal üksteisest mõne tunni jooksul rikke. Sega partiid või tootjad (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• ** Kasutage ainult NAS-i/ettevõtte draive koos TLER / SCT ERC lubatud (või tõsta Linux mdadm SCSI ajalõpud töölauadraividele)**: Linuxi tarbijadraividele mdadm, kasutage a udev reegel tõsta /sys/block/sdX/device/timeout alates 30 sekundit kuni 180 sekundit nii mdadm ootab draivi mahajätmise asemel sisemise sektori uuesti kaardistamist.
• Migreerige massiive, mille draivid on suuremad kui 8 TB alates RAID 5 / SHR-1 / RAIDZ1 juurde RAID 6 / SHR-2 / RAIDZ2: koos 12 TB juurde 24 TB draivid, ühepaarsuse taasteajad ületavad 30 tundi, muutes kahepaarsuse (RAID 6 / SHR-2 / RAIDZ2) oluline, et hõbedamise ajal halb sektor üle elada.
• ** Ajakava iga kuu Data Scrubbing (mdadm check / zpool scrub) ja laiendatud SMART testid**: igakuine puhastamine parandab varjatud sektori vead (Current_Pending_Sector), kui kõik draivid on võrgus.
• Pidage meeles, et RAID on kõrge kättesaadavusega, mitte kunagi varukoopiana: järgige 3-2-1 varustrateegia võrguühenduseta koopiaga.

Piirkondlikud hädaabinumbrid ja agentuuride protokollid¶

Salvestuskatkestused, mis mõjutavad tervishoiuvõrke, hädaabisidet või kohustuslikke isiklikke andmeid, nõuavad viivitamatut eskalatsiooni:

• Ameerika Ühendriigid ja Kanada: helistage 911 kui salvestuskrahh blokeerib haigla kliinilised süsteemid (EHR / PACS) või saatmine. Teatage NAS-i sihitud lunavarast (DeadBolt, LockBit, Akira) kuni CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov) või Kanada küberturvalisuse keskus (1-833-CYBER-88).
• Ühendkuningriik: vali 999 hädaolukordadeks, mis mõjutavad eluohutust või NHSi ägedat abi. Ühendkuningriigi GDPR-i kohaselt hinnake, kas isikuandmete püsiva varundamata kadumise korral tuleb teavitada ICO-d (0303 123 1113) 72 tunni jooksul.
• Euroopa Liit: vali 112 kogu ELis. NIS2 direktiivi kohased üksused peavad teatama suurematest töökatkestustest oma riiklikule CSIRT-ile 24 tunni jooksul ja isikuandmete püsiv kättesaadavuse kadu käivitab GDPR artikli 33 kohaselt teatamise 72 tunni jooksul.
• Austraalia ja Uus-Meremaa: helistage 000 Austraalias või 111 Uus-Meremaal; teatage infrastruktuuri või lunavara NAS-i juhtudest ACSC-le (1300 CYBER1) või CERT NZ (0800 237 869).
• India ja Aasia ja Vaikse ookeani piirkond: helistage 112 Indias hädaolukordadele reageerimiseks; teatage infrastruktuuri salvestusintsidentidest CERT-In (incident@cert-in.org.in) kohustusliku 6-tunnise ajavahemiku jooksul.

Korduma kippuvad küsimused¶

Miks tegi mdadm --assemble --force keelduda minu RAID 5 massiivi käivitamisest not enough to start the array?¶

4-ajamiga RAID 5 massiiv, vähemalt 3 sõitu 4-st tuleb edasi anda mdadm --assemble --force. Jookse sudo mdadm --examine /dev/sd[a-z]3 et kontrollida, miks kolmas draiv tagasi lükati: kas läbisite partitsiooni asemel terve ketta (/dev/sdd asemel /dev/sdd3), märgiti selle superplokk kui a Varu katkestatud ümberehituse tõttu või Ubuntu automaatkoostaja lukustas ühe draivi passiivseks /dev/md127 seade (käivita sudo mdadm --stop --scan esmalt, siis uuesti mdadm --assemble --force --readonly).

Mis siis, kui draivi hakatakse ümber ehitama (Recovery = 12%) enne kui teine sõit välja kukkus?¶

Kui draiv 2 suri, sisestasite asendusketta 2 ja kell 12% ümberehitamise edenemine Drive 3 katkes halva sektori tõttu võrguühenduseta, ärge kasutage 12% ümberehitatud asendusdraivi 2. Selle asemel kloonige originaal Sõida 3 koos ddrescue. Kuna 3. draiv oli täiesti praegune kuni taasehitamise peatumiseni 12% juures, kui massiivi jõuga kokkupanemine kirjutuskaitstuks draivi 1 abil, ddrescue Drive 3 kloon ja Drive 4 (jättes draivi 2 välja) annab teile ühtlase massiivi.

Kas ma saan panna oma Synology- või QNAP-draivid uhiuude NAS-i šassiisse, kui NAS-i toiteallikas või plaat suri?¶

Jah, mõlemad Synology (HDD migratsioon) ja QNAP (Otsene NAS-i migratsioon) salvestage RAID-i konfiguratsioon draividele endile. Siiski kui kaks või enam draivi on juba välja langenud (`Volume Crashed`) enne šassii surma ärge käivitage neid uues NAS-i šassiis, sest migreerimisviisard võib partitsioonid üle kirjutada või käivitada hävitava ümberehituse. Esmalt päästke Ubuntu kirjutuskaitstud andmed.

Kuidas ma tean, kas maha kukkunud draivi on kloonimiseks ohutu? ddrescue versus puhasruumi labori vajamine?¶

Ühendage draiv SATA-ga, lülitage see sisse ja kuulake vaatamise ajal 10 sekundit sudo dmesg -w. Kui draiv teeb rütmilist klõpsamist, kraapimist või suminat, pöörleb üles ja tagasi alla või teatab võimsusest 0 B / 4,1 GB sisse lsblk, on lugemis-/kirjutuspead füüsiliselt ebaõnnestunud: katkestage kohe vool ja kasutage puhta ruumi laborit. Kui draiv pöörleb sujuvalt, kuvatakse selle täisvõimsus lsblk, ja ainult logid Praegune_ootel_sektor või ajalõpu vead, kloonige see ddrescue.

Mis on "RAID 5 kirjutusauk" ja kuidas see töötab ZFS või Btrfs vältida seda elektrikatkestuse ajal?¶

Traditsioonilises RAID 5 / RAID 6 ilma päevikuta nõuab triibu värskendamine andmeploki ja paarsusploki samaaegset kirjutamist kahele kettale. Kui kirjutamise ajal katkeb toide, ei ühti andmed ja paarsus enam ( Kirjutage auk). ZFS (`RAIDZ`) ja Btrfs kõrvaldage kirjutusava, kasutades funktsiooni Copy on-Write (`CoW`), kirjutades iga uue triibu kasutamata plokkideks ja värskendades Uberblocki/juurkursorit alles pärast seda, kui kogu riba on kettal.

Kas ma saan kasutada dmsetup ülekatted RAID-i parameetrite testimiseks ilma kloonitud draive muutmata?¶

Jah, saate luua funktsiooni Copy-on-Write (`CoW`) ülekatted kirjutuskaitstud ahela seadmete peal (`losetup --read-only`), kasutades Linuxit dmsetup (`snapshot` sihtmärk), mida toetavad hõredad failid /tmp. Kõik kirjutab alates mdadm --assemble --force või fsck -y minge ühekordseks kasutamiseks /tmp ülekattefaili, mis võimaldab teil vajadusel lähtestada 1 sekundiga.

Seotud juhendid¶

• NAS RAID-massiivi halvenemine, mitme draivi rike ja ZFS/Btrfs-i taastamine
• RAID-kontrolleri kaardi surm, võõrkonfiguratsiooni import ja miks te ei tohi kunagi kettaid initsialiseerida
• Kõvaketta rike ja andmete taastamine
• SSD ja NVMe äkiline kirjutuskaitstud režiim, 0% varuplokke ja TRIM-i keelav pääste
• Juhuslik "rm -rf" või "Shift+Delete" Linuxis, macOS-is või Windowsis: kohene kirjutuskaitstud uuesti ühendamine
• Arvuti varukoopiad, strateegia 3-2-1 ja avariitaaste
• Hädaabinumbrid riigiti

Allikad ja ametlikud juhised¶

• Linux Raid Wiki (raid.wiki.kernel.org) ja Linuxi tuuma organisatsioon: Ebaõnnestunud tarkvara RAID-i taastamine (mdadm --assemble --force --readonly ja sündmuste loenduri mittevastavus).
• Vaba Tarkvara Sihtasutus (GNU Project): GNU ddrescue Käsiraamat: kohtuekspertiisi andmete taastamine ebaõnnestunud andmekandjatelt.
• OpenZFS dokumentatsioon (openzfs.github.io): ZFS-i kogumi impordi taastamine (zpool import -F, kirjutuskaitstud impordid ja zdb Ülevaatus).
• Synology Inc.: Synology Knowledge Center: kuidas ma saan kasutada arvutit andmete taastamiseks, kui Synology NAS-i talitlushäired (mdadm + LVM2 Paigaldamine).
• Riiklik Standardi- ja Tehnoloogiainstituut (NIST) (Ameerika Ühendriigid): Eriväljaanne 800-209: Salvestusinfrastruktuuri turvajuhised.