[COLUG] Clearing your data from an HDD (was Re: Drive Wiping Speed)
William Yang
wyang at gcfn.net
Fri Sep 14 07:03:57 EDT 2007
jep200404 wrote:
> David Sherman wrote:
>
>
>>I prefer an empty hard drive ...
>
>
> dd if=/dev/zero of=/dev/hda
I don't know what the specific application for that was, but this seems
as good a time as any to talk about clearing drives before repurposing.
I've recently come into a few systems that contain a bunch of
proprietary information through my consulting business. Now, I could
just use DBAN to clear them and be done with it, but that requires that
I burn YACDI (Yet Another CD Image). I've found, with a reasonably
large music case full of media of things I've had to burn, that this is
starting to get annoying to me. Furthermore, simply using DBAN doesn't
really teach me much, so I'm thinking through the process of cleaning disks.
I've looked at DBAN. It's got a several methods to clean a disk, but
unless I really have misunderstood it, it's not really doing anything
I'm terribly concerned about on modern equipment. My understanding and
research lead me to believe that 8 destructive passes with data streamed
from /dev/urandom to a drive is probably sufficient, which means I'm
likely to do:
#! /bin/sh
#
# THIS CODE DESTROYS DATA ON DISKS.
# IT IS *INTENDED* TO MAKE SUCH DATA AS NON-RECOVERABLE AS REASONABLY
# POSSIBLE. YOU MUST BE EXTREMELY CAREFUL USING THIS CODE.
#
DISK=/dev/nosuchdevice
for t in 1 2 3 4 5 6 7 8 ; do
dd if=/dev/urandom of=$DISK bs=16k
done
# because it makes sense to have a clean disk, and it doesn't take that
# long
dd if=/dev/zero of=$DISK bs=1M
#=-= end code
/dev/urandom is significantly slower, of course -- given that it's doing
a hash on seed data, even if it's reusing its entropy base, it's much
more computationally expensive. But how much so?
The base throughput test was simple:
for dev in urandom zero ; do
test -f testfile && /bin/rm -f testfile
dd if=/dev/$dev of=testfile bs=1M count=16
test -f testfile && /bin/rm -f testfile
done
From a performance standpoint, I should have used the same Gentoo
2006.1 minimal LiveCD, doing reads from a devfs /dev/urandom and
/dev/zero, and writing to a ramdisk section of the filesystem, to
eliminate the disk IO factor (what I used on the 800Mhz -- I actually
used existing OS's on the other two machines). Even confounded by disk
IO on the latter two machines, you can see the trend based on the
controlling CPU and IO bus to RAM factors. Every machine has memory
that's properly matched to its bus.
1) A Celeron 800Mhz machine
urandom 16777216 bytes (17 MB) copied, 15.6097 s, 1.1 MB/s
zero 16777216 bytes (17 MB) copied, 0.15252 s, 110 MB/s
2) A Celeron 2.53 Ghz machine (devfs to disk)
urandom 16777216 bytes (17 MB) copied, 4.49014 s, 3.7 MB/s
zero 16777216 bytes (17 MB) copied, 0.0612527 s, 274 MB/s
3) A Core 2 Duo 1.66 Ghz machine (devfs to disk)
urandom 16777216 bytes (17 MB) copied, 3.72988 s, 4.5 MB/s
zero 16777216 bytes (17 MB) copied, 0.039693 s, 423 MB/s
Net result: /dev/zero is about 8x to 10x faster than /dev/urandom...
But you should still use it when you're clearing disks if you're
concerned about confidentiality of data before you give a disk away or
reuse it.
--
William Yang
wyang at gcfn.net
More information about the colug432
mailing list