[Info-vax] ODS-5 data/file recovery

[Stephen Hoffman]

On 2013-02-18 22:21:22 +0000, MG said:

> On 18-feb-2013 12:35, David Froble wrote:
>> In your case, you have several needs that don't seem to be widely
>> available in a weendoze world.  ODS-5 expertise.  Data still being on
>> the disk.
> 
> What are you talking about?  There are tons of undelete tools out
> there for NTFS.  I'm not at all a fan of Windows, but that is just
> a fact.

Allow me to rephrase David's comment...  You need ODS-5 experience 
here, and you also need the data to still be on the disk.  In a world 
that's based on Microsoft Windows (and to a lesser extent Linux, 
Android, OS X, iOS and some others), there's not much ODS-5 experience 
around, and what experience there is will be more expensive.  There 
will be fewer existing tools such as that Windows undelete tools for 
NTFS or FAT, too.  Whether the data is even still on the disk is not a 
certainty.


>> If interested, do your own search for "data recovery".  Might be
>> interesting.
> 
> I did and nothing came up, other than questionable looking sites
> with Wikipedia-like 'generic' information and tacky looking web
> site graphics...

At the risk of stating the obvious, have you tried calling HP support?

But unless you're willing to spend past US$1000 here, and likely well 
past that sum, there's not much point in continuing this part of the 
discussion.

Want to have this stuff available and (relatively) inexpensive?  
Windows or Linux or another platform that's more widely available would 
be a better choice.

This all being the downside of that old adage about OpenVMS being rare 
and its security little-known and thus seldom attacked and supposedly 
therefore more secure, and of not having a profile in the broader IT 
community, too.  But I digress.

Which gets back to learning how to attempt the data recovery yourself 
and then attempting the data recovery, if you really need that file 
back.   Of reading the source code and specs, and understanding what's 
going on within OpenVMS.  Got questions on the source code?  Ask.   
I'll help you learn that, if your questions are interesting.  As will 
others.

On 2013-02-18 22:39:04 +0000, MG said:
> On 18-feb-2013 18:18, gce at gce.com wrote:
>> Your best bet, for a single file, is just to dump the index file
>> to look for some of the filename (or dump a directory and see if file
>> ID may still be there), then follow retrieval pointers by hand (or by
>> tool if a tool works) and copy the data off. You'll want some tool that
>> grabs LBNs and dumps (or if doing this under linux, use dd).
> 
> First of all, thank you very much for your input!  I like the
> idea of using "dd", I will keep that in mind and I might consider
> that.

If BACKUP /PHYSICAL is triggering errors, then dd isn't very likely to 
work either.

> Although, I think that --- like many have suggested --- it's going
> to be a very slight chance and very likely not.  Another painful
> aspect: It's a 1.64 Tbyte volume and it is going to take ages to
> plow through it.  I also feel that the >1 Tbyte support (since V8.4)
> is also still quite timid...  For instance, yesterday the "BACKUP
> /PHYSICAL" failed prematurely and it even screwed up the SCSI
> sub-system (or maybe it was LDD that couldn't handle it, not sure).

All of what's going on here could well be due to a problem with the 
storage hardware, including the original data loss.  Overheating, bus 
errors, flaky devices, termination, etc., can all lead to instability 
and data loss.  SCSI bus errors will toss BACKUP, CIFS and the rest of 
the stack off the rails.



-- 
Pure Personal Opinion | HoffmanLabs LLC