I'd recommend DBAN as well.

I've recovered plenty of data from a drive that has been zeroed with 
/dev/zero before.

--Adam

On 1/20/2012 9:08 PM, Brian Wall wrote:
> On Fri, Jan 20, 2012 at 2:17 PM, Mike Miller<mbmiller+l at gmail.com>  wrote:
>
>> But seriously -- regarding /dev/zero -- does anyone think there are any
>> *real* worries about data recovery after you've filled the drive with zeros?
> Yes.  I once used a tool (Ontrack maybe?) that found bits of file
> structures after wiping with /dev/zero.  Ever since then, I rely on no
> less than a 3 pass DBAN wipe.
>
>>   I know if I was working on a secret project at Microsoft, I wouldn't fill
>> my old drive with zeros and then hand it to developers at Apple or Oracle,
>> but if we're talking about giving a personal hard drive to someone who just
>> wants to use it in their personal computer, isn't use of /dev/zero plenty?
> I trust no one, but I'm weird that way.
>
>> Jeremy pointed out that /dev/urandom would use random bits.  I would think
>> that /dev/urandom would be a better choice than /dev/zero.  Is there any
>> reason to prefer /dev/zero?  In other words, isn't this a really good
>> answer:
>> dd if=/dev/urandom of=/dev/<drive>
>> Is it really even necessary to do that twice?
> In theory, alternating bit patterns mask magnetic signatures better
> than a single stream of 0s.  Multiple passes increase the masking
> effect and make software based recovery impossible.  If I don't have
> DBAN handy, I'll usually do two passes of urandom and one pass of
> zeros.  It makes me feel better for some reason.  Irrational paranoia
> is fun sometimes.
>
>> To properly mess up that drive, can I just do this?:
>> dd if=/dev/urandom of=/dev/sdb
> Can and should.  As others have stated, this whacks the whole
> partition table, boot sector, and of course all areas of the drive
> with data.
>
> Brian
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>