Erase disk data quickly (Summary)

Thank you to everyone that responded. I had a number of good ideas
suggested to me. The two most common suggestions were:

A) Run newfs on the file systems. Some who suggested this also suggested
that a better way then just running newfs would be to overwrite the old
partitions with new "dummy" partitions first with format and then running
newfs. See Jay Lessart's comments below on why this might not be a good
way  to go about this if you are concerned about your data getting into
the wrong hands.

B) The other popular suggestion was to use "dd" to write over the
disks. People who suggested this pointed out that instead of running dd on 
each partition, that I could just do this to slice 2 (provided I followed
the standard practice of slice 2 refore to the whole disk). The syntax
most often suggested was: dd if=/dev/zero of=/dev/rdsk/c?t?d?s2 bs=8192
although some suggested using /dev/random if it is available.

I also had an e-mail from Jay Lessert suggesting that just using "newfs"
doesn't do much at all. I included his e-mail below because if you have
any data that you are at all concerned about, you might want to think
about what he has to say. BTW, in my case, I followed Sun's recommendations
to erase the disk that we had our Library Automation database on as
described in their technical FAQ titled "How do I remove sensative
information from a disk?" and that is how I know it takes so long. It is
probably worth the time if you have it and you are concerned about someone
reading your data. At any rate, if you think that newfs is a good enough 
way or a bad way to do this, let me know and I'll summarize for the list.

On Fri, 25 Oct 2002, Jay Lessert wrote:

> Anyone that touts a "quick" method is giving you bad advice.  Running
> destructive format->analyze is the best approach.
> 
> Given that somebody can look for your sensitive information by
> going:
> 
>     less -f /dev/rdsk/c1t0d1s0
> 
> (is that simple enough?) touching all the bits is the only way to
> go.  In particular, re-running newfs does pretty close to nothing.
> 
> You could fill the file system with garbage:
> 
> #!/bin/tcsh -f
> set DEST=/some/filesystem
> set count=1
> while (1)
>     echo $count
>     tar cf $DEST/tarfile.$count /usr/lib || exit
>     @ count++
> end
> 
> But that *will* leave unused blocks and fragments, and won't be much
> faster (if any) than a single analyze pass.
> 
> Bottom line is: either you really care or you don't.
> 
> If you really care, you (at least) use format.
> 
> If you really don't care, why pretend?
> 
> By the way, I think you'll find analyze->write or analyze->verify
> is faster than purge.  One write pass instead of two.
> 
> -- 
> Jay Lessert                               jay_lessert@accelerant.net
> Accelerant Networks Inc.                       (voice)1.503.439.3461
> Beaverton OR, USA                                (fax)1.503.466.9472
> 

Again, thanks for all the quick responses,

Edward Corrado

Here is my original post.....

On Fri, 25 Oct 2002, Edward M. Corrado wrote:

> I am in the process of preparing a leased Ultra 450 server to be send
> back to Sun. I want to get the data off as much as best as possible. I saw
> on Sun's website (and from some Internet searches), about removing
> Sensative information using:
> 
> format -> defect -> primary
> 
> format -> analyze -> purge
> 
> While I have no doubt this is a food method, this data is not very
> sensative and this takes a long time. Does anyone have a quick method for
> erasing the data on a disk so that it is not simple to recover? As I
> mentioned, in this case the data is not very sensative, but I's like to
> do whatever I can to make it difficult to get to the data without it
> taking all day to do so.
> 
> Edward Corrado
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers