Ignite doesn't bring back SAN Volume Groups

[jackie baron_1]

My Ignite server is working nicely and archives and restores a test client perfectly.

I then tried to archive the vg00 of another server that also had some volume groups on SAN disks.

The Ignite server created the vg00 archive perfectly.
It was then time to restore it.

It ran through all the phases (load software, build kernel, etc.) but failed at the post installation scripts.

The server came back up but with only vg00 restored. None of the other volume groups returned. It also seemed to blow them out of the /etc/lvmtab even though they're all still in the fstab. The device files are all still there.

Attached is a text file of bdf before and after and also the logfile extract from where it started failing.

Thanks for any help

j

[sujit kumar singh]

Hi Jackie,


u will need to include the other vgs also at the time of making the Archives.


while using the command line syntax of ceating the archives which include vg00 and other VG say vg01 also u need to do like this:

#make_net_recovery -v -x enc_entire=vg00 -x inc_entire=vg01 -x enc_entire=vgxx -s -s

While using GUI u shall get in the right side of screen where u can include the other VG.

Once ur Ignite image contains the archives of vg00 as well as the other VG(s) u will be surely prompted for the other VG configuratuions at the time of restoring the Clients using that Image.


Regards
Sujit

[Pete Randall]

I'm just think out loud here, but I have to wonder if you don't just need to import them. Check and see if the /dev entries are there already (/dev/vg01 and /dev/vg01/group, for example). Then you just have to run the vgimport. If the entries aren't there, just create them and then run the import. These steps could be put into the post installation scripts, I would think.


Pete

[Pete Randall]

Sorry - "thinking out loud"


Pete

[Avinash20]

NOTE: The data on SAN disk is not touched

# If you like to use the same disk on the SAN for this server, and if the disk are claimed, and if you are having the old /etc/lvmtab and could identify the disk to which vg it belong, you could well create the VG's directory again (mkdir /dev/vg01, mknod .. ) and do a vgimport with the disk.

If you are having the mapfiles(/etc/lvmconf/*.map), then you need to include -m with vgimport so that you could get the original lvol name instead of default lvol1,2...

[sujit kumar singh]

hello Jakie,


aloght mistake in the command in the earlier post please note that

#make_net_recovery -v -x enc_entire=vg00 -x inc_entire=vg01 -x enc_entire=vgxx -s -s


here actually shud be -d


Also if u have vg01(,vg02,.., vgxx) as included in teh make_net_archive, u will be gettting an opportunity to congigure the other VGs also and the size of the LVs while restoring that image on to the Client.


Regards
sujit

[sujit kumar singh]

hi


might be my earlie rreplies are far too away from what the post talks .... but jakie did u configure the other VGs and the disks to be used by them while u were restoring the image on to the client ...

assuming that ur ignite image had vg00 and other vgs included when the archive was being made.


REgards


sujit

[sujit kumar singh]

hi


did u choose the disks properly for the rootVG and the other VGs in the Ignite Restoration and OS install screen Filesystems Menu?

actually from the Filesystem TAB of the Ignite Restoration screen also u can get an opportunity of configuring the root VG and other VGs during the Ignite Install Screen on to the client.

just few questions


regards
sujit

[jackie baron_1]

Sujit you write "enc_entire" in your conmmand recommendation....

...is that correct syntax?

J

[likid0]

I should think, that you want to import the vgs/data on the san disks, not restore all the data from the ignite backup, otherwise you could finish with a gigantic ignite image.That would take ages to restore.

You should check on the ignite gui you check the import vgs option.

And then check the logs and have a look at why it has failed the post installation scripts.