On Gibson Research website - grc.com, there is a description as to how
their SpinRite product works, and why it is needed. This also complicates
ensuring that data is unrecoverable.

Data is "lost" over time when the data marks get out of alignment with the
address marks. At least two reasons for this:
1) slight mechanical wear where the arm pivots
2) data written mostly in one direction of the arm.

If patterns are written to disk but always when arm is moving in one
direction, pieces can remain unchanged.

I, unfortunately, had the opportunity to test SpinRite's data recovery
process on a personal computer hard drive. The heads are wiggled many
times over problem areas to correct for misalignment of prewritten sector
marks (from formatting) and data marks from many writes. I was able to
recover most of the data from that failed drive. My conclusion is that
three patterns need to be written to each sector AND the direction the
heads move needs to be reversed and the three patterns written again to
ensure that data will be unrecoverable. I am wondering if the disk
sanitizer programs do that.

John McKee

On Wed, Mar 5, 2014 at 11:42 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 04-Mar-2014 18:30 -0800, DrFranken wrote:
On 3/4/2014 9:00 PM, Jerome Draper wrote:

Suggestions for doing a DOD erase of an IBMi?

1. PRPQ Disk Sanitizer
2. Map a drive and use a Windows disk clean pgm
3. Boot Linux and use a Linux disk clean pgm
4. Other solution?

I Used this logic to clean up a few different systems now.

Delete all user identifiable information:
<<SNIP list>>

The theory here being you still have on the system ONLY the stuff
that is IBM and it was on the disk before so the places it occupies
are not critical to a data wipe.

The theory is, unfortunately, flawed. There is a significant amount
of potential for "user" information to remain in inconspicuous places.
Essentially, ensuring all of the tasks required to literally "delete all
user identifiable information" is exhaustive, is very difficult and
certainly requires an even more extensive list; and I even expect, that
a much more extensive list might still miss some. If there is a true
requirement to ensure user information is not on the disks, I recommend
against trying to RYO process.

Now use a small program to write records of 1K Bytes using binary
pattern '11111111'. Fill up the system until the disks are full
99.9%. I used multiple copies of the file in different libraries and
ran as many as possible until the disks were all being hammered
pretty good.

Now clear the files (Faster to clear and re-write than to overwrite
the records.)

Now write pattern 01010101.
Repeat with pattern 10101010.
Repeat with pattern 0000000.

When you think you've written enough patterns, manual IPL to an i
7.1 DVD and install the LIC. Then add all disks to the ASP to write
a final pattern of 0's to all of them.

Specifically a scratch install of the LIC and OS prior to running
that program would be much more appropriate, to ensure at least one
overwrite of all information. Much simpler than trying to devise a
truly comprehensive list of tasks to eliminate user information which is
IMO a fool's errand.

Alternatively you could instead do:

D-IPL from DVD.
Install the LIC.
Stop all RAID
Add all units to ASP
This step will make one pass over the disks writing 0's. So that's
pretty much got it there already as we know but not DOD level.

I infer that implies a scratch-install, whereby the LIC is actually
being installed after the disks are initialized. Otherwise, part of the
issue regarding user information never being overwritten remains.

Then run the program as listed above.

... requiring that the install continued, to include the OS.

Regards, Chuck
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page