Sie sind nicht angemeldet.

[gelöst] Klonen einer Festplatte mit fehlerhaftem Block

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

1

04.03.2018, 07:59

Klonen einer Festplatte mit fehlerhaftem Block

Ein altes Problem ist wieder aufgelebt: Vor etwas mehr als einem Jahr hatte ich bereits Schwierigkeiten mit eine 4TB-Platte, wofür der smartd immer Fehler meldet und die sich sporadisch "dienstunfähig" meldete: http://www.ubuntu-forum.de/artikel/66882…ter-fehler.html. Später verschwand der Fehler still und leise und sie lief 1 Jahr fehlerfrei. Im Februar ist sie wieder kritisch geworden und diesmal war es ernst: SMART hat einen defekten Block erkannt und konnte diesen auch mit seiner Nummer benennen.

Also war sofortiges Handeln angesagt und ich holte eine andere 4TB-Platte aus einem RAID-1 heraus, weil ich sonst nichts hatte. Vorher machte ich noch eine letzte Sicherung des wichtigsten Partition mit back-in-time auf eine externe Platte; die Sicherung meldete keine Fehler. Die einfache Überlegung dabei war:
  1. keinen Stress mit kryptischer Software;
  2. alles so einfach halten, daß Bedienungsfehler ausgeschlossen sind;
  3. möglichst keine Fallunterscheidung von Sonderfällen und Ausnahmen.

Folglich starte ich ein Clonezilla Live-System, die schadhafte Platte blieb wo sie war, die Ersatzplatte kam über einen USB-Adapter (leider nur V2 und nicht das schnellere V3) ins System. Nach dem Motto "alles so einfach wie möglich" befahl ich, die gesamte Platte zu klonen. Die erste Ernüchterung kam ziemlich schnell, denn die Ersatzplatte war ein paar Bytes kleiner als die zu rettende und es wurde gewarnt, daß der Klon schadhaft werden könne. Ich ließ den Vorgang trotzdem laufen; es dauerte zwischen 7 und 8 Stunden, was ich noch erträglich fand und es wurden Fortschrittsbalken und Zeitschätzungen angezeigt, was ich alles plausibel fand. Der Ablauf beendet sich ohne Fehlermeldung.

Anschließend schaute ich mir das Ergebnis mit gparted und auch mit gdisk an:
alle 3 Partitionen waren bis aufs Byte genau mit den Größen des Originals repliziert worden, hatten aber keinen erkennbaren Inhalt, denn es waren keine Dateisystem drauf (ext4, swap und btrfs hätten drauf sein müssen). Aber ich war ja gewarnt worden! Also nächster Versuch: GpartEd bot die Option der Datenrettung an, verlangte aber, daß ich das Programm gpart nachinstallieren müsse, was ich tat. Nach mehr als 12 Stunden war immer noch nicht zu erkennen, ob sich etwas tut, weswegen ich den Vorgang abbrach. Danach formatierte ich die auf der Rettungsplatte schon vorhandenen Partitionen mit dem Wunschdateisystemen neu, was natürlich die UUIDs verändern würde, aber das war mir jetzt auch schon egal. Zunächst erwog ich, die Daten schlicht und einfach mit dem altbewährten tar zu übertragen, aber weil ich schon an die 10 Jahre nicht mehr ernsthaft damit gearbeitet hatte und eine Menge andere Dinge um die Ohren hatte, konnte ich mich nicht auf das Wiedererlenen der vielen kryptischen Parameter und Optionen einlassen.

Also bekam Clonezilla eine zweite Chance und sollte diesmal nur eine einzige Partition klonen. Diese war die /home-Partion eines Xubuntu-Systems und rund 1 TB groß; die Aufgabe schien also überschaubar (es hätte keinesfalls mehr als 8 Stunden dauern dürfen). Sonderfälle wie Bootdinger (Grub etc.) gab es nicht es nicht -- es war nur eine GPT mit "protective MBR" auf der Platte. Zu meiner großen Überraschung fing Clonezilla an, Unmengen von Prüfsummen für alle Partitionen zu berechnen. Ich mußte dann weg und als ich nach 5 Stunden wieder kam war es mit den Prüfsummen bei 96% angelangt. Als es fertig war hatte es fast eine Million Dateien auf der 1TB großen /home-Partition gefunden und mehr als 6 Millionen Dateien auf einer 3TB großen Sicherungspartition, die von verschiedenen Betriebssystemen benutzt worden war. Danach fing es endlich mit dem Klonen an und das schaute auch ganz vertrauenserweckend aus: es zeigt wieder einen Fortschrittsbalken und gab auch eine Zeitschätzung ab. Als die Vorhersage nach einer Stunde auf mehr als 80 Stunden(!) mit ständig steigender Tendenz angestiegen war, brach ich ab. Es konnte ja nicht sein, daß 4 TB mit 8 Stunden ausgekommen waren, eine Einzelpartition mit 1 TB aber mehr als das 10fache dauern sollte.

Also doch tar? Vorher stieß ich beim Recherchieren aber auf ddrescue und dessen Beschreibung gefiel mir. Also wieder alles in Stellung gebracht: ein System gestartet, welches keine der beiden Platten irgendwie einhängte und so losgelegt:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11

[----@i5Tuxedo ~]$ sudo ddrescue --force -n /dev/sdb1 /dev/sdc1 ddrescue-20180303a.log
[sudo] Passwort für ----: 
GNU ddrescue 1.23
Press Ctrl-C to interrupt
     ipos:    9502 MB, non-trimmed:        0 B,  current rate:    132 MB/s
     opos:    9502 MB, non-scraped:        0 B,  average rate:  45035 kB/s
non-tried:  919371 MB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    9502 MB,   bad areas:        0,        run time:      3m 31s
pct rescued:    1.02%, read errors:        0,  remaining time:      2h 17m
                              time since last successful read:          0s
Copying non-tried blocks... Pass 1 (forwards)

Schaut doch gut aus!
Als mißtrauischer Mensch legte ich mir aber von einem anderen Terminalfenster auf die Lauer:

Quellcode

 
1
2

[---@i5Tuxedo ~]$ ls -al | grep *.log
-rw-r--r--  1 root     root       412  3. Mär 19:22 ddrescue-20180303a.log

und

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12

[----@i5Tuxedo ~]$ ps a
  PID TTY      STAT   TIME COMMAND
  538 tty1     Ssl+   3:08 /usr/lib/xorg-server/Xorg -nolisten tcp -auth /var/run/sddm/{040
  872 pts/1    Ss+    0:00 /bin/bash
 1463 pts/4    Ss     0:00 /bin/bash
 1632 pts/5    Ss     0:00 /bin/bash
 1637 pts/5    S+     0:00 sudo ddrescue --force -n /dev/sdb1 /dev/sdc1 ddrescue-20180303a.
 1642 pts/5    D+     0:10 ddrescue --force -n /dev/sdb1 /dev/sdc1 ddrescue-20180303a.log
 1647 pts/4    S+     1:54 top
 1726 pts/6    Ss     0:00 /bin/bash
 1897 pts/7    Ss+    0:00 /bin/bash
 2660 pts/6    R+     0:00 ps a

Schon nach kurzer Zeit stieß mir sauer auf, daß die Diode für die Quellplatte Dauerlicht (nicht das allergeringste Flackern!) zeigt, während am Adapter ("Docking Station") für die Zielplatte keinerlei Tätigkeit zu beobachten war. Trotzdem ließ ich das Ding die ganze Nacht laufen und heute morgen war alles unverändert: die Lampen leuchten bzw. leuchten nicht, die CPU-Zeit für ddrescue verharrt bei 10 Sekunden.

Weil ich mit Logdatei gestartet hatte bestand die Möglichkeit mit Strg-C zu unterbrechen. Der nächste Hammer:

Quellcode

 
1
2
3
4
5
6
7
8
9
10

Press Ctrl-C to interrupt
     ipos:    9502 MB, non-trimmed:        0 B,  current rate:    132 MB/s
     opos:    9502 MB, non-scraped:        0 B,  average rate:  45035 kB/s
non-tried:  919371 MB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    9502 MB,   bad areas:        0,        run time:      3m 31s
pct rescued:    1.02%, read errors:        0,  remaining time:      2h 17m
                              time since last successful read:          0s
Copying non-tried blocks... Pass 1 (forwards)
^C
^C^C^C^C^C^C^C^

Nichts tat sich; Strg-C wird eiskalt ignoriert. Bleibt also wieder nur abbrechen? Oder abwarten und beten? Das glaube ich nicht!
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »ebbi97a« (09.03.2018, 08:47)

alt-medregnet

User

  • »alt-medregnet« ist männlich

Beiträge: 576

Registrierungsdatum: 22.01.2015

Derivat: Ubuntu GNOME

Architektur: 32-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: Siduction (Debian 64 Bit), Ubuntu XFCE (64 Bit), Windows 10

  • Nachricht senden

2

04.03.2018, 15:48

Hast du es bei Clonezilla im Expertenmodus mit der Option -rescue versucht (überspringt was es nicht lesen kann)?
https://download.uib.de/opsi_stable/doc/…parameters1.png

Gruss Uli

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

3

04.03.2018, 19:56

Zitat von »alt-medregnet«

Hast du es bei Clonezilla im Expertenmodus mit der Option -rescue versucht (überspringt was es nicht lesen kann)?

Nein, ich glaube nicht. Aber mit ddrescue habe ich es explizit versucht.

Noch ein paar Zusatzinfos:
Mit 2 Parallelsystemen, die nicht im Produktiveinsatz sind und von der kritischen Platte keine Partition automatisch einhängen, habe ich die beiden Platten untersucht:
  1. Linux Mint und gparted;
  2. Manjaro mit KDE-Partitionsverwaltung.

Beide zeigen an, daß auf die geklonte Platte in die /home-Partition Daten gelangt sind. Der belegt Bereich ist auf der kopierten Partition genauso groß wie auf der originalen.
Wenn ich diese in Linux Mint einhänge und den Inhalt auflisten will, bekomme ich die Meldung

Quellcode

 
1

Leider konnte der gesamte Inhalt von »948157c2-855b-47b4-b084-5eca13d5861e1« nicht angezeigt werden: Fehler beim Holen der Informationen für Datei »/media/----/948157c2-855b-47b4-b084-5eca13d5861e1/----«: Die Struktur muss bereinigt werden

Manjaro/KDE meldet dagegen:

Quellcode

 
1

Beim Zugriff auf „Persönlicher Ordner“ ist ein Fehler aufgetreten, die Meldung lautet: Das Gerät ist bereits eingebunden: Device /dev/sdg1 is already mounted at `/run/media/----/948157c2-855b-47b4-b084-5eca13d5861e'.

Das mag damit zu tun haben, daß beim einem der Klonversuche mit der Einzelpartition tatsächlich etwas gelungen ist und die beiden UUID identisch sind, was natürlich streng verboten ist:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[----@i5Tuxedo ~]$ blkid
/dev/sda1: UUID="13c0bf09-6d17-462a-9383-8505ebd5c935" TYPE="swap" PARTLABEL="Linux swap" PARTUUID="061de765-ba20-4880-a2a5-e6480391afe2"
/dev/sda2: LABEL="EF00" UUID="FF79-8166" TYPE="vfat" PARTLABEL="EFI System" PARTUUID="80e8e41d-127b-4f5d-8e88-63d12e76470f"
/dev/sda5: LABEL="Xubuntu" UUID="57fad0b2-4ce5-4cae-82c3-d3794f3c2887" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="dde99e29-34c7-4213-86fd-361a8b246738"
/dev/sda8: LABEL="Manjaro" UUID="cf74d943-21a2-42ad-8d72-66335c755f74" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="bc68fc1b-f70c-4945-94f1-489f743d6b61"
/dev/sda3: LABEL="Antergos" UUID="b64c9970-64bc-40f7-98a9-64eb8d426b54" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="8b15eacb-f3f3-4439-bae1-d30328cbcacd"
/dev/sda6: LABEL="(/var)" UUID="29463195-f864-40d1-a2e9-5ef11815dce3" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="30392cb9-1745-41ad-90c8-854048c1b8c4"
/dev/sda7: LABEL="Mint" UUID="fc669513-df7e-42df-9df1-7cf9374d439d" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="e8b5ab4b-1cd3-429e-9baf-4a247e810bdd"
/dev/sda4: LABEL="Gecko" UUID="27be2b7a-90ee-41e0-881a-f8ed63b1ecee" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="5a1605f0-bba9-4c75-a3b8-a5b442ccbe3f"
/dev/sdb1: UUID="948157c2-855b-47b4-b084-5eca13d5861e" TYPE="ext4" PARTLABEL="HOME" PARTUUID="7228d8ae-baaa-4b54-91c0-8ce50bfa0e5c"
/dev/sdb2: UUID="45a93cd8-0b4d-4bc1-a90b-42deb9870f52" TYPE="swap" PARTUUID="1098fb85-b98b-45e7-9971-62c395146239"
/dev/sdb3: UUID="e29062e9-3de1-4d73-a8e7-1ff82f96b5f9" UUID_SUB="4afcdbd2-8920-482b-9ba4-f10955b54701" TYPE="btrfs" PARTLABEL="SICHERUNG" PARTUUID="d8170afc-1ea2-48de-a13a-7fdd7b5ff583"
/dev/sdg1: UUID="948157c2-855b-47b4-b084-5eca13d5861e" TYPE="ext4" PARTLABEL="HOME" PARTUUID="7228d8ae-baaa-4b54-91c0-8ce50bfa0e5c"
/dev/sdg2: LABEL="SWAP2" UUID="186df0ce-9b27-4bd2-9070-4d6bc1f62420" TYPE="swap" PARTUUID="1098fb85-b98b-45e7-9971-62c395146239"
/dev/sdg3: LABEL="SICHERUNG" UUID="d89050a7-ca09-4f6b-b4ac-1176b776a074" UUID_SUB="41618079-f2cf-4365-91f9-de0d455aee5a" TYPE="btrfs" PARTLABEL="SICHERUNG" PARTUUID="d8170afc-1ea2-48de-a13a-7fdd7b5ff583"

Das Wichtige nochmals übersichtlich zusammenkopiert:

Quellcode

 
1
2

/dev/sdb1: UUID="948157c2-855b-47b4-b084-5eca13d5861e" TYPE="ext4" PARTLABEL="HOME" PARTUUID="7228d8ae-baaa-4b54-91c0-8ce50bfa0e5c"
/dev/sdg1: UUID="948157c2-855b-47b4-b084-5eca13d5861e" TYPE="ext4" PARTLABEL="HOME" PARTUUID="7228d8ae-baaa-4b54-91c0-8ce50bfa0e5c"

Kann man daraus sinnvolle Erkenntnisse gewinnen?
Gerne würde ich die Daten in der geklonten Partition anschauen, weiß aber nicht wie. Ob es etwas hilft, wenn ich die Docking-Station mit dieses Platte an einem anderen Rechner anschließe, wo keine doppelten UUID auftreten?
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »ebbi97a« (04.03.2018, 20:11)

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

4

05.03.2018, 06:57

Zitat von »ebbi97a«

Ob es etwas hilft, wenn ich die Docking-Station mit dieses Platte an einem anderen Rechner anschließe, wo keine doppelten UUID auftreten?

Das habe ich gerade gemacht und die Fehlermeldung für die geklonte Partition (/dev/sdX1 (ext4) -- das "X" ist veriabel) beim Einhängeversuch ist identisch mit der, die auf dem Hauptsystem von Linux Mint / XFCE Cinnamon abgesondert wurde.

Das überrascht mich, weil dieses Testsytem auf dem anderen Rechner eben ein Manjaro / XFCE ist und ich hätte erwartet, daß eine Meldung wie vom anderen Manjaro / KDE kommt -- aber nein. Jedenfalls scheint es nichts mit der doppelten UUID zu tun zu haben.

Die weiter vorhandene zusätzliche Partition /dev/sdX3 macht übrigens nirgends Ärger: sie läßt sich überall ohne Gemecker einhängen und ist leer, hat aber ein Dateisystem (BtrFS). Anscheinend ist sie von meinen Klonversuchen unbeleckt geblieben. Die UUID sind übrigens verschieden, was aber auf dem Testsystem der anderen Hardware nicht bemerkt werden kann, weil der Vergleichsplatte dort nicht bekannt ist.

Erkenntnis ??
Sollte ich mich mal mit einem "File System Check" dran wagen? Habe irgendwo gelesen, daß das helfen könnte.

Ich komme mir vor, wie in einer Gummizelle: darf mich abstrampel und herumhampeln ohne was zu bewirken, verletze mich aber auch nicht. :wacko:
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »ebbi97a« (05.03.2018, 07:11)

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

5

05.03.2018, 10:45

Soll ich besser nochmal von vorn anfangen?

Irgendwie kommt mir die Lage so vor, als hätte ich irgendwo einen Fehler gemacht und den systematisch übersehen. Es kann einfach nicht sein, daß das Klonen einer Festplatte so schwierig ist, daß man ständig vor Rätseln steht. Gerade habe ich nochmals mit wieder einem System von etwas anderer Machart als die Debian-/Ubuntu-/Arch-ähnlichen einen Analyse gewagt. Es handelt sich um Void-Linux auf einer einfachen Hardware (2Kern mit 64bit-Architektur), aus dem weder die Originalplatte noch der mißlungene Klon stammen. Auch war dort zur Analyse nur der Klon eingehängt, so daß keine Verwechslung möglich ist. Zusätzlich enthält der Klon auch keinerlei startfähiges Betriebssystem: er ist mit GPT partitioniert und hat 3 Partitionen: eine Swap, eine ext4 und eine BtrFS mit sehr vielen Dateien.

Zitat von »ebbi97a«

Sollte ich mich mal mit einem "File System Check" dran wagen? Habe irgendwo gelesen, daß das helfen könnte.

Das habe ich noch nicht gemacht und halte es auch nicht mehr für sinnvoll. Damit nicht jeder, der hier herschaut, die ganze langatmige Schilderung der bisherigen Experimente erleiden muß, schildere in Kürze nochmal das Wesentliche:

  • Da ist eine 4TB-Festplatte, die den Weg aller Festplatten geht - sie wird siech (SMART hat Lesefehler gefunden und der ist reproduzierbar).
  • Ich versuchte sie auf verschiedenen Wegen zu klonen, aber das ging mehrfach schief.
  • Die letzten Versuche beschränkten sich darauf, nur die kritischste und wichtigste Partition zu klonen (es handelt sich um /home aus meinem Produktivsystem).
  • Diese Partition enthält irgendwelche Daten, wie verschiedene Partitionierungsprogramme übereinstimmend melden, aber ich kann sie nicht einsehen, um den Inhalt zu kontrollieren.
  • Die belegten Daten werden sogar mit genau der richtigen Menge (Größe) angegeben.

Um die Überprüfung nicht durch irgendwelche übersehenen Abhängigkeiten im Ursprungssystem zu verfälschen, habe ich den Klon in einen USB-Adapter gesteckt und auf völlig fremder Hardware, die nichts mit den Daten und auch nichts mit einer der beiden Platten zu tun hatte, angeschlossen und versucht, Einblick zu gewinnen. Der letzte Versuch erfolge mit Void Linux und einem dort installierten gparted und zu Fuß und mit mc (Midnight Commander). Statt schwer überschaubarer Textkopien zeige ich 4 Bildschirmabzüge:


Hier sieht man die 3 Partitionen, wobei hier nur sdb1 wichtig ist; das ist die fremde Platte mit der einen geklonte Partition, wo meine Versuche Spuren hinterlassen haben. 2 davon sind automatisch eingehängt worden; warum weiß ich nicht, aber es sollte auch nicht stören.


Hier sieht man, daß die Partition Daten enthält (Zusatzinformation: deren Größe stimmt genau mit dem Original überein, das jetzt nicht angeschlossen ist).


Hier steht, was das Betriebssystem (void linux) auf dem Analyserechner sieht.


Hier sieht man, daß die automatisch eingehängte Partition etwas enthält, dessen Struktur nicht in Ordnung ist.


Was soll ich tun?
  1. Die GPT (offensichtlich in Ordnung) lassen und mit tar einfach umkopieren?
  2. Mit clonezilla und genau einer Partition erneut versuchen mit äußerst gewissenhafter Kontrolle aller Optionen?
  3. Mit ddrescue und einer Partition erneut probieren? Zunächst nur die fehlerfreien Blöcke lesen und - falls erforderlich - in einem zweiten Durchgang auch die anderen?
  4. Versuchen, die Struktur auf dem Klon zu reparieren?
_______________________________
Welches System hätten's denn gern?

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

6

05.03.2018, 11:45

Nachtrag:

Zitat von »ebbi97a«

Was soll ich tun?

4. Versuchen, die Struktur auf dem Klon zu reparieren?

Es war nicht viel Arbeit, also hab' ich's gemacht:

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

[----@MSI ~]$ sudo fsck.ext4 -n /dev/sdb1
e2fsck 1.43.9 (8-Feb-2018)                                                                                                    
/dev/sdb1 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen.                                                            
Durchgang 1: Inodes, Blöcke und Größen werden geprüft                                                                         
Inode 29900801 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.               
Bereinigen? nein                                                                                                              
                                                                                                                              
Inode 29900801 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein                                                    
                                                                                                                              
Inode 29900801 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein                                                          
                                                                                                                              
Inode 29900801 hat eine ungültige Extragröße (27943)                                                                          
Reparieren? nein                                                                                                              
                                                                                                                              
Inode 29900801, i_size ist 4036684733741902704, sollte 0 sein.  Reparieren? nein
Inode 29900801, i_Blocks ist 126818442916212, sollte 0 sein.  Reparieren? nein
Inodes wurden gefunden, die Teil einer defekten verketteten Liste von
verwaisten Inodes waren.  Reparieren? nein
Inode 29900802 war Teil der Liste verwaister Inodes.  IGNORIERT.
Inode 29900802 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900802 hat eine ungültige Extragröße (45577)
Reparieren? nein
Inode 29900803 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900803 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900803 hat eine ungültige Extragröße (12247)
Reparieren? nein
Inode 29900803, i_size ist 3555969743913219760, sollte 0 sein.  Reparieren? nein
Inode 29900803, i_Blocks ist 137197590660192, sollte 0 sein.  Reparieren? nein
Inode 29900804 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900804 hat eine ungültige Extragröße (46857)
Reparieren? nein
Inode 29900805 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900805 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900805 hat eine ungültige Extragröße (14873)
Reparieren? nein
Inode 29900805 hat den INDEX_FL-Bitschalter gesetzt, ist aber kein Verzeichnis.
Der HTree-Index wird bereinigt? nein
HTREE-Verzeichnis-Inode 29900805 hat einen unvollständigen Wurzelknoten („root node“).
Der HTree-Index wird bereinigt? nein
Inode 29900805, i_size ist 15654065854364605959, sollte 0 sein.  Reparieren? nein
Inode 29900805, i_Blocks ist 118697037759838, sollte 0 sein.  Reparieren? nein
Inode 29900806 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900806 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900806 hat eine ungültige Extragröße (25579)
Reparieren? nein
Inode 29900806, i_size ist 202768894361468315, sollte 0 sein.  Reparieren? nein
Inode 29900806, i_Blocks ist 119550359919568, sollte 0 sein.  Reparieren? nein
Inode 29900807 scheint Inlinedaten zu besitzen, aber der Erweiterungs-Bitschalter ist gesetzt.
Reparieren? nein
Die Bitschalter von Inode 29900807 für Inlinedaten und Erweiterungen sind gesetzt aber i_block enthält Müll.
Inode bereinigen? nein
Inode 29900807 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900807 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900807 hat eine ungültige Extragröße (57711)
Reparieren? nein
Inode 29900807 hat einen defekten Erweiterungs-Vorspann.  Inode bereinigen? nein
Inode 29900807, i_Blocks ist 42868211700027, sollte 0 sein.  Reparieren? nein
Inode 29900808 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900808 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900808 hat eine ungültige Extragröße (60390)
Reparieren? nein
Spezielle Geräte-/Socket-/Fifo-Datei (Inode 29900809) hat den Erweiterungs-
oder Inlinedaten-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900809 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900809 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900809 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900809 hat eine ungültige Extragröße (969)
Reparieren? nein
Inode 29900809 hat den INDEX_FL-Bitschalter gesetzt, ist aber kein Verzeichnis.
Der HTree-Index wird bereinigt? nein
HTREE-Verzeichnis-Inode 29900809 hat einen unvollständigen Wurzelknoten („root node“).
Der HTree-Index wird bereinigt? nein
Inode 29900809, i_size ist 11212493537503701094, sollte 0 sein.  Reparieren? nein
Inode 29900809, i_Blocks ist 280774734954466, sollte 0 sein.  Reparieren? nein
Inode 29900810 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900810 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900810 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900810 hat eine ungültige Extragröße (37829)
Reparieren? nein
Inode 29900810 hat den INDEX_FL-Bitschalter gesetzt, ist aber kein Verzeichnis.
Der HTree-Index wird bereinigt? nein
HTREE-Verzeichnis-Inode 29900810 hat einen unvollständigen Wurzelknoten („root node“).
Der HTree-Index wird bereinigt? nein
Inode 29900810, i_size ist 8857243047096157609, sollte 0 sein.  Reparieren? nein
Inode 29900810, i_Blocks ist 273968576523254, sollte 0 sein.  Reparieren? nein
Inode 29900811 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900811 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900811 hat eine ungültige Extragröße (36640)
Reparieren? nein
Inode 29900812 scheint Inlinedaten zu besitzen, aber der Erweiterungs-Bitschalter ist gesetzt.
Reparieren? nein
Die Bitschalter von Inode 29900812 für Inlinedaten und Erweiterungen sind gesetzt aber i_block enthält Müll.
Inode bereinigen? nein
Inode 29900812 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900812 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900812 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900812 hat eine ungültige Extragröße (58966)
Reparieren? nein
Inode 29900812 hat den INDEX_FL-Bitschalter gesetzt, ist aber kein Verzeichnis.
Der HTree-Index wird bereinigt? nein
HTREE-Verzeichnis-Inode 29900812 hat einen unvollständigen Wurzelknoten („root node“).
Der HTree-Index wird bereinigt? nein
Inode 29900812, i_size ist 2987918919647206365, sollte 0 sein.  Reparieren? nein
Inode 29900812, i_Blocks ist 102423950077607, sollte 0 sein.  Reparieren? nein
Inode 29900813 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900813 hat eine ungültige Extragröße (33020)
Reparieren? nein
Inode 29900813, i_size ist 12638617963575757192, sollte 0 sein.  Reparieren? nein
Inode 29900813, i_Blocks ist 156203902372128, sollte 0 sein.  Reparieren? nein
Spezielle Geräte-/Socket-/Fifo-Datei (Inode 29900814) hat den Erweiterungs-
oder Inlinedaten-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900814 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900814 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900814 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900814 hat eine ungültige Extragröße (17443)
Reparieren? nein
Inode 29900814 hat den INDEX_FL-Bitschalter gesetzt, ist aber kein Verzeichnis.
Der HTree-Index wird bereinigt? nein
HTREE-Verzeichnis-Inode 29900814 hat einen unvollständigen Wurzelknoten („root node“).
Der HTree-Index wird bereinigt? nein
Inode 29900814, i_size ist 1351660657065069810, sollte 0 sein.  Reparieren? nein
Inode 29900814, i_Blocks ist 162035204214965, sollte 0 sein.  Reparieren? nein
Inode 29900815 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900815 hat eine ungültige Extragröße (58266)
Reparieren? nein
Spezielle Geräte-/Socket-/Fifo-Datei (Inode 29900816) hat den Erweiterungs-
oder Inlinedaten-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900816 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900816 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900816 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900816 hat eine ungültige Extragröße (16477)
Reparieren? nein
Inode 29900816, i_size ist 6134682725299140125, sollte 0 sein.  Reparieren? nein
Inode 29900816, i_Blocks ist 131010688075003, sollte 0 sein.  Reparieren? nein
Inode 29900817 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900817 hat eine ungültige Extragröße (12354)
Reparieren? nein
Inode 29900817, i_size ist 12534246057632336425, sollte 0 sein.  Reparieren? nein
Inode 29900817, i_Blocks ist 180382469771780, sollte 0 sein.  Reparieren? nein
Inode 29900818 hat den Bitschalter INDEX_DATA_FL gesetzt obwohl das Dateisystem Inline-Daten nicht unterstützt.
Bereinigen? nein
Inode 29900818 ist in Benutzung, aber hat dtime gesetzt.  Reparieren? nein
Inode 29900818 hat den Imagic-Bitschalter gesetzt.  Bereinigen? nein
Inode 29900818 hat eine ungültige Extragröße (31108)
Reparieren? nein
Fehler beim Iterieren über die Blöcke in Inode 29900818: Iterieren von Datenblöcken eines Inodes, das Inlinedaten enthält, ist nicht möglich
/dev/sdb1: ********** WARNUNG: Noch Fehler im Dateisystem  **********
e2fsck: abgebrochen
/dev/sdb1: ********** WARNUNG: Noch Fehler im Dateisystem  **********

Kann man damit noch was anfangen oder ist das hoffnungslos?
_______________________________
Welches System hätten's denn gern?

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

7

06.03.2018, 23:31

Was sagt eigentlich SMART, bei welchem Block der erste Fehler auftritt?

Wenn SMART eine Defekt der Platte meldet, kann das Dateisystem nichts für die fehlerhaften Daten. So gesehen kann fdisk a priori nicht helfen.

Wenn allerdings der Plattendefekt den Verwaltungsbereich des Dateisystems betriftt, könntest du versuchen, dieses zu reparieren. Natürlich nicht auf der Originalplatte, sondern auf dem Klon. Noch besser wäre ein weiterer Klon, damit dir ein Rettungsnetz bleibt, wenn sich der Zustand der Originalplatte weiter verschlechtert. Hier käme dann doch fdisk mit Reparatur-Option zum Zug.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

8

07.03.2018, 06:31

Auf dem Weg zum Erfolg, aber nocht nicht verifiziert

Die Platte mit den Nutzerdaten, wo ich die SMART-Diagnose gespeichert habe, ist gerade ausgebaut und der Ersatz noch nicht wieder eingebaut; es war aber eine ziemlich hohe Blocknummer. Beim Kopieren ist nichts auffälliges gemeldet worden. Die Sicherungspartition habe ich mit dem Midnight Commander und mit dem cp-Kommando übertragen und die HOME-Partition mit Clonezilla und einem Image als Zwischenstufe (device -> device hat 2mal nicht geklappt). Die geklonte Homepartition verhielt sich beim Einhängen ist Testsysteme normal. Jetzt wird sie gerade ins Rechnergehäuse eingebaut und ersetzt die kaputte Platte; mal schauen ob sie dann auch noch taugt.

Ein gestern gekaufter USB3-Adapter (statt einer USB2-Dockingstation) hat das Arbeiten erheblich beschleunigt. Der von dir vorgeschlagene zweite Klon existiert indirekt: das Conezilla-partimage hatte ich auf die heile Ersatzplatte geschrieben und dort bleibt es vorläufig auch.
_______________________________
Welches System hätten's denn gern?

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

9

07.03.2018, 14:22

Gelungen!

Alles funktioniert wieder und der Umbau ist beendet; Kiste wieder zugeschraubt. Die alte Platte liegt noch da, falls in den nächsten Stunden noch eine Schwierigkeit auftaucht. Ich mußte lediglich ein paar UUID anpassen und Timeshift (3 von den 5 realen Systemen verwenden das) seine Sicherungspartition erneut zeigen (auch wegen geänderter UUID).

Was nicht so glatt lief war der Vergleich alt ./. neu, weil diff in eine Rekursionsschleife geraten ist; hätte vielleicht besser rsync nehmen sollen. Danach habe ich mich mit dem Vergleich von Stückzahl der Dateien und deren aufsummierten Größe in Original und Klon zufrieden gegeben.
_______________________________
Welches System hätten's denn gern?

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

10

07.03.2018, 14:59

Zitat von »Fredl«

Was sagt eigentlich SMART, bei welchem Block der erste Fehler auftritt?

Der kurze Selbsttest wurde nach 10% abgebrochen mit

Zitat

LBA of the first error: 18564000

Betriebsstundenzahl (lifetime hours) = 6346; das erste Mal fiel dieser Block bei 6027 Stunden auf.
_______________________________
Welches System hätten's denn gern?

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

11

08.03.2018, 00:44

Kommt auf den Dateisystemtyp an, wo die Verwaltungsinformationen liegen.
Wenn die Daten jetzt im Trockenen sind, ist es eigentlich jetzt irrelevant.
Wenn du Lust hast könntest du mit badblocks nachsehen, wie schlimm es bereits um die Platte steht. Ggf. ergibt sich ein zusammenhängender Bereich, den du mit neuer Partitionierung aussparen kannst und so noch eine Weile unwichtigere Daten ablegen kannst. Zuverlässig ist das natürlich nicht.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

12

08.03.2018, 08:03

Danke

Bin kein Hardware-Freak. Das Ding wird gelöscht (mit DBAN oder dc3dd) und geht dann in die Garantieabwicklung zusammen mit einem SMART-Protokoll. Habe schon mit dem Händler gesprochen: er schickt es ein, dort wird es geprüft und ich bekomme Ersatz, wenn die einen Fehler finden. Mit größter Wahrscheinlichkeit bekomme ich nicht mehr die gleiche Platte repariert zurück, sondern irgendeine andere (gebraucht, neu, selbes Modell oder anderes). Genaueres konnte er nicht sagen.

Du hattest mich ja schon im November/Dezember 2016 eindringlich gewarnt, mit der Platte weiter zu arbeiten. Sie lief dann aber noch 1 Jahr fehlerfrei. Vielleicht sind jetzt alle Reservesektoren aufgebraucht und ich habe gerade noch die Kurve gekriegt.
_______________________________
Welches System hätten's denn gern?

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

13

11.03.2018, 11:52

So wird es wohl sein. Diese Erfahrung habe ich auch einmal gemacht.

Tipp: Wenn Die Austauschplatte kommt, erstelle als erstes wieder ein smart-Protokoll wie bereits beschrieben. Drucke es aus und hebe es mit dem Lieferschein auf. Dann kannst du gegebenenfalls den Lieferzustand nachweisen.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

Ähnliche Themen

Verwendete Tags

clonezilla, ddrescue, gparted & gpart, smartd