How to make a bootable backup of the operating system

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
[286 byte] By [Cinderella99a] at [2007-11-27 7:35:29]
# 1

Well, define "bootable" :)

It could very well be that the person who gave you the request wants something but that he/she immediately took a shortcut in asking your for a bootable backup.

So you really need to get back to this person and ask what the -goal- is. What would you guys like to be able to do in the future?

Would you like to be able to have a bootable backup? Create a ghost disk (which basically is a third mirror disk that you split off regularly).

Would you like to be able to boot even if your disks are broken? Create a boot server in the relevant subnet. Or just make sure you have the Solaris DVDs.

Would you like to be able to automatically restore your original system to a new system? Create flash archives (aka FLAR) and put them on your Jumpstart server.

Would you like to be able to boot another system as if it were the original? Kind of like Firewire Target Mode with Apple computers? That ain't gonna happen. Unless you take one of those ghost disks and put it in the new system.

I'm curious about your reply :)

Cailin_Coilleacha at 2007-7-12 19:16:00 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...
# 2

The fast way you can have a bootable media is to put your root

disk on a mirror and if something happens on the main disk

you can boot from the mirror, altough this is not the best practice.

The best practice with a mirror would be to have a 2 disk mirror

and when one fails the other still keeps working so you can

replace the failed one, not sure it needs a reboot, maybe not.

Max_a at 2007-7-12 19:16:00 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...
# 3

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):

0rootwm0 - 634471.29MB(635/0/0)

965200

1varwm635 - 20141.00GB(1380/0/0)

2097600

2backupwm0 - 27321.98GB(2733/0/0)

4154160

3swapwu2015 - 2704512.11MB(690/0/0)

1048800

4 unassignedwm2705 - 271810.39MB(14/0/0)

21280

5 unassignedwm2719 - 273210.39MB(14/0/0)

21280

6 unassignedwm00 (0/0/0)

0

7 unassignedwm00 (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 mountFSfsck

mountmount

#to mountto fsck pointtypepassat

boot options

#

#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs1yes

-

fd-/dev/fd fd-no-

/proc-/procproc-no-

/dev/dsk/c1t2d1s3--swap-no-

/dev/dsk/c1t2d1s0/dev/rdsk/c1t2d1s0/ufs1

no

-

/dev/dsk/c1t2d1s1/dev/rdsk/c1t2d1s1/varufs1

no

-

swap-/tmptmpfs-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.

mtalhaa at 2007-7-12 19:16:03 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...