Putting bigger discs in server

[MarkSyder]

Hi everybody.

I'm supporting a server which has four disc slots. The first three have 1 x 9Gb disc (vg00) and 2 x 18Gb discs (vg01 and vg02). The server is running HP-UX 10.20.

I've just been given 2 x 73Gb discs to put in this server. Rather than waiting till I get in a mess and then asking for help, I thought it a good idea to prepare a plan of action then post it here so people who've done this before can give me the appropriate commands I need to run and warn me of any potential pitfalls.

Plan of action:

1. Put a 73Gb disc in slot 4 (already done successfully and identified with ioscan).

2. Set up a new volume group on this disc and transfer the contents of vg01 and vg02 on to it, with certain filesystems increased in size.

3. The 2 x 18Gb discs will now be empty, so I intend removing the disc from slot 3 and putting the other 73Gb disc in its place.

4. Install HP-UX 11i on the 18Gb disc in slot 2. Set the server up to boot from this disc.

5. Remove the 9Gb disc from slot 1 and replace it with the 18Gb disc removed at stage 3.

6. Install Mirrordisk and make the two 18Gb discs identical.

What I need to know in advance is:

1. What commands do I use to transfer the contents of vg01 and vg02 to the new disc? I expect to be using vgexport and vgimport, but these are not commands I've used before and I would appreciate guidance.

2. What volume group name will the new disc use? Will it default to vg03 (the first available) or will vgimport allow me to make this disc vg01?

3. Is HP-UX selective about the order in which it finds the volume groups? I.e. is it acceptable for me to have vg01 in slot 4 and vg02 in slot 3?

Please be patient while you wait for your points. I can't start on stage 2 till Friday afternoon, after the users have gone home early. I'll be giving out points next Monday.

Mark Syder (like the drink but spelt different)

[Geoff Wild]

Looks like a good plan.

1. To transfer - use vxdump/vxrestore:

vxdump -0 -f - -s 1000000 -b 16 /mountpointfromolddisk | (cd /tempmountpointnewdisk ; vxrestore rf -)&

2. vg can be named anything you like.

3. vg's can be in any slot you want - doesn't matter.

vgexport - do that to old vg's after they have been copied....

Rgds...Geoff

[Pete Randall · Accepted solution]

Mark,
Vgexport/vgimport don't move data from one disk to another - the data remains on the same disk and is dis-connected from one system and re-connected to another.

You need to create a new VG and reload it from some sort of backup. If you wish, you can re-use vg01 as long as you've backed up and gotten rid of the original vg01 first.

The order of the volume groups is not significant.


Pete

[bhavin asokan]

see the following procedure,


1. Put a 73Gb disc in slot 4 (identify with ioscan).

2. Set up a new volume group with this disc.

3. create the logical volumes on the new vg(total number of logical volumes on new vg=number of logical volumes on vg01+number of logical volumes on vg02 ).the lv sizes should be equal to or more than that of that of corresponding lv in vg01 and vg02.

4. create filesystem on the lvs with newfs.

5. mount the lvols to temperory mount points.

6.go to the specific directory (mount point) use the following command to transfer data.

find . -depth |cpio -pdmluva /destination

provided /destination is the temperory mount point of your new lv .

7 . compare the data on both mount points.
unmount both lvs. mount the newlv on the proper mount point.

8. repeat this for all lvs.

9.vgexport old vg01 and vg02.

you can use dd command also to copy the old lvol to new disks logical volume.

before doing any activity of installation create ignite backup of root vg. create map files of all vgs by vgexport .create conf files by vgcfgbackup.


after installation of hp-ux you can vgimport the vg with map file.


vg can be named anything you like

vg's can be in any slot you want .it dosen't depends on the slots.

regds,

[MarkSyder]

Thanks everyone.

These are very useful posts and will be suitably rewarded after I've done the work.

I particularly like the look of the find/cpio command to copy data from the old lvol to the new, but have one question about it:

I have checked all the recommended options on the man cpio page and -l states "Whenever possible, link files rather than copying them". Surely I don't want to use this? I want to copy the files so I can re-use the discs with the old lvols on them. If I link, won't I end up with links to non-existent files? Or does link in this context not mean what I think it means?

Mark

[Robert-Jan Goossens_1]

Mark,

The find/cpio command.

# find /orig_mountpoint | cpio -pcmudv /copy_mountpoint

Good luck,
Robert-Jan

[Pete Randall]

Mark,

I've always been puzzled by that phrasing as well. I can say that I've done the cpio thing many times (options: pdumxl) and the only thing that can mess things up on occasion is permissions. You can start getting yourself into a real mess when a few dozen files don't get copied and you have to go back and get them individually. For me, unless it's a fairly small number of files, I find a backup/restore to be far more reliable.


Pete

[MarkSyder]

What a relief - I wasn't allowed to post at all yesterday (page not found).

Backup/restore: interesting. I thought at first of a tape backup, but tapes are slow. The lvols I'm creating are twice the size of the old ones. That leaves plenty of room for a tar file of the old lvol plus the untarred version. Anything wrong with that plan?

Also, the suggestion of setting up a temporary mountpoint in the new lvol and subsequently renaming it: the wording of that suggestion implies I can do that before I've run vgexport. Is that right? Simply umount both lvols, change the name of the mountpoint in the new lvol, then mount it?

And when the time comes, what is the exact syntax of vgexport?

Mark

[Ravi_8]

Hi Mark

I would do creating a ignite backup (make_tape_recovery) and restoring on new 73GB disks

[Robert-Jan Goossens_1]

Mark,

Just a thought, if you can live with an other volume group name (vg03) you do not have to use vgexport/vgimport, just create a new volume group, create new logical volumes and mount them on temp mountpoints. Copy the data from the original filesystems, unmount the original filesystems and mount the new filesystems on the old mountpoints.

Regards,
Robert-Jan

[MarkSyder]

But isn't ignite only for vg00? I'm not yet at the stage of upgrading the root disc, and whn I am I'll be doing a cold install of HP-UX 11i.

My understanding is that ignite will work for other filesystems but isn't recommended.

Mark

[Michael Tully]

Hi Mark,

ignite can be used for more than just vg00 but this all depends on the size of the system being backed up. My philsophy on this, is that if you can't fit the whole ignite backup on one tape, (generally a DAT) forget any other VG's and use a different tool for it. Mind you I use an IUX (ignite server) to do my VG00 backups and use different tools for other servers, Omniback for most systems and fbackup for systems in my DMZ.

Cheers
Michael

[MarkSyder]

Hi Robert-Jan.

Yes, I can certainly live with another vg name and have already set the first new disc up with vg03. But when I've transferred all the data from the two old discs I'm going to remove one to create a space for the second new one. Won't the system generate error messages every time it boots if there appears to be a disc missing?

Mark

[Robert-Jan Goossens_1]

---
Set up a new volume group on this disc and transfer the contents of vg01 and vg02 on to it, with certain filesystems increased in size
---

If I understand the above message, you do not need vg01 and vg02 after you have tranfered the data to a new vg. Just blow them away with a vgexport. The disk used in the vg01 + vg02 can now be used for a new vg or being added to an existing vg.

Regards,
Robert-Jan

[MarkSyder]

Hi Michael.

Yes, I will have Omniback backups available of the old filesystems, but I am wondering about the speed of tape (especially as we do one weekly backup and four incrementals - this could be a time-consuming process!).

I know that tar is, in the words of Marty Poniatowski, "as slow as molasses" but wonder if tar across discs will be faster than Omniback via tapes.

All suggestions gratefully received.

Mark

[Michael Tully]

tar or cpio across disks will certainly be faster as long as they on the same system and you have the available space. Only problem I see, is if you have a problem with the system itself and cannot recover. Don't forget backups are your lifeblood and it is important that you have a backup that you can recover a system from, whatever the reason.

Backup times will depend largely upon the hardware available to you.

[MarkSyder]

Right, I'm clear on how I'm going to do that part of it now. Now a reminder of the second part of today's question:

Also, the suggestion of setting up a temporary mountpoint in the new lvol and subsequently renaming it: the wording of that suggestion implies I can do that before I've run vgexport. Is that right? Simply umount both lvols, change the name of the mountpoint in the new lvol, then mount it?

Points to follow when the system is successfully upgraded.

Mark

[Michael Tully]

To do the copies from old FS to new FS can be done with cpio.

cd /oldfs
find . | cpio -pdumv /newfs

Once you've copied everything, simply unmount old FS, deactivate VG using 'vgchange -a n /dev/myvg' and then 'vgexport'

[MarkSyder]

I think we're nearly there.

I've been reading about vgchange and vgexport to give myself some background knowledge before I run commands I've never used before.

I'm happy with vgchange, but I'm curious about the -m option in vgexport. The manual page refers to creating a mapfile in case you want to import the vg on to another system. What about if I want to import the vg back on to this system if everything goes horribly wrong? Would I be right in thinking it would be a good idea for me to create a mapfile?

Mark

[Robert-Jan Goossens_1]

Hi Mark,

---
Create a mapfile to be copied to other systems in a high availability cluster to build the volume group information for the volume group, /dev/vg02. Note that the volume group is not removed from the
exporting system. The importing systems will create the volume group with the vgimport command using the -s and -m options.

vgexport -s -p -m -v vg02.mymap /dev/vg02
---

in the above command the -s option is used (sharable), you could skip this option.

vgexport -p -v -m /tmp/vg01.mymap /dev/vg01

just for creating a map file.

Best regards,
Robert-Jan

[Sridhar Bhaskarla]

Hi Mark,

The command I usually use is 'fbackup' to copy data across the filesystems. I found it very reliable. It compares the files on the source and destination directories and copy only the files that changed/additional on the source directory.

#cd /srcdir;/usr/sbin/fbackup -i . -f - |(cd /dstdir; /usr/sbin/frecover -v -r -f -)

Try it on some test directories first before doing it on your production filesystems.

I assume other people might have answered the rest. Regarding your point 3) HP-UX doesn't care where the disks are located. The configuration is dependent on how you add the disks to the VG.

-Sri

[bhavin asokan]

hi,

vgexport and vgimport affects the /etc/lvmtab file and it adds or removes the block & character files in the respective vg.this is not creating any changes in your disks.

vgexport -s -p -v -m vg02.map /dev/vg02
command creates a map file with VGID and whatever the lvols within the /dev/vg02.
this file is a ascii file and you can see by more command.

-p is used for preview mode so that it will not remove the VG when creating map file.if you omit this it will remove the VG entry also from lvmtab file.

-s is used for shared mode .this option will include the VGID in the map file. at the time of importing you don't have to mention the pvs if you are using this option.
system will automatically findout the disks(which is connected to system)which is having same VGID and it will get added to specified VG .otherwise you should have to manually specify the pvs in that volume group.

-m used for specifying map file.if you are not using map file , at the time of vgimport it will create the lvs with default naming convention. ie. lvol1 ,lvol2 ,lvol3 ,.... in this order. if you are having some different names for lvols for your convenience like sales , admin (which you may have identified/mounted for using by specific depts) will not be imported on the same name with out map file.(map file contains the existing lvol names)



at the time of importing you can specify
first
vgimport -s -p -v -m vg02.map /dev/vg02
for checking .

then if no error use

vgimport -s -v -m vg02.map /dev/vg02.


you can import to the same system also if vg configuration getting corrupted or after installing OS in a new hdd you want to use the VG.
one situation where map file comes in use is below.
i implemented SAN switch recently.before implementing the switch i created the map file of all VGs .after implementing the switch all the disk devices(from the disk array) got changed.after i got new disk devices on my system using ioscan ,i exported all the VGs without preview option.
then i created the group files for each VGs and done the vgimport with map file successfully.

if you are using databases like oracle with raw filesystem ,the names of vgs/lvs are so important.


regds

[MarkSyder]

I've now copied all the data across and tried to run vgchange -a etc., but it tells me that the device is busy.

I'm the only person logged in to the server and I'm in a directory on a different vg. How do I get out of this?

Mark

[bhavin asokan]

hi,

did you unmounted all the lvols from that vg.unmount all the lvols (which is the part of vg you want to unmount)

assuming vg02 and its lvols are mounted on /mnt1 ,/mnt2 etc..

#fuser -cu /mnt1
#fuser -cu /mnt2
.............
............
............
if it shows any user on that mount point

#fuser -ku /mnt1
#fuser -ku /mnt2
.......
.........
.......
if it is not showing any user accessing that lvols then unmount that mount points.

#umount /mnt1
...
...


after that disable the vg

vgchange -a n vg02


regds,

[MarkSyder]

Thanks.

I thought fuser would be involved somewhere, but I've never used it and wasn't sure of the syntax.

Unfortunately, I'd gone home by the time this post came in, so everyone will have to wait till next Monday for their points - Friday afternoon is the only time I can do this job.

Mark