24.10.2017, 13:29 UTC+2

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

Lieber Besucher, herzlich willkommen bei: Knoppix Forum | www.KnoppixForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

12.02.2014, 01:36

Datenrettung mit ddrescue

Hi Leute,

Kurz zu meinem Problem. Ner Freundin von mir is die Notebook FP mit empfindlichen Daten abgeschmiert. Hab sie ausgebaut und an den Standrechner angeschlossen. Ne live DVD hab ich mir schon gebrannt und Knoppix erkennt die Festplatte auch soweit. Sie lässt sich nur nicht mounten. Ich hab mich dann mal in ddrescue eingelesen um ein Abbild auf eine meiner am Stand PC hängenden FP's zu machen. Mir ist auch bewusst, dass die FP dann überschrieben wird. Meine Frage ist nun, was wohl der schonenste Befehl wäre um erstmal alle noch fehlerfreien Sektoren auszulesen. ich hab mich ins Handbuch mal eingelesen und würde diesen Befehl ausführen:

ddrescue -n -v /dev/kaputte_FP /dev/frische_FP /mnt/ein_usb_stick/rettung.log

Bin ich da komplett am Holzweg? Vielen Dank im Voraus für die Antworten

Greetz

klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

2

12.02.2014, 02:18

Hallo!

Bei neueren Knoppix-Versionen sollte /mnt/ein_usb_stick/rettung.log eher /media/ein_usb_stick/rettung.log lauten. Außerdem muss der Befehl ddrescue mit root-Rechten ausgeführt werde. Wenn man sich ganz sicher über die Gerätenamen ist, wäre dann m. E. der Befehl

Quellcode

1
sudo ddrescue -n -v /dev/kaputte_FP /dev/frische_FP /media/ein_usb_stick/rettung.log 
auszuführen. Natürlich muss der USB-Stick in das Dateisystem eingebunden sein, wohingegen die beiden Festplatten nicht eingebunden sein sollten. Vorischtshalber würde ich daher zuerst

Quellcode

1
2
sudo umount /dev/kaputte_FP
sudo umount /dev/frische_FP
ausführen. Im schlimmsten Fall gibt es Fehlermeldungen, die man gegebenenfalls besprechen könnte.

3

12.02.2014, 10:02

Hi!

Wegen den Root Rechten hab ich mich einfach mit su in der Konsole als Root angemeldet, ist das das selbe als im Befehl sudo zu schreiben?
Beide FP's sind nicht gemounted und ich werde von den Ergebnissen berichten!

Danke für die Antwort

Grüße!

4

12.02.2014, 10:51

Noch eine Frage:Darf ich die Log Datei auch auf die frische F draufschmeißen oder ist das streng verboten?

also: sudo ddrescue -f -n -v /dev/kaputte_FP /dev/frische_FP /dev/frische_FP/rettung.log

klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

5

12.02.2014, 11:24

Das wäre völlig falsch!

Zunächst einmal wird die frische FP gerade beschrieben, das Logfile wäre also verloren.

Außerdem stimmt die Bezeichnung /dev/frische_FP/rettung.log nicht, weil das Logfile auf ein eingebundenes Dateisystem geschrieben werden muss, nicht jedoch direkt auf das Gerät.

Prinzipiell sollte man folgendes berücksichtigen: Woher ist bekannt, dass die neu beschriebene frische FP sofort über ein verwendbares Dateisystem verfügt? Einen Schreibvorgang sollte man erst nach einem ausführlichen (Oberflächen-/Dateisystem-)Test durchführen.

6

12.02.2014, 11:29

Ok das heißt zuerst die frische FP testen dann versuchen die Daten zu schreiben?
Wie wäre denn der Befehl zum austesten der FP`? Mir sagt er nämlcih eben, dass ich den befehl forcen muss und ich mir darüber im klaren sein soll, dass alles auf der frischen weg ist. Sie ist mit NTFS formatiert und leer

LG

klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

7

12.02.2014, 11:50

Zitat

Ok das heißt zuerst die frische FP testen dann versuchen die Daten zu schreiben?
Wenn Du optimistisch bist, kannst Du diesen Schritt überspringen.

"--force" ist notwendig, weil Du direkt auf ein Gerät schreibst. Meistens kopiert man in eine Datei.

Du könntest zuerst wie geplant alle lesbaren Bereiche mit ddrescue von der alten FP auf die frische FP kopieren. Anschließend würde ich das Logfile anschauen.

Man könnte dann entweder sofort an einem Windows-Rechner mit der frischen FP einen Dateisystemtest durchführen, oder man versucht, fehlende Bereiche mit einem weiteren Durchlauf von ddrescue zu ergänzen.

Welches Dateisystem wird auf der kaputten FP verwendet?

8

12.02.2014, 12:02

Hi,

Nun ja da die relativ neu ist, bin ich schon einigermaßen optimistisch dass es da keine Probleme geben sollte, wenn du das meinst.
Die kauptte hat ebenfalls NFTS.

Gut dann werd ich mal einen ersten Durchlauf starten!

Grüße!

9

12.02.2014, 13:56

So , ich hab ein kleines Problem:

Wenn ich den Befehl sudo ddrescue -f -n -v /dev/kaputte_FP dev/frische_FP /media/usb_Stick/rettung.log eingeben bekomm ich folgende Meldung:

"ddrescue: Error opening logfile '/media/usb_Stick/rettung.log ' for writing: No such file or dirctory"

wenn ich statt media "dev" eingeben bekomme ich : Not a directory

Der USB Stick ist aber gemounted und mit NTFS formatiert.An was könnte das liegen?

Greetz

klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

10

12.02.2014, 14:26

Wie sieht die Ausgabe des Befehls

Quellcode

1
ls -l /media 
aus? Das Wurzelverzeichnis des USB-Sticks muss nach dem Einhängen in das Dateisystem ein Unterverzeichnis von /media sein. Vielleicht hilft auch der Befehl

Quellcode

1
mount |grep media 
die Situation zu klären.

11

12.02.2014, 14:42

Wenn der Stick gemounted ist bekomm ich für ls -l /media folgende Ausgabe:

insgesamt 4
drwxr -xr -x 2 knoppix knoppix 0 Feb 12 14:30 sda1
drwxrwxrwx 2 knoppix knoppix 4096 Jan 1 1970 sdb1 (ist grün untersrichen, das dürfet der Stick sein?)
drwxr -xr -x 2 knoppix knoppix 0 Feb 12 14:30 sdc
drwxr -xr -x 2 knoppix knoppix 0 Feb 12 14:30 sde
drwxr -xr -x 2 knoppix knoppix 0 Feb 12 14:30 sdf
drwxr -xr -x 2 knoppix knoppix 0 Feb 12 14:30 sr0

führe ich dann den Befehl sudo mount |grep media aus erhalte ich:

/dev/sdb1 on /media/sdb1 type vfat (rw, nosuid,nodev,relatime,uid=1000,gid=1000,fmask=1000,dmask=1000,allow_utime0022,codepage=cp850,iocharset=utf8,shortname=wimnt,errors=remount-ro)

Grüße und danke

Edit: hab grad im fdisk -l gesehn, dass der Stick FAT formatiert ist. Kanns daran liegen?

klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

12

12.02.2014, 14:52

Zitat

Der USB Stick ist aber gemounted und mit NTFS formatiert

Zitat

/dev/sdb1 on /media/sdb1 type vfat (rw, nosuid,nodev,relatime,uid=1000,gid=1000,fmask=1000,dmask=1000,allow_utime0022,codepage=cp850,iocharset=utf8,shortname=wimnt,errors=remount-ro)

Ich nehme an, dass der USB-Stick mit dem üblichen FAT32-Dateisystem formatiert wurde.

Da /dev/sdb1 der einizige eingehängte DAtenträger zu sein scheint, wird /media/sdb1 sicherlich richtig sein.

Das Dateisystem FAT(32) wird von Linux gut unterstützt, stellt also kein Problem dar. Es ist in den meisten Fällen unter Linux einem mit NTFS formatierten vorzuziehen.

Ich denke, dass Du jetzt mit der Kopieraktion starten kannst.

13

12.02.2014, 15:04

Es hat geklappt , er ist am kopieren =) , melde mich wieder wenn es Neuigkeiten gibt!

Vielen Dank für die Zeit!

Grüße

14

12.02.2014, 18:07

So, hab mal wieder draufgeschaut und soweit sind 40 GB rescued und 40 MB im errorsize mit 1300 Errors. ... mit den Aussagen wird man in dem Stadium warsch. noch nicht so viel anfangen können aber meine Frage ist, ob ich heute Nache oder so mal interrupten sollte um die Festplatte ein bisschen abkühlen zu lassen. Geht das problemlos mit dem Logfile? ... und ich hab wo gelesen, dass man sich da Logfile jederzeit ansehen kann, in nem neuen Terminal Tab?

Danke und Grüße!

klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

15

12.02.2014, 20:49

Wenn man das darf, könntest Du das Logfile in einem neuen Tab mit dem Befehl

Quellcode

1
less /media/sdb1/rettung.log 
betrachten. Das Programm less dient zum Blättern in Textdateien, verändert diese im Gegensatz zu einem Texteditor aber nicht. Mit der Taste q kann man das Programm verlassen.

Ob die Festplatte zu heiß wird, kannst eigentlich nur Du entscheiden. Vielleicht besitzt Du ein digitales Thermometer oder einen Temperaturfühler für ein Multimeter, womit die äußere Temperatur gemessen werden könnte. Es gibt auch Linux-Software, welche die S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) verwendet. Dazu könntest Du die Seite Ubuntu 9.04: Festplattentemperatur auslesen ansehen. Ich würde das Programm hddtemp ausprobieren. Die ebenfalls erwähnten smartmontools sind bereits auf der Knoppix 7.2.0 CD und DVD enthalten.

Wenn man neue Pakete installieren möchte, benötigt man eine Verbindung zum Internet. Bevor die auf der erwähnten Seite aufgeführten Programme installiert werden können, muss man die Paketliste mit

Quellcode

1
sudo apt-get update
auf den neuesten Stand bringen.

Welche Knoppix-Version verwendest Du?

Wie groß ist eigentlich die zu kopierende Festplatte? Wenn bisher etwa 40 GB in 3 Stunden kopiert wurden, wird sich die Geschwindigkeit vermutlich kaum erhöhen, so dass eine grobe Abschätzung der noch benötigten Zeit möglich sein sollte.

Gruß
Klaus

16

12.02.2014, 22:51

Danke für den Tipp mit dem Logfile.

Solche Sachen besitze ich leider nicht, werd es wohl nach Gefühl abtasten müssen >.<, bzw werd ich mir deinen Link erstmal zu Gemüte führen.
Ich hab Knoppix 7.0.5 auf ner DVD.

Die defekte Platte ist 320 GB groß, davon sind etwa 200 GB Daten drauf. Macht ddrescue da einen Unterschied oder geht er auch die leeren Sektoren durch?

Grüße
Alex

Edit: Danke für den Link, hab mir mit smartctl die Temperatur ausgeben lassen können , gerade bei 34 Grad nach 5 Stunden kopieren is denk ich in Ordnung.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Hoatsteil« (12.02.2014, 22:56)


klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

17

13.02.2014, 01:15

Zitat

Macht ddrescue da einen Unterschied oder geht er auch die leeren Sektoren durch?

Die Festplatte wird vom ersten bis zum letzten Sektor kopiert. Von Lesefehlern sei hier abgesehen.
Der Kopiervorgang könnte also einen Tag lang dauern.

Gruß
Klaus

18

13.02.2014, 11:43

Hi Wieder ein kurzes Update von mir. Über die Nacht ist er jez mit dem kopieren fertig geworden. Es wurden 319,8 GB rescued und 200 MB im errisze.... Jetzt trimmed er die failing Blocks runter, hab grad bemerkt , dass dadurch die Errsize weniger wird. Ich nehm an das ist soweit normal?

Grüße Alex

klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

19

14.02.2014, 12:48

Ich habe die Dokumentation des Programms ddrescue so verstanden, dass die Festplatte bei Verwendung des Arguments "-n" nur einmal gelesen wird, und dass die Fehlerbehandlung erst bei einem weiteren Durchlauf mit dem Argument "-r" durchgeführt würde.

Ist die Kopieraktion inzwischen beendet? Wie lange hat das Programm benötigt?

Gruß
Klaus

20

14.02.2014, 15:52

Hi, ja das dachte ich eigentlich auch. Komisch, wie auch immer , der Kopiervorgang ist "abgeschlossen" ja , in Hochkomma deshalb, weil die 200 MB die im errsize drinen waren jez mit 1,3 KB/s abgeklappert werden und auf die rescued verschoben werden.... Bei dem Tempo wirds halt noch bis Sonntag dauern.... Danach sollte es aber aufhören denn die Option -n überspringt Phase 4 imho., also splitting failed Blocks.... melde mich wieder wenns Neues gibt

Grüße Alex

21

15.02.2014, 10:59

Hi , ddrescue ist nun finished!.... Was sind nun die nächsten Schritte? Soll ich mal versuchen einfach die FP im Windows anzusprechen?

Grüße

Edit: Alles hat geklappt, konnte so gut wie alles retten! Ich danke vielmals für die Hilfe hier im Forum! Einfach top! =)

Grüße Alex

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Hoatsteil« (15.02.2014, 11:17)


klaus2008

Meister

Beiträge: 2 653

Geschlecht: Männlich

22

16.02.2014, 00:49

Dann hast Du Glück gehabt!

In Zukunft sollte man vielleicht ein regelmäßiges Backup der wichtigsten Dokumente in Betracht ziehen :)

Gruß
Klaus

Linux HardwareLinux Computer & PCs | Linux Notebooks & Laptops | Geek Shirts | Geek und Nerd Shirt Shop