Recovery From Ignite Backup

[rianui]

Hi Gurus,

I have a client with an rx7410 that recently had a disk failure. While trying to remove the faulty drive from the mirror, I got into some problems and so decided to recover the OS from a similar server from a DR site.Both servers are attached to an external Disk System 2405 (FC). The database seated on the storage on the primary site was also messed up because there were three disks that had failed. I replaced these three disks as well.

Now, after restoring the ignite backup I want to restore data from the DR site as well. I get an error during the restore. I have attached the text document with the error.

Regards,

Rianui

P.S. This thread has been moved from HP-UX > System Administration to HP-UX > ignite - HP Forums moderator

[Ralf Seefeldt]

Hi Rianui,

I assume your LVs are not mirrored.

you want to restore the data. Thus, the volume groups and lovgical volumes wil not be restored. You have to create/restore them manually.

It looks like the three new disk have no VG and LV information. If those disks have the same devicefiles than the old ones, you could try vgcfgrestore. If not, you have to manually remove the broken disks from the VGs vgsybase and vgsybase2 (vgreduce -f ${VG} <disk>) and manually add the three new disks (pvcreate /dev/r${disk} ; vgextend /dev/${VG} /dev/${disk} ; lvextend -m 1 /dev/vg00/lvol1 /dev/${disk})

Check the man pages of the comands for the opions available for your specific OS-version.

Bye Ralf

[rianui]

Hi Ralf,

Yes, the new disks do not have anything on them. The enclosure however, has other disks with info. It would be easier for me to clean the storage of any data and restore from the backup. There are quite a number of LVs to be created though. What's the best way to do this?

Regards,

Rianui

[rianui]

Hi Ralf,

I cannot reduce the VG because it does not exist in the lvmtab file: vgreduce: Volume group "/dev/vgsybase" does not exist in the "/etc/lvmtab" file

Also, vgscan gives me the following output.

# vgscan -a -v
vgscan: The physical volume "/dev/dsk/c0t6d0" is already recorded in the "/etc/lvmtab" file.
vgscan: The physical volume "/dev/dsk/c3t6d0" is already recorded in the "/etc/lvmtab" file.
Physical Volume "/dev/dsk/c4t12d0" contains no LVM information
Physical Volume "/dev/dsk/c4t13d0" contains no LVM information
Physical Volume "/dev/dsk/c4t14d0" contains no LVM information
Physical Volume "/dev/dsk/c5t12d0" contains no LVM information
Physical Volume "/dev/dsk/c5t13d0" contains no LVM information
Physical Volume "/dev/dsk/c5t14d0" contains no LVM information


/dev/vg00
/dev/dsk/c0t6d0
/dev/dsk/c3t6d0


Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c4t0d0
/dev/dsk/c4t1d0
/dev/dsk/c4t2d0
/dev/dsk/c4t3d0
/dev/dsk/c4t4d0
/dev/dsk/c4t5d0
/dev/dsk/c4t6d0
/dev/dsk/c4t7d0
/dev/dsk/c5t0d0
/dev/dsk/c5t1d0
/dev/dsk/c5t2d0
/dev/dsk/c5t3d0
/dev/dsk/c5t4d0
/dev/dsk/c5t5d0
/dev/dsk/c5t6d0
/dev/dsk/c5t7d0

Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c4t8d0
/dev/dsk/c4t9d0
/dev/dsk/c4t10d0
/dev/dsk/c4t11d0
/dev/dsk/c5t8d0
/dev/dsk/c5t9d0
/dev/dsk/c5t10d0
/dev/dsk/c5t11d0

The Volume Group /dev/vgsybase was not matched with any Physical Volumes.
The Volume Group /dev/vgsybase02 was not matched with any Physical Volumes.
Scan of Physical Volumes Complete.


Regards,

Rianui

[Ralf Seefeldt]

Hi Rianui,

... was not matched with any Physical Volumes.

That sounds strange. Dit those two VGs realy contain only 1 respectively 2 disks? Then, all disks of those VGs would in deed be gone and you could rebuild them from scratch using vgcreate.

Tell me more about your disk storage. Do you use physical Disks to create your VGs or does your disk storage present logical disks, that are made of chunks from several physical disks?

What VGs do you expect th have had data on the three failed disks?

Do you have additional VGs?

Do all your disks have two conections and two devicefiels acossiated with them?

Bye Ralf

[rianui]

Hi Ralf,

>>Dit those two VGs realy contain only 1 respectively 2 disks?

See the output from /etc/lvmpvg

# cat /etc/lvmpvg
VG      /dev/vgsybase
PVG     PVG0
/dev/dsk/c4t0d0
/dev/dsk/c4t1d0
/dev/dsk/c4t2d0
/dev/dsk/c4t3d0
/dev/dsk/c4t12d0
PVG     PVG3
/dev/dsk/c5t0d0
/dev/dsk/c5t1d0
/dev/dsk/c5t2d0
/dev/dsk/c5t3d0
/dev/dsk/c5t12d0
PVG     PVG1
/dev/dsk/c4t4d0
/dev/dsk/c4t5d0
/dev/dsk/c4t6d0
/dev/dsk/c4t7d0
/dev/dsk/c4t13d0
PVG     PVG4
/dev/dsk/c5t4d0
/dev/dsk/c5t5d0
/dev/dsk/c5t6d0
/dev/dsk/c5t7d0
/dev/dsk/c5t13d0
VG      /dev/vgsybase02
PVG     PVG5
/dev/dsk/c5t8d0
/dev/dsk/c5t9d0
/dev/dsk/c5t14d0
PVG     PVG7
/dev/dsk/c4t8d0
/dev/dsk/c4t9d0
/dev/dsk/c4t14d0
PVG     PVG6
/dev/dsk/c5t10d0
/dev/dsk/c5t11d0
PVG     PVG8
/dev/dsk/c4t10d0
/dev/dsk/c4t11d0

>>Do you use physical Disks to create your VGs or does your disk storage present logical disks, that are made of chunks from several physical disks?

Not sure how to answer this :-(.....maybe I can send you a command output?

>>What VGs do you expect th have had data on the three failed disks?

>>Do you have additional VGs?

Can I send you command output for these? Sorry I'm not very conversant with UX :-(

>>Do all your disks have two conections and two devicefiels acossiated with them?

Yes, the storage connects to the server using two FC cables. See the output of ioscan attached.

Regards,

Rianui

[Ralf Seefeldt]

Hi Rianui,

please send the output of

vgdisplay

ls -l /dev/vg* /dev/VG*

What a disk subsystem do you have? (product name, ...)

Do you have to ask someone to get an additional disk?

Do you have two storage devices, probably distributed to two locations?

what OS version do you run? (uname -a)

Do you have mapfiles for the VGs? if so, send the first lines of them. How did you create the mapfiles (what oprions where used)?

Did the deficefiles for the replaced disks chagne or are those the same as for the old disks?

If you want to recover the filesystems from scratch, you even could recreate the VGs and LVs from scratch (if recovering them fails).

Bye

Ralf

[rianui]

Hi Ralf,

I appreciate your support.

>>please send the output of

vgdisplay

ls -l /dev/vg* /dev/VG*

--Find attached docs.

>> What a disk subsystem do you have? (product name, ...)

--Disk System 2405

>> Do you have to ask someone to get an additional disk?

--Not sure I understand. I have new disks on site for replacement.

>> Do you have two storage devices, probably distributed to two locations?

--There are two rp7410 servers and each is directly connected to a storage box (Disk System 2405)

>> what OS version do you run? (uname -a)

--HP-UX equinox B.11.23 U 9000/800 3491026600 unlimited-user license

>> Do you have mapfiles for the VGs? if so, send the first lines of them. How did you create the mapfiles (what oprions where used)?

--I have attached a document (Live Installation_12thNov2008). This is how the VGs were created last time.

>> Did the deficefiles for the replaced disks chagne or are those the same as for the old disks?

-- Not sure I understand but nothing changed other than replacing the faulty drives.

>> If you want to recover the filesystems from scratch, you even could recreate the VGs and LVs from scratch (if recovering them fails)

--Yes, I would like to do this and restore from the good system if this will be faster.

Best Regards,

Rianui

[rianui]

Hi Ralf,

For your information, the file "Live Installation_12thNov2008.txt" was collected before three new disks were added later and the VGs extended. See the file "VG Extension 01DEC2008" for extension information.

Regards,

Rianui

[Ralf Seefeldt]

Hi Rianui,

You have no mapfiles. That is, you don't know the identifying number of your lost VGs

You would get those number using "vgexport -ps -m <mapfile> <VG-name>"

Having this number in the first line of a mapfile (using vgexport -pm and the -s option) would enable you reimporting all disks, that cary this number.

You have lots of (r)ase*, *_dat and *_ndx files in your volumegroup directories.  I don't know those files. May be, sybase is writing to the raw devices.

Try vgcfgrestore to get the VG information back on the new disks. Then, try to vgimport the VG. refere to the man pages. I don't have a HP-UX 11.23 to check the available options.

If vgcfgrestore fails, the only way I see is recreating the VGs from scratch.
If sybase uses direct access to the raw LVOL-devices or uses the _dat and _ndx devicefiles, recreating the filesystems from scratch could kill your application. I don't know.

If you have a working backup and you have, at some point in the (not to distant past), tested the backup to be restorable, then you could continue just rebuilding the VGs.
If not, be aware, that you will lose those _ndx and _dat files and the (r)ase* files  when you rebuild the VGs. You could recreate them by hand.
At this point, you should find someone, who knows about those _dat and _ndx files.

I'm sorry not to can support you with a secure restoredescription in this case.

Bye

Ralf

[rianui]

Hi Ralf,

I appreciate your assistance a lot.

I will proceed and reconfigure the storage system. Attached are the commands I plan to use to complete the task. If you can add anything or advice me in any way please let me know, otherwise, thank you very much form the assistance. I will close the case and post the results of my solution once the work is complete.

Best Regards,

Rianui

[rianui · Accepted solution]

Hi Ralf,

I reconfigured the storage again and created PVs, VGs and LVs afresh.

I am now restoring the data from the fbackup backup I had taken.

Best Regards,