Frage ZFS unter FreeBSD: Wiederherstellung von Datenkorruption


Ich habe mehrere TBs mit sehr wertvollen persönlichen Daten in einem zpool, auf die ich aufgrund von Datenkorruption nicht zugreifen kann. Der Pool wurde ursprünglich im Jahr 2009 auf einem FreeBSD 7.2-System eingerichtet, das in einer virtuellen VMWare-Maschine auf einem Ubuntu 8.04-System läuft. Die FreeBSD-VM ist immer noch verfügbar und läuft gut, nur das Host-Betriebssystem hat sich jetzt zu Debian 6 geändert. Die Festplatten werden der Gast-VM mittels VMWare-generischen SCSI-Geräten, insgesamt 12, zugänglich gemacht.

Es gibt 2 Pools:

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

Der eine, der funktioniert, ist leer, der gebrochene enthält alle wichtigen Daten:

[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

Ich konnte vor ein paar Wochen auf den Pool zugreifen. Seitdem musste ich fast die gesamte Hardware des Host-Rechners ersetzen und mehrere Host-Betriebssysteme installieren.

Mein Verdacht ist, dass eine dieser Betriebssysteminstallationen einen Bootloader (oder was auch immer) auf einen (der ersten?) Der 500GB-Laufwerke geschrieben und einige zpool-Metadaten (oder was auch immer) zerstört hat - "oder was auch immer", was bedeutet, dass dies nur eine sehr vage Idee ist und dieses Thema ist nicht gerade meine starke Seite ...


Es gibt viele Websites, Blogs, Mailinglisten usw. über ZFS. Ich poste diese Frage hier in der Hoffnung, dass es mir hilft, genug Informationen für einen vernünftigen, strukturierten, kontrollierten, informierten, sachkundigen Ansatz zu sammeln, um meine Daten zurückzubekommen - und hoffentlich anderen dort draußen in derselben Situation zu helfen.


Das erste Suchergebnis beim googlen für 'zfs recover' ist das ZFS Fehlerbehebung und Datenrettung Kapitel aus dem Solaris ZFS-Administrationshandbuch. In der ersten ZFS Fehlermodi Abschnitt, sagt es im Abschnitt "Corrupted ZFS Data":

Datenkorruption ist immer permanent und erfordert besondere Rücksicht bei der Reparatur. Selbst wenn die zugrunde liegenden Geräte repariert oder ersetzt werden, sind die ursprünglichen Daten für immer verloren.

Etwas entmutigend.

Das zweite Google-Suchergebnis ist jedoch Max Brunings Weblog und drinnen las ich

Kürzlich wurde mir eine E-Mail von jemandem geschickt, der 15 Jahre Video und Musik in einem 10TB ZFS-Pool gespeichert hatte, der nach einem Stromausfall defekt wurde. Er hatte leider kein Backup. Er verwendete ZFS Version 6 unter FreeBSD 7     [...]   Nachdem ich ungefähr eine Woche damit verbracht hatte, die Daten auf der Festplatte zu untersuchen, konnte ich im Grunde alles wiederherstellen.

und

Wie für ZFS, Ihre Daten zu verlieren, bezweifle ich es. Ich vermute, dass Ihre Daten da sind, aber Sie müssen den richtigen Weg finden, um darauf zu kommen.

(Das klingt so viel mehr wie etwas, das ich hören will ...)

Erster Schritt: Was genau ist das Problem?

Wie kann ich diagnostizieren, warum genau der zpool als beschädigt gemeldet wird? Ich sehe, dass es zdb gibt, das von Sun oder Oracle nirgendwo im Internet offiziell dokumentiert zu sein scheint. Von seiner Manpage:

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.

Darüber hinaus hat Ben Rockwood eine ausführlicher Artikel und da ist ein Videovon Max Brüning bei der Open Solaris Developer Conference am 28. Juni 2008 in Prag (und mdb).

Wenn Sie zdb als root für den defekten zpool ausführen, erhalten Sie folgende Ausgabe:

[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

Ich nehme an, dass der Fehler 'ungültiges Argument' am Ende auftritt, weil das zpool01 nicht existiert: Es tritt nicht auf dem funktionierenden zpool02 auf, aber es scheint auch keine weitere Ausgabe zu geben ...

Ok, in diesem Stadium ist es wahrscheinlich besser, dies zu posten, bevor der Artikel zu lang wird.

Vielleicht kann mir jemand Ratschläge geben, wie ich mich von hier fortbewegen kann und während ich auf eine Antwort warte, schaue ich mir das Video an, gehe die Details der zdb-Ausgabe oben durch, lese Bens Artikel und versuche herauszufinden, was es ist Was...


20110806-1600 + 1000

Update 01:

Ich denke, ich habe die Ursache gefunden: Max Brüning war so freundlich, sehr schnell auf eine E-Mail von mir zu antworten und bat um die Ausgabe von zdb -lll. Auf jeder der 4 Festplatten in der 'guten' Raidz1-Hälfte des Pools ist die Ausgabe ähnlich wie oben beschrieben. Jedoch auf den ersten 3 der 4 Laufwerke in der "gebrochenen" Hälfte, zdb Berichte failed to unpack label für Label 2 und 3. Das vierte Laufwerk im Pool scheint in Ordnung, zdb zeigt alle Etiketten an.

Googeln diese Fehlermeldung wird angezeigt dieser Beitrag. Von der ersten Antwort auf diesen Post:

Bei ZFS sind das vier identische Labels   physisches vdev, in diesem Fall eine einzelne Festplatte.   L0 / L1 am Anfang des vdev, und   L2 / L3 am Ende des vdev.

Alle 8 Laufwerke im Pool sind vom selben Modell, Seagate Barracuda 500 GB. Ich erinnere mich jedoch, dass ich den Pool mit 4 Laufwerken gestartet hatte, dann starb einer von ihnen und wurde im Rahmen der Garantie von Seagate ersetzt. Später fügte ich noch 4 Laufwerke hinzu. Aus diesem Grund unterscheiden sich die Laufwerks- und Firmware-IDs:

[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 

Ich erinnere mich aber, dass alle Laufwerke die gleiche Größe hatten. Betrachtet man jetzt die Laufwerke, zeigt sich, dass sich die Größe für drei von ihnen geändert hat, sie sind um 2 MB geschrumpft:

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

So gesehen, war es nicht eine der Betriebssysteminstallationen, die 'einen Bootloader zu einem der Laufwerke' (wie ich vorher angenommen hatte) schrieb, es war tatsächlich das neue Motherboard (ein ASUS P8P67 LE) Erstellen eines 2 MB Host geschützten Bereich am Ende von drei der Laufwerke, die meine ZFS-Metadaten durcheinander gebracht haben.

Warum wurde auf allen Laufwerken keine HPA erstellt? Ich glaube, das liegt daran, dass die HPA-Erstellung nur auf älteren Laufwerken mit einem Bug durchgeführt wird, der später durch ein Seagate-Festplatten-BIOS-Update behoben wurde: Als der gesamte Vorfall vor einigen Wochen begann, habe ich Seagate betrieben SeaTools um zu überprüfen, ob etwas mit den Laufwerken physikalisch nicht stimmt (immer noch auf der alten Hardware) und ich eine Nachricht erhielt, dass einige meiner Laufwerke ein BIOS-Update benötigen. Da ich jetzt versuche, die genauen Details dieser Nachricht und den Link zum Firmware-Update-Download zu reproduzieren, scheint es, dass seit dem Motherboard die HPA erstellt wurde, beide SeaTools-DOS-Versionen die betreffenden Festplatten nicht zu erkennen - eine schnelle invalid partitionoder etwas Ähnliches blinkt, wenn sie anfangen, das ist es. Ironischerweise finden sie jedoch eine Reihe von Samsung-Laufwerken.

(Ich habe auf die schmerzhaften, zeitraubenden und letztlich fruchtlosen Details des Verschraubens in einer FreeDOS-Shell auf einem nicht vernetzten System verzichtet.) Am Ende installierte ich Windows 7 auf einem separaten Rechner, um SeaTools Windows zu starten Version 1.2.0.5. Noch eine letzte Bemerkung zu DOS SeaTools: Versuchen Sie nicht, sie eigenständig zu booten - investieren Sie stattdessen ein paar Minuten und machen Sie einen bootfähigen USB-Stick mit dem genialen Ultimate Boot-CD - was neben DOS SeaTools auch viele andere wirklich nützliche Werkzeuge bringt.

Beim Start ruft SeaTools für Windows diesen Dialog auf:

SeaTools Firmware Update Dialog

Die Links führen zum Seriennummer Checker (die aus irgendeinem Grund durch ein Captcha geschützt ist - meines war 'Invasive Benutzer') und a Wissensdatenbankartikel über das Firmware-Update. Es gibt wahrscheinlich weitere Links, die spezifisch für das Festplattenmodell und einige Downloads sind und was nicht, aber ich werde diesen Pfad im Moment nicht verfolgen:

Ich werde nicht sofort die Firmware von drei Laufwerken aktualisieren, die Partitionen abgeschnitten haben und Teil eines defekten Speicherpools sind. Das verlangt nach Ärger. Für den Anfang kann das Firmware-Update höchstwahrscheinlich nicht rückgängig gemacht werden - und das könnte unwiderruflich meine Chancen ruinieren, meine Daten zurück zu bekommen.

Das erste, was ich als nächstes mache, ist, die Laufwerke zu erstellen und mit den Kopien zu arbeiten, also gibt es ein Original, zu dem man zurückkehren kann, wenn etwas schief geht. Dies kann eine zusätzliche Komplexität mit sich bringen, da ZFS wahrscheinlich feststellen wird, dass Laufwerke ausgetauscht wurden (mittels der Laufwerks-Seriennummer oder einer anderen UUID oder was auch immer), obwohl es bitgenau auf dasselbe Festplattenmodell kopiert wird. Außerdem ist der Zpool nicht einmal live. Junge, das könnte schwierig werden.

Die andere Option wäre jedoch, mit den Originalen zu arbeiten und die gespiegelten Laufwerke als Backup zu behalten, aber dann werde ich wahrscheinlich in eine höhere Komplexität geraten, wenn etwas mit den Originalen schief ging. Naa, nicht gut.

Um die drei Festplatten, die als Image-Ersatz für die drei Laufwerke mit dem fehlerhaften BIOS im kaputten Pool dienen sollen, zu löschen, muss ich Speicherplatz für die Sachen schaffen, die jetzt da sind, also werde ich tief hinein graben die Hardware-Box und assembliere einen temporären zpool von einigen alten Laufwerken - mit denen ich auch testen kann, wie ZFS dd-Laufwerke austauscht.

Das könnte eine Weile dauern ...


20111213-1930 + 1100

Update 02:

Das hat tatsächlich eine Weile gedauert. Ich habe Monate mit mehreren offenen Computergehäusen auf meinem Schreibtisch verbracht, mit verschiedenen Mengen an Festplattenstapeln, und auch ein paar Nächte mit Ohrstöpseln geschlafen, weil ich die Maschine vor dem Zubettgehen nicht herunterfahren konnte, weil sie eine längere kritische Operation durchführte . Letztendlich habe ich mich jedoch durchgesetzt! :-) Ich habe dabei auch viel gelernt und möchte dieses Wissen hier für alle in einer ähnlichen Situation teilen.

Dieser Artikel ist schon viel länger als jeder andere, der einen ZFS-Dateiserver außer Betrieb hat, hat die Zeit zu lesen, also werde ich hier ins Detail gehen und eine Antwort mit den wesentlichen Erkenntnissen weiter unten erstellen.

Ich grub tief in die veraltete Hardware-Box, um genügend Speicherplatz zu schaffen, um das Zeug von den einzelnen 500-GB-Laufwerken zu entfernen, auf die die fehlerhaften Laufwerke gespiegelt wurden. Ich musste auch ein paar Festplatten aus ihren USB-Gehäusen herausreißen, damit ich sie direkt über SATA anschließen konnte. Es gab noch ein paar andere Probleme, die nichts miteinander zu tun hatten, und einige der alten Laufwerke fingen an zu scheitern, als ich sie wieder in Aktion setzte, was ein zpool replace erforderte, aber ich werde darauf verzichten.

Spitze: Irgendwann gab es insgesamt etwa 30 Festplatten. Mit so viel Hardware ist es eine enorme Hilfe, sie ordentlich zu stapeln; Kabel, die sich lösen, oder Festplatten, die von Ihrem Schreibtisch fallen, helfen dabei sicher nicht und können weitere Schäden an Ihrer Datenintegrität verursachen.

Ich habe ein paar Minuten damit verbracht, ein paar verrückte Pappfestplatten zu bauen, die wirklich geholfen haben, die Dinge zu sortieren:

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...

Ironischerweise, als ich die alten Laufwerke das erste Mal angeschlossen habe, habe ich festgestellt, dass dort ein alter Zpool ist, den ich erstellt habe, um mit einer älteren Version von einigen, aber nicht allen persönlichen Daten, die verschwunden sind, zu testen, also während der Datenverlust war etwas reduziert, bedeutete dies zusätzliches Verschieben von Dateien.

Schließlich habe ich die problematischen Laufwerke auf Backup-Laufwerken gespiegelt, die für die zpool-Laufwerke verwendet und die ursprünglichen getrennt gelassen. Die Backup-Laufwerke haben eine neuere Firmware, mindestens SeaTools meldet keine erforderlichen Firmware-Updates. Ich habe die Spiegelung mit einem einfachen dd von einem Gerät zum anderen gemacht, z.

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

Ich glaube, ZFS bemerkt die Hardware-Änderung (durch eine Festplatte UUID oder was auch immer), scheint aber nicht zu kümmern.

Der Zpool befand sich jedoch immer noch im selben Zustand, unzureichende Replikate / beschädigte Daten.

Wie in der HPA Wikipedia Artikel Wie bereits erwähnt, wird das Vorhandensein eines Host-geschützten Bereichs gemeldet, wenn Linux gestartet wird und mithilfe von untersucht werden kann hdparm. Soweit ich weiß, gibt es auf FreeBSD kein hdparm-Tool, aber zu diesem Zeitpunkt hatte ich sowieso FreeBSD 8.2 und Debian 6.0 als Dual-Boot-System installiert, also habe ich Linux gebootet:

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
   ...

Das Problem bestand also offensichtlich darin, dass das neue Motherboard am Ende des Laufwerks eine HPA von einigen Megabyte erstellte, die die oberen zwei ZFS-Labels "verbarg", d. H. Verhinderte, dass ZFS sie sah.


Der Umgang mit der HPA scheint ein gefährliches Geschäft zu sein. Von der hdparm Manpage, 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 meinem Fall wird die HPA wie folgt entfernt:

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

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

und auf die gleiche Weise für die anderen Laufwerke mit einem HPA. Wenn Sie das falsche Laufwerk erhalten oder etwas über den von Ihnen angegebenen Größenparameter nicht plausibel ist, ist hdparm intelligent genug, um Folgendes zu bestimmen:

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.

Danach habe ich die virtuelle FreeBSD 7.2-Maschine, auf der der zpool ursprünglich erstellt wurde, neu gestartet und zpool status erneut einen Arbeits-Pool gemeldet. YAY! :-)

Ich habe den Pool auf dem virtuellen System exportiert und auf dem FreeBSD 8.2-System-System erneut importiert.

Einige größere Hardware-Upgrades, ein weiterer Motherboard-Tausch, ein ZFS-Pool-Update auf ZFS 4/15, ein gründliches Scrubbing und nun besteht mein Zpool aus 8x1TB plus 8x500GB raidz2-Teilen:

[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 letztes Wort, es scheint mir, ZFS-Pools sind sehr, sehr schwer zu töten. Die Leute von Sun, die dieses System erstellt haben, haben den Grund, es als das letzte Wort in Dateisystemen zu bezeichnen. Respekt!


41
2017-08-03 09:44


Ursprung


Bevor Sie etwas tun, sollten Sie diese Laufwerke abbilden! Machen Sie eine Sicherungskopie Ihrer "korrupten" Daten, falls Sie es noch schlimmer machen. - MikeyB
Ja, das ist ein sehr guter Punkt! und es ist auch der Grund, warum ich diesen Artikel noch nicht mit meinen Fortschritten aktualisiert habe - immer noch beschäftigt, Ersatz-Festplatten zu löschen ... - ssc


Antworten:


Das Problem bestand darin, dass das BIOS des neuen Motherboards auf einigen Laufwerken einen Host Protected Area (HPA) erstellte, ein kleiner Abschnitt, der von OEMs für Systemwiederherstellungszwecke verwendet wird und sich normalerweise am Ende der Festplatte befindet.

ZFS verwaltet 4 Beschriftungen mit Partitionsmetadaten, und die HPA verhindert, dass ZFS die oberen zwei erkennt.

Lösung: Starten Sie Linux, verwenden Sie hdparm, um die HPA zu inspizieren und zu entfernen. Seien Sie sehr vorsichtig, dies kann Ihre Daten leicht für immer zerstören. Weitere Informationen finden Sie im Artikel und auf der hdparm-Manpage (Parameter -N).

Das Problem trat nicht nur bei der neuen Hauptplatine auf. Ich hatte ein ähnliches Problem, als ich die Laufwerke mit einer SAS-Controller-Karte verband. Die Lösung ist die gleiche.


22
2017-12-13 10:47





Die allererste Sache, die ich Ihnen empfehlen würde, ist, mehr Festplatten zu bekommen und doppelte Kopien der 8 Laufwerke zu machen, die Sie mit Ihren Daten auf ihnen haben, mit dem dd Befehl. Auf diese Weise können Sie, wenn Sie bei Ihren Versuchen, sie wiederherzustellen, die Situation noch verschlimmern, zu dieser Basislinie zurückkehren.

Ich habe das schon mal gemacht und es gab Zeiten, in denen ich es nicht brauchte, aber die Zeiten habe ich hat getan Es muss die Mühe absolut wert sein.

Arbeiten Sie nicht ohne ein Netz.


4
2017-08-26 07:17



Eigentlich würde ich empfehlen ddrescue Über dd. Es funktioniert nicht sehr viel anders, wenn die Laufwerke perfekt funktionieren (aber es gibt Ihnen eine gute Fortschrittsanzeige), aber wenn es irgendwelche problematischen Sektoren oder etwas ähnliches gibt, behandelt ddrescue diese Situation viel besser als dd (oder so wurde mir gesagt). - α CVn


Sie scheinen auf dem richtigen Weg zu sein, dies zu lösen. Wenn Sie eine andere, möglicherweise neuere Sichtweise wünschen, können Sie eine Solaris 11 Express Live-CD ausprobieren. Es wird wahrscheinlich viel neuer Code dort laufen (zpool in Solaris ist jetzt in Version 31, während Sie in Version 6 sind) und es könnte bessere Wiederherstellungsmöglichkeiten bieten. Lauf nicht zpool upgrade unter Solaris, wenn Sie den Pool unter FreeBSD mounten wollen.


1
2017-08-09 21:06



Danke für diesen Tipp! :-) Ich habe OpenSolaris im Jahr 2009 untersucht, als ich mit dem ZFS-Geschäft angefangen habe, aber leider hat es die Controller, die ich verwende, nicht unterstützt - das ist immerhin Consumer-Hardware. Erst kürzlich habe ich auch OpenIndiana angeschaut, aber ich bin mir nicht sicher, ob sich die Situation geändert hat. Ich könnte die Controller irgendwann auf SAS aktualisieren und dann eine Migration in Betracht ziehen. - ssc
Ich denke, dass OpenIndiana ein neues Aussehen wert sein könnte. Sie könnten, wenn auch sonst, gegenüber "billiger" Hardware freundlicher sein als Oracle ... Ich empfehle die Live-CD, weil sie einfach zu testen ist - Sie können sie auch in einer VM ausführen. - Jakob Borg


Die FreeBSD-Mailinglisten sind möglicherweise ein guter Ausgangspunkt für Ihre Suche. Ich erinnere mich, ähnliche Anfragen auf FreeBSD-Stable und -Current gesehen zu haben. Abhängig von der Wichtigkeit Ihrer Daten sollten Sie sich jedoch an eine professionelle Wiederherstellungsfirma wenden, da die Manipulation unzugänglicher Datenspeicherpools eine gute Chance birgt, die Situation zu verschlimmern.


0
2017-08-05 20:08





Ich hatte ein ähnliches Problem nach dem Upgrade von FreeBSD 10.3 auf 11.1, danach war der zpool fehlerhaft und es gab keine Möglichkeit, die Daten wiederherzustellen, obwohl zdb -lll gab alle vier Etiketten gültig zurück.

Es stellt sich heraus, dass das Update die Intel Speicherverwaltungstreiber dazu veranlasst hat, einen Softraid-Spiegel aus den Festplatten zu erstellen (vielleicht wurde er aktiviert, aber nicht unterstützt) geomIntel-Provider, bis nach dem Update?) und blockiert ZFS von der Montage der Festplatten.

Sie werden an einen anderen PC angeschlossen, auf dem die Intel RST Boot-Time-Firmware aktiviert ist, und das Softraid deaktiviert (sehr wichtig: es gibt zwei Möglichkeiten, die Softraid zu brechen, deren Standard die Festplatten (auch bekannt als Formate!) initialisiert. Sie müssen stattdessen die Option auswählen, die deaktiviert werden soll, ohne die Daten zu berühren.) Lassen Sie dann ZFS die erste Festplatte im Spiegel erkennen, obwohl ich damit nicht die verbleibenden Festplatten als identisch mit denen in der Computer-Voraktualisierung identifizieren konnte. Glücklicherweise war es ein gespiegelter zpool, und ich konnte die Festplatten einfach abtrennen und wieder an den fraglichen Pool anschließen und das Resilver ohne Ereignis abschließen.

Randnotiz: In meinem Fall hdparm (läuft von einem Live Ubuntu Server ISO) berichtet, dass HBA auf allen Festplatten deaktiviert war und nicht helfen konnte.


0
2018-04-13 20:48





Wenn es nur ein Partitionsproblem irgendeiner Art wäre, würde ich die Laufwerkspartitionen + MBR ddd und nur die Partition die richtige Größe machen ...

Wenn Sie keine Partition formatieren, hat das Erstellen oder Ändern der Partitionstabelle keine Auswirkungen (Sie können das also rückgängig machen!), solange kein Format vorhanden ist, sind die meisten Daten immer noch verfügbar, wenn die neue Partition eingefügt wird Am Ende der Fahrt haben Sie möglicherweise korrupte Dateien dort, wo das neue Zeug hart geschrieben wurde, weshalb Ihr nur für diesen Trick gut ist, bis Sie formatieren (neue mbr, Dateitabelle usw.)


-2
2017-09-05 20:11