Ich wollte wissen, wie gut sich Daten mit Linux-Bordmitteln wiederherstellen lassen. Also habe ich eine alte Festplatte genommen und es systematisch ausprobiert. Erst normal gelöschte Dateien, dann ein RAW-Image, und am Ende habe ich die Platte physisch zerstört, um zu sehen was ddrescue und PhotoRec aus den Trümmern holen.
Vorbereitung: Testplatte befüllen
Die älteste funktionierende Platte aus meinem Fundus: eine WD Expert 136BA. Erst komplett mit Nullen überschrieben, dann partitioniert und als NTFS formatiert:
dd if=/dev/zero of=/dev/sdb1 mkfs.ntfs -L TestDatenloeschung -T /dev/sdb1
Einen ca. 1,53 GB großen Ordner mit verschiedensten Dateien habe ich dann so lange auf die Platte kopiert, bis sie voll war.
ntfsundelete: Gelöschte Dateien wiederherstellen
Erster Scan, noch ohne etwas gelöscht zu haben:
ntfsundelete -s /dev/sdb1 # Files with potentially recoverable content: 0
Logisch, es wurde ja noch nichts gelöscht. Also ein paar Dateien weg und erneut scannen:
ntfsundelete -s /dev/sdb1 # Files with potentially recoverable content: 154
154 Dateien. Jetzt die Wiederherstellung:
ntfsundelete /dev/sdb1 -u -m '*.*' -p 100 -d /test
Die Optionen: -u für Undelete-Modus, -m '*.*' für alle Dateien (mit -m '*.doc' könnte man nur Word-Dateien holen), -p 100 für nur zu 100 % wiederherstellbare Dateien, -d /test als Zielverzeichnis. Bei Bildern könnte man den Prozentsatz auch niedriger setzen, Teile eines JPEG sind besser als nichts.
Alle 154 Dateien kamen vollständig zurück. Einzige Einschränkung: Dateien mit gleichem Namen werden nicht überschrieben. Sollte man beachten oder per Script lösen.
Arbeiten mit RAW-Images
Im Ernstfall arbeitet man nie mit der Originalplatte. Sobald man den Datenverlust bemerkt, am besten sofort den Stecker ziehen. Jeder weitere Betrieb, selbst ein Herunterfahren, kann die gelöschten Daten überschreiben. Also erst ein RAW-Image ziehen:
dd if=/dev/sdb1 of=/001/TestRettung.img # 26709984+0 Datensätze ein # 13675511808 Bytes (14 GB) kopiert, 701,766 s, 19,5 MB/s
ntfsundelete funktioniert genauso mit dem Image-File. Gleiche Ergebnisse, gleiche Wiederherstellung. Genau so soll es sein.
Die Festplatte zerstören
Jetzt wird es interessant. Mich hat natürlich interessiert, was bei einer physisch beschädigten Platte passiert. Also Platte wieder voll gemacht und dann aufgeschraubt.
Vorsichtig ein paar Kratzer mit dem Schraubendreher auf die Magnetscheiben gesetzt. Nicht zu viel, aber genug, dass einige Gigabyte unlesbar sein sollten.
ddrescue: 52 Stunden an einer zerkratzten Platte
Platte wieder zugeschraubt und ddrescue drauf losgelassen:
ddrescue -n /dev/sdb1 /001/datenrettung.img /001/datenrettung.log ddrescue -d -n -r3 /dev/sdb1 /001/datenrettung.img /001/datenrettung.log
Nach meiner kleinen Kratzorgie hat ddrescue 52 Stunden an der Platte gefummelt, bevor es durch war.
Wann zum Profi?
Wenn einem die Daten mehr als 3.000 Euro wert sind, sollte man einen professionellen Datenretter aufsuchen. Die nehmen zur Diagnose oft um die 90 Euro und sagen dann, was es wirklich kostet. Bei einem Fall aus 2010 hat ein Kunde mit einer 160 GB HDD und Headcrash einen Kostenrahmen von 15.000 bis 18.000 Euro genannt bekommen. Jede Bewegung an der Platte kann weitere Daten zerstören.
Ich habe selbst mal bei einer Seagate SCSI-Platte die komplette Elektronik von einer baugleichen getauscht, weil sie keinen Spin-Up mehr machte. Lief danach wieder, als wäre nie etwas gewesen. Auch ein Tausch der Schreib-/Leseköpfe hat einmal funktioniert, nachdem einer halb abgerissen war. Die Platte sprang genau ein Mal an, ich konnte sichern, beim nächsten Versuch ging nichts mehr. Solche Experimente klappen nicht immer. Hat man an der Platte herumgefummelt, hat oft auch der Profi keine Chance mehr.
PhotoRec: Dateien anhand des Headers retten
Das ddrescue-Image ließ sich in meinem Fall nicht mehr mounten. Durch die Kratzer war auch das NTFS-Dateisystem total im Eimer, selbst fsck half nicht. Also brauchte ich ein Programm, das Dateien anhand ihres Headers wiederherstellen kann: PhotoRec.
photorec datenrettung_parti_sicher.img
PhotoRec hat erstaunlich viele Dateien aus der zerkratzten Platte zurückgeholt. Wer sich das Programm anschaut, sollte sich auch TestDisk vom gleichen Entwickler ansehen. Damit lassen sich gelöschte Partitionen rekonstruieren und noch vieles mehr.
Update 2026: Was bei SSDs und NVMe anders ist
Der Beitrag oben ist von 2010 und das merkt man. Die meisten Endgeräte haben heute keine drehende Festplatte mehr, sondern eine SSD oder NVMe. Das ändert das Spiel komplett.
Sobald TRIM oder UNMAP aktiv sind, meldet das Dateisystem dem Controller, welche Blöcke nach einem DELETE freigegeben sind. Der Controller löscht diese Zellen oft sofort oder beim nächsten Garbage-Collection-Lauf. Ergebnis: ntfsundelete oder PhotoRec laufen ins Leere, weil die Daten physisch schon weg sind. Wer ein Recovery-Tool an einer SSD ansetzt, sollte das Laufwerk vorher per Software-Hardware-Befehl ruhigstellen, also nicht mounten und keine TRIM-Befehle mehr absetzen lassen.
NVMe legt noch eine Schaufel drauf. Mit nvme sanitize oder nvme format --ses=1 ist nach Sekunden alles weg, kryptografisch sauber. Das ist gut für Hardware-Verkauf oder -Entsorgung, ein Albtraum für Recovery.
Verschlüsselte Datenträger sind ein eigenes Kapitel. BitLocker, LUKS, FileVault, APFS-Encryption: ohne den Schlüssel oder das Recovery-Passwort hilft kein Tool der Welt. Bei einem PCB-Defekt einer SSD wird es zusätzlich kritisch, weil moderne Controller die Verschlüsselung intern anders handhaben als der Host. Selbst wenn die NAND-Chips noch heile sind, bekommt ohne den passenden Controller-State niemand mehr Klartext zurück. Mit anderen Worten: ein einfacher PCB-Tausch wie bei meiner alten Seagate SCSI ist 2026 nicht mehr drin, schon gar nicht im Selbstbau.
Update 2026: Backup schlägt Recovery
Die ehrliche Wahrheit nach 15 Jahren: ich habe nicht mehr ein einziges Mal in echt eine Datenrettung gemacht. Nicht weil die Tools schlechter geworden wären, sondern weil ich Backups habe. Wenn eine Platte stirbt, ziehe ich den letzten Snapshot zurück und gut ist. Recovery ist die Notlösung, wenn das Backup fehlt oder kaputt ist.
Was ich heute tatsächlich nutze:
- ZFS-Snapshots mit
zfs-auto-snapshot: stündlich, täglich, wöchentlich. Auf der Workstation und im Storage. Versehentlichesrm -rfoder ein Crypto-Trojaner sind in Sekunden zurückgerollt. - zfs send / zfs recv auf einen externen Pool und auf ein Offsite-System. Inkrementell, verschlüsselt mit
zfs send -w, vollautomatisch per Cron. - Borg / Restic für die Geräte, die kein ZFS sprechen. Deduplizierend, verschlüsselt, push und pull-Modi.
- Time Machine auf dem MacBook, weil es genau das macht was es soll.
Die 3-2-1-Regel ist alt und immer noch korrekt: drei Kopien, auf zwei verschiedenen Medien, eine davon räumlich getrennt. Cloud-Sync wie Dropbox, OneDrive oder Google Drive ist dabei kein Backup. Wenn dort etwas gelöscht wird, ist es im selben Moment auch lokal weg. Ein Backup ist immer eine Kopie, die nicht automatisch mitläuft.
Update 2026: Tools und Preise heute
Die guten Nachrichten zuerst: alle vier Tools aus dem Original werden weiter aktiv gepflegt.
- GNU ddrescue: aktuell Version 1.28, läuft auf jedem Linux/BSD/macOS. Mit ddrescueview gibt es eine GUI, die das Mapfile visualisiert.
- PhotoRec / TestDisk: Version 7.2, von cgsecurity.org. Versteht inzwischen über 500 Dateiformate, auch moderne wie HEIC, AVIF, MKV-Container.
- ntfsundelete: Teil der ntfs-3g/ntfsprogs, weiterhin im Standard-Repository jeder Distribution.
- SMART und Vorhersage:
smartctlaus smartmontools ist Pflicht. Die WerteReallocated_Sector_Ct,Current_Pending_SectorundOffline_Uncorrectablesagen oft schon Tage vorher, dass die Platte sterben wird.
Bei den Preisen für professionelle Datenrettung hat sich einiges getan. Die Diagnose liegt heute meist zwischen 50 und 200 Euro, oft sogar kostenlos wenn man den Auftrag erteilt. Die eigentliche Rettung ist stark gestaffelt: einfache Logikfehler ab etwa 300 Euro, mechanische Defekte mit Reinraum ab 800 bis 1.500 Euro, schwere Schäden mit Plattentausch und Adaption-Tabellen können immer noch vier- bis fünfstellig werden. Anbieter wie CBL, Ontrack oder Stellar geben kostenlose Erstdiagnose, das nutze ich heute auch wenn nur ein Verdacht im Raum steht.
Ein Hinweis noch: SSD- und NVMe-Recovery ist deutlich teurer als HDD-Recovery, weil der Reinraum-Aufwand durch teure Equipment-Setups für NAND-Reads ersetzt wird. Wer also wirklich wichtige Daten auf einer SSD hatte, fährt mit einem soliden Backup-Konzept finanziell und nervlich besser.
Fazit
Für normal gelöschte Dateien auf NTFS reicht ntfsundelete. Bei physischen Schäden ist ddrescue das Mittel der Wahl, um erst ein Image zu sichern. Und wenn das Dateisystem komplett zerstört ist, kann PhotoRec anhand der Datei-Header noch erstaunlich viel retten. Wichtigste Regel: Nie an der Originalplatte arbeiten, immer zuerst ein Image ziehen.
2026 gilt das alles weiter, mit zwei Einschränkungen. Auf SSDs und NVMe kommt man oft schon gar nicht mehr an die Daten. Und: das beste Recovery ist das, das man nie machen muss. Backup, Backup, Backup.
Siehe auch: FreeBSD: Automatische ZFS-Snapshots mit zfs-auto-snapshot, FreeBSD: ZFS-Datensicherung mit Snapshots und zfs send/recv und FreeBSD: Verschlüsseltes ZFS-Backup auf USB-Platte mit geli.
Fragen? Einfach melden.
Einige Male habe ich mir schon vorgenommen die ganzen Schlabberdisketten irgendwie ordentlich zu archivieren. Tja, aber wie? Von Schlabberdiskette auf Schlabberdiskette kopieren ist nicht das Gelbe vom Ei. Zum Einen sind die Dinger einfach zu empfindlich und zum Anderen gibt es auch Disketten die sich nicht so einfach kopieren lassen. Ich denke da z.B. an GEOS usw…
Also, was machen? Ein PC-Laufwerk für die Schlabberdisketten kann die Commodore beschriebenen leider nicht lesen. Das liegt jetzt nicht am genutzten Dateisystem auf den Datenträgern, sondern an der Art wie der Kontroller die Daten auf die Diskette packen lässt. Daher fällt es schon einmal flach diese einfach mit einem einfachen PC-Laufwerk kopieren bzw. archivieren zu wollen. Vielleicht kann man das Commodore Laufwerk ja einfach in den PC einbauen? Hm, so einfach geht das nicht aber man könnte über ein Kabel die komplette Floppy an seinen Computer anschließen. Zumindest hat mir google so etwas erzählt. Dann könnte ich auch Disketten 1A kopieren und öhm Images von Disketten machen und diese archivieren. Wie viele C64 Diskette (jede Seite hat ~170,8KB) bekomme ich wohl auf eine CD-ROM oder gar DVD *denk*? Diese Idee mit dem Kabel und der ganzen Floppy am PC hat mir gefallen, daher habe ich google mal nach dem Kabel gefragt.
Die Antwort war dieser Schaltplan zu einem XM1541 Kabel:
Gut, schaut ja nicht sonderlich schwer aus. Ich brauche quasi nur:
– 1 x 25 Pol. LPT Stecker
– 1 x 6 Pol. DIN Stecker
– 4 x Diode BAT85 (sind diese Schottky Dioden), die 1N5819 sollten also auch klappen.
– 1 x 5 Pol. geschirmte Leitung (ungeschirmt geht sicher auch. Nur halt nicht bei Leuten mit Hirn)
Jetzt kann ich auch schon meine 1541 Floppy an meinen Laptop anstöpseln:
Ja, so gefällt mir das schon. Schaut doch ganz nett aus, oder?
Den Hardwareteil hätten wir damit. Jetzt müssen wir es nur noch schaffen, der Hardware zu sagen was sie machen soll. Also mal wieder google nach Hilfe gefragt. Cbm4linux soll da wohl die Lösung meiner Probleme sein. Auf der Homepage zu 
Richtig geil wird es aber erste wenn man einen C64 / C128 oder ähnlich Emulator benutzt. Ich nutze hier VICE. 1A Teil. Dieser unterstützt nämlich die Anbindung von einer echten Commodore Floppy an einen PC. Weil der PC „etwas“ schneller ist als der Commodore 64 mit seiner 1MHz CPU rennt alles (je nach Einstellung) natürlich auch wie Sau. Schaut selbst:
Links ist ein Standfuss mit Magnet. Dieser hält auch bei 50km/h noch auf dem Autodach.
Auf diesen wird nun die Antenne (Mitte) geschraubt. Dieses kann man nun ohne Probleme in die
Orinoco Gold PCMCIA-Karte (rechts) stecken, hier ist auch ein Prism II Chip verbaut.
Fertig….. Der Empfang ist einfach nur geil. Egal
wo man nun genau sitzt!
Jetzt fehlt nur noch ein Notebook.
Ich nutze ein Fujitsu Siemens LifeBook E 7110! Linux arbeiten mit
allen Komponenten in diesem Notebook ohne Probleme und gebastel zusammen.
Um Funknetzwerke zu finden, muss die Wlan-Karte in den Monitor Mode gesetzt werden.
Im Monitor Mode nimmt die Karte alle Packet an. Egal aus welchem Netz sie kommen und egal
für wen sie bestimmt sind.
Der Standart Linux-Kernel kann die Karte nicht in den Monitor Mode setzen. Dieser muss also gepatch
werden oder es muss ein passendes Kernelmodul erstellt werden. Am einfachsten geht es so:
0. Mit iwpriv schauen ob der eigene Kernel vielleicht schon gepatcht wurde!
1. Quellen des aktuellen Kernels installieren.
2. gcc installieren.
3. Die aktuelle Konfiguration des Kernels ins root der Kernelquellen legen.
Unter Suse: zcat /proc/config.gz > .config
Als Root unter /usr/src/linux
4. Saug dir 
Dieses sollte vorher noch konfigurieren werden;-). Es gibt unter /etc/kismet/ die Datei:
kismet.conf.
In dieser müssen wir zwei Änderungen vornehmen.
Beim Punkt „suiduser=“ tragen wir hinter dem = unseren Usernamen ein mit dem wir auf der Linux
Kiste arbeiten.
Am Punkt „source=“ tragen wir hinter dem = folgendes ein: orinoco,eth1,orinocosource
Wobei wir eth1 natürlich gegebenenfalls gegen unsere Wlan-Karte austauschen!
Ein „sudo kismet“ in der Userkonsole sollte nun das Programm starten und sogleich nach Netzen
suchen.
Haben wir eines gefunden und wollen erst einmal nachschauen, was genau dort durch die Gegend fliegt.
Brauchen wir dazu ein Programm mit dessen Hilfe wir den Datenstrom auslesen können. Dieses erledigt Ethereal
super. Später ist es auch drin, mit diesem Programm sehr komplexe Filterungen auf den Datenstrom anzuwenden.
Da wir aber nur die Daten annehmen können welche auf unserem Channel gesendet werden.
Betreibt Kismet Channelhopping. D.h.: Kismet springt im ms. Takt vom Einen in den Anderen Channel.
Wenn wir einen konstanten Datenstrom mitlesen wollen, ist das scheisse! Wir können dann ja nur die Daten
mitlesen, wenn wir auch gerade im passenden Channel sind. Daher beenden wir Kismet und setzen die Karte von Hand
in den Monitor Mode und den passenden Channel. Dieses geht als User-Root so:
iwpriv eth1 monitor 1 1
eth1 ist in diesem Fall die Wlan-Karte, mit monitor 1 sagen wir das der Monitor Mode gestartet werden soll
(mit iwpriv eth1 monitor 0 würden wir ihn also wieder beenden) und die letzte 1 gibt den Channel an, in
welchem die Karte gesetzt werden soll.
Ethereal kann nun mit den im Bild angezeitgen Optionen gestartet werden.
Nun würde Ethereal JEDES Datenpaket welches im Channel 1 durch die Gegend fliegt
auffangen und speichern.
Sollte auf dem AccessPoint eine Mac-Adressenfilterung eingerichtet sein, so müssen wir uns um
diese nicht weiter kümmern. Wir versuchen uns ja nicht am AP anzumelden, sondern hören ja einfach
nur zu. Interessant wird es erst, wenn das Netzwerk die Daten verschlüsselt überträgt.
Wir bekommen zwar immer noch alles, können damit aber nichts mehr anfangen.
Es ist aber Möglich WEP-Verschlüsselungen aufzubrechen, den Schlüssel zu errechnen.
AirSnort ist ein Programm welches genau das macht. Es kann die Karte in den Monitor-Mode
packen. Wenn vom User gewünscht auch gleich noch in den passenden Channel. Ab diesem Zeitpunkt
sammelt Airsnort die verschlüsselten Packete. Bei einer 128 Bit WEP Verschlüsselung muss es ca.
6 Millionen Pakete sammeln.
Das liegt daran, dass für die WEP Verschlüsselung nur ein begrenzter
Zufallszahlenraum zur Verfühgung steht. Nach ca. 6 Millionen Paketen wiederholen sich in jedem Fall Teile.
Mit diesen kann AirSnort nun rechnen.
Hat AirSnort den Schlüssel erfolgreich errechnet, tragen wir ihn einfach mit iwpriv bei unserer Wlan-Karte
ein und schon kann es weiter gehen!
WEP Verschlüsselungen mit einer Stärke von 256 Bit sind im Vergleich noch sehr sicher. Es würde
eine sehr lange Zeit dauern die notwendigen Pakete zu sammeln. Leider arbeiten kaum Karten mit 256 Bit WEP
Schlüsseln. Es gibt auch eine neue Methode: WPA… WPA gilt bisher als sicher.
Ich stufe mein Wlan immer noch als ein feindliches Netz ein. So behandelt es auch meine Firewall und so sollte es
jeder Admin behandeln. Es ist und bleibt wohl noch über lange Zeit ein grosses Sicherheitsproblem.
Genauere Fragen zu diesem Thema beantworte ich gerne per E-Mail!
Solltest du Fragen stellen achte bitte darauf deine Frage so genau wie irgend
möglich zu stellen. Beschreibe kurz dein Problem, haue mich nicht mit log und
configs zu und habe etwas Geduld. Ich bekomme nicht nur eine E-Mail am Tag. Darum
werde ich ganz sicher nicht auf unfreundliche und ungenaue Fragen antworten. KEINER
hat ein Recht drauf von mir Support zu bekommen!!