[gelöst] USB-Stick sicher löschen - wie? (2017)
[gelöst] USB-Stick sicher löschen - wie? (2017)
Hallo Debianer,
ich würde gerne einen USB-Stick verschenken, doch dieser hatte schon viele Dateien von mir drauf. Davon waren es auch persönliche Daten. Ich habe einen Beitrag von 2008 hier gefunden und habe dementsprechend auch die Beitrags-Überschrift angepasst, da dies wohl eher als "wiederbeleben" angesehen werden kann.
In dem Beitrag wurde damals geschrieben, das es reichen würde, mit dd den USB-Stick zu nullen, allerdings ist ein USB-Stick doch ein Flashspeicher, wie eine SSD das auch ist, oder? Genügt es daher wirklich den USB-Stick zu nullen oder gibt es eine andere Methode? Das Secure Erase Verfahren, was man auch mittels hdparm anwenden kann, funktioniert auf einem USB-Stick nicht, zumindest bei mir nicht.
Vielleicht hat ja jemand von euch noch eine Idee oder Tipp? Vielen Dank schon einmal.
ich würde gerne einen USB-Stick verschenken, doch dieser hatte schon viele Dateien von mir drauf. Davon waren es auch persönliche Daten. Ich habe einen Beitrag von 2008 hier gefunden und habe dementsprechend auch die Beitrags-Überschrift angepasst, da dies wohl eher als "wiederbeleben" angesehen werden kann.
In dem Beitrag wurde damals geschrieben, das es reichen würde, mit dd den USB-Stick zu nullen, allerdings ist ein USB-Stick doch ein Flashspeicher, wie eine SSD das auch ist, oder? Genügt es daher wirklich den USB-Stick zu nullen oder gibt es eine andere Methode? Das Secure Erase Verfahren, was man auch mittels hdparm anwenden kann, funktioniert auf einem USB-Stick nicht, zumindest bei mir nicht.
Vielleicht hat ja jemand von euch noch eine Idee oder Tipp? Vielen Dank schon einmal.
Zuletzt geändert von Houbey am 11.03.2020 12:51:47, insgesamt 2-mal geändert.
Viele Grüße
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Re: USB-Stick sicher löschen - wie? (2017)
ich glaube, dass es USB-Sticks gibt, die über mehr Speicherplatz verfügen als zugänglich ist. Dieser überschüssige Speicher wird dann als Reservespeicher verwendet um defekte Flashzellen zu ersetzen und für Wear-Leveling.
Dann würde am wie bei SSDs mit dem Überschreiben des kompletten Datenträgers sicher sein können, dass der überwiegender Teil der Daten unwiderbringlich futsch ist, aber man kann sich keinesfalls sicher sein, dass tatsächlich alle Daten unwiderbringlich verloren sind. Im Unterschied zur SSD gibt es aber kein Secure Erase oder etwas vergleichbares.
Ich habe auch schon die Empfehlung gelesen einen (geheimen) Schlüssel (zum Beispiel zur Verschlüsselung mittels luks) nicht unbedingt auf einen USB-Stick zu schreiben und zwar aus genau dem Grund, dass es schwer bis unmöglich ist, sicherzustellen, dass kein Fragment des Schlüssels mehr irgendwo auf dem Stick liegt.
Andererseits kann ich mich auch gut erinnern, dass mir schon jemand hier im Forum widersprochen und gemeint hat, USB-Sticks würden keinesfalls über Wear-Leveling verfügen (ob derjenige damit auch Reservespeicher für kaputte Speicherbereiche ausgeschlossen hat, die ja im wesentlich dasselbe Risiko bergen, weiß ich allerdings nicht mehr).
Ich meine für den Alltagsgebrauch ist das Überschreiben mit Nullen vollkommen ausreichend und mehr kann man bei USB-Sticks ohnehin nicht machen.
Dann würde am wie bei SSDs mit dem Überschreiben des kompletten Datenträgers sicher sein können, dass der überwiegender Teil der Daten unwiderbringlich futsch ist, aber man kann sich keinesfalls sicher sein, dass tatsächlich alle Daten unwiderbringlich verloren sind. Im Unterschied zur SSD gibt es aber kein Secure Erase oder etwas vergleichbares.
Ich habe auch schon die Empfehlung gelesen einen (geheimen) Schlüssel (zum Beispiel zur Verschlüsselung mittels luks) nicht unbedingt auf einen USB-Stick zu schreiben und zwar aus genau dem Grund, dass es schwer bis unmöglich ist, sicherzustellen, dass kein Fragment des Schlüssels mehr irgendwo auf dem Stick liegt.
Andererseits kann ich mich auch gut erinnern, dass mir schon jemand hier im Forum widersprochen und gemeint hat, USB-Sticks würden keinesfalls über Wear-Leveling verfügen (ob derjenige damit auch Reservespeicher für kaputte Speicherbereiche ausgeschlossen hat, die ja im wesentlich dasselbe Risiko bergen, weiß ich allerdings nicht mehr).
Ich meine für den Alltagsgebrauch ist das Überschreiben mit Nullen vollkommen ausreichend und mehr kann man bei USB-Sticks ohnehin nicht machen.
Re: USB-Stick sicher löschen - wie? (2017)
Alles als root ausführen:
oder
Das x mit dem Device ersetzen, die Klammern beziehen sich auf Partitionen, wenn es der ganze Stick ist, entfällt das.
Du kannst auch den Stick neu formatieren mit neuer Partitiontabelle, dann wird auch alles gelöscht.
Code: Alles auswählen
dd if=/dev/zero of=/dev/sdx(x) count=1
Code: Alles auswählen
shred -n 1 -v /dev/sdx(x)
Du kannst auch den Stick neu formatieren mit neuer Partitiontabelle, dann wird auch alles gelöscht.
Re: USB-Stick sicher löschen - wie? (2017)
Hallo ihr zwei,
vielen Dank für eure Antworten.
Das formatieren soll ja normalerweise die Dateien physisch nicht wirklich löschen, sondern lediglich als freien Speicher markieren. Betrifft das auch USB Sticks dann oder lediglich magnetische Festplatten, also HDDs? Denn da kann man ja ohne Probleme mittels dd, DBAN, cat etc. die gesamte Platte vollschreiben lassen.
@ KP97, was bedeutet denn das count=1 ?
@ smutbert, ich habe zwar des öfteren die USB-Sticks mit nullen überschrieben, war mir allerdings nicht mehr so sicher, als ich einen Beitrag gelesen habe, das USB-Sticks lediglich die "langsameren" SSDs vergleichsweise sein sollen. Daher auch meine Frage zwecks Flash-Speichers.
vielen Dank für eure Antworten.
Das formatieren soll ja normalerweise die Dateien physisch nicht wirklich löschen, sondern lediglich als freien Speicher markieren. Betrifft das auch USB Sticks dann oder lediglich magnetische Festplatten, also HDDs? Denn da kann man ja ohne Probleme mittels dd, DBAN, cat etc. die gesamte Platte vollschreiben lassen.
@ KP97, was bedeutet denn das count=1 ?
@ smutbert, ich habe zwar des öfteren die USB-Sticks mit nullen überschrieben, war mir allerdings nicht mehr so sicher, als ich einen Beitrag gelesen habe, das USB-Sticks lediglich die "langsameren" SSDs vergleichsweise sein sollen. Daher auch meine Frage zwecks Flash-Speichers.
Zuletzt geändert von Houbey am 11.03.2020 12:52:07, insgesamt 1-mal geändert.
Viele Grüße
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Re: USB-Stick sicher löschen - wie? (2017)
Count=1 bedeutet erster Startsektor
Das kann man aber auch weglassen oder hier mal nachlesen:
https://wiki.ubuntuusers.de/dd/
Zu SSD's kann ich mangels Vorhandensein nichts sagen, da weiß @smutbert sicher mehr.
Das kann man aber auch weglassen oder hier mal nachlesen:
https://wiki.ubuntuusers.de/dd/
Zu SSD's kann ich mangels Vorhandensein nichts sagen, da weiß @smutbert sicher mehr.
Re: USB-Stick sicher löschen - wie? (2017)
Zu SSD komplett löschen kann ich etwas beitragen.
Ich mache es immer als root aus der Konsole, meist mit einer Knoppix Live DVD. Sollte aber auch ohne Knoppix funktionieren.
blkdiscard -v /dev/sdx
partprobe /dev/sdx
neu booten
Das x muß natürlich ersetzt werden je nach device evt. sda, sdb usw. Das geht aber nicht mit USB Sticks!
Es ist immens schnell ....
Ich mache es immer als root aus der Konsole, meist mit einer Knoppix Live DVD. Sollte aber auch ohne Knoppix funktionieren.
blkdiscard -v /dev/sdx
partprobe /dev/sdx
neu booten
Das x muß natürlich ersetzt werden je nach device evt. sda, sdb usw. Das geht aber nicht mit USB Sticks!
Es ist immens schnell ....
Wer nicht lieben kann, muß hassen. Wer nicht aufbauen kann muß zerstören. Wer keine Brücken baut, muß spalten.
-
- Beiträge: 3792
- Registriert: 26.02.2009 14:35:56
Re: USB-Stick sicher löschen - wie? (2017)
Wenn es um absolute Sicherheit geht, hilft nur thermisches Vernichten - ist zwar nicht ganz umweltfreundlich, aber wirklich sicher.
Re: USB-Stick sicher löschen - wie? (2017)
Mechanisches Vernichten reicht auch. Wenn du die Chips mit einem Hammer zertrümmerst, kommst du auch nichtmehr an die Daten ran.pferdefreund hat geschrieben:06.11.2017 08:36:11Wenn es um absolute Sicherheit geht, hilft nur thermisches Vernichten
Bei USB-Sticks reicht aber das Beschreiben mit Nullen völlig aus. Da ist auch nach dem Nullen keine "Restinformation" mehr vorhanden. Vor allem die billigen USB-Sticks (gefühlsmässig alles bis 64GB) haben garantiert keine Reservezellen. Auch über Wearlevelling verfügen sie in der Regel nicht. Wobei Wearlevelling auch ohne Reservezellen realisierbar ist, und nichts mit der Löschfähigkeit zu tun hat.
Re: USB-Stick sicher löschen - wie? (2017)
Da gehört doch noch die Byte-Size dazu? Oder kann man das da weglassen?KP97 hat geschrieben:05.11.2017 15:49:29Alles als root ausführen:Code: Alles auswählen
dd if=/dev/zero of=/dev/sdx(x) count=1
Code: Alles auswählen
dd if=/dev/zero of=/dev/Usbstick bs=1024
Re: USB-Stick sicher löschen - wie? (2017)
Vielen Dank für eure ganzen Antworten. Das hilft mir schon sehr viel.
@ debianoli, die bs kannst du auch weglassen, da dd standardmäßig immer mit 512 bytes überschreibt. Außer du möchtest es beschleunigen, dann ist das so wie du geschrieben hast, eigentlich korrekt.
Wäre der Befehl dann mit dem count wie folgt?:
oder muss das bs wenn man es eintragen möchte, ans Ende, hinter dem count?
@ debianoli, die bs kannst du auch weglassen, da dd standardmäßig immer mit 512 bytes überschreibt. Außer du möchtest es beschleunigen, dann ist das so wie du geschrieben hast, eigentlich korrekt.
Wäre der Befehl dann mit dem count wie folgt?:
Code: Alles auswählen
dd if=/dev/zero of=/dev/USB-Stick bs=1M count=1
Zuletzt geändert von Houbey am 11.03.2020 12:52:47, insgesamt 1-mal geändert.
Viele Grüße
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Re: USB-Stick sicher löschen - wie? (2017)
Nein, bs=1M count=1 überschreibt nur das erste Megabyte des Sticks.carlchen hat geschrieben:06.11.2017 10:50:41Wäre der Befehl dann mit dem count wie folgt?:
Code: Alles auswählen
dd if=/dev/zero of=/dev/USB-Stick bs=1M count=1
Um wirklich sicher zu gehen, muß man count und bs weglassen.
count gibt nämlich an, wie oft der mit bs angegeben Block geschrieben werden soll.
Eine zu große bs könnte dazu führen, daß das letzte Ende des Datenspeichers gar nicht bescrieben wird, wenn die Kapazität nicht exakt durch bs teilbar ist.
Re: USB-Stick sicher löschen - wie? (2017)
Na, da wird der Beschenkte aber Augen machen...;-)MSfree hat geschrieben:06.11.2017 08:49:10Wenn du die Chips mit einem Hammer zertrümmerst, kommst du auch nichtmehr an die Daten ran. :wink:
@MSfree
Danke für den Hinweis zu count, war mir so nicht bekannt.
Re: USB-Stick sicher löschen - wie? (2017)
Auch wenn es wieder unter gehen wird:
Macht das gleiche wie
Nur das letzteres schneller geht.
Der Grund: Bei erstem Befehl wird mit den 2. 512 Byte erst angefangen, wenn die ersten fertig geschrieben sind.
Das ist in zweifacher Hinsicht unsinnig:
Code: Alles auswählen
dd if=/dev/zero of=/dev/USB-Stick
Code: Alles auswählen
cat /dev/zero > /dev/USB-Stick
Der Grund: Bei erstem Befehl wird mit den 2. 512 Byte erst angefangen, wenn die ersten fertig geschrieben sind.
Das ist in zweifacher Hinsicht unsinnig:
- Die nächsten 512Byte könnten locker gelesen werden während noch die ersten geschrieben werden. Es gibt also immer eine Pause fürs Lesen, während geschrieben wird.
Da /dev/zero extrem schnell ist, ist das in dem Beispiel eher harmlos. Beim Kopieren eines Sticks auf den anderen ist da gerne mal der Faktor 2 drin. (Wenn lesen und schreiben gleich schnell ist, wird die Hälfte der Zeit gelesen und die Hälfte geschrieben. Statt die ganze Zeit gleichzeitig zu lesen und zu schreiben.) - USB-Sticks können oft nur 4096-Blöcke schreiben. – Bei der dd-variante werden also die ersten 4096Byte gelesen, die ersten 512byte ausgetauscht und wieder geschrieben. Danach erneut gelesen, die 2. 512Byte ausgetauscht und erneut geschrieben...
Am Ende hat man den gleichen ersten Block 8 statt ein mal geschrieben. Das ist nicht nur langsam sondern auch nicht sonderlich gut für die Haltbarkeit des Sticks.
Die meisten Sticks fangen das mit Caches ab. Trotzdem bleibt da immer ein ziemlich signifikanter Unterschied.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: USB-Stick sicher löschen - wie? (2017)
Nein, das geht nicht unter. Danke für den Tipp.wanne hat geschrieben:06.11.2017 16:10:19Auch wenn es wieder unter gehen wird:Macht das gleiche wieCode: Alles auswählen
dd if=/dev/zero of=/dev/USB-Stick
Nur das letzteres schneller geht.Code: Alles auswählen
cat /dev/zero > /dev/USB-Stick
Re: USB-Stick sicher löschen - wie? (2017)
Wie auch debianoli schon schrieb, das wird nicht untergehen. Vielen Dank für den Tipp. Also ist cat zu empfehlen, damit die Haltbarkeit länger gewährleistet ist?wanne hat geschrieben:06.11.2017 16:10:19Auch wenn es wieder unter gehen wird:Macht das gleiche wieCode: Alles auswählen
dd if=/dev/zero of=/dev/USB-Stick
Nur das letzteres schneller geht.Code: Alles auswählen
cat /dev/zero > /dev/USB-Stick
Zuletzt geändert von Houbey am 11.03.2020 12:53:11, insgesamt 1-mal geändert.
Viele Grüße
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Re: USB-Stick sicher löschen - wie? (2017)
Kurz: Ja.carlchen hat geschrieben:06.11.2017 18:23:00Wie auch debianoli schon schrieb, das wird nicht untergehen. Vielen Dank für den Tipp. Also ist cat zu empfehlen, damit die Haltbarkeit länger gewährleistet ist?
Länger: cat versucht die Größe der zu schreibenden Blöcke intelligent zu ermitteln das ist meist deutlich schonender als die 512Byte von dd. Du kannst auch mit dd über den bs= Parameter die Blockgröße festlegen. Wenn du die für den Stick passend festlegt kannst du natürlich genausogut sein (oder kannst sogar besser sein, wenn du dich intelligenter als cat anstellst, weil du die Hardware besser als der cat kennst.) Aber die defaults von 512Byte von dd sind halt alles andere als gut für USB-Sticks.
rot: Moderator wanne spricht, default: User wanne spricht.
- heisenberg
- Beiträge: 3586
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: USB-Stick sicher löschen - wie? (2017)
Ist das nicht nur so wenn man oflag=sync angibt?wanne hat geschrieben:06.11.2017 16:10:19Auch wenn es wieder unter gehen wird:Macht das gleiche wieCode: Alles auswählen
dd if=/dev/zero of=/dev/USB-Stick
Nur das letzteres schneller geht.Code: Alles auswählen
cat /dev/zero > /dev/USB-Stick
Der Grund: Bei erstem Befehl wird mit den 2. 512 Byte erst angefangen, wenn die ersten fertig geschrieben sind.
Das ist in zweifacher Hinsicht unsinnig:
- Die nächsten 512Byte könnten locker gelesen werden während noch die ersten geschrieben werden. Es gibt also immer eine Pause fürs Lesen, während geschrieben wird.
Aber wie Du schon schriebst: Hier vollkommen vernachlässigbar. Falls man einen Cache braucht, dann wäre mbuffer hilfreich.
Zuletzt geändert von heisenberg am 06.11.2017 22:12:22, insgesamt 3-mal geändert.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
- heisenberg
- Beiträge: 3586
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: USB-Stick sicher löschen - wie? (2017)
Ich habe die Ausgabe von dd bisher immer so interpretiert, das entweder ganze oder unvollständige Blöcke geschrieben werden, aber geschrieben wurde da immer.MSfree hat geschrieben:06.11.2017 11:17:26Eine zu große bs könnte dazu führen, daß das letzte Ende des Datenspeichers gar nicht bescrieben wird, wenn die Kapazität nicht exakt durch bs teilbar ist.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: USB-Stick sicher löschen - wie? (2017)
Ich würde das so nicht sagen. Auch kleine Unterbrechungen in schreiben führen ganz gerne mal zu größeren Wartezeiten.heisenberg hat geschrieben:06.11.2017 21:53:06Aber wie Du schon schriebst: Hier vollkommen vernachlässigbar.
Der Extremfall sind da CDs wenn denen mal das schreiben unterbrochen wurde, brauchen sie mehrere Sekunden, bis sie wieder weiterschreiben können. Aber auch Flash speicher haben durchaus ansprechzeiten, die deutlich länger als ein ununterbrochenes Schreiben sind.
Du kannst einfach mal benchmarken: Das wurde auch schon hier im Forum gemacht. cat ist merkbar schneller.
I/O auf unformatierte devices ist immer synchron.Ist das nicht nur so wenn man oflag=sync angibt?
Die Paar Byte die die cat buffert sind mehr als ausreichend. Daneben hat eine einfache Pipe mittlerweile 65536Byte. für I/O in richtung Platte auch ohne zusätzliches mbuffer mehr als Ausreichend. Da brauchst du kein mbuffer mehr dazwischen.heisenberg hat geschrieben:06.11.2017 21:53:06Falls man einen Cache braucht, dann wäre mbuffer hilfreich.
Aber prinzipiell genau die Idee hinter mbuffer genau die. Wenn du schnellere und unregelmäßigere I/O hast, brauchst du größere Buffer und dann ist mbuffer das richtige Tool für dich.
rot: Moderator wanne spricht, default: User wanne spricht.
- heisenberg
- Beiträge: 3586
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: USB-Stick sicher löschen - wie? (2017)
Hmm... selbst wenn ich das auf die Spitze treibe und mal zum Testen nur Byteweise beschreibe um damit die Zugriffszahlen zu maximieren, kann ich da nur einen kaum bemerkbaren Unterschied sehen:
Nachtrag: hier auch nochmal der Schreibvorgang mit Ausgabe direkt auf das Gerät(statt in ein Dateisystem):
Ich habe einen normalen USB-Stick(USB 2) an einem schnellen Rechner verwendet.
Wenn also bei 50.000.000 Schreibzugriffen so wenig Auswirkung ist, würde ich sagen, dass die Ansprechzeiten des USB-Sticks hier vernachlässigbar sind.
Hier nochmal der Test, wenn ich mit etwas mehr Daten mit grösseren Blockgrössen(Standardblockgrösse = 512 Bytes) schreibe:
Der popelige USB-Stick schafft diese Geschwindigkeit nie im Leben. D. h. ich vermute da wird überhaupt nix synchron geschrieben, sondern alles gecached , erst im Hintergrund auf den Stick geschrieben und die langsame Geschwindigkeit oben kommt nur daher, dass das System jedes Byte einzeln hin- und herschubsen muss.
Wenn ich auch mal verschiedene Bereiche beschreibe, dann sieht man da nochmal eine Veränderung:
D. h. ich beschreibe bei jeder Iteration einen anderen Bereich. Sobald der Cache voll ist, müssen die Daten geschrieben werden, und dann geht die Schreibgeschwindigkeit auf die tatsächliche Geschwindigkeit runter, die der Stick leisten kann und wird dann erst wieder schnell, wenn die Daten aus dem Cache weggeschrieben sind. Wenn ich kontinuierlich schreibe, dann geht die Geschwindigkeit tendenziell in den Keller, wie oben zu sehen.
Lange Rede, kurzer Sinn
Ich sehe da nicht dass bei meinem System(Debian Stretch, Desktop-PC), beim direkten Schreiben auf eine USB-Stick-Gerätedatei, da irgendetwas synchron geschrieben wird.
Das hier scheint es zu erklären.
https://lwn.net/Articles/572911/
Bei mir steht dirty_ratio auf 10 (%). D. h. bei 16 GB RAM wird 1,6 GB für das Caching verwendet.
Code: Alles auswählen
root@desk:/media/usbstick# for((i=1;$i<=20;i++));do { dd </dev/zero bs=1c count=$((1024*1024*50)) >testfile ; } 2>&1 | grep -v Datens ; done
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,392 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,3795 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,5895 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,3803 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,5129 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,3975 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,794 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,4439 s, 2,0 MB/s
...
root@desk:/media/usbstick# for((i=1;$i<=20;i++));do { dd </dev/zero bs=1c count=$((1024*1024*50)) iflag=sync oflag=sync >testfile ; } 2>&1 | grep -v Datens ;done
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,4446 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,7176 s, 2,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,181 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,3521 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,2663 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,1722 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 26,5311 s, 2,0 MB/s
...
Code: Alles auswählen
for((i=1;$i<=20;i++));do { dd </dev/zero bs=1c count=$((1024*1024*50)) >/dev/sdb ; } 2>&1 | grep -v Datens ;done
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,8363 s, 2,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,4236 s, 2,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,4284 s, 2,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 23,1841 s, 2,3 MB/s
...
Wenn also bei 50.000.000 Schreibzugriffen so wenig Auswirkung ist, würde ich sagen, dass die Ansprechzeiten des USB-Sticks hier vernachlässigbar sind.
Hier nochmal der Test, wenn ich mit etwas mehr Daten mit grösseren Blockgrössen(Standardblockgrösse = 512 Bytes) schreibe:
Code: Alles auswählen
for((i=1;$i<=20;i++));do { dd </dev/zero count=$((1024*1024)) >/dev/sdb ; } 2>&1 | grep -v Datens ;done
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,640451 s, 838 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,542197 s, 990 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,546151 s, 983 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,601548 s, 892 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,552735 s, 971 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,551296 s, 974 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,551773 s, 973 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,561011 s, 957 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,570087 s, 942 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 1,13311 s, 474 MB/s
536870912 Bytes (537 MB, 512 MiB) kopiert, 0,61497 s, 873 MB/s
Wenn ich auch mal verschiedene Bereiche beschreibe, dann sieht man da nochmal eine Veränderung:
Code: Alles auswählen
root@desk:/media/usbstick# for((i=1;$i<=100;i++));do { dd </dev/zero count=$((1024*100)) seek=$(($i*1024*100)) >/dev/sdb ; } 2>&1 | grep -v Datens ;done
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0885792 s, 592 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,126787 s, 414 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0974019 s, 538 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,101278 s, 518 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,102126 s, 513 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,129887 s, 404 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0890491 s, 589 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,102819 s, 510 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,101822 s, 515 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,128684 s, 407 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0905995 s, 579 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0901749 s, 581 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,128309 s, 409 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0901506 s, 582 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 20,2728 s, 2,6 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,097679 s, 537 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 119,756 s, 438 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0833935 s, 629 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 107,291 s, 489 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,124952 s, 420 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 112,425 s, 466 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0750392 s, 699 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 64,9629 s, 807 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0630086 s, 832 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 27,5559 s, 1,9 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0992653 s, 528 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 57,5047 s, 912 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,102086 s, 514 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 45,8611 s, 1,1 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,0579088 s, 905 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 43,4918 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 0,127354 s, 412 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 40,1855 s, 1,3 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 1,00295 s, 52,3 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 56,5088 s, 928 kB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 49,1058 s, 1,1 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 43,8796 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 48,5203 s, 1,1 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 45,0704 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 35,149 s, 1,5 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 44,1591 s, 1,2 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 51,5053 s, 1,0 MB/s
52428800 Bytes (52 MB, 50 MiB) kopiert, 43,5743 s, 1,2 MB/s
Lange Rede, kurzer Sinn
Ich sehe da nicht dass bei meinem System(Debian Stretch, Desktop-PC), beim direkten Schreiben auf eine USB-Stick-Gerätedatei, da irgendetwas synchron geschrieben wird.
Das hier scheint es zu erklären.
https://lwn.net/Articles/572911/
Bei mir steht dirty_ratio auf 10 (%). D. h. bei 16 GB RAM wird 1,6 GB für das Caching verwendet.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: USB-Stick sicher löschen - wie? (2017)
ich geb auch mal mein Senf dazu,
also im Thread Kopf steht "sicher löschen" , dass bedeutet das jeder sektor mindestens 7x mit zufälligen Werten beschrieben werden muss! Besser sogar 35x jeden Sektor mit Zufallwerten beschreiben und das sehe ich "shred" schonmal als sehr brauchbar an:
ungetested:
shred --interation=35 --random-source=/dev/urandom --zero /dev/DEVICE
also im Thread Kopf steht "sicher löschen" , dass bedeutet das jeder sektor mindestens 7x mit zufälligen Werten beschrieben werden muss! Besser sogar 35x jeden Sektor mit Zufallwerten beschreiben und das sehe ich "shred" schonmal als sehr brauchbar an:
ungetested:
shred --interation=35 --random-source=/dev/urandom --zero /dev/DEVICE
Re: USB-Stick sicher löschen - wie? (2017)
Das ist schon bei Festplatten Unsinn und für Flashspeicher schlicht und ergreifend komplett falsch. Nach einmaligem Überschreiben ist bei Flashspeicher keine Restinformation mehr aus dem "Hintergrundrauschen" zu bekommen.ren22 hat geschrieben:15.11.2017 18:18:27also im Thread Kopf steht "sicher löschen" , dass bedeutet das jeder sektor mindestens 7x mit zufälligen Werten beschrieben werden muss! Besser sogar 35x
- heisenberg
- Beiträge: 3586
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: USB-Stick sicher löschen - wie? (2017)
Das war mal ne Zeit lang in der Diskussion. Aber irgendwann hat man festgestellt, dass man 1 maligem Überschreiben vielleicht noch hier und da mal 1 BIT restaurieren könnte, aber von einer Datenmenge, aus der man tatsächlich brauchbare Informationen gewinnen könnte, war das dann doch extrem weit weg. Und damit hat sich der Satz: "Mindestens 20 Mal überschreiben" erledigt. Seitdem ist der Default bei shred auch wieder 3 Iterationen und das reicht Dicke.
Im übrigen freuen sich alle Computerhändler und Chiphersteller und können die Anzahl der Überschreibzyklen für sicheres löschen gar nicht hoch genug ansetzen.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: USB-Stick sicher löschen - wie? (2017)
Die Diskussiom um die Statusanzeige von cat wurde nach Status für cat verschoben
Das hat den Beitrag um die Bitte danach etwas aus dem Kontext genommen. --wanne
Ursprünglicher Beitrag:
Das hat den Beitrag um die Bitte danach etwas aus dem Kontext genommen. --wanne
Ursprünglicher Beitrag:
carlchen hat geschrieben:Alles klar, das kann ich machen. Werde mich gleich mal mit einem Mod in Verbindung setzen.
Dankeschön für eure Antworten.
Viele Grüße
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.
Houbey
------------------------------
Debian GNU/Linux 11.9 Bullseye, Xfce 4.16, als 64-Bit und bis jetzt noch glücklich damit.