Ich habe mehrere TB 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 ausgeführt wird. Die FreeBSD-VM ist noch verfügbar und läuft einwandfrei, nur das Host-Betriebssystem wurde auf Debian 6 geändert. Die Festplatten werden der Gast-VM über generische VMWare-SCSI-Geräte zugänglich gemacht (insgesamt 12).
Es gibt 2 Pools:
- zpool01: 2x 4x 500 GB
- zpool02: 1x 4x 160 GB
Das, was funktioniert, ist leer, das kaputte 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 \
[email protected]:/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 austauschen und mehrere Host-Betriebssysteme installieren.
Mein Verdacht ist, dass eine dieser Betriebssysteminstallationen einen Bootloader (oder was auch immer) auf ein (das erste?) Der 500-GB-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 ich genug Informationen für einen vernünftigen, strukturierten, kontrollierten, informierten und sachkundigen Ansatz sammle, um meine Daten wiederzugewinnen - und hoffentlich jemand anderem da draußen in der gleichen Situation zu helfen.
Das erste Suchergebnis, wenn Sie nach 'zfs recover' googeln, ist das Kapitel zur ZFS-Fehlerbehebung und Datenwiederherstellung im Solaris ZFS-Administrationshandbuch. Im ersten ZFS Fehler - Möglichkeits- Abschnitt, heißt es in den ‚Verdorbene ZFS - Daten‘ Absatz:
Datenkorruption ist immer dauerhaft und erfordert besondere Berücksichtigung bei der Reparatur. Selbst wenn die zugrunde liegenden Geräte repariert oder ersetzt werden, gehen die ursprünglichen Daten für immer verloren.
Etwas entmutigend.
Das zweite Google-Suchergebnis ist jedoch das Weblog von Max Bruning, und darin habe ich gelesen
Vor kurzem wurde mir eine E-Mail von jemandem gesendet, der 15 Jahre lang Videos und Musik in einem 10-TB-ZFS-Pool gespeichert hatte, der nach einem Stromausfall defekt wurde. Er hatte leider kein Backup. Er benutzte ZFS Version 6 unter FreeBSD 7 [...] Nachdem ich etwa eine Woche lang die Daten auf der Festplatte untersucht hatte, konnte ich im Grunde alles wiederherstellen.
und
Ich bezweifle, dass ZFS Ihre Daten verliert. Ich vermute, dass Ihre Daten vorhanden sind, aber Sie müssen den richtigen Weg finden, um darauf zuzugreifen.
(Das klingt so viel eher wie etwas, das ich hören möchte ...)
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, die von Sun oder Oracle an keiner Stelle im Web 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.
Außerdem hat Ben Rockwood einen ausführlichen Artikel gepostet und es gibt ein Video von Max Bruning, der auf der Open Solaris Developer Conference am 28. Juni 2008 in Prag darüber spricht.
Wenn Sie zdb als root auf dem kaputten zpool ausführen, erhalten Sie die 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 wirklich existiert: Es tritt nicht auf dem funktionierenden zpool02 auf, aber es scheint auch keine weitere Ausgabe zu geben ...
OK, zu diesem Zeitpunkt ist es wahrscheinlich besser, dies zu posten, bevor der Artikel zu lang wird.
Vielleicht kann mir jemand einen Rat geben, wie ich von hier aus weitermachen kann. Während ich auf eine Antwort warte, schaue ich mir das Video an, gehe die Details der obigen ZDB-Ausgabe durch, lese den Artikel von Bens und versuche herauszufinden, was passiert Was...
20110806-1600 + 1000
Update 01:
Ich glaube, ich habe die Ursache gefunden: Max Bruning war so freundlich, sehr schnell auf eine E-Mail von mir zu antworten und nach der Ausgabe von zu fragen zdb -lll. Auf jeder der 4 Festplatten in der "guten" raidz1-Hälfte des Pools ist die Ausgabe ähnlich wie oben. Doch auf die ersten 3 der 4 - Laufwerke in der ‚kaputt‘ Hälfte, zdbBerichte failed to unpack labelfür Etikett 2 und 3. Die vierte Laufwerk im Pool scheint OK, zdbzeigt alle Etiketten.
Wenn Sie diese Fehlermeldung googeln, wird dieser Beitrag angezeigt . Von der ersten Antwort auf diesen Beitrag:
Bei ZFS sind das 4 identische Bezeichnungen auf jedem physischen 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 haben das gleiche Modell, Seagate Barracuda 500 GB . Ich erinnere mich jedoch, dass ich den Pool mit 4 Laufwerken gestartet habe, dann starb eines von ihnen und wurde im Rahmen der Garantie von Seagate ersetzt. Später habe ich weitere 4 Laufwerke hinzugefügt. 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 jedoch, dass alle Laufwerke die gleiche Größe hatten. Betrachtet man nun die Laufwerke, so 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 wie es aussieht, war es nicht eine der Betriebssysteminstallationen, die 'einen Bootloader auf eines der Laufwerke geschrieben hat' (wie ich vorher angenommen hatte), sondern das neue Motherboard (ein ASUS P8P67 LE ), das einen 2 MB- Host erstellt hat geschützter Bereich am Ende von drei Laufwerken, die meine ZFS-Metadaten durcheinander gebracht haben.
Warum wurde nicht auf allen Laufwerken ein HPA erstellt? Ich glaube, das liegt daran, dass die HPA-Erstellung nur auf älteren Laufwerken mit einem Fehler durchgeführt wird, der später durch ein Seagate-Festplatten-BIOS-Update behoben wurde: Als dieser gesamte Vorfall vor einigen Wochen begann, habe ich SeaTools von Seagate ausgeführt , um zu überprüfen, ob es ihn gibt Irgendetwas ist physikalisch mit den Laufwerken nicht in Ordnung (immer noch auf der alten Hardware) und ich erhalte die Meldung, dass einige meiner Laufwerke ein BIOS-Update benötigen. Da ich jetzt versuche, die genauen Details dieser Meldung und den Link zum Firmware-Update-Download zu reproduzieren, scheinen beide SeaTools-DOS-Versionen, seit das Motherboard den HPA erstellt hat, die fraglichen Festplatten nicht zu erkennen - eine schnelle invalid partitionoder ähnliche blinkt, wenn sie anfangen, das wars. Ironischerweise finden sie jedoch eine Reihe von Samsung-Laufwerken.
(Ich habe auf die schmerzhaften, zeitaufwendigen und letztendlich vergeblichen Details des Herumschraubens einer FreeDOS-Shell auf einem nicht vernetzten System verzichtet.) Schließlich habe ich Windows 7 auf einem separaten Computer installiert, um SeaTools Windows auszuführen Version 1.2.0.5. Noch eine letzte Bemerkung zu DOS SeaTools: Versuchen Sie nicht, sie eigenständig zu booten. Nehmen Sie sich stattdessen ein paar Minuten Zeit und erstellen Sie einen bootfähigen USB-Stick mit der großartigen Ultimate Boot-CD. Abgesehen von DOS SeaTools erhalten Sie auch wirklich viele andere Nützliche Hilfsmittel.
Beim Start von SeaTools für Windows wird folgender Dialog angezeigt:
Die Links führen zum Serial Number Checker (der aus irgendeinem Grund durch ein Captcha - Mine "Invasive Users" geschützt ist) und einem Knowledge Base - Artikel über das Firmware - Update. Es gibt wahrscheinlich weitere Links speziell für das Festplattenmodell und einige Downloads und was nicht, aber ich werde diesen Pfad im Moment nicht befolgen:
Ich werde nicht gleich die Firmware von drei Laufwerken aktualisieren, die Partitionen abgeschnitten haben und Teil eines defekten Speicherpools sind. Das bittet um Ärger. Für den Anfang kann das Firmware-Update höchstwahrscheinlich nicht rückgängig gemacht werden - und das kann meine Chancen, meine Daten wiederzugewinnen, unwiderruflich ruinieren.
Daher werde ich als erstes ein Image der Laufwerke erstellen und mit den Kopien arbeiten, sodass Sie auf ein Original zurückgreifen können, wenn etwas schief geht. Dies kann eine zusätzliche Komplexität mit sich bringen, da ZFS wahrscheinlich feststellen wird, dass Laufwerke ausgetauscht wurden (anhand der Seriennummer des Laufwerks oder einer weiteren UUID oder was auch immer), obwohl es sich um bitgenaue dd-Kopien auf dasselbe Festplattenmodell handelt. Darüber hinaus ist der Zpool nicht einmal live. Junge, das könnte schwierig werden.
Die andere Möglichkeit wäre jedoch, mit den Originalen zu arbeiten und die gespiegelten Laufwerke als Backup zu behalten, aber dann werde ich wahrscheinlich auf die oben genannte Komplexität stoßen, wenn mit den Originalen etwas schief gelaufen ist. Naa, nicht gut.
Um die drei Festplatten auszuräumen, die als Ersatz für die drei Laufwerke mit dem fehlerhaften BIOS im defekten Pool dienen sollen, muss ich Speicherplatz für das Material schaffen, das jetzt dort vorhanden ist die Hardware-Box und stellen einen temporären Zpool aus einigen alten Laufwerken zusammen - mit dem ich auch testen kann, wie ZFS mit dem Auslagern von dd'd-Laufwerken umgeht.
Dies kann eine Weile dauern ...
20111213-1930 + 1100
Update 02:
Das hat in der Tat eine Weile gedauert. Ich habe Monate mit mehreren offenen Computergehäusen auf meinem Schreibtisch verbracht, in denen verschiedene Mengen an Festplattenstapeln heraushingen, und auch ein paar Nächte mit Ohrstöpseln geschlafen, weil ich die Maschine vor dem Zubettgehen nicht ausschalten konnte, da sie einige langwierige kritische Vorgänge durchführte . Ich habe mich aber endlich durchgesetzt! :-) Ich habe dabei auch viel gelernt und möchte dieses Wissen hier für jeden, der sich in einer ähnlichen Situation befindet, weitergeben.
Dieser Artikel ist bereits viel länger als jeder andere, bei dem ein ZFS-Dateiserver außer Betrieb ist. Daher werde ich hier auf Details eingehen und eine Antwort mit den wesentlichen Ergebnissen erstellen, die weiter unten aufgeführt sind.
Ich grub mich 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 defekten 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 einige andere Probleme, die nichts damit zu tun hatten, und einige der alten Laufwerke fielen aus, als ich sie wieder in Betrieb nahm und einen Zpool-Austausch erforderte, aber ich werde darauf verzichten.
Tipp: Irgendwann waren insgesamt rund 30 Festplatten daran beteiligt. Bei so viel Hardware ist es eine enorme Hilfe, sie richtig zu stapeln. Kabel, die sich lösen oder die Festplatte, die vom Schreibtisch fällt, helfen dabei sicherlich nicht und können die Datenintegrität weiter beeinträchtigen.
Ich habe ein paar Minuten damit verbracht, ein paar Geräte aus Pappkarton zu entwickeln, die wirklich dazu beigetragen haben, die Dinge in Ordnung zu halten:
Ironischerweise stellte ich beim ersten Anschließen der alten Laufwerke fest, dass ein alter Zpool vorhanden ist, den ich zum Testen mit einer älteren Version einiger, aber nicht aller fehlenden personenbezogenen Daten erstellt haben musste, während der Datenverlust stattfand etwas reduziert bedeutete dies ein zusätzliches Hin- und Herschieben von Dateien.
Schließlich habe ich die problematischen Laufwerke auf Sicherungslaufwerke gespiegelt, diese für den Zpool verwendet und die ursprünglichen Laufwerke nicht angeschlossen. Die Backup-Laufwerke haben eine neuere Firmware. Zumindest 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 Festplatten-UUID oder was auch immer), scheint sich aber nicht darum zu kümmern.
Der zpool befand sich jedoch noch im selben Zustand, unzureichende Replikate / beschädigte Daten.
Wie in dem bereits erwähnten HPA-Wikipedia-Artikel erwähnt, wird das Vorhandensein eines Host-geschützten Bereichs beim Booten von Linux gemeldet und kann mithilfe von hdparm untersucht werden . Soweit ich weiß, gibt es unter FreeBSD kein HDParm-Tool, aber zu diesem Zeitpunkt hatte ich trotzdem 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 war also offensichtlich, dass das neue Motherboard am Ende des Laufwerks einen HPA von ein paar Megabyte erstellt hat, der die oberen beiden ZFS-Labels „versteckte“, dh verhinderte, dass ZFS sie sehen konnte.
Sich mit der HPA zu beschäftigen, scheint eine gefährliche Angelegenheit zu sein. In der hdparm-Manpage lautet der 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 folgendermaßen 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 klug genug, um Folgendes herauszufinden:
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 neu gestartet, auf der der Zpool ursprünglich erstellt worden war, und der Zpool-Status hat erneut einen funktionierenden Pool gemeldet. YAY! :-)
Ich habe den Pool auf dem virtuellen System exportiert und auf dem Host-FreeBSD-8.2-System erneut importiert.
Einige weitere wichtige Hardware-Upgrades, ein weiterer Motherboard-Swap, ein ZFS-Pool-Update auf ZFS 4/15, ein gründliches Scrubbing und jetzt besteht mein Zpool aus 8x1 TB plus 8x500 GB 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 scheint es mir, dass ZFS-Pools sehr, sehr schwer zu töten sind. Die Jungs von Sun, die dieses System erstellt haben, haben allen Grund, es als das letzte Wort in Dateisystemen zu bezeichnen. Respekt!
Antworten:
Das Problem bestand darin, dass das BIOS des neuen Motherboards auf einigen Laufwerken einen Host-geschützten Bereich (HPA) erstellt hat, einen kleinen Abschnitt, der von OEMs für Systemwiederherstellungszwecke verwendet wird und sich normalerweise am Ende der Festplatte befindet.
ZFS verwaltet 4 Bezeichnungen mit Partitions-Metainformationen und die HPA verhindert, dass ZFS die oberen beiden Bezeichnungen sieht.
Lösung: Booten Sie Linux und verwenden Sie hdparm, um den HPA zu überprüfen und zu entfernen. Seien Sie sehr vorsichtig, dies kann leicht Ihre Daten für immer zerstören. Weitere Informationen finden Sie im Artikel und in der Manpage zu hdparm (Parameter -N).
Das Problem trat nicht nur beim neuen Motherboard auf, sondern auch beim Anschließen der Laufwerke an eine SAS-Controllerkarte. Die Lösung ist die gleiche.
quelle
Das allererste, was ich Ihnen empfehlen würde, ist, weitere Festplatten zu beschaffen und mit dem
ddBefehl Kopien der 8 Laufwerke zu erstellen, auf denen sich Ihre Daten befinden . Auf diese Weise können Sie immer noch zu dieser Grundlinie zurückkehren, wenn Sie versuchen, sie wiederherzustellen, was die Situation verschlimmert.Ich habe das schon einmal gemacht und es gab Zeiten, in denen ich es nicht brauchte, aber die Zeiten, in denen ich es brauchte, machten es die Mühe absolut wert.
Arbeiten Sie nicht ohne Netz.
quelle
ddrescueüber empfehlendd. Es funktioniert nicht wirklich anders, wenn die Laufwerke einwandfrei funktionieren (aber es gibt Ihnen eine nette Fortschrittsanzeige), aber wenn es problematische Sektoren oder ähnliches gibt, geht ddrescue mit dieser Situation viel besser um als dd (oder so, wie ich) wurde mir gesagt).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. Dort läuft wahrscheinlich viel neuer Code (zpool in Solaris ist jetzt in Version 31, während Sie in Version 6 sind), und er bietet möglicherweise bessere Wiederherstellungsmöglichkeiten. Laufen Sie jedoch nicht
zpool upgradeunter Solaris, wenn Sie den Pool unter FreeBSD bereitstellen möchten.quelle
Die FreeBSD-Mailinglisten könnten ein guter Ausgangspunkt für Ihre Suche sein. Ich erinnere mich, dass ich ähnliche Anfragen bei FreeBSD-Stable und -Current gesehen habe. Abhängig von der Wichtigkeit Ihrer Daten können Sie sich an eine professionelle Wiederherstellungsfirma wenden, da Manipulationen an unzugänglichen Datenspeicherpools eine gute Chance haben, die Situation zu verschlimmern.
quelle
Ich hatte nach dem Upgrade von FreeBSD 10.3 auf 11.1 ein ähnliches Problem. Danach war der Zpool fehlerhaft und es gab keine Möglichkeit, die Daten wiederherzustellen, obwohl
zdb -lllalle vier gültigen Labels zurückgegeben wurden.Es hat sich herausgestellt, dass das Update die Intel Storage Management-Treiber dazu veranlasst hat, einen Softraid-Spiegel aus den Festplatten zu erstellen (möglicherweise war es aktiviert, wurde aber vom
geomIntel-Anbieter erst nach dem Update unterstützt?), Und dass ZFS daran gehindert wurde, die Festplatten zu mounten .Anschließen an einen anderen PC mit aktivierter Intel RST-Boot-Firmware und Deaktivieren der Softraid ( sehr wichtig: Es gibt zwei Möglichkeiten, die Softraid zu unterbrechen, durch deren Standard die Festplatten initialisiert werden (auch bekannt als Formate!). Sie müssen die Option auswählen deaktivieren, ohne stattdessen die Daten zu berühren), und ZFS die erste Festplatte im Spiegel erkennen lassen, obwohl ich nichts getan habe, um die verbleibenden Festplatten als dieselben zu identifizieren, die sich in der Maschinenvoraktualisierung befanden. Zum Glück handelte es sich um einen gespiegelten Zpool, und ich konnte die Datenträger einfach vom betreffenden Pool trennen und wieder an diesen anschließen, und der Resilver wurde ohne Ereignis ausgeführt.
Randnotiz: In meinem Fall
hdparm(läuft von einem Ubuntu-Server-ISO) wurde berichtet, dass HBA auf allen Festplatten deaktiviert war und nicht helfen konnte.quelle
Wenn es sich nur um ein Partitionsproblem handeln würde, würde ich die Laufwerkspartitionen + MBR hinzufügen und die Partition auf die richtige Größe bringen ...
Wenn Sie eine Partition nicht formatieren, hat das Erstellen oder Ändern der Partitionstabelle keine Auswirkungen (Sie können dies also rückgängig machen!), solange es kein Format gibt, sind die meisten Daten noch vorhanden / zugänglich, wenn die neue Partition eingefügt wird Am Ende des Laufwerks haben Sie möglicherweise beschädigte Dateien, in denen das neue Material hart geschrieben wurde. Das ist der Grund, warum Sie nur für diesen Trick gut sind, bis Sie es formatieren (neue MBR, Dateitabelle usw.).
quelle