Thanks to all who responded As it turns out, since both systems are identical hardware this cloning process is reasonably simple. The following summarizes the procedure we have successfully developed and tested for cloning, based on the advice I received. initial assumptions: system 1 is the original Solaris 5.8 unit, system 2 is the new clone we are making. each server has 2x18 Gb drives, each with 3 partitions. All drives are identical model#s. There are 3 metadatabases on each drive slice 7 The md.tab looks like this: d0 -m d1 d2 1 d1 1 1 c0t0d0s0 d2 1 1 c0t1d0s0 d30 -m d31 d32 1 d31 1 1 c0t0d0s3 d32 1 1 c0t1d0s3 d50 -m d51 d52 1 d51 1 1 c0t0d0s5 d52 1 1 c0t1d0s5 Procedure on system 1 1. metadetach d0 d2; metadetach d30 d32; metadetach d50 d52 2. metaclear d2; metaclear d32; metaclear d52 3. remove second drive (c0t1) from system while hot. This will become the new root drive for system 2 4. metadb -d -f c0t1d0s0 4. put new drive in second slot (c0t1) and wait for it to spin up and be visible to OS 5. format with "prtvtoc -h /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2" 6. metadb -a -c 3 c0t1d0s0 7. metainit d2 1 1 c0t1d0s0; metainit d32 1 1 c0t1d0s0; metainit 52 1 1 c0t1d0s0 8. metattach d0 d2; metattach d30 d32; metattach d50 d52 9. after mirrors resync, reboot. The original system is identical to how we started now. procedure on system 2 1. while powered off remove any existing drives and install the drive removed from system 1 into the first drive slot (c0t0) on this system. 2. power up and allow to autoboot. It will fail with metadb errors throwing you into the miniroot shell. 3. metadb -d -f c0t1d0s0 4. reboot -- -s (to get into normal single-user mode) 5. install another disk into second (c0t1) location 6. format it with "prtvtoc -h /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2" 7. metadb -a -c 3 c0t1d0s0 8. metainit d2 1 1 c0t1d0s0; metainit d32 1 1 c0t1d0s0; metainit 52 1 1 c0t1d0s0 9. metattach d0 d2; metattach d30 d32; metattach d50 d52 10. after mirrors resync, reboot with init 6. This system is now a clone of system 1 additional notes: This worked for my two tests using a Netra T1 first and then an 1120. In the real case I will be on Netra 20's so the drives will be 36Gb. Also note the Netra20 uses C1 rather than C0. ---------------------------------------------------------------------- Original question: to the esteemed wizards... I have a project that requires upgrading all of the VOIP application software on a 5.8 Netra 20-server that is in 24x7 service with small maintenance window opportunities. Management is requesting we use a duplicate system to do the upgrade, leaving the original fully intact in case of problems. The condundrum is that we do not have time to clone the box onto a second and do the upgrade all within the prescribed maintenance window. Because the disks in this box are all mirrored with DiskSuite, it has been suggested to simply take out one of the drives for each mirror pair and put them in the duplicate system. Then we would do the upgrade on the second system and put new spare drives in both to re-mirror them after the application upgrade is completed. On the surface this sounds simple however my prior experiences with disksuite tell me this is risky. I'm sure it is easy to corrupt the partitions to a nonfunctional state. Obviously I may need to add or delete metadatabases but what other issues might occur? Has anyone done this and/or has anyone written a procedure that I can follow? Thanks Jon _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Wed Jul 2 16:54:09 2003
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:15 EST