Eșecul matricei RAID, pool de stocare NAS corupt și siguranța reconstrucției¶

Când un dispozitiv de stocare atașat la rețea (NAS) de la domiciliu sau al unei întreprinderi mici (cum ar fi un Synology DiskStation, QNAP Turbo NAS, TrueNAS sau un server Unraid) începe să emită un semnal sonor cu un LED chihlimbar și semnalează „Storage Pool Degraded” sau „Volum blocat”, determină, de obicei, dacă fotografiile de afaceri ale proprietarului sunt de 20 de clicuri de neînlocuit. salvate sau distruse definitiv. Timp de decenii, utilizatorii au fost învățați că, atunci când o unitate dintr-o matrice RAID 5 sau RAID 1 devine roșie, pur și simplu scoateți unitatea nefuncțională, introduceți o unitate goală nouă și faceți clic pe "Reparați / Reconstruiți."

În pool-urile moderne de stocare de mare capacitate, construite cu unități de la 8 TB până la 24 TB achiziționate din același lot de producție, pornirea orbește a unei reconstruiri RAID la loc este cauza nr. 1 a morții totale, irecuperabile, a matricei cu mai multe unități. Reconstruirea unei matrice RAID 5 cu 4 unități de 16 TB forțează fiecare unitate învechită rămasă să citească 100% din sectoarele sale non-stop timp de 24 până la 72 de ore la sarcina termică și mecanică maximă. Când una dintre unitățile frate supraviețuitoare lovește o eroare de citire necorecabilă (URE) sau suferă degradarea capului la jumătatea reconstrucției, controlerul RAID scoate a doua unitate din pool și blochează întreaga matrice. Supraviețuirea unei urgențe RAID, ZFS sau Btrfs necesită întreruperea imediată a tuturor scrierilor, auditând S.M.A.R.T. telemetrie pe toate unitățile supraviețuitoare, copierea de rezervă a folderelor critice înainte de a atinge topologia matricei și imaginea discurilor membre degradate cu GNU ddrescue înainte de a încerca vreodată o reconstrucție de paritate sau un ansamblu de metadate doar pentru citire.

Fă asta acum¶

1. NU scoateți NICIODATĂ mai multe unități pentru a le „reașeza” în timp ce NAS-ul sau serverul este pornit și NU schimbați NICIODATĂ unitățile fără a le eticheta numerele exacte ale slotului. Înainte de a atinge o singură tavă de unitate, luați un sharpie sau un aparat de etichetare și marcați partea superioară fizică a fiecărei unități cu numărul exact al locașului (Bay 1 / sda, Bay 2 / sdb, Bay 3 / sdc). Deși Linux modern mdadm, LVM și ZFS stochează superblocuri UUID pe fiecare disc, controlerele RAID hardware (Dell PERC, HP Smart Array, Broadcom/LSI MegaRAID) leagă adesea metadatele de configurare la numerele fizice ale sloturilor SAS/SATA.
2. NU faceți clic imediat pe „Reparare” sau „Reconstruiți” pe o matrice RAID 5/SHR-1 degradată dacă nu aveți o copie de rezervă externă actualizată. În timp ce o matrice cu paritate unică (RAID 5, Synology SHR-1 sau ZFS RAIDZ1) se află în Mod Degradat (1 unitate moartă, 10% din fișierele rămase online) sunt încă citite ** 10% din fișierele dvs. rămase. Conectați un hard disk extern USB 3.0 direct în NAS și copiați folderele cele mai critice și de neînlocuit din grupul degradat înainte de a supune unitățile care au supraviețuit unui test de stres brutal de 48 de ore al unei reconstruiri de paritate.
3. NICIODATĂ nu faceți clic pe „Inițializați discul”, „Creați un pool nou”, „Ștergeți configurația” sau executați fsck -y / btrfs check --repair pe o matrice prăbușită. Când două unități ies dintr-o matrice RAID 5 simultan (adesea din cauza unei scurte scăderi a sursei de alimentare sau a unui timeout SATA, mai degrabă decât a unei morți fizice adevărate), GUI NAS va marca Pool-ul de stocare ca „Crashed” și va oferi inițializarea sau recrearea volumului. Inițializarea scrie superblocuri și zerouri noi de-a lungul benzilor de paritate, distrugând datele recuperabile. La fel, alergând btrfs check --repair pe un volum Btrfs corupt este notoriu în comunitatea de kernel Linux pentru distrugerea arborelui de măsurare dincolo de recuperare.
4. Opriți imediat toate containerele Docker, mașinile virtuale, serverele media Plex, înregistrările camerelor de supraveghere și scruburile RAID programate. Fiecare operațiune de scriere într-o matrice degradată crește riscul unei găuri de scriere de paritate sau împingerea unei a doua unități marginale peste margine. Conectați-vă la interfața web NAS sau la terminalul SSH și opriți toate serviciile de fundal și sarcinile de I/O ridicate.
5. Dacă orice unitate din NAS emite sunete ritmice de clicuri, bătăi, șlefuit sau țipete, închideți NAS-ul în mod curat chiar acum. O unitate care face clic sau șlefuiește a suferit o prăbușire fizică a capului de citire/scriere (consultați Defecțiunea hard diskului și recuperarea datelor). Lăsând-o să se rotească în interiorul carcasei NAS, platourile magnetice vor deveni praf în câteva minute.
6. Verificați dacă „eșecul NAS” este de fapt doar o placă de bază NAS moartă sau o cărămidă de alimentare externă. Dacă Synology, QNAP sau Asustor NAS nu se pornesc brusc deloc sau clipește la nesfârșit LED-ul albastru de alimentare (cum ar fi faimosul Intel Atom C2000), hard disk-urile și datele sunt aproape sigure. Puteți migra acele unități într-un NAS de înlocuire sau le puteți monta numai în citire pe orice PC desktop Ubuntu Linux folosind porturi SATA standard.

flowchart TD
    A["Bip NAS / matrice RAID raportează starea degradată sau blocată"] --> B{"Sunt unități care fac zgomote mecanice de clicuri, măcinare sau zgârieturi?"}
    B -->|"Da: accident fizic de cap"| C["Opriți imediat NAS, etichetați fiecare unitate cu numărul său Bay și scoateți unitatea care face clic"]
    B -->|"Nu: Funcționare silențioasă"| D{"Care este starea Pool-ului de stocare?"}
    D -->|"DEGRADAT (1 unitate a eșuat, volumul încă citibil)"| E["OPRIȚI toate scrierile Docker/VM/Surveillance și NU faceți clic pe Reconstruire încă"]
    E --> F["Verificați S.M.A.R.T. Atribute (ID 5, 187, 197, 198) pe toate unitățile SURVIVING"]
    F --> G["Conectați unitatea USB externă și copiați mai întâi fișierele critice din pool-ul degradat"]
    G --> H{"Unitățile care au supraviețuit arată sectoare defecte (ID 5 / 197 > 0)?"}
    H -->|"Da: a doua unitate este defectă"| I["Opriți și clonați fiecare unitate cu GNU ddrescue înainte de a încerca orice reconstrucție"]
    H -->|"Nu: supraviețuirea conduce 100% sănătoasă"| J["Introduceți unitatea CMR de schimb (niciodată SMR) și executați Rebuild parity"]
    D -->|"CRASHED / OFFLINE (mai multe unități au fost abandonate)"| K["NU inițializați sau rulați fsck/btrfs --repair; opriți și etichetați toate locașurile de unitate"]
    C --> L["Clonează toate unitățile membre degradate pe unități sănătoase folosind GNU ddrescue + mapfiles"]
    K --> L
    L --> M["Reasamblați unitățile clonate în modul Numai citire prin Linux mdadm/LVM, zpool import -o readonly=on sau UFS Explorer RAID"]

Înțelegerea de ce eșuează reconstrucțiile RAID: capcanele „Lotul unității frate” și „Unitatea SMR”.¶

Pentru a lua decizii sigure în timpul unei urgențe NAS, trebuie să înțelegeți cele două capcane fizice care ucid matricele RAID în timpul recuperării:

Capcana 1: Eșecul lotului corelat și erorile de citire necorectabile (URE)¶

Majoritatea proprietarilor de NAS cumpără toate cele patru sau șase hard disk-uri în aceeași zi de la același comerciant. Acele unități provin de pe aceeași linie de asamblare din fabrică, partajează versiuni identice de firmware, se rotesc exact în același mediu de vibrații ale șasiului și acumulează exact același număr de ore de pornire. * Când Drive 1 moare după 38.000 de ore de funcționare, Drive 2, 3 și 4 sunt, de asemenea, la 38.000 de ore de uzură. * Dacă introduceți o unitate nouă de înlocuire în Bay 1 și faceți clic pe Rebuild pe o matrice RAID 5, controlerul NAS trebuie să citească fiecare sector pe Drive-urile 2, 3 și 4 pentru a calcula XOR blocurile de paritate lipsă pentru Bay 1. * Dacă Drive 3 adăpostește în liniște 14 sectoare dăunătoare imposibil de citit (Current Pending Sectors, S.M.A.R.T. ID 197) într-un folder vechi pe care nu l-ați deschis de doi ani, procesul de reconstrucție se va lovi cu capul în acele sectoare defecte la ora 19. Pe multe dispozitive hardware fără carduri RAID și recuperarea vechilor sisteme RAID (Erori RAID) și NASCTLER. o singură blocare de citire de mai multe secunde determină controlerul să marqueze unitatea 3 ca „Eșuat/Eșuat”, pierzând o a doua unitate dintr-o matrice RAID 5 cu o singură paritate și blocând întregul volum.

Capcana 2: Nu introduceți niciodată o unitate SMR (înregistrare magnetică cu șindrilă) într-o matrice RAID sau ZFS¶

Când cumpărați un hard disk de înlocuire de urgență de la un magazin local de electronice pentru a vă reconstrui NAS-ul, verificați dacă unitatea de schimb folosește CMR (înregistrare magnetică convențională), NICIODATĂ SMR (înregistrare magnetică cu șindrilă). * Hard disk-uri pentru desktop cu buget redus (cum ar fi standard Western Digital Red non-Plus EFAX modelele de la 2 TB la 6 TB, unități desktop Seagate Barracuda Compute și multe unități USB externe ieftine pe care utilizatorii le „scoate” din carcase de plastic) folosesc Drive-Managed SMR, unde pistele magnetice se suprapun ca șindrila acoperișului. * În timpul unei scrieri multi-terabyte RAID sau ZFS resilver, memoria cache media internă a unei unități SMR se umple complet în 30 de minute. Odată ce memoria cache este plină, unitatea SMR se blochează timp de 10 până la 30+ secunde în timp ce citește și rescrie intern benzi întregi, sau returnează un ATA IDNF (Sector ID Not Found) timeout. * Linux mdadm, Synology DSM și în special ZFS (zed) interpretează acele blocaje SMR de 20 de secunde ca pe un hard disk nefuncțional, scotând noua unitate de înlocuire imediat înapoi din matrice în mijlocul reconstrucției. Cumpărați întotdeauna unități CMR NAS/Enterprise (cum ar fi WD Red Plus / WD Red Pro, Seagate IronWolf / IronWolf Pro / Exos sau Toshiba N300 / MG Enterprise).

Matrice de diagnosticare: niveluri RAID, toleranță la erori și reguli de supraviețuire¶

Triare pas cu pas pentru un pool NAS „Degradat” (1 unitate a eșuat, datele încă accesibile)¶

Dacă NAS-ul dvs. emite un bip deoarece 1 unitate dintr-un pool RAID 1, RAID 5, SHR-1, RAID 6 sau RAIDZ a eșuat, urmați exact această secvență înainte de a înlocui discul:

Pasul 1: Audit S.M.A.R.T. mai întâi atributele de pe toate unitățile de supraviețuire¶

Deschideți Storage Manager -> HDD/SSD -> Health Info -> S.M.A.R.T. Atribut (pe Synology/QNAP) sau rulați smartctl -a /dev/sdX prin SSH pe fiecare unitate sănătoasă/online rămasă în piscină. Uită-te la RAW_VALUE coloană pentru aceste patru atribute critice: * ID 5 (Reallocated_Sector_Ct): Ideal ar trebui să fie 0. Dacă o unitate de supraviețuire are zeci sau sute de sectoare realocate, suprafața sau capetele sale se degradează în mod activ. * ID 187 (Reported_Uncorrect): Trebuie să fie 0. * ID 197 (Current_Pending_Sector): CRITIC. Orice număr mai mare decât 0 înseamnă că unitatea de supraviețuire are în prezent sectoare ilizibile care așteaptă să provoace o blocare în momentul în care o reconstrucție RAID încearcă să le citească. * ID 198 (Offline_Uncorrectable): Trebuie să fie 0.

Regula de decizie: * Dacă toate unitățile supraviețuitoare arată 0 pe ID-urile 5, 187, 197 și 198, puteți face copii de siguranță ale folderelor esențiale pe o unitate USB externă și apoi puteți continua cu o GUI NAS normală Reparare/Reconstruire utilizând o unitate de înlocuire CMR sănătoasă. * Dacă orice unitate supraviețuitoare dintr-un pool RAID 5/SHR-1/RAIDZ1 cu paritate unică afișează Current_Pending_Sector > 0 sau escaladare Reallocated_Sector_Ct, NU RELAȚI O RECONSTRUIRE. Copiați imediat toate datele de pe NAS degradat pe unități USB externe, cât timp volumul este încă montat; dacă volumul are deja probleme, opriți NAS-ul și clonați unitățile membre defectuoase pe un PC Linux folosind GNU ddrescue mai întâi.

Salvare pas cu pas atunci când un volum RAID / NAS „se blochează” (mai multe unități au renunțat)¶

Ce se întâmplă dacă te trezești și NAS-ul tău RAID 5 cu 4 locații spune „Storage Pool 1: Crashed” deoarece Drive 2 a eșuat marți seara și Drive 4 a încetat miercuri dimineață?

De ce majoritatea „defecțiunilor cu 2 unități” sunt de fapt recuperabile: Cu excepția cazului în care casa ta a fost lovită de fulger sau NAS-ul a căzut pe scări, două hard disk-uri mecanice aproape niciodată nu suferă prăbușiri totale catastrofale de cap exact în aceeași secundă. În schimb, ceea ce s-a întâmplat de fapt este secvenţial: 1. Drive 2 a dezvoltat câteva sectoare proaste și a fost scos din matrice cu câteva zile sau cu ore mai devreme (lăsând matricea să ruleze în modul Degradat pe unitățile 1, 3 și 4). 2. Mai târziu, Drive 4 a întâlnit un singur sector ilizibil (sau un scurt timp de expirare SATA) în timp ce NAS rula o curățare de fundal. Deoarece matricea nu mai avea redundanță pentru a remedia acel singur sector defect de pe Drive 4, driverul RAID a scos și Drive 4 și a marcat întregul pool Crashed.

În acest scenariu, Drive 4 are cel mai proaspăt contor de evenimente raid de ultimă oră (Events count) și este sănătos în proporție de 99,9999%, în timp ce Drive 2 este ușor depășit ("învechit").

Cum să recuperați un Synology, QNAP sau Linux prăbușit mdadm matrice în siguranță pe un computer Linux¶

Pasul 1: Opriți NAS, etichetați fiecare locaș de unitate și conectați unitățile la un computer desktop care rulează Ubuntu Linux Live USB¶

1. Închideți NAS-ul. Etichetați fiecare unitate (Bay 1, Bay 2, Bay 3, Bay 4).
2. Conectați unitățile la porturile SATA ale plăcii de bază (sau o placă HBA precum un LSI 9211-8i/9300-8i în modul IT; evitați hub-urile USB ieftine care se deconectează sub sarcină) pe un computer desktop pornit într-un Ubuntu Linux Live USB.
3. Deschideți un terminal și inspectați aspectul partiției și mdadm superblocuri strict în modul de diagnosticare numai în citire:

# List all connected drives and partitions without mounting anything
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE

# Inspect the Linux Software RAID (mdadm) superblock metadata on the data partitions
# Note: On Synology DSM, Partition 1 is Root OS, Partition 2 is Swap, and Partition 3 (or 5) is your User Data array (e.g., /dev/sda3, /dev/sdb3, /dev/sdc3, /dev/sdd3)
sudo mdadm --examine /dev/sd[a-d]3

Pasul 2: Citiți Events contor şi Array State ieșire din mdadm --examine¶

Privește cu atenție rezultatul sudo mdadm --examine /dev/sd[a-d]3 pentru fiecare unitate: * Veți vedea linii precum: * /dev/sda3: Events : 48210, Array State : A.AA (A = activ, . = Lipsă) * /dev/sdb3 (Drive 2, a abandonat primul): Events : 47950, Array State : AAAA * /dev/sdc3: Events : 48210, Array State : A.AA * /dev/sdd3 (Drive 4, ultimul abandonat): Events : 48209, Array State : A.AA * Observați ce Events contorul vă spune: Unitățile 1, 3 și 4 (sda3, sdc3, sdd3) sunt la 1 eveniment unul de celălalt (48210 vs 48209), în timp ce Drive 2 (sdb3) a căzut mult mai devreme la eveniment 47950. * Regulă critică: într-o matrice RAID 5 cu 4 unități, aveți nevoie doar de 3 unități pentru a reconstrui 100% din date. TREBUIE să asamblați matricea folosind 3 cele mai noi unități (sda3, sdc3, și sdd3) și omite unitatea învechită (sdb3). Dacă accidental forțați asamblarea folosind vechea unitate veche (sdb3), metadatele sistemului de fișiere de acum două zile nu se potrivesc cu benzile de date curente de pe celelalte unități și vă vor deteriora folderele.

Pasul 3: Clonează orice unitate cu sectoare defecte folosind GNU ddrescue mai întâi¶

Înainte de asamblare, clonați unitatea recent căzută (/dev/sdd) (și, în mod ideal, toate unitățile membre) la o unitate de înlocuire sănătoasă folosind ddrescue (vezi Defecțiunea hard diskului și recuperarea datelor pentru plin ddrescue sintaxa):

# Clone the dropped drive (/dev/sdd) to a healthy new spare drive (/dev/sde) with a mapfile
sudo ddrescue -f -n /dev/sdd /dev/sde /root/drive4_clone.map
sudo ddrescue -d -f -r3 /dev/sdd /dev/sde /root/drive4_clone.map

Acum deconectați defecțiunea originală /dev/sdd și puneți-l în siguranță pe un raft, astfel încât să lucrați cu clona sănătoasă (/dev/sde).

Pasul 4: Reasamblați matricea RAID, grupul de volume LVM și sistemul de fișiere în modul strict READ-ONLY¶

Pe sistemele Synology (SHR / RAID) și QNAP, stiva de stocare are până la trei straturi: mdadm (RAID) -> LVM2 (Manager de volum logic) -> ext4 sau Btrfs (Sistem de fișiere). Iată secvența exactă de comandă pentru a le monta în siguranță în modul numai citire pe Ubuntu:

# Install mdadm, lvm2, and btrfs-progs inside the Ubuntu Live environment
sudo apt update && sudo apt install -y mdadm lvm2 btrfs-progs

# Stop any partial auto-assembled md arrays first
sudo mdadm --stop --scan

# Assemble the 3 freshest RAID 5 partitions in READ-ONLY mode (using --force ONLY if the 3rd drive's event count is off by 1-2 events, on the cloned drive)
sudo mdadm --assemble --readonly --run /dev/md127 /dev/sda3 /dev/sdc3 /dev/sde3

# Check that /dev/md127 is now active (even in degraded [UU_U] read-only state)
cat /proc/mdstat

# Activate the LVM Volume Group in read-only mode
sudo vgchange -ay --readonly

# List the discovered Logical Volumes (look for /dev/vg1000/lv or /dev/vg1/volume_1)
sudo lvs

# Create a mount point and mount the Logical Volume strictly READ-ONLY (-o ro,noload for ext4 or -o ro,norecovery for Btrfs)
sudo mkdir -p /mnt/nas_rescue

# For ext4 volumes:
sudo mount -o ro,noload /dev/vg1000/lv /mnt/nas_rescue

# OR for Btrfs volumes (such as Synology Btrfs pools):
sudo mount -o ro,norecovery /dev/vg1000/lv /mnt/nas_rescue

Odată /mnt/nas_rescue monturi, toate folderele dvs. partajate NAS (photo, homes, video, documents) va apărea în interior /mnt/nas_rescue/ astfel încât să le puteți copia direct pe o unitate externă de rezervă USB.

• ** Ce se întâmplă dacă Synology NAS ar avea „Synology Hybrid RAID (SHR)” cu dimensiuni de unități mixte?** Synology SHR împarte pur și simplu unitățile mai mari în mai multe partiții (sda5, sda6) și creează un separat mdadm matrice pe fiecare nivel de partiție, apoi le unește md matrice împreună într-un singur ** Grup de volum LVM (vg1000)**. Alergarea sudo mdadm --assemble --scan --readonly şi sudo vgchange -ay reunește automat volumele SHR pe mai multe niveluri pe Ubuntu.
• Alternativă GUI comercială (Windows/macOS/Linux): Dacă nu sunteți confortabil cu comenzile terminalelor Linux sau aveți un pool LVM QNAP complex, UFS Explorer RAID Recovery sau ReclaiMe Free RAID Recovery poate inspecta toate unitățile NAS conectate pe un PC Windows sau Linux în modul 100%, software-ul de rotație și modul de citire automată a parității offset-uri și copiați folderele fără a modifica un singur sector de pe unitățile NAS.

ZFS (zpool) și comenzile de salvare de urgență Btrfs¶

Platformele NAS moderne (TrueNAS SCALE/CORE, Proxmox, Ubuntu Server, Unraid și volume Synology Btrfs) folosesc tot mai mult sisteme de fișiere copy-on-write (CoW) în loc de vechi. ext4. Dacă un ZFS zpool sau Btrfs pool refuză să se monteze sau provoacă o panică a kernelului la pornire după o întrerupere de curent sau o defecțiune a unității, montarea normală va eșua deoarece sistemul de operare încearcă să reia tranzacțiile de scriere deteriorate. Trebuie să utilizați parametrii de returnare a tranzacțiilor numai pentru citire.

1. ZFS (zpool) Recuperare de urgență (TrueNAS / Proxmox / Linux ZFS)¶

Dacă un pool ZFS afirmă FAULTED, UNAVAIL, sau blochează serverul (panica nucleului) în momentul în care încercați să-l importați după o pierdere de energie necurată:

# 1. Inspect all visible ZFS pools on the connected disks without importing them
sudo zpool import

# 2. ALWAYS attempt a Read-Only Import first (prevents ZFS from writing to disks or replaying the ZIL/SLOG)
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 3. What if a normal import causes a kernel panic or says 'damaged pool metadata'?
# Use -F (Rollback/Recovery Mode) with -n (Dry Run ONLY) to see if ZFS can rewind the last few seconds of corrupted Transaction Groups (TXGs):
sudo zpool import -F -n <pool_name>

# 4. Combine Read-Only + Safe Transaction Group Rewind (-F -o readonly=on) so no disk sectors are altered while you copy your data off:
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 5. For heavily damaged pools where Space Map allocation tables are corrupt, disable space map loading prior to read-only import:
echo 1 | sudo tee /sys/module/zfs/parameters/zfs_recover
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

Odată montat sub /mnt/zfs_rescue, copiați-vă seturile de date folosind rsync sau zfs send înainte de a încerca vreodată să importați pool-ul de citire-scriere.

2. Recuperare de urgență Btrfs (Synology Btrfs / Unraid Cache Pool / Linux Btrfs)¶

În schimb, încercați să montați sau să extrageți volumul Btrfs în ordine progresivă strictă, de la scanarea cea mai puțin invazivă la cea mai profundă:

# Stage 1: Mount Read-Only without replaying the corrupted Journal Log Tree (fixes 80% of power-loss Btrfs mount failures)
sudo mount -t btrfs -o ro,norecovery /dev/sdX1 /mnt/btrfs_rescue
# (Note: on newer Linux kernels 5.11+, use: -o ro,rescue=nologreplay)

# Stage 2: Mount Read-Only using the backup Root Tree + ignoring bad checksums (for multi-drive or bit-rot corruption)
sudo mount -t btrfs -o ro,rescue=all /dev/sdX1 /mnt/btrfs_rescue
# (On older kernels: sudo mount -t btrfs -o ro,usebackuproot,nologreplay,degraded /dev/sdX1 /mnt/btrfs_rescue)

# Stage 3: If the volume still refuses to mount in the kernel, extract files directly in userspace without mounting using 'btrfs restore'
# First, list available backup tree roots:
sudo btrfs-find-root /dev/sdX1

# Then run 'btrfs restore' (strictly read-only userspace extractor) to dump all files to an external healthy drive:
sudo btrfs restore -v -i -m -S /dev/sdX1 /mnt/external_usb_backup/

Situații de urgență pentru controlerul RAID hardware: „Configurație străină” și carduri RAID moarte¶

Serverele de întreprindere (Dell PowerEdge cu carduri PERC, HPE ProLiant cu Smart Array, Lenovo ThinkSystem sau stațiile de lucru cu controlere Broadcom/LSI MegaRAID) folosesc carduri RAID hardware cu NVRAM la bord și cache pentru baterie/supercondensator (BBU / CacheVault).

1. Importați configurație străină vs. configurație clară (CRITIC)¶

Când o unitate se deconectează momentan sau mutați unități într-un șasiu de server de înlocuire, ecranul de pornire Dell PERC sau LSI MegaRAID BIOS se va întrerupe și va anunța: „Configurații străine găsite pe adaptor.” * ** ÎNTOTDEAUNA selectați Import Foreign Configuration (sau Preview Foreign Configuration -> Import).** Eticheta „Străin” înseamnă pur și simplu că controlerul RAID vede metadate RAID existente valide scrise pe hard disk-urile în sine (sectoarele de configurare Disk Data Format / DDF sau LSI de la sfârșitul unităților) care diferă de starea curentă a NVRAM a plăcii. Importul citește aspectul matricei direct de pe unități și readuce discul virtual online fără a pierde niciun octet. * NICIODATĂ selectați Clear Foreign Configuration sau Initialize Virtual Disk. Ștergerea sau inițializarea șterge metadatele matricei sau pune la zero unitățile. * Avertisment de excepție: Dacă o singură unitate a încetat în urmă cu trei săptămâni, ați continuat să scrieți date noi în matricea degradată timp de trei săptămâni, apoi ați conectat din nou acea unitate veche și veche de 3 săptămâni, NU importați configurația străină de pe acea unitate unică învechită peste unitățile active sănătoase; în schimb, înlocuiți sau clonați unitatea veche.

2. Ce se întâmplă dacă placa hardware RAID în sine moare?¶

Dacă placa de bază a serverului sau placa de control hardware PCIe RAID suferă o defecțiune electronică și nu va porni: * NU trebuie să cumpărați exact aceeași versiune a plăcii de bază, iar datele dvs. sunt încă intacte pe unități. * Achiziționați un controler RAID de schimb din aceeași familie de chipset-uri de controler (de exemplu, orice card LSI/Broadcom MegaRAID SAS 2108/2208/3108 sau Dell PERC H710/H730/H740 poate citi metadatele DDF de pe un card PERC mai vechi). * Instalați placa RAID de schimb într-un computer funcțional, conectați unitățile etichetate în ordinea inițială a locașurilor, porniți în BIOS-ul controlerului (Ctrl+R sau Ctrl+H sau UEFI HII) și selectați Import Foreign Configuration. Controlerul va citi aspectul RAID de pe unități și va monta volumul imediat.

Întrebări frecvente¶

Ghiduri aferente¶

• Defecțiunea hard diskului și recuperarea datelor
• Ștergerea accidentală a fișierelor, unitatea formatată și recuperarea fotografiilor
• Backup-uri pe computer: strategie 3-2-1 și recuperare în caz de dezastru
• Eșecul de pornire a sistemului Linux și repararea GRUB
• Răspuns de urgență pentru ransomware și malware
• Numere globale de urgență

Surse verificate¶

• Linux Kernel Organization (Internațional): Linux RAID (mdadm) Wiki (raid.wiki.kernel.org), Recuperarea unui RAID software eșuat și Documentația Btrfs Kernel (btrfs.readthedocs.io pe btrfs rescue şi btrfs restore).
• Proiect de documentare OpenZFS (internațional): zpool import Numai citire și derularea grupului de tranzacții (-F -o readonly=on) Referință de administrare.
• Synology Inc. (Taiwan/International): articol oficial din baza de cunoștințe Synology KB-1079 (Cum pot folosi un computer pentru a recupera date atunci când Synology NAS funcționează defectuos utilizând Ubuntu mdadm şi lvm2).
• Proiect GNU / Free Software Foundation (Internațional): GNU ddrescue Manual pentru imagistica nedistructivă la nivel de bloc a unităților membre RAID degradate.
• Institutul Național de Standarde și Tehnologie (NIST) (Statele Unite ale Americii): Publicația specială 800-86 și Ghidul privind fiabilitatea stocării pentru Windows de expunere la reconstrucție RAID și probabilități de eroare de citire necorecabilă (URE).