Bulk erased drives
in [Design]
|
Prev: Trailer and Power Generator
Next: Bad Resistors
From: JosephKK on 26 Jun 2010 11:36 On Fri, 25 Jun 2010 03:16:09 -0700 (PDT), Greegor <greegor47(a)gmail.com> wrote: >Robert Baer, what was the most recent version of >Spinrite before Gibson sold it to Microsoft? > >I used to use Spinrite a LOT (system integrator) >back on the old MFM and RLL hard disks. > >Spinrite ceased to work it's magic and could >not even be safely run on IDE drives when they >came onto the scene. Did Gibson make a >version later on that DID work well on IDE (ATA) >drives? Yep. The current version is 6; available direct from Gibson Research. One google, first hit.
From: Pieyed Piper on 26 Jun 2010 12:25 On Sat, 26 Jun 2010 09:09:51 -0700, Fred Abse <excretatauris(a)invalid.invalid> wrote: >On Fri, 25 Jun 2010 22:44:23 -0700, Robert Baer wrote: > >> ??? 'dd' ??? Whazzat? > >UN*X disk raw read/write utility. Will clone an entire disk, byte-for-byte. That used to be the case, but the new GPT drives are a bit different I think you'll find. And "byte-for-byte" is the wrong claim too. Cylinder-for-cylinder or track-for-track is more correct. If you want a copy of a volume, you do not care what the file system is. If the copy is true, it will get carried. http://www.justlinux.com/forum/showthread.php?threadid=153121
From: Nobody on 26 Jun 2010 22:00 On Sat, 26 Jun 2010 09:25:48 -0700, Pieyed Piper wrote: >>> ??? 'dd' ??? Whazzat? >> >>UN*X disk raw read/write utility. Will clone an entire disk, byte-for-byte. > > > That used to be the case, but the new GPT drives are a bit different I > think you'll find. > > And "byte-for-byte" is the wrong claim too. Cylinder-for-cylinder or > track-for-track is more correct. Or even more correct, "block-for-block". The main difference between "dd" and e.g. "cat" is that "dd" specifically reads/writes blocks of a user-defined size. This can matter if the source or destination is a tape drive, where each read/write operation reads/writes one block, padding or truncating the data as necessary. In many cases "cat /dev/zero > /dev/sdd" will do just as well; the main reason for using dd is that it won't abort on the first error. But if you want to securely erase a drive, use "hdparm --security-erase". That will overwrite remapped sectors, "hidden" areas, etc, while "dd" will only overwrite the parts which are "visible". The feature is supported on all IDE drives made since ~2001 (at which time the largest available IDE drive was 15GB, so any drive larger than that will support it).
From: Robert Baer on 27 Jun 2010 04:20 Grant wrote: > On Fri, 25 Jun 2010 22:44:23 -0700, Robert Baer <robertbaer(a)localnet.com> wrote: > >> Grant wrote: >>> On Fri, 25 Jun 2010 16:57:11 -0400, "Michael A. Terrell" <mike.terrell(a)earthlink.net> wrote: >>> >>>> Grant wrote: >>>>> On Thu, 24 Jun 2010 23:40:18 -0400, "Michael A. Terrell" <mike.terrell(a)earthlink.net> wrote: >>>>> >>>>>> D Yuniskis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> A 501(3)c that I am affiliated with received a donation >>>>>>> of several hundred ~80G SATA/PATA drives the other day. >>>>>>> They have allegedly (?) been bulk erased. I was asked, >>>>>>> today, if there is any way to make the drives serviceable, >>>>>>> again. >>>>>>> >>>>>>> I have not seen the drives or had a chance to play with >>>>>>> any of them. As "proof" that they were bulk erased, I >>>>>>> am told each drive bears a label: >>>>>>> ERASED >>>>>>> Magnetic data is completely erased. >>>>>>> Erased product can't be reused or repaired. >>>>>>> >>>>>>> When *I* take a drive out of service, I "bulk erase" them >>>>>>> (after "electronically" overwriting the existing data) and >>>>>>> then subject them to the 500G drop test :> But, I'll admit >>>>>>> I have never *tried* to recover data from a drive thusly >>>>>>> (ahem) "treated". >>>>>>> >>>>>>> My initial response to them was "recycle them, they're trash". >>>>>>> Was I too hasty? >>>>>>> >>>>>>> I would imagine all the servo information, low level >>>>>>> formatting, bad sector table, etc. are gone or corrupted >>>>>>> so putting these back into service would require "special >>>>>>> factory tools"... >>>>>> There is a software command for newer drives to erase all data. >>>>> Yes, but it takes too long to execute for commercial reality? >>>> Have you ever tried it? >>> No, but the time quoted for secure erase in 'smartctl' report for HDD >>> is similar period to what writing zeroes to entire surface would take. >>> So I 'dd' zeroes to the HDD instead :) >>> >>> Grant. >> ??? 'dd' ??? Whazzat? > > Command line utility on unix-like OS (eg. Linux), dd is a generalised > data transfer utility. Example, write zeroes to entire HDD: > > # dd if=/dev/zero bs=1M of=/dev/sdd > > Decode: # - superuser prompt, if=/dev/zero - input file is endless > stream of zeroes, bs=1M - blocksize is 1MB, of=/dev/sdd - output > file is a particular HDD treated as one big file; no end condition > specified so command runs until output file (the drive) is full. > > Grant. Note the larger the file size, the faster the read or write of that data block (as long as one does not over-run free RAM space with that I/O block). With a measly 1Meg block, it takes LONGER to open the file than to read or write it; try 100Megs or so..
From: Robert Baer on 27 Jun 2010 04:26
Fred Abse wrote: > On Fri, 25 Jun 2010 22:44:23 -0700, Robert Baer wrote: > >> ??? 'dd' ??? Whazzat? > > UN*X disk raw read/write utility. Will clone an entire disk, byte-for-byte. > If true that is infinitely better than Norton's GhostPE which is supposed to be able to a "forensic" copy, but in fact does not. |