Schreiben Sie ein HFS +-formatiertes Laufwerksabbild auf ein Laufwerk mit geringerer Kapazität unter Linux

641
GabrielB

Ich habe ein möglicherweise defektes 1-TB-Festplattenlaufwerk mit einem Datenbestand von etwa 270 GB mit ddrescue auf einem Lubuntu-Live-System abgebildet. Die Erholung ist zu 99,9% abgeschlossen. Es gibt nur einen 52-KB-Bereich, der in der Nähe der 300-MB-Marke nicht lesbar war. In SMART gibt es jedoch keine "ausstehenden" oder "neu zugewiesenen" Sektoren. Erste Frage: Wie ist das möglich? Könnte dies ein günstiger Fall von "logischen" fehlerhaften Sektoren sein, dh Sektoren, die zwar physisch noch in Betrieb sind, aber in einem inkonsistenten Zustand sind, was zu einem Ausfall der CRC-Prüfung führt, und könnten sie dauerhaft und zuverlässig "fixiert" werden, indem sie einfach überschrieben werden? Ich führte den kurzen Selbsttest durch, der mit einem Lesefehler abgeschlossen wurde. Kann ich SMART data weiterhin zu 100% vertrauen und sicher sein, dass es auf physischer Ebene tatsächlich keinen gibt, wenn kein fehlerhafter Sektor gemeldet wird?

Dann habe ich 3 Ersatzlaufwerke, mit denen ich die wiederhergestellten Daten für den Besitzer übertragen könnte, der einen MacBook-Computer verwendet: ein 320-GB-Laufwerk in USB2, ein 500-GB-Laufwerk in USB3, ein 1-TB-Laufwerk in USB3. Das Quelllaufwerk ist in HFS + formatiert. Gibt es eine sichere und bequeme Möglichkeit, dieses 1-TB-Image, das tatsächlich nur etwa 270 GB (da es mit ddrescue-Schalter -S-Switch erstellt wurde) belegt, direkt auf ein Laufwerk mit geringerer Kapazität, mit einem kostenlosen Linux- oder Windows-Tool, zu schreiben so, dass die wiederhergestellte Festplatte mit einer konsistenten Partitionstabelle leicht lesbar ist? (Ich habe keine Erfahrung mit Partitions- und Formatierungsschemata von Apple.) Oder wäre es besser, wenn Sie eine HFS + -Partition erstellen - mit welchem ​​Werkzeug GParter offenbar damit nicht umgehen kann - und die Dateien und Ordner kopieren? Aber in diesem Fall Werden die Zeitstempel und andere Metadaten automatisch beibehalten? Oder müsste ich eine bestimmte Methode verwenden, um sich zu vergewissern? Kann ein Linux-Befehl wie "cp" Dateien zwischen HFS + -Partitionen kopieren und alle für dieses Dateisystem spezifischen Attribute beibehalten?

Vielen Dank.

0
Ich nehme an, Sie haben die Platte in eine Datei aufgenommen und auch eine Protokolldatei gespeichert? Haben Sie noch einmal "ddrescue" ausgeführt und die Log- / Map-Datei bereitgestellt? Es ist möglich, dass der nicht lesbare Bereich erfolgreich gelesen werden kann, wenn Sie es noch einmal versuchen. Attie vor 6 Jahren 0
Wenn Sie ein Image mit einem Loch auf eine neue Festplatte schreiben, wird dies irgendwann zu Problemen führen. Ich würde es dagegen empfehlen. Mounten Sie das Dateisystem mithilfe des Images (nicht der Festplatte) und kopieren Sie die Dateien in ein neues Dateisystem auf einer neuen Festplatte mit `rsync` oder ähnlichem. Zeitstempel sollten verarbeitet werden, andere Apple-spezifische Metadaten können jedoch ausgelassen werden. Attie vor 6 Jahren 0
Ja, ich habe eine Protokolldatei verwendet, aber nein, dieser Bereich wurde immer (ich habe ein paar Mal wiederholt, um den ersten GB zu extrahieren) als "Fehler" behandelt - und sofort ohne Verzögerung oder Verlangsamung, wie es normalerweise bei einem "physischen" geschieht ”Es gibt einen schlechten Sektor, der die„ logische “schlechte Sektorhypothese zu bestätigen scheint. GabrielB vor 6 Jahren 0
Nun, es ist nicht wirklich ein "Loch", es ist nur ein kleiner Bereich leer, oder? Mit ddru_findbad von ddr_utilities habe ich herausgefunden, dass sich die 104 nicht lesbaren Sektoren in der Datei „/.journal“ befanden. Wenn es in NTFS wie $ LogFile / $ UsnJrnl aussieht, sollte dies die Integrität der Partition gefährden, oder? Andernfalls: GParted kann keine HFS + -Partition erstellen. Gibt es ein kostenloses Tool, das das kann? GabrielB vor 6 Jahren 0

1 Antwort auf die Frage

0
GabrielB

Also habe ich getan, was meine Intuition mir gesagt hat: Ich habe versucht, nur den winzigen, unlesbaren Bereich mit diesem Befehl zu überschreiben (könnte mit dem einfacheren Tool dd ausgeführt werden, aber ich bin damit weniger vertraut):

lubuntu@lubuntu:~$ sudo ddrescue -o 312881152 -s 53248 -f /dev/zero /dev/sdb /media/lubuntu/354E48E260FCFD84/dev_zero_dev_sdb.log  [Note : the -f switch is necessary here since there is natively a protection preventing ddrescue from writing directly to a physical device.]

Und es hat funktioniert: Zur Verifizierung habe ich das erste GB erneut abgebildet, und diesmal war kein Fehler aufgetreten (ich hatte dieses partielle Imaging versucht, bevor der obige Befehl ausgeführt wurde, und der Fehlerbereich war dann immer noch dort, mit exakt derselben Position und Größe.) Ich bemerkte auch, dass es sofort übersprungen wurde, ohne dass es zu einer Verlangsamung kam, im Gegensatz zu dem, was normalerweise passiert, wenn es einen "physischen" schlechten Sektor gibt und dieser sich verlangsamt oder vor dem Überspringen für einige Sekunden hängt.); Der "kurze Selbsttest" wird nun ebenfalls fehlerfrei abgeschlossen.

Zuvor habe ich einige Windows-Tools ausprobiert: Durch einen Lese-Scan mit Hard Disk Sentinel wurde es auf unbestimmte Zeit eingefroren. Ich musste das Laufwerk herunterfahren. Beim Versuch, auf den problematischen Bereich mit WinHex zuzugreifen, wurde es erstarrt, bis das Laufwerk heruntergefahren wurde.

Ist es richtig, dass dies ein Fall "logischer" fehlerhafter Sektoren war und das Laufwerk physisch in Ordnung ist und wieder verwendet werden kann, da in SMART zu keinem Zeitpunkt ein "ausstehender" oder "neu zugewiesener" Sektor angezeigt wurde des Prozesses Was ist die wahrscheinliche Ursache dafür, möglicherweise ein Schreibvorgang, der durch ein nicht ordnungsgemäßes Herunterfahren unterbrochen wurde? Ist dies ein häufiges Problem und wird das Laufwerk normalerweise außer Betrieb gesetzt, wenn eine Systemdatei betroffen ist?

Verwandte Probleme