• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1005
  • Last Modified:

Hard-drive Upgrade

I’m a Unix programmer, not a sysadmin.  I’ve never done anything like this before, so I could use, well, maybe just a sanity check ….

I have a clone sparc box running Solaris-7.  I’ve had it for several years, and recently ran out of hard-drive space on /home.  Since the drive is about 5 years old anyway, I thought I’d just replace it with a larger drive, which I’ve already bought.

Here’s the trick:  I need to format & partition the drive, make it bootable, and then clone my existing system to the new drive.  Sounds simple enough ...

   (1)  I don’t want to reinstall Solaris from scratch because over the years, I’ve installed all kinds of stuff, customized things etc. …  And its not just about the effort involved, it’s a matter of trying to remember everything I’ve done.  So cloning is really the only answer.  But…

   (2)  I am concerned that if I just bulk copy the image of the original drive to the new drive, there may be some system-file content which encodes the physical parameters of the drive or its partitions.  (Where’s the partition table itself, for example?)

I suppose that I’d better keep the SCSI ID at ID0 since anything (scripts, etc) that might reference the raw slices would be affected (I guess too that its the default for booting ?).  Amyway, I can’t keep the partition sizes the same (as I would if were just replacing a bad drive with an identical one) because the whole point of this exercise is to upgrade.  So what kind of trouble do I have to lookout for?

  (3)  When allocating the new space, are there any partition size limitations I have to watch out for?  I think, for example that SWAP has to be less than 2GB (right?).  What about the other partitions?

   (4)  Also regarding allocations … I currently have 256MB  memory with 512MB SWAP.  It seems to me this doesn’t leave much for /tmp, but on the other hand, I’ve been running fine like this for years … would there be any advantage to allocating a larger Swap partition?

To format the drive, I thought I’d go through the exercise of doing a cold install onto the new drive from the Solaris installation CD.  Then, once the partitions have been setup and drive is made bootable, I’d reattach & reboot the original drive, and over-copy the old system to the new drive.

Something like this (please comment):

   for  x  in  0  1  3  4  5  6  7
        rm   –r   /newdrivemount/slice{$x}
        dd   /dev/dsk/c0t0d0s{$x}   /dev/dsk/c0t1d0s{$x}

   (5)  Will this work as I expect, or will I be indirectly clobbering the destination partition table in the course of copying…(?)

  • 4
  • 3
  • 2
2 Solutions
The best way to do this is to (from a boot into single user mode):

1) Use format to create slices on the new drive for each file system that you have. Note that it is possible to change the system layout while doing the transfer.

2) Use newfs on each file system on the new drive (skip the slice for swap).

3) Use ufsdump/ufsrestore to copy each existing file system to the appropriate FS on the new drive.

4) Install the bootloader (installboot)

5) Shut down and move the new drive to SCSI ID 0 and boot.
jlevie pointed you to the right direction, to make life easier, you can use JustUNIX's script
to clone the HD, see http:Q_20782407.html for the details about the script and learn more
details about how to clone a Solaris disk.
Eric-KAuthor Commented:
Thanks for the pointers, but you have to understand (as I said from the outset) that I’m not an admin, and the tools you guys regularly use are unfamiliar to me.  So when you tell me to “just” use this or that utility, try to appreciate that it makes me a bit nervous to do something critical for the first time, based on just what I read in a man-page … the script  yuzh  pointed me to is helpful, but again, I couldn’t tell just by reading it, if it had a typo … or even whether its actually doing what I really want.  I did read it though, and if I understand it correctly, the line:

    prtvtoc /dev/rdsk/${S}s2|fmthard -s - /dev/rdsk/${T}s2     # copy VTOC

suggests that its not doing what I really want ... that it clones partitions of identical size from the original (which from all articles I’ve read seems to be the thing people normally do).  So I’m still unsure whether its okay to clone to different sized partitions.

The thing is, that I’d have a lot more confidence in what I’m doing if I understood it better.  And to do that, I really need the answers to my original questions.  The main things I need to know are:

  (1)  If I first partition and then bulk-copy (by whatever means) do I corrupt the VTOC?  If not, then why not use dd, which seems pretty straight forward?  The main problem with ufsdump/ufsrestore, is that I have no place to store the backupset.
  (2)  What other files need to be specially treated? JustUNIX's script, for example, does something with vfstab, although I don’t get why.  
  (3)  I also asked for some advise as to how to apportion my new space …  (a) Are there any gottcha’s about maximum partition sizes, or anything similar that I should watchout for?  and (b) Is there any point to cranking up SWAP, if my system is already running fine?  Would it increase performance, for example?
I do appreciate you telling me how you would do it … if it were you … but for my own comfort level, I really need direct answers to these questions. Thx
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

For the purposes of illustration I'll assume that your existing disk layout looks like:

Slice    Use
0           /
1           swap
2           entire disk
3          /var
4          /home

And you'd like to replicate that to the new disk and increase the size of one or more partitions. During the copy the original boot disk will be at SCSI ID 0 and the new disk will be SCSI ID 1. The steps to accomplish this are:

1. Boot up in single user mode and mount all file systems with 'mount -a'.

2. Use format to create slices on the new disk of appropriate size. The slice numbers must match the old disk or else vstab will require editing.

3. Create file systems on the new slices:
    newfs /dev/rdsk/c0t1d0s0
    newfs /dev/rdsk/c0t1d0s3
    newfs /dev/rdsk/c0t1d0s4

4. Copy data from the old to the new disk with:
    mkdir /mnt/disk
    mount /dev/dsk/c0t1d0s0 /mnt/disk
    cd /mnt/disk
    ufsdump 0f - / | ufsrestore if -
    rm restoresymtable
    mount /dev/dsk/c0t1d0s3 /mnt/disk/var
    cd var
    ufsdump 0f - /var | ufsrestore if -
    rm restoresymtable
    mount /dev/dsk/c0t1d0s4 /mnt/disk/home
    cd ../home
    ufsdump 0f - /home | ufsrestore if -
    rm restoresymtable
    cd /

5. Install a bootblock on the new disk with:
    installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0

6. Shutdown and remove the old disk and change the SCSI ID of the new disk to be 0.

Adjust the procedure as necessary for your disk layout and file systems. As long as the new disk has the same layout as the old the system will boot right up on the new disk with no changes necessary to anything.

For more information on the commands used to do this see 'man format', 'man mount', 'man newfs', 'man ufsdump', and 'man installboot'.

You can't use dd to clone a disk if you want to change the size of one or more partitions. That would be a block-for-block copy and you'd wind up with the new disk appearing the be the same size as the old since the partition table would be copied as-is. To replicate the system and change partition sizes it is necessary to do file copies of the data onto a new file system of the appropriate size. And it is important to preserve all of the permissions and special file types during the copy. Hence the use of ufsdump/ufsrestore.
If you don't want to use script (well script is a lot easier), you just following jlevie's instructions in http:#13748501

you can use "format" command to find out the disk name for yor new HD, when you
partition the new HD, make sure the new partion size (equal or greater than the source
Eric-KAuthor Commented:
Thanks jlevie ... that's exactly what I needed.

But I do have a couple more questions:
(a) What are the " rm restoresymtable " commands for?
(b) The script referenced earlier was using fssnap (a command
     I wouldn't have known about had I not seen it there ...) and I
     notice you aren't using it.  Do I need it?  I should be okay if
     I'm in single user mode right?
As to (a)... When usfrestore is extracting data from the ufsdump archive it uses restoresymtable as a workspace file. The file isn't needed once the restore completes and can be deleted.

As to (b)... fssnap is a means of getting a frozen snapshot of the file system being dumped to avoid file corruption that can result if a file changes during the dump. The very nature of single user mode ensures that can't happen so fssnap isn't needed.
Eric-KAuthor Commented:

Thanks guys, I really appreciate your help.

The prize, of course goes to jlevie, but I do appreciate yuzh's help as well (reading the script you pointed me back-to did help me understand, and even though it wasn't your script in the first place, the pointer was helpful).  I want however, to especially thank you, jlevie, for taking the extra time and effort to spell it all out for me.

I'm giving you guys an A-rating; jlevie gets the buck-fifty, plus I'm gonna add an extra 50 points to split between you as a thank-you bonus.

Well Done!

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now