Ich bin gerade dabei, Daten von einem defekten 1-TB-Laufwerk zu retten (habe danach gefragt inVorgehensweise zum Ersetzen einer Festplatte?). Ich habe dies ddrescuevon einem USB-Stick aus durchgeführt, mit einer resultierenden Fehlergröße von 557568 B bei 191 Fehlern, wahrscheinlich alle bei eins /home(ich nehme an, dass es sich bei den sogenannten „Fehlern“ nicht um fehlerhafte Sektoren handelt, sondern um aufeinanderfolgende Sequenzen davon).
Nun, die verschiedenen Anleitungen, die ich gesehen habe, empfehlen, dies e2fsckauf der neuen Festplatte zu tun, und ich erwartete, dass dies irgendwie herausfindet, dass einigen Dateien „leere Sektoren/Blöcke“ zugewiesen wurden, sodass ich zumindest weiß, welche Dateien nicht vollständig gespeichert werden konnten. Aber es wurden überhaupt keine Fehler gefunden (ich habe es ohne ausgeführt, -yum sicherzugehen, dass ich nichts übersehen habe). Jetzt führe ich es erneut mit aus -c, aber bei 95 % wurden bisher keine Fehler gefunden; ich schätze, ich habe ein neues Laufwerk mit einigen normal aussehenden Dateien mit Nullen oder zufälligen Teilen darin, die nicht erkannt werden, bis ich sie eines Tages mit der entsprechenden Software öffne oder Linux Mint sie benötigt.
Kann ich mit den alten/neuen Laufwerken irgendetwas machen, um eine Liste möglicherweise beschädigter Dateien zu erhalten? Ich weiß nicht, wie viele es sein könnten, da diese 191 Dateien umfassen könnten, aber zumindest ist die Gesamtgröße nicht groß; ich mache mir hauptsächlich Sorgen um einen großen Haufen alter Familienfotos und -videos (jeweils 1+ MB), der Rest ist wahrscheinlich irrelevant oder wurde vor kurzem gesichert.
Update: der neue Durchlauf von e2fsck hat etwas Neues gebracht, von dem ich nichts verstehe:
Block bitmap differences: +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes
Antwort1
Sie benötigen die Blocknummern aller gefundenen fehlerhaften Blöcke (ich ddrescuehätte Ihnen eine Liste geben sollen, ich hoffe, Sie haben sie gespeichert) und dann müssen Sie herausfinden, welche Dateien diese Blöcke verwenden (siehe z. B.Hier). Wenn viele fehlerhafte Blöcke vorhanden sind, möchten Sie dies möglicherweise in einem Skript ausführen.
e2fsckhilft nicht, es prüft lediglich die Konsistenz des Dateisystems selbst und reagiert daher nur, wenn die fehlerhaften Blöcke „administrative“ Dateisysteminformationen enthalten.
Die fehlerhaften Blöcke in den Dateien sind einfach leer.
Bearbeiten
Ok, schauen wir uns mal die Sache mit der Blockgröße an. Erstellen wir ein Testdateisystem mit 512-Byte-Geräteblöcken:
$ dd if=/dev/zero of=fs bs=512 count=200
$ /sbin/mke2fs fs
$ ll fs
-rw-r--r-- 1 dirk dirk 102400 Apr 27 10:03 fs
$ /sbin/tune2fs -l fs
...
Block count: 100
...
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Die Dateisystemblockgröße beträgt also 1024, und wir haben 100 dieser Dateisystemblöcke (und 200 512-Byte-Geräteblöcke). So retten Sie es:
$ ddrescue -b512 fs fs.new fs.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued: 102400 B, errsize: 0 B, current rate: 102 kB/s
ipos: 65536 B, errors: 0, average rate: 102 kB/s
opos: 65536 B, run time: 1 s, successful read: 0 s ago
Finished
$ cat fs.log
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue fs fs.new fs.log
# Start time: 2017-04-27 10:04:03
# Current time: 2017-04-27 10:04:03
# Finished
# current_pos current_status
0x00010000 +
# pos size status
0x00000000 0x00019000 +
$ printf "%i\n" 0x00019000
102400
Die Hex- ddrescueEinheiten sind also in Bytes, nicht in Blöcken. Sehen wir uns abschließend an, was debugfsverwendet wird. Erstellen Sie zunächst eine Datei und suchen Sie ihren Inhalt:
$ sudo mount -o loop fs /mnt/tmp
$ sudo chmod go+rwx /mnt/tmp/
$ echo 'abcdefghijk' > /mnt/tmp/foo
$ sudo umount /mnt/tmp
$ hexdump -C fs
...
00005400 61 62 63 64 65 66 67 68 69 6a 6b 0a 00 00 00 00 |abcdefghijk.....|
00005410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Die Byteadresse der Daten lautet also 0x5400. Konvertieren Sie dies in 1024-Byte-Dateisystemblöcke:
$ printf "%i\n" 0x5400
21504
$ expr 21504 / 1024
21
und wenn wir schon dabei sind, probieren wir auch den Blockbereich aus:
$ /sbin/debugfs fs
debugfs 1.43.3 (04-Sep-2016)
debugfs: testb 0
testb: Invalid block number 0
debugfs: testb 1
Block 1 marked in use
debugfs: testb 99
Block 99 not in use
debugfs: testb 100
Illegal block number passed to ext2fs_test_block_bitmap #100 for block bitmap for fs
Block 100 not in use
debugfs: testb 21
Block 21 marked in use
debugfs: icheck 21
Block Inode number
21 12
debugfs: ncheck 12
Inode Pathname
12 //foo
Das funktioniert also wie erwartet, außer dass Block 0 ungültig ist, wahrscheinlich weil die Metadaten des Dateisystems vorhanden sind. Für Ihre Byteadresse 0x30F8A71000von ddrescuesubtrahieren wir also, vorausgesetzt, Sie haben auf der gesamten Festplatte und nicht auf einer Partition gearbeitet, die Byteadresse des Partitionsanfangs
210330128384 - 7815168 * 512 = 206328762368
Teilen Sie das durch die tune2fsBlockgröße, um den Dateisystemblock zu erhalten (beachten Sie, dass mehrere physische, möglicherweise beschädigte Blöcke einen Dateisystemblock bilden, die Zahlen also keine genauen Vielfachen sein müssen):
206328762368 / 4096 = 50373233,0
und das ist der Block, mit dem Sie testen sollten debugfs.
Antwort2
NTFS, ext3, ext4
Nachdem Sie die Daten mit von Ihrem defekten Laufwerk kopiert haben ddrescue, verwenden Sieddrutilityum die betroffenen Dateinamen zu finden.
ddrescueIch habe es erfolgreich geschafft, die betroffenen NTFS-Dateien auf einer 1-TB-Partition mithilfe einer Map-Datei in weniger als 20 Sekunden aufzulisten .
Es schreibt seine Protokolldatei in das aktuelle Verzeichnis.
Auf der verlinkten Seite wird die Unterstützung für NTFS, ext3 und ext4 erwähnt.
btrfs, zfs
Diese Dateisysteme haben ihre eigene integrierte scrubFunktion.
Antwort3
Ich würde ein bereits implementiertes Dienstprogramm namens empfehlen ddrutility. Dadurch würden die mühsamen manuellen Berechnungen entfallen.
Sie sollten es auf Ihrem geklontenKopieren(nicht das Original) Laufwerk wie folgt:
ddru_findbad /dev/sdb /ddrescue-disk-copy.map
Die Verwendung der Map-Datei (zweites Argument) ist hier zwingend erforderlich.
Das Dienstprogramm ist recht intelligent, unterstützt verschiedene Dateisysteme (sogar NTFS) und verfügt auch über die Funktion, fehlerhafte Sektoren zu testen, die noch aufgeteilt werden müssen (indem sie als fehlerhafte temporäre Sektoren markiert werden). Sie sollten also abschätzen können, ob Sie den gesamten ddrescueVorgang abschließen müssen. Beachten Sie auch, dass /dev/sdbhier eine ganze Festplatte verwendet wird (nicht eine Partition wie /dev/sdb1), da die gesamte Festplatte ursprünglich geklont wurde.
Das Dienstprogramm ist in Debian-Repos verfügbar und kann mit folgendem installiert werden:
sudo apt install ddrutility
Das Wiki des Projekts:https://sourceforge.net/p/ddrutility/wiki/Home
Antwort4
Ich habe einfach Filezilla verwendet und mein Problem behoben. Verwenden Sie das normale Filezilla, um alle guten Daten zu sichern. Mir ist aufgefallen, dass eine große Datei nicht richtig kopiert wurde (sie brach mittendrin ab und die Übertragung wurde neu gestartet). Zum Glück habe ich eine frühere Sicherung derselben Datei. Um die Festplatte zu duplizieren, musste ich die fehlerhaften Blöcke auf der Festplatte mit diesem Verfahren finden:
1. Finden Sie die Problemfestplatte, indem Sie die HD-Informationen verwendenfdisk -l
2. Wenn Ihre Festplatte/Entwickler/sdbdann müssen Sie den Befehl ausführen badblocks -v /dev/sdbEs werden alle fehlerhaften Blöcke auf dem Laufwerk aufgelistet. Zum Glück gibt es einige. Wenn keine fehlerhaften Blöcke gefunden werden, sind die Blöcke Ihres Laufwerks in Ordnung und Sie müssen sich etwas anderes überlegen. Meine Blockgröße beträgt 512, also verwende ich diese Standardnummer, um DD auszuführen
3. Jeder Block hat eine Größe von 512, also habe ich bs=512 gesetzt
Jedes Mal, wenn ich DD wie immer regelmäßig ausführe, werden meine Daten nach den Fehlern beschädigt. Also verwende ich dann die Parameter wie auf der Seite erklärthttps://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.htmlDurchsuchen Sie den Abschnitt „Nach fehlerhaften Festplatten“.
dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock
Es hat eine Weile gedauert. Jeder fehlerhafte Block klingt wie ein Klopfen auf dem fehlerhaften Laufwerk. Es kopiert Block für Block und hat bei allen meinen fehlerhaften Blöcken das gleiche Geräusch gemacht. Die Häufigkeit, mit der das Geräusch gemacht wurde, lag daran, dass es einen weiteren fehlerhaften Block gefunden hat und Sie über eine Fehlermeldung auf dem Display informiert. Was ist der„conv=keinFehler,Sync“ist, fehlerhafte Lesevorgänge mit NULs aufzufüllen, während'iflag=vollständiger Block'eignet sich für kurze Lesevorgänge, hält Ihre Daten aber bis zum Ende synchron. Keine Beschädigungen, es kopiert lediglich die fehlerhaften Blöcke nicht und füllt sie mit leeren NULs.
Nachdem das Kopieren mit DD abgeschlossen war, habe ich einfach die fehlerhafte Datei ersetzt, indem ich Filezilla von einem früheren Backup wiederhergestellt habe, und alles hat einwandfrei funktioniert. Ich hoffe, dass dies für andere nützlich ist, die versuchen, fehlerhafte Laufwerke zu sichern.
HINWEIS: Meine fehlerhaften Blöcke lagen ziemlich nah beieinander. Ungefähr 4 Blöcke gleichzeitig in Gruppen wurden als fehlerhaft erkannt. Wenn Ihre Blöcke über die ganze Festplatte verteilt sind, könnten mehrere Dateien betroffen sein. Glücklicherweise war in meinem Fall nur eine große Datenbankdatei mit 4 GB betroffen.