nur genutzte Bereiche einer HDD überschreiben

Wanderdüne

Profi
Thread Starter
Mitglied seit
12.08.2020
Beiträge
173
Hallo,

gibt es eine Lösung, um nur die benutzten Bereiche einer HDD zu überschreiben?

Zum Überschreiben mit Nullen kenne ich nur Varianten, die die gesamte Platte/Partition überschreiben. Für den Fall, dass man eine große HDD hat, auf der wenige Daten sind, ist das ziemlich ineffizient.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Um die gefüllten Sektoren einer Festplatte zu finden, müssen sowieso alle Sektoren gelesen werden. Wieviel Zeit spart man gegenüber einem kompletten Überschreiben ein?
 
Bei einer SMR-Platte ist der Unterschied zwischen Lesen und Schreiben ziemlich groß, zumindest, wenn man verhindern kann, dass sehr viele Daten geschrieben werden.
 
Genutzte Bereiche ist aber nicht gleich belegte Bereiche!
Wenn man eine Datei ändert, wird die Originaldatei i.d.R. als gelöscht markiert und die geänderte Datei an einem anderen Platz auf der Platte gespeichert.

Und wenn man Sektoren durch andere Dateien überschreibt, werden die nicht belegten Bereiche des Sektors nicht mit Nullen aufgefüllt, sondern der alte Inhalt bleibt erhalten.
Dateien füllen ja i.d.R. nicht komplette Sektoren.
Wenn die Sektorgröße z.B. 512 Byte ist, die Datei aber 513 Byte groß ist, so braucht man dafür 2 Sektoren.
Im ersten Sektor werden alle 512 Byte überschrieben, im 2. Sektor dagegen nur das erste Byte. Die restlichen 511 Byte werden nicht mit Nullen aufgefüllt, sondern der Inhalt, der da vorher drin stand, bleibt auch drin.
Das kann man gut mit einem Hexeditor, der die Platten sektorweise auslesen kann, sehen.

Wenn man also z.B. eine Platte mit 1 TB Kapazität hat und auf der sind nur 200 GB belegt, heißt das nicht, das in den übrigen 800 GB nichts oder Nullen drin stehen.
Wenn auf der Platte viel geschrieben wurde, kann es sein, das in den gesamte 800 GB durchaus Daten drin stehen, die aber als gelöscht markiert sind.
Diesen Umstand machen sich z.B. auch Undelete-Programme zu nutze.

Daher macht ein Überschreiben nur der aktuell belegten Bereiche keinen Sinn.
Einzig Sinn macht es, die komplette Platte bzw. Partition zu überschreiben.
 
Eine SMR-Platte habe ich nicht und daher keine Erfahrung damit. Aber ich könnte mir vorstellen, dass das Löschen mit SMART SECURE ERASE die Besonderheiten von SMR berücksichtigt und dadurch etwas Zeit spart.
 
Belegt, benutzt, ... Haarspalterei :-)
Mir ist grob klar, wie die Daten bei ntfs abgelegt werden. Vielleicht ist mein Anliegen auch zu speziell. Ich gehe davon aus, dass die Speicherinhalte von neuen Datenträgern Nullen enthalten und nur dann etwas Anderes, wenn sie in Benutzung sind oder waren. Hat man eine sehr große und neue HDD (z.B. 12 TB), auf der man nur einige Gigabyte geschrieben hat und möchte das löschen, braucht man mehrere Stunden oder gar Tage. Könnte man nur die Zellen überschreiben, die nicht nur Nullen enthalten, ginge das flotter.
 
Könnte man nur die Zellen überschreiben, die nicht nur Nullen enthalten, ginge das flotter.
Könnte der Mensch fliegen, bräuchte er nicht zu laufen und es ginge auch schneller, aber dies geht halt leider nicht. Wenn die die "Haarspalterei" bzl. des von passat3233 genannten Problems egal ist, schau mal nach einem Wipe Tool wie z.B. SDelete von Sysinternals. Ob das dateiweise überschreiben aber am Ende wirklich schneller geht, dürfte vor allem von der Anzahl und Größe der Dateien abhängen.
 
Normalerweise werden die Daten eher zusammenhängend geschrieben, da die Platte sonst unnötige Sprünge machen müsste. Würde die Überschreibsoftware potentielle Daten(-reste) finden, sollte sie nicht nur einzelne Blocks, sondern größere Bereiche löschen. Sie könnte mit 8M anfangen. Findet sie im darauffolgenden Block wieder was, überschreibt sie 8M, dann 16M, usw. Findet sie nix, senkt sie wieder die Blockgröße schrittweise.

Aber gut, dass es so etwas für einen eher speziellen Fall nicht gibt, leuchtet auch ein - aber es hätte ja doch sein können.

Ich habe zwischenzeitlich festgestellt, dass dd mit der Option bs=128M (*) bei einer SMR-Platte nicht dazu führt, dass diese durch SMR ausgebremst wird. dd schreibt anfangs mit 200 MB/s und gegen Ende sind es 150 MB/s im Mittel, woraus man auf ca 100MB/s im hinteren Bereich schließen kann. Mit SMR-Geschaufel wäre die HDD auf 25 MB/s eingebrochen.
Der Vorteil durch partielles Löschen wäre daher vermutlich tatsächlich klein.


BTW: Die "Haarspalterei" war gekennzeichnet

(*)der genaue Befehl lautet hier:
sudo time dd if=/dev/zero of=/dev/sdX bs=128M status=progress conv=noerror
 
Normalerweise werden die Daten eher zusammenhängend geschrieben, da die Platte sonst unnötige Sprünge machen müsste.
Ja, aber NTFS reserviert irgendwo, normalerweise etwa in der Mitte, einem Bereich (per default 12,5%) für den MFT und beschreibt den erst mit Userdaten, wenn sonst kein Platz mehr frei ist.

Würde die Überschreibsoftware potentielle Daten(-reste) finden, sollte sie nicht nur einzelne Blocks, sondern größere Bereiche löschen. Sie könnte mit 8M anfangen. Findet sie im darauffolgenden Block wieder was, überschreibt sie 8M, dann 16M, usw. Findet sie nix, senkt sie wieder die Blockgröße schrittweise.
Was wäre der Sinn? Wenn der Algorithmus sonst nicht abbricht, würde dies die Sache nur langsamer machen, da je gelesen und geschrieben wird.

Ich habe zwischenzeitlich festgestellt, dass dd mit der Option bs=128M (*) bei einer SMR-Platte nicht dazu führt, dass diese durch SMR ausgebremst wird.
Ja, wenn man auf einmal einen Bereich überschreibt der groß genug ist um alle überlappenden Spuren in einem Segment abzudecken, dann stört SMR die Schreibgeschwindigkeit nicht, denn dann müssen ja vor dem eigentlichen Schreibvorgang der neuen Daten keine alten Daten gelesen und nachher wieder geschrieben werden. So funktioniert übrigens auch Host Managed SMR, da sind auch nur Schreibvorgänge erlaubt, bei denen so ein kompletter Bereich überlappender Spuren am Stück überschrieben wird, der Host muss im Zweifel die alten Daten dann selbst vorher lesen, wenn er nur einen Teil davon überschreiben möchte.

Mit SMR-Geschaufel wäre die HDD auf 25 MB/s eingebrochen.
Wenn einem die Schreiberformance wichtig ist, dann lässt man die Finger von SMR Platten!
 
Was wäre der Sinn? Wenn der Algorithmus sonst nicht abbricht, würde dies die Sache nur langsamer machen, da je gelesen und geschrieben wird.

Mir geht es um den Fall, dass die HDD so gut wie nicht beschrieben wurde. Wenn ein Nutzer die Löschmethode nur in diesem Fall anwendet, könnte er einen deutlichen Geschwindigkeitsvorteil erreichen, weil 99% des Laufwerks nur gelesen, aber nicht beschrieben werden müsste.
Man könnte den Algorithmus aber auch verfeinern und bei zu häufigen Schreibvorgängen abbrechen und stumpf alles überschreiben, aber es wäre ja schon mal ein Anfang. Ob man damit tatsächlich Zeit spart hinge zumindest bei der einfachen Variante auch davon ab, ob der Benutzer die geeignete Methode wählt, aber das sehe ich für so einen speziellen Fall nicht als Nachteil an, denn etwas Fachwissen wird dem Benutzer ohnehin abverlangt, wenn er so etwas macht. Vor- und Nachteile lassen sich auch leicht erklären, sodass selbst wenig versierte Anwender eine sinnvolle Entscheidung treffen können. Bei einem Laufwerk, bei dem Schreib- und Lesegeschwindigkeit (fast) gleich groß sind, wäre die Methode sinnlos.

Evtl. wäre so ein Tool aber auch nützlich, um die Lebensdauer von Datenträgern zu verlängern. Ich denke da an SSDs, denen man damit sehr viele Schreibvorgänge ersparen könnte, sofern es da nicht andere Methoden gibt, die einfacher funktionieren und ähnlich (un-)sicher sind.
 
Wenn ein Nutzer die Löschmethode nur in diesem Fall anwendet, könnte er einen deutlichen Geschwindigkeitsvorteil erreichen, weil 99% des Laufwerks nur gelesen, aber nicht beschrieben werden müsste.
Man muss ja gar nicht 99% lesen, man kann aus den Metadaten der Dateien lesen, welches Cluster sie belegen und dann überschreibt man nur diese. Das macht ein Wipe Tool ja auch und wenn nie eine Datei gelöscht oder durch eine kleinere Version überschrieben wurde, dann würde so auch alles überschrieben, außer eben den Metadaten selbst, aber auch da überschreiben viele der Wipe Tools den Filenamen, denn den würden Recoverytools sonst finden und man könnte meinen sie würden diese Dateien auch wiederhestellen, nur wäre der Inhalt der "geretteten" Dateien dann eben Schrott, weil ja der Inhalt der Cluster den sie belegt haben, überschrieben wurde. Aber das wissen die Recoverytools natürlich nicht und wenn der "Datenretter" dies auch nicht prüft, dann denkt er er hätte etwas wiederhestellen können, auch wenn dem eben nicht so ist.
Evtl. wäre so ein Tool aber auch nützlich, um die Lebensdauer von Datenträgern zu verlängern. Ich denke da an SSDs
Bei SSDs gibt es TRIM, damit kann man dem Controller gezielt sagen, dass er bestimmte Daten löschen kann und er wird es dann auch früher oder später, vermutlich bei der nächsten Idle-GC, auch machen, aber wann er es macht, ist eigentlich egal, da er die LBAs nach dem Timmen aus der Mappingtabelle nimmt und man dann nicht mehr auf die Daten zugreifen kann, selbst wenn sie noch im NAND stehen.

Jedes aktuelle Betriebssystem unterstützt TRIM und trimmt die LBAs die von einer Datei belegt waren, wenn man diese löscht und dazu schaut es eben auch in den Metadaten des Filesystems welche dies sind. Da braucht an so ein Tool also nicht und man kann eine SSD auch komplett löschen, indem man den gesamten Adressraum trimmt.
 
Man muss ja gar nicht 99% lesen, man kann aus den Metadaten der Dateien lesen, welches Cluster sie belegen und dann überschreibt man nur diese. Das macht ein Wipe Tool ja auch und wenn nie eine Datei gelöscht oder durch eine kleinere Version überschrieben wurde, dann würde so auch alles überschrieben, außer eben den Metadaten selbst, aber auch da überschreiben viele der Wipe Tools den Filenamen,

Wenn man alle Bereiche, die benutzt worden sind, mit Nullen überschreiben will, dann kann man sich mMn. nicht auf die Metadaten verlassen. Du schreibst ja selbst, dass das Nullen nur dann funktioniert, wenn keine Datei zuvor gelöscht oder mit einer kleineren Version überschrieben worden ist.
 
Ja, aber dann ist es sehr wahrscheinlich in den meisten Fällen auch am schnellste einfach alles zu überschreiben, statt vorher alles zu lesen um zu schauen, was dann beschrieben wurde um gezielt nur dies zu überschreiben, nachdem man es zuvor schon gelesen hat. Bei HDDs mit SMR hängt dies natürlich auch sehr davon ab, wie man dies überschreibt, also davon wie lang die Schreibzugriffe jeweils sind, aber wenn man da immer einen kompletten Bereich überlappender Spuren beschreibt, dann schreiben sie kaum langsamer als wenn sie kein SMR hätten.
 
Joaa... ich mache das auch gerade und hab deshalb den Thread gelesen. Ne 18 TB USB Platte braucht doch dann 24h, oder? ;D
 
Im hinteren Bereich hat man idR nur die halbe Schreib-/Lesegeschwindigkeit im Vergleich zum Anfangsbereich. Wenn die Platte mit 200 MB/s beschrieben werden kann, hast du am Ende nur 100 MB/s und im Mittel etwas mehr als 150 MB/s. Dann würde es mit einer 18TB-Platte ~33h dauern, wenn du sie komplett überschreiben würdest.
Falls dd benutzen solltest, achte auf den bs-Parameter (Blocksize). Standardmäßig nimmt es sonst 512 bytes und wird vergleichsweise schnarchlahm, besonders bei SNR-Platten.
Mit dem vollständigen o.g. Kommando wird dir auch ein Status angezeigt und es macht bei einem Fehler weiter. Außerdem wird angezeigt, welchen Teil dd gerade beschreibt. Wenn man sich diesen merkt, kann man den Vorgang unterbrechen und später mit dem entsprechenden Offset fortsetzen, sodass die Kiste nicht unbedingt durchlaufen muss. Das kann sehr nützlich sein, wenn man auch noch was anderes zu tun hat.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh