Storage Pool crashed - läßt sich die VM noch irgendwie retten?

[Stationary]

Ich habe auf einer der cache SSDs in der DS720+ unter DSM 6.2.4 ein Volume (basic, btrfs) eingerichtet (statt cache) und dort ein paar Daten gespeichert und eine Ubuntu VM installiert. Bei Starten heute morgen ist das Volume als "crashed" angezeigt worden. Die sonstigen Daten auf der SSD lassen sich noch kopieren (läuft gerade).
Gibt es eine Möglichkeit, die Ubuntu VM noch irgendwie zu retten? Migration funktioniert von einem gecrashten Laufwerk nicht mehr. Ein Backup der VM habe ich nicht (bevor jemand fragt), weil alles, was auf der SSD ist/war nicht weiter von Belang ist - im Sinne: ich kann es mit wenig Aufwand wieder neu aufbauen. Aber es wäre natürlich weniger Arbeit, wenn ich die VM noch irgendwie retten könnte.
Sieht jemand eine Chance, wie ich mir die Arbeit ersparen kann und die VM von der gecrashten SSD bekomme?
Und was mache ich am Besten mit der gecrashten SSD, überprüfen, auswerfen und neu einbinden?
Die SSD selbst wird als "healthy" angezeigt, available spare 99%, number of error log entries 1.

 

[Benares]

Gute Frage. Was sagt denn der DSM zur gecrashten SSD? Was die Smart-Werte?
Könntest du bitte mal ein paar Screenshots posten?

 

[Stationary]

Smart-Werte scheinen o.k.:





Power Cycles kommen daher, daß die DS jeden Abend schlafen geht und jeden Morgen wieder hochfährt.



Und der VMM:

 

[Stationary]

Ist das eventuell die Ubuntu VM:


Das würde von der Größe her hinkommen:


Wenn ja, wie bekomme ich sie da herunter? Kann man den LUN-Ordner einfach kopieren? (Edit: Ja, man kann...)

cp -R /volume3/@iSCSI/LUN /volume1/VM-Backup

Und kann man das Ganze dann einfach in einen Ordner /volume1/@iSCSI/LUN kopieren und die VM funktioniert von dort weiter? (Edit: Nein, offenbar nicht so ohne Weiteres, der VMM erkennt sie dort nicht)

 

[Benares]

Du, ich hab keine Ahnung, weil ich VMM schon vor Jahren als unbrauchbar eingestuft habe. Benutzt der iSCSI zur Einbindung der Platten?
Vielleicht ist 2. SSD ja wirklich hin, dafür spricht



Was zeigt die andere SSD da? Ist im Protokoll-Center unter Protokolle, "Laufwerke" dazu was zu finden?

 

[Stationary]

Die andere zeigt 0. Ich habe die SSD jetzt aus dem Pool entfernt, jetzt sind die Daten wie folgt:



Die Fehler sind auf 181 angestiegen!
Außerdem habe ich keine Möglichkeit, die SSD wieder neu einzubinden. Vermutlich muß ich die erst wieder über das Terminal bereitstellen?

Aber schon defekt? Die ist noch kein halbes Jahr alt, nur einmal beschrieben worden und sonst immer nur gelesen.

 

[Stationary]

Hast Du eine Idee, wie ich die wieder initalisiert bekomme?

Edit: Habe sie jetzt neu partitioniert und im Terminal wieder entsprechend eingehängt. Mal schauen, wie es weitergeht. Aber vermutlich muß ich die VM abschreiben und neu aufsetzen. Als storage pool habe ich sie wieder:

 

[Benares]

Nö, keine Ahnung. Ausbauen/Booten/Einbauen/Booten vielleicht?
Nochmal die Frage: Ist im Protokoll-Center unter Protokolle, "Laufwerke" dazu was zu finden?
Wenn ja, lösch dieses Protokoll mal. Manche der Smart-Werte stammen m.E. nicht von den Platten/SSDs, sondern aus den Protokollen.

 

[Stationary]

Habe sie im Terminal neu partitioniert und wieder eingehängt, s.o. Hat natürlich immer noch 181 Fehler. Die hat sie aber ja erst bekommen, nachdem ich alle Daten herunterkopiert habe, keine Ahnung wieso.

Mal sehen, ob ich die VM da jetzt wieder drauf bekomme.

 

[Benares]

Aber du hast schon gelesen, was ich geschrieben habe?

 

[Stationary]

Ja, aber wo lösche ich das Protokoll? Anders gefragt, was für ein Protokoll Center? Meinst Du das Log Center? Und dann "Clear"?

 

[Benares]

Über die 4 Dödels oben links, Hauptmenü, dann Protokoll-Center aufrufen

 

[Stationary]

Die einzigen Einträge dort sind

 

[Benares]

Ach du hast Englisch eingestellt, mag sein, dass es da "Log Center" heißt. Leider auch keine Hinweise

Was mir grad auffällt, dass bei beiden SSDs um 19:21 der Cache disabled wurde. War da ein Reboot?
Schau mal auf das Alter der Dateien unter /var/lib/disk-compatibility. Ich bekam kürzlich eine Meldung, dass ich neu booten solle, weil es "Optimierungen" für meine Platten gäbe . Nicht, dass dir Synology in dieser Beziehung grad ein Ei ins Nest legt. Meine ds415+_host_v7.db ist vom 16.06.2022.

Aber im Moment geh ich einfach davon aus, dass deine eine SSD fehlerhaft ist.

 

[Stationary]

Nein, das war ich mit dem Cache ausschalten. Die VM bekomme ich zwar auf der Konsole wieder da hinkopiert, wo sie war, aber das System erkennt sie nicht. Bin gerade dabei, sie wieder neu aufzusetzen.

Ich denke auch, daß die SSD einen Fehler hat oder gehabt hat. Ist eben eine Konfiguration, die nicht offiziell gemacht werden sollte, weder die 10 GB RAM sind offiziell, noch das SSD Volume.
Ich frage mich bloß, ob ich mit den Werten versuchen sollte, die SSD auf Garantie zu tauschen, die ist grade mal ein halbes Jahr alt. Wobei sie mir da wahrscheinlich die unsafe shutdowns anlasten werden.
Ich schau gleich mal nach der disk compatibility.

 

[Brillenschlange]

Ich frage mich bloß, ob ich mit den Werten versuchen sollte, die SSD auf Garantie zu tauschen, die ist grade mal ein halbes Jahr alt. Wobei sie mir da wahrscheinlich die unsafe shutdowns anlasten werden.

Ich hatte vor kurzem auch eine Samsung SSD einschicken müssen. Es war keine M.2, sondern eine "SAMSUNG SSD 870 EVO 4TB", aber die hat schon nach drei Betriebsmonaten 19 fehlerhafte Sektoren gehabt. Eine zweite hatte laut SMART schon einen defekten Sektor, aber die wollten Sie nicht tauschen, weil Magician keine defekten Sektoren bei der Diagnose angezeigt hatte.

Einfach mal versuchen und ein RMA Ticket auf machen.

 

[Stationary]

Hast Du die bei Samsung reklamiert oder beim Händler?

 

[Brillenschlange]

Bei Samsung. Zuständig für die SSD RMA ist die Firma Hanaro Europe B.V. Diese Wickeln das für Samsung ab. Die Supporthotline von Samsung hat folgende Nummer: 0800 7267864. Die folgende Telefonnummer hatte ich von dann vom Samsung Support erhalten: 0800 80108011.

Hanaro schickt Dir dann eine Mail mit den notwendigen Informationen und Bildern die sie brauchen. Ist ein wenig nervig und fummelig, aber es sollte sich lohnen.

 

[Stationary]

Geschafft...mit ein wenig tricksen in den Konfigurationsdateien des VMM habe ich es geschafft, die alte VM wieder einzubinden: die zuvor gesicherte Ubuntu VM von volume1 wieder auf volume3 kopieren, dann eine neue Ubuntu VM installieren, danach die Verweise auf die vdisk in der Konfigurationsdatei austauschen und am Ende die vdisk der neuen VM löschen. Etwas Bastelei auf der Konsole. Morgen teste ich dann, ob alles noch funktioniert, wie es soll und kümmere mich um den RMA. Vielen Dank für Eure Geduld!

 

[Stationary]

Damit ich mir die Frickelei in Zukunft spare, exportiere ich jetzt erst einmal die VM als OVA… Man kann zwar die vdisk, wie festgestellt, wieder einbinden, aber mit dem Aufwand, daß man erst eine neue VM erstellen muß, der man dann die alte vdisk unterschiebt.
Anfrage an Hanaro ist auch raus.