Overwriting a active disk by accident, now boot fails

[Christopher Bamber]

I was using a system tody (HP-UX 10.20) that according to SAM had two hard disks installed (both have different hardware paths), one of them was marked as unused. I was requested to add more space to the system so decided to use this unused disk. I created a new volume group (vg01) and then created a new filesystem on the disk and mounted it. All was fine and then a few minutes later error messages started appearing (Bad Magic number etc) and then the GUI crashed and the system hung, could not logon remotely and decided to power off. The reboot failed and when I searched for disks, it only stated one disk was in the system.

For some reason, the system actually allowed me to overwrite the active disk and create a filesystem on it. Why would SAM do allow such a thing to happen ?

I try attaching the disk to another system and accessing it but it has just one partition on it, all the data that was previously on there is gone.

Any recommendations on how I can get the data back. Should I send to a data recovery center ?

Thanks in advance for any advice

[Jeeshan]

check this doc

[Steven Schweda]

> check this doc

And how will that help?

> Any recommendations on how I can get the
> data back.

Restoring from backup is popular.

> Should I send to a data recovery center ?

Assuming that you have no backup, you need to
compare the costs of an outside data recovery
service against the benefits, and compare
those against those for other methods
(recreating the data, employment elsewhere,
...).

[Mark Graham]

Christopher, SAM is a great tool (when patched up to date) that has improved over the years...

However, SAM is just one of many tools HP-UX admins can use when working with disks created in LVMLand.

Knowing the rest of the LVM story (man lvm) will reveal many other tools that will help you avoid a problem like this in the future...

A simple lvlnboot -v on the disk or disks at the bottom of vgdisplay -v output would have told you if/how the disks were used or not used...

The field in SAM is just a label or informational field, and should not be trusted as the only source of information about the status of disks on the system...

Even review of print_manifest output might have kept this from happening...

Without an Ignite image from tape or network, I'm not sure you have a viable way back to the original state of your system...

Rebuild the OS from CD and then carefully and selectively restore "data" files...

Good luck!