Daten von gelöschter Veracrypt-Partition retten

[nutrix]

Erste Frage, welche SSD ist das genau?

@duabar, kannst Du bitte noch diese Frage beantworten?

 

[BFF]

Wo denn?

https://administrator.de/forum/veracrypt-verschluesselung-festplatte-datenrettung-678906.html

Erste Frage, welche SSD ist das genau?

Das würde mich auch interessieren.

Inhaltlich: Mehr als was ich getan habe kann ich nicht mehr machen, ich denke ich werde das aufgeben.
Nochmal danke an den Teil der Leute die mir hier gute Tipps gegeben haben und mit eigenem Interesse bei der Sache waren.

Also war in der Partition nix Wichtiges. Ok.

Ich verstehe zwar weiterhin nicht wie es sein kann dass ein einziger Fehler die gesamten Daten unbrauchbar macht, aber egal. Erwartet hätte ich höchstens dass eben dann ein Teil davon verloren ist, aber nicht dass ein einziger Fehler irgendwo die gesamte Veracrypt-Partition unleserlich macht.

Dein „Fehler“ war die Schnellformatierung nachdem Du mit „diskpart clean“ die SSD gekillt hast. Eigentlich war das bereits der zweite Fehler. 👻

 

[recu]

Dein „Fehler“ war die Schnellformatierung nachdem Du mit „diskpart clean“ die SSD gekillt hast. Eigentlich war das bereits der zweite Fehler. 👻

Nein, die Schnellformatierung war zwar ein Fehler, aber die Auswirkungen scheinen mir begrenzt.
Die wichtigen Dinge liegen alle vorne, z.B. die MFT der NTFS-Partition. Dass die letzte RAW-Partition in Mitleidenschaft gezogen worden ist, ist unwahrscheinlich, weil die weiter hintenliegt.

Zusatz: 29.9.2026 8:57
Dieser Beitrag ist falsch, weil er zu pauschal ist. Eine Schnellformatierung von SSD hat zerstörerische Folgen, siehe Beitrag unten!

 

[BFF]

Probier es aus für Dich @recu

Was da gewesen ist beim TE sammelst Du über den Thread.

Ohne die Schnellformatierung gelange ich hier weitaus besser an die originale Partitionierung als mit. Und mit den originalen Partitionen bekomme ich auch das per Veracrypt verhackstückelte zurück.

Egal. TE hat aufgegeben.

 

[TorenAltair]

Dass die letzte RAW-Partition in Mitleidenschaft gezogen worden ist, ist unwahrscheinlich, weil die weiter hintenliegt.

Bei einer SSD gibt es kein vorne oder hinten. Bei SSDs ist es eine rein logische Verteilung.

 

[nutrix]

Ohne die Schnellformatierung gelange ich hier weitaus besser an die originale Partitionierung als mit.

Nein, die Schnellformatierung war zwar ein Fehler, aber die Auswirkungen scheinen mir begrenzt.

Wenn ich einige Quellen studiere und dazu noch eine gekaufte KI befrage, erhalte ich diese Antwort:

• Kritisch: Windows führt bei einem Quick Format auf SSDs standardmäßig ein synchrones TRIM über den gesamten adressierten Partitionsbereich aus.

Sobald Windows ein Dateisystem auf einem Solid-State-Medium formatiert (über die GUI, format.com oder PowerShell Format-Volume), prüft das System über IOCTL_STORAGE_QUERY_PROPERTY, ob der Datenträger TRIM bzw. Deallocate unterstützt.

Ist TRIM aktiv (DisableDeleteNotify = 0 in fsutil), sendet der Formatier-Prozess während der Initialisierung des Volumes einen I/O-Control-Befehl an den Storage-Stack:

• Control Code: IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES
• Action: DeviceDsmAction_Trim (Wert 1)
• Übergebener Bereich (DEVICE_DATA_SET_RANGE): Der gesamte LBA-Bereich der formatierten Partition.

Der Storage-Klassentreiber (partmgr.sys / disk.sys / storport.sys) transformiert diesen Request in das jeweilige Protokollkommando:

• Bei NVMe: Ein Dataset Management Command mit gesetztem Deallocate-Bit (0x04).
• Bei SATA/AHCI: Ein DATA SET MANAGEMENT-Kommando mit gesetztem TRIM-Bit.
• Bei SCSI/SAS: Ein UNMAP (0x42)-Kommando.

Dieser Befehl wird synchron während des Formatierens abgesetzt, nicht erst Tage später durch die Aufgabenplanung (defrag.exe / Re-TRIM). Das ist auch der Grund, warum ein Quick Format auf einer SSD bei sehr langsamen oder fehlerhaften Controllern manchmal einige Sekunden "hängt": Windows wartet auf den Abschluss des DSM/Trim-IOCTLs.

Die wichtigen Dinge liegen alle vorne, z.B. die MFT der NTFS-Partition. Dass die letzte RAW-Partition in Mitleidenschaft gezogen worden ist, ist unwahrscheinlich, weil die weiter hintenliegt.

Wie kommst Du auf die Idee, daß es bei einer SSD/NVMe sowas wie "vorne" und "hinten" noch gibt? SSDs verhalten sich hier doch ganz anderes als HDDs mit sequentiellem Lesen und schreiben auf einer Magnetspur einer drehenden Scheibe.

Und mit den originalen Partitionen bekomme ich auch das per Veracrypt verhackstückelte zurück.

Der große Irrtum ist hier auch wieder, daß keiner weiß, was weiter beim Controller in der SSD/NVMe passiert. Es ist den meisten hier nicht bewußt, daß die heutigen Controller im Prinzip wie kleine Minicomputer autark arbeiten können, um den Zugriff der NAND-Zellen so zu optimieren, so daß möglichst wenig Verschleiß entsteht. Sprich, sobald vom OS ein Kommando für Partitionslöschen an den Controller geschickt wurde, fängt der im Hintergrund, solange er Strom hat, alles zu bereinigen, ohne daß der normale Benutzer irgendwas mitbekommt oder sogar dagegen machen könnte. Auch hier war die KI wieder sehr erhellend:

Was der Controller bei einem TRIM/Deallocate-Befehl macht​

1. Löscht der Controller die Zellen sofort physisch? Nein. Flash-Speicher kann nur in Blöcken (mehrere MB) gelöscht werden. Ein physisches Löschen (Erase Cycle) ist langsam und verschleißt das NAND. Der Controller belässt die Datenbits zunächst physikalisch unverändert in den NAND-Zellen.
2. Was passiert mit dem FTL? Der Controller löscht den Eintrag in der FTL-Mapping-Tabelle. Die Zuordnung LBA -> PBA wird verworfen; der LBA wird als "ungemappt" (unallocated) markiert.
3. Was liefert ein Lesezugriff (Read)? Nahezu alle modernen SSDs implementieren DZAT (Deterministic Read Zero after TRIM) oder RZAT (Read Zero after TRIM). Fragt ein Recovery-Tool nun über Standard-OS-Treiber LBA X an, schaut der Controller in die FTL-Tabelle, sieht "ungemappt" und gibt sofort Nullen (0x00) zurück, ohne die NAND-Zellen überhaupt elektrisch auszulesen.
4. Garbage Collection (GC): Im Leerlauf (Idle) beginnt die Firmware im Hintergrund mit der Bereinigung. Sie konsolidiert noch gültige Datenblöcke und löscht Blöcke mit getrimmten (ungültigen) Daten physisch per Block-Erase.

Und

• Technischer FTL-Bypass (Professionelles Datenrettungslabor):Hardware-Systeme wie PC-3000 Flash / PC-3000 NVMe (Ace Laboratory) schalten den Controller über Testpunkte in den Techno-Mode / Safe-Mode (Vendor Commands). Dadurch wird die interne Firmware umgangen und der Raw-NAND direkt über den Controller ausgelesen. Anschließend wird die FTL-Tabelle im RAM des Datenrettungs-PCs virtuell aus den Metadaten der Flash-Pages rekonstruiert.
• Voraussetzung: Der Controller-Typ und die Firmware müssen von Spezialwerkzeugen unterstützt werden (bei vielen Phison-, Silicon Motion- oder Marvell-Controllern machbar; bei modernen, proprietären Samsung- oder WD-Controllern oft extrem schwierig oder unmöglich).

A. Microsoft Learn / Windows Driver Kit (WDK)​

Die internen Schnittstellen für diesen Vorgang sind in der Windows-Treiber-Dokumentation beschrieben:

• Dokumentation zu DSM (Data Set Management):
  
  Suche nach IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES und DeviceDsmAction_Trim auf Microsoft Learn. Hier wird dokumentiert, wie Windows Bereiche als freigegeben deklariert.
• Dokumentation zu fsutil behavior:
  
  Unter fsutil behavior set DisableDeleteNotify beschreibt Microsoft offiziell das Verhalten: „Delete notifications (also known as trim or unmap) is a feature that notifies the underlying storage device of clusters that have been freed due to a file delete operation [or format operations].“

B. Forensische Forschung & Whitepapers (Digital Forensics)​

Im Bereich der IT-Forensik ist dieses Phänomen Gegenstand zahlreicher Analysen, da SSDs im Gegensatz zu klassischen HDDs nach einem Quick Format meist keine verwertbaren Spuren mehr liefern:

• The TRIM Effect on File Recovery (diverse Arbeiten):
  
  • Bell, G. B., & Boddington, R.: "Solid State Drives: The Forensic Challenge" (beschreibt den Verlust von Carving-Artefakten nach Formatierung unter Windows 7/8/10/11).
  • Gubanov, Y. & Afonin, O. (Belkasoft / ElcomSoft): Artikelreihe „Life after TRIM: Using SSD Forensic Techniques“ sowie ihr Buch Mobile and Solid-State Storage Forensics. Belkasoft zeigt experimentell mit Hex-Analysen, dass ein Windows-Quick-Format die LBA-Ränge sofort leert (Nullen zurückliefert), selbst wenn davor Gigabyte an Nutzdaten lagen.
• DFIR Training / SANS Institute:
  
  In Forensik-Kursen (z. B. SANS FOR500: Windows Forensic Analysis) wird explizit gelehrt: Ein Quick Format unter Windows mit aktivem TRIM entspricht de facto einem sofortigen logischen Wipen der LBA-Tabelle via RZAT/DZAT.

C. OSR Online & Windows Kernel Dev Foren (NTDEV)​

• In Entwickler-Foren für Windows-Dateisystem- und Filtertreiber (community.osr.com) taucht diese Frage regelmäßig auf, wenn Entwickler virtuelle Disktreiber implementieren.
• Wenn ein virtueller Blocktreiber IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES unterstützt, loggt er beim Ausführen von format X: /Q sofort den Aufruf von DeviceDsmAction_Trim für den gesamten Cluster-Bereich des Datenträgers.

Ich sehe eine Chance.

Wenn ich das da oben genau lese, ist dem mitnichten so, nach Quick Format keine Chance mehr.

Könntest Du noch sagen, unter welchem Betriebssystem Du die Partition gelöscht hast?
Was sagt der Befehl "fsutil behavior query DisableDeleteNotify"
wenn Du in auf dem Löschcomputer
in einer Eingabeaufforderung ("DOS-Box") mit Admin-Rechten ausführst?

Da hier anscheinend direkt beim Quickformat explizit TRIM mitgegeben wird, geht dann über die Schnittstellen direkt ein Befehl an die Controller, der Controller löscht den Eintrag in der FTL-Mapping-Tabelle. Die Zuordnung LBA -> PBA wird verworfen; der LBA wird als "ungemappt" (unallocated) markiert. Laut den Infos oben hast Du dann ohne entsprechende professionelle Tools bei Datenrettern, die den Technischer FTL-Bypass beherrschen, keine Chance mehr.

Wie ich es anfangs sagte, Dreh und Angelpunkt ist der Controller der SSD. Solange wir weder die SSD kennen, noch der TS genauer sagt, ob die SSD per SATA, NVMe, USB über Controllerchip angebunden wurde (wo bei USB ein Hauch einer Change bestehen würde, wenn der USB-Brigdechip den TRIM abfängt), sind diese Ratschläge auch wenig hilfreich.

Ergänzung (28. September 2026)

1. wichtig: SSD nicht mehr anstecken

2. Ein Datenrettungsunternehmen kontaktieren wie ontrack

Das ist dann an der Stelle die einzige sinnvolle Maßnahme. Sofort vom Strom trennen, nicht mehr selbst damit irgend etwas machen, an einen Datenretter schicken.

Auch das nachträgliche blockweise Sichern ist an sich sinnlos, weil der Controller, solange er Strom hat, im Hintergrund mit GC weiterarbeiten wird.

 

[BFF]

Sofort vom Strom trennen, nicht mehr selbst damit irgend etwas machen, an einen Datenretter schicken.

Das duerfte sich mittlerweile wohl erledigt haben beim TE. Jedenfalls wenn ich #29 ueberfliege.

 

[nutrix]

Anhand der Doku kann ich jetzt auch nur noch ernüchtert das Fazit ziehen, daß mit unseren "Spielzeugprogrammen" in so einem Fall kaum was rettbar ist, und man bei SSDs als Hobbyforensiker verloren hat.

Gut war jetzt daran, daß nun detaillierter gute Infos vorliegen. In Zukunft erübrigt sich für diesen Fall jede weitere Diskussion und brauchen nicht 50 Beiträge mehr, oder?

 

[BFF]

In Zukunft erübrigt sich für diesen Fall jede weitere Diskussion

Es eruebrigt sich die Diskussion wenn es um eine per Veracrypt verschluesselte Partition geht.
Von den beiden Anderen aka den Ventoy-Krams hole ich hier immer noch die Dateien. Selbst nach der Schnellformatierung. Vermutlich weil ich andere Hardware (mx500 mit USB3-SATA) genutzt habe.

Aber im Endeffekt hast Du recht.
Man muss sehr genau schauen was ueberhaupt passiert ist und welche reale Hardware darunter ist.
Das zu erfahren ist allein schon richtig kompliziert.

daß mit unseren "Spielzeugprogrammen"

So Spielzeug sind DMDE, R-Studio und in meinem Fall auch Autopsy nicht. Das ist eigentlich schon fast gehobene Klasse gegenueber dem was Ontrak z.B. selbst bereitstellt. 😁

Ich bin, wenn es um verschluesselte Datentraeger geht, immer auf der Seite das es nicht gewollt ist da wieder ran zu kommen. Voellig egal welches Produkt man nutzt um zu vercrypten. Fuer mich war es einen Versuch wert. Rein um die Lernkurve steil zu halten in meinem Alter. Die Lernkurve derer die am Ende keine Daten mehr haben wird noch steiler sein vermutlich wenn das Verschluesselte der einzige Ort war.

Anyway.
Ich hab gerade eine niedliche HDD mit "Datenbrei" vor mir, worauf sich ein paar RTF-Dokumente befinden sollen welche extrem wichtig sind. HDD vom verstorbenen Opa, welcher selbst seiner Frau nicht erzaehlte was er da so am Computer tat. Niedlich kleine IDE HDD aus einem ollen DELL 9400 17" aus 2006. Und Opa hat damals ein Mandrake Linux benutzt. Ich liebe sowas, zumal die HDD anstandslos funktioniert am Adapter. Image wird gerade gemacht und uebermorgen kann dann Autopsy ueber das Image drueber herfallen. 😁

 

[duabar]

@duabar, kannst Du bitte noch diese Frage beantworten?

Fanxiang S109

Also war in der Partition nix Wichtiges. Ok.

Jein. Es war ein Videoarchiv mit über Jahre hinweg aus den Mediatheken heruntergeladenen und mühevoll sortierten Filmen. Also nichts lebenswichtiges oder wofür ich jetzt >500 € für (am Ende wohl ebenso erfolglose) Datenrettung ausgeben möchte. Aber ärgerlich ist es wegen der reingesteckten Zeit und weil das nicht mal so auf die Schnelle wiederaufbaubar ist schon.

Wie kommst Du auf die Idee, daß es bei einer SSD/NVMe sowas wie "vorne" und "hinten" noch gibt? SSDs verhalten sich hier doch ganz anderes als HDDs mit sequentiellem Lesen und schreiben auf einer Magnetspur einer drehenden Scheibe.

Der große Irrtum ist hier auch wieder, daß keiner weiß, was weiter beim Controller in der SSD/NVMe passiert. Es ist den meisten hier nicht bewußt, daß die heutigen Controller im Prinzip wie kleine Minicomputer autark arbeiten können, um den Zugriff der NAND-Zellen so zu optimieren, so daß möglichst wenig Verschleiß entsteht. Sprich, sobald vom OS ein Kommando für Partitionslöschen an den Controller geschickt wurde, fängt der im Hintergrund, solange er Strom hat, alles zu bereinigen, ohne daß der normale Benutzer irgendwas mitbekommt oder sogar dagegen machen könnte.

Ich bin etwas skeptisch vor der KI, weil ich es damit auch probiert hatte und da ziemlich viel Bullshit dabei war.
Aber trotzdem ist das auch mein Gefühl, dass da zumindest ein Teil der Daten zwar nicht mit Nullen, aber mit irgendetwas anderem überschrieben und/oder neu zugeordnet wurde.

Weiterhin verstehe ich trotzdem nicht warum Veracrypt da keine zugreifbare Partition mehr "daraus macht". Nach meinem Verständnis hätte ich eigentlich erwartet dass dann eben nur teilweise Daten fehlen, aber nicht dass nur weil ein Teil beschädigt ist dann quasi alles Müll/offensichtlich nicht mehr entschlüsselbar ist.

 

[recu]

Bei einer SSD gibt es kein vorne oder hinten. Bei SSDs ist es eine rein logische Verteilung.

Du verwechselt die Ebene des SSD-Controllers mit der Ebene des "Storage-Treibers" von Windows. Der arbeitet mit Sektornummern. Darüber ist dann die Ebene des Dateisystems.

Wenn ich jetzt von vorne und hinten spreche, beziehe ich mich auf die Ebene des "Storage-Treibers", der die Sektoren anspricht. Und da gibt es eine Ordnung von 0 bis n-1.

 

[BFF]

Ich bin etwas skeptisch vor der KI

Das von @nutrix war garnicht an Dich gerichtet. 😉

Weiterhin verstehe ich trotzdem nicht warum Veracrypt da keine zugreifbare Partition mehr "daraus macht". Nach meinem Verständnis hätte ich eigentlich erwartet dass dann eben nur teilweise Daten fehlen

Wenn Du es nicht schaffst die Partitionierung vor der Schnellformatierung wiederherzustellen wird nur 💩 rauskommen. Gerade dann wenn der Bereich der ausgelesen werden soll nett verschluesselt ist. Das mit der Schnellformatierung nach dem Diskpart clean so Einiges auch noch neu geschrieben wurde was Partitionen angeht versteht sich.

Das ist auch das was ich weiter oben schon tippte.
Hier bei mir konnte ich eine vollverschluesselte VeraCrypt Partition unter Zuhilfenahme des Headerbackups wieder nutzbar machen nachdem per diskpart clean die SSD behandelt wurde. Ging ueber TestDisk die beiden Ventoy-Partitionen wiederherstellen, dann den restlichen Platz ohne Dateisystem bereitstellen und mit Veracrypt weiter.

Das ist das was ich damals auch bei einem Meeting so hoerte und scheinbar auch kuerzlich hier funktionierte. Das dort andere Dateisysteme vorhanden waren ausserhalb der Veracrypt-Partition lassen wir mal unbeobachtet.

https://forum.endeavouros.com/t/how-to-recover-a-lost-veracrypt-volume/60400/4

Aber! Da ist keine Rede von einer (Schnell)formatierung nach einem Loeschen.

Nach der Schnellformatierung konnte ich zwar noch den Krams von Ventoy auslesen und in Theorie wiederherstellen. An die Partition von Veracrypt war ausser zu sehen das da in Theorie Platz ist kein rankommen.

 

[recu]

Probier es aus für Dich @recu

Test läuft, 240GB SSD wird gerade vollgeschrieben, befindet sich im Microserver Gen7 innen drin.

 

[TorenAltair]

Du verwechselt die Ebene des SSD-Controllers

Und wer löscht die Zellen? Der Controller.

 

[recu]

Test der Schnellformatierung bei einer SSD

Hardware: HP Microserver Gen7 (Variante 54L)
Software: Windows 7 SP1 64bit
Testobjekt: SSD, Typ WD Green 240 GB, intern angeschlossen

Testablauf:
1. WD Green im GPT-Stil mit der Datenträgerverwaltung partitioniert.
2. Eine Partition, die die ganze SSD umfasst, erzeugt und mit NTFS formatiert
3. Partition mit h2testw komplett befüllt
4. visuelle Schnellkontrolle der Befüllung mit HxD
5. Mit der Datenträgerverwaltung eine Schnellformatierung durchgeführt

Befund:
Durchsicht der Festplatte, bzw. Partition mit HxD. Die Partition sieht aus, als hätte sie jemand mit der Schrottflinte beschossen: Es scheinen sich regelmäßig Bereiche mit gelöschten Sektoren mit ungelöschten Sektoren abzuwechseln, wo vorher alles beschrieben war.
Der Runtime Disk Explorer X zeigt diese Bereiche als "invalid" an.

Fazit:
In der obigen Testkonstellation scheint eine Entschlüsselung nicht mehr möglich zu sein.

Ergänzung (29. September 2026)

Und wer löscht die Zellen? Der Controller.

Was hat das mit der Reihenfolge der Sektoren zu tun?
Entsprechend der Sektornummerierung der SSD gibt es niedrige und hohe Sektornummern. Für den Benutzer bzw. das Betriebssystem ist die interne Abbildung durch die Firmware der SSD auf einen Pool von Flashzellen irrelevant.
Eine Formatierung betrifft vor allem die niedrigen Hausnummern. Hinten passiert nicht viel.
Wenn also ein Datenträger z.B. drei gleichgroße Partitionen enthält, die gelöscht werden und stattdessen eine große Partition erzeugt und mit NTFS schnellformatiert wird, dann überschreibt ein Windows-Betriebssystem überwiegend den Anfang dieser Partition (niedrige Sektornummern).

 

[nutrix]

Test läuft, 240GB SSD wird gerade vollgeschrieben, befindet sich im Microserver Gen7 innen drin.

Was für eine SSD ist es bitte genau?
Update, nochmal überarbeitet worden, jetzt sehe ich es, danke.

 

[recu]

Wie kommst Du auf die Idee, daß es bei einer SSD/NVMe sowas wie "vorne" und "hinten" noch gibt? SSDs verhalten sich hier doch ganz anderes als HDDs mit sequentiellem Lesen und schreiben auf einer Magnetspur einer drehenden Scheibe.

Die Sektoren der SSD lassen sich bei einer SSD genauso beschreiben wie bei einer HDD. Nicht beschriebene Sektoren (die mit den hohen Hausnummern) bleiben unverändert. Das führt dazu, dass bei einer HDD eine Schnellformatierung wie im Beispiel des Fragers der hinten liegenden Bereich mit der gelöschten Partition von Schreibvorgängen durch Schnellformatierung kaum betroffen ist.

Bei aktiviertem TRIM aber, wie sich aus Deiner KI-Recherche (vielen Dank für die Veröffentlichung des Ergebnis!) und auch bei meinem Test ergibt, sind geschriebene Inhalte hinten auf dem Datenträger bei einer Schnellformatierung nicht mehr verfügbar, weil neben den Schreibvorgängen für die Neuformatierung auch noch zusätzlich ein oder mehrere TRIM-Befehle für die zu löschenden Bereiche der Partition vom Betriebssystem abgesetzt werden.

Und damit sind auch die Inhalte der "hohen Hausnummern" auf denen das Betriebssystem fast nichts geschrieben hatte, aufgrund des TRIM-Befehls futsch, oder besser gesagt, dem Nutzer, bzw. dem Betriebssytem entzogen, nicht mehr wieder lesbar - es sei denn, die SSD wird stromlos gemacht, so dass ein Datenretter mit der passenden Ausrüstung für den verbauten Controller auf der SSD diese Inhalte extrahieren kann, ohne dass der Controller die vorhandene und noch nicht zu Ende bearbeitete "Löschliste" weiter abarbeiten kann.

 

[nutrix]

Weiterhin verstehe ich trotzdem nicht warum Veracrypt da keine zugreifbare Partition mehr "daraus macht". Nach meinem Verständnis hätte ich eigentlich erwartet dass dann eben nur teilweise Daten fehlen, aber nicht dass nur weil ein Teil beschädigt ist dann quasi alles Müll/offensichtlich nicht mehr entschlüsselbar ist.

Nochmals, sobald der Controller vom OS durch Quickformat das go erhält, fängt dieser selbstständig per Garbage Collector an, die betroffenen Zellen zu "löschen", siehe oben Punkt 4 bei Was der Controller bei einem TRIM/Deallocate-Befehl macht. Je nach Geschwindigkeit und Auslastung braucht der Controller eine Weile dafür, und wenn Du in dem Moment mit einem Datenrettungstool versuchst, alle Datenfragmente zu ermitteln, die noch vorhanden sind, kann es durchaus sein, daß diesem Programm im Hintergrund die Datenblöcke markiert, und dann dieser Müll mit unvollständigen Dateien entsteht.

Ergänzung (29. September 2026)

Was hat das mit der Reihenfolge der Sektoren zu tun?

Es gibt bei SSDs keine Sektoren mehr, verabschiede Dich bitte davon. SSD haben Flash-Speicherzellen, die in Seiten (Pages) und Blöcke (Blocks) eingeteilt sind. Die Sektoren gibt es nur noch simuliert, damit das Dateisytem von Windows funktioniert.

Entsprechend der Sektornummerierung der SSD gibt es niedrige und hohe Sektornummern. Für den Benutzer bzw. das Betriebssystem ist die interne Abbildung durch die Firmware der SSD auf einen Pool von Flashzellen irrelevant.
Eine Formatierung betrifft vor allem die niedrigen Hausnummern. Hinten passiert nicht viel.
Wenn also ein Datenträger z.B. drei gleichgroße Partitionen enthält, die gelöscht werden und stattdessen eine große Partition erzeugt und mit NTFS schnellformatiert wird, dann überschreibt ein Windows-Betriebssystem überwiegend den Anfang dieser Partition (niedrige Sektornummern).

Dann hast Du die obige Beschreibung von mir nicht genau durchgelesen, dort wird doch genau erklärt, daß nicht so vorgegangen wird, wie Du das hier denkst.

 

[recu]

Es gibt bei SSDs keine Sektoren mehr, verabschiede Dich bitte davon. SSD haben Flash-Speicherzellen, die in Seiten (Pages) und Blöcke (Blocks) eingeteilt sind. Die Sektoren gibt es nur noch simuliert, damit das Dateisytem von Windows funktioniert.

Habe ich irgendwo das Gegenteil behauptet?

 

[nutrix]

Ja, hier:

Die Sektoren der SSD lassen sich bei einer SSD genauso beschreiben wie bei einer HDD.

Und das stimmt so nicht.