This document contains the entire README file on the fbackup and frestore commands. This document is also laid out like the README file and is split into 2 main sections:

1) BRIEF OVERVIEW (only for fearless sys admins)

2) DETAILS (for the more inquisitive types)

Currently the only files that exist are: fbackup, frestore, cvdisk, and dktab.usatlua5. If any files are added they would most likely be other dktab.hostname files.

All files are assumed to be located in /etc/backup.fsu directory. But these scripts can run from anywhere as long as all the files that they reference are located in the directory from where you started the script.

To backup the system, type fbackup.

To restore the system, do the following in sequence.

create a temporary directory

change to temporary directory

cpio -icvdumB -I <tape device name>

type frestore to run the script

reboot the machine

The machine reboots into restored operating system. At this point, login as root on the restored O/S (don't forget the root password of the newly restored O/S.)

change to the frestore directory

reboot the machine

type cvdisk to run the script

reboot the machine

The machine is now ready to boot into multi-user mode. Here is where TCP/IP will be reconfigured. Please see the network admin for new IP addresses.

There are only 3 scripts to this backup and restore procedure. The other files are necessary configuration files. The 3 scripts are fbackup, frestore, cvdisk. The only configuration file at this time is dktab.usatlua5. and gen.vt.

If any files are added they would most likely be other dktab.hostname files because the dktab file is based on a standard virtual disk mapping according to the disk array located at ACC. These files are very time consuming to make and it would be beneficial to have them preconfigured. If one does not exist then you can take the dktab.usatlua5 and copy it to dktab.<hostname> before you run fbackup. At least you will have a copy that you can modify. If you do not do this, then you will not have a base copy to work from.

All files are assumed to be located in /etc/backup.fsu directory. The fbackup script can run from anywhere. This script creates a temporary directory and stores all the needed configuration files in that place. Those files are placed on the first stack of the tape.

After restoring those configuration files located on the first stack of the tape, you MUST be located in the directory of the restored files before executing the frestore script. These files can be located in any directory that you choose, but you must be located in that directory when running frestore.

To backup the system, type fbackup, which can be run from anywhere. There are

only two variables that you should change from system to system:

tmpdir - which defines a temporary directory to store configuration files

before they are stored on tape.

filesys_list - a list of file systems to backup during fbackup. To add

more file systems to backup, simply add the basename of

the file system. For example, if /usr/spool was a file

system, then you would just add spool to the filesys_list

Do NOT include the "/". The only breakdown in logic, is when

you would have two file systems with the same basename.

This script is broken into these main sections:

The fbackup script creates the temporary directory to store all the needed configuration files. We have to find the root device by cXtCdXsX name (where X stands for the number of the controller, scsi, lun, etc...) We find the major and minor numbers of the /dev/root device and grep for those numbers when doing a long listing of the /dev/rdsk directory. If the root disk is mirrored, then a virtual disk will be the result of our long listing and greps. This is still not what we need, so we look in the dktab file and find the actual device name. The first line under the vdisk name will be the device that is being mirrored and is the raw device.

The file systems /usr and /var are sometimes separate file systems but are still located on the same physical disk as the root file system. If this is the case, then we do not need to backup those file systems because we do a device dump of the entire disk (all slices included). This fact is true for any file system. If the file system (that is defined in the filesys_list variable) does not exist on the same physical disk as the root file system, then fbackup will backup that file system with cpio.

To find out whether a file system is located on the same physical disk as the root file system, we find the device name of the file system in question such as /usr from the vfstab. If the device name is a vdisk, then we look in the dktab file. Once the device name is determined, then the name is compared with the root file system device name. To compare the two names, we must strip the slice information out of the names.

For example, the root file system device name might be c0t6d0s1 and the /usr file system might be c0t6d0s3. So the slice information is strip to find out if the file systems are on the same physical disk. Here the root (c0t6d0) without the s1 is compared with /usr (c0t6d0) without the s3.

If the file systems are separate then fbackup creates a file with the name <file system>.yes that contains the actual device name. For example, if /var was on a different physical disk than the root file system, then the device name of the /var file system would be stored in a file called var.yes.

Find the tape device using prtconf -T ... searching for an 8mm by looking for the word EXABYTE. To find another device, look at the output of prtconf and find the SCSI line. Change EXABYTE to the new word (5 words from the left) and check the number of lines down from the device name and change the NR + x value.

This section gets into the nitty gritty of the backup. First we store the root disk device name in a file called rootdev. That file will be used by frestore.

Then this section gets all the volume table of contents for each disk and stores that information in a file called <device name>.vt. For example, the root device name might be c0t6d0s0, so the file c0t6d0s0.vt would contain all the slicing information for that disk. Again, this gets the slicing information for the entire physical disk, so we only need to get it from all devices that end with slice 0 (s0). The command to get this information is:

prtvtoc -f <file>.vt /dev/rdsk/<device name>

Next, we store all the file system information by the disk slice device name of that file system. The file names take the form of <device name>.fs and contain the exact command to make the file system when restoring. For example, the /usr file system might be on device c0t6d0s3, so the file system information would be stored in c0t6d0s3.fs and would contain a mkfs command. Note that the root file system is stored in the file rroot.fs and not by its device name. The command to get this information is:

mkfs -F <file system type> -m <file system> > <file>.fs

fbackup then copies vfstab, dktab, fbackup, frestore, cvdisk, and dktab.<hostname> to the temporary directory. The prtvtoc and mkfs command might have created a lot of 0 byte files because of device names that exist in /dev/rdsk but are not used. We remove those files.

The tape_toc is a file that contains the backup tape contents produced by fbackup. This is created on the fly because of the different file systems that might be added to the filesys_list variable.

All file systems that are in the filesys_list variable and are NOT on the same physical disk as the root file system are backed up using cpio. fbackup determines this by looking for any files with the .yes extension (see section 2 for details). First we grab a listing of all the files that are just on that file system. The following command is used to store those listings:

cd <file system>; find . -mount -print > <file system>.bkf

This section is commented out by default, but can be used to create mountable diskettes to store all the configuration files that are stored on the first stack of the tape.

If you wish to make a bootable diskette, then use the dd command and find someone who has the original diskettes.

This section actually performs the backups. The way the tape is stacked is no secret. We just use a no-rewind tape device (usually has an n or nn at the end of its name). A no rewind tape device name might be /dev/rmt/c0t2d0s0nn.

The first stack is the configuration files. The second stack is the image of the root device disk. The third and so on would be for the file systems that are in the filesys_list variable and are NOT part of the physical disk that the root file system is on.

Before doing any backup, fbackup checks that the tape is mounted. This is done by trying to rewind the device. There is error checking that will be used in section 7, so all results are stored in a file named bkerr and tapeerr.

The commands that are used to backup the first stack are:

cd <temporary directory>

ls | cpio -ocvB -O /dev/rmt/<no-rewind tape device>

The commands that are used to backup the second stack are:

cd /

dd if=/dev/rdsk/<device name> of=/dev/rmt/<no-rewind tape> bs=200k

The commands that are used to backup the third or more stack are:

cd <file system>

cpio -ocvB < <temporary directory>/<file system>.bkf -O \

/dev/rmt/<no-rewind tape>

After all backups are complete, we rewind the tape by doing the following

command:

fbackup mails the results if there is an ERROR. stderr (2) for cpio produces the file names that are being backed up, so a bkerr file will always be created. Therefore, I will grep for fbackup in that file to determine whether to send the results.

The file tapeerr is created and contains the error if the tape could not be accessed by mt.

The file bkerr contains all errors (stderr 2) for cpio and dd. If the commands did not complete successfully, then fbackup writes the word "fbackup" into the file. We then grep for fbackup in the bkerr file to determine if we need to mail the results.

If results are mailed, then the hostname is put in the subject line, the grep of fbackup results are in the top section and the rest of the bkerr file is in the bottom half of the mail message. Currently, email is send to:

o9061c@usatlua7

To restore the system, do the following in sequence.

create a temporary directory

change to temporary directory

cpio -icvdumB -I <tape device name>

type frestore to run the script

This whole script will work under a restore from diskette or from an existing bootable unix machine. The fbackup script stacks the tape based on the file systems defined and whether the file system is on a different physical disk than the root file system. You should always reference a NO REWIND tape device when using cpio. For example, if the tape_toc contains 4 stacks and the last 2 are /var and /usr, then you should use the following commands after this script completes.

mount -F ufs /dev/dsk/cXtXdXsX /var

cd /var

cpio -icvdumB -I /dev/rmt/c0t2d0s0nn

mount -F ufs /dev/dsk/cXtXdXsX /usr

cd /usr

cpio -icvdumB -I /dev/rmt/c0t2d0s0nn

The frestore script is broken into these main sections:

The script adds /usr/sadm/sysadm/bin and /usr/ucb to your path. frestore will ask for the raw device in which you are restoring to. This device that you specify here will be the disk that contains the root file system. DO NOT put the full path name, just the actual name of the device in the form of cXtXdXs0. For example, c10t5d0s0. If you just hit return, then the default name of "c10t5d0s0" will be used. If you hit any other character, then the script will fail when it fails to open the device (in section 2) you specified.

All files ending in a .yes extension tells frestore that those file systems are backed up on tape in cpio format and should be restored once this script has finished. frestore only notifies that these backups exist and does nothing else because it doesn't know which raw devices to use in the new configuration.

Find the tape device using prtconf -T ... searching for an 8mm by looking for the word EXABYTE. To find another device, look at the output of prtconf and find the SCSI line. Change EXABYTE to the new word (5 words from the left) and check the number of lines down from the device name and change the NR + x value.

If you don't want frestore to try and find out what the tape device name is, then comment out the whole prtconf area within section 2. You should comment from where is says:

"# if trouble comment out from here to END OF COMMENT"

to where is says:

"# END OF COMMENT"

If that section is commented out, then the script will prompt you for the full path name of the no rewind tape device.

Here is where the device name that was entered is checked. If the device does not exist, then the script exits. Two variable are created and used throughout the script: rdev (the full path of the raw device, e.g. /dev/rdsk/c10t5d0s0) and dev (the full path of the block device, e.g. /dev/dsk/c10t5d0s0).

If the device does exist then the script move on and slices the disk as it was on the old system. The script knows that the file rootdev contains the name of the root device and that the name has a file associated with it with a .vt extension. The file <rootdevice>.vt contains all the vtoc information on that file system.

The only system commands run in this section is edvtoc and dklayout. The dklayout copies the boot file to the new root device. Once these commands are run, then frestore will check to see if all the slices have a character and block device name associated with each slice.

The restore process begins here. The dd command is used to grab the image off of tape and is transferred to the raw device, $rdev. Once the dd command completes, then an fsck is run on every slice (whether it exists or not). So here is where you might get some errors about fsck ... just make sure that the errors didn't occur in a slice that is active. Next, the root file system is mounted. This is critical to the rest of the script. If the file system did not mount, all of the guts of this script, which is section 5 and 6, will be bypassed. Section 6 is dependent on section 5, so if section 5 is bypassed, then so is section 6.

The stand file system is mounted, and if it fails, section 6 is bypassed. The first part of this section creates the character and block devices on the new root file system (before, we created them on the current system). The next part is to move the original files to a backup. If for some reason the script failed in the middle, the original file will never be erased. They will always be named file.ORIG.O and if that doesn't exist, then look for file.ORIG. The script moves all files to file.ORIG on the first pass. If you needed to run the script again on a second pass, the original files are moved to file.ORIG.O so that file.ORIG can be over-written by the script for trouble shooting.

The script modifies the following files on the newly created root file system that has been mounted under /mnt:

These files are linked with the corresponding device name of the new root disk.

/dev/root /dev/rroot /dev/swap /dev/rswap

/etc/vfstab

contains all the old mountable devices - frestore builds a new one

/etc/dktab

contains all the old disk array information - frestore assumes a new array will be

used and that dktab files have already been built based on the array located at

acc. this dktab file is called dktab.new

/etc/swapnodes

contains the old swap device - frestore places the new swap devices name in

this file ... this must be present on the new system.

/etc/dumpnodes

this file contains to old dump device (if any) ... the contents will be

replaced with slice 6 of the new root device.

/etc/inittab

this file will be rebuilt when we rebuild the kernel ... but for now, we

use a basic inittab found in /mnt/etc/conf/cf.d/init.base and we modify

the default level as 1.

/etc/ild/ildcf

this file contains the token ring mac addresses ... frestore will zero

those value out.

/etc/rc3.d/S40NetWare

Netware specific and must not be executed until modified by the novell

system admin.

/etc/rc2.d/S65ipx

Netware specific and must not be executed until modified by the novell

system admin.

/etc/gateways.eth

contains the gateway info and ip info ... since the restore is in a new

location, new ip addresses must be assigned.

/etc/hosts

moving this file will trigger tcpip to be reconfigured once the new system

is booted into multiuser mode.

The script also creates a directory called frestore on the new root file system, then copies all the backup configuration files (also located on the first stack of the tape) to that directory.

All the systems have arrays on them. Because we are restoring to a new system with a new array, we must rebuild the array table with the dktab file. But before we do that, we must tell the newly restored system that the array doesn't exist anymore. We must do this is order to boot into the new system and we can only add the new array, once we are booted into the new system. If the array information was left on the newly restore system, then the system would fail to boot. The frestore script modifies three file in addition to moving the dktab file: sassign, space.c, & vdisk

Again, these files are on the newly restore file system which is mounted under /mnt.

/etc/conf/node.d/vdisk

we remove all references to root and swap within this file.

/etc/conf/cf.d/sassign

we replace vdisk with SCSI.

/etc/conf/pack.d/vdisk/space.c

we turn off disk mirroring by setting vd_boot, vd_user, and vd_var to 0.

The script will add a generic vfstab that contains only the main disk that the root file system is on. For example, if the device name of the newly restored system is c10t5d0s0, then the following would be the generic vfstab file:

/dev/root /dev/rroot / ufs 1 yes -

/dev/dsk/c10t5d0s4 /dev/rdsk/c10t5d0s4 /var ufs 1 yes rw,suid

/proc - /proc proc - no -

/dev/fd - /dev/fd fdfs - no -

/dev/dsk/f0t /dev/rdsk/f0t /install s5 - no -

/dev/dsk/f1t /dev/rdsk/f1t /install s5 - no -

/dev/dsk/f0 /dev/rdsk/f0 /install s5 - no -

/dev/dsk/f1 /dev/rdsk/f1 /install s5 - no -

/stats - /stats stats - no -

/dev/dsk/c10t5d0sa /dev/rdsk/c10t5d0sa /stand bfs 1 yes -

The whole key to having the newly restore system boot is in this section. If you would to boot on the kernel from the old system, it would fail if the hardware wasn't identical. To avoid this problem, we boot up on a maintenance kernel called unix.ncrm. Once we have booted up on this kernel, then we can make a new one with all the correct hardware settings. To boot up on this kernel simply copy /mnt/stand/unix.ncrm /mnt/stand/unix.

The frestore script modifies the /mnt/stand/boot file. It changes the rdac references (the disk array) to SCSI and puts in the new minor numbers of the root and swap devices. This entry must exist for a dual boot disk set. Without this entry in the boot file, the newly restored file system will fail to boot.

The setboot command changes the CMOS settings on which disk drive to boot from.

This ends the description of the frestore command ... now you are ready to reboot the machine.

reboot the machine

The machine reboots into restored operating system. At this point, login as root on the restored O/S (don't forget the root password of the newly restored O/S.)

This script should only be run after you use frestore and have rebooted the machine. The cvdisk stands for create virtual disk.

This is to create all the vdisks for the array located in ACC. This script is based on the array following a standard that all devices will remain the same for any unix system restore. Currently, the ACC disk array has a hardware RAID 5 configuration and supports the list of the following devices.

change to the frestore directory

type cvdisk to run the script

A mktable will be performed then a verification of the raw devices will be performed. If any device is missing, the script will exit and you will need to go through sysadm / raid menu to configure the devices. This script assumes that a dktab has been generated previously using the following devices ... if one has not, then you have a lot of work on your hands to create one.

Probably most of this script will be done by hand. First you have to format each disk with fdisk. Then you must initialize the disk with dklayout. After that, you need to slice the disk into equal parts. The script uses the file gen.vt to slice the disk, but you can modify this file to your liking. The dktab.new file is moved into place and will be referenced by mkfs to create the file systems. File systems are then created on each virtual disk by executing the vdisk*.fs files. These files where created during fbackup.

Now that the virtual disk are all in place, cvdisk replaces the SCSI reference with rdac in the /stand/boot file. A new vfstab is generated by grepping for vdisk in the original vfstab and adding it to the current one. You should really double check the vfstab file before rebooting. To make sure everything is okay, try and mount each virtual disk by typing "mountall". This can be done after the kernel has been built.

The last thing cvdisk does is build a new kernel with idbuild.

Now it is up to you to double check everything and reboot the machine.

The machine is now ready to boot into multi-user mode. Here is where TCP/IP will be reconfigured. Please see the network admin for new IP addresses.