I use Sunfire V480R , and i am seeing lot of scsi transport errors for the root drive & i think it is going to die . the system is having 2 drives & the second drive is kept unused . can someone guide me how do i clone the root drive to the seconddrive and make that bootable .
the best thing would be the "ufsdump" and "ufsrestore" command... another option is the flasharchive. have a look at the manpage of "flarcreate".
will ufsrestore make the 2nd drive bootable ? heard that dd command also helps in cloning the root drive ... how do we use dd for root drives ? do we need to be in single user mode ?
As DukeNuke wrote, the siblings ufsdump/ufsrestore are your friends.
I don't know the commands by heart, and I haven't got a Solaris box in reach right now.
So I may be wrong.
But first after having plugged in the new drive (run devfsadm -c disk) you will have to copy the VTOC.
If I remember correctly the command for this is fmthard (a bit misleading as it only writes the volume table of contents and doesn't format).
Please look up man fmthard, because you can pipe output from prtvtoc of your moribund drive right into fmthard to the new drive.
Then you will have to write the boot header.
I think the command was installboot. Again look up its manpage
because you have to give it the correct image for your platform (e.g. Sparc vs. IA).
There are examples in the manpage.
Then you need to create filesystems on each mountable partition (or slice in BSD/SunOS jargon).
Use newfs for that.
Then create mount points (mkdir) and mount the new filesystems of the slices.
Before you run the ufsdump, especially on / and /var (if these are separate FS)
you would normaly have to init to single user mode.
But UFS can make filesystem snapshots (damn forgotten the command, google or see man -k snap if you have a whatis created)
Then you mount the snapshot of / and ufsdump from there.
Of course on SDS, SVM, VxVM managed devices the whole procedure is totally different.
Btw, I would suggest that you mirror your system disks with SDS or SVM which are free Solaris tools.
svm/sds will not help... you need a free slice for the metadb... after cloning the drive setting up a mirror should be the next step.
i forget about one tool that might be usefull also. liveupgrade! read the manpage of "lucreate" and also check http://docs.sun.com for realy good infos about liveupgrade.
You can use dd if you want to. But it will copy the data and "all other stuff" including those bad blocks etc that exists in your current boot disk. Your disks should be of the same geometry also.
But ufsdump copys only your data which is 100% clean. you can restore the data in the partitions you create in your new(2nd) disk then installbootblk to make it bootable 
I believe this is what needs to be done. someone please correct this if it is wrong.
- you need to run below in order to copy over the disk geometry and partitioning:
prtvtoc /dev/rdsk/c?t?d?s2 | fmthard -s - /dev/rdsk/c?t?d?s2
-
restore from backup.
-
you need to run below in order for the new disk to be bootable:
installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c?t?d?s?
The OP said that the drive is already available. If the drives are identical, I too would use a dd command. This will copy the partition table and the boot block. The 2nd drive will end up thinking it is the first drive. So you would need to switch drives to use it.
First, boot the install cd in single user mode. From the OK prompt:
boot cdrom -s
Then some command like:
dd if=/dev/rdsk/c1t0d0s2 bs=65536 of=/dev/rdsk/c1t1d0s2
When this completes, power off, remove the first drive, move the 2nd drive to the first drives slot and reboot.
Perderabo - would you still need to run installboot to get the device bootable or does dd already satisfy this?
you don't need installboot after the dd.
Right. That is why we are using slice 2, devices that end in "s2". If your partition tables are correct, slice 2 is the entire user accessible disk. dd will make an exact copy of the disk. It is critical that the disks be the same model.
By the way, I once benchmarked various values for the bs= parameter and found that 65536 was optimal. Other values will slow you down.
Thats why because of precautions, checks and measures to be taken, ufsdump is much faster, easier and safer. 
indeed 
I must disagree. ufsdump works only with ufs filesystems. ufsrestore will not render a disk bootable, copy the partition table, or deal with any slices not containing ufs filesystems. A lot of analysis is needed to clone a disk piecemeal. If you really find a single dd command more complex than prtvtoc, fmthard, installboot, and several invocations of ufsdump and and newfs and ufsrestore, ok, I will take you at your word. But what if you have this task to perform on an HP-UX system, a Solaris system, an SCO system, and a Linux system. Each of these these systems needs a cloned root disk and each may or may not be partitioned and the partitions may or may not contain the local equivalent of a McKusick filesystem. Now which is easier? The dd is conceptually very easy and does not depend on intimate knowledge of the particular unix flavor or disk layout. This makes it attractive to someone without a great deal of Solaris knowledge... such as a person who might post the question in the first place.
If the disk is dominated by mostly empty ufs filesystems and/or the swap slice, then your way probably will be faster for larger disks. But for a 72 GB or smaller disk, like you might find on an old V480, you will need to hustle to beat the dd.