Daten von gelöschter Veracrypt-Partition retten

[recu]

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)

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.

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.

Vielleicht solltest Du meinen Beitrag zu Ende lesen? Bitte zitiere nicht reportermäßig Ausschnitte, die meine Aussage komplett umkehren. Danke!

Ergänzung (29. September 2026)

Ja, hier:

Und das stimmt so nicht.

Ich habe es doch oben erklärt:

Von unten nach oben:

1. Firmware der HDD oder SSD -> unterste Ebene
2. HDD oder SSD auf Interface-Ebene -> Sektor-Darstellung
3. Dateisystem -> Darstellung von Ordnern und Dateien

Du schmeißt die Ebenen durcheinander.

Analoges Beispiel bei HDD mit Advanced Sektor Format und Emulation von herkömmlichen Sektoren mit 512 Bytes:

1. Firmware -> physische Sektoren mit 4096 Bytes Nutzlast
2. Festplattenschnittstelle -> logische (emulierte!) Sektoren mit 512 Byte Größe
3. Dateisystem -> Darstellung von Ordnern und Dateien

Wenn die Festplatte in einem externen USB-Gehäuse steckt und größer als 2 TB ist, dann kommt auch gerne noch ein Punkt dazu:

1. Firmware -> physische Sektoren mit 4096 Bytes Nutzlast
2. a) Festplattenschnittstelle -> logische (emulierte!) Sektoren mit 512 Byte Größe
2. b) Emulation von großen Sektoren durch Zusatzelektronik -> 4096 Byte (an der USB-Schnittstelle)
3. Dateisystem -> Darstellung von Ordnern und Dateien

Für das Betriebssystem ist ein Sektor die kleinste Einheit, die es lesen oder schreiben kann, egal ob HDD oder SSD. Und die sind geordnet. Der (legacy) MBR befindet sich immer in Sektor Null.
Wird z.B. ein FAT32-Dateisystem geschrieben, dann beginnt das mit einem Bootsektor, gefolgt von den beiden FATs und dem Wurzelverzeichnis, danach wird kein weiterer Sektor mit hoher Sektornummer angefasst (weiß nicht, ob FAT32 einen Backup-Sektor hat, der irgendwie hinten steht).
Das ist die Betriebssystem-Ebene!

 

[nutrix]

Vielleicht solltest Du meinen Beitrag zu Ende lesen?

Du hast mich zitiert, ich weiß jetzt nicht, was Du von mir willst.

Ich habe es doch oben erklärt:

Erstens brauchst Du mir das nicht erklären, ich bin schon lange genug dabei, ich kenne das alles bereits, sogar seit RLL und MFM aus den 80ern. Ungefragt brauche ich hier keinen Erklärbär mit Dingen, die ich schon weiß.
Zweitens Deine Erklärungen sind irrelevant und hier OT, besonders mit HDDs und 2TB und bla. Aktualisiere Dein Wissen bzgl. SSDs, da läuft das alles anders.
Drittens lagst Du mit vielen Deiner Thesen einfach falsch.

Bitte erspare Dir jetzt weitere Erläuterungen mit HDDs, die keinen hier weiter interessieren, und die OT sind, Wir sind bei SSDs, und das Thema ist erledigt. Du mußt Dich jetzt nicht weiter mit Pseudowissen hier aufspulen.

 

[Evil E-Lex]

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.

Auch wenn das Thema erledigt ist, interessiert es mich doch: Ist irgendwo dokumentiert, dass bei diskpart clean der TRIM-Befehl abgesetzt wird? Bei meinen Tests werden die ersten und letzten 1 MiB des Datenträgers genullt, der Rest bleibt lesbar. Auch nach Stunden.

 

[nutrix]

Man findet dazu in der offiziellen Dokumentation und anderweitig im Netz nichts weiter:
https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/clean

• Auf MBR-Datenträgern (Master Boot Record) werden nur die MBR-Partitionierungsinformationen und Informationen zu verborgenen Sektoren überschrieben.
• Auf GPT-Datenträgern (GUID Partition Table) werden die GPT-Partitionierungsinformationen überschrieben, einschließlich des Schutz-MBRs. Es gibt keine Informationen zu verborgenen Sektoren.

Das heißt, diskpart clean sendet kein TRIM, so wie es bei Quickformat passiert. Ja, damit würde ich Dir zustimmen, passiert hier alleine erst mal nichts weiter auf einer SSD, die hintern Sektoren des Dateisystems (da gibts ja noch Sektoren, bevor jetzt wieder seltsame Einwände kommen.) bleiben anscheinend erhalten.

Im Endeffekt bedeutet es, daß ein diskpart clean kein sicheres Löschen darstellt, und die Gefahr, daß jemand die SSD nach dem Verkauf oder Weitergabe auslesen kann, noch gegeben ist. Sicher wäre nur ein diskpart clean all, wo man die SSD unnötig überschreibt, oder danach einfach die SSD nochmal formatieren, so daß IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES laufen kann. Hier dann aber auch die Frage, was passiert beim Quickformat, wenn man DisableDeleteNotify (arbeitet auf Dateisystemebene) explizit ausschaltet und auf 1 setzt?

fsutil behavior set DisableDeleteNotify 1

https://kb.plugable.com/data-storage/trim-an-ssd-in-windows-10
https://www.computerwoche.de/article/2858848/abfrage-auf-aktiviertes-ssd-trim.html

Meiner Meinung nach sollte dann auch noch die Daten dann zugreifbar auf der SSD liegen.

Update:
Ja, dem ist wirklich so. Ich habe es gerade mit einer Samsung 860 Evo getestet:

Auf Computer: SERVER

DISKPART> list disk

  Datenträger ###  Status         Größe    Frei     Dyn  GPT
  ---------------  -------------  -------  -------  ---  ---
  Datenträger 0    Online           XX TB  1024 KB        *
  :
  Datenträger 2    Online          931 GB  1024 KB        *

DISKPART> select disk 2

Datenträger 2 ist jetzt der gewählte Datenträger.

DISKPART> clean

Der Datenträger wurde bereinigt.

Danach

PS C:\Users\nutrix> fsutil behavior query DisableDeleteNotify
NTFS DisableDeleteNotify = 0  (TRIM-Vorgänge dürfen an Speichergeräte gesendet werden)
ReFS DisableDeleteNotify = 0  (TRIM-Vorgänge dürfen an Speichergeräte gesendet werden)
PS C:\Users\nutrix> fsutil behavior set DisableDeleteNotify 1
NTFS DisableDeleteNotify = 1  (TRIM-Vorgänge dürfen nicht an Speichergeräte gesendet werden)

Dieser Vorgang wird sofort wirksam (kein Neustart erforderlich)
PS C:\Users\nutrix> fsutil behavior query DisableDeleteNotify
NTFS DisableDeleteNotify = 1  (TRIM-Vorgänge dürfen nicht an Speichergeräte gesendet werden)
ReFS DisableDeleteNotify = 0  (TRIM-Vorgänge dürfen an Speichergeräte gesendet werden)

Und ich kann mit EaseUS Data Recovery Wizard Professional 20.8.0 wieder die Daten herstellen. Übrigens hatte ich vor einigen Jahren mal einen Service Request bei EaseUS erstellt, warum man hier nur in ein Image sichern, aber nicht davon recovern kann. Das haben sie mittlerweile tatsächlich eingebaut. 👍

 

[Evil E-Lex]

Im Endeffekt bedeutet es, daß ein diskpart clean kein sicheres Löschen darstellt, und die Gefahr, daß jemand die SSD nach dem Verkauf oder Weitergabe auslesen kann, noch gegeben ist.

So kenne ich das auch. Wobei ich bei meinen Tests noch eine andere Feststellung gemacht hab: Ich hab den Datenträger komplett mit Zufallsdaten vollgeschrieben (um eine Festplattenverschlüsselung wie VeraCrypt zu simulieren "VeraCrypt volumes have no "signature" or ID strings. Until decrypted, they appear to consist solely of random data.") und die dann mit diskpart clean bearbeitet. Ergebnis war, es ist schlicht nichts passiert. Die ersten und letzten 1 MiB waren weiter vorhanden. Erst nachdem ich per diskpart mittels convert gpt eine GPT-Partitionstabelle auf dem Datenträger erstellt hab, hat diskpart clean wie erwartet funktioniert.

Da stellt sich mir die Frage, ob diskpart auf Datenträgern ohne erkennbare Partitionsstruktur überhaupt arbeitet, oder in der Annahme es befände sich ohnehin keine sinnvolle Partitionsstruktur auf dem Datenträger schlicht nichts macht.

 

[BFF]

diskpart ist ein MS Produkt.
Das es nichts ausser Eigenes kann ist doch bekannt. Irgendwie.
https://www.computerbase.de/forum/t...ren-von-usb-sticks-eigentlich-so-rum.1957633/
Und dann noch USB anders behandelt als man vermutet. 🤷🏼‍♂️

 

[Evil E-Lex]

Ich hab jetzt nochmal ein bisschen weiter getestet:
Ich hab die SSD mit Veracrypt verschlüsselt und danach diskpart clean ausgeführt. Auch in diesem Fall wird nichts gelöscht, da keine Partitionsstrukturen vorhanden sind, die diskpart löschen könnte. Hat man also diesen Fall und bemerkt hier, dass man den falschen Datenträger bearbeitet, hat man Glück gehabt. Man kann den Datenträger normal in Veracrypt einbinden.
Geht man jetzt einen Schritt weiter und initialisiert den Datenträger über die Datenträgerverwaltung oder convert gpt in diskpart, wird eine leere GPT geschrieben. Das überschreibt den Veracrypt Header. Da mag eine Datenrettung noch möglich sein, hab ich aber nicht ausprobiert.
Geht man jetzt noch weiter und erstellt eine neue Partition per Schnellformatierung, wird für den Bereich der Partition TRIM ausgeführt. Alle Daten, die in diesem Bereich lagen, sind verloren, da der SSD-Controller nur noch Nullbytes zurückliefert.

 

[nutrix]

Ich teste gerade den neuen Paragon Festplattenmanager 18 Advanced. Der hat tatsächlich jetzt beim Löschen auch die Funktion SSD Trim drinnen:

 

[Evil E-Lex]

Es ist gut zu sehen, dass die Softwareentwickler so langsam dahinter kommen, dass SSDs speziell behandelt werden wollen.

Ich kann in diesem Zusammenhang nwipe (Nachfolger von DBAN) empfehlen. Das unterstützt seit dem neuesten Release 0.43 von vor drei Tagen die sichere Löschung von SSDs:

We are excited to announce a major milestone in nwipe's data destruction capabilities: the long-awaited hardware sanitise feature.

As storage technology has evolved, traditional software-based overwriting has become less effective on modern flash memory due to wear-levelling algorithms and over-provisioning. With this release, nwipe introduces native support for hardware-level Sanitise commands, achieving a true "Purge" level of data destruction as defined by the NIST 800-88 guidelines. This makes nwipe fully equipped to handle modern SSD and NVMe drives securely and efficiently.

Die kompletten Release Notes hier, sind sehr interessant.

 

[nutrix]

Aber die überschreiben tatsächlich wieder komplett die SSD, was sie mehr belastet. Sie schreiben auch, daß sie das ATA Secure Erase hier nicht verwenden. Bei Samsung Laufwerken weiß ich, daß sie bei ATA Secure Erase den Schlüssel tauschen, und damit ein Cryptographic Erase (CE) vorliegt. Bei vielen anderen Laufwerken scheint das nicht zu sein:
https://www.thomas-krenn.com/de/wiki/SSD_Secure_Erase

Bei neueren SSDs mit integrierter Verschlüsselung kann Secure Erase allerdings anders implementiert sein. Solche SSDs verschlüsseln automatisch alle Daten die geschrieben werden. Bei einem Secure Erase würde es dann ausreichen den Schlüssel sicher zu löschen - die Daten könnten damit nicht mehr entschlüsselt werden, wären aber noch physisch vorhanden.[1] Auf Anfrage teilte uns Tahmid Rahman (Intel Senior Technical Marketing Engineer) am Ende der Session Optimizing Solid-State Drive (SSD) Performance for Data Center Applications am Intel Developer Forum 2011 mit, dass die Intel 320 Series SSDs und Intel 710 Series SSDs mit integrierter Verschlüsselung trotz dieser Möglichkeit nur den Schlüssel zu löschen weiterhin auch die Flash Blöcke löschen. Hauptgrund ist, dass ein Secure Erase auch bei diesen SSDs weiterhin die Performance wieder in den Ausgangszustand bringen soll. Anders ist das Verhalten beispielsweise bei Sandisk, wo ein Secure Erase nicht alle Daten löscht.[2]

Bei anderen SSDs mit integrierter Verschlüsselung, bei denen das Verhalten bei einem Secure Erase nicht ausreichend dokumentiert ist, empfiehlt es sich zusätzlich zu einem Secure Erase die Blöcke der SSD per Trim zu löschen, um für die neue Verwendung der SSD die optimale Performance zu bekommen. Windows 7 führt ein solches TRIM bei der Formatierung automatisch durch, ebenso Ext4 ab mke2fs 1.41.10 und XFS ab xfsprogs 3.1.0.

 

[Evil E-Lex]

Sie schreiben auch, daß sie das ATA Secure Erase hier nicht verwenden.

Ja, weil es laut deren Ausführungen eine Technologie für alte Datenträger vor 2012 ist. ATA Secure Erase wurde danach von ATA Sanitize abgelöst. Es gibt also kein "entweder/oder" sondern ein "stattdessen".

Bei meinen Tests dauerte Sanitize ein paar Sekunden, vollständig überschreiben geht da also schon zeitlich nicht. Außerdem:

Writing a full PRNG pass consumes 1 Drive Write (1 DW) (1 complete fill of the drive) of NAND endurance. For modern consumer SSDs, typically rated for 300–600 TBW (Terabytes Written) and enterprise SSDs (rated for 1–3+ DWPD (Drive Writes Per Day) over 5 years), a single diagnostic/erasure pass consumes a negligible fraction of total drive lifespan while providing high confidence in drive health.

 

[mchawk777]

Ist irgendwo dokumentiert, dass bei diskpart clean der TRIM-Befehl abgesetzt wird?

Ist in sofern ein wenig müßig, da SSD-Controller auch unabhängig von einen TRIM-Befehl eine Garbage Collection durchführen.
Die Frage ist nie "ob" - nur "wann".
Das Verhalten von SSD-Controller sind halt eine Blackbox.
Es ist ein Unsicherheitsfaktor - und man muss selbst entscheiden, ob und welche Kausalkette man unbeeinflusst lässt. 😉

 

[Evil E-Lex]

Ist in sofern ein wenig müßig, da SSD-Controller auch unabhängig von einen TRIM-Befehl eine Garbage Collection durchführen.

Dass der SSD-Controller unabhängig von TRIM Garbage Collection betreibt, beantwortet die Frage nicht. Ohne TRIM/Deallocate weiß der Controller nicht, dass die durch diskpart clean oder, wie ich mittlerweile weiß, durch Schnellformatierung logisch freigewordenen LBAs nicht mehr benötigt werden. Bei der Garbage Collection müsste er diese weiterhin als gültig behandeln.

Oder kurz: Ohne TRIM keine GC.

 

[mchawk777]

Dass der SSD-Controller unabhängig von TRIM Garbage Collection betreibt, beantwortet die Frage nicht.

Nein - es macht Deine Frage zumindest für mich nur obsolet.
Wenn man eine SSD wirklich löschen will, dann sollte man SmartErase nutzen.

Wenn man eine Datenrettung versucht - vor allem mit VeraCrypt-verschlüsselten Laufwerken setzt man sich dem Zufall aus.
Es kann sein, dass eine Garbage Collection erst stattfindet, wenn man die Speicherzellen voll laufen - es kann aber auch deutlich schneller gehen - oder überhaupt nie.
Deine Erfahrung dieser einen SSD sind ja valide - aber keinesfalls generell übertragbar.

...und wer VeraCrypt ohne Backups verwendet fordert endgültigen Datenverlust regelrecht heraus. 🤷‍♂️

 

[Evil E-Lex]

Nein - es macht Deine Frage zumindest für mich nur obsolet.
Wenn man eine SSD wirklich löschen will, dann sollte man SmartErase nutzen.

Meine Frage zielte aber nicht auf die Löschung ab, sondern auf die Funktionsweise von diskpart.

Unabhängig davon wird die GC niemals in die logische Struktur der Daten eingreifen, das wäre fatal.

 

[BFF]

sondern auf die Funktionsweise von diskpart.

Und die, ist fuer mich, kaum mehr sicher nachvollziehbar wenn es nur um "clean" geht.
Zumindest wenn es um USB-Datentraeger angeht welche vollumfaenglich TRIM unterstuetzen.

Am Ende auch fast egal, wenn man sich nicht um vorhandene Daten kuemmern muss sondern einfach eine Neupartitionierung macht so wie der TE dieses Threads.
Ich hab das fuer mich mit meinen Mitteln mehrfach versucht nachzustellen und lande am Ende an der Stelle das von der Veracrypt verschluesselten Partition ausser Muell nichts mehr da ist wenn eine Neupartitionierung mit diskmgt in's Spiel kommt. Den Ventoy-Krams kann ich definitiv trotz Neupartitionierung per diskmgt wieder herstellen.

 

[Evil E-Lex]

Und die, ist fuer mich, kaum mehr sicher nachvollziehbar wenn es nur um "clean" geht.

Exakt das ist die Erkenntnis die ich daraus mitnehme. Ich ging bislang davon aus, dass diskpart bei "clean" immer den logischen Anfang und Ende des Datenträgers mit Nullen überschreibt, unabhängig davon, ob sich auf dem Datenträger tatsächlich eine Partitionstabelle befindet. Nach meinen - zugegeben, eher kurzen - Tests, scheint dies nicht der Fall zu sein.

 

[BFF]

Leg doch einfach mal eine Prozedure fest wie man das "sicher" heraus finden koennte fuer das clean von Windows. @Evil E-Lex Mach dazu einfach einen neuen Thread.
Im Rahmen meiner bescheidenen Moeglichkeiten mache ich da mit.

Und warum nicht auch verschiedene Ausgangszustaende nennen und was getan wurde um die Ausgangszustaende zu killen (mit Nennung der entsprechenden Hardware). Als angepinnter Arbeitsthread hier bei CB vielleicht gar keine schlechte Idee.


Muss nur ganz oben dick und Fett in Rot rein, das Veracrypt aussen vor ist. 🤣

 

[mchawk777]

Ich ging bislang davon aus, dass diskpart bei "clean" immer den logischen Anfang und Ende des Datenträgers mit Nullen überschreibt, unabhängig davon, ob sich auf dem Datenträger tatsächlich eine Partitionstabelle befindet.

Wäre wenn nur bei HDDs plausibel.
Bei SSDs bekommt diskpart gar nicht mit wo Anfang und Ende tatsächlich sind. 😉

Aber wie ihr schon sagt:
Bei verschlüsselten Volumen ist die Löschaktion im Prinzip eher akademisch - sofern sichere Passphrasen verwendet werden.

 

[Evil E-Lex]

Wäre wenn nur bei HDDs plausibel.
Bei SSDs bekommt diskpart gar nicht mit wo Anfang und Ende tatsächlich sind. 😉

Und schon wieder dieser Quatsch. Es ist dem Betriebssystem völlig egal, wo die Daten physikalisch liegen, das interessiert sich nur für LBAs. Da ist ist sehr wohl wichtig Anfang und Ende eines Datenträgers zu Überschreiben, wenn man Partitionsinformationen löschen will.