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

Slušanje Synology DiskStation, QNAP TS serije, TrueNAS poslužitelja ili Linuxa mdadm kontinuirani zvučni signal poslužitelja za pohranu dok se prijavljuje Pad volumena, Pool degradiran / neispravan ili Multiple Drives Disconnected je hitan slučaj pohrane s visokim ulozima. Kada jedan pogon ispadne iz a RAID 5, Synology Hybrid RAID (SHR-1), ili ZFS RAIDZ1 bazen, niz radi s nultom redundancijom (degraded stanje), rekonstruirajući nedostajuće blokove u hodu paralelnim čitanjem svakog preostalog diska. Ako drugi disk prestane biti povezan sa mrežom nekoliko sati kasnije ili izbaci nepopravljivu pogrešku čitanja (URE) na pola puta ponovne izgradnje na zamjenski disk, paritetna matematika se pokvari i spremište za pohranu potpuno se isključuje. Uspaničeni administratori često unište terabajte podataka koji se mogu povratiti u sljedećih šezdeset sekundi klikom na Inicijaliziraj, ponovno stvarajući niz s mdadm --create, ili prisiljavanje na trenutnu mrežnu ponovnu izgradnju na pokvarenom hardveru. Ako je vaša kartica hardverskog RAID kontrolera umrla, a ne diskovi, prijeđite na Smrt kartice RAID kontrolera, uvoz strane konfiguracije i zašto nikada ne smijete inicijalizirati diskove; ako pojedinačni tvrdi disk škljoca ili se odbija okretati, obratite se kvar tvrdog diska i oporavak podataka ili NAS RAID polje degradirano, kvar više diskova i ZFS/Btrfs oporavak. Ako ovaj kvar pohranjivanja onemogući bolničko medicinsko snimanje (PACS), hitnu pomoć ili infrastrukturu za sigurnost života, nazovite svoj lokalni broj za hitne slučajeve (911 u Sjedinjenim Državama i Kanadi, 112 diljem Europske unije, 999 u Ujedinjenom Kraljevstvu) ili provjerite naš imenik hitne brojeve.

Učinite to sada¶

1. ZAUSTAVITE i NEMOJTE kliknuti "Inicijaliziraj", "Kreiraj skup", "Popravi" ili pokreni mdadm --create na ispuštenim pogonima: Klikom na Initialize u Synology DSM ili QNAP QTS ili pokretanje mdadm --create u Linuxu, piše potpuno nove superblokove i počinje nulirati paritetne trake na svim diskovima članova. Ispušteni pogon obično još uvijek stoji 99.99% vaših datoteka netaknutih, samo označenih izvan sinkronizacije svojim brojačem događaja.
2. Čisto isključite NAS ili poslužitelj (ili isključite napajanje ako se aktivno obnavlja preko pogona koji klikaju) kako biste zamrznuli brojače događaja: svake sekunde niz ostaje na mreži u djelomično degradiranom stanju, operativni sustav 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 obnoviti disk s lošim sektorima, nastavak čitanja tog pogona može ogoliti premaz magnetske ploče (head crash).
3. Označite svaki utor ležišta pogona 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 pratiti redoslijed pogona prema UUID-u unutar svakog superbloka particije, stariji hardverski kontroleri i priručnik dmsetup rekonstrukcije tablice zahtijevaju točan fizički redoslijed utora (0, 1, 2, 3...).
4. Nikada ne pokušavajte oporavak, prisilno sastavljanje ili fsck izravno na izvornim pogonima članova; klonirajte svaki pogon malo po bit koristeći ddrescue prvi: Prije trčanja mdadm --assemble --force ili zpool import -F, priključite svaki članski disk na Linux radnu stanicu putem izravnog SATA/SAS (nikada jeftinog USB mosta koji skriva SMART ili SCT ERC timeouts) i klonirajte ga pomoću ddrescue na zdrave rezervne diskove ili slikovne datoteke.
5. Prisilno sastavite klonirano polje isključivo u načinu rada SAMO ZA ČITANJE (--readonly ili -o readonly=on): Prilikom sastavljanja mdadm nizovi čiji su se brojači događaja udaljili tijekom istovremenog pada više pogona, uvijek prolaze --readonly (mdadm --assemble --force --readonly /dev/md0 ...). U načinu rada samo za čitanje, niti jedno mdadm, LVM2, ext4, Btrfs, niti ZFS može prebrisati crte pariteta ili ponovno reproducirati destruktivni dnevnik.
6. Kopirajte svoje najkritičnije podatke na neovisni eksterni pogon za sigurnosno kopiranje odmah nakon postavljanja samo za čitanje: prvo evakuirajte svoje dokumente, baze podataka, virtualne strojeve i fotografije na zasebni pogon, zatim obrišite i testirajte diskove ispočetka.

Stablo odlučivanja: hitna trijaža RAID-a s više pogona i ZFS skupa¶

Upotrijebite ovaj dijagram toka kako biste utvrdili je li vaš niz pretrpio logični pad vremenskog ograničenja (TLER / ERC neusklađenost), pravi kvar lošeg sektora na više diskova tijekom ponovne izgradnje ili ZFS transakcijska grupa (TXG) greška:

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

    ConnectLinux --> CheckSmart["Pregledajte SMART & metapodatke samo za čitanje: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Kliknu li neki pogoni, odbijaju li se okretati ili ispuštaju izvan mreže u dmesg-u?"}

    PhysicalHealth -->|"Da: mehanički kvar/kvar glave na 2+ pogona u RAID 5"| Cleanroom["ZAUSTAVITE napajanje diskova -> Pošaljite u Cleanroom Data Recovery Lab"]
    PhysicalHealth -->|"Ne: Svi pogoni se okreću (možda imaju loše sektore na čekanju ili pad vremena)"| CloneAll["Kloniraj svaki pogon člana koristeći GNU ddrescue (prolaz naprijed -> obrnuto struganje)"]

    CloneAll --> DisconnectOrig["Isključite izvorne pogone i radite isključivo na kloniranim diskovima/slikama"]
    DisconnectOrig --> ArrayType{"Koja se arhitektura pohrane koristi?"}

    ArrayType -->|"Synology DSM (SHR / klasični RAID)"| SynologyFlow["Pregledaj događaje putem mdadm --examine -> Force-Assemble Read-Only -> Activate LVM2 / Btrfs Read-Only"]
    ArrayType -->|"QNAP QTS (HAL LVM tanki / debeli RAID)"| QnapFlow["Sastavite mdadm samo za čitanje -> Aktivirajte DRBD sloj ako je prisutan -> Skeniraj prilagođene QNAP LVM2 superblokove"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Mirror)"| ZfsFlow["Pokrenite zpool import -d /dev/disk/by-id -> Import Read-Only with Rollback: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Standardni Linux mdadm"| LinuxFlow["Usporedite brojače događaja -> Pokreni mdadm --assemble --force --readonly -> Montiraj datotečni sustav s -o ro,noload"]

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

Da biste razumjeli zašto klik na Popravi/ponovno izgradi ili zamjena jednog diska i čekanje 36 sati često uzrokuje potpuni pad niza, morate razumjeti kako rekonstrukcija pariteta opterećuje starenje magnetskih medija i zašto potrošački stolni pogoni ispadaju iz NAS kućišta.

1. Matematička stvarnost nepopravljivih pogrešaka čitanja (UREs) tijekom ponovne izgradnje RAID 5 ili RAIDZ1¶

U 4 pogona RAID 5 ili ZFS RAIDZ1 skup, podaci i paritetni blokovi (P) isprugani su preko sva četiri diska koristeći isključivi ILI (XOR) izračun (D1 XOR D2 XOR D3 = P). Ako Pogon 2 potpuno nestane, polje nema preostalu redundanciju. Za ponovno sastavljanje Pogona 2 na potpuno novi zamjenski disk, NAS mora čitati svaki sektor od bajta 0 do kraja diska na Pogonu 1, Pogonu 3 i Pogonu 4 istovremeno (Reconstructed D2 = D1 XOR D3 XOR P).

Razmislite što se događa kada su ti pogoni četiri tvrda diska od 12 terabajta (12 000 gigabajta) kupljena iz iste proizvodne serije prije četiri godine: - Ponovna izgradnja 12 terabajta zahtijeva čitanje 36 terabytes (2.88 x 1014 pojedinačni bitovi) neprekidno tijekom 24 do 48 sati pri maksimalnom toplinskom i mehaničkom opterećenju. - Potrošački tvrdi diskovi obično nose nepopravljivu pogrešku čitanja (URE) specifikacija od 1 error in 1014 bits (12.5 terabytes), a stari pogoni razvijaju tihe latentne sektorske pogreške (Current_Pending_Sector) u hladnim područjima diska koja godinama nisu čitana. - U trenutku kada Drive 3 pogodi jedan nečitljiv loš sektor od 4 kilobajta (0,004 megabajta), dok Drive 2 još uvijek nedostaje ili je napola obnovljen, XOR jednadžba ima dvije nepoznanice (D2 i D3).

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

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

Primijetite što se zapravo dogodilo: Drive 3 nije mrtav. Ima 99.999999% zdravi sektori i samo 1 ili 2 nečitljiva sektora od 4 kilobajta (8 kilobytes od 12 terabytes). Ipak zato mdadm izbacio Drive 3 iz niza zbog isteka naredbe od 30 sekundi, cijeli volumen prikazuje se kao Crashed. Ako klonirate Drive 3 sa ddrescue (koji graciozno preskače 8 kilobajta loših sektora i kopira ostalih 12 terabajta) i prisilno sastavite polje samo za čitanje, oporavljate gotovo 100 posto svojih datoteka.

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

Kada se niz sruši, dva destruktivna mita kruže online: - Mit 1: "Ponovo stvorite niz s točno istim redoslijedom pogona koristeći mdadm --create." Čak i sa --assume-clean, moderne verzije mdadm zadano drugačije Data Offset vrijednosti ovisno o kernelu i mdadm osloboditi (2048 sectors u odnosu na 262144 sectors). Kada mdadm --create piše novu verziju 1.2 superblok na pogrešnom pomaku ili s neusklađenom veličinom dijela, on prepisuje LVM2 zaglavlje fizičkog volumena ili ext4 superblok na prednjem dijelu volumena. - Mit 2: "Izvucite drugi pogon koji je upravo ispao, ponovno ga uključite i kliknite Popravi." Ako je Pogon 1 ispao prije tri dana (pa su njegovi podaci zastarjeli 3 dana), a Pogon 3 je ispao prije 10 minuta (pa su podaci aktualni), povlačenje i ponovno umetanje pogrešnog pogona ili prisilna ponovna izgradnja s Pogonom 1 označenim kao "aktivan" i Pogonom 3 označenim kao "rezervni" uzrokuje da NAS prebriše ažurni niz s 3 dana stare ustajale crte pariteta, kvare svaki direktorij i datoteku izmijenjenu u posljednja 72 sata.

Faza 2: Inspekcija superblokova i Event brojači sigurno na Linux hostu za spašavanje¶

Za sigurno spašavanje srušenog polja Synology, QNAP, TrueNAS ili Linux, uklonite sve pogone članove (nakon što označite njihove brojeve ležišta) i spojite ih na stolno računalo ili poslužitelj koji pokreće Ubuntu 22.04 LTS / 24.04 LTS (čak se pokreće i s Live USB sticka).

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

Otvorite terminal na svom računalu za spašavanje Ubuntua 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 tablicu particija tipičnog Synology DSM, QNAP ili TrueNAS pogona:

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

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

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

Usporedite 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 Events računati na 479012 od prije dva dana (Oct 29). Taj je disk prvi ispao, prije dva dana, i od tada je bio izvan mreže. 2. /dev/sdb3 (Role 0) i /dev/sde3 (Role 3) oboje imaju Events : 482190 na 14:12:09. 3. /dev/sdd3 (Role 2) ima Events : 482188 na 14:12:04, samo 5 sekundi i 2 događaja iza sdb3 i sde3. 4. Zaključak: morate rekonstruirati niz pomoću sdb3 (Role 0), sdd3 (Role 2), i sde3 (Role 3) (čiji su brojači događaja udaljeni samo 2 kvačice), dok odlazi sdc3 (Role 1) van u potpunosti.

Faza 3: Kloniranje svakog pogona malo po malo GNU ddrescue¶

Prije trčanja mdadm --assemble --force ili zpool import -F, klonirajte svaki potrebni disk (osobito onaj koji je zadnji ispao zbog loših sektora, kao što je /dev/sdd u gornjem primjeru) na zdrav prazan pogon jednakog ili većeg kapaciteta ili u sirovi .img datoteka na velikom volumenu za pohranu.

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

Standardno dd prekida na prvom lošem sektoru, ili sa conv=noerror,sync gubi sate na brušenje svojih glava za čitanje preko oštećene staze dok ne ispunjava megabajte susjednih dobrih podataka. GNU ddrescue radi u inteligentnim višestupanjskim prolazima: 1. Prolaz 1 (faza kopiranja): Kopira sva zdrava područja diska koja brzo reagiraju punom sekvencijalnom brzinom (150 MB/s do 250 MB/s), odmah preskačući spore ili nečitljive blokove kako se pogon ne bi pregrijao ili ugasio prije nego što dobijete 99.99% dobri podaci. 2. Prolaz 2 (faza skraćivanja): Čita sve do točnih rubova svakog lošeg bloka s prednje i stražnje strane (reverse direction) za izolaciju oštećenog područja do točnog hardverskog sektora od 4 kilobajta. 3. Prolaz 3 (faza struganja): nježno ponovno pokušava obraditi oštećene sektore bez nepotrebnog resetiranja sabirnice.

Korak 2: Pokrenite 2 faze ddrescue naredba kloniranja¶

Uvijek navedite mapfile (sdd_rescue.map). Ako se umirući izvorni pogon odspoji 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-a (SHR-1 / SHR-2 / Klasični RAID), QNAP i Linux mdadm¶

Nakon što su vaši klonirani pogoni (ili uređaji s petljom samo za čitanje) spremni i originalni NAS pogoni sigurno isključeni, slijedite točan redoslijed sklapanja bez destrukcije za svoju platformu.

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

1. Zaustavite svaki djelomični md polje koje 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 umrle sdc3) u strogo samo za čitanje:

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

   Pogledajte izlaz: mdadm izvijestit će 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 polje aktivno i označeno (auto-read-only) ili (read-only):

   cat /proc/mdstat
   

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

Synologyjev SHR (Synology Hybrid RAID) je 100 posto standardni Linux mdadm + LVM2 (Logical Volume Manager): - Kada su svi pogoni u SHR skupu iste veličine (na primjer, četiri pogona od 8 terabajta), Synology stvara jedan mdadm RAID 5 particija (md2 na particiji 3 svakog pogona) i postavlja an LVM2 grupa volumena (vg1000 ili vg1) na vrhu md2. - Kada pogoni u SHR skupu imaju različite veličine (na primjer, dva pogona od 8 terabajta i dva pogona od 16 terabajta), Synology stvara dva odvojena mdadm nizovi: md2 preko odjeljka 5 (8 TB rez na sva 4 pogona u RAID 5) i md3 preko particije 6 (ostalo 8 TB slice na dva pogona od 16 TB u RAID 1), zatim se spaja md2 + md3 u jedinstvenu 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 sveske i grupe svezaka:

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: šifriranje volumena Synology DSM 7+ ili šifriranje dijeljene mape (eCryptfs)¶

• Šifriranje dijeljene mape (@sharename@ mape koje sadrže ECRYPTFS_FNEK_ENCRYPTED... imena datoteka): Kopiraj cijeli @encrypted_share@ mapa isključena /mnt/synology_rescue prvo, zatim ga montirajte i dešifrirajte na Ubuntu koristeći svoju Synology lozinku za šifriranje ili .key datoteka:

  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+ Enkripcija punog volumena (LUKS): ako /dev/vg1000/lv pokazuje TYPE="crypto_LUKS" u blkid, otključajte ga samo za čitanje pomoću .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) umetnite interni jednostruki čvor DRBD uređaj (/dev/drbd1) između /dev/md1 i LVM2 Grupa volumena (vg1). 1. Prvo prisilno sastavite QNAP podatkovne particije (/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š poslužitelj za pohranu pokreće TrueNAS CORE, TrueNAS SCALE, Proxmox VE ili Ubuntu ZFS, oporavak ne koristi mdadm. Umjesto toga, ZFS kombinira upravitelj volumena i kopiranje na pisanje (CoW) datotečni sustav u jedinstvenu transakcijsku arhitekturu izgrađenu oko Uberblocks i sekvencijalnih Transakcijskih grupa (TXGs).

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

Svaka particija člana ZFS-a pohranjuje četiri identične kopije konfiguracije bazena i niz zadnjih 128 Uberblokova (dvije oznake na prednjoj strani particije, L0 i L1, i dvije oznake na samom kraju, L2 i L3). Trčanje zdb -l na svakoj kloniranoj particiji za pregled stanja skupa i najviše predane transakcijske grupe (txg):

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

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

Korak 2: Uvezite ZFS skup u načinu rada samo za čitanje (-o readonly=on)¶

Prvo provjerite uvozne bazene bez montiranja bilo čega putem sudo zpool import -d /dev/disk/by-id. Nikada nemojte uvoziti oštećeni ili ispušteni ZFS skup u načinu rada za čitanje i pisanje. Pri uvozu sa -o readonly=on, ZFS ne pokušava pokrenuti resilver, ne piše nove Uberblokove i ne može paničariti kernel ako je oštećena karta prostora (spacemap) nailazi se tijekom 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 s I/O error ili corrupted data, koristite TXG Rollback (-F i -T)¶

Ako su dva pogona ispala unutar nekoliko sekundi jedan od drugog tijekom velikog niza pisanja, najnovija Transakcijska grupa (TXG N) može biti nepotpun preko preostalih linija pariteta, dok TXG N-1 ili TXG N-2 (napisano 5 do 15 sekundi ranije) je 100 posto netaknuto unutar međuspremnika prstena Uberblock.

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 javlja Would be able to return pool to its state as of <timestamp>, pokrenite uvoz vraćanja 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 Uberblokove, popis povijesnih Uberblock TXG brojeva s zdb i uvezite određeni stariji TXG (-T):

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

   Odaberite a txg broj od 30 do 60 sekundi prije pada (npr. txg = 9481020) i uvesti skup zamrznut u tom točnom trenutku u načinu rada samo za čitanje:

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

Faza 6: Verifikacija nakon oporavka i sprječavanje budućih kaskada ponovne izgradnje¶

Nakon što ste kopirali 100 posto svojih oporavljenih podataka iz /mnt/synology_rescue ili /mnt/zfs_rescue na neovisni rezervni cilj, slijedite ovaj kontrolni popis hardvera i konfiguracije prije ponovnog stavljanja NAS-a u rad:

• Nikada ne kupujte sve NAS pogone od istog prodavača istog dana: Pogoni iz iste proizvodne serije dijele identične glavne serije i firmware, što uzrokuje njihov kvar unutar nekoliko sati jedan od drugog tijekom ponovne izgradnje. Miješajte serije ili proizvođače (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• Koristite samo NAS/Enterprise pogone s TLER / SCT ERC omogućeno (ili podignuti Linux mdadm SCSI timeouts za desktop pogone): Za potrošačke pogone u Linuxu mdadm, koristite a udev pravilo podići /sys/block/sdX/device/timeout iz 30 sekunde do 180 sekundi tako mdadm čeka remapiranje unutarnjeg sektora umjesto da ispusti pogon.
• Migracija polja s pogonima većim od 8 TB iz RAID 5 / SHR-1 / RAIDZ1 do RAID 6 / SHR-2 / RAIDZ2: sa 12 TB do 24 TB diskovi, vrijeme obnove s jednim paritetom prelazi 30 sati, što čini dvoparitet (RAID 6 / SHR-2 / RAIDZ2) važno za preživljavanje lošeg sektora tijekom ponovnog posrebrenja.
• Raspored mjesečno Data Scrubbing (mdadm check / zpool scrub) i Prošireno SMART testovi: Mjesečno čišćenje popravlja latentne sektorske pogreške (Current_Pending_Sector) dok su svi pogoni na mreži.
• Zapamtite da je RAID visoka dostupnost, nikad sigurnosna kopija: Slijedite 3-2-1 rezervna strategija s izvanmrežnom kopijom.

Regionalni brojevi za hitne slučajeve i protokoli agencija¶

Prekidi pohrane koji utječu na zdravstvene mreže, hitne komunikacije ili zakonske osobne evidencije zahtijevaju trenutnu eskalaciju:

• Sjedinjene Države i Kanada: Birajte 911 ako pad pohrane onesposobi bolničke kliničke sustave (EHR / PACS) ili slanje. Prijavite ransomware usmjeren na NAS (DeadBolt, LockBit, Akira) u CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov) ili Kanadski centar za kibernetičku sigurnost (1-833-CYBER-88).
• Ujedinjeno Kraljevstvo: Birajte 999 za hitne slučajeve koji utječu na sigurnost života ili akutnu NHS skrb. Prema GDPR-u za UK, procijenite zahtijeva li trajni gubitak osobnih podataka bez sigurnosne kopije obavještavanje ICO (0303 123 1113) u roku od 72 sata.
• Europska unija: Birajte 112 u cijeloj EU. Subjekti prema NIS2 Direktivi moraju prijaviti velike prekide rada svom nacionalnom CSIRT-u u roku od 24 sata, a trajni gubitak dostupnosti osobnih podataka pokreće GDPR članak 33 prijavu u roku od 72 sata.
• Australija i Novi Zeland: Birajte 000 u Australiji ili 111 na Novom Zelandu; prijavite NAS incidente infrastrukture ili ransomwarea ACSC-u (1300 CYBER1) ili CERT NZ (0800 237 869).
• Indija i Azija-Pacifik: Birajte 112 u Indiji za hitne intervencije; prijavite incidente pohrane infrastrukture CERT-In (incident@cert-in.org.in) unutar obveznog 6-satnog prozora.

Često postavljana pitanja¶

Zašto jesam mdadm --assemble --force odbiti pokrenuti moj RAID 5 niz s not enough to start the array?¶

U 4 pogona RAID 5 niz, barem 3 od 4 pogona mora se proslijediti na mdadm --sastaviti --prisiliti. Trči sudo mdadm --ispitajte /dev/sd[a-z]3 da provjerite zašto je treći pogon 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 Ubuntuov auto-assembler zaključao jedan pogon u neaktivan /dev/md127 uređaj (trčanje sudo mdadm --stop --scan prvo, zatim ponovno mdadm --sastaviti --force --samo za čitanje).

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

Ako je Drive 2 prestao, umetnuli ste zamjenski Drive 2, a na 12% napredak obnove Drive 3 je ispao offline zbog lošeg sektora, nemojte koristiti 12%-obnovljeni zamjenski Drive 2. Umjesto toga, klonirajte izvornik Pogon 3 sa ddrescue. Budući da je pogon 3 bio potpuno aktualan sve dok se ponovna izgradnja nije zaustavila na 12%, prisilno sastavljanje niza samo za čitanje pomoću pogona 1, ddrescue klon Pogona 3, a Pogon 4 (izostavljajući Pogon 2) daje vam konzistentan niz.

Mogu li staviti svoje Synology ili QNAP pogone u potpuno novo NAS kućište ako je NAS napajanje ili ploča umrla?¶

Da, oba Synology (Migracija HDD-a) i QNAP (Izravna migracija NAS-a) pohranjuju RAID konfiguraciju na same pogone. međutim, ako su dva ili više diskova već otpala (`Volume Crashed`) prije nego što se kućište pokvari, nemojte ih pokretati unutar novog NAS kućišta, jer čarobnjak za migraciju može prebrisati particije ili pokrenuti destruktivnu ponovnu izgradnju. Prvo spasite podatke samo za čitanje na Ubuntuu.

Kako mogu znati je li ispušteni pogon siguran za kloniranje ddrescue u odnosu na potrebu za čistim laboratorijem?¶

Spojite pogon na SATA, uključite ga i slušajte 10 sekundi dok gledate sudo dmesg -w. Ako pogon proizvodi ritmične zvukove škljocanja, struganja ili zujanja, okreće se gore i nazad dolje ili prijavljuje kapacitet kao 0 B / 4,1 GB u lsblk, glave za čitanje/pisanje su fizički pokvarene: odmah isključite struju i upotrijebite laboratorij čiste sobe. Ako se disk vrti glatko, prikazuje svoj puni kapacitet u lsblk, i samo trupci Trenutačni_sektor_na_čekanju ili pogreške isteka vremena, klonirajte ga s ddrescue.

Što je "RAID 5 Write Hole" i kako ZFS ili Btrfs izbjeći tijekom nestanka struje?¶

U tradicionalnom RAID 5 / RAID 6 bez dnevnika, ažuriranje pruge zahtijeva pisanje podatkovnog bloka i paritetnog bloka na dva diska istovremeno. Ako napajanje nestane tijekom pisanja, podaci i paritet se više ne podudaraju ( Napiši Hole). ZFS (`RAIDZ`) i Btrfs uklonite rupu za pisanje pomoću Copy-on-Write (`CoW`), pisanje 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 modificiranja 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` cilj) podržan rijetkim datotekama u /tmp. Svatko piše iz mdadm --sastaviti --prisiliti ili fsck -y idi u jednokratnu upotrebu /tmp preklapajuću datoteku, što vam omogućuje resetiranje u 1 sekundi ako je potrebno.

Povezani vodiči¶

• NAS RAID polje degradirano, kvar više diskova i ZFS/Btrfs oporavak
• Smrt kartice RAID kontrolera, uvoz strane konfiguracije 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: trenutačno ponovno postavljanje samo za čitanje
• Sigurnosne kopije računala, strategija 3-2-1 i oporavak od katastrofe
• Brojevi hitnih službi po državama

Izvori i službene upute¶

• Linux Raid Wiki (raid.wiki.kernel.org) & Organizacija jezgre Linuxa: Oporavak neuspjelog softverskog RAID-a (mdadm --assemble --force --readonly i neusklađenosti brojača događaja).
• Free Software Foundation (GNU Project): GNU ddrescue Priručnik: Forenzičko obnavljanje podataka s neispravnih medija.
• OpenZFS dokumentacija (openzfs.github.io): ZFS Pool Import Recovery (zpool import -F, uvozi samo za čitanje i zdb Inspekcija).
• Synology Inc.: Synology Knowledge Center: Kako mogu koristiti računalo za oporavak podataka ako moj Synology NAS ne radi ispravno (mdadm + LVM2 Montaža).
• Nacionalni institut za standarde i tehnologiju (NIST) (Sjedinjene Države): Posebna publikacija 800-209: Sigurnosne smjernice za infrastrukturu pohrane.