zfs-mirror reparieren

G

georg

Well-Known Member
Ich habe bekannten einen Mailserver unter Freebsd eingerichtet.

FreeBSD selber ist mit zfs eingerichtet und befindet sich auf zwei SSD (USB) disks, die als ein zfs mirror eingerichtet sind.
Sie haben nun FreeBSD gebotet und haben dabei leider eine der SSD versehentlich aus dem USB-Slot herausgezogen gehabt und FreeBSD ist erst gar nicht gebootet. Sie haben es dann schlussendlich geschafft, Disk vollständig entfernt, und FreeBSD ist dann von der zweiten Disk gebootet. Der mirror ist dann als degraded angegeben worden. Leider haben sie es dann damit nicht beendet gelassen, sondern haben versucht erneut zu booten, und SSDs wieder neu eingesteckt in die USB Spots und erneut rebootet.

Jetzt wird auch der andere mirror wohl nicht mehr richtig erkannt, jedenfalls bleibt die Maschine beim booten irgendwann hängen (Assertion failed, missing variable oder so etwas).
ich habe die beiden Disks nun bei mir zuhause an ein FreeBSD System angeschlossen und kann auf beiden disks die GPT Struktur erkennen und sehe auch bei einem zpool import , dass ein z-mirror vorhanden ist. Was kann ich tun, um die beiden Disks wieder erkennbar werden, wenn ich sie wieder an das Originalsystem anhänge?

Georg
 
Wie immer gilt: Nicht die Platten mounten und Schreibvorgänge durchführen!

Mach zunächst in Ruhe ein Image von der Platte und lies das Image in einer virtuellen Maschine. Dann kannst du ohne Gefahr nach dem Fehler forschen.
 
zuglufttier schrieb:
Wie immer gilt: Nicht die Platten mounten und Schreibvorgänge durchführen!

Ich habe Die Platten nur an mein System angehängt, kein mount und mit einem zpool Import ohne Parameter angesehen, was mir angezeigt wird.

pool: zroot
id: xxxxx
State: online
Status: Pool was last accessed by another system.
Action: The pool can be imported using its name or numeric id qualifier and the -f flag
Comment: inherit
Config: zroot ONLINE
mirror-0 ONLINE
gpt/zroot0 ONLINE
gpt/zroot1 ONLINE

Auch die gpt-Struktur auf beiden Disks sieht gut aus.
Zum Vergrößern anklicken....
 
Sichere den Inhalt des Pools!
... und alles, was sonst noch wichtig ist!!!!!!!

Danach wäre ich schmerzfrei und würde die Platten im Rechner booten oder es zumindest versuchen. Wenn sie das aus irgendwelchen Gründen nun tatsöchlich beide alleine, jede für sich nicht mehr tun, würde ich das Ding platt machen, neu aufsetzen und eine Sprengfalle an jeder Platte montieren, die los geht, wenn sie einer anpackt ...

Startet der Pool von einer Platte und die andere ist inkonsistent -> ggf. zweite Platte neu aufsetzen und einbinden oder einfach ein resilver.
 
Ich tendiere zu einem ähnlichen Vorgehen. Allerdings wie würdest Du die Sicherung machen? Wie gesagt, ich habe die beiden Disks an meinem Laptop angeschlossen, (Läuft auch unter freebsd/zfs, interne Disk ada0 und mit einem zum Glück anderen Namen für den zpool.

Was ich sehen kann (ohne die Disks wirklich einzubinden):
Auf dem laptop erscheinen die beiden Disks als da0 und da1.
Die Disks sind mit gpt partitioniert:
da0p1 freebsd-boot
da0p2 freebsd-swap
da0p3 freebsd-zfs (klein für ZIL vorgesehen aber nicht verwendet)
da0p4 freebsd-zfs (zroot0,)
auf da1 sieht es analog aus, gpart gibt mir den Status ok für beide disks

zpool Import zeigt mir an, dass da ein zpool zu importieren wäre:
zroot
mirror-0
gpt/zroot0
gpt/zroot1

der zpool hat zum Glück einen anderen Namen wir der zum Laptop gehörende, aber da sich auf ihm (zroot) freebsd befindet, befürchte ich, dass über meine laptop Installation drüber-gemountet wird wenn ich ein zpool import -f mache.

Bin mir daher nicht ganz sicher, wie ich das am besten mache.
 
Also, wie gesagt. Erst einmal die Platten in ein Image kopieren und dann den Pool versuchen zu importieren. Das wird wahrscheinlich direkt klappen, wenn nicht die Rettungsparameter (also erstmal -F) probieren.
 
Yamagi schrieb:
Also, wie gesagt. Erst einmal die Platten in ein Image kopieren und dann den Pool versuchen zu importieren. Das wird wahrscheinlich direkt klappen, wenn nicht die Rettungsparameter (also erstmal -F) probieren.
Zum Vergrößern anklicken....

Wegen dem Importieren, was ist mit meinen Befürchtungen, dass über mein bestehendes System auf dem Laptop drüber-gemounted wird. Ist das kein Problem oder kann ich das irgendwie abfangen?

Ich gehe auch davon, aus, dass der Import des Pools funktioniert, frage mich aber, was genau kaputtgegangen ist, dass das nicht mehr bootet
 
Das kannst du per "Alternate Root" machen, dabei wird ein Pfad vor alle Mountpoints im Pool gehängt. Also zum Beispiel "zpool import -R /mnt altername neuername". Das importiert den Pool "altername" mit dem Namen "neuername" und setzt vor alle Pfade im Pool ein /mnt. Aus / wird also /mnt, aus /usr wird /mnt/usr und so weiter.
 
Bevor ich mich ans Werk mache (Disks kopieren mit dd if=/dev/da0 of=/image-da0.img bs=1m und dann den zpool import wie von Yamagi beschrieben) , um den importierten zpool wieder loszuwerden, genügt dann ein zpool export -f <poolname> ?
 
Bin einen Schritt weiter, ich habe den pool wie Yamagi es beschrieben hat importiert:
zpool import -f -R /mnt zroot
das ging problemlos. Der pool ist vollständig da mit beiden zmirror Mitgliedern (gpt/zroot0 und gpt/zroot1) . Ein zpool status bringt

pool: zroot
state: ONLINE
Status: one or more devices has experienced an unrecoverable error. Un attempt was made to correct the error. Applications are unaffected.
Action: determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'
scan: resilvered 36.1M in 0h0m with no error on Monday Mar 26 12:4336 2018
Errors: no known data errors

Ich denke, ein zpool clear wäre jetzt noch angebracht. Ich habe ein Blick in das Filesystem /mnt/boot geworfen, mir sind aber keine Fehler aufgefallen.

Was sollte ich noch ansehen oder untersuchen? Ansonsten könnte ich den Pool wieder exportieren und die Disks zu dem betroffenen System bringen und dieses Rebooten/neustarten.

Habt ihr irgendwelche Vorschläge, was jetzt das beste weitere Vorgehen wäre?
 
georg schrieb:
Ansonsten könnte ich den Pool wieder exportieren und die Disks zu dem betroffenen System bringen und dieses Rebooten/neustarten.
Zum Vergrößern anklicken....

Genau das würde ich jetzt auch erstmal machen. Mach es selber...erstmal und dann wieder die Bekannten ranlassen. Dann würd ich erstmal snapshots einrichten und mir Gedanken über ein Kaltbackup machen....einfach für die Zukunft und das Gewissen.
 
Kann zfs noch irgendwo Status/error-Informationen aufbewahren, die mir dazwischenfunken könnten? Z.B. zpool.cache oder an anderen Orten?
 
vor allem würd ich als erstes jetz mal die Daten vom Pool runterkopieren, sofern nicht schon geschehen, bevor die wieder im Originalsystem online gehen.

der Ursprungsfehler würde ja wie auch die Meldung, jetz beim einhängen und importieren des Pools in ein anderes System, darauf hindeuten, dass doch irgendwo was auf den Platten im Argen is - was vermutlich noch nicht (automatisch) gefixt wurde...
 
Das ist bereits geschehen, ich habe ein zpool scrub rüberlaufen gelassen und ebenfalls ein zpool clear um den Fehlerstatus loszuwerden.

Ich weiss nicht , was sonst noch an dem System verändert wurde. Kann es Probleme geben, wenn die Disk sich Devicemässig verschieben von da0 und da1 zu zB. da1 und da2, oder sollte es grundsätzlich kein Problem sein?
 
georg schrieb:
Das ist bereits geschehen, ich habe ein zpool scrub rüberlaufen gelassen und ebenfalls ein zpool clear um den Fehlerstatus loszuwerden.

Ich weiss nicht , was sonst noch an dem System verändert wurde. Kann es Probleme geben, wenn die Disk sich Devicemässig verschieben von da0 und da1 zu zB. da1 und da2, oder sollte es grundsätzlich kein Problem sein?
Zum Vergrößern anklicken....

Höchstens beim Booten (bootcode nur auf einer Platte) - ZFS selbst ist eigentlich recht unempfindlich in Bezug auf sich ändernde Devicenames
 
Nun ja, beide Platten sind absolut identisch mit gpt (gpart) eingerichtet. Auf beiden befindet sich eine gpt-bootpartion, mitsamt dem entsprechenden Bootcode damals mit:
# gpart add -a 4k -t freebsd-boot -l bootcode0 -s 512k daX
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 daX
auf beiden Platten eingerichtet. Das sollte also funktionieren.
 
Ich mache nie einen "zpool export" nach einem "alternate root" und das funktioniert blendend.

Ich erinnere mich dunkel mal Probleme mit dem Cache gehabt zu haben, aber das ist viel Jahre her und zfs auf FreeBSD vermutlich ein ganzes Stück weiter.
 
georg schrieb:
Kann es Probleme geben, wenn die Disk sich Devicemässig verschieben von da0 und da1 zu zB. da1 und da2, oder sollte es grundsätzlich kein Problem sein?
Zum Vergrößern anklicken....

Das hat bei mir noch nie Probleme gemacht, wenn das System alle Platten physikalisch 'sieht' und ich hab da schon viel Schund getrieben...
 
<bikeshed> echt jetzt? Man hat einen Mirror und ZFS freaked wegen dem beschriebenen Vorgehen so aus? Ich kenn das ja (incl "hidden meta-data") ja von Linux md(4) -- das kann doch nicht sein. Platte raus, Platte rein -> Drama?
 
double-p schrieb:
<bikeshed> echt jetzt? Man hat einen Mirror und ZFS freaked wegen dem beschriebenen Vorgehen so aus? Ich kenn das ja (incl "hidden meta-data") ja von Linux md(4) -- das kann doch nicht sein. Platte raus, Platte rein -> Drama?
Zum Vergrößern anklicken....

Eigentlich tut zfs das nicht.
Mir rauchen im Dauerbetrieb immer wieder mal Platten und Rechner ab. Am Anfang hatte ich ein paar Probleme mit ZFS, aber da war es auch erst kurz in FreeBSD implementiert. Mittlerweile sitzen Fehler eher in mir - also bootcode nicht auf beide Platten geschrieben und so ein Gedöns. Ansonsten scheint mir das alles extrem fehlertolerant zu sein.
 
ZFS ist extrem fehlertolerant und überlebt auch böse Dummheiten. Was hier genau schief gegangen ist, lässt sich post-mortem von außen nicht beantworten. Wenn ich mal raten darf: Unser aller Freund USB.
 
ja, leider habe ich nichts konkretes gefunden, an dem man wirklich nachvollziehen kann, was da abgelaufen ist. Was vermutest Du mit USB ?


Morgen abend kann ich die beiden Disks an ihren Server anhängen und dann sehen wir mal, ob das Problem behoben ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben