SUMMARY: Cloning disk with ufsdump/ufsrestore

From: sunmanagers freehome.ch <sunmanagers_at_freehome.ch>
Date: Fri Mar 14 2003 - 16:12:54 EST
Hi Sunmanagers

For a few days I was asking the Sunmanagers about cloning disk with the
command "dd". A lot of people where writing me with different notes etc.
Some of the people are giving me the note that it could be also be done by
ufsdump and ufsrestore. Thanks a lot to this people:

Maddox, Andrew
SANTHAKUMAR Siva
Tim Kirby
Shanker Durgad

Now this is through but if the disk are from the same vendor (I tested also
dd on disks with different vendors and it function well) and if it the disk
are the same size my opinion is to use the dd command because it is easier
to be done. Anyway if the disk are not from the same size or vendor it could
be done also with ufsdump and ufsrestore. Here how it works and what I did
if your would like to clone a disk with ufsdump and ufsrestore:

For testing we have two disks:

	c1t2d0	(Source Disk)
	c1t2d1	(Destination Disk)

The source disk has the following layout (slice 4 and 5 are for Disksuite
metadb's but are not initialized or configured):

	  0       root    wm       0 -  634      471.29MB    (635/0/0)
965200
	  1        var    wm     635 - 2014        1.00GB    (1380/0/0)
2097600
	  2     backup    wm       0 - 2732        1.98GB    (2733/0/0)
4154160
	  3       swap    wu    2015 - 2704      512.11MB    (690/0/0)
1048800
	  4 unassigned    wm    2705 - 2718       10.39MB    (14/0/0)
21280
	  5 unassigned    wm    2719 - 2732       10.39MB    (14/0/0)
21280
	  6 unassigned    wm       0               0         (0/0/0)
0
	  7 unassigned    wm       0               0         (0/0/0)
0

On our testsystem the disk are the same size. Firstable the layout/label
from the source disk must be copied to the destination disk because with
ufsdump and ufsrestore this information will not be transfered to the
destination disk because this commands are based on filesystem. This is also
a difference between dd and ufsdump because dd copies also the information
from labels and layouts because this command is based on blocks and not on
filesystem. Here it is how it wors to copy the information from
layout/label:

	# prtvtoc /dev/rdsk/c1t2d0s0 > /tmp/z
	# fmthard -s /tmp/z /dev/rdsk/c1t2d1s0
	fmthard:  New volume table of contents now in place.

The slice 0 from the destination disk has now the same layout like the
source disk. This could be controlled with the command:

	# format

To transfer the information from slice 0 source disk to the slice 0
destination disk the destination disk must be prepared to work on it. It
means at the moment there is no filesystem on this disk. To do this use the
command newfs. No option are neccessary because for default the filesystem
would be ufs. Only the raw device/slice must given to the command that newfs
knows what exactly must be don:

	# newfs /dev/rdsk/c1t2d1s0
	newfs: /dev/rdsk/c1t2d1s0 last mounted as /
	newfs: construct a new file system /dev/rdsk/c1t2d1s0: (y/n)? Y

Now we have a filesystem on slice 0 and we could mount the slice 0. This
would be made with the command mount and option -F for filesystem = ufs and
-o for read or write = rw and at least which slice = 0. At the end of the
command is the device with the slice which must be mounted:

	# mount -F ufs -o rw /dev/dsk/c1t2d1s0 /mnt

Now the device is mounted. With the following command ufsdump 0f = slice 0
and / = partition the filesystem / would be dumped. The whole dump would be
piped (I hope this is the correct english word) to the command ufsrestore
which would be executed in the mounted directory ufsresore and extracts the
dump.

	# ufsdump 0f - / | ( cd /mnt ;ufsrestore xvf - )
	Add links
	Set directory mode, owner, and times.
	set owner/mode for '.'? [yn] y
	Directories already exist, set modes anyway? [yn] y
	  DUMP: 405886 blocks (198.19MB) on 1 volume at 406 KB/sec
	  DUMP: DUMP IS DONE

After given the command, the partition / from source disk and / from the
destination disk looks based on files absolutly the same but there is a
information which MUST be changed and it is the information in "/etc/vfstab"
because on the destination disk in this file are the information from the
source disk (it means source disk will be mounted on the device c1t2d0 and
the destination diks on the device c1t2d1). This information must be changed
in "/etc/vfstab" on the destination disk:


	# vi /mnt/etc/vfstab

	---------- /mnt/etc/vfstab ----------

	#device         device          mount           FS      fsck
mount   mount
	#to mount       to fsck         point           type    pass    at
boot options
	#
	#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr          ufs     1       yes
-
	fd      -       /dev/fd fd      -       no      -
	/proc   -       /proc   proc    -       no      -
	/dev/dsk/c1t2d1s3       -       -       swap    -       no      -
	/dev/dsk/c1t2d1s0       /dev/rdsk/c1t2d1s0      /       ufs     1
no
		-
	/dev/dsk/c1t2d1s1       /dev/rdsk/c1t2d1s1      /var    ufs     1
no
	-
	swap    -       /tmp    tmpfs   -       yes     -

	---------- /mnt/etc/vfstab ----------

Now we changed the information and the work is done on slice 0. We can now
umount the slice 0:

	# umount /mnt

Proceed with the other slice similar like explained before. In our example
it would be:

	# newfs /dev/rdsk/c1t2d1s1
	newfs: /dev/rdsk/c1t2d1s1 last mounted as /var
	newfs: construct a new file system /dev/rdsk/c1t2d1s1: (y/n)? y

	# mount -F ufs -o rw /dev/dsk/c1t2d1s1 /mnt
	# ufsdump 1f - /var | ( cd /mnt ;ufsrestore xvf - )
	Set directory mode, owner, and times.
	set owner/mode for '.'? [yn] y
	Directories already exist, set modes anyway? [yn] y

	# umount /mnt

Slice 4 and 5 are in our example not importante because this slice as
explained are for Disksuite metadb's and on the source disk there are at the
moment no information and no filesystem because Disksuite was not
initialized or configured.

It is a good idea to check the slices which where transfered files before.
This could be done with the command fsck:

	# fsck /dev/rdsk/c1t0d1s0
	# fsck /dev/rdsk/c1t0d1s1
	# fsck /dev/rdsk/c1t0d1s2
	# fsck /dev/rdsk/c1t0d1s4
	# fsck /dev/rdsk/c1t0d1s5

Now it seems that all what done but something is missing!? The destination
disk looks now like the source disk with one exception; there is NO
boot-block on the destination disk. If you don't create a boot-block the
destination disk would never be bootable. To do this the system where it
must be done must be from the same architecture like the source disk it
means if the source disk is based on sun4m and you give now the command from
a architecture like sun4u to the destination disk the boot-block would not
work. This is what by me happens by the test (source disk based system on
sun4m > to install boot-block I tried to give the command from sun4u based
system and after I tried to boot the destination disk > result = destination
disk was not able to boot). Ok we set now the command for boot-block to the
destination disk to create there a boot-block:

	# /usr/sbin/installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
\
	/dev/rdsk/c1t2d1s0

Now you could boot the destination disk with the correct alias or the
correct device alias. If you don't know what the alias is give on the system
the following command:

	# ls -la /dev/dsk/c1t2d1s0
	/dev/dsk/c1t2d1s0 ->
../../devices/iommu@0,10000000/sbus@0,10001000/SUNW,soc@
1,0/SUNW,pln@a0000000,753a58/ssd@2,1:a

End the OS with init 6 and stop the system reboot if the banner of OBP
appears with stop + A. After that you are on the ok prompt. To set an alias
give following command:

	# nvalias clone1 /iommu@0,10000000/sbus@
	0,10001000/SUNW,soc@,0/SUNW,pln@a0000000,753a58/ssd@2,1:a

Use the alias with:

	ok boot clone1

Have fun with you new clone...! I hope I did not forgett something but I
tested it several times and it worked every time absolutly nice with no
errors. I wish you now a nice weekend by by :-)

Andrea
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Fri Mar 14 16:19:41 2003

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:05 EST