Summary: ESA10000 swap

From: <jedmonds_at_claritas.com>
Date: Sat, 19 Feb 2000 21:51:19 -0500

Thanks to Dr. Thomas P. Blinn who pointed out that I could,

"create the new LSM RAID setup and then add it as a new volume you your
existing
AdvFS domain, then remove the old LSM RAID volumes from the AdvFS domain,
and let the AdvFS software move the data"

This is what I opted to do and it was indeed a simple thing to do.



> I've got a 4100 server running du 4.0d. It currently has an ESA10000
> (ESA#1) cabinet fully populated with 9GB drives. I now have another
> ESA10000 (ESA#2) fully populated with 18GB drives. I have successfully
> created the raidsets on the new ESA.
>
> I want to move the data from ESA#1 to ESA#2. Once ESA#1 is no longer
> needed, I'll replace those 9GB drives with 18 and 36 GB drives and repeat
> the process on another server.
>
> My basic thought process is as follows.
> Shutdown server.
> Install KZPBA controller.
> Attach ESA#2 to KZPBA
> Boot to single user mode.

Run the bcheckrc script to mount local file systems and enable access
to software in the /usr and /var hierarchies; possibly source the root
account's .profile to adjust search path, etc.

> Configure ESA#2 for LSM (duplicating ESA#1 configuration) and create
AdvFS
> file system (with similar naming convention as ESA#1)
> Mount new AdvFS domain as /temp
> Copy files from /data1 to /temp using following command
>
> vdump -0f - /data1 | vrestore -xf - -D /temp
>
> Modify fstab file to mount new filesystem to old filesystem mount point.

Assuming no applications are accessing the old file system (probably the
case if you're in single user mode), you can unmount /data1 and /temp and
then mount /data1 to verify your /etc/fstab changes; if you can't mount
the new RAIDset and domain at this point, you want to fix it before you
reboot.

> Reboot and verify the server is operational.
>
> Can anyone think of anything that I am overlooking? Anything I need to
> watch out for?

As noted above. Otherwise, looks reasonable, should work, don't be at all
surprised if copying the RAID takes a long time. There is an alternative
way of doing this, assuming you have AdvFS utilities, which is to create
the new LSM RAID setup and then add it as a new volume you your existing
AdvFS domain, then remove the old LSM RAID volumes from the AdvFS domain,
and let the AdvFS software move the data; this, too, will take a long time
but you can do it with the system up and operational, instead of doing it
in single user mode. If it were me, I might try the addvol/rmvol trick, I
have used it successfully in the past, but it's not as straight-forward as
the approach you are proposing.

> Thanks in advance.
>
> James Edmonds
> UNIX Administrator
> Claritas Inc.

You're welcome.

Tom

 Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer Corporation
  110 Spit Brook Road, MS ZKO3-2/W17 Nashua, New Hampshire 03062-2698
   Technology Partnership Engineering Phone: (603) 884-0646
    Internet: tpb_at_zk3.dec.com Digital's Easynet: alpha::tpb
     ACM Member: tpblinn_at_acm.org PC_at_Home: tom_at_felines.mv.net

  Worry kills more people than work because more people worry than work.

      Keep your stick on the ice. -- Steve Smith ("Red Green")

     My favorite palindrome is: Satan, oscillate my metallic sonatas.
                              -- Phil Agre, pagre_at_alpha.oac.ucla.edu

     Yesterday it worked / Today it is not working / UNIX is like that
               -- apologies to Margaret Segall

  Opinions expressed herein are my own, and do not necessarily represent
  those of my employer or anyone else, living or dead, real or imagined.
Received on Sun Feb 20 2000 - 03:01:29 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:40 NZDT