moonwalker3
Anmeldungsdatum: 30. Juni 2008
Beiträge: 767
|
Ich Wiki-Artikel zu dd wird für das sichere Löschen einer Festplatte der Befehl dd bs=1M if=/dev/zero of=/dev/sdX empfohlen. Gibt eine Möglichkeit, den Fortschritt angezeigt zu bekommen? Bei einer 3TB großen Platte könnte das Überschreiben einige Zeit dauern.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
https://scheible.it/fortschrittsanzeige-dd/ Man könnte auch shred nutzen, das zeigt den Fortschritt.
|
rleofield
Anmeldungsdatum: 14. September 2008
Beiträge: 779
Wohnort: Görlitz
|
moonwalker3 schrieb: Ich Wiki-Artikel zu dd wird für das sichere Löschen einer Festplatte der Befehl dd bs=1M if=/dev/zero of=/dev/sdX empfohlen. Gibt eine Möglichkeit, den Fortschritt angezeigt zu bekommen? Bei einer 3TB großen Platte könnte das Überschreiben einige Zeit dauern.
So mache ich das: Verschlüsseln und mit '0' überschreiben | cryptsetup -d /dev/urandom -c aes-xts-plain create delete GERÄT
shred -vzn 0 /dev/mapper/delete
sync
sleep 4
cryptsetup remove delete
|
rleofield
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Beim dd einfach ein status=progress dazu.
-c aes-xts-plain
aes-xts-plain64 oder die Daten wiederholen sich nach 2TB. An der Geschwindigkeit ändert sich nichts. Anstelle von shred kann man hier auch badblocks -w die überschriebenen Daten anschließend wieder einlesen und somit verifizieren daß das Löschen auch tatsächlich geklappt hat. Oder anschließend cmp /dev/zero /dev/delete oder sowas.
|
moonwalker3
(Themenstarter)
Anmeldungsdatum: 30. Juni 2008
Beiträge: 767
|
rleofield schrieb:
So mache ich das: Verschlüsseln und mit '0' überschreiben
Ist das nicht doppelt gemoppelt? Wenn man eine Festplatte verschlüsselt, dann kann es sein, dass Stellen mit alten Daten noch lesbar sind. Wenn man aber eine Festplatte komplett überschreibt, dann sollte das sicher genug sein, oder?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
moonwalker3 schrieb: Ist das nicht doppelt gemoppelt? Wenn man eine Festplatte verschlüsselt, dann kann es sein, dass Stellen mit alten Daten noch lesbar sind. Wenn man aber eine Festplatte komplett überschreibt, dann sollte das sicher genug sein, oder?
Bei dem Ansatz wird die gesamte Festplatte mit "Zufallsdaten" überschrieben, die durch das Verschlüsseln von Nullen entstanden sind. Durch die Verschlüsselung ist das dann auch reproduzierbar und damit verifizierbar. Früher war /dev/urandom unerträglich langsam deswegen der Umweg über die Verschlüsselung (wenn man Pseudorandom a la shred nicht mag). Heute ist /dev/urandom schnell genug, ist aber nicht reproduzierbar/verifizierbar. Der Verschlüsselungsansatz hat von daher immer noch seine Berechtigung (wenn man nicht nur blind löschen will sondern das ganze mit Nachweis daß es auch geklappt hat).
|
moonwalker3
(Themenstarter)
Anmeldungsdatum: 30. Juni 2008
Beiträge: 767
|
frostschutz schrieb: Der Verschlüsselungsansatz hat von daher immer noch seine Berechtigung (wenn man nicht nur blind löschen will sondern das ganze mit Nachweis daß es auch geklappt hat).
Klingt nachvollziehbar, aber wie lange dauert dann das Überprüfen? Und was ist, wenn es an einer Stellen keine Nullen gibt? Was kann man dann schlussfolgern?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
moonwalker3 schrieb: Klingt nachvollziehbar, aber wie lange dauert dann das Überprüfen?
Einmal komplett überschreiben, einmal komplett einlesen... joa, das dauert. ☺
Und was ist, wenn es an einer Stellen keine Nullen gibt? Was kann man dann schlussfolgern?
Da gibt es zwei Möglichkeiten 1) das Überschreiben hat nicht geklappt 2) die Festplatte wurde anderweitig beschrieben Fall 1) sollte man ein Terminal mit dmesg -w offen haben während das Überschreiben läuft, damit man I/O Fehler etc. direkt sieht. Fall 2) passiert etwa wenn das Dateisystem auf der Festplatte noch gemountet war, das RAID noch lief, etc.
|
moonwalker3
(Themenstarter)
Anmeldungsdatum: 30. Juni 2008
Beiträge: 767
|
Nach über 6 Stunden ist der Vorgang abgeschlossen. Ist die Fehlermeldung normal? 3000584110080 Bytes (3,0 TB, 2,7 TiB) kopiert, 22928 s, 131 MB/s
dd: Fehler beim Schreiben von '/dev/sdb': Auf dem Gerät ist kein Speicherplatz mehr verfügbar
2861589+0 Datensätze ein
2861588+0 Datensätze aus
3000592982016 Bytes (3,0 TB, 2,7 TiB) kopiert, 22935,4 s, 131 MB/s
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5349
|
moonwalker3 schrieb: Nach über 6 Stunden ist der Vorgang abgeschlossen. Ist die Fehlermeldung normal? 3000584110080 Bytes (3,0 TB, 2,7 TiB) kopiert, 22928 s, 131 MB/s
dd: Fehler beim Schreiben von '/dev/sdb': Auf dem Gerät ist kein Speicherplatz mehr verfügbar
2861589+0 Datensätze ein
2861588+0 Datensätze aus
3000592982016 Bytes (3,0 TB, 2,7 TiB) kopiert, 22935,4 s, 131 MB/s
Ja. Nachdem du bei dd wahrscheinlich nicht angegeben hast, wie viel geschrieben werden soll, macht dd einfach weiter bis irgendein Fehler auftritt, in dem Fall hat dd das Ende der Platte erreicht.
|
phanthomasX
Anmeldungsdatum: 26. Dezember 2008
Beiträge: 99
|
... um noch die Ursprungsfrage zu beantworten: Ja, man kann auch den Fortschritt anzeigen. Der Hinweis war ziemlich weit unten im Wiki-Artikel versteckt. ☺
https://wiki.ubuntuusers.de/dd/#Fortschrittsanzeige
In Ubuntu 16.04 ist dd in der Version 8.25 enthalten. Seit Version 8.24 ist es mit dem Parameter status möglich den Fortschritt anzuzeigen. Der Befehl dazu könnte so aussehen:
| dd if=/dev/XXX of=/dev/XXX status=progress
|
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
status=progress wurde ja schon genannt.
Und wenn man status=progress vergessen hat und dd nicht abbrechen will, auch das gute alte killall -s USR1 dd Alternativ auch per lsof u.a. Tools sehen an welchem Offset sich der Filedeskriptor von dd gerade bewegt.
|