Vraag ZFS op FreeBSD: herstel van datacorruptie


Ik heb verschillende TB's met zeer waardevolle persoonlijke gegevens in een zpool, waar ik geen toegang toe heb vanwege data corruptie. Het zwembad is oorspronkelijk in 2009 of later opgezet op een FreeBSD 7.2-systeem dat draait in een virtuele VMWare-machine bovenop een Ubuntu 8.04-systeem. De FreeBSD VM is nog steeds beschikbaar en werkt prima, alleen het host-besturingssysteem is nu gewijzigd in Debian 6. De harde schijven worden toegankelijk gemaakt voor de gast-VM met behulp van generieke SCSI-apparaten van VMWare, 12 in totaal.

Er zijn 2 zwembaden:

  • zpool01: 2x 4x 500GB
  • zpool02: 1x 4x 160GB

Degene die werkt is leeg, de kapotte bevat alle belangrijke gegevens:

[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
  Fri May  1 07:18:07 UTC 2009                          \
  root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6

[user@host ~]$ sudo zpool status
  pool: zpool01
 state: UNAVAIL
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool01     UNAVAIL      0     0     0  insufficient replicas
      raidz1    UNAVAIL      0     0     0  corrupted data
        da5     ONLINE       0     0     0
        da6     ONLINE       0     0     0
        da7     ONLINE       0     0     0
        da8     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da1     ONLINE       0     0     0
        da2     ONLINE       0     0     0
        da3     ONLINE       0     0     0
        da4     ONLINE       0     0     0

  pool: zpool02
 state: ONLINE
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool02     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da9     ONLINE       0     0     0
        da10    ONLINE       0     0     0
        da11    ONLINE       0     0     0
        da12    ONLINE       0     0     0

errors: No known data errors

Ik heb een paar weken geleden toegang gekregen tot het zwembad. Sindsdien moest ik vrijwel alle hardware van de host-machine vervangen en verschillende host-besturingssystemen installeren.

Mijn vermoeden is dat een van deze OS-installaties een bootloader (of wat dan ook) schreef naar een (de eerste?) Van de 500GB-schijven en sommige zpool-metadata (of wat dan ook) vernietigde - wat betekent dat dit slechts een heel vaag idee is en dat onderwerp is niet bepaald mijn sterke kant ...


Er zijn tal van websites, blogs, mailinglijsten, etc. over ZFS. Ik post deze vraag hier in de hoop dat het me helpt om voldoende informatie te verzamelen voor een gezonde, gestructureerde, gecontroleerde, geïnformeerde en deskundige manier om mijn gegevens terug te krijgen - en hopelijk iemand anders in dezelfde situatie te helpen.


Het eerste zoekresultaat bij het googlen naar 'zfs herstellen' is het ZFS-probleemoplossing en gegevensherstel hoofdstuk uit de Solaris ZFS-beheerdershandleiding. In de eerste ZFS-foutmodes sectie, staat er in de paragraaf 'Beschadigde ZFS-gegevens':

Datacorruptie is altijd permanent en vereist speciale aandacht tijdens de reparatie. Zelfs als de onderliggende apparaten worden gerepareerd of vervangen, gaan de originele gegevens voor altijd verloren.

Enigszins ontmoedigend.

Het tweede Google-zoekresultaat is echter Max Bruning's weblog en daar lees ik

Onlangs kreeg ik een e-mail van iemand die 15 jaar video en muziek had opgeslagen in een 10 TB ZFS-pool die na een stroomstoring defect was geraakt. Hij had helaas geen back-up. Hij gebruikte ZFS versie 6 op FreeBSD 7     [...]   Nadat ik ongeveer een week besteed had aan het onderzoeken van de gegevens op de schijf, kon ik dit in wezen allemaal herstellen.

en

Wat betreft het verlies van uw gegevens door ZFS, betwijfel ik het. Ik vermoed dat je gegevens er zijn, maar je moet de juiste manier vinden om ermee aan de slag te gaan.

(dat klinkt zoveel meer als iets dat ik wil horen ...)

Eerste stap: Wat is precies het probleem?

Hoe kan ik vaststellen waarom de zpool precies als corrupt is gerapporteerd? Ik zie dat er zdb is, dat niet overal op het web officieel door Sun of Oracle gedocumenteerd lijkt te zijn. Van zijn manpagina:

NAME
       zdb - ZFS debugger

SYNOPSIS
       zdb pool

DESCRIPTION
       The  zdb  command is used by support engineers to diagnose failures and
       gather statistics. Since the ZFS file system is  always  consistent  on
       disk  and is self-repairing, zdb should only be run under the direction
       by a support engineer.

       If no arguments are specified, zdb, performs basic  consistency  checks
       on  the pool and associated datasets, and report any problems detected.

       Any options supported by this command are internal to Sun  and  subject
       to change at any time.

Verder heeft Ben Rockwood een geplaatst gedetailleerd artikel en er is een video-van Max Bruning erover (en mdb) op de Open Solaris Developer Conference in Praag op 28 juni 2008.

Het uitvoeren van zdb als root op de gebroken zpool geeft de volgende uitvoer:

[user@host ~]$ sudo zdb zpool01
    version=6
    name='zpool01'
    state=0
    txg=83216
    pool_guid=16471197341102820829
    hostid=3885370542
    hostname='host.domain'
    vdev_tree
        type='root'
        id=0
        guid=16471197341102820829
        children[0]
                type='raidz'
                id=0
                guid=48739167677596410
                nparity=1
                metaslab_array=14
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=4795262086800816238
                        path='/dev/da5'
                        whole_disk=0
                        DTL=202
                children[1]
                        type='disk'
                        id=1
                        guid=16218262712375173260
                        path='/dev/da6'
                        whole_disk=0
                        DTL=201
                children[2]
                        type='disk'
                        id=2
                        guid=15597847700365748450
                        path='/dev/da7'
                        whole_disk=0
                        DTL=200
                children[3]
                        type='disk'
                        id=3
                        guid=9839399967725049819
                        path='/dev/da8'
                        whole_disk=0
                        DTL=199
        children[1]
                type='raidz'
                id=1
                guid=8910308849729789724
                nparity=1
                metaslab_array=119
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=5438331695267373463
                        path='/dev/da1'
                        whole_disk=0
                        DTL=198
                children[1]
                        type='disk'
                        id=1
                        guid=2722163893739409369
                        path='/dev/da2'
                        whole_disk=0
                        DTL=197
                children[2]
                        type='disk'
                        id=2
                        guid=11729319950433483953
                        path='/dev/da3'
                        whole_disk=0
                        DTL=196
                children[3]
                        type='disk'
                        id=3
                        guid=7885201945644860203
                        path='/dev/da4'
                        whole_disk=0
                        DTL=195
zdb: can't open zpool01: Invalid argument

Ik veronderstel dat de fout 'ongeldig argument' aan het einde voorkomt omdat de zpool01 niet echt bestaat: het gebeurt niet op de werkende zpool02, maar er lijkt ook geen verdere uitvoer te zijn ...

OK, in dit stadium is het waarschijnlijk beter om dit te posten voordat het artikel te lang wordt.

Misschien kan iemand me wat advies geven over hoe verder te gaan en terwijl ik wacht op een reactie, zal ik de video bekijken, de details van de bovenstaande zdb-uitvoer bekijken, het Bens-artikel lezen en proberen te achterhalen wat wat...


20110806-1600 + 1000

Update 01:

Ik denk dat ik de oorzaak heb gevonden: Max Bruning was zo vriendelijk om heel snel te reageren op een e-mail van mij, met het verzoek om de output van zdb -lll. Op een van de 4 harde schijven in de 'goede' raidz1 helft van de pool, is de uitvoer vergelijkbaar met wat ik hierboven heb gepost. Op de eerste 3 van de 4 schijven in de 'gebroken' helft, zdb rapporten failed to unpack label voor label 2 en 3. De vierde rit in het zwembad lijkt in orde, zdb toont alle labels.

Googelen die foutmelding wordt weergegeven deze post. Vanaf het eerste antwoord op die post:

Met ZFS zijn dit elk vier identieke labels   fysieke vdev, in dit geval een enkele harde schijf.   L0 / L1 aan het begin van de vdev, en   L2 / L3 aan het einde van de vdev.

Alle 8 schijven in het zwembad zijn van hetzelfde model, Seagate Barracuda 500 GB. Ik herinner me echter dat ik het zwembad met 4 drives begon, waarna een van hen stierf en door Seagate onder garantie werd vervangen. Later heb ik nog eens 4 schijven toegevoegd. Om die reden zijn de schijf- en firmware-ID's anders:

[user@host ~]$ dmesg | egrep '^da.*?: <'
da0:  <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device 
da1:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da2:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da3:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da4:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da5:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da6:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da7:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da8:  <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device 
da9:  <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 

Ik herinner me dat alle schijven dezelfde grootte hadden. Kijkend naar de schijven nu, toont het dat de grootte voor drie van hen is veranderd, ze zijn met 2 MB gekrompen:

[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0:   10240MB (20971520  512 byte sectors: 255H 63S/T 1305C)
da1:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9:  152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)

Dus het lijkt er niet op dat het een van de OS-installaties was die 'een bootloader schreef naar een van de drives' (zoals ik eerder had aangenomen), het was eigenlijk het nieuwe moederbord (een ASUS P8P67 LE) het maken van een 2 MB host beschermd gebied aan het einde van drie van de schijven die mijn ZFS-metadata verknoeien.

Waarom heeft het geen HPA op alle schijven gemaakt? Ik denk dat dit komt omdat de HPA-creatie alleen wordt gedaan op oudere schijven met een bug die later werd verholpen door een BIOS-update van de Seagate hard drive: toen dit hele incident een paar weken geleden begon, heb ik Seagate's uitgevoerd SeaTools om te controleren of er iets fysiek mis is met de drives (nog steeds op de oude hardware) en kreeg ik een bericht dat sommige van mijn drives een BIOS-update nodig hebben. Aangezien ik nu probeer de exacte details van dat bericht en de link naar de firmware-update te reproduceren, lijkt het erop dat sinds het moederbord de HPA heeft gemaakt, beide SeaTools DOS-versies de harde schijven in kwestie niet kunnen detecteren - een snelle invalid partitionof iets dergelijks flitst door wanneer ze beginnen, dat is alles. Ironisch genoeg vinden ze wel een set Samsung-schijven.

(Ik heb de pijnlijke, tijdrovende en uiteindelijk vruchteloze details van het rondschudden in een FreeDOS-shell overgeslagen op een niet-genetwerkt systeem.) Uiteindelijk installeerde ik Windows 7 op een afzonderlijke machine om SeaTools Windows uit te voeren versie 1.2.0.5. Nog een laatste opmerking over DOS SeaTools: Doe niet de moeite om ze op zichzelf te laten opstarten - in plaats daarvan, investeer een paar minuten en maak een opstartbare USB-stick met het geweldige Ultieme Boot-CD - wat naast DOS SeaTools ook veel andere, echt nuttige, hulpprogramma's oplevert.

Wanneer gestart, brengt SeaTools voor Windows dit dialoogvenster naar voren:

SeaTools Firmware Update Dialog

De links leiden naar de Serienummercontrole (dat om een ​​of andere reden door een captcha - mine werd beschermd, was 'Invasive users') en a kennisbasisartikel over de firmware-update. Er zijn waarschijnlijk nog andere links die specifiek zijn voor het model van de harde schijf en sommige downloads en wat niet, maar ik zal dat pad voorlopig niet volgen:

Ik zal niet haasten om de firmware van drie schijven bij te werken op een moment dat partities zijn ingekort en deel uitmaken van een kapotte opslagpool. Dat is vragen om problemen. Om te beginnen kan de firmware-update hoogstwaarschijnlijk niet ongedaan worden gemaakt - en dat kan mijn kansen onherstelbaar verpesten om mijn gegevens terug te krijgen.

Daarom is het allereerste dat ik nu ga doen de image van de schijven en het werken met de kopieën, dus er is een origineel om naar terug te gaan als er iets misgaat. Dit zou een extra complexiteit kunnen introduceren, omdat ZFS waarschijnlijk zal merken dat schijven geruild zijn (door middel van het serienummer van het station of nog een andere UUID of wat dan ook), ook al is het bit-exact dd-kopieën op hetzelfde harde-schijfmodel. Bovendien is de zpool niet eens live. Jongen, dit kan lastig worden.

De andere optie zou echter zijn om met de originelen te werken en de gespiegelde schijven als back-up te behouden, maar dan kom ik waarschijnlijk boven de complexiteit te staan ​​als er iets fout is gegaan met de originelen. Naa, niet goed.

Om de drie harde schijven leeg te maken die zullen dienen als beeldvervangende vervangingen voor de drie schijven met het BIOS met fouten in de gebroken pool, moet ik wat opslagruimte maken voor de dingen die er nu zijn, dus ik zal diep graven in de hardwaredoos en assembleer een tijdelijke zpool van een aantal oude schijven - die ik ook kan gebruiken om te testen hoe ZFS omgaat met het wisselen van dd'd-schijven.

Dit kan even duren...


20111213-1930 + 1100

Update 02:

Dit duurde inderdaad een tijdje. Ik heb maanden doorgebracht met verschillende open computerbehuizingen op mijn bureau met verschillende hoeveelheden harde schijven die uit elkaar hingen en sliepen ook een paar nachten met oordopjes, omdat ik de machine niet kon afsluiten voordat ik naar bed ging omdat het een lange kritieke operatie aan het uitvoeren was . Ik heb echter eindelijk de overhand gekregen! :-) Ik heb ook veel geleerd in het proces en ik zou die kennis graag willen delen voor iedereen in een vergelijkbare situatie.

Dit artikel is al veel langer dan iedereen met een ZFS-bestandsserver die niet meer werkt, heeft de tijd om te lezen, dus zal ik hier in detail treden en een antwoord creëren met de essentiële bevindingen hieronder.

Ik heb diep in de verouderde hardwaredoos gegraven om voldoende opslagruimte te verzamelen om de spullen van de enkele 500GB-schijven te verplaatsen waarnaar de defecte schijven waren gespiegeld. Ik moest ook een paar harde schijven uit hun USB-hoesjes halen, zodat ik ze direct via SATA kon verbinden. Er waren wat meer, niet-gerelateerde problemen bij betrokken en sommige van de oude schijven begonnen te falen toen ik ze weer in actie bracht waarvoor een zpool-vervanging nodig was, maar ik sla dit over.

Tip: Op een bepaald moment waren er in totaal ongeveer 30 harde schijven bij betrokken. Met zoveel hardware is het een enorme hulp om ze op de juiste manier te laten stapelen; kabels die losraken of harde schijven die van uw bureau vallen, zullen zeker niet helpen in het proces en kunnen verdere schade aan uw gegevensintegriteit veroorzaken.

Ik heb een paar minuten besteed aan het maken van wat make-shift kartonnen harddrive-armaturen die echt hielp om dingen gesorteerd te houden:

some of the make-shift storage space just a bunch of screws plus some cardboard the fan is not exactly required, the stack is from an earlier project the distance pieces aren't required either...

Ironisch genoeg, toen ik de eerste keer de oude schijven met elkaar verbond, realiseerde ik me dat er daar een oude Zpool is die ik heb moeten maken voor het testen met een oudere versie van sommige, maar niet alle persoonlijke gegevens die zijn verdwenen, dus terwijl het verlies van gegevens was enigszins verminderd, dit betekende extra verschuiven heen en weer van bestanden.

Ten slotte heb ik de problematische schijven naar back-upschijven gespiegeld, die gebruikt voor de zpool en de oorspronkelijke uitgewisseld. De back-upschijven hebben een nieuwere firmware, tenminste SeaTools rapporteert geen vereiste firmware-updates. Ik deed de mirroring met een eenvoudige dd van het ene apparaat naar het andere, b.v.

sudo dd if=/dev/sda of=/dev/sde

Ik geloof dat ZFS de hardwarewijziging (door een UUID met harde schijf of wat dan ook) opmerkt, maar het lijkt er niet op te schelen.

De zpool was echter nog steeds in dezelfde staat, onvoldoende replica's / beschadigde gegevens.

Zoals vermeld in de HPA Wikipedia-artikel eerder vermeld, wordt de aanwezigheid van een door een host beschermd gebied gerapporteerd wanneer Linux opstart en kan worden onderzocht met hdparm. Voor zover ik weet, is er geen hdparm-tool beschikbaar op FreeBSD, maar tegen die tijd had ik sowieso FreeBSD 8.2 en Debian 6.0 geïnstalleerd als dual-boot-systeem, dus ik startte op Linux:

user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done

   ...
/dev/sdd:
 max sectors   = 976773168/976773168, HPA is disabled
/dev/sde:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdf:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdg:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdh:
 max sectors   = 976773168/976773168, HPA is disabled
   ...

Het probleem was dus duidelijk dat het nieuwe moederbord een HPA van een paar megabytes creëerde aan het einde van de schijf die de bovenste twee ZFS-labels 'verborg', d.w.z. voorkwam dat ZFS ze zag.


Dabbelen met de HPA lijkt een gevaarlijke onderneming. Van de hdparm man-pagina, parameter -N:

Get/set max visible number of sectors, also known as the Host Protected Area setting.
  ...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles.  By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
  ...

In mijn geval is de HPA als volgt verwijderd:

user@host:~$ sudo hdparm -Np976773168 /dev/sde

/dev/sde:
 setting max visible sectors to 976773168 (permanent)
 max sectors   = 976773168/976773168, HPA is disabled

en op dezelfde manier voor de andere schijven met een HPA. Als je de verkeerde drive hebt of iets over de parameter size die je opgeeft niet aannemelijk is, is hdparm slim genoeg om te berekenen:

user@host:~$ sudo hdparm -Np976773168 /dev/sdx

/dev/sdx:
 setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

Hierna herstartte ik de FreeBSD 7.2 virtuele machine waarop de zpool oorspronkelijk was gemaakt en meldde de zpool-status opnieuw een werkgroep. YAY! :-)

Ik heb de pool geëxporteerd op het virtuele systeem en opnieuw geïmporteerd op het FreeBSD 8.2-systeem van de host.

Nog enkele belangrijke hardware-upgrades, nog een moederbord-swap, een ZFS-poolupdate naar ZFS 4/15, een grondige scrubbing en nu bestaat mijn zpool uit 8x1TB plus 8x500GB raidz2-onderdelen:

[user@host ~]$ sudo zpool status
  pool: zpool
 state: ONLINE
 scrub: none requested
config:

NAME        STATE     READ WRITE CKSUM
zpool       ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    ad0     ONLINE       0     0     0
    ad1     ONLINE       0     0     0
    ad2     ONLINE       0     0     0
    ad3     ONLINE       0     0     0
    ad8     ONLINE       0     0     0
    ad10    ONLINE       0     0     0
    ad14    ONLINE       0     0     0
    ad16    ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    da0     ONLINE       0     0     0
    da1     ONLINE       0     0     0
    da2     ONLINE       0     0     0
    da3     ONLINE       0     0     0
    da4     ONLINE       0     0     0
    da5     ONLINE       0     0     0
    da6     ONLINE       0     0     0
    da7     ONLINE       0     0     0

errors: No known data errors

[user@host ~]$ df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
/dev/label/root     29G     13G     14G    49%    /
devfs              1.0K    1.0K      0B   100%    /dev
zpool              8.0T    3.6T    4.5T    44%    /mnt/zpool

Als een laatste woord, het lijkt mij dat ZFS-pools heel, heel moeilijk te doden zijn. De jongens van Sun van wie dat systeem heeft gemaakt, hebben alle reden dat ze het het laatste woord in bestandssystemen noemen. Respect!


41
2017-08-03 09:44


oorsprong


Voordat je iets doet, stel je die drives voor! Neem een ​​back-up van uw 'corrupte' gegevens voor het geval u het nog erger maakt. - MikeyB
ja, dat is een heel goed punt! en het is ook de reden waarom ik dit artikel niet heb bijgewerkt met mijn vorderingen tot nu toe - nog steeds bezig met het opruimen van vervangende harde schijven ... - ssc


antwoorden:


Het probleem was dat het BIOS van het nieuwe moederbord een host protected area (HPA) op sommige van de schijven creëerde, een klein gedeelte dat door OEM's wordt gebruikt voor systeemherstel, meestal aan het einde van de harde schijf.

ZFS onderhoudt 4 labels met partitiemetaninformatie en de HPA voorkomt dat ZFS de bovenste twee ziet.

Oplossing: start Linux op, gebruik hdparm om de HPA te inspecteren en te verwijderen. Wees heel voorzichtig, dit kan je gegevens gemakkelijk voorgoed vernietigen. Raadpleeg het artikel en de hdparm-manpagina (parameter -N) voor meer informatie.

Het probleem deed zich niet alleen voor met het nieuwe moederbord, ik had een soortgelijk probleem bij het aansluiten van de schijven op een SAS-controllerkaart. De oplossing is hetzelfde.


22
2017-12-13 10:47





Het allereerste wat ik u zou aanraden is om meer harde schijven te krijgen en duplicaten van de 8 schijven die u hebt met uw gegevens erop te maken, met behulp van de dd commando. Op die manier kun je, als je ze probeert te herstellen, de zaken erger maken, kun je nog steeds teruggaan naar deze basislijn.

Ik heb dit eerder gedaan en soms had ik het niet nodig, maar de keren dat ik deed heb het absoluut de moeite waard gemaakt.

Werk niet zonder een net.


4
2017-08-26 07:17



Eigenlijk zou ik aanbevelen ddrescue over- dd. Het werkt niet echt heel anders als de schijven perfect werken (maar het geeft je wel een goede voortgangsindicatie) maar als er problematische sectoren zijn of iets dergelijks, dan doet ddrescue die situatie veel beter dan dd (dus ik is verteld). - α CVn


Je lijkt op schema om dit op te lossen. Als je een ander, mogelijk nieuwer gezichtspunt wilt, kun je een live-CD van Solaris 11 Express proberen. Er loopt waarschijnlijk een veel nieuwere code (zpool in Solaris is nu op versie 31, terwijl je bij versie 6 bent) en het zou betere herstelmogelijkheden kunnen bieden. Ren niet zpool upgrade onder Solaris hoewel als je het zwembad onder FreeBSD mountable wilt houden.


1
2017-08-09 21:06



Bedankt voor die tip! :-) Ik was OpenSolaris aan het bekijken in 2009 of zo toen ik aan dit hele ZFS-bedrijf begon, maar helaas ondersteunde het niet de controllers die ik gebruik - dit is uiteindelijk consumentenhardware. Onlangs heb ik ook gekeken naar OpenIndiana, maar ik weet niet zeker of de situatie is veranderd. Ik zou de controllers op enig moment kunnen upgraden naar SAS en dan overwegen om te migreren. - ssc
Ik denk dat OpenIndiana misschien een nieuwe look waard is. Als er niets anders is, zijn ze misschien vriendelijker voor 'goedkope' hardware dan Oracle ... Ik heb de live-cd aanbevolen omdat het gemakkelijk is om uit te proberen - je kunt het ook in een VM uitvoeren. - Jakob Borg


De FreeBSD-mailinglijsten kunnen een goed startpunt zijn voor uw zoekopdracht. Ik herinner me dat ik soortgelijke verzoeken voorbij zag gaan op FreeBSD-Stable en -Current. Afhankelijk van het belang van uw gegevens, wilt u mogelijk contact opnemen met een professioneel herstelbedrijf, omdat knoeien met ontoegankelijke gegevensopslagpools een goede kans maakt om het nog erger te maken.


0
2017-08-05 20:08





Ik ondervond een soortgelijk probleem na het upgraden van FreeBSD 10.3 naar 11.1, daarna werd de zpool bekritiseerd en er was geen manier om de gegevens te herstellen, ook al zdb -lll alle vier de labels zijn geldig.

Het bleek dat op de een of andere manier de update de Intel-stuurprogramma's voor opslagbeheer activeerde om een ​​softraid-mirror uit de schijven te maken (misschien was het ingeschakeld, maar niet ondersteund door geomis de Intel-provider tot na de update?) en blokkeerde ZFS de schijven niet.

Bevestig ze op een andere pc met Intel RST boot-time firmware ingeschakeld en schakel de softraid uit (erg belangrijk: er zijn twee manieren om de softraid te verbreken, waarvan de standaard de schijven initialiseert (oftewel formaten!). U moet de optie kiezen om uit te schakelen zonder de gegevens in plaats daarvan aan te raken) en dan ZFS de eerste schijf in de spiegel laten herkennen, hoewel niets dat ik deed het mogelijk zou maken om de resterende schijven te identificeren als dezelfde die in de pre-update van de machine waren. Gelukkig was het een mirrored zpool en kon ik de schijven gewoon losmaken en opnieuw bevestigen aan het betreffende zwembad en kon het resilver zonder gebeurtenis worden voltooid.

Kanttekening: in mijn geval hdparm (loopt van een live Ubuntu Server ISO) meldde dat HBA op alle schijven was uitgeschakeld en niet kon helpen.


0
2018-04-13 20:48





als het gewoon een soort partitie probleem was, zou ik de schijf partities + MBR dd en de partitie de juiste grootte geven ...

als u een partitie niet opmaakt, maakt het maken of wijzigen van de partitietabel niets (dus u kunt dat terugdraaien!) zolang er geen indeling is, dan zijn de meeste gegevens er nog steeds / toegankelijk als de nieuwe partitie is ingevoegd aan het einde van de schijf heb je misschien corrupte bestanden daar waar de nieuwe dingen moeilijk te schrijven waren, daarom is je enige goed voor die truc tot je formatteert (nieuwe mbr, bestandstabel enz ...)


-2
2017-09-05 20:11