VM Festplatten können nicht mehr eingebunden werden

[dxniel7402]

Hallo zusammen,

 

heute hat mich panisch mein Vater angerufen, der auf seine VMs nicht mehr zugreifen konnte. Beim kurzen überprüfen stellte ich fest, dass alle VMs nicht gestartet waren und beim start Versuch gemeldet haben, dass sie ihre zugeordnete Disk nicht finden. 

Unter den Shares konnte ich dann auch sehen, was das Problem ist:

 

"Vm" und "Vm 2" konnten nicht eingebunden werden, weil kein ... file system mehr vorhanden ist ...?

 

Das klingt für mich erstmal so, als wären die Daten nicht verloren, sondern dass da irgendein Block der das Filesystem darstellt, verloren gegangen ist. Zumindest hoffe ich das, denn seit ein paar Wochen musste ich die Backups der VMs deaktivieren um die Art und weiße wie ich Backupe zu überdenken (volllaufende Speicher etc.).

 

Mit der Voraussetzung, dass die Disks noch existieren (und im besten Fall keine Schäden haben) wie kriege ich das wieder gefixt? Kann ich die beiden Festplatten dann einfach weiter verwenden, oder sollte ich mir neue Zulegen und die Daten übertragen?

 

Ich habe auch mal die Diagnostik drüber laufen lassen, vielleicht ist Problem gar nicht so wild ... allerdings hab ich wenig bis keine Erfahrung darin solche Probleme zu Debuggen ... und ehrlich gesagt will ich auch nichts überstürzen, bevor ich versehentlich Daten von der Platte lösche

unraid-server-diagnostics-20230211-2035.zip

[cz13]

Nachdem das Dateisystem BTRFS ist würde ich hier ansetzten:

https://wiki.unraid.net/Check_Disk_Filesystems Punkt 1.6.2 bzw. 2.2

den scrub kann man auch nur read only ohne Korrekturen laufen lassen um zu sehen ob er etwas findet.

Hab selbst keine Erfahrung damit, deshalb nur der Link zur Doku.

[dxniel7402]

5 hours ago, cz13 said:

Nachdem das Dateisystem BTRFS ist würde ich hier ansetzten:

https://wiki.unraid.net/Check_Disk_Filesystems Punkt 1.6.2 bzw. 2.2

den scrub kann man auch nur read only ohne Korrekturen laufen lassen um zu sehen ob er etwas findet.

Hab selbst keine Erfahrung damit, deshalb nur der Link zur Doku.

 

Leider lässt sich kein scrub ausführen. Sowohl in der webGUI nicht, als auch nicht über die CLI:

 

root@unRAID-Server:~# btrfs scrub start -rdB /dev/vm
ERROR: cannot check /dev/vm: No such file or directory
ERROR: '/dev/vm' is not a mounted btrfs device
root@unRAID-Server:~# btrfs scrub start -rdB /dev/nvme2n1
ERROR: '/dev/nvme2n1' is not a mounted btrfs device
root@unRAID-Server:~# btrfs scrub start -rdB /dev/nvme1n1
ERROR: '/dev/nvme1n1' is not a mounted btrfs device
root@unRAID-Server:~# btrfs scrub start -rdB nvme1n1
ERROR: cannot check nvme1n1: No such file or directory
ERROR: 'nvme1n1' is not a mounted btrfs device

 

Die webGUI sagt zum scrub, dass das Array gestartet sein muss (was es eigentlich auch ist ...).

[cz13]

Sind die Docker und VM Dienste unter Settings deaktiviert und du hast das Array normal gestartet? Nicht im Maintenance Mode.

[dxniel7402]

54 minutes ago, cz13 said:

Sind die Docker und VM Dienste unter Settings deaktiviert und du hast das Array normal gestartet? Nicht im Maintenance Mode.

Hab die beiden Dienste gerade deaktiviert, Array wurde bereits normal, nicht im Maintenance Mode, gestartet. Keine Veränderung sichtbar

[dxniel7402]

Hm aber die Befehle gingen (allerdings nicht mit nvme1n1 und nvme2n1) :

 

root@unRAID-Server:/dev# btrfs check /dev/nvme1n1p1
Opening filesystem to check...
Checking filesystem on /dev/nvme1n1p1
UUID: 200e8534-0c33-49b5-a6a4-b2634c22e872
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 2191846191104 bytes used, no error found
total csum bytes: 2185544
total tree bytes: 1216446464
total fs tree bytes: 630243328
total extent tree bytes: 582959104
btree space waste bytes: 199137645
file data blocks allocated: 13557149679616
 referenced 2038132912128
root@unRAID-Server:/dev# btrfs check /dev/nvme2n1p1
Opening filesystem to check...
Checking filesystem on /dev/nvme2n1p1
UUID: 200e8534-0c33-49b5-a6a4-b2634c22e872
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 2191846191104 bytes used, no error found
total csum bytes: 2185544
total tree bytes: 1216446464
total fs tree bytes: 630243328
total extent tree bytes: 582959104
btree space waste bytes: 199137645
file data blocks allocated: 13557149679616
 referenced 2038132912128

 

Edited February 12, 2023 by dxniel7402

[mgutt]

Der Server muss stromlos gemacht werden. Die NVMe sind komplett weg. Eventuell ist der Pool dann sogar ohne Reparatur wieder da. Scrub sollte man aber in jedem Fall machen.

 

Vorher aber bitte syslogs runterladen und syslog mirror auf USB aktivieren. Du musst herausfinden wann die ersten Fehler waren und warum die NVMe verloren gegangen sind.

[dxniel7402]

Ich habe jetzt auch mal folgende zwei Befehle für die beiden Platten ausgeführt:

btrfs restore /dev/nvme1n1p1 /mnt/user/backup/btrfs_restore
btrfs restore /dev/nvme2n1p1 /mnt/user/backup/btrfs_restore_2

Also Rückmeldung habe ich das erhalten:

...
offset is 851968
offset is 1048576
Short read for 145842241536, read 11780096, read_len 13631488
ERROR: exhausted mirrors trying to read (2 > 1)
ERROR: copying data for /mnt/user/backup/btrfs_restore_2/domains/VM01/vdisk1.img failed
ERROR: searching directory /mnt/user/backup/btrfs_restore_2/domains/VM01/vdisk1.img failed: -1
ERROR: searching directory /mnt/user/backup/btrfs_restore_2/domains/VM01/vdisk1.img failed: -1

Entsprechend liegt jetzt in beiden Ordnern die Datei "vdisk1.img" (jeweils mit Ordnerstruktur) da, aber mehr nicht. Der Fehlermeldung nach sieht es auch irgendwie so aus, als hätte er die Datei zwar angelegt, aber nicht kopiert. 

 

Für mich bedeutet das jedoch ebenfalls, dass theoretisch die Daten noch dort drin liegen und aaslesbar sind. 

 

Hat jemand eine Idee wie ich das jetzt sinnvoll retten kann?...

[dxniel7402]

18 minutes ago, mgutt said:

Der Server muss stromlos gemacht werden. Die NVMe sind komplett weg. Eventuell ist der Pool dann sogar ohne Reparatur wieder da. Scrub sollte man aber in jedem Fall machen.

 

Vorher aber bitte syslogs runterladen und syslog mirror auf USB aktivieren. Du musst herausfinden wann die ersten Fehler waren und warum die NVMe verloren gegangen sind.

 

Hab den syslog_mirror jetzt aktiviert. Hab noch mal die Diagnostik Daten hochgeladen (ich denke mal dort dürfte ebenfalls was vom syslog drin sein).

 

Also versteh ich dich richtig?

Ich soll zunächst den Server herunterfahren, dann den Server komplett vom Strom nehmen, so dass keine Komponente mehr Strom hat -> den Server dann wieder hoch fahren und mit ein bisschen Glück ist der Pool wieder in Tackt? 

 

Das wäre optimal um zumindest alle Daten zu sichern und zu validieren, ob die ganzen Disks auch noch gehen ...

unraid-server-diagnostics-20230212-1732.zip

[mgutt]

1 hour ago, dxniel7402 said:

Also versteh ich dich richtig?

Ich soll zunächst den Server herunterfahren, dann den Server komplett vom Strom nehmen, so dass keine Komponente mehr Strom hat -> den Server dann wieder hoch fahren und mit ein bisschen Glück ist der Pool wieder in Tackt? 

Jo. Da /dev/nvme... nicht mehr da ist, gibt es keinen anderen Weg. Du solltest dir auch mal Gedanken über Backups machen. Siehe zb das VM Backup Plugin oder mein rsync incremental Script.

[DataCollector]

28 minutes ago, mgutt said:

Jo. Da /dev/nvme... nicht mehr da ist, gibt es keinen anderen Weg. Du solltest dir auch mal Gedanken über Backups machen. Siehe zb das VM Backup Plugin oder mein rsync incremental Script.

 

Nur so eine Idee:

Soweit ich es verstanden habe, betrifft das eine unraidmaschine des Vaters (vielleicht sogar räumlich weit entfernt?).

 

Sollte sowas häufiger auftreten, bzw der Fehler nicht permanent behoben werden können, wäre es vielleicht möglich das System des Vaters an eine fernsteuerbare Steckdose zu hängen. Die kann man dann vielleicht über ein VPN-Ferbindung/Fernsteuerungsbefehl aus der Ferne nutzen um mal so für 1 Minute Power abzuschalten, ohne daß Papa unter den Schreitisch kriechen muß.

 

[dxniel7402]

@mgutt Der Server ist jetzt heruntergefahren - ausgestöpselt werden kann er erst morgen. Hoffe sehr, dass das was bringt ^^

Zu den Backups: Bis vor Eingen Wochen (inzwischen eher Monate) hatte ich diese aktiviert, aber musste sie wieder deaktivieren, weil ich da an den Einstellungen etwas anpassen musste ... aber ja, Backups sind das A und O. Sehr ärgerlich, dass das genau dann passiert, wo ich keine mehr angefertigt habe (wie soll es denn auch anders sein :D).

 

@DataCollector Das ist schon eine Hammer Idee! Die werde ich die Tage umsetzen! Danke dir ^^

[mgutt]

2 hours ago, dxniel7402 said:

Der Server ist jetzt heruntergefahren - ausgestöpselt werden kann er erst morgen.

Dann ist er doch stromlos 😉 Hier und da wird vielleicht noch WoL versorgt, aber der Rest wie CPU, PCIe Slots usw ist komplett stromlos, was wir erreichen wollen.

 

Anders wäre es bei einem Neustart. Da bleibt die Stromversorgung des Boards durchgehend erhalten.

[dxniel7402]

7 minutes ago, mgutt said:

Dann ist er doch stromlos 😉 Hier und da wird vielleicht noch WoL versorgt, aber der Rest wie CPU, PCIe Slots usw ist komplett stromlos, was wir erreichen wollen.

 

Anders wäre es bei einem Neustart. Da bleibt die Stromversorgung des Boards durchgehend erhalten.

Aber einschalten kann ich den gerade nicht 😂

[mgutt]

11 minutes ago, dxniel7402 said:

Aber einschalten kann ich den gerade nicht 😂

Smarte Steckdose schon bestellt? 😅

[dxniel7402]

11 hours ago, mgutt said:

Smarte Steckdose schon bestellt? 😅

Zumindest schon mal im Warenkorb 😂.

 

Leider hat das Herunterfahren nichts an der Situation geändert, die beiden M2 SSDs melden immer noch den selben Fehler 😓.

[DataCollector]

5 hours ago, dxniel7402 said:

Leider hat das Herunterfahren nichts an der Situation geändert, die beiden M2 SSDs melden immer noch den selben Fehler 😓.

Stopp!

 

Vorher war Deine Aussage: "Die NVMe sind komplett weg"

 

Das habe ich (und vermutlich auch mgutt) so interpretiert, daß diese Devices in keinster Weise mehr vom System erkannt werden und auch nicht in irgendeiner Form angezeigt werden.

 

Jetzt teilst Du mit, daß "die beiden M2 SSD" den selben Fehler melden.

Damit würden sie jetzt schon mal wieder erkannt und das Problem ist ein anderes/gewandert.

Somit könntest Du jetzt wieder dort ansetzen um zu versuchen das Dateisystem auszulesen/reparieren/etc...

 

Oder was habe ich an den Beiträgen in den falschen Hals bekommen?

😕

 

Edited February 13, 2023 by DataCollector

[dxniel7402]

Just now, DataCollector said:

Stopp!

 

Vorher war Deine Aussage: "Die NVMe sind komplett weg"

 

Das habe ich (und vermutlich auch mgutt) so interpretiert, daß diese Devices in keinster Weise mehr vom System erkannt werden und auch nicht in irgendeiner Form angezeigt werden.

 

Jetzt teilst Du mit, daß "die beiden M2 SSD" den selben Fehler melden.

Damit würden sie jetzt schon mal wieder erkannt und das Problem ist ein anderes/gewandert.

 

Oder was habe ich an den Beiträgen in den falschen Hals bekommen?

😕

 

 

Oh, tut mir leid... da hab ich mich wohl vor lauter Angst um die beiden SSDs falsch ausgedrückt. Tut mir leid!

 

Die beiden SSDs werden grundsätzlich vom System erkannt, allerdings ist kein Zugriff darauf möglich. Beide melden jeweils "Unmountable: No file system" (wie auf dem Screenshot zu sehen), somit kann ich bzw. Unraid nicht darauf Zugreifen. Die folge davon ist, dass die VM Profile nicht auf die "vdisks" zugreifen können.

 

Wie Unraid schon meldet, ist vermutlich das Filesystem kaputt und muss irgendwie repariert werden.

 

Vor wenigen Minuten konnte ich die Daten von beiden Platten (sind scheinbar identisch) retten mit folgendem Befehl:

btrfs restore -isxmSo /dev/nvme2n1p1 /mnt/user/backup/btrfs_restore_2/

(aus der Doku: https://btrfs.wiki.kernel.org/index.php/Restore)

 

Während des restores sind allerdings einige Fehler aufgetreten wie z.B.:

...
offset is 217088
offset is 57344
offset is 4096
Short read for 1099219587072, read 679936, read_len 1114112
ERROR: exhausted mirrors trying to read (2 > 1)
ERROR: copying data for /mnt/user/backup/btrfs_restore_2/domains/test-win11/vdisk1.img failed

 

Allerdings haben die Dateien eine ordentliche Größe und können auch in einer VM gebootet werden, jedoch kommt Windows bisher nicht weit und meldet Boot Fehler. Also scheint irgendwie doch vllt. korrupt zu sein 😕.

 

Das alles ändert jedoch erstmal nicht das Problem, dass die Platten zwar da sind, aber nicht gemounted werden können / darauf zugegriffen werden kann...

[dxniel7402]

Ehrlich gesagt gehen mir die Ideen aus ... Die wiederhergestellten VM Images scheinen nicht wirklich zu funktionieren, dort ist einiges nicht so wie es sein sollte.

 

@DataCollector @mgutt @cz13 Ich glaube die einzige Möglichkeit das ganze wieder ordentlich zum laufen zu bekommen ist, das Filesystem von den beiden Platten wieder zu reparieren. Ich hab aber leider zu wenig Ahnung davon, habt ihr Ideen wie ich hier noch vorgehen könnte? Bin inzwischen ziemlich verzweifelt

[mgutt]

3 hours ago, dxniel7402 said:

btrfs restore -isxmSo /dev/nvme2n1p1

Die Parameter sagen mir nichts. Was machen die? Ansonsten von der anderen NVMe ebenfalls den Restore versuchen. Ist ja schließlich ein RAID1 und vielleicht wurden nicht auf beiden die selben Daten zerlegt.

 

EDIT: Ok hab die Parameter gecheckt. Scheint ok zu sein:

https://btrfs.readthedocs.io/en/latest/btrfs-restore.html

 

 

28 minutes ago, dxniel7402 said:

Filesystem von den beiden Platten wieder zu reparieren.

Scrub. Wenn "btrfs scrub -B" es nicht repariert bekommt, hast du ein großes Problem. Siehe auch:

https://btrfs.readthedocs.io/en/latest/btrfs-scrub.html

 

Danach geht vom Prinzip nur noch "btrfs check --repair" aber das muss der absolut letzte Notnagel sein, denn damit kann man auch alles zerstören, da dieser Modus Daten überschreibt. Siehe auch:

https://btrfs.readthedocs.io/en/latest/btrfs-check.html