 |
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).
|
|
|
|
|
