Discussion:
Best way to get what I can off a failed VMS Disk?
(too old to reply)
Chris Townley
2020-10-24 12:49:37 UTC
Permalink
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)

What is the best way to recover those files that are recoverable, with
the drive going into mount verify?

Thanks


Chris
geze...@rlgsc.com
2020-10-24 13:09:03 UTC
Permalink
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Thanks
Chris
Chris,

It depends upon the reason for the MOUNT verify. If the problem is one or a few bad blocks, it may be possible to reconstruct by obtaining information from an earlier backup and doing a form of custom merge. It can be done, but it is a tedious process.

For a start, I would try to see if it was possible to MOUNT/FOREIGN/NOWRITE and do a physical BACKUP of the drive.

Before commencing this journey, it is important to consider the importance of the files on the failing disk. If the file can be recovered from a backup without great loss, that is the more economical path. If there are high-value files on the drive in question, the more exotic measures can be considered. There is no generic answer. If only one or a handful of files are of high value, efforts can be undertaken to locate and collect the blocks associated with THAT file or files, and recovering the balance of the data from backups.

- Bob Gezelter, http://www.rlgsc.com
Michael Moroney
2020-10-24 15:37:53 UTC
Permalink
Post by ***@rlgsc.com
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Thanks
Chris
Chris,
It depends upon the reason for the MOUNT verify. If the problem is one or a few bad
blocks, it may be possible to reconstruct by obtaining information from an earlier backup
and doing a form of custom merge. It can be done, but it is a tedious process.
For a start, I would try to see if it was possible to MOUNT/FOREIGN/NOWRITE and do a
physical BACKUP of the drive.
My personal suggestion, if you have the hardware, would be to do the MOUNT/FOREIGN/NOWRITE
and BACKUP/PHYSICAL to a new drive, then do a BACKUP/PHYSICAL to a seccond new drive.

Try to recover from the second backup drive and do all manipulation (such as
ANALYZE/DISK/REPAIR or poking at things like INDEXF.SYS if you know how) only to the
second drive. That way if you somehow make things worse, MOUNT/FOREIGN/NOWRITE the
first backup drive and create the second backup drive again, in other words start over.
That should be the only time the first backup is used, and you'll still have whatever was
pulled off the bad drive the first time. Depending on the exact failure, the original
bad drive may become unusuable after more usage.

I did this when on my hobby system something scribbled all over part of INDEXF.SYS on one
drive and this lost access to many files as well as others became "lost" files when their
directory header got scrozzled. I know the bits would be there until an ANALYZE/DISK/REPAIR
would free any "incorrectly allocated" blocks.

DFU on freeware may also be useful.
abrsvc
2020-10-24 13:18:24 UTC
Permalink
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Thanks
Chris
A lot depends upon the reason for the failure. I have had success replacing the controller board on an SBB drive with another to read the "failing" drive. Both must be the same however.

Any idea where the failure is? Controller, disk itself?
Chris Townley
2020-10-24 13:37:38 UTC
Permalink
Post by abrsvc
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Thanks
Chris
A lot depends upon the reason for the failure. I have had success replacing the controller board on an SBB drive with another to read the "failing" drive. Both must be the same however.
Any idea where the failure is? Controller, disk itself?
It is a hobbyist machine. Only real interest is to save some interesting
bits when I ported the work AXP to I64 - work after my last backup.

SCSI controller is fine - I am booting off that and I have added another
disk.

I will try the backup/physical approach - after chilling the disk!
Presumably followed by anal/disk/repair on the new disk?

Chris
abrsvc
2020-10-24 13:53:54 UTC
Permalink
Post by Chris Townley
Post by abrsvc
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Thanks
Chris
A lot depends upon the reason for the failure. I have had success replacing the controller board on an SBB drive with another to read the "failing" drive. Both must be the same however.
Any idea where the failure is? Controller, disk itself?
It is a hobbyist machine. Only real interest is to save some interesting
bits when I ported the work AXP to I64 - work after my last backup.
SCSI controller is fine - I am booting off that and I have added another
disk.
I will try the backup/physical approach - after chilling the disk!
Presumably followed by anal/disk/repair on the new disk?
Chris
Note of clarification: When I spoke of the controller, I meant the controller card attached to the HD itself. This is usually attached with 4 screws and can be replaced easily. Please note that you should only READ teh device at this time as specific information about the HDD is stored on that card and is unique to each physical device.
geze...@rlgsc.com
2020-10-24 14:51:03 UTC
Permalink
Post by Chris Townley
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Thanks
Chris
A lot depends upon the reason for the failure. I have had success replacing the controller board on an SBB drive with another to read the "failing" drive. Both must be the same however.
Any idea where the failure is? Controller, disk itself?
It is a hobbyist machine. Only real interest is to save some interesting
bits when I ported the work AXP to I64 - work after my last backup.
SCSI controller is fine - I am booting off that and I have added another
disk.
I will try the backup/physical approach - after chilling the disk!
Presumably followed by anal/disk/repair on the new disk?
Chris
Chris,

If you want to try doing a /RECOVER , I would do the BACKUP/PHYSICAL to a save set, and restore the backup onto a new drive to attempt the /RECOVER. I mentioned the BACKUP/PHYSICAL to preserve the information so it could be manually referenced. Doing an automated recovery could make it impossible to take the manual reconstruction path.

- Bob Gezelter, http://www.rlgsc.com
Chris Townley
2020-10-24 15:25:47 UTC
Permalink
Post by ***@rlgsc.com
Post by Chris Townley
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Thanks
Chris
A lot depends upon the reason for the failure. I have had success replacing the controller board on an SBB drive with another to read the "failing" drive. Both must be the same however.
Any idea where the failure is? Controller, disk itself?
It is a hobbyist machine. Only real interest is to save some interesting
bits when I ported the work AXP to I64 - work after my last backup.
SCSI controller is fine - I am booting off that and I have added another
disk.
I will try the backup/physical approach - after chilling the disk!
Presumably followed by anal/disk/repair on the new disk?
Chris
Chris,
If you want to try doing a /RECOVER , I would do the BACKUP/PHYSICAL to a save set, and restore the backup onto a new drive to attempt the /RECOVER. I mentioned the BACKUP/PHYSICAL to preserve the information so it could be manually referenced. Doing an automated recovery could make it impossible to take the manual reconstruction path.
- Bob Gezelter, http://www.rlgsc.com
Good idea - will do

Thanks

Chris
Volker Halle
2020-10-24 15:18:10 UTC
Permalink
Chris,

there is also the DISKBLOCK freeware tool. You could mount the disk /FOREIGN/NOWRITE and then access files, as long as the file headers in the index file are readable. You can search for file names in the index file and COPY individual files from that disk to another disk.

You'll find DISKBLOCK on the OpenVMS Freeware CDs, the most recent version (V6.3) can be found on:

https://eisner.decuserve.org/~halle/

Volker.
Phillip Helbig (undress to reply)
2020-10-24 15:41:03 UTC
Permalink
Post by Chris Townley
It is a hobbyist machine. Only real interest is to save some interesting
bits when I ported the work AXP to I64 - work after my last backup.
If you have a hobbyist license, you have a license for HBVS. You need a
new disk anyway. So try to see if you can form a volume set.
Phillip Helbig (undress to reply)
2020-10-24 15:41:56 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Chris Townley
It is a hobbyist machine. Only real interest is to save some interesting
bits when I ported the work AXP to I64 - work after my last backup.
If you have a hobbyist license, you have a license for HBVS. You need a
new disk anyway. So try to see if you can form a volume set.
volume set ---> shadow set
Chris Townley
2020-10-24 15:55:01 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Phillip Helbig (undress to reply)
Post by Chris Townley
It is a hobbyist machine. Only real interest is to save some interesting
bits when I ported the work AXP to I64 - work after my last backup.
If you have a hobbyist license, you have a license for HBVS. You need a
new disk anyway. So try to see if you can form a volume set.
volume set ---> shadow set
Yes - never done that. Just ordered 2 more disks, and reading the manual


thanks

Chris
Phillip Helbig (undress to reply)
2020-10-24 17:41:45 UTC
Permalink
Post by Chris Townley
Post by Phillip Helbig (undress to reply)
Post by Phillip Helbig (undress to reply)
If you have a hobbyist license, you have a license for HBVS. You need a
new disk anyway. So try to see if you can form a volume set.
volume set ---> shadow set
Yes - never done that. Just ordered 2 more disks, and reading the manual
Example:

$ MOUNT/CLUSTER/NOASSIST/CONFIRM DSA400 -
/SHADOW=($110$DKA100:,$120$DKB200:) <label>

This will give a -F- message, which is confusing, to say the least, but
you can see the source and copy disk and confirm.

You do need to have allocation classes set up. If I recall correctly,
they are required for shadow-set members not for the original reason of
allocation classes (dual-ported disks), but rather because of the length
and/or format of the disk name.

Note that the members can be on different controllers or even different
nodes. In fact, that is a big advantage of HBVS, above being able to
swap out disks on a running system. You can reboot a node and have the
shadow set continuously available. You can even have the nodes
separated by large distances (at least several kilometres). The members
don't have to be of the same physical size, and you can dynamically
expand to larger sizes.

However, if you don't have allocation classes set up, you'll have to
reboot.
Phillip Helbig (undress to reply)
2020-10-24 15:39:35 UTC
Permalink
Post by Chris Townley
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)
That is one thing HBVS is good for.
Post by Chris Townley
What is the best way to recover those files that are recoverable, with
the drive going into mount verify?
Before things get any worse, try to make a shadow set out of it then get
rid of the bad disk (and then at the latest add a second good disk to
the shadow set; you can have up to 6 members).
Scott Dorsey
2020-10-24 15:49:16 UTC
Permalink
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)=20
What is the best way to recover those files that are recoverable, with=20
the drive going into mount verify?=20
With modern disks, once you start seeing bad blocks, the problem has been
going on for a long time and bad block replacement has been taking place
inside the drive and you're only seeing bad blocks because the drive is
so far gone that it can't do bad block replacement anymore.

Get a drive image as soon as possible. You can do it on the Alpha, you
can pull it off and put it on a PC with Clonezilla or with dd, although
the best thing to do is to drop it into one of the offline disk duplicators.

Every minute you run the drive it's getting worse and worse... your goal
is to get an image done as quickly as possible so as little as possible
is lost.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Chris Townley
2020-10-24 15:57:19 UTC
Permalink
Post by Scott Dorsey
I have a failing ODS-2 disk in my Alpha (HPE VMS 8.3)=20
What is the best way to recover those files that are recoverable, with=20
the drive going into mount verify?=20
With modern disks, once you start seeing bad blocks, the problem has been
going on for a long time and bad block replacement has been taking place
inside the drive and you're only seeing bad blocks because the drive is
so far gone that it can't do bad block replacement anymore.
Get a drive image as soon as possible. You can do it on the Alpha, you
can pull it off and put it on a PC with Clonezilla or with dd, although
the best thing to do is to drop it into one of the offline disk duplicators.
Every minute you run the drive it's getting worse and worse... your goal
is to get an image done as quickly as possible so as little as possible
is lost.
--scott
I haven't powered it up since I first noticed the errors, and a copy
caused mount verification.

No SCSI adapters in my PC, so will have to look at it under VMS!

Chris
Phillip Helbig (undress to reply)
2020-10-24 17:34:29 UTC
Permalink
Post by Scott Dorsey
Get a drive image as soon as possible. You can do it on the Alpha, you
can pull it off and put it on a PC with Clonezilla or with dd, although
the best thing to do is to drop it into one of the offline disk duplicators.
Would forming a shadow set be slower than an offline disk duplicator?
Simon Clubley
2020-10-24 18:11:21 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Scott Dorsey
Get a drive image as soon as possible. You can do it on the Alpha, you
can pull it off and put it on a PC with Clonezilla or with dd, although
the best thing to do is to drop it into one of the offline disk duplicators.
Would forming a shadow set be slower than an offline disk duplicator?
Will forming a shadow set cause random I/O all over the failing
disk or will the disk be read exactly once from start to finish
in strict sequential order without any additional I/Os ?

Lots of extra random I/O is very bad on a failing disk.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
geze...@rlgsc.com
2020-10-24 19:12:43 UTC
Permalink
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Get a drive image as soon as possible. You can do it on the Alpha, you
can pull it off and put it on a PC with Clonezilla or with dd, although
the best thing to do is to drop it into one of the offline disk duplicators.
Would forming a shadow set be slower than an offline disk duplicator?
Will forming a shadow set cause random I/O all over the failing
disk or will the disk be read exactly once from start to finish
in strict sequential order without any additional I/Os ?
Lots of extra random I/O is very bad on a failing disk.
Simon.
--
Walking destinations on a map are further away than they appear.
Phillip and Simon,

SHADOW copies are probably not a good idea.

For a start, one must be able to MOUNT the disk to do create a shadow set.

What is wanted is something that needs the least validity from the problematic drive. That is BACKUP/PHYSICAL, a block-by-copy, ignoring the file structure.

- Bob Gezelter, http://www.rlgsc.com
Phillip Helbig (undress to reply)
2020-10-24 21:54:28 UTC
Permalink
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Would forming a shadow set be slower than an offline disk duplicator?
Will forming a shadow set cause random I/O all over the failing
disk or will the disk be read exactly once from start to finish
in strict sequential order without any additional I/Os ?
There are shadowing experts here who might reply. I believe it moves
sequentially through the source, writing to the target, and keeping
track of what portions were updated since the begin of the copy, then
after the initial pass updates those sections, and so on, until it
converges. I forget how large these sections are, but there is a bitmap
(used for MINICOPY and MINIMERGE as well) which keeps track of whether
that section needs to be updated or not, and if so the whole section is
copied. (This is a balance between writing too much unnecessary stuff
and having a bitmap as large as the disk itself.)
Jan-Erik Söderholm
2020-10-24 22:08:37 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Would forming a shadow set be slower than an offline disk duplicator?
Will forming a shadow set cause random I/O all over the failing
disk or will the disk be read exactly once from start to finish
in strict sequential order without any additional I/Os ?
There are shadowing experts here who might reply. I believe it moves
sequentially through the source, writing to the target, and keeping
track of what portions were updated since the begin of the copy, then
after the initial pass updates those sections, and so on, until it
converges. I forget how large these sections are, but there is a bitmap
(used for MINICOPY and MINIMERGE as well) which keeps track of whether
that section needs to be updated or not, and if so the whole section is
copied. (This is a balance between writing too much unnecessary stuff
and having a bitmap as large as the disk itself.)
Why would a single bit in the bitmap point to a smaller part of the disk
than the smallest writeable part (a block, a cluster or whatever)? Can
you write anything less than a 512 byte block?

But anyway, the whole shadowing thing depends on that the source disk
can be mounted, and it couldn't, if I understood correctly.
Phillip Helbig (undress to reply)
2020-10-25 04:38:20 UTC
Permalink
Post by Jan-Erik Söderholm
Why would a single bit in the bitmap point to a smaller part of the disk
than the smallest writeable part (a block, a cluster or whatever)? Can
you write anything less than a 512 byte block?
The regions mapped by the bitmap consist of several blocks.
Post by Jan-Erik Söderholm
But anyway, the whole shadowing thing depends on that the source disk
can be mounted, and it couldn't, if I understood correctly.
Right.
Craig A. Berry
2020-10-24 22:24:05 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Would forming a shadow set be slower than an offline disk duplicator?
Will forming a shadow set cause random I/O all over the failing
disk or will the disk be read exactly once from start to finish
in strict sequential order without any additional I/Os ?
There are shadowing experts here who might reply.
And they've already said, "Don't do that!" BACKUP/PHYSICAL will be safer.
Stephen Hoffman
2020-10-25 18:29:31 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Phillip Helbig (undress to reply)
Would forming a shadow set be slower than an offline disk duplicator?
Yes.

On OpenVMS, this speed differential goes all the way back to the HSC50
controller (if not before), where a controller-level storage-cloning
operation is substantially faster than a host-based clone.

HSC50 is the first OpenVMS-supported storage controller I'm aware of
that had a controller-level cloning feature, but there may have been
earlier examples. And it was wicked fast. That with disk-to-disk, and
disk-to-tape.
Post by Phillip Helbig (undress to reply)
Will forming a shadow set cause random I/O all over the failing disk or
will the disk be read exactly once from start to finish in strict
sequential order without any additional I/Os ?
Yes, host-based volume shadowing HBVS will churn I/O. And the source
volume has to be mounted read-write, and I'd rather not write to a
failing hard disk drive.

And HBVS will attempt to re-vector failing blocks after attempting
re-reading with the failing blocks, and it's somewhere between possible
and quite likely that the re-vectoring attempts will fail due to the
depletion of spares.

And that assumes that a corrupt source volume doesn't abort the HBVS
virtual unit formation, and as I'd expect would happen here.
Post by Phillip Helbig (undress to reply)
There are shadowing experts here who might reply.
I would not use shadowing for failing-storage-hardware volume recovery. Nope.

BACKUP /PHYSICAL, dd, COPY, controller-level cloning if that's
available, or other data-recovery-related tools (DISKBLOCK) that are
intended and coded to be somewhat more tolerant of errors in the source
data are the path. This with the source mounted write-locked, and
usually also mounted foreign.

DISKBLOCK063 was here: http://eisner.encompasserve.org/~halle/





Some semi-related reading:

wiz_6926.txt:
Disk Bad Block Processing?
The Question is:

Header.
How operate-correct with SCSI disks or give him a second chance to be useful ,
while error count is growing up, badlog.sys rize and particial files cannot
accessed. Illus here.
-----------------------------------------------
Meaning of question.
1. Are the Bad Block Locator Utility(Analize/Media DCL coomand) is now obsolete
for this type(SCSI) device or not? Is this utility insert,automaticaly, bad
blocks
location(placement) in file on tested volume:
ddccu:[mfd]badblk.sys, to avoid a problem whith
using trusted pplaces.
2. Are the Analise/disk is now obsolete for this type(SCSI) device or not? Is
this utility insert,automaticaly, bad blocks location(placement) in file on
tested volume:
ddccu:[mfd]badlog.sys, to avoid a problem whith
using trusted pplaces.
-----------------------------------------------
I desire to be sure what i have workable tools,
even if it is from maintanance Tool kit.
Some Thing like annoing MS Scandisk. This is problem for me, becouse i am not
sure with data
integrityn whith all ot these RAID-nn solution, while logical fault from
ordinary file, which is represent entry level of data input, may destroy all
deepthinkig secure system.
-----------------------------------------------
It will be good, what storage device self repaire this problem like DSSI and
HSC, e.t.c.,
but it is good to have transparent ability and
possibility to assuranse.

With best regards ans great respect from long term VMS worshipper.
Live long and prosper.

The Answer is :

The ANALYZE/MEDIA (BAD) utility, BAD*.SYS files, and the related tools are
typically not required on modern disks; OpenVMS, the controllers and/or the
disks transparently and volume shadowing or a RAID controller all conspire
provide the appearance of a logically perfect storage medium. That said,
there are cases where the BADBLK.SYS file will be used to store bad blocks.

Failing disk blocks are typically revectored to spare blocks as failing
(or failed) blocks are detected, usually on write verify or on detection
of corruption on read. The implementation details do differ depending on
the particular disk device involved, and can involve the disk device, the
controller, and/or the host operating system software.

With more recent SCSI devices and OpenVMS V6.2 and later, the AWRE
(Automatic Write REmapping) and ARRE (Automatic Read Remapping) mechanism
is available -- when disabled, the host handles the revectoring. When
AWRE is enabled, the controller and the disk handle bad blocks and the
drive appears perfect (until there are more bad blocks than spare blocks).

When accessing a directly-connected disk with AWRE and ARRE disabled,
OpenVMS performs the defect management.

If on a SCSI disk WRITE (using the XQP or using host-based shadowing) a
hard error is encountered, OpenVMS will issue a REASSIGN command to the
disk and the disk will revector the block, adding the bad block to its
"GLIST" -- this is the SCSI equivalent of the DSA structure known as the
Replacement and Caching Table (RCT). If the defect list is full or if
the disk is incapable of REASSIGN, OpenVMS then marks the block bad in
BADBLK.SYS.

If on a SCSI disk READ a hard error is encountered and the disk is a
member of a volume shadowset, then the data is read from another shadowset
member and returned to the user without error. A REASSIGN is issued against
the failing block, and the good data is written back to the disk. This
causes known-good data to be written into a new block, and the failing
block is added to the GLIST.

If on a SCSI disk READ a hard error is encountered and the disk is not
a member of a volume shadowset, the data is lost, and a parity error
(SS$_PARITY) error is returned. A REASSIGN cannot be issued against
the bad block, because there is no good data for the new block. OpenVMS
will set a forced-error flag in the file header, and an associated error
(SS$_FORCEDERROR) will be reported to accessors.

Upon the deletion of a file with a forced error, OpenVMS will start with
the last block of the file and work backwards until it finds the bad block.
VMS will attempt to issue a REASSIGN if the device is capable of it.
If the defect list is full or the device is incapable of REASSIGN
commands, then OpenVMS will add the bad block into BADBLK.SYS.

If a file on a SCSI device is not processed using volume shadowing
or the XQP, the bad block cannot be corrected. The system pagefile
-- when operating on a volume that is not shadowed -- is an example
of a file access that does not use the XQP, and that thus cannot be
revectored. Thre ability of OpenVMS to revector bad blocks under
the pagefile or other non-XQP-accessed file requires the re-creation
of the file, while the ability to tolerate and to recover from such
disk errors without the re-creation of the file requires the use of
host-based volume shadowing or of controller-based RAID.

Related tools include the (Freeware) RZDISK and the ANALYZE/MEDIA tools.

RAID storage controllers and host-based volume shadowing and similar
constructs are all intended to reduce the effects of hardware failures
on the host operating system and to particularly return good data to
the host (and to the revector) in the event of uncorrectable disk block
errors.

BADLOG.SYS is used as a repository of (potentially) failing disk blocks.
Known-bad blocks are stored in BADBLK.SYS.

You can request a scan of bad blocks (using BADBLOCK_SCAN) during file
deletion, by setting the FH2$V_BADBLOCK bit in the file header.

DSA disks provide a forced-error flag, SCSI devices do not -- this means
that reads can report data errors only on DSA disks.

The ANALYZE/DISK utility verifies the file structure. The other central
component involved in this area is the BACKUP utility, as this is one of
the core tools to recover from errors.

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

If you want to overwrite or erase the data on the media for reasons of
security or other related reasons, related topics include (841), (3926),
(4286), (4598), and (7320). (Do note that ANALYZE/MEDIA (BAD) will save
and will write the addresses of bad blocks into a low-level on-disk
structure known as the Detected Bad Block File (DBBF), which will mean
that there will potentially be one or more blocks on a disk that will
not contain the erasure pattern even after a full BAD pass. This is
documented in the ANALYZE/MEDIA (BAD) manual.)

Answer written or last revised on 25-OCT-2004
--
Pure Personal Opinion | HoffmanLabs LLC
Michael Moroney
2020-10-25 17:23:01 UTC
Permalink
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Post by Scott Dorsey
Get a drive image as soon as possible. You can do it on the Alpha, you
can pull it off and put it on a PC with Clonezilla or with dd, although
the best thing to do is to drop it into one of the offline disk duplicators.
Would forming a shadow set be slower than an offline disk duplicator?
Will forming a shadow set cause random I/O all over the failing
disk or will the disk be read exactly once from start to finish
in strict sequential order without any additional I/Os ?
Lots of extra random I/O is very bad on a failing disk.
Yes, shadowing will cause excessive I/Os.

Shadowing uses an algorithm for copy/merge that doesn't require the file that the blocks
being copied represent to be locked against modification, but it requires read/compare as
well as writes to verify the file system hasn't done anything. MOUNTing the disk into the
shadowset and adding the new drive(s) also causes a few writes to the original disk which
you want to avoid.

Mount the bad disk read-only and use BACKUP/PHYSICAL to another drive or saveset.
BACKUP/PHYSICAL is also quicker than a shadow copy.

(aside: in my previous suggestion for using two disks, you can use a saveset instead of
the first disk if that's easier for your configuration)
Scott Dorsey
2020-10-24 19:27:12 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Scott Dorsey
Get a drive image as soon as possible. You can do it on the Alpha, you
can pull it off and put it on a PC with Clonezilla or with dd, although
the best thing to do is to drop it into one of the offline disk duplicators.
Would forming a shadow set be slower than an offline disk duplicator?
That's a good question.

Just about everything is slower than the offline disk duplicator. It usually
copies a disk in a good bit less time than doing a dd on the computer, but
to be honest I have no idea why. I don't know how fast the shadow set
rebuilds, either. I would be surprised if it rebuilt as fast as a direct
volume copy but I never timed it or watched the operations.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Simon Clubley
2020-10-25 17:10:33 UTC
Permalink
Post by Scott Dorsey
Just about everything is slower than the offline disk duplicator. It usually
copies a disk in a good bit less time than doing a dd on the computer, but
to be honest I have no idea why. I don't know how fast the shadow set
rebuilds, either. I would be surprised if it rebuilt as fast as a direct
volume copy but I never timed it or watched the operations.
--scott
What is the block size on your dd command ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Loading...