Disk Arrays
cancel
Showing results for 
Search instead for 
Did you mean: 

migrating to new disk

SOLVED
Go to solution
Ed McKnight
Advisor

migrating to new disk

I have a K260 with hp-ux 11. and 2 3312 jamaca's mirrored.
this started with 1 4gig disk each, the database got too big and the largest filesystem was moved to a new 4gig, again it grows and the largest filesystem is moved to a third 4gig, the first problem file grows and is extended to a 4th 4gig disk. now I arrive, I get 2 18gig disks I want to stripe these as one space and then allocate for the filesystems
first I want to move everything to the 36gig space and then stripe the 4 4gig's into 1 16gig then move some things back. PLEASE what is the most foolproof and least painfull way to do this! cpio, mirror, tape? all the mount points need to keep the orignal names i.e. /uvdata /uvdata2 /uvdata3....
this used to be the production system it is now the development/'failover' system but the production files are bigger than the filesystems. this is the reason to add lots of space. Thanks in advance. Ed
9 REPLIES
Shahul
Esteemed Contributor

Re: migrating to new disk

Hi

I think mirroring is the best option for U.

With rgds, Shahul
Jordan Bean
Honored Contributor

Re: migrating to new disk

Can you provide a vgdisplay -v and ioscan -fnC disk? I'd like to help you plan everything step by step if necessary.

Assuming all the 4gig disks are in one vg, if "Max PE per PV" is large enough to accommodate the 18gig disks, them mirroring may work well. Otherwise, a new vg will be required and the migration will be more involved.
Ed McKnight
Advisor

Re: migrating to new disk

I have attached devel.txt it contains the output from vgdisplay -v and ioscan -fnC disk.
Thanks for any help you can give me.
Ed
Jordan Bean
Honored Contributor

Re: migrating to new disk

What do you want to do with the two 9g disks of vg02? I was expecting to find only eight 4g and four 18g disks evenly distributed between jamaicas, but you also have two 9g disks occupying the same enclosure. I also noticed that this vg is using 32m extents.
Ed McKnight
Advisor

Re: migrating to new disk

Sorry, the 9gigs are to be removed these are not supported under our hp support contract. They were a stopgap measure to get us past an emergency
Jordan Bean
Honored Contributor

Re: migrating to new disk

Okay, ignoring the 9g disks.

Since the existing vgs cannot accommodate the full capacity of the 18g disks, I'd go with creating a new bootable vg with all the necessary filesystems and copy the data over with cpio. This would be a good time to determine if you want to resize any logical volumes (like swap). After successfully booting into the new vg, the previous vgs can be obliterated, the new vg renamed to vg00, the physical volumes recreated, and another new vg created to which some data can be moved. This is pretty involved, but the pay-off is a clean configuration... I'll throw together some more notes tonight while I have time...
Jordan Bean
Honored Contributor
Solution

Re: migrating to new disk

I've attached my procedures (far from complete since a few more decisions still need to be made). It looks like a posix-shell script, but it's not.
Ed McKnight
Advisor

Re: migrating to new disk

I know you said this is not a script but what do i do with the, if then do while fi done, part?
I thank you for your help and I am going over all the commands putting in my numbers and choosing sizes for the file systems.
I am changing the game plan to suit my boss,
the 2x18s will be for the data,
then 2x4s for root/sys files
1x 4 for /tmp
( our database uses var to reindex and some files are more than 1gig)
the last 4 will be held for whatever happens next.
1x 9gig will come out
1x 9gig for junk space/moving stuff/extra copies just in case.
Jordan Bean
Honored Contributor

Re: migrating to new disk

Sorry, I'm about to contradict myself. Let me completely truthful about this file.

It IS a posix shell script, but I never intended for it to be run. Even if it were complete, accurate, and started first with `set -ex` to exit on error and echo all commands and parameters as they are executed, I still wouldn't run it. I tend to document my procedures as a script because the instructions are exact and cannot be misunderstood. So if you are comfortable with the changes you've made, you can run the script and keep an eye on it while arguing with an end user on the phone about taking up 73% of /home because he or she refuses to delete anything. Since it's a posix shell script, you can (as long as you're in the posix shell) literally execute the if, while, for, until, case, etc blocks interactively.