hard disk crash

[Jose Tabisi]

I am working with SCO Unix 5.0.4, using two disks, the second one with
a removable bay so that I can use for backup purposes. By mistake we
powered on the machine with both disks connected as master disks to
the same IDE controller. This usually meant that the machine would not
start until that problem got corrected, but this time it somehow
managed to start and then finally crashed after a while. Both disks
have a DOS and UNIX partition, and the UNIX partition have /root and
/u divisions defined.

Now the situation is that both disks have lost the partition
information and I can not access them in any way. I have searched and
downloaded some demo programs available in Internet and I have been
able to scan, list and even recover files which reside in the DOS
partition. However, none of these programs seem to be able to
recognize HTFS files. Both disks seem to be both physically and
logicaly intact, the BIOS finds them OK and the scanning of the
programs do not end with an error condition.

What I do have available are the root and boot disks. What I do not
have are either partition information and the divisions info. All I
really need is the information which resides in the /u division of the
UNIX partition, the rest of the disk I don´t care.

Any comments and suggestions will be highly appreciatted.

[tony@aplawrence.com]

Jose Tabisi <josetabisi@tecnitower.com.ar> wrote:

>What I do have available are the root and boot disks. What I do not
>have are either partition information and the divisions info. All I
>really need is the information which resides in the /u division of the
>UNIX partition, the rest of the disk I don´t care.

>Any comments and suggestions will be highly appreciatted.

Do an install on another drive, mount this drive as a secondary, copy
away. See [url]http://aplawrence.com/Unixart/recover42.html[/url] for an
example.


--
[email]tony@aplawrence.com[/email] Unix/Linux/Mac OS X resources: [url]http://aplawrence.com[/url]
Get paid for writing about tech: [url]http://aplawrence.com/publish.html[/url]

[Bob Bailin]

"Jose Tabisi" <josetabisi@tecnitower.com.ar> wrote in message
news:c8f61b71.0307231201.35e923c0@posting.google.c om...

> I am working with SCO Unix 5.0.4, using two disks, the second one with
> a removable bay so that I can use for backup purposes. By mistake we
> powered on the machine with both disks connected as master disks to
> the same IDE controller. This usually meant that the machine would not
> start until that problem got corrected, but this time it somehow
> managed to start and then finally crashed after a while. Both disks
> have a DOS and UNIX partition, and the UNIX partition have /root and
> /u divisions defined.
>
> Now the situation is that both disks have lost the partition
> information and I can not access them in any way. I have searched and
> downloaded some demo programs available in Internet and I have been
> able to scan, list and even recover files which reside in the DOS
> partition. However, none of these programs seem to be able to
> recognize HTFS files. Both disks seem to be both physically and
> logicaly intact, the BIOS finds them OK and the scanning of the
> programs do not end with an error condition.
>
> What I do have available are the root and boot disks. What I do not
> have are either partition information and the divisions info. All I
> really need is the information which resides in the /u division of the
> UNIX partition, the rest of the disk I don´t care.
>
> Any comments and suggestions will be highly appreciatted.

Not to belabor the obvious, but wouldn't it be easier to restore from
a recent backup?

[Steve Fabac]

Jose Tabisi wrote:

>
> I am working with SCO Unix 5.0.4, using two disks, the second one with
> a removable bay so that I can use for backup purposes. By mistake we
> powered on the machine with both disks connected as master disks to
> the same IDE controller. This usually meant that the machine would not
> start until that problem got corrected, but this time it somehow
> managed to start and then finally crashed after a while. Both disks
> have a DOS and UNIX partition, and the UNIX partition have /root and
> /u divisions defined.
>
> Now the situation is that both disks have lost the partition
> information and I can not access them in any way. I have searched and
> downloaded some demo programs available in Internet and I have been
> able to scan, list and even recover files which reside in the DOS
> partition. However, none of these programs seem to be able to
> recognize HTFS files. Both disks seem to be both physically and
> logicaly intact, the BIOS finds them OK and the scanning of the
> programs do not end with an error condition.
>
> What I do have available are the root and boot disks. What I do not
> have are either partition information and the divisions info. All I
> really need is the information which resides in the /u division of the
> UNIX partition, the rest of the disk I don´t care.
>
> Any comments and suggestions will be highly appreciatted.

If the data on these disks is valuable to you, get professional help.

If you have the necessary records then try these steps:

1) Boot the Emergency boot/root floppies and use fdisk to setup the
UNIX partition with start block and size identical to the settings used
for the original install. If you're lucky, divvy should show you the
original division table. If you see the original division table. try
'mount -r /dev/u /mnt' to see if you can see the files. If you can
see the u files, re-install UNIX on the other disk and recover the
files by mounting the recovered disk's "u" division.

2) If divvy does not show the division table, you may have entered the
wrong partition start and size, or the divvy table may be destroyed.
If you are brave, run "mkdev hd 0 0" and setup a new division table
with the information from your records for the divisions.

>Be sure to "prevent" creation of new file systems on the divisions<

as creating new file systems will destroy any hope of recovering your
data. You must be able to run fsck on the "u" file system without
getting an overwhelming number of errors. I would be happy with less
then 10-20 un-referenced files. I would be suspicious I see a lot
of DUP blocks and or unrealistic file sizes.

3) If you can successfully mount /dev/u from the emergency boot floppy
set, reinstall UNIX on a new hard disk, then recover your files from
the restored disk.

NOTE: The above steps can be destructive if you make a mistake. You
should purchase a new disk that is identical to the original 2 disks
and use a disaster recovery product that will sector copy all data
from one of the original disks to the "working" disk. Only work on the
third disk. That way, if you butch the recovery on the new disk, you
need only repeat the copy and try again.

[url]http://www.just-data-recovery-links.com/partition_partition_recovery_table_tool.html[/url]

Good luck.

P.S. Thanks for your post. I will print it and pass out copies to anyone
trying to save money by omitting a good tape backup system on their
UNIX server.


--

Steve Fabac
S.M. Fabac & Associates
816/765-1670

[Scott McMillan]

On Thu, 24 Jul 2003 16:46:21 GMT, Steve Fabac <smfabac@att.net> wrote:

>Jose Tabisi wrote:

>>
>> I am working with SCO Unix 5.0.4, using two disks, the second one with
>> a removable bay so that I can use for backup purposes. By mistake we
>> powered on the machine with both disks connected as master disks to
>> the same IDE controller. This usually meant that the machine would not
>> start until that problem got corrected, but this time it somehow
>> managed to start and then finally crashed after a while. Both disks
>> have a DOS and UNIX partition, and the UNIX partition have /root and
>> /u divisions defined.
>>
>> Now the situation is that both disks have lost the partition
>> information and I can not access them in any way. I have searched and
>> downloaded some demo programs available in Internet and I have been
>> able to scan, list and even recover files which reside in the DOS
>> partition. However, none of these programs seem to be able to
>> recognize HTFS files. Both disks seem to be both physically and
>> logicaly intact, the BIOS finds them OK and the scanning of the
>> programs do not end with an error condition.
>>

<snipped helpful stuff from Steve>

>
>P.S. Thanks for your post. I will print it and pass out copies to anyone
>trying to save money by omitting a good tape backup system on their
>UNIX server.

ROTFL!! I was just about to do the same thing! Thanks for the grin,
Steve, I needed one today :-)


Scott McMillan

[Jose Tabisi]

Thanks Steve

Regarding your post scriptum, it looked like a good solution until it
failed. I had bad experiencies with tape backups in the past, of
course now I regret not having other backups around.

Back to your message, I did send the main disk to an expert, there are
not as many choices here as there are there, and I hope to have made
the right choice, I will know soon.

However I have kept the second disk and keep on working on it. I
downloaded a disk editor for windows, mounted the unix disk as
secondary and looked at the info, it seems to be still there.

I was tring to figure what the original partitions were because I
really do not know. Unix data seems to start somewhere around cylinder
750, which makes perfect sense considering /boot must lie within the
first 1024 cylinders of the disk for Unix to be able to start. I then
mounted the disk as secondary with a working Unix as master disk and
tried different fdisk partitions followed by 'divvy /dev/hd10'. So far
I have not been succesfull, maybe there's something wrong with my
reasoning.

If I did try, for example, using the whole disk for the Unix partition
(which was not the original partition), is there any chance I can get
back the data ? Any ideas ? Thanks for your help

Steve Fabac <smfabac@att.net> wrote in message news:<3F1FB8FA.72D65064@att.net>...

> Jose Tabisi wrote:

> >
> > I am working with SCO Unix 5.0.4, using two disks, the second one with
> > a removable bay so that I can use for backup purposes. By mistake we
> > powered on the machine with both disks connected as master disks to
> > the same IDE controller. This usually meant that the machine would not
> > start until that problem got corrected, but this time it somehow
> > managed to start and then finally crashed after a while. Both disks
> > have a DOS and UNIX partition, and the UNIX partition have /root and
> > /u divisions defined.
> >
> > Now the situation is that both disks have lost the partition
> > information and I can not access them in any way. I have searched and
> > downloaded some demo programs available in Internet and I have been
> > able to scan, list and even recover files which reside in the DOS
> > partition. However, none of these programs seem to be able to
> > recognize HTFS files. Both disks seem to be both physically and
> > logicaly intact, the BIOS finds them OK and the scanning of the
> > programs do not end with an error condition.
> >
> > What I do have available are the root and boot disks. What I do not
> > have are either partition information and the divisions info. All I
> > really need is the information which resides in the /u division of the
> > UNIX partition, the rest of the disk I don´t care.
> >
> > Any comments and suggestions will be highly appreciatted.

>
> If the data on these disks is valuable to you, get professional help.
>
> If you have the necessary records then try these steps:
>
> 1) Boot the Emergency boot/root floppies and use fdisk to setup the
> UNIX partition with start block and size identical to the settings used
> for the original install. If you're lucky, divvy should show you the
> original division table. If you see the original division table. try
> 'mount -r /dev/u /mnt' to see if you can see the files. If you can
> see the u files, re-install UNIX on the other disk and recover the
> files by mounting the recovered disk's "u" division.
>
> 2) If divvy does not show the division table, you may have entered the
> wrong partition start and size, or the divvy table may be destroyed.
> If you are brave, run "mkdev hd 0 0" and setup a new division table
> with the information from your records for the divisions.

> >Be sure to "prevent" creation of new file systems on the divisions<

> as creating new file systems will destroy any hope of recovering your
> data. You must be able to run fsck on the "u" file system without
> getting an overwhelming number of errors. I would be happy with less
> then 10-20 un-referenced files. I would be suspicious I see a lot
> of DUP blocks and or unrealistic file sizes.
>
> 3) If you can successfully mount /dev/u from the emergency boot floppy
> set, reinstall UNIX on a new hard disk, then recover your files from
> the restored disk.
>
> NOTE: The above steps can be destructive if you make a mistake. You
> should purchase a new disk that is identical to the original 2 disks
> and use a disaster recovery product that will sector copy all data
> from one of the original disks to the "working" disk. Only work on the
> third disk. That way, if you butch the recovery on the new disk, you
> need only repeat the copy and try again.
>
> [url]http://www.just-data-recovery-links.com/partition_partition_recovery_table_tool.html[/url]
>
> Good luck.
>
> P.S. Thanks for your post. I will print it and pass out copies to anyone
> trying to save money by omitting a good tape backup system on their
> UNIX server.

[Jose Tabisi]

We used Jumbo backups, afterwars they were bought by HP. It was not
easy neither reliable (not to mention fast). However I do not want to
start a discussion about them, I wish I had one with me now. Regards.

[email]bv@wjv.comR[/email]EMOVE (Bill Vermillion) wrote in message news:<HIL5tp.uAo@wjv.com>...

> In article <c8f61b71.0307250605.354fde18@posting.google.com >,
> Jose Tabisi <josetabisi@tecnitower.com.ar> wrote:

> >Thanks Steve

>

> >Regarding your post scriptum, it looked like a good solution until it
> >failed. I had bad experiencies with tape backups in the past, of
> >course now I regret not having other backups around.

>
> Bad tape backups are often caused by 1) poor choice of backup
> device 2) bad care of media 3) improper maitenance.
>
> A good device, with media properly cared for, and regular cleaning
> will quite often mean that you change the tape backup device
> because it is too small for your needs.
>
> Care to mention the problem you had with tape backups?

[Bill Vermillion]

In article <c8f61b71.0307251257.35fb5247@posting.google.com >,
Jose Tabisi <josetabisi@tecnitower.com.ar> wrote:

>We used Jumbo backups, afterwars they were bought by HP. It was not
>easy neither reliable (not to mention fast). However I do not want to
>start a discussion about them, I wish I had one with me now. Regards.

No need to start a discussion on those. Everyone whose been on the
group for years knows how bad those were. They barely deserved the
name tape backup. Anytime anyone mentioed they had one the
universal cray was 'get rid of it now'.

>
>bv@wjv.comREMOVE (Bill Vermillion) wrote in message news:<HIL5tp.uAo@wjv.com>...

>> In article <c8f61b71.0307250605.354fde18@posting.google.com >,
>> Jose Tabisi <josetabisi@tecnitower.com.ar> wrote:

>> >Thanks Steve

>>

>> >Regarding your post scriptum, it looked like a good solution until it
>> >failed. I had bad experiencies with tape backups in the past, of
>> >course now I regret not having other backups around.

>>
>> Bad tape backups are often caused by 1) poor choice of backup
>> device 2) bad care of media 3) improper maitenance.
>>
>> A good device, with media properly cared for, and regular cleaning
>> will quite often mean that you change the tape backup device
>> because it is too small for your needs.
>>
>> Care to mention the problem you had with tape backups?

--
Bill Vermillion - bv @ wjv . com

[Jose Tabisi]

Dear Steve

We have not met, and I had never heard of you before three days ago,
but let me tell you this : I LOVE YOU.

It was as simple as you put it, I found the string with the disk
editor (at cylinder 508, head 0, sector 1) installed the disk again in
the unix machine, run fdisk /dev/rhd10, created the partition starting
at track 8128 (508 x 16 heads, made it the active partition (not
necessary at first I guess) and then
run divvy /dev/hd10, and voilá, the division table was there. I
renamed the division number 3 and copied the whole division to my
master disk.

Again, I deeply appreciatte your advise and hope to be able to
retribute this to you in the future.

Regards, José

Steve Fabac <smfabac@att.net> wrote in message news:<3F21CAFB.376964B6@att.net>...

> Jose Tabisi wrote:

> >
> > Thanks Steve
> >
> > Regarding your post scriptum, it looked like a good solution until it
> > failed. I had bad experiencies with tape backups in the past, of
> > course now I regret not having other backups around.
> >
> > Back to your message, I did send the main disk to an expert, there are
> > not as many choices here as there are there, and I hope to have made
> > the right choice, I will know soon.
> >
> > However I have kept the second disk and keep on working on it. I
> > downloaded a disk editor for windows, mounted the unix disk as
> > secondary and looked at the info, it seems to be still there.

>
> I strongly advise that you purchase a new disk and use a product
> like CPR Data Recovery Tools to clone the damaged disk to the
> new disk and only work on that disk. That way, if you corrupt the
> copy, just clone the disk again and start over.
>

> >
> > I was tring to figure what the original partitions were because I
> > really do not know. Unix data seems to start somewhere around cylinder
> > 750, which makes perfect sense considering /boot must lie within the
> > first 1024 cylinders of the disk for Unix to be able to start. I then
> > mounted the disk as secondary with a working Unix as master disk and
> > tried different fdisk partitions followed by 'divvy /dev/hd10'. So far
> > I have not been succesfull, maybe there's something wrong with my
> > reasoning.

>
> I just checked my active partition and found the divvy table at offset
> 5400H from the start of the partition. Use your disk editor to
> search for the string "hd(40).0123456789ABCDEF" (the "." is 00H
> the string is "68 64 28 34 30 29 00 30 31 32 33 34 35 36 37 38
> 39 41 42 43 44 45 46" Hexadecimal). the hd(40) is at 14b (331 bytes)
> from the beginning of the partition.
>
> Once you find the proper cylinder/head/sector with this marker, you
> may have a better shot at using fdisk to set the active partition
> start track. Note that UNIX fdisk is in tracks with each track being
> all the heads in a cylinder. My machine is 2232 Cyl X 255 Heads
> for 569160 tracks reported by fdisk.
>
>

> >
> > If I did try, for example, using the whole disk for the Unix partition
> > (which was not the original partition), is there any chance I can get
> > back the data ? Any ideas ? Thanks for your help
> >
> > Steve Fabac <smfabac@att.net> wrote in message news:<3F1FB8FA.72D65064@att.net>...

> > > Jose Tabisi wrote:
> > > >
> > > > I am working with SCO Unix 5.0.4, using two disks, the second one with
> > > > a removable bay so that I can use for backup purposes. By mistake we
> > > > powered on the machine with both disks connected as master disks to
> > > > the same IDE controller. This usually meant that the machine would not
> > > > start until that problem got corrected, but this time it somehow
> > > > managed to start and then finally crashed after a while. Both disks
> > > > have a DOS and UNIX partition, and the UNIX partition have /root and
> > > > /u divisions defined.
> > > >
> > > > Now the situation is that both disks have lost the partition
> > > > information and I can not access them in any way. I have searched and
> > > > downloaded some demo programs available in Internet and I have been
> > > > able to scan, list and even recover files which reside in the DOS
> > > > partition. However, none of these programs seem to be able to
> > > > recognize HTFS files. Both disks seem to be both physically and
> > > > logicaly intact, the BIOS finds them OK and the scanning of the
> > > > programs do not end with an error condition.
> > > >
> > > > What I do have available are the root and boot disks. What I do not
> > > > have are either partition information and the divisions info. All I
> > > > really need is the information which resides in the /u division of the
> > > > UNIX partition, the rest of the disk I don´t care.
> > > >
> > > > Any comments and suggestions will be highly appreciatted.
> > >
> > > If the data on these disks is valuable to you, get professional help.
> > >
> > > If you have the necessary records then try these steps:
> > >
> > > 1) Boot the Emergency boot/root floppies and use fdisk to setup the
> > > UNIX partition with start block and size identical to the settings used
> > > for the original install. If you're lucky, divvy should show you the
> > > original division table. If you see the original division table. try
> > > 'mount -r /dev/u /mnt' to see if you can see the files. If you can
> > > see the u files, re-install UNIX on the other disk and recover the
> > > files by mounting the recovered disk's "u" division.
> > >
> > > 2) If divvy does not show the division table, you may have entered the
> > > wrong partition start and size, or the divvy table may be destroyed.
> > > If you are brave, run "mkdev hd 0 0" and setup a new division table
> > > with the information from your records for the divisions.
> > > >Be sure to "prevent" creation of new file systems on the divisions<
> > > as creating new file systems will destroy any hope of recovering your
> > > data. You must be able to run fsck on the "u" file system without
> > > getting an overwhelming number of errors. I would be happy with less
> > > then 10-20 un-referenced files. I would be suspicious I see a lot
> > > of DUP blocks and or unrealistic file sizes.
> > >
> > > 3) If you can successfully mount /dev/u from the emergency boot floppy
> > > set, reinstall UNIX on a new hard disk, then recover your files from
> > > the restored disk.
> > >
> > > NOTE: The above steps can be destructive if you make a mistake. You
> > > should purchase a new disk that is identical to the original 2 disks
> > > and use a disaster recovery product that will sector copy all data
> > > from one of the original disks to the "working" disk. Only work on the
> > > third disk. That way, if you butch the recovery on the new disk, you
> > > need only repeat the copy and try again.
> > >
> > > [url]http://www.just-data-recovery-links.com/partition_partition_recovery_table_tool.html[/url]
> > >
> > > Good luck.
> > >
> > > P.S. Thanks for your post. I will print it and pass out copies to anyone
> > > trying to save money by omitting a good tape backup system on their
> > > UNIX server.