17.11.2017, 20:37 UTC+1

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

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!

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. 

klaus2008

Meister

Beiträge: 2 655

Geschlecht: Männlich

2

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

Quellcode

1
sudo sgdisk -p /dev/sdd 
und

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

3

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:

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

Zitat

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ß!
»kimito« hat folgende Datei angehängt:

4

13.08.2017, 11:56

Knoppix 7.7.1
Sicherungs-Speicher: die im notebook vorhandene HD (NTFS-format). /dev/sda?

klaus2008

Meister

Beiträge: 2 655

Geschlecht: Männlich

5

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.

Quellcode

1
dmesg | tail -n 30
Man erhält die letzten 30 Zeilen der Kernel-Nachrichten.

Gruß
Klaus

6

13.08.2017, 13:15

ok, skripts eingeschaltet..

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 ! ! !

klaus2008

Meister

Beiträge: 2 655

Geschlecht: Männlich

7

13.08.2017, 13:28

Zitat

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

8

13.08.2017, 16:25

Hallo Klaus,
Wie sichere / kopiere ich denn die Daten, wenn ich keinen Zugriff darauf habe?

Wenn geschehen, wie gehe ich weiter vor?
Testdisk/photorec: geht's hier ans Eingemachte? ( und was muss ich da machen?)

Viele grüße!

ubuntuli

Fortgeschrittener

Beiträge: 385

Geschlecht: Männlich

9

13.08.2017, 21:40

Hallo kimito.
Kannst Du bitte folgende Befehle im Terminal eingeben.

Quellcode

1
2
3
sudo su
cd /media
ls -l



und das Foto hier hochladen um zu sehen welche Festplatten erkannt werden und wer welche Zugriffrechte hat.

10

13.08.2017, 21:51

Aaalso,
testdisk gestartet. Bis hierher.
jetzt warte ich....und werde berichten.

Vielen lieben Dank für die Hilfe bisher!
Gruß und gute Nacht!
»kimito« hat folgende Dateien angehängt:

11

13.08.2017, 21:55

Hallo ubuntuli,
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#

12

14.08.2017, 20:41

Hallo,
habe gestern testdisk gestartet und über Nacht laufen lassen.
Leider hat sich an dem Fenster, welches 2 post's drüber ist, nichts geändert.
Hab' somit abgebrochen.
Was nu'?
Nochmals laufen lassen mit anderen Einstellungen?
photorec laufen lassen?

Wer hat Rat?

Gruß!

ubuntuli

Fortgeschrittener

Beiträge: 385

Geschlecht: Männlich

13

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.

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)


14

15.08.2017, 12:12

viele Köche verderben oft den Brei, deshalb will ich mich nicht großartig einmischen und nochmal etwas vollkommen unterschiedliches erzählen.

Wenn du ein Neuling im Land der Freien bist (was allerdings gar nicht so aussieht), kennst du vielleicht noch nicht die (zumeist) eingebauten man-pages. man man sagt mehr dazu und mit man testdisk erhältst du eine gute Beschreibung, was mit dem Befehl gemacht werden kann. Es wird sich mit photorec wohl ähnlich verhalten.
Sieh dir diese Information unbedingt zuerst und gewissenhaft an.
Es gibt dann auch Informationen im Netz, wo du Beispiele vorgeführt bekommst und somit ebenfalls eine Orientierungshilfe erhältst.
Wichtig ist, dass du dir über die Art der Festplatte möglichst gut im klaren bist und auch darüber, wo denn nun die Daten liegen, die du brauchst.
So wird da zB einmal von einem raid gesprochen und du erwähnst, dass die Platte in einem NAS gewesen ist. Solche Geräte haben ganz oft mehrere Platten zu einem RAID verbunden und die wichtigen Daten liegen dann natürlich hier. Schlecht allerdings, dass man diese Daten dann sehr oft gar nicht in anderen Rechnern auslesen kann (bei HW-Raid). Dies gilt auch und vor allem für Partitionen, die eine Verschlüsselung benutzen. Sollten solche Fälle bei dir zutreffen, kannst du vermutlich gleich mit allen Bemühungen stoppen.
Vollkommen uninteressant wären zB Partitionen, auf denen nur das Betriebssystem liegt.

Du fragst gut und richtig, wie denn die Platte kopiert werden kann, wenn du sie nicht einbinden kannst.
Eingebunden werden nur (fehlerfreie) Dateisysteme. Dateisysteme liegen aber auch als Bits und Bytes auf der Platte und auf der Ebene können die komplett (also auch mit allen Fehlern) kopiert werden. Solch eine Kopie (manche sagen Klon (Clone) dazu), kann von der Platte komplett oder von einzelnen Partitionen angefertigt werden, es muss dabei immer ausreichend Platz im Ziel vorhanden sein und es ist die allererste Maßnahme, die man überhaupt durchführt, wenn es ans retten von Daten geht. Man macht gleich zwei solche Klone. Einmal nur lässt man die Platte dabei laufen und dann hängt man die weg, denn jeder Zugriff auf die Platte kann den zustand der Daten verschlimmern, wenn diese tatsächlich defekt ist und zusehends stirbt. Alle Rettungsarbeiten macht man dann an einem Klon und behält einen zweiten in der Hinterhand, denn auch Rettungsaktionen können Daten schrotten. Ein gängiges Mittel zum Anlegen solcher Klone ist der Befehl dd und der ist unbedingt mit Vorsicht zu genießen. dd if=/dev/sdd4 of=/part-4.img erzeugt zB am Platz /part-4.img einen Klon der vierten Partition. Ohne weitere Zugaben zum Befehl schreibt dd so Bitweise und das dauert lange, ist aber nicht das Verkehrteste. Gewöhnlich nutzt man einen Zusatz, wie bs=1M um in größeren Blöcken zu schreiben. Siehe die man-page. Es gibt da auch den offenbar effektiven Befehl ddrescue, den ich selbst nie genutzt habe.
Weitere Tools zur Festplattenforensik bietet der sleuthkit (kann bei Knoppix nachinstalliert werden).

Bei diesen Befehlen muss man in der Regel SuperUser sein. Das kann ein vorgestellter sudo erledigen, den ich selbst aber gar nicht mag, oder ein einfaches su ohne Passwort (in KNOPPIX). Als SuperUSer hat man große Macht und kann die auch missbrauchen!

EDIT: was ich vorhin vergessen hatte: es spricht bei der Draufsicht sehr viel dafür, dass deine Daten in der vierten Partition der Platte liegen, die als sdd erkannt wurde.Diese Partition ist sehr groß, sie ist weitaus größer, als die von dir als Rettungs-Disk angedachte Platte in deinem PC. Ein dd -image nimmt wirklich allen Platz ein, es überträgt auch alle "Nullen" deiner Platte oder Partition. das bedeutet, dass du einen ebenfalls sehr großen Rettungs-Speicher brauchst und viieel Zeit. Es ist mir nicht klar, welches Dateisystem dort verwendet wird. Man liest zwar immer irgendwas von Microsoft, aber sicher scheint mir das keineswegs und testdisk kam nicht so einfach darauf. Angenommen, es wäre NTFS, dann kann auch Microsoft versuchen, den Defekt zu reparieren. Es kennt dazu chkdsk (afaik). Das könnte einen Fehler im Dateisystem reparieren, aber nicht deine defekte Platte heilen.
Du hattest die Platte in einem Windows und da besteht auch die nicht ganz geringe Möglichkeit, dass dir dabei deine tatsächlichen Dateisysteme zerschossen wurden. ich habe das neulich erst gelernt, dass Windows sehr eigen ist, was Dateisysteme auf externen Datenträgern angeht.
Es ist für einen NAS eine sehr seltsame Aufteilung der Platte, die mich durchaus nachdenklich macht. Aber ich kenne auch das Produkt nicht.
file -s /dev/sdd4 könnte auch etwas mehr Angaben zum Dateisystem zeigen, aber ich weiß nicht, wie vertrauenswürdig das alles nun so ist und ob da noch was zu retten ist.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »pit234a« (15.08.2017, 18:28)


15

19.08.2017, 14:44

Hallo zusammen, hallo pit234a,
vielen Dank für die bisherige Hilfe und die letzten ausführlichen Erläuterungen.
Gehe ich recht in der Annahme, daß ich fur das Anlegen des clones ebensoviel Speicherplatz brauche wie das Original? Sprich 4TB?

Falls ja, was haltet Ihr von folgenden Gedanken:
- Die Daten habe ich anfangs irgendwie doch von der Festplatte unter windows kopieren können. Teilweise aber nicht vollständig. Dies geht nun ja nicht mehr.
- Wenn ich unter Windows wäre, würde ich -als letzten Versuch- die HD neu partitionieren / formatieren (und damit wieder überhaupt Zugriff bekommen)
- und dann ein Recovery-Programm drüberlaufen lassen, um die Daten wieder soweit wie möglich zu erhalten.
- Somit hätte ich sogar unter Windows Zugriff auf die Daten.
- Falls nicht unter Windows -aber doch vielleicht unter "normalem" Linus-Zugriff.

Oder doch noch eine LINUX-Lösung?
Übrigens, ich glaube die Patition ist im ext4-Format

Photorec habe ich übrigens über alle Partitionen laufen lassen, ging auch soweit bis zu sdd4. Hier habe ich die Nachricht von zuwenig SPeicherplatz erhalten.
Bei den Anderen Partitionen habe ich zwar keine Fehlermeldung erhalten aber Zugriff ahbe ich nun auch nicht mehr als vorher..

Viele Grüße!

16

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.

17

19.08.2017, 17:59

Quellcode

1
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


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
sorgt dafür, dass man Einträge sieht, die mit sd-Geräten zu tun haben. Wir wollen herausfinden, wie die externe Platte demnächst erkannt wird. Die Geräte werden durch gezählt. Du siehst da nun vielleicht sda, sdb1 und sdb2 oder so etwas. Versuch es dir ein wenig zu merken. Dann die neue Platte stecken und erkennen lassen, gleichen Befehl wiederholen (Pfeil nach oben) und erkennen, als was die neue Platte erkannt wird.
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
und hier mit p die Partitionen anzeigen lassen. Oder

Quellcode

1
# gparted /dev/sdd &
und hier alles grafisch betrachten. Oder

Quellcode

1
# apt-get install sleuthkit
um ein anderes Set an forensischen Tools zu installieren, wobei man Verbindung zum Internet braucht und dann

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
das sollte mehr zum Dateisystem sagen.

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.

18

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:


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!!!
»kimito« hat folgende Datei angehängt:

19

20.08.2017, 19:10

Anbei das Gparted-Phto nach mehrfachen Abbrechen
»kimito« hat folgende Datei angehängt:

20

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:

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.

21

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.

22

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):

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:
»kimito« hat folgende Dateien angehängt:

23

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.

24

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"

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

25

20.08.2017, 21:18

Ah, kurz vorm Feierabend...

Ja, das ist ungefähr, was ich erwartet hatte: es geht da nichts mehr. Die Daten sind hin und weg.

Das Ziel wird nicht automatisch gesetzt. Wieso du keine Berechtigung hattest, ist etwas merkwürdig, weil Knoppix eigentlich immer alles so mountet, dass man als einfacher User Zugriff hat. Du hättest es als root probieren können, etwa mit einem mkdir /media/sde1/Ziel und später die Rechte dafür anpassen. Du hättest auch noch einige weitere Dinge testen und probieren können. Es ist wichtig, dass du als root ins Ziel schreiben kannst. Sonst versagt der Befehl eh.
Aber er versagt hier auch deshalb, weil er einfach keine Daten und kein Dateisystem erkennen kann. So, wie die anderen Tools auch.
Ich glaube, dass du das am Besten aufgibst, weil da echt nichts mehr zu holen ist.
photorec hätte ansonsten auch was finden können.
Man kann natürlich noch manuell mit sehr viel Aufwand versuchen, Daten zu finden und sie zusammen zu führen und zu Dateien zu vereinen. Das ist echt super viel Mühe und ich würde das nicht mehr probieren.
Man muss irgendwann erkennen, dass man kostenlos keine Chance mehr hat und das ist ein guter Zeitpunkt dafür.
Ich weiß nicht, wie ich das erklären soll. Alle Programmen arbeiten im Grunde mit ähnlichen Mechanismen und sie brauchen gewisse Ausgangsdaten, an denen sie sich orientieren können. Ansonsten ist es unglaublich schwer, aus einer Folge von Einsen und Nullen auf einen korrekten Datensatz zu schließen. Man kann so etwas machen, aber das ist echt komplex. Die Ausgangsdaten beschreiben in etwa die Schubladen, von denen ich schon mal gesprochen habe. Die sind nun einfach platt gemacht und damit greifen Automatismen nicht mehr. Man muss den Rahmen nun sehr aufwändig ermitteln und diese Ausgangsdaten manuell setzen, um da noch was herausholen zu können und selbst das kann unter Umständen nur noch Müll sein.

Wenn eine Platte so anfängt zu spinnen und kaputt zu gehen, ist immer der erste Schritt ein Image und dazu braucht man ein gleich großes Ziel.
Das bedeutet aber auch, dass man immer eine Datensicherung anlegen kann und nicht erst auf einen Defekt wartet. Das ist die Standard-Lösung!
Dann versucht man eine Reparatur des Dateisystems. Das geht natürlich nur, so lange es die benötigten Metadaten noch hat, also, so lange da nicht formatiert wurde. Dateisystemreparaturen sind sehr oft erfolgreich und danach können alle Daten bequem gesichert werden. Erst danach versucht man forensische Tools, wie eben den sleuthkit und wendet die aber immer noch auf das vorhandene (möglicherweise beschädigte) Dateisystem an. Das alles mach man nicht an der Platte, die am sterben ist, weil die zusätzlich ständig neue Fehler produzieren kann.
Wenn das nicht gelingt, also photorec und sleuthkit etc keinen direkten Erfolg haben, dann ist für uns arme Seelen in der Regel Schluss. Weil dann kostet es viel Zeit, Energie und Wissen und das ist Arbeit für echte Speziallisten.

Du kannst dir natürlich noch Dokumentationen und Beispiele im Netz suchen und sehen, ob dir noch was besseres einfällt.

Ich würde mir das System (auf /media/sdd2) nochmal ansehen und versuchen, da etwas zu retten. Natürlich in Abhängigkeit davon, was du überhaupt mit dem NAS vorhast.
Ansonsten Platte platt machen, neu formatieren, Dauerstress-Test und dann vermutlich wegwerfen.

Solche Probleme gehen einem ja häufig noch länger nicht aus dem Sinn und man will unbedingt noch dies und jenes versuchen und ich würde da auch noch einige Dinge testen und probieren. Ich habe das aber auch schon häufiger getan und manche Nacht damit verbracht, Daten wieder zu beschaffen. Als ich noch jünger war. Heute habe ich da keine große Lust mehr und neige viel eher zum Aufgeben. Heute habe ich aber auch immer Datensicherungen! Alleine schon, weil heute die Medien derart groß sind, dass eine manuelle Sichtung eine extreme Herausforderung darstellt.
Aus der Ferne ist es aber sehr schwierig, alles zu vermitteln, was dazu nötig wäre und ich glaube nicht, dass ich das bewerkstelligen kann.
Vielleicht haben noch andere Leute Ideen. Aber ich fürchte, wenn da nicht Daten dabei sind, die wirklich wertvoll sind, dass sich kein Aufwand mehr in vernünftigem Verhältnis zum zu erwartenden Ergebnis bewegt.
Ich will auch nicht Beispiele kreieren und hier posten, nur um zu zeigen, wie es "normalerweise" laufen könnte. Das ist auch die Mühe nicht Wert.
Du könntest das mit den Schreibrechten für root noch testen und du könntest noch ein -f ext4 oder was auch immer probieren, damit der Automatismus nicht so viel suchen muss. Aber das wird nichts bringen. Schätze ich.

26

20.08.2017, 21:34

Hallo pit234a,
vielen, vielen Dank nochmals für Deine Bemühungen und ausführlichen Erläuterungen.
Schade, daß es nicht geklappt hat!
Auch schätze ich es sehr, daß Du das sinnvolle Limit erkennst und mir mitteilst. Da höre ich gerne drauf, da auch ich den Aufwand gegen die Zeit aufrechne.

Noch eine letzte Frage (...oder einer der letzten...):
Denkst Du, daß die Festplatte hardwareseitig defekt ist? Hast Du deshalb den "Dauerstress-Test" genannt, um nach Partitionierung und Formatierung und vor erneutem NAS-Einbau die Hardware auf mittel- und langfristige Tauglichkeit zu überprüfen? Kann ich diesem Dauerstress-Test mit normalen Boardmitteln machen (Linux oder Windows)?

Schönen Abend!

27

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!

28

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:

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.

FM_81

Fortgeschrittener

29

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:

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] ----

30

22.08.2017, 12:13

ich will versuchen kurz zu bleiben.
Es ist fällt mir nie leicht, immer habe ich das gefühl, etwas wichtiges zu vergessen und nicht richtig verstanden zu werden und dann passieren mir längere Beiträge, die nicht zur Übersichtlichkeit des Problems beitragen.

Wie FM_81 sagt, gibt es einige Hinweise und das geschilderte Verhalten, die auf eine mangelhafte Spannungsversorgung der Platte während des Tests deuten. Das muss jedenfalls korrigiert werden.

Es gibt aber auch "klare" Aussagen zu dem momentanen Datenstand auf der Platte und da kann man sagen, dass etwas damit passiert ist, das die Lage nicht verbessert hat. Es wurde etwas an den Dateisystemen verändert, die im standard-Fall zuerst hätten gesichert werden müssen.
Ich bin da ziemlich drakonisch.
Auch dann, wenn photorec hier noch etwas finden sollte, ist es doch eine gute Gelegenheit, Lehrgeld zu bezahlen. Man geht so nicht mit Daten um, wenn man sie sicher behalten möchte. Das ist mir sogar wichtiger, als das mögliche Restaurieren.
Dem Threadstarter mag das nicht gefallen und seine Prioritäten liegen sicher im Augenblick anders. Aber, kimito, das soll nicht überheblich auf dich wirken. Ich glaube, dass ich deine Situation gut verstehen und nachfühlen kann. Der sichere Umgang mit Daten wird für jeden von uns immer wichtiger und man muss sich deshalb Gedanken machen und informieren. Man sollte zu einem Zustand kommen, wo Hilfsmittel zur Datenrettung vollkommen überflüssig sind, weil durchgängig die Existenz wichtiger Daten gewährleistet ist. Je nach Umfeld muss das sogar "Atombombensicher" sein, bei uns genügt es vielleicht, den Ausfall eines Mediums oder vielleicht noch einen Hausbrand mit Verlust aller lokalen Medien zu bedenken.
Datenrettung ist immer ein unsicheres, letztes Hilfsmittel in der Verzweiflung, ohne jegliche Gewähr.

Mit photorec habe ich nun mehrere Versuche gespielt und auch auf alten, mehrfach "überschriebenen" Medien noch zusammenhängende Daten gefunden. Meist sind das kleine Icons und eine Menge Müll.
Die Wahrscheinlichkeit, mit photorec noch irgendwas zu finden, ist also extrem hoch.
Gar nichts finden wird es (meiner Meinung nach) nur dann,
  • wenn ein sogenanntes "deep-format" erfolgte,
  • das Medium gezielt mit Nullen oder Unsinn beschrieben wurde,
  • das Medium unrettbar defekt ist (oder die momentane Spannungsversorgung das verursacht),
  • der Anwender grundlegende Fehler im Umgang mit photorec machte.

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