Daten von USB-Stick retten

Gestern hatte ich das Problem, dass eine USB-Stick nur noch schwer lesbar und beschreibbar war. Grund hierfür: Der USB-Stick meldet sich alle 15s an und wieder ab. (Das fällt einem durch automount bei kleinen Textdateien nicht mal sofort auf) Das Problem trat sowohl unter Windows als auch Linux auf – auch an verschiedenen USB-Ports von drei Rechnern. dmesg macht einem mit

1
[12124.276596] blk_update_request: I/O error, dev sdd, sector 12949480

nicht gerade Hoffnungen. Die Diagnose ist einfach wie bitter zugleich: USB-Stick kaputt. Nun steht man vor dem Problem: Hab ich von allen Daten, die gegebenenfalls noch auf dem Stick sind, noch eine Kopie? Ein simples Kopieren der Daten vom Stick war durch das zyklische An- und Abmelden nicht mehr möglich. Also als allererstes ein Image erstellen.

Image erstellen

Programm der Wahl ist hier ddrescue. Der Programmaufruf ist dabei simpel:

1
$ sudo ddrescue -n QUELLE ZIEL ddrescue.log
  • QUELLE ist immer ein Linux-Device, also nach dem Schema /dev/sdX
  • ZIEL kann eine Datei sein; eine andere Partition o.ä. wäre aber auch möglich
  • -n sorgt dafür, dass bei einem Fehler nicht probiert wird, den selben Sektor wiederholt zu lesen. Die Sektoren werden entsprechend im log markiert. Ist ddrescue soweit fertig, kann man die Option entfernen. Erst ohne Option wird versucht, beschädigte Sektoren zu lesen. Letzteres kann aber dauern.
  • Über ddrescue.log weiß ddrescue, welche Sektoren bereits mit welchem Status gelesen wurden. Dadurch ist ddrescue also auch für häufig abbrechende Lesevorgänge geeignet.

Das ganze habe ich dann noch in eine while-Schleife gepackt. Somit macht ddrescue weiter, sobald der USB-Stick sich wieder beim Kernel angemeldet hat. Das Ende vom Lied: 15MB an Sektoren sind nicht mehr lesbar. (es war ein Stick mit 16GB) Auch ohne -n hat sich dieser Wert nur noch um eine einstellige Zahl an 100 kB verbessert.

Mit einer Kopie des Images kann man dann weiterarbeiten und Rettungsversuche durchführen, wie man lustig ist. Man hat ja noch das originale Image auf der Platte.

Image mounten

Zuerst wird via losetup ein loop-Device erstellt:

1
$ sudo losetup -f -P /path/to/image
  • -f automatisch nächstes, freies loop-Device wählen
  • -P Markierung für Partition an loop-Device hinzufügen

In den meisten Fällen wird dadurch loop0 verwendet. Da der Stick nur eine Partition hatte, ist diese entsprechend unter /dev/loop0p1 zu finden.

Vor dem Mounten ist es zudem sinnvoll einmal fsck über die Partition laufen zu lassen:

1
$ sudo fsck -y /dev/loop0p1

Durch -y werden alle automatisch erkennbaren Fehler entfernt. Danach mounten per:

1
$ sudo mount /dev/loop0p1 /mnt/my-recover-mountpoint

/mnt/my-recover-mountpoint ist beliebige wählbar; der Ordner muss einzig vor dem mounten existieren.

Nach dem mounten gab es noch Probleme mit dem Zeichensatz von Dateinamen. Mir ist unbekannt, ob das Problem schon vorher vorhanden war. Retter in der Not hier: convmv.

Datensichtung

Nachdem man jetzt (hoffentlich erfolgreich) auf die Inhalte des Images Zugriff hat, kann man mal schauen, was alles noch so auf dem Stick ist – oder wie kaputt die Daten sind. Man findet zum Beispiel Folgendes:

JPEG-Bild mit Artefakten, die durch Datenverlust entstanden sind
JPEG-Bild nach teilweisem Datenverlust

Bei dem Bild war es nicht schlimm, da es auf dem Stick nur als Backup lag. Aber es zeigt meiner Meinung nach recht anschaulich, was passiert, wenn Sektoren nicht mehr gelesen werden können.

Sollte noch mehr kaputt oder nicht auffindbar (Beschädigte Inode etc.) sein, helfen Programme wie PhotoRec. Das Programm eignet sich auch gut, um sofort versehentlich gelöschte Daten wiederherzustellen. Das aber nur als Hinweis am Rand, ich werde hier jetzt nicht genauer darauf eingehen.

Fazit

tja, was lernt man daraus?

  • Backups sind immer wichtig. Am besten in mehrfacher Ausführung.
  • Vertraue keinem USB-Stick wichtige Daten an. Die sind nur dafür da, eine Kopie von A nach B zu tragen.
  • Im Idealfall kann man noch einige Daten retten. Aber das ist auch reine Glückssache.

Links

Kommentare

Noch kein Kommentar zu diesem Artikel.

Neuen Kommentar schreiben