Radoslaw, One of the problems I see with Host based overwrite is that you can only overwrite the current location of the logical volume.
If you are using IBM's Eazytier, or Hitachi's HDT you really do not know the past location of the chunks of the volume, only the last location. The same problem exists for volumes copied with volume copy products that dynamically allocate the target address. Once the relationship is removed how do you know where it was and what is left behind. I'm a strong believer in encryption of data at rest. I can't imagine that anything can be assembled from the residual image at the edges of a track when said track is encrypted with a strong key length. A single overwrite will defeat decryption by luck or stealth I would hope that best practice for overwriting a disk array before removal would be to format the drives as useable volume space front to back and overwrite all of those volumes. One pass is enough with encryption at rest, and as many as you feel is enough for data in the clear. Ron > 1. I did mean DISK overwirte. Not some emulated gismo, especially not dasd > arrays like Iceberg/RVA. That's completely different story and - important - > it's still not applicable to number of writes. The problem in such arrays is to > really overwrite the disks, no matter how many times. It's important to > overwirte al least once, but every disk area, each copy. It's more like caution > to delete dataset *and* its copies and backups. > (Disclaimer: spare sectors on HDD is yet another story.) 2. Fun story: some > company used special software to overwrite PC HDDs. > The number of writes was set to 5. Reason: default was 3, "but we want > more security". > 3. Regarding possibility rto read *valuable* information overwritten > once: Such theoretical possibility assumes one use good microscope and > watches single magnetic domain. There is no hidden HDD command like > "read deleted info". And now: what is easier: decrypt encrypted content of > play with 100000000000000000-element puzzle of domains? > > > > -- > Radoslaw Skorupka > Lodz, Poland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
