Hi
Ich habe versucht, die Daten einer Festplatte wieder herzustellen. Als
Speicherort des Recovery Tools habe ich mein Synology NAS gewählt. Viele
der wieder hergestellten Dateien sind defekt, darum hab ich sie später
wieder gelöscht.
Als ich nun den Trashcan des Laufwerks auf dem NAS leeren wollte, blieb
ein Ordner über. Ich loggte mich über SSH ins NAS ein und sehe nun, dass
in dem Ordner im Trashcan eine handvoll Dateien liegen, die ich aber
nicht löschen kann. Beim Versuch, sie zu löschen, bekomme ich bei jeder
Datei eine Fehlermeldung in der Form:
rm: cannot remove 'zzz/xyz.jpg': Input/output error
auch mit -f kann ich die Dateien nicht löschen. Hat jemand einen Tipp?
Gerald K. schrieb:> Man könnte es unter Windows mit dem "Unlocker" versuchen.
Ich kann mich auch irren, aber das sieht für mich nicht nach Windows
aus:
Freddy schrieb:> rm: cannot remove 'zzz/xyz.jpg': Input/output error>> auch mit -f kann ich die Dateien nicht löschen.
Frank H. schrieb:> Gerald K. schrieb:>> Man könnte es unter Windows mit dem "Unlocker" versuchen.>> Ich kann mich auch irren, aber das sieht für mich nicht nach Windows> aus:> Freddy schrieb:>> rm: cannot remove 'zzz/xyz.jpg': Input/output error>>>> auch mit -f kann ich die Dateien nicht löschen.
Schon richtig, aber man könnte die Festplatte, sofern die
Festplattenformatierung passt in einen PC als Zweitplatte einbauen und
dann mittel "Unlocker" die Dateien und das Verzeichnis löschen.
Gerald K. schrieb:> Frank H. schrieb:>> Gerald K. schrieb:>>> Man könnte es unter Windows mit dem "Unlocker" versuchen.>>>> Ich kann mich auch irren, aber das sieht für mich nicht nach Windows>> aus:>> Freddy schrieb:>>> rm: cannot remove 'zzz/xyz.jpg': Input/output error>>>>>> auch mit -f kann ich die Dateien nicht löschen.>> Schon richtig, aber man könnte die Festplatte, sofern die> Festplattenformatierung passt in einen PC als Zweitplatte einbauen und> dann mittel "Unlocker" die Dateien und das Verzeichnis löschen.
Seit wann kann Windows mit Linux-Filesystemen umgehen?
Und warum sollte man ein Windows-Tool für Windows-Probleme nutzen für
ein Problem was Unix-Filesysteme nicht haben?
Windows Hater schrieb:> Seit wann kann Windows mit Linux-Filesystemen umgehen?
Ich verwende "Paragon Linux File Systems". Damit kann ich z.B. auch SD
Karten für Raspberry Pi schreiben und lesen.
Thomas W. schrieb:> -> Es ist jetzt an der Zeit ueber die Wirksamkeit Deiner> Backup-Strategie nachzudenken.
die Platten im NAS laufen im Raid5, werden beim ersten SMART Hickup oder
spätestens nach 3 Jahren getauscht.
Ich denke, dass das OS "denkt" der Fehler in den paar Dateien deutet auf
das Filesystem hin; dabei wurden sie eben mit diesem Fehler von der
erwähnten defekten -USB- Festplatte wiederhergestellt
Nun ja, dmesg mal angucken und dann weiter entscheiden. Wenn keine
Fehlermeldungen da sind: fsck ist eventuell Dein Freund wenn Du die
Platte/Partition aushaengen kannst (auch eingehaengt sollte ein fsck
"vernuenftige" Ergebnisse geben).
Gruesse
Th.
P.S.: die Zahlen der Klammern korrigiert
Thomas W. schrieb:> Nun ja, dmesg mal angucken und dann weiter entscheiden. Wenn keine> Fehlermeldungen da sind: fsck ist eventuell Dein Freund wenn Du die> Platte/Partition aushaengen kannst (auch eingehaengt sollte ein fsck> "vernuenftige" Ergebnisse geben).
Es kann auch sein das die FS-Strukturen beschädigt sind und deswegen
Blocknummern drinstehen die "außerhalb" der Platte liegen.
Wenn die Blocknummern der IO-Errors verdächtig groß sind könnte das der
Fall sein. fsck (nur checken, nicht reparieren) ist erst mal nicht
verkehrt.
Wenn du keine Erfahrung mit solchen Sachen hast, solltest du auch erst
mal ganz vorsichtig an die Sache ran gehen um nicht noch mehr kaputt zu
machen.
Freddy schrieb:> Viele> der wieder hergestellten Dateien sind defekt, darum hab ich sie später> wieder gelöscht.
Mit was hast Du versucht die Daten wieder herzustellen?
Freddy schrieb:> die Platten im NAS laufen im Raid5,
Das hat mit Backup nix zu tun, wie man am tollen IO-Error sieht.
> werden beim ersten SMART Hickup oder> spätestens nach 3 Jahren getauscht.
Dann kann es schon zu spät sein ...
Freddy schrieb:> PC-Freak schrieb:>> Mit was hast Du versucht die Daten wieder herzustellen?>> mit EaseUS Data Recovery
Verabschiede dich schon mal von deinen Daten wenn du gleich mit solchen
Automatik Programmen ran gehst, anstatt erst mal mit Bordmitteln und
/dev/brain.
Freddy schrieb:> Viele> der wieder hergestellten Dateien sind defekt, darum hab ich sie später> wieder gelöscht.
Wenn Du auf die Daten abgewiesen bist, kannst Du mir die HDD schicken.
Ich würde versuchen diese (soweit es geht) wieder herzustellen. Klappt
aber nur, wenn Du keine Mega-Recovery versucht hast, bzw die Daten NICHT
auf diese HDD zurück zu schreiben versucht hast.
Freddy schrieb:> Ich denke, dass das OS "denkt" der Fehler in den paar Dateien deutet auf> das Filesystem hin; dabei wurden sie eben mit diesem Fehler von der> erwähnten defekten -USB- Festplatte wiederhergestellt
Nein, einen I/O-Error kann man nicht kopieren. Die Ursache muss eine
andere sein.
LG, Sebastian
Für sowas in Windows war früher immer eine DOS-Diskette gut.
Oder ein Live-Linux.
Live-Windowse gab es ja auch mal, auch diese wären eine Option gewesen.
Fehlerhafter Assemblercode war schwieriger, da war es hilfreich, eine
Textdatei mit Hinweisen mit dazuzulegen.
Meistens hatte ich so "schwierige" Sachen aber nur auf DOS-Disketten
geschrieben.
DOS stürzte auch nicht gleich ab, wie Windows, wenn man so eine
fehlerhafte Datei von Festplatte oder von einer Diskette aufruft.
Für problematische Festplatten gab es u.a. auch diese hilfreichen
Norton-Tools.
rbx schrieb:> Für sowas in Windows war früher immer eine DOS-Diskette gut.> Für problematische Festplatten gab es u.a. auch diese hilfreichen> Norton-Tools.
Kinder kommt rein, die Siebziger sind zu Besuch… ;-)
Ich hab grad gesehen, ich kann auch einen weiteren Ordner nicht löschen.
Diesmal aber nicht wegen input/output error. Hier der ssh Mitschnitt:
Freddy@homeNet:/volume1/Data/#recycle$ ls
c zzz
Freddy@homeNet:/volume1/Data/#recycle$ rm c -r
rm: cannot remove 'c/level7481.0.json.~2~': No such file or directory
rm: cannot remove 'c': Directory not empty
Freddy@homeNet:/volume1/Data/#recycle$ cd c
Freddy@homeNet:/volume1/Data/#recycle/c$ ls
ls: cannot access 'level7481.0.json.~2~': No such file or directory
level7481.0.json.~2~
hat jemand einen Idee?
Freddy schrieb:> hat jemand einen Idee?
Sieht nach Filesystem aus. Deshalb wurde dir schon paarmal fsck
vorgeschlagen. Und genauso oft wurdest du schon nach dmesg gefragt.
Wenn dmesg nicht funktioniert (gibt's das?), kannst du mal sowas
probieren und das Ausgabefile (strace-rm) posten:
1
strace -f -o /tmp/strace-rm rm zzz/xyz.jpg
Andererseits: warum willst du die überhaupt löschen, viel wichtiger wäre
doch, alle anderen Daten vom NAS in Sicherheit zu bringen. Es ist doch
total egal, ob du die defekte Platte mit oder ohne xyz.jpg entsorgst?
Norbert schrieb:> Kinder kommt rein, die Siebziger sind zu Besuch… ;-)
ja, eine überschaubare Filesystem-Auswahl und IT-Genies, die sich sowas
wie Turing-Test, oder Merkbegriffe wie KISS ausdachten.
Frank H. schrieb:> Freddy schrieb:>> hat jemand einen Idee?>> Sieht nach Filesystem aus. Deshalb wurde dir schon paarmal fsck> vorgeschlagen. Und genauso oft wurdest du schon nach dmesg gefragt.
Der TO will sich nicht helfen lassen.
Emil schrieb:> Frank H. schrieb:>> Freddy schrieb:>>> hat jemand einen Idee?>>>> Sieht nach Filesystem aus. Deshalb wurde dir schon paarmal fsck>> vorgeschlagen. Und genauso oft wurdest du schon nach dmesg gefragt.>> Der TO will sich nicht helfen lassen.
Tja...
Freddy schrieb:> Hat jemand einen Tipp?
1.Mach erst mal ein komplettes Backup bevor noch mehr kaputt ist!
2.Versuche nie das eigene System zur Reparatur zu benutzen. Es wird auf
die eigene Platte schreiben, wodurch wertvolle Daten überschrieben
werden könnten.
3.Hast Du als User überhaupt Rechte dort zu löschen?
Hatte ich auch mal, ich konnte die Dinger zwar nicht löschen, aber
ersetzen.
Dazu hab ich in nem anderen Ordner eine Datei erstellt mit exakt
demselben Namen und dann in den Ordner kopiert. Die Nachfrage, Datei
ersetzen mit Ja beantworten und diese Datei konnte gelöscht werden.
Uli S. schrieb:> Hatte ich auch mal, ich konnte die Dinger zwar nicht löschen, aber> ersetzen.> Dazu hab ich in nem anderen Ordner eine Datei erstellt mit exakt> demselben Namen und dann in den Ordner kopiert. Die Nachfrage, Datei> ersetzen mit Ja beantworten und diese Datei konnte gelöscht werden.
Aber das macht doch alles ein fsck selbst. Warum sollte man in einer
kaputten Datenstruktur noch manuell rumfummeln, evtl. macht gerade das
noch mehr kaputt. Ja, man muss das Filesystem unmounten und dafür evtl.
neu booten, aber das geht das alles fix im Gegensatz zum Einspielen
einen Backups (oder dem Gestochere in Resten, falls man keins hat...).
Uli S. schrieb:> Hatte ich auch mal, ich konnte die Dinger zwar nicht löschen, aber> ersetzen.> Dazu hab ich in nem anderen Ordner eine Datei erstellt mit exakt> demselben Namen und dann in den Ordner kopiert. Die Nachfrage, Datei> ersetzen mit Ja beantworten und diese Datei konnte gelöscht werden.
Meist lässt sich eine blockierte Datei auch nicht in einen anderen
Ordner verschieben. Aber vielleicht lässt sie sich im abgesicherten
Modus löschen.
Gerald K. schrieb:> Meist lässt sich eine blockierte Datei auch nicht in einen anderen> Ordner verschieben.
Das ist ja ein logisch nachvollziehbares Verhalten.
Verschieben ist ja ein Löschen am alten Platz PLUS kopieren an den neuen
Platz.
oszi40 schrieb:> Entweder hat er keine ausreichenden Rechte> oder die Datei ist noch im Zugriff> oder das Dateisystem kaputt? https://de.wikipedia.org/wiki/Fsck
Mal schauen, ob jetzt eine Reaktion von ihm kommt.
So oft, wie ihm das schon gesagt wurde...
Freddy schrieb:> Thomas W. schrieb:>> -> Es ist jetzt an der Zeit ueber die Wirksamkeit Deiner>> Backup-Strategie nachzudenken.>> die Platten im NAS laufen im Raid5, werden beim ersten SMART Hickup oder> spätestens nach 3 Jahren getauscht.
Wer auf das Stichwort Backup mit RAID anfängt hat nichts verstanden. Der
Sinn eines RAID ist Verfügbarkeit. Heißt Downtime im Fehlerfall zu
vermeiden. Das hat mit Backup nichts zu tun und es ersetzt auch kein
Backup.
Frank H. schrieb:> Gerald K. schrieb:>> Meist lässt sich eine blockierte Datei auch nicht in einen anderen>> Ordner verschieben.>> Das ist ja ein logisch nachvollziehbares Verhalten.> Verschieben ist ja ein Löschen am alten Platz PLUS kopieren an den neuen> Platz.
Nur wenn es über Dateisystemgrenzen hinweg geschieht oder die
Implementation schlecht ist. Sonst ist es nur ein Umhängen im
Verzeichnisbaum.
Naja, raid ist immerhin schonmal ein klein wenig besser, als gar keine
Zweitkopie. Von meinen wichtigen Daten (ein paar GB), habe ich tägliche
Backups, und behalte die Jahre auf, und das Backup System hat auch
nochmal RAID. Aber für meine paar TB Film Sammlung, hoffe ich einfach,
dass nie zu viele Platten in dessen RAID den geist aufgeben. Das werden
sonst einfach zu viele Festplatten...
Rolf M. schrieb:> Nur wenn es über Dateisystemgrenzen hinweg geschieht oder die> Implementation schlecht ist. Sonst ist es nur ein Umhängen im> Verzeichnisbaum.
Für das "Umhängen" werden doch sicherlich auch bestimmte Berechtigungen
nötig sein. Und da gibt es doch nur rwx--- Wenn dieser Vorgang keine
Berechtigung "x" hat, kann es auch möglich sein, dass das Umhängen nicht
funktioniert. Oder wie ist das?
Dieter D. schrieb:> Wer auf das Stichwort Backup mit RAID anfängt hat nichts verstanden. Der> Sinn eines RAID ist Verfügbarkeit.
Wenn man fälschlicher Weise eine Datei ändert oder womöglich löscht ist
durch Raidsystem nicht geschützt, aber durch ein Backup sehr wohl.
Frank H. schrieb:> Rolf M. schrieb:>> Nur wenn es über Dateisystemgrenzen hinweg geschieht oder die>> Implementation schlecht ist. Sonst ist es nur ein Umhängen im>> Verzeichnisbaum.>> Für das "Umhängen" werden doch sicherlich auch bestimmte Berechtigungen> nötig sein.
Natürlich.
> Und da gibt es doch nur rwx--- Wenn dieser Vorgang keine> Berechtigung "x" hat, kann es auch möglich sein, dass das Umhängen nicht> funktioniert. Oder wie ist das?
Die Berechtigung x ist für das Verzeichnis nötig, ja. Aber wenn man die
Berechtigung nicht hat, kommt als Fehler "Permission denied" und nicht
"Input/output error".
Es wurde bereits mehrfach erwähnt mit dmsg mal zu schauen, ob das
Blockdevice einen i/o error meldet. Wenn das so ist, führen die Versuche
mit rm (und fsck ohne readonly-Option) dazu, das mit jedem "Test" das
Dateisystem potentiell weiter Schaden nimmt. Aufgrund der Lernresistenz
des OT können die Daten nicht wirklich wichtig sein ...
Rolf M. schrieb:> Die Berechtigung x ist für das Verzeichnis nötig, ja. Aber wenn man die> Berechtigung nicht hat, kommt als Fehler "Permission denied" und nicht> "Input/output error".
Stimmt. Das x ist für Directories. Aber für das Umhängen sind doch auch
Berechtigungen nötig. Könnte mir vorstellen, dass es "w" ist. Kann mir
nicht vorstellen, dass das Umhängen ohne jede Berechtigung möglich
ist.(!?)
Eine Datei mit Berechtigung/mode 0o000 lässt sich natürlich völlig
problemlos verschieben (wenn sie einem gehört).
Hier mit inode Anzeige.
1
~/tmp$ l -i dir2
2
insgesamt 0
3
796681 ---------- 1 norbert norbert 0 Aug 29 18:14 AAA
4
~/tmp$ mv dir2/AAA dir1
5
~/tmp$ l -i dir1
6
insgesamt 0
7
796681 ---------- 1 norbert norbert 0 Aug 29 18:14 AAA
8
~/tmp$
Was das ›x‹ wirklich bedeutet kann man aber problemlos herausfinden:
man chmod
oder:
LC_ALL=C man chmod
Allerdings gibt es extended attributes, da ist das Ding dann wirklich
geschützt (selbst gegen eigene Blödheit und auch ›root‹)
Und noch weiter darüber sitzen die Herren Bell und LaPadula.
Freddy schrieb:> Hat jemand einen Tipp?
Lässt sich die Daten denn vllt. umbenennen? Denn wenn nicht liegt es
sicher am Dateinamen oder der Länge davon?
Der einzige richtige Schritt ist nun die Festplatte auf
blockdevice-Level auf Funktion zu prüfen. Sie ist ziemlich sicher
kaputt.
Alle Doktoreien auf FS-Ebene bringen gar nichts.
Freddy schrieb:> auch mit -f kann ich die Dateien nicht löschen. Hat jemand einen Tipp?
Alle Dateien auf andere Festplatte oder großen USB Stick kopieren und
dann Quellfestplatte formatieren.
Gerald K. schrieb:> Alle Dateien auf andere Festplatte oder großen USB Stick kopieren und> dann Quellfestplatte formatieren.
Dieser Rat ist etwas zu pauschal, da bisherige Rechte und Dateidatum
wahrscheinlich bei Deinem einfachem Kopieren verändert werden.
oszi40 schrieb:> Gerald K. schrieb:>> Alle Dateien auf andere Festplatte oder großen USB Stick kopieren und>> dann Quellfestplatte formatieren.>> Dieser Rat ist etwas zu pauschal, da bisherige Rechte und Dateidatum> wahrscheinlich bei Deinem einfachem Kopieren verändert werden.
Platte clonen
oszi40 schrieb:> da bisherige Rechte und Dateidatum> wahrscheinlich bei Deinem einfachem Kopieren verändert werden.
Muss man halt die entsprechende Option angeben.
cp -av
rsync -av
Ich gehe davon aus das NAS basiert auf linux.
Dann ist einfach so dass du keine RECHTE hast das zu löschen.
https://wiki.ubuntuusers.de/chmod/
Linux kann da ab und zu mal sinfolles liefern wenn man sich auskennt.
Frank H. schrieb:> Gerald K. schrieb:>> Meist lässt sich eine blockierte Datei auch nicht in einen anderen>> Ordner verschieben.>> Das ist ja ein logisch nachvollziehbares Verhalten.> Verschieben ist ja ein Löschen am alten Platz PLUS kopieren an den neuen> Platz.
Das kommt darauf an, ob das Kopieren innerhalb desselben Dateisystems
stattfindet oder über Dateisystemgrenzen hinweg. Solange die Datei nur
innerhalb desselben Dateisystems "kopiert" wird, wird sie nur umbenannt.
Marco K. schrieb:> Ich gehe davon aus das NAS basiert auf linux.> Dann ist einfach so dass du keine RECHTE hast das zu löschen.> https://wiki.ubuntuusers.de/chmod/> Linux kann da ab und zu mal sinfolles liefern wenn man sich auskennt.
Richtig ist, dass Linux "ab und zu mal sinfolles liefern" kann, wenn man
sich auskennt. Du kennst Dich aber anscheinend nicht so gut aus, wie Du
denkst, denn wenn Du Dich auskennen würdest, hättest Du erkannt und
verstanden, dass da ein I/O-Fehler gemeldet wird und kein "Permission
denied", wie es bei einem Rechteproblem der Fall wäre. Dieser Hinweis
wurde im Thread, den Du anscheinend auch nicht gelesen hast,
mittlerweile schon mehrfach gegeben.
Im NAS sind 5 Platten die in Raid5 laufen. Ich hab alle Platten einen
extended SMART Test unterzogen, keine davon brachte dabei eine
Fehlermeldung. Wie sollte ich weiter vorgehen?
"Warning: Do not use --repair unless you are advised to do so by a
developer or an experienced user, and then only after having accepted
that no fsck successfully repair all types of filesystem corruption. Eg.
some other software or hardware bugs can fatally damage a volume.".
Ruhe bewahren, Daten sichern, Ursachenforschung betreiben. Erst mal
gucken zu welcher Datei der Block gehört.
Freddy schrieb:> die in Raid5 laufen
Das verschlimmert die Sache noch, wie bei der Weihnachtbaumbeleuchtung.
Eine richtige Datensicherung wäre jetzt nützlich.
Thread beobachten
Seitenaufteilung abschalten