|
HP OpenVMS Systemsask the wizard |
|
The Question is: The company I worked for would like to erase the operating system on our vax 6100 ver 5.5. Can this be accomplished without booting from an external peripheral,such as a tape drive. How about booting to the sys$boot>>> prompt to erase the system drive. And if so, How can it be done. Have a beautiful day. jahi The Answer is : Various intelligent storage controllers can potentially contain erasure capabilities, as can the diagnostics available on a few system consoles, and these may or may not meet local data security requirements -- some sites require pattern-based erasures, and will sometimes require rather more stringent procedures to avoid the unintended release of data. (Integrated media self-destruct mechanisms are one obvious and specialized area of the storage media market.) For a simple host-based erasure, you will have to perform a bootstrap of diagnostic software, or a bootstrap of OpenVMS itself from a bootable device (other than from a disk targeted for erasure), or (if the particular system supports it) a console disk initialization diagnostic, or (if available) from a bootable media diagnostic tool. Your suggestion of incorporating at least some basic disk erasure capabilities into the SYSBOOT utility or into an alternate secondary bootstrap is an interesting one, but such support is not currently available. And such host-based erasure support may or may not suffice for site-specific requirements, given particular features of modern storage media and controllers. As one complication to media erasure, both MSCP and SCSI disks support a process known as bad block revectoring. This is a process by which the host or even the device can detect a bad block, and can replace it with a spare block -- devices with this support will contain a device-specific number of extra blocks that are effectively hidden from the host, and these blocks can be used to replace bad physical blocks found in the host-accessable portion of the media. The host thus references all blocks using logical access, and never sees that its I/O references can be redirected away from any underlying bad physical blocks found on the media. There is presently no standard way to access the entire range of blocks present on a physical SCSI disk, and no certain way to overwrite the contents of these bad blocks. (With MSCP disks, access to the replacement caching table (RCT) is permitted.) Because of the bad block revectoring, secure media erasure usually involves degaussing (above the required magnetic coorcivity for the media; applying a magnetic field in excess of the media-specific Oersted rating) and then potentially grinding and "slagging" the media. This mechanical destruction to avoid releasing information stored in one of these revectored bad blocks -- these (bad) blocks are potentially still readable, given appropriate access to the media. (Though RCT access is permitted on MSCP media, reliable write access to the revectored (bad) blocks is rather obviously an activity that is likely to be generally somewhat less than successful.) In addition to the potential to access the contents of blocks marked as bad, it is also potentially feasible to read the contents of an erased block by aligning more sensitive read heads slightly off the track location, and reading any magnetic "splatter" that was not completely overwritten by a pattern erasure -- this is one of the reasons that sites concerned about data remanence can require multiple media erasure passes, each often using a different bit pattern. And quite obviously, not all customers have the same level of concern over the release of the contents of the media -- something like the provided $ERAPAT erasure mechanism and the INITIALIZE/ERASE command can suffice for certain customers. Related discussions include (841), (3926), (4286), (4598), (7320). Topics specific to unintential initialization or the overwriting of disk and tape media include (1286) and (6990). For errors resulting from file structure, directory structure, or file structure corruptions, please see topics such as (1213), (4088), (4571), (5071), (5553), (5719), (6021), (6234). Disk bad block handling is discussed in topic (6926).
|