RAID 5, RAID 6 arba ZFS kelių diskų nukritimas: sudužusio Synology, QNAP arba TrueNAS masyvo atkūrimas nepažeidžiant lygybės¶

„Synology DiskStation“, „QNAP TS“ serijos, „TrueNAS“ serverio arba „Linux“ klausymas mdadm saugyklos serveris nuolat pypsi, kol pranešama apie Tomas nutrūko, Pablogėjęs / sugedęs baseinas arba Atjungti keli diskai yra didelė saugojimo padėtis. Kai vienas diskas iškrenta iš a RAID 5, Synology Hybrid RAID (SHR-1), arba ZFS RAIDZ1 baseinas, masyvas veikia be nulinio pertekliaus (degraded būseną), atkuriant trūkstamus blokus, lygiagrečiai nuskaitant kiekvieną likusį diską. Jei po kelių valandų antrasis diskas nutrūksta neprisijungus arba rodoma neatkuriama skaitymo klaida (URE). Panikuoti administratoriai dažnai sunaikina terabaitus atkuriamų duomenų per kitas šešiasdešimt sekundžių spustelėdami Inicijuoti ir iš naujo sukuria masyvą su mdadm --create, arba priversti nedelsiant atkurti sugedusią aparatinę įrangą internetu. Jei mirė pati aparatinės įrangos RAID valdiklio kortelė, o ne diskai, pereikite prie RAID valdiklio kortelės mirtis, užsienio konfigūracijos importas ir kodėl niekada neturite inicijuoti diskų; jei atskiras standusis diskas spustelėja arba atsisako pasukti, pasitarkite kietojo disko gedimas ir duomenų atkūrimas arba NAS RAID masyvas sugadintas, kelių diskų gedimas ir ZFS/Btrfs atkūrimas. Jei dėl šio saugojimo gedimo ligoninės medicininis vaizdas išjungiamas (PACS), skubios pagalbos išsiuntimas arba gyvybės saugos infrastruktūra, skambinkite vietiniu pagalbos numeriu (911 JAV ir Kanadoje, 112 visoje Europos Sąjungoje, 999 Jungtinėje Karalystėje) arba patikrinkite mūsų katalogą pagalbos numeriai.

Padarykite tai dabar¶

1. ** SUSTABDYKITE ir NESPUSTELKITE „Inicijuoti“, „Sukurti baseiną“, „Taisyti“ arba paleisti mdadm --create išmestuose diskuose**: „Synology DSM“ arba „QNAP QTS“ spustelėjimas „Inicijuoti“ arba paleidimas mdadm --create Linux sistemoje rašo visiškai naujus superblokus ir pradeda nulinti pariteto juostas visuose narių diskuose. Nukritęs diskas paprastai vis dar išlieka 99.99% jūsų failai nepažeisti, tik įvykių skaitiklis pažymėjo, kad jie nesinchronizuojami.
2. Švariai išjunkite NAS arba serverį (arba ištraukite maitinimą, jei jis aktyviai atkuria spustelėjusius diskus), kad sustabdytumėte įvykių skaitiklius: kiekvieną sekundę masyvas lieka prisijungęs iš dalies pablogėjusios būsenos, operacinė sistema padidina superbloką. Update Time ir Events skaitiklis ant išlikusių diskų, o iškritęs diskas lieka užšaldytas pagal senesnį įvykio numerį. Jei NAS bando automatiškai atkurti diską su blogais sektoriais, toliau skaitydami, kad diskas gali nuimti magnetinės plokštelės dangą (head crash).
3. ** Pažymėkite kiekvieną disko skyriaus angą fiziniu žymekliu arba juostele (Bay 1, Bay 2, Bay 3, Bay 4) prieš išstumdami bet kurį dėklą**: kai naudojate „Linux“. mdadm, LVM2, ir ZFS Sekite disko tvarką pagal UUID kiekvieno skaidinio superbloko viduje, senesnius aparatūros valdiklius ir vadovą dmsetup lentelės rekonstrukcijoms reikalinga tiksli fizinė lizdų tvarka (0, 1, 2, 3...).
4. Niekada nebandykite atkurti, surinkti jėga ar fsck tiesiai ant originalių narių diskų; klonuokite kiekvieną diską bitais po bitų naudodami ddrescue pirma: prieš bėgiojant mdadm --assemble --force arba zpool import -F, prijunkite kiekvieną nario diską prie Linux darbo stoties per tiesioginį SATA/SAS (jokiu būdu nėra pigaus USB tilto, kuris slepiasi SMART arba SCT ERC timeouts) ir klonuokite jį naudodami ddrescue į sveikus atsarginius diskus arba vaizdo failus.
5. ** Priverstinai surinkite klonuotą masyvą griežtai tik SKAITYMO režimu (--readonly arba -o readonly=on)**: Surenkant mdadm masyvai, kurių įvykių skaitikliai nukrypo vienas nuo kito vienu metu nukritus keliems diskams, visada praeina --readonly (mdadm --assemble --force --readonly /dev/md0 ...). Tik skaitymo režimu taip pat mdadm, LVM2, ext4, Btrfs, nei ZFS gali perrašyti pariteto juosteles arba atkurti destruktyvų žurnalą.
6. Svarbiausius duomenis nukopijuokite į nepriklausomą išorinį atsarginį diską iškart po to, kai jie yra tik skaitomi: pirmiausia išvalykite dokumentus, duomenų bazes, virtualias mašinas ir nuotraukas į atskirą diską, tada nuvalykite ir patikrinkite diskus nuo nulio.

Sprendimų medis: kelių diskų RAID ir ZFS baseino avarinis skirstymas¶

Naudokite šią schemą norėdami nustatyti, ar jūsų masyvas patyrė loginio skirtojo laiko sumažėjimą (TLER / ERC neatitikimas), tikras kelių diskų blogo sektoriaus gedimas atkūrimo metu arba ZFS operacijų grupė (TXG) gedimas:

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS baseinas sudužo po to, kai iškrito 2 ir daugiau diskų"] --> StopIO["Nedelsdami SUSTABDYKITE visus perstatymus ir išjunkite NAS"]
    StopIO --> Label["Pažymėkite kiekvieną disko dėklą pagal skyriaus numerį (nuo 1 iki N)"]
    Label --> ConnectLinux["Prijunkite narių diskus prie Ubuntu Linux Rescue Host per tiesioginį SATA / HBA"]

    ConnectLinux --> CheckSmart["Tikrinti SMART ir metaduomenis, tik skaitoma: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Ar dmesg diskai spustelėja, atsisako suktis arba išjungiami neprisijungę?"}

    PhysicalHealth -->|"Taip: mechaninis / galvos gedimas 2 ir daugiau diskų RAID 5"| Cleanroom["STOP maitinti diskus -> Siųsti į Cleanroom Data Recovery Lab"]
    PhysicalHealth -->|"Ne: visi diskai sukasi (gali turėti laukiančių blogų sektorių arba gali sumažėti skirtasis laikas)"| CloneAll["Klonuoti kiekvieną nario diską naudojant GNU ddrescue (pereiti pirmyn -> atgalinis įbrėžimas)"]

    CloneAll --> DisconnectOrig["Atjunkite originalius diskus ir griežtai dirbkite su klonuotais diskais / vaizdais"]
    DisconnectOrig --> ArrayType{"Kokia saugojimo architektūra naudojama?"}

    ArrayType -->|"Synology DSM (SHR / klasikinis RAID)"| SynologyFlow["Patikrinkite įvykius per mdadm --examine -> Force-Assemble Read-Only -> Active LVM2 / Btrfs Read-Only"]
    ArrayType -->|"QNAP QTS (HAL LVM plonas / storas RAID)"| QnapFlow["Surinkite mdadm tik skaitymą -> Aktyvuokite DRBD sluoksnį, jei yra -> Nuskaitykite pasirinktinius QNAP LVM2 superblokus"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / veidrodinis)"| ZfsFlow["Vykdykite zpool import -d /dev/disk/by-id -> Import-Only Read-only with Rollback: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Standartinis Linux mdadm"| LinuxFlow["Palyginti įvykių skaitiklius -> Vykdyti mdadm --assemble --force --readonly -> Prijunkite failų sistemą su -o ro,noload"]

1 etapas: kodėl priverstinis atstatymas sunaikina duomenis (URE ir tos pačios partijos kaskada)¶

Kad suprastumėte, kodėl spustelėjus Taisyti / Atstatyti arba pakeitus vieną diską ir laukiant 36 valandas, dažnai sugenda visas masyvas, turite suprasti, kaip pariteto atkūrimas veikia senstančią magnetinę laikmeną ir kodėl vartotojų stalinių kompiuterių diskai iškrenta iš NAS korpusų.

1. Neatkurtų skaitymo klaidų matematinė tikrovė (UREs) RAID 5 arba RAIDZ1 atkūrimo metu¶

4 pavaroje RAID 5 arba ZFS RAIDZ1 baseinas, duomenų ir pariteto blokai (P) yra dryžuoti visuose keturiuose diskuose naudojant išskirtinį ARBA (XOR) skaičiavimas (D1 XOR D2 XOR D3 = P). Jei Drive 2 visiškai išnyksta, masyve nebeliks nulio dubliavimo. Norėdami iš naujo sukurti Diską 2 į visiškai naują pakaitinį diską, NAS turi vienu metu nuskaityti kiekvieną sektorių nuo 0 baito iki disko pabaigos 1 diske, Drive 3 ir Drive 4 vienu metu (Reconstructed D2 = D1 XOR D3 XOR P).

Apsvarstykite, kas atsitiks, kai tie diskai yra keturi 12 terabaitų (12 000 gigabaitų) standieji diskai, įsigyti iš tos pačios gamybos partijos prieš ketverius metus: - Norint atkurti 12 terabaitų, reikia skaityti 36 terabytes (2.88 x 1014 atskirus bitus) nepertraukiamai per 24-48 valandas esant didžiausiai šiluminei ir mechaninei apkrovai. - Vartotojų kietuosiuose diskuose paprastai yra neatkuriama skaitymo klaida (URE) specifikacija 1 error in 1014 bits (12.5 terabytes), o senstantys diskai sukuria tylias latentinio sektoriaus klaidas (Current_Pending_Sector) šaltose disko vietose, kurios nebuvo skaitomos daugelį metų. - Tą akimirką, kai Drive 3 pasiekia vieną neįskaitomą 4 kilobaitų (0,004 megabaito) blogą sektorių, o Drive 2 vis dar trūksta arba pusiau atkurtas, XOR lygtis turi du nežinomuosius (D2 ir D3).

2. Kodėl darbalaukio diskai be TLER / SCT ERC visiškai išmestas per 1 blogą sektorių¶

Štai spąstai, dėl kurių „Synology“, „QNAP“ ir „Linux“ nustoja veikti keli įrenginiai 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.                 |
+-------------------------------------------------------------------------+

Atkreipkite dėmesį, kas iš tikrųjų atsitiko: ** 3 diskas neveikia**. Turi 99.999999% sveiki sektoriai ir tik 1 arba 2 neįskaitomi 4 kilobaitų sektoriai (8 kilobytes iš 12 terabytes). Vis dėlto todėl mdadm išmetė 3 diską iš masyvo dėl 30 sekundžių komandos skirtojo laiko, visas garsas rodomas kaip Uždužo. Jei klonuosite Drive 3 su ddrescue (kuris grakščiai praleidžia 8 kilobaitus blogų sektorių ir nukopijuoja kitus 12 terabaitų) ir priverstinai surenkate tik skaitymo masyvą, atkursite beveik 100 procentų savo failų.

3. Kodėl NIEKADA neturėtumėte bėgti mdadm --create arba spustelėkite "Inicijuoti"¶

Kai masyvas sugenda, internete sklando du destruktyvūs mitai: - 1 mitas: „Iš naujo sukurkite masyvą ta pačia disko tvarka, naudodami mdadm --create Net su --assume-clean, modernios versijos mdadm numatytasis kitoks Data Offset vertės priklausomai nuo branduolio ir mdadm paleisti (2048 sectors prieš 262144 sectors). Kada mdadm --create rašo naują versiją 1.2 superblokas su netinkamu poslinkiu arba nesutampančiu gabalo dydžiu, jis perrašo LVM2 fizinio tūrio antraštė arba ext4 superblokas tomo priekyje. - 2 mitas: „Ištraukite antrą ką tik nukritusį diską, vėl prijunkite jį ir spustelėkite Taisyti“. Jei Drive 1 iškrito prieš tris dienas (todėl jo duomenys paseno 3 dienas) ir Drive 3 iškrito prieš 10 minučių (todėl jo duomenys yra dabartiniai), ištraukus ir iš naujo įdėjus netinkamą diską arba privertus perdaryti Drive 1 pažymėtą "aktyvus" ir Drive 3 pažymėtą "atsarginis masyvas" perkeliama . 3 dienų senumo pasenusios pariteto juostos, sugadinančios kiekvieną katalogą ir failą, pakeistą per paskutines 72 valandas.

2 etapas: Superblokų tikrinimas ir Event saugiai skaito Linux gelbėjimo pagrindiniame kompiuteryje¶

Norėdami saugiai išgelbėti sudužusį „Synology“, QNAP, „TrueNAS“ ar „Linux“ masyvą, pašalinkite visus narių diskus (pažymėję jų skyriaus numerius) ir prijunkite juos prie stalinio kompiuterio arba serverio, kuriame veikia Ubuntu 22.04 LTS / 24.04 LTS (net paleidžiant iš tiesioginės USB atmintinės).

1 veiksmas: įdiekite teismo medicinos gelbėjimo įrankių rinkinį Ubuntu¶

Atidarykite Ubuntu gelbėjimo mašinos terminalą ir įdiekite reikiamas priemones:

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

2 veiksmas: susiekite kiekvieną disko raidę, serijos numerį ir skaidinio išdėstymą¶

Išvardykite visus prijungtus blokinius įrenginius ir jų aparatinės įrangos serijos numerius, kad niekada nepainiotumėte gelbėjimo disko su šaltinio NAS disku:

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

Pažiūrėkite į tipinio Synology DSM, QNAP arba TrueNAS disko skaidinių lentelę:

3 veiksmas: patikrinkite mdadm --examine norėdami sužinoti, kodėl masyvas sudužo („The Event Counter Matrix“)¶

„Synology“, „QNAP“ arba „Linux“. mdadm masyvą, patikrinkite RAID metaduomenis vartotojo duomenų skaidiniuose (pvz., 3 skaidinyje /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) nieko nemontuojant ir nekeičiant:

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

Palyginkite visų keturių diskų išvestį:

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

Atidžiai perskaitykite šią teismo ekspertizę: 1. /dev/sdc3 (Device Role 1) turi Events skaičius 479012 nuo prieš dvi dienas (Oct 29). Šis diskas pirmą kartą iškrito prieš dvi dienas ir nuo to laiko buvo neprisijungęs. 2. /dev/sdb3 (Role 0) ir /dev/sde3 (Role 3) abu turi Events : 482190 adresu 14:12:09. 3. /dev/sdd3 (Role 2) turi Events : 482188 adresu 14:12:04, tik 5 sekundės ir 2 įvykiai atsilieka sdb3 ir sde3. 4. Išvada: turite atkurti masyvą naudodami sdb3 (Role 0), sdd3 (Role 2), ir sde3 (Role 3) (kurio įvykių skaitiklius skiria tik 2 varnelės), o išeina sdc3 (Role 1) visiškai išeina.

3 etapas: kiekvieno disko klonavimas GNU ddrescue¶

Prieš bėgimą mdadm --assemble --force arba zpool import -F, klonuokite kiekvieną reikalingą diską (ypač diską, kuris iškrito paskutinis dėl blogų sektorių, pvz., /dev/sdd aukščiau pateiktame pavyzdyje) į sveiką tuščią tokios pat ar didesnės talpos diską arba į neapdorotą diską .img failą didelėje atminties talpoje.

1 veiksmas: kodėl ddrescue su mapfile yra privaloma¶

Standartinis dd nutraukiamas pirmame blogame sektoriuje arba su conv=noerror,sync sugaišta valandas šlifuodamas savo skaitymo galvutes per pažeistą takelį, tuo pačiu nepripildydamas megabaitų gretimų gerų duomenų. GNU ddrescue veikia intelektualiuose daugiapakopiuose leidimuose: 1. 1 leidimas (kopijavimo fazė): visu nuosekliu greičiu kopijuoja visas sveikas, greitai reaguojančias disko sritis (150 MB/s į 250 MB/s), nedelsdami peršokdami per visus lėtus ar neįskaitomus blokus, kad diskas neperkaistų ir neišnyktų, kol gausite 99.99% geri duomenys. 2. 2 eiga (kirpimo fazė): nuskaitoma iki tikslių kiekvieno blogo bloko kraštų tiek iš priekio, tiek iš galo (reverse direction), kad atskirti pažeistą sritį iki tiksliai 4 kilobaitų aparatinės įrangos sektoriaus. 3. ** 3 veiksmingumas (nubraukimo fazė)**: švelniai iš naujo bando pažeistus sektorius, be reikalo nenustatant magistralės iš naujo.

2 veiksmas: paleiskite 2 etapus ddrescue klono komanda¶

Visada nurodykite žemėlapio failą (sdd_rescue.map). Jei mirštančio šaltinio pavara atsijungia ir jam reikia maitinimo ciklo, ddrescue nuskaito žemėlapio failą ir tęsia nuo tikslaus baito, nuo kurio jis buvo baigtas, neperskaitydamas nė vieno jau nukopijuoto sektoriaus:

# 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 etapas: Synology DSM atkūrimas (SHR-1 / SHR-2 / Classic RAID), QNAP ir Linux mdadm¶

Kai klonuoti diskai (arba tik skaitymo ciklo įrenginiai) bus paruošti ir originalūs NAS diskai bus saugiai atjungti, laikykitės tikslios jūsų platformos neardomosios surinkimo sekos.

A scenarijus: standartinis „Linux“. mdadm arba Synology Classic RAID (RAID 5 / RAID 6)¶

1. Sustabdykite bet kokią dalinę md masyvas, kurį Ubuntu galėjo paleisti:

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

2. Priverstinai surinkite klonuotus skaidinius (sdb3, sdd3, sde3, praleidžiant seniai mirusius sdc3) tik skaitymo režimu:

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

   Stebėkite išvestį: mdadm praneš forcing event count in /dev/sdd3(2) from 482188 up to 482190 ir mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Patikrinkite, ar masyvas aktyvus ir pažymėtas (auto-read-only) arba (read-only):

   cat /proc/mdstat
   

B scenarijus: „Synology Hybrid RAID“ (SHR-1 ir SHR-2) su LVM2 ir Btrfs / ext4¶

Synology's SHR (Synology Hybrid RAID) yra 100 procentų standartinis „Linux“ mdadm + LVM2 (Logical Volume Manager): - Kai visi SHR telkinio diskai yra vienodo dydžio (pavyzdžiui, keturi 8 terabaitų diskai), „Synology“ sukuria vieną mdadm RAID 5 skaidinys (md2 kiekvieno disko 3 skirsnyje) ir įdeda an LVM2 tūrio grupė (vg1000 arba vg1) viršuje md2. - Kai SHR telkinyje esantys diskai yra įvairaus dydžio (pavyzdžiui, du 8 terabaitų diskai ir du 16 terabaitų diskai), „Synology“ sukuria du atskirus mdadm masyvai: md2 per 5 skaidinį (8 TB supjaustykite visuose 4 RAID 5 diskuose) ir md3 per 6 skaidinį (likusieji 8 TB supjaustykite du 16 TB diskus RAID 1), tada prisijungia md2 + md3 į singlą LVM2 Apimties grupė (vg1000).

Sumontuoti tik skaitomą Synology SHR tomą Ubuntu po priverstinio surinkimo /dev/md2 (ir /dev/md3 jei mišraus dydžio SHR): 1. Ieškoti Synology LVM2 fizinių tūrių ir tūrių grupių:

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

C scenarijus: „Synology DSM 7+“ tomo šifravimas arba bendrinamo aplanko šifravimas (eCryptfs)¶

• Bendrinamo aplanko šifravimas (@sharename@ aplankus, kuriuose yra ECRYPTFS_FNEK_ENCRYPTED... failų pavadinimai): Nukopijuokite visą @encrypted_share@ aplankas išjungtas /mnt/synology_rescue pirma, tada prijunkite ir iššifruokite jį Ubuntu naudodami savo Synology šifravimo slaptažodį arba .key failas:

  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+ viso tomo šifravimas (LUKS): Jeigu /dev/vg1000/lv rodo TYPE="crypto_LUKS" in blkid, atrakinkite jį tik skaitymui naudodami .rkey Atkūrimo rakto failas, atsisiųstas kuriant tomą:

  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
  

D scenarijus: QNAP QTS (LVM2 Thin Provisioning ir DRBD sluoksnis)¶

Šiuolaikiniai QNAP NAS įrenginiai (QTS 4.3+ / 5.x) įterpkite vidinį vieną mazgą DRBD prietaisas (/dev/drbd1) tarp /dev/md1 ir LVM2 Apimties grupė (vg1). 1. Pirmiausia priverstinai surinkite QNAP duomenų skaidinius (/dev/sd[b-e]3) tik skaityti į /dev/md1:

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

5 etapas: „TrueNAS“ ir „Linux“ gelbėjimas ZFS baseinai (RAIDZ1, RAIDZ2, RAIDZ3)¶

Jei jūsų saugyklos serveryje veikia TrueNAS CORE, TrueNAS SCALE, Proxmox VE arba Ubuntu ZFS, atkūrimas nenaudoja mdadm. Vietoj to, ZFS sujungia apimties tvarkyklę ir kopijavimą rašant (CoW) failų sistemą į vieną operacijų architektūrą, sukurtą aplink Uberblokus ir nuoseklias operacijų grupes (TXGs).

1 veiksmas: patikrinkite 4 ZFS vdev etiketes (L0, L1, L2, L3) kiekviename klonuotame diske¶

Kiekviename ZFS nario skaidinyje saugomos keturios identiškos telkinio konfigūracijos kopijos ir paskutinių 128 Uberblokų masyvas (dvi etiketės skaidinio priekyje, L0 ir L1ir dvi etiketės pačioje pabaigoje, L2 ir L3). Bėk zdb -l kiekviename klonuotame skaidinyje, kad patikrintumėte telkinio būseną ir didžiausią įsipareigojimų grupę (txg):

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

Palyginkite txg: numeriai visuose klonuotuose diskuose. Tiesiog kaip mdadm's Events skaitiklis, jei vienas diskas iškrito likus 5 minutėms iki maitinimo praradimo arba antro disko nukritimo, jo txg bus šiek tiek mažesnis nei likę diskai.

2 veiksmas: importuokite ZFS telkinį tik skaitymo režimu (-o readonly=on)¶

Pirmiausia patikrinkite importuojamus baseinus nieko nemontuodami sudo zpool import -d /dev/disk/by-id. Niekada neimportuokite sugadinto arba iškritusio kelių diskų ZFS telkinio skaitymo ir rašymo režimu. Kai importuojama su -o readonly=on, ZFS nebando inicijuoti resilver, nerašo naujų Uberblokų ir negali panikuoti branduolio, jei sugadintas erdvės žemėlapis (spacemap) aptinkama rašymo paskirstymo metu:

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

3 veiksmas: jei zpool import nepavyksta su I/O error arba corrupted data, naudokite TXG Rollback (-F ir -T)¶

Jei du diskai iškrito per kelias sekundes vienas nuo kito intensyvaus rašymo serijos metu, pati naujausia operacijų grupė (TXG N) gali būti neišsamios išlikusiose pariteto juostose, o TXG N-1 arba TXG N-2 (parašyta 5-15 sekundžių anksčiau) yra 100 procentų nepažeista Uberblock žiedo buferyje.

1. Išbandykite neardomąją sausosios eigos atšaukimo peržiūrą (-F -n):

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

   Jei ZFS praneša Would be able to return pool to its state as of <timestamp>, paleiskite tik skaitymo atšaukimo importavimą be -n:

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

2. Jei -F vis dar negali prijungti naujausių Uberblocks, surašykite istorinius Uberblock TXG numerius zdb ir importuoti konkretų senesnį TXG (-T):

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

   Pasirinkite a txg skaičius nuo 30 iki 60 sekundžių iki avarijos (pvz., txg = 9481020) ir importuoti tuo metu įšaldytą telkinį tik skaitymo režimu:

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

6 etapas: patikrinimas po atkūrimo ir būsimų atstatymo kaskadų prevencija¶

Kai nukopijuosite 100 procentų atkurtų duomenų iš /mnt/synology_rescue arba /mnt/zfs_rescue prie nepriklausomo atsarginės kopijos tikslo, vadovaukitės šiuo aparatūros ir konfigūracijos kontroliniu sąrašu prieš vėl pradėdami naudoti NAS:

• Niekada nepirkite visų NAS diskų iš to paties mažmenininko tą pačią dieną: tos pačios gamybos partijos diskai turi identišką pagrindinę partiją ir programinę-aparatinę įrangą, todėl atkūrimo metu jie sugenda per kelias valandas vienas nuo kito. Sumaišykite partijas arba gamintojus (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• Naudokite tik NAS/Enterprise diskus su TLER / SCT ERC įjungtas (arba pakelkite Linux mdadm Stalinio kompiuterio diskų SCSI skirtasis laikas): vartotojų diskams sistemoje „Linux“. mdadm, naudokite a udev taisyklė kelti /sys/block/sdX/device/timeout iš 30 sekundžių iki 180 sekundžių taip mdadm laukia vidinio sektoriaus pertvarkymo, o ne išmes diską.
• Perkelti masyvus, kurių diskai yra didesni nei 8 TB iš RAID 5 / SHR-1 / RAIDZ1 į RAID 6 / SHR-2 / RAIDZ2: su 12 TB į 24 TB diskai, vieno pariteto atkūrimo laikas viršija 30 valandų, todėl dvigubas paritetas (RAID 6 / SHR-2 / RAIDZ2) svarbu išgyventi blogą sektorių pasidabruojant.
• ** Tvarkaraštis kas mėnesį Data Scrubbing (mdadm check / zpool scrub) ir pratęstas SMART testai**: mėnesinis šveitimas pataiso latentinės sektoriaus klaidas (Current_Pending_Sector), kol visi diskai yra prisijungę.
• Atminkite, kad RAID yra aukšto pasiekiamumo, niekada nenaudokite atsarginės kopijos: vadovaukitės 3-2-1 atsarginė strategija su neprisijungusia kopija.

Regioniniai pagalbos numeriai ir agentūrų protokolai¶

Saugojimo nutraukimas, turintis įtakos sveikatos priežiūros tinklams, skubios pagalbos ryšiams arba įstatymų numatytiems asmeniniams įrašams, turi būti nedelsiant padidintas:

• Jungtinės Valstijos ir Kanada: surinkite 911 jei dėl saugyklos gedimo išjungiamos ligoninės klinikinės sistemos (EHR / PACS) arba išsiuntimas. Pranešti apie į NAS nukreiptą išpirkos programą (DeadBolt, LockBit, Akira) į CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov) arba Kanados kibernetinio saugumo centras (1-833-CYBER-88).
• Jungtinė Karalystė: surinkite 999 ekstremalioms situacijoms, turinčioms įtakos gyvybės saugumui arba ūmiai NHS priežiūrai. Pagal JK GDPR įvertinkite, ar dėl nuolatinio asmens duomenų praradimo be atsarginių kopijų reikia pranešti ICO (0303 123 1113) per 72 valandas.
• Europos Sąjunga: surinkite 112 visoje ES. Subjektai, kuriems taikoma NIS2 direktyva, turi pranešti apie didelius veiklos sutrikimus savo nacionalinei CSIRT per 24 valandas, o nuolatinis asmens duomenų prieinamumo praradimas sukelia BDAR 33 straipsnio ataskaitas per 72 valandas.
• Australija ir Naujoji Zelandija: surinkite 000 Australijoje arba 111 Naujojoje Zelandijoje; pranešti apie infrastruktūros ar išpirkos reikalaujančių NAS incidentų ACSC (1300 CYBER1) arba CERT NZ (0800 237 869).
• Indija ir Azijos-Ramiojo vandenyno regionas: surinkite 112 Indijoje reaguoti į ekstremalias situacijas; pranešti apie infrastruktūros saugojimo incidentus CERT-In (incident@cert-in.org.in) per privalomą 6 valandų laikotarpį.

Dažnai užduodami klausimai¶

Kodėl padarė mdadm --assemble --force atsisakyti paleisti mano RAID 5 masyvą not enough to start the array?¶

4 pavaroje RAID 5 masyvas, bent jau 3 iš 4 važiavimų turi būti perduotas mdadm --assemble --force. Bėk sudo mdadm --examine /dev/sd[a-z]3 Norėdami patikrinti, kodėl trečiasis diskas buvo atmestas: arba perdavėte visą diską, o ne skaidinį (/dev/sdd vietoj /dev/sdd3), jo superblokas buvo pažymėtas kaip a Atsarginis dėl pertraukto atkūrimo arba Ubuntu automatinis surinkėjas užrakino vieną diską į neaktyvų /dev/md127 įrenginys (paleisti sudo mdadm --stop --scan pirma, tada paleiskite dar kartą mdadm --assemble --force --readonly).

Ką daryti, jei diskas pradedamas atstatyti (Recovery = 12%) kol iškrito antrasis važiavimas?¶

Jei 2 diskas mirė, įdėjote pakaitinį 2 diską ir 12 % atkūrimo eiga 3 diskas buvo atjungtas dėl blogo sektoriaus, nenaudokite 12 % atkurto pakaitinio 2 disko. Vietoj to, klonuokite originalą Vairuoti 3 su drescue. Kadangi 3 diskas buvo visiškai dabartinis iki tol, kol atkūrimas sustojo ties 12%, surenkant masyvą tik skaitymui naudojant 1 diską, drescue 3 disko klonas, o 4 diskas (nepaliekant 2 disko) suteikia jums nuoseklų masyvą.

Ar galiu įdėti savo Synology arba QNAP diskus į visiškai naują NAS važiuoklę, jei NAS maitinimo šaltinis arba plokštė sugedo?¶

Taip, abi Synology (HDD perkėlimas) ir QNAP (Tiesioginė NAS migracija) išsaugokite RAID konfigūraciją pačiuose diskuose. Tačiau jei du ar daugiau diskų jau buvo išjungti (`Volume Crashed`), kol važiuoklė sugedo, neįkraukite jų naujoje NAS važiuoklėje, nes perkėlimo vedlys gali perrašyti skaidinius arba suaktyvinti destruktyvų atkūrimą. Pirmiausia išsaugokite tik skaitomus duomenis Ubuntu.

Kaip sužinoti, ar iškritusį diską saugu klonuoti ddrescue prieš tai, kad reikia švarios patalpos laboratorijos?¶

Prijunkite diską prie SATA, įjunkite jį ir klausykitės 10 sekundžių žiūrėdami sudo dmesg -w. Jei diskas skleidžia ritmiškus spragtelėjimus, braukimą ar zvimbimą, sukasi aukštyn ir atgal arba praneša talpą kaip 0 B / 4,1 GB in lsblk, skaitymo / rašymo galvutės sugedo fiziškai: nedelsdami atjunkite maitinimą ir naudokite švarios patalpos laboratoriją. Jei diskas sukasi sklandžiai, rodomas visas jo pajėgumas lsblk, ir tik rąstai Dabartinis_Laukiamas_Sektorius arba skirtojo laiko klaidas, klonuokite jį naudodami drescue.

Kas yra „RAID 5 rašymo anga“ ir kaip ji veikia ZFS arba Btrfs to išvengti dingus elektrai?¶

Tradiciškai RAID 5 / RAID 6 be žurnalo, norint atnaujinti juostelę, duomenų bloką ir pariteto bloką reikia įrašyti į du diskus vienu metu. Jei maitinimas nutrūksta rašymo viduryje, duomenys ir paritetas nebeatitinka ( Rašykite skylę). ZFS (`RAIDZ`) ir Btrfs pašalinkite rašymo angą naudodami funkciją Kopijuoti rašant (`CoW`), kiekvieną naują juostelę įrašydami į nenaudojamus blokus ir atnaujindami Uberblock / šakninį žymeklį tik tada, kai visa juostelė bus diske.

Ar galiu naudoti dmsetup perdangas, kad išbandytų RAID parametrus nekeičiant klonuotų diskų?¶

Taip, galite sukurti kopijavimą rašant (`CoW`) perdangos tik skaitomų kilpos įrenginių viršuje (`losetup --read-only`) naudojant Linux dmsetup (`snapshot` tikslas), paremtas retais failais /tmp. Bet koks rašo iš mdadm --assemble --force arba fsck -y eik į vienkartinį /tmp perdangos failą, leisdami iš naujo nustatyti per 1 sekundę, jei reikia.

Susiję vadovai¶

• NAS RAID masyvas sugadintas, kelių diskų gedimas ir ZFS/Btrfs atkūrimas
• RAID valdiklio kortelės mirtis, užsienio konfigūracijos importas ir kodėl niekada neturite inicijuoti diskų
• Kietojo disko gedimas ir duomenų atkūrimas
• SSD ir NVMe staigus tik skaitymo režimas, 0% atsarginių blokų ir TRIM išjungiantis gelbėjimas
• Atsitiktinis „rm -rf“ arba „Shift+Delete“ sistemoje „Linux“, „MacOS“ arba „Windows“: iš karto tik skaitomas pakartotinis prijungimas
• Kompiuterių atsarginės kopijos, 3-2-1 strategija ir atkūrimas po nelaimių
• Pagalbos numeriai pagal šalį

Šaltiniai ir oficialios rekomendacijos¶

• Linux Raid Wiki (raid.wiki.kernel.org) ir Linux branduolio organizacija: * Nepavykusio programinės įrangos RAID atkūrimas (mdadm --assemble --force --readonly ir įvykių skaitiklių neatitikimai)*.
• Laisvos programinės įrangos fondas (GNU Project): GNU ddrescue Vadovas: teismo ekspertizės duomenų atkūrimas iš sugedusios laikmenos.
• OpenZFS dokumentacija (openzfs.github.io): ZFS baseino importo atkūrimas (zpool import -F, Tik skaitomas importavimas ir zdb Apžiūra).
• „Synology Inc.“: Synology žinių centras: kaip galiu naudoti kompiuterį duomenims atkurti, kai sugenda „Synology NAS“ (mdadm + LVM2 Montavimas).
• Nacionalinis standartų ir technologijos institutas (NIST) (Jungtinės Amerikos Valstijos): Specialusis leidinys 800-209: saugojimo infrastruktūros saugos gairės.