- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- regarding vgimport/vgcfgrestore
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2001 08:47 AM
02-27-2001 08:47 AM
--- Logical extents ---
LE PV1 PE1 Status1
00000 ??? 00000 current
Why do I get the question marks? How do I get the system to identify the physical volume when the mirrored copies are mounted on the backup server? Would vgcfgbackup/restore work on this?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2001 02:32 PM
02-27-2001 02:32 PM
Re: regarding vgimport/vgcfgrestore
You should first vgexport on primary in preview mode using -p option:
$ vgexport -p -m mapfile vg_name
Then bring mapfile to secondary(using ftp or rcp,etc.) and vgimport using this map file:
$ vgimport -v -m mapfile vg_name pv_path1 pv_path2 ......
Still It doesn't work you need to run vgcfgrestore... It will fix the problem.
Cheers.....
Satish.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2001 04:59 PM
02-27-2001 04:59 PM
Re: regarding vgimport/vgcfgrestore
The questions marks mean that lvdisplay cannot determine the physical disk associated with the lvol. If you are on 10.20 or later there is an option -k that will give you the PV Key of the disk...not that will help you in your situation. For clarification - on one server you want to split your mirror. On the other server that has access to the disks you want to mount this data. You cannot export a portion of the volume group. Are you exporting the whole volume group?If not, then the previous poster mentions how to vgexport in preview mode of the entire volume group (but not really export it) and import on the other server only the disks that are offline. But both systems will have the lvm configuration. This is not good. Also to import, you have to create a directory and do a mknod for the group file before doing a vgimport. I'm not really giving specifics because I'm afraid this is not the best approach. Maybe you should use nfs and remote mount.
Got any spare disks? You could create another VG and lvols and copy the data to that. Then you could vgexport/vgimport as much as you'd like. It would be a safe offline copy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-28-2001 12:28 AM
02-28-2001 12:28 AM
SolutionYou are missing a step. We use business copy here.
So far, then you have used created the business copy and split it away from its parent.
What will happen is the system suddenly "sees" a number of new disks which were part of that business copy.
For each of the "new" disks you need to run
vgchgid against these disks _but_in_the_same_VG!
For example, if your Business Copy contains the volume group vg_fred, consisting of three luns and you split the copy then you will have three new luns appear, lets call them c1t2d1 c1t2d2 and c3t4d5. To prepare them for a new volume group run:
vgchgid /dev/rdsk/c1t2d1 /dev/rdsk/c1t2d2 /dev/rdsk/c3t4d5
I believe vgchgid makes a random vg header id on the disk, so you must have each disk in the same group on the same line so they receive the same random number.
You can then import the volume group:
mkdir /dev/vg_banana
mknod /dev/vg_banana/group c 64 0x010000
vgimport vg_banana /dev/dsk/c1t2d1 /dev/dsk/c1t2d2 /dev/dsk/c3t4d5
Now you have the volume group you export it, ready for the second server:
vgexport vg_banana
And then on the new server, import the VG.
If you have any problems I am willing to show you the code I use to do this job.
Best wishes
Adam
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-28-2001 06:45 AM
02-28-2001 06:45 AM
Re: regarding vgimport/vgcfgrestore
You're definitely of help here! Not sure if our systems are the same, but I have 4 servers total.. 3 of which are app servers and 1 is a dedicated backup server (connected to a tape library), and all 4 are connected to an XP disk array.
Sounds like the vgchgid is what I need. Could you run down exactly what the process is when you split your business copies off every night and mount them to the backup server? This split and mount is what does not seem to be working for me. If it wouldn't be too much trouble, could you start from the beginning, assuming that I have not setup any of the volume groups on the backup server, and have done no vgexports or vgimports? Basically, start from when I have 4 servers connected to the array, and 3 of them have one volume group located on the array (so there are 3 vg's total on the array). How would I split the mirror and mount the 3 business copies to the backup server?
After the backups are done, are there any special procedures you need to run against the BC disks before you resync them?
Sorry to go back to basics here! I just want to be sure that I'm not forgetting something. Thanks Adam!
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-28-2001 10:31 AM
02-28-2001 10:31 AM
Re: regarding vgimport/vgcfgrestore
We have four volume groups here which have a business copy on them. The machine is called 'tyne'. The volumes are vg1, vg2, vg3, vg4.
Structure of vgs when in BC pair:
vg1: c4t6d0
vg2: c11t6d0
vg3: c4t7d2, c11t7d2
vg4: c11t6d2
business copy groups: vg1, vg2, vg3, vg4
What happens is this:
1. At midnight our databases are shut down and the business copy is split:
pairsplit -g vg1
pairevtwait -g vg1 -t 600 -s psus
what this does is split the BC pair, the wait for 600 seconds for the system to be in suspended state - 'psus'. This can be verified by doing
pairdisplay -g vg1
This is done for each business copy group.
2. When the BC pair splits a new lun will appear (the first time) and you may have to do an insf to create the device files.
What happens here is:
vg1 goes to c4t6d0 *plus* c4t12d0 (BC)
vg2 goes to c11t6d0 *plus* c11t12d0 (BC)
vg3 goes to c4t7d2,c11t7d2 *plus* c4t13d2,c11t13d2 (BC)
vg4 goes to c11t6d2 *plus* c11t12d2 (BC)
So the status is that we have a number of disks 'floating' which the OS does not think are part of a VG, but if you force it to read the VGRA then it will say 'hold on, its disk 1 of vg1!' and get thoroughly confused.
After this step our DBs are restarted.
3. We now create new volume groups based on the new disks. Lets call them vg1_bc, vg2_bc, vg3_bc and vg4_bc.
First of all we need to prepare the volume groups.
cd /dev
mkdir vg1_bc vg2_bc vg3_bc vg4_bc
mknod vg1_bc/group c 64 0x050000
mknod vg2_bc/group c 64 0x060000
mknod vg3_bc/group c 64 0x070000
mknod vg4_bc/group c 64 0x080000
Obviously change the minor number to the correct values for your system.
4. Now change the volume group IDs on the new disks:
vgchgid /dev/rdsk/c4t12d0
vgchgid /dev/rdsk/c11t12d0
vgchgid /dev/rdsk/c4t13d2 /dev/rdsk/c11t13d2
vgchgid /dev/rdsk/c11t12d2
Note that we have two disks on one line. If you don't they end up with a different VGID on each which means that you can't import them (take it from me, after much pain!).
5. Create a map file of each of your volume groups...
vgexport -m vg1.mapfile -p vg1
vgexport -m vg2.mapfile -p vg2
vgexport -m vg3.mapfile -p vg3
vgexport -m vg4.mapfile -p vg4
REMEMBER THE -p OPTION! This will cause the mapfile to be created (only needs doing once, or each time you add a LV), and the existing VG to be left alone.
6. Import the volume groups into the new volumes.
vgimport -m vg1.mapfile vg1_bc /dev/dsk/c4t12d0
vgimport -m vg2.mapfile vg2_bc /dev/dsk/c11t12d0
vgimport -m vg3.mapfile vg3_bc /dev/dsk/c4t13d2 /dev/dsk/c11t13d2
vgimport -m vg4.mapfile /dev/dsk/c11t12d2
7. Activate the volume groups.
vgchange -a y vg1_bc
vgchange -a y vg2_bc
vgchange -a y vg3_bc
vgchange -a y vg4_bc
You can now mount the logical volumes and do what you want.
8. When you want to finish using the business copies and re-sync them you need to
a) umount all filesystems.
b) deactivate the volume group (vgchange -a n VG)
c) export the volume group (vgexport vgX)
d) resync the BC:
pairresync -g vgX
pairevtwait -g vgX -t 600 -s pair
Each time you split off a copy you need to do a vgchgid then a vgimport.
If you wish to use another server to import the VGs then I still suggest you use a vgchgid before an import, assuming you know the target names (cXtYdZ) - using Brocade switches gets confusing with all the disks! You may already have a VG with the same ID.
I hope this has been of help. If you would like any further help please feel free to email me at Adam.Wainwright@pgen.com
Best wishes
Adam