Happy new year everyone
I found this small tut ( yes, another one... ) on how to clone a rootdrive.
The good part is and I don't know if this is new ( it was for me ) is that you don't have to have disks of the same size....
Cloning A Root Disk
Sometimes, it's necessary to make an exact copy of a disk, perhaps for backup purposes or perhaps during an OS upgrade, eg. a single client machine has a new OS installed and its disk is then cloned to all other client disks before individual changes are made. This is a very good way of ensuring that all client systems have identical software setups and is alot faster than installing products manually on each machine. The procedure itself is easy, so if you're someone who has dozens of systems to configure, then don't panic! The info here should help. Note that SGI's TechPubs site has further information.
There are two main ways to clone a disk: using xfsdump in conjunction with xfsrestore, or by using the tar command. The xfsdump method is listed first as it's faster and has other advantages. Sometimes though, the xfsdump method is not appropriate, in which case tar is used - example scenarios are explained later. xfsdump is just better at handling device files, etc. whereas tar can cause problems if not used properly.
In the description given here, I'm assuming certain things:
The disk to be cloned is a root (system) disk on SCSI ID 1 on controller 0. Cloning option disks is a very similar process - specifics connected with this are given later.
The disk to be copied onto is installed as SCSI ID 2 on controller 0.
The file system type on both disks is XFS (if your source file system is EFS, then use the tar method given later).
Bootup the system and login as root. Obtain a UNIX shell.
Create a mount point:
Use fx to repartition the extra disk (don't include my comments):
fx -x # Run fx
<Enter> # Select dksc
<Enter> # Select controller 0
2 # Select drive 2
<Enter> # Select lun 0
r # Select repartition option
ro # Select root drive option
<Enter> # Select XFS
yes # Yes, continue with the operation
.. # Return to the main menu
l # Create a new label
sy # Write out the new label
/exit # Exit fx
Use mkfs to create a new file system:
mkfs -b size=512 /dev/dsk/dks0d2s0
Note that if the disk is 4GB or larger, then exclude the block size definition, ie. just enter:
Mount the destination disk:
mount /dev/dsk/dks0d2s0 /0
Confirm the amount of space available with 'df -k'.
Now begin the copy process:
xfsdump -l 0 -p 5 - / | xfsrestore - .
This specifies a Level 0 dump (all files), progress report every 5 seconds, acting on the root file system. xfsdump sends the data to the standard output (by the use of the '-' character); this is piped to xfsrestore which is getting its data from the standard input (again by the use of the '-' character).
NB: I often find it useful to know how long these copy procedures take, eg. planning whether or not one has enough time to do multiple systems, etc. Thus, I always use the timex command to report how long the copy process lasted. Just put timex as the first command, ie. instead of the above, enter:
timex xfsdump -l 0 -p 5 - / | xfsrestore - .
It doesn't make any difference to the copy process, but it can be useful to have a appreciation for how long these tasks take.
Tip 1: if you're doing all this in a standard xterm, make it wider so that the progress messages don't get wrapped onto the next line. It's easier to read.
Tip 2: if you're using a multi-CPU system, remember you can use the runon command to force the copy process to run on a particular CPU. It's best to choose a CPU that's closest to the SCSI controller(s) involved in the copy process as this minimises system traffic. This is more relevant to newer systems such as Origin, Onyx2, etc. On older systems like Onyx and Challenge, it's more useful simply as a way to prevent the default CPU 0 being used to do everything, eg. for a 4-CPU deskside one might run the task on CPU 3 thus:
runon 3 timex xfsdump -l 0 -p 5 - / | xfsrestore - .
Finally, the volume header information from the root disk must be copied onto the target disk, though one could do this while the copying is going on. Enter the following:
dvhtool -v get sash sash /dev/rdsk/dks0d1vh
dvhtool -v get ide ide /dev/rdsk/dks0d1vh
dvhtool -v creat sash sash /dev/rdsk/dks0d2vh
dvhtool -v creat ide ide /dev/rdsk/dks0d2vh
There may be a symmon entry in the volume header too, in which case enter these extra commands:
dvhtool -v get symmon symmon /dev/rdsk/dks0d1vh
dvhtool -v create symmon symmon /dev/rdsk/dks0d2vh
Try the 'get symmon' command above; if it gives a not-found error, then there isn't any symmon entry present, so don't bother with the creat command.
Alternatively, one can copy the volume header interactively, which does have the advantage of being able to see exactly what is present in the volume header. Also, some systems will have other entries besides sash, ide and symmon, eg. O2 will often have a file called IP30prom. Thus, the interactive method is what I usually use. Here is what to enter (exclude my comments of course):
dvhtool /dev/rdsk/dks0d1vh # Access the system disk volume header
vd # Switch to a different menu
l # List contents of volume header
g sash sash # Copy volume header entries to disk;
g ide ide # If the 'l' command shows other entries
g symmon symmon # besides these, then copy them too.
quit # Exit from this session...
dvhtool /dev/rdsk/dks0d2vh # Access the destination disk
d sash # Delete old entries (if any are shown
d ide # to be present by the l command),
d symmon # including any besides, sash, ide and symmon.
a sash sash # Copy new entries to destination volume header...
a ide ide
a symmon symmon
write # Confirm out the changes
In fact, the amount of typing required for the interactive method is less, so that's another advantage.
Note that 5.3 handles the sash in a slightly different way from 6.2/6.5, so if the disk to be copied is a 5.3 installation, then the volume header copy operation can be compacted to:
dvhtool -v creat /stand/sash sash /dev/rdsk/dks0d2vh
And that's it! The machine can now be powered down and the cloned disk removed. Don't forget to change the clone disk's SCSI ID to 1, though on many systems that is done automatically via the use of a disk sled.
Most of the time, using xfsdump is the best, fastest and most efficient way to clone a disk. However, sometimes it may not be appropriate, eg. if the file system spans several disks but the destination is just a single disk (xfsdump only dumps a single named file system). In such circumstances, using tar is the main alternative.
However, using tar requires some special measures: all NFS mounts should be unmounted beforehand, as should the /proc file system. Also, any CDROMs and other media should be ejected from their respective devices.
Here is what to enter after the fx/mkfs procedure, making the /0 mount point and mounting the target disk:
tar cvBpf - . | (cd /0; tar xBpf -)
This command recursively copies the root disk or file system onto the extra disk. By recursive I mean that it also copies /0 into /0; however, at the time this is done, the only items in /0 are some hidden files (because the copy process hasn't yet alphabetically reached anything else), so not much extraneous data is copied. This is why I use /0 as a mount point: if the extra disk was mounted on /disk2 and there was a directory such as /Data or /Alias containing alot of data, then alot of unnecessary copying would occur, and the copy procedure might even fail due to running out of disk space. The character '0' comes before just about everything else in the ASCII character set, so these problems ar prevented.
Note that one definitely does not want to try and tar over /proc since /proc does not contain 'real' files - the entries in /proc relate to process information, used, for example, by the 'ps' command and 'killall'. The entries appear as very large files even though they're not; they are effectively images of running processes; tar cannot understand this and chokes on them, so one should unmount /proc before beginning the tar procedure.
Anyway, after the tar process has finished, enter the following to remount /proc and remove the unwanted '0' directory that's inside /0:
/bin/rm -rf 0
Using tar does have the advantage that one can see the files being copied, which is good feedback on the copying process. However, as the various necessary commands demonstrate, tar is sensitive to issues such as NFS mounts, /proc, mounted removeable media, etc. After the cloning has finished, copy over the volume header information just as for the xfsdump method.
I haven't tried this yet but I will very soon when I replace my 9GB rootdrive of my Octane2 to a 181GB drive ( thanks to the keeper