Professional Web Applications Themes

hard disk crash - SCO

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

  1. #1

    Default hard disk crash

    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.
    Jose Tabisi Guest

  2. #2

    Default Re: hard disk crash

    Jose Tabisi <josetabisitecnitower.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]tonyaplawrence.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]
    tony@aplawrence.com Guest

  3. #3

    Default Re: hard disk crash


    "Jose Tabisi" <josetabisitecnitower.com.ar> wrote in message
    news:c8f61b71.0307231201.35e923c0posting.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?


    Bob Bailin Guest

  4. #4

    Default Re: hard disk crash

    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
    Steve Fabac Guest

  5. #5

    Default Re: hard disk crash

    On Thu, 24 Jul 2003 16:46:21 GMT, Steve Fabac <smfabacatt.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

    Scott McMillan Guest

  6. #6

    Default Re: hard disk crash

    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 <smfabacatt.net> wrote in message news:<3F1FB8FA.72D65064att.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 Guest

  7. #7

    Default Re: hard disk crash

    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]bvwjv.comR[/email]EMOVE (Bill Vermillion) wrote in message news:<HIL5tp.uAowjv.com>...
    > In article <c8f61b71.0307250605.354fde18posting.google.com >,
    > Jose Tabisi <josetabisitecnitower.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?
    Jose Tabisi Guest

  8. #8

    Default Re: hard disk crash

    In article <c8f61b71.0307251257.35fb5247posting.google.com >,
    Jose Tabisi <josetabisitecnitower.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'.

    >
    >bvwjv.comREMOVE (Bill Vermillion) wrote in message news:<HIL5tp.uAowjv.com>...
    >> In article <c8f61b71.0307250605.354fde18posting.google.com >,
    >> Jose Tabisi <josetabisitecnitower.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
    Bill Vermillion Guest

  9. #9

    Default Re: hard disk crash

    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 <smfabacatt.net> wrote in message news:<3F21CAFB.376964B6att.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 <smfabacatt.net> wrote in message news:<3F1FB8FA.72D65064att.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 Guest

Similar Threads

  1. What is LVD hard disk ?
    By Jose Perez in forum AIX
    Replies: 1
    Last Post: September 15th, 03:08 PM
  2. [PHP] can we know hard disk no via a php script?
    By Khalid El-Kary in forum PHP Development
    Replies: 0
    Last Post: July 27th, 12:04 PM
  3. [PHP] Hard disk number
    By Adrian in forum PHP Development
    Replies: 0
    Last Post: July 27th, 11:35 AM
  4. Hard disk number
    By Pehepe Php in forum PHP Development
    Replies: 0
    Last Post: July 27th, 11:33 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139