SOLVED
You're not clear on what this second computer is - is it also a HP-UX system? If not you on a hiding to nothing...
I am an HPE Employee
OK - so the first step is to see if the new system can even see the old disk - start by executing:
ioscan -fnC disk
You should be able to pick out of that output the current disk the system is booted off (confirm with lvlnboot -v) and the "damaged" disk as well...
I am an HPE Employee
That's all good - next stage is to identify that the disk looks like a LVM disk - so:
pvdisplay /dev/dsk/c2t5d0
Should tell us that... then we'll be looking at the process to import a volume group and mount the disks - what version of HP-UX is this? (uname -a will tell us)
I am an HPE Employee
Wow 10.20 - you do know that is like way, way, WAY out of support yeah? ;op
Anyway that bad output isn't necessarily a problem. Next thing to do is try and import the volume group - to do that you need to establish how many volume groups you already have on your system - you can do that by looking at the the files in /dev as follows:
# ll /dev/*/group
crw-r----- 1 root sys 64 0x000000 Oct 28 2006 /dev/vg00/group
crw-r----- 1 root sys 64 0x010000 Jun 5 2009 /dev/vg01/group
#
So on my system I can see I already have 2 volume groups, vg00 (the root volume group) and vg01 which in my case holds some data. So if I want to add a new volume group to import that disk into the first things is to create a new volume group directory and group file under /dev/ This has to have a unique minor number (the hex output in the above). I can see that 0x000000 and 0x010000 are taken, so I'll use 0x020000:
# mkdir /dev/vgrecovery
# mknod /dev/vgrecovery/group c 64 0x020000
# ll /dev/*/group
crw-r----- 1 root sys 64 0x000000 Oct 28 2006 /dev/vg00/group
crw-r----- 1 root sys 64 0x010000 Jun 5 2009 /dev/vg01/group
crw-r----- 1 root sys 64 0x020000 Feb 25 02:44 /dev/vgrecovery/group
Now we can use the vgimport command to import the volume group - I don't have an unused disk on my system so I'm going to temporarily remove the disk in my vg01 volume group and use that as an example. So my starting point now looks like this:
# ll /dev/*/group
crw-r----- 1 root sys 64 0x000000 Oct 28 2006 /dev/vg00/group
So I'm going to create the group files under /dev as we did previously:
# mkdir /dev/vgrecovery
# mknod /dev/vgrecovery/group c 64 0x010000
# ll /dev/*/group
crw-r----- 1 root sys 64 0x000000 Oct 28 2006 /dev/vg00/group
crw-r----- 1 root sys 64 0x010000 Feb 25 02:50 /dev/vgrecovery/group
And now I will import the volume group off the disk I want to put into that new vg - I know this on my system is /dev/dsk/c3t5d0 - on your system it was /dev/dsk/c2t5d0 - I will also activate the volume group and take a backup of it:
# vgimport /dev/vgrecovery /dev/dsk/c3t5d0
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.
# vgchange -a y /dev/vgrecovery
Activated volume group
Volume group "/dev/vgrecovery" has been successfully changed.
# vgcfgbackup /dev/vgrecovery
Volume Group configuration for /dev/vgrecovery has been saved in /etc/lvmconf/vgrecovery.conf
Ok let's take a look at what is on that disk I just put into a new volume group:
# vgdisplay -v /dev/vgrecovery
--- Volume groups ---
VG Name /dev/vgrecovery
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 8683
VGDA 2
PE Size (Mbytes) 4
Total PE 8681
Alloc PE 8681
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
--- Logical volumes ---
LV Name /dev/vgrecovery/lvol1
LV Status available/syncd
LV Size (Mbytes) 34724
Current LE 8681
Allocated PE 8681
Used PV 1
--- Physical volumes ---
PV Name /dev/dsk/c3t5d0
PV Status available
Total PE 8681
Free PE 0
Autoswitch On
Proactive Polling On
I my case there's just one logical volume (lvol1) - on yours there will be a bunch more as there are a bunch of extra lvols in a root volume group usually. Anyway I can create mount points and look at the contents of my filesystems on that disk:
# mkdir /recovery
# mkdir /recovery/lvol1
# mount /dev/vgrecovery/lvol1 /recovery/lvol1
# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 307200 162312 144120 53% /
/dev/vg00/lvol1 295024 40880 224640 15% /stand
/dev/vg00/lvol8 1843200 1498672 343376 81% /var
/dev/vg00/lvol7 2306048 1346664 952968 59% /usr
/dev/vg00/lvol4 204800 131136 73664 64% /tmp
/dev/vg00/lvol6 1794048 1740264 53784 97% /opt
/dev/vg00/lvol5 20480 2448 17896 12% /home
/dev/vgrecovery/lvol1
35557376 347601 33015103 1% /recovery/lvol1
# ls -l /recovery/lvol1
total 561238
drwxr-x--- 34 root sys 1024 Dec 8 2010 depot
-rw-r----- 1 root sys 287344640 Oct 16 2012 gcc-4.2.3-hppa-11.11.depot
drwxr-xr-x 2 root root 96 Jun 5 2009 lost+found
As you can see I have now mounted this filesystem and can see the contents. You will have a bunch more lvols that should roughly correspond to the logical volumes listed above (i.e. lvol1 will be /stand etc) - don't try and mount lvol2 as it is usually the swap partition and has no filesystem on it.
Let's see how you get on with that! Good luck!
I am an HPE Employee
No you can't mount a tape as a filesystem... How the backups works will depend on how they were taken - do you know how the backup tapes were created? What commands were run to create them or even just what utility?
I am an HPE Employee
Depends very much on the commands you are using and the tape device you are using. What tape device are you using? (show the output if "ioscan -funC tape") WHat exact cpio/dd/tar commands did you try?
I am an HPE Employee
If the ioscan isn't reporting anything at all, that suggests there's a problem accessing the tape drive - even without a tape in the drive you should get something back on the ioscan. Can you post the full output of:
ioscan -fn
I am an HPE Employee
If the backups were created from within SAM then they will be in fbackup/frecover format, so tar/cpio/dd would probably not help.
frecover should default to using /dev/rmt/0m which I think is your tape drive, so with the tape in try the following commands:
frecover -I /tmp/index
frecover -V /tmp/volheaderif the tape is in that format then that should recover a volume header (which will tell you a bit about when the backup was done) and an index (which will tell you the files that were backed up) .
Post the output of those commadns here (don't post the /tmp/index file if it is created - it will probably be too big, but if it works you should be able to determine if the data you want is on the tape)
I am an HPE Employee
hmmm - I think your tape drive may also be goosed :o(
Any indication of recent chnages to the system log file that might give us a clue if that's the case?
/var/adm/syslog/syslog.log
I am an HPE Employee
incidentally if this command that you tried:
dd if=/dev/rmt/0m of=/home/recoverywas resulting in absolutely nothing being written into the file /home/recovery (it would need to not exist and not be a directory before you tried it) then either the tape drive is bust, or there is nothing on that tape, as the dd command literaly just reads a raw stream of data off the tape until it encounters an end-of-file marker.
I am an HPE Employee