Linux Linux Server - SSD "ab-ge-raucht" oder doch anderes Problem?

[Tetradrachm]

Servus...

ich bin kein Linux Profi und brauche daher bitte Eure Hilfe. Ich versuche mal alles am besten zu umschreiben, damit Ihr Euch ein Bild machen könnt. Ich habe einen kleinen Rechner gekauft - meines Wissens ist es so ein ARM Rechner - ähnlich dem Raspery - nur jedoch mit größerer Platine (microATX), echten RAM Riegeln, passiv gekühlt. Als Speicher dient eine PCIe NVMe 2 TB SSD. Diesen Rechner betreibe ich als Server - installiert habe ich ein Linux Ubuntu (aktuellste Version).

Erstes Problem.

Dieser kleine Server dient für eine Gruppe von kreativen Künstlern als Workspace hier bei mir. Es sind verschiedene Benutzer eingerichtet, verschiedene Rechte des Zugriffes auf Ordner und freigegebene Netzlaufwerke - was alles einwandfrei funktioniert hat - bis heute Morgen. Seitdem kann ich den "Server" Rechner nicht mehr hoch fahren.

Ich habe Euch mal zwei Bilder angehängt - diese Meldung kam heute Vormittag.

1. Dann habe ich mal gewartet bis heute Nachmittag. Wenn ich den Rechner nun anschalte, dann kommt gar nichts mehr - als nur das Bild des Start-BIOS und dann nur noch ein blinkender Cursor. Sonst gar nichts.

2. Dann habe ich mal testweise die SSD ausgebaut - dann startet wenigstens der Rechner, bringt aber, dass er kein Betriebssystem hat, das er booten kann. Aber immerhin kommt eine Fehlermeldung bei ausgebauter SSD, anstatt wie bei (1) nur der blinkende Cursor.

3. Da ich für mich paar Daten brauche, dachte ich, probiere doch mal aus die SSD in ein T490s zu brauen und zu booten. Dachte das klappt mit Linux so einfach die SSD in einen anderen Rechner und starten. Tut es aber nicht - es kommen Meldungen wie fehlendes ACPI (oder so ähnlich) und ich soll ein manuelles fsck laufen lassen. Aber da traue ich mich erst mal nicht weiter - daher habe ich da jetzt mal nicht weiter gemacht.

* Ok - das ist der Stand des Rechners / Servers mit der SSD. Könnt Ihr bereits da was erkennen was schief gelaufen ist oder läuft?

* Da ich an die Daten heran kommen sollte - überlege ich mir einen PCIe NVMe USB Adapter zu kaufen um die SSD auszulesen. Kann ich die SSD einfach an einen Windows oder Mac Rechner anschließen und die Daten auslesen?

So und jetzt kommt das zweite Problem!

Daten von der SSD auslesen? Hast Du etwa kein Backup Deiner Daten? Doch!

Ich habe an den Linus Rechner / Server eine externe USB HDD angeschlossen. Ubuntu Linux bietet ein eigenes Backup Programm an, dass selbständig die Daten vom Rechner auf ein anderes Medien sichert. Das habe ich auch gemacht! Aber - ich weiß nicht 100% auch seit heute - die externe HDD ist auf einmal leer! Das ist ganz komisch.

Auf der externen HDD gibt es einen Order "linuxserver" (das ist der Rechnername) mit einem TimeStamp vom Dezember 2022. An dem Tag habe ich das erste Mal das Linux Backup Tool gestartet und dabei hat es diesen Ordner erzeugt. Und in diesen Ordner hinein macht das hauseigene Ubuntu Backup Tool ja die Backups. Und ich habe auch immer wieder mal die externe HDD kontrolliert! Und die Ordner waren da! Ich kann nicht sagen ob wirklich immer alles gesichert wurde bis zur letzten Datei - aber unter "linuxserver" waren einzelne Backup Ordner mit meinen ganzen Ordnern und Dateien! Und jetzt - ist nur noch der leere Ordner da!

Also das ein backup nur teilweise gemacht wurde oder einzelne Dateien nicht vorhanden mag alles vorkommen - aber der Linux Server, respektive das Ubuntu backup Programm, löscht doch nicht in dem Haupt-Backup-Ordner auf einmal alle Inhalte!?!

* Entweder Ihr sagt mir jetzt - dass ich mit einem Windows bzw. Mac Rechner auch gar nicht die Ordner und Dateien sehe wenn ich auf die externe HDD anschließe. Das ich dafür Linux benötige.

* Oder ich weiß auch nicht. Man könnte fast meinen - jemand hat auf die externe USB HDD zugegriffen und unter dem Backupordner alle Dateien per Hand gelöscht!? Also ich habe noch nie erlebt, dass ein Backup Programm Ordner und Dateien gelöscht hat - aber den "Ober-Ordner" übrig gelassen hat. Da müsste doch die ganze externe HDD verkorkst sein?



Ok. Ich bitte um Hilfe. Hat jemand Tipps wie ich bei dem Linux Rechner / Server am besten vorgehe? Kann jemand den Log lesen? Kann ich die SSD in ein Thinkpad einbauen zum Testen? Soll ich die interne Linux SSD an einen USB NVMe Adapter anschließen und versuchen mit meinen anderen Rechnern darauf zuzugreifen?

Was ist mit der externen Backup HDD passiert? Kann sich jemand vorstellen was da passiert sein könnte? Dass die SSD heute ausfällt und gleichzeitig auf der externen HDD auf einmal der Oberordner noch da ist aber die Unterordner alle gelöscht - finde ich einen ziemlich komischen Zufall.


DANKE!

 

[Ravensberger]

/dev/... ist die Laufwerkssortierung des Betriebssystem Hier befindet sich das Gerät, also sdb oder die Partition sdb1 als erste Partition auf dem Gerät. Auf diesem Weg werden keine Ordner angesprochen. Dein home hat von Deinem Live-system einen Einhängepunkt bekommen. Richtig ist der Pfad aus dem Bild mit dem ellenlangen Pfad aus der Hash-ID: 76e.../home/server.

Beitrag automatisch zusammengeführt: 3 Mai 2023

Du kannst auch nicht auf ein Gerät schreiben. Finde einmal den Einhängepunkt von Deiner ersten Partition der zweiten Platte heraus, die hier als Gerät sdc1 angeführt wird.

 

[fakiauso]

Mache das mal so wie hier beschrieben. Das weist dd an, bei Lesefehlern weiter zu kopieren und ein fsck kannst Du ggf. aus dem Journal auch auf der Kopie laufen lassen, wenn die Daten übertragen worden sind.

sudo dd if=/dev/sda of=/dev/sdb conv=noerror,sync status=progress

Für die korrekten Laufwerksbezeichnungen kannst Du vorher ein

sudo fdisk -l

laufen lassen. Hat das geklappt, arbeitest Du wie erwähnt auf dem Klon weiter.

 

[Korfox]

Ich würde weiter auf ddrescue setzen. Allerdings nicht auf eine andere Platte klonen, sondern in ein Image. Ddrescue kann Klonvorgänge fortsetzen, wenn es unterbrochen wird (z. B. Weil der Datenträger verschwindet). Dazu braucht es iirc eine Logdatei, die man angibt.

Allerdings bin ich nicht sicher, ob ich nicht auch erst versuchen würde die Ordner per Hand einfach zu kopieren. Das ist definitiv der weniger invasive Eingriff und danach kann man immernoch ddrescue machen und das Image dann wegen mir gzippen, falls doch noch etwas fehlt...

 

[Tetradrachm]

Allerdings bin ich nicht sicher, ob ich nicht auch erst versuchen würde die Ordner per Hand einfach zu kopieren. Das ist definitiv der weniger invasive Eingriff und danach kann man immernoch ddrescue machen und das Image dann wegen mir gzippen, falls doch noch etwas fehlt...

Das "händisch" kopieren habe ich jetzt aufgegeben, da der Explorer sich immer wieder wegen einzelnen Daten aufhängt. Manche Ordner und Unterordner gehen - manche hängen sich einfach auf. Das ist ein undankbares Geschäft das Tage dauern wird - das ich aber, wenn gar nichts mehr geht - am Ende machen werde.

/dev/... ist die Laufwerkssortierung des Betriebssystem Hier befindet sich das Gerät, also sdb oder die Partition sdb1 als erste Partition auf dem Gerät. Auf diesem Weg werden keine Ordner angesprochen. Dein home hat von Deinem Live-system einen Einhängepunkt bekommen. Richtig ist der Pfad aus dem Bild mit dem ellenlangen Pfad aus der Hash-ID: 76e.../home/server.

Beitrag automatisch zusammengeführt: 3 Mai 2023

Du kannst auch nicht auf ein Gerät schreiben. Finde einmal den Einhängepunkt von Deiner ersten Partition der zweiten Platte heraus, die hier als Gerät sdc1 angeführt wird.

Das klappt nicht ... so oder so nicht. Er meldet andauernd, dass er den Pfad nicht findet.

rsync -av --ignore-errors /FFFFFFFF1111112222222/home/server/ordnername /DDDDDDD1111111222222

geht ebensowenig wie

rsync -av --ignore-errors benutzername/media/FFFFFFFF1111112222222/home/server/ordnername benutzername/media/DDDDDDD1111111222222

Ich habe mir im Festplattenmanager die Einhängepunkte anzeigen lassen und den Pfad einfach kopiert. Es gibt ja nur den Hash, als auch /benutzername/media/hash - aber beide Einhängepunkte - weder der komplette noch der nur mit dem Hash - gehen nicht. Der Hash oben ist jetzt natürlich erfunden - aber ich habe aus dem Festplattenmanager die zwei richtigen Hash Werte raus kopiert.

Mache das mal so wie hier beschrieben. Das weist dd an, bei Lesefehlern weiter zu kopieren und ein fsck kannst Du ggf. aus dem Journal auch auf der Kopie laufen lassen, wenn die Daten übertragen worden sind.

sudo dd if=/dev/sda of=/dev/sdb conv=noerror,sync status=progress

Für die korrekten Laufwerksbezeichnungen kannst Du vorher ein

sudo fdisk -l

laufen lassen. Hat das geklappt, arbeitest Du wie erwähnt auf dem Klon weiter.

Ok - ich habe jetzt NICHT sdb3 als Quelle und sdc1 als Ziel genommen - sondern:

sudo dd if=/dev/sdb of=/dev/sdc conv=noerror,sync status=progress

... weil ich will ja die ganze "sdb" auf die ganze "sdc" kopieren / klonen - richtig?

Zumindest läuft das Tool jetzt schon länger als vorher und arbeitet und arbeitet und arbeitet...

 

[zwieblum]

Wennst glück hast rennt das durch ... aber IMO wird sich wieder die nvme mitten drinnen veranschieden. Aber du kannst mal probieren, die nvme mir einem Ventilator zu kühlen, vielleicht hält sie dann länger durch.

 

[Ravensberger]

Und, hattest Du wenigstens gestern oder über Nacht noch einen Erfolg?
Die Pfade, die Du bei rsync verwenden wolltest, gibt es nicht. In dem von Dir angehängten Bild sieht man, dass der Einstig /media ist und es von dort weitergeht. Wenn Du einen Dateimanager offen hast, kopiere den Pfad vollständigen Pfad aus diesem, denn dieser Pfad existiert ganz bestimmt. Unter Windows macht man das auch so. Noch besser ist es, die shell zum Auflösen zu verwenden, also:

rsync -av --ignore-errors /media/ <TABTASTE> k <TABTASTE> u.s.w., so lange, bis der gewünschte Pfad vollständig aufgelöst ist.

Einen Denkfehler hast Du noch: Festplattenlaufwerke unter /dev, wie "device", entsprechen niemals Ordnerpfaden. Das ist anders als unter Windows.

 

[hikaru]

Arbeite bevorzugt auf dem Image und nicht auf dem original Datenträger.

Eigentlich sollte man auf einer Kopie des Images arbeiten, denn man weiß nie, ob man je ein Zweites von der sterbenden SSD ziehen kann. Und wenn man dann sein einziges erfolgreich gezogenes Image kaputtspielt, hat man auch nichts gekonnt.

Allerdings bin ich nicht sicher, ob ich nicht auch erst versuchen würde die Ordner per Hand einfach zu kopieren. Das ist definitiv der weniger invasive Eingriff und danach kann man immernoch ddrescue machen

Wenn gezielt bestimmte Daten gesichert werden sollen, dann definitiv zuerst auf Dateisystemebene kopieren, danach auf Geräteebene! Einige Dateien wird man wohl verloren geben müssen, aber dafür kann man ja dann das (mit extundelete wiederhergestellte) Backup auf der HDD heranziehen.

Das "händisch" kopieren habe ich jetzt aufgegeben, da der Explorer sich immer wieder wegen einzelnen Daten aufhängt.

Nimm ein anderes Tool! Dein Dateimanager (übrigens nicht der "Explorer" - so heißt der Dateimanger von Windows; dein Screenshot hier sieht eher nach Nautilus aus) kann offenbar keine Dateien bei Lesefehlern überspringen. mc kann das.
rsync (auf Mountpoints, nicht auf Devicenames) wäre allerdings der sinnvollere Ansatz.

Einen Denkfehler hast Du noch: Festplattenlaufwerke unter /dev, wie "device", entsprechen niemals Ordnerpfaden. Das ist anders als unter Windows.

Eigentlich ist das unter Windows gar nicht so anders. Das was unter Linux traditionell in der fstab geschieht (welche heute nur noch ein Systemd-Frontend ist), nämlich das Mapping von Devicenames auf Mountpoints, macht Windows in den Untiefen der Registry.
Nur kriegen das die meisten Windows-User nie zu Gesicht.

 

[Korfox]

Eigentlich sollte man auf einer Kopie des Images arbeiten, denn man weiß nie, ob man je ein Zweites von der sterbenden SSD ziehen kann. Und wenn man dann sein einziges erfolgreich gezogenes Image kaputtspielt, hat man auch nichts gekonnt.

Das ist natürlich korrekt, dann braucht man halt nochmal so viel Speicherplatz und wenn man ein image ro einbindet halte ich die Gefahr für recht gering es kaputt zu spielen (ich habe dazu oben nichts geschrieben, aber ich halte es auch für nicht sinnvoll mit chown oder chmod an die Daten vom Originaldatenträger zu kommen, sondern man sollte sich einen User-Account suchen/schaffen, der da dran kommt - für gewöhnlich sollte man mit sudo alles lesen können...). Der originaldatenträger sollte auch nur noch ro eingebunden werden, wenn überhaupt.

 

[Tetradrachm]

Wennst glück hast rennt das durch ... aber IMO wird sich wieder die nvme mitten drinnen veranschieden. Aber du kannst mal probieren, die nvme mir einem Ventilator zu kühlen, vielleicht hält sie dann länger durch.

Aktueller Status...

Ich habe so wie fakiauso in Posting #22 beschrieben gegen 22 Uhr bekommen mit:

sudo dd if=/dev/sda of=/dev/sdb conv=noerror,sync status=progress

... einen Versuch zu starten und seitdem kopiert Linux vor sich hin ohne Unterbrechung. Spricht das ganze läuft jetzt knapp 13 Stunden vor sich hin. Ich werte das mal als positives Zeichen und hoffe, dass die Aktion auch bis zum Ende durch geführt wird.

Bis dahin lasse ich das nun natürlich laufen und bin auf das Ergebnis gespannt. Bricht er ab erneut - werde ich rsync nochmals versuchen. Aber jetzt muss ich das Ganze eh erst mal durch laufen lassen.


----
Nebenbei hat man Zeit nachzudenken. Was mich immer noch verwundert ist, dass die Backup HDD leer ist. Wobei nicht leer - der Oberordner und ein paar andere Ordner waren ja noch unberührt vorhanden - nur die drei Ordner (mit Inhalt), welche von der SSD zur HDD kopiert wurden mittels Tool - die fehlen.

Das Linux Tool das ich verwendet habe - hat einfach die (drei) ausgewählten Ordner von der Linux SSD auf die externe HDD kopiert. Dabei habe ich in den Einstellungen angegeben, dass Ordner und Dateien einmalig rüber kopiert werden als Backup - und danach nur die Dateien, welche sich geändert haben.

Jetzt kam ja die Idee, dass das Tool vielleicht die SSD als "leer" interpretiert hat und damit die Dateien auf der HDD gelöscht.

- die SSD ist aber nicht leer, die Ordner kann ich ja selbst jetzt noch sehen. Und innerhalb der Ordner sind ja sogar viele Dateien ganz normal zu kopieren und zu öffnen - also vorhanden. Nur ein Teil schein "korrupt" zu sein. Wenn dann müsste auf der Backup HDD also nur - wenn überhaupt - einige Dateien fehlen - aber nicht exakt nur die drei Backup Ordner samt Inhalt.

- Zumal das Tool Dateien die auf der Quelle fehlen (durch Löschen zum Beispiel) gar nicht auf der Ziel HDD löscht. Denn das wollte ich nicht, sondern Dateien die auf dem Rechner gelöscht werden, sollen ja als Sicherheitskopie auf der HDD bleiben. Und das war in der Vergangenheit auch so, dass auf der SSD gelöschte Dateien auch auf Backup HDD bleiben.

- Ebenso verwundert, wenn das Tool (selbst wenn) die Inhalte der Backup Ordner löscht - auch die Ordner an sich gelöscht werden! Zum Verständnis. Auf der Backup HDD gab es folgende Hierarchie:

* Dateien
** Bilder
** Videos
** Backups
*** Backup A
***** Ordnername A
*** Backup B
***** Ordnername B
*** Backup C
***** Ordnername A

So - die Ordner oder den Pfad: Dateien / Backups / Backup A habe ich selbst erstellt mit "neu Ordner". Der Pfad ist nicht vom Backup Programm! Dem Backup Tool habe ich dann die Quelle gezeigt und das Ziel. Das Tool hat dann in den Pfad "Dateien / Backups / Backup A" den zu kopierenden Ordner mit Inhalt noch rein kopiert. Wenn das Tool also amok gelaufen ist - müsste wenn alleine "Ordnername A" fehlen. Aber seit Montag gibt oder gab es auf der HDD nur noch:

* Dateien
** Bilder
** Videos

Das finde ich etwas strange ... wieso sollte das Tool bitte den obersten Ordner samt Inhalte löschen? Zumal - auch das muss ich sagen - die drei kopierten (Unterordner) auch drei verschiedene Backup Tasks waren.

Merkwürdig.

 

[Dr_Schmoker]

Die Zielplatte also die sdc hat 1,8Tb. Die Ausgangsplatte sdb hat 1,9Tb. Das könnte noch zum Problem werden.

An den Befehl

sudo dd if=/dev/sdb of=/dev/sdc conv=noerror,sync status=progress

hättest du besser noch ein bs=1M angehangen, weil Zitat:

Hinweis:​

Wenn man keine Blockgröße angibt, verwendet dd eine kleine Standardgröße, was den Datentransfer durch den Overhead sehr langsam macht. Insofern ist es empfehlenswert, z.B. bs=1M anzugeben.

 

[Ravensberger]

Ist das Backup- Programm freeFilesync?
Es ist gut möglich, dass die SSD bereits eine Weile Fehler aufweist und dann die Vergleichskriterien Name, Größe, Alter nicht mehr lesbar oder verfälscht sind. Bei einer defekten Platte ist alles möglich, weshalb man im Idealfall mit mehrstufigen Sicherungen nach dem Kind - Vater - Großvater - Prinzip arbeitet. Für den Heimanwenderfall heißt das: zumindest gelegentliche Backups auf ein drittes Medium OHNE die vorherige Sicherung zu löschen.

 

[cuco]

Ich habe so wie fakiauso in Posting #22 beschrieben gegen 22 Uhr bekommen mit:
sudo dd if=/dev/sda of=/dev/sdb conv=noerror,sync status=progress
... einen Versuch zu starten und seitdem kopiert Linux vor sich hin ohne Unterbrechung. Spricht das ganze läuft jetzt knapp 13 Stunden vor sich hin. Ich werte das mal als positives Zeichen und hoffe, dass die Aktion auch bis zum Ende durch geführt wird.

Du kannst den Status erfahren, in dem du in einem zweiten Fenster folgenden Befehl ausführst:
sudo killall -SIGUSR1 dd
(das -SIGUSR1 ist wichtig, inkl. Bindestrich!)

Dann spuckt der laufende dd-Prozess dir aus, wie weit er momentan ist.

 

[fakiauso]

Spricht das ganze läuft jetzt knapp 13 Stunden vor sich hin. Ich werte das mal als positives Zeichen und hoffe, dass die Aktion auch bis zum Ende durch geführt wird.

Hört sich für mich ebenfalls positiv an und solche Aktionen sind meist klassische Übernachtjobs. Das mit der Blockgröße ist an sich korrekt, mache ich aber bei angeknackten Platten eher ungern. Falls es wirklich der letzte Versuch ist, erscheint mir das langsamere Verfahren fehlersicherer.

Sollte das Abziehen eines Klones so nicht laufen, bleibt immer noch der Weg, per Photorec/Testdisk die Daten separat zu retten.

 

[Korfox]

Du kannst den Status erfahren, in dem du in einem zweiten Fenster folgenden Befehl ausführst:
sudo killall -SIGUSR1 dd
(das -SIGUSR1 ist wichtig, inkl. Bindestrich!)

Dann spuckt der laufende dd-Prozess dir aus, wie weit er momentan ist.

Das tut der Prozess dank status=progress eh schon.

 

[zwieblum]

Die Zielplatte also die sdc hat 1,8Tb. Die Ausgangsplatte sdb hat 1,9Tb. Das könnte noch zum Problem werden.

Der Konjuntiv ist ein Euphemismus dd wird mit Fehler abbrechen und der User ist schlauer. IMO gleich abbrechen und eine Platte suchen, die groß genug ist.

 

[Tetradrachm]

Dann spuckt der laufende dd-Prozess dir aus, wie weit er momentan ist.

Ich trau mich nix anzufassen, bevor das nicht zu Ende ist

Hört sich für mich ebenfalls positiv an und solche Aktionen sind meist klassische Übernachtjobs.

Übernacht... der Prozess läuft immer noch ... ist heute bereits der dritte Tag oder der zweite Tag?

Und er kopiert und kopiert und kopiert und kopiert...

 

[zwieblum]

kannst dir mal ausrechnen wie lang er braucht. Aber er wird mit einem Fehler enden, der Vorgang, weil das Ziel kleiner als die Quelle ist.

 

[Tetradrachm]

kannst dir mal ausrechnen wie lang er braucht. Aber er wird mit einem Fehler enden, der Vorgang, weil das Ziel kleiner als die Quelle ist.

Ganz sicher?

Aktuell ist er bei 1.3TB erledigt kann ich erkennen.

 

[zwieblum]

Siehe Post#30. Aber mach' mal eine andere Konsole auf und tippe:
$ cat /proc/partitions

Ist dein Ziel größer als deine Quelle, dann ist alles OK. Wenn nicht ... tja.

 

[Tetradrachm]

Siehe Post#30. Aber mach' mal eine andere Konsole auf und tippe:
$ cat /proc/partitions

Ist dein Ziel größer als deine Quelle, dann ist alles OK. Wenn nicht ... tja.

Die Quelle - sdb - wird mir leider nicht angezeigt bei Deinem Befehl - aber die Ziel HDD sdc



Was sagt mir das? Lieber gleich abbrechen?