{"id":22614,"date":"2026-02-20T12:10:14","date_gmt":"2026-02-20T11:10:14","guid":{"rendered":"https:\/\/linux-bibel.at\/?p=22614"},"modified":"2026-02-20T12:10:16","modified_gmt":"2026-02-20T11:10:16","slug":"usb-stick-unter-linux-pruefen-und-daten-retten","status":"publish","type":"post","link":"https:\/\/linux-bibel.at\/index.php\/2026\/02\/20\/usb-stick-unter-linux-pruefen-und-daten-retten\/","title":{"rendered":"USB\u2011Stick unter Linux pr\u00fcfen und Daten retten"},"content":{"rendered":"\n

Ein defekter USB<\/a>‑Stick scheitert meist an zwei Dingen: Logische Fehler im Dateisystem<\/a> oder physische Schäden an Speicher, Controller oder Stecker. Typische Anzeichen sind Nichterkennung, Formatierungsaufforderungen, extrem lan<\/a>gsames Arbeiten oder plötzlich verschwundene Datei<\/a>en. Erste Checks: Anderen USB<\/a>‑Port und anderen Rechner testen, im System nachsehen, ob der Daten<\/a>träger überhaupt noch auftaucht, und den Stick auf sichtbare Schäden prüfen. Ein USB<\/a>‑Stick, der sich plötzlich nur noch lesen, aber nicht mehr beschreiben lässt, ist ein klares Warnsignal…<\/p>\n\n\n\n

Leichte Dateisystem<\/a>fehler lassen sich oft mit Bordmitteln oder Tools reparieren – aber je wichtiger die Daten<\/a>, desto weniger Experimente sollte man machen. <\/p>\n\n\n\n

USB<\/a>‑Stick identifizieren<\/p>\n\n\n\n

Bevor Reparaturversuche gestartet werden, sollte sicher sein, dass am richtigen Gerät gearbeitet wird. Dazu den USB<\/a>‑Stick anschließen und im Terminal<\/a> folgenden Befehl<\/a> ausführen:<\/p>\n\n\n\n

lsblk<\/code><\/pre>\n\n\n\n
In der Liste erscheinen alle Laufwerke (z.B. sda, sdb, sdc) und deren Partition<\/a>en (sdb1, sdb2 usw.)… Anhand der Größe lässt sich der USB<\/a>‑Stick meist gut erkennen – oftmals auch an der Gerätebezeichnung.
Notieren Sie sich ggf. die ermittelte Gerätekennung > sdb1<\/em><\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Optional lässt sich mit dem Befehl<\/a>:<\/p>\n\n\n\n
sudo blkid \/dev\/sdb1<\/code><\/pre>\n\n\n\n
das verwendete Dateisystem<\/a> abfragen. sdb1<\/em> entspricht im Beispiel die Gerätekennung. Damit wird sichtbar, ob der Stick z.B. mit ntfs, vfat, exfat<\/a> oder ext4<\/a> formatiert ist…<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Prüfen, ob der USB<\/a>‑Stick nur noch „read‑only“ ist<\/p>\n\n\n\n
Wenn der Stick nur mehr lesend Zugriff erteilt, schlagen Schreibversuche fehl. Der Status lässt sich direkt abfragen mit:<\/p>\n\n\n\n
mount | grep sdb1<\/code><\/pre>\n\n\n\n
Ggf. sdb1<\/em> durch die eigene Bezeichnung ersetzen.<\/p>\n\n\n\n
Die Ausgabe im Beispiel sieht so aus:<\/p>\n\n\n\n
\/dev\/sdb1 on \/media\/user\/SanDisk type ntfs3 (ro, \u2026)<\/code><\/pre>\n\n\n\n
Wichtig ist hier der Hinweis (ro<\/strong>…<\/p>\n\n\n\n
ro<\/strong> bedeutet: read‑only (nur lesend eingehängt).
rw<\/strong> bedeutet: read‑write (lesen und schreiben möglich).<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Solche Meldungen geben Anhalts<\/a>punkte, ob eher ein logischer Fehler (Dateisystem<\/a>) oder ein Hardwareproblem vorliegt.<\/p>\n\n\n\n
Vorrangig: Daten<\/a> retten statt reparieren<\/p>\n\n\n\n
USB<\/a>‑Sticks sind Verschleißteile mit begrenzter Lebensdauer, und billige Massenware beschleunigt ihren Ausfall zusätzlich. Flash‑Speicher verkraftet nur eine bestimmte Zahl von Schreibzyklen, während bei günstigen Modellen oft an Controller, Fehlerkorrektur und Qualität gespart wird. Alltagseinflüsse wie hartes Abziehen, Temperaturwechsel oder Transport am Schlüsselbund setzen der Hardware zusätzlich zu. Erfahrungsgemäß ist es sinnvoller, wichtige Daten<\/a> zu retten, solan<\/a>ge noch Zugriff darauf gewährt ist.<\/p>\n\n\n\n
Daten<\/a> mit rsync<\/a> oder cp sichern<\/p>\n\n\n\n
Im Beispiel ist der Stick ist unter \/media\/user\/SanDisk eingehängt. Mit folgendem Befehl<\/a> erstellen wir im home<\/a>-Bereich einen Ordner usb<\/a>-backup<\/a> in dem gesicherten Daten<\/a> vom USB<\/a>-Stick gespeichert werden:<\/p>\n\n\n\n
mkdir -p ~\/usb-backup\nrsync -av --progress \/media\/user\/SanDisk\/ ~\/usb-backup\/<\/code><\/pre>\n\n\n\n
Mit Klick auf [Enter] startet der Prozess – warten Sie den Vorgang ab, der je nach Daten<\/a>menge einige Zeit dauern kann…<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Im Beispiel konnten so alle Datei<\/a>en im Verzeichnis<\/a> usb<\/a>-backup<\/a> gesichert werden mit vollem Lese- und Schreibzugriff…<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Alternativ zu rsync<\/a><\/em> wäre cp<\/em><\/p>\n\n\n\n
cp -a \/media\/user\/SanDisk ~\/usb-backup<\/code><\/pre>\n\n\n\n
Vorteile von rsync<\/a> gegenüber cp:<\/strong>
Bricht bei Fehlern nicht sofort ab und zeigt Fortschritt und problematische Datei<\/a>en an.<\/p>\n\n\n\n
Fazit<\/p>\n\n\n\n
Wenn man etwas längerlebiges möchte, lohnt sich der Griff zum Markenprodukt – mit moderat dimensionierter Kapazität. Also nicht das billigste 1‑€‑Sonderangebot. Große, schreibintensive Arbeiten besser auf SSD<\/a>\/Backup<\/a>‑Systeme verlagern statt auf den Stick.<\/p>\n\n\n\n
Titelbild: Designed by Freepik<\/a><\/p>\n
\r\n    
\r\n    \r\n                            \"Gef\u00e4llt\r\n            <\/a>\r\n    17    <\/span>\r\n<\/div>
\r\n    \r\n                            \"Gef\u00e4llt\r\n            <\/a>\r\n    <\/span>\r\n<\/div><\/div>","protected":false},"excerpt":{"rendered":"
Ein defekter USB\u2011Stick scheitert meist an zwei Dingen: Logische Fehler im Dateisystem oder physische Sch\u00e4den an Speicher, Controller oder Stecker. Typische Anzeichen sind Nichterkennung, Formatierungsaufforderungen, extrem langsames Arbeiten oder pl\u00f6tzlich verschwundene Dateien. Erste Checks: Anderen USB\u2011Port und anderen Rechner testen, im System nachsehen, ob der Datentr\u00e4ger \u00fcberhaupt noch auftaucht, und den Stick auf sichtbare Sch\u00e4den […]<\/p>\n","protected":false},"author":7,"featured_media":22617,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[1514,85],"class_list":["post-22614","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-allgemein","tag-daten-retten","tag-usb-stick"],"_links":{"self":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/22614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/comments?post=22614"}],"version-history":[{"count":3,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/22614\/revisions"}],"predecessor-version":[{"id":22627,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/22614\/revisions\/22627"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/media\/22617"}],"wp:attachment":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/media?parent=22614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/categories?post=22614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/tags?post=22614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}