13.08.2017, 01:04
NAS Festplatte (WD My Cloud 4TB) - Daten auslesen / retten
Hallo zusammen,
wohl wieder ein gängiges Problem, mit dem ich aber trotz Forum-Recherche alleine nicht zurechtkomme.
Das das NAS-System nicht mehr funktioniert, habe ich die Festplatte ausgebaut und über USB verbunden.
Anfänglich hatte ich über Win10 (diskInternal oder so...) Zugriff auf die Festplatte und habe einige Daten gesichert. Dann habe ich 1. unbeabsichtigt einen Teil der Daten auf der NAS-Festplatte gelöscht und 2. später keinen Zugrif mehr bekommen.
Nun habe ich als Linux-Neuling Knoppix installiert, komme aber keinen Schritt weiter, um 1. meine Daten vollständig zu sichern (und 2. die gelöschten Daten wiederherzustellen). Beschrieben habe ich die Festplatte seither nicht mehr.
Über jegliche Hilfe würde ich mich sehr freuen!
Unten noch die "lsusb" und fdisk -l" -Ausgaben.
Danke im Voraus!
und
wohl wieder ein gängiges Problem, mit dem ich aber trotz Forum-Recherche alleine nicht zurechtkomme.
Das das NAS-System nicht mehr funktioniert, habe ich die Festplatte ausgebaut und über USB verbunden.
Anfänglich hatte ich über Win10 (diskInternal oder so...) Zugriff auf die Festplatte und habe einige Daten gesichert. Dann habe ich 1. unbeabsichtigt einen Teil der Daten auf der NAS-Festplatte gelöscht und 2. später keinen Zugrif mehr bekommen.
Nun habe ich als Linux-Neuling Knoppix installiert, komme aber keinen Schritt weiter, um 1. meine Daten vollständig zu sichern (und 2. die gelöschten Daten wiederherzustellen). Beschrieben habe ich die Festplatte seither nicht mehr.
Über jegliche Hilfe würde ich mich sehr freuen!
Unten noch die "lsusb" und fdisk -l" -Ausgaben.
Danke im Voraus!
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 |
knoppix@Microknoppix:~$ lsusb Bus 002 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller Bus 002 Device 003: ID 0bb4:2910 HTC (High Tech Computer Corp.) Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 064e:c321 Suyin Corp. Bus 001 Device 009: ID 04ca:3004 Lite-On Technology Corp. Bus 001 Device 008: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser Bus 001 Device 007: ID 04f9:0180 Brother Industries, Ltd MFC-7420 Bus 001 Device 006: ID 174c:1153 ASMedia Technology Inc. ASM2115 SATA 6Gb/s bridge Bus 001 Device 003: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub |
und
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 |
knoppix@Microknoppix:~$ fdisk -l Festplatte /dev/ram0: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram1: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram2: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram3: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram4: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram5: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram6: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram7: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram8: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram9: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram10: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram11: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram12: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram13: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram14: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/ram15: 4 MiB, 4194304 Bytes, 8192 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/cloop0: 9,6 GiB, 10269753344 Bytes, 20058112 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplatte /dev/cloop1: 1009,6 MiB, 1058668544 Bytes, 2067712 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplatte /dev/zram0: 2 GiB, 2071547904 Bytes, 505749 Sektoren Einheiten: Sektoren von 1 * 4096 = 4096 Bytes Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplatte /dev/sda: 931,5 GiB, 1000204886016 Bytes, 1953525168 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplattenbezeichnungstyp: dos Festplattenbezeichner: 0xaa021fc0 Gerät Boot Anfang Ende Sektoren Größe Kn Typ /dev/sda1 2048 31746047 31744000 15,1G 27 Verst. NTFS WinRE /dev/sda2 * 31746048 31950847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda3 31950848 1952598015 1920647168 915,9G 7 HPFS/NTFS/exFAT /dev/sda4 1952598016 1953519615 921600 450M 27 Verst. NTFS WinRE Festplatte /dev/sdb: 18,7 GiB, 20014718976 Bytes, 39091248 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: dos Festplattenbezeichner: 0x064ffdef Gerät Boot Anfang Ende Sektoren Größe Kn Typ /dev/sdb1 2048 39088127 39086080 18,7G 84 versteckte OS/2- oder Intel Ruhepartition Festplatte /dev/sdc: 7,2 GiB, 7744782336 Bytes, 15126528 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: dos Festplattenbezeichner: 0xe2491368 Gerät Boot Anfang Ende Sektoren Größe Kn Typ /dev/sdc1 * 8064 15126527 15118464 7,2G c W95 FAT32 (LBA) Festplatte /dev/sdd: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes Festplattenbezeichnungstyp: gpt Festplattenbezeichner: 0119DFDC-1684-40B4-BE20-1401D258C9E7 Gerät Anfang Ende Sektoren Größe Typ /dev/sdd1 1032192 5031935 3999744 1,9G Linux RAID /dev/sdd2 5031936 9031679 3999744 1,9G Linux RAID /dev/sdd3 30720 1032191 1001472 489M Microsoft Basisdaten /dev/sdd4 9428992 7814035455 7804606464 3,6T Microsoft Basisdaten /dev/sdd5 9031680 9226239 194560 95M Microsoft Basisdaten /dev/sdd6 9226240 9422847 196608 96M Microsoft Basisdaten /dev/sdd7 9422848 9424895 2048 1M Microsoft Basisdaten /dev/sdd8 9424896 9428991 4096 2M Microsoft Basisdaten Partitionstabelleneinträge sind nicht in Festplatten-Reihenfolge. |
13.08.2017, 11:05
Hallo!
Die betreffende Festplatte hat den Namen /dev/sdd erhalten und ist mit GPT eingerichtet. Ich würde jetzt zunächst
und
ausführen, um weitere Informationen zum benutzten Dateisystem zu erhalten.
Welche Knoppix-Version verwendest Du?
Verfügst Du über eine weitere Festplatte mit ausreichender freier Kapazität für zu rettende Daten?
Gruß
Klaus
Die betreffende Festplatte hat den Namen /dev/sdd erhalten und ist mit GPT eingerichtet. Ich würde jetzt zunächst
|
|
Quellcode |
1 |
sudo sgdisk -p /dev/sdd |
|
|
Quellcode |
1 |
sudo blkid /dev/sdd4 |
ausführen, um weitere Informationen zum benutzten Dateisystem zu erhalten.
Welche Knoppix-Version verwendest Du?
Verfügst Du über eine weitere Festplatte mit ausreichender freier Kapazität für zu rettende Daten?
Gruß
Klaus
13.08.2017, 11:50
Hallo,
vielen Dank für das feedback.
Anbei noch ein screenshot nach Versuch auf die sdd4 zuzugreifen im Dateiexplorer.
folgendes erscheint nach Eingabe der Befehle:
und
Wie bekomme ich lange quotes eigentlich mit Bildlaufleiste rechts, damit das post nicht so lang ist?
Danke nochmals und Gruß!
vielen Dank für das feedback.
Anbei noch ein screenshot nach Versuch auf die sdd4 zuzugreifen im Dateiexplorer.
folgendes erscheint nach Eingabe der Befehle:
Zitat
knoppix@Microknoppix:~$ sudo sgdisk -p /dev/sdd
Disk /dev/sdd: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 0119DFDC-1684-40B4-BE20-1401D258C9E7
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 32365 sectors (15.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 1032192 5031935 1.9 GiB FD00 primary
2 5031936 9031679 1.9 GiB FD00 primary
3 30720 1032191 489.0 MiB 0700 primary
4 9428992 7814035455 3.6 TiB 0700 primary
5 9031680 9226239 95.0 MiB 0700 primary
6 9226240 9422847 96.0 MiB 0700 primary
7 9422848 9424895 1024.0 KiB 0700 primary
8 9424896 9428991 2.0 MiB 0700 primary
und
knoppix@Microknoppix:~$ sudo blkid /dev/sdd/dev/sdd: PTUUID="0119dfdc-1684-40b4-be20-1401d258c9e7" PTTYPE="gpt"
Wie bekomme ich lange quotes eigentlich mit Bildlaufleiste rechts, damit das post nicht so lang ist?
Danke nochmals und Gruß!
13.08.2017, 13:00
Es war die Frage nach "sudo blkid /dev/sdd4 " gestellt, nicht "sudo blkid /dev/sdd", damit wir den Typ des Dateisystems erfahren können.
Du könntest "code" statt "quote" verwenden. Dann gibt es auch Zeilennummern, was eine Diskussion einzelner Ergebnisse erleichtern könnte.
Das Bild zeigt einen Hinweis: "dmesg | tail"
Diesen Befehl gibt man im Terminal ein, z. B.
Man erhält die letzten 30 Zeilen der Kernel-Nachrichten.
Gruß
Klaus
Du könntest "code" statt "quote" verwenden. Dann gibt es auch Zeilennummern, was eine Diskussion einzelner Ergebnisse erleichtern könnte.
Das Bild zeigt einen Hinweis: "dmesg | tail"
Diesen Befehl gibt man im Terminal ein, z. B.
|
|
Quellcode |
1 |
dmesg | tail -n 30 |
Gruß
Klaus
13.08.2017, 13:15
ok, skripts eingeschaltet..
....bahnhof...?
D A N K E ! ! !
|
|
Quellcode |
1 2 |
knoppix@Microknoppix:~$ sudo blkid /dev/sdd4 /dev/sdd4: PARTLABEL="primary" PARTUUID="512b8585-3c6a-4d98-b4ae-e6c2698a65c7" |
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
knoppix@Microknoppix:~$ dmesg | tail -n 30 [ 196.485499] Buffer I/O error on dev sdd2, logical block 499952, async page read [ 199.996864] sd 9:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 199.996880] sd 9:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] [ 199.996888] sd 9:0:0:0: [sdd] tag#0 Add. Sense: Unrecovered read error [ 199.996896] sd 9:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 89 d0 00 00 00 00 08 00 00 [ 199.996903] blk_update_request: critical medium error, dev sdd, sector 9031680 [ 203.519627] sd 9:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 203.519642] sd 9:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] [ 203.519650] sd 9:0:0:0: [sdd] tag#0 Add. Sense: Unrecovered read error [ 203.519660] sd 9:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 89 d0 00 00 00 00 08 00 00 [ 203.519666] blk_update_request: critical medium error, dev sdd, sector 9031680 [ 203.519674] Buffer I/O error on dev sdd5, logical block 0, async page read [ 498.485211] FAT-fs (sdd4): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 498.490273] FAT-fs (sdd4): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 498.529937] UDF-fs: warning (device sdd4): udf_fill_super: No partition found (2) [ 498.530685] F2FS-fs (sdd4): Magic Mismatch, valid(0xf2f52010) - read(0xc7e58cb0) [ 498.530693] F2FS-fs (sdd4): Can't find valid F2FS filesystem in 1th superblock [ 498.531335] F2FS-fs (sdd4): Magic Mismatch, valid(0xf2f52010) - read(0x100000) [ 498.531345] F2FS-fs (sdd4): Can't find valid F2FS filesystem in 2th superblock [ 498.531372] F2FS-fs (sdd4): Magic Mismatch, valid(0xf2f52010) - read(0xc7e58cb0) [ 498.531377] F2FS-fs (sdd4): Can't find valid F2FS filesystem in 1th superblock [ 498.531383] F2FS-fs (sdd4): Magic Mismatch, valid(0xf2f52010) - read(0x100000) [ 498.531386] F2FS-fs (sdd4): Can't find valid F2FS filesystem in 2th superblock [ 5685.359770] wlan0: disconnect from AP 30:d3:2d:6f:52:25 for new auth to 30:d3:2d:49:23:c9 [ 5685.368582] wlan0: authenticate with 30:d3:2d:49:23:c9 [ 5685.383339] wlan0: send auth to 30:d3:2d:49:23:c9 (try 1/3) [ 5685.393851] wlan0: authenticated [ 5685.395214] wlan0: associate with 30:d3:2d:49:23:c9 (try 1/3) [ 5685.402369] wlan0: RX AssocResp from 30:d3:2d:49:23:c9 (capab=0x431 status=0 aid=3) [ 5685.402503] wlan0: associated |
....bahnhof...?
D A N K E ! ! !
13.08.2017, 13:28
blk_update_request: critical medium error, dev sdd, sector 9031680
Jetzt wäre der richtige (vielleicht auch letzte, man weiss nie wie lange eine Festplatte durchhält...) Zeitpunkt, eine vollständige Kopie der defekten Platte anzufertigen.
Anschließend könnte man mit testdisk oder photorec sein Glück versuchen. Wie wichtig sind die Daten (oder ist es nur ärgerlich, wenn sie weg sind)?
Auf jeden Fall sollte man vorsichtig vorgehen.
Gruß
Klaus
13.08.2017, 21:55
Hallo ubuntuli,
gerade erst nachträglich Deine Nachricht gelesen...
gerade erst nachträglich Deine Nachricht gelesen...
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
knoppix@Microknoppix:~$ sudo su root@Microknoppix:/home/knoppix# cd /media root@Microknoppix:/media# ls -l insgesamt 12 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 md0 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sda1 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sda2 drwxrwxrwx 1 knoppix knoppix 12288 Aug 10 21:10 sda3 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sda4 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdb1 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdc1 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdd2 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdd4 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdd5 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdd6 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdd7 drwxr-xr-x 2 knoppix knoppix 40 Aug 13 11:38 sdd8 root@Microknoppix:/media# |
14.08.2017, 21:59
Danke.
Ich sehe 4 primäre Festplatten.
Sda1-4 ist die interne FP mit 4 Partitionrn.
sdb und sdc könnten eingebaute Festplatten sein.
Sdd2-8.
Ist sdd die Platte die Du am USB hast?
Du „kannst“ versuchen die Zugriffsrechte zu ändern.
mit diesem Befehl könntest Du die Zugriffsrechte ändern.
sei bitte vorsichting beim benutzen von chmod!
was ich nicht gut finde ist das sdd1 fehlt. sdd1 ist der boot von sdd. wenn der fehlt oder gelöscht ist kannst du die Platte nicht sehen.
Ich sehe 4 primäre Festplatten.
Sda1-4 ist die interne FP mit 4 Partitionrn.
sdb und sdc könnten eingebaute Festplatten sein.
Sdd2-8.
Ist sdd die Platte die Du am USB hast?
Du „kannst“ versuchen die Zugriffsrechte zu ändern.
|
|
Quellcode |
1 2 3 |
sudo su cd /media chmod 777 * |
mit diesem Befehl könntest Du die Zugriffsrechte ändern.
sei bitte vorsichting beim benutzen von chmod!
was ich nicht gut finde ist das sdd1 fehlt. sdd1 ist der boot von sdd. wenn der fehlt oder gelöscht ist kannst du die Platte nicht sehen.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »ubuntuli« (14.08.2017, 23:10)
19.08.2017, 17:17
- Wenn ich unter Windows wäre, würde ich -als letzten Versuch- die HD neu partitionieren / formatieren (und damit wieder überhaupt Zugriff bekommen)
NEIN
Je mehr du an der Platte mit ihren Defekten arbeitest, desto schlimmer wird alles. Deshalb: erst einen Clon anfertigen und zwar von dem, was ist. Ohne Änderungen und Rettungsversuche.
Neu zu Partitionieren löscht zwar noch nicht die alten Daten, aber schon beinahe, weil man mit bloßem Auge nicht mehr sieht, wo die alten Partitionen denn waren. Neu zu formatieren löscht (für gewöhnlich) auch noch nicht die alten Daten, aber es verschlimmert die Situation dramatisch, weil alle Programme nun gar nicht mehr auf die alten Daten schauen, sondern die Beschreibungen des neuen Dateisystems benutzen. Sobald nun auch noch auf dieses neue Dateisystem geschrieben wird, werden die alten Daten zusehends geschrottet, weil durch neue Daten gnadenlos überschrieben.
Also, keinesfalls neu Partitionieren oder neu formatieren.
Erst einen Clon anlegen. Wenn das nicht geht, dann eben mit Risiko direkt an der Platte arbeiten, aber nichts neu machen.
Oder doch noch eine LINUX-Lösung?
Unter GNU/Linux gibt es einige sehr gute Tools, besonders zum Auslesen der vorhandenen Platte. Aber, sie lassen sich ebenfalls täuschen. Wenn du schon irgendwas geändert hattest, sehen viele Tools nur noch das und eben nicht mehr den alten Zustand. Tools, wie fdisk, parted, mmls zum Beispiel, die lesen die Einträge in den Partitionstabellen aus. Sie betrachten nicht direkt die Daten und analysieren diese. photorec und afaik auch testdisk gehen da genau den anderen Weg, sie analysieren die Daten und photorec schaut dabei noch nicht mal auf das vorhandene Dateisystem.
Vielleicht sollte man das etwas näher erklären. So ein Speichermedium muss organisiert sein, damit man die Daten auch wieder findet. Diese Daten liegen zu Einheiten zusammengefasst in kleinen Schubladen verteilt auf dem Medium. Die Organisation der Schubladen passiert im Dateisystem. Meist gibt es dazu sogenannte Header-Daten und/oder Metadaten, in denen die Struktur gespeichert wird. Je nach Dateisystem kann diese Ordnung vollkommen unterschiedlich ausfallen, angefangen von der Größe der einzelnen Schubladen bis hin zur Verteilung von Daten, die logisch zusammen gehören. Ein einziges Bild zum Beispiel kann auf viele Schubladen verteilt sein und diese können wiederum wild umher verteilt sein, oder alle nahe beieinander liegen. Der letztere Zustand wird angestrebt. Nun hat der Datensatz, der das Bild bildet, selbst auch noch Kopfdaten und Zusatzinformationen. In solchen Kopfdaten wird etwa der Dateityp bestimmt (oder beschrieben). Und es gibt Kopfdaten und Fußdaten, also Daten am Ende des Datensatzes. Nach solchen Informationen kann photorec suchen und versucht dann, die Daten zusammenhängend wieder zu restaurieren. Es liest also nicht in den Tabellen die Informationen des Dateisystems, sondern es liest direkt alle Daten durch und hofft, dass es möglichst wenig Durcheinander vorfindet und Daten zusammenhängend wieder herstellen kann.
Zuverlässig ist das nicht.
Die Lage und der Umgang mit den Schubladen macht mehr oder weniger die Eigenschaften eines Dateisystems aus und man kann pro Partition genau ein Dateisystem haben. Legst du nun eine neues Dateisystem auf einer Partition an (neu formatieren), dann werden die Bereiche für die Daten-Schubladen neu aufgeteilt und zugeordnet. Die alten Schubladen sind noch vorhanden, solange nicht neue Daten geschrieben werden. Wo die Schubladen aber liegen und welche Eigenschaften sie haben, das kann man schon nicht mehr sehen, weil diese Information im Dateisystem drin steckte, das durch die neue Formatierung ja abgelöst wurde.
Außer den genannten und womöglich einigen weiteren forensischen Tools, gehen die meisten Programme einen anderen Weg.
Das Betriebssystem muss ein Dateisystem unterstützen und mit der vorhandenen Information kann es dann dieses Dateisystem so einbinden, dass alle Programme transparent auf die Dateien zugreifen können, ohne dass sie selbst das Dateisystem auch noch beherrschen müssen. Das geht nur bei Dateisystemen, für die entsprechende Mechanismen im Betriebssystem eingebaut sind. Bei Knoppix ist ein zusätzlicher Mechanismus für Windows-Dateisysteme eingebaut. Es können keine Dateisysteme mit Fehlern eingebunden werden.
So lange du also nicht etwas formatierst, bleiben die Informationen über die derzeit benutzten Schubladen noch vorhanden und es besteht die Möglichkeit, eventuelle Fehler zu bereinigen (Durcheinander der Schubladen zu korrigieren oder unbrauchbare zu entfernen, den Rest aber wieder zu nutzen).
Ob und was du nun genau machen kannst, ergibt sich erst nach einer entsprechenden Analyse.
Übrigens, ich glaube die Patition ist im ext4-Format
Das wäre toll. Aber die Chance, dass du dann unter einem Windows Daten davon hättest lesen können, sind sehr gering. Windows unterstützt nur FAT und EXFAT und NTFS, afaik. Ob es zusätzliche Programme gibt, die auch ext4 können, kann ich nicht sagen.
Ich werde mir nun die vorherigen Beiträge nochmal genauer ansehen. Die Antwortfrequenz in diesem Forum ist für mich etwas zu niedrig, ich vergesse da zu schnell. Wenn ich etwas sehe, schreibe ich dies in einen neuen Beitrag.
19.08.2017, 17:59
Quellcode
OK. Ich lass das mal hier so stehen, es ist ein Zitat aus deiner fdisk -l Ausgabe.
Man sieht da ziemlich gut, dass die Angaben unter fdisk nicht besonders nützlich sind. Zumindest nicht in diesem Fall.
Die Frage ist, wie wir da nun an verlässlichere Informationen kommen können. Verlässlich so weit, wie das überhaupt noch möglich ist. Immerhin ist da ja was defekt und kann nicht mehr gelesen werden. Es ist gut möglich, dass alle Bemühungen vollkommen vergeblich sind.
Ich würde versuchen:
Knoppix starten. Ein Terminal öffnen. irgendwann müssen wir zum SuperUser werden, vielleicht gleich zu Beginn. Also su und Enter und man ist root.
|
|
Quellcode |
1 |
# dmesg | grep sd |
Letztes Mal ist es bei dir /dev/sdd gewesen und ich gehe im Folgenden davon aus, aber du musst das entsprechend anpassen, wenn es diesmal anders ist.
Wir wollen nun wissen, welche Partitionen vorhanden sind und welche Dateisysteme darauf liegen. Da haben wir mancherlei Möglichkeiten.
|
|
Quellcode |
1 |
# parted /dev/sdd |
|
|
Quellcode |
1 |
# gparted /dev/sdd & |
|
|
Quellcode |
1 |
# apt-get install sleuthkit |
|
|
Quellcode |
1 |
# mmls /dev/sdd |
Man müsste irgendwie eine Liste an Partitionen mit Start- und Stop-Sektor erhalten und vielleicht das passende Dateisystem dazu geliefert bekommen. Dies sehen wir uns aber nochmal genauer an. Es interessiert uns mal auf Verdacht hin die größte Partition auf der Platte und das war zuvor sdd4.
|
|
Quellcode |
1 |
# file -s /dev/sdd4 |
Achtung nochmal: wenn das eine von zwei Platten aus einem Raid-Verband ist, dann geht hier gar nichts mehr und man hampelt sich nur so durch. testdisk hatte zwei Raid-Partitionen und eine SWAP erkannt, das spricht für ein Linux und raid.
Es ist wichtig zu wissen, welches Dateisystem du hast, weil du dann eine Reparatur versuchen kannst. Das ist der erste Schritt, den man noch vor allen anderen Rettungsroutinen probiert.
Man braucht dann in jedem Fall wieder ein Zielmedium, auf das alle Daten kommen können. Das gilt grundsätzlich immer: ein einziges Medium bietet keinerlei Sicherheit. Das macht man einfach nicht.
Probier das mal aus, wenn du magst. Wir sehen da nicht wirklich die Daten, nur die Informationen zu den Dateisystemen. Die können helfen, sie können auch falsch sein. Aber es hilft jedenfalls, sich zu orientieren. Auch und besonders vor einem Einsatz von testdisk. Du weißt sonst ja gar nicht, was du machen möchtest.
20.08.2017, 17:50
Hallo pit234a,
sehr ausführliche Erklärungen, vielen Dank dafür!
Ich gehe mal die emails durch
- Clone anlegen:
eher nicht, da ich nicht in eine neue, teuere 4GB Festplatte investieren möchte. Es sei denn, eine 1 TB-HD würde ausreichen. Eine solche habe ich noch. Die zu rettenden Datenmenge umfasst meiner Erinnerung nach höchstens 700GB. Aber weiter oben habe ich Dich so verstanden, daß die Clone-HD so groß sein muß wie die Original.
-partitionieren / formatieren / Wiederherstellen d Daten:
selbstverständlich lieber auf anderen Weg. Falls es einen anderen Weg gibt.
Diesen Weg allerdings bin ich schon einmal über Windows gegangen: Nach Sicherung d Daten habe ich also neu partitioniert und formatiert. Nur "zu Spaß" habe ich aber eine freeware-Rescue-"Software drüberlaufen lassen und es ließ sich doch erstaunlich viel weiderherstellen.
Wie gesagt, nur zur Erläuterung, nicht um von Dir einen "Segen" dafür zu bekommen.
ext4:
Ich meine (und bin mir ziemlich sicher), bei der Herstellerinfo (Western Digital) gelesen zu haben, daß dies das Format d Festplatte sei.
Die Dateien wurden unter Windows durch die Software "DiskInternals Linux Recovery) z.Teil gerettet.
Dann ist aber wahrscheinlich das aufgetreten, was Du beschreibst. Nämlich, daß durch dieses Vorgehen die Dateisystem-Struktur dahingehend verändert wurde, daß nun kein Zugriff mehr möglich ist. (+ Durcheinander-Benutzen anderer Linux-Reader...)
So, ich fange an:
Weiterhin sdd...
Hier sind nicht so viele Zusatz-Infos, dehalb nächster /Alternativ-Befehl mit angehängtem Bild
und somit der nächste Befehl:
und schließlich
Von ext4-Dateisystem habe ich hier zwar noch nix gelesen, bin mir aber -wie gesagt- ziemlich sicher...
Vielen Dank nochmals für die Hilfe!!!
sehr ausführliche Erklärungen, vielen Dank dafür!
Ich gehe mal die emails durch
- Clone anlegen:
eher nicht, da ich nicht in eine neue, teuere 4GB Festplatte investieren möchte. Es sei denn, eine 1 TB-HD würde ausreichen. Eine solche habe ich noch. Die zu rettenden Datenmenge umfasst meiner Erinnerung nach höchstens 700GB. Aber weiter oben habe ich Dich so verstanden, daß die Clone-HD so groß sein muß wie die Original.
-partitionieren / formatieren / Wiederherstellen d Daten:
selbstverständlich lieber auf anderen Weg. Falls es einen anderen Weg gibt.
Diesen Weg allerdings bin ich schon einmal über Windows gegangen: Nach Sicherung d Daten habe ich also neu partitioniert und formatiert. Nur "zu Spaß" habe ich aber eine freeware-Rescue-"Software drüberlaufen lassen und es ließ sich doch erstaunlich viel weiderherstellen.
Wie gesagt, nur zur Erläuterung, nicht um von Dir einen "Segen" dafür zu bekommen.
ext4:
Ich meine (und bin mir ziemlich sicher), bei der Herstellerinfo (Western Digital) gelesen zu haben, daß dies das Format d Festplatte sei.
Die Dateien wurden unter Windows durch die Software "DiskInternals Linux Recovery) z.Teil gerettet.
Dann ist aber wahrscheinlich das aufgetreten, was Du beschreibst. Nämlich, daß durch dieses Vorgehen die Dateisystem-Struktur dahingehend verändert wurde, daß nun kein Zugriff mehr möglich ist. (+ Durcheinander-Benutzen anderer Linux-Reader...)
So, ich fange an:
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 |
knoppix@Microknoppix:~$ su root@Microknoppix:/home/knoppix# dmesg | grep sd [ 1.852218] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 2.939326] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) [ 2.939328] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.939334] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 2.939450] sd 0:0:0:0: [sda] Write Protect is off [ 2.939457] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.939600] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.019763] sda: sda1 sda2 sda3 sda4 [ 3.020498] sd 0:0:0:0: [sda] Attached SCSI disk [ 3.279287] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 3.279304] sd 1:0:0:0: [sdb] 39091248 512-byte logical blocks: (20.0 GB/18.6 GiB) [ 3.279711] sd 1:0:0:0: [sdb] Write Protect is off [ 3.279716] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 3.279871] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.280525] sdb: sdb1 [ 3.280967] sd 1:0:0:0: [sdb] Attached SCSI disk [ 4.079708] usbcore: registered new interface driver ums-isd200 [ 4.079796] usbcore: registered new interface driver ums-sddr09 [ 4.079809] usbcore: registered new interface driver ums-sddr55 [ 4.112985] sdhci: Secure Digital Host Controller Interface driver [ 4.112991] sdhci: Copyright(c) Pierre Ossman [ 4.113140] wbsd: Winbond W83L51xD SD/MMC card interface driver [ 4.113146] wbsd: Copyright(c) Pierre Ossman [ 4.113634] sdhci-pltfm: SDHCI platform and OF driver helper [ 4.280739] FAT-fs (sda): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 4.311750] UDF-fs: warning (device sda): udf_fill_super: No partition found (2) [ 4.312760] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.312777] F2FS-fs (sda): Can't find valid F2FS filesystem in 1th superblock [ 4.312975] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.312979] F2FS-fs (sda): Can't find valid F2FS filesystem in 2th superblock [ 4.312991] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.313004] F2FS-fs (sda): Can't find valid F2FS filesystem in 1th superblock [ 4.313008] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.313012] F2FS-fs (sda): Can't find valid F2FS filesystem in 2th superblock [ 4.315386] FAT-fs (sdb): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 4.330141] UDF-fs: warning (device sdb): udf_fill_super: No partition found (2) [ 4.331107] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.331114] F2FS-fs (sdb): Can't find valid F2FS filesystem in 1th superblock [ 4.331464] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.331469] F2FS-fs (sdb): Can't find valid F2FS filesystem in 2th superblock [ 4.331490] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.331494] F2FS-fs (sdb): Can't find valid F2FS filesystem in 1th superblock [ 4.331497] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 4.331500] F2FS-fs (sdb): Can't find valid F2FS filesystem in 2th superblock [ 4.334065] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 4.444895] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 4.508170] FAT-fs (sda3): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 5.321259] FAT-fs (sda4): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 5.394624] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 5.413857] UDF-fs: warning (device sdb1): udf_fill_super: No partition found (2) [ 5.414688] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0xffffffff) [ 5.414707] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 1th superblock [ 5.414940] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 5.414945] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 2th superblock [ 5.414958] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0xffffffff) [ 5.414971] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 1th superblock [ 5.414974] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 5.414977] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 2th superblock [ 5.871235] sd 8:0:0:0: Attached scsi generic sg2 type 0 [ 5.871761] sd 8:0:0:0: [sdc] 15126528 512-byte logical blocks: (7.74 GB/7.21 GiB) [ 5.872369] sd 8:0:0:0: [sdc] Write Protect is off [ 5.872378] sd 8:0:0:0: [sdc] Mode Sense: 45 00 00 00 [ 5.872987] sd 8:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 5.930042] sdc: sdc1 [ 5.933183] sd 8:0:0:0: [sdc] Attached SCSI removable disk [ 7.425564] FAT-fs (sda): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 7.516176] UDF-fs: warning (device sda): udf_fill_super: No partition found (2) [ 7.517327] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.517337] F2FS-fs (sda): Can't find valid F2FS filesystem in 1th superblock [ 7.517511] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.517515] F2FS-fs (sda): Can't find valid F2FS filesystem in 2th superblock [ 7.517528] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.517532] F2FS-fs (sda): Can't find valid F2FS filesystem in 1th superblock [ 7.517536] F2FS-fs (sda): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.517539] F2FS-fs (sda): Can't find valid F2FS filesystem in 2th superblock [ 7.520622] FAT-fs (sdb): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 7.535882] UDF-fs: warning (device sdb): udf_fill_super: No partition found (2) [ 7.536775] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.536783] F2FS-fs (sdb): Can't find valid F2FS filesystem in 1th superblock [ 7.537139] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.537145] F2FS-fs (sdb): Can't find valid F2FS filesystem in 2th superblock [ 7.537156] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.537159] F2FS-fs (sdb): Can't find valid F2FS filesystem in 1th superblock [ 7.537163] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.537167] F2FS-fs (sdb): Can't find valid F2FS filesystem in 2th superblock [ 7.539832] FAT-fs (sdc): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 7.590786] UDF-fs: warning (device sdc): udf_fill_super: No partition found (2) [ 7.592538] F2FS-fs (sdc): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.592544] F2FS-fs (sdc): Can't find valid F2FS filesystem in 1th superblock [ 7.593033] F2FS-fs (sdc): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.593037] F2FS-fs (sdc): Can't find valid F2FS filesystem in 2th superblock [ 7.593048] F2FS-fs (sdc): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.593052] F2FS-fs (sdc): Can't find valid F2FS filesystem in 1th superblock [ 7.593066] F2FS-fs (sdc): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 7.593069] F2FS-fs (sdc): Can't find valid F2FS filesystem in 2th superblock [ 7.596484] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 7.711618] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 7.771617] FAT-fs (sda3): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 8.588240] FAT-fs (sda4): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 8.665131] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 8.685495] UDF-fs: warning (device sdb1): udf_fill_super: No partition found (2) [ 8.686654] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0xffffffff) [ 8.686671] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 1th superblock [ 8.687092] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 8.687099] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 2th superblock [ 8.687112] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0xffffffff) [ 8.687116] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 1th superblock [ 8.687119] F2FS-fs (sdb1): Magic Mismatch, valid(0xf2f52010) - read(0x0) [ 8.687122] F2FS-fs (sdb1): Can't find valid F2FS filesystem in 2th superblock [ 8.690350] FAT-fs (sdc1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 8.693430] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [ 116.513527] sd 9:0:0:0: Attached scsi generic sg3 type 0 [ 116.517208] sd 9:0:0:0: [sdd] Spinning up disk... [ 126.712804] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16). [ 126.713252] sd 9:0:0:0: [sdd] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) [ 126.713259] sd 9:0:0:0: [sdd] 4096-byte physical blocks [ 126.714359] sd 9:0:0:0: [sdd] Write Protect is off [ 126.714366] sd 9:0:0:0: [sdd] Mode Sense: 43 00 00 00 [ 126.715539] sd 9:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 126.716636] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16). [ 126.791075] sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6 sdd7 sdd8 [ 126.794520] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16). [ 126.797263] sd 9:0:0:0: [sdd] Attached SCSI disk [ 130.430802] sd 9:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 130.430817] sd 9:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] [ 130.430834] sd 9:0:0:0: [sdd] tag#0 Add. Sense: Unrecovered read error [ 130.430838] sd 9:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 89 cf 80 00 00 00 08 00 00 [ 130.430841] blk_update_request: critical medium error, dev sdd, sector 9031552 [ 133.875387] sd 9:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 133.875414] sd 9:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] [ 133.875422] sd 9:0:0:0: [sdd] tag#0 Add. Sense: Unrecovered read error [ 133.875430] sd 9:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 89 cf 80 00 00 00 08 00 00 [ 133.875436] blk_update_request: critical medium error, dev sdd, sector 9031552 [ 133.875443] Buffer I/O error on dev sdd2, logical block 499952, async page read [ 137.440878] sd 9:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 137.440884] sd 9:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] [ 137.440887] sd 9:0:0:0: [sdd] tag#0 Add. Sense: Unrecovered read error [ 137.440890] sd 9:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 89 d0 00 00 00 00 08 00 00 [ 137.440893] blk_update_request: critical medium error, dev sdd, sector 9031680 [ 140.886345] sd 9:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 140.886351] sd 9:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] [ 140.886354] sd 9:0:0:0: [sdd] tag#0 Add. Sense: Unrecovered read error [ 140.886358] sd 9:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 89 d0 00 00 00 00 08 00 00 [ 140.886360] blk_update_request: critical medium error, dev sdd, sector 9031680 [ 140.886363] Buffer I/O error on dev sdd5, logical block 0, async page read [ 141.018820] md: bind<sdd1> |
Weiterhin sdd...
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
root@Microknoppix:/home/knoppix# parted /dev/sdd GNU Parted 3.2 Using /dev/sdd Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ASMT 2115 (scsi) Disk /dev/sdd: 4001GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 3 15,7MB 528MB 513MB primary msftdata 1 528MB 2576MB 2048MB primary raid 2 2576MB 4624MB 2048MB ext3 primary raid 5 4624MB 4724MB 99,6MB primary msftdata 6 4724MB 4824MB 101MB primary msftdata 7 4824MB 4826MB 1049kB primary msftdata 8 4826MB 4828MB 2097kB primary msftdata 4 4828MB 4001GB 3996GB primary msftdata |
Hier sind nicht so viele Zusatz-Infos, dehalb nächster /Alternativ-Befehl mit angehängtem Bild
|
|
Quellcode |
1 2 3 4 5 6 7 |
root@Microknoppix:/home/knoppix# gparted /dev/sdd & [1] 4338 root@Microknoppix:/home/knoppix# Failed to list units: No such method 'ListUnitsFiltered' Too few arguments. ====================== libparted : 3.2 ====================== |
und somit der nächste Befehl:
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
root@Microknoppix:/home/knoppix# apt-get install sleuthkit
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
sleuthkit is already the newest version (4.2.0-3).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
root@Microknoppix:/home/knoppix# mmls /dev/sdd
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
000: Meta 0000000000 0000000000 0000000001 Safety Table
001: ------- 0000000000 0000030719 0000030720 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
003: Meta 0000000002 0000000033 0000000032 Partition Table
004: 002 0000030720 0001032191 0001001472 primary
005: 000 0001032192 0005031935 0003999744 primary
006: 001 0005031936 0009031679 0003999744 primary
007: 004 0009031680 0009226239 0000194560 primary
008: 005 0009226240 0009422847 0000196608 primary
009: 006 0009422848 0009424895 0000002048 primary
010: 007 0009424896 0009428991 0000004096 primary
011: 003 0009428992 7814035455 7804606464 primary
012: ------- 7814035456 7814037167 0000001712 Unallocated
|
und schließlich
|
|
Quellcode |
1 2 |
root@Microknoppix:/home/knoppix# file -s /dev/sdd4 /dev/sdd4: data |
Von ext4-Dateisystem habe ich hier zwar noch nix gelesen, bin mir aber -wie gesagt- ziemlich sicher...
Vielen Dank nochmals für die Hilfe!!!
20.08.2017, 19:42
ich selbst traue mich ja kaum, dazu etwas zu empfehlen. Aus der Ferne sieht das nach Totalschaden aus. Keines der Tools erkennt ein gültiges Dateisystem.
Die Chance ist sehr groß, dass es mal ein ext4 gewesen ist. Mir ist die Zuordnung nicht vollkommen klar und ich verstehe nicht, wieso ein Raid mit zwei Partitionen auf einer einzigen Platte aufgebaut wird, aber so scheint das nun mal gewesen zu sein. Irgendwo dürfte auch noch eine Swap gewesen sein und all das ist nicht mehr erkennbar und vermutlich deshalb, weil neue Dateisysteme angelegt worden sind. Ich vermute, dass damit und vielleicht einigen anderen Aktionen alle Daten unrettbar verloren sind.
Die Platte ist außerdem wenigstens beschädigt, sie ist kurz vorm Sterben, wie es scheint und da kann natürlich irgendwie alles passieren.
Ich will dir da wirklich jede Hoffnung nehmen, noch irgendwas retten zu können.
Alles, was man normalerweise tun würde, ist schon vereitelt worden.
Ich sage dir nun, was ich an deiner Stelle machen würde, anstatt alles gleich aufzugeben und weg zu schmeißen. Du magst es versuchen, aber nicht enttäuscht sein, wenn es keinerlei Erfolg hat.
Nimm die große Platte zusätzlich, die du noch hast. Die defekte ist /dev/sdd in deinen letzten Ausgaben und sie hat eine große Partition, die wir als Partition mit den Daten annehmen wollen, die wir versuchen zu retten. Die zusätzliche, große Platte wird dann /dev/sde werden. Sieh zu, dass du sie vorher in NTFS formatierst (damit du sie gleich auch unter deinem Windows wieder nativ verwenden kannst). Wenn sie FAT ist, ändere das bitte. FAT kann nur 4G große Dateien und ist nicht mehr zeitgemäß. Du kannst das unter einem Windows einfach und bequem machen, es geht auch einfach grafisch mit Knoppix und gparted (der bei dir aber offenbar zuvor nicht gestartet war, seltsam). Wenn du glaubst, dass du keine Dateien größer 4G zu retten hast und nun einfach mal schnell sehen möchtest, ob überhaupt noch was geht, dann lass es eben bei FAT (Falls es das überhaupt ist). Ich habe nun nicht mehr in Erinnerung, wie groß dein freier Platz auf den eingebauten Platten ist. Du kannst natürlich auch diese als Zielmedium für den Rettungsversuch nehmen. Sei aber bereit, dass es große Probleme gibt, wenn der Platz nicht ausreicht und man braucht unter Umständen deutlich mehr Platz, als Daten vorhanden sind (natürlich, falls denn noch was gerettet werden kann). Mach dich auch bereit, dass der Vorgang sehr lange dauern kann. Ich nenne im Beispiel nachher /media/sde1/Ziel den Pfad, wohin die Daten gerettet werden sollen. Das musst du dann nach deinen Gegebenheiten anpassen. Es sollte der Ort sein, zu dem die Daten sollen.
Wenn du die externe Platte nimmst, lass sie sich mounten und den Dateimanager öffnen, dann siehst du sofort den mountpoint, also den Zielpfad.
Die defekte Platte lass wieder sdd sein, vergewissere dich dessen zuvor.
Wenn du ein System mit Overlay-Partition benutzt, ist der sleuthkit noch installiert, ansonsten musst du die Installation wiederholden.
Sieh zunächst wieder nach, ob die Partitionen noch stimmen und alles korrekt ist:
dies ist die Zeile mit der großen Partition, die wir als Datenpartition annehmen wollen. Wichtig ist, wo diese startet: 9428992, denn das geben wir dem "Rettungsbefehl" mit.
Ich nehme seit Jahren immer gerne den sleuthkit und der hat auch eine Art GUI, Autopsy und wir könnten die auch bemühen und viel tiefer gehende Analysen machen, aber ich würde es einfach mit dem Programm tsk_recover aus dem sleuthkit probieren und sehen, ob da noch was geht. Dazu lies dir die man page durch, also im Terminal man tsk_recover. Man sollte niemals einfach nachmachen, was andere einem empfehlen. Immer selbst denken und verstehen. Ich kann sehr leicht etwas übersehen und Fehler machen. Ich gebe alle diese Befehle wieder als root ein und zeige das jeweils durch den vorgestellten # in einer Zeile an.
Dein Befehl wäre nun etwa:
tsk_recover fängt dann an der Stelle an zu suchen, wo die Partition beginnt (-o 9428992). Es kann auch Daten finden, wenn das Dateisystem eine Macke hat und auch auf fremden Dateisystemen, sofern der sleuthkit sie selbst kennt. Man kann auch in der Option -f ein Dateisystem angeben, aber tsk_recover kann auch einen Automatismus benutzen und es selbst herausfinden. Manchmal geht das nicht und dann solltest du den Befehl mit Dateisystem versuchen, aber ich schätze mal, dass das ext4 ohnehin zerstört ist und nicht mehr geht.
Wenn du tsk_recover so benutzt, also mit -ev, dann schreibt es alle Dateien in dein Ziel, die es noch erkennen kann. Mit dem -v wird einfach nur auch etwas ausgegeben, ansonsten würdest du nicht sehen, ob überhaupt etwas passiert. Mit -a anstatt -e kannst du nur solche Dateien suchen, die nicht zuvor schon gelöscht waren und mit nur -v und ohne -e oder -a würden ausschließlich gelöschte Dateien wieder hergestellt. Du könntest das auch nacheinander machen und im Ziel getrennte Ordner anlegen und dann auch dorthin sichern lassen. Ist das verständlich?
testdisk kann grundsätzlich so etwas ähnliches und photorec auch (habe ich gelesen). Dass beide bei dir kein Ergebnis brachten, ist ein guter Hinweis darauf, dass nichts mehr zu holen ist.
Ich habe eben selbst die meiste Erfahrung mit sleuthkit und kann dir da halt einen Tip zur Anwendung geben. Ich wollte aber nicht den Eindruck erwecken, als könne ich irgendwas besser, als die anderen Teilnehmer schon vorgeschlagen hatten. Und ich zaubere nicht, ich erkläre mir selbst Dinge und hoffe, dass man dann auch versteht, wieso ich Vorschläge so mache.
Mit dem GUI Autopsy (das einfach zu installieren aber nicht so einfach zu handhaben ist), könnten auch Daten analysiert und ausgelesen und neu sortiert in ein Ziel kopiert werden. Ich weiß nicht, ob das besser oder tiefgreifender ist, als tsk_recover. Bevor es tsk_recover gab, habe ich das manchmal angewendet, aber seither genügte mir eigentlich immer das einfache Programm im Terminal.
Wenn du Lust hast, es zu probieren, werden wir ja sehen, ob es irgendwas macht. Wenn es nichts mehr macht (ich vermute, dass das in irgendeiner Form so sein wird), können wir vielleicht noch mit Autopsy spielen, aber ich denke nicht, dass das uns dann noch weiter bringen wird.
Die entscheidenden Fehler zum kontaminieren des Leichnams wurden schon gemacht. Da kann (unsre kostenlose und von uns Unbedarften benutzte) Forensik-SW nicht mehr einfach so viel raus holen. Deshalb scheiterte auch photorec, wahrscheinlich.
Du musst dich aber nicht zu sehr ärgern. Auch dann, wenn du (und deine benutzten Programme) alles richtig gemacht hätten, wäre die Chance groß, dass alle Daten verloren sind. Die Platte macht echt Ärger (falls nicht vielleicht die Spannungsversorgung zu schwach ist für sie). Du solltest da keine Erwartungen haben, alleine schon deshalb. Es ist fraglich, ob sie überhaupt einen kompletten recovery überstehen kann.
PS: ich sehe gerade, dass du doch noch ein Bild mit dem gparted bekommen hast. Das sehe ich mir noch an, stelle dies aber schon mal Online.
Die Chance ist sehr groß, dass es mal ein ext4 gewesen ist. Mir ist die Zuordnung nicht vollkommen klar und ich verstehe nicht, wieso ein Raid mit zwei Partitionen auf einer einzigen Platte aufgebaut wird, aber so scheint das nun mal gewesen zu sein. Irgendwo dürfte auch noch eine Swap gewesen sein und all das ist nicht mehr erkennbar und vermutlich deshalb, weil neue Dateisysteme angelegt worden sind. Ich vermute, dass damit und vielleicht einigen anderen Aktionen alle Daten unrettbar verloren sind.
Die Platte ist außerdem wenigstens beschädigt, sie ist kurz vorm Sterben, wie es scheint und da kann natürlich irgendwie alles passieren.
Ich will dir da wirklich jede Hoffnung nehmen, noch irgendwas retten zu können.
Alles, was man normalerweise tun würde, ist schon vereitelt worden.
Ich sage dir nun, was ich an deiner Stelle machen würde, anstatt alles gleich aufzugeben und weg zu schmeißen. Du magst es versuchen, aber nicht enttäuscht sein, wenn es keinerlei Erfolg hat.
Nimm die große Platte zusätzlich, die du noch hast. Die defekte ist /dev/sdd in deinen letzten Ausgaben und sie hat eine große Partition, die wir als Partition mit den Daten annehmen wollen, die wir versuchen zu retten. Die zusätzliche, große Platte wird dann /dev/sde werden. Sieh zu, dass du sie vorher in NTFS formatierst (damit du sie gleich auch unter deinem Windows wieder nativ verwenden kannst). Wenn sie FAT ist, ändere das bitte. FAT kann nur 4G große Dateien und ist nicht mehr zeitgemäß. Du kannst das unter einem Windows einfach und bequem machen, es geht auch einfach grafisch mit Knoppix und gparted (der bei dir aber offenbar zuvor nicht gestartet war, seltsam). Wenn du glaubst, dass du keine Dateien größer 4G zu retten hast und nun einfach mal schnell sehen möchtest, ob überhaupt noch was geht, dann lass es eben bei FAT (Falls es das überhaupt ist). Ich habe nun nicht mehr in Erinnerung, wie groß dein freier Platz auf den eingebauten Platten ist. Du kannst natürlich auch diese als Zielmedium für den Rettungsversuch nehmen. Sei aber bereit, dass es große Probleme gibt, wenn der Platz nicht ausreicht und man braucht unter Umständen deutlich mehr Platz, als Daten vorhanden sind (natürlich, falls denn noch was gerettet werden kann). Mach dich auch bereit, dass der Vorgang sehr lange dauern kann. Ich nenne im Beispiel nachher /media/sde1/Ziel den Pfad, wohin die Daten gerettet werden sollen. Das musst du dann nach deinen Gegebenheiten anpassen. Es sollte der Ort sein, zu dem die Daten sollen.
Wenn du die externe Platte nimmst, lass sie sich mounten und den Dateimanager öffnen, dann siehst du sofort den mountpoint, also den Zielpfad.
Die defekte Platte lass wieder sdd sein, vergewissere dich dessen zuvor.
Wenn du ein System mit Overlay-Partition benutzt, ist der sleuthkit noch installiert, ansonsten musst du die Installation wiederholden.
Sieh zunächst wieder nach, ob die Partitionen noch stimmen und alles korrekt ist:
|
|
Quellcode |
1 |
# mmls /dev/sdd |
|
|
Quellcode |
1 |
003 0009428992 7814035455 7804606464 primary |
dies ist die Zeile mit der großen Partition, die wir als Datenpartition annehmen wollen. Wichtig ist, wo diese startet: 9428992, denn das geben wir dem "Rettungsbefehl" mit.
Ich nehme seit Jahren immer gerne den sleuthkit und der hat auch eine Art GUI, Autopsy und wir könnten die auch bemühen und viel tiefer gehende Analysen machen, aber ich würde es einfach mit dem Programm tsk_recover aus dem sleuthkit probieren und sehen, ob da noch was geht. Dazu lies dir die man page durch, also im Terminal man tsk_recover. Man sollte niemals einfach nachmachen, was andere einem empfehlen. Immer selbst denken und verstehen. Ich kann sehr leicht etwas übersehen und Fehler machen. Ich gebe alle diese Befehle wieder als root ein und zeige das jeweils durch den vorgestellten # in einer Zeile an.
Dein Befehl wäre nun etwa:
|
|
Quellcode |
1 |
# tsk_recover -ev -o 9428992 /dev/sdd /media/sde1/Ziel |
tsk_recover fängt dann an der Stelle an zu suchen, wo die Partition beginnt (-o 9428992). Es kann auch Daten finden, wenn das Dateisystem eine Macke hat und auch auf fremden Dateisystemen, sofern der sleuthkit sie selbst kennt. Man kann auch in der Option -f ein Dateisystem angeben, aber tsk_recover kann auch einen Automatismus benutzen und es selbst herausfinden. Manchmal geht das nicht und dann solltest du den Befehl mit Dateisystem versuchen, aber ich schätze mal, dass das ext4 ohnehin zerstört ist und nicht mehr geht.
Wenn du tsk_recover so benutzt, also mit -ev, dann schreibt es alle Dateien in dein Ziel, die es noch erkennen kann. Mit dem -v wird einfach nur auch etwas ausgegeben, ansonsten würdest du nicht sehen, ob überhaupt etwas passiert. Mit -a anstatt -e kannst du nur solche Dateien suchen, die nicht zuvor schon gelöscht waren und mit nur -v und ohne -e oder -a würden ausschließlich gelöschte Dateien wieder hergestellt. Du könntest das auch nacheinander machen und im Ziel getrennte Ordner anlegen und dann auch dorthin sichern lassen. Ist das verständlich?
testdisk kann grundsätzlich so etwas ähnliches und photorec auch (habe ich gelesen). Dass beide bei dir kein Ergebnis brachten, ist ein guter Hinweis darauf, dass nichts mehr zu holen ist.
Ich habe eben selbst die meiste Erfahrung mit sleuthkit und kann dir da halt einen Tip zur Anwendung geben. Ich wollte aber nicht den Eindruck erwecken, als könne ich irgendwas besser, als die anderen Teilnehmer schon vorgeschlagen hatten. Und ich zaubere nicht, ich erkläre mir selbst Dinge und hoffe, dass man dann auch versteht, wieso ich Vorschläge so mache.
Mit dem GUI Autopsy (das einfach zu installieren aber nicht so einfach zu handhaben ist), könnten auch Daten analysiert und ausgelesen und neu sortiert in ein Ziel kopiert werden. Ich weiß nicht, ob das besser oder tiefgreifender ist, als tsk_recover. Bevor es tsk_recover gab, habe ich das manchmal angewendet, aber seither genügte mir eigentlich immer das einfache Programm im Terminal.
Wenn du Lust hast, es zu probieren, werden wir ja sehen, ob es irgendwas macht. Wenn es nichts mehr macht (ich vermute, dass das in irgendeiner Form so sein wird), können wir vielleicht noch mit Autopsy spielen, aber ich denke nicht, dass das uns dann noch weiter bringen wird.
Die entscheidenden Fehler zum kontaminieren des Leichnams wurden schon gemacht. Da kann (unsre kostenlose und von uns Unbedarften benutzte) Forensik-SW nicht mehr einfach so viel raus holen. Deshalb scheiterte auch photorec, wahrscheinlich.
Du musst dich aber nicht zu sehr ärgern. Auch dann, wenn du (und deine benutzten Programme) alles richtig gemacht hätten, wäre die Chance groß, dass alle Daten verloren sind. Die Platte macht echt Ärger (falls nicht vielleicht die Spannungsversorgung zu schwach ist für sie). Du solltest da keine Erwartungen haben, alleine schon deshalb. Es ist fraglich, ob sie überhaupt einen kompletten recovery überstehen kann.
PS: ich sehe gerade, dass du doch noch ein Bild mit dem gparted bekommen hast. Das sehe ich mir noch an, stelle dies aber schon mal Online.
20.08.2017, 19:50
Anbei das Gparted-Phto nach mehrfachen Abbrechen
das spricht auch dafür, dass die Platte einfach hin ist.
gparted braucht allerdings auch immer eine Weile, bis das gerät gescannt ist.
Dafür zeigt es sehr schön, was es erkennt und man sieht die beiden Partitionen, die mal das System in einem raid drauf hatten und wovon eine als ext3 erkannt und eingebunden wird und man sieht die ehemalige SWAP Partition und man sieht alles weitere ist Müll und ohne zugeordnete Daten. Öd und leer, könnte man sagen.
Also, da wird wohl nichts mehr gehen, selbst, wenn die Platte das noch durchhalten sollte.
Du könntest aber auch noch einen Backup des Systems machen (auf /media/sdd2 eingebunden). Irgendwie willst du ja vielleicht wieder eine Platte in den NAS bringen und dann braucht der ja ein System. Das hast du nun wahrscheinlich noch greifbar. Das ist die einzige intakte Datenpartition. Und da könntest du übrigens auch mal in der /etc/fstab nachsehen (also /media/sdd2/etc/fstab), als was dort die Dateisysteme gemountet worden waren.
20.08.2017, 19:58
Bevor ich beginne, habe ich noch eine Frage zu der zusätzlichen 1TB-HD (sde).
Hoffentlich verkompliziere ich die Situation nicht allzusehr.
Die Festplatte ist an einem Samsung-TV mit Aufnahmen, welche selbstverständlich nicht lebenswichtig sind.
Kann ich diese (ca 150GB) erhalten und trotzdem für unsere Rettungsaktion benutzen? Indem ich sie partitioniere?
Anbei Infos zu der HD (Auszug aus fdisk -l):
Und Screenshots vom Dateimanager und Laufwerksübersicht:
Hoffentlich verkompliziere ich die Situation nicht allzusehr.
Die Festplatte ist an einem Samsung-TV mit Aufnahmen, welche selbstverständlich nicht lebenswichtig sind.
Kann ich diese (ca 150GB) erhalten und trotzdem für unsere Rettungsaktion benutzen? Indem ich sie partitioniere?
Anbei Infos zu der HD (Auszug aus fdisk -l):
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 |
Festplatte /dev/sde: 931,5 GiB, 1000204886016 Bytes, 1953525168 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: dos Festplattenbezeichner: 0x7ca0e0d3 Gerät Boot Anfang Ende Sektoren Größe Kn Typ /dev/sde1 2048 1953520064 1953518017 931,5G 7 HPFS/NTFS/exFAT |
Und Screenshots vom Dateimanager und Laufwerksübersicht:
20.08.2017, 20:14
Kann ich diese (ca 150GB) erhalten und trotzdem für unsere Rettungsaktion benutzen? Indem ich sie partitioniere?
du brauchst keine gesonderte Partition. Leg nur zur Übersicht einen beliebigen Ordner als Zielordner an und benutze den.
Auf eine Merkwürdigkeit dabei gehe ich nun nicht ein, wir können sie ignorieren. Die Platte hat eine Partition und wurde wie erwartet als sde1 erkannt und nach /media/sde1 eingebunden. Leg zB einen Ordner "Ziel" an oder "Rettung" oder so und benutze dann diesen als Zielordner, also durch Angabe des Pfades /media/sde1/Ziel oder /media/sde1/Rettung oder was auch immer. Oder lege zwei Ordner an, für deletete und nicht deletete Dateien, falls du das möchtest.
Du könntest auch direkt nach /media/sde1 kopieren, aber falls tatsächlich etwas dort ankommt, dann müllt dir das den Ort unnötig zu. Deshalb ist es übersichtlicher, einen extra Ordner dafür zu setzen.
Eine eigene Partition bietet zusätzliche Risiken und sie ist in der Größe unnötig begrenzt. So steht dir der komplette freie Platz zur Verfügung und würde bei viel Glück mit Daten gefüllt.
20.08.2017, 20:32
hab's ziemlich fix wieder ausgespuckt bekommen...
..wird das Ziel-Verzeichnis eigentlich automatisch erstellt? Denn unter dem Dateimanager hatte ich keine "Berechtigung"
..wird das Ziel-Verzeichnis eigentlich automatisch erstellt? Denn unter dem Dateimanager hatte ich keine "Berechtigung"
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 |
root@Microknoppix:/home/knoppix# tsk_recover -ev -o 9428992 /dev/sdd /media/sde1/Ziel tsk_img_open: Type: 0 NumImg: 1 Img1: /dev/sdd aff_open: Error determining type of file: /dev/sdd aff_open: Datei oder Verzeichnis nicht gefunden tsk_img_findFiles: /dev/sdd found tsk_img_findFiles: 1 total segments found raw_open: segment: 0 size: 4000787030016 max offset: 4000787030016 path: /dev/sdd fsopen: Auto detection mode at offset 4827643904 raw_read: byte offset: 4827643904 len: 65536 raw_read: found in image 0 relative offset: 4827643904 len: 65536 raw_read_segment: opening file into slot 0: /dev/sdd ntfs_open: Incorrect NTFS magic fatfs_open: Incorrect FATFS magic ext2fs_open: invalid magic raw_read: byte offset: 4827709440 len: 65536 raw_read: found in image 0 relative offset: 4827709440 len: 65536 ufs_open: Trying 256KB UFS2 location raw_read: byte offset: 4827906048 len: 65536 raw_read: found in image 0 relative offset: 4827906048 len: 65536 ufs_open: Trying UFS1 location ufs_open: No UFS magic found raw_read: byte offset: 20992 len: 65536 raw_read: found in image 0 relative offset: 20992 len: 65536 raw_read: byte offset: 2048 len: 65536 raw_read: found in image 0 relative offset: 2048 len: 65536 raw_read: byte offset: 156160 len: 65536 raw_read: found in image 0 relative offset: 156160 len: 65536 raw_read: byte offset: 137216 len: 65536 raw_read: found in image 0 relative offset: 137216 len: 65536 raw_read: byte offset: 291328 len: 65536 raw_read: found in image 0 relative offset: 291328 len: 65536 raw_read: byte offset: 272384 len: 65536 raw_read: found in image 0 relative offset: 272384 len: 65536 raw_read: byte offset: 426496 len: 65536 raw_read: found in image 0 relative offset: 426496 len: 65536 raw_read: byte offset: 407552 len: 65536 raw_read: found in image 0 relative offset: 407552 len: 65536 raw_read: byte offset: 561664 len: 65536 raw_read: found in image 0 relative offset: 561664 len: 65536 raw_read: byte offset: 542720 len: 65536 raw_read: found in image 0 relative offset: 542720 len: 65536 raw_read: byte offset: 696832 len: 65536 raw_read: found in image 0 relative offset: 696832 len: 65536 raw_read: byte offset: 677888 len: 65536 raw_read: found in image 0 relative offset: 677888 len: 65536 raw_read: byte offset: 832000 len: 65536 raw_read: found in image 0 relative offset: 832000 len: 65536 raw_read: byte offset: 813056 len: 65536 raw_read: found in image 0 relative offset: 813056 len: 65536 raw_read: byte offset: 967168 len: 65536 raw_read: found in image 0 relative offset: 967168 len: 65536 raw_read: byte offset: 948224 len: 65536 raw_read: found in image 0 relative offset: 948224 len: 65536 raw_read: byte offset: 1102336 len: 65536 raw_read: found in image 0 relative offset: 1102336 len: 65536 raw_read: byte offset: 1083392 len: 65536 raw_read: found in image 0 relative offset: 1083392 len: 65536 raw_read: byte offset: 1237504 len: 65536 raw_read: found in image 0 relative offset: 1237504 len: 65536 raw_read: byte offset: 1218560 len: 65536 raw_read: found in image 0 relative offset: 1218560 len: 65536 yaffsfs_open: could not find valid spare area format See http://wiki.sleuthkit.org/index.php?title=YAFFS2 for help on Yaffs2 configuration raw_read: byte offset: 4827644928 len: 65536 raw_read: found in image 0 relative offset: 4827644928 len: 65536 iso9660_open img_info: 18446744071562996680 ftype: 2048 test: 1 iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 Trying RAW ISO9660 with 16-byte pre-block size fs_prepost_read: Mapped 32768 to 4827681552 iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 Trying RAW ISO9660 with 24-byte pre-block size fs_prepost_read: Mapped 32768 to 4827681560 iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 iso9660_open: Error loading volume descriptor Cannot determine file system type (Sector offset: 9428992)Files Recovered: 0 |
20.08.2017, 23:10
Denkst Du, daß die Festplatte hardwareseitig defekt ist?
Aufgrund der Meldungen in dmesg, die im Verlauf dieses Threads häufiger gelistet wurden, sieht es so aus. Du hast die Platte nicht in deinen PC eingebaut und über eine externe Lösung betrieben. Da kann es auch sein, dass Fehler von hier kommen, weil vielleicht das benutzte Netzteil zu schwach für die Platte ist oder Kabel schlechten Kontakt machen. Das sollte vor einem Test jedenfalls ausgeschlossen werden. Der Einbau, auch nur provisorisch, in deinen PC könnte eine Alternative sein und dürfte auch schneller für die eh langsamen Tests laufen.
Echte Stresstests sind immer schwer zu bekommen. Wenn deine Platte eingebaut ist, dürfte sie SMART-tauglich sein (über USB geht das oft nicht) und dann gibt es die smartmontools und damit kann auch getestet werden. Ich werde mal im Netz suchen und die Tage vielleicht Artikel nennen, die das gut beschreiben. Oder such selbst mal im Ubuntu-Wiki, das ist immer eine gute Anlaufstelle.
Ein weiterer Test, langsam, aber recht gut, ist badblocks aus den e2fsprogs. Hier muss man aber auch zuvor lesen, wie das geeignet verwendet wird. Es kann auch zerstörerisch eingesetzt werden.
Sodann kann man sich selbst eine große Datei anlegen und eine Quersumme dazu bestimmen. Diese Datei schreibt man dann auf die Platte und kontrolliert immer wieder die Quersumme. Man schreibt und liest die Datei am Besten von der Platte auf ein anderes Medium und zurück. Wenn ausreichend RAM vorhanden ist, kann man den sehr gut dazu nutzen. Das kann man in einem script laufen lassen und die Dateinamen hochzählen. Wenn man dann gleichzeitig den smartd laufen hat, kann man sich das Verhalten der Platte schon mal ganz gut ansehen. Für diesen Test ist es sinnvoll, die Platte mit einem Dateisystem zu versehen. Man kann aber auch ohne dies mittels dd arbeiten. Man muss sich das zuvor überlegen, auch, wie man später weiter machen möchte. Jedenfalls sollte man das so auslegen, dass tatsächlich die Platte mehrmals komplett beschrieben und ausgelesen wird. Bei 4T dauert das extrem lange. Auch die anderen erwähnten Tests.
Wie das mit Windows aussieht, weiß ich gar nicht. Ich benutze das nicht. Ich benutze auch kein Linux und Knoppix nur gelegentlich und selten, deshalb kenne ich mich hier auch nicht gut aus. Aber das Ubuntu-Wiki oder Arch-Linux-Wiki sind meist gute Anlaufstellen. Da bekommt man gute Erklärungen und viele Beispiele.
Wie du weiter machen willst, ist eine gute Frage.
Du kannst nicht einfach eine neue Platte kaufen und in den NAS hängen. Es sieht jedenfalls so aus, als sei das System des NAS ja auf der Platte installiert. Du brauchst also das System wieder, damit du den NAS überhaupt betreiben kannst und das könntest du nun noch sichern. Das war die eine erhaltene Datenpartition. Es ist fraglich, ob das alles überhaupt reibungslos laufen würde, wenn du die Platte nun in den NAS zurück baust. Möglicherweise hat die SW des NAS bereits Tests für die Platte mit eingebaut, die du dann abrufen könntest. Selbst, wenn das alles funktioniert und die Platte keine Mucken macht und du sie neu formatieren kannst, musst du dir ein Konzept für Datensicherung überlegen. Eine Platte ist niemals sicher!
21.08.2017, 10:36
photorec
ich hatte ja schon erwähnt, dass ich mich immer auf sleuthkit gestützt hatte. Von testdisk und photorec hatte ich nur gelesen. photorec glaubte ich sogar, gar nicht auf meinem rechner zu haben. Erst Gestern erkannte ich, dass es teil des testdisk-Kits ist und da habe ich es mir mal genauer angesehen.
photorec macht genau das, was ich zuvor mal beschrieben hatte. Es durchkämmt die Platte Bitweise und erkennt irgendwelche übrig gebliebenen Daten. Es fragt dabei nach dem Dateisystem, findet aber auch Daten, die noch von anderen Dateisystemen übrig geblieben sind. Das geht wohl nur mit solchen Daten, die zusammen hängen und nicht defragmentiert sind und am Besten deshalb mit kleineren Paketen, die möglichst komplett in einer Schublade liegen.
Anders gesagt: der Spruch ist ja, dass man nicht damit umgehen kann, wenn man mit dem sleuthkit nicht weiter kommt. Mit photorec hätte es ein Ergebnis geben müssen, wenn man nicht grundsätzlich was falsch macht oder die Partition komplett gelöscht oder (mit Nullen) überschrieben wurde oder ein gravierender HW-Defekt vorliegt. Also noch einfacher und zwingender, als mit dem sleuthkit.
Dein Aufruf für photorec wäre ja gewesen:
und dann hättest du irgendwas wählen müssen und es hätte irgendwas gefunden werden müssen. Du musst einen Speicherort bestimmen, wohin die Ergebnisse landen.
Es wird nicht der Inhalt der alten Platte repariert oder so, dort wird nur lesend zugegriffen, nur gescannt. Dein Speicherort muss also beschreibbar sein und ausreichend Platz bieten. Es werden dort unter Umständen viele Daten landen, denn es gibt viel Müll, der als irgendwas erkannt wird.
Vielleicht hattest du das falsch verstanden.
photorec macht genau das, was ich zuvor mal beschrieben hatte. Es durchkämmt die Platte Bitweise und erkennt irgendwelche übrig gebliebenen Daten. Es fragt dabei nach dem Dateisystem, findet aber auch Daten, die noch von anderen Dateisystemen übrig geblieben sind. Das geht wohl nur mit solchen Daten, die zusammen hängen und nicht defragmentiert sind und am Besten deshalb mit kleineren Paketen, die möglichst komplett in einer Schublade liegen.
Anders gesagt: der Spruch ist ja, dass man nicht damit umgehen kann, wenn man mit dem sleuthkit nicht weiter kommt. Mit photorec hätte es ein Ergebnis geben müssen, wenn man nicht grundsätzlich was falsch macht oder die Partition komplett gelöscht oder (mit Nullen) überschrieben wurde oder ein gravierender HW-Defekt vorliegt. Also noch einfacher und zwingender, als mit dem sleuthkit.
Dein Aufruf für photorec wäre ja gewesen:
|
|
Quellcode |
1 |
# photorec /dev/sdd4 |
und dann hättest du irgendwas wählen müssen und es hätte irgendwas gefunden werden müssen. Du musst einen Speicherort bestimmen, wohin die Ergebnisse landen.
Es wird nicht der Inhalt der alten Platte repariert oder so, dort wird nur lesend zugegriffen, nur gescannt. Dein Speicherort muss also beschreibbar sein und ausreichend Platz bieten. Es werden dort unter Umständen viele Daten landen, denn es gibt viel Müll, der als irgendwas erkannt wird.
Vielleicht hattest du das falsch verstanden.
22.08.2017, 02:55
Sagt jetzt bitte nicht, dass die Platte immer noch über USB dran hängt?
Das (von einem Beitrag ganz am Anfang) sieht für mich so aus, als ob zu viel Strom gezogen wurde, und der USB dicht gemcht hat:
Platte intern anschliessen, SMART-Werte auslesen.
Dann wissen, ob Platte physisch im Eimer oder nur Dateisysteme geschreddert.
Letzteres kann schon beim allerersten Versuch passiert sein!?
Muss noch nicht mal an Windows liegen, falls der Controller wegen Überstrom dicht gemacht hat, während Du kopiertest.
Ob es ein EXT4 Dateisystem war, können wir nur raten, genau so kann es XFS oder sonst was gewesen sein.
Dass dort zwei RAID-Partitionen gleicher Grösse zu sehen sind, ist zugegeben etwas seltsam?
Ja, man könnte auch so ein RAID einrichten. Aber sollte man wirklich ...?
Die Leute hören "ich hab RAID" und verstehen "ich hab eingebautes Backup" und in Wirklichkeit ist es weder das eine noch das andere ..
(Dieser Absatz war rhethorisch gemeint, und ging an den NAS-Hersteller.)
Wenn es ein "sinnvolles" RAID gewesen wäre, hättest mindestens noch eine weitere Platte; hast Du aber bestimmt nicht, sonst wäre es erwähnt worden, oder?
Und dass dort "Microsoft Basisdaten" so oft auftraucht, deutet im schlimmsten Fall darauf hin, dass Windows vielleicht versucht hat, Dir einen dynamischen Datenträger daraus zu machen?
Eventuell schon beim ersten Versuch ...
Lange Rede, kurzer Sinn: die Platte ist vielleicht hinüber, vielleicht auch noch gut. Um die Daten darauf ist es sicher weniger gut bestellt!
Gruß, FM_81
Das (von einem Beitrag ganz am Anfang) sieht für mich so aus, als ob zu viel Strom gezogen wurde, und der USB dicht gemcht hat:
|
|
Quellcode |
1 |
[ 203.519642] sd 9:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] |
Platte intern anschliessen, SMART-Werte auslesen.
Dann wissen, ob Platte physisch im Eimer oder nur Dateisysteme geschreddert.
Letzteres kann schon beim allerersten Versuch passiert sein!?
Muss noch nicht mal an Windows liegen, falls der Controller wegen Überstrom dicht gemacht hat, während Du kopiertest.
Ob es ein EXT4 Dateisystem war, können wir nur raten, genau so kann es XFS oder sonst was gewesen sein.
Dass dort zwei RAID-Partitionen gleicher Grösse zu sehen sind, ist zugegeben etwas seltsam?
Ja, man könnte auch so ein RAID einrichten. Aber sollte man wirklich ...?
Die Leute hören "ich hab RAID" und verstehen "ich hab eingebautes Backup" und in Wirklichkeit ist es weder das eine noch das andere ..
(Dieser Absatz war rhethorisch gemeint, und ging an den NAS-Hersteller.)
Wenn es ein "sinnvolles" RAID gewesen wäre, hättest mindestens noch eine weitere Platte; hast Du aber bestimmt nicht, sonst wäre es erwähnt worden, oder?
Und dass dort "Microsoft Basisdaten" so oft auftraucht, deutet im schlimmsten Fall darauf hin, dass Windows vielleicht versucht hat, Dir einen dynamischen Datenträger daraus zu machen?
Eventuell schon beim ersten Versuch ...
Lange Rede, kurzer Sinn: die Platte ist vielleicht hinüber, vielleicht auch noch gut. Um die Daten darauf ist es sicher weniger gut bestellt!
Gruß, FM_81
ACHTUNG!
Ihre Systemleistung reicht nicht aus, um einen BLUE-SCREEN zu erzeugen!
Möchten Sie statt dessen einen GREEN-SCREEN sehen?
---- [Ja] ---- [Nein] ---- [Weiß noch nicht] ----
Ihre Systemleistung reicht nicht aus, um einen BLUE-SCREEN zu erzeugen!
Möchten Sie statt dessen einen GREEN-SCREEN sehen?
---- [Ja] ---- [Nein] ---- [Weiß noch nicht] ----
Ähnliche Themen
-
Konfigurations- und Datensicherung »-
Mini Live Cd Erstellen
(26.08.2015, 12:27)
-
- Retter in der Not »
-
DVR CP CAM Festplattenformat????
(20.08.2009, 11:06)
-
- Hardware »
-
daten wiederherstellen unter knoppix
(11.02.2008, 20:43)
-
- Anwendungssoftware »
-
wie finde ich meine Daten unter Brennprogramm
(24.04.2008, 22:29)
-
- Retter in der Not »
-
Festplatte direkt ansprechen (byte f?r byte)
(22.04.2006, 18:08)