Nu se poate monta un sistem de fișiere XFS din matricea Linux RAID6 ("Log inconsistent")

Afiș pentru prima dată - scuzele mele dacă nu înțeleg corect eticheta.

Am o matrice RAID6 de ~200TB cu 30 de discuri și nu reușesc să o montez - am primit doar mesajul:

montați /dev/md125 /export/models
mount:/dev/md125: nu pot citi superblock

Dacă fug mdadm --detaliu pe ea, arată ca curat:

/dev/md125:
           Versiune: 1.2
     Ora creării: miercuri 13 sept 15:09:40 2017
        Nivel raid: raid6
        Dimensiunea matricei: 218789036032 (203,76 TiB 224,04 TB)
     Dimensiune Dev folosită: 7813894144 (7,28 TiB 8,00 TB)
      Dispozitive raid: 30
     Total dispozitive: 30
       Persistență: Superblocul este persistent

     Bitmap intenție: intern

       Ora actualizării: vineri, 20 mai, 23:54:52 2022
             Stare: curat
    Dispozitive active: 30
   Dispozitive de lucru: 30
    Dispozitive eșuate: 0
     Dispozitive de rezervă: 0

            Aspect: stânga-simetric
        Dimensiune bucată: 512K

Politica de consistență: bitmap

              Nume: localhost.localdomain:SW-RAID6
              UUID: f9b65f55:5f257add:1140ccc0:46ca6c19
            Evenimente: 1152436

    Număr Major Minor Raid Starea dispozitivului
       0 8 1 0 sincronizare activă /dev/sda1
       1 65 161 1 sincronizare activă /dev/sdaa1
       2 65 177 2 sincronizare activă /dev/sdab1
       3 65 193 3 sincronizare activă /dev/sdac1
       4 65 209 4 sincronizare activă /dev/sdad1
       5 8 17 5 sincronizare activă /dev/sdb1
       6 8 33 6 sincronizare activă /dev/sdc1
       7 8 49 7 sincronizare activă /dev/sdd1
       8 8 65 8 sincronizare activă /dev/sde1
       9 8 81 9 sincronizare activă /dev/sdf1
      10 8 97 10 sincronizare activă /dev/sdg1
      11 8 113 11 sincronizare activă /dev/sdh1
      12 8 129 12 sincronizare activă /dev/sdi1
      13 8 145 13 sincronizare activă /dev/sdj1
      14 8 161 14 sincronizare activă /dev/sdk1
      15 8 177 15 sincronizare activă /dev/sdl1
      16 8 193 16 sincronizare activă /dev/sdm1
      17 8 209 17 sincronizare activă /dev/sdn1
      18 8 225 18 sincronizare activă /dev/sdo1
      19 8 241 19 sincronizare activă /dev/sdp1
      20 65 1 20 sincronizare activă /dev/sdq1
      21 65 17 21 sincronizare activă /dev/sdr1
      22 65 33 22 sincronizare activă /dev/sds1
      23 65 49 23 sincronizare activă /dev/sdt1
      24 65 65 24 sincronizare activă /dev/sdu1
      25 65 81 25 sincronizare activă /dev/sdv1
      26 65 97 26 sincronizare activă /dev/sdw1
      27 65 113 27 sincronizare activă /dev/sdx1
      28 65 129 28 sincronizare activă /dev/sdy1
      29 65 145 29 sincronizare activă /dev/sdz1

cat /proc/stat spectacole:

[root@knox ~]# cat /proc/mdstat
Personalități: [raid1] [raid6] [raid5] [raid4]
md125 : raid6 activ sdo1[18] sdh1[11] sdad1[4] sdd1[7] sdb1[5] sdi1[12] sdt1[23] sdr1[21] sdp1[19] sdx1[27] sd[10] sdg 17] sdm1[16] sdab1[2] sdu1[24] sdl1[15] sde1[8] sdf1[9] sdw1[26] sdc1[6] sdq1[20] sdy1[28] sds1[22] sds1[22] sdac1[3] sdz1[29] sdaa1[1] sda1[0] sdj1[13] sdk1[14]
      218789036032 blocuri super 1.2 nivel 6, 512k chunk, algoritm 2 [30/30] [UUUUUUUUUUUUUUUUUUUUUUUUUUUU]
      bitmap: 0/59 pagini [0KB], 65536KB bucată

md126: raid1 activ sdae3[0] sdaf2[1]
      976832 blocuri super 1.0 [2/2] [UU]
      bitmap: 0/1 pagini [0KB], bucată de 65536KB

md127: raid1 activ sdaf1[1] sdae1[0]
      100554752 blocuri super 1.2 [2/2] [UU]
      bitmap: 1/1 pagină [4KB], bucată de 65536KB

dispozitive nefolosite: <niciunul>

Examina pe dispozitivele individuale arată, de asemenea, ca sănătos (nu am inclus rezultatele pentru toate, deoarece ar ocupa prea mult spațiu, dar sunt toate la fel ca acesta):

/dev/sda1:
          Magie: a92b4efc
        Versiune: 1.2
    Hartă caracteristică: 0x1
     UUID matrice: f9b65f55:5f257add:1140ccc0:46ca6c19
           Nume: localhost.localdomain:SW-RAID6
  Ora creării: miercuri 13 sept 15:09:40 2017
     Nivel raid: raid6
   Dispozitive raid: 30

 Dimensiune Dev disponibil: 15627788288 sectoare (7,28 TiB 8,00 TB)
     Dimensiunea matricei: 218789036032 KiB (203,76 TiB 224,04 TB)
    Offset de date: 262144 sectoare
   Super Offset: 8 sectoare
   Spațiu nefolosit: înainte=262056 sectoare, după=0 sectoare
          Stare: curat
    UUID dispozitiv: 917e739e:36fa7cf6:c618d73c:43fb7dec

Bitmap intern: 8 sectoare din superbloc
    Ora actualizării: vineri, 20 mai, 23:54:52 2022
  Bad Block Log: 512 intrări disponibile la offset 72 de sectoare
       Sumă de control: 2b5e9556 - corect
         Evenimente: 1152436

         Aspect: stânga-simetric
     Dimensiune bucată: 512K

   Rolul dispozitivului: dispozitiv activ 0
   Starea matricei: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA („A” == activ, „.” == lipsește, „R” == înlocuire)

Intrările relevante din dmesg arată:

[13297.001208] XFS (md125): Montarea sistemului de fișiere V5
[13297.008854] XFS (md125): jurnal inconsecvent (nu a găsit antetul anterior)
[13297.008874] XFS (md125): nu s-a găsit capul jurnalului
[13297.008878] XFS (md125): montarea/recuperarea jurnalului a eșuat: eroare -5
[13297.008934] XFS (md125): montarea jurnalului a eșuat

Contextul este destul de lung și complicat, dar versiunea scurtă este că am încercat să măresc matricea cu adăugarea unui disc suplimentar și operațiunea a fost întreruptă. În cele din urmă, matricea a fost reconstruită, remodelând-o înapoi la cele 30 de discuri originale (care a durat două săptămâni!), dar acum nu vrea să se monteze.

Din păcate, nu este făcută o copie de rezervă (mă refer la unde faci copii de rezervă pentru 200TB?!?!). Nimic de valoare nu trebuia să fie stocat aici, dar, ființele umane, ceea ce sunt, unele lucruri esențiale au fost stocate acolo.

M-am uitat la xfs_repair dar nu sunt sigur dacă ar trebui să-l rulez pe matricea RAID (md125) sau pe dispozitivele sd* individuale.

Mulțumiri

Actualizare (istoria din spatele tuturor):

Dispozitivul este un server SuperMicro care rulează CentOS 7 (3.10.0-1160.11.1.e17.x86_64) cu versiunea 4.1 – 2018-10-01 de mdadm cu disc de 30 x 8TB într-o configurație RAID6. Are, de asemenea, boot și root pe 2 matrice RAID1 â matricea RAID6 fiind exclusiv pentru date. Nu mai avea spațiu, așa că am decis să adăugăm mai multe unități la matrice (poate găzdui un total de 45 de unități).

Deoarece discul original din matrice erau unități de 4kN și dispozitivele furnizate erau 512e, a fost necesar să le reformatați cu sg_format pentru a le converti (o procedură acceptată de Western Digital). Am început cu un singur disc ca test. Din păcate, procesul a fost întrerupt parțial, așa că l-am repornit și am terminat OK, un fel de... a convertit discul la 4096k, dar a generat o eroare I/O sau două, dar nu mi s-a părut prea îngrijorător și am m-am gândit că, dacă ar exista o problemă, aceasta va apărea în următorii doi pași. De atunci am descoperit jurnalul dmesg și asta a indicat că au existat semnificativ mai multe erori I/O decât credeam.

Oricum, din moment ce sg_format părea să se termine OK, am trecut la următoarea etapă care a fost să partiționez discul cu următoarele comenzi

     parted -a optim /dev/sd<x>
     (despărțit) mklabel msdos
     (despărțit) mkpart primary 2048s 100% (trebuie să verificați dacă pornirea este corectă)
     (separat) align-check optim 1 (verificați alinierea partiției 1)
     (despărțit) activați 1 raid (setați FLAG la RAID)
     (despărțit) imprimare

Apoi am adăugat noul disc la matrice:

     mdadm --add /dev/md125 /dev/sd<x>

Și s-a finalizat fără probleme.

Apoi am continuat să măresc matricea:

     mdadm --grow --raid-devices=31 --backup-file=/grow_md125.bak /dev/md125

Am monitorizat acest lucru cu cat /proc/mdstat și a arătat că se remodelează, dar viteza a fost de 0K/sec și remodelarea nu a progresat de la 0%.

Aproximativ 12 ore mai târziu, deoarece remodelarea nu progresase de la 0%, am căutat modalități de a o anula, cum ar fi mdadm --stop /dev/md125, care nu a funcționat, așa că am ajuns să repornesc serverul.

Serverul a apărut în modul de urgență.

Am putut să mă conectez ca root OK, dar matricea RAID6 a rămas blocată în starea de remodelare.

apoi am incercat mdadm --assemble --update=revert-reshape --backup-file=/grow_md125.bak --verbose --uuid= f9b65f55:5f257add:1140ccc0:46ca6c19 /dev/md125 si asta a produs:

     mdadm: Nu s-a găsit niciun super bloc pe /dev/sde (Magie așteptată a92b4efc, a primit <numere variabile>
     mdadm: Fără superbloc RAID pe /dev/sde
     .
     .
     mdadm: /dev/sde1 este identificat ca membru al /dev/md125, slotul 6
     .
     .
     mdadm: /dev/md125 are o remodelare activă - verificând dacă secțiunea critică trebuie restaurată
     mdadm: Nu există metadate de rezervă pe /grow_md125.back
     mdadm: Nu s-a găsit o copie de rezervă a secțiunii critice
     mdadm: Nu s-a restabilit secțiunea critică pentru remodelare, îmi pare rău.

Am încercat variații diferențiate, inclusiv mdadm --assemble --invalid-backup --force toate fără niciun rezultat.

În acest moment, am eliminat și discul suspect, dar acest lucru nu a făcut nicio diferență.

Dar cel mai aproape am ajuns să repar asta este să ruleze mdadm /dev/md125 --assemble --invalid-backup --backup-file=/grow_md125.bak --verbose /dev/sdc1 /dev/sdd1 ....... /dev/sdaf1 si asta produce:

     mdadm: /dev/sdaf1 este identificat ca membru al /dev/md125, slotul 4.
     mdadm: /dev/md125 are o remodelare activă - verificând dacă secțiunea critică trebuie restaurată
     mdadm: Nu există metadate de rezervă pe /grow_md125.back
     mdadm: Nu s-a găsit o copie de rezervă a secțiunii critice
     mdadm: continuă fără restaurarea copiei de rezervă
     mdadm: adăugat /dev/sdac1 la /dev/md125 ca 1
     .
     .
     .
     mdadm: RUN_ARRAY eșuat /dev/md125: Argument nevalid

dmesg are aceste informatii:

     md: md125 oprit.
     md/raid:md125: reshape_position prea devreme pentru recuperare automată - se anulează.
     md: pers->run() a eșuat...
     md: md125 oprit.

Deoarece toate cele de mai sus, am pornit de pe un CD de salvare și am putut să-l remodelez înapoi la cele 30 de dispozitive originale și am pornit din nou în instalarea nativă (a trebuit să remarc această matrice de la fstab pentru a face acest lucru).

Vreau să extind sugestiile de mai sus.

Este extrem de meritat configurarea dispozitivului de blocare suprapusă, astfel încât orice modificare a sistemului de fișiere pe care o veți face în încercarea de a-l recupera nu va schimba nimic pe RAID și acest lucru vă va permite să resetați totul și să începeți de la început. Prin urmare, vi se va da un număr infinit de încercări, eliberând astfel presiunea psihologică.

Am făcut asta cu Qemu's qemu-nbd, Linux nbd.ko (driverul de dispozitiv Network Block) și fișierul de suprapunere qcow2.

1. Conectați un disc suplimentar unde va fi stocată suprapunerea. Încărcați driverul NBD. Montați discul dvs. scratch undeva:

modprobe nbd
montați /dev/sdXXN /tmp/overlay

2. Creați un fișier de suprapunere qcow2:

qemu-img create -f qcow2 -b /dev/md125 -F brut /tmp/overlay/attempt1.qcow2

3. Creați un dispozitiv bloc din fișierul suprapus folosind qemu-nbd:

qemu-nbd -c /dev/nbd0 /tmp/overlay/attempt1.qcow2

Acum ai un /dev/nbd0 care este o „clonă care poate fi scrisă” a matricei dumneavoastră. Puteți scrie în siguranță pe acest dispozitiv, orice modificări vor fi scrise /tmp/overlay/attempt1.qcow2. Deci, de exemplu, când încercați sfatul lui @shodanshok, aplicați-l la /dev/nbd0.

4. Dacă ați rămas blocat, deconectați suprapunerea și eliminați fișierul suprapus

qemu-nbd -d /dev/nbd0
rm /tmp/overlay/attempt1.qcow2

Apoi repetați totul de la pasul (2). Alternativ, puteți crea atâtea suprapuneri cât spațiu și /dev/nbdX dispozitivele permit (eu am 16 dintre ele, de exemplu) și funcționează în paralel. Toate acestea ar trebui să folosească diferite imagini suprapuse, desigur. Acest lucru este util dacă se întâmplă să recuperați doar date parțiale într-o încercare și cealaltă parte a datelor într-o altă încercare.

Când lucrați cu clone ale sistemului de fișiere XFS, amintiți-vă că fiecare dintre ele ar trebui să aibă un UUID distinct.

Când (dacă) este găsită calea de recuperare corectă, aceasta poate fi reaplicată dispozitivului brut, „recuperând ireversibil sistemul de fișiere”, sau puteți închiria spațiu, descărcați datele recuperate acolo din NBD-uri suprapuse, recreați RAID și sistemul de fișiere și descărcați-l înapoi.

Știu, este greu și greoi. Acesta este motivul pentru care organizațiile de recuperare de date taxează mult atunci când lucrează cu RAID-uri. Când îl încercați singur, veți fi de acord că aceste facturi nu sunt atât de umflate pe cât ar putea părea la prima vedere.

Și repet că din nou, RAID6 de 30 de dispozitive este o durere. Mai bine au de ex. 3 matrice RAID6 a câte 10 unități fiecare, apoi uniți-le împreună folosind MD RAID 0 sau LVM stratificat. Acest lucru va face lucrurile mai ușor de gestionat, iar operațiunile de remodelare/verificare nu vor dura săptămâni. Da, faci verificări de consistență RAID (scrubbing) în mod regulat, cel puțin o dată la două luni, nu-i așa?

Actualizați: Există informații valoroase în comentarii, care merită adăugate aici.

• Mă îndoiesc că lucrurile qemu vor fi disponibile în Synology DSM. Dar puteți conecta discuri la un computer obișnuit cu Linux și puteți continua. Sau încercați să porniți Synology din rețea sau LiveUSB – NAS care poate conecta 30 de discuri este practic un computer obișnuit amd64 montabil în rack. â

• @Mark sugerează o altă modalitate de a crea o suprapunere:

@Bob, există și alte opțiuni pentru a crea o suprapunere â Am folosit o unitate USB și pașii de la https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID

Mod frumos, care folosește cadrul Device Mapper, probabil să fie prezent în DSM! De asemenea, este probabil mai rapid decât abordarea mea. Este dmsetup comanda care creează dispozitivul virtual cu un fișier suprapus rar. Cu toate acestea, deoarece matricea RAID în sine pare curată în cazul dvs. și tot ce vorbim despre remedierea unui sistem de fișiere, vă sugerez să creați o suprapunere a unei matrice asamblate (/dev/md125) mai degrabă decât a componentelor matricei individuale.

Buștenii

[13297.001208] XFS (md125): Montarea sistemului de fișiere V5
[13297.008854] XFS (md125): jurnal inconsecvent (nu a găsit antetul anterior)
[13297.008874] XFS (md125): nu s-a găsit capul jurnalului
[13297.008878] XFS (md125): montarea/recuperarea jurnalului a eșuat: eroare -5
[13297.008934] XFS (md125): montarea jurnalului a eșuat

fă-mă să cred că remodelarea întreruptă a „amestecat” numărul LBA, astfel încât XFS să nu-și găsească jurnalul de intenții.Aceasta înseamnă probabil o mare corupție, așa cum au spus deja alții, opriți-vă aici și contactați un serviciu profesional de recuperare de date.

Dacă acest lucru nu este posibil, aș încerca o ultimă încercare ignorând jurnalul XFS cu ceva ca mount -o ro,norecovery /dev/md125 /export/models dar în caz foarte improbabil dacă funcționează, fiți pregătiți pentru coruperea extinsă a datelor.

Din nou, dacă a stocat date critice, contactați o firmă de recuperare de date înainte de a face ceva.