How to make a bootable backup of the operating system

Question

Hi,
I am given the task to make a bootable backup of the OS (Solaris 9). I know I can use ufsdump to backup the system in single user mode. However, to make a backup bootable, shall I backup the file system to a DVD? Any advice will be greatly appreciated!
Cinderella

Answer 1

i call it cloning the disk . you can install boot block as mentioned in second solution of cloning disk
e.g
# /usr/sbin/installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t2d1s0
################## solution 1 ####################################
dd if=/dev/rdsk/c0t1d0s2 of=/dev/rdsk/c0t4d0s2 bs=2048
############### solution 2 #####################3333
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 at 0,10000000/sbus at 0,10001000/SUNW,soc@
1,0/SUNW,pln at a0000000,753a58/ssd at 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 at 0,10000000/sbus@
     0,10001000/SUNW,soc@,0/SUNW,pln at a0000000,753a58/ssd at 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.