Harde schijf wissen; dd lijkt constant te crashen

[chainzz]

Hallo,

Ik heb mijn desktop PC verkocht maar voordat ik deze aan de koper geef wil ik graag de twee harde schijven die erin zitten compleet wissen. Ik ben erachter gekomen dat dit kan met het volgende commando:

code:

dd if=/dev/urandom of=/dev/sdx bs=1M

Ik probeer dit te doen vanaf een Ubuntu 10.10 live-cd. Gisteren probeerde ik twee dd processen tegelijk te starten, voor zowel mijn eerste als mijn tweede schijf. Ik had gelezen dat je met "kill -USR1 pid_van_dd" kon checken hoever dd was met het overschrijven, dit leek mij erg handig aangezien het hier om twee schijven van 500GB gaat, het overschrijven duurt dus wel een tijdje.

In het begin zag ik dat de twee van processen van dd veel CPU activiteit vertoonden en met het kill commando zag ik dat dd steeds meer GB's had overgeschreven met random data. Na een tijdje viel me echter op dat de twee dd processen geen enkele CPU activiteit meer vertoonden en dat het kill commando ook de status van van dd niet meer weergaf. Ik ging er dus maar vanuit dat de twee dd processen gecrasht waren en probeerde het daarna opnieuw, dit keer door dd alleen op de eerste schijf uit te voeren.

Dit leek langer goed te gaan dan met twee dd processen maar toen ik vanochtend checkte hoever hij was bleek dd weer gecrasht te zijn. Er was geen enkele CPU activiteit meer en dd reageerde ook niet meer op het kill commando.

Weet iemand wat hier aan de hand is?

[Midas.e]

Je process is klaar?

[Cyphax]

Je kunt even kijken in je logs, maar geeft dd normaal niet een soort overzichtje achteraf met aantal sectoren in en out oid? Ik gebruik dd weleens om een iso te maken van een cd'tje, dan heb je iig wel.

[Sallin]

Met dd uit /dev/urandom krijg je ook een overzichtje.

Ik ga even twee domme vragen stellen, ten eerste gebruik je letterlijk dat commando of heb je de juiste /dev/sdx gepakt, ten tweede is er een specifieke reden dat je bs=1M gebruikt (uit nieuwsgierigheid)?

Verder gaat trekken uit /dev/urandom wel even duren. Op een p4 duurde 750GB 5 dagen.

[ Voor 14% gewijzigd door Sallin op 29-12-2010 11:30 ]

[Nick_S]

En als je nou niet je proces naar de achtergrond laat verdwijnen, maar gewoon twee terminals pakt? (Of twee tabjes in dezelfde terminal) Dan kun je gewoon kijken of het proces nog draait en wat voor output het heeft gegeven.

[chainzz]

Midas.e schreef op woensdag 29 december 2010 @ 10:49:
Je process is klaar?

Normaal gesproken geeft dd output zodra hij klaar is in de vorm van het hierboven genoemde overzichtje.

Sallin schreef op woensdag 29 december 2010 @ 11:29:
Met dd uit /dev/urandom krijg je ook een overzichtje.

Ik ga even twee domme vragen stellen, ten eerste gebruik je letterlijk dat commando of heb je de juiste /dev/sdx gepakt, ten tweede is er een specifieke reden dat je bs=1M gebruikt (uit nieuwsgierigheid)?

Verder gaat trekken uit /dev/urandom wel even duren. Op een p4 duurde 750GB 5 dagen.

Ik heb /dev/sdx uiteraard vervangen door /dev/sda en /dev/sdb. Waarom ik bs=1M gebruik weet ik eigenlijk ook niet precies, ik zag het op internet bijna overal staan dus ik heb het maar zo gedaan....

Nick_S schreef op woensdag 29 december 2010 @ 11:31:
En als je nou niet je proces naar de achtergrond laat verdwijnen, maar gewoon twee terminals pakt? (Of twee tabjes in dezelfde terminal) Dan kun je gewoon kijken of het proces nog draait en wat voor output het heeft gegeven.

Ik laat de processen niet naar de achtergrond verdwijnen, ze draaien gewoon op de voorgrond in een terminal. dd geeft geen output totdat hij helemaal klaar is, daarom gebruik ik het 'kill -USR1 pid_van_dd' commando om tussentijds te checken hoever hij is (waarbij ik 'pid_van_dd' natuurlijk vervang door het juiste pid). dd geeft dan het overzichtje wat normaal alleen op het einde gegeven wordt.

[KoosDijk]

Waarom pak je niet /dev/zero? Gaat een stuk sneller, desnoods overschrijf je 2 of 3 keer.

[Ultraman]

Dd stopt gewoon zodra er geen vrije ruimte meer is. Dat is normaal gedrag.

Als je echter zeker wilt zijn dat je data niet meer te recoveren is, dan is eenmalig overschrijven met random data niet voldoende. Als ik schijven wil wipen doe ik een actie als deze meerdere malen, gevolgd door een zero fill.
Maar doorgaans pak ik dan DBAN, staat voor Darik's boot and nuke. Dat is een livecd waarmee je dit soort dingen makkelijk en grondig kan doen. Bovendien laat deze ook netjes zien hoe ver deze is en kun je het algoritme en aantal passes kiezen. Ook een doornormale zero fill behoort tot de mogelijkheden.

[chainzz]

Ultraman schreef op woensdag 29 december 2010 @ 12:02:
Dd stopt gewoon zodra er geen vrije ruimte meer is. Dat is normaal gedrag.

Als je echter zeker wilt zijn dat je data niet meer te recoveren is, dan is eenmalig overschrijven met random data niet voldoende. Als ik schijven wil wipen doe ik een actie als deze meerdere malen, gevolgd door een zero fill.
Maar doorgaans pak ik dan DBAN, staat voor Darik's boot and nuke. Dat is een livecd waarmee je dit soort dingen makkelijk en grondig kan doen. Bovendien laat deze ook netjes zien hoe ver deze is en kun je het algoritme en aantal passes kiezen. Ook een doornormale zero fill behoort tot de mogelijkheden.

Ik weet inderdaad dat dd stopt zodra er geen vrije ruimte meer is, maar ik denk niet dat hij al klaar was want volgens mijn berekeningen zou het wel ongeveer 24 uur duren voordat de schijf compleet overschreven was.

DBAN heb ik ook geprobeerd maar helaas wilde de live-cd bij mij niet opstarten.

[sub0kelvin]

Doet alleen dd moeilijk of gaat het ook mis als je shred gebruikt? Die is aanwezig in de Ubuntu live-omgeving, en overschrijft standaard 3x met random data. Hij gebruikt daar volgens mij ook dd als backend voor, maar geeft wel tussentijdse output met -v.

code:

shred -v /dev/sdx

of als je 1x overschrijven voldoende vindt

code:

shred -v -n 1 /dev/sdx

DBAN wat Ultraman aanbeveelt werkt ook prima.

[Henk007]

KoosDijk schreef op woensdag 29 december 2010 @ 11:51:
Waarom pak je niet /dev/zero? Gaat een stuk sneller, desnoods overschrijf je 2 of 3 keer.

De noodzaak van meer dan één keer overschrijven is een busted myth en stamt nog uit vroegere tijden toen de magnetische sporen op floppy disks zo breed waren dat er resten van het vorige signaal leesbaar waren. Dat is bij moderne HDDs absoluut niet het geval.

[sub0kelvin]

Overigens heb ik laatst een langzame 250GB disk geshred met 5x overschrijven (4x random + 1x zero) en dat duurde in totaal zo'n 6-8 uur. Dus 24u voor het eenmalig overschrijven van 2 disks lijkt me wat veel, het zou dus goed kunnen dat het process niet gecrasht is, maar klaar is.

[smokalot]

Als dd er halverwege mee ophoudt kun je m natuurlijk wel verder laten gaan waar ie ongeveer op was gehouden. Heb geen GNU dd bij de hand, dus weet niet welke optie je daarvoor precies moet gebruiken, op BSD dd is het seek=n, waarbij n het aantal blocks is. Over blocks: je gebruikt bs=1M zodat ie data leest en schrijft in grotere blokken, dat zou sneller moeten gaan (en het is makkelijker om naar de juiste plek te seeken).

Afhankelijk van de gevoeligheid van de gegevens die op je hdd staan, en hoeveel redenen je hebt om ten eerste de nieuwe eigenaar niet te vertrouwen, en ten tweede de hoeveelheid technische expertise die je hem toedicht, lijkt het me dat één keer overschrijven met nullen echt wel genoeg is. Als je overschrijft met nullen moet je afaik toch professionele datarecovery apparatuur hebben om uberhaupt nog iets terug te kunnen krijgen, en ook nog eens de tijd erin steken om die te gebruiken, als je gewoon photorec oid over die hdd heenhaalt vindt ie nog niks. Als Henk007 niet al gelijk heeft en er geen shadowed data overblijft na overschrijven.

[jan99999]

Probeer dit eens http://partedmagic.com/doku.php
Is een livecd met linux, kun je veel mee.
Hier zit ook bij om je hd te wissen, dacht dat er dd word gebruikt.