Erase the Contents of a Volume

Safe Data Storage

Sometimes it is necessary to erase the contents of a volume either before or after it is put into use in an OpenVMS environment. This can be driven by corporate rules and regulations. The need to erase the data can be driven by the need to follow governmental rules and regulations. And as we all know, it can be driven by the need to protect secrets.

Whatever the driving force behind the need to protect the contents of a volume, the use of SAN storage greatly complicates this issue. For example, how do you ensure the data is fully protected from scavenging of data in an environment that might move from location to location?  Let’s expand upon this with two different storage array technologies.

EVA Storage Arrays

EVA Storage Arrays provide virtual RAID volumes. The advantage of this approach is that the volume is automatically spread across as many physical spindles as possible to decrease the utilization of any single spindle and thus decrease the overall response time from all physical spindles.

Unfortunately, this also implies the data will migrate from physical volume to physical volume. What happens if a physical disk fails? Can we guarantee the data on that volume has been properly erased, even if we performed an INITIALIZE/ERASE using the DoD erasure pattern?

Update on 2008/08/10: I put on my thinking cap on this, and realized there are two potential solutions to this issue with the EVA storage arrays. First, the EVA Storage Array can be used to contain similar data. Second, if a mixed environment is needed (such as patient information mixed with user data storage), then a separate disk group to contain the sensitive data can be used. This helps isolate the data within the EVA storage array.

For most sites, destruction of that failed physical spindle would probably suffice. But some sites might need to be able to ascertain the contents of the physical disk. In those situations, virtual raid technology, such as the EVA Storage Arrays might not be the best choice.

For most OpenVMS installations (probably over 98% of them), this is not an issue. However, since many in the OpenVMS community must deal with sensitive data of various levels, it is important to realize this could be an issue.

XP Disk Arrays

XP Disk Arrays do offer the chance to better control the contents of the physical volumes. While the data can be spread across numerous physical disks, the assignment of the data to specific physical disks is completely up to the SAN administrator. This would allow a customer, who handles sensitive data, to assign a specific pool of physical disks to handle the sensitive data.

Additionally, you can purchase software to provide Data Shredding for XP Disk Arrays. There are several advantages to this. First, it ensures data presented to various hosts follow corporate / regulatory guidelines. Second, the work is done outside of the host environment. Though INITIALIZE/ERASE with the DoD erasure pattern can do the same, with very large volumes, the time required is extensive. Performing this operation on the array allows the array to completely offload the work from the host.

Some Pointers

The following pointers might provide a better understanding of this information.

HP ITRC OpenVMS Forum Discussion about DoD Erasure Pattern Usage

HP StorageWorks XP Data Shredder Software

Finally, if all else fails, turning the physical disk drive into a nonfunctional drive is an option:

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: , , ,

  1. jbf’s avatar

    Thanks to Bill Pedersen, who noted I originally wrote “fully protected from savaging of data”. As he notes, it should read (and is now corrected to read) “fully protected from scavenging of data”. So, either we’re savaged for not protecting the data from scavengers, or I’m savaged for a typo! :) [Okay, I admit, stupid humor!] Seriously, thanks to everyone for taking the time to help make this better for the whole OpenVMS community.