SSH: dd if=/dev/urandom für externe 1,5TB Samsung Festplatte – Läuft seit Mittwoch?!?

[spaboleo]

Hallo zusammen,

ich habe eine 1,5TB Samsung Festplatte (EcoGreen F4 HD154UI), die ich ehe ich sie abgebe sicher löschen möchte.
Da ich meine Rechner nicht so lange laufen lassen wollte, dachte ich das NAS, welches eh in Betrieb ist, wird dies ja auch verrichten können.

Also habe ich mich per SSH mit meiner DiskStation DS214+ verbunden, den Mountpoint der externen Platte identifiziert und dd gestartet:

dd if=/dev/urandom of=/dev/sdq1

Von einem zweiten Terminal Fenster aus habe ich die Process-ID mittels

ps | grep dd

für den nun laufenden dd-Prozess identifiziert.

Mittels

kill -USR1 <Process-ID>

kann ich mir nun in erstem Terminal-Fenster die aktuell verarbeiteten Blöcke ausgeben lassen und das sieht mittlerweile so aus:

1103979173+1 records in
1103979173+1 records out

Gestartet wurde dieser dd-Kopierprozess am Mittwoch vor der Arbeit.


Ich habe keine Block-Size definiert, da ich den Wert nicht ermitteln konnte.

hdparm -I /dev/sdq1

Hat mir dabei nicht weitergeholfen. Ich hab den Output gerade nicht zur Hand, aber ich meine es stand dort "unknown".

Ist die Standard-Blocksize von dd bei 1024Bytes oder gar nur 512Bytes?
Ich habe beides bereits bei Websuchen gelesen :/

Mit wievielen Blöcken kann ich nun rechnen?
bs=1024 (Bytes): 1,5 * 1024^3 = 1610612736 Blöcke
bs=512 (Bytes): 1,5 * 1024^3 *2 = 3221225472 Blöcke


Ersteres, 1024 Bytes, würde bedeuten, dass ich bei knapp (1103979173 / 1610612736 =) 68% der Gesamtbearbeitung wäre, richtig?
Letzteres, 512 Bytes, analog nur bei knapp (1103979173 / 3221225472 =) 34%?


Insgesamt ein sehr langes Unterfangen
Was wären denn eine für den nächsten "Überschreibvorgang" sinnvolle Block-Size? 4096?
Inwiefern beschleunigt dies den Kopiervorgang?


Ferner ist es überhaupt ratsam diesen Kopiervorgang von der DiskStation aus auszuführen?
Was hat überhaupt Einfluss auf die Performance?


Ich meine mich erinnern zu können, dass ich vor einiger Zeit mal eine 1TB Festplatte mittels DBAN (Darik's Boot and Nuke) Live-CD 7x hab mit Zufalls-Zahlen und anschließend mi Nullen überschreiben lassen, was insgesamt knappe 28 Stunden gedauert hat.
Das ist doch ein deutlicher Unterschied zu meiner oben beschriebenen "Performance" :/
Was macht den Unterschied aus?


Vielen Dank und liebe Grüße

 

[Ameisentaetowierer]

Die Blockgrösse wird in deinem Fall durch dd auf 512 bytes gesetzt...sagt die manpage.
Theoretisch kannst du eine beliebige Blockgrösse definieren. Da Festplatten m.W. intern mit 4k arbeiten, wäre ein Vielfaches von 4k nicht falsch.
Aber eigentlich sollte das keine Rolle spielen.

Was aber auch bremst, ist die Generierung der Zufallszahlen in /dev/urandom.
Du kannst ja mal die Geschwindigkeit von
dd if=/dev/urandom of=/dev/null
mit
dd if=/dev/urandom of=/dev/null bs=4194304
vergleichen.
Und dann mal mit /dev/zero bzw. /dev/null probieren.

 

[spaboleo]

Danke
Gute Idee!

Anbei mal die Ergebnisse für alle, die es Interessiert und selbst mit der DS214+ (oder vergleichbarer DiskStation) nicht testen wollen:
Ich habe mittels nachfolgendem Befehl mal gemessen wie lange die Generierung von 256MB Zufallszahlen mit verschiedenen <BLOCK-SIZE> Werten dauert:

time dd if=/dev/urandom of=/dev/null bs=<BLOCK-SIZE> count=<BLOCK-COUNT>

Die Werte sind so gewählt, dass das Produkt aus <BLOCK-SIZE> und <BLOCK-COUNT> immer 256MB = 268697600 Bytes ergibt und das Ergebnis erstaunt mich nun schon etwas:



Wie man sieht ist der limitierende Faktor hier ganz klar die DS214+, welche die Zufallszahlen offensichtlich nicht schnell genug generieren kann
~3,1xMB ist das Maximum dass man herauskitzeln kann, selbst wenn man die Block-Size auf hohe Werte stellt (wie hier 64MB).

Hingegen geht das Schreiben von Nullen deutlich flotter von der Hand. Hier sieht man schön den positiven Einfluss der Block-Size jenseits der 512 Byte (dd Standardwert).
Nicht in der Tabelle aufgeführt, da nachgeschoben:

dd if=/dev/zero of=/dev/sdq1 bs=4096 count=65536

...benötigte 0,98s. Sprich man schriebt Nullen mit knappen 256MB/s.

Ich schließe daraus die Block-Size, die ratsam ist sind die 4096 Byte, denn danach nimmt die Geschwindigkeit nur geringfügig zu bzw. liegt im Rahmen der Messungenauigkeit bzw. Schwankungen der Randbedingungen.


Ärgerlich ist jedoch in meinem Falle die miserable Performance beim Füllen durch Zufallszahlen mittels /dev/urandom.
Das vollständige Überschreiben besagter 1,5TB Festplatte dauert damit fast 6 Tage!


Ich werde selbige Tests mal von einem Rechner aus starten und sehen wie sich die obigen Parameter-Kombinationen dann auf die Performance auswirken.


Fazit im Bezug auf dd an der DiskStation:
Guter Gedanke, mangelnde Performance, daher nicht ratsam.


(Oder habe ich etwas übersehen um die dd Performance mit /dev/urandom als Quelle zu erhöhen? Danke )

 

[spaboleo]

Vom MacBook aus eben via Terminal getestet und so kam ich auf knappe ~8,8MB/s mit /dev/urandom als Quelle.
Finde ich auch ein wenig schwach zumal dabei nur ein Kern zu knapp 2/3 ausgelastet wurde.

Auch damit würde ein Schreibvorgang mit Zufallsdaten noch 48 Stunden dauern.


Sind diese niedrigen Werte normal?

 

[Ameisentaetowierer]

Soweit ich weiss, ist das normal.
Der Kernel muss halt für die Zufallszahlen sorgen.
Dabei ist urandom noch weniger zufällig als random (s. Wikipedia)

Und /dev/zero bzw. /dev/null als Quelle für Daten sind auch nicvht so gut, da man bei diesen konstanten Werten noch über die Abweichung den ursprünglichen Inhalt ermitteln könnte.
Aber der Aufwand/die Kosten dafür sind dann schon ziemlich hoch.

Nimm einen grossen Magneten, das sollte schneller gehen

 

[trininja]

Mal ausgehend davon das man evtl eine Fortschritsanzeige möchte:

dd if=/dev/random conv=noerror,notrunc,sync bs=10240 | pv >/dev/sdq1

Damit wird dir eine "Fortschrittsanzeige" angezeigt. So plätte ich immer meine Platten.

 

[spaboleo]

Soweit ich weiss, ist das normal.
Der Kernel muss halt für die Zufallszahlen sorgen.
Dabei ist urandom noch weniger zufällig als random (s. Wikipedia)

Und /dev/zero bzw. /dev/null als Quelle für Daten sind auch nicvht so gut, da man bei diesen konstanten Werten noch über die Abweichung den ursprünglichen Inhalt ermitteln könnte.
Aber der Aufwand/die Kosten dafür sind dann schon ziemlich hoch.

Nimm einen grossen Magneten, das sollte schneller gehen

Ja.

Es sollen natürlich mehrere Schreibvorgänge vorgenommen werden. Zumindest 3x vollständig mit Zufallszahlen und anschließend jeweils mit Nullen.
Und gerade dann würden die sich ergebenden 18 Tage Bearbeitungszeit ins Gewicht fallen.

Magnet? – Witzig, nein. Weitere uneingeschränkte Benutzbarkeit soll gewährleistet sein.


@ trininja:
Ja das hatte ich auch probiert, doch mir scheint dass die synology mit dem pipe viewer nicht umgehen kann :/ ("-ash: pv: not found")
Auch verfügt dd über keine Abschlussstatistik (Übertragungsgeschwindigkeit), wie man es sonst gewohnt ist.

 

[spaboleo]

Was spricht eigentlich dagegen auf der Festplatte einen den gesamten verfügbaren Speicherplatz einnehmenden TrueCrypt Container zu erstellen?
Dieser wird doch auch vorab mit Zufallsinhalt gefüllt? Jedenfalls bei den Containern mit vorab definierter Größe.
Im Anschluss mit Nullen überschreiben. Und den Vorgang TC + Nullen beliebig wiederholen.

TrueCryopt hatte ich dabei als recht Flink in Erinnerung.

 

[Peter_Lehmann]

Hallo spabelo,

guter Gedanke, aber ....

1. Macht TrueCrypt beim Befüllen des Containers mit Zufallszahlen ja nichts anderes, als dd => es lässt "Zufall" generieren und schreibt diesen auf die Platte. Warum sollte das ein zusätzliches Programm schneller machen können als dd und /dev/urandom?
   Wenn wir TC nutzen, dann meinen wir in der Regel einen Container mit ein paar 100MB oder einigen GB. Hier gehts um 1,5TB ... . Und die wollen erst einmal geschrieben sein.
2. Das eigentliche Problem: Wer garantiert dir, dass du mit TC wirklich den gesamten Bereich deiner HD erwischst? Heutzutage sind journaled Filesysteme üblich. Verschiedene Betriebssysteme legen sogar "unsichtbare" Bereiche/Partitionen auf der Festplatte an, welche der ONU nicht sieht bzw. kennt. Überall stehen Daten drin. Alles das wird von TC auch nicht mit überschrieben, diese Bereiche werden ja nicht gesehen ... .
   Ich möchte an das bewährte Tool "VS-Clean" vom BSI erinnern, mit welchem es zulässig war, sogar als VS eingestufte Festplatten vollständig zu löschen. Dieses Tool wurde wegen der o.g. Probleme zurückgezogen. (=> BSI : VS-Clean Festplatten-Löschprogramm)

Meine Empfehlung für ein sicheres Löschen ist DBAN. Einen "alten Rechner" hat wohl jeder herumzustehen.

BTW: In einem Beitrag stand hier etwas von "einem starken Magneten". Ja, den gibt es als die ultimative Löschmethode wirklich! HDs in den "Gauss-Ofen" reinstapeln, dicke Tür zu, Raum verlassen und von draußen Strom anlegen. Nach ein paar Stunden ist alles "gar" und vor allem wieder abgekühlt und kann entsorgt werden.


MfG Peter

 

[spaboleo]

1) TrueCrypt:

Ich hab es soeben noch einmal getestet:
Also das Container erstellen mittels Truecrypt geht sehr flink von der Hand.
Zum Test habe ich einen 10GB Container (FAT32, AES verschlüsselt) in knapp über 90s mit damit rund 110MB/s auf die externe Platte (angeschlossen via USB 3.0) erstellt.
Auslastung dabei...1 Kern mit knapp 45%.

Was schließe ich daraus:
Es werden lediglich bestehende Daten mit dem vorher definierten Schlüssel verschlüsselt, nicht aber neue Zufallszahlen generiert.

Den 10GB Container habe ich im Anschluss mit einer Windows-ISO mit knapp 3GB befüllt. Der Kopiervorgang dauert ca. 30 Sekunden.
Sind also auch knappe 100MB/s, wobei die Last in einem Kern auf knapp 60% klettert.
Vertretbare Zeiten.

1,5TB ließen sich so in knapp 4h mit einem Container befüllen.
Das Füllen mit nicht aussagekräftigen Daten (z.B. einem Windows-ISO) würde weitere 4h dauern.
Danach überschrieben mit Nullen. Geben wir dem Durchgang 9h.

Immer noch zeitlich attraktiver als dd.
18 Tage für 3 Überschreibvorgänge stehen dann knapp über einem Tag gegenüber.

Ja, es nicht vollständig. Vermutlich wird irgendwo auch das Filesystem behalten.
Jemand, z.B. ein potentieller Käufer, kann im Anschluss auf der Platte herumschnüffeln und könnt vielleicht auch die Dateinamen auslesen.
Dennoch meine ich dass durch das Befüllen mit nicht aussagekräftigen Daten (ISO) in verschlüsselter Form nicht viel damit anzufangen ist. Den der eigentlich Kern, der zuvor auf der Platte gesicherten Daten ist überschrieben.
Für den Heimgebrauch vielleicht eine ausreichende Alternative.


2) Warum überhaupt nach Alternativen suchen
Ein altes System habe ich nicht herumstehen. Dafür habe ich ansonsten keine Verwendung für, also weshalb den Ballast verwahren/mit sich rumschleppen?
Ansonsten bin ich voll und ganz bei dir...früher habe ich auch stets das u.a. vom BSI empfohlene DBAN verwendet.
Doch mit steigenden Festplattenkapazitäten und damit steigender Dauer solcher Löschvorgänge kann ich meinen Laptop eben nicht so lange entbehren. Es ist ja nicht umsonst ein mobiles Gerät

18 Tage für 3 vollständige Überschreibvorgänge ist schon eine magere Ausbeute.
Möchte ich wirklich auf Nummer sicher gehen wollen und würde auf die als "sicher" geltenden 7 Durchläufe gehen wollen, so würde das 42 Tage bedeuten.
Wenn ich 1,5 Monate formatieren muss, um eine Festplatte von 1,5TB ruhigen Gewissens verkaufen zu können. So vergeht mir schon fast die Lust am Verkauf. (Da wird der Magnet mit anschließendem Hammer-Einsatz und leicht paranoider stückenweise separierter Entsorgung schon fast attraktiv )

Einen Zweitrechner anschaffen nur um im Jahr 2-3 Festplatten zu formatieren erscheint mir irgendwie auch nicht als ideale Lösung.
Wo doch ein kleiner fast 24 Stunden am Tag laufender Rechenknecht, die DiskStation, als "eh-da Gerät" im Haus steht.


3) Und damit mal wieder zurück zur DiskStation
Und da schließt sich der Kreis.
Denn leider musste ich feststellen dass die DiskStation auch den dd-Prozess stoppt, sobald die ssh-Verbindung unterbrochen wird. Letzteres geschieht z.B. beim Schließen der Shell aus der er gestartet wurde oder aber auch bei Timeouts (gerne hervorgerufen durch Standby des Clientrechners). Oder wenn man trivialer Weise mal mit seinem Mobilcomputer das Haus verlässt.
Unangenehm.
Gibt es eine Möglichkeit den Prozess am Laufen zu halten?

Darüber hinaus gibt es ja durchaus andere Pakete z.B. "shred", die das Überschreiben schneller durchführen als dd.
Können diese nachträglich auf der DiskStation installiert werden?
Und zwar so dass es keinen Einfluss auf das sonstige System hat, sprich Updates weiter wie gewohnt eingespielt werden können etc.
Die DiskStation soll in erster Linie sicher und stabil sein, es ist für mich ein Datenlager und Teil meiner ersten Backup-Stufe, da kann und will ich mir keine Wackelfaktoren durch ein "zusammengeschustertes" Bastelsystem ins Boot holen

Vielen Dank und liebe Grüße

 

[dil88]

Gibt es eine Möglichkeit den Prozess am Laufen zu halten?

Dafür gibt es das Kommando "nohup". Ich weiss nur nicht, ob das im Standard DSM enthalten ist, aber damit solltest Du es hinbekommen.

 

[spaboleo]

Dafür gibt es das Kommando "nohup". Ich weiss nur nicht, ob das im Standard DSM enthalten ist, aber damit solltest Du es hinbekommen.

Danke dir! Ich werde es heute Abend mal testen.

 

[borg2k]

http://wiki.ubuntuusers.de/Shell/Prozesssteuerung