RAID 5, RAID 6 ili ZFS Multiple Drive Drop: Oporavak srušene Synology, QNAP ili TrueNAS niza bez uništavanja pariteta¶

Slušanje Synology DiskStation, QNAP TS serije, TrueNAS servera ili Linuxa mdadm server za skladištenje neprekidno pišti dok se javlja Srušeni volumen, Pool degradiran / neispravan ili Multiple Drives Disconnected je hitna situacija za skladištenje sa visokim ulozima. Kada jedan disk ispadne iz a RAID 5, Synology Hybrid RAID (SHR-1), ili ZFS RAIDZ1 pool, niz radi sa nultom redundantnošću (degraded stanje), rekonstruišući blokove koji nedostaju u hodu čitajući svaki preostali disk paralelno. Ako drugi disk ispadne van mreže satima kasnije ili prikaže nepopravljivu grešku čitanja (URE) na pola puta kroz ponovnu izgradnju na zamjenski disk, matematika pariteta se kvari i spremište za pohranu potpuno se isključuje. Uspaničeni administratori često uništavaju terabajte podataka koji se mogu oporaviti u narednih šezdeset sekundi klikom na Inicijaliziraj, ponovo kreirajući niz sa mdadm --create, ili prisiljavanje trenutne online ponovne izgradnje na neispravnom hardveru. Ako je vaša hardverska kartica RAID kontrolera umrla, a ne diskovi, prebacite se na Smrt kartice RAID kontrolera, uvoz stranih konfiguracija i zašto nikada ne smijete inicijalizirati diskove; ako pojedinačni čvrsti disk klikće ili odbija da se okrene, obratite se kvar tvrdog diska i oporavak podataka ili NAS RAID niz degradiran, višestruki disk neuspjeh i ZFS/Btrfs oporavak. Ako ova greška u pohranjivanju onemogući bolničko medicinsko snimanje (PACS), dispečer u hitnim slučajevima ili infrastrukturu za životnu sigurnost, pozovite svoj lokalni broj hitne pomoći (911 u Sjedinjenim Državama i Kanadi, 112 širom Evropske unije, 999 u Ujedinjenom Kraljevstvu) ili provjerite naš imenik brojevi za hitne slučajeve.

Uradi ovo sada¶

1. ZASTANITE i NEMOJTE kliknuti na "Inicijaliziraj", "Kreiraj bazen", "Popravi" ili pokreni mdadm --create na ispuštenim diskovima: Klikom na Initialize u Synology DSM ili QNAP QTS, ili pokretanje mdadm --create u Linuxu, piše potpuno nove superblokove i počinje nuliranje pruga pariteta na svim diskovima članova. Ispušteni pogon obično još uvijek stoji 99.99% Vaših fajlova netaknutih, samo označenih kao nesinhronizovani od strane brojača događaja.
2. Čisto isključite NAS ili server (ili povucite napajanje ako se aktivno obnavlja između diskova koji klikću) da biste zamrznuli brojače događaja: Svake sekunde niz ostaje na mreži u djelimično degradiranom stanju, operativni sistem povećava superblok Update Time i Events brojač na preživjelim diskovima dok ispušteni disk ostaje zamrznut na starijem broju događaja. Ako NAS pokušava automatizirano rekonstruirati disk sa lošim sektorima, nastavak čitanja tog diska može ukloniti premaz magnetne ploče (head crash).
3. Označite svaki slot ležišta disk jedinice fizičkim markerom ili trakom (Bay 1, Bay 2, Bay 3, Bay 4) prije izvlačenja bilo koje ladice: Dok je Linux mdadm, LVM2, i ZFS prati redosled pogona po UUID-u unutar svakog superbloka particije, starijih hardverskih kontrolera i priručnika dmsetup rekonstrukcije tablice zahtijevaju tačan fizički redosljed mjesta (0, 1, 2, 3...).
4. Nikada ne pokušavajte oporavak, nasilno sastavljanje ili fsck direktno na originalne članske pogone; klonirajte svaki pogon bit za bit koristeći ddrescue prvi: Prije trčanja mdadm --assemble --force ili zpool import -F, priključite disk svakog člana na Linux radnu stanicu putem direktnog SATA/SAS (nikada jeftin USB most koji skriva SMART ili SCT ERC timeouts) i klonirajte ga sa ddrescue na zdrave rezervne diskove ili datoteke slika.
5. Prisilno sastavite klonirani niz striktno u načinu SAMO ČITANJE (--readonly ili -o readonly=on): Prilikom sklapanja mdadm nizovi čiji se brojači događaja odvajaju tokom istovremenog ispuštanja više diskova, uvijek prolaze --readonly (mdadm --assemble --force --readonly /dev/md0 ...). U načinu samo za čitanje, ni jedno ni drugo mdadm, LVM2, ext4, Btrfs, niti ZFS može prepisati paritetne trake ili ponovo reprodukovati destruktivni dnevnik.
6. Kopirajte svoje najkritičnije podatke na nezavisnu eksternu rezervnu disk jedinicu odmah nakon montiranja samo za čitanje: evakuirajte svoje dokumente, baze podataka, virtuelne mašine i fotografije prvo na zaseban disk, a zatim obrišite i testirajte diskove od nule.

Stablo odlučivanja: RAID sa više diskova i hitna trijaža ZFS bazena¶

Koristite ovaj dijagram toka da odredite da li je vaš niz pretrpio logički pad vremena (TLER / ERC neusklađenost), pravi greška lošeg sektora na više diskova tokom ponovne izgradnje ili ZFS transakcijska grupa (TXG) greška:

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS bazen se srušio nakon što su 2+ diskovi ispušteni"] --> StopIO["ZAUSTAVITE sve rekonstrukcije i odmah isključite NAS"]
    StopIO --> Label["Označite svaku ladicu pogona brojem ležišta (od 1 do ležišta N)"]
    Label --> ConnectLinux["Povežite članske diskove na Ubuntu Linux Rescue Host putem Direct SATA / HBA"]

    ConnectLinux --> CheckSmart["Pregledajte SMART i metapodatke samo za čitanje: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Da li neki diskovi klikaju, odbijaju da se okreću ili ispadaju van mreže u dmesg-u?"}

    PhysicalHealth -->|"Da: mehanička / greška glave na 2+ diska u RAID 5"| Cleanroom["STOP Powering Disks -> Pošalji u Cleanroom Data Recovery Lab"]
    PhysicalHealth -->|"Ne: svi diskovi se okreću (možda imaju neispravne sektore na čekanju ili istek vremena)"| CloneAll["Klonirajte pogon svakog člana koristeći GNU ddrescue (Prolaz naprijed -> Reverse Scrape)"]

    CloneAll --> DisconnectOrig["Isključite originalne diskove i radite striktno na kloniranim diskovima / slikama"]
    DisconnectOrig --> ArrayType{"Koja se arhitektura pohrane koristi?"}

    ArrayType -->|"Synology DSM (SHR / Classic RAID)"| SynologyFlow["Pregledajte događaje putem mdadm --examine -> Force-Assemble samo za čitanje -> Aktivirajte LVM2 / Btrfs samo za čitanje"]
    ArrayType -->|"QNAP QTS (HAL LVM Thin / Thick RAID)"| QnapFlow["Sastavite mdadm samo za čitanje -> Aktivirajte DRBD sloj ako postoji -> Skenirajte prilagođene QNAP LVM2 superblokove"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Mirror)"| ZfsFlow["Pokreni zpool import -d /dev/disk/by-id -> Import Read-Only s Rollback: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Standardni Linux mdadm"| LinuxFlow["Uporedite brojače događaja -> Pokreni mdadm --assemble --force --readonly -> Montiraj sistem datoteka sa -o ro,noload"]

Faza 1: Zašto prisilna rekonstrukcija uništava podatke (URE i Same-Batch Cascade)¶

Da biste razumjeli zašto klik na Popravi/Ponovo izgradi ili zamjena jednog diska i čekanje 36 sati često uzrokuje potpuni pad niza, morate razumjeti kako rekonstrukcija pariteta naglašava starenje magnetnih medija i zašto potrošački desktop diskovi ispadaju iz NAS kućišta.

1. Matematička stvarnost nepopravljivih grešaka čitanja (UREs) tokom rekonstrukcije RAID 5 ili RAIDZ1¶

U 4 pogona RAID 5 ili ZFS RAIDZ1 blokovi, podaci i paritetni blokovi (P) su prugaste na sva četiri diska koristeći Exclusive OR (XOR) obračun (D1 XOR D2 XOR D3 = P). Ako Disk 2 potpuno umre, niz ima nula preostale redundanse. Da bi ponovo izgradio Disk 2 na potpuno novi zamjenski disk, NAS mora čitati svaki pojedinačni sektor od bajta 0 do kraja diska na Disk 1, Disk 3 i Disk 4 istovremeno (Reconstructed D2 = D1 XOR D3 XOR P).

Razmislite šta se dešava kada su ti diskovi četiri čvrsta diska od 12 terabajta (12.000 gigabajta) kupljena iz iste proizvodne serije pre četiri godine: - Obnova 12 terabajta zahteva čitanje 36 terabytes (2.88 x 1014 pojedinačni bitovi) neprekidno tokom 24 do 48 sati pri maksimalnom termičkom i mehaničkom opterećenju. - Potrošački tvrdi diskovi obično nose nepopravljivu grešku čitanja (URE) specifikacija 1 error in 1014 bits (12.5 terabytes), a zastarjeli pogoni razvijaju tihe latentne sektorske greške (Current_Pending_Sector) u hladnim područjima diska koji nisu čitani godinama. - U trenutku kada Drive 3 udari u jedan nečitljiv loš sektor od 4 kilobajta (0,004 megabajta), dok Drive 2 još uvijek nedostaje ili je napola obnovljen, XOR jednačina ima dvije nepoznate (D2 i D3).

2. Zašto desktop diskovi bez TLER / SCT ERC biti potpuno izbačen preko 1 lošeg sektora¶

Evo zamke koja uzrokuje katastrofalne padove više diskova na Synology, QNAP i Linux 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.                 |
+-------------------------------------------------------------------------+

Obratite pažnju šta se zapravo dogodilo: Vozi 3 nije mrtav. Ima 99.999999% zdravi sektori i samo 1 ili 2 nečitljiva sektora od 4 kilobajta (8 kilobytes out of 12 terabytes). Ipak zato mdadm izbacio Drive 3 iz niza zbog isteka komande od 30 sekundi, ceo volumen se prikazuje kao Srušen. Ako klonirate Drive 3 sa ddrescue (koji elegantno preskače 8 kilobajta loših sektora i kopira ostalih 12 terabajta) i prisilno sastavite niz samo za čitanje, oporavljate gotovo 100 posto vaših datoteka.

3. Zašto NIKADA ne smijete trčati mdadm --create ili kliknite na "Inicijaliziraj"¶

Kada se niz sruši, dva destruktivna mita kruže online: - Mit 1: „Ponovo kreirajte niz sa potpuno istim redosledom pogona koristeći mdadm --create." Čak i sa --assume-clean, moderne verzije mdadm podrazumevano drugačije Data Offset vrijednosti u zavisnosti od kernela i mdadm osloboditi (2048 sectors vs 262144 sectors). Kada mdadm --create piše novu verziju 1.2 superblok na pogrešnom pomaku ili s neusklađenom veličinom komada, on prepisuje LVM2 zaglavlje fizičkog volumena ili ext4 superblok na prednjoj strani volumena. - Mit 2: "Izvucite drugi disk koji je upravo ispao, ponovo ga uključite i kliknite Popravi." Ako je Disk 1 ispao prije tri dana (tako da su njegovi podaci zastarjeli 3 dana) i Disk 3 je ispao prije 10 minuta (tako da su njegovi podaci aktuelni), povlačenje i ponovno umetanje pogrešnog diska ili prisilno rekonstruiranje s Disk 1 označenim kao "aktivan" i Disk 3 označenim "rezervni" uzrokuje da se NAS podiže over-ray 3 dana stare ustajale trake pariteta, oštećujući svaki direktorij i datoteku izmijenjenu u posljednja 72 sata.

Faza 2: Provjera superblokova i Event broji sigurno na Linux hostu za spašavanje¶

Da biste bezbedno spasili Synology, QNAP, TrueNAS ili Linux niz, uklonite sve članske diskove (nakon označavanja brojeva njihovih ležišta) i priključite ih na desktop računar ili server koji radi Ubuntu 22.04 LTS / 24.04 LTS (čak i pokrenuti sa Live USB sticka).

Korak 1: Instalirajte forenzički paket alata za spašavanje u Ubuntu¶

Otvorite terminal na vašoj Ubuntu mašini za spašavanje i instalirajte potrebne uslužne programe:

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

Korak 2: Mapirajte svako slovo pogona, serijski broj i izgled particije¶

Navedite sve povezane blok uređaje i njihove serijske brojeve hardvera kako nikada ne biste zamijenili disk za spašavanje s izvornim NAS diskom:

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

Pogledajte tabelu particija tipičnog Synology DSM, QNAP ili TrueNAS disk jedinice:

Korak 3: Provjerite mdadm --examine da vidite zašto se niz srušio (Matrica brojača događaja)¶

Na Synology, QNAP ili Linux mdadm niz, ispitajte RAID metapodatke na particijama korisničkih podataka (na primjer, particija 3 na /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) bez montiranja ili modifikacije bilo čega:

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

Uporedite izlaz na sva četiri pogona:

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

Pažljivo pročitajte ovu forenzičku priču: 1. /dev/sdc3 (Device Role 1) ima an Events count of 479012 od prije dva dana (Oct 29). Taj disk je prvi ispao prije dva dana i od tada je van mreže. 2. /dev/sdb3 (Role 0) i /dev/sde3 (Role 3) oba imaju Events : 482190 at 14:12:09. 3. /dev/sdd3 (Role 2) ima Events : 482188 at 14:12:04, samo 5 sekundi i 2 događaja iza sdb3 i sde3. 4. Zaključak: Morate rekonstruisati niz koristeći sdb3 (Role 0), sdd3 (Role 2), i sde3 (Role 3) (čiji su brojači događaja udaljeni samo 2 tiketa), dok odlaze sdc3 (Role 1) potpuno van.

Faza 3: Kloniranje svakog pogona bit za bit sa GNU ddrescue¶

Prije trčanja mdadm --assemble --force ili zpool import -F, klonirajte svaki potreban disk (posebno disk koji je zadnji ispao zbog loših sektora, kao npr. /dev/sdd u gornjem primjeru) na zdravu praznu disk jedinicu jednakog ili većeg kapaciteta ili u sirovu .img datoteku na velikom volumenu za pohranu.

Korak 1: Zašto ddrescue sa mapfileom je obavezan¶

Standard dd prekida na prvom lošem sektoru, ili sa conv=noerror,sync gubi sate bruseći svoje glave za čitanje preko oštećene staze dok ne puni megabajte susednih dobrih podataka. GNU ddrescue radi u inteligentnim višestepenim prolazima: 1. Prolaz 1 (faza kopiranja): Kopira sve zdrave regije diska koje brzo reaguju punom brzinom sekvence (150 MB/s to 250 MB/s), odmah preskačući sve spore ili nečitljive blokove kako se disk ne bi pregrijao ili umro prije nego što dobijete 99.99% dobri podaci. 2. Prolaz 2 (faza obrezivanja): Čita tačno do tačnih ivica svakog lošeg bloka i sa prednje i sa zadnje strane (reverse direction) za izolaciju oštećenog područja do tačnih 4 kilobajta hardverskog sektora. 3. Prolaz 3 (faza struganja): Lagano pokušava ponovo oštećene sektore bez nepotrebnog resetovanja sabirnice.

Korak 2: Pokrenite 2 faze ddrescue naredba kloniranja¶

Uvijek navedite datoteku mape (sdd_rescue.map). Ako se umirući izvorni pogon isključi i zahtijeva ciklus napajanja, ddrescue čita mapfile i nastavlja na točnom bajtu gdje je stao bez ponovnog čitanja jednog već kopiranog sektora:

# 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

Faza 4: Rekonstrukcija Synology DSM (SHR-1 / SHR-2 / Classic RAID), QNAP i Linux mdadm¶

Kada su vaši klonirani diskovi (ili uređaji samo za čitanje) spremni i originalni NAS diskovi bezbedno isključeni, pratite tačan nedestruktivni redosled sastavljanja za svoju platformu.

Scenario A: Standardni Linux mdadm ili Synology Classic RAID (RAID 5 / RAID 6)¶

1. Zaustavite bilo kakvu delimičnu md niz koji je Ubuntu možda pokušao pokrenuti:

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

2. Prisilno sastavite klonirane particije (sdb3, sdd3, sde3, izostavljajući davno mrtve sdc3) u načinu samo za čitanje:

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

   Pogledajte izlaz: mdadm će prijaviti forcing event count in /dev/sdd3(2) from 482188 up to 482190 i mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Provjerite je li niz aktivan i označen (auto-read-only) ili (read-only):

   cat /proc/mdstat
   

Scenarij B: Synology Hybrid RAID (SHR-1 i SHR-2) sa LVM2 i Btrfs / ext4¶

Synology SHR (Synology Hybrid RAID) je 100 posto standardni Linux mdadm + LVM2 (Logical Volume Manager): - Kada su svi diskovi u SHR grupi iste veličine (na primjer, četiri diska od 8 terabajta), Synology kreira jedan mdadm RAID 5 particija (md2 na particiji 3 svakog diska) i postavlja an LVM2 grupa volumena (vg1000 ili vg1) na vrhu md2. - Kada disk jedinice u SHR grupi imaju različite veličine (na primjer, dva diska od 8 terabajta i dva diska od 16 terabajta), Synology kreira dva odvojena mdadm nizovi: md2 preko Particije 5 (8 TB preseci na sva 4 diska u RAID 5) i md3 preko Particije 6 (preostale 8 TB preseci na dva diska od 16 TB u RAID 1), a zatim se spaja md2 + md3 u singl LVM2 Grupa volumena (vg1000).

Za montiranje Synology SHR volumena samo za čitanje na Ubuntu nakon prisilnog sastavljanja /dev/md2 (i /dev/md3 ako je SHR mješovite veličine): 1. Skenirajte Synology LVM2 fizičke volumene i grupe volumena:

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

Scenarij C: Synology DSM 7+ Volume Enkripcija ili Šifriranje zajedničke mape (eCryptfs)¶

• Šifrovanje dijeljene mape (@sharename@ foldere koji sadrže ECRYPTFS_FNEK_ENCRYPTED... imena fajlova): Kopirajte cijelu @encrypted_share@ folder isključen /mnt/synology_rescue prvo, zatim ga montirajte i dešifrirajte na Ubuntu koristeći svoju Synology šifru za šifriranje ili .key fajl:

  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+ Full Volume Encryption (LUKS): Ako /dev/vg1000/lv emisije TYPE="crypto_LUKS" in blkid, otključajte ga samo za čitanje koristeći .rkey Datoteka ključa za oporavak preuzeta kada je volumen kreiran:

  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
  

Scenarij D: QNAP QTS (LVM2 Thin Provisioning i DRBD sloj)¶

Moderne QNAP NAS jedinice (QTS 4.3+ / 5.x) ubacite interni jednostruki čvor DRBD uređaj (/dev/drbd1) između /dev/md1 i LVM2 Grupa volumena (vg1). 1. Prvo na silu sastavite QNAP particije podataka (/dev/sd[b-e]3) samo za čitanje u /dev/md1:

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

Faza 5: Spašavanje TrueNAS-a i Linuxa ZFS bazeni (RAIDZ1, RAIDZ2, RAIDZ3)¶

Ako vaš server za skladištenje pokreće TrueNAS CORE, TrueNAS SCALE, Proxmox VE ili Ubuntu ZFS, oporavak ne koristi mdadm. Umjesto toga, ZFS kombinuje upravljač volumena i copy-on-write (CoW) datotečni sistem u jednu transakcijsku arhitekturu izgrađenu oko Uberblokova i sekvencijalnih Transakcionih grupa (TXGs).

Korak 1: Pregledajte 4 ZFS vdev oznake (L0, L1, L2, L3) na svakom kloniranom disku¶

Svaka particija članica ZFS pohranjuje četiri identične kopije konfiguracije bazena i niz od posljednjih 128 Uberblokova (dvije oznake na prednjoj strani particije, L0 i L1, i dvije etikete na samom kraju, L2 i L3). Trči zdb -l na svakoj kloniranoj particiji da se pregleda stanje spremišta i najveća predana transakcijska grupa (txg):

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

Uporedite txg: brojeve na svim kloniranim diskovima. Baš kao mdadm's Events brojač, ako je jedan disk ispao 5 minuta prije nestanka struje ili drugog diska, njegov txg bit će nešto niže od preostalih diskova.

Korak 2: Uvezite ZFS bazen u strogo Read-Only modu (-o readonly=on)¶

Prvo provjerite uvozne bazene bez montiranja bilo čega preko sudo zpool import -d /dev/disk/by-id. Nikada nemojte uvoziti oštećeno ili više diskova ispušteno ZFS spremište u načinu čitanja i pisanja. Prilikom uvoza sa -o readonly=on, ZFS ne pokušava pokrenuti resilver, ne piše nove Uberblokove i ne može paničiti kernel ako je oštećena mapa prostora (spacemap) se susreće tokom dodjele pisanja:

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

Korak 3: Ako zpool import ne uspijeva sa I/O error ili corrupted data, koristite TXG Rollback (-F i -T)¶

Ako dva diska ispadnu u roku od nekoliko sekundi jedan od drugog tokom velikog rafala pisanja, najnovija grupa transakcija (TXG N) može biti nepotpun preko preživjelih parnih pruga, dok TXG N-1 ili TXG N-2 (napisano 5 do 15 sekundi ranije) je 100 posto netaknuto unutar Uberblock prstenastog bafera.

1. Testirajte nedestruktivni pregled vraćanja na suho (-F -n):

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

   Ako ZFS prijavi Would be able to return pool to its state as of <timestamp>, pokrenite uvoz za vraćanje samo za čitanje bez -n:

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

2. Ako -F još uvijek ne mogu montirati najnovije Uberblockove, navesti istorijske Uberblock TXG brojeve s zdb i uvezite određeni stariji TXG (-T):

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

   Izaberite a txg broj od 30 do 60 sekundi prije pada (npr. txg = 9481020) i uvezite bazen zamrznut u tom tačnom trenutku u načinu samo za čitanje:

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

Faza 6: Verifikacija nakon oporavka i sprečavanje kaskada obnove u budućnosti¶

Nakon što ste kopirali 100 posto svojih oporavljenih podataka iz /mnt/synology_rescue ili /mnt/zfs_rescue na nezavisni cilj sigurnosne kopije, slijedite ovu kontrolnu listu hardvera i konfiguracije prije nego što svoj NAS vratite u rad:

• Nikad ne kupujte sve NAS diskove od istog prodavca istog dana: Diskovi iz iste proizvodne serije dele identične serije glava i firmver, što dovodi do njihovog otkazivanja u roku od nekoliko sati jedan od drugog tokom rekonstrukcije. Miješane serije ili proizvođači (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• Koristite samo NAS/Enterprise diskove sa TLER / SCT ERC omogućen (ili podignite Linux mdadm SCSI vremenska ograničenja za desktop diskove): Za potrošačke diskove u Linuxu mdadm, koristite a udev pravilo podizanja /sys/block/sdX/device/timeout od 30 sekundi do 180 sekundi tako mdadm čeka ponovno mapiranje unutrašnjeg sektora umjesto ispuštanja pogona.
• Migrirajte nizove sa diskovima većim od 8 TB od RAID 5 / SHR-1 / RAIDZ1 to RAID 6 / SHR-2 / RAIDZ2: Sa 12 TB to 24 TB diskovi, jednoparitetna vremena obnavljanja prelaze 30 sati, čineći dvostruki paritet (RAID 6 / SHR-2 / RAIDZ2) važno za preživljavanje lošeg sektora tokom ponovnog srebrenja.
• Raspored mjesečno Data Scrubbing (mdadm check / zpool scrub) i Prošireno SMART testovi: Mjesečno ribanje popravlja latentne greške sektora (Current_Pending_Sector) dok su svi diskovi na mreži.
• Zapamtite da je RAID visoka dostupnost, nikad rezervna kopija: Pratite 3-2-1 strategija rezervne kopije sa offline kopijom.

Regionalni brojevi za hitne slučajeve i protokoli agencija¶

Prekidi skladištenja koji utiču na mreže zdravstvene zaštite, komunikacije u hitnim slučajevima ili zakonske lične evidencije zahtijevaju hitnu eskalaciju:

• Sjedinjene Američke Države i Kanada: Pozovite 911 ako pad skladišta onesposobi bolničke kliničke sisteme (EHR / PACS) ili otprema. Prijavite NAS ciljani ransomware (DeadBolt, LockBit, Akira) do CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), ili Kanadski centar za sajber sigurnost (1-833-CYBER-88).
• Ujedinjeno Kraljevstvo: birajte 999 za hitne slučajeve koji utiču na sigurnost života ili akutnu NHS njegu. Prema UK GDPR-u, procijenite da li je za trajni gubitak ličnih podataka bez rezervne kopije potrebno obavijestiti ICO (0303 123 1113) u roku od 72 sata.
• Evropska unija: Pozovite 112 širom EU. Subjekti prema NIS2 Direktivi moraju prijaviti velike operativne prekide svom nacionalnom CSIRT-u u roku od 24 sata, a trajni gubitak dostupnosti ličnih podataka pokreće prijavljivanje GDPR-a, član 33 u roku od 72 sata.
• Australija i Novi Zeland: Birajte 000 u Australiji ili 111 na Novom Zelandu; prijavi infrastrukturne ili ransomware NAS incidente ACSC-u (1300 CYBER1) ili CERT NZ (0800 237 869).
• Indija i azijsko-pacifički region: birajte 112 u Indiji za hitan odgovor; prijavi incidente pohrane infrastrukture CERT-In (incident@cert-in.org.in) unutar obaveznog roka od 6 sati.

Često postavljana pitanja¶

Zašto mdadm --assemble --force odbiti da pokrenem moj RAID 5 niz sa not enough to start the array?¶

U 4 pogona RAID 5 niz, barem 3 od 4 pogona mora se proslijediti na mdadm --assemble --force. Trči sudo mdadm --ispitati /dev/sd[a-z]3 da provjerite zašto je treći disk odbijen: ili ste proslijedili cijeli disk umjesto particije (/dev/sdd umjesto /dev/sdd3), njegov superblok je označen kao a Rezervni prekinutom ponovnom izgradnjom ili je Ubuntu-ov auto-sastavljač zaključao jedan disk u neaktivan /dev/md127 uređaj (pokreni sudo mdadm --stop --scan prvo, pa ponovo pokrenuti mdadm --assemble --force --readonly).

Šta ako se disk počne obnavljati (Recovery = 12%) prije nego što je drugi disk ispao?¶

Ako je disk 2 umro, umetnuli ste zamjenski pogon 2 i na 12% napredak ponovne izgradnje Drive 3 je isključen zbog lošeg sektora, nemojte koristiti 12% obnovljeni zamjenski pogon 2. Umjesto toga, klonirajte original Vozite 3 sa ddrescue. Budući da je Drive 3 bio potpuno aktuelan sve dok se rekonstrukcija nije zaustavila na 12%, prisilno sastavljanje niza samo za čitanje koristeći Drive 1, ddrescue klon Drive 3, a Drive 4 (ostavljajući Drive 2 van) daje vam konzistentan niz.

Mogu li staviti svoje Synology ili QNAP diskove u potpuno novu NAS šasiju ako je NAS napajanje ili ploča nestala?¶

Da, oba Synology (HDD Migracija) i QNAP (Direktna NAS migracija) pohraniti RAID konfiguraciju na same disk jedinice. međutim, ako su dva ili više diskova već ispali (`Volume Crashed`) prije nego što je kućište umrlo, nemojte ih pokretati unutar novog NAS kućišta, jer čarobnjak za migraciju može prepisati particije ili pokrenuti destruktivnu obnovu. Prvo spasite podatke samo za čitanje na Ubuntu.

Kako da znam da li je ispušteni disk siguran za kloniranje ddrescue u odnosu na potrebu za laboratorijom za čistu sobu?¶

Povežite disk na SATA, uključite ga i slušajte 10 sekundi dok gledate sudo dmesg -w. Ako disk ispušta ritmične klikove, struganje ili zujanje, okreće se gore i okreće nazad dolje ili prijavljuje kapacitet kao 0 B / 4,1 GB in lsblk, glave za čitanje/pisanje su fizički otkazale: odmah isključite struju i koristite laboratoriju za čistu sobu. Ako se pogon okreće glatko, pokazuje svoj puni kapacitet lsblk, i samo dnevnike Trenutni_sektor_na čekanju ili greške isteka, klonirajte ga sa ddrescue.

Šta je "RAID 5 Write Hole" i kako funkcioniše ZFS ili Btrfs izbjeći ga tokom nestanka struje?¶

U tradicionalnom RAID 5 / RAID 6 bez dnevnika, ažuriranje trake zahtijeva upisivanje bloka podataka i bloka parnosti na dva diska istovremeno. Ako struja nestane usred pisanja, podaci i paritet se više ne podudaraju ( Write Hole). ZFS (`RAIDZ`) i Btrfs eliminirajte rupu za upis koristeći Copy-on-Write (`CoW`), upisivanje svake nove trake u neiskorištene blokove i ažuriranje Uberblock/root pokazivača tek nakon što je cijela traka na disku.

Mogu li koristiti dmsetup preklapanja za testiranje RAID parametara bez modifikacije kloniranih diskova?¶

Da, možete kreirati Copy-on-Write (`CoW`) preklapanja na vrhu uređaja petlje samo za čitanje (`losetup --read-only`) koristeći Linux dmsetup (`snapshot` target) podržan od rijetkih datoteka u /tmp. Bilo koje pisanje od mdadm --assemble --force ili fsck -y idi u jednokratnu upotrebu /tmp overlay fajl, koji vam omogućava resetovanje za 1 sekundu ako je potrebno.

Povezani vodiči¶

• NAS RAID niz degradiran, višestruki disk neuspjeh i ZFS/Btrfs oporavak
• Smrt kartice RAID kontrolera, uvoz stranih konfiguracija i zašto nikada ne smijete inicijalizirati diskove
• Kvar tvrdog diska i oporavak podataka
• SSD i NVMe iznenadni način rada samo za čitanje, 0% rezervnih blokova i TRIM onemogućavanje spašavanja
• Slučajno rm -rf ili Shift+Delete na Linuxu, macOS-u ili Windowsu: trenutno ponovno montiranje samo za čitanje
• Sigurnosne kopije računara, strategija 3-2-1 i oporavak od katastrofe
• Brojevi za hitne slučajeve po zemljama

Izvori i službene upute¶

• Linux Raid Wiki (raid.wiki.kernel.org) & Organizacija jezgra Linuxa: Oporavak neuspjelog softverskog RAID-a (mdadm --assemble --force --readonly i Nepodudarnosti brojača događaja).
• Fondacija slobodnog softvera (GNU Project): GNU ddrescue Priručnik: Forenzički oporavak podataka sa neispravnih medija.
• OpenZFS dokumentacija (openzfs.github.io): ZFS Pool Import Recovery (zpool import -F, Uvoz samo za čitanje i zdb Inspekcija).
• Synology Inc.: Synology Centar znanja: Kako mogu koristiti PC za oporavak podataka kada moj Synology NAS ne radi (mdadm + LVM2 Montaža).
• Nacionalni institut za standarde i tehnologiju (NIST) (Sjedinjene Američke Države): Specijalna publikacija 800-209: Sigurnosne smjernice za infrastrukturu pohrane.